KCM in non systemd computers?

[joakim-tjernlund]

As I understand it, KCM is socket activated in systemd. Non systemd users may not have socket activated services.
Is it possible to use KCM in such systems as well?

[alexey-tikhonov]

Did you try to add 'kcm' to sssd.conf::services list?

[joakim-tjernlund]

No, I haven't tried anything yet as I figure it will break if I don't address the lack of socket activation.
Are you confident that just adding kcm in sssd.conf will work?

[joakim-tjernlund]

I guess I can start sssd_kcm as a normal openrc service at boot but is that enough?
Do I have to replace the socket activation part with something else(XDG?) ?

[alexey-tikhonov]

@pbrezina , do you remember if we support running sssd_kcm via sssd.conf::services instead of socket-activated config?

[joakim-tjernlund]

I just tested to start sssd_kcm and sssd_secrets to see what happened, started just fine. However, after a few mins of inactivity
both services terminated due to idle timer. How can one work around that ?

[alexey-tikhonov]

I just tested to start sssd_kcm and sssd_secrets to see what happened, started just fine.

Why do you need sssd_secrets? It's deprecated long time and I plan to remove it completely in upcoming release.

However, after a few mins of inactivity
both services terminated due to idle timer. How can one work around that ?

Try setting responder_idle_timeout = 0 in [kcm] section of sssd.conf

[joakim-tjernlund]

I just tested to start sssd_kcm and sssd_secrets to see what happened, started just fine.

Why do you need sssd_secrets? It's deprecated long time and I plan to remove it completely in upcoming release.

Oh, I just saw that there was one. Good to know I can skip that one then :)

However, after a few mins of inactivity
both services terminated due to idle timer. How can one work around that ?

Try setting responder_idle_timeout = 0 in [kcm] section of sssd.conf

I did in sssd.conf:

[kcm]
responder_idle_timeout = 0

Seems to work, I do think an option to sssd_kcm would be cleaner, sssd.conf should not be adjusted for this I think.

When should sssd_kcm be started(if a service)? As early as possible, just before or after sssd?

[joakim-tjernlund]

Q: sssd(without KCM) can renew tickets it has created itself(pam_sss) I think.
What about screenunlocks? Can that be make to work somehow too?

[joakim-tjernlund]

Why socket activation? Is it just an optimization or is there some function behind it?
I am wondering if i could add an xinetd service to do socket activation? Just an idea ATM.

[joakim-tjernlund]

So I have started kcm as a service and seem to be working well and change krb5.conf: default_ccache_name = KCM:
But when I login (ssh or XDM) I still get

env | grep KRB5
KRB5CCNAME=FILE:/tmp/krb5cc_1001

I am stumped, why don't I grep the KCM cache?
Do I need to build mit-krb5 with some extra option, I have(Gentoo):

