realm join taking more than 5 minutes - caused time out
by smfrench@gmail.com
In our of cases, we noticed RHEL7.3's "realm join" taking more than 5 minutes (which timed out in our cli). As you can see from the verbose output below the two longest stretches (greater than 2 minutes! each) were waiting between launching "net ads join" and piping the password in (and similarly "net ads keytab create" had a long delay between starting the command and giving it the password). Looking at realmd service/realm-samba-enroll.c e.g. begin_net_process() calling out to realm_command_runv_async it was not obvious why there should be any delay between the launch of the net command the passing of the password (I did see one report of "net ads keytab create" hanging if the keytab already existed but that is not the same problem as this). Any idea how/why such long delays between launching net and inputting the password in realmd async code? > 5 minutes is a long time to do something that usually completes in 10 seconds
2017-08-01 19:54:09 realmd[14197]: * Performing LDAP DSE lookup on: ...
2017-08-01 19:54:09 realmd[14197]: * Successfully discovered ...
2017-08-01 19:54:10 realmd[14197]: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
2017-08-01 19:54:10 realmd[14197]: * Joining using a manual netbios name: ....
2017-08-01 19:54:10 realmd[14197]: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.0DFU4Y -U <username> ads join <domain>
2017-08-01 19:56:42 realmd[14197]: Enter <username's> password:
2017-08-01 19:56:42 realmd[14197]: Using short domain name -- <short name>
2017-08-01 19:56:42 realmd[14197]: Joined ... to dns domain ...
2017-08-01 19:56:42 realmd[14197]: * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.0DFU4Y -U <username> ads keytab create
2017-08-01 19:59:33 realmd[14197]: Enter <username's> password:
6 years, 8 months
[sssd PR#202][opened] T3315 infopipe group users master
by celestian
URL: https://github.com/SSSD/sssd/pull/202
Author: celestian
Title: #202: T3315 infopipe group users master
Action: opened
PR body:
"""
Reproducer is:
```
# PREPARING
ipa user-add --first=Test --last=User --email=u1(a)test-domain.sssd test_user
ipa group-add test_group
# REPRODUCER
systemctl daemon-reload
sudo su -c "truncate -s0 /var/log/sssd/*.log"
sudo su -c "rm -f /var/lib/sss/db/*"
sudo su -c "rm -f /var/lib/sss/mc/*"
sudo systemctl restart sssd.service
ipa group-add-member --users=test_user test_group
sss_cache -UG
getent group test_group
# getent show user test_user in test_group, but dbus call doesn't:
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe \
/org/freedesktop/sssd/infopipe/Groups \
org.freedesktop.sssd.infopipe.Groups.FindByName \
string:test_group
# command above returns <RESULT_OBJECT>
# We need to update group in cache because method "org.freedesktop.DBus.Properties.GetAll"
# doesn't update records (<-- this should be better commented)
dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe \
<RESULT_OBJECT> \
org.freedesktop.sssd.infopipe.Groups.Group.UpdateMemberList
# --> this call doesn't work without patch "IFP: Parse ghost name in Group.UpdateMemberList"
# after this call group is updated in cache and we can call:
dbus-send --system --print-reply --dest=org.freedesktop.sssd.infopipe \
<RESULT_OBJECT> \
org.freedesktop.DBus.Properties.GetAll \
string:"org.freedesktop.sssd.infopipe.Groups.Group"
# We expect test_user in result users array.
# CLEANING
ipa group-del test_group
ipa user-del test_user
```
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/202/head:pr202
git checkout pr202
6 years, 8 months