Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
Thank you for the awesome work with it!
On Tue, Mar 22, 2016 at 1:47 PM, Pavel Reichl preichl@redhat.com wrote:
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
This is great and will make our lives much easier in support! Currently we have autokeyed commands like 'service sssd stop; rm -f /var/lib/sss/db/*; service sssd stop'
Once implemented I think we need update the sosreport plugin obtain sssctl output to be included in the sosreport.
-Justin
On 03/22/2016 08:47 AM, Pavel Reichl wrote:
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Tue, Mar 22, 2016 at 04:23:26PM -0400, Justin Stephenson wrote:
This is great and will make our lives much easier in support! Currently we have autokeyed commands like 'service sssd stop; rm -f /var/lib/sss/db/*; service sssd stop'
Yes in fact, most users expect this to be done by the sss_cache tool. If implementing this in sss_cache is not practical, then we should at least amend sss_cache documentation so that the user knows that this is not the place to remove the cache.
Once implemented I think we need update the sosreport plugin obtain sssctl output to be included in the sosreport.
-Justin
On 03/22/2016 08:47 AM, Pavel Reichl wrote:
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Wed, Apr 06, 2016 at 10:52:24AM +0200, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 04:23:26PM -0400, Justin Stephenson wrote:
This is great and will make our lives much easier in support! Currently we have autokeyed commands like 'service sssd stop; rm -f /var/lib/sss/db/*; service sssd stop'
Yes in fact, most users expect this to be done by the sss_cache tool. If implementing this in sss_cache is not practical, then we should at least amend sss_cache documentation so that the user knows that this is not the place to remove the cache.
Bump, I don't think we resolved this item.
If it was possible/easy to offer this functionality via the sss_cache tool as well, then I think we should do it. I also think it would be fine if this functionality depended on the D-Bus responder running. Bonus points for auto-activating the D-Bus responder if it's not running.
On 04/18/2016 07:33 PM, Jakub Hrozek wrote:
On Wed, Apr 06, 2016 at 10:52:24AM +0200, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 04:23:26PM -0400, Justin Stephenson wrote:
This is great and will make our lives much easier in support! Currently we have autokeyed commands like 'service sssd stop; rm -f /var/lib/sss/db/*; service sssd stop'
Yes in fact, most users expect this to be done by the sss_cache tool. If implementing this in sss_cache is not practical, then we should at least amend sss_cache documentation so that the user knows that this is not the place to remove the cache.
Bump, I don't think we resolved this item.
If it was possible/easy to offer this functionality via the sss_cache tool as well, then I think we should do it. I also think it would be fine if this functionality depended on the D-Bus responder running. Bonus points for auto-activating the D-Bus responder if it's not running.
I think it is yet too soon to answer unless some coding is done. At the moment 1) I don't see any problem with connecting to D-Bus in other tools, 2) this particular operation don't require D-Bus. Thus it should be doable in sss_cache. We can also implement it in sssctl and allow running it also from sss_cache as an alias.
Hello
Currently we mostly run
# service sssd stop ; rm -rf /var/lib/sss/db/* /var/log/sssd/* ; service sssd start
It would be great if we can have option to remove log files also i sssctl
# sssctl restore-cache remove-logs
This should either remove old logs or force rotate them.
Regards Arpit Tolani
----- Original Message -----
From: "Pavel Reichl" preichl@redhat.com To: sssd-devel@lists.fedorahosted.org Cc: gagriogi@redhat.com, "Arpit Tolani" atolani@redhat.com, fjayalat@redhat.com, "Eugene Keck" ekeck@redhat.com Sent: Tuesday, March 22, 2016 6:17:40 PM Subject: Re: [SSSD] Design document - sssctl
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On Fri, Apr 29, 2016 at 06:21:44AM +0530, Arpit Tolani wrote:
Hello
Hi Arpit, thank you very much for checking the design document.
Currently we mostly run
# service sssd stop ; rm -rf /var/lib/sss/db/* /var/log/sssd/* ; service sssd start
Yes, we plan on implememting this. But a word of caution -- if you remove the cache on an offline system, you can effectivelly remove any means of authenticating or retrieving identity data from the client.
It would be great if we can have option to remove log files also i sssctl
# sssctl restore-cache remove-logs
This should either remove old logs or force rotate them.
I think sending SIGHUP to sssd should already rotate the logs, but only in the sense that the logfiles would be reopened. This sounds like a valid use-case to consider though.
Regards Arpit Tolani
----- Original Message -----
From: "Pavel Reichl" preichl@redhat.com To: sssd-devel@lists.fedorahosted.org Cc: gagriogi@redhat.com, "Arpit Tolani" atolani@redhat.com, fjayalat@redhat.com, "Eugene Keck" ekeck@redhat.com Sent: Tuesday, March 22, 2016 6:17:40 PM Subject: Re: [SSSD] Design document - sssctl
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 04/29/2016 10:07 AM, Jakub Hrozek wrote:
On Fri, Apr 29, 2016 at 06:21:44AM +0530, Arpit Tolani wrote:
Hello
Hi Arpit, thank you very much for checking the design document.
Currently we mostly run
# service sssd stop ; rm -rf /var/lib/sss/db/* /var/log/sssd/* ; service sssd start
Yes, we plan on implememting this. But a word of caution -- if you remove the cache on an offline system, you can effectivelly remove any means of authenticating or retrieving identity data from the client.
Yes, we should print a loud warning with sssctl and ask for confirmation unless some --force option is used.
It would be great if we can have option to remove log files also i sssctl
# sssctl restore-cache remove-logs
This should either remove old logs or force rotate them.
I think sending SIGHUP to sssd should already rotate the logs, but only in the sense that the logfiles would be reopened. This sounds like a valid use-case to consider though.
Regards Arpit Tolani
----- Original Message -----
From: "Pavel Reichl" preichl@redhat.com To: sssd-devel@lists.fedorahosted.org Cc: gagriogi@redhat.com, "Arpit Tolani" atolani@redhat.com, fjayalat@redhat.com, "Eugene Keck" ekeck@redhat.com Sent: Tuesday, March 22, 2016 6:17:40 PM Subject: Re: [SSSD] Design document - sssctl
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
Hello
Yes, we plan on implememting this. But a word of caution -- if you remove the cache on an offline system, you can effectivelly remove any means of authenticating or retrieving identity data from the client.
thn lets add an warning message before we delete it & ask confimation, or may be give warning only in case domain is offline.
Regards Arpit Tolani
Hello
Some of my customers are asking if we have a command line option to dump information of all SSSD current settings, Can we add that feature in sssctl
sssctl --show-current-config
The intention is to have output like we have in testparm which shows all current configuarion, global options of nss, pam & domain if they are not changed, default cache/timeout values.
Regards Arpit Tolani
----- Original Message -----
From: "Arpit Tolani" atolani@redhat.com To: "Pavel Reichl" preichl@redhat.com Cc: sssd-devel@lists.fedorahosted.org Sent: Friday, April 29, 2016 6:21:44 AM Subject: Re: [SSSD] Design document - sssctl
Hello
Currently we mostly run
# service sssd stop ; rm -rf /var/lib/sss/db/* /var/log/sssd/* ; service sssd start
It would be great if we can have option to remove log files also i sssctl
# sssctl restore-cache remove-logs
This should either remove old logs or force rotate them.
Regards Arpit Tolani
----- Original Message -----
From: "Pavel Reichl" preichl@redhat.com To: sssd-devel@lists.fedorahosted.org Cc: gagriogi@redhat.com, "Arpit Tolani" atolani@redhat.com, fjayalat@redhat.com, "Eugene Keck" ekeck@redhat.com Sent: Tuesday, March 22, 2016 6:17:40 PM Subject: Re: [SSSD] Design document - sssctl
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
Sure, file an upstream ticket or a downstream bug. But I don't think this is in scope of the next release.
On 30 May 2016, at 18:06, Arpit Tolani atolani@redhat.com wrote:
Hello
Some of my customers are asking if we have a command line option to dump information of all SSSD current settings, Can we add that feature in sssctl
sssctl --show-current-config
The intention is to have output like we have in testparm which shows all current configuarion, global options of nss, pam & domain if they are not changed, default cache/timeout values.
Regards Arpit Tolani
----- Original Message -----
From: "Arpit Tolani" atolani@redhat.com To: "Pavel Reichl" preichl@redhat.com Cc: sssd-devel@lists.fedorahosted.org Sent: Friday, April 29, 2016 6:21:44 AM Subject: Re: [SSSD] Design document - sssctl
Hello
Currently we mostly run
# service sssd stop ; rm -rf /var/lib/sss/db/* /var/log/sssd/* ; service sssd start
It would be great if we can have option to remove log files also i sssctl
# sssctl restore-cache remove-logs
This should either remove old logs or force rotate them.
Regards Arpit Tolani
----- Original Message -----
From: "Pavel Reichl" preichl@redhat.com To: sssd-devel@lists.fedorahosted.org Cc: gagriogi@redhat.com, "Arpit Tolani" atolani@redhat.com, fjayalat@redhat.com, "Eugene Keck" ekeck@redhat.com Sent: Tuesday, March 22, 2016 6:17:40 PM Subject: Re: [SSSD] Design document - sssctl
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 05/30/2016 06:06 PM, Arpit Tolani wrote:
Hello
Some of my customers are asking if we have a command line option to dump information of all SSSD current settings, Can we add that feature in sssctl
sssctl --show-current-config
The intention is to have output like we have in testparm which shows all current configuarion, global options of nss, pam & domain if they are not changed, default cache/timeout values.
If I understand this correctly, you want to print value for every option even those that are set to default value and not present in sssd.conf?
Regards Arpit Tolani
----- Original Message -----
From: "Arpit Tolani" atolani@redhat.com To: "Pavel Reichl" preichl@redhat.com Cc: sssd-devel@lists.fedorahosted.org Sent: Friday, April 29, 2016 6:21:44 AM Subject: Re: [SSSD] Design document - sssctl
Hello
Currently we mostly run
# service sssd stop ; rm -rf /var/lib/sss/db/* /var/log/sssd/* ; service sssd start
It would be great if we can have option to remove log files also i sssctl
# sssctl restore-cache remove-logs
This should either remove old logs or force rotate them.
Regards Arpit Tolani
----- Original Message -----
From: "Pavel Reichl" preichl@redhat.com To: sssd-devel@lists.fedorahosted.org Cc: gagriogi@redhat.com, "Arpit Tolani" atolani@redhat.com, fjayalat@redhat.com, "Eugene Keck" ekeck@redhat.com Sent: Tuesday, March 22, 2016 6:17:40 PM Subject: Re: [SSSD] Design document - sssctl
Hello, I'm adding some people, who might be interested in this tool, to CC list. (Please feel free to extend).
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
https://fedorahosted.org/sssd/wiki/DesignDocs/sssctl _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 03/22/2016 07:42 AM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
"This tool will communicate with InfoPipe responder through its public D-Bus interface."
Presumably this means that the sssctl CLI will be a thin presentation-layer shim over the D-BUS API (meaning that the CLI would contain no logic outside of argument processing)? This would be the ideal case, since it would also allow plugging in other front-ends for this (such as Cockpit).
On 03/23/2016 03:42 AM, Stephen Gallagher wrote:
On 03/22/2016 07:42 AM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
"This tool will communicate with InfoPipe responder through its public D-Bus interface."
Presumably this means that the sssctl CLI will be a thin presentation-layer shim over the D-BUS API (meaning that the CLI would contain no logic outside of argument processing)? This would be the ideal case, since it would also allow plugging in other front-ends for this (such as Cockpit).
Yes, this is current plan.
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
Hi,
I would like to give a litle comment to:
""" Uses cases
Removing cache - Removing SSSD cache seems to be often misused act done by administrators as there are few real needs for that. Nevertheless, if administrator decides to remove the cache it would be better to do this using the tool instead of crude removing directories that might contain other useful data and could lead to serious problems. Q: Is this what was requested as 'force reload'? Q: Should this rather be part of sss_cache tool? """
There are two slightly related tickets: [1] sss_cache: invalidate sudo rules [2] Trigger full refresh of sudo rules on desire
We have patch on list (tests remains to finish) for the first. The second is on my opinion candidate for sssctl. Reason is that is not only action of sss cache to obtain new updated data.
Regards
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
From the design document: Q1: [Domain; Last request] What would be preferred number of request to be printed? Do we wan't a parameter for this in sssd.conf or even make it possible to change this value dynamically? - I wouldn't over-engineer this personally, let's start with some fixed number and see if anyone complains.
Q2: [Domain; Server list] Is it enough to print only active server or do we want full list of primary and backup servers as well? - Several users I talked to who I talked to about this feature were also interested in seeing what servers did SSSD discover
Q3: [Domain; Server list] Do we want to also print IP adresses? - I guess this is not needed, this can be easily verified with an external tool.
Q4: [Talloc report] Should we provide parameter $file or should we hardcod the path as SSSD logs directory, generating name from component and time? - I think dumping this to the log directory is OK as long as the tool or its manpage tells the admin where to look.
On 04/06/2016 10:54 AM, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
From the design document: Q1: [Domain; Last request] What would be preferred number of request to be printed? Do we wan't a parameter for this in sssd.conf or even make it possible to change this value dynamically? - I wouldn't over-engineer this personally, let's start with some fixed number and see if anyone complains.
We talked about 10. Do we agree it's a reasonable number for the start?
Q2: [Domain; Server list] Is it enough to print only active server or do we want full list of primary and backup servers as well? - Several users I talked to who I talked to about this feature were also interested in seeing what servers did SSSD discover Q3: [Domain; Server list] Do we want to also print IP adresses? - I guess this is not needed, this can be easily verified with an external tool. Q4: [Talloc report] Should we provide parameter $file or should we hardcod the path as SSSD logs directory, generating name from component and time? - I think dumping this to the log directory is OK as long as the tool or its manpage tells the admin where to look.
On Tue, Apr 12, 2016 at 01:02:30PM +0200, Pavel Březina wrote:
On 04/06/2016 10:54 AM, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
From the design document: Q1: [Domain; Last request] What would be preferred number of request to be printed? Do we wan't a parameter for this in sssd.conf or even make it possible to change this value dynamically? - I wouldn't over-engineer this personally, let's start with some fixed number and see if anyone complains.
We talked about 10. Do we agree it's a reasonable number for the start?
Fine by me.
Q2: [Domain; Server list] Is it enough to print only active server or do we want full list of primary and backup servers as well? - Several users I talked to who I talked to about this feature were also interested in seeing what servers did SSSD discover Q3: [Domain; Server list] Do we want to also print IP adresses? - I guess this is not needed, this can be easily verified with an external tool. Q4: [Talloc report] Should we provide parameter $file or should we hardcod the path as SSSD logs directory, generating name from component and time? - I think dumping this to the log directory is OK as long as the tool or its manpage tells the admin where to look.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 04/06/2016 10:54 AM, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
From the design document: Q1: [Domain; Last request] What would be preferred number of request to be printed? Do we wan't a parameter for this in sssd.conf or even make it possible to change this value dynamically? - I wouldn't over-engineer this personally, let's start with some fixed number and see if anyone complains.
Q2: [Domain; Server list] Is it enough to print only active server or do we want full list of primary and backup servers as well? - Several users I talked to who I talked to about this feature were also interested in seeing what servers did SSSD discover Q3: [Domain; Server list] Do we want to also print IP adresses? - I guess this is not needed, this can be easily verified with an external tool. Q4: [Talloc report] Should we provide parameter $file or should we hardcod the path as SSSD logs directory, generating name from component and time? - I think dumping this to the log directory is OK as long as the tool or its manpage tells the admin where to look.
Since it is no problem to provide a filename when we issue the method over D-Bus we can default to log dir but also allow to specify a path.
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
One more question..
The design document talks about: # sssctl domain-status $domain [--online, --last-request, --active-server, --servers] Online status: Online/Offline Active server: $currently-conected-server (server status, port status, resolver status)
But only main domains have a connection status. How are we going to present the subdomain status? Currently we only disable subdomains temporarily if they are unreachable. I think it would be nice to display this somehow, but I'm not sure if the user would care about our internal status (disabled for subdomain, offline for main domain) or if we should display just online/offline from the start..
On 04/12/2016 12:52 PM, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
One more question..
The design document talks about: # sssctl domain-status $domain [--online, --last-request, --active-server, --servers] Online status: Online/Offline Active server: $currently-conected-server (server status, port status, resolver status)
But only main domains have a connection status. How are we going to present the subdomain status? Currently we only disable subdomains temporarily if they are unreachable. I think it would be nice to display this somehow, but I'm not sure if the user would care about our internal status (disabled for subdomain, offline for main domain) or if we should display just online/offline from the start..
If a subdomain is disabled/enabled use offline/online as well?
On Tue, Apr 12, 2016 at 01:01:03PM +0200, Pavel Březina wrote:
On 04/12/2016 12:52 PM, Jakub Hrozek wrote:
On Tue, Mar 22, 2016 at 12:42:28PM +0100, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
One more question..
The design document talks about: # sssctl domain-status $domain [--online, --last-request, --active-server, --servers] Online status: Online/Offline Active server: $currently-conected-server (server status, port status, resolver status)
But only main domains have a connection status. How are we going to present the subdomain status? Currently we only disable subdomains temporarily if they are unreachable. I think it would be nice to display this somehow, but I'm not sure if the user would care about our internal status (disabled for subdomain, offline for main domain) or if we should display just online/offline from the start..
If a subdomain is disabled/enabled use offline/online as well?
I think it would be fine, because the user doesn't care about the internals, but cares about the fact, that only cached data can be used at that point.
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
I just updated the design page to latest version.
On Mon, Jun 06, 2016 at 02:09:57PM +0200, Pavel Březina wrote:
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
I just updated the design page to latest version.
Would list-domains also include the domain online status or whether the domain is autoconfigured subdomain or a main domain?
On 06/07/2016 11:36 AM, Jakub Hrozek wrote:
On Mon, Jun 06, 2016 at 02:09:57PM +0200, Pavel Březina wrote:
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
I just updated the design page to latest version.
Would list-domains also include the domain online status or whether the domain is autoconfigured subdomain or a main domain?
It is of course possible. But my idea was to print just the domain names so the caller known what to pass to 'sssctl domain-status $domain' to get more information.
On Tue, Jun 07, 2016 at 11:53:55AM +0200, Pavel Březina wrote:
On 06/07/2016 11:36 AM, Jakub Hrozek wrote:
On Mon, Jun 06, 2016 at 02:09:57PM +0200, Pavel Březina wrote:
On 03/22/2016 12:42 PM, Pavel Reichl wrote:
Hello,
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.
Thanks!
I just updated the design page to latest version.
Would list-domains also include the domain online status or whether the domain is autoconfigured subdomain or a main domain?
It is of course possible. But my idea was to print just the domain names so the caller known what to pass to 'sssctl domain-status $domain' to get more information.
Yes, that's better.
sssd-devel@lists.fedorahosted.org