Forem: Sergio Peris

Configure static IP address on Netplan

Sergio Peris — Tue, 31 Mar 2026 09:00:23 +0000

I've recently set up a new Ubuntu Server 24.04 and needed to assign it a static IP address. For a server, you don't want the IP to change whenever DHCP leases expire.

Finding your network interface

Before making any configuration changes, you need to know the name of your network interface. On Ubuntu Server, you'll likely see something like ens33 or enp0s3.

Run this command to see all network interfaces:

ip link

Look for the interface that has an IP address assigned to it. That's the one you want to configure. In my case, it was enp0s3.

Configuring Netplan

Ubuntu Server 24.04 stores network configuration in /etc/netplan/. There's usually a file there called something like 50-cloud-init.yaml. Let's check what's in that directory:

ls /etc/netplan/

Open the configuration file and you will see something like this by default:

vi /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true

Change it to use a static IP instead. Here's what I configured:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 1.0.0.1

As you can see, the IP address includes the CIDR notation. The CIDR /24 means a subnet mask of 255.255.255.0. I'm using explicit routes instead of the older gateway4 key, because Ubuntu 24.04 deprecated gateway4. For DNS, I pointed to Cloudflare's public DNS servers, but you can use the DNS servers of your choice.

Applying the changes

Once the file is saved, instruct Netplan to apply the changes:

sudo netplan apply

Verifying the changes

Check that your static IP is now assigned:

ip addr show enp0s3

It should now show your new static IP address.

Backup S3 buckets using rclone

Sergio Peris — Tue, 10 Feb 2026 08:00:24 +0000

Backing up our files is a crucial task that we don't consider until it's too late. Using rclone, we can make a backup of all our data stored in S3 buckets.

Installing rclone

First, we need to install rclone. We'll be using Ubuntu Server, but you can use any distribution supported.

curl https://rclone.org/install.sh | sudo bash

Once we've installed it, we can verify it.

rclone version

rclone v1.72.1
 - os/version: ubuntu 24.04 (64 bit)
 - os/kernel: 6.8.0-90-generic (x86_64)
 - os/type: linux
 - os/arch: amd64
 - go/version: go1.25.5
 - go/linking: static
 - go/tags: none

Configure the remote

To connect to our S3 storage, we must create a rclone remote.

rclone config

This command will prompt us to answer a few questions to configure it correctly.

Some options may differ from this example, so take your time reviewing the options offered to select the one that best suits your case.

n) New remote
name> s3-storage

Storage> s3
provider> Other
env_auth> false
access_key_id> ACCESS_ID_KEY
secret_access_key> ACCESS_SECRET_KEY
region> REGION
endpoint> http://s3.example.com
location_constraint>
acl> private
y/e/d> y
e/n/d/r/c/s/q> q

Test the remote

Once we've configured the remote, we need to test it. Running the following command should list all buckets available:

rclone lsd s3-storage:

-1 2026-01-29 21:09:35        -1 bucket-1
-1 2026-01-29 20:05:31        -1 bucket-2

Configuring the backup

To back up the S3 storage, we'll create a backup script.

vi /usr/local/bin/s3-backup.sh

#!/bin/bash
set -e

LOG="/var/log/rclone-backup.log"
DEST="/backup"

rclone sync garage: "$DEST" \
  --checksum \
  --fast-list \
  --s3-no-check-bucket \
  --transfers=8 \
  --checkers=16 \
  --log-file="$LOG" \
  --log-level INFO

This script will back up all S3 buckets to the /backup folder.

Next, we make the script executable.

chmod +x /usr/local/bin/s3-backup.sh

And run it to create the first backup.

s3-backup.sh

Set up a cron job

To run the backup periodically, we must create a cron job.

crontab -e

# Backup Garage S3 to QNAP daily at 02:00.
0 2 * * * /usr/local/bin/s3-backup.sh

This cron job will run the backup script every day at 02:00.

Add an NFS mount point to a Ubuntu Server

Sergio Peris — Mon, 02 Feb 2026 09:00:24 +0000

NFS allows us to mount a network share as a local device. This system uses the client IP address for authentication. Don't confuse it with SMB, which allows user and password authentication.

In this tutorial, we'll explain how to connect an NFS share to an Ubuntu Server as a client.

Install dependencies

First, we must install the dependencies.

apt install nfs-common

Create a mount point

Once we've installed the dependencies, we must ensure the mount point we want to use exists.

mount -p /mnt/backups

Add a persistent mount

Using the mount command, we can temporarily mount the NFS share. However, we'll modify the /etc/fstab file to make the mount persistent.

192.168.1.10:/Backups /mnt/backups nfs defaults,_netdev 0 0

To apply the changes we've made at /etc/fstab we must run:

mount -a

Now we can check that the NFS mount is working as expected.

df -h

