URL:
https://github.com/SSSD/sssd/pull/106
Title: #106: Add a new "files" provider
pbrezina commented:
"""
**UTIL: Add a generic inotify module**
```c
if ((debug_level & SSSDBG_TRACE_LIBS) == false) {
return;
}
^ use DEBUG_IS_SET(SSSDBG_TRACE_LIBS)
```
**D-Bus Interfaces:**
I would like to see the interfaces like this. It reads better to me as a command.
```xml
<interface name="org.freedesktop.sssd.Responder.Domain">
<annotation value="iface_responder_domain"
name="org.freedesktop.DBus.GLib.CSymbol"/>
<method name="EnableDomain">
<arg name="name" type="s" direction="in"
/>
</method>
<method name="DisableDomain">
<arg name="name" type="s" direction="in"
/>
</method>
</interface>
<interface name="org.freedesktop.sssd.Responder.NegativeCache">
<annotation value="iface_responder_ncache"
name="org.freedesktop.DBus.GLib.CSymbol"/>
<method name="ResetUsers" />
<method name="ResetGroups" />
</interface>
```
**DP: Add internal DP interface to enable and disable domains**
**DP: Add internal interface to reset negative cache from DP**
You can use `sbus_create_message()`
**FILES: Add the files provider**
```c
static struct dp_reply_std
files_account_info_handler(struct dp_id_data *data,
struct sss_domain_info *domain)
```
Change it to `errno_t files_check_account_input(struct dp_id_data *data)` or move it into
`files_account_info_handler_send()` please. It is not necessary to move creation of reply
further into the code.
I didn't know what `sf_` prefix stands for (sssd files), I believe keeping `files_`
prefix as in the names of sources files and structures and other functions will read
better.
`delete_all_users/groups()` -> you can use `sysdb_delete_recursive()`
**CONFDB: The files provider always enumerates**
We do not have to support enumeration just because we do enumeration internally. We can
make it default, yes. But do not force it.
**CONFDB: Make pwfield configurable per-domain**
`nss_get_pwfield()` move to `nss_util.c`. You can include nss_private.h there for sure.
> You say that a domain is disabled during enumeration and we fall
back to nss files. Do you expect the update to take a really long time? Wouldn't it be
better to jus wait until the enumeration is done?
I was thinking about this for some time and it seemed safer to me to
fall back. But just when I was thinking about this again today, I
realized that at least the InfoPipe interface has nowhere to fall back
to, so the behaviour must either differ on the cache_req level between
the nss responder and the ifp responder or we should wait until the
domain updates in both cases.
Do not special case. Currently users are waiting several seconds to get remote identities
so I think an occasional little delay with local users is acceptable (but we need to block
client until enumeration is finished so we always return accurate information). Keep in
mind that:
* the change will be still pretty fast on most systems since sssd users do not usually
have large `passwd` and `groups`
* unless it is a kickstart the change in files will be triggered by user input and there
will be a delay before the user will provide another command
If there will be pushback we can try to optimize it later but I would start simple.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/106#issuecomment-271569020