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). 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). >> 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).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
