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.
--
/ Alexander Bokovoy
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
