On Sun, Mar 26, 2017 at 2:47 PM, Joshua Schaeffer <jschaeffer0...@gmail.com> wrote: > > On 03/25/2017 03:03 PM, Boylan, Ross wrote: > > The problem is that I can't convert to using a shared directory when > different systems assign different uids to the same named user. In other > words, to get to the shared accounts solution I must already have solved the > problem of mismatching ids. > > Not entirely true, NFSv4 has the ability to map uid/gid between systems with > the rpc.idmapd program, which uses the idmapd.conf configuration files. > > The problems are mostly with system users, and I've seen some advice > indicating such users don't normally go in LDAP. So excluding would reduce > the problem, for LDAP, but also leave lots of unsynchronized ids. > > What is the issue of unsynchronized system ids? Are you allowing login of > these system ids? Are they also sharing a filesystem (NFS, CIFS, etc) for > these system ids? My assumption is that when you say shared directory you > are talking about $HOME for a normal user. If that's not the case then it > sounds like you are using an old technique where many systems mount shared > filesystems to /usr, /usr/share, /opt, etc. I haven't seen that in years as > disks are quite large enough to handle the space needed for these > directories.
The main practical problem is with backups, restores and copies that use numeric ids instead of names. This includes taking a disk that was used on one system and using it in another. Beyond that, I had a general sense that the mismatched ids could cause trouble. You're right, I'm not likely to be doing things like ssh'ing after having assumed a system account id or sharing files owned by system ids over NFS. So it may be just the backup/copying that's an issue. > > I'm not sure how much a problem it the mismatches are for NFSv4; I believe > it allows user/kerberos based authentication, but I'm not sure what that > means for the uids of the files. > > Mismatched ids in NFSv4 will result in a uid/gid of -1, which translates to > something like 4294967295 (I don't think that's the exact number but it's > close to 2^32) when you run an ls -l on the NFS mount point. > > LDAP is my go to solution for synchronized authorization and central account > management (I do not use it for authentication, but that is my own personal I was planning on using kerberos. Partly that's because I thought NFSv4 needed it anyway. > preference). I advocate it, but I know some people prefer simpler solutions > depending on the situation. A company of 10 systems can easily avoid all of > the management, hardware, upkeep, etc of LDAP and use something like NIS, > Puppet, etc or use no central management at all. > > I guess I'm not understanding the core problem. I never put system ids > (including root) into LDAP, only user's ids. Typing this out, it occurred to > me that I am assuming you mean a system id is an id of >1000 (in Debian). If I mean ids < 1000. 1000+ seems to be for users on my systems. On my systems it's 100-124 that have the problems. > you are talking about some generic account that is not an actual system ID, > but is not used by a specific user, then yes you have to find a way to > synchronize and/or transfer the account. I would simply create the account > in LDAP and then transfer all ownership of processes and files to that new > account (as you already stated). Are you saying there is a way to change the uid/gid of a process that is already running from the outside? Does usermod do that if you change the uid? My concern is that if I change file uids existing processes will gag and, worst case, the system becomes non-functional even on reboot.* This seems particularly acute with systemd. I know I can shutdown most services, change ids, and restart them. But I have the impression that the ones associated with systemd, and maybe some others like messagebus, are essential and have to be left running. And I am accessing the systems via ssh, and so changing the ssh u/gid seems especially dicey. *It just occurred to me I could temporarily make permissions more permissive, or add group permissions, to avoid getting locked out. Ross
