En ja hoor... alweer eens tevroeg gejuicht!

Jammy J. draaide uitstekend, ondanks de last van Virtualmin op z'n rug. Totdat ik met een stomme kop een regeltje verwijderde uit de netwerk-definitie sectie van Virtualmin. Waarom ik dat deed? Omdat sinds alle wijzigingen van de router en van het OS ik 4 IP-adressen van de router krijg voor de thuisserver. Op zich geen probleem, maar ik vraag er maar 3. Kan ik dan die ene, die ik echt niet nodig heb niet gewoon weigeren? Nee, dat kan dus niet. Zucht...

Het is een gevolg van alle wijzigingen die binnen Ubuntu werden en worden doorgevoerd in het vastleggen van de netwerk-definities. Tegenwoordig gaat dat met netplan. En zoals ik al eens eerder heb geschreven: daarbij is het niet eenvoudig om statische IP-adressen vast te leggen. Eén IP-adres is geen probleem, maar 3 verschillende voor één apparaat? Dan krijg je er gelijk 4, of je wilt of niet. Terwijl ik dit schrijf realiseer ik me een omweggetje... hmm, komen we op terug.

Maar goed... wat je dus niet moet doen is gaan klojen in de netwerk-definties in Virtualmin. Dat heeft hetzelfde effect als het verwijderen van de netplan-defs. En dàt had ik de volgende ochtend pas door. Ik deed de stomme zet twee dagen geleden, 30/5/2022, vlak voor ik naar bed ging. De volgende ochtend zag ik dat de thuisserver stond te draaien, had zichzelf keurig op de gewenste tijd uitgeschakeld, en de volgende ochtend weer aangezet (jaja, ook op Jammy werkt rtcwake keurig!) en was als volgende stap wat folders gaan synchroniseren tussen de extra HDD en de NAS. Prima! Maarre...

Het scriptje dat de synchro's doet, ging ervan uit dat de doel-volume op de NAS succesvol gekoppeld was op de thuisserver. En dat kàn helemaal niet na netwerk-definitie-geklooi. Dus probeerde het scriptje te synchroniseren naar de "lege" aankoppel-folder op de OS-SSD van de thuisserver. Die was snel tot barstenstoe gevuld! Al wat ik zag, toen ik een monitor en toetsenbord aan de thuisserver had gehangen, was een computer die het prima deed, zij het met een overvolle OS-partitie en zonder internetverbinding. Maar ik zag niet -zo 1... 2... 3...- waar al die ruimte was heengegaan. Na enig gezucht, erin geslaagd de netwerk-verbinding te herstellen, en toen gewoon via SSH gaan zoeken waarheen de ruimte was verdampt. Meestal, als een server volloopt, is antwoord te vinden in /home of in /var. Het was snel duidelijk dat /home de boosdoener niet was. Maar /var... daar zet het systeem van alles en nog wat in... Geprobeerd die folder te verplaatsen naar de extra HDD, die heeft met z'n 2TB altijd wel ruimte over. Maar /var kan je op een draaiend systeem niet zomaar even verplaatsen. Dat leidt tot nog meer ongein, vooral apt de pakket-beheerder van Ubuntu gaat dan tegenspurtelen.

Lang verhaal een beetje korter: de enige manier om een goede /var terug te krijgen was... overnieuw beginnen. OS opnieuw geïnstalleerd, dus weer Focal Fossa. Eerst goed kijken of de OS-partititie wel veilig geformateerd kan worden. Hé, waarom staat er zoveel in /uhome, terwijl de NAS niet eens gekoppeld is? O, dáár is de schijfruimte gebleven... Ik had dus helemaal niet met /var hoeven oetelen. Maar ja, te laat nu. Dus Ubuntu 20:04 opnieuw erop gezet. Virtualmin opnieuw er boven op, net als ufw, samba, qbittorrent en minidlna en alle kleine extra's. En dan weer de release-upgrade en toen het tegen bedtijd was draaide de thuis-server weer lekker op Jammy.

Vanmorgen heb ik éérst het synchro-scriptje aangepast. Het test nu of er echt een werkende verbinding naar de NAS is, voor aan het werk te gaan (if mountpoint -q /uhome then...). Al doende leer je...