Yes, login.defs what what I had in mind. When I referred to rpms, I meant how
rpms in %post will commonly call useradd and such and create users that depend
on order of install, indirectly pointing out why sys uid/gids would be skipped
and why it’s not as simple as ‘prsysnc /etc/passwd compute:/etc/’ sort of thing.
I was thinking that mostly the gid/uid would be preserved, but membership list
may be overwritten… Similarly so for shadow, though I don’t think I’ve ever
seen a shadow entry change for a ‘sys’ account. Other details about said
groups can be modified with relative impunity cluster wide, but messing with
uid/gid that was expected at install time will cause bizarre behavior for many
packages was all.
In such a case, I’d imagine membership in system groups to merge only if said
local group exists, I suppose, otherwise ignore, don’t add a group in the
system group gid range if it doesn’t exist.
For ID conflict, in this case I think it would be ids in the MIN-MAX range are
fair game for obliteration. The master copy trumps everything.
For solutions that don’t use the files, so far I’m aware of commonly NIS and
LDAP, and there I’d say the solution would be for the nodes to be connected as
appropriate.
This would very specifically and narrowly apply to ‘I just want to do etc-file
style stuff and have it apply everywhere’, and more sophisticated approaches
would pretty much stay as they are.
Of course, the practical answer may be making use of ldap easier and always
recommending nscd for the performance problem…
From: Kevin Keane <[email protected]>
Sent: Tuesday, June 19, 2018 12:46 PM
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?
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]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
Sent: Tuesday, June 19, 2018 10:16 AM
To: xCAT Users Mailing list
<[email protected]<mailto:[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]<mailto:[email protected]>>
Sent: Monday, June 18, 2018 12:56
To: xCAT Users Mailing list
<[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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
