On 2012. July 9. 09:33:22 Sage Weil wrote:
> On Mon, 9 Jul 2012, Székelyi Szabolcs wrote:
> > this far I accessed my Ceph (0.48) FS with the client.admin key, but I'd
> > like to change that since I don't want to allow clients to control the
> > cluster.
> >
> > I thought I should create a new key, give it some caps (don't exactly know
> > which ones), and distribute it to clients. Here are some things I don't
> > know/understand:
> >
> > * What do the r, w, x, and * caps ("permissions"?) mean on a mon, mds, or
> > osd?
>
> They roughly correspond to read, write, execute. The distinction is
> subtle and poorly specfied for mon caps; just use the documented values
> for now.
Does this mean that what I'm trying to achieve is not possible at the moment?
I'd like to give access to my clients to the data in the filesystem, but not
control over the cluster. My thought was that removing some mon caps from the
clients' keys will get me there. But from what you write, it looks to me like
if a client can access the data in the filesystem, it can also (for example)
bring the cluster down...
> The problem is that the mount.ceph command doesn't understand keyrings; it
> only understands secret= and secretfile=. There is a longstanding feature
> bug open for this
>
> http://tracker.newdream.net/issues/266
>
> but it hasn't been prioritized. Sorry for the confusion! It will happen
> soon.
>
> In the meantime, you need
>
> -o secretfile=/path/to/secretfile,name=access_fs
Is this also true for the FUSE client? I have obscure memories about big
differences between the kernel and the FUSE client, for example the latter
being able to read ceph.conf, and get the necessary info, including the
keyring file, from there. Maybe I didn't emphasize it, but that's what I'm
using.
Thanks,
--
cc
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
