As mentioned in my last post I decided to go with Proxmox. While there are plenty of other options out there, I found Proxmox to be the simplest to run on a single host while also maintaining clustering ability. I also like the built in backup capabilities. The fact that it’s based on Debian is also an appeal as it’s a platform I am already familiar with. I’d prefer not to have to rebuild the server again for the life of the hardware. Having a stable and reliable base platform is therefore a priority.

Planning For The Move

My key priorities during the move were to keep the internet up as much as possible and to not lose data. For the first part, I built a new router VM on my spare (and very noisy) Supermicro 6017R. I chose to use VyOS for this and was sufficiently impressed with it that it has now replaced pfSense as my main router OS. I’ll have a lot more to say about it in future posts.

I do eventually want to rebuild all my home infrastructure and move more services into containers. However, for now I just wanted to move everything over as-is. I can then tackle one service at a time after researching the best options for each situation.

The migration process actually turned out to be much simpler than I expected. Initially I powered down the VMs and copied the contents of /var/lib/libvirt/images onto an external hard drive. I would then later import these into newly created VMs after migrating to Proxmox.

Installing Proxmox

The Proxmox installation process is pretty typical for any Linux installation, just download the ISO, write it to a USB drive and boot from it. You’ll just need to select your boot drive, set a root password and configure a static IP address. Once you boot into the new installation, the console will show the IP/port combination for the web interface.

Configuring Proxmox updates

By default, Proxmox will expect an enterprise subscription and will have the enterprise update repo enabled. In a production environment, a subscription is highly recommended to get access to more thoroughly tested packages and support. For a homelab this is overkill so we need to enable the community repo. In the node settings go to Updates > Repositories. You will see two repositories under the enterprise.proxmox.com domain. Select these repositories and disable them. Next, click Add and click OK to the warning that you don’t have a subscription. Select “No-subscription” and click OK. In the updates tab, click Refresh and Upgrade. Once the updates are installed, reboot the host.

Creating Storage Pools

Once you have signed back in to the web interface, you’ll want to create some storage pools. Proxmox will create a pool automatically on your boot disk. However, storing VMs on separate disks will make life easier in the event that you need to reinstall. I have 5 additional disks in my host, two 1TB SSDs, two 4TB SATA HDDs and one 8TB HDD. I used the 1TB disks for a mirrored ZFS pool for VM boot disks. Then I did the same with the 4TB disks for bulk storage. This can be used for any archival data and for VMs which require a lot of space. The 8TB disk will be used for backup storage. Unfortunately I don’t have enough SATA ports to add a second mirror for this disk so can’t make this redundant. That is something I’d definitely look to reconsider for the next hardware iteration.

Configuring the Network

Next, I set up the network configuration. As the router will be running as a VM, I needed to make a WAN and LAN bridge. I could have used the existing vmbr0 interface as the LAN but in the future I may want to move the management interface to a dedicated vlan. To retain flexibility, I created a separate LAN bridge. I also made a separate Lab bridge to keep any lab traffic well away from anything important. I didn’t add any uplinks for this bridge as it will only be communicating with other VMs.

Separating Resources

One of my main aims for the homelab rebuild was to have plenty of separation between home infrastructure and lab. One way to do this is to have separate resource pools. This creates a simple way to have different permissions for different types of VMs. This will come in particularly handy if I want to experiment with automation in the Proxmox environment. I can create an account which only has permission to touch lab VMs and be confident it wont touch infrastructure. Resource pools are configured in Datacentre > Permissions > Pools. I created two pools, Home and Lab.

Importing Existing VMs to Proxmox

I had worried about importing the existing VMs but it turned out to be far simpler than I expected. I had only copied the disk images so had to re-make the rest of the VM config.

To do this I created the VMs as normal through the web UI. As we already have the boot image, on the OS tab I selected “Do not use any media”. On the Disks tab I deleted the default scsi0 device. I configured the CPU, memory and network as appropriate for the particular VM.

Import the Disk

Once the VM was created, all we need to do is import the disk images. I plugged in the external drive and checked the device name in the node disk settings. In my case it came up as /dev/sdg I hadn’t partitioned it so this was the location I needed to mount. I went to the shell tab and mounted the disk as follows:

mount /dev/sdg /mnt

We then need to import the image into the VM which we can do as follows:

