Posted by jpluimers on 2021/05/24
For my link archive: [Wayback/Archive.is] 2 x Speakers surround replacement – Designed for Apple G4 Cube M7963 | eBay
Via: [Archive.is] Power Macintosh G4 Cube Owners Group : Hi Guys. Just for you to be aware, this is my product, specifically designed and produced by me to repair the Apple G4 Cube speakers | Facebook
–jeroen
Posted in Apple, Mac, Power Mac, Power Mac G4 Cube, Power User | Leave a Comment »
Posted by jpluimers on 2021/05/24
I only needed one of the standalone ways for the many ways in [WayBack] Forgot the ESXi root password? No problems, here are 4 ways to reset it! – VMWARE BLOG
Passwords are the things people tend to forget. Well, ESXi root passwords are not an exception either! Without the root password, you lose control over your hosts, so it’s good to know how to reset it. Well, resetting an ESXi host password is the thing I gonna talk about in this article.
…
Resetting root password on the standalone ESXi hosts
Now, as we know how to reset the password with vCenter, let’s look at some tough cases. Let’s say, you don’t have vCenter installed on the host. Once again, I do not want to re-install the server OS as VMware says. Seriously, that’s not fun! Let’s look at something more interesting instead. Well, let’s say, what about changing the password right on the node itself?
Before I start, I’d like to mention that you won’t be able to trick ESXi security and change the root password on the node without shutting it down. This means that you, like it or not, do need to shut down each VM from the inside! If you screw things up, you won’t be able to start VMs without ESXi re-installation.
Also, you need the boot the CD image. I used Ubuntu GNOME in this article. Find out how to create a boot CD and download Ubuntu GNOME here. You also need Rufus to write the boot CD image on the flash drive.
So, you need to boot from the flash disk, mount the required ESXi datastore, unpack the archive, and edit the file with passwords. Next, you upload the file back into the initial directory, and, after rebooting the host, you can access the it without the password.
Editing the “shadow” file
What’s “shadow” is?
For safety concerns, ESXi keeps passwords encrypted in some file… whatever, here’s how you still can reset the password. According to some unofficial sources, this file is called “shadow”. You can find it in one of those booting volumes in the /etc directory. Before the host boots, /etc is in the local.tgz archive. Here’s the path: /etc => local.tgz => state.tgz. You can find it in one of those booting volumes in the /etcdirectory. Before the host boots, /etc is in the local.tgz archive. Here’s the path: state.tgz => local.tgz => /etc.
Here’s how the disk is formatted in ESXi 6.0 or higher:
Volume name What it is for? Volume size in my case /dev/sda1 Starts the system 4 MB /dev/sda2: /scratch: System volume that is created while installing ESXi on the over-5 GB disk. 4 GB /dev/sda3: VMFS datastore: Represents all the remaining disk space /dev/sda5: /bootbank: The ESXi image 250 MB /dev/sda6: /altrbootbank: The older system version image. You’ll see it as an empty volume if you have never updated the system 250 MB /dev/sda7: vmkDiagnostic (the first volume) Keeps the core dump 110 MB /dev/sda8: /store VMware Tools image 286 MB /dev/sda9: vmkDiagnostic (the second volume) Keeps all the information connected with vSAN diagnostics. You can observe this volume only in over-8 GB datastores 2.5 GB Among of all those volumes, we need only the /bootbank one as it keeps the ESXi archive. In this way, “shadow” should be somewhere there.
Chasing the “shadow”
So, let’s boot the host from the flash disk first and start the terminal.
Run the following cmdlet to acquire root privileges:
# sudo su
Next, deploy the command below to look through the sda directory.
# fdisk –l | grep /dev/sda*
Well, it seems that we need that 250 MB /dev/sda5 directory. Create the mnt directory.
# mkdir /mnt/sda5
Create the directory for the temporary files now.
# mkdir /temp
And, mount the /dev/sda5 directory using the cmdlet below.
# mount /dev/sda5 /mnt/sda5
Now, look for that state.tgz archive I was talking above.
# ls -l /mnt/sda5/state.tgz
Extract both state.tgz and local.tgz. Here are the commands you can use for that purpose:
# tar -xf /mnt/sda5/state.tgz –C /temp/
# tar -xf /temp/local.tgz –C /temp/
Once you are done with unpacking, get rid of those old archives with the cmdlet below:
# rm /temp/local.tgz
Now, you are ready to do some magic with “shadow”. Open the file, edit it, and close it. As simple as it! To double-check the changes, open the file one more time.
# vi /temp/etc/shadow
Actually, here’s how “shadow” looks like inside. See, it contains all users’ passwords.
To reset the password, just delete everything between the double colons. Remember, everything is encrypted? That’s why passwords look that weird.
# vi /temp/etc/shadow
Next, go to the work directory.
# cd /temp
Now, add the “shadow” back to the archive.
# tar -czf local.tgz etc
# tar -czf state.tgz local.tgz
Move the new archive to the initial directory.
# mv state.tgz /mnt/sda5/
Unmount the /sda5 disk with the cmdlet below:
# umount /mnt/sda5
And, eventually reboot the host.
# reboot
Well, to make the stuff I’ve just written above more reader-friendly, here’re all commands you need to deploy step-by-step.
Well, you are almost there. Reboot the server now, and try accessing the host without any password. Well, check out what I’ve got.
Now, select Configure Password, and type a new password in the self-titled field.
Ok, this time, please write the root password, or just try no to forget it!
Replace one “shadow” with another
There’s another way to reset the ESXi root password using “shadow”. Actually, that’s nothing more than a variation of the method I described above.
So, another thing you can do to reset the ESXi password is just using another host “shadow” file! Yes, you can just copy the “shadow” file from another host with the known root password to the one more flask disk. To get the file with passwords from another host, you need WinSCP. The utility is available here. The nice thing is that you can retrieve that file from the host with the unknown ESXi root password without even shutting it down.
Next, call the terminal with the Ubuntu GNOME and reset the password.
Update user privileges to root first. You can run the following command for that purpose:
# sudo su
Now, let’s see what you have on the disk.
# fdisk –l | grep sd
Create two temporary volumes afterward.
# mkdir /mnt/sda5
# mkdir /mnt/sdb1
Mount the ESXi disk and flash disk where the “shadow” resides using the following cmdlet.
# mount /dev/sda5 /mnt/sda5
# mount /dev/sdb1 /mnt/sdb1
Now, create the temporary volume for further work with archives.
# mkdir /temp
Create the volume where you are going to keep the state.tgz copy just in case something goes wrong.
# mkdir /mnt/sdb1/save
Find the necessary file in the archive.
# ls -l /mnt/sda5/state.tgz
Copy the archive.
# cp /mnt/sda5/state.tgz /mnt/sdb1/save
Run the following command to double-check whether the file has been copied:
# ls -l /mnt/sdb1/save
Extract state.tgz using the cmdlet below:
# tar -xf /mnt/sda5/state.tgz –C /temp/
Find the temp file.
# ls –l /temp
Extract local.tgz.
# tar -xf /temp/local.tgz –C /temp/
Make sure that you extracted the /etc directory.
# ls –l /temp
Now, delete the local.tgz volume to ensure that it won’t be included into the new archive by accident.
# rm /temp/local.tgz
Find “shadow” in the /etc directory.
# ls -l /temp/etc
Replace the original “shadow” with the one from the host with known root password. Type the following cmdlet:
# cp /mnt/sdb1/shadow /temp/etc
Now, deploy the following command to open the file and look through the saved credentials.
# vi /temp/etc/shadow
If you do not want some users to access the host, go ahead and just remove them from the listing! Here, I removed Test from the users that can access the host. Wait, why did I delete only Test? At this point, I’d like to warn you against deleting any users you are not familiar with. In my case, all users except Test are system ones. If you delete any of those guys, you may destabilize the OS!
Here’s how the “shadow”: file looks like once the unnecessary user.
Check whether all changes have been applied.
# vi /temp/etc/shadow
Type the following line to navigate to the /temp directory.
# cd /temp
Archive the /etc directory.
# tar -czf local.tgz etc
Check whether archiving has run smoothly.
# ls -l /temp/
Now, create the state.tgz volume.
# tar -czf state.tgz local.tgz
Again, check whether the volume has been created.
# ls -l /temp/
Move the archive to the working ESXi directory.
# mv state.tgz /mnt/sda5/
Check the result one more time.
# ls -l /mnt/sda5/
Unmount the sda5 directory.
# umount /mnt/sda5
Eventually, reboot the host.
# reboot
Enjoy! If everything is done right, you can access the host with the known password. Well, to make everything more or less convenient here’s the entire set of commands I used for this method.
If the host starts acting weird after reboot, there’s still a copy of the initial state.tgz. Well, it should be. You can mount both /sda5 and /sdb1 and retrieve the original state.tgz using the following cmdlet… and try again!
# cp /mnt/sdb1/save/state.tgz /mnt/sda5/
–jeroen
Posted in Power User, Virtualization, VMware, VMware ESXi | Leave a Comment »
Posted by jpluimers on 2021/05/24
I had something odd on one SuperMicro systeem:
The “Virtual Storage” menu item under “Virtual Media” was marked grey (gray?) as being unavailable.
Despite that, no disk image was shown mounted according to the web interface at menu path “Virtual Media” -> “CD-ROM Image“:
Port settings were good though as seen in menu path “Configuration” -> “Port“:
Even nmap did not show significant differences between the various systems (partial dump here; full dump below)
Discovered open port 443/tcp on 192.168.71.96 Discovered open port 5900/tcp on 192.168.71.96 Discovered open port 80/tcp on 192.168.71.96 Discovered open port 22/tcp on 192.168.71.96 Discovered open port 5985/tcp on 192.168.71.96 Discovered open port 623/tcp on 192.168.71.96I use alias
alias nmap-fingerprint_host_all-ports-even-if-ping-fails='sudo nmap -O -v -A -p- -Pn'here as it usually gives best results for port scans on a single machine.
The secret is in a different menu entry under menu path “Maintenance” -> “IKVM reset“:
After pressing the Reset button, then restarting the iKVM client, “Virtual Media” -> “Virtual Storage” is nog grey any more, and just works:
Posted in Hardware, IPMI, Mainboards, Power User, SuperMicro, X9SRi-F | Leave a Comment »
The Wiert Corner - irregular stream of stuff 