While the process of moving users between AD forests using the AD migration tool is relatively straightforward, I had struggled to find any documentation on how to ensure the migrated users would continue to match up with their Entra ID counterparts.

How Entra Connect Identifies Users

When the synchronization service identifies a new user account in Active Directory it will pass the user attributes to Entra ID to create a new user. One of these attributes is “sourceAnchor” which by default is a base64 encoded copy of the on premises user’s GUID.

While the sourceAnchor is based on the user’s GUID, it does not map directly to the GUID. This will be useful later as it will allow us to match up the account with a new on premises account. Instead, the sourceAnchor maps to “mS-DS-ConsistencyGuid” in on premises AD. The value here does not exactly match that in “sourceAnchor” as the “sourceAnchor” is base64 encoded and “mS-DS-ConsistencyGuid” is hex encoded but if converted to the same format they will be the same. Note, “mS-DS-ConsistencyGuid” is only populated after the second sync cycle so for the below process to work, the user must have existed for at least 2 sync cycles. This will be true for almost all production cases but is worth bearing in mind for testing.

One other important factor to note about the second sync is that for the on premises delta import, we also see an Add operation corresponding to our user account. If we look in the attributes for this sync we see that the object does not contain “mS-DS-ConsistencyGuid”. This is because the purpose of this operation is not to write data back to AD, it is to confirm to the sync service that the previous add operation has been successful. If it does not see the original object returned it will assume that the original export has failed and attempt it again.

Migrating a User

As we have seen, when the Entra Sync Service runs it will match on premises and cloud users based on their “mS-DS-ConsistencyGuid”. This means that if we want to sync an Entra ID user with a different on premises user we simply need to ensure that the new on premises user has the same “mS-DS-ConsistencyGuid”. Our other concern is that we do not want the Synchronization Service in multiple directories to be syncing the same user. If this were to happen, each time a sync ran, that directory’s attributes would overwrite the other directory’s attributes causing the account to flip flop between two states.

Prerequisites

Prior to beginning a user migration there are some prerequisites to check. These will simplify the process and reduce the risk of errors or duplicated accounts.

The first prerequisite to check is that the source anchor is actually set to “mS-DS-ConsistencyGuid”. This is the default configuration but can be configured when Entra Sync is first set up. While there are ways to change this later they are complex and beyond the scope of this article. In Microsoft Azure Active Directory Connect, select “View or export current configuration” and click “Next”. Under Synchronization Settings you should see the source anchor attribute, this should be set to “mS-DS-ConsistencyGuid”. If it is set to something else, this migration method will likely be impossible.

In the original AD forest, you will need an OU which is not synced to Entra ID. This will allow you to remove users from the sync without deleting them. If no such OU exists, open Microsoft Azure Active Directory Connect on the sync server in the original domain and click “Customize Synchronisation Options”. Sign in when prompted and press “Next”. In “Domain and OU filtering”, ensure that at least one OU is unchecked.

You should also check that all users you wish to sync have a value set for “mS-DS-ConsistencyGuid”. If a user does not have this set it may still be possible for them to sync using soft matching based on the UPN or the proxy addresses. Such a configuration will break in a scenario like a domain move as these values would change. The following PowerShell command will identify all users with an empty “mS-DS-ConsistencyGuid”. If any of these are on the list to be synced, you will need to fix them before proceeding.

Get-ADUser -Filter * -Properties "mS-DS-ConsistencyGuid" | Where-Object "mS-DS-ConsistencyGuid" -eq $null

Finally, before making any changes I would recommend disabling the automatic sync cycle in both the source and target domains. This is not strictly necessary but it will ensure that syncs only occur when you plan for them, making sure that an object won’t be synced at an inopportune moment. To disable syncing, run the following PowerShell command:

Set-ADSyncScheduler -SyncCycleEnabled $false

When you are done and want to re-enable automatic syncing, run:

Set-ADSyncScheduler -SyncCycleEnabled $true

Detaching the Source User

Before creating the user in the target domain, we must break the syncing relationship between the Entra ID user and the old on premises user. To do this we can simply move the user out of a synced OU and then run a sync:

Start-ADSyncSyncCycle -PolicyType Delta