qm disk import <vm id> <image path> <storage pool>

The disk import process will make a copy of the image to the storage pool. It will create it as a new disk so don’t worry about overwriting any existing disks. Depending on the image size and storage speed, the import may take a while. If you use the shell interface in the web UI, navigating away from the shell will cancel the import. You may find it easier to run the commands over SSH or use the nohup command if you have large disks to import.

Attach the Disk

In the VM settings, you should now see an unused disk in the Hardware tab. Click on this disk and click Edit. If it is a Linux VM, change the Bus/Device setting to VirtIO Block for improved disk performance. Windows requires additional drivers to support VirtIO so if you don’t have them installed, stick with one of the other options. Once you are happy with the settings, click Add.

Go to the Options tab and double click on Boot Order. You should now see your new disk at the bottom of the list. Check the box to enable the disk and drag it to the top of the list. You are now ready to boot the VM.

For now I have significantly scaled back what was running so I just have a router, UniFi controller and file server. I will probably add PiHole back at a later date but for now I want to keep things simple. I also made the decision to not host email at home any more. It’s stressful enough having to manage mail servers at work and I don’t want to have to do it at home too. Hosting email in the cloud should mean it’s online more often. If you’ve sent me an email and got a delivery failure, I’m sorry and this shouldn’t happen in future.

Next steps

So far I have got to the point that my existing infrastructure is running on a more manageable platform, this will make it easier to make incremental changes later so expect more updates in future. I have already replaced my pfSense router with VyOS and implemented the Proxmox Backup Server but this post is long enough already so these will be covered in future updates.

The post Homelab Upgrade Project #2: A New Start with Proxmox appeared first on David's Homelab.

The simplest way to regain this redundancy is just to run 2 independent Pi-hole servers and set them as the primary and fallback DNS servers. However, this approach has a couple of disadvantages. The main problem is that we have no setting synchronisation between our servers. If we update the block lists on one, we have to remember to update them on the other. We also can’t guarantee which server clients will connect to, so if one is down, clients may still try to connect and then have to wait for a timeout before querying the second server. This can cause performance drops when one of the servers is offline.

Using failover to provide a highly available Pi-hole cluster

We can resolve these problems by linking our pair of Pi-hole servers into a unified failover cluster. The original idea for this came from u/Panja0 on Reddit. However, this approach doesn’t quite work on Pi-hole 5 and above as the way the data is saved changed. This article is therefore an updated version of that basic idea to remain compatible with the latest Pi-hole versions.

To accomplish our goal we need to solve 2 problems. Firstly, we need a way to keep the blocklists and settings in sync between the 2 Pi-hole servers. We then need a mechanism to monitor the servers and hand over the IP address if the primary fails. If you are unconcerned about DNS timeouts, you can skip the IP failover setup and just have 2 servers on their own IP addresses. For the greatest reliability, you will want to configure both stages.

What do we need?

You will need 2 Pi-hole servers, ideally updated to the latest version but anything greater than 5.0 should work. You can update an existing instance to the latest version by running sudo pihole updatePihole. Note that this will restart the DNS resolver. I will not cover how to set up a Pi-hole server as I have described it previously. This article is a few years old so you will probably want to use a more recent OS such as Ubuntu 20.04LTS but the installation process is more or less unchanged. For a more recent guide, you can look at this article or the Pi-hole documentation. I will assume the use of a Debian/Ubuntu based distro for this guide but it should be easily adaptable for CentOS.

You will also need a third IP address which will be shared between the 2 servers.

Synchronising Pi-hole blocklists

Pi-hole 5 no-longer stores the blocklists in plain text files. Instead they are stored in a SQLite database in /etc/pihole/gravity.db. This means we can’t use Panja0’s original method of using rsync to synchronise the list files. Instead, we use Michael Stanclift’s (vmstan on GitHub) gravity-sync script.

This script will synchronise blocklists, exclusions and local DNS records. It won’t synchronise admin passwords, upstream DNS servers, DHCP leases and statistics. We will therefore need to manually configure the admin password and upstream DNS servers to be the same on both servers. There isn’t a practical way to have DHCP on the Pi-hole so that will have to run on the router or some other device.

Preparing the Pi-hole servers

To begin with, ensure all dependencies are installed. Most will already be installed but if not, we can catch them by running:

