Mostly notes about how I (tried to) solve local IT issues
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]
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:
unprivileged: 0features: nesting=1/etc/modules-load.d/modules.conf
/etc/moduleslxc.apparmor.profile: unconfined lxc.cgroup.devices.allow: a lxc.cap.drop: lxc.mount.auto: proc:rw sys:rwZolang 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;
/proc/sys/net/netfilter/nf_conntrack_max Hints:
.ssh/authorized_keys eigendom is van root of van 100000 ; met dat laatste doet hij het (terecht?) niet.
root is (noch op de host, noch in de container). Bronnen:
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
De quickstart op cloudnative-pg.io geeft:
kubectl apply --server-side -f \ https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.25/releases/cnpg-1.25.1.yamlkubectl get deployment -n cnpg-system cnpg-controller-managercluster-example.yaml van de sitekubectl apply -f cluster-example.yamlkubectl get podskubectl 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
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:
/var/www/snappymail/app# cd data/_data_/_default_/admin_password.txt openen/var/www/snappymail/app/data/_data_/_default_/configs/application.iniadmin_password, onder het kopje “Login and password for the web admin panel”
admin_password.txt wordt even daarna automatisch aangemaaktapplication.iniHet is telkens weer puzzelen, nu een aantkening voor de volgende keer:
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.
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.
Tekstopdrachten om hetzelfde te bereiken:
pvenode acme account register pve-node-staging letsencrypt_pve_node@osba.nlpvenode acme config set --acme accoun=pve-node-staging domains=pve-node.osba.nlpvenode acme cert ordersystemctl restart pveproxyLet 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.
Ik blijf vergeten waar in de GUI de downloadknop voor templates te vinden is.
Ga in het linker menu naar local storage van je node, vervolgens naar CT Templates, en dan de ‘Templates’ knop
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
Kort stappenplan:
De node is nu bereikbaar onder de domeinnaam, zonder een beveiligingsuitzondering in je browser te maken.
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.
Deze stappen heb ik genomen:
apt upgrade && apt update -yAnders 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.
Nadat het snapshot teruggezet is:
yunohost app upgrade nextcloudInfo: WARNING - chown: cannot access '/home/yunohost.app/nextcloud/data/appdata_ocjk9xv5jzs5/preview/f/8/6/8/e/8': Structure needs cleaningOmdat 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.
In willekeurige volgorde valt op in de logging, om verder uit te zoeken:
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:25DEBUG - 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_STANDALONEWARNING - chown: cannot access '/home/yunohost.app/nextcloud/data/appdata_ocjk9xv5jzs5/preview/1/d/c/6/2': Structure needs cleaningGezien 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.
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 levelIk 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.
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.184213Ik 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.
HP301 weegt met onbekende hoeveelheid inkt 39 gram.
Op het moment stokt magenta, als troubleshoot:
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:
… 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.
Dit jaar Normandie, verdeeld over drie locaties en een vierde enkele overnachting op de terugweg.
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.
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.
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.
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.