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.
I’d setup Traefik to use LetsEncrypt, but due to the scarey words around rate limits etc, I felt it sensible to use the staging LetsEncrypt servers, rather than the production ones – basically I wasn’t sure how many changes I’d have to make as it has been a while since I played with any of this in anger. I assumed that Traefik would renew the certificates with LetsEncrypt when I needed production ones.
I surprisingly got this working quite straightforwardly – I had more issues with getting Apache and WordPress (mainly Apache) playing nicely with everything.
However, the staging certificates result in a warning which I didn’t want any longer than necessary. Since it now was working, I altered my certificate resolver in Traefik to point to the production LetsEncrypt server. I then performed a bounce to pick up the changes, expecting to see a new certificate and no more errors.
Anxious pause…
I waited a bit (pressing F5) and was disappointed to see that it hadn’t changed. Same certificate was in use, and I could see in the log that no attempt had been made to fetch a new certificate.
Frantic prodding ensued as I attempted to work out what I had done wrong. Nothing was the answer. The problem, such as it is, is that Traefik already has a certificate that it can use. Traefik doesn’t feel it needs to change it the certificate.
Whilst the last link on the face of it initially seemed less relevant (it related to fixing a security flaw), on reading it gave the simplest answer for my situation.
In my situation, it looked like I could simply delete the storage acme.json file. No certificates needed to be kept – I could just start again from scratch.
I stopped Traefik, moved acme.json out of the way (belts and braces right), and then restarted it.
Traefik Renew from LetsEncypt!
Hey, Presto! I could see in the log file the lack of certificate being identified and Traefik calls to renew certificates from the production LetsEncrypt server.
Padlock look right, everything is gravy! Let’s move on to the next thing.
An explanation of how to set up Traefik Log Rotation. This covers both the access log AND the traefik log.
I initially setup simple log rotation using the standard logrotate package i have installed for everything else. I implemented this by following this page (there are others about) but this covered my scenario the best (as I have traefik running natively, not in a container.
The main change I made was in the directory (mine is /var/log/traefik/) and then the files (I have an access.log and a traefik.log, so I altered the pattern to be *.log. I also added size – more on that in a minute.
This resulted in a file /etc/logrotate.d/traefik below:
However, I began to spot that it did not working as anticipated.
access.log wouldn’t rotate
traefik.log rotated but still wrote to the rotated our file
It turns out access.log not rotating was because I misunderstood what size would do. It’s not an either/or with the daily setting – size supersedes daily if it is in the file. Simply removing size made access.log rotate as expect.
However, traefik.log still won’t rotate on a USR1 – which seems contrary to their own documentation (link).
I decided that something weird must be going on, so I dug about a bit. If you check the code in git (link) you’ll see that the code specifically mentions rotation of the access log, and their tests also only check the access log.
This means that USR1 signal only rotates the access log. That was annoying.
I wondered if I was missing something, so I went in search of rotate in git (link) and found something that whilst documented at source level seems to be missing in the Traefik log documentation (link).
It turns out that Traefik can do some quite clever stuff with rotating its own log if you configure it right.
log:
# Log level
#
# Optional
# Default: "ERROR"
#
level: <whatever level you want>
# Sets the filepath for the traefik log. If not specified, stdout will be used.
# Intermediate directories are created if necessary.
#
# Optional
# Default: os.Stdout
#
filePath: <directory location>/<file>.log
# Format is either "json" or "common".
#
# Optional
# Default: "common"
#
#format: json
maxSize: 5
maxBackups: 50
maxAge: 10
compress: true
This will rotate at 5Mb, compress the old copies, and keep for 10 days and keep a maximum of 50 files. There are other options in the document – I have not used them.
This then means I can make the logrotate configuration focus just on the access log:
I purchased a FAN-SHIM and Raspberry Pi 4 from Pimoroni last year but occasionally saw a problem, and struggled with a diagnosis.
The FAN-SHIM generally worked great, but I noticed that it didn’t seem to always work when I didn’t have a lead coming off the header to a breadboard. The fan would just run, the LEDS wouldn’t work – it was basically unhappy. Given it was directly related to the cable, I took the easy route to fixing things – leave it attached! However, I always wanted to properly diagnose what was going on.
Stock Pi 4 with a FAN-SHIM plugged in.
Exploring Problems with the FAN-SHIM on a Pi
I recently had a chance to look at this again, and this is collecting my exploration and thoughts. In short, I did a lot of hunting about, until I found something that really helped me diagnose things. I knew the installation was working – as I said, with the cable attached all is good. However, I didn’t really want it plugged in all the time. It looked like it was pushed on OK – but I had no control.
How could I work out if it was the SHIM with an issue, my Pi or something else?
Eventually, I found this page. A comment by gadgetoid suggested a really good diagnostic approach.
Diagnosing the FAN-SHIM problem on the Pi
Basically, turn the fanshim service off:
systemctl stop pimoroni-fanshim.service
Then, start up python and run the following:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
GPIO.setup(18,GPIO.OUT)
GPIO.output(18,0) # Should turn fan off
GPIO.output(18,1) # Should turn fan on
Basically, run the command to get the fanshim to do what it isn’t at the moment. Then adjust the fanshim until the action actually happens – so in my case it finally turned off!
Having done this, I could run now run the other test scripts in the fanshim example source code.
Finally the LED would change as expected, and the fan would turn on and off as expected.
I now re-enabled the fan-shim service:
systemctl start pimoroni-fanshim.service
Now, I know how to check things if it goes wrong again!
Hey! I’ve managed to configure Microsoft Live Writer to work with my Drupal install (see this URL).
I had a minor issue configuring Microsoft Live Writer, where I couldn’t login as my non-administration user. Initially, I worked that that returning the edit privilege in Drupal “Authenticated Users” made it work. Since then I had a more detailed look at this issue. It seems that rights to the Blog API needed to be granted. After that, I managed to restrict the rest of the rights to more or less where they were before.
So, now I might actually start using Live Writer… it’s much easier to blog this way (yes, I like to do things the easy way were ever possible).
So I decided to add an user wolagent and put the script into his home directory. The question is how to backup this user. Simply using the ‘s’ – command from the Bering 3.x – menu doesn’t backup the user and his homedir. In short, there seemed to be no way to persist this Bering change locally.
So how can I do that? Add your stuff to /var/lib/lrpkg/local.local
