CentOS - Jul 2005 - Fix passwd/shadow/group files?

I've been copying old passwd/shadow/group files from system to system
for ages across different distributions/updates and would like to
get them back in sync with each other so the system tools will
work.  Now they hang like:

#userdel irose 
 hangs forever, syslog says:
Jul 12 11:19:32 newftp userdel[30335]: delete user `irose'
Jul 12 11:19:32 newftp userdel[30335]: delete `irose' from group `ftp'
Jul 12 11:20:02 newftp last message repeated 373404 times
Jul 12 11:21:04 newftp last message repeated 646597 times
Jul 12 11:21:06 newftp last message repeated 29123 times

Is there some kind of test/diagnostic tool I can use to clean up
the parts that don't match anymore?  Preferably one that doesn't
hang forever when something is missing....

-- 
  Les Mikesell
   lesmikesell at gmail.com

Had something similiar happen, if you take a look at your 
passwd/shadow/group files (which are likely .5 MB or more in size now)
you'll see tons of junk and lots of commas...
I think I ended up fixing this mostly via sed/grep and by hand...
Can't remember what caused it though...
Cheers,
MaZe.

On Wed, 13 Jul 2005, Les Mikesell wrote:
> I've been copying old passwd/shadow/group files from system to system
> for ages across different distributions/updates and would like to
> get them back in sync with each other so the system tools will
> work.  Now they hang like:
>
> #userdel irose
> hangs forever, syslog says:
> Jul 12 11:19:32 newftp userdel[30335]: delete user `irose'
> Jul 12 11:19:32 newftp userdel[30335]: delete `irose' from group
`ftp'
> Jul 12 11:20:02 newftp last message repeated 373404 times
> Jul 12 11:21:04 newftp last message repeated 646597 times
> Jul 12 11:21:06 newftp last message repeated 29123 times
>
> Is there some kind of test/diagnostic tool I can use to clean up
> the parts that don't match anymore?  Preferably one that doesn't
> hang forever when something is missing....
>
>

On Wed, 2005-13-07 at 18:27 -0500, Les Mikesell wrote:
> I've been copying old passwd/shadow/group files from system to system
> for ages across different distributions/updates and would like to
> get them back in sync with each other so the system tools will
> work.  Now they hang like:
> 
> #userdel irose 
>  hangs forever, syslog says:
> Jul 12 11:19:32 newftp userdel[30335]: delete user `irose'
> Jul 12 11:19:32 newftp userdel[30335]: delete `irose' from group
`ftp'
> Jul 12 11:20:02 newftp last message repeated 373404 times
> Jul 12 11:21:04 newftp last message repeated 646597 times
> Jul 12 11:21:06 newftp last message repeated 29123 times
I recall a message about something similar to this in the Fedora users
lists, I believe.  I think the person that reported it tracked it down
to a bug in useradd etc.

Run a search in the Fedora list, and check out bugzilla.

HTH,

Ranbir
-- 
Kanwar Ranbir Sandhu
Systems Aligned Inc.
www.systemsaligned.com

On Wed, 13 Jul 2005, Les Mikesell wrote:
> I've been copying old passwd/shadow/group files from system to system
> for ages across different distributions/updates and would like to
> get them back in sync with each other so the system tools will
> work.  Now they hang like:
> Is there some kind of test/diagnostic tool I can use to clean up
> the parts that don't match anymore?  Preferably one that doesn't
> hang forever when something is missing....
   pwck   ?

-- Russ Herrold

From: Les Mikesell <lesmikesell at gmail.com>
> Good call!  That and the corresponding grpck found a couple of
> duplicate lines that seemed to be confusing things.  
Any reason you haven't considered NIS?
If you're worried about passwords, setup Kerberos for authentication.
It's easier than you think.



--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Les Mikesell <lesmikesell at gmail.com>
> The machines in question were set up years ago when it wasn't so
> easy and are on opposite sides of a firewall
Setup an NIS slave local to each LAN (and a VPN to the NIS master,
or consider SFS tunneling for portmap), and also run a name services
cache daemon (nscd) on each client.
> (but sometimes have NFS mounts in common).
All the more reason to use NIS, for Automounter maps.  ;->
I only recommend NIS because it's cake to setup.