Filesystem                     Size  Used Avail Use% Mounted on
/dev/sda2                       30G  6.9G   21G  25% /
192.168.1.10:/Backups          916G  594G  322G  65% /mnt/backups

Remove local and local-lvm from Proxmox

Sergio Peris — Mon, 26 Jan 2026 09:00:24 +0000

Proxmox, by default, configures two storage volumes on the disk where the Proxmox OS resides: one named local-lvm for storing the disk images and containers, and another named local for storing the ISO images, container templates, and backups.

The local-lvm, as its name suggests, is a LVM thin-provisioned.
The local is simply a directory stored at /var/lib/vz.

It's common to have more than one disk in a Proxmox host, so the best approach is to separate the Proxmox OS from the disk images. For example, a node with one 480GB disk for the Proxmox OS and two 960GB disks in RAID 0 for storing the disk images and containers.

To remove the local-lvm and local storage volumes, follow the steps below.

Using the Proxmox GUI, navigate to Datacenter > Storage.

There, select the local-lvm storage volume and remove it. Next, select the local storage volume and edit it to disable it, as this storage volume cannot be deleted.

Now, open a shell on your node, as you will run a few commands.

First, you should remove the logical volume:

lvremove /dev/pve/data

Next, you're going to reclaim the free space that is left unused in the logical volume:

lvresize -l +100%FREE /dev/pve/root

Finally, you must expand the disk format to be able to use the newly added space:

resize2fs /dev/mapper/pve-root

With these steps, you've successfully removed the local storage volumes from your Proxmox.

Registry CRUD actions on Windows Group Policy

Sergio Peris — Wed, 21 Jan 2026 09:00:24 +0000

Using Group Policies, you can modify the registry of all computers joined to the domain.

When you create a new GPO, one of the parameters you're required to configure is the action that will be performed. These are:

Create
Update
Replace
Delete

But do you know what each action entails?

Create action

This action will create the registry key if it doesn't exist. If it already exists, it will do nothing, even if the actual registry value doesn't match the value set in the GPO.

Update action

This is the default action. It updates the registry value to the one set in the GPO. If the registry key doesn't exist, it will also be created.

Replace action

This action will delete the registry key if it already exists and then recreate it. If it doesn't exist, it will be created. This is similar to the update action but more aggressive, because it will delete the registry key every time it is applied. This action is rarely used.

Delete action

This action will delete the registry key if it's present.

Now that you understand how each action works, you can begin configuring the GPO on your domain controller.

Disabling Fast Boot via Windows Registry

Sergio Peris — Mon, 19 Jan 2026 09:00:23 +0000

Fast Boot allows us to boot our computer faster by performing a deep hibernation instead of completely powering it off.

If you have startup scripts, you should disable Fast Boot because it will prevent running the scripts, as your computer will not be "starting up".

In a domain-controlled environment, you can set a Group Policy that disables Fast Boot for all your computers by modifying the Registry.

You should configure the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnable

With the value 0 as a DWORD.

With this Registry key, your computer will skip the Fast Boot and perform a complete power-off and startup cycle.

Trust any proxy in Laravel

Sergio Peris — Mon, 12 Jan 2026 09:00:23 +0000

It's a common practice to deploy Laravel apps behind load balancers, aka proxy.

But doing this requires you to change the middleware settings so Laravel trusts your load balancer.

If you don't change it, some side effects may occur, such as hitting rate limiters on for all users at once instead of per IP address.

In your bootstrap/app.php file, you need to add the following inside the ->withMiddleware function.

$middleware->trustProxies(at: '*')

The asterisk * will trust any load balancer.

Please note that it's recommended to narrow down the allowed proxies, because any user can tamper with the header used to determine the real user IP.

If you only have one load balancer and you know the IP address, you can set the IP address like this:

$middleware->trustProxies(at: '10.0.0.2')

If you have multiple load balancers, you can provide an array.

$middleware->trustProxies(at: [
  '10.0.0.2',
  '10.0.1.2',
])

Or even a CIDR for the IP addresses.

$middleware->trustProxies(at: '10.0.0.0/8')

In some cases, the load balancer adds its IP address to the right side of the X-Forwarded-For standard header, maintaining the leftmost IP address as the actual user IP.

To ensure Laravel obtains the correct IP address for the user's IP, you may need to set it to 0.0.0.0/0, allowing any load balancer to discard all IP addresses in this header except the leftmost one.

Trust proxy with Traefik in K8s

Sergio Peris — Mon, 05 Jan 2026 09:00:22 +0000

Traefik, by default, will not trust the standard Forwarding headers Load Balancers usually populate with the client and proxy IPs.

If your apps don’t need to know the user’s real IP, you don’t need to change any configuration.
However, if you want to use the X-Forwarded-For header, some changes are required.

In your Traefik’s yaml configuration, you need to add the following argument with all the IP CIDRs from your Load Balancers. For example, if your Load Balancer is at 10.0.0.3.

