[Sunhelp] Scary error messages

dhansen at zebra.net dhansen at zebra.net
Sat May 13 00:04:13 CDT 2000


> So, I
> a) open the passwd file with vipw. Opens in emacs, my default editor.
> b) page through a bit. I *change nothing! *
> c) quit emacs. Get this error:
> 
> Root login directory != "/" or default shell missing:
> root:x:0:1:System Administrator:/root:/sbin/sh
> vipw: you mangled the /etc/ptmp file, /etc/passwd unchanged
> Root login directory != "/" or default shell missing:
> root:x:0:1:System Administrator:/root:/sbin/sh
> vipw: you mangled the /etc/ptmp file, /etc/passwd unchanged
> 
> d) do a
> # more /etc/passwd
> root:x:0:1:System Administrator:/root:/sbin/sh
> ....
> Indeed, all looks normal.
> Can su to root. Have shell.
> 

 to new users this can read as a pretty scary sounding
error message, but if you sit back and look at it you'll
realize that it really isn't. your login directory for
the root account is not "/", it is "/root"...so this
is a correct statement. also, it says that ptmp is 
mangled, not your /etc/passwd file and that it will
not make any changes to the /etc/passwd file as a 
result. now you're probably thinking "...yeah, ok
but 'why!'...".
 here comes the faithful old "read the man pages" and
'understand an administration command _before_ you use
it', that everyone soo loves to hear.
 vipw is a special tool designed to make certain that
any changes made are done 'correctly' (note the emphasis
here, any piece of software is going to have to define
things like what it deems to be 'correct') so that
new users have a lesser chance of hosing their systems
and seasoned admins can spend less valuable time
paying close attention to mundane tasks.
 
more to the point, here is an excerpt from 
man -s 1B vipw
  vipw performs a number of consistency checks on the password
  entry  for  root,  and will not allow a password file with a
  "mangled" root entry to be installed.  It  also  checks  the
  /etc/shells file to verify the login shell for root.
and from man -s 4 passwd
  take a quick look-over of example 1

  what has happened is that vipw is not a simple text
editor. when you exited (changes made or not) it still
does validity checking on the root account and the
login directory of /root did not meet what vipw was
programmed to recognize as a 'correct' entry. the ptmp
file is the temporary file vipw creates to hold all 
changes in until you are done and then it does validity
checking to see if that ptmp information qualifies as
an acceptable replacement for the necessary /etc/passwd,
/etc/shadow, etc... files. in this case you are still
perfectly safe with your change, you just didn't match
what vipw expected and it alerted you to it. your root
login directory is still under the "/" filesystem and
the invoked shell is a statically linked one (this is
important because in system emergencies when only "/"
can be mounted roots' login directory has to be in that
partition and its' shell must be found there too as well
as the shell cannot have any library dependencies laying
over in /usr/lib (which wouldn't be found because it 
couldn't be mounted, for whatever reason).)

> ----
> 
> And, while cleaning out bogus and old users:
> 
> # userdel -r zsimon
> UX: userdel: WARNING: Group entry exceeds 512 char: /etc/group entry truncated.
> 
> 

from man -s 4 group
 Malformed entries cause routines  that  read  this  file  
 to halt,  in  which  case  group  assignments specified 
 further along are never made.  To prevent this from  
 happening,  use grpck(1B)  to  check  the  /etc/group  
 database from time to time.

 check out man -s 1B grpck and run it against your 
/etc/group file. from the error message it sounds
like you have an incredibly long entry in one of 
your group lines. (you'll also see that grpck(1B)
mentions this limitation under the Diagnostics section.)
  also, if you check out the man page for userdel it tells
you how it behaves under different error conditions
(you can see the error code after a command is run if you
immediately type "echo $?" (i'm betting you got a 
return error code of "10" after that attempt).)

> What do these error messages mean?
> 

 i hope you don't mind a lengthy explanation. it's just
been my experience that including "why" in answering
these types of questions often goes a long way in 
increasing a users awareness of what they are doing.

  also, i would like to add a little more explanation of
"why" the root account is expected to just have a login
directory of "/". one of the two foremost reasons i 
already explained above, roots' login directory _must_
be in the "/" filesystem so that it can be found in
_all_ scenarios (especially the most minimilistic) and
equally crucial is that it has a statically linked shell
that can also be invoked under the same constaints.
  another reason is that the root account really (and this
cannot be stressed enough) should never be any kind of
a personal account (hence no need for a personal 
directory for storing files, etc...). in a purist view,
the root account should never even be logged into (only
summoned via 'su' or 'sudo') except in dire emergencies.
the root account should be thought of more as a tool,
than a user and only invoked when that tool is necessary.
of course, in the real world people disregard more
strict and purist views...just remember that even
seasoned unix 'gods' make mistakes and the more time
you spend in an account that has complete power over the
system the more you increase your chances that a typo
or oversight or ignorance will result in an unrecoverable
system.

david








More information about the SunHELP mailing list