On Wed, 2013-08-07 at 12:00 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 11:47:14AM +0200, steve wrote:
Hi Any chance of having this for 1.10? Cheers, Steve
I can push the patch, no problem, but keep in mind that currently is it just a shorthand. It doesn't invalidate sudo rules for instance.
Anything which removes the need for a peripheral script is a good move for us.
Could I apply the patch and rebuild over what we already have from the 1.10.1 tarball?
Thanks
On Wed, Aug 07, 2013 at 12:13:02PM +0200, steve wrote:
On Wed, 2013-08-07 at 12:00 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 11:47:14AM +0200, steve wrote:
Hi Any chance of having this for 1.10? Cheers, Steve
I can push the patch, no problem, but keep in mind that currently is it just a shorthand. It doesn't invalidate sudo rules for instance.
Anything which removes the need for a peripheral script is a good move for us.
What kind of script? I'd like to understand whether the patch would solve the issue for you or you're actually facing something else..
Could I apply the patch and rebuild over what we already have from the 1.10.1 tarball?
Thanks
Sure, that would work.
On Wed, Aug 07, 2013 at 01:17:46PM +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 12:13:02PM +0200, steve wrote:
On Wed, 2013-08-07 at 12:00 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 11:47:14AM +0200, steve wrote:
Hi Any chance of having this for 1.10? Cheers, Steve
I can push the patch, no problem, but keep in mind that currently is it just a shorthand. It doesn't invalidate sudo rules for instance.
Anything which removes the need for a peripheral script is a good move for us.
What kind of script? I'd like to understand whether the patch would solve the issue for you or you're actually facing something else..
Could I apply the patch and rebuild over what we already have from the 1.10.1 tarball?
Thanks
Sure, that would work.
Pushed to master and sssd-1-10
On Wed, Aug 07, 2013 at 01:20:40PM +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 01:17:46PM +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 12:13:02PM +0200, steve wrote:
On Wed, 2013-08-07 at 12:00 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 11:47:14AM +0200, steve wrote:
Hi Any chance of having this for 1.10? Cheers, Steve
I can push the patch, no problem, but keep in mind that currently is it just a shorthand. It doesn't invalidate sudo rules for instance.
Anything which removes the need for a peripheral script is a good move for us.
What kind of script? I'd like to understand whether the patch would solve the issue for you or you're actually facing something else..
Could I apply the patch and rebuild over what we already have from the 1.10.1 tarball?
Thanks
Sure, that would work.
Pushed to master and sssd-1-10
I'm sorry, I replied to a wrong thread. Please ignore.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
Hi OK, maybe I should explain our frustration. A college where students come and go and change courses. This involves changes in AD. Just something to say e.g. student1 has left or change his group from course1 to course2 or remove him from that course or group. Something like turning off nscd when you run nss-ldapd. Imagine doing it for a whole class as and when the student returns, a bit at a time. We don't want old expired data. At the end of the class neither we nor the student have any need for it. Cheers
On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
Hi OK, maybe I should explain our frustration. A college where students come and go and change courses. This involves changes in AD. Just something to say e.g. student1 has left or change his group from course1 to course2 or remove him from that course or group. Something like turning off nscd when you run nss-ldapd. Imagine doing it for a whole class as and when the student returns, a bit at a time. We don't want old expired data. At the end of the class neither we nor the student have any need for it. Cheers
And if you ran sss_cache -UG instead, would that still give you wrong data?
On Thu, 2013-08-08 at 00:15 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
Hi OK, maybe I should explain our frustration. A college where students come and go and change courses. This involves changes in AD. Just something to say e.g. student1 has left or change his group from course1 to course2 or remove him from that course or group. Something like turning off nscd when you run nss-ldapd. Imagine doing it for a whole class as and when the student returns, a bit at a time. We don't want old expired data. At the end of the class neither we nor the student have any need for it. Cheers
And if you ran sss_cache -UG instead, would that still give you wrong data?
Yes. -UG is not enough:
Here is an AD group with one member:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 member: CN=steve2,CN=Users,DC=hh3,DC=site whenChanged: 20130808065259.0Z uSNChanged: 5758
Here is sssd showing the member:
hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
We remove the member from the group: hh16:/home/steve # samba-tool group removemembers staff2 steve2 Removed members from group staff2
Here is the group with steve2 removed:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 whenChanged: 20130808064630.0Z uSNChanged: 5757
sssd_cache -UG still shows steve2 as a member:
hh16:/home/steve # sss_cache -UG hh16:/home/steve # systemctl restart sssd hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
The only way this works is to remove the contents of /usr/local/var/lib/sss/db/ and restart sssd. Thanks
On Thu, Aug 08, 2013 at 09:04:37AM +0200, steve wrote:
On Thu, 2013-08-08 at 00:15 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote:
>
What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
Hi OK, maybe I should explain our frustration. A college where students come and go and change courses. This involves changes in AD. Just something to say e.g. student1 has left or change his group from course1 to course2 or remove him from that course or group. Something like turning off nscd when you run nss-ldapd. Imagine doing it for a whole class as and when the student returns, a bit at a time. We don't want old expired data. At the end of the class neither we nor the student have any need for it. Cheers
And if you ran sss_cache -UG instead, would that still give you wrong data?
Yes. -UG is not enough:
Here is an AD group with one member:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 member: CN=steve2,CN=Users,DC=hh3,DC=site whenChanged: 20130808065259.0Z uSNChanged: 5758
Here is sssd showing the member:
hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
We remove the member from the group: hh16:/home/steve # samba-tool group removemembers staff2 steve2 Removed members from group staff2
Here is the group with steve2 removed:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 whenChanged: 20130808064630.0Z uSNChanged: 5757
sssd_cache -UG still shows steve2 as a member:
hh16:/home/steve # sss_cache -UG hh16:/home/steve # systemctl restart sssd hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
The only way this works is to remove the contents of /usr/local/var/lib/sss/db/ and restart sssd. Thanks
This sounds to me like a bug. Even without the restart the sequence of:
sss_cache -UG getent group staff2
Is suposed to fetch the new group memberships. You're running a custom build, right? Can you please try applying commits 9615f4c3c6f6dcc50ee7d4e50020549a2ff720c0 and f7aef1e3ca5bdcddb6fb7c7e6556315faa96165d ?
Those landed yesterday and might fix the problem for you..
On 08/08/13 09:51, Jakub Hrozek wrote:
On Thu, Aug 08, 2013 at 09:04:37AM +0200, steve wrote:
On Thu, 2013-08-08 at 00:15 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote: >> > > What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
Hi OK, maybe I should explain our frustration. A college where students come and go and change courses. This involves changes in AD. Just something to say e.g. student1 has left or change his group from course1 to course2 or remove him from that course or group. Something like turning off nscd when you run nss-ldapd. Imagine doing it for a whole class as and when the student returns, a bit at a time. We don't want old expired data. At the end of the class neither we nor the student have any need for it. Cheers
And if you ran sss_cache -UG instead, would that still give you wrong data?
Yes. -UG is not enough:
Here is an AD group with one member:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 member: CN=steve2,CN=Users,DC=hh3,DC=site whenChanged: 20130808065259.0Z uSNChanged: 5758
Here is sssd showing the member:
hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
We remove the member from the group: hh16:/home/steve # samba-tool group removemembers staff2 steve2 Removed members from group staff2
Here is the group with steve2 removed:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 whenChanged: 20130808064630.0Z uSNChanged: 5757
sssd_cache -UG still shows steve2 as a member:
hh16:/home/steve # sss_cache -UG hh16:/home/steve # systemctl restart sssd hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
The only way this works is to remove the contents of /usr/local/var/lib/sss/db/ and restart sssd. Thanks
This sounds to me like a bug. Even without the restart the sequence of:
sss_cache -UG getent group staff2
Is suposed to fetch the new group memberships. You're running a custom build, right? Can you please try applying commits 9615f4c3c6f6dcc50ee7d4e50020549a2ff720c0 and f7aef1e3ca5bdcddb6fb7c7e6556315faa96165d ?
Those landed yesterday and might fix the problem for you..
This is 1.10.1 from the tarball. With Samba4 AD. Is there a how to for applying commits?
On Thu, 2013-08-08 at 09:51 +0200, Jakub Hrozek wrote:
On Thu, Aug 08, 2013 at 09:04:37AM +0200, steve wrote:
On Thu, 2013-08-08 at 00:15 +0200, Jakub Hrozek wrote:
On Wed, Aug 07, 2013 at 05:25:08PM +0200, steve wrote:
On Wed, 2013-08-07 at 08:07 -0400, Stephen Gallagher wrote:
On 08/07/2013 07:48 AM, steve wrote:
On Wed, 2013-08-07 at 13:17 +0200, Jakub Hrozek wrote: >> > > What kind of script?
#!/bin/bash systemctl stop sssd rm /usr/local/var/lib/sss/db/* systemctl start sssd
It's worth noting that sss_cache does not *delete* the cache contents, it only marks them all as expired. This means you don't lose cached credentials and if your LDAP server isn't available to repopulate the cache, you still have access to the old, expired data until it is.
Hi OK, maybe I should explain our frustration. A college where students come and go and change courses. This involves changes in AD. Just something to say e.g. student1 has left or change his group from course1 to course2 or remove him from that course or group. Something like turning off nscd when you run nss-ldapd. Imagine doing it for a whole class as and when the student returns, a bit at a time. We don't want old expired data. At the end of the class neither we nor the student have any need for it. Cheers
And if you ran sss_cache -UG instead, would that still give you wrong data?
Yes. -UG is not enough:
Here is an AD group with one member:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 member: CN=steve2,CN=Users,DC=hh3,DC=site whenChanged: 20130808065259.0Z uSNChanged: 5758
Here is sssd showing the member:
hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
We remove the member from the group: hh16:/home/steve # samba-tool group removemembers staff2 steve2 Removed members from group staff2
Here is the group with steve2 removed:
ldbsearch --url=/usr/local/samba/private/sam.ldb cn=staff2 # record 1 dn: CN=staff2,CN=Users,DC=hh3,DC=site cn: staff2 instanceType: 4 whenCreated: 20130605160553.0Z uSNCreated: 3922 name: staff2 objectGUID: 6ce9797b-96db-4e70-97ca-e1a2d8d0b3d1 objectSid: S-1-5-21-451355595-2219208293-2714859210-1111 sAMAccountName: staff2 sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=hh3,DC=site objectClass: top objectClass: posixGroup objectClass: group gidNumber: 21111 whenChanged: 20130808064630.0Z uSNChanged: 5757
sssd_cache -UG still shows steve2 as a member:
hh16:/home/steve # sss_cache -UG hh16:/home/steve # systemctl restart sssd hh16:/home/steve # getent group staff2 staff2:*:21111:steve2
The only way this works is to remove the contents of /usr/local/var/lib/sss/db/ and restart sssd. Thanks
This sounds to me like a bug. Even without the restart the sequence of:
sss_cache -UG getent group staff2
Is suposed to fetch the new group memberships. You're running a custom build, right? Can you please try applying commits 9615f4c3c6f6dcc50ee7d4e50020549a2ff720c0 and f7aef1e3ca5bdcddb6fb7c7e6556315faa96165d ?
Those landed yesterday and might fix the problem for you..
OK. I got the git master 1.10.93
sss_cache -UG or sss:cache -E now works perfectly for users but still fails for groups.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Stephen Gallagher -
steve