If we now review the sync logs we can see that the user has been deleted from Entra ID.

We can also see in the Entra ID portal that the user has been soft deleted and shows up in the deleted users list.

One caveat to bear in mind here is that, as we discovered during the account creation, the Synchronisation Service will not fully trust that the user has been deleted until the next sync cycle. If we were to migrate the user now, they would be deleted again on the next sync. The trick here is to run the sync command for a second time. When we do this, we see the deletion reflected in the Delta Import, confirming that the deletion has been successful.

We will also see that if we try to view the deleted object, we get an error message.

This occurs because the Synchronisation Service has now fully removed this object from its database. As long as the object doesn’t come back in to scope, the service will not modify it again.

Creating the Target User

There are several ways that the target user can be created. For a production migration the most likely scenario is that you would be using the AD Migration Tool. While this is certainly recommended, an in depth explanation of ADMT is beyond the scope of this article. I will therefore be creating the new user manually. This method has some pitfalls which are not present in ADMT so I will point these out as we go.

Create a new user account in the target domain. The username and details can be the same as in the source domain but this is not necessary. The UPN suffix will almost certainly be different unless you have the same UPNs configured on both domains. If not using ADMT and automatic sync is enabled in the target domain, create the user in a non-synced OU.

In Active Directory Users and Computers, click “View” and ensure “Advanced Features” is checked. Open the newly created user account and go in to the “Attribute Editor” tab. Scroll down to “mS-DS-ConsistencyGuid”. This should currently be blank. Repeat the same process for the user in the source domain and you should see a hex string. Copy and paste this hex string to the new account. This is not necessary when using ADMT as it will sync the attribute automatically.

Once the source anchor is updated, we can now safely sync this account with Entra ID. If it was created in an unsynced OU, move it to a synced OU.

If we run the sync command and look in Entra ID, the user account no longer appears under deleted users. Returning to the All Users page, we see that the user has been re-added as a synced account. The account now uses the UPN suffix we selected in the target domain, confirming it has been synced from the new domain.

If we used ADMT the above process could be simplified as we wouldn’t need to manually set the source anchor. Instead we could simply migrate the user to a synced OU and run a sync.

Conclusion

Having gone through this process it turns out not to be as complex as I initially expected. The main pitfall is that the sync must be run twice on the source domain before setting the user up on the target. Another potential complication is that the user in the source domain could conflict if it were to ever become synced again. While this is unlikely to happen in a scenario where one domain is to be decommissioned, you can guard against it by clearing the “mS-DS-ConsistencyGuid” attribute. In this scenario if the user were to be synced again a new user would be created in Entra ID.

In summary, the steps to perform the process are:

1. Move the user out of a synced OU
2. Run the sync command once and verify that the user is soft deleted in Entra ID
3. Run the sync command a second time
4. Migrate the user to the new domain by whatever means you have chosen
5. Ensure that the “mS-DS-ConsistencyGuid” attribute is the same for the source and target users
6. Run the sync command on the target domain and verify that the Entra ID user is undeleted

The post AD Cross-Forest Migration With Entra ID Sync appeared first on David's Homelab.

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.

To this end, I have identified some pain points with the existing set up and have a plan for how to improve them in the rebuild. Each step will be documented in future articles.

Virtualisation

When I initially started, I used libvirt on Ubuntu as my hypervisor. While this worked pretty well initially there are definitely a few pain points. There is no Windows management client, requiring a Linux PC for managing VMs. The networking is also a bit of a pain to set up compared to a more dedicated hypervisor OS. As I’m running on a single host I don’t want to deal with the additional complication of oVirt so plan to use Proxmox. This will allow me to use grouping to keep production and lab infrastructure separate. I can also use the built in LXC support to create containers for workloads where a full VM isn’t necessary.

To make matters even better, it also has modules for Ansible and Terraform, which will be useful further down the line when I implement configuration management.

IPv6

As my ISP provided IPv4 address is behind CGN, IPv6 has proved useful to allow external access to internal services. However, running IPv4 and IPv6 on the internal LAN has proved to be overly cumbersome and usually resulted in me just sticking with IPv4. This time I plan to go IPv6 only for the LAN, using NAT64 to enable access to IPv4 services.

