On Tue, Nov 22, 2016 at 09:23:39AM +0100, Lukas Slebodnik wrote:
On (21/11/16 18:09), zfnoctis(a)gmail.com 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..