app-crypt/mit-krb5
Installed versions:  1.18.2-r3^t{xpak}(16:13:53 15/03/21)(keyutils nls threads -doc -libressl -lmdb -openldap -pkinit -selinux -test -xinetd ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32" CPU_FLAGS_X86="aes")

[joakim-tjernlund]

So I have started kcm as a service and seem to be working well and change krb5.conf: default_ccache_name = KCM:
But when I login (ssh or XDM) I still get

env | grep KRB5
KRB5CCNAME=FILE:/tmp/krb5cc_1001

I am stumped, why don't I grep the KCM cache?

After rebooting I got a KCM: cache, no idea why not restartin sssd/sssd-kcm worked

[joakim-tjernlund]

Now I think the remaining Q is, when should sssd-kcm service start(early as possible, just before or after sssd)?

[joakim-tjernlund]

sudo does not work as before:

jocke@se-jocke4-lx ~ $ sudo 
se-jocke4-lx jocke # klist 
klist: Credentials cache 'KCM:0' not found

What is missing ?
ksu works though

[joakim-tjernlund]

Now I think the remaining Q is, when should sssd-kcm service start(early as possible, just before or after sssd)?

could not sssd start sssd_kcm, just like sssd does with sssd_be, sssd_nss, sssd_pam etc?

[alexey-tikhonov]

could not sssd start sssd_kcm, just like sssd does with sssd_be, sssd_nss, sssd_pam etc?

Did you try this?

[joakim-tjernlund]

could not sssd start sssd_kcm, just like sssd does with sssd_be, sssd_nss, sssd_pam etc?

Did you try this?

How? doesn't that require soem code in sssd ?
But the bigger Q is if sssd-kcm should be considered independent of sssd, can sssd-kcm operate independent of sssd ?
I think so and that implies sssd-kcm should be its own service I guess

[joakim-tjernlund]

However, after a few mins of inactivity
both services terminated due to idle timer. How can one work around that ?

Try setting responder_idle_timeout = 0 in [kcm] section of sssd.conf

This does not work 100% There are case when kcm terminates on its own, not sure when.
I do think it happened when I did a kdestroy and the cache became empty.

All in all, KCM does not seem ready yet, there are a few bugs here that are must have.

[alexey-tikhonov]

@justin-stephenson, probably you could help here answering some of the questions.

[pbrezina]

@joakim-tjernlund What distribution do you run that doesn't have systemd? What sssd version do you run?

In general, sssd-kcm was intended to be socket activate. Other ways of starting it may be possible but we don't official support them nor test them. At least, starting sssd_kcm manully works since I use it from time to time to debug it. Second option is to add it to services line in sssd.conf.

The process is socket activated since it usually does not need to run all the time. Termination can be avoided by setting responder_idle_timeout = 0 as Alexey already suggested. If that does not work correctly, we need to see some logs.

But the bigger Q is if sssd-kcm should be considered independent of sssd, can sssd-kcm operate independent of sssd ?
I think so and that implies sssd-kcm should be its own service I guess

Yes, sssd-kcm can run without other sssd processes. It is its own systemd service (sssd-kcm.service) that you can start, but we don't official support it without systemd.

[pbrezina]

sudo does not work as before:

jocke@se-jocke4-lx ~ $ sudo 
se-jocke4-lx jocke # klist 
klist: Credentials cache 'KCM:0' not found

What is missing ?
ksu works though

I guess you need to set KRB5CCNAME to "KCM:$uid" and let sudo.conf keep this env var (which you probably already do).

[joakim-tjernlund]

@joakim-tjernlund What distribution do you run that doesn't have systemd? What sssd version do you run?

Gentoo, it has systemd but systemd bugs for us whenever we try it. Seems like there are some rough corners left in systemd in a corporate setting. We run sssd master ATM

In general, sssd-kcm was intended to be socket activate. Other ways of starting it may be possible but we don't official support them nor test them. At least, starting sssd_kcm manully works since I use it from time to time to debug it. Second option is to add it to services line in sssd.conf.

The process is socket activated since it usually does not need to run all the time. Termination can be avoided by setting responder_idle_timeout = 0 as Alexey already suggested. If that does not work correctly, we need to see some logs.

Tried responder_idle_timeout = 0 but it does not work fully, I think kdestroy on the last ticket makes KCM terminate.

socket activation is still debated if it adds value or not, I wish you would support both. If I am to support non socket activation by myself it is really too much, digging into sssd codebase is a big investment and you would probably reject any patches as it is not supported.

[pbrezina]

@joakim-tjernlund What distribution do you run that doesn't have systemd? What sssd version do you run?

Gentoo, it has systemd but systemd bugs for us whenever we try it. Seems like there are some rough corners left in systemd in a corporate setting. We run sssd master ATM

In general, sssd-kcm was intended to be socket activate. Other ways of starting it may be possible but we don't official support them nor test them. At least, starting sssd_kcm manully works since I use it from time to time to debug it. Second option is to add it to services line in sssd.conf.
The process is socket activated since it usually does not need to run all the time. Termination can be avoided by setting responder_idle_timeout = 0 as Alexey already suggested. If that does not work correctly, we need to see some logs.

Tried responder_idle_timeout = 0 but it does not work fully, I think kdestroy on the last ticket makes KCM terminate.

I'm not aware of such logic in the code, can you provide logs?

socket activation is still debated if it adds value or not, I wish you would support both. If I am to support non socket activation by myself it is really too much, digging into sssd codebase is a big investment and you would probably reject any patches as it is not supported.

We support both with systemd - you can just run 'systemctl enable --now sssd-kcm.service' (and setting responder_idle_timeout). So the question is if you want to get rid of socket activation or systemd as whole. If you want to get rid of systemd completely, that is something we don't officially support fo kcm.

[joakim-tjernlund]

Tried responder_idle_timeout = 0 but it does not work fully, I think kdestroy on the last ticket makes KCM terminate.

I'm not aware of such logic in the code, can you provide logs?

Been trying for 24 hours now to get logs but the problem has not shown itself :(
kcm did die/exit 3-4 times in less than a day when I did my initial testing.

socket activation is still debated if it adds value or not, I wish you would support both. If I am to support non socket activation by myself it is really too much, digging into sssd codebase is a big investment and you would probably reject any patches as it is not supported.

We support both with systemd - you can just run 'systemctl enable --now sssd-kcm.service' (and setting responder_idle_timeout). So the question is if you want to get rid of socket activation or systemd as whole. If you want to get rid of systemd completely, that is something we don't officially support fo kcm.

Not systemd, we use elogind as replacement so that is fine. I was not aware you supported KCM as a service too in systemd, good. Is that something you test on a regular basis too? The one requset I have is that one should not have edit sssd.conf to switch between socket activation/service. Image you had to set socket_activation = true in sssd.conf before you could start that part.

[alexey-tikhonov]

Unfortunately, sssd_kcm name of the process is somewhat misleading.
sssd_kcm actually isn't coupled to SSSD itself, it's a daemon on its own, merely sharing some libs with SSSD project.
There is no real reason to run/manage 'sssd_kcm' via SSSD's 'monitor'.

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards,
André Boscatto