j a m i e

This has been particularly painful for me the last fortnight, ever since my last phone died and took with it all my 2factor logins. (scratch codes are overrated, right?).

The general consensus from the OPNsense forums was booting with a live image, resetting the password, cancelling the install and then rebooting the old image was the way to go. I put this off because 1. I was being lazy and 2. I was wary of doing this when my OPNsense image is a bit customized.

This morning I had some spare time after fixing plex and I was looking through alternatives. The backup configs saved me once before when I mangled the drivers for the 10g switch so I started with looking there. Sidenote, this is way too awesome to not leverage if you’re already using OPNsense, check it out.

Anyway, if you check through the config and search for ‘root’, towards the bottom of that block you’ll see a OTP string. Grab that badboy and put it in your 2factor on your new device to setup a new code. Login working again as if nothing ever changed.

I’m undecided on if this is a security flaw or not, people should be backing up to secure locations to begin with but it’s still a free scratch code. Works for now anyway!

Tired of looking at something like this?

The default amount of processes that Zabbix will trigger an alert for is 300, in the image above my Zabbix server never even dips below it, always above so it’s been a (harmless) alert for about two months for me.

Turns out fixing it is pretty easy though, all we need to do is edit the template to a more ‘reasonable’ number.

1. Login to Zabbix and head to Configuration
2. Templates
3. Template OS Linux
4. Triggers
5. Too many processes on {HOST.NAME}

I updated mine from 300 to 450, giving a little overhead for future growth while still allowing it to alert. Back down to 0 alerts and a clean bill of health, nice!

This was terrifying for me first time, so don’t do what I did. It’s pretty painless if you take your time and have backups in place beforehand. Lets dive in!

So first off, migrate off all the VMs you need to keep online to another host. Make backups of anything left because you’ll wish you did if anything goes wrong. I’m going to use the H700 as an example in this post. I did this without making a backup first – I was being dumb and lazy, make backups!

Shut down the remaining VMs, set it to maintenance mode and shut her down.

Swap out the old RAID card, replace it with the new one. Ensure the battery is hooked up and the cabling is set correctly – SAS A to SAS A etc.

Boot it back up, then use this guide to live-patch your host to get the drivers etc for your new RAID card (h700). It’s going to take a while to finish, reboot afterwards.

Upon booting up, hit ctrl+r to get back to the RAID configuration. It will complain that all your drives are lost, don’t worry. Hit c to load configuration and y to confirm.

When you’re in the RAID config, hit F2 and import foreign config. This will load the previous config on your drives.

Now, this part is important. I don’t know why, but sometimes it requires the RAID to be rebuilt despite nothing changing. Two of my servers didn’t need to, two did – go figure. If it does, it will automatically start an operation in the RAID config screen called back init. For me, this took around 35 minutes however if you have a much larger setup it’s obviously going to take longer.

So when that’s finished – or if you didn’t need to rebuild, lets get that datastore back on ESXi!

After rebooting again and letting it boot up, you’ll probably get quite a fright that your datastore isn’t there and all VMs are throwing errors – to add to it too in ESXi you can’t even see the datastore to add it!

This is where VSphere VCenter comes in (the naming structure of this kills me).

Login to VCenter and navigate to your host, click on ‘Actions’ -> ‘Storage’ -> ‘New Datastore’.

Select your datastore type, hit next and it should show up here.

From the list of LUNs, select the LUN that has a datastore name displayed in the VMFS Label column.

Note: The name present in the VMFS Label column indicates that the LUN is a copy that contains a copy of an existing VMFS datastore.

Under Mount Options, you’ll be looking for this option Keep Existing Signature: Persistently mount the LUN

Review & finish – If you hop back to ESXi your VMs should all be populated again – on a sidenote you may need to reconfigure globallogging again if that’s something you do.

To do this go to ESXi -> ‘Manage’ -> ‘System’ -> ‘Advanced Settings’ and search for Syslog.global.logDir

Set it up like so, swap my datastore name for yours and you’re all done.

If I had a penny for everytime this happened to me..

Anyways, resetting it isn’t that bad. Login to vcenter appliance management admin and enable SSH access.

Go ahead and SSH in with the appliance management password and follow these steps;

Enable shell shell.set --enabled true.
Type shell and hit enter.
Next, /usr/lib/vmware-vmdir/bin/vdcadmintool

This will popup an options list, select 3 for reset password.
Input your vcenter username, might be something like ‘[email protected]’
It will give you a temporary password, copy and paste that back to vcenter to get logged in, then set a new password.

Back in shell, type 0 to exit the options and exit again to surprise, close out your session.
Go back to vcenter appliance management and disable SSH access, all done.

I made the mistake of skipping the FQDN when setting this up thinking I could just set it afterwards, was too lazy to update my dnsmasq entries. On the bright side, updating it isn’t so bad.

Login to vCenter, hop to access and click ‘Edit’ up in the top right hand side.

Login via SSH, type shell to open a new bash screen.

/opt/vmware/share/vami/vami_config_net

Hit 3 for hostname, type in the new value you want and hit enter, then 1 to exit.

This does not require a reboot or anything either, nice!

Ensure your internal DNS reflects the new settings and you're good to go.