Zomervakantie 2025 – DE, CZ

Van de zomer gaan we naar Duitsland en Tsjechie. Voor Duitsland hebben we al een locatie, maar voor Tsjechie nog niet; daarom eerst in kaart brengen waar we al geweest zijn:












Poging voor een andere weergave, gebaseerd op tekst later in de post?

[leaflet-map fitbounds]
[overviewmap debug latlngs=ovm-latlng show_thumbnails]
[hover snap=0 class=leafext-overview-tooltip]

Print this entry

k3s op Proxmox

Om gemakkeijk Postgres scenario’s door te nemen, gebruiken we bij de “Blue Elephant Pack” containers op Kubernetes.

Een eenvoudige manier om Kubernetes te gebruiken, is via k3s. Kubernetes vereist aanpassingen aan de LXC containers die Proxmox beschikbaar stelt. Het makkelijkste is om /etc/pve/lxc/100.conf (althans, het nummer van de betreffende container) aan te passen:

  • De container moet priveleged zijn
    • unprivileged: 0
  • Nesting moet toegestaan zijn voor de container
    • features: nesting=1
  • Een aantal modules moet beschikbaar gemaakt worden aan de container
    • op de host: /etc/modules-load.d/modules.conf
      • overlay
      • nf_nat
      • br_netfilter
      • xt_conntrack
      • aufs
      • vhci-hcd
      • eventueel toevoegen in de container aan /etc/modules
  • Enkele losse aanpassingen aan de containerconfiguratie zijn nodig
    • lxc.apparmor.profile: unconfined
    • lxc.cgroup.devices.allow: a
    • lxc.cap.drop:
    • lxc.mount.auto: proc:rw sys:rw

Zolang de configuratie niet in orde is, faalt de configuratiecheck: k3s check-config roept aan het einde modprobe: FATAL: Module configs not found in directory /lib/modules/kernelversie

Laatste status:

  • k3sup install van de triangletodd-link hieronder geprobeerd;
    • warning: er ontbreken nog modules
    • error: geen toegang tot /proc/sys/net/netfilter/nf_conntrack_max

Hints:

  • SSH opeens ‘stuk’ in de container? Controleer of .ssh/authorized_keys eigendom is van root of van 100000 ; met dat laatste doet hij het (terecht?) niet.
    • Een betere optie zou misschien zijn een nieuwe gebruiker aan te maken, die echt geen root is (noch op de host, noch in de container).
    • Het zou veroorzaakt kunnen zijn door het switchen van unprivileged container naar privileged container: in een privileged container zal root echt root zijn.

Bronnen:

Retry, nu met een VM ipv LXC

Met de quickstart van k3s.io: curl -sfL https://get.k3s.io | sh -

Ongeveer 10 seconden later: klaar

Het is nu een single-node cluster; later meer nodes toevoegen, maar eerst zorgen dat Postgres ‘t doet

Cloudnative PG

De quickstart op cloudnative-pg.io geeft:

  • Operator installeren: kubectl apply --server-side -f \ https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.25/releases/cnpg-1.25.1.yaml
  • Verifieren dat ‘ie ‘t doet / er is: kubectl get deployment -n cnpg-system cnpg-controller-manager
  • Creeer een yaml-bestand met de configuratie voor ‘t Postgres-cluster, bijvoorbeeld het cluster-example.yaml van de site
  • Start de configuratie met kubectl apply -f cluster-example.yaml
  • Check het resultaat met kubectl get pods
kubectl get pods
NAME                             READY   STATUS      RESTARTS   AGE
cluster-example-1                1/1     Running     0          21s
cluster-example-1-initdb-vmmb5   0/1     Completed   0          59s
cluster-example-2-join-vtb4d     0/1     Completed   0          10s

Toegang tot de database was een beetje puzzelen. CloudnativePG werkt met kubectl cnpg .., maar dat herkent mijn installatie niet. Mogelijk te wijten aan K3S, maar misschien ook een gebrek aan kennis.

Wat wel werkt, met dank aan ‘arsblogger.com

kubectl exec -it cluster-example-1  -- psql -U postgres -c "SELECT pg_is_in_recovery();"

Hij heeft op diezelfde pagina hints hoe hij het cluster via een node port extern beschikbaar maakt

Print this entry

Snappymail admin password

Ik blijf de (werkwijze voor de) adminpagina en de credentials voor Snappymail vergeten. Het idee is simpel: de applicatie maakt een initieel admin wachtwoord; je past het aan na het inloggen en verwijderd het oorspronkelijke bestand met het wachtwoord. Klaar.

Alleen, dat ontschiet me wel eens. Ook de locatie van het adminpanel, of het bestaan ervan: meestal blijft het werken na initele configuratie.

Dus, als samenvatting:

  • Initieel admin password:
    • bestaat niet tijdens installatie van Snappymail
    • bezoek de adminpagina, op https://sub.domain.tld/snappymail/app/?admin
    • log in op de server via SSH, ga naar /var/www/snappymail/app# cd data/_data_/_default_/
    • het kan even duren voor het bestandje gecreerd is; zodra het bestaat kun je in die directory admin_password.txt openen
    • log in op het “Admin Panel” met admin als login en het gevonden wachtwoord als passphrase ; TOTP is initieel niet geconfigureerd.
    • je wordt er aan herinnerd het wachtwoord te wijzigen
    • Snappymail verwijdert automatisch het bestandje met het tijdelijke wachtwoord
  • Na vergeten van het wachtwoord:
    • Een versleutelde versie van het wachtwoord is opgeslagen in de config, te vinden op
      /var/www/snappymail/app/data/_data_/_default_/configs/application.ini
    • de eigenschap heet admin_password, onder het kopje “Login and password for the web admin panel”
      • is de waarde leeg? Dan heb je nog niet ingelogd. Het wachtwoordbestandje wordt aangemaakt na bezoeken van de admin-pagina
      • is de waarde gevuld? Dan heb je al eens ingelogd.
    • nieuw wachtwoord genereren:
      • verwijder het het genoteerde wachtwoord
      • bezoek de adminpagina opnieuw (eventueel in private browser venster)
      • het bestandje admin_password.txt wordt even daarna automatisch aangemaakt
    • log in met het nieuwe wachtwoord
    • bovenaan de pagina wordt een banner getoond met de suggestie het wachtwoord te wijzigen
      • behalve het wachtwoord, kun je ook de naam van de admingebruiker aanpassen
      • let op dat je ook het (nieuwe/tijdelijke) huidige wachtwoord nodig hebt
      • de nieuwe gebruiker/wachtwoordcombinatie wordt weggeschreven in de eerder genoemde application.ini
    • na wijzigen van het wachtwoord ruimt Snappymail zelf het bestandje met het tijdelijke wachtwoord op

Print this entry

Proxmox ACME voor Let’s Encrypt

Het is telkens weer puzzelen, nu een aantkening voor de volgende keer:

  • Account aanmaken
    • Kan op datacenterniveau, maar ook vanuit de node
    • Ik maak een account per node
  • Challenge-plugin activeren, indien nodig
    • HTTP-01 is het meest gebruikelijk, maar vereist (read only) toegang vanuit Letsencrypt naar de webserver; het werkt zonder plugin
    • DNS-01 verifieert via een TXT record op de DNS server. Zodoende ook te gebruiken voor private IP’s en machines die niet vanuit het publieke Internet te bereiken zijn (of geen webserver hebben draaien). De plugin heeft toegang nodig tot de API van je DNS server om het TXT record te maken.
  • Domein toevoegen
    • Op node-niveau
    • Kies hier ook het te gebruiken account

Account aanmaken, eventueel plugin activeren onder “Datacenter”

Register account

Geef een naam op voor het account, maak een emailalias en vul die in; kies eerst de staging directory, maak als alles goed ingericht is een nieuw account voor de reguliere (production) directory. Ik hergebruik het emailadres.

yunohost user update mailbox_account --add-mailalias letsencrypt_pve_node@osba.nl

Voor de DNS-01 plugin is de naam vrij te kiezen; de delay laat ik op de default staan. De DNS API moet natuurlijk die van je DNS server zijn. Mijn DNS loopt via dns.he.net (HE), de API data zijn “HE_Username=accountnaam”, “HE_Password=accountwachtwoord”. Gezien de gevoeligheid van die gegevens, geef ik de voorkeur aan HTTP-01.

Certificaat toevoegen onder “Certificates”

De bovenste helft van het scherm is al gevuld met de self-signed certificaten van Proxmox. Kies in de onderste helft , achter ACME, eerst het zojuist aangemaakte account en klik apply:

Voeg een te certificeren domein toe met de “Add”-knop. Zonder instellen van de DNS-01 plugin, wordt automatisch voor HTTP-01 als methode gekozen, daaronder geef je het domein op:

Klik nu “Order certificates”. Succesvol? Dan een account voor productie aanmaken, en opnieuw een account aanvragen.

CLI opdrachten

Tekstopdrachten om hetzelfde te bereiken:

  • pvenode acme account register pve-node-staging letsencrypt_pve_node@osba.nl
  • pvenode acme config set --acme accoun=pve-node-staging domains=pve-node.osba.nl
  • pvenode acme cert order
  • systemctl restart pveproxy

PVEproxy restart

Let op: na het aanvragen van certificaten, wordt de GUI herstart. Zolang er enkel een self-signed certificaat is, of enkel de staging gedraaid heeft, komt de browser waarschijnlijk (opnieuw) met een beveiligingswaarschuwing.

Na aanvragen van een certificaat via ACME productie kan je inloggen via de domeinnaam.

Print this entry

Postfix – autorisatie voor groepsleden

Standaard mag een Yunohost-gebruiker geen mails versturen met als from: een mail alias van een groep waar die gebruiker lid van is.

Om dat wel toe te staan, is een aanvulling op de Postfix-configuratie /etc/postfix/main.cf nodig.

Bij de migratie van Yunohost 11 naar Yunohost 12 (Debian Bullseye naar Bookworm) werd Postfix’s main.cf aangeduidt als “handmatig aangepast en mogelijk overschreven tijdens de upgrade”

Hieronder een diff van de aangepaste main.cf en de default van Yunohost.

 # Virtual Domains Control
 virtual_mailbox_domains = ldap:/etc/postfix/ldap-domains.cf
-virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf
+virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf,hash:/etc/postfix/app_senders_login_maps
 virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf,ldap:/etc/postfix/ldap-groups.cf
-smtpd_sender_login_maps=
+smtpd_sender_login_maps = unionmap:{
    # Regular Yunohost accounts
    ldap:/etc/postfix/ldap-accounts.cf,
-   # test: groups toevoegen, om groep-alias werkend te krijgen
-   ldap:/etc/postfix/ldap-groups.cf,
    # Extra maps for app system users who need to send emails
-   hash:/etc/postfix/app_senders_login_maps
-
+   hash:/etc/postfix/app_senders_login_maps }

De toevoeging komt uit /etc/postfix/ldap-groups.cf; daarin zitten:

# cat /etc/postfix/ldap-groups.cf
server_host = localhost
server_port = 389
search_base = dc=yunohost,dc=org
query_filter = (&(objectClass=groupOfNamesYnh)(mail=%s))
scope = sub
result_attribute = memberUid, mail
terminal_result_attribute = memberUid

Print this entry

Proxmox TLS certificaat via LetsEncrypt

Kort stappenplan:

  • Emailalias aanmaken voor het account
  • Account via certificates/ACME/create account
  • Accountnaam = nodenaam + staging, email = alias, directory = staging v2
  • Domein voor certificaat toevoegen op datzelfde scherm, certificates/ACME/Add
  • Publiek toegankelijk? Dan werkt HTTP als challenge makkelijk. Interne domeinnamen? Dan is DNS eenvoudiger.
  • Klaar? “Order Certificates Now”
  • Alles OK? Dan nieuw account maken met de productie-URL
    • Ga naar het tweede tabje, “ACME Accounts”
    • “Add” onder accouns
    • Gebruik nu nodenaam zonder staging als toevoeging, en “Let’s Encrypt V2” als directory
    • Terug naar tabje “Certificates”
    • Ververs de pagina, kies nu “Using Account:” de zojuist toegevoegde. Niet beschikbaar? Dan pagina (nogmaals) verversen.
    • “Order Certificates Now”
    • En klaar!

De node is nu bereikbaar onder de domeinnaam, zonder een beveiligingsuitzondering in je browser te maken.

Print this entry

Nextcloud upgrade van NC27 naar NC28

Nextcloud upgrades verlopen meestal zonder problemen, maar niet elke keer. Krap vier jaar terug had ik problemen met de upgrade van NC18 naar NC19: de database was gegroeid tot 440 GB, wat moeite gaf (timeout) bij de backup. In dat geval bleek het gros van de database te bestaan uit cache van externe bestanden; na truncate (truncate oc_filecache;) van de tabel verliep de upgrade zonder problemen.

Nu een aantal versies later: de upgrade van Nextcloud 27 naar Nextcloud 28 wil niet. Aan het begin van het jaar heb ik het eens geprobeerd, zonder succes, en een rollback gedaan naar het snapshot van juist daarvoor.

Ondertussen is Nextcloud 29 al een tijdje beschikbaar en raakt NC27 ‘unsupported’. In de hoop dat mogelijke bugs gevonden zijn, heb ik opnieuw een upgrade gestart. Helaas weer zonder succes.

Tweede poging

Deze stappen heb ik genomen:

  • Alle systeemcomponenten bijwerken : apt upgrade && apt update -y
  • Alle NC-apps bijwerken naar de laatste versie via admin login –> gezichts-menu –> Apps –> Your apps en dan “Upgrade all”
  • Controleren welke apps nog geen ondersteuning hebben in de nieuwe Nextcloud. Er is zo’n lijstje voor unsupported apps in NC29, maar voor NC28 heb ik dat niet kunnen vinden. Er zijn geen apps actief die in dat lijstje voorkomen
  • Shutdown container in Proxmox ; voor snapshots is dat niet nodig, maar om een consistente staat van de databases de garanderen lijkt het me een goed idee
  • Create snapshot in Proxmox en start de container
  • Log in in Yunohost en start de upgrade van Nextcloud
    • Yunohost creeert eerst een backup
    • Voert de upgrade uit
    • Klapt op “App ‘Text file editor’ not supported in NC28”, of iets in die geest
    • Probeert een restore van de backup uit te voeren
    • Restore hangt op “Restoring the MySQL database”
  • Shutdown container in Proxmox
  • Restore container snapshot in Proxmox
  • Start container

Anders dan de ‘unsupported app’-melding heb ik de specifieke fout niet kunnen herleiden; door de restore van het snapshot is de logging niet meer beschikbaar.

Derde poging

Nadat het snapshot teruggezet is:

  • Applicatie “Edit text files” verwijderen
  • De nu beschikbare MariaDB-updates installeren
  • Shutdown container, snapshot maken, boot container
  • Nextcloud upgraden vanaf de command line voor wat meer live-inzicht: yunohost app upgrade nextcloud
  • De upgrade loopt weer fout, ik laat het proces verder lopen in de achtergrond om te zien wat de restore van de backup doet
  • Na geruime tijd te blijven hangen op ‘Restoring the MySQL database’, wordt het script vervolgd
  • Restore van de backup klapt uiteindelijk op ontbrekende cachebestanden of previews,
    Info: WARNING - chown: cannot access '/home/yunohost.app/nextcloud/data/appdata_ocjk9xv5jzs5/preview/f/8/6/8/e/8': Structure needs cleaning
  • Logging is via de Yunohost-logpublicatieservice te vinden op:

Omdat de restore mislukt, is er geen Nexctloud beschikbaar. Het is aantrekkelijk om het snapshot van voor de mislukte upgrade terug te zetten, maar daarmee vervallen tussentijdse wijzigingen: conceptversies van deze blogpost bijvoorbeeld, of tussentijds binnengekomen emails.

Logging doorzoeken

In willekeurige volgorde valt op in de logging, om verder uit te zoeken:

  • Bij de upgrade:
    • DEBUG - An unhandled exception has been thrown:
      DEBUG - Error: Undefined constant OCA\Keeweb\Migration\RegisterMimeType::CUSTOM_MIMETYPEALIASES in /var/www/nextcloud/apps/keeweb/lib/Migration/RegisterMimeType.php:25
  • Bij de restore:
    • DEBUG - Checking smb.conf with testparm
      WARNING - Load smb config files from /etc/samba/smb.conf
      WARNING - Loaded services file OK.
      WARNING - Weak crypto is allowed
      WARNING - Server role: ROLE_STANDALONE
    • WARNING - chown: cannot access '/home/yunohost.app/nextcloud/data/appdata_ocjk9xv5jzs5/preview/1/d/c/6/2': Structure needs cleaning

Gezien het beperkte aantal emails en m’n offline kopie van deze tekst, is restore van het snapshot de snelste weg naar een nieuwe poging. Ik verwijder daarvoor eerst de Keeweb-app. De Keeweb-app heeft nooit gewerkt, maar ook nooit in de weg gezeten; het is de enige foutmelding in het upgrade-log.

Er zou een werkende versie van de app moeten zijn, hoewel er nu bij de app vermeld staat dat er upstream, bij Keeweb zelf, geen updates zijn sinds 2021. Na disable+remove van Keeweb sla ik het concept op en maak ik een nieuw snapshot, klaar voor een vierde poging.

Vierde poging

De vierde poging komt verder; de upgrade naar Nextcloud 28 (meer specifiek: 28.0.8 blijkt uit het log) lijkt voltooid: er wordt gemeld dat de upgrade naar Nextcloud 29.0.5 start.

Die upgrade slaagt niet; het log meldt:

InvalidArgumentException: Index name "sa" for table "oc_social_3_stream_act" collides with the constraint on table "oc_social_stream_act".
Update failed
Maintenance mode is kept active
Resetting log level

Ik wacht de restore van de backup niet af; ik controleer of er mail ontvangen is gedurende de update en ga meteen door met een rollback van het snapshot.

Er zijn een paar aanwijzingen te vinden op ‘t Net: op de Nextcloud-fora en op de Gitub-pagina van Nextcloud. De oc_social_3_*-tabellen zijn in de loop van de tijd hernoemd naar oc_social_*, zonder “3” in de naam. De social app was al disabled wegens niet compatibel na een eerdere upgrade; ik heb de tabellen meteen verwijderd zoals gesuggereerd in een van de threads:

drop table oc_social_3_action; drop table oc_social_3_actor; drop table oc_social_3_cache_actor; drop table oc_social_3_cache_doc; drop table oc_social_3_client; drop table oc_social_3_follow; drop table oc_social_3_hashtag; drop table oc_social_3_instance; drop table oc_social_3_req_queue; drop table oc_social_3_stream; drop table oc_social_3_stream_act ; drop table oc_social_3_stream_dest; drop table oc_social_3_stream_queue; drop table oc_social_3_stream_tag;

Concept opslaan, snapshot maken en nog eens proberen.

Vijfde poging

Geslaagd! De upgrade van NC27 via NC28 naar NC29 besloeg een kwartier, waarvan het grootste deel voor rekening van de backup van de database kwam.

Er is een niet-fatale waarschuwing,

Warning: File /var/www/nextcloud/config/config.php has been manually modified since the installation or last upgrade. So it has been duplicated in /var/cache/yunohost/appconfbackup//var/www/nextcloud/config/config.php.backup.20240917.184213

Ik meen dat ik de configuratie als read-only gemarkeerd heb; voor de rest moet ik de verschillen erop naslaan.

Bij het oproepen van de site en bij het inloggen heeft Nextcloud geen vervelende verrassingen. Een nieuw jasje en onder de motorkap vast veel gewijzigd, maar aan de buitenkant ‘gewoon’ de bestanden die er altijd al stonden. Fijn.

