On ma, 07 helmi 2022, Brian J. Murrell wrote:
On Mon, 2022-02-07 at 11:41 +0200, Alexander Bokovoy wrote:
I think timer should be enabled during package upgrades.
Only upgrades? So on a machine's first installation of ipa-server, the
timer is not enabled? Is that the desired behaviour? Doesn't seem
like it should be.
On first installation it is run as a part of httpd instance creation
process. You should see in the installation log something like
2022-01-28T17:43:00Z DEBUG [15/21]: clean up any existing httpd ccaches
2022-01-28T17:43:00Z DEBUG Starting external process
2022-01-28T17:43:00Z DEBUG args=['/bin/systemd-tmpfiles', '--create',
'--prefix', '/run/ipa/ccaches']
2022-01-28T17:43:00Z DEBUG Process finished, return code=0
2022-01-28T17:43:00Z DEBUG stdout=
2022-01-28T17:43:00Z DEBUG stderr=
2022-01-28T17:43:00Z DEBUG step duration: httpd remove_httpd_ccaches 0.02 sec
You could have just re-run
systemd-tmpfiles --create /usr/lib/tmpfiles.d/ipa.conf
Indeed.
This should have been run on a server restart as well.
Yes it should, and I will be paying close attention at next reboot to
ensure that it does.
This (Failed to unseal session data) means there is wrong key used by
mod_auth_gssapi to encrypt the original session and to decrypt it
now.
Where is this encrypted session stored?
I addressed that in my original answer. The encrypted session is in
ipa_session cookie. It has validity bound to min(kinit_lifetime, 1800)
seconds where kinit_lifetime is defined in default.conf(5).
I can only assume you have been restarting server or its components
and /etc/httpd/alias/ipasession.key got regenerated?
Actually not really. On the non-webUI-functioning server:
# ls -l /etc/httpd/alias/ipasession.key
-rw-------. 1 root root 32 Jan 31 18:28 /etc/httpd/alias/ipasession.key
# uptime
07:08:31 up 1 day, 21:04, 2 users, load average: 0.12, 0.26, 0.31
So clearly that didn't get regenerated on the last reboot. Indeed, it
looks like it has not been regenerated since the replica was created:
Ok, so this one is long-living key. It may be regenerated but not
removed automatically. gssproxy session key, on other hand, is either
tied to a key present in a keytab it tracks for a particular application
or to a random runtime key which is gone if you'd restart gssproxy.
# ls -l /var/log/ipareplica-install.log
-rw-------. 1 root root 5786278 Jan 31 18:36 /var/log/ipareplica-install.log
Same situation on my working replica:
# ls -l /etc/httpd/alias/ipasession.key
-rw-------. 1 root root 32 Jan 17 14:30 /etc/httpd/alias/ipasession.key
# uptime
07:02:12 up 13 days, 21:31, 4 users, load average: 0.17, 0.24, 0.16
# ls -l /var/log/ipareplica-install.log
-rw-------. 1 root root 5736458 Jan 17 14:36 /var/log/ipareplica-
install.log
So indeed, this key has not been changed since the replica was
originally created.
When doing tests with reboot/removal, it is best to clear cookies on
the
client side as well.
Meaning cookies on the browser?
on reboot gssproxy session key is regenerated,
But clearly given the above, on both my working and non-working
replicas, this is not actually the case.
mod_auth_gssapi claims it cannot decode ipa_session cookie, so the
cookie is invalid for the key used by mod_auth_gssapi.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
