On 12/02/2013 05:20 PM, Alexander Bokovoy wrote: > On Mon, 02 Dec 2013, Martin Kosek wrote: >> On 12/02/2013 04:05 PM, Petr Viktorin wrote: >>> On 12/02/2013 03:42 PM, Simo Sorce wrote: >>>> On Mon, 2013-12-02 at 14:51 +0100, Petr Viktorin wrote: >>>>> On 12/02/2013 02:01 PM, Martin Kosek wrote: >>>>>> On 12/02/2013 01:58 PM, Petr Viktorin wrote: >>>>>>> On 11/29/2013 01:48 PM, Martin Kosek wrote: >>>>>>>> On 11/19/2013 12:35 PM, Petr Viktorin wrote: >>>>>>>>> On 11/05/2013 07:22 PM, Martin Kosek wrote: >>>>>>>>>> Server and client installer should allow kernel keyring ccache when >>>>>>>>>> supported. >>>>>>> >>>>>>>>> >>>>>>>>> How do I enable the kernel keyring? On f20 I get this: >>>>>>>>> >>>>>>>>> 2013-11-19T11:28:07Z DEBUG Starting external process >>>>>>>>> 2013-11-19T11:28:07Z DEBUG args=keyctl get_persistent @s 0 >>>>>>>>> 2013-11-19T11:28:07Z DEBUG Process finished, return code=1 >>>>>>>>> 2013-11-19T11:28:07Z DEBUG stdout= >>>>>>>>> 2013-11-19T11:28:07Z DEBUG stderr=keyctl_get_persistent: Key has been >>>>>>>>> revoked >>>>>>>> >>>>>>>> It should be enabled out of the box. But there were some initial issues >>>>>>>> with >>>>>>>> persistent keyring in the first versions of kernel with a support, >>>>>>>> hopefully >>>>>>>> this was just a fluke which disappeared. >>>>>>>> >>>>>>>> This is what I see on my F20 with kernel-3.11.9-300.fc20.x86_64: >>>>>>>> >>>>>>>> # keyctl get_persistent @s 0 >>>>>>>> 637466038 >>>>>>> >>>>>>> With kernel-3.11.10-300.fc20.x86_64, I get an error again: >>>>>>> $ keyctl get_persistent @s 0 >>>>>>> keyctl_get_persistent: Key has been revoked >>>>>> >>>>>> Not sure if it is a typo, but you won't surely get a root's keyring as a >>>>>> non-root user... >>>>> >>>>> It is just a typo, but it looks like you got me on the right track. >>>>> keyctl apparently needs a real root login: >>>>> >>>>> $ sudo keyctl get_persistent @s 0 >>>>> keyctl_get_persistent: Key has been revoked >>>>> >>>>> $ sudo su >>>>> # keyctl get_persistent @s 0 >>>>> keyctl_get_persistent: Key has been revoked >>>>> # exit >>>>> >>>>> $ sudo su - >>>>> Last login: Mon Dec 2 14:09:36 CET 2013 on pts/1 >>>>> # keyctl get_persistent @s 0 >>>>> 968622527 >>>>> # logout >>>>> >>>> >>>> Please use "sudo -i" to get an interactive 'login' shell. >>>> >>>>> Unsurprisingly, when ipa-server-install is run from sudo, it complains >>>>> that the key is unsupported. From a root login all is OK. >>>>> >>>>> Is that expected? >>>> >>>> You should run ipa-server-install using a login shell I think. >>>> Should we open a bug to detect this and fail ? >>> >>> It's always worked with just sudo for me. So yes, if it's required I think >>> we >>> should enforce it. >>> >> >> Simo or Alexander, is there some way to find that out in a clean way? I mean >> if >> we are in an interactive login shell. Ideally, please also file a bug with >> this >> information :) > Interactive or login? These two are different a bit. > > There is no general way because not all shells implement common approach > to detect this. For example, > echo $- | grep -q i > > would work in a Bourne-style shell for interactive shell > > shopt -q login_shell > > would give you a login shell detector in bash but > > test $options[LOGIN] = on > > would work for login shell in zsh, similarly INTERACTIVE index would > give you state of interactive shell. > >
I meant login shell - so that we do not have problems with checking the get_persistent keyctl command. I still do not fully understand the keyctl behavior, it is working on my kernel-3.11.9-300.fc20.x86_64 even with plain "sudo": $ sudo keyctl get_persistent @s 0 Anyway, any opinions on this particular patch? I'd prefer to get it in soon and file enhancement ticket for the login terminal detection, if needed. Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel