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
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
