On Nov 23, 22:43, Carlos Murillo wrote:
> >> # passwd
> >> cannot execute
> >
> >Probably the executable isn't in your PATH.
>
> 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.
> > 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"
program,
> 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)
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.
> >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;
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.
> /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
Received on Sat Nov 24 2001 - 04:13:14 GMT