apt update && apt install sqlite3 sudo git rsync ssh

On both servers, we will need a service account with sudo privileges. Create this account by running the following command on each server:

sudo useradd -G sudo -m pi
sudo passwd pi

On some distros (e.g. CentOS), the privileged group is called wheel instead of sudo so you may need to adjust this command.

Install Gravity-Sync on the primary Pi-hole

Pick one of the servers to act as the primary and log in to it as the pi user account. Run the installer script:

export GS_INSTALL=primary && curl -sSL https://gravity.vmstan.com/ | bash

Install Gravity-Sync on the secondary Pi-hole

Log in to the other server as the pi account and run:

export GS_INSTALL=secondary && curl -sSL https://gravity.vmstan.com/ | bash

While the installer on the primary just verifies pre-requisites, the secondary needs additional configuration as it performs the active role of replication. When prompted, provide the name of the service account on the primary, the IP address of the primary and configure password-less SSH login.

Verify connectivity and enable synchronisation

On the secondary Pi-hole, navigate in to the gravity-sync directory and run:

./gravity-sync.sh compare

This should give you output similar to the below. It will not actually perform a sync but will verify connectivity and detect if a sync is required.

If the primary already has configuration but the secondary is a fresh install you will want to ensure that the first sync is a one-way sync from the primary to the secondary. If you don’t do this, the script may detect the configuration on the secondary as newer and overwrite the primary. To force a one way sync, run:

./gravity-sync.sh pull

Finally, enable automatic synchronisation by running:

./gravity-sync.sh automate

Set an update frequency from the available options. Setting a lower frequency will increase the risk of changes not syncing but will result in reduced server load so may be more appropriate on busy servers.

Synchronisation should now be working, if you do not want to configure IP failover the setup is now complete. If you have additional servers you want to keep in sync, use the steps for adding a secondary server.

Configure IP failover

Now our Pi-hole instances are in sync, we can configure IP failover to direct traffic towards the primary when it is available and switch over to the secondary if the primary ever fails. On both servers, install the required packages:

sudo apt install keepalived libipset13 -y

Next, we need to download a script on both servers to monitor the status of the pihole-FTL service so we can fail over if it ever stops running:

sudo mkdir /etc/scripts
sudo sh -c "curl https://pastebin.com/raw/npw6tcuk | tr -d '\r' > /etc/scripts/chk_ftl"
sudo chmod +x /etc/scripts/chk_ftl

Now, we need to add our keepalived configuration. On the primary, run:

sudo curl https://pastebin.com/raw/nsBnkShi -o /etc/keepalived/keepalived.conf

and on the secondary:

sudo curl https://pastebin.com/raw/HbdsUc07 -o /etc/keepalived/keepalived.conf

We now need to edit the configuration on both servers. On each server, set the following properties:

We are now ready to start and enable keepalived. On both servers, run:

systemctl enable --now keepalived.service
systemctl status keepalived.service

You should see a status of active. If you don’t see this, you most likely have an error in your config and the status message should give you a hint as to where it is. Additionally, on the primary server, you should see that it has placed itself into the master role.

Testing Pi-hole failover

