#3138 Enable socket-activate services to refresh configuration
Closed: cloned-to-github 3 years ago by pbrezina. Opened 7 years ago by jhrozek.

At the moment, we have some socket-activated services (like sssd-secrets) that read the configuration from confdb, but the confdb is only refreshed when sssd starts.

We should write an on-demand socket-activated service that just writes the configuration to confdb and exits. Simo suggested we could implement this by writing a byte into the socket which would start the config service and wait until a byte comes back, which would signify the configuration was written.


We need this ticket implemented for KCM and localusers, therefore filing to 1.15.

milestone: NEEDS_TRIAGE => SSSD 1.15 Beta

Fields changed

rhbz: => todo

Fields changed

owner: somebody => fidencio

As currently the only socket-activated service that we have is sssd-secrets, I'm wondering whether this new service must be built only when secrets is built and also to put its code under src/responders/secrets/.

Considering we go for this, in the future when more socket-activated services show up we can move it to some new src/helpers/services/ directory structure.

Ideas? Objections?

Consider that the component that writes to the confdb must run as root (to read sssd.conf), must be allowed to write to the confdb both by UNIX DAC rights and by SELinux.

Fields changed

patch: 0 => 1
status: new => assigned

What was the original intention of confdb anyway? Can't we just used memory mapped ini file instead?

The history is that the confdb was there first. INI was added later. Also it is hard to share a memory mapped INI between processes while confdb can have connections from different processes at the same time.

Ok, so I think we can parse sssd.conf at startup into internal data structure and get rid of confdb entirely and finally allow options and manpages to be generated from one source.

You want to be able to do several things:

- Use INI in memory
- Reload it on SIGHUP
- Make it available to different processes in a consistent and non-racy way

To be able to do it you need a service that would actually be responsible for configuration that other services would query and use. This makes the architecture quite complex. Making INI loaded into each process will be racy and will make reloads unstable. IMO this is not that simple as it seems. But I agree that removing confdb should be the goal.

This discussion is valid but I'd like to have it tracked in a separate ticket.

There was a discussion in the #sssd channel about this very same topic and I'm copying and pasting the relevant parts here, just for the record:

11:25 <mzidek> fidencio, jhrozek, simo: I think it would be great to get rid of confdb and have a service with nice API to read the configuration... the service could be controlled with sssctl commands (for example sssctl confd-start/stop/reload)

11:28 <simo> mzidek: you need to write the config somewhere

11:28 <simo> and you do not want to have interprocess communications just to read a config variable

(...)

11:30 <fidencio> I still didn't get the big advantage of getting rid of confdb

11:33 <mzidek> fidencio: well getting rid of confdb is just idea... the problem we have with reading keeping the copy of configuration in different processes is that it is not very consistent... for example sometimes we store part of the configuration in some structure and sometimes we use confdb

11:36 <mzidek> fidencio: ideally we would need something centrally managed and fast... I am not sure how fast is DBus in comparison to reading an mmaped file... the possibilities need to be investigated

11:36 <fidencio> hmm. seems like something that I'll ignore for now.

11:45 <simo> mzidek: IPC is always a lot slower than reading an mmaped file

11:47 <Crys> and less efficient

11:48 <mzidek> simo: yes, but the question is if DBus is "fast enough" for us

11:50 <Crys> I would be more concerned with security. SSSD is a critical part of infrastructure.

11:50 <simo> mzidek: I do not see the point really

11:50 <simo> mzidek: what would be the advantage to do IPC every time you need to check config variables ?

11:51 <simo> mzidek: or do you mean to request all config at once via dbus ?

12:12 <mzidek> simo: I though it may be good to have centrally managed configuration by a service that would do the config file merging and create some sort of readable structure (ok, DBus may not be the best idea for that)... and offer API for tools and SSSD to read the config (one option at a time or all at once if needed)

12:14 <simo> mzidek: that's what confdb is, what's the advantage in changing it if you end up with a semantically similar solution ?

12:14 <simo> we already have python API to read config

12:14 <simo> also confdb allows you to read individual options

12:15 <simo> what I am trying to understand is: a) what is your goal ? b) what is the difference from what we have now (assuming ticket #3138 is implemented)

12:21 <mzidek> simo: if ticket #3138 is implemented then it will not be such an issue indeed...

I think the main reason why we started talking about changing the way we do configuration is that we can't change config files and make SSSD reload configuration without restarting SSSD completely. It was assumed that SIGHUP should work (see #2465). But maybe we can do the following:
a. Extract the logic that does the config reading and merging into a separate tool.
b. Run this process to update confdb at SSSD start
c. Run this process when sssctrl is called with a new switch --confreload or something like
d. Make sure that the processes that read data from confdb do not have an extra cache in memory or at least can flush it if they get a D-BUS message from sssctrl

If we do something along these lines we would solve the issue. However this assumes that confdg by itself provides the level of performance we are OK with.

Metadata Update from @jhrozek:
- Issue assigned to fidencio
- Issue set to the milestone: SSSD 1.15.3

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch adjusted to on (was: 1)
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: None
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.15.3)

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: cleanup-two-point-oh

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue untagged with: cleanup-two-point-oh
- Issue set to the milestone: SSSD 2.0 (was: SSSD 1.15.4)

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue priority set to: critical (was: major)

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.1 (was: SSSD 2.0)

5 years ago

Metadata Update from @fidencio:
- Assignee reset

5 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.2 (was: SSSD 2.1)

5 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.3 (was: SSSD 2.2)

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: Future milestone

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4171

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @pbrezina:
- Issue close_status updated to: cloned-to-github
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata