Berichten

Geplaatst op

PBS-migratie – valse start

Update: onderstaand stappenplan is de prullenbak ingegaan nadat ik van RAID0 naar RAID5 ging, ipv RAID10. Herzien: rechtstreeks naar RAID10 met een kleine hardware-aanpassing.

Oude situatie: 1x 4TB in gebruik + 3x 4TB ongebruikt
Nieuwe situatie: RAID10 over 4x 4TB + LVM caching over 4x 0,2TB SSD

Stappen:

  • HDD’s identificeren en overbrengen naar nieuwe behuizing
  • LVM RAID0 over 2x 4TB, caching toevoegen
  • 8TB RAID0 LVM toevoegen aan PBS
  • PBS sync van ZFS op 1x 4TB naar 8TB RAID0 LVM
  • Mirror toevoegen aan beide schijven, van 2x 4TB naar 4x 4TB

Praktische uitvoering:

  • 1x 4TB SAS blijkt defect, voorlopig vervangen met beschikbare 3TB of 6TB SATA schijf
  • LVM voorbereiden:
    • fdisk /dev/sde
      • g – nieuw GPT disklabel
      • n – nieuwe partitie (partitie 1, vanaf default sector 2048 tot default laatste sector, en dan van de laatste sector een stukje afhalen om ~1% vrije ruimte over te laten)
      • t – type: lvm
      • p – print indeling ter controle
      • w – schrijf de indeling naar schijf
    • pvcreate /dev/sde1 /dev/sdf1
    • vgcreate backup /dev/sde1 /dev/sdf1
    • Striped LV over de twee HDD’s, stripesize van 1 MB
      • Niet de volle 100% vrije ruimte gebruiken om toekomstige mutaties niet te blokkeren (Volume group "backup" has insufficient free space (0 extents): 8 required
      • lvcreate -n localbaks -vt -i2 -l95%VG backup -I 1M /dev/sdf1 /dev/sde1
    • Tijdelijk de huidig beschikbare SSD toevoegen als dmcache
      • vgextend backup /dev/sda1
    • Cachevol maken en toevoegen aan de striped LV; gebruik niet %VG, dat gaat over de volledige VG, niet over de aangewezen PV
      • lvcreate -vt -n localbaks_cache -L 70G backup /dev/sda1
      • lvconvert --type cache --cachepool localbaks_cache backup/localbaks
    • Is het nodig om cache te verwijderen?
      • lvconvert --uncache backup/localbaks
  • Het gecreerde volume toevoegen aan PBS; omdat het geen raw disk device is, kunnen we niet het disk subcommand van proxmox-backup-manager gebruiken. Daarom handmatig een bestandssysteem aanmaken, mounten en vervolgens een datastore maken:
    • mkfs.ext4 /dev/mapper/backup-localbaks
    • mkdir -p /mnt/datastore/localbaks
    • echo '/dev/mapper/backup-localbaks /mnt/datastore/localbaks ext4 defaults 0 0' >> /etc/fstab
    • proxmox-backup-manager datastore create localbaks /mnt/datastore/localbaks

Vervolgstappen

sync-job: ingericht via de web-GUI:

  • Gecreëerd vanuit de nieuwe ‘localbaks’ datastore, als ‘sync pull job’
  • ‘remote’ uitgevinkt, locale oude datastore als bron aangewezen
  • volledige namespace
  • jaarlijks (want eenmalig) gepland
  • vervolgens met ‘run now’ handmatig gestart

De actie trekt volgens de ‘administration’ sectie van PBS zo’n 100% CPU met IO wait op 80% en 6 van 16 GB geheugen bezet; htop geeft 10-15% belasting op elk van de 4 cores bij een bescheiden geheugengebruik van <700 MB

Transfersnelheid zit op zon 80 MB/s via PBS en 100 MiB/s via htop wat redelijk bij elkaar in de buurt komt.

Er is wel een groot verschil in het aantal IOPS op de oude disk tegenover de nieuwe gecachte RAID0: volgens PBS ongeveer 20 IOPS op de oude schijf, tegelijkertijd zo’n 700 IOPS op de nieuwe schijf. Zelfs als de oude schijf 4k sectors zou hebben en de nieuwe 512b, is dat verschil niet te verklaren.

De verhouding tussen bandbreedte en IOPS op de nieuwe RAID0 is 1 MB/s voor elke 10 IOPS, dus 100 kB per I/O. Later nog eens naar kijken, wordt vervolgd.

Todo’s

  • RAID0 –> RAID10
  • 1x 80 GB SSD vervangen door deel van 4x 200 GB SSD
  • 1x 100 GB system SSD vervangen door deel van 4x 200 GB SSD

Print this entry

Geplaatst op

JBL Bluetooth koptelefoon met laptop verbinden

Pairing van de koptelefoon werkte meteen, maar na verbinden werd de verbinding meteen verbroken

May 22 11:45:01 tp2 CRON[3168238]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 22 11:45:01 tp2 CRON[3168239]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
May 22 11:45:01 tp2 CRON[3168238]: pam_unix(cron:session): session closed for user root
May 22 11:45:43 tp2 kernel: Bluetooth: hci0: Ignoring error of Inquiry Cancel command
May 22 11:46:01 tp2 plasmashell[4652]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x5574242788f0) QQmlContext(0x55741e463c20) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
May 22 11:46:01 tp2 plasmashell[4652]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x5574242788f0) QQmlContext(0x55741e463c20) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
May 22 11:46:07 tp2 plasmashell[4652]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x5574225975f0) QQmlContext(0x55741e463c20) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
May 22 11:46:07 tp2 plasmashell[4652]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x5574225975f0) QQmlContext(0x55741e463c20) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
May 22 11:46:08 tp2 blueman-manager[3161989]: blueman-manager 11.46.08 WARNING  ManagerDeviceMenu:145 fail      : fail g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Failed: blueman.bluez.errors.DBusFailedError:  le-connection-abort-by-local
May 22 11:46:08 tp2 blueman-manager[3161989]:  (0)
May 22 11:46:09 tp2 kwin_x11[4617]: kwin_core: XCB error: 152 (BadDamage), sequence: 21956, resource id: 16286893, major code: 143 (DAMAGE), minor code: 3 (Subtract)
May 22 11:46:12 tp2 ksmserver[5256]: kf.xmlgui: Index  23  is not within range (0 -  21 )
May 22 11:47:59 tp2 bluetoothd[1621]: src/service.c:btd_service_connect() a2dp-sink profile connect failed for 88:92:CC:0D:B8:DB: Protocol not available
May 22 11:47:59 tp2 plasmashell[4652]: kf.bluezqt: PendingCall Error: "br-connection-profile-unavailable"
May 22 11:47:59 tp2 plasmashell[4652]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55742481c1b0) QQmlContext(0x55741e463c20) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
May 22 11:47:59 tp2 plasmashell[4652]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55742481c1b0) QQmlContext(0x55741e463c20) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")

