Jarod,
I like your approach overall. There are a few things that may need to be
addressed (normal when you are dealing with something this fundamental),
but those can be overcome:
- System accounts and groups are easy to identify by the UID value. Simply
look in /etc/login.defs for UID_{MIN,MAX}, SYS_UID_{MIN,MAX}, GID_{MIN,MAX}
and SYS_GID_{MIN,MAX}. No need to rely on RPMs or so.
- Keep in mind that sometimes system accounts can be members in user
groups, or vice versa.
- What about situations where a user or group legitimately only exists on
the management node? For instance, only the mgmt node may have a wwwroot or
httpd user and group, but ordinary users may be members of the httpd group.
- There is a potential for ID conflicts if a user account already exist on
the nodes. Theoretically, it shouldn't be an issue, but you know what they
say about the best laid plans...
- User names and passwords can come from many different locations, not just
the three files. In most cases, the other locations are non-local accounts,
of course, but you never know... Might be better to use getent
passwd/shadow/group, but that precludes using inotify, and may also pick up
unwanted accounts.
_______________________________________________________________________
Kevin Keane | Systems Architect | University of San Diego ITS |
[email protected]
Maher Hall, 192 |5998 Alcalá Park | San Diego, CA 92110-2492 | 619.260.6859
*REMEMBER! **No one from IT at USD will ever ask to confirm or supply your
password*.
These messages are an attempt to steal your username and password. Please
do not reply to, click the links within, or open the attachments of these
messages. Delete them!
On Tue, Jun 19, 2018 at 7:32 AM, Jarrod Johnson <[email protected]>
wrote:
> I have contemplated, but was not sure if this would be something of
> interest...
>
> A service dedicated to synchronizing credentials for those using
> synchronized local credentials. The behavior would be:
> -It would be aware of system accounts versus user accounts, and
> accordingly leave system accounts (those created by rpms) alone with
> respect to uid/gid, fully synchronizing user accounts
> -Include an option for stub shadow entries versus passwords, for
> environments confidently using key based authentication that want to opt
> out of compute nodes being able to do password authentication
> -It would inotify watch the key files (passwd, shadow, group) to induce a
> sync action, no need to explicitly sync at some interval, it would
> naturally react to passwd/useradd/etc.
>
> I have not given it much thought beyond the above three sentences. If
> this already exists, cool, if it doesn't but is not a wanted thing, ok.
> Otherwise, let me know if there is some sort of interest. The simplest
> form of this would be a single server to monitor and have a list of nodes
> to push to, to avoid confusion about which is the authoritative copy.
>
> Given the relatively little time I've thought about this, don't be
> surprised if I'm missing some glaring huge problem.
>
> -----Original Message-----
> From: Christian Caruthers <[email protected]>
> Sent: Tuesday, June 19, 2018 10:16 AM
> To: xCAT Users Mailing list <[email protected]>
> Subject: Re: [xcat-user] [External] What is the best way for
> changing/maintain users/groups/passwords for the computing nodes?
>
> Some suggestions:
>
> Rather than sync'ing the passwd, group, and shadow files to the systems,
> use a postscript to simply appended what you need to those files.
>
> Set the xCAT management node up as an NIS server.
>
> Set up ansible on xCAT MN to manage/create user accounts.
>
> Connect to LDAP or AD domain.
>
> Regards,
> Christian Caruthers
> Lenovo Professional Services
> Mobile: 757-289-9872
>
> -----Original Message-----
> From: Daniel Hilst Selli <[email protected]>
> Sent: Monday, June 18, 2018 12:56
> To: xCAT Users Mailing list <[email protected]>
> Subject: [External] [xcat-user] What is the best way for changing/maintain
> users/groups/passwords for the computing nodes?
>
> Hi!
>
> I had a problem where I couldn't login to a computing node with the
> password contained at system key of passwd table. I search in the internet
> for options on setting password for xcat.
>
> The documentation says
>
> chtab key=system passwd.username=root passwd.password=abc123
>
> But I don't really understand how this password would get to /etc/shadow
> of the computing nodes. Changing the password and reboot stateless node
> doesn't has effect, the node keep using the old password and passwd table
> and nodes /etc/shadow are out of sync.
>
> I saw people on internet synchronizing /etc/{group,shadow,passwd} from
> management node, but if this is the case, what is the point of the system
> key on passwd table?
>
> Any suggestion on how to handle computing node users will be appreciated!
>
>
> Regards,
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
