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
> 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
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
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
> 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).