misc

The Nagios Cross-Platform Agent (NCPA) runs on monitored hosts and exposes metrics to the Nagios server. The steps below install NCPA on CentOS 7 and Ubuntu 16/18/20.

Open the required firewall port

sudo firewall-cmd --permanent --add-port=5693/tcp
sudo firewall-cmd --reload

Install on CentOS 7

rpm -Uvh https://repo.nagios.com/nagios/7/nagios-repo-7-4.el7.noarch.rpm
yum install ncpa -y
systemctl enable ncpa_listener ncpa_passive
systemctl start ncpa_listener ncpa_passive

Install on Ubuntu 18.04 / 20.04

wget -qO - https://repo.nagios.com/GPG-KEY-NAGIOS-V2 | sudo apt-key add -
echo "deb https://repo.nagios.com/deb/bionic ./" | sudo tee /etc/apt/sources.list.d/nagios.list
sudo apt-get update
sudo apt-get install ncpa -y

Install on Ubuntu 16.04

wget -qO - https://repo.nagios.com/GPG-KEY-NAGIOS-V2 | sudo apt-key add -
echo "deb https://repo.nagios.com/deb/xenial ./" | sudo tee /etc/apt/sources.list.d/nagios.list
sudo apt-get update
sudo apt-get install ncpa -y

Configure the NCPA token

Edit /usr/local/ncpa/etc/ncpa.cfg and set a strong community token:

[api]
community_string = your-secret-token

sudo systemctl restart ncpa_listener

Test the agent

curl "https://AGENT_IP:5693/api?token=your-secret-token" -k

Multipass does not have a built-in command to resize CPU and RAM after a VM is created. You can edit the instance configuration file directly while the Multipass daemon is stopped.

Steps

1. Stop the VM:
   multipass stop INSTANCE_NAME
2. Stop the Multipass daemon:
   sudo systemctl stop snap.multipass.multipassd.service
3. Edit the instance config file:
   sudo vi /var/snap/multipass/common/data/multipassd/multipassd-vm-instances.json
   Find your instance and change cpus and mem_size values.
4. Resize the disk image (if needed):
   sudo qemu-img resize /var/snap/multipass/common/data/multipassd/vault/instances/INSTANCE_NAME/ubuntu-22.04-server-cloudimg-amd64.img +10G
5. Restart the daemon and VM:
   sudo systemctl start snap.multipass.multipassd.service
multipass start INSTANCE_NAME
6. Extend the filesystem inside the VM:
   multipass exec INSTANCE_NAME -- sudo growpart /dev/sda 1
multipass exec INSTANCE_NAME -- sudo resize2fs /dev/sda1

Verify

multipass info INSTANCE_NAME

Backup scripts running during peak hours can saturate CPU and disk I/O, slowing down active workloads. Use nice (CPU priority) and ionice (I/O priority) to run them at lower priority.

nice – lower CPU priority

# Run a command at the lowest CPU priority (19 = lowest, -20 = highest)
nice -n 19 /usr/local/bin/backup.sh

# Wrap an existing process
renice -n 19 -p PID

ionice – lower disk I/O priority

# Best-effort class, lowest priority (7)
ionice -c 2 -n 7 /usr/local/bin/backup.sh

# Idle class — only runs when no other I/O is pending (most aggressive throttle)
ionice -c 3 /usr/local/bin/backup.sh

Combine both for backup scripts

#!/bin/bash
# Run at lowest CPU and I/O priority
exec nice -n 19 ionice -c 2 -n 7 "$@"

Or wrap your cron entry directly:

0 2 * * * nice -n 19 ionice -c 2 -n 7 /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

ionice classes explained

• Class 1 (Realtime) — always gets I/O first, regardless of other processes. Avoid for backups.
• Class 2 (Best-effort) — default class; priority 0–7 (0=highest, 7=lowest).
• Class 3 (Idle) — gets I/O only when the disk is otherwise idle. Best for backups.

By default, self-hosted GitLab runs over HTTP. This guide configures HTTPS using either a commercial SSL certificate or a free Let's Encrypt certificate.

Option 1 – Let's Encrypt (recommended, free)

Edit /etc/gitlab/gitlab.rb:

external_url 'https://gitlab.yourdomain.com'
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['admin@yourdomain.com']

sudo gitlab-ctl reconfigure

GitLab will automatically obtain and renew the certificate via Let's Encrypt.

