On Tue, Nov 22, 2016 at 09:23:39AM +0100, Lukas Slebodnik wrote: > On (21/11/16 18:09), [email protected] wrote: > >What is the appropriate usage of these scripts? Should I run "stap > >nested_group_perf.stp" and in another terminal run id $username or su - > >$username ?. > > > Yes, but you will also neet to install systemtap-devel on fedora. > You might also use id_perf.stp just for id > stap /usr/share/sssd/systemtap/id_perf.stp
Also iirc kernel-debuginfo, but this should be pulled by stap automatically (I think). > > It is not required to restart the script between successive id runs, > the variables are cleared when systemtap detects id had started or > finished. > > The situation is little bit different for nested_group_perf.stp > Please note that since the script is supposed to be used in scenarios such > as > tracing "id" performance, which typically involve multiple group requests. > Therefore, the variables are not zeroed out and you need to interrupt the > script manually with Ctrl+C. > > >Also I have setup a new Fedora 24 VM with sssd 1.14.2. I am not sure what > >is going on, but there appears to be some issues with group lookups and now > >it is affecting sudo. I have not encountered these issues on Ubuntu 16.04 > >with sssd 1.13 so far. > > > >1. Adding an AD group, say, MY.DOMAIN\\linuxadmins, to /etc/sudoers, > >"%MY.DOMAIN\\linuxadmins ALL=(ALL) ALL" does not allow group members to > >elevate privileges. I have verified the users are in the group via id, and > >I have verified the group contains the users via "getent group > >MY.DOMAIN\\linuxadmins". However simply adding the users directly to > >/etc/sudoers allows elevation. > > > >2. Users are not seen as members of groups after attempting to elevate with > >sudo. As in id and getent group no longer show the user as belonging to that > >group. > >I also noticed the following error from systemctl status sssd (potentially > >same as fedorahosted.org/sssd/ticket/2982): > > > >"Nov 21 10:25:00 fc24-vm.my.domain sssd[nss][729]: More groups have the same > >GID [965793034]in directory server. SSSD will not work correctly." > > > >This appears to be resolved by modifying ldap_idmap settings. For example: > > > >ldap_idmap_range_min=100000 > >ldap_idmap_range_max=2000100000 > >ldap_idmap_range_size=2000000000 > > > Have you changed id mapping related options before? > If yes, did you remove sssd cache? rm -f /var/lib/sss/db/* > > I do not see a reason why changing idmapping options should fix > problem with "More groups have the same" > > >I am now very concerned that 1.14 means I cannot use sssd for non-graphical > >environments if sudo cannot find group members. > Missing groups might cause problems also for other programs and not just for > sudo. Feel free to file a fedora BZ with sanitized sssd configuration and > sssd log files. > https://fedorahosted.org/sssd/wiki/Troubleshooting I think if this issue happens after the cache is cleared, it would be nice to peek at the ldb cache with ldbsearch to see which objects have the duplicate gid.. _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
