On Thu, Jan 24, 2019 at 4:13 PM mlausch <manuel.lausch@xxxxxxxx> wrote:
>
>
>
> Am 24.01.19 um 22:02 schrieb Alfredo Deza:
> >>
> >> Ok with a new empty journal the OSD will not start. I have now rescued
> >> the data with dd and the recrypt it with a other key and copied the
> >> data back. This worked so far
> >>
> >> Now I encoded the key with base64 and put it to the key-value store.
> >> Also created the neccessary authkeys. Creating the json File by hand
> >> was quiet easy.
> >>
> >> But now there is one problem.
> >> ceph-disk opens the crypt like
> >> cryptsetup --key-file /etc/ceph/dmcrypt-keys/foobar ...
> >> ceph-volume pipes the key via stdin like this
> >> cat foobar | cryptsetup --key-file - ...
> >>
> >> The big problem. if the key is given via stdin cryptsetup hashes this
> >> key per default with some hash. Only if I set --hash plain it works. I
> >> think this is a bug in ceph-volume.
> >>
> >> Can someone confirm this?
> >
> > Ah right, this is when it was supported to have keys in a file.
> >
> > What type of keys do you have: LUKS or plain?
>
> I have both, plain and luks.
> At the moment I played around with the plain dmcrypt OSDs and run into
> this problem. I didn't test the luks crypted OSDs.
There is support in the JSON file to define the type of encryption with the key:
encryption_type
If this is undefined it will default to 'plain'. So that tells me that
we may indeed have a problem here. I'm not sure
what might be needed here, but I do recall having some trouble trying
to understand what ceph-disk was doing. That is
capture in this comment
https://github.com/ceph/ceph/blob/v12.2.10/src/ceph-volume/ceph_volume/devices/simple/activate.py#L150-L155
Do you think that might be related?
>
>
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