--entryPoints.web.forwardedHeaders.trustedIPs=10.0.0.3/32

If you use MicroK8s, the arguments are in the Traefik daemonset resource.

If you don’t know the Load Balancer IPs, you can use 0.0.0.0/0 to trust all IPs, but this is not recommended, as any user can fake this header to bypass security features, such as IP-based rate limiters.

Trusting all IPs at Traefik requires validating the X-Forwarded-For header inside the application.

MicroK8s upgrade ingress from NGINX to Traefik

Sergio Peris — Mon, 29 Dec 2025 09:00:25 +0000

The Kubernetes nginx-ingress is scheduled to be retired in March 2026, so Canonical’s MicroK8s team replaced Nginx with Traefik for its ingress addon.

If you’re running a MicroK8s cluster with the Nginx ingress, you may want to upgrade it.

First, you need to disable the ingress addon to remove the old Nginx ingress.

microk8s disable ingress

Then, you should update the core addons repository.

microk8s addons repo update core

Finally, you can enable the new Traefik ingress.

microk8s enable ingress

The Traefik ingress is compatible with your previous Nginx configuration, so all your sites and services should work fine.

Passing Laravel route to Maizzle button

Sergio Peris — Mon, 08 Dec 2025 09:00:26 +0000

Maizzle is a framework that helps us quickly build HTML emails with Tailwind CSS. We can integrate it into our Laravel project to create beautiful emails.

By default, Maizzle provides us with a button component which can be used as a CTA button in our emails, like:

<x-button href="https://maizzle.com" class="bg-slate-950 hover:bg-slate-800">Verify email</x-button>

In Laravel, it's common to use the helper route to create links to different routes of the project.

For a "Verify email" button like the previous, we might modify it to something like this:

<x-button href="route('auth.verify-email')" class="bg-slate-950 hover:bg-slate-800">Verify email</x-button>

If we generate the email with this code, Maizzle will output this:

<a href="route('dns-check.results', [$check->project, $check])"

As you can see, the URL will not work as it was placed without being interpreted.

We might try to add the curly brackets to allow the route helper to be interpreted:

<x-button href="{{ route('auth.verify-email') }}"

But Maizzle will generate this:

<a href="{{ route(&amp;#039;auth.verify-email&amp;#039;) }}"

Ok, that's not working, maybe we need to add @ to escape the content:

<x-button href="@{{ route('auth.verify-email') }}"

With these, Maizzle will generate:

<a href="{{ route(&#039;auth.verify-email&#039;]) }}"

As you can see, this is not working.

The solution is to escape the content within the button component, not outside.

So we will use the button as:

<x-button href="route('auth.verify-email')"

And the button.html component should be modified from:

<a attributes href="{{{ href }}}"

To this:

<a attributes href="@{{ {{{ href }}} }}"

If we try it again, Maizzle will generate this:

<a href="{{ route('auth.verify-email') }}"

Now, when we send the email from our Laravel app, the button will have the correct link.

Merge video with audio using FFMPEG

Sergio Peris — Mon, 10 Nov 2025 09:00:25 +0000

If you have two files, one with audio and one with video, you can use FFMPEG to merge them without re-encoding.

For this example, the video file will be video.mp4 and the audio will be audio.mp4.

To merge both files, you should use the following command:

ffmpeg -i video.mp4 -i audio.mp4 -c:v copy -c:a copy output.mp4

Once finished, the output.mp4 file will contain both audio and video together.

Solve Dovecot error "Unknown section name: plugin"

Sergio Peris — Fri, 24 Oct 2025 09:00:25 +0000

If you use Dovecot as your mail server, upgrading from 2.3 to 2.4 can cause some issues.

It's always recommended to carefully read the upgrade guide before upgrading a a neewer version, but if you use Plesk like me, the upgrade can happen automatically.

If you're getting the following error:

doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/37-custom-global-sieve.conf line 2: Unknown section name: plugin

You need to modify the 37-custom-global-sieve.conf file to the new syntax.

Until version 2.3, this was the syntax you'll probably have:

vi /etc/dovecot/conf.d/37-custom-global-sieve.conf

plugin {
       # Make sure to run "sievec" on this:
       sieve_after = /etc/dovecot/conf.d/custom-sieve/global_after.sieve
}

Since version 2.4, in new syntax the plugin section no longer exists, and sieve_after also has changed. To achieve the same functionality as before, you should update the file content to the following:

vi /etc/dovecot/conf.d/37-custom-global-sieve.conf

sieve_script after {
  sieve_script_path = /etc/dovecot/conf.d/custom-sieve/global_after.sieve
}

After this change, you can run the following command to check if there's any other syntax error.

doveconf -n

If it displays the whole Dovecot configuration, you're ready to go.

Restart your server and everything should work as expected.