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
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 LS _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
