On Tue, Nov 22, 2016 at 09:49:52AM -0500, Stephen Gallagher wrote: > On 11/22/2016 09:38 AM, Simo Sorce wrote: > > On Tue, 2016-11-22 at 09:23 -0500, Stephen Gallagher wrote: > > >> OK, so the service is only semi-socket-activated? If we're keeping tevent > >> timers > >> around for renewals and reaping, the service won't be exiting unless all > >> tickets > >> have expired and been reaped. > >> > >> Would it be possible to look into setting non-persistent systemd timer > >> units > >> instead that would "wake up" the sssd_kcm service at appropriate times to > >> do > >> renewal and expiration? > >> > >> systemd provides the CreateTransientUnit() method on its public API that we > >> could use for this purpose. If we did it this way, then the service would > >> only > >> need to be activated whenever a ticket was actually being retrieved from > >> the > >> collection. > > > > I am trying to think if this would gain us anything. > > What would you use as a reasonable timeout to decide to exit ? > > There are other events we may want to detect in future. for example we > > may want to decide to destroy all of a user ccaches if all his sessions > > go away, this requires active probing though, but I guess it could also > > be a timer or maybe systemd has a way to notify and start a process when > > this happens too ? > > > > Well, as far as a timeout to exit, I'd probably go with a minute or two (since > you may have a short flurry of activity, such as when a user first connects > to a > VPN).
I think the systemd transient units would be workable, but I also think it's not the biggest priority. For starters, we could make the service exit only when there are no credentials to be renewed or kept track about. So unless you disagree, I would file a ticket about this and proceed without any elaborate shutdown logic first. There is still a lot of work to do even without this additional functionality :) > > As far as notification of a user signing in or out, we *could* attach a helper > unit to the systemd user session default.target (and have an ExecStop command > for handling when it gets shut down too). Yes, this is something to look into. We already have https://fedorahosted.org/sssd/ticket/2551 > > >> How do containers access the KCM? Would they have to run their own copy > >> internal > >> to the container? Would we bind-mount the > >> /var/run/.heim_org.h5l.kcm-socket and > >> then work some namespacing magic in the host? > > > > Deployment specific, I can see either way as an option depending on what > > you are doing. > > > > OK, but the document doesn't describe how that might be done. We should > identify > the set of supported approaches up-front and include them in the design. > > > >> You call out in the introduction that this will help address container > >> use-cases, but then don't describe that implementation. This seems like an > >> important piece of the puzzle that should be added to the page (or made > >> more > >> clear, since if it's in there, I can't spot it). > > > > What would you want to call out exactly ? > > > > Describe a couple use-cases and the expected user experience for setting them > up > and using them. If we bind-mount the host's KCM into the container, would the > user namespacing be handled "magically" by the kernel or do we need to keep > track of which cgroup our client is and sort it into its own section of the > database? (Just for example). I added (and tested!) two, both concern containers because the single host use-case is IMO quite clear. You can find them described in detailed steps here: https://fedorahosted.org/sssd/wiki/DesignDocs/KCM#Use-case:separatingccachesofrootusersincontainersSSSDisrunningonthehost and here: https://fedorahosted.org/sssd/wiki/DesignDocs/KCM#Use-case:separatingccachesofcontainersfromccachesofthehost Writing up these cases was actually a nice exercise to see if the current version in my branch already covers what we wanted :) Feel free to ask if you'd like me to test and document more cases. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
