0

Homelab vSphere 6.7u3 experience

About 18 months ago I wrote a post on my experience upgrading my homelab from vSphere 6.5 to vSphere 6.7. Since that time it has had a few rebuilds and reconfigurations, been off for several months, been idle, been busy and generally just worked. The one constant though was the build of ESXi that I was using. It was always 6.7 GA.

Having been switched off for some time, I brought it back up over the Christmas break after a long lunch with homelab hero @virtualhobbit. The point of this post is not the reasons why my lab has come back to life (I’ll cover that at some point), but about how I got it updated to the latest version of vSphere.

As a recap, and to save anyone reading my previous post, my lab is constructed from Dell workstations that don’t appear on the HCLs for VMware. As any homelabber will attest, sometimes compromises have to be made to run your own lab. In my case, updates aren’t as straightforward as they should be but that’s offset by the cheaper cost and age of the hardware. That said, I will most likely not be able to run the next version of vSphere owing to the deprecation of the vmklinux driver stack.

Coming back to the topic in hand, vSphere Update Manager tends to complain when I use it owing to my unsupported processors. Updating my hosts via esxcli however still works. My first attempt at an update was not successful however. I had downloaded the offline update bundle from VMware’s site and placed it on a shared VMFS datastore.

But I was met with the following error when I tried to apply it:

Maybe my esxcli is rusty. Luckily there’s another way if you have ESXI hosts that can connect to the internet. The first step is to open up the hosts’s firewall so it can connect out:

Next, to prove connectivity and get the correct update name, the following command can be use to list the available software profiles:

The “grep” command at the end can be adjusted to filter the results. You don’t want to soft through EVERY update available.

In my case that returned me four results:

The second entry is the one that I wanted. To apply it, just pop the name of the profile in to the following command:

If the update is successful (it can take a few minutes, be patient), you should see something like this (I’ve truncated the output as it’s a bit long):

All that remains in theory is to close the firewall access off and reboot the host:

That worked for two of my hosts. But the third refused to play ball. When I tried to apply the update I got an error.

This was pretty simple to solve by adjusting the system swap settings for the host through vCenter. Head to the Configure tab for the host and locate “System Swap”. Edit the settings, and enable the host to use a specific datastore (the first option below).

I retried the update and it went through. vCenter updates were applied via the normal mechanisms (https://vcenter-fqdn:5480).

0

Installing SQUID on a Synology NAS

I’m not going to go into exactly why (it’s a minor networking niggle following on from a change in broadband provider) but I wanted a simple HTTP proxy in my lab so that my lab VMs could get out on to the internet. Mostly for installing updates etc.

Since my NAS is ideally placed in my network I thought that I’d use that. It’s only a short-term thing anyway.

Now in order to get a proxy service on to the NAS, I needed to setup IPKG first. This allowed me to install and configure SQUID as follows:

1. Open an SSH session to the NAS

2. Download and install SQUID

[text]ipkg install squid[/text]

3. Perform a couple of configuration commands

[text]squid -k parse
squid -z
ln -s /opt/etc/init.d/S80squid /usr/syno/etc/rc.d/[/text]

4. SQUID can now be started using /opt/etc/init.d/S80squid start

Now there may be some additional changes you might want to make. By default SQUID will accept connections from a standard set of internal networks as follows:

[text]acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network[/text]

However, you may want to tie this down for one reason or another. For me, I’m not too bothered. Any changes can be done by editing /opt/etc/squid/squid.conf.

Want to check that it works? I configured the proxy config in my VM as follows:

CapturFiles-201409248_110961

And then monitored the proxy access file using tail:

[text]tail -f /opt/var/squid/logs/access.log
1409911439.044    141 192.168.100.151 TCP_MISS/200 405 HEAD http://download.windowsupdate.com/v9/windowsupdate/redir/muv4wuredir.cab? – DIRECT/80.239.217.24 application/octet-stream
1409911439.138     80 192.168.100.151 TCP_MISS/200 24017 GET http://download.windowsupdate.com/v9/windowsupdate/redir/muv4wuredir.cab? – DIRECT/80.239.217.24 application/octet-stream
1409911445.219     46 192.168.100.151 TCP_MISS/200 405 HEAD http://ds.download.windowsupdate.com/v11/3/windowsupdate/selfupdate/WSUS3/x64/Win7SP1/wsus3setup.cab? – DIRECT/213.120.161.243 application/octet-stream
1409911445.246     16 192.168.100.151 TCP_MISS/200 34418 GET http://ds.download.windowsupdate.com/v11/3/windowsupdate/selfupdate/WSUS3/x64/Win7SP1/wsus3setup.cab? – DIRECT/213.120.161.243 application/octet-stream[/text]

0

How to install IPKG on a Synology NAS

Sometimes you want to install “community” or third party packages on your Synology NAS and they require IPKG (Itsy Package Management System) to be present. Instruction about how to go about this seem to vary and are often specific for the CPU inside your NAS. The easiest method that I’ve found for getting IPKG installed is as follows…

First job is to open an SSH session to the NAS and confirm what type of processor it has. This can be done using the following command:

[text]cat /proc/cpuinfo | grep model[/text]

For my DS1513+ it returns:

[text]model: 54
model name: Intel(R) Atom(TM) CPU D2701   @ 2.13GHz
model: 54
model name: Intel(R) Atom(TM) CPU D2701   @ 2.13GHz
model: 54
model name: Intel(R) Atom(TM) CPU D2701   @ 2.13GHz
model: 54
model name: Intel(R) Atom(TM) CPU D2701   @ 2.13GHz[/text]

Next you need to dig around the site http://ipkg.nslu2-linux.org/feeds/optware/ to find the correct bootstrap for your architecture. In my case it’s at http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh.

To install it, there are a couple of steps…

1. Within your SSH session, change to a temporary location (note that you will probably need to be logged in as root to do all this)

[text]cd /tmp[/text]

2. Download the bootstrap script

[text]wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh[/text]

3. Make the file executable

[text] chmod +x syno-i686-bootstrap_1.2-7_i686.xsh[/text]

4. Run the script

[text]sh syno-i686-bootstrap_1.2-7_i686.xsh[/text]

5. If it all went well, remove the script

[text]rm syno-i686-bootstrap_1.2-7_i686.xsh[/text]

6. Update the package list

[text]ipkg update[/text]

Well done, you’re now ready to install custom packages via ipkg.