Option 2 – Commercial/custom SSL certificate

1. Place your certificate files on the server:
   /etc/gitlab/ssl/gitlab.yourdomain.com.crt
/etc/gitlab/ssl/gitlab.yourdomain.com.key
2. Set correct permissions:
   chmod 600 /etc/gitlab/ssl/*
3. Edit /etc/gitlab/gitlab.rb:

   external_url 'https://gitlab.yourdomain.com'
   nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.yourdomain.com.crt"
   nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.yourdomain.com.key"

4. Apply: sudo gitlab-ctl reconfigure

Force HTTP → HTTPS redirect

Add to gitlab.rb:

nginx['redirect_http_to_https'] = true

sudo gitlab-ctl reconfigure

Verify

sudo gitlab-ctl status
curl -I https://gitlab.yourdomain.com

BorgBackup is a deduplicating, compressed, encrypted backup tool. Combined with a Hetzner Storage Box (or any SSH-accessible storage), it provides efficient, secure off-site backups.

Step 1 – Install BorgBackup

# Ubuntu / Debian
sudo apt-get install -y borgbackup

# CentOS / RHEL
sudo yum install -y borgbackup

Step 2 – Enable SSH access on the Storage Box

In the Hetzner Robot panel, enable SSH support for the Storage Box. Then add your public SSH key to the box's authorized_keys.

Step 3 – Initialise the Borg repository

borg init --encryption=repokey   ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./backups/myserver

Save the repository key and passphrase in a secure location.

Step 4 – Create a backup

export BORG_PASSPHRASE='your-passphrase'

borg create --stats --progress   ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./backups/myserver::$(date +%Y-%m-%d)   /var/www /etc /home

Step 5 – Prune old backups

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6   ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./backups/myserver

Step 6 – Automate with cron

0 3 * * * /usr/local/bin/borg-backup.sh >> /var/log/borg-backup.log 2>&1

List and restore

# List archives
borg list ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./backups/myserver

# Extract a specific archive
borg extract ssh://...::2024-01-15 var/www/html

Install Redis from the Remi repository (which provides up-to-date packages) and compile the PHP Redis extension from source.

Step 1 – Install Redis

wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm
rpm -Uvh remi-release-7.rpm
yum install redis -y
systemctl start redis
systemctl enable redis

Step 2 – Verify Redis is running

redis-cli ping   # should return: PONG
redis-cli info server | grep redis_version

Step 3 – Install the PHP Redis extension

cd /root
git clone https://github.com/phpredis/phpredis.git
cd phpredis/
/usr/local/bin/phpize
./configure --with-php-config=/usr/local/bin/php-config
make
make install

Step 4 – Enable the extension

Add to your php.ini (or create /etc/php.d/20-redis.ini):

extension=redis.so

php -m | grep redis   # verify

Basic Redis configuration (/etc/redis.conf)

# Bind to localhost only (default, more secure)
bind 127.0.0.1

# Set a password
requirepass your-strong-password

# Max memory and eviction policy
maxmemory 256mb
maxmemory-policy allkeys-lru

systemctl restart redis

Wake-on-LAN (WoL) sends a "magic packet" to power on a sleeping computer. On newer TP-Link routers without OpenWrt, you can still trigger WoL through the router's built-in feature.

Prerequisites

• Target PC must have WoL enabled in BIOS/UEFI.
• The network adapter must support WoL (check Device Manager → NIC properties → Power Management → "Allow this device to wake the computer").
• The PC must be connected via Ethernet (WoL generally doesn't work over Wi-Fi).

Enable WoL on a TP-Link router (stock firmware)

1. Log in to the router admin panel (usually 192.168.0.1 or tplinkwifi.net).
2. Go to Advanced → USB Settings → Wake on LAN (exact path varies by model).
3. Enable the feature and note your router's external IP or use a DDNS hostname.

Send a WoL magic packet remotely (Linux/Mac)

# Install wakeonlan
sudo apt-get install -y wakeonlan

# Send magic packet (replace with target MAC address)
wakeonlan AA:BB:CC:DD:EE:FF

For remote WoL across the internet, forward UDP port 9 on the router to the broadcast address (e.g., 192.168.1.255), then send the packet to your public IP.

Alternative: SSH into router (if OpenWrt is available)

ssh root@ROUTER_IP "wol AA:BB:CC:DD:EE:FF"