Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KCM in non systemd computers? #5574

Closed
joakim-tjernlund opened this issue Apr 7, 2021 · 25 comments
Closed

KCM in non systemd computers? #5574

joakim-tjernlund opened this issue Apr 7, 2021 · 25 comments

Comments

@joakim-tjernlund
Copy link
Contributor

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
Copy link
Member

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

@joakim-tjernlund
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

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

@joakim-tjernlund
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@joakim-tjernlund
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

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

Did you try this?

@joakim-tjernlund
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

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

@pbrezina
Copy link
Member

@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
Copy link
Member

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
Copy link
Contributor Author

joakim-tjernlund commented Apr 12, 2021

@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
Copy link
Member

@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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor

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

@andreboscatto andreboscatto closed this as not planned Won't fix, can't repro, duplicate, stale Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants