Moving local accounts to NIS
Updated on Thu, 2017-06-01 12:51 by wbetts. Originally created by jeromel on 2015-09-24 09:39.
We agreed to begin with user accounts and address generic accounts later.
We agreed to begin with user accounts and address generic accounts later.
Individual account conversion
Procedure are valid ONLY if the local account has tcsh as a shell- TO BE DONE ONCE
Create a CFEngine policy that would "create /star if it does not exists, create a link from /star/u to /ldaphome if /ldaphome exists AND /star/u does not exist". Make sure the directory /star is created with protection 0755.
This will allow HOME for a particular use to be remapped to /star/u/$USER ...
- Select a node where we have local accounts fitting the description above - example. wbetts on burton
- STOP nscd for this work (will restore at the end)
- Check if a directory named /star/u exists - ATTENTION, if it does not, make sure the directory tree is created with 0755.
- Configure NIS on the machine and make sure the UID from NIS are available
- For each local account, do the following
- For a given user (example wbetts), make sure NO processes are running. Kill if exists.
- Convert first the GID that are local
- Example - group docker (local GID 492) exists locally but not in NIS, create docker in NIS BUT make sure the GID are in the 10,000 range (agreed convention)
- When the new group is added to NIS, remove from the local file, make sure to usermod -G ... (to add secondary groups)
Note: I suggest using the native unix commands to remove a GID or UID as removing by hand will leave the entry in the shadow file (see groupdel and userdel). - Note: it often happens that a local group has the same name as the user name. Do NOT convert those (use rhstar instead)
- Execute pushNisUpdates from onlldap (you may make sure you create all needed groups first, then execute this script once instead of once after each new group's creatuion in NIS)
- Use the find command on the local node to convert all files belonging to the local GID to the new GID.
In our example, the command were
% find / -xautofs -xdev -gid 492 -exec chgrp -h 10003 {} \; # for docker
% find / -xautofs -xdev -gid 500 -exec chgrp -h 31012 {} \; # for rhstar
- Multiple local group may need to be converted. Make sure all of them are taken care off before the next step.
- Now, convert the UID i.e. search for files belonging to this user and change it. In our example,
% find / -xautofs -xdev -uid 500 -exec chown -h wbetts {} \; - Assuming /home/$USER was the local HOME directory for this user, create a link /star/u/$USER -> /home/$USER
- Remove the local group(s) from the /etc/group file and remove the user from /etc/passwd (see note above on using groupdel and userdel)
- Remap this user's HOME directory to be /star/u/$USER in NIS
- At this stage, there should be no local groups and no local user, all in NIS and the common remapped HOME should be /star/u/$USER ... Verify you can log under this user's account (su - wbetts in our example would be necessary)
- Go back to step 3.1 for the next user until all users are conevrted
- Restart NSCD service on this node after all local accounts are converted
- Go back to step 2 for the next node ...
User accounts generic issues
- For users using a different shell that csh (bash for example), we simply need to make sure the user agrees to either use bash everywhere or revert to csh. We may need to ask individuals. Mixed solution would not be possible in this case.
Status: procedure generally agreed upon. - A password issues was brought up - if a local user existed, it is likely that the user remembers his/her password. In NIS, doubtful the user remembers. How do we handle this?
Suggestion: as simply as possibly achievable - we ask the user, possibly reset the password and ask to change it. The second part is that we could always have a /usr/local/bin/passwd which calls yppasswd instead of passwd if the account is detected as being in YP/NIS.
Status:
Looking forward, issues with generic accounts and service accounts
A few issues came up during discussions in handling group or service accounts. Will enumerate them below with possible solutions.- Group accounts: as soon as they move to NIS, the group account would exists on all nodes in the ecnlave which may not be desired and/or desirable (for example, a generic pxl account may only be valid for the pixel/HFT related nodes but not a DAQ node).
Requirement: we need fine grain login control and disallow those from login in "in general" except on specific nodes
Solutions: using access.conf should be possible or see also You do not have access to view this node
Status:
- Service accounts: some service accounts (osiris, condor) would benefit from being homogenized in their UID/GID mapping ... but this may create a race condition or a clash as their related services may start before NIS/ypbind.
Requirement: service accounts do not have to be global but documented (so we do not re-use the UID/GID for something else)
Solution: Possible solution is to document the account in NIS (reserving the UID/GID) but still declare it locally (and matching)
»
- jeromel's blog
- Login or register to post comments