And yes... cheered too early again!

Jammy J. performed excellently, despite the burden of Virtualmin on his back. Until I stupidly deleted a line from the network definition section of Virtualmin. Why I did that? Because since all the router and OS changes I am getting 4 IP addresses from the router for the home server. Not a problem in itself, but I only ask for 3. Can't I just refuse the one that I really don't need? No, that is not possible. Sigh...

It is a result of all changes that were and are being made in Ubuntu in the recording of the network definitions. Nowadays, this is done with netplan. And as I have written before: it is not easy to define static IP addresses. One IP address is no problem, but 3 different ones for one device? Then you immediately get 4, whether you like it or not. As I write this I realize a detour... hmm, let's get to that.

Anyway... what you shouldn't do is mess around with the network definitions in Virtualmin. This has the same effect as removing the netplan defs. And I didn't realize that until the next morning. I made the stupid move two days ago, 5/30/2022, just before going to bed. The next morning I saw that the home server was running, had switched itself off neatly at the desired time, and switched it on again the next morning (yes, rtcwake also works on Jammy !) and as the next step I synchronized some folders between the extra HDD and the NAS. Fine! But...

The script that does the synchros assumed that the destination volume on the NAS was successfully mounted on the home server. And that is not possible after network definition messing around. So the script tried to synchronize to the "empty" mount folder on the home server's OS SSD. It was quickly filled to bursting! All I saw when I hooked up a monitor and keyboard to the home server was a computer that worked just fine, albeit with an overcrowded OS partition and no Internet connection. But I didn't see, immediately, where all that space had gone. After some sighing, managed to restore the network connection, then just SSH to find where the space had evaporated. Usually, when a server fills up, the answer can be found in /home or in /var. It quickly became clear that /home was not the culprit. But /var... the system puts anything and everything in there... Tried to move that folder to the extra HDD, which always has space left with its 2TB. But you can't just move /var on a running system. That leads to even more mischief, especially apt, the package manager of Ubuntu, will struggle.

Long story a little shorter: the only way to get a good /var back was... to start over. OS reinstalled, so Focal Fossa again. First check whether the OS partition can be safely formatted. Hey, why is there so much in /uhome when the NAS isn't even mounted? Oh, that's where the disk space went... So I shouldn't have had to fiddle with /var at all. But yeah, too late now. So reinstalled Ubuntu 20:04. Virtualmin again on top, as well as ufw, samba, qbittorrent, and minidlna, and all the little extras. And then the release upgrade again and when it was close to bedtime, the home server was running on Jammy again.

This morning I first modified the synchro script. It now tests if there really is a working connection to the NAS before going to work (if mountpoint -q /uhome then...). By doing you will learn...