The only wrinkle I have found is that the remote node doesn’t always remember the multiple keys properly – as it only is supposed to have one key.
On ASUSWRT, the main router strips out a false carriage return characters and puts the carriage return back. If the AIMesh node reboots, I have to go and do that same action by hand.
This post is intended to cover how to install the Traefik Proxy on a Debian server. The process is a little complex as, unfortunately, there isn’t a .deb file that I could find.
This will not be use under a functional configuration is in place.
Starter Configuration
Static Configuration
Now copy the below starter configuration and place it in /etc/traefik/traefik.yaml
################################################################
#
# Configuration sample for Traefik v2.
#
# For Traefik v1:
# https://github.com/traefik/traefik/blob/v1.7/traefik.sample.toml
#
################################################################
################################################################
# Global configuration
################################################################
global:
checkNewVersion: true
sendAnonymousUsage: true
################################################################
# EntryPoints configuration
################################################################
entryPoints:
web:
address: :85
websecure:
address: :448
################################################################
# Traefik logs configuration
################################################################
log:
level: DEBUG
################################################################
# API and dashboard configuration
################################################################
# Enable API and dashboard
api:
dashboard: true
providers:
file:
filename: /etc/traefik/dynamic.yaml
In short, this file will:
Make traefik listen on port 85 and 448
Increase logging to debug level So, we can see what is going on
Enable the API and the Dashboard
Configure a file provider call dynamic.yaml
Dynamic Configuration
Now create an authentication user (replace the content of the angle brackets) – you will need the output from this in the next step.
htpasswd -nb <user> <password>
Follow this up with placing this in /etc/traefik/dynamic.yaml replacing <string from htpasswd> with your string from htpasswd (yes, put it inside the double quotes).
# dynamic.yaml
http:
routers:
api:
rule: PathPrefix(`/api`) || PathPrefix(`/dashboard`)
service: api@internal
entryPoints:
- "web"
middlewares:
- auth
catchall:
# attached only to web entryPoint
entryPoints:
- "web"
# catchall rule
rule: "PathPrefix(`/`)"
service: unavailable
# lowest possible priority
# evaluated when no other router is matched
priority: 1
middlewares:
auth:
basicAuth:
users:
- "<string from htpasswd>"
services:
# Service that will always answer a 503 Service Unavailable response
unavailable:
loadBalancer:
servers: {}
Yes, the back ticks are correct, single quote will cause a problem due to go.
This file sets up the following:
Two routers
API
catch traffic coming in from the “web” entry point (85)
protects using the auth middleware
looks for /api and /dashboard traffic
will then route trafic to api@internal service
CatchAll
catch traffic coming in from the “web” entry point (85)
looks for anything under /
will route traffic to unavailable service.
Middleware To protect the api and dashboard endpoints from prying eyes.
Service To show when things are broken.
Install Traefik Proxy
The next step of the install of Traefik Proxy on Debian is to extract the downloaded zip file:
cd /opt/traefik
tar -zxvf <download location>/traefik_v<version>_<platform>.tar.gz
Since traefik proxy will be using privileged ports, it therefore needs a permission setting:
sudo setcap 'cap_net_bind_service=+ep' traefik
Testing Traefik Proxy
This is where things begin to get fun. I had some fun and games with getting the Dashboard to work initially, hence why I am writing this and posting it for posterity.
You MUST have the PathPrefix rule to make Dashboard and API endpoints work right.
On the plus side, its presence in dynamic.yaml means we can fiddle about with the file and Traefik Proxy will just reload it.
Now, simply run the Traefik Proxy executable – it looks in standard locations for configuration and /etc/traefik/traefik.yaml is one of those.
./traefik
If it works you should see something like this:
You should also be able to access various URLs.
api/endpoints
dashboard
anything else
Assuming everything is working we can now go about locking the software installation, enabling the services configuration that was setup, and linking it to the Docker.
Troubleshooting
Hopefully, Traefic Proxy is working for you. If it isn’t the terminal that Traefic is running in should give you some indication of what has gone wrong.
It is likely to be related to listening on the selected ports. The simplest option would then be to move to a different port by altering the values for address in /etc/traefik/traefik.yaml.
Having done this, stop traefik [if needed] and re-run it.
As part of the creation of my new lab installation I wanted to migrate WordPress from barebones Apache/FPM into a custom PHP container.
The original thought was to segretate the web server and PHP FPM from one another – but it seemed to be far to complex. I eventually found this web site:
This site is talking about a generalised solution for embedding any PHP application into a container, but it turns out the approach worked fine for WordPress too.
In short, it is easier to start off with a PHP-FPM container. So I chose one from the DockerHub PHP site.
Having done that, I created a Docker file:
# Dockerfile.nginx - PHP-FPM with Nginx in a single container
FROM php:8.3-fpm-alpine
# Install Nginx
RUN apk add --no-cache nginx curl
# Install PHP extensions
RUN apk add --no-cache \
freetype-dev \
libjpeg-turbo-dev \
libpng-dev \
libzip-dev \
icu-dev \
postgresql-dev \
&& docker-php-ext-configure gd --with-freetype --with-jpeg \
&& docker-php-ext-install -j$(nproc) \
gd zip intl pdo pdo_mysql pdo_pgsql opcache
# PHP-FPM configuration
COPY php-fpm.conf /usr/local/etc/php-fpm.d/www.conf
COPY php-production.ini /usr/local/etc/php/conf.d/production.ini
# Nginx configuration
COPY nginx.conf /etc/nginx/nginx.conf
COPY nginx-default.conf /etc/nginx/http.d/default.conf
# Copy application code
COPY . /var/www/html/
RUN chown -R www-data:www-data /var/www/html
# Startup script that runs both Nginx and PHP-FPM
COPY docker-entrypoint.sh /docker-entrypoint.sh
RUN chmod +x /docker-entrypoint.sh
EXPOSE 80
HEALTHCHECK --interval=15s --timeout=5s --retries=3 \
CMD curl -f http://localhost/health.php || exit 1
ENTRYPOINT ["/docker-entrypoint.sh"]
This file:
Installs NGINX
Configures NGINX
Installs PHP modules.
Configures FPM
Installs CURL
Defines a CURL healthcheck
Mounts the application and fixes the permissions.
TODO: add actual example files.
I then just archived my installation on the old server, and transferred the directories to the Lab server. These where then mounted as volumes.
Obviously, I need to do regular checks of the image to make sure it is patched up – but WordPress is working in my custom PHP container (as you can tell by being here now!)
I’ve recently reinstalled my HomeAssistant using HAOS, rather than my previous Supervisor install – mainly because the suppliers of HomeAssistant have desupported that method. However, I still want to be able to connect at the operating system level, rather than only relying on HomeAssistant WebUI for everything – and that means getting HAOS SSH mode working.
I initially attempted to follow the “USB Method” documented here:
However, it didn’t seem to want to work – even though the command appear to complete correctly. And I obviously couldn’t see if it was working, as I don’t have access to the operating system to check!
Open addon Web UI and run the following: cp /etc/ssh/authorized_keys /share docker run -it --rm \ -v /root:/mnt/root \ -v /mnt/data/supervisor/share:/mnt/share \ bash cp /mnt/share/authorized_keys /mnt/root/.ssh rm /share/authorized_keys ha host reboot
HomeAssistant will now reboot (the final command told it to).
That’s all. You should be able to access HAOS using ssh and the same keys on:
My Lab server needs to be able to send emails now. I’ve done some digging about, and have decided that I will configure Postfix to do forward things to my email hosting provider instead of exim4.
Obviously, this required a bit more thumping this time, as I’ve never used Postfix before.
Annoyingly, the default that Debian sets up results in warning being generated in log files, which means you have to manually tune the main.cf file to make the warning go away and then I could configure it to forward to my email host.
These initial changes involve me adding the following:
As part of setting up my new lab server, I needed to transfer Nginx Proxy Manager from its old home to a new home. This is intended to capture what I did, in case I ever need to repeat the process.
Backup npm_data/_data and npm_letsencrypt/_data locations on the old host.
Migrate the stack from the old host to the new host using Portainer.
Stop the new stack
It will create an empty installation, which is obviously not useful for me.
Restore the backup of the stack volumes, replacing the ones the migration just created.
Restart the stack,
The transfer of Nginx Proxy Manager is now complete. Check that it has connectivity to the downstream servers, and then move any firewall rules so that it is now the external server rather than the old one.
Obviously now clean up the old installation on the old docker server.
I use Nginx Proxy Manager to direct things around my URLs and web sites – including Home Assistant.
Its a great product, but does mean I have to configure my applications right to route via it.
This is a notes because I had forgetten I had done a thing!
Remember that in Home Assistant, there will need to be an entry under “http” in “trusted proxies” section for the server doing the work.
This was mainly caused by the fact that I was changing from a “co-locating” the docker containers that I use for HA and NPM to ones that had to route between servers.
My original values listed 172.20.x.x and I now needed to list the server IP address.
I use the product Portainer to manage the various docker containers I have at home. Periodically, I change my infrastructure set up, which results in my having to transfer the Portainer containers to a different server.
This time, I have decided to document what I did, in an attempt to not have to recreate the wheel next time I need to perform this activity.
Check you have the command line for starting Portainer.
Obviously, you will need this to start up portainer when it gets where it is going.
Make a volume on the new host.
This will hold a copy of the persisted Portainer data.
Stop portainer on the old host
Backup the old volume on the old host.
You’ll likely need to be root to view the folder correctly.
Transfer the backed up file to the new host using scp.
Restore the backup file into the volume on the new host.
You’ll likely need to be root to get the permissions correct.
Startup portainer using the volume
At this point the transfer of Portainer is technically complete.
Test you can connect to portainer.
Startup portainer agent on the old host.
This is so that I have access to the old host again. I’m going to need this to clean up the old host.
Redirect the proxy.
I use NPM and I needed to fix the proxy to fetch portainer from the new host.
Clean up stacks
In this situation i am moving to a new Lab server, so I have copied stacks from the old host to the new host, manually backing up and transferring volumes as required.
