[Bug 1807246] Re: after upgrading to bionic, my session forgets who I am frequently
Andreas Hasenack
andreas at canonical.com
Wed Jan 16 19:12:53 UTC 2019
** Description changed:
[Impact]
- * An explanation of the effects of the bug on users and
+ * An explanation of the effects of the bug on users and
- * justification for backporting the fix to the stable release.
+ * justification for backporting the fix to the stable release.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ * In addition, it is helpful, but not required, to include an
+ explanation of how the upload fixes this bug.
[Test Case]
- * detailed instructions how to reproduce the bug
+ * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test)
+ sudo apt update
+ sudo apt install sssd slapd ldap-utils
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
+ * Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password:
+ sudo dpkg-reconfigure slapd
+
+ * Populate the ldap directory:
+ ldapadd -x -D cn=admin,dc=example,dc=com -w secret
+ dn: ou=People,dc=example,dc=com
+ ou: People
+ objectClass: organizationalUnit
+
+ dn: ou=Group,dc=example,dc=com
+ ou: Group
+ objectClass: organizationalUnit
+ dn: uid=testuser1,ou=People,dc=example,dc=com
+ uid: testuser1
+ objectClass: inetOrgPerson
+ objectClass: posixAccount
+ cn: testuser1
+ sn: testuser1
+ givenName: testuser1
+ mail: testuser1 at example.com
+ userPassword: testuser1secret
+ uidNumber: 10001
+ gidNumber: 10001
+ loginShell: /bin/bash
+ homeDirectory: /home/testuser1
+
+ dn: cn=testuser1,ou=Group,dc=example,dc=com
+ cn: testuser1
+ objectClass: posixGroup
+ gidNumber: 10001
+ memberUid: testuser1
+
+ dn: cn=ldapusers,ou=Group,dc=example,dc=com
+ cn: ldapusers
+ objectClass: posixGroup
+ gidNumber: 10100
+ memberUid: testuser1
+
+ ^D
+
+ * Create /etc/sssd/sssd.conf with the following contents:
+ [sssd]
+ services = nss
+ domains = local,example
+
+ [nss]
+ debug_level = 6
+ memcache_timeout = 30
+
+ [domain/local]
+ id_provider = local
+ enumerate = true
+ max_id = 1000
+
+ [domain/example]
+ id_provider = ldap
+ enumerate = true
+ auth_provider = ldap
+ ldap_uri = ldap://localhost
+ ldap_search_base = dc=example,dc=com
+ ldap_tls_reqcert = allow
+ cache_credentials = true
+ use_fully_qualified_names = false
+
+ * Adjust permissions and restart:
+ sudo chmod 0600 /etc/sssd/sssd.conf
+ sudo systemctl restart sssd
+
+ * Test:
+ id testuser1
+
+ Should return:
+ uid=10001(testuser1) gid=10001 groups=10001,10100
+
+ * Create a home directory:
+ sudo mkdir /home/testuser1 -m 0700
+ sudo chown testuser1:testuser1 /home/testuser1
+
+ * Become testuser1 and run this script. It should fail at the 4th attempt, i.e., after about 40 seconds:
+ sudo -u testuser1 -i
+ while /bin/true; do date; whoami || break; echo; sleep 10; done
+
+ Wed Jan 16 19:12:02 UTC 2019
+ testuser1
+ ...
+
+ Wed Jan 16 19:12:22 UTC 2019
+ whoami: cannot find name for user ID 10001: Unknown error 1432158300
+
+
+ With the fixed packages installed, that while loop won't be exited.
[Regression Potential]
- * discussion of how regressions are most likely to manifest as a result
+ * discussion of how regressions are most likely to manifest as a result
of this change.
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the
- event of a regression.
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the
+ event of a regression.
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
[Other Info]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
- * and address these questions in advance
+
+ * Anything else you think is useful to include
+ * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
+ * and address these questions in advance
[Original Description]
I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.
However, after upgrading to 18.04.1 LTS, I find that the system is
continuously forgetting who I am. After a few commands, or a few
minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
to run sudo or whoami, it says that I am an unknown user. for example,
```
whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300
```
if I run the id command on my username, it returns the correct results,
and whoami/sudo/other restricted commands will work again for a short
time before forgetting who I am again.
In the sssd_nss.log file, I see the lookup against the @local domain,
but I do not see a related lookup in the ldap domain either in that log
file or in the log file specific to the ldap domain.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: sssd 1.16.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Thu Dec 6 12:30:43 2018
Ec2AMI: ami-ea677d80
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
SourcePackage: sssd
UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)
** Description changed:
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test)
sudo apt update
sudo apt install sssd slapd ldap-utils
- * Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password:
+ * Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password. For the rest, accept defaults:
sudo dpkg-reconfigure slapd
* Populate the ldap directory:
ldapadd -x -D cn=admin,dc=example,dc=com -w secret
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
dn: uid=testuser1,ou=People,dc=example,dc=com
uid: testuser1
objectClass: inetOrgPerson
objectClass: posixAccount
cn: testuser1
sn: testuser1
givenName: testuser1
mail: testuser1 at example.com
userPassword: testuser1secret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/testuser1
dn: cn=testuser1,ou=Group,dc=example,dc=com
cn: testuser1
objectClass: posixGroup
gidNumber: 10001
memberUid: testuser1
dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10100
memberUid: testuser1
^D
* Create /etc/sssd/sssd.conf with the following contents:
[sssd]
services = nss
- domains = local,example
+ domains = local,example
[nss]
debug_level = 6
memcache_timeout = 30
[domain/local]
id_provider = local
enumerate = true
max_id = 1000
[domain/example]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = false
* Adjust permissions and restart:
sudo chmod 0600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
* Test:
id testuser1
Should return:
uid=10001(testuser1) gid=10001 groups=10001,10100
* Create a home directory:
sudo mkdir /home/testuser1 -m 0700
sudo chown testuser1:testuser1 /home/testuser1
* Become testuser1 and run this script. It should fail at the 4th attempt, i.e., after about 40 seconds:
sudo -u testuser1 -i
while /bin/true; do date; whoami || break; echo; sleep 10; done
Wed Jan 16 19:12:02 UTC 2019
testuser1
...
Wed Jan 16 19:12:22 UTC 2019
whoami: cannot find name for user ID 10001: Unknown error 1432158300
-
With the fixed packages installed, that while loop won't be exited.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result
of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.
However, after upgrading to 18.04.1 LTS, I find that the system is
continuously forgetting who I am. After a few commands, or a few
minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
to run sudo or whoami, it says that I am an unknown user. for example,
```
whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300
```
if I run the id command on my username, it returns the correct results,
and whoami/sudo/other restricted commands will work again for a short
time before forgetting who I am again.
In the sssd_nss.log file, I see the lookup against the @local domain,
but I do not see a related lookup in the ldap domain either in that log
file or in the log file specific to the ldap domain.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: sssd 1.16.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Thu Dec 6 12:30:43 2018
Ec2AMI: ami-ea677d80
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
SourcePackage: sssd
UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)
** Description changed:
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test)
sudo apt update
sudo apt install sssd slapd ldap-utils
* Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password. For the rest, accept defaults:
sudo dpkg-reconfigure slapd
* Populate the ldap directory:
- ldapadd -x -D cn=admin,dc=example,dc=com -w secret
+ ldapadd -x -D cn=admin,dc=example,dc=com -w secret -c <<EOF
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
dn: uid=testuser1,ou=People,dc=example,dc=com
uid: testuser1
objectClass: inetOrgPerson
objectClass: posixAccount
cn: testuser1
sn: testuser1
givenName: testuser1
mail: testuser1 at example.com
userPassword: testuser1secret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/testuser1
dn: cn=testuser1,ou=Group,dc=example,dc=com
cn: testuser1
objectClass: posixGroup
gidNumber: 10001
memberUid: testuser1
dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10100
memberUid: testuser1
- ^D
+ EOF
* Create /etc/sssd/sssd.conf with the following contents:
[sssd]
services = nss
domains = local,example
[nss]
debug_level = 6
memcache_timeout = 30
[domain/local]
id_provider = local
enumerate = true
max_id = 1000
[domain/example]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = false
* Adjust permissions and restart:
sudo chmod 0600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
* Test:
id testuser1
Should return:
uid=10001(testuser1) gid=10001 groups=10001,10100
* Create a home directory:
sudo mkdir /home/testuser1 -m 0700
sudo chown testuser1:testuser1 /home/testuser1
* Become testuser1 and run this script. It should fail at the 4th attempt, i.e., after about 40 seconds:
sudo -u testuser1 -i
while /bin/true; do date; whoami || break; echo; sleep 10; done
Wed Jan 16 19:12:02 UTC 2019
testuser1
...
Wed Jan 16 19:12:22 UTC 2019
whoami: cannot find name for user ID 10001: Unknown error 1432158300
With the fixed packages installed, that while loop won't be exited.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result
of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.
However, after upgrading to 18.04.1 LTS, I find that the system is
continuously forgetting who I am. After a few commands, or a few
minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
to run sudo or whoami, it says that I am an unknown user. for example,
```
whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300
```
if I run the id command on my username, it returns the correct results,
and whoami/sudo/other restricted commands will work again for a short
time before forgetting who I am again.
In the sssd_nss.log file, I see the lookup against the @local domain,
but I do not see a related lookup in the ldap domain either in that log
file or in the log file specific to the ldap domain.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: sssd 1.16.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Thu Dec 6 12:30:43 2018
Ec2AMI: ami-ea677d80
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
SourcePackage: sssd
UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)
** Description changed:
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test)
sudo apt update
sudo apt install sssd slapd ldap-utils
* Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password. For the rest, accept defaults:
sudo dpkg-reconfigure slapd
* Populate the ldap directory:
ldapadd -x -D cn=admin,dc=example,dc=com -w secret -c <<EOF
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
+
dn: uid=testuser1,ou=People,dc=example,dc=com
uid: testuser1
objectClass: inetOrgPerson
objectClass: posixAccount
cn: testuser1
sn: testuser1
givenName: testuser1
mail: testuser1 at example.com
userPassword: testuser1secret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/testuser1
dn: cn=testuser1,ou=Group,dc=example,dc=com
cn: testuser1
objectClass: posixGroup
gidNumber: 10001
memberUid: testuser1
dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10100
memberUid: testuser1
EOF
* Create /etc/sssd/sssd.conf with the following contents:
[sssd]
services = nss
domains = local,example
[nss]
debug_level = 6
memcache_timeout = 30
[domain/local]
id_provider = local
enumerate = true
max_id = 1000
[domain/example]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = false
* Adjust permissions and restart:
sudo chmod 0600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
* Test:
id testuser1
Should return:
uid=10001(testuser1) gid=10001 groups=10001,10100
* Create a home directory:
sudo mkdir /home/testuser1 -m 0700
sudo chown testuser1:testuser1 /home/testuser1
* Become testuser1 and run this script. It should fail at the 4th attempt, i.e., after about 40 seconds:
sudo -u testuser1 -i
while /bin/true; do date; whoami || break; echo; sleep 10; done
Wed Jan 16 19:12:02 UTC 2019
testuser1
...
Wed Jan 16 19:12:22 UTC 2019
whoami: cannot find name for user ID 10001: Unknown error 1432158300
With the fixed packages installed, that while loop won't be exited.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result
of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.
However, after upgrading to 18.04.1 LTS, I find that the system is
continuously forgetting who I am. After a few commands, or a few
minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
to run sudo or whoami, it says that I am an unknown user. for example,
```
whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300
```
if I run the id command on my username, it returns the correct results,
and whoami/sudo/other restricted commands will work again for a short
time before forgetting who I am again.
In the sssd_nss.log file, I see the lookup against the @local domain,
but I do not see a related lookup in the ldap domain either in that log
file or in the log file specific to the ldap domain.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: sssd 1.16.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Thu Dec 6 12:30:43 2018
Ec2AMI: ami-ea677d80
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
SourcePackage: sssd
UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)
** Description changed:
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test)
sudo apt update
sudo apt install sssd slapd ldap-utils
* Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password. For the rest, accept defaults:
sudo dpkg-reconfigure slapd
* Populate the ldap directory:
ldapadd -x -D cn=admin,dc=example,dc=com -w secret -c <<EOF
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
dn: uid=testuser1,ou=People,dc=example,dc=com
uid: testuser1
objectClass: inetOrgPerson
objectClass: posixAccount
cn: testuser1
sn: testuser1
givenName: testuser1
mail: testuser1 at example.com
userPassword: testuser1secret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/testuser1
dn: cn=testuser1,ou=Group,dc=example,dc=com
cn: testuser1
objectClass: posixGroup
gidNumber: 10001
memberUid: testuser1
dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10100
memberUid: testuser1
EOF
* Create /etc/sssd/sssd.conf with the following contents:
[sssd]
services = nss
domains = local,example
[nss]
debug_level = 6
memcache_timeout = 30
[domain/local]
id_provider = local
enumerate = true
max_id = 1000
[domain/example]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = false
* Adjust permissions and restart:
sudo chmod 0600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
* Test:
id testuser1
Should return:
uid=10001(testuser1) gid=10001 groups=10001,10100
* Create a home directory:
sudo mkdir /home/testuser1 -m 0700
sudo chown testuser1:testuser1 /home/testuser1
- * Become testuser1 and run this script. It should fail at the 4th attempt, i.e., after about 40 seconds:
+ * Become testuser1 and run this script. Depending on how long ago was the sssd restart above, it should fail soon, at most in 40s:
sudo -u testuser1 -i
while /bin/true; do date; whoami || break; echo; sleep 10; done
Wed Jan 16 19:12:02 UTC 2019
testuser1
...
Wed Jan 16 19:12:22 UTC 2019
whoami: cannot find name for user ID 10001: Unknown error 1432158300
With the fixed packages installed, that while loop won't be exited.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result
of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.
However, after upgrading to 18.04.1 LTS, I find that the system is
continuously forgetting who I am. After a few commands, or a few
minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
to run sudo or whoami, it says that I am an unknown user. for example,
```
whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300
```
if I run the id command on my username, it returns the correct results,
and whoami/sudo/other restricted commands will work again for a short
time before forgetting who I am again.
In the sssd_nss.log file, I see the lookup against the @local domain,
but I do not see a related lookup in the ldap domain either in that log
file or in the log file specific to the ldap domain.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: sssd 1.16.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Thu Dec 6 12:30:43 2018
Ec2AMI: ami-ea677d80
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
SourcePackage: sssd
UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)
** Description changed:
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
- * Install sssd, slapd and ldap-utils, on a bionic VM (do not use lxd, as the default user mapping range might not suit this test)
+ * Install sssd, slapd and ldap-utils, on a bionic VM or LXD (if you get weird errors, use a VM, because the uid mapping in lxd might be conflicting with the uids chosen for this test):
sudo apt update
sudo apt install sssd slapd ldap-utils
* Reconfigure slapd. Enter "example.com" for the domain, "example" for the organization, and "secret" for the admin password. For the rest, accept defaults:
sudo dpkg-reconfigure slapd
* Populate the ldap directory:
ldapadd -x -D cn=admin,dc=example,dc=com -w secret -c <<EOF
dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
dn: uid=testuser1,ou=People,dc=example,dc=com
uid: testuser1
objectClass: inetOrgPerson
objectClass: posixAccount
cn: testuser1
sn: testuser1
givenName: testuser1
mail: testuser1 at example.com
userPassword: testuser1secret
uidNumber: 10001
gidNumber: 10001
loginShell: /bin/bash
homeDirectory: /home/testuser1
dn: cn=testuser1,ou=Group,dc=example,dc=com
cn: testuser1
objectClass: posixGroup
gidNumber: 10001
memberUid: testuser1
dn: cn=ldapusers,ou=Group,dc=example,dc=com
cn: ldapusers
objectClass: posixGroup
gidNumber: 10100
memberUid: testuser1
EOF
* Create /etc/sssd/sssd.conf with the following contents:
[sssd]
services = nss
domains = local,example
[nss]
debug_level = 6
memcache_timeout = 30
[domain/local]
id_provider = local
enumerate = true
max_id = 1000
[domain/example]
id_provider = ldap
enumerate = true
auth_provider = ldap
ldap_uri = ldap://localhost
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = allow
cache_credentials = true
use_fully_qualified_names = false
* Adjust permissions and restart:
sudo chmod 0600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
* Test:
id testuser1
Should return:
uid=10001(testuser1) gid=10001 groups=10001,10100
* Create a home directory:
sudo mkdir /home/testuser1 -m 0700
sudo chown testuser1:testuser1 /home/testuser1
* Become testuser1 and run this script. Depending on how long ago was the sssd restart above, it should fail soon, at most in 40s:
sudo -u testuser1 -i
while /bin/true; do date; whoami || break; echo; sleep 10; done
Wed Jan 16 19:12:02 UTC 2019
testuser1
...
Wed Jan 16 19:12:22 UTC 2019
whoami: cannot find name for user ID 10001: Unknown error 1432158300
With the fixed packages installed, that while loop won't be exited.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result
of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
I configured sssd on an Ubuntu 16.04 LTS system, and it worked just fine. In fact, using the same sssd.conf file (which is managed by puppet) on un-upgraded system continues to work fine.
However, after upgrading to 18.04.1 LTS, I find that the system is
continuously forgetting who I am. After a few commands, or a few
minutes (I'm not sure exactly how many, but around 3-5 minutes) if I try
to run sudo or whoami, it says that I am an unknown user. for example,
```
whoami
whoami: cannot find name for user ID 2000: Unknown error 1432158300
```
if I run the id command on my username, it returns the correct results,
and whoami/sudo/other restricted commands will work again for a short
time before forgetting who I am again.
In the sssd_nss.log file, I see the lookup against the @local domain,
but I do not see a related lookup in the ldap domain either in that log
file or in the log file specific to the ldap domain.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: sssd 1.16.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-42.45-generic 4.15.18
Uname: Linux 4.15.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
Date: Thu Dec 6 12:30:43 2018
Ec2AMI: ami-ea677d80
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t2.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
SourcePackage: sssd
UpgradeStatus: Upgraded to bionic on 2018-10-04 (63 days ago)
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1807246
Title:
after upgrading to bionic, my session forgets who I am frequently
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1807246/+subscriptions
More information about the Ubuntu-server-bugs
mailing list