Update 2026: Firmware 3.0.1 released. With new UI and Wireguard support. Wow. For a +10 year router... Installation is the same.

If you are like me, you don't call an all-in-one spaceship a router. I like things to do what they are supposed to do, so in my home network I have a separate device for every task. When it comes to home routers, I think the Ubiquiti EdgeRouter X is pretty unbeatable in the price vs. features category. I won't sing odes about how nice the interface or how great the command line is. All I will say is that this little piece of hardware is probably one of the most reliable devices I've ever had. Too bad they discontinued it.

Nevertheless, I did find an EdgeRouter X SFP, which is basically the same. It's always nice to have a backup, in case my trusty old one decides to go sleep with the fishes. I used the wizard to set up the basic operating mode, then since it runs Linux (vyatta on 1.x), I went for the command line 🤪 The official documentation on Ubiquiti's site is great, but I gathered all I needed in one place. I hope you'll also find it useful. Here we go!

Update the EdgeRouter firmware

Check if there is enough space in /tmp directory (as of now 80-90 MB should be enough)

show system storage
# check /tmp space

Download the firmware to /tmp

curl https://dl.ui.com/firmwares/edgemax/v1.10.11/ER-e50.v1.10.11.5274269.tar > /tmp/ER-e50.v1.10.11.5274269.tar

Checksum the file, just to be sure

sha256sum /tmp/ER-e50.v1.10.11.5274269.tar

Check to see if enough space on / (root) for the new firmware

show system storage

Check if you have a backup image (older version)

show system image storage

If there is not enough space, you can delete the backup image (the one without default boot)

delete system image

Install the new firmware

add system image /tmp/ER-e50.v1.10.11.5274269.tar

Check if the new image is selected for the default boot image

show system image

If something goes wrong during the upgrade, you can swap between boot images

set system image default-boot

Now you should wait 3-5 minutes. Trust me on this. Then, reboot the router

reboot

Check if the upgrade was successfull

show version

Note - Other ways to get the latest firmware:

# Download the image directly from the Ubiquiti website using HTTPS
add system image https://dl.ui.com/.../firmware.tar

# Downloading the image from a remote server using TFTP, FTP or SCP
add system image tftp://ip-address/firmware.tar
add system image scp://ip-address/firmware.tar
add system image ftp://ip-address/firmware.tar

# Copying the firmware from another machine to the router
scp -P <ssh port> ~/Downloads/ER-e50.v3.0.1.5862409.tar user@<router-ip>:/tmp

Upgrading the Edgerouter bootloader

After rebooting the router for the firmware upgrade, you may encounter a similar MOTD like the one below:

Boot image can be upgraded to version [ e50_002_4c817 ].
Run "add system boot-image" to upgrade boot image.

This is because, on most EdgeRouter models, the bootloader version is not updated automatically with a firmware upgrade and must be updated manually. The EdgeRouter bootloader controls functions such as the LED boot behavior, configuration/driver loading and much more.

To upgrade the bootloader version run

add system boot-image

Reboot the router again

reboot

Check if the upgrade was successfull or a boot-image update is available

show system boot-image

Configure the default firewall

Enter configuration mode.

configure

Configure the WAN_IN firewall policy (already created by wizard).

set firewall name WAN_IN default-action drop
set firewall name WAN_IN description 'WAN to internal LAN'
set firewall name WAN_IN rule 10 action accept
set firewall name WAN_IN rule 10 description 'Allow established/related'
set firewall name WAN_IN rule 10 state established enable
set firewall name WAN_IN rule 10 state related enable
set firewall name WAN_IN rule 20 action drop
set firewall name WAN_IN rule 20 description 'Drop invalid state'
set firewall name WAN_IN rule 20 state invalid enable

Configure the WAN_LOCAL firewall policy (already created by wizard).

set firewall name WAN_LOCAL default-action drop
set firewall name WAN_LOCAL description 'WAN to router'
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 description 'Allow established/related'
set firewall name WAN_LOCAL rule 10 state established enable
set firewall name WAN_LOCAL rule 10 state related enable
set firewall name WAN_LOCAL rule 20 action drop
set firewall name WAN_LOCAL rule 20 description 'Drop invalid state'
set firewall name WAN_LOCAL rule 20 state invalid enable

Configure the WAN_OUT firewall policy

set firewall name WAN_OUT default-action accept
set firewall name WAN_OUT description 'Internal LAN to WAN'
set firewall name WAN_OUT rule 20 action reject
set firewall name WAN_OUT rule 20 description 'Reject invalid state'
set firewall name WAN_OUT rule 20 state invalid enable

Attach the firewall policies to the WAN interface in the inbound and local direction.

set interfaces ethernet eth0 firewall in name WAN_IN
set interfaces ethernet eth0 firewall local name WAN_LOCAL
set interfaces ethernet eth0 firewall out name WAN_OUT

or for PPPoE (in PPPoE scenario eth0 only carries ppp encapsulated packets. These packets won't hit the routing engine at all, so an iptables rule on eth0 would be futile). In this example the PPPoE interface is on eth0

set interfaces ethernet eth0 pppoe 0 firewall in name WAN_IN
set interfaces ethernet eth0 pppoe 0 firewall local name WAN_LOCAL
set interfaces ethernet eth0 pppoe 0 firewall out name WAN_OUT

Note: EdgeRouter firewall policies only become active when they are attached to an interface + direction.

Commit the changes and save the configuration

commit ; save

Other useful commands

Create new user and delete the default

set system login user <username> authentication plaintext-password <password>
set system login user <username> level admin
delete system login user ubnt
sudo rm -r /home/ubnt

Set the router hostname

set system host-name YourNewHostname

Set timezone

set system time-zone Europe/Athens

Change default HTTPS GUI port

set service gui https-port 60443

Change default SSH port

set service ssh port 60022

Set pre-login SSH banner

set system login banner pre-login "\n\t-~===__._Welcome_to_MyRouter_.__===~-\n\n\tThis system is restricted to authorized users only.\n\tYour data and all activities on this system are logged.\n\tUnauthorized access will be fully investigated and reported\n\tto the appropriate law enforcement agencies.\n\n"

Delete pre-login banner, go back to default

delete system login banner ; set system login banner

Set post-login SSH banner

set system login banner post-login "\nMessage of the day\n"

Delete post-login banner, go back to default

delete system login banner post-login "\nMessage of the day\n"

Set system DNS servers

set system name-server <ip-address1>
set system name-server <ip-address2>

Check DNS servers used by the router and statistics

show dns forwarding nameservers
show dns forwarding statistics

Set router to only use the system DNS servers (without those from ISP)

set service dns forwarding system

Set subnet domain-name

set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 domain-name mylan.local

Disable ipv6

set system ipv6 disable

Reconnect PPPoE

disconnect interface pppoe0
connect interface pppoe0

This is set by the wizard for PPPoE - Below commands will 'fix' connectivity to remote sites where ICMP is blocked and PMTU is broken:

# if you don't know your connection type for sure - sets it on all if's
set firewall options mss-clamp interface-type all

# for pppoe use
set firewall options mss-clamp interface-type pppoe

# set mss
set firewall options mss-clamp mss 1452

See System Logs

dmesg
# or
cat /var/log/messages

Bandwidth test with iperf (though not relevant when run from the EdgeRouter)

iperf3 -c public.iperf.server -p <port>
# add -R for reverse

Show config (and also export them)

show configuration
# or add "| tee config.txt" to also export them to you home folder

Check hardware offloading status

show ubnt offload

Enable (disable) hardware offload

set system offload hwnat enable # or disable
set system offload ipsec enable # or disable

• WARNING: IPsec offload on ER-X platform is causing problems to L2TP remote-access VPN and IPV6 site-to-site IPSec VPN. You should not enable IPsec offload if you are using any of above. IPv4 site-to-site IPsec VPN is working correctly with IPsec offload. PPTP VPN is working correctly with IPsec offload. Only ER-X/ER-X-SFP/EP-R6 models are affected by this issue. This issue is to be fixed in future release.

Links you may need

Configure L2TP IPsec VPN Server

Official guide for EdgeRouter TFTP recovery

EdgeRouter - Device LED Statuses

That is all for this note. And one more thing...

If you cannot do great things, do small things in a great way.

Since I recently upgraded the case of my trusty Raspberry Pi to an Argon ONE (the last Pi case you'll ever need, really), I thought it's a good time to share the procedure of installing one of the best pieces of software I have ever used: namely Pi-hole. This little DNS server whacks most of the ads before the request even leaves your network, making internet browsing a much better experience. Great thing is, once put in place, it's set and forget. You will realize how much you love it when you surf the net without it 🤪

I like things organized and my Pi runs other things besides Pi-hole so I'll use Docker. Instructions are for Raspbian (Raspberry Pi OS), but should be similar on other OS's as Pi-hole is not exclusive to the Raspberry.

Get Docker

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

... and docker compose:

sudo mkdir -p /usr/local/lib/docker/cli-plugins
sudo curl -SL https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-linux-armv7 -o /usr/local/lib/docker/cli-plugins/docker-compose
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

Setting up Pi-hole

Create a directory for Pi-hole persistent files and edit the docker compose file:

mkdir -p ~/pihole/pihole ~/pihole/dnsmasq.d
cd ~/pihole
nano docker-compose.yml

Paste the following into docker-compose.yml

version: "3"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:2021.12
    restart: unless-stopped
    network_mode: host
    #ports:
      #- "53:53/tcp"
      #- "53:53/udp"
      #- "67:67/udp" #needed only if you want PiHole-DHCP
      #- "80:80/tcp"
    dns:
      - 127.0.0.1 #Sets your container's resolve settings to localhost - may fix resolution errors on container restart.
      - 1.1.1.1 #Sets a backup server of your choosing in case DNSMasq has problems starting
    environment:
      TZ: 'Europe/Athens'
      # Set to your server's LAN IP, used by web block modes and lighttpd bind address.
      #FTLCONF_REPLY_ADDR4: 'YOUR.SERVER.IP' #called ServerIP in the past
      ServerIP: YOUR.SERVER.IP # Will be deprecated
      WEBPASSWORD: '' #blank
      # to reset afterwards run docker exec -it pihole_container_name pihole -a -p
      PIHOLE_DNS_: '127.0.0.1#5053;127.0.0.1#5053'
    volumes:
      - './pihole/:/etc/pihole/'
      - './dnsmasq.d/:/etc/dnsmasq.d/'

A few explanations here - I choose to run the container in host network mode as it is easier in my setup. If you want to define required ports for bridge mode, I've left the ports in the config, just comment network_mode and uncomment the ports section. Regarding Pi-hole, version 2022.01 (latest as of now) was having problems with FTL on my Pi, so I use the 2021.12 version, but you can try latest.

In the environment section you should change:

• TZ: Your timezone
• ServerIP: your hosting server's IP. Although the documentation states that ServerIP variable will be deprecated and you should use FTLCONF_REPLY_ADDR4, I couldn't get it to work with the new setting. Maybe in future versions.
• WEBPASSWORD: should be changed to whatever you like.
• PIHOLE_DNS_: is the upstream DNS that Pi-hole uses. These can be set up also in the web interface of Pi-hole later, so it's optional to specify them here. I always define two, because if not, it will auto-pick EvilEmpire for the second one and we don't want that. You may notice I point it to localhost port 5053, that's where cloudflared runs for DNS-over-HTTPS. More on that later.

Now you can fire up the Pi-hole container.

cd ~/pihole
sudo docker compose up -d

Finishing up

After you started the Pi-hole container, you must configure your DHCP server (or client) to point to Pi-hole's IP as DNS server. Then navigate to http://pi.hole/admin/ and you are greated by the Pi-hole login screen. Here, use your pass to log in and configure your ad-black-hole.

The first thing you should do, is check that FTL is running normally. You can do this by looking for the green Active status top-left of Pi-hole's web interface. Then configure your blocklists by clicking Group Management -> Adlists. The best collection of blacklists I found is on firebog.net. Check it out.

If you haven't configured your upstream DNS servers, go to Settings -> DNS. As you will see, there is a wide range of options to select from like Google, Cloudflare, Quad9 and so on.

Happy browsing! 😉

If you want DNS-over-HTTPS (DoH)

For this, we will need to configure cloudflared on our Pi so Pi-hole can use it as upstream DNS. There is a very good guide on how to do this in the Pi-hole documentation. Below the configuration for armhf 32-bit.

wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-arm
sudo cp ./cloudflared-linux-arm /usr/local/bin/cloudflared
sudo chmod +x /usr/local/bin/cloudflared
cloudflared -v

The last command above is to test the version of the daemon. If all is good, proceed with creating a cloudflared user to run the daemon and a configuration file.

sudo useradd -s /usr/sbin/nologin -r -M cloudflared
sudo nano /etc/default/cloudflared

This file contains the command-line options that get passed to cloudflared on startup. I have mine like this, comment/uncomment it to fit your needs. I know which line you will touch first 🤓.

# Commandline args for cloudflared

# Normal resolver
#CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

# Malware off - 1.1.1.2/1.0.0.2
#CLOUDFLARED_OPTS=--port 5053 --upstream https://security.cloudflare-dns.com/dns-query

# Malware and pr0n off - 1.1.1.3/1.0.0.3
CLOUDFLARED_OPTS=--port 5053 --upstream https://family.cloudflare-dns.com/dns-query

Malware and pr0n off will not work with IP's. I got it working with the URL's and cloudflared -v 2021.11. To test when setup is done: dig @127.0.0.1 -p 5053 nudity.testcategory.com (or phishing.testcategory.com). Should resolve to 0.0.0.0

Next, update the permissions for the configuration file and cloudflared binary to allow access for the cloudflared user:

sudo chown cloudflared:cloudflared /etc/default/cloudflared
sudo chown cloudflared:cloudflared /usr/local/bin/cloudflared

Then create the systemd script to control running of the service:

sudo nano /etc/systemd/system/cloudflared.service

Paste the following into it:

[Unit]
Description=cloudflared DNS over HTTPS proxy
After=syslog.target network-online.target

[Service]
Type=simple
User=cloudflared
EnvironmentFile=/etc/default/cloudflared
ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

Enable the service to run on startup, then start the service and check its status:

sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

Finally, go to Pi-hole settings and set the upstream DNS like this:

You are all done. YAY!

And one more thing ...

Simplicity is the ultimate sophistication.

Hmm ... hmm ... I just can't get enough of my ArgonONE case ... 🤤

I've been itching to set up an FTP server on my CentOS VPS, so that whenever one of my friend asks for some files, I have a quick way of meeting their needs. I ended up setting up a vsftpd server. As inspiration I used this great tutorial from digitalocean. However the problem with it is that it was set up for a separate directory for each user. Not what I wanted. So I dived deep.

First things first - install the FTP server. It's a lot easier to set this whole thing up if you become root.

sudo -i
dnf install vsftpd

Next the firewall. Don't ever forget the firewall. 😂 Now here, you have some choices to make. Do you want to expose port 21, so that every bot on the planet will try and violate your port or you choose a custom one. I went with the latter. You will need a port for FTP commands (default 21) and a port range for actual data transfer in passive mode (server decides the port). If confused, click.

The default firewall (called firewalld) on RedHat and the like ... really whips the llama's ass. Not only that the control commands make a lot of sense, but you can create your own services to easily add to the rules. Which we are going to do now, since we are here. To set up a service definition for firewalld all you have to do is edit an *.xml in a certain location.

nano /usr/lib/firewalld/services/vsftpd-custom.xml

Add the following lines and save.

<service>
  	<short>VSFTPD-custom</short>
  	<description>VSFTPD custom port settings</description>
  	<port port="33021" protocol="tcp"/>
  	<port port="33030-33050" protocol="tcp"/>
</service>

All you have to do afterwards is to reload the firewall so it recognizes the freshly defined service, add the service as permanent and reload firewalld again.

firewall-cmd --reload
firewall-cmd --add-service=vsftpd-custom --permanent
firewall-cmd --reload
firewall-cmd --list-all

Running the last command should reveal all your active firewall entries and you should see VSFTPD-custom among services. I think it's nice that definitions have a name so you don't have to remember the reason for each of the 4937 ports you opened.

Okay, now with the firewall out of the way, let's get on with the FTP server. First we back up the default configuration (just in case) and create our own.

mv /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.bkp
nano /etc/vsftpd/vsftpd.conf

Next thing, paste the below configuration. The default has some pretty clear comments and I also added my own, so I won't repeat myself here.

# Config guide: https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/s1-ftp-vsftpd-conf.html
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
#022=755; 002=775 (to calculate 777-what you need)
local_umask=022
#local_umask=002
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/xferlog
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=NO
# with ipv6 it listens also to ipv4
listen_ipv6=YES
#
# Port for FTP server to listen on; comment to use default 21
listen_port=33021
#
pam_service_name=vsftpd
#
# Only allow users on list
userlist_enable=YES
userlist_file=/etc/vsftpd/vsftpd.userlist
# However, userlist_deny=NO alters the setting, meaning that only users explicitly listed in userlist_file=/etc/vsftpd/vsftpd.userlist will be permitted to login.
userlist_deny=NO
#
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
#
# Jail ftp users to ftp root
chroot_local_user=YES
#
# writeable local root
#allow_writeable_chroot=YES
#
# define local root
local_root=/var/ftp/pub
#
# Ports used for PASsiVe mode
pasv_min_port=33030
pasv_max_port=33050
#
#for users to have ftp go to their home dir
#user_sub_token=$USER
#local_root=/home/$USER/ftp
#
# Securing with TLS/SSL (uncomment all bellow)
#rsa_cert_file=/etc/pki/tls/private/vsftpd.pem
#rsa_private_key_file=/etc/pki/tls/private/vsftpd.pem
#ssl_enable=YES
#allow_anon_ssl=NO
#force_local_data_ssl=YES
#force_local_logins_ssl=YES
#ssl_tlsv1=YES
#ssl_sslv2=NO
#ssl_sslv3=NO
#require_ssl_reuse=NO
#ssl_ciphers=HIGH

As you can see I also left the settings for running the server secured with TLS in and also the settings for  running the server with the FTP root defaulting to the user's home folder. Lines after pasv_max_port are safe to delete if you don't care. To securing with TLS I'll get back later.

Back to our setup. Paranoia sets in and I create a user that I specially use only for FTP. The digitalocean article had a nice tip on doing this by defining a custom shell for FTP users. Here is how to set it up:

nano /bin/ftponly

Add lines:

#!/bin/sh
echo "This account is limited to FTP access only."

Make it xecutable:

chmod a+x /bin/ftponly

Then, edit /etc/shells and add /bin/ftponly at the end.

Now let's create the user, add him to the FTP group (your choice) and give him no shell:

useradd -g ftp -s /bin/ftponly ftpuser
passwd ftpuser

After creating the user, we have to add it to the file referenced in vsftpd.conf. Only users included in this file will be able to access the server.

echo "ftpuser" | tee -a /etc/vsftpd/vsftpd.userlist

In order to allow people and the recently created user to upload files to our FTP server, we need to define a writable folder, because the way we secured our local root ftp directory, nobody is able to write it. And that is the way it should be.

chmod a-w /var/ftp/pub
mkdir /var/ftp/pub/uploads
chown ftpuser:ftp /var/ftp/pub/uploads
chmod g+w /var/ftp/pub/uploads

The only thing that is left to do is to start the vsftpd service and then enable it so it starts automatically when the server reboots.

systemctl start vsftpd
systemctl enable vsftpd

After this is done you should be able to access your own FTP server and put files in the uploads folder. Great success 😎.

Giving access to your FTP to a friend is easy as:

sudo -i
useradd -g ftp -s /bin/ftponly newftpuser
passwd newftpuser
echo "newftpuser" | tee -a /etc/vsftpd/vsftpd.userlist

A note on SELinux: this is a topic that I am no expert in, the only way I got my server working correctly was by modifying it like this - maybe you know a more secure way:

setsebool ftpd_full_access on

Optional: If you want to secure your server with TLS, you have to generate certificates (these will be valid for 1 year if you don't change the days)

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/vsftpd.pem -out /etc/pki/tls/private/vsftpd.pem

With the certificates generated, it's time to comment out the related lines in vsftpd.conf and restart the FTP server. You should be good to go!

And one more thing ...

Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great. - Twain

In this note you will learn to run a blog with popular CMS Ghost in Docker contaniers. As a matter of fact, I will show you how you can run multiple Ghost blogs and nginx proxy in the same stack. So you just pop a docker-compose and everything is up... well, not really. But almost 🙃.

Prerequisites

• a linux server (or other flawour), but let's be serious here...
• don't forget to open required ports in the firewall (http/s)
• a domain name
• a little time

Install Docker

My server is CentOS, so commands are for this breed. Please visit the official Docker documentation for your breed.

dnf config-manager --add repo=https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io
sudo systemctl start docker.service
sudo systemctl enable docker.service

For convenience you can add your user to the docker group, so you don't have to type sudo before every docker command to drive you nuts and you should also test the Docker installation.

sudo usermod -aG docker YOURUSER
docker run hello-world

We want to get fancy, so let's also install Docker Compose:

sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
#test
docker-compose --version

Now, if you would like to run Ghost in a container we would just execute:

docker run -d \
--name ghost \
-p 2368:2368 \
-v /path/to/your/local/ghost:/var/lib/ghost/content \
-e url=http://localhost:2368 \
ghost

You should be able to pop up a browser and visit your Ghost site at localhost:2368. You could also create an external environment file, if you have more variables (like mail settings) and call it with --env-file /srv/ghost/env.list \ - but we ain't gonna do that.

Preparing the environment

Let's create the directory structure. Main directory is ghost-blog in our home folder.

cd
mkdir -p ~/ghost-blog/ghost/content ghost-blog/letsencrypt ghost-blog/nginx

For nginx to run, we need to run a temporary nginx container, extract some files and delete the temporary container. There might be a better way to do this, if you happen to know one, drop me a line.

docker run --rm --name nginxtmp -it -v ~/ghost-blog/nginx:/tmp/nginx nginx:1.21 cp -rv /etc/nginx/conf.d/ /tmp/nginx/

Now we need to create the initial config file for nginx, which we we'll do with

cd ghost-blog
nano nginx/conf.d/ghost.conf

and add the following:

server {
        server_name your.domain.com;
        listen 80;
        
        location / {
                proxy_pass	 http://ghost-prd:2368;
                proxy_set_header    X-Real-IP $remote_addr;
                proxy_set_header    Host      $http_host;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        
        #maximum upload file size
        client_max_body_size 10M;
        
}

CTRL+O to save and CTRL+X to exit nano.

After this we are going to create the docker-compose file. This file is used to control our ghost-nginx stack.

nano docker-compose.yml

Copy and paste the below config in your docker-compose.yml

version: "3.9"
# Compose file reference: https://docs.docker.com/compose/compose-file/compose-file-v3/

services:
  ghost-prd:
    image: ghost:4.32
    container_name: ghost-prd
    hostname: ghost
    restart: unless-stopped
#    ports:
#      - 2368:2368
    #with the expose option only the stack can see the port
    expose:
      - "2368"
    environment:
      #change to site url
      url: https://your.domain.com
      #set email option or comment out
      mail__transport: SMTP
      mail__from: Sender <no-reply@yourdomain.com>
      mail__options__service: Mailgun
      mail__options__host: smtp.mailgun.org
      mail__options__port: 465
      mail__options__auth__user: postmaster@xxx.mailgun.org
      mail__options__auth__pass: pass
      mail__option__secure: "true"
      #logging (info, warn, error)
      logging__level: info
      #logging__rotation__enabled: "true"
      #logging__rotation__count: 10
      #logging__rotation__period: 1d
    volumes:
      - ./ghost/content:/var/lib/ghost/content

  nginx-prd:
     image: nginx:1.21
     container_name: nginx-prd
     hostname: nginx
     restart: unless-stopped
     depends_on:
       - ghost-prd
     ports:
       - 80:80
       - 443:443
     volumes:
       - ./nginx/conf.d:/etc/nginx/conf.d
       - ./letsencrypt:/etc/letsencrypt

Just to note some things here, I use Mailgun for these sort of things, but email settings should work with gmail or any other mail service.

I usually set the Ghost logging option to warn as nginx also logs and Ghost logs can get out of hand.

Using expose setting for the port makes it visible inside the stack, but it won't map it to the host. Which in my opinion is cleaner and because KISS 😛

After the docker-compose.yml is saved we should take a deep breath and pray... then run the stack:

docker-compose up -d

It should start pulling the images and setting everything up. When it is finished, you have a working Ghost blog powered by nginx in a stack, in two separate containers. The only thing that is left is installing certbot for certificates and securing the site. Certbot will do all that it is needed, install certificates and modify your ghost.conf file. To install Certbot, we need to go into our nginx container and do some mambo.

docker exec -it nginx-prd /bin/bash

Once inside the matrix, run:

apt-get update && apt-get install certbot python3-certbot-nginx -y
certbot --nginx

Pay attention when certbot requires input from you, so that you add a valid email address and secure your correct site. Now the only thing that remains is to restart the stack.

docker-compose stop
docker-compose up -d

Logs can be checked with docker-compose logs. Your stack and also your secured site should be up at https://your.domain.com. Hooray!!! That wasn't so hard now, was it? To unleash the dormant philosopher upon the world, check out https://your.domain.com/ghost

If for any reason you want to destroy your stack and set everything on fire you can run docker-compose down and your containers will be gone. You would just need to   also delete the ghost-blog folder in your home and you can start from scratch.

Updating

I like to control stuff, so in my docker-compose.yml I use fixed image tags instead of latest. Both can be set to latest. There is only one caveat, to which I haven't  figured out a solution yet. When upgrading nginx, certbot will be bye-bye, so you'll have to reinstall it. The certificates and site settings are safe, as there is a mapping for those in the letsencrypt folder.

One more thing ...

How to run multiple Ghost blogs in the same stack

If you want to add another Ghost instance in the same stack, you just have to add another service to your docker-compose.yml. Like this - note the exposed port and container_name:

ghost2-prd:
    image: ghost:4.32
    container_name: ghost2-prd
    hostname: ghost2
    restart: unless-stopped
    expose:
      - "2369"
    environment:
      #change to site url
      url: https://someother.domain.com
      #set if you want Ghost to run on non-default port
      server__port: 2369
      #set email option or comment out
      mail__transport: SMTP
      mail__from: Buster <no-reply@someother.domain.com>
      mail__options__service: Mailgun
      mail__options__host: smtp.mailgun.org
      mail__options__port: 465
      mail__options__auth__user: postmaster@xyz.mailgun.org
      mail__options__auth__pass: passW0Rd
      mail__option__secure: "true"
      #logging (info, warn, error)
      logging__level: warn
      #logging__rotation__enabled: "true"
      #logging__rotation__count: 10
      #logging__rotation__period: 1d
    volumes:
      - ./ghost2/content:/var/lib/ghost/content

Create folder to hold the contents of the second blog and also make another nginx config file for it:

cd
mkdir -p ghost-blog/ghost2/content
nano ghost-blog/nginx/conf.d/ghost2.conf

ghost2.conf should look like this:

server {
        server_name someother.domain.com;
        listen 80;

        location / {
                proxy_pass	 http://ghost2-prd:2369;
                proxy_set_header    X-Real-IP $remote_addr;
                proxy_set_header    Host      $http_host;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        }
}

Then:

docker-compose up -d
docker exec -it nginx-prd /bin/bash
	#inside the nginx container set up the second site
    	certbot --nginx

Stop and start your stack and you should have both sites running.

Phew. That was a long one. I hope it all makes sense 😂 I might put it all up on Github and then it will be easier. But that's a story for another day.

Do or do not. There is no try.

I started using Mac OS’s Photos recently. Photos is not perfect, but I like to use it as it is integrated with my photo editors and maybe the most important thing, it has a “Masters” folder where it organizes the untouched photo files in a nice manner – pretty much the same way I would manually.

I like to have a backup copy of my important files and for this I use NAS backups for pretty much everything. I used Carbon Copy Cloner in the past, but I’ve had some free time and put together a nice little solution for my backups, with rsync as backup tool and scheduling with launchd.

So let’s get on with it. We are going to backup the content of the “Masters” folder to a network share / backup location. First thing we do is define the share path and a mount point for it on your computer. I like to use my Public folder for these things.

SHARE="192.x.x.x/share/folder"
MOUNTPOINT="/Users/YourUser/Public/backup"

After this I would ping the NAS once, just to wake it up because it has power saving features and mount would fail if the NAS was sleeping when the mount command was issued – I could make it retry after a few seconds, but this is easier 😉 . You can just leave it out of the script if you don’t need it.

echo Starting backup on $(date)
ping -c 1 192.x.x.x
sleep 10
echo Mounting photo backup disk
mount_smbfs //'WORKGROUP;NasUsername:N@sPassw0rd'@$SHARE $MOUNTPOINT

The NasUsername and N@sPassw0rd gets sent as URL, so you might want to encode them properly. For this, you can use this link. Note how our N@sPassw0rd becomes N%40sPassw0rd.

OK, now we check if the share is mounted. It can happen that you are not on the network with your NAS, so there is no use for the backup to run. If it cannot mount the share, it will give you feedback and quit the script.

if mount | grep "on $MOUNTPOINT" > /dev/null; then
...
else
echo Photo backup disk cannot be mounted. Exiting.
fi

If everything is OK, then we go on with the backup:

rsync -abhP --backup-dir=_rsyncbck --delete --exclude=_rsyncbck --stats ~/Pictures/Photos\ Library.photoslibrary/Masters/ $MOUNTPOINT/
echo Unmounting photo backup disk
umount $MOUNTPOINT
echo Photo backup finished on $(date)

This is what the rsync command does: It backs up files as archive (a), it creates backup of deleted files from source (b), it makes the output human readable (h), it saves progress (P). The backup directory is defined, it’s also excluded so rsync doesn’t recreate it every time leaving you with a mess of a folder structure and –statsis added so we have a nice little log about everything rsync did. You can also add z so it uses compression and save some bandwidth (at the cost of CPU).

Below is the whole script, save it as photos_backup.sh. Of course, make adjustments to reflect your own environment.

#!/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

SHARE="192.x.x.x/photo/Masters"
MOUNTPOINT="/Users/YourUser/Public/backup"

echo -en '\n'
echo Starting backup on $(date)
ping -c 1 192.x.x.x
sleep 10
echo -en '\n'
echo Mounting photo backup disk
mount_smbfs //'WORKGROUP;NasUsername:N%40sPassw0rd'@$SHARE $MOUNTPOINT
if mount | grep "on $MOUNTPOINT" > /dev/null; then
echo -en '\n'
echo Backing up Photos Library
rsync -abhP --backup-dir=_rsyncbck --delete --exclude=_rsyncbck --stats ~/Pictures/Photos\ Library.photoslibrary/Masters/ $MOUNTPOINT/
echo -en '\n'
echo Unmounting photo backup disk
umount $MOUNTPOINT
echo Photo backup finished on $(date)
echo =====================================================================
else
echo -en '\n'
echo Photo backup disk cannot be mounted. Exiting.
echo =====================================================================
fi

The many echo lines are there just so the log file generated looks nice 😉 Note the trailing “/” in the paths in the rsync command! With how this is set up it would sync the content of the Masters folder into a Masters folder on the NAS backup drive!

Now we set the proper permissions on the *.sh file we created. Pop Terminal, navigate to where you saved your script and:

chmod a+x photos_backup.sh

You could execute this script manually and it should work fine

./photos_backup.sh

But we want the script to execute automatically with launchd. First we need to create a *.plist file. Mine is set up to run every Sunday at 22:00. You can play around with the occurrence by defining other values below StartCalendarInterval. Save it as com.backup.photos.plist – adjust to your environment.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.backup.photos</string>
 <key>ProgramArguments</key>
 <array>
 <string>/Path/to/your/script/photos_backup.sh</string>
 </array>
 <key>StandardErrorPath</key>
 <string>/Path/to/your/error.log</string>
 <key>StandardOutPath</key>
 <string>/Path/to/your/success.log</string>
 <key>StartCalendarInterval</key>
 <dict>
 <key>Minute</key>
 <integer>00</integer>
 <key>Hour</key>
 <integer>22</integer>
 <key>Weekday</key>
 <integer>7</integer>
 </dict>
</dict>
</plist>

Now we move the *.plist file created to it’s proper location and we register it so it runs when defined. Open Terminal and execute:

cp ~/Path/to/your/com.backup.photos.plist ~/Library/LaunchAgents
launchctl load -w ~/Library/LaunchAgents/com.backup.photos.plist

All done! You should also get nice log files in the place you specified.

This was tested on OS X El Capitan and MacOS High Sierra but it also should work on other versions. You can modify the script to backup other things too!

Let’s say you are on a trip and want a secure connection while you check your e-mail or you want to have secure access to home computers. Let’s say you work in a corporate environment where the network admin is overzealous with connection rules and you want to access restricted sites (though tempering with those rules can get you fired). Let’s say you live in a shithole country like I do and want to access Pandora, Spotify or Hulu. That’s where SSH tunneling comes into play.

First you need some kind of SSH server. You can use a free or paid service that offers SSH services (like silenceisdefeat.com), you can run it on your home computer (any OS) or have a router that has an SSH server. In my case, I have a really nice Linksys WRT54GL router with Tomato firmware on it and its SSH server works pretty well and it’s also cost efficient.

About router configuration and port forwarding

Normally SSH runs on port 22, but it’s somewhat unwise to leave it open on the WAN side. For example if you run your SSH server off off a Windows machine with freeSSHd, it will run on the machine’s IP and on port 22 inside your LAN. Now you need to forward that port to the internet so you can access the SSH server remotely from outside. The screenshot is from a WRT54GL, but it should be similar on your router too.

Now that we forwarded port 443 to the internet (you can choose any random port to forward port 22 to), we know that we can access our server from that port. We also need to have some means to access our home router from the internet. Most likely you have a dynamic IP allocated to you by your ISP, so we have to nail that IP somehow. The most straightforward method is to use a service like dyndns.com, a free DNS service that can translate your allocated IP to an address you can easily remember (ex. testssh.someserver.com). You need to set this thing in your router once and then it updates your associated IP automatically. Look for DDNS (Dynamic DNS) setting on your router or something similar. In this example we would access our server at testssh.someserver.com:443

When the SSH server part is out of the way, you need an SSH client to access the server remotely. If your client machine runs Mac or Linux, you don’t have to worry, because the SSH client is built-in. If you are on Windows you need a neat little program like PuTTY.

The Windows way – setting up PuTTY

Now go to SSH and select tunnels there. Type the port number you want your tunnel to work on in the source port field, select Dynamic and click Add, go back to Sessions menu and click Save to save the connection. If you go back to the SSH menu, it should look like this – I have chosen port 8080 for my tunnel:

If you happen to be behind a firewall, you may need to specify a proxy setting also for things to work, this can be done in the Proxy menu on the left. So now that we configured our client we test the connection and open the SSH tunnel – click on Session > Open in putty. The server will ask for your username and password in a terminal window. Log into your SSH server and the tunnel is open. Do not close the PuTTY window as with closing it, you close the tunnel also. Now that we have the tunnel, it’s time to configure our system to use it. You can apply it system-wide from Internet Options, going to Connections -> LAN settings -> Advanced and configuring the SOCKS proxy (enter localhost and the port you chose in PuTTY’s Tunnel settings):

You can also use the tunnel in a browser that you only keep for this purpose (so your environment still works, but you can visit restricted sites). In Firefox it would look like this:

SSH Tunnel on Mac OS X / Linux

If you are on Mac OS X or Linux then it’s nothing more to do then fire up a Terminal window and type:

ssh -D 8080 -C -N username@testssh.someserver.com

If you need to specify a remote port other than the default port 22 (like in our example above) we add the -p switch while specifying the port :

ssh -D 8080 -p 443 -C -N username@testssh.someserver.com

The -C (compression) switch is useful if you are on a modem or bad connection, otherwise drop it. The -N switch is useful for port forwarding (doesn’t allow remote execution), like in our case. The rest of the configuration goes just as in Windows for browser settings. For system-wide usage go to Proxies in System Preferences and set it there.

As you can see you can use the tunnel for any means you see fit, basically once you open up the SSH tunnel and tell your system to use it, it’s like you are in the LAN you open the tunnel to – this means that if you download something, it will use your home bandwidth also (assuming your SSH server runs on your home network).