You should now be able to reach the Pi-hole interface on the virtual IP we configured previously (e.g. http://192.168.1.20/admin). In the top right corner of the interface it will show the hostname and you should see that it is the primary server. To check that failover is working, shut down the primary server. If you reload the page you should see that the hostname in the top right has changed to the name of the secondary.

You can also test DNS requests using nslookup. The following script will make a DNS lookup every second, allowing you to verify that you receive responses even if the primary is offline:

while true; do
nslookup davidshomelab.com [virtual IP of Pi-hole cluster]
sleep 1
done

If you shut down pihole1 while this script is running you should see that DNS lookups are not interrupted. There may be a brief moment of interruption at the exact moment that the failover occurs but it should resume within around a second.

The post Pi-hole failover using Gravity Sync and Keepalived appeared first on David's Homelab.

What is tar?

Tar, originally standing for tape archive is the traditional archiving utility on most UNIX-like systems. On modern systems without tape drives, you would usually save archives to a file instead of tape. Unlike the zip format, which both combines and compresses files, tar only combines files. Compression is performed separately using a utility such as gzip or bzip2. However, you can use the tar command to perform both the archiving and compression in one go.

Creating an archive

You can create an archive using the --create flag (c in the short format). One caveat is that if the archive file already exists, attempting to create a new archive will overwrite it. This can cause problems if you invert the order of your source files and your archive as you may end up replacing your source files. The easiest way to remember this is to think about the command using long form flags. For example:

tar --create --file example.tar file1 file2 file3

In this example it should be clear that the --file (f) flag indicates the output file. The input files are specified at the end of the command. Once you understand the syntax, you can use the short form version of the command:

tar cf example.tar file1 file2 file3

Files will be added to the archive using the full provided path excluding the leading /. For example, if you ran

tar cf example.tar /tmp/{file1,file2}

and then extracted the archive, a folder called “tmp” would be created in your extraction location. The files would be placed in that folder.

Extracting an archive

Once you have created an archive, the next thing you will want to do is extract it. The command to do this is almost the same as the command to create an archive. Except the --extract (x) flag is used:

tar xf example.tar

If you just need to extract certain files, you can specify them at the end of the command:

tar xf example.tar file1 file2

If you are specifying files you will need to specify the full path location in the archive. For example:

tar xf example.tar tmp/example/file1

Extracted file paths are always relative to the current working directory.

All about compression

As discussed, tar archives are uncompressed by default but compression can be enabled if desired. The short options for some of the compression algorithms can be a little confusing but there are also long options. The table below shows all the available compression algorithms.

Additionally, if you use the --auto-compress (a) flag, tar will automatically detect the right compression algorithm based on the file extension:

tar caf example.tar.gz file1

When extracting an archive, the compression algorithm can be specified but if omitted will be detected from the file name.

Inspecting the contents of tar archives

If you want to list the contents of an archive you can use the --list (t) flag. You will still need to use the f flag to indicate that the archive you want to list is a file:

tar tf example.tar
------------------------------------
file1
file2
file3

If the archive contains subfolders, the full path will be listed. This can be useful if you need to modify an archive or extract only a couple of files.

Modifying tar archives

Adding more files

You can add additional files to an existing archive using the --append (r) flag. This flag uses the same syntax as --create:

tar rf example.tar file3

Updating an archive

The --update (u) flag is used to update an archive by only appending files that either don’t exist in the archive or which have been modified since the archive was created. Updated files will not actually replace the old copies of the file in the archive. Instead you will get multiple copies of the file with the same name. This presents a difficulty when extracting the archive in determining which copy of the file you will get. When an archive is extracted, files are processed in the order that they appear in the archive. This means that the newest copy of the file will always be extracted unless another version is specified. You can use the --occurrence flag to specify which version of the file to use. For example, the following command will extract the 3rd instance of file1:

tar xf example.tar file1 --occurrence=3

Removing a file

You can remove files from an uncompressed archive using the --delete flag. There is no way to remove a file from a compressed archive.

tar f example.tar --delete file1

Other useful actions

When creating or extracting an archive, you might want to see the names of the files being processed. You can do this using the --verbose (v) flag.

You can combine multiple archives together using --concatenate (A):

tar Af example1.tar example2.tar example3.tar

In the above example, the contents of example2.tar and example3.tar will be appended to example1.tar

There are many other options which can be used to accomplish different tasks but the above commands should cover most common situations. You can find the full list of commands in the man page and, even if you are using different options, you can use the above commands as skeletons to be modified for the more advanced options.

The post Tar on Linux – File Storage and Retrieval appeared first on David's Homelab.

Many larger homes end up using multiple separate access points with a mix of repeaters. This results in a confusing mix of networks with devices connecting to a sub-optimal AP, causing weak signal. UniFi resolves this by managing all access points from a central controller and treating them as a single network. This saves you having to join your devices to several different networks and allows the APs to intelligently hand devices off to each other as you roam around the house. This ensues that you are always communicating with the AP that has the strongest signal.

UniFi can act solely as an access point without performing NAT. This means that unlike mesh WiFi systems which are traditionally used to expand coverage in a home setting, you shouldn’t run in to communications issues between wireless and wired devices in your home.

Why not another product?

While there are plenty of other good products on the market, there are several reasons why UniFi is a strong contender. When compared to other commercial solutions, UniFi hardware is priced very reasonably and is widely available from consumer outlets. This means you don’t need to procure hardware through trade-specific distribution networks. One other advantage is the simplicity of setting up devices. Once you have the controller set up, you can add new devices by adding them to the network. They will appear in the dashboard and can you can easily configure them in just a few clicks.

For me, the flexibility around the controller software is the key selling point. Some providers require you to buy an expensive hardware controller in addition to the APs. Other systems can only be managed from the cloud which some people may view as a security risk. The UniFi controller can instead be installed on any Windows, Mac or Ubuntu PC (or VM), allowing you to run it on hardware you already have. That’s not to say that you can’t run it in the cloud or have a dedicated controller. UniFi provide various models of CloudKey(paid link) for users who wish to avoid the effort of building their own controller. The basic model will be sufficient for any home or office with fewer than a couple of dozen managed devices. Additionally, while not owned by UniFi, the HostiFi company offers cloud hosted controllers requiring no on-premisies management hardware.

Setting up the UniFi controller on Ubuntu

While the controller software can be installed on any PC, a dedicated server will simplify management. Windows and Ubuntu are both supported but Ubuntu is preferred due to its lack of licensing costs and smaller footprint. The instructions provided here are for Ubuntu Server 20.04. While an LTS version of Ubuntu Server is preferred, any recent version of Ubuntu Server or Desktop can be used.

The system requirements depend on the number of managed devices but 1 CPU core, 2GB of RAM and 25GB of storage should be enough in most cases. The UniFi controller software isn’t in the main Ubuntu repos so we need to add the correct repo. We must also install the GPG keys so the repo is trusted:

echo 'deb https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list
sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg https://dl.ui.com/unifi/unifi-repo.gpg 

Next, update the apt cache and install the UniFi controller along with its prerequisites:

sudo apt update && sudo apt install ca-certificates openjdk-8-jdk apt-transport-https unifi -y

Once the install is finished, check that the service is running:

systemctl status unifi.service

If the service shows as failed or not running, restart the service with:

sudo systemctl restart unifi.service

Configuring the UniFi controller

Check the status again and verify that the service is running. Once everything is up and running, open a web browser and go to https://[server&/#8217;s IP address]:8443. You will need to accept the self-signed certificate warning.

Next, chose a name for your controller and accept the terms and conditions.

On the next screen, sign in with your UniFi account. If you want to be able to access your controller through Unifi’s cloud enter your login details here.

If you want to keep your controller local to your network, set up a local account, click “Switch to Advanced Setup”. Uncheck both checkboxes and set up a local username and password.

On the next screen, leave auto backup and network optimisation enabled.

Installing on an Ubuntu server is one of the simplest and cheapest ways to deploy the UniFi controller.

If you already have your devices, you can now choose to set them up. If you are just setting up the controller in preparation for receiving the devices, you can add them later.

Enter a WiFi network name and password. If you plan to have multiple SSIDs you can add the rest later, just enter your primary one here.

Finally, confirm your settings and set your location and time zone.

The wizard will redirect you to the main dashboard and your network will be set up.

There is plenty more you can do with UniFi hardware such as having multiple SSIDs on separate vlans, captive portal and MAC address based vlan assignments. Come back soon for more guides.

The post UniFi Controller Setup on Ubuntu 20.04LTS appeared first on David's Homelab.

Install the Zabbix Proxy plug-in

In the pfSense management console, go to System > Package Manager > Available Packages and search for “zabbix-proxy”. You will see multiple different versions. Unlike the agent, the proxy must be the same version as the server so select the appropriate one for your server. In this case we will install zabbix-proxy5.

Connect the proxy to the server

In the pfSense console go to Services > Zabbix Proxy 5.0 and configure the proxy. Set the server to the IP address or hostname of the Zabbix server and the hostname to whatever you will call the proxy within the Zabbix console. The other options can be left as default but can be modified if desired. For example, if you only want the proxy to listen on one interface, set the listen IP to the pfSense IP address for the interface you want to listen on. If you have a large number of proxies you can increase this value to reduce load on the server but doing so will increase the propagation time for any changes you make to your setup.

While testing or for small deployments you may wish to lower the config frequency from the default of 1 hour. This value determines how often the proxy will contact the server to get the current configuration, including the hosts to monitor and the data it is supposed to collect.

Finally, enable the service and save the settings.

Now the proxy is configured it is time to tell the server where to find it. From the Zabbix console, go to Administration > Proxies. Click “Create proxy” to add the new proxy. Enter the name (this is the hostname you configured in the proxy) and the IP address of the proxy.

Once you have added the proxy, reload the page and check that the proxy shows up in the list and it has a “last seen” value. If all is well and the listing shows something similar to the below, the proxy is set up and we are ready to configure hosts to talk to it.

Configure the proxy to monitor hosts

Configuring an agent to use a proxy is very similar to configuring it to talk to the server directly. For this example I will modify the CentOS host described in my post on configuring Zabbix agents to get it to talk via the proxy.

Log in to the server and open /etc/zabbix/zabbix_agent.conf. Edit the Server and ServerActive values to the IP address or hostname of the Zabbix proxy and save and close the file. Restart the Zabbix agent:

systemctl restart zabbix-agent.service

Now log in to the Zabbix console and go to Configuration > Hosts and select the host you want to monitor via the proxy. In the host settings, click the drop-down next to “Monitored by proxy” and select the proxy you have configured the host to talk to. Click “Update” to save your settings.

When you return to the hosts list you will probably see that the host appears to be offline. This is because the proxy will not find out that it is meant to be monitoring the host until the next time it syncs its settings with the server. If you have set a reasonable update frequency you will just need to wait for that period of time and it should start to appear and collect data automatically.

If you need to force the proxy to update immediately, log in to pfSense and go to Status > Services and restart the zabbix_proxy service. When the service starts up this will force a config sync and you should see the host come online within a couple of seconds after the service restarts.

The post Install Zabbix Proxy on pfSense to Monitor Hosts in Remote Sites appeared first on David's Homelab.

I will be upgrading the Zabbix server I set up in my previous tutorials on Zabbix so this guide assumes a CentOS 8 operating system. With the exception of the package manager commands, the steps should be more or less the same on any Linux distribution.

Update your system

Before making major changes it is worth making sure the base system is up to date to make sure there aren’t any issues arising from using older packages. Run the following commands to update and reboot the system.

dnf upgrade
reboot

Back up your current installation

While the upgrade process shouldn’t cause too many problems, it will make changes to your database and overwrite the old installation. In the event that this process runs into an error or the machine crashes or loses power while the upgrade is in progress, having a backup of your database and configuration files will make recovery a lot easier.

Create a directory to store all your backups:

mkdir /opt/zabbix-backup
cd /opt/zabbix-backup

Now we will need to stop the Zabbix server to ensure that the database remains in a consistent state while we are performing the backups. Run the following commands to stop Zabbix and write the database to a file:

systemctl stop zabbix-server.service
mysqldump -u[zabbix-user] -p [zabbix database] > zabbix-database.sql

For the mysqldump command, you will need to enter the names of the Zabbix database user and the database in the appropriate places. If you do not remember what these are, check in /etc/zabbix/zabbix_server.conf. The lines you are looking for are DBName, DBUser and DBPassword.

You will also want to back up your configuration files as follows:

cp /etc/zabbix/zabbix_server.conf /opt/zabbix-backup/
cp /etc/httpd/conf.d/zabbix.conf  /opt/zabbix-backup/
cp -R /usr/share/zabbix/ /opt/zabbix-backup/
cp -R /usr/share/doc/zabbix-* /opt/zabbix-backup/

Update Zabbix

Install the new repo by running the following commands:

rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm
dnf clean all 

If you are not running CentOS 8, check the Zabbix download page for the link the the correct repo for your distribution and the required commands to install it.

This will remove the old 4.0 repo from your system and replace it with the 5.0 repo. Now you can just upgrade your Zabbix packages as follows:

yum upgrade zabbix*

If the update installs without errors, restart the Zabbix server and agent as follows:

systemctl restart zabbix-server.service
systemctl restart zabbix-agent.service

Copy the Apache config file back to its original location and restart Apache:

cp /opt/zabbix-backup/zabbix.conf /etc/httpd/conf.d/
systemctl restart httpd

You should now be able to log in to the Zabbix web console. You’ll see that the UI now has the navigation menus on the left hand side and the version number at the bottom has changed to 5.0.1. If the page doesn’t load correctly, clear your browser cache and cookies and try again.

The post Upgrade Zabbix Server to 5.0 LTS appeared first on David's Homelab.

Preparing to update

The most important thing to do before updating is to create a backup. There are a few ways this can be done, if you are running Nextcloud in a virtual machine you can just create a snapshot of the VM. If you are running on a physical server, the two things you need to back up are the webroot and the database.

The first step is to enable maintenance mode, this stops users from logging in to Nextcloud and reduces the risk that anything will change while you’re running the backup, leaving the installation in an inconsistent state in the event that you need to restore. You can enter maintenance mode by running the following command:

sudo -u www-data php /var/www/html/nextcloud/occ maintenance:mode --on

Note that this must be done as the user the web server runs as. The above command will work for Ubuntu but if you are using a different distribution the web server user might not be “www-data” so you will need to adjust accordingly. If you are unsure, run ls -l /var/www/html/nextcloud and see who owns the files. Additionally the occ program is in the Nextcloud webroot so if you have installed Nextcloud somewhere other than /var/www/html/nextcloud you will also need to adjust this part of the command

Once you have run this command go to your Nextcloud URL in a browser and verify that logins have been disabled. You will see a warning that the host is in maintenance mode.

You can now run the following commands to back up your files and database. As before, take note to adjust any file paths or usernames:

sudo tar -czf NextCloud-backup-$(date -I).tar.gz /var/www/html/nextcloud/

The above command will create a compressed archive of your full Nextcloud install directory and place it in your current working directory. If you wish you can offload this file to another system using rsync or sftp but as long as it is not created inside /var/www/html/nextcloud the installer shouldn’t touch it so it should be safe.

We now run the next command to back up our database to a file in the current directory:

sudo mysqldump --single-transaction -u[username] -p[password] [databse name] > NextCloud-db-$(date -I).sqlbak

If you have set up your Nextcloud installation using my previous guide your username and database name will probably both be “nextcloud” but if your setup is different you will need to adjust accordingly. Additionally, if your database is not running on localhost you will need to specify the database location using the -h [hostname] flag. If the command is successful you should see a file in your current directory with a .sqlbak extension. This is a text file containing all the MySQL commands you would need to recreate the database in its current form. If a restore is needed, you will need to drop and recreate the existing database and then pipe the sql commands into the MySQL client as follows:

sudo mysql -u[username] -p[password] -e "DROP DATABASE nextcloud"
sudo mysql -u[username] -p[password] -e "CREATE DATABASE nextcloud"
sudo mysql -u[username] -p[password] [db_name] < [backupfilename].sqlbak

Installing the update

Now our files and database are safely backed up, we can proceed with the update process. The easiest way to do this is via the web interface, meaning we will need to disable maintenance mode:

sudo -u www-data php /var/www/html/nextcloud/occ maintenance:mode --off

Now when we go to the web page we see that functionality has returned to normal and we will be able to log in. You will need to log in as the admin user to perform the update so if you normally work as a non admin user (you should be doing this) you will need to log out and back in as the admin.

Click your user icon in the top right corner to go to the settings page. From here you will need to go to the “Overview” screen and click “Open updater”

From the update screen you will be able to install the update. For the most part the installation is automatic and it will show you the steps it is taking and warn you if there are any problems which need manual intervention. You most likely won’t have any issues but if you do you should be able to find a solution on Google or leave me a comment and I will do my best to assist.

If all goes well you will see a screen similar to the one below. You will then be asked if you wish to keep maintenance mode active. As we want to use the web based updater to finish the update, select “no” for this.

You will then be taken to a screen with a list of the apps that need to be updated. As we are updating to a new major version there will be a lot of apps in this list. Just click “Start Update” to begin the installation. Note that at the bottom of the list you will see a list of incompatible apps which will be disabled if you go ahead with the update. If you rely on any of these apps you should not proceed with the update and should instead restore your Nextcloud deployment from the backups we created.

Once complete you will be given the option to view a detailed log of the installation process or just continue to your new Nextcloud installation. If everything has gone well with the update, you should be returned to the main login screen or your main home screen if you are already logged in. The look and feel of Nextcloud 17 is very similar to Nextcloud 16 as most of the changes focus on additional performance and security improvements. For the full list of changes, check out this article on the Nextcloud blog.

The post Updating Nextcloud to 17.0.2 appeared first on David's Homelab.