Re: [Ceph-maintainers] statically allocated uid/gid for ceph

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

+ceph-devel

On Wed, 10 Dec 2014, Ken Dreyer wrote:
> On 12/06/2014 01:54 PM, Sage Weil wrote:
> > Hi Colin, Boris, Owen,
> > 
> > We would like to choose a statically allocated uid and gid for use by Ceph 
> > storage servers.  The basic goals are:
> > 
> >  - run daemons as non-root (right now everything is uid 0 (runtime and 
> > on-disk data) and this is clearly not ideal)
> >  - enable hot swap of disks between storage servers
> >  - standardize across distros so that we can build clusters with a mix
> > 
> > To support the hot swap, we can't use the usual uids allocated dynamically 
> > during package installation.  Disks will completely filled with Ceph data 
> > files with the uid from one machine and will not be usable on another 
> > machine.
> > 
> > I'm hoping we can choose a static uid/gid pair that is unused for Debian 
> > (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
> > us maintain consistency across the entire ecosystem.
> 
> How many system users should I request from the Fedora Packaging
> Committee, and what should their names be?
> 
> For example, are ceph-mon and ceph-osd going to run under the same
> non-privileged system account?

Hmm, my first impulse was to make a single user and group.  But it might 
make sense that e.g. rgw should run in a different context than ceph-osd 
or ceph-mon.

If we go down that road, then maybe

 ceph-osd
 ceph-mon
 ceph-mds
 ceph-rgw
 ceph-calamari

and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
and other librados users?

Alternatively, if we just do user+group ceph, then rgw can run as www-data 
or apache (as it does now).  Not sure what makes the most sense for 
ceph-calamari.

sage

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 12/11/2014 05:48 AM, Sage Weil wrote:
> +ceph-devel
> 
> On Wed, 10 Dec 2014, Ken Dreyer wrote:
>> On 12/06/2014 01:54 PM, Sage Weil wrote:
>>> Hi Colin, Boris, Owen,
>>>
>>> We would like to choose a statically allocated uid and gid for use by Ceph 
>>> storage servers.  The basic goals are:
>>>
>>>  - run daemons as non-root (right now everything is uid 0 (runtime and 
>>> on-disk data) and this is clearly not ideal)
>>>  - enable hot swap of disks between storage servers
>>>  - standardize across distros so that we can build clusters with a mix
>>>
>>> To support the hot swap, we can't use the usual uids allocated dynamically 
>>> during package installation.  Disks will completely filled with Ceph data 
>>> files with the uid from one machine and will not be usable on another 
>>> machine.
>>>
>>> I'm hoping we can choose a static uid/gid pair that is unused for Debian 
>>> (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
>>> us maintain consistency across the entire ecosystem.
>>
>> How many system users should I request from the Fedora Packaging
>> Committee, and what should their names be?
>>
>> For example, are ceph-mon and ceph-osd going to run under the same
>> non-privileged system account?
> 
> Hmm, my first impulse was to make a single user and group.  But it might 
> make sense that e.g. rgw should run in a different context than ceph-osd 
> or ceph-mon.
> 
> If we go down that road, then maybe
> 
>  ceph-osd
>  ceph-mon
>  ceph-mds
>  ceph-rgw
>  ceph-calamari
> 
> and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
> and other librados users?
> 
> Alternatively, if we just do user+group ceph, then rgw can run as www-data 
> or apache (as it does now).  Not sure what makes the most sense for 
> ceph-calamari.

FWIW my gut says go with a single ceph user+group and leave rgw running
as the apache user.

Calamari consists of a few pieces - the web-accessible bit runs as the
apache user, then there's the cthulhu daemon, as well as carbon-cache
for the graphite stuff.  These latter two I believe run as root (at
least, they do with my SUSE packages which have systemd units for each
of these services, and I assume they run as root on other distros where
they're run under supervisord).  Now that I think of it though, I wonder
if it makes sense to just run the whole lot as the apache user...?

Regards,

Tim
-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[John Spray]

On Thu, Dec 11, 2014 at 2:07 AM, Tim Serong <tserong@suse.com> wrote:
> Calamari consists of a few pieces - the web-accessible bit runs as the
> apache user, then there's the cthulhu daemon, as well as carbon-cache
> for the graphite stuff.  These latter two I believe run as root (at
> least, they do with my SUSE packages which have systemd units for each
> of these services, and I assume they run as root on other distros where
> they're run under supervisord).  Now that I think of it though, I wonder
> if it makes sense to just run the whole lot as the apache user...?

It probably doesn't make sense to move all the services under apache:
the in-apache parts (i.e. the REST request handlers) are relatively
unprivileged things that just know how to make calls to other (local)
services, whereas the other services are reaching out over the network
to the Ceph servers.  It might make sense to use a ceph-calamari user
for cthulhu et al, and leave the REST bits running as apache.

As for carbon-cache, that should cease to be a calamari-specific
question when using proper distro packages instead of an embedded
instance (iirc we were still running our own built-in carbon last time
I touched calamari)

Cheers,
John

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

On Thu, 11 Dec 2014, Tim Serong wrote:
> On 12/11/2014 05:48 AM, Sage Weil wrote:
> > +ceph-devel
> > 
> > On Wed, 10 Dec 2014, Ken Dreyer wrote:
> >> On 12/06/2014 01:54 PM, Sage Weil wrote:
> >>> Hi Colin, Boris, Owen,
> >>>
> >>> We would like to choose a statically allocated uid and gid for use by Ceph 
> >>> storage servers.  The basic goals are:
> >>>
> >>>  - run daemons as non-root (right now everything is uid 0 (runtime and 
> >>> on-disk data) and this is clearly not ideal)
> >>>  - enable hot swap of disks between storage servers
> >>>  - standardize across distros so that we can build clusters with a mix
> >>>
> >>> To support the hot swap, we can't use the usual uids allocated dynamically 
> >>> during package installation.  Disks will completely filled with Ceph data 
> >>> files with the uid from one machine and will not be usable on another 
> >>> machine.
> >>>
> >>> I'm hoping we can choose a static uid/gid pair that is unused for Debian 
> >>> (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
> >>> us maintain consistency across the entire ecosystem.
> >>
> >> How many system users should I request from the Fedora Packaging
> >> Committee, and what should their names be?
> >>
> >> For example, are ceph-mon and ceph-osd going to run under the same
> >> non-privileged system account?
> > 
> > Hmm, my first impulse was to make a single user and group.  But it might 
> > make sense that e.g. rgw should run in a different context than ceph-osd 
> > or ceph-mon.
> > 
> > If we go down that road, then maybe
> > 
> >  ceph-osd
> >  ceph-mon
> >  ceph-mds
> >  ceph-rgw
> >  ceph-calamari
> > 
> > and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
> > and other librados users?
> > 
> > Alternatively, if we just do user+group ceph, then rgw can run as www-data 
> > or apache (as it does now).  Not sure what makes the most sense for 
> > ceph-calamari.
> 
> FWIW my gut says go with a single ceph user+group and leave rgw running
> as the apache user.

Someone just tripped over this with hammer's radosgw, which doesn't 
require apache by default (using civetweb)--the apache user didn't 
exist.

It is probably simplest to make radosgw run as 'ceph' too.  This avoids 
all these issues, and will let radosgw log to /var/log/ceph/* too.

sage


> Calamari consists of a few pieces - the web-accessible bit runs as the
> apache user, then there's the cthulhu daemon, as well as carbon-cache
> for the graphite stuff.  These latter two I believe run as root (at
> least, they do with my SUSE packages which have systemd units for each
> of these services, and I assume they run as root on other distros where
> they're run under supervisord).  Now that I think of it though, I wonder
> if it makes sense to just run the whole lot as the apache user...?
> 
> Regards,
> 
> Tim
> -- 
> Tim Serong
> Senior Clustering Engineer
> SUSE
> tserong@suse.com
> --
> 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: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

Tim, Owen:

Can we get a 'ceph' user/group uid/gid allocated for SUSE to get this 
unstuck?  IMO the radosgw systemd stuff is blocked behind this too.

I think a osd-prestart.sh snippet (or similar) that does a chown -R of any 
non-root osd data to the local ceph user prior to starting the daemon will 
handle the cross-distro changes without too much trouble.  I'd lean toward 
not going from root -> ceph, though, and have the start script stay root 
and not drop privs if the data is owned by root.. that covers upgrades 
without interruption.

What do you think?

sage



On Thu, 11 Dec 2014, Tim Serong wrote:

> On 12/11/2014 05:48 AM, Sage Weil wrote:
> > +ceph-devel
> > 
> > On Wed, 10 Dec 2014, Ken Dreyer wrote:
> >> On 12/06/2014 01:54 PM, Sage Weil wrote:
> >>> Hi Colin, Boris, Owen,
> >>>
> >>> We would like to choose a statically allocated uid and gid for use by Ceph 
> >>> storage servers.  The basic goals are:
> >>>
> >>>  - run daemons as non-root (right now everything is uid 0 (runtime and 
> >>> on-disk data) and this is clearly not ideal)
> >>>  - enable hot swap of disks between storage servers
> >>>  - standardize across distros so that we can build clusters with a mix
> >>>
> >>> To support the hot swap, we can't use the usual uids allocated dynamically 
> >>> during package installation.  Disks will completely filled with Ceph data 
> >>> files with the uid from one machine and will not be usable on another 
> >>> machine.
> >>>
> >>> I'm hoping we can choose a static uid/gid pair that is unused for Debian 
> >>> (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
> >>> us maintain consistency across the entire ecosystem.
> >>
> >> How many system users should I request from the Fedora Packaging
> >> Committee, and what should their names be?
> >>
> >> For example, are ceph-mon and ceph-osd going to run under the same
> >> non-privileged system account?
> > 
> > Hmm, my first impulse was to make a single user and group.  But it might 
> > make sense that e.g. rgw should run in a different context than ceph-osd 
> > or ceph-mon.
> > 
> > If we go down that road, then maybe
> > 
> >  ceph-osd
> >  ceph-mon
> >  ceph-mds
> >  ceph-rgw
> >  ceph-calamari
> > 
> > and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
> > and other librados users?
> > 
> > Alternatively, if we just do user+group ceph, then rgw can run as www-data 
> > or apache (as it does now).  Not sure what makes the most sense for 
> > ceph-calamari.
> 
> FWIW my gut says go with a single ceph user+group and leave rgw running
> as the apache user.
> 
> Calamari consists of a few pieces - the web-accessible bit runs as the
> apache user, then there's the cthulhu daemon, as well as carbon-cache
> for the graphite stuff.  These latter two I believe run as root (at
> least, they do with my SUSE packages which have systemd units for each
> of these services, and I assume they run as root on other distros where
> they're run under supervisord).  Now that I think of it though, I wonder
> if it makes sense to just run the whole lot as the apache user...?
> 
> Regards,
> 
> Tim
> -- 
> Tim Serong
> Senior Clustering Engineer
> SUSE
> tserong@suse.com
> --
> 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: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 04/14/2015 11:05 AM, Sage Weil wrote:
> Tim, Owen:
> 
> Can we get a 'ceph' user/group uid/gid allocated for SUSE to get this 
> unstuck?  IMO the radosgw systemd stuff is blocked behind this too.

I haven't yet been able to get a good answer to assignment of static
UIDs and GIDs (I was told all the ones between 0-99 are taken already).

But, if it's OK for the UID and GID numbers to potentially be different
on different systems, adding a "ceph" user and "ceph" group is easy, we
just add appropriate `groupadd -r ceph` and `useradd -r ceph`
invocations to the rpm %pre script, which will give a UID/GID somewhere
in the 100-499 range (see
https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
for some notes on this).  We'd also want to update rpmlint to not whine
about the "ceph" name.

I originally thought the risk of non-static UID/GID numbers on different
systems was terrible, but...

> I think a osd-prestart.sh snippet (or similar) that does a chown -R of any 
> non-root osd data to the local ceph user prior to starting the daemon will 
> handle the cross-distro changes without too much trouble.  I'd lean toward 
> not going from root -> ceph, though, and have the start script stay root 
> and not drop privs if the data is owned by root.. that covers upgrades 
> without interruption.
> 
> What do you think?

...that sounds reasonable, and I think it would also handle the case
where, say, you move an OSD from one SUSE host to another - if the
UID/GID doesn't match (maybe some other `useradd`ing software was
installed first on the other host), the chown will fix it anyway.

Are there any holes in this?

Regards,

Tim


> 
> 
> On Thu, 11 Dec 2014, Tim Serong wrote:
> 
>> On 12/11/2014 05:48 AM, Sage Weil wrote:
>>> +ceph-devel
>>>
>>> On Wed, 10 Dec 2014, Ken Dreyer wrote:
>>>> On 12/06/2014 01:54 PM, Sage Weil wrote:
>>>>> Hi Colin, Boris, Owen,
>>>>>
>>>>> We would like to choose a statically allocated uid and gid for use by Ceph 
>>>>> storage servers.  The basic goals are:
>>>>>
>>>>>  - run daemons as non-root (right now everything is uid 0 (runtime and 
>>>>> on-disk data) and this is clearly not ideal)
>>>>>  - enable hot swap of disks between storage servers
>>>>>  - standardize across distros so that we can build clusters with a mix
>>>>>
>>>>> To support the hot swap, we can't use the usual uids allocated dynamically 
>>>>> during package installation.  Disks will completely filled with Ceph data 
>>>>> files with the uid from one machine and will not be usable on another 
>>>>> machine.
>>>>>
>>>>> I'm hoping we can choose a static uid/gid pair that is unused for Debian 
>>>>> (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
>>>>> us maintain consistency across the entire ecosystem.
>>>>
>>>> How many system users should I request from the Fedora Packaging
>>>> Committee, and what should their names be?
>>>>
>>>> For example, are ceph-mon and ceph-osd going to run under the same
>>>> non-privileged system account?
>>>
>>> Hmm, my first impulse was to make a single user and group.  But it might 
>>> make sense that e.g. rgw should run in a different context than ceph-osd 
>>> or ceph-mon.
>>>
>>> If we go down that road, then maybe
>>>
>>>  ceph-osd
>>>  ceph-mon
>>>  ceph-mds
>>>  ceph-rgw
>>>  ceph-calamari
>>>
>>> and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
>>> and other librados users?
>>>
>>> Alternatively, if we just do user+group ceph, then rgw can run as www-data 
>>> or apache (as it does now).  Not sure what makes the most sense for 
>>> ceph-calamari.
>>
>> FWIW my gut says go with a single ceph user+group and leave rgw running
>> as the apache user.
>>
>> Calamari consists of a few pieces - the web-accessible bit runs as the
>> apache user, then there's the cthulhu daemon, as well as carbon-cache
>> for the graphite stuff.  These latter two I believe run as root (at
>> least, they do with my SUSE packages which have systemd units for each
>> of these services, and I assume they run as root on other distros where
>> they're run under supervisord).  Now that I think of it though, I wonder
>> if it makes sense to just run the whole lot as the apache user...?
>>
>> Regards,
>>
>> Tim
>> -- 
>> Tim Serong
>> Senior Clustering Engineer
>> SUSE
>> tserong@suse.com
>> --
>> 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
>>
>>
> 


-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

On Tue, 14 Apr 2015, Tim Serong wrote:
> On 04/14/2015 11:05 AM, Sage Weil wrote:
> > Tim, Owen:
> > 
> > Can we get a 'ceph' user/group uid/gid allocated for SUSE to get this 
> > unstuck?  IMO the radosgw systemd stuff is blocked behind this too.
> 
> I haven't yet been able to get a good answer to assignment of static
> UIDs and GIDs (I was told all the ones between 0-99 are taken already).
> 
> But, if it's OK for the UID and GID numbers to potentially be different
> on different systems, adding a "ceph" user and "ceph" group is easy, we
> just add appropriate `groupadd -r ceph` and `useradd -r ceph`
> invocations to the rpm %pre script, which will give a UID/GID somewhere
> in the 100-499 range (see
> https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
> for some notes on this).  We'd also want to update rpmlint to not whine
> about the "ceph" name.
> 
> I originally thought the risk of non-static UID/GID numbers on different
> systems was terrible, but...

I think we still want them to be static across a distro; it's the 
cross-distro change that will be relatively rare.  So a fixed ID from each 
distro family ought to be okay?

> > I think a osd-prestart.sh snippet (or similar) that does a chown -R of any 
> > non-root osd data to the local ceph user prior to starting the daemon will 
> > handle the cross-distro changes without too much trouble.  I'd lean toward 
> > not going from root -> ceph, though, and have the start script stay root 
> > and not drop privs if the data is owned by root.. that covers upgrades 
> > without interruption.
> > 
> > What do you think?
> 
> ...that sounds reasonable, and I think it would also handle the case
> where, say, you move an OSD from one SUSE host to another - if the
> UID/GID doesn't match (maybe some other `useradd`ing software was
> installed first on the other host), the chown will fix it anyway.
> 
> Are there any holes in this?

It would be nicer if the suse->suse case didn't require a chown, but yeah, 
it'd still work just fine...

sage


> 
> Regards,
> 
> Tim
> 
> 
> > 
> > 
> > On Thu, 11 Dec 2014, Tim Serong wrote:
> > 
> >> On 12/11/2014 05:48 AM, Sage Weil wrote:
> >>> +ceph-devel
> >>>
> >>> On Wed, 10 Dec 2014, Ken Dreyer wrote:
> >>>> On 12/06/2014 01:54 PM, Sage Weil wrote:
> >>>>> Hi Colin, Boris, Owen,
> >>>>>
> >>>>> We would like to choose a statically allocated uid and gid for use by Ceph 
> >>>>> storage servers.  The basic goals are:
> >>>>>
> >>>>>  - run daemons as non-root (right now everything is uid 0 (runtime and 
> >>>>> on-disk data) and this is clearly not ideal)
> >>>>>  - enable hot swap of disks between storage servers
> >>>>>  - standardize across distros so that we can build clusters with a mix
> >>>>>
> >>>>> To support the hot swap, we can't use the usual uids allocated dynamically 
> >>>>> during package installation.  Disks will completely filled with Ceph data 
> >>>>> files with the uid from one machine and will not be usable on another 
> >>>>> machine.
> >>>>>
> >>>>> I'm hoping we can choose a static uid/gid pair that is unused for Debian 
> >>>>> (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
> >>>>> us maintain consistency across the entire ecosystem.
> >>>>
> >>>> How many system users should I request from the Fedora Packaging
> >>>> Committee, and what should their names be?
> >>>>
> >>>> For example, are ceph-mon and ceph-osd going to run under the same
> >>>> non-privileged system account?
> >>>
> >>> Hmm, my first impulse was to make a single user and group.  But it might 
> >>> make sense that e.g. rgw should run in a different context than ceph-osd 
> >>> or ceph-mon.
> >>>
> >>> If we go down that road, then maybe
> >>>
> >>>  ceph-osd
> >>>  ceph-mon
> >>>  ceph-mds
> >>>  ceph-rgw
> >>>  ceph-calamari
> >>>
> >>> and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
> >>> and other librados users?
> >>>
> >>> Alternatively, if we just do user+group ceph, then rgw can run as www-data 
> >>> or apache (as it does now).  Not sure what makes the most sense for 
> >>> ceph-calamari.
> >>
> >> FWIW my gut says go with a single ceph user+group and leave rgw running
> >> as the apache user.
> >>
> >> Calamari consists of a few pieces - the web-accessible bit runs as the
> >> apache user, then there's the cthulhu daemon, as well as carbon-cache
> >> for the graphite stuff.  These latter two I believe run as root (at
> >> least, they do with my SUSE packages which have systemd units for each
> >> of these services, and I assume they run as root on other distros where
> >> they're run under supervisord).  Now that I think of it though, I wonder
> >> if it makes sense to just run the whole lot as the apache user...?
> >>
> >> Regards,
> >>
> >> Tim
> >> -- 
> >> Tim Serong
> >> Senior Clustering Engineer
> >> SUSE
> >> tserong@suse.com
> >> --
> >> 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
> >>
> >>
> > 
> 
> 
> -- 
> Tim Serong
> Senior Clustering Engineer
> SUSE
> tserong@suse.com
> 
> 

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Ken Dreyer]

On 04/14/2015 09:21 AM, Sage Weil wrote:
> I think we still want them to be static across a distro; it's the 
> cross-distro change that will be relatively rare.  So a fixed ID from each 
> distro family ought to be okay?

Sounds sane to me. I've filed https://fedorahosted.org/fpc/ticket/524 to
request one from Fedora.

- Ken

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Gaudenz Steinlin]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


Hi

Ken Dreyer <kdreyer@redhat.com> writes:

> On 04/14/2015 09:21 AM, Sage Weil wrote:
>> I think we still want them to be static across a distro; it's the 
>> cross-distro change that will be relatively rare.  So a fixed ID from each 
>> distro family ought to be okay?
>
> Sounds sane to me. I've filed https://fedorahosted.org/fpc/ticket/524 to
> request one from Fedora.

I have now requested the same for Debian. If the request is granted we
will most likely get the uid/gid 64045. Maybe others could use the same.
It seems that only Debian has a range of reserved ids for this purpose.
I would expect Ubuntu to use the same id, but that's up to them finally.

Gaudenz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 810 bytes --]

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 04/16/2015 03:14 AM, Gaudenz Steinlin wrote:
> 
> Hi
> 
> Ken Dreyer <kdreyer@redhat.com> writes:
> 
>> On 04/14/2015 09:21 AM, Sage Weil wrote:
>>> I think we still want them to be static across a distro; it's the 
>>> cross-distro change that will be relatively rare.  So a fixed ID from each 
>>> distro family ought to be okay?
>>
>> Sounds sane to me. I've filed https://fedorahosted.org/fpc/ticket/524 to
>> request one from Fedora.
> 
> I have now requested the same for Debian. If the request is granted we
> will most likely get the uid/gid 64045. Maybe others could use the same.
> It seems that only Debian has a range of reserved ids for this purpose.
> I would expect Ubuntu to use the same id, but that's up to them finally.

Fedora has rejected the request for a static UID (see
https://fedorahosted.org/fpc/ticket/524#comment:16), and I haven't made
much progress on the SUSE front.  I did suggest everyone just do what
Debian does ;) but both Fedora and SUSE people pointed out that the 64K
range isn't safe to claim, what with not being specifically reserved.

I did make one small bit of progress - I've added the ceph user and
group to rpmlint on openSUSE Factory
(https://build.opensuse.org/request/show/303537) so at least the SUSE
build won't bitch if files specified in any of the packages are owned by
ceph:ceph.

Regards,

Tim
-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com

RE: [Ceph-maintainers] statically allocated uid/gid for ceph

[HEWLETT, Paul (Paul)** CTR **]

What about making it configurable in ceph.conf or /etc/sysconfig/ceph? (or via PAM/ldap...)

That way individual users could make it a value that they know does not conflict and they will still be able to
move OSDs between nodes etc...

Paul Hewlett
Senior Systems Engineer
Velocix, Cambridge
Alcatel-Lucent
t: +44 1223 435893



________________________________________
From: ceph-devel-owner@vger.kernel.org [ceph-devel-owner@vger.kernel.org] on behalf of Tim Serong [tserong@suse.com]
Sent: 27 April 2015 10:56
To: Gaudenz Steinlin; Ken Dreyer; Sage Weil
Cc: ceph-devel@vger.kernel.org; cjwatson@debian.org; ceph-maintainers@ceph.com; timm@fnal.gov; Owen Synge
Subject: Re: [Ceph-maintainers] statically allocated uid/gid for ceph

On 04/16/2015 03:14 AM, Gaudenz Steinlin wrote:
>
> Hi
>
> Ken Dreyer <kdreyer@redhat.com> writes:
>
>> On 04/14/2015 09:21 AM, Sage Weil wrote:
>>> I think we still want them to be static across a distro; it's the
>>> cross-distro change that will be relatively rare.  So a fixed ID from each
>>> distro family ought to be okay?
>>
>> Sounds sane to me. I've filed https://fedorahosted.org/fpc/ticket/524 to
>> request one from Fedora.
>
> I have now requested the same for Debian. If the request is granted we
> will most likely get the uid/gid 64045. Maybe others could use the same.
> It seems that only Debian has a range of reserved ids for this purpose.
> I would expect Ubuntu to use the same id, but that's up to them finally.

Fedora has rejected the request for a static UID (see
https://fedorahosted.org/fpc/ticket/524#comment:16), and I haven't made
much progress on the SUSE front.  I did suggest everyone just do what
Debian does ;) but both Fedora and SUSE people pointed out that the 64K
range isn't safe to claim, what with not being specifically reserved.

I did make one small bit of progress - I've added the ceph user and
group to rpmlint on openSUSE Factory
(https://build.opensuse.org/request/show/303537) so at least the SUSE
build won't bitch if files specified in any of the packages are owned by
ceph:ceph.

Regards,

Tim
--
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com
--
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: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 04/27/2015 09:29 PM, HEWLETT, Paul (Paul)** CTR ** wrote:
> What about making it configurable in ceph.conf or /etc/sysconfig/ceph? (or via PAM/ldap...)
> 
> That way individual users could make it a value that they know does not conflict and they will still be able to
> move OSDs between nodes etc...

IMO that's a bit chicken-and-eggy -- you really want the package to
create the user and group early during install (%pre in an rpm), so
that, say, log file directories and whatnot potentially owned by the
package can be installed with the correct ownership.

Regards,

Tim

> 
> Paul Hewlett
> Senior Systems Engineer
> Velocix, Cambridge
> Alcatel-Lucent
> t: +44 1223 435893
> 
> 
> 
> ________________________________________
> From: ceph-devel-owner@vger.kernel.org [ceph-devel-owner@vger.kernel.org] on behalf of Tim Serong [tserong@suse.com]
> Sent: 27 April 2015 10:56
> To: Gaudenz Steinlin; Ken Dreyer; Sage Weil
> Cc: ceph-devel@vger.kernel.org; cjwatson@debian.org; ceph-maintainers@ceph.com; timm@fnal.gov; Owen Synge
> Subject: Re: [Ceph-maintainers] statically allocated uid/gid for ceph
> 
> On 04/16/2015 03:14 AM, Gaudenz Steinlin wrote:
>>
>> Hi
>>
>> Ken Dreyer <kdreyer@redhat.com> writes:
>>
>>> On 04/14/2015 09:21 AM, Sage Weil wrote:
>>>> I think we still want them to be static across a distro; it's the
>>>> cross-distro change that will be relatively rare.  So a fixed ID from each
>>>> distro family ought to be okay?
>>>
>>> Sounds sane to me. I've filed https://fedorahosted.org/fpc/ticket/524 to
>>> request one from Fedora.
>>
>> I have now requested the same for Debian. If the request is granted we
>> will most likely get the uid/gid 64045. Maybe others could use the same.
>> It seems that only Debian has a range of reserved ids for this purpose.
>> I would expect Ubuntu to use the same id, but that's up to them finally.
> 
> Fedora has rejected the request for a static UID (see
> https://fedorahosted.org/fpc/ticket/524#comment:16), and I haven't made
> much progress on the SUSE front.  I did suggest everyone just do what
> Debian does ;) but both Fedora and SUSE people pointed out that the 64K
> range isn't safe to claim, what with not being specifically reserved.
> 
> I did make one small bit of progress - I've added the ceph user and
> group to rpmlint on openSUSE Factory
> (https://build.opensuse.org/request/show/303537) so at least the SUSE
> build won't bitch if files specified in any of the packages are owned by
> ceph:ceph.
> 
> Regards,
> 
> Tim
> --
> Tim Serong
> Senior Clustering Engineer
> SUSE
> tserong@suse.com
> --
> 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
> 


-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

On Mon, 27 Apr 2015, Tim Serong wrote:
> On 04/16/2015 03:14 AM, Gaudenz Steinlin wrote:
> > 
> > Hi
> > 
> > Ken Dreyer <kdreyer@redhat.com> writes:
> > 
> >> On 04/14/2015 09:21 AM, Sage Weil wrote:
> >>> I think we still want them to be static across a distro; it's the 
> >>> cross-distro change that will be relatively rare.  So a fixed ID from each 
> >>> distro family ought to be okay?
> >>
> >> Sounds sane to me. I've filed https://fedorahosted.org/fpc/ticket/524 to
> >> request one from Fedora.
> > 
> > I have now requested the same for Debian. If the request is granted we
> > will most likely get the uid/gid 64045. Maybe others could use the same.
> > It seems that only Debian has a range of reserved ids for this purpose.
> > I would expect Ubuntu to use the same id, but that's up to them finally.
> 
> Fedora has rejected the request for a static UID (see
> https://fedorahosted.org/fpc/ticket/524#comment:16), and I haven't made

Gah!  It looks like they were confusing the cross-distro issue.  I'll go 
beg that they reconsider.  :(

> much progress on the SUSE front.  I did suggest everyone just do what
> Debian does ;) but both Fedora and SUSE people pointed out that the 64K
> range isn't safe to claim, what with not being specifically reserved.
> 
> I did make one small bit of progress - I've added the ceph user and
> group to rpmlint on openSUSE Factory
> (https://build.opensuse.org/request/show/303537) so at least the SUSE
> build won't bitch if files specified in any of the packages are owned by
> ceph:ceph.

Thanks!
sage

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 04/28/2015 02:02 AM, Sage Weil wrote:
>> much progress on the SUSE front.  I did suggest everyone just do what
>> Debian does ;) but both Fedora and SUSE people pointed out that the 64K
>> range isn't safe to claim, what with not being specifically reserved.
>>
>> I did make one small bit of progress - I've added the ceph user and
>> group to rpmlint on openSUSE Factory
>> (https://build.opensuse.org/request/show/303537) so at least the SUSE
>> build won't bitch if files specified in any of the packages are owned by
>> ceph:ceph.

It is my sad duty to report that I've been unable to get a static
UID/GID allocated for SLES or openSUSE.

TL;DR:

* There's nothing free in the reserved static range 0-99.
* We can't take something from the unreserved ranges (500-999,
60001-64K) and hope for the best due to potential conflicts with old
systems, LDAP users on those ranges, customers, etc. etc.

Consequently I would like to propose the following as a least-worst
fallback/workaround:

1) Add functionality to ceph-deploy to create the user and group during
`ceph-deploy install`.  This would happen iff new (optional) --ceph-uid
and --ceph-gid arguments[1] were passed to `ceph-deploy install`, and
would happen before any ceph packages are installed.  This would allow
individual sites to choose the UID/GID so they know it doesn't conflict
with anything already in use.

2) Add a guard to the %pre script in the RPM so it only invokes `useradd
and `groupadd` if the ceph user and group don't already exist.

If the UID and GID aren't specified during `ceph-deploy install`, then
it'll fall back to "next available" in the system range when
useradd/groupadd are invoked in the rpm %pre script.

The above should have no impact on other distros where a fixed UID/GID
is already set in the package.

Does this sound viable?

Regards,

Tim

[1] Or, possibly, it should force both UID and GID to the same number,
meaning we only need one argument, say --ceph-uidgid?
-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Ken Dreyer]

On 05/14/2015 06:16 AM, Tim Serong wrote:
> The above should have no impact on other distros where a fixed UID/GID
> is already set in the package.
> 
> Does this sound viable?

This plan sounds fine to me.

- Ken

> [1] Or, possibly, it should force both UID and GID to the same number,
> meaning we only need one argument, say --ceph-uidgid?

Sure, sounds good.

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

On Thu, 14 May 2015, Tim Serong wrote:
> On 04/28/2015 02:02 AM, Sage Weil wrote:
> >> much progress on the SUSE front.  I did suggest everyone just do what
> >> Debian does ;) but both Fedora and SUSE people pointed out that the 64K
> >> range isn't safe to claim, what with not being specifically reserved.
> >>
> >> I did make one small bit of progress - I've added the ceph user and
> >> group to rpmlint on openSUSE Factory
> >> (https://build.opensuse.org/request/show/303537) so at least the SUSE
> >> build won't bitch if files specified in any of the packages are owned by
> >> ceph:ceph.
> 
> It is my sad duty to report that I've been unable to get a static
> UID/GID allocated for SLES or openSUSE.

Too bad!  :(

> * There's nothing free in the reserved static range 0-99.
> * We can't take something from the unreserved ranges (500-999,
> 60001-64K) and hope for the best due to potential conflicts with old
> systems, LDAP users on those ranges, customers, etc. etc.

Just out of curiousity, what is 100-499?

> Consequently I would like to propose the following as a least-worst
> fallback/workaround:
> 
> 1) Add functionality to ceph-deploy to create the user and group during
> `ceph-deploy install`.  This would happen iff new (optional) --ceph-uid
> and --ceph-gid arguments[1] were passed to `ceph-deploy install`, and
> would happen before any ceph packages are installed.  This would allow
> individual sites to choose the UID/GID so they know it doesn't conflict
> with anything already in use.
> 
> 2) Add a guard to the %pre script in the RPM so it only invokes `useradd
> and `groupadd` if the ceph user and group don't already exist.
> 
> If the UID and GID aren't specified during `ceph-deploy install`, then
> it'll fall back to "next available" in the system range when
> useradd/groupadd are invoked in the rpm %pre script.
> 
> The above should have no impact on other distros where a fixed UID/GID
> is already set in the package.

This sounds pretty reasonable to me!  Perhaps there can be a 'default' 
(but still opt-in) uid that is reserved and won't conflict going forward, 
but may conflict with legacy environments?  That at least minimizes 
complexity/pain for fresh environments (which I suspect will 
be the bulk of the install base)?

> [1] Or, possibly, it should force both UID and GID to the same number,
> meaning we only need one argument, say --ceph-uidgid?

+1

sage

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Robert LeBlanc]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

blagh HTML....

- ----------------
Robert LeBlanc
GPG Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1

On Thu, May 14, 2015 at 10:19 AM, Robert LeBlanc  wrote:
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, May 14, 2015 at 10:08 AM, Sage Weil  wrote:
> The above should have no impact on other distros where a fixed UID/GID
> is already set in the package.

This sounds pretty reasonable to me!  Perhaps there can be a 'default'
(but still opt-in) uid that is reserved and won't conflict going forward,
but may conflict with legacy environments?  That at least minimizes
complexity/pain for fresh environments (which I suspect will
be the bulk of the install base)?


Since there is no guarantee, can we just default to the same UID/GID
that was received from Debian, or is there a known conflict in
RH/Cent/SUSE/etc?

 ----------------
Robert LeBlanc
GPG Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1

- -----BEGIN PGP SIGNATURE-----
Version: Mailvelope v0.13.1
Comment: https://www.mailvelope.com

wsFcBAEBCAAQBQJVVMr7CRDmVDuy+mK58QAAZtoQAL0geoqctooRrc+UaKLN
FbpfPRzF7wRyPbrwFJZV1jqJC1e4n1wVI/tRCaTNKOrlE/7e7AiEwPczwjD7
OLKXU1FJ/HNDXM5W0dbfBL8eauHziHo0ufK+odSAIuy+Tx21/Ll4+7FvrCj+
14pJ3wsNn4FHyDD7UpdJwYc+fK0QdqPrKzv8TJXxSE5RLNcRlem2FZxZn0MV
2xFaDdFDbBMZCTFM88wgU4ZewEIsJ12+nCHD8MgIIOrXSarK3sE1cIf0ihtu
WLD1hksOQtNGU2D3vSxYFYsFHIgwS/Cx/FuXggFmLQcK5FABlIS+UqveyY+e
lAcmkhA1auAcm0p1dp4GevKnfx5CxfcSGUEc7SQEa37/sNjplRTRPDGa/Pwg
8u989hTwf6acoCMhEp7P9i3MApeAEgYcQrd8fF5fK7nLr+hRbgLBoUWqm7pj
Ji3uVm3qFAjWQLBoeyVD0XfETU733CShAEWSP4pKsvfl7DNny/IBcGVM1j5g
+kf1BKP8QSPOGtR2dUZQIfjg0gUUuRaUU/JHItGUdua6XygcIf/g9RB+6pBx
SbSbMyKEjl+K+NhUcD6DavtrG4+sC4WTOdtqzxRZvnxQ09LlBLUWh4UMkjgd
L2j8C9z7dHgvL/ifR73plPSqL+RDiuLCthjjjGIj+DATbB5RlPQO+501AAyH
bwk1
=4CmY
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v0.13.1
Comment: https://www.mailvelope.com

wsFcBAEBCAAQBQJVVMtXCRDmVDuy+mK58QAANCAP/i58Tb1zbtP6ZblgxTKV
N7cXLTNZAoVvSdMWj9VcP//2Ha9CMFV/Qu9GrVdeOJkDfcvn2T6Hx6UU0l6P
5cvRD6LDG+g8JFuh2kGZksarBBq47/Leg7Z57OQcQGh/59sIkmj7LiXzguZo
r9lB9F19j5Ejy91ztF2Ai+VHV7hEN+qRY/UQjCnL/PfyGzBgsL3emMg7NHde
stDyzRVIKDKbwELYPYaTn1vNYq7NAY9F5ziuDd5LDKdma61UtBloPmVtxaiN
WaycGVey3FlB0CeQKwqee0ZhkC2YhqhK0LjyTB3NhlLSHTEhiSjRIUMZeKX1
9H99HcYS6GjI9WBJ3MudznwPkkIwqzN4BKkgbcyYql/NNU0jzCHDNQ8lnbCa
+wCaKXQl4rLhrdQTRnFramVPuO6vPpUp85HsNA+xKrddFBBU+/RU6tK4OTgv
5XoYMVc8+aaZd1k62fjCafGs/B7a9QnYtU5GFOo67p7UnsZ2ISGKEv3fnR+E
eeXQ+2AKdjKB1f9XZcG6JLrY10ddwNmjz0dDNNxTo+Dd427hpspQaf1WRDyx
Lb1Qq4O+xx8bNbzPZHcSlNPq6tdCJKri7ZC8vCU3aXLXMKvTk5fRrA56qTkk
SsaOYqpYk9gbYj2bQeLjIY+lFrrsm1/NqzvXIHfX7BYbTiYKKl5ncDeDAjTq
sk6v
=cY5H
-----END PGP SIGNATURE-----

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1324 bytes --]

On Thu, 14 May 2015, Robert LeBlanc wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On Thu, May 14, 2015 at 10:08 AM, Sage Weil  wrote:
> > The above should have no impact on other distros where a fixed UID/GID
> > is already set in the package.
> 
> This sounds pretty reasonable to me!  Perhaps there can be a 'default'
> (but still opt-in) uid that is reserved and won't conflict going forward,
> but may conflict with legacy environments?  That at least minimizes
> complexity/pain for fresh environments (which I suspect will
> be the bulk of the install base)?
> 
> 
> Since there is no guarantee, can we just default to the same UID/GID that wa
> s received from Debian, or is there a known conflict in RH/Cent/SUSE/etc?

The Fedora UID is 167.
  - fedora: 0-200 = fixed allocations
  - debian: 100-999 = dynamically allocated
  - suse: 100-499 = dyamically allocated system users

The Debian UID is likely to be 64045.
  - fedora: undefined (1000-60000 = user accounts, nothing above that)
  - debian: 60000-64999 = reserved fixed uids, dynamically created
  - suse: undefined (1000-60000 = user accounts, nothing above that)

I'm not sure which is less likely: colliding with a dynamically allocated 
system user (how many of those are there?) or a regular user (64045 is a 
very large uid).

sage

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 05/15/2015 02:41 AM, Sage Weil wrote:
> On Thu, 14 May 2015, Robert LeBlanc wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On Thu, May 14, 2015 at 10:08 AM, Sage Weil  wrote:
>>> The above should have no impact on other distros where a fixed UID/GID
>>> is already set in the package.
>>
>> This sounds pretty reasonable to me!  Perhaps there can be a 'default'
>> (but still opt-in) uid that is reserved and won't conflict going forward,
>> but may conflict with legacy environments?  That at least minimizes
>> complexity/pain for fresh environments (which I suspect will
>> be the bulk of the install base)?
>>
>>
>> Since there is no guarantee, can we just default to the same UID/GID that wa
>> s received from Debian, or is there a known conflict in RH/Cent/SUSE/etc?
> 
> The Fedora UID is 167.
>   - fedora: 0-200 = fixed allocations
>   - debian: 100-999 = dynamically allocated
>   - suse: 100-499 = dyamically allocated system users
> 
> The Debian UID is likely to be 64045.
>   - fedora: undefined (1000-60000 = user accounts, nothing above that)
>   - debian: 60000-64999 = reserved fixed uids, dynamically created
>   - suse: undefined (1000-60000 = user accounts, nothing above that)
> 
> I'm not sure which is less likely: colliding with a dynamically allocated 
> system user (how many of those are there?)

Some random data: my openSUSE desktop system has about 35 dynamically
allocated system users.  Looking at my mostly-clean SLE 11 and SLE 12
test sytems, each seems to have about 10 dynamically allocated users,
although interestingly SLE 11 starts adding these from 100, and
increments, while SLE 12 seems to start at 499 and go backwards.

> or a regular user (64045 is a very large uid).

My earlier thought was "everyone should follow Debian because it's a
very large UID", but this is still risky because high ranges can
conflict with UID ranges chosen when using an LDAP, AD or other backend.
 I can't state a specific conflict, just that there are sites whose
chosen user UID ranges overlap.  This is actually a real issue; there
are sites that have all systems (i.e.: even their servers) running such
backends, because they need users, even the sysadmins, to log in as a
regular user using that backend (then `sudo` or whatever for admin work)
due to auditing/security policies.

Regards,

Tim
-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Colin Watson]

On Wed, Apr 15, 2015 at 07:14:35PM +0200, Gaudenz Steinlin wrote:
> I have now requested the same for Debian. If the request is granted we
> will most likely get the uid/gid 64045.

Indeed so, and done.

> It seems that only Debian has a range of reserved ids for this purpose.
> I would expect Ubuntu to use the same id, but that's up to them finally.

(Switching hats:) Debian's base-passwd allocations are authoritative for
Ubuntu too.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]

Re: [Ceph-maintainers] statically allocated uid/gid for ceph

[Tim Serong]

On 04/15/2015 01:21 AM, Sage Weil wrote:
> On Tue, 14 Apr 2015, Tim Serong wrote:
>> On 04/14/2015 11:05 AM, Sage Weil wrote:
>>> Tim, Owen:
>>>
>>> Can we get a 'ceph' user/group uid/gid allocated for SUSE to get this 
>>> unstuck?  IMO the radosgw systemd stuff is blocked behind this too.
>>
>> I haven't yet been able to get a good answer to assignment of static
>> UIDs and GIDs (I was told all the ones between 0-99 are taken already).
>>
>> But, if it's OK for the UID and GID numbers to potentially be different
>> on different systems, adding a "ceph" user and "ceph" group is easy, we
>> just add appropriate `groupadd -r ceph` and `useradd -r ceph`
>> invocations to the rpm %pre script, which will give a UID/GID somewhere
>> in the 100-499 range (see
>> https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups
>> for some notes on this).  We'd also want to update rpmlint to not whine
>> about the "ceph" name.
>>
>> I originally thought the risk of non-static UID/GID numbers on different
>> systems was terrible, but...
> 
> I think we still want them to be static across a distro; it's the 
> cross-distro change that will be relatively rare.  So a fixed ID from each 
> distro family ought to be okay?

Optimally, yes, I too want at least a fixed ID per distro.  I'm
presently attempting to find out exactly how we (SUSE) do this in some
officially recognised way.

>>> I think a osd-prestart.sh snippet (or similar) that does a chown -R of any 
>>> non-root osd data to the local ceph user prior to starting the daemon will 
>>> handle the cross-distro changes without too much trouble.  I'd lean toward 
>>> not going from root -> ceph, though, and have the start script stay root 
>>> and not drop privs if the data is owned by root.. that covers upgrades 
>>> without interruption.
>>>
>>> What do you think?
>>
>> ...that sounds reasonable, and I think it would also handle the case
>> where, say, you move an OSD from one SUSE host to another - if the
>> UID/GID doesn't match (maybe some other `useradd`ing software was
>> installed first on the other host), the chown will fix it anyway.
>>
>> Are there any holes in this?
> 
> It would be nicer if the suse->suse case didn't require a chown, but yeah, 
> it'd still work just fine...

OK.  So at least that's a technically viable but undesirable fallback
position.

Tim

> 
> sage
> 
> 
>>
>> Regards,
>>
>> Tim
>>
>>
>>>
>>>
>>> On Thu, 11 Dec 2014, Tim Serong wrote:
>>>
>>>> On 12/11/2014 05:48 AM, Sage Weil wrote:
>>>>> +ceph-devel
>>>>>
>>>>> On Wed, 10 Dec 2014, Ken Dreyer wrote:
>>>>>> On 12/06/2014 01:54 PM, Sage Weil wrote:
>>>>>>> Hi Colin, Boris, Owen,
>>>>>>>
>>>>>>> We would like to choose a statically allocated uid and gid for use by Ceph 
>>>>>>> storage servers.  The basic goals are:
>>>>>>>
>>>>>>>  - run daemons as non-root (right now everything is uid 0 (runtime and 
>>>>>>> on-disk data) and this is clearly not ideal)
>>>>>>>  - enable hot swap of disks between storage servers
>>>>>>>  - standardize across distros so that we can build clusters with a mix
>>>>>>>
>>>>>>> To support the hot swap, we can't use the usual uids allocated dynamically 
>>>>>>> during package installation.  Disks will completely filled with Ceph data 
>>>>>>> files with the uid from one machine and will not be usable on another 
>>>>>>> machine.
>>>>>>>
>>>>>>> I'm hoping we can choose a static uid/gid pair that is unused for Debian 
>>>>>>> (and Ubuntu), Fedora (and RHEL/CentOS), and OpenSUSE/SLES.  This will let 
>>>>>>> us maintain consistency across the entire ecosystem.
>>>>>>
>>>>>> How many system users should I request from the Fedora Packaging
>>>>>> Committee, and what should their names be?
>>>>>>
>>>>>> For example, are ceph-mon and ceph-osd going to run under the same
>>>>>> non-privileged system account?
>>>>>
>>>>> Hmm, my first impulse was to make a single user and group.  But it might 
>>>>> make sense that e.g. rgw should run in a different context than ceph-osd 
>>>>> or ceph-mon.
>>>>>
>>>>> If we go down that road, then maybe
>>>>>
>>>>>  ceph-osd
>>>>>  ceph-mon
>>>>>  ceph-mds
>>>>>  ceph-rgw
>>>>>  ceph-calamari
>>>>>
>>>>> and a 'ceph' group that we can use for /var/log/ceph etc for the qemu 
>>>>> and other librados users?
>>>>>
>>>>> Alternatively, if we just do user+group ceph, then rgw can run as www-data 
>>>>> or apache (as it does now).  Not sure what makes the most sense for 
>>>>> ceph-calamari.
>>>>
>>>> FWIW my gut says go with a single ceph user+group and leave rgw running
>>>> as the apache user.
>>>>
>>>> Calamari consists of a few pieces - the web-accessible bit runs as the
>>>> apache user, then there's the cthulhu daemon, as well as carbon-cache
>>>> for the graphite stuff.  These latter two I believe run as root (at
>>>> least, they do with my SUSE packages which have systemd units for each
>>>> of these services, and I assume they run as root on other distros where
>>>> they're run under supervisord).  Now that I think of it though, I wonder
>>>> if it makes sense to just run the whole lot as the apache user...?
>>>>
>>>> Regards,
>>>>
>>>> Tim
>>>> -- 
>>>> Tim Serong
>>>> Senior Clustering Engineer
>>>> SUSE
>>>> tserong@suse.com
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Tim Serong
>> Senior Clustering Engineer
>> SUSE
>> tserong@suse.com
>>
>>
> 


-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong@suse.com