On 09.07.2024 20:53, Alexander Bokovoy wrote:
# mount |grep /run
tmpfs on /run type tmpfs
(rw,nosuid,nodev,seclabel,size=800996k,nr_inodes=819200,mode=755,inode64)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,seclabel,size=400496k,nr_inodes=100124,mode=700,inode64)
This is on VM and in container it will be the same, so /run is gone when
container instance is gone.
The lookup for ccache referenced from the cookie is done by
mod_auth_gssapi. If it is missing, the file path will still be set (so
KRB5CCNAME will be defined for IPA framework to see) but there will be
no use for it as we just delete the session cookie and redirect for a
login again. This is what you see in the log above.
I think what might be happening here as well is that mod_auth_gssapi
session key gets wiped too so old session cookie cannot be decrypted by
new container instance.
We use the following location for the session key:
GssapiSessionKey file:/etc/httpd/alias/ipasession.key
freeipa-container moves /etc/httpd/alias to the /data volume, so
theoretically ipasession.key should persist.
Can you check that after restart this volume contains ipasession.key and
it is the same as before?
Thank you for quick reply!
Date and sha256 for that file is same before and after container
restart, so it persists correctly.
What else to check?
BR,
Paavo
--
_______________________________________________
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
