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
>> around for renewals and reaping, the service won't be exiting unless all
>> 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
>> 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
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
>> How do containers access the KCM? Would they have to run their own copy
>> 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:
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.