Hi List,
I wanted to use sss_cache to find out whether sssd is running in a connected or disconnected mode, but I found out it is not working the way I expected. Example:
1. # id -a ondrej - shows something about me. 2. # sss_cache -u ondrej - I expect all information about me is trashed 3. # id -a ondrej - still shows information about me even if no ldap provider is available to connect. Evidently sssd still returns cached information.
Is this a normal behavior or is this a bug? Thanks,
Ondrej
On Mon, 2012-09-10 at 16:21 +0200, Ondrej Valousek wrote:
Hi List,
I wanted to use sss_cache to find out whether sssd is running in a connected or disconnected mode, but I found out it is not working the way I expected. Example:
# id -a ondrej
- shows something about me.
# sss_cache -u ondrej
- I expect all information about me is trashed
# id -a ondrej
- still shows information about me even if no ldap provider is
available to connect. Evidently sssd still returns cached information.
Is this a normal behavior or is this a bug? Thanks,
sss_cache does not *delete* information. This is by design. It immediately *expires* it so that the next request for it will go back to the server and refresh it.
The reason not to delete it is that if you're offline (or go that way immediately after running sss_cache) you will not lose all your file access.
It's also important to note https://fedorahosted.org/sssd/ticket/1311 if you happen to be running our 1.9.0 pre-releases.
Hi,
I wanted to use sss_cache to find out whether sssd is running in a connected or disconnected mode, but I found out it is not working the way I expected.
# sss_cache -u ondrej
- I expect all information about me is trashed
sss_cache does not *delete* information. This is by design. It immediately *expires* it so that the next request for it will go back to the server and refresh it.
The reason not to delete it is that if you're offline (or go that way immediately after running sss_cache) you will not lose all your file access.
I realize the benefit of this approach there's also a (corner) case where this can be surprising to an administrator. Think of an administrator doing the following on an offline system where "testuser" is in SSSD's cache and perhaps already deleted from LDAP:
# pkill -U testuser # userdel -r testuser # sss_cache -u testuser
At this point the administrator may easily be tempted to think that testuser is gone for good but actually as long as the system is offline, testuser can login as before and merrily continue doing whatever s/he was getting the kick from the administrator for.
Cheers,
What about introducing another parameter (say -f for "force") which would delete the information at once? Does it make any sense?
Ondrej
On 09/11/2012 03:52 PM, Marko Myllynen wrote:
Hi,
I wanted to use sss_cache to find out whether sssd is running in a connected or disconnected mode, but I found out it is not working the way I expected.
# sss_cache -u ondrej
- I expect all information about me is trashed
sss_cache does not *delete* information. This is by design. It immediately *expires* it so that the next request for it will go back to the server and refresh it.
The reason not to delete it is that if you're offline (or go that way immediately after running sss_cache) you will not lose all your file access.
I realize the benefit of this approach there's also a (corner) case where this can be surprising to an administrator. Think of an administrator doing the following on an offline system where "testuser" is in SSSD's cache and perhaps already deleted from LDAP:
# pkill -U testuser # userdel -r testuser # sss_cache -u testuser
At this point the administrator may easily be tempted to think that testuser is gone for good but actually as long as the system is offline, testuser can login as before and merrily continue doing whatever s/he was getting the kick from the administrator for.
Cheers,
On 09/11/2012 09:54 AM, Ondrej Valousek wrote:
What about introducing another parameter (say -f for "force") which would delete the information at once? Does it make any sense?
Ondrej
On 09/11/2012 03:52 PM, Marko Myllynen wrote:
Hi,
I wanted to use sss_cache to find out whether sssd is running in a connected or disconnected mode, but I found out it is not working the way I expected.
# sss_cache -u ondrej
- I expect all information about me is trashed
sss_cache does not *delete* information. This is by design. It immediately *expires* it so that the next request for it will go back to the server and refresh it.
The reason not to delete it is that if you're offline (or go that way immediately after running sss_cache) you will not lose all your file access.
I realize the benefit of this approach there's also a (corner) case where this can be surprising to an administrator. Think of an administrator doing the following on an offline system where "testuser" is in SSSD's cache and perhaps already deleted from LDAP:
# pkill -U testuser # userdel -r testuser # sss_cache -u testuser
At this point the administrator may easily be tempted to think that testuser is gone for good but actually as long as the system is offline, testuser can login as before and merrily continue doing whatever s/he was getting the kick from the administrator for.
Cheers,
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
https://fedorahosted.org/sssd/ticket/1520
On Mon, Sep 10, 2012 at 04:21:51PM +0200, Ondrej Valousek wrote:
Hi List,
I wanted to use sss_cache to find out whether sssd is running in a connected or disconnected mode, but I found out it is not working the way I expected. Example:
# id -a ondrej
- shows something about me.
# sss_cache -u ondrej
- I expect all information about me is trashed
No, the information is never completely removed. It is only marked as expired so that the next lookup would go to the server and download fresh data again.
# id -a ondrej
- still shows information about me even if no ldap provider is available to connect. Evidently sssd still returns cached information.
Is this a normal behavior or is this a bug? Thanks,
A proper test would look like: 1. id -a ondrej 2. change an attribute of ondre's record 3. sss_cache -u ondrej 4. id -a ondrej
Step 4. should print updated information on ondrej.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Marko Myllynen -
Ondrej Valousek -
Stephen Gallagher