The following is the method I used to replace a forgotten root password on a VirtualBox system.
I created a new minimal Openserver 6 system: took all the defaults and used the demo license.
Started this system to confirm that all is well. Shutdown.
Modifed the VirtualBox configuration to add the primary disk of the target system as drive 2.
Re-started the minimal system and as
root:
#divvy /dev/rhd1a
(n)ame partition 2 as hd2root
save and exit
#mkdir /hd2root
#mount /dev/hd2root /hd2root
#cd /hd2root
#cd etc
#ls -li shadow
4646 lrwxrwxrwx 1 root sys 38 May 23 2018 shadow -> /var/opt/K/SCO/Unix/6.0.0Ni/etc/shadow
NOTE: that this file links to the same file as the /etc/shadow in the boot file system.
#vi /hd2root/var/opt/K/SCO/Unix/6.0.0Ni/etc/shadow
old line 1:
root:zZZPHFOSVnlCQ:17921:0:0
new line 1:
root::17921:0:0
save
#Shutdown the minimal system
Start the target system.
You will be asked to enter a new root password.
This works for all versions of Openserver, with the following caveats.
The directory "6.0.0Ni" in the example will change depending upon the release of the Openserver target system.
The minimal system release cannot be older than the target system. ie Openserver6 works with all Openserver5, but Openserver5 cannot mount an Openserver6 vxfs file system.
If the minimal system is installed as a new drive 0 in the same system as the target, you MUST disconnect the
target disk from the system while installing the minimal system. Openserver6 initializes all disks that it finds during system installation.
If the target system uses a different disk controller than the minimal system, be sure to include it during the install, eg: minimal system is to be installed on a SATA disk, and target is a RAID system.
If the minimal system is Openserver5, then you will also need to run "mkdev hd" before divvy to add the target drive, be absolutely sure that you do not create any new partitions
After restarting the target system, and before entering the new password, you may receive a message that the protected password database is corrupted. If so run:
Is there a difference between this and putting the device in single user mode to reset a root password? I guess if there's a password on GRUB and you can't get to single user this might be handy. Or less steps in general.
interesting method, didn't try that so far. But setting up a complete new system, even minimalistic, seems a bit elaborated to me.
In almost any cases (at least in my experience) there is the possibility to mount a vdi or vmdk virtual hdd, using the qemu-utils package (if available):
$ shutdown guest
$ modprobe nbd # maybe not needed
$ qemu-nbd -c /dev/nbd0 /path/to/hdd.vdi # or vmdk or ...
# now /dev/nbd0 can be used as a 'normal', partitioned disk:
$ lsblk /dev/nbd0 # or fdisk -l /dev/nbd0
# locate root partition in the above output, e.g. /dev/nbd0p1
$ mount /dev/nbd0p1 /mnt
$ mkdir -p /mnt/{dev,proc,sys,run} # probably not needed
$ for d in dev proc sys run; do mount -B /$d /mnt/$d; done
$ chroot /mnt /bin/bash
# (now in chrooted system)
$ passwd
$ exit
# (back in current system)
$ umount /mnt/{dev,proc,sys,run} && umount /mnt
$ qemu-nbd -d /dev/nbd0
SCO uses vxfs (openserver6) or htfs (openserver5) file systems. Most Linux systems will not mount either.
The SCO passwd program does not encrypt the password, it uses a one way hash, from a seed that is different on each installation.
I only used a VM to prove a method. I have to do this for real on a bare metal system this week.
The following line is missing from the original post, which explains why /etc/shadow points to the same physical file when both file systems are mounted.
unix:/# cd etc
unix:/etc# ls -l |grep shadow
-rw-rw---- 1 root auth 535 Mar 23 17:12 shadow@
unix:/# ls -li /etc/shadow
4646 lrwxrwxrwx 1 root sys 38 May 23 2018 /etc/shadow -> /var/opt/K/SCO/Unix/6.0.0Ni/etc/shadow
unix:/#
EPILOGUE:
I drove the 225km yesterday to see the client, and sat down with the owner and office manager to find out who might have changed the password.
Within five minutes it came out in conversation that the office manager changes each user's password every 90 days, by signing in as root and:
#passwd user
my guess was that the user name had been omitted and that they should try signing on as root using one of the recent new passwords. Sure enough on the second try they were able to log in and change the root password back to the original.
In this case, they had taken it upon themselves to change passwords, and this was the method they came up with. Password rotation is easily accomplished through the menu driven scoadmin shell.
Some other methods I use:
Always have two sessions logged in when changing the root password, then if you cannot sign in you still have a signed in session to be able to change it again.
Set up passwordless login from another machine either with rlogin (hosts.equiv) or ssh..
