23 Nov
2001
23 Nov
'01
8:13 p.m.
On Nov 23, 22:43, Carlos Murillo wrote:
No, apparently when the file isn't found the msg is ": not found" .
I tried all sane locations for the passwd program. "cannot execute"
means something else, perhaps a permissions or restricted shell issue.
I meant that it may find the file /etc/passwd and realise it's not
executable. To be honest, I wouldn't expect most things -- including
passwd -- to work under a maintenance shell.
program,
If you *can* run things from the mounted filesystems, the relative
positions of the bin, lib, etc directories may matter. But the contents
may not work anyway; you're not running a full kernel, only a very limited
stand-alone maintenance program.
Then it seems you'll have to use cat and echo, I suppose. Cat the file to
see what's in it, then use echo to put modified versions of the lines you
need into some other file.
# passwd
cannot execute
Probably the executable isn't in your PATH. > If you have the filesystems
>mounted (BTW, why "mymnt" not just "mnt"? That's what mnt is
for) you
can
add the
relevant directories
PATH=/mymnt/hd2/bin:$PATH
I did something similar; I copied all stuff in the ram-based /usr
to another ram-based /usr1 and added /usr1/bin, /usr1/sbin and so
on to the path, the idea being that after I used getrootfs I would not
lose the previously available tools (while getrootfs seemed to change
the actual anchoring of / from the ram to the HD device, it failed to
properly mount /usr; however, the earlier ram-based tree at /usr became
unavailable after the execution of getrootfs, leaving out the "mount"
even though the mounting of /dev/hd2 at /usr had
failed)
>but it might be better (if you just have two partitions on the hard
drive)
to mount hd2
directly on /mnt, and then mount hd4 on /mnt/usr. At least
then things will be in the correct places relative to each other. There
isn't a directory called "/root", is there?
Yes, I did not keep relative mounting closeness in my arrangement.
I'll have to check about the existence of /root (I'm away
from the machine now) >You could try the "users" command,
though I expect it only works on a
>normal system (ie not from the maintenacne shell, which is sort of a
mini
>system, like the miniroot or standalone shell in
IRIX and Solaris). If
you
can edit
/etc/passwd with ed, you can probably remove the password field
from root's entry, leaving a null field (no password).
No ed so far; /mymnt/hd4/etc/security/passwd and opasswd exist, but
they
are in a totally unknown format--anything like unix.
What does a line in each of those look like?
Normally etc/security/passwd contains lines with username, encrypted
password, lastupdate, restrictions (if this is null, it means "none";
alternatives are "nologin" and "nouse"), and a field describing audit
classes used for accounting.
/etc/security/passwd is roughly the equivalent of the /etc/shadow file used
by other UNIXes, not the equivalent of /etc/passwd; opasswd is either an
older version, or the original /etc/passwd before it was converted to use
shadowing. It might be worth trying to rename them or move them somewhere
else, then replace /etc/passwd (move the original somewhere else) with one
containing a null field instead of the indicator (usually 'x' in UNIX but
'!' in AIX) that tells AIX to look in /etc/security/passwd of the password
data. So you end up with an /etc/passwd that has a line like:
root::0:0::/:
instead of
root:!:0:0::/:
Could I replace a known encrypted (that is, under
another unix
variant) password in the corresponding token?
I can't remember if AIX of that vintage used the same algorithm for
encrypting passwords. I think so. But I think it would be much easier
just to null out the password field (in either /etc/passwd or better still
in /etc/security/passwd). If you can then boot the system properly and log
in as root with no password, then you can set one in the normal way.
--
Pete Peter Turnbull
Network Manager
University of York