Configuration Management

Most of my existing resources have been configured manually. This lack of standardisation has resulted in a mix of different operating systems with different base configuration on each device. Going forward, all configuration will be set up using configuration management and stored in source control. This will make it easier to rebuild services, either for disaster recovery or just to make a copy for testing. My current plan is to provision all VMs using Terraform and then manage configuration through Ansible. As much as possible will be run on Docker or Kubernetes.

Redundancy

An advantage to using containers is that stateless workloads can be parallelised, making updates possible with no downtime. While I only have a single host so can’t avoid downtime for host updates, it should be possible to restart or update anything else without causing interruptions to anything critical such as the firewall, DNS or file access.

Monitoring

I had previously run Zabbix but due to the lack of standardisation, managing alert policies for all the different VMs posed an excessive maintenance burden so it started to fall by the wayside. I will rebuild it using a standard set of basic alerts for disk space, updates, expiring SSL certificates etc.

The plan

Initially I will back up all existing VMs and restore them as-is onto Proxmox. I will then begin developing the Kubernetes cluster and migrate all possible workloads onto that. This will require me to come up with some plan for persistent HA SQL and file storage. At this point I will also set up a new Zabbix server and figure out exactly what I want to monitor.

Once all internal workloads are migrated, I will replace the firewall and disable IPv4. Finally I will do a full test of the infrastructure as code by setting up a clone of the network which can be used as the test network. Come back soon for future updates.

The post Homelab Upgrade Project #1: The Plan appeared first on David's Homelab.

We can demonstrate the basic behaviour with the following code:

Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 25
Start-Sleep 0.25
Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 50
Start-Sleep 0.25
Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 75
Start-Sleep 0.25
Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 100
Start-Sleep 0.25

Here, create a progress bar and increment by 25 percent every 0.25 seconds. In real scripts you wouldn’t sleep between steps, this is just for demonstration purposes and would be replaced by your actual tasks.

If we want to have multiple progress bars (perhaps a main bar for the overall script progress and then additional bars for sub-tasks, we just need to provide an -Id parameter to differentiate between the bars. If we don’t provide this then the second one to be created will replace the first one.

Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 25 -Id 0
Write-Progress -Activity "MySecondActivity" -Status "Performing more actions" -PercentComplete 25 -Id 1
Start-Sleep 0.25
Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 50 -Id 0
Write-Progress -Activity "MySecondActivity" -Status "Performing more actions" -PercentComplete 50 -Id 1
Start-Sleep 0.25
Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 75 -Id 0
Write-Progress -Activity "MySecondActivity" -Status "Performing more actions" -PercentComplete 75 -Id 1
Start-Sleep 0.25
Write-Progress -Activity "MyActivity" -Status "Performing actions" -PercentComplete 100 -Id 0
Write-Progress -Activity "MySecondActivity" -Status "Performing more actions" -PercentComplete 100 -Id 1
Start-Sleep 0.25

A disadvantage of this method is that we need to manually specify the percentage complete, meaning that if we change our code, we will need to remember to update how the progress bars are generated. In his blog, Adam Bertram provides a fantastic way to automatically calculate the percentage completion using the PsParser .NET class. I’d highly recommend reading Bertram’s article as it provides a lot of background about how PsParser works that I won’t repeat here. To summarise Adam’s method, he simply parses the script file and counts how many calls are made to Write-Progress and treats this as the number of steps the progress bar needs to handle. For scripts containing only a single progress bar this is fine but if we want to track the progress of multiple tasks we will need something more advanced.

Creating a ProgressBar class

As we are looking to create multiple progress bars which need to keep track of their own internal state (specifically the number of steps completed) we can create a class from which we can generate as many progress bars as we need.

class ProgressBar {

    $completedSteps = 0
    $activity
    $id = 0
    $totalSteps

    ProgressBar(
        [string]$activity,
        [int]$id
    ){
        $this.activity = $activity
        $this.id = $id
    }

    [void] UpdateProgress($status) {
        $percentComplete = ($this.completedSteps / $this.totalSteps) * 100
        Write-Progress -Activity $this.activity -Status $status -PercentComplete $percentComplete -Id $this.id
        $this.completedSteps += 1
    }  
}

This code doesn’t yet automatically count the total number of steps, but once it is provided, it will do most of the rest of the work of tracking the progress. Whenever the UpdateProgress method is called, it will update the status message and increment the completed steps by 1. It will also automatically calculate the percentage completion.

To use this class to create a progress bar we need to create an instance:

[ProgressBar]::new("MyProgressBar",1)

We can now call the UpdateProgress method on this object to create and increment the progress bar:

$progressbar.UpdateProgress("Task1")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task2")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task3")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task4")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task5")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task6")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task7")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task8")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task9")
Start-Sleep 0.25
$progressbar.UpdateProgress("Task10")
Start-Sleep 0.25