If you have ActiveDirectory Services (ADS), then consider
Services for UNIX (SFU).  You can even use one-way Kerberos
trust from ADS to avoid password hashes (as well as clear
text passwords using Kerberosized clients).

I don't prefer ADS-SFU when you have UNIX platforms though.
Especially Red Hat, who made NIS-Kerberos integration so
seemless as of Red Hat Linux 7 onward.
> One machine has all user accounts and things are managed
> normally there.
Great!
It's so easy to turn that one system into an NIS master then.
;->
> The others only have small subsets of users (on purpose)
> and I've pasted in the passwd entries from the machine that
> has them all to keep the uids in sync for NFS and rsync'ing
> chunks of stuff around.
Then setup multiple NIS domains.
It's easy to do even on one, physical NIS master for all.
It'll easily repay you for the manual operations you do.

[ But even then, why aren't you using a script run over ssh
to minimize your manual workload?  Just curious. ]
> I just had some duplicated lines from the last OS version
> change where I copied too much from the previous one.
> I might re-do it with LDAP someday, but it's probably
> more work to control the users that aren't supposed to
> log into these machines than to separately add the ones
> that are.
Netscape Directory Server (NsDS), now Red Hat/Fedora Directory
Server, is a great LDAP server.

But when I just want something like you need, an NIS domain
or a few from one system, with local NIS slaves and nscd running
on all the clients does everything I need.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

Ignacio Vazquez-Abrams wrote:
> Stuff pam_netgroups into system-auth then make a group per machine.
> http://www2.physics.umd.edu/~payerle/Software/PAM/
Doh!!!  I should have realized that.

Yes, using NIS Netgroups and PAM authentication around them is much,
much better on Linux (and even Solaris) than using multiple NIS domains.

And even if he still replicates his files manually (he should at least
consider automating their distribution via SSH), he can still setup just 1
file and use the same netgroups-PAM solution.

Good catch.

From: Paul Heinlein <heinlein at madboa.com>
> If you set up netgroups, you can specify login rights easily:
> * /etc/passwd
> [...]
> + at login-group
> +:::::/dev/null:/sbin/nologin
> * /etc/nsswitch.conf
> passwd:     compat
> shadow:     compat
> group:      files nis
> netgroup:   files nis
Now that only works for NIS distributed passwd, netgroups, correct?
Or will it work for local users as well?


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Paul Heinlein <heinlein at madboa.com>
> I think it'll only work for NIS passwd maps, but I think that the 
> netgroups map can come from NIS *or* live in /etc/netgroup.
Right.

But in a nutshell, I think we agree that NIS is the way to go.
Totally forgot about netgroups and using the +:::::: limitations
in /etc/passwd on each NIS client.

All excellent suggestions.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Les Mikesell <lesmikesell at gmail.com>
> The problem is that nearly all of the people are windows users
> that need samba accounts to work in addition to ftp/ssh.
So?  I've been authenticating Samba against NIS servers since
the mid-'90s.  I've even used NIS to distribute my smbpasswd
files.

See "Samba Unleashed," Appendix A (Solaris).  ;->
[ NOTE:  The book is 5 years old now, Samba 2.0 was latest. ]

I wanted to put in more, but the main author (and my largest
professional critic) wanted me to keep the NIS/NFS compatibility
down because the rest of the book didn't address it.
> Some maintain web content, some are customer support that need
> write access to the ftp server and another set does some
> development and testing on a different box. At various times
> in the past, some of the boxes were solaris and freebsd.
So?  NIS is _universal_ to just about any UNIX flavor.
Almost every UNIX C Library supports checking against it.
Some include more modular options, like NSSwitch for
telling it whether or not to check against NIS maps.
> Now they are all Linux and I'm using smb authentication against
> a windows domain controller but still create the accounts for each
> permitted user manually.
Dude ...

