All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: Sage Weil <sweil@redhat.com>, ceph-devel@vger.kernel.org
Cc: branto@redhat.com
Subject: Re: wip-user status
Date: Wed, 5 Aug 2015 09:21:51 +0200	[thread overview]
Message-ID: <55C1B98F.2020807@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1508041335370.22099@cobra.newdream.net>

On 08/04/2015 10:53 PM, Sage Weil wrote:
> I rebased the wip-user patches from wip-selinux-policy onto 
> wip-selinux-policy-no-user + merge to master so that it sits on top of the 
> newly-merged systemd changes.

Great, so if it is build-ready state, I can try it with our virtual cluster install.

> Notes/issues:
> 
>  - ceph-osd-prestart.sh verifies that the osd_data dir is owned by either 
> 'root' or 'ceph' or else it exits with an error.  (Presumably systemd will 
> fail to start the unit in this case.)  It prints a helpful message 
> pointing the user at 'ceph-disk chown ...'.
> 
>  - 'ceph-disk chown ...' is not implemented yet.  Should it take the base 
> device, like activate and prepare?  Or a mounted path?  Or either?

It should be easy to convert device/mountpoint by using findmnt so I would
prefer what is more consistent with the user interface...

IIRC, if the parameter is a base device, what should happen if device is not mounted?
If mount path - then what about other data/journal partitions?

It seems to me that parameter could be base OSD device and chown will simply
handle all its partitions. (So for encrypted OSD it needs to get key to unlock it etc...)

>  - Currently ceph-osd@.service unconditionally passes --setuser ceph to 
> ceph-osd... even if the data directory is owned by root.  I don't think 
> systemd is smart enough to do this conditionally unless we make an ugly 
> wrapper script that starts ceph-osd.  Alternatively, we could make 
> ceph-osd conditionally do the setuid based on the ownership of the 
> directory, but... meh.  The idea was to do the setuid *very* early in the 
> startup process so that logging and so on are opened as the ceph user.  
> Ideas?

Well, systemd could do that if the service is generated (like e.g. cryptsetup
activation jobs are generated according to crypttab). But this adds complexity
that we do not need...

Maybe another option is to use environment variable (CEPH_USER or so), set it
in service Environment=/EnvironmentFile... and ceph-osd will use that...

But I think some systemd gurus will find something better here:)

Thanks,
Milan


  reply	other threads:[~2015-08-05  7:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04 20:53 wip-user status Sage Weil
2015-08-05  7:21 ` Milan Broz [this message]
2015-08-06 14:24   ` Sage Weil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C1B98F.2020807@redhat.com \
    --to=mbroz@redhat.com \
    --cc=branto@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sweil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.