Hi List,
Are there any plans for a command line tool like 'wbinfo' which for winbind for sssd? Thanks,
Ondrej
Well, I would like to see something like 'adquery' or 'adinfo' from Centrify - i.e. tool that would: 1. enumerate maps like group, passwd, automount... getent can not do everything 2. Display information about a user (account active, disabled, locked,...) 3. Group membership - how was group membership computed (in ldap we can have nested groups, not all groups have Unix attributes defined) 4. Status about connection to the domain (connected/disconnected,...) + all details (like ldap controller being connected...) 5. Version running
In general some too that would help in case of any problems. Reconfiguring sssd for higher debug level & restarting & inspecting logs - this all takes a lot of time....
Ondrej
On 02/21/2012 06:16 PM, Stephen Gallagher wrote:
On Tue, 2012-02-21 at 18:08 +0100, Ondrej Valousek wrote:
Hi List,
Are there any plans for a command line tool like 'wbinfo' which for winbind for sssd?
That's a very broad request. Would you mind listing the specific features you'd like to see from SSSD, please?
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
s/some too/something
Ondrej
On 02/21/2012 06:26 PM, Ondrej Valousek wrote:
Well, I would like to see something like 'adquery' or 'adinfo' from Centrify - i.e. tool that would:
- enumerate maps like group, passwd, automount... getent can not do everything
- Display information about a user (account active, disabled, locked,...)
- Group membership - how was group membership computed (in ldap we can have nested groups, not all groups have Unix attributes defined)
- Status about connection to the domain (connected/disconnected,...) + all details (like ldap controller being connected...)
- Version running
In general some too that would help in case of any problems. Reconfiguring sssd for higher debug level & restarting & inspecting logs - this all takes a lot of time....
Ondrej
On 02/21/2012 06:16 PM, Stephen Gallagher wrote:
On Tue, 2012-02-21 at 18:08 +0100, Ondrej Valousek wrote:
Hi List,
Are there any plans for a command line tool like 'wbinfo' which for winbind for sssd?
That's a very broad request. Would you mind listing the specific features you'd like to see from SSSD, please?
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Tue, 2012-02-21 at 18:26 +0100, Ondrej Valousek wrote:
Well, I would like to see something like 'adquery' or 'adinfo' from Centrify - i.e. tool that would:
- enumerate maps like group, passwd, automount... getent can not do
everything
This only works with AD because there is an alternative RPC-based mechanism to ask for this information. In the general LDAP case, SSSD can't get any more information than 'getent' is permitted.
- Display information about a user (account active, disabled,
locked,...)
This is again not always possible to determine. Most LDAP servers use server-side policy controls. We basically can't learn this information until we try to authenticate in many cases.
- Group membership - how was group membership computed (in ldap we
can have nested groups, not all groups have Unix attributes defined)
This might be a nice feature. Please file an enhancement ticket at https://fedorahosted.org/sssd
If you need an account, you can get one for free at https://admin.fedoraproject.org/accounts
- Status about connection to the domain (connected/disconnected,...)
- all details (like ldap controller being connected...)
This isn't really useful information much of the time, because we don't always maintain a connection(it wastes resources on the server-side). The most we could give you is whether the last attempt to contact the server was successful, but this would probably be more misleading than useful.
- Version running
https://fedorahosted.org/sssd/ticket/953
This was added in SSSD 1.7.0
In general some too that would help in case of any problems. Reconfiguring sssd for higher debug level & restarting & inspecting logs - this all takes a lot of time....
We added the ability to change debug levels without restarting SSSD in 1.7.0: https://fedorahosted.org/sssd/ticket/950
On 02/21/2012 03:14 PM, Stephen Gallagher wrote:
On Tue, 2012-02-21 at 18:26 +0100, Ondrej Valousek wrote:
Well, I would like to see something like 'adquery' or 'adinfo' from Centrify - i.e. tool that would:
- enumerate maps like group, passwd, automount... getent can not do
everything
This only works with AD because there is an alternative RPC-based mechanism to ask for this information. In the general LDAP case, SSSD can't get any more information than 'getent' is permitted.
- Display information about a user (account active, disabled,
locked,...)
This is again not always possible to determine. Most LDAP servers use server-side policy controls. We basically can't learn this information until we try to authenticate in many cases.
But would it make sense to have a tool that would provide this info based on the local cache? Enumerating everything is probably a server side tool. For IPA it can be done via CLI and script around. But for SSSD we might want to have a way to inspect the cache and display a report based on it. I know we have tools to deal with the cache so I wonder it this something that Ondrej would consider useful.
Hi,
Well, I would like to see something like 'adquery' or 'adinfo' from Centrify - i.e. tool that would:
- enumerate maps like group, passwd, automount... getent can not do
everything
This only works with AD because there is an alternative RPC-based mechanism to ask for this information. In the general LDAP case, SSSD can't get any more information than 'getent' is permitted.
- Display information about a user (account active, disabled,
locked,...)
This is again not always possible to determine. Most LDAP servers use server-side policy controls. We basically can't learn this information until we try to authenticate in many cases.
But would it make sense to have a tool that would provide this info based on the local cache?
this proposal reminds me about an IRC conversation a year or so ago, I suggested something like sss_search which administrators could use to check for example from which domain a user on a system is coming from.
Of course it should be possible to dig out that information by grepping logs or by using ldapsearch but with several domains configured (and in the future trusts and sub-domains also in play) it's getting a bit laborious to manually construct LDAP queries for each domain or plunge into cache files to find out information about a user's origin or group memberships instead of just doing something like "sss_search -u jdoe", just as Ondrej says.
If a specific action Ondrej suggests wouldn't work with certain types of domains the tool could just inform the administrator about the fact that those domains are not included in the results. The administrator could then decide next steps depending on the situation at hand, at least all the information possible to retrieve on the client side for the domains configured would be easily available.
Thanks,
Of course it should be possible to dig out that information by grepping logs or by using ldapsearch but with several domains configured (and in the future trusts and sub-domains also in play) it's getting a bit laborious to manually construct LDAP queries for each domain or plunge into cache files to find out information about a user's origin or group memberships instead of just doing something like "sss_search -u jdoe", just as Ondrej says.
If a specific action Ondrej suggests wouldn't work with certain types of domains the tool could just inform the administrator about the fact that those domains are not included in the results. The administrator could then decide next steps depending on the situation at hand, at least all the information possible to retrieve on the client side for the domains configured would be easily available.
Thanks,
Well, I understand that not all features would be available for all backends, but to be honest, to me is sssd synonym for a robust ldap-client - so I imagine sssd would be in a vast majority used with ldap/IPA backend.
As Marko said, "sss_search -u jdoe" would be nice. I also expect it to return more than what 'getent' does - i.e. things like mail address, telephone number,... ok these might not be important now, but certainly will be in the future (imagine sssd being queried by mailing client or ekiga/pidgin).
Also, having the information about ldap connection state (i.e. sssd running in connected or disconnected mode) is extremely useful to me as one the biggest pain with winbind is its cache - you never know which information came from the authoritative source and which was just cached & winbind can not bind to any server due to whatever reason.
Ondrej
On Mon, 2012-02-27 at 14:54 +0100, Ondrej Valousek wrote:
Of course it should be possible to dig out that information by grepping logs or by using ldapsearch but with several domains configured (and in the future trusts and sub-domains also in play) it's getting a bit laborious to manually construct LDAP queries for each domain or plunge into cache files to find out information about a user's origin or group memberships instead of just doing something like "sss_search -u jdoe", just as Ondrej says.
If a specific action Ondrej suggests wouldn't work with certain types of domains the tool could just inform the administrator about the fact that those domains are not included in the results. The administrator could then decide next steps depending on the situation at hand, at least all the information possible to retrieve on the client side for the domains configured would be easily available.
Thanks,
Well, I understand that not all features would be available for all backends, but to be honest, to me is sssd synonym for a robust ldap-client - so I imagine sssd would be in a vast majority used with ldap/IPA backend.
As Marko said, "sss_search -u jdoe" would be nice. I also expect it to return more than what 'getent' does - i.e. things like mail address, telephone number,... ok these might not be important now, but certainly will be in the future (imagine sssd being queried by mailing client or ekiga/pidgin).
Also, having the information about ldap connection state (i.e. sssd running in connected or disconnected mode) is extremely useful to me as one the biggest pain with winbind is its cache - you never know which information came from the authoritative source and which was just cached & winbind can not bind to any server due to whatever reason.
These are certainly worth considering. The preferred method of requesting such changes is to file enhancement tickets at https://fedorahosted.org/sssd so that they will not get forgotten and can be scheduled appropriately.
Hi,
Of course it should be possible to dig out that information by grepping logs or by using ldapsearch but with several domains configured (and in the future trusts and sub-domains also in play) it's getting a bit laborious to manually construct LDAP queries for each domain or plunge into cache files to find out information about a user's origin or group memberships instead of just doing something like "sss_search -u jdoe", just as Ondrej says.
As Marko said, "sss_search -u jdoe" would be nice. I also expect it to return more than what 'getent' does - i.e. things like mail address, telephone number,... ok these might not be important now, but certainly will be in the future (imagine sssd being queried by mailing client or ekiga/pidgin).
These are certainly worth considering. The preferred method of requesting such changes is to file enhancement tickets at https://fedorahosted.org/sssd so that they will not get forgotten and can be scheduled appropriately.
I've filed a generic ticket about such a tool and few separate tickets about certain features - please feel free to complement them:
https://fedorahosted.org/sssd/ticket/1220 https://fedorahosted.org/sssd/ticket/1221 https://fedorahosted.org/sssd/ticket/1222 https://fedorahosted.org/sssd/ticket/1223
Thanks,
Hi,
As Marko said, "sss_search -u jdoe" would be nice. I also expect it to return more than what 'getent' does - i.e. things like mail address, telephone number,... ok these might not be important now, but certainly will be in the future (imagine sssd being queried by mailing client or ekiga/pidgin).
indeed - if something like this would be available it would open the door for innovative use of the information so easily retrievable.
Also, having the information about ldap connection state (i.e. sssd running in connected or disconnected mode) is extremely useful to me as one the biggest pain with winbind is its cache - you never know which information came from the authoritative source and which was just cached & winbind can not bind to any server due to whatever reason.
I filed an RFE to implement querying of online/offline status two years ago but it's been silent on that front for long time, not sure what's the status with the InfoPipe effort it was planned to be combined with:
https://fedorahosted.org/sssd/ticket/385
Cheers,
On Mon, 2012-02-27 at 16:11 +0200, Marko Myllynen wrote:
Also, having the information about ldap connection state (i.e. sssd running in connected or disconnected mode) is extremely useful to me as one the biggest pain with winbind is its cache - you never know which information came from the authoritative source and which was just cached & winbind can not bind to any server due to whatever reason.
I filed an RFE to implement querying of online/offline status two years ago but it's been silent on that front for long time, not sure what's the status with the InfoPipe effort it was planned to be combined with:
We haven't done this because we haven't ever been able to determine a way to present this information without sometimes lying. There are two reasons why what you two are asking for is difficult if not impossible to provide:
1) For identity lookups, we always prefer the local cache unless the cache is expired. This is to improve performance and lower the load on the LDAP server. We don't care if we're online or offline if the cache is up-to-date.
2) SSSD is designed to be reactive; we rarely know our definitive online/offline status until a request comes in. Once a request arrives that is a cache-miss (either expired or the first attempt to request this data) we try to ask the server. It's only at this time that we ever know with any degree of certainty whether the system is online or offline. If it's offline, we'll attempt to use the (expired) cached value if it's available, so the client continues to function.
We do some tricks to enable us to detect online availability quickly (such as monitoring the /etc/resolv.conf file so that if it changes, we try to immediately reconnect, guessing that you may have joined a new network or connected to a VPN). But most of the time, the system is idle and querying us will at best give you what our state was the LAST time the providers were asked for LDAP data. This could be very old information and no longer valid.
What I had originally proposed as an answer to Marko's enhancement request was actually a service to which a client could register to be notified of whether a provider had *switched* from online to offline operation. This is an action we CAN describe definitively. The original intent was to include that in a D-BUS responder that we were scoping, but have now repeatedly shelved in favor of more urgent functionality.
Another thing we COULD do (I'm not sure yet how useful it would be) is include a syslog message at INFO or DEBUG level for each request that's answered by the NSS responder. It could log a message saying that "User userA in [%s]" where %s could be "unexpired cache", "expired offline cache", "refreshed cache" or "not found" for the four cases it's possible for us to detect.
I *will* note that there are two problems with this approach: 1) syslog will be VERY noisy, as many requests for user information come in every minute. 2) We're planning in 1.9 to supplement the responder cache with an in-memory cache that will basically always return results for the "unexpired cache" without ever contacting the NSS responder, so the responder wouldn't be able to log this case any longer.
Well, I would like to see something like 'adquery' or 'adinfo' from Centrify - i.e. tool that would: 1. enumerate maps like group, passwd, automount... getent can not do everything 2. Display information about a user (account active, disabled, locked,...) 3. Group membership - how was group membership computed (in ldap we can have nested groups, not all groups have Unix attributes defined) 4. Status about connection to the domain (connected/disconnected,...) + all details (like ldap controller being connected...) 5. Version running
In general some too that would help in case of any problems. Reconfiguring sssd for higher debug level & restarting & inspecting logs - this all takes a lot of time....
If this is for the purpose of debugging, you can use ldbsearch on SSSD's local cache. Sure, the output is crude and not very user friendly but you will get basically every information you can get.
Jan
sssd-devel@lists.fedorahosted.org