1)  I specifically asked you if you had an true MS ADS DC.
2)  I mentioned MS Services for UNIX (SFU)

Dude, if you had a true MS ADS DC and were already authenticating
Samba against it, you _should_also_ use SFU to share out NIS from
the same.  Now you just control your netgroups at your MS ADS DC.

Furthermore, you can even setup true UNIX/Linux NIS "slave" servers
to SFU, just like you can setup UNIX/Linux BIND "secondary" DNS
servers to MS ADS-integrated DNS.  That way if your MS ADS DC
tanks, you're not down, because you still have UNIX/Linux DNS/NIS.
> Can NIS/netgroups mesh with samba authentication against a
> windows domain or would I have to use LDAP for better
> integration?
Think of NIS as "flat file" like old CIFS (except without the
broadcast
non-sense).  Whereas CIFS moved the Reigstry-SAM password DB
network-wide, used NT LAN Manager authentication and introduced
WINS as a name resolution service, NIS basically does the same for
_any_ UNIX files.  You don't even need DNS.

You can even use pGINA to replace your NT/200x/XP login to
authenticate against other servers.  I used to do similar with
NISGINA back in the '90s (before MS ADS was even an option for
Windows networks).  GINA is NT's graphical login/authentication
system when you logon.

Now that MS has gotten serious, you can just use SFU on your MS
ADS DC _directly_!  Now you're hosting maps, and ensuring ADS
objects _match_ those of NIS maps.

Alternatively, if you're worried about security, you can use Kerberos
for your password store (instead of NIS hashes in passwd).  Now
that gets a little more client-specific, but you _can_ use MS ADS'
Kerberos to provide a "one-way trust" down to a Keberos realm.
> Actually, I guess the next integration will be with Active Directory.
Wait!  Are you CIFS PDC/BDCs or ADS DCs?

If you are the former, you _can_ switch _away_ from CIFS altogether!
Not only does Samba 2.2+ provide _full_ CIFS replacement, but you
can setup Samba 3.0+ as a BDC, mirror the existing, native CIFS PDC,
and then _easily_ promote it to a PDC!

Once your PDC is Samba, then it's cake to do NIS.

If you already made your Network ADS' bitch, then just get MS SFU.
Trust me on this, it makes life 100x easier!  I wouldn't be surprised
if management thinks UNIX/Linux "sucks" because the UNIX/Linux
network is setup like crap, and not because it's not capable.
> This company has been acquired and the corporate parent is in the
> process of converting their domains now and will be including the
> users at this location.
Just FYI ...
Once you ADS, you're _always_ going to be Microsoft-controlled.
Samba will _never_ reverse engineer all of Microsoft's LDAP schema.

I know MS ADS is required for a lot of new services.  In such case,
consider segmenting, maintaining and sychronizing the MS ADS
to Red Hat Directory Server (fka Netscape Directory Server, NsDS).
Florida Institute of Technology's (FIT's) "acctsync" is a ADS
DC-side
service designed to retrieves any changes or sends any updates
(like password) back to their "master" NsDS tree (acctsync also now
supports OpenLDAP, although limitedly).

FIT did this because back in 1999, when Windows 2000 starting
infiltrating their network, they did _not_ want to put UNIX/Linux
reliability at the mercy of MS ADS.  They were already running a
full LDAP tree with NsDS, and even if they were still using legacy
NIS, SFU 1.0 didn't offer a good NIS/NFS service yet (that wasn't
really until 3.0 -- current version is 3.5 and _free_).  You better
decide soon whether or not you're going to put your entire network
at the mercy of MS ADS, or if you want to maintain some anonymous
control.

You really need an independent architect to come in and make your
life easier.  Because it seems your department isn't aware of all your
interoperability options.  I'm sure your management must think that
Windows is 100x easier to support than UNIX/Linux because of your
current setup.  I mean, NIS is circa 1982 (yes, _82_) UNIX design,
and it would solve your problem quite nicely.



--
Bryan J. Smith   mailto:b.j.smith at ieee.org