Hi Milan- On Thu, 18 Jun 2015, Milan Broz wrote: > On 06/17/2015 06:16 AM, Sage Weil wrote: > >>> The wiki logins are broken, but ignore that.. we're moving to > >>> tracker.ceph.com's wiki shortly anyway. Email is best in the meantime! > >> > >> This proposal seems not have to have it to the new wiki. Is it still > >> alive? What do we need to do to keep this moving? > > I am not able to even login to wiki, seems logins are still completely broken. > Probably nobody can edit it now?
The old wiki is frozen.. see the new wiki at http://tracker.ceph.com/projects/ceph/wiki (not much there yet). Jewel CDS blueprints are at http://tracker.ceph.com/projects/ceph/wiki/Jewel > > I can create a placeholder session. Can you two hash out a proposal over > > the next week or so to discuss? I think there are some tricky questions > > if petera is used if we want it to integrate with the monitors as well > > (e.g., leverage the monitors for updating/distributing the petera > > certs/keys). > > Yes, but later please. We have a lot of fun with selinux and other things, > this feature could follow later. > > BTW Petera is now renamed to Deo (and should be in Fedora packaged already). (Good to hear--petera had bad google mojo.) > The idea was: > > - use LUKS as the encryption format > > - use Deo to map OSD, for more info see > https://github.com/npmccallum/deo > > In short, Deo will connect to MON node and negotiate key and directly > unlock LUKS device. > (New version now uses libcryptsetup direcly, so it is really one client > binary.) > > There must be a service listening on MONs nodes (Deo server). > > I have no idea yet how problematic will be handling certificates here, but > because it ensures authentication and encrypts communication, it seems like > a nice design. I think the ceph-mon piece is that we would need a monitor service that is responsible for storing/distributing the certs/keys. In order to make them visible to Deo, we'd need them to be stored in plaintext in a simple directory structure in /var/lib/ceph/mon/$cluster-$id/ somewhere. If we simply co-opt config-key to do this, or do this for a subset of the config-key namespace, this should be pretty simple. Do you know what the server-side file/directory should look like for Deo? > Anyway, delegating this task to one simple tool (maintained independently > of Ceph) is IMHO a good idea and the whole integration should not be > complicated. > (Moreover it will allow easy integration with FreeIPA and similar tools > later.) Yeah. My assumption is that this is essentially swapping out the bits that use the ceph mons to install keys? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