Print this entry

Navullen: HP301 ‘xl’

HP301 weegt met onbekende hoeveelheid inkt 39 gram.

Op het moment stokt magenta, als troubleshoot:

  • Eerst een magenta-gradient geprint; de lichte gebieden worden totaal niet geprint, de donkere stukken wel, maar met onderbrekingen.
    • Het kan zijn dat de inkt een beetje op is
    • waarschijnlijker is dat een aantal spuitmondjes verstopt zijn
    • het wordt niet beter met meerdere keren printen
  • Weken, bijvullen en leegtrekken:
    • Eerst even weken op een papiertje met spiritus
    • dan magenta bijvullen
    • daarna de inkt met het ‘primer’ tooltje er doorheen trekken
  • Gevuld tot (netto) 44 gram met 5 gram magenta en 2 gram geel, 2 ml gemengde verf eruit getrokken

De 2 ml gemengde inkt heb ik in de zwarte cartridge gespoten. Die bleek bij aanvang slechts 33 gram te wegen, en bij primen van de kop kwam er geen inkt uit. Daarom meer bijgevuld; met 44 gram stroomde de cartridge nog niet over.

Nadat de cartridges weer in de printer zitten, is zwart weer zwart (het ging een beetje tegen grijsgroen), maar magenta laat niets van zich weten.

Ik heb nog wat geemmerd met navullen en leegtrekken:

  • gaatjes geel en cyaan afsluiten
  • zuigen aan de onderkant om magenta er door te trekken
  • bovenaan magenta bijvullen

… maar dat heeft enkel tot gevolg gehad dat er magenta in geel en cyaan kwam (die werden immers vacuum gezogen, en trokken de beschikbare magenta weer naar binnen).

Bij opnieuw testen kwamen er bruin en paars uit de gele- en cyaankanalen; magenta deed niets. Het kan zijn dat de kop volledig stuk is, maar het zou ook kunnen dat het sponsje er zo slecht aan toe was, dat het wel ruimte maar geen inkt opnam.

Conclusie: deze cartridge vervangen. Het was al een cartridge van een refill-merk, in een printer die ik tien jaar terug gekregen heb en met enige regelmaat bijgevuld heb. Toevalligerwijs heb ik nog een refill-merk cartridge van Kringloop liggen die ik meteen kan wegen voor het ‘nieuw’-gewicht, en een continuous ink system van AliExpress wat ik al eens wilde uitproberen.

Print this entry

Vakantie zomer 2024

Dit jaar Normandie, verdeeld over drie locaties en een vierde enkele overnachting op de terugweg.

Duclair

De eerste etappe gaat van Zwolle naar Duclair. Foto’s van het huisje op booking.com

Het is ongeveer 600 kilometer, we laden een keer voordat we Belgie binnenrijden, en daarna weer in Frankrijk.

Het ligt aan de (schone…) Seine (…lang leve de Olympische spelen…), in de buurt van Rouen en op afzienbare afstand van zee.

We blijven daar vier nachten.

Agy

De tweede stop is Agy, op ongeveer 150 kilometer van Duclair. We zitten daar dichter bij zee. Op weg naar de zee komen we door Bayeux, van de tapijten.

Agy ligt ongeveer 30 kilometer ten westen van Caen.

We blijven hier het langste, een hele week.

Montaigu-les-Bois

De laatste locatie is maar een kleinstukje (~60 km) naar het Zuid-Westen.

Vanaf daar is het ongeveer een uur naar Mont-Saint-Michel.

We blijven daar vier nachten.

Noyelles-Godault

Terug naar Zwolle is in een dag te doen, maar met 800 kilometer wel een een wat lange zit zonder uitstapjes. Verspreid over twee dagen kunnen we nog wat bekijken onderweg.

We beginnen met 450 kilometer naar het Noord-Oosten en overnachten in “Novetel Lens“, met zwembad en ontbijt.

De volgende dag is het dan nog ruim 350 kilometer naar Zwolle.

Print this entry