If we wanted to create a second progress bar we could simply create a second instance and we would then be able to update the two progress bars independently. We would of course need to make sure both bars have separate ID fields to allow them to be shown independently.

Detecting the number of steps

To detect the number of steps we do something similar to Bertram’s method but instead of counting the number of calls to Write-Progress we need to count the calls to our custom ProgressBar object. I was unable to find a reliable way to determine the variable names we choose for our progress bars so we need to add an additional property to our class to store the name of the variable. We simply add a $variableName property to the class and add it to the constructor so we can use it when creating an object.

Once we have this, we can use Bertram’s method to locate instances of our progress bar variable. One issue I had getting this to work is that $($MyInvocation.MyCommand.Name)doesn’t appear to populate correctly when called inside a class definition so we need to save the script path as a variable outside of the class:

$ScriptFile = Get-Content "$PSScriptRoot\$($MyInvocation.MyCommand.Name)"

We can then scan the script and automatically set the value of $totalSteps:

[int]$totalSteps = ([System.Management.Automation.PsParser]::Tokenize(( $ScriptFile ), [ref]$null) | Where-Object { $_.Type -eq 'Variable' } | Where-Object { $_.Content -eq $variableName }).Count - 1

Putting it all together

Now we are able to detect the names of our progress trackers and scan the script for instances of it, we can put it all together.

Defining our auto-incrementing ProgressBar class

$ScriptFile = Get-Content "$PSScriptRoot\$($MyInvocation.MyCommand.Name)"

class ProgressBar {

    [int]$completedSteps = 0
    [string]$activity
    [int]$id
    [string]$variableName
    [int]$totalSteps = ([System.Management.Automation.PsParser]::Tokenize(( $ScriptFile ), [ref]$null) | Where-Object { $_.Type -eq 'Variable' } | Where-Object { $_.Content -eq $variableName }).Count - 1

    ProgressBar(
        [string]$activity,
        [int]$id,
        [string]$variableName
    ){
        $this.activity = $activity
        $this.id = $id
        $this.variableName = $variableName
    }

    [void] UpdateProgress($status) {
        $percentComplete = ($this.completedSteps / $this.totalSteps) * 100
        Write-Progress -Activity $this.activity -Status $status -PercentComplete $percentComplete -Id $this.id
        $this.completedSteps += 1
    }
}

Creating our auto-incrementing progress bar objects

$progressbar = [ProgressBar]::new("MyProgressBar",1,"progressbar")
$progressbar2 = [ProgressBar]::new("MySecondProgressBar",2,"progressbar2")

Note that the third argument is the name of the variable we will use to refer to the progress bar. This is how we determine the number of steps our progress bar needs.

Performing our tasks

The following are some example tasks simply to demonstrate how the progress bar can be updated. In a real script, the progressbar and progressbar2 objects need not be updated at the same time and you would perform actual tasks instead of sleeping.

$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1
$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1
$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1
$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1
$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1
$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1
$progressbar.UpdateProgress("Task")
$progressbar2.UpdateProgress("Task2")
Start-Sleep 1

The post Handling multiple auto-incrementing progress bars in PowerShell 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.

When you first develop a feature you may want a lot of information about its state. Later, when it matures, you may only want to see serious errors and skip events that are purely informational. At this point we then comment out the print statements, and re-enter them the next time there is a bug and we want detailed output. This leads to the possibility that important messages could be commented out or informational messages could be left in, leading to messy output.

