Password file

[Bill Vermillion]

On Thu, Jul 13, 2006 at 14:47 , the murky waters churned and seethed,
the dark weeds parted and the water took on the sinister,
shifting visage we recognize as David J. Orman.  The great maw opened,
and the following was heard:

> 1 - SSH daemon changes in 4.11 would be my guess 2 - Changed
> UID/GID for postfix user. You need to chown/chmod the spool
> directory/contents properly using the new postfix user account
> UID/GID 3 - No idea.

> Your best bet is going to be reinstall, it'll be much less
> painful IMO. Secondly, the way you are handling this, is bad. It
> may have worked for a long time, but it's not the correct way to
> go about this.

I think a re-install is probably overkill.  It shohld be nothing
more than to see which programs are erroring, and then look
at the UID/GID of directories and files.  I only use sendmail -
after it became more civilized back in about 1995 I moved from
smail.  So I don't know if postfix diddle the password files on
reinstall, but I've see programs that do, so it's probably 
the UID/GID.  He could change the directories/programs to match,
or change the UID/GID in the new password file to match what
they are.

> #1 - You should not allow root login via ssh. You should ssh as
> a normal user and su. This is for all cases, not just automated
> processes. Bad bad bad.

In a reply he said removing the user and adding the user fixed it.
It might have been related to the stored key files and an
remove/re-add would have nuked those files.

> #2 - Although you didn't explain why, it *seems* as if you're
> copying the master.passwd file/rebuilding your pwdb to make sure
> user accounts are synched on the machines? If so - no comment,
> other then stop right now. In this kind of deployment, where
> you have multiple servers which need to have synchronized user
> accounts, you need to setup some kind of directory server (LDAP
> would be most common - OpenLDAP is a free LDAP server.) Then
> your servers can do authentication via the LDAP store. Virtual
> users in postfix can be handled the same way.

And he really could edit the files if he took the proper steps.
One would be to copy the file to a temporary spot on the new
machine, and then run a diff on the files.  At that point you know
what is going to be changed.  Secondly you backup the working
password file [master.passwd] so you can put it back if things go
wrong.

Making sure you can reverse everything you do is the key to keeping
systems up and running.

And something I learned a long time ago when AT&T stupidly put
in a ULIMIT of 1MB by default in their system, where we had
to move login to login2, and write a login that set the ULIMIT to
reasonable sizes, and then call login2, I learned the hard way
to MAKE SURE that when you diddle critical files you always have at
LEAST on more root login than the one you are using.  Then when you
make changes test by logging in on another account.  And DO NOT log
out your current root login.  If you do that you may never get back
in have to reinstall.  I had remembered the extra login twice, but
forgot it the 3rd time.

This was an install over a Christmas Holiday, and we got shipped
a wrong machine, and I was installing on the original with the idea
to get much work done and then backup to tape, and transfer into
the new machine when it arrived by overnight, shipping on Dec
26th.     And in light if 'if anything can go wrong it will', it
turns out when I made tape backups and verified them, the machine
was writing NOTHING to tape, and the verify agreed with what it
thought it had done.  That was the conversion from hell.

But if you know the system you should have no fear of editing
virtually anything on the system, taking precautions to be able to
reverse any changes - which includes making comments in all files
you modify with time/date and intials/name.

I've learned and have a degree from the School of Hard Knocks since
I first migrated to Unix/Xenix systems back in 1983.

In a Unix system which you know, only the worst cases - such as
major file corruption - should ever require a re-install.

> PS - I cannot strongly enough reiterate, the master.passwd
> copying deal is *really* not the best way to do this, and remote
> root logins are a bad idea.

I agree 1000% on the remote root login, but as I stated, being
careful and HOW you do it means you can edit your password files
with no worry.   However just copying without having any way to
reverse your actions could be a recipe for disaster as the OP
has found out.

I've edited SysV password files, used vi to add fields to match
the BSD formats, and took the shadow file from a SysV and inserted
it into the master.passwd file, and moved the ISP I was working
with then from and SGI IRIX environment onto FreeBSD.  

No problems.  The plus was going from IRIX and the Netscape server
to FreeBSD [I think it as 2.7 or so at that time] and moving from
a 400Mhz MIPS to a 200Mhz Pentium - even with a slower CPU and
about 1/2 the memory of the SGIs the performance was dramatically
better.

The real key is understand the Unix systems as a whole - and with
that under your belt you can work on any variant you come across -
if you know how to read error mesages and man pages.


Bill

-- 
Bill Vermillion - bv @ wjv . com