It is possible to edit the /etc/passwd, /etc/shadow, /etc/group files - they are only text files after all.

But you better know the format and understand what the fields are, how they are used, and what can go wrong.

The usual times I do so is during debugging new tools to manipulate these files. It is rather slow to add 400 users one at a time using the useradd utility, even when using a script to do so. Possible, yes. Just slow. And sometimes userdel does things you DON'T want (like deleting user home directories... fortunately the default is to not do that anymore). Sometimes, you do want the home directory deleted, but not the users mail file.... and sometimes the reverse. Hence the need for some sites to have custom tools.

Well, yeah, they're text and you can -- but it's not for the faint of heart or uninitiated, methinks. There are the little tricks, like poking an asterisk in the password field of /etc/shadow, well, editing it and just replace the password with * and you don't lose the user home directory -- ain't no way to log in to it.

Another thing I've done (more than once) was a new server and all those accounts and passwords and whatnot were just copied from the old server to the new server (password files don't change in format). scp from old to new, scp home from old to new (with appropriate arguments) and viola! everything is right where it needs to be.

I still do that. On my systems I restrict (as much as possible) installing any software in the root tree, I back up /etc to a a partition I call spares for no particular reason, then do a full install (Slackware) in the root tree. Copy the stuff from /etc that I need (including the password files and a few others).

The partitions look like this:
So, when you do the install, you add the partitions but you only format the root partition, all the rest of them are just sitting there waiting until the old password files replace the new password files. Takes about 20 minutes, 30 if I go outside and smoke, to do a full install of Slackware, up and running. Maybe another 15 minutes to get stuff in etc where it needs to be and all done. In my case, sdb1 and sdb2 are level 0 back ups of the non-system files.


I make a lot of use of /opt, /usr/local, separate partitions (or drives) for data bases and all my servers are configured identically -- not sizes but mount points whether or not used (virtual, for example is only used on my desktop but is a mount point on all the others "just in case someday or not."

It works for me, may not for others, but I long ago learned to keep every system identical except for size and always do a full install rather than update. There's a lot of way to skin a cat.

Hope this helps some.

1 members found this post helpful.

Thanks gentelmen I have much to consider. I want to try installing systems like you mentioned tron, ive seen videos of ppl doing that. Sounds good for not having to reconfigure everything over and over again.. About the only change Ive considered making to /etc/shadow is additional ! symbols to prevent accounts I feel should not be able to login. Anyways mucho gracias seniors!

The standard is to use an "x" in the /etc/passwd file, then have it disabled in the /etc/shadow file with an "*" instead of the encrypted password.

Granted, any character will work in the /etc/shadow file, but the "*" is the default.

Understood, I knew the the names that have an * after their name in /etc/shadow designated service accounts, and that symbol prevented them from logging in. And the other method is usermod -L to lock a user account from logging in..

They don't login. They are started/used as system daemon services. That allows the UID/GID to be given to processes, but they did not login to be started.

All the /etc/passwd entry provides is a designated owner and group.

Ahh ok ill add that to my notes, thanks for the clarification!