We can use the logging module set up custom event handlers to control which locations we log events to. For example, we may want to send all messages to a file but only send significant errors to the console. At a later date we may find a bug and want to output detailed debug messages. We can do this by making a small configuration change instead of un-commenting hundreds of lines of code.

The logging module has a lot of features and I will not cover all possible uses here. Instead, I will provide a general overview that you can adapt to implement basic logging functionality in scripts.

Using the logging module to generate log messages

The logging module provides the capacity to create multiple logger objects each with different properties, allowing for flexibility over the routing of log messages. Alternatively you can call the logging class directly to use the root logger. We can start using the logging module to print a message to the console using the default settings of the root logger as follows:

import logging
logging.error("this is a test log message")

When we run this code we get the output on the console:

ERROR:root:this is a test log message

This message shows the severity of the message (ERROR), the name of the logger (root) and the message to output. If we wanted to create a secondary logger we could use the GetLogger method:

logging.getLogger("CustomLogger").error("This is an error message sent to a custom logger")

ERROR:CustomLogger:This is an error message sent to a custom logger

We can also assign a custom logger to a variable to simplify calling it in future:

myCustomLogger = logging.getLogger("CustomLogger")
myCustomLogger.error("This custom logger is mapped to a variable")

Handling different logging severity levels

So far we have just generated log messages with a severity level of “ERROR”. There are 5 default severity levels, “DEBUG”, “INFO”, “WARNING”, “ERROR” and “CRITICAL”. We can use each of these levels by using the appropriate method of the logging module. In the following example we generate a log message with each severity level.

logging.critical("this is a test CRITICAL message")
logging.error("this is a test ERROR message")
logging.warning("this is a test WARNING message")
logging.info("this is a test INFO message")
logging.debug("this is a test DEBUG message")

When you run this code, you see that not all of your messages appear on the console:

CRITICAL:root:this is a test CRITICAL message
ERROR:root:this is a test ERROR message
WARNING:root:this is a test WARNING message

We only get messages with a severity greater than or equal to WARNING but our INFO and DEBUG messages are ignored. This is because by default the logger object has a severity level set to WARNING. We can customise this level at the root logger object and at the handler level (more on handlers later) but the message must match the severity level for both the logger and the handler. For example, if we set the logger to “WARNING” and the handler to “DEBUG”, the handler would still only receive WARNING or higher.

We can use the setLevel method to change the severity level for the logger object:

logging.getLogger().setLevel("DEBUG")
logging.critical("this is a test CRITICAL message")
logging.error("this is a test ERROR message")
logging.warning("this is a test WARNING message")
logging.info("this is a test INFO message")
logging.debug("this is a test DEBUG message"

Now the output contains all messages:

CRITICAL:root:this is a test CRITICAL message
ERROR:root:this is a test ERROR message
WARNING:root:this is a test WARNING message
INFO:root:this is a test INFO message
DEBUG:root:this is a test DEBUG message

This now means we can adjust the severity of messages we receive without needing to comment out any print statements, we just need to adjust the parameter in our call to SetLevel and the change will take effect throughout our code.

Redirecting logging module output

So far we have just looked at printing log output to the console but the logging module provides various handlers to redirect the output. For example, we could write the output to a file, a syslog server or even to email. We can also customise the severity of logs that go to different locations and the level of detail that goes in to the logs. For example, we may want only errors to appear on the console but all detail to appear in the log file. We may also want critical alerts to generate an email message or we might want the log file to contain timestamps that do not appear in the console.

Outputting to a file

We create handlers by creating a new handler object and assigning it to the logger object. For example, we could create a new file handler and set its severity level to INFO as follows:

filehandler = logging.FileHandler("test.log")
filehandler.setLevel("INFO")

We can then assign that handler to our logger object:

logging.getLogger().addHandler(filehandler)

If you are not using the root logger then you will need to specify the name of the logger as a parameter to the getLogger method. If you have assigned the logger object to a variable you can also use the name of that variable to reference the object. For example:

mylogger = logging.getLogger("ExampleLogger")
mylogger.addHandler(filehandler)

If we now run our example code we will see that it does not print anything to the screen. Instead, we can find a file called test.log which contains:

this is a test CRITICAL message
this is a test ERROR message
this is a test WARNING message
this is a test INFO message

Outputting to the console

The reason we don’t see anything on the screen is because the logging module only creates a default stream handler if there are no other handlers. If we want to have a stream handler as well as a file handler then we must explicitly define both. The method for adding a stream handler is similar to adding a file handler:

streamhandler = logging.StreamHandler()
streamhandler.setLevel("WARNING")
logging.getLogger().addHandler(streamhandler)

If we run this now we get

this is a test CRITICAL message
this is a test ERROR message
this is a test WARNING message

printed to the console and

this is a test CRITICAL message
this is a test ERROR message
this is a test WARNING message
this is a test INFO message

appended to test.log. The INFO message is skipped from the console as we only care about WARNING or higher.

Controlling disk usage when logging to a file

There are several different types of handler which I will not cover here as the aim is to provide a general overview but the full details of all handlers are in the module documentation. One handler I will mention here is the rotating file handler. This works similarly to the file handler we have discussed previously but also allows us to delete stale log files.

Suppose your application continuously generates log messages and never deletes them. Eventually the logs will end up taking up a significant amount of space and may even become impossible to open. The rotating handler specifies the maximum size a log file is allowed to reach before a new one is created. We can also specify how many historical log files to keep before deleting the old ones.

To use the rotating file handler, along with the other advanced handlers, we also need to import the logging.handlers module. This is in addition to the main logging module:

import logging.handlers

We can now define our handler as follows:

rotatingfilehandler = logging.handlers.RotatingFileHandler(
    "Rotating.log",maxBytes=1024,backupCount=3)
rotatingfilehandler.setLevel("DEBUG")
logging.getLogger().addHandler(rotatingfilehandler)

This handler will output to a file called Rotating.log and will archive the file whenever it reaches 1kB in size. When the handler rotates a file, it increments a number at the end. For example, when the file is rotated once, the logger will rename it to Rotating.log1, then to Rotating.log2 etc. We have set it to retain 3 archived copies.

As we do not need to worry about the log filling up the disk space we can, if we choose, store all detail including DEBUG messages. RotatingFileHandler and FileHandler are not mutually exclusive. If you wanted to save informational messages to a log that gets rotated but save ERROR and CRITICAL to a secondary log file that is never replaced, you could use both types of handler at the same time. This is the same as how we used both FileHandler and StreamHandler in the previous example.

Formatting logging output

You may recall from our first example, that the log messages we generated didn’t just contain the message. They also showed the severity and the name of the logger object that generated the message.

We can control how to display messages by using formatters. These specify the extra information that should go in to a log message. As we assign the formatter to a specific handler, not to the overall logging object, we can specify different format options for each handler. For example, we may want to show a timestamp in the log file but not on the console.

Formatter objects are created as strings containing placeholder variables for specific data. You can find a full list of all the possible variables here. For a simple example, suppose we wanted the log file to contain the timestamp, severity level, and log message and the console to just show the severity and the message. We could do:

fileformatter = logging.Formatter("%(asctime)s - %(level)s: %(message)s")
streamformatter = logging.Formatter("%(level)s - %(message)s")
streamhandler.setFormatter(streamformatter)
filehandler.setFormatter(fileformatter)

If we now generate some example log messages we can see the following on the console:

CRITICAL - this is a test CRITICAL message
ERROR - this is a test ERROR message
WARNING - this is a test WARNING message

And this in our log file:

2021-08-14 13:14:50,731 - ERROR: this is a test ERROR message
2021-08-14 13:14:50,731 - WARNING: this is a test WARNING message
2021-08-14 13:14:50,731 - INFO: this is a test INFO message

Next steps

We have now seen how to generate logging messages and filter by severity level. We have also seen how to redirect our log messages to a file while also ensuring high priority messages are still visible on the console. I hope this should be enough to gain a general understanding of how the logging module works, allowing the reader to research the more advanced features directly from the library documentation. By using logging instead of print statements to provide feedback on the operation of our code we make it more maintainable and easier to home in on the specific information needed when investigating bugs.

The post Say goodbye to print() with the Python logging module 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.