Hello Simo, memcache works for me.
Thanks for support. Marek Odoslané pomocou bezpečného emailu Proton Mail. pondelok 27. apríla 2026, 20:23, Simo Sorce <[email protected]> napísal/a: > On Mon, 2026-04-27 at 18:12 +0000, Marek Greško wrote: > > Great analysis. I found out there are some ways of configuring gssd in > > /etc/nfs.conf. Mys current config for it states: > > > > use-gss-proxy=1 > > > > There are available options > > > > # cred-cache-directory= > > # use-memcache=0 > > > > Would not one of these options solve my problem? > > memcache may be worth a try, the only issue is that a process restart > means loosing the cache and having to go back to the KDC to acquire a > new TGT, but that shouldn't be a big deal. > > > I think the memory cache woudl be better. Are there any culprits I am not > > aware of not to do it like this? > > The memory cache is a cache collection and could lead to some > interesting issues, but it may be worth a try. > > > If the second option with cred directory is used, what is the recommended > > diretory in Fedora to use? Should I use /var/lib/nfs? > > Any directory that is accessible by rpc.gssd and is not world writable > will not cause selinux issues will be fine, given your users never > litter /tmp with ccaches. In fact an otherwise empty directory will > speed up some operations when rpc.gssd decided to "scan" the ccache > directory for user caches. > > > Thanks > > > > Marek > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > pondelok 27. apríla 2026, 19:33, Simo Sorce via Kerberos <[email protected]> > > napísal/a: > > > > > Gssproxy never stores caches in /tmp, that file is more likely created > > > by rpc.gssd the NFS Client daemon that handles GSSAPI authentication. > > > > > > rpc.gssd is sadly stuck in time and forces the use of the FILE: ccache > > > through most of its code, which is why we intercept it with gssproxy > > > for some operations with user ccaches only. > > > > > > HTH, > > > Simo. > > > > > > On Mon, 2026-04-27 at 17:02 +0000, Marek Greško via Kerberos wrote: > > > > Hello, > > > > > > > > so for klist it seems it is generated by gssproxy, because there is > > > > nfs/ ticket. > > > > > > > > Regarding gssproxy.conf I have the file > > > > /etc/gssproxy/99-network-fs-clients.conf containing: > > > > > > > > [service/network-fs-clients] > > > > mechs = krb5 > > > > cred_store = keytab:/etc/krb5.keytab > > > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > > > cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab > > > > cred_usage = initiate > > > > allow_any_uid = yes > > > > trusted = yes > > > > euid = 0 > > > > min_lifetime = 60 > > > > > > > > But apparently it is not using the path. I also did not find how to > > > > specify path for machine ccache. Even better, if I could convince > > > > machine ccache to be also stored in KCM. Is it possible? > > > > > > > > Thanks > > > > > > > > Marek > > > > > > > > > > > > > > > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > > > > > pondelok 27. apríla 2026, 16:19, Christian, Mark > > > > <[email protected]> napísal/a: > > > > > > > > > On Mon, 2026-04-27 at 04:38 +0000, Marek Greško wrote: > > > > > > Hello, > > > > > > > > > > > > the > > > > > > kinit -c /tmp/krb5ccmachine_EXAMPLE.COM > > > > > > asks for password. Which password? What should I expect thereafter > > > > > > to > > > > > > happen? > > > > > > > > > > Sorry I meant for you to use klist, not kinit: > > > > > > > > > > % klist -c /tmp/krb5ccmachine_EXAMPLE.COM > > > > > > > > > > > > > > > > > I also asked AI to help me on the original issue. It thinks it is > > > > > > related to gssproxy and most probably it is right. It stated there > > > > > > is > > > > > > not nuch to do and I should accept the current state. But I feel a > > > > > > little bit unhappy, since it creates file with predictable name in > > > > > > the /tmp and it could be a security risk. > > > > > > > > > > see man gssproxy.conf for details on howto configure the location of > > > > > cred_store / ccache. > > > > > > > > > > Mark > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Marek > > > > > > > > > > > > > > > > > > > > > > > > Odoslané pomocou bezpečného emailu Proton Mail. > > > > > > > > > > > > piatok 24. apríla 2026, 16:02, Christian, Mark > > > > > > <[email protected]> napísal/a: > > > > > > > > > > > > > On Fri, 2026-04-24 at 10:44 +0000, Marek Greško via Kerberos > > > > > > > wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > I have configured kerberos client on Fedora 43. I configured > > > > > > > > kerberos > > > > > > > > to use KCM: ccache. Users ccaches are in KCM, but I always see > > > > > > > > the > > > > > > > > file /tmp/krb5ccmachine_EXAMPLE.COM created. Why is this file > > > > > > > > created? > > > > > > > > > > > > > > Perhaps related to your kerberos NFS configuration? Inspect the > > > > > > > cache, > > > > > > > kinit -c /tmp/krb5ccmachine_EXAMPLE.COM, doing so might clue you > > > > > > > in. > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > > > What mechanism does not use KCM and how could it be convinced > > > > > > > > to > > > > > > > > do > > > > > > > > so? > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Marek > > > > > > > > ________________________________________________ > > > > > > > > Kerberos mailing list [email protected] > > > > > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > > > > > > > > > ________________________________________________ > > > > > > > Kerberos mailing list [email protected] > > > > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > > > > > > > > > > > > ________________________________________________ > > > > > Kerberos mailing list [email protected] > > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > > > > > > > > ________________________________________________ > > > > Kerberos mailing list [email protected] > > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > -- > > > Simo Sorce > > > Distinguished Engineer > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > ________________________________________________ > > > Kerberos mailing list [email protected] > > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
