I should have kept reading the policy manual. The relevant section seems to be: 60000-64999: Globally allocated by the Debian project, but only created on demand. The ids are allocated centrally and statically, but the actual accounts are only created on users' systems on demand. The changelog for the base-passwd package shows recent allocations for things like hacluster and slurm, and that doesn't seem to be problematic, as the request for slurm shows: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444412 Cheers, Paulo On Sat, 2014-12-06 at 17:45 -0500, mdw@xxxxxxxxxxxx wrote: > On Sat, Dec 06, 2014 at 08:44:41PM +0000, Paulo Almeida wrote: > ... > > You can also register uids with Debian. Quoting from the Policy > > Manual[1]: > > > > The UID and GID numbers are divided into classes as follows: > > > > 0-99: > > > > Globally allocated by the Debian project, the same on every > ... > > I think you will find it hard to get one of those 99 numbers. Probably > you would have to argue that your id will show up on almost all systems > anyways - same as "bin", "root", "daemon", etc. > > [ Another problem with one number: you probably want the > *same* number on redhat, ubuntu, suse, etc. -- surely > you want to allow people to have mixed debian/redhat/ubuntu/suse > setups. . . ] > > The same policy page (https://www.debian.org/doc/debian-policy/ch-opersys.html) > goes on to say: > > 100-999: > > Dynamically allocated system users and groups. Packages which need a > user or group, but can have this user or group allocated dynamically > and differently on each system, should use adduser --system to create > the group and/or user. adduser will check for the existence of the > user or group, and if necessary choose an unused id based on the > ranges specified in adduser.conf. > > I think this is what you really want to be using instead, and it's easy > to find good examples of how to do this in many other existing debian packages. > > It does mean the per-machine local "ceph" user might be different > on different machines. I don't think that this number is actually visible > outside of the local machine, so it should't cause any real problems. > Well, except for ceph.conf. > > Probably the easiest fix for "ceph.conf" would be to accept a username instead > of a uid. The name is what you really care the most about - it means things > you do with ssh between machines will be coordinated. > > A more complicated fix might be to separate out "ceph.conf" into a generic > piece that can be shared across all servers and clients, and per-cluster > and per-machine pieces that can be used to contain anything the cluster > needs to keep in common, and anything that doesn't need to be know outside > of that machine. uid#'s clearly fall into the last category. The main > software thing that needs to happen for this it to allow for a "/etc/ceph.d/" > directory to contain configuration that gets merged at runtime. > > -Marcus Watts _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |