Thanks for the quick reply. FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd packages.
I don't seem to have the "ldbadd" command on my client, either. Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and I see more in the logs now. But, I don't seem to be seeing my UID changing like I'd expect, and I seem to no longer be able to run sudo on my client... If I unapply the view from my client's host, though, sudo again works as expected. So, it's picking up... something... just not quite everything yet. On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose <sb...@redhat.com> wrote: > On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote: > > On Tue, Feb 16, 2016 at 04:23:10PM +0000, Mike Kelly wrote: > > > >> Thanks. Here's what is hopefully the relevant lines: > > > > > > > > I'm sorry, but these logs only capture how the original entry was > > > searched, not the overrides. Can you capture the full logs since the > sssd > > > startup? Also please make sure the cache was invalidated prior to the > > > request with sss_cache -E. > > > > > > Attached are the full logs since a restart of sssd. > > > > Thank you, the logs helped. The IPA client reads the idview at startup > > time either from the cache or the IPA server. Since there is of course > > no idview name saved in the cache of your client the name must be looked > > up from the server. The lookup of the idview name is part of the request > > which reads other data about the IPA domain and possible trusted > > domains. Unfortunately the current code expects that e.g. the domain SID > > of the IPA domain is defined before it proceeds to read the idview. > > > > This is of course a bug and I will try to fix it. If you would like to > > try a work-around you can call ipa-adtrust-install on one of your IPA > > servers. This will create the needed data on the server. It is > > sufficient to call it on one server because the data will be replicated > > to the other servers and since you currently not plan to add a trust to > > a AD domain, you do not have to prepare additional services on other > > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to > > add a trust). > > > > If you can wait a day or two I'd be happy to prepare a SSSD test build > > with a fix. > > It looks it was easier than I expected. You can find test packages for > RHEL/CentOS-7 at > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051 > > (Please tell me if you need packages for a different platform) > > Before you upgrade the package on a client please run > > # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF > dn: cn=views,cn=sysdb > viewName: default > EOF > > Otherwise SSSD will not recognise the name change and still show the > original values. As an alternative you can remove the cache completely > before starting the new version or unapply the idview and apply it again > on the server while you restart the new sssd version on the client after > each change on the server. I'll try to think of a way to make this more > easy without breaking the existing detection of a change in the idview > name. > > HTH > > bye, > Sumit > > > > > bye, > > Sumit > > > > > > > > I ran these commands: > > > > > > systemctl stop sssd > > > > > > echo '----MARK----' >> /var/log/sssd/sssd_home.pioto.org.log # so I > could > > > mark were the restart happened > > > > > > sss_cache -E > > > > > > systemctl start sssd > > > > > > sss_cache -E > > > > > > id pioto > > > > > > ---- > > > > > > I still don't see the override being applied. Possibly because of this > line? > > > > > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]] > > > [ipa_get_ad_override_send] > > > (0x4000): View not defined, nothing to do. > > > > > > So, I get the feeling that, for whatever reason, sssd isn't correctly > > > deciding that my id view applies to this host, or just isn't looking > it up? > > > > > > Is there possibly some sort of extra configuration that I've missed to > tell > > > SSSD to apply these views? From what I can tell, it should just pick > these > > > up out of the box, from the configuration built by > ipa-client-install...? > > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > -- Mike Kelly
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project