Categorie: homeserver

Geplaatst op

OPNsense / Unbound – DNS rebind protection

Op de een of andere manier lukte het me niet om vanaf m’n desktop een server in het locale netwerk te bereiken. Wel op IP, zowel v4 als v6, maar niet op FQDN.

Andere machines in het netwerk hadden geen probleem, en machines buiten ‘t LAN konden de hostname zonder probleem herleiden naar een IP.

Na wat puzzelen, bleek de Unbound service op OPNsense aan DNS rebind protection te doen. Hoe ik daar nog niet eerder tegenaan gelopen ben? Geen idee; de meeste machines in het LAN kan ik gewoon op FQDN bereiken, zonder hosts-entry en zonder publiek IPv4. Misschien over IPv6? Eens op letten.

In ieder geval, voor deze nieuwe server lukte het niet, en een hosts-entry leek me onnodig. Zoals gezegd, het bleek uiteindelijk in de DNS rebind protection van Unbound te zitten: het interne netwerk wordt genoemd in de lijst met rebind protection networks (A in het screenshot)

Oplossing? Onze eigen domeinen toevoegen aan ‘Private Domains’ (B in het screenshot)

Print this entry

Geplaatst op

Proxmox – PVE aan datacenter toevoegen

Uitgangspositie:

  • Debian geinstalleerd met gewenste hostname
  • Proxmox PVE daar aan toegevoegd
  • PVE draait ‘standalone’, niet als deel van een bestaand datacenter
  • Netwerk: DHCP-pool adres

Doelsituatie:

  • De node heeft ‘t juise (vaste) IP
  • De node heeft een LetsEncrypt certificaat
  • De node maakt deel uit van het bestaande datacenter

Stappen voor IP-adressering

  • DHCP inrichten als fallback
    • reservering maken voor IPMI/iKVM/iLO/DRAC in de IPMI-range
    • reservering maken voor ‘t MAC van eth0 of bond0, afhankelijk van waarop de kabel aangesloten is, in de hypervisor-range
  • Reboot, verifieer dat:
    • IPMI beschikbaar is op het gereserveerde adres
    • PVE beschikbaar is op het gereserveerde adres
  • PVE statisch IP toekennen
    • Via GUI in het menu van de node: System –> Network –> Create –> Linux Bridge
      • Name : vmbr0
      • IPv4/CIDR : hetzelde adres als in de reservering
      • Gateway (IPv4) : gateway van ‘t netwerk
      • IPv6/CIDR : het juiste adres uit de hypervisor range
      • Autostart : ja
      • VLAN aware : indien nodig
      • Bridge ports : minstens een van de poorten waar een kabel in zit, meestal eth0 of enpNs0
    • OK in de popup, en “Apply Configuration” in het netwerkmenu om de pending changes te activeren.
      • De gewijzigde configuratie is nu ook zichtbaar via /etc/network/interfaces
  • /etc/hosts : corrigeer het IP adres ; het adres dat hier genoemd staat is het hoofd-adres van deze node, en is ook het adres dat getoond wordt als welkomstbericht op de locale tty / CLI

Reboot om te verifieren dat ook na een reboot alles werkt als verwacht.

Stappen voor datacenter

Het ligt voor de hand om na configuratie van de IP-adressen, de TLS-certificaten in orde te maken. Een deel van de configuratie voor ACME is echter op datacenter-niveau, en is dus al beschikbaar op het doel-datacenter.

Het is daarom efficienter om de nieuwe host op IP en self-signed certificate aan het datacenter toe te voegen, en daarna pas via ACME een certificaat voor de hostname te genereren.

  • Via een node in het bestaande datacenter:
    • Datacenter –> Cluster –> “Join Information”
      • Kopieer de gegevens in de popup
  • Via de nieuwe node:
    • Datacenter –> Cluster –> “Join Cluster”
      • Vink “Assisted join” aan
      • Plak de gekopieerde gegevens, OK en wachtwoord van de _andere_ node invullen
      • OK
  • Log opnieuw in op de nieuwe node

Stappen voor certificaten

Uitgebreider stappenplan: de korte instructies (ouder) of die met plaatjes (nieuwer)

De basisinstellingen zijn al gedaan op het bestaande datacenter waar de node nu deel van uitmaakt. Maak eventueel een nieuw account aan onder datacenter –> ACME –> Accounts, of hergebruik een bestaand account.

  • Buiten PVE om, bij de DNS provider van het domein: maak de node bekend in DNS (ook voor private IP’s), anders werkt de ACME DNS-plugin niet
  • Daarna, in het menu van de node:
  • System –> Certificates –> ACME-deelscherm
    • Using account :
      • Edit
      • kies de zojuist aangemaakte, of een bestaande; begin met een account op Letsencrypt Staging
      • Apply
    • Add (popup)
      • Challenge Type : DNS
      • Plugin : de voor DNS geconfigureerde plugin
      • Domain : de FQDN van de node
      • OK
    • “Order Certificates Now”
    • Popup, zonder fouten, als het meezit
    • Fouten? Dan uitzoeken/troubleshoot. Geen fouten? Dan account vervangen door een non-staging account
  • ACME: edit account, switch naar productie-account
  • Opnieuw : “Order Certificates Now”

Dat was ‘t. De nieuwe node is nu beschikbaar in het datacenter.

Print this entry

Geplaatst op

Yunohostmigratie

Migratie van opensoos.nl naar een krachtigere server.

Op zich werkte alles wel, maar… vaak na wachten, en meestal niet tegelijkertijd. De server was destijds over, zat ruim genoeg in z’n jasje om er meerdere diensten tegelijk op te draaien, en had voldoende opslagruimte om beeldmateriaal weg te schrijven.

De specificaties, beknopt uit de YABS-header:

  • Processor  : Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz
  • CPU cores  : 1 @ 2593.906 MHz
  • RAM        : 1.9 GiB
  • Swap       : 1.0 GiB
  • Disk       : 98.4 GiB
  • Distro     : Debian GNU/Linux 12 (bookworm)
  • Kernel     : 6.1.0-43-cloud-amd64
  • VM Type    : KVM
  • IPv4/IPv6  : ✔ Online / ✔ Online

Zoals gezegd, de server verslikte zich in de workload, terwijl ik nog niet klaar was. Er draaide nu:

  • BookWyrm voor boekbesprekingen
  • flohmarkt voor advertenties
  • Mastodon voor korte berichtjes
  • PeerTube voor videomateriaal
  • Pixelfed voor fotomateriaal
  • SnappyMail om mail te lezen

SnappyMail zal ‘m de das niet omgedaan hebben, maar sommige van de Fediverse-apps zijn vrij zwaar. Daaroverheen wilde ik in ieder geval een ‘verzamel alles’-dienst draaien (*key of *fish variant), eventueel een link-aggregator zoals Lemmy, en misschien, als dat bestaat, een muziek/geluidsfragmentendienst. Om de zaak te beschrijven zou er een ‘social-enabled’ WordPress bij mogen.

Dat zou deze server zeker niet trekken. Het zijn federated diensten, dus ik zou het geheel … federated op kunnen zetten, maar ik wil dit hele zwikje enigszins overzichtelijk houden en op een machine laten draaien.

Zodoende, migreren naar een zwaardere machine. Beschikbaar:

  • Processor  : AMD EPYC 7313 16-Core Processor
  • CPU cores  : 2 @ 3000.000 MHz
  • AES-NI     : ✔ Enabled
  • VM-x/AMD-V : ✔ Enabled
  • RAM        : 3.8 GiB
  • Swap       : 1.5 GiB
  • Disk       : 79.9 GiB
  • Distro     : Debian GNU/Linux 12 (bookworm)
  • Kernel     : 6.1.0-9-amd64
  • VM Type    : KVM
  • IPv4/IPv6  : ✔ Online / ✔ Online

Weliswaar met minder opslagruimte, maar alles minstens dubbel zo snel. Meer opslagruimte kan vast via een S3-provider aangevuld worden, eventueel van de oude server.

Stappenplan

Oude server : A
Nieuwe server: B

  • Op B
    • Schone installatie van Debian 12 (momenteel, Yunohost 12) via de managementsinterface van de hoster
    • Installeer Yunohost: curl https://install.yunohost.org | bash
    • Creeer zonodig SSH ids, voeg ‘t public ID van root@A toe aan .ssh/authorized_keys
    • Ontvang de backup van A
    • Restore de zojuist ontvangen backup, in plaats van de reguliere postinstall : yunohost backup restore 20260212
    • Push vanuit Yunohost de gewijzigde IP’s naar DNS, of doe het met de hand
  • Op A
    • Vergroot, wegens performance, swap: fallocate -l 1G /swap2 && chmod 600 /swap2 && mkswap /swap2 && swapon /swap2
    • Backup: yunohost backup create
    • Hernoem de server : hostname -b old.opensoos.nl && echo 'old.opensoos.nl > /etc/hostname
    • Creeer zonodig SSH ids: ssh-keygen -t ed25519
    • Test SSH: ssh root@opensoos.nl (zonder reboot van A wijst dit nog naar localhost, gebruik evt ‘t IP van B)
    • Kopieer de backup van A naar B: scp 20260212-223700.*  root@opensoos.nl:/home/yunohost.backup/archives

In grote lijnen verliep de boel volgens plan, maar na afloop:

  • Mastodon was niet geinstalleerd
    • Verkeerde bundler-versie ; handmatig geinstalleerd
      • apt install gem
      • gem install bundler -v ‘~> 2.6’
      • Ook na die handmatige ingreep liep restore op hetzelfde punt stuk
    • Backup-tar uitpakken, en controleren of er ergens een bundler-installatie plaatsvindt
      • ja, inderdaad: ynh_gem install bundler --no-document; aangepast naar ynh_gem install bundler -v '~> 2.6' --no-document en de tar bundel weer geupload voor een nieuwe poging
      • Daarmee slaagt restore van Mastodon
  • Peertube was niet geinstalleerd :
    • 2026-02-12 20:59:42,714: WARNING - Feb 12 20:54:42 (node)[33774]: peertube.service: Failed to locate executable /opt/node_n/n/versions/node/22.21.1/bin/node: No such file or directory
      2026-02-12 20:59:42,715: WARNING - Feb 12 20:54:42 (node)[33774]: peertube.service: Failed at step EXEC spawning /opt/node_n/n/versions/node/22.21.1/bin/node: No such file or directory
      2026-02-12 20:59:42,716: WARNING - Feb 12 20:54:42 systemd[1]: peertube.service: Main process exited, code=exited, status=203/EXEC 2026-02-12 20:59:42,716: WARNING - Feb 12 20:54:42 systemd[1]: peertube.service: Failed with result 'exit-code'.
    • Peertube op de oude server had nog geen federatie of interactie met de buitenwereld –> herinstallatie
    • Herinstallatie ging zonder problemen, maar na afloop kon ik mijn Yunohost-gebruikers niet vinden; de LDAP-plugin had geen configuratieparameters (“This plugin does not have any configuration”).
    • LDAP-plugin verwijderd, opnieuw geinstalleerd; kon nu wel geconfigureerd worden volgens de Yunohost-instructies
      • Login voor de eerste de beste Yunohost gebruiker werkte niet
      • oorzaak blijkt: die gebruiker was al als root/admin aangemaakt in Peertube
        • andere gebruikers konden wel via LDAP inloggen
        • na aanpassen van het emailadres van root/admin in Peertube, kon ook die YNH-gebruiker als reguliere Peertube-user inloggen via LDAP
  • Flohmarkt wilde niet starten
    • De oorspronkelijke oorzaak heb ik niet achterhaald, ik kwam er pas achter nadat ik een upgrade deed
    • Nieuwe installatie gaf ook een probleem
    • Zodoende opnieuw de backup teruggezet, die bleek meteen niet te functioneren:
      • Het numerieke ID van systeemgebruiker ‘flohmarkt’ kwam niet overeen met het numerieke ID van ‘flohmarkt’ in de backup. Rechtzetten door:
      • root@opensoos:/var/www# find . -uid 987 -exec chown flohmarkt {} +
      • root@opensoos:/var/www# find . -gid 987 -exec chgrp flohmarkt {} +

In grote lijnen was de migratie geslaagd, maar een paar dingen liepen niet helemaal lekker. Een log van m’n werkzaamheden is verloren gegaan, de details ontbreken zodoende:

  • flohmarkt start niet:
    • de flohmarkt-gebruiker was met een ander numeriek ID aangemaakt op de nieuwe server, waardoor de systeemgebruiker geen toegang kreeg tot z’n ‘eigen’ bestanden
    • hersteld door de bestanden en directories op basis van de numerieke ID’s aan de correcte gebruiker toe te wijzen:
      • /var/www# find . -uid 987 -exec chown flohmarkt {} +
      • /var/www# find . -gid 987 -exec chgrp flohmarkt {} +
  • Peertube plugins plugden niet in :
    • Het leek of de plugins wel geinstalleerd waren, maar niet bruikbaar waren. Geen van de benodigde configuratieopties was beschikbaar.
    • Een van de plugins verzorgt de koppeling met Yunohost SSO ; zodoende kon er niet ingelogd worden
    • Verwijderen en opnieuw installeren/configurerern van de plugins heeft dat verholpen
    • Vervolgprobleem :
      • een van de gebruikers kon alsnog niet inloggen. Het bleek dat ik in tegenstelling tot hoe het op de oorspronkelijke server ingericht was, voor de peertube-root-user een emailadres van een van de Yunohost-users had gebruikt.
      • LDAP matcht gebruikers in dit geval op emailadres. Omdat het emailadres van die Yunohost-user reeds aan de Peertube-root-user gekoppeld was, kon die betreffende gebruiker niet inloggen.
      • Hersteld door het emailadres van de Peertube-root-user aan te passen naar een ander emailadres
  • BookWyrm:
    • Ik meen me te herinneren dat herstel van de backup van BookWyrm niet slaagde
    • BookWyrm was nog een lege installatie, ik heb ervoor gekozen dat opnieuw te installeren.

Vervolg

De migratie speelde een week of twee terug. Openstaande punt was toen nog om een ‘centrale’ sociale plaats te definieren, waar de verschillende mediaspecifieke sociale identiteiten in uitmonden.

Kandidaatnetwerken voor de centrale identiteit waren na een eerste schifting op basis van beschikbaarheid in de Yunohost catalogus, features, aantal gebruikers en aantal ontwikkelaars:

  • Friendica
  • *key
    • Misskey
    • Sharkey
    • Iceshrimp

Sharkey is als winnaar uit de bus gekomen. Installatie slaagde na toevoegen van wat extra swap-ruimte.

Print this entry

Geplaatst op

OPNsense als TFTP-server met netboot.xyz

Dat ging snel opeens!

Lang geleden draaide er thuis een TFTP-server (oa voor de VoIP-telefoontoestellen, toen dat nog een ding was) op een Linksys NSLU, maar met een hardwarewissel is die verdwenen en niet meer teruggekomen.

Zo nu en dan zou het wel van pas komen; een apparaat dat alleen via TFTP geflashed wil worden, alsnog een VoIP-toestel, en met enige regelmaat als alternatief voor het flashen van een USB-stick met installtiebestanden.

Een tijdje geleden vond ik netboot.xyz, en voor ik me er in kon verdiepen, werd het me aangeraden als optie om een gehuurde server van een OS te voorzien. Onlangs zat er thuis een server verlegen om een operating system en zou netboot.xyz een mooie optie zijn geweest.

Zodoende kort gekeken wat er aan opties op *BSD is voor TFTP. Wat blijkt? OPNsense heeft een TFTP-plugin, en er is iemand zo vriendelijk geweest de (weinige) stappen op een blogpost te zetten:

  • Installeer de community-plugin os-tftp
  • Download de netboot.xyz-bestanden naar /usr/local/tftp :
    • fetch https://boot.netboot.xyz/ipxe/netboot.xyz.efi
    • sha256sum netboot.xyz.efi
  • In het OPNsense-menu, onder services:
    • TFTP kan nu geactiveerd worden:
      • Het listen address zet ik op de het adres van de router in het netwerk waarin het gros van de machines draait
    • Onder de DHCP-server (hij draait op IPv4 bij mij, dus inrichten onder de DHCPv4 server)
      • het item “Network booting” opzoeken en openklappen
      • als “next-server IP” het IP invullen wat eerder onder TFTP ingevuld is
      • de naam van het bootbestand invullen (voorlopig enkel netboot.xyz.efi onder x64 UEFI/EBC firmware)
    • Opslaan en DHCP herstarten
  • Klaar!

Getest met m’n laptop: het werkt meteen! Althans…

Brakke netwerkdrivers (aka Realtek)

Realtek kaarten zijn geen garantie op slechte ondersteuning, maar vaak wel een indicatie van een grote kans op slechte ondersteuning. Zo ook de driverondersteuning door Lenovo in de firmware van m’n Thinkpad met Realtek netwerk: het werkt niet.

De eerste feedback is veelbelovend:

  • TFTP-server adres wordt correct getoond
  • netboot.xyz.efi wordt gevonden en gedownload
  • iPXE wordt geinitialiseerd, features worden getoond
  • maar dan als net0/net1 geconfigureerd wordt:
    • no configuration methods succeeded
    • net0 using rtl8168 [closed] wordt getoond
    • net1 using MNP [closed]op dezelfde manier
    • TX loopt op, maar RX blijft op 0: er wordt wel wat verstuurd, maar niets ontvangen

Een poging met de undionly-versie (waarbij de basic EFI-netwerkdriver gebruikt wordt in plaats van een driver specifiek voor deze Realtek kaart) geeft ook geen resultaat.

Wat wel werkt (aka Intel)

Een paar willekeurige machines op het netwerk, toevallig allemaal met Intel NIC’s : die booten zonder problemen bij een eerste poging. Leuk hoor!

Print this entry

Geplaatst op

ASUS P9D-I

Voor een upgrade van de Proxmox-infrastructuur heb ik een nieuw tweedehands moederbordje: Asus P9D-I. Het is een mini-ITX bordje voor een oudere generatie Xeon processoren.

Bij aanvang deed het bordje niets: ledjes gingen aan, de CPU-fan draaide, maar er was geen beeld op de onboard DVI-aansluiting. Ook een externe grafische kaart boodt geen soelaas.

Met wat meer onderzoek realiseerde ik me dat er via ASMB7-iKVM remote access ingebouwd zat, en na inloggen gaf dat een mogelijke oorzaak: de CPU-temperatuur schoot meteen na het aanzetten naar 127 graden Celsius. Hoewel het koelblok niet gigantisch heet voelde, was de warmte van de CPU wel aan de onderzijde van de serverbehuizing voelbaar.

In de hoop dat het systeem nog te redden viel, heb ik alles uit elkaar gehaald, goed ontstoft, fans schoongemaakt en CPU van nieuwe koelpasta voorzien.

Na alles inbouwen was er alsnog geen beeld, maar wel het idee dat 127 graden erg lijkt op het uiteinde van een signed 8-bit schaal, van -128 via 0 tot 127.

Stom genoeg had ik geen reset gedaan van BIOS of ME. Alleen verzetten van de CLRTC1-jumper leek geen effect te hebben. Na loskoppelen van de batterij en terugzetten van de jumper, heb ik het systeem aan laten staan terwijl ik verdere documentatie probeerde te vinden.

Tot mijn verbazing begon het systeem na een paar minuten uit zichzelf te piepen. Lang-kort-kort, lang-kort-kort: geen RAM aanwezig. Dat klopt: alles lag er nog uit.

Snel alles ingebouwd, en ja hoor: boot en beeld op de interne DVI.

CPU-upgrade

Het bordje werd geleverd met een Xeon E3-1220v3: 4 cores op 3,5 GHz met 8 MB cache bij een TDP van 80 W.

Ik heb er een iets nieuwere CPU bij kunnen vinden in de E3-1275v3. Die heeft met 3,9 GHz een hogere topfrequentie, met 2,7 GHz een lagere basisfrequentie en daarbij een ingebouwde GPU; dat alles bij een TDP van 45 W.

Ik vermoed dat het verschil in idle-verbruik nihil is, omdat beide CPU’s zullen terugschalen als er geen belasting is, maar voor een router VM met OPNSense komt de hogere topfrequentie van pas terwijl de GPU mogelijk kan ondersteunen bij het genereren van JPG of transcoden van mediabestanden op Nextcloud.

Na een paar keer alles uit- en inbouwen was verwisselen van de CPU een fluitje van een cent. Het systeem bootte zonder verdere problemen.

SSD-upgrade

De mini-ITX behuizing (Chenbro SR3019) biedt ruimte aan 4×3,5″ en 2×2,5″ opslagmedia. Het moederbord heeft echter slechts 4x SATA. Het PCIe 16x uitbreidingsslot gebruik ik voor een U.2 adapter voor een 1,92 TB NVMe SSD.

De SSD dient als caching voor een RAID10-configuratie van harde schijven, voor het installeren van het OS en voor zaken als databases in de VM’s.

Installatie van Debian 12, om daarna Proxmox te installeren, verloopt ‘uneventful’,

Starten van de nieuwe installatie echter niet. Geen besturingssysteem gevonden!

In het BIOS is de SSD niet terug te vinden. Tijd voor een BIOS-upgrade.

BIOS-upgrade

Het moederbord werd geleverd met een BIOS uit 2016; de meest recente BIOS die Asus aanbiedt is van 2018. Het zal echter blijken dat Asus ook daarin geen ondersteuning van NVMe biedt.

Voor de upgrade biedt Asus een DOS-utility. Booten van Freedos zou makkelijk via iKVM moeten kunnen door via de virtuele bootmedia de ISO te koppelen, maar ik kan nergens in de interface de benodigde functionaliteit vinden (zit niet in de webinterface, zo blijkt, maar in de java viewer. Zie onder Java webview). Daarom de ISO naar een USB-stick schrijven (dd if=FD14FULL.img of=/dev/sdf bs=32M status=progress) en booten van USB.

Eenmaal in DOS beland, is het voldoende om BUPDATER.EXE /iP9DI2101.CAP te draaien vanaf de betreffende directory.

Zoals al aangekondigd, ondersteuind de nieuwste officiele BIOS helaas geen NVMEe. Oplossing? Een aangepaste BIOS.

Ik ben blijkbaar niet de eerste die tegen het probleem aan loopt. Niet alleen is er de afgelopen tien jaar een berg aan informatie over het aanpassen van UEFI firmwares gepost, er is ook al iemand geweest die de moeite heeft genomen dat voor de P9D-I te doen en het resultaat te posten.

Om te verifieren dat er inderdaad een NVMe-module beschikbaar is in de gedownloade firmware, is er UEFITool (sudo apt install efitools pesign sbsigntool uefitool uefitool-cli)

Het vervelende is alleen dat in de loop van de tijd de firmwares verpakt zijn in een formaat (.cap) met checksum. De Asus-flasher geeft een foutmelding bij het laden voor het flashen van de firmware.

De alternatieve weg, via Ami’s firmware update utility, leunt op een vervallen optie (/GAN), waarmee de checksum genegeerd werd.

Bij gebrek aan die mogelijkheid via Ami’s utility, zijn er nog drie opties:

  • Misschien is het nog wel mogelijk een dergelijke firmware via de UEFI-console te flashen;
  • Een oudere versie van de DOS-versie van die utility;
  • Flashen van de BIOS chip met een externe hardware-flasher (CH341A), nog aan te schaffen

Met het constant toevoegen van bestandjes aan de USB stick wordt het wat irritant telkens de boel in- en uit te pluggen.

Java webview

Het zou fijn zijn als iKVM naar behoren werkte, maar met de java-viewer (.jnlp) die draait via javaws mag dat niet, omdat javaws al jaren geen unsigned bestanden meer wil lezen.

Na een tijd prutsen met de beveiligingsinstellingen van Java en alternatieve manieren om de viewer te starten, ben ik uiteindelijk gestuit op OpenWebStart van Karakun. Na een eenvoudige sudo dpkg -i OpenWebStart_linux_1_12_0.deb, werkte het meteen!

In de JViewer app is een menu-optie “Media” om virtuele media te koppelen. De ISO’s die ik geprobeerd heb aan de viewer te voeren slikte hij echter niet.

Terug bij af…

Het systeem wil niet meer starten. Mogelijk is het de eerste ‘cold boot’ sinds de BIOS update. Het viel me op nadat ik het systeem van uit, inschakelde met een UEFI-bootable USB-stick: geen beeld.

De symptomen zijn gelijk aan de oorspronkelijke situatie, met het verschil dat de stappen van toen nu geen verbetering bieden.

Wat wel werkt:

  • ME: via IPMI kan ik het systeem starten; de temperatuur gaat daarmee van 0 graden Celsius naar 127 graden Celcius
  • Hetzelfde is te bereiken met de aan-/uit-knop
  • Piiip-pip-pip bij geen RAM geinstalleerd, maar ook slechts na een vrij lange periode, ca 30 seconden.

Wat niet werkt:

  • Beeld
  • USB power – geen toetsenbord-activiteit

Zodra ik een enkel reepje RAM installeer, volgt er geen pieptoon. Het maakt daarbij niet uit in welk van de twee sloten het reepje geinstalleerd wordt. Via IPMI is te zien dat een van de twee bankjes bezet is.

… of toch niet

Het project heeft een tijdje stilgelegen voordat deze pagina gepubliceerd werd. Nu ik (via IPMI/iKVM) opnieuw door het BIOS loop, probeer ik de verschillende boot-configuraties die mogelijk zijn. Het idee was om de verschillende CSM opties in ‘legacy’ en ‘UEFI’ modus te proberen, en volledig zonder CSM actief. Dat laatste deed ik als eerste en dat was meteen raak. De mogelijk betrokken opties:

  • PCI subsystem settings
    • Above 4G decoding : enable ipv disable
    • ASPM : disabled (default)
  • Boot
    • Boot option 1 : PATA (ja, inderdaad, PATA. Het is het label waaronder PCIe-boot beschikbaar is)
    • CSM : disabled

Met ipmitool -I lanplus -C 3 -H 172.26.90.171 -U admin power on en ipmitool -I lanplus -C 3 -H 172.26.90.171 -U admin sol activate is te zien hoe, tot mijn verbazing en blijdschap, bij de eerste poging GRUB gevonden werd:


AMIBIOS(C)2013 American Megatrends, Inc.

ASUS P9D-I Series ACPI BIOS Revision 2101
Press DEL to run Setup. Press F12 to run Net Boot.
Press ALT + F2 to run EzFlash.
Press F8 for BBS POPUP.
CPU: Intel(R) Xeon(R) CPU E3-1275L v3 @ 2.70GHz
Total Memory: 16384MB (DDR3 1600)

USB Devices total: 2 Drives, 3 Keyboards, 2 Mice, 3 Hubs
USB Drive #0: AMI Virtual CDROM0 1.00
USB Drive #1: AMI Virtual Floppy0 1.00

Detected ATA/ATAPI Devices...
BMC is Ready

Welcome to GRUB!

Print this entry

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

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

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