---
Francis Augusto Medeiros-Logeay
Oslo, Norway
On 2023-03-23 16:06, Alexander Bokovoy via FreeIPA-users wrote:
On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay wrote:
Thanks a lot Alexander. I have some follow up questions,
On 23 Mar 2023, at 14:50, Alexander Bokovoy <aboko...@redhat.com>
wrote:
On to, 23 maalis 2023, Francis Augusto Medeiros-Logeay via
FreeIPA-users wrote:
Hi,
We use RHEL 8 with kerberos, and we are using NFSv4 for mounting
home
directories.
We have experienced that some machines become unresponsive if a user
has a job that writes to the home directory after his ticket has
expired after the default lifetime (7 days in our case).
While we are looking for ways to allow people to automatically get
new
tickets, we also want to have a mechanism to log users out if their
tickets are too close expiration (as well as all their jobs and cron
jobs).
Is there a way to get the expiration date for user tickets for a
given
user with for example “klist", or only the user himself can get that
info?
klist already lists the expiration date and time. You need to parse
that
if you want to know it. As long as you have access to the ccache
(e.g.
klist runs within the user session scope or you can specify the
ccache
explicitly and have access to it), you have that information.
We use KCM, and with a quick test I saw that, as root, I don’t get to
read much, and I don’t get to know what’s the cache id.
Any idea on how to circumvent that?
Well, 'su - user' might give you access to KCM's view of that user.
Other than that, it might not accessible.
systemd gives you a way to force out logout for a service:
RuntimeMaxSec=
Configures a maximum time for the service to run. If this is
used and the service has been active for longer than the
specified time it is terminated and put into a failure state.
Note that this setting does not have any effect on
Type=oneshot services, as they terminate immediately after
activation completed. Pass "infinity" (the default) to
configure no runtime limit.
If a service of Type=notify sends "EXTEND_TIMEOUT_USEC=...",
this may cause the runtime to be extended beyond
RuntimeMaxSec=. The first receipt of this message must occur
before RuntimeMaxSec= is exceeded, and once the runtime has
extended beyond RuntimeMaxSec=, the service manager will
allow the service to continue to run, provided the service
repeats "EXTEND_TIMEOUT_USEC=..." within the interval
specified until the service shutdown is achieved by
"STOPPING=1" (or termination). (see sd_notify(3)).
The problem here - as I see it - is to start the count dynamically, in
case the user, for example, renews his ticket by entering his password
on another ssh session.
Yeah, this is not something to achieve this way.
and logind gives a way to force killing processes on user's logout:
KillUserProcesses=
Takes a boolean argument. Configures whether the processes of
a user should be killed when the user logs out. If true, the
scope unit corresponding to the session and all processes
inside that scope will be terminated. If false, the scope is
"abandoned", see systemd.scope(5), and processes are not
killed. Defaults to "no", but see the options KillOnlyUsers=
and KillExcludeUsers= below.
In addition to session processes, user process may run under
the user manager unit user@.service. Depending on the linger
settings, this may allow users to run processes independent
of their login sessions. See the description of enable-linger
in loginctl(1).
Note that setting KillUserProcesses=yes will break tools like
screen(1) and tmux(1), unless they are moved out of the
session scope. See example in systemd-run(1).
Thanks. This is also a good tool. But I guess we need to find a way to
scan possible cron jobs that starts exactly when the user isn’t logged
in.
Indeed.
Thanks Alexander. So I guess that we do have to impersonate the user to
get this done, anyway. I wanted to avoid that route, but if that's what
it takes, so I guess that's what we'll have to do :)
Best,
Francis
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
