On Wed, Jul 04, 2018 at 09:06:50AM +0200, John Hearns wrote:
Sumit, thankyou.
What I have done is to write a Python script which loops over all local
users.
The script calls sss_override user-set for each user. Then the script runs
user-export to create a file as you suggest.
I have edited the sssd.service unit file, and placed the changed copy in
/etc/systemd/system/sssd.service
This has an added Post Start action to read in the file using user-import.
These are the lines I added:
ExecStartPost=-/usr/sbin/sss_override user-import /etc/sssd/overrides
TimeoutStartSec=180
ok, this should do no harm, but as said, as long as the cache file is on
a disk and is not removed during reboots or on other circumstances this
should not be needed.
bye,
Sumit
On 4 July 2018 at 08:41, Sumit Bose <sbose(a)redhat.com> wrote:
> On Thu, Jun 14, 2018 at 02:33:22PM +0200, John Hearns wrote:
> > We have an existing set of users in a local passwd file
> > I want to run sss_override to create mappings from the AD SID numbers to
> > the existing uid numbers.
> >
> > What is the concensus on running sss_override?
> > I can script it to either parse through the existing passwd file and make
> > an override entry per user,
> > or to parse the file and create an import file which is run once with
> > import-user
> >
> > But when is a good time to run this?
> >
> > In a daily cron job
> >
> > When sssd is started, which would involve editing the systemd unit file
> >
> > Creating a new systemd service which depends on sssd.service . This
> service
> > runs sss_override and then restarts sssd.service
> >
> > Or am I misunderstanding something?
> >
> > I am assuming here we have on-disk sssd databases. If the databases are
> on
> > a tmpfs then clearly the sss_override must be run at boot time by one of
> > the above methods also.
>
> As long as the cache file in /var/lib/sss/db is not removed it should be
> sufficient to run sss_override for each user once and then the override
> data should stay in the cache.
>
> I once got a report that the link between the original user data and the
> override data got lost, but I wasn't able to reproduce this so far.
>
> It is always a good idea to call user-export/group-export to have a
> backup file around.
>
> HTH
>
> bye,
> Sumit
>
>
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@
>
lists.fedorahosted.org/message/TMGIPZGSONS6Q62RGKFBI5EDZ7GPCEUU/
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@
>
lists.fedorahosted.org/message/R3L7BBZGZ5URRV7VYSBIUMRSKVZRYIMJ/
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahost...