Hi Karl, thanks for your interest in the slurm Debian package. On Thu, Jan 12, 2017 at 01:30:40AM +0000, Karl Kornel wrote: > We are in the process of setting up a new cluster, which will be > available to many Stanford people. As part of setting it up, I > discovered that UID 64030 (which is normally used for SLURM) is > already in use by a previous student! > ... > The easiest thing to do would be to make a local modification to the > existing preinst script, replacing “64030” with a different UID (I > already have one allocated). But, I think the better way to do it is > to make the preinst script prompt the user for an ID, and then use > that!
As you can read in the Debian policy manual [1] the range 60000-64999 is "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." When I packaged slurm for Debian, I explicitly asked for a free UID in that range (check bug #444412) and 64030 was given. I preferred to use this approach because it avoids manual configuration and needs of synchronization among nodes. That range 60000-64999 of UID should be avoided for regular users on a Debian System. > Here’s how things work: > > 1) If an account called “slurm” already exists, and a group called > “slurm” already exists, then the package install takes place. This is > actually a break from previous behavior. > 2) Ask the user to provide an ID. If no ID is provided (because the > user cleared the field, because a noninteractive install is happening, > etc.), then default to ID 64030. > 3) Check for non-numeric characters in the response. If any are > found, notify the user and mark an error. > 4) Check if the ID is already in use, either for a user or a group. > If the ID is in use, notify the user and mark an error. > 5) If no errors were found, go to the next step. If there have been > three failed attempts, then error out the install/upgrade. Otherwise, > increase the priority of the query, and go back to Step 2. > 6) Add the user/group, as a system account, and without a home directory. Regarding your script, in chapter 6 "Best Packaging Practices" of the "Debian Developer's Reference" [2] it's clearly stated that "All prompting or interactive configuration should be kept to a minimum." Without considering the use of automatic configuration tools this proposed patch would require the administrator to enter the slurm ID on all the cluster nodes. > As I mentioned, the biggest change between the original script, and my > proposal, is that two previous checks have been removed: > > * There was a check to see if the slurm account had a home directory; > if it did, then (under certain conditions) the home directory is > changed to “/nonexistent”. This is still required since previous version of the package added user without specifying "/nonexistent", therefore when updating from those releases we need to modify this information. [1] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 [2] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-maint-scripts Best regards -- Gennaro Oliva
