I'm sending this on behalf of Pavel Reichl...
Hi,
during devconf week Jakub asked us to send a few overview paragraphs about features we will be working on in forth coming months. Implementation details will be discussed in design documents as usually.
I and Pavel Březina will be working together on SSSD control tool - SSSCTL. Main purpose of this task is to make administration & debugging tasks more user friendly and thus hopefully save time of users, support and us developers.
SSSCTL will be mostly CLI/TUI client using the SSSD infopipe as a server that will be providing necessary data and will perform/delegate commands to the SSSD providers and responders.
Capabilities of the tool:
1) online/offline state - https://fedorahosted.org/sssd/ticket/385 Users have repeatedly asked for simple mean how to check if data provider id offline or online without need to check logs (if logging is enabled at all).
2a) Report whether the entry is present in SSSD cache - https://fedorahosted.org/sssd/ticket/2166
2b) Check if the cached entry is valid and refresh if appropriate - https://fedorahosted.org/sssd/ticket/2166
2c) Measure the time an operation took (useful in performance tuning) - https://fedorahosted.org/sssd/ticket/385
3) Failover status - Current state of failover process {connecting to server, waiting, failed, succeeded)
4) Display server to which provider is connected to - https://fedorahosted.org/sssd/ticket/385
5) Display current debug level of a component
6) Generate memory report Usually when user is observing a memory leak we provide him a special build that generates talloc report which we can then analyze. Using this tool customer would simply select SSSD component that is supposed to leak memory and generate the talloc report immediately.
7) Force reload - restart of components?
Work dependency: 1) Data provider refactoring 2) Extend interface between DP and IFP - https://fedorahosted.org/sssd/ticket/2957, https://fedorahosted.org/sssd/ticket/2954 3) Extend public interface of IFP 4) Tool (logic + user interface) - https://fedorahosted.org/sssd/ticket/385
On Fri, Feb 19, 2016 at 02:34:17PM +0100, Pavel Březina wrote:
I'm sending this on behalf of Pavel Reichl...
Hi,
during devconf week Jakub asked us to send a few overview paragraphs about features we will be working on in forth coming months. Implementation details will be discussed in design documents as usually.
I and Pavel Březina will be working together on SSSD control tool - SSSCTL. Main purpose of this task is to make administration & debugging tasks more user friendly and thus hopefully save time of users, support and us developers.
SSSCTL will be mostly CLI/TUI client using the SSSD infopipe as a server that will be providing necessary data and will perform/delegate commands to the SSSD providers and responders.
Capabilities of the tool:
- online/offline state - https://fedorahosted.org/sssd/ticket/385
Users have repeatedly asked for simple mean how to check if data provider id offline or online without need to check logs (if logging is enabled at all).
OK, we just need to make it clear in the docs that the state can change over time either with another lookup or even with a periodic task or as a result of external change (netlink notification etc..)
2a) Report whether the entry is present in SSSD cache - https://fedorahosted.org/sssd/ticket/2166
2b) Check if the cached entry is valid and refresh if appropriate - https://fedorahosted.org/sssd/ticket/2166
I think 2a and 2b are more or less the same, what the admins are interested in is whether an entry was returned from the cache or refreshed. So I guess publishing the dataExpireTimestamp on the bus would do?
2c) Measure the time an operation took (useful in performance tuning) - https://fedorahosted.org/sssd/ticket/385
IIRC when we brainstormed about the idea we were thinking about a ring buffer that would keep track of the last 10 back end requests and their start/stop time, correct?
- Failover status - Current state of failover process {connecting to
server, waiting, failed, succeeded)
- Display server to which provider is connected to -
Did you already think about how this would be exposed? As part of the domain object on the bus or as a new status object (I think I would prefer the latter, at least because I don't think anyone except root should read this info..)
Display current debug level of a component
Generate memory report
Usually when user is observing a memory leak we provide him a special build that generates talloc report which we can then analyze. Using this tool customer would simply select SSSD component that is supposed to leak memory and generate the talloc report immediately.
- Force reload - restart of components?
Hmm, I thought this was a separate task, which would add a command to sss_cache that actually removes the caches? This would be handy when we start adding more files (secrets especially) to /var/lib/sss/ to prevent someone from accidentally deleting these files...
Work dependency:
- Data provider refactoring
- Extend interface between DP and IFP -
https://fedorahosted.org/sssd/ticket/2957, https://fedorahosted.org/sssd/ticket/2954
I think only these two should be part of the Alpha release and all other tickets should be in Beta.
- Extend public interface of IFP
- Tool (logic + user interface) - https://fedorahosted.org/sssd/ticket/385
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On (19/02/16 14:34), Pavel Březina wrote:
I'm sending this on behalf of Pavel Reichl...
Hi,
during devconf week Jakub asked us to send a few overview paragraphs about features we will be working on in forth coming months. Implementation details will be discussed in design documents as usually.
I and Pavel Březina will be working together on SSSD control tool - SSSCTL. Main purpose of this task is to make administration & debugging tasks more user friendly and thus hopefully save time of users, support and us developers.
SSSCTL will be mostly CLI/TUI client using the SSSD infopipe as a server that will be providing necessary data and will perform/delegate commands to the SSSD providers and responders.
Capabilities of the tool:
- online/offline state - https://fedorahosted.org/sssd/ticket/385
Users have repeatedly asked for simple mean how to check if data provider id offline or online without need to check logs (if logging is enabled at all).
2a) Report whether the entry is present in SSSD cache - https://fedorahosted.org/sssd/ticket/2166
2b) Check if the cached entry is valid and refresh if appropriate - https://fedorahosted.org/sssd/ticket/2166
2c) Measure the time an operation took (useful in performance tuning) - https://fedorahosted.org/sssd/ticket/385
Is this related to Jakub's systemtap work?
- Failover status - Current state of failover process {connecting to server,
waiting, failed, succeeded)
- Display server to which provider is connected to -
https://fedorahosted.org/sssd/ticket/385
Display current debug level of a component
Generate memory report
Usually when user is observing a memory leak we provide him a special build that generates talloc report which we can then analyze. Using this tool customer would simply select SSSD component that is supposed to leak memory and generate the talloc report immediately.
Could you compare this feature to following command?
gdb -ex 'call talloc_enable_null_tracking()' \ -ex 'call talloc_report_full(0, debug_file)' \ -ex 'detach' \ -ex 'quit' \ program `pgrep sssd_nss`
It will dump talloc report into log file. So you will also see a context and moreover it works also with any version of sssd.
- Force reload - restart of components?
What do you mean by "reload component"? Reload configuration?
Work dependency:
- Data provider refactoring
- Extend interface between DP and IFP -
https://fedorahosted.org/sssd/ticket/2957, https://fedorahosted.org/sssd/ticket/2954 3) Extend public interface of IFP 4) Tool (logic + user interface) - https://fedorahosted.org/sssd/ticket/385
LS
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Pavel Březina