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 -
Yes, but you will also neet to install systemtap-devel on fedora.
You might also use id_perf.stp just for id
It is not required to restart the script between successive id runs,
the variables are cleared when systemtap detects id had started or
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
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
"Nov 21 10:25:00 fc24-vm.my.domain sssd[nss]: More groups have the same GID
in directory server. SSSD will not work correctly."
This appears to be resolved by modifying ldap_idmap settings. For example:
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.