Bug#851103: slurm account's UID conflicts with a user -- Allow setting a different ID at install time
Hi Karl, thanks for your interest in the slurm Debian package. On Thu, Jan 12, 2017 at 01:30:40AM +, 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 6-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 #12) and 64030 was given. I preferred to use this approach because it avoids manual configuration and needs of synchronization among nodes. That range 6-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
Bug#851103: slurm account's UID conflicts with a user -- Allow setting a different ID at install time
Source: slurm-llnl Version: 16.05.8-1 Severity: wishlist Tags: patch Hello! 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 student has graduated, so the UID is no longer active, but if the student ever comes back, then he will get that UID again, which will cause problems. (By the way, I say that because the cluster uses central LDAP for account information, so giving him a new UID would be difficult.) 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! This also means that I can offer the script for you to take upstream, which is what I’m doing now! 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. 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”. * There was a check to see if the existing slurm account had UID and GID 64030. Both of those checks were removed under the idea that, if an account already exists, it should not be messed with. I would really appreciate it if people could try out this change. I have tried this many times on the new cluster (which runs Ubuntu Xenial), but this patch adds a lot of complexity, so I think other people should try it before it gets applied (assuming you are willing to take the patch). NOTE: This patch requires that you have already applied the patches from bug 850891. I definitely think bug 850891 should be resolved before this one, because that bug moves the same code from three preinst scripts into one. Finally, it is possible for the text to be translated! If anyone is interested in making translations, information is available here: http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN34 (see the section called “Localizing the templates file”). I look forward to any comments that you have. Thank you very much! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 0001-Allow-custom-ID-for-slurm-user.patch Description: 0001-Allow-custom-ID-for-slurm-user.patch