Als optie werd op het ‘Net gesuggereerd om niet de KDE Plasma applet te gebruiken, maar Blueman. Daarmee hetzelfde resultaat.

Uiteindelijk opgelost door pulseaudio handmatig te starten:

wbk@localhost:~$ rm -r ~/.config/pulse/
wbk@localhost:~$ pulseaudio -k
E: [pulseaudio] main.c: Failed to kill daemon: No such process
wbk@localhost:~$ pulseaudio --start

Gezeien pulseaudio -k meteen al ‘no such process' laat weten, denk ik dat Pulseaudio niet actief was.

Vervolgens wilde de koptelefoon meteen verbinden.

Geen geluid

Vervolgens kwam geluid alsnog uit de laptop of de bedrade koptelefoon. De bluetooth headset staat niet in de lijst met geluidsapparaten.

Na wat speuren:

  • Audio loopt via pipewire
  • De koptelefoon is via de bluetooth plugin van pulseaudio aangesloten

Een post op ‘t Raspberry Pi forum sugeereert om pipewire opnieuw te installeren. Daarmee ben ik terug bij af; blijkbaar heb ik de configuratie niet correct om Bluetooth via Pipewire te laten lopen, en Pipewire verkeerd ingericht om audio van PulseAudio naar Pipewire te routen.

Wordt vast vervolgd.

…

Toch nog even gekeken naar info over Pipewire Bluetooth. De Arch-wiki heeft meer details: met Pipewire, is Pulseaudio overbodig. Voor audio Bluetooth apparaten is echter pipewire-audio nodig. Die bleek nog niet geinstalleerd, dus apt install pipewire-audio.

Dat mocht helaas nog niet baten. Grafische weergave met qpwgraph toont dat de (ondertussen weer onverbindbare) koptelefoon ontbreekt.

Vervolg: succes?

De volgende dag liep ik met de koptelefoon op, verbonden met de telefoon, richting de laptop. “Connected”, riep de koptelefoon plots. De verbinding was gemaakt, en de koptelefoon is zichtbaar als volumeregelaar en werkt ook als output.

Het is helaas niet duidelijk wat er nodig was om het te laten werken. Mogelijk een reboot en volledig herstarten van alle services met gewijzigde configuraties na de aanpassingen van de dag daarvoor.

Print this entry

Geplaatst op

Let’s Encrypt ACME op PBS

Na automatische update van de certificaten is er een fingerprint mismatch tussen PVE en PBS.

De oplossing is het verwijderen van de fingerprint in de opslagconfiguratie op PVE (/etc/pve/storage.conf). Controleer daar meteen of de locatie via de FQDN of via het IP gerefereerd wordt: zonder fingerprint geeft IP een foutmelding. Na het verwijderen van de fingerprint is het dus nodig ook het IP te vervangen door de FQDN van PBS in overeenstemming met de hostname in het certificaat:

pbs: markttweak
        datastore bak_sdc
        server 172.26.2.20
        content backup
        fingerprint 2e:30:b5:fa:0f:64:9b:3b:b7:97:c9:07:87:22:9a:49:80:ad:26:48:17:49:6a:a3:16:13:8a:72:1b:7e:61:2c

wordt:

pbs: markttweak
        datastore bak_sdc
        server markttweak.osba.nl
        content backup

De aanpassing van storage.conf wordt (vrijwel) direct opgemerkt door PVE; is het niet nodig een service of een machine opnieuw te starten.

Print this entry

Geplaatst op

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]

Deze keer:

Eerst een week standplaats Staßfurt, daarna een week Praag (zie ook de punaises op de kaart).


Afstanden

  • Zwolle – Staßfurt : 460 km
  • Staßfurt – Dresden : 200 km
  • Dresden – Praag : 170 km
  • Praag – Kutna Hora : 70 km
  • Praag – Český Krumlov : 175 km

Print this entry

Geplaatst op

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

Geplaatst op

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

Geplaatst op

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

Geplaatst op

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

Geplaatst op

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