enabling cephx by default

enabling cephx by default

[Sage Weil]

The next stable release will have cephx authentication enabled by default.  
We will probably do it in the next development release (v0.53) to work out 
any upgrade kinks well before that.  The process for setting up teh 
authentication keys on an existing cluster is at

	http://ceph.com/docs/master/cluster-ops/authentication/

This needs a few eyeballs to make sure the upgrade process makes sense...

Thanks!
sage

Re: enabling cephx by default

[Wido den Hollander]

On 09/12/2012 02:25 AM, Sage Weil wrote:
> The next stable release will have cephx authentication enabled by default.
> We will probably do it in the next development release (v0.53) to work out
> any upgrade kinks well before that.  The process for setting up teh
> authentication keys on an existing cluster is at
>
> 	http://ceph.com/docs/master/cluster-ops/authentication/
>
> This needs a few eyeballs to make sure the upgrade process makes sense...
>

"Generate a secret key for every OSD, where {$id} is the OSD number:"

Where does {$id} come from? I know it's just a variable which the users 
needs to fill in, but it could be somewhat confusing.

You could do:

for id in {0..10}; do
ceph auth get-or-create osd.${id} mon 'allow rwx' osd 'allow *' -o 
/var/lib/ceph/osd/ceph-${id}/keyring;
done

I know this doesn't work for the mds which uses alpha-numeric names, but 
imho the {$id} variable seems to come from nowhere.

Maybe an example to make it more clear, because later in the page $id is 
used without the brackets ( { & } )


Later on, this command won't work:
$ sudo ceph auth get-or-create client.admin mds 'allow' osd 'allow *' 
mon 'allow *' > /etc/ceph/keyring

The "ceph" command gets executed as root, but the output won't, so 
writing to /etc/ceph/keyring will fail.

We could assume everybody executes these commands as root, but it might 
be somewhat confusing if one command has "sudo" prefixed and other 
don't. That might suggest it's somewhat special.

The same goes for a couple of commands after the one mentioned above.

I haven't tested the upgrade itself, but this is what I noticed while 
reading the docs.

Wido


> Thanks!
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: enabling cephx by default

[Guido Winkelmann]

Am Dienstag, 11. September 2012, 17:25:49 schrieben Sie:
> The next stable release will have cephx authentication enabled by default.

Hm, that could be a problem for me. I have tried multiple times to get cephx 
working in the past, without lasting success. (I cannot recall at the moment 
what the problem was the last time around, but it was probably qemu/libvirt.)

IMHO, the documentation badly needs a high-level overview for cephx (or maybe 
I just haven't found it yet); what it does, what dangers it protects you from 
and how it achieves that.

        Guido

Re: enabling cephx by default

[Andrey Korolyov]

On Tue, Sep 18, 2012 at 4:37 PM, Guido Winkelmann
<guido-ceph@thisisnotatest.de> wrote:
> Am Dienstag, 11. September 2012, 17:25:49 schrieben Sie:
>> The next stable release will have cephx authentication enabled by default.
>
> Hm, that could be a problem for me. I have tried multiple times to get cephx
> working in the past, without lasting success. (I cannot recall at the moment
> what the problem was the last time around, but it was probably qemu/libvirt.)

BTW, libvirt 0.10.x has a broken cephx support somehow. It forms same
string for -drive as 0.9x(at least in a log) but failing to pass
authentication same moment.

>
> IMHO, the documentation badly needs a high-level overview for cephx (or maybe
> I just haven't found it yet); what it does, what dangers it protects you from
> and how it achieves that.
>
>         Guido
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: enabling cephx by default

[Andrey Korolyov]

On Tue, Sep 18, 2012 at 5:34 PM, Andrey Korolyov <andrey@xdel.ru> wrote:
> On Tue, Sep 18, 2012 at 4:37 PM, Guido Winkelmann
> <guido-ceph@thisisnotatest.de> wrote:
>> Am Dienstag, 11. September 2012, 17:25:49 schrieben Sie:
>>> The next stable release will have cephx authentication enabled by default.
>>
>> Hm, that could be a problem for me. I have tried multiple times to get cephx
>> working in the past, without lasting success. (I cannot recall at the moment
>> what the problem was the last time around, but it was probably qemu/libvirt.)
>
> BTW, libvirt 0.10.x has a broken cephx support somehow. It forms same
> string for -drive as 0.9x(at least in a log) but failing to pass
> authentication same moment.
>
Please nevermind, I have build incorrect regex for log parsing previously.
https://www.redhat.com/archives/libvirt-users/2012-September/msg00082.html
>>
>> IMHO, the documentation badly needs a high-level overview for cephx (or maybe
>> I just haven't found it yet); what it does, what dangers it protects you from
>> and how it achieves that.
>>
>>         Guido
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: enabling cephx by default

[Wido den Hollander]

On 18-09-12 15:54, Andrey Korolyov wrote:
> On Tue, Sep 18, 2012 at 5:34 PM, Andrey Korolyov <andrey@xdel.ru> wrote:
>> On Tue, Sep 18, 2012 at 4:37 PM, Guido Winkelmann
>> <guido-ceph@thisisnotatest.de> wrote:
>>> Am Dienstag, 11. September 2012, 17:25:49 schrieben Sie:
>>>> The next stable release will have cephx authentication enabled by default.
>>>
>>> Hm, that could be a problem for me. I have tried multiple times to get cephx
>>> working in the past, without lasting success. (I cannot recall at the moment
>>> what the problem was the last time around, but it was probably qemu/libvirt.)
>>
>> BTW, libvirt 0.10.x has a broken cephx support somehow. It forms same
>> string for -drive as 0.9x(at least in a log) but failing to pass
>> authentication same moment.
>>
> Please nevermind, I have build incorrect regex for log parsing previously.
> https://www.redhat.com/archives/libvirt-users/2012-September/msg00082.html
>>>

Hmmm, did I break that? With this commit: 
http://www.libvirt.org/git/?p=libvirt.git;a=commitdiff;h=ccb94785007d33365d49dd566e194eb0a022148d

The full code can be found here: 
http://www.libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_command.c;h=94b2919f52d52c14e364aac44fe130e9dbaf97ae;hb=ccb94785007d33365d49dd566e194eb0a022148d#l1733

The commit above only adds a else statement where it adds 
auth_supported=none when disk->username was not set.

Wido

>>> IMHO, the documentation badly needs a high-level overview for cephx (or maybe
>>> I just haven't found it yet); what it does, what dangers it protects you from
>>> and how it achieves that.
>>>
>>>          Guido
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>