On Sat, 2013-09-14 at 13:11 -0400, Brian Lindblom wrote: > Of course, I would imagine that since the GECOS field is set upon > account creation based on the values provided for first and last name, > and since GECOS is not a provided field in the UI for user attributes, > that GECOS should be updated automatically to reflect those changes. > Bug perhaps?
If gecos is set on creation but not updated it is a bug please open a ticket with the details. Thanks, Simo. > > On Fri, Sep 13, 2013 at 6:26 PM, Brian Lindblom <b...@usf.edu> wrote: > I've run into this exact same problem. Check the output of > > > ipa user-find --all <user> > > > The GECOS field is probably set to the old information. You > can use > > > ipa user-mod --gecos="New Name" <user> > > > to correct the issue. This solved it for me. > > > -Brian > > > On Fri, Sep 13, 2013 at 3:55 PM, cbul...@gmail.com > <cbul...@gmail.com> wrote: > > Hi Jakub, > > I attached the log files after doing the same test > that you requested me > before. > Please let me know if you need anything else. > > Thanks!! > > > > On 09/10/2013 06:30 AM, Jakub Hrozek wrote: > > > On Wed, Sep 04, 2013 at 11:14:50AM -0500, > cbul...@gmail.com wrote: > >> Hi Jakub, > >> > >> > >> Thanks for your time and tips about sssd cache! > >> > > I'm sorry about the late response, I didn't flag > your response when it > > came back.. > > > >> I did the test and let me explain what I got: > >> > >> - After step 4 I can see dataExpireTimestamp to 1 > for the user. > > OK, this is expected. > > > >> - After step 7 dataExpireTimestamp is back to 0 but > the user data have > >> not changed. > > This is really strange because if the > dataExpireTimestamp was reset > > after the lookup, then the backend has updated the > entry...and it should > > have updated the entry with the up-to-date data.. > > > > Can you put debug_level=8 into the [nss] and > [domain] sections > > and paste or attach the contents > of /var/log/sssd/sssd_nss.log and > > /var/log/sssd/sssd_$domain.log after the request > that follows the sss_cache > > run? > > > > Also in the logs you should see the server the SSSD > connects to, can you > > check if there is maybe some replica that is out of > sync? > > > > Unfortunately I can't reproduce the bug here.. > > > >> The first line after the command ldbsearch is: > >> > >> asq: Unable to register control with rootdse! > > No, that's an internal info, ignore this message. > > > >> Is it a problem? > >> > >> We are not using nscd service. > >> > >> Please let me know if you need to do some other > tests. > >> Thanks in advance! > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipaemail@example.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Brian Lindblom (Smith) > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > > > > > -- > Brian Lindblom (Smith) > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > _______________________________________________ > Freeipa-users mailing list > Freeipafirstname.lastname@example.org > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users