Berichten

Geplaatst op

VPS-migratie

Een van de VPS’en zit vol. Uitbreiden van de opslagruimte is niet (goedkoop) mogelijk, maar omdat het er al een tijdje aan zat te komen, heb ik een ruimere VPS beschikbaar.

Bij een eerdere migratie, van thuis naar VPS, heb ik een howto op lowendspirit gevolgd waarmee het disk-image goed te versturen was. Ik had nu moeite hem weer terug te vinden, dus voor de volgende keer leg ik het hier ook vast.

Het idee is in grote lijnen:

  • Sluit de draaiende server af, om een statische situatie te hebben zodat het bestandssysteem consistent blijft.
  • Start een rescue-mode op de VPS-omgeving. In de rescue-mode zijn de diskpartities van de VPS beschikbaar.
  • Kopieer de partitie van de ene machine naar de andere machine met dd over SSH

In dit geval is het resultaat: 

rescue # dd if=/dev/vda1 bs=32M status=progress | ssh -C root@185.193.158.65 "dd of=/dev/vda"
The authenticity of host '185.193.158.65 (185.193.158.65)' can't be established.
RSA key fingerprint is SHA256:+EhOiwW9GjD4wv2S/0eRveRdoxV8Mlf1x8sICc9JxUY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '185.193.158.65' (RSA) to the list of known hosts.
root@185.193.158.65's password: 
973078528 bytes (973 MB, 928 MiB) copied, 35.8094 s, 27.2 MB/s

De partitie gaat van een datacenter in Frankfurt naar eentje in Amsterdam. De doorvoersnelheid stabiliseert zich op iets boven 33 MB/s, waarmee de partitie van 20 GB in ongeveer 10 minuten gekopieerd is.

De partitie is meteen al 40 GB, maar het bestandssysteem is nog 20 GB. Met resize2fs kan de grootte van het ext4-bestandssysteem aangepast worden: 

# e2fsck -f /dev/vda
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
....
# resize@fs /dev/vda
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/vda to 10485760 (4k) blocks.
The filesystem on /dev/vda is now 10485760 (4k) blocks long. 
#

Het enige probleem is dat het doelsysteem niet boot. Als ik de schijf boot in rescue-modus, staat alle data er op, inclusief de bootdirectory.

Wat blijkt? Bij het kopieren heb ik uit gewoonte de eerste partitie van de schijf (/dev/vda1) gepakt, terwijl er op de doelserver geen partitie is de schijf zit: het had /dev/vda1 ipv /dev/vda moeten zijn, of allebei /dev/vda.

Opgelost vanuit een system-rescue door:

  • Bestandssysteem krimpen tot minimum, de grootte van de bezette ruimte (resize2fis -M)
  • Nogmaals kopieren, nu van /dev/vda1 naar /dev/vda1
  • Bestandssysteem laten groeien tot partitiegrootte

Het systeem bootte toen wel, maar de netwerkconfiguratie was nog die van de oude server. Toen het eenmaal half-en-half werkte, vond ik de ‘reconfigure networking’ knop in de Solus-management-omgeving.

Daarmee werkte routing voor IPv6 weer; DNS was al gecorrigeerd.

Nu lijkt alles weer naar behoren te werken, met ruim het dubbele aan beschikbare ruimte.

Print this entry

Geplaatst op

Firefox sync server

Omdat de sync server afhankelijk is van Python 2, is het al een tijdje lastig de boel bij te werken. De syncserver op online.osba.nl houdt daarmee de volledige server in z’n grip, omdat daardoor Debian niet van 10 naar 11 geupgrade kan worden. Daarmee zijn recente PHP-versies niet goed beschikbaar, waardoor andere pakketten weer niet bijgewerkt kunnen worden.

De sync server krijgt daarom een eigen machine toegewezen. Het adres veranderd helaas een klein beetje, wat weer gevolgen heeft voor alle verbonden Firefox instanties. Op desktopversies is dat nog wel makkelijk aangepast via about:config, maar op Android is die pagina sinds een paar versies niet meer beschikbaar.

Er is een wat spijtige workaround voor Firefox op Android nodig:

  • ga naar settings –> about Firefox –> klik 5x op het Firefox-logo.
  • er volgt een popupje dat debug-settings beschikbaar zijn
  • in settings is nu onder het kopje ‘Account’ een menu-optie ‘Custom Sync Server’ beschikbaar gekomen.
    • Zolang er een reeds verbonden Firefox-account actief is, is de optie uitgegrijsd
  • vul als custom sync server in: https://ffs.osba.nl/ffsync/token/1.0/sync/1.5
  • Als je het veld leegmaakt, wordt de hele optie op nul gezet en moet je opnieuw op het logo kloppen.

Op dezelfde pagina is te lezen dat voor desktop-versies van Firefox de custom-synchronisatie-optie ook moeilijker gemaakt is, naast het invullen van de URL van de synchronisatieserver, was het ook nodig twee andere instellingen op nee te zetten:

  • identity.fxaccounts.useSessionTokensForOAuth = false
  • identity.sync.useOAuthForSyncToken = false
  • de tokenserver zelf nog steeds corrigeren naar de eigen server:
    • identity.sync.tokenserver.uri = https://ffs.osba.nl/ffsync/token/1.0/sync/1.5

Print this entry

Geplaatst op

Wireguard VPN

Met dank aan Nyr op lowendspirit.com makkelijk te installeren en configureren op een NAT-VPS.

Het script wordt onderhouden op github, de huidige kopie heb ik lokaal staan. Nieuwe versie ophalen met wget https://git.io/wireguard -O wireguard-install.sh

Edit eind 2023: ik heb een kopie in de lokale forge gemaakt. Die zal gaan achterlopen in geval van wijzigingen. Voor de lol: wget https://forge.osba.nl/wbk/wireguard-install/raw/branch/master/wireguard-install.sh

Gebruik:

  • De eerste keer is de daadwerkelijke installatie/configuratie:
    • geef het externe IP/hostname waarop de server bereikbaar is
    • geef een poort die Wireguard mag gebruiken
    • voor de eerste gebruiker:
      • geef de DNS-resolver die gebruikt moet worden
      • geef de gebruikersnaam
    • Wireguard wordt nu geinstalleerd
    • er wordt een QR-code getoond met de configuratie, direct te scannen met een Wireguard-programmaatje op je telefoon
  • De volgende keer uitvoeren kun je nieuwe gebruikers toevoegen

Klaar!

Print this entry

Geplaatst op

UEFI BIOS boot en GRUB

Voor de zoveelste keer tijdens een installatie: wat zijn ook alweer de benodigde partities sinds UEFI?

In ieder geval /boot , groot genoeg voor een stuk of drie Linux-images; met 50-70 MB per stuk is 200 MB ruim voldoende.

Dan is er de BIOS-boot-partitie, waar de UEFI-bestanden terechtkomen. Volgens specificaties tot zo’n 500 MB, maar mag ook minder zijn. Gok ook op 200 MB.

Uiteindelijk: een kleine partitie (1-2 MB is meer dan genoeg) voor de het deel van de bootloader wat voorheen in de loze ruimte in de partitietabel weggeschreven werd. In tegenstelling tot een DOS-partitieschema, heeft GPT geen loze ruimte.

Het is wel nodig om GRUB over te halen gebruik te maken van die loze ruimte, anders meldt grub-install dat use of blocklists ‘discouraged’ is:

# grub-install /dev/sda1 --force

… vooropgesteld natuurlijk dat de mini-partitie te vinden is op /dev/sda1.

Print this entry

Geplaatst op

reMarkable BRICK

Waarschuwingen, wat kun je er anders mee doen dan ze in de wind slaan? Even een alternatieve packagemanager proberen kan geen kwaad toch?

Dat ssh-copy-id niet het gewenste resultaat had, ach… Dan verander ik tijdelijk het wachtwoord naar iets wat ik zeker niet vergeet. Om dan ook nog een reservekopie te maken van je de configuratiebestanden en een backup van kladjes: daar ga ik nu toch niets mee doen. Alleen maar een paar programma’tjes proberen.

Alleen: de programmastarter is niet geintegreerd in het reguliere OS. Het is of stock reMarkable-OS, of iets anders. Jammer, niet het toppunt van handig. Ander programma proberen, mijn favoriete ereader: koreader.

Yep, dat is koreader. Fijn, volgende programmaatje proberen. SSH: timeout. Lichte paniek. WiFi? WiFi staat uit, gelukkig. Netwerk over USB dan; in een keer raak, ssh root@10.11.99.1, maar inloggen? Nee hoor: incorrect wachtwoord. Meer paniek.

Rust. Ik kan niet de eerste zijn die dit verprutst. Na wat zoeken blijken ook niet hele volksstammen er met open ogen ingerend te zijn, maar er zijn howto’s die – na een introductie over ‘bricking beyond repair’ – je weer op pad helpen.

Ik kwam uit bij remarkable-uuuflash. Ik zag er een beetje tegenop om de procedure uit te zoeken, tegen problemen aan te lopen en zonder resultaat de avond af te sluiten, maar die vrees was ongegrond: het werkt precies zoals voorgesteld.

Unbrick

Veel meer dan copy/paste van de bron-site is dit niet. Samengevat:

  • Sluit de reMarkable per USB op je PC; let op dat het een datakabel is, niet eentje die enkel kan opladen.
  • Schakel de reMarkable, mocht hij aanstaan. Dat is nodig om de USB poort van modus te kunnen laten switchen.
  • Houdt de middelste knop onderaan ingedrukt terwijl je de aan-/uitknop een seconde of 3-5 ingedrukt houdt. Op het scherm is niets te zien: het OS dat het scherm aanstuurt, wordt niet gestart.
  • Op je PC zie je met dmesg|tail onderaan de USB poort in flash modus genoemd worden, of met tail -f /var/log/messages komt hij voorbij:
    [111357.268334] hid-generic 0003:15A2:0063.0005: hiddev1,hidraw4: USB HID v1.10 Device [Freescale SemiConductor Inc  SE Blank MEGREZ] on usb-0000:00:1a.0-1.3/input0
  • Gebruik uuu (op je PC) om een recovery-image in RAM (van de reMarkable) te laden :
    # ./uuu recover.uuu
  • De reMarkable boot nu in het recovery-image; als tail -f /var/log/messages aan staat, zie je de seriele poort voorbij komen, anders lezen op de laatste regels van dmesg|tail. Het zal waarschijnlijk een /dev/ttyACMx-apparaat zijn.
  • Open nu een seriele verbinding vanaf je PC naar de reMarkable:
    # screen /dev/ttyACM1
  • Log in als root
  • Je zit nu in het recovery-image, er is dus nog niets beschikbaar van de flash opslag op de reMarkable. Die kun je wel aankoppelen:
    # mount /dev/mmcblk1p2 /mnt/
    # mount /dev/mmcblk1p7 /mnt/home
    # mount /dev/mmcblk1p1 /mnt/var/lib/uboot
  • chroot naar het aangekoppelde bestandssysteem:
    # chroot /mnt
  • Voer nu uit waar je voor gekomen was. In mijn geval: het wachtwoord van root verwijderen. passwd werkte niet, misschien dat dat ook in de chroot-omgeving het /etc/shadow-file buiten chroot probeert aan te passen, of misschien is er iets ingebouwd in het reMarkable-OS dat voorkomt dat het wachtwoord aangepast wordt (zou verklaren waarom ik er eerder niet inkwam). In plaats daarvan, maak ik het root-password leeg door in /etc/passwd de verwijzing naar /etc/shadow te verwijderen:
    # vi /etc/passwd
  • de ‘x’ achter root geeft aan dat het gehashte wachtwoord opgeslagen is in /etc/shadow: root:x:0:0:root:/home/root:/bin/sh wordt root::0:0:root:/home/root:/bin/sh, dus zonder de ‘x’ tussen de ::’s

Met een reboot-commando wordt de reMarkable herstart. screen blijft nog even hangen, met de toetsenserie enter-tilde-punt-enter wordt de verbinding verbroken als het je te lang duurt.

Terug in koreader…

… maar nu met werkende SSH-toegang. Eerst maar terug naar reMarkable-OS:
systemctl disable --now koreader && systemctl enable --now xochitl

Op zoek naar een oplossing kwam ik tegen dat er de middelste knop als switch van reMarkable-OS naar koreader in te richten is, en bovendien dat launchers het leven eenvoudiger kunnen maken.

… en weer terug in reMarkable-OS

Installatie van ddvk-hacks had een reboot nodig om de functionaliteit beschikbaar te maken in xochitl, de reMarkable-reader-app.

Na de reboot was het wachtwoord weer actief: niet het lege wachtwoord, niet mijn zelfgekozen wachtwoord, maar h04ytCFiD zoals in de help (waar ik nu weer bij kan).

Task switcher to the rescue

Er zijn nu drie launchers in het opkg-repository, draft, oxide en remux. Van die drie lijkt alleen remux een multitasking-launcher te zijn. Die heb ik nu bereikbaar via lang indrukken van de middelste knop met
# systemctl enable --now remux

Dat werkt best aardig. Mooi voor vanavond!

Print this entry

Geplaatst op

LVM thin pool extension, v2

Het verhaal van vorige keer dat een van de data-LV’s bijna vol zat is wat lang van tekst en niet volledig van uitleg, nu een poging voor een puntsgewijze howto.

Het gaat deze keer om de video-LV. Een DV-tapes neemt ongeveer 15 GB in beslag, en er was niet meer voldoende ruimte voor de eerste vakantie-tape.

Gebruikte commando’s

# df-h /home/wbk/movies 
# lvs -a data/videoRW -o+thin_count,thin_id,devices
# vgs data -o+pv_name,pv_free
# pvs /dev/sde1 -a -o-vg_name -o+vg_name,vg_size,vg_free,lv_name,origin,pool_lv,data_lv
# lvextend -r -L+200G data/videoRW /dev/sde1

Huidige status afleiden

Eerst df -h om de juiste LV bij de volle directory/partitie te vinden. De movies-directory heeft nog 13 MB vrij in LV data-videoRW :

df -h /home/wbk/movies
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.3T  1.3T   13M 100% /home/wbk/movies

Daarna de LVM-status erbijzoeken; /dev/mapper/data-videoRW is een van de vijf thin LV’s onder datatlvpool, namelijk nummer 4 (onderaan). videoRW heeft zelf geen (hardware-) device, omdat het een logisch volume in een logisch volume is.

Het feitelijke (hardware-) device waarop de data terecht komt, kan gevonden worden via de thin pool, hier datatlvpool.

Omdat videoRW een thin LV is, kan de in df -h gerapporteerde vrije ruimte groter zijn dan de daadwerkelijke beschikbare ruimte op de onderliggende fysieke volumes. Dat is voor videoRW (nog) niet aan de orde: datatlvpool heeft nog 8% van 800 GB, ~64 GB, vrije ruimte. 

root@fractal:~# lvs -a data -o+thin_count,thin_id,devices
  LV                  VG   Attr       LSize   Pool          Origin          Data%  Meta%  Move Log Cpy%Sync Convert #Thins ThId Devices             
  archief             data -wi-a----- 800.00g                                                                                   /dev/sda9(0)        
  [cache_fotos]       data Cwi---C---  48.00g                               99.99  9.16            0.00                         cache_fotos_cdata(0)
  [cache_fotos_cdata] data Cwi-ao----  48.00g                                                                                   /dev/sdd4(0)        
  [cache_fotos_cmeta] data ewi-ao---- 100.00m                                                                                   /dev/sdb4(0)        
  datatlvpool         data twi-aot--- 798.21g                               92.02  47.56                                 5      datatlvpool_tdata(0)
  [datatlvpool_tdata] data Twi-ao---- 798.21g                                                                                   /dev/sde1(0)        
  [datatlvpool_tmeta] data ewi-ao---- 400.00m                                                                                   /dev/sdb4(10265)    
  fotosRO             data ori-a-C---   2.68t [cache_fotos] [fotosRO_corig] 99.99  9.16            0.00                         fotosRO_corig(0)    
  [fotosRO_corig]     data owi-aoC---   2.68t                                                                                   /dev/sda1(1)        
  fotosRW             data Vwi-aot---  <3.27t datatlvpool   fotosRO         15.21                                             5                     
  geluidRO            data ori-a-----  16.56g                                                                                   /dev/sda1(703333)   
  geluidRW            data Vwi-aot---  16.56g datatlvpool   geluidRO        5.19                                              1                     
  [lvol0_pmspare]     data ewi------- 400.00m                                                                                   /dev/sda1(707573)   
  muziekRO            data ori-a----- 150.00g                                                                                   /dev/sda2(1)        
  muziekRW            data Vwi-aot--- 150.00g datatlvpool   muziekRO        26.97                                             2                     
  pubNR               data ori-a-----   8.00g                                                                                   /dev/sda2(323587)   
  pubRW               data Vwi-aot---   8.00g datatlvpool   pubNR           0.01                                              3                     
  romRO               data -wi-ao----  90.00g                                                                                   /dev/sda3(1)        
  ssdata              data -wi-ao----  40.00g                                                                                   /dev/sdb4(25)       
  videoRO             data ori-a-----  <1.09t                                                                                   /dev/sda2(38402)    
  videoRW             data Vwi-aot---   1.23t datatlvpool   videoRO         14.56                                             4

De conclusie is wel: om de vakantietapes van dit jaar over te zetten op schijf, moet naast het videoRW-volume, ook het datatlvpool-volume groter gemaakt worden. Voor metadata is nog voldoende ruimte: datatlvpool_tmeta heeft nog maar 200 MB van 400 MB gebruikt.

Hoeveel ruimte is er om datatlvpool groter te maken? Dat hangt van de vrije ruimte in de volumegroep data af, en uiteindelijk van de vrije ruimte van de onderliggende fysieke volumes. De data van datatlvpool zit in het data-component van het volume, datatlvpool_tdata, met als onderliggend (handmatig toegewezen) fysiek volume /dev/sde1. 

# vgs data -o+pv_name,pv_free
  VG   #PV #LV #SN Attr   VSize VFree  PV         PFree   
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda1    18.07g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda2     9.80g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda3   <60.00g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sdd4    <2.00g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sdb4    <7.51g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sda9  <328.67g
  data   7  14   0 wz--n- 7.31t <1.64t /dev/sde1     1.22t

Het rapport voor PV /dev/sde1 laat zien dat sde1 deel uitmaakt van VG data. Die VG heeft (in totaal) 1.6 TB vrije ruimte, de (enige) toegewezen LV is datatlvpool_tdata

# pvs /dev/sde1 -a -o-vg_name -o+vg_name,vg_size,vg_free,lv_name,origin,pool_lv,data_lv
  PV         Fmt  Attr PSize  PFree VG   VSize VFree  LV                  Origin Pool Data
  /dev/sde1  lvm2 a--  <2.00t 1.22t data 7.31t <1.64t [datatlvpool_tdata]                 
  /dev/sde1  lvm2 a--  <2.00t 1.22t data 7.31t <1.64t

De grootte van pool datatlvpool kan automatisch bijgewerkt worden door LVM, zie Automatically extend thin pool LV in man 7 lvmthin, maar voor de thin volumes zelf zie ik het niet 1-2-3. Die moet dus handmatig vergroot worden. Controle van de gemonitorde pool:

# lvs data/datatlvpool -o+seg_monitor
  LV          VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Monitor  
  datatlvpool data twi-aot--- 798.21g             92.02  47.56                            monitored

Extend thin volume videoRW

Automatische uitbreiding van de thin volumes kan ook aangezet worden, zie man 7 lvmthin , Automatic extend settings.

Waarschijnlijk heb ik het, bang voor ongemerkt volschrijven van de VG, uitgezet. De standaardsetting is dat de thinLV bij 70% uitgebreid wordt, met 20%. Dat kun je uitzetten door in /ect/lvm/lvm.conf de optie thin_pool_autoextend_threshold op 100 te zetten. Dat staat hij op het moment, en met dezelfde overweging laat ik hem daar op staan. 

# lvextend -tvr -L+200G data/videoRW /dev/sde1
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Executing: /sbin/fsadm --dry-run --verbose check /dev/data/videoRW
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Filesystem has not been checked after the last mount, using fsck -f
fsadm: Dry execution fsck -f -p /dev/mapper/data-videoRW
    Test mode: Skipping archiving of volume group.
    Extending logical volume data/videoRW to <1.43 TiB
  WARNING: Sum of all thin volume sizes (<4.87 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<1.64 TiB).
  Size of logical volume data/videoRW changed from 1.23 TiB (323584 extents) to <1.43 TiB (374784 extents).
    Test mode: Skipping backup of volume group.
  Logical volume data/videoRW successfully resized.
    Executing: /sbin/fsadm --dry-run --verbose resize /dev/data/videoRW 1535115264K
fsadm: "ext4" filesystem found on "/dev/mapper/data-videoRW".
fsadm: Device "/dev/mapper/data-videoRW" size is 1357209665536 bytes
fsadm: Parsing tune2fs -l "/dev/mapper/data-videoRW"
fsadm: Resizing filesystem on device "/dev/mapper/data-videoRW" to 1571958030336 bytes (331350016 -> 383778816 blocks of 4096 bytes)
fsadm: Dry execution resize2fs /dev/mapper/data-videoRW 383778816

dsadm: Skipping filesystem check : Het bestandssysteem is aangekoppeld; fsck kan geen kwaad dus ik unmount het.
WARNING: Sum of thin volumes exceeds thin pool: Ik vermoed dat in de 4.77 TB ook de RO-origins opgenomen zijn, anders zit ik volgens mij nooit tegen de 5 TB aan mediabestanden. Alhoewel… fotosRW geeft aan 3.27 TB, waarvan 15.21% bezet is. Dat zou redelijk passen in een totaal van ~5 TB waarvan minder dan 1.5 TB bezet is.

Nu voor ’t echie:

# lvextend -r -L+200G data/videoRW /dev/sde1  
fsck from util-linux 2.36.1
...
filmNR: Inode 54001666 extent tree (at level 2) could be narrower.  IGNORED.
filmNR: Inode 55050243 extent tree (at level 1) could be shorter.  IGNORED.
...
filmNR: Inode 60030985 extent tree (at level 1) could be narrower.  IGNORED.
filmNR: 5000/82837504 files (23.6% non-contiguous), 328700572/331350016 blocks
  WARNING: Sum of all thin volume sizes (<4.87 TiB) exceeds the size of thin pool data/datatlvpool and the amount of free space in volume group (<1.64 TiB).
  Size of logical volume data/videoRW changed from 1.23 TiB (323584 extents) to <1.43 TiB (374784 extents).
  Logical volume data/videoRW successfully resized.
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/data-videoRW to 383778816 (4k) blocks.
The filesystem on /dev/mapper/data-videoRW is now 383778816 (4k) blocks long.

De beschikbare ruimte in de volumegroup data is nog steeds 1.64 TB, er is immers enkel beschikbare ruimte toegewezen aan de thin LV videoRW, maar nog niets gebruikt.

Het resultaat

Er is nu voldoende ruimte voor zo’n 12 uur aan DV-video: 

# df -h /home/wbk/movies/
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/data-videoRW  1.5T  1.3T  206G  86% /home/wbk/movies

Print this entry

Geplaatst op

Verlanglijstje

Deze keer:

  • Een nieuw kussen, of in ieder geval het luchtige schuimrubber aan de binnenkant, voor mijn fiets;
  • Een abonnement op Ars Technica, met een NFC-security-key;
  • Een prettige rugzak, met meerdere compartimenten en heup-riem;
  • Een stofzuigrobotje?

Print this entry

Geplaatst op

Zomervakantie 2022

Stranden zoeken: beachsearcher.com

1e etappe: Zwolle – Zwarte Woud (26)

Langs de Rijn omhoog naar het Zuiden; eerst naar Arnhem (via A50 en A12 richting Oberhausen), grens over bij Zevenaar, over de A3 langs Oberhausen, Duisburg, Dusseldorf, Keulen, (op een afstandje langs) Koblenz, tussen Frankfurt, Wiesbaden en Mainz door richting Darmstadt. Daar wordt het A5, langs Mannheim en Heidelberg tot Karlsruhe. Daar naar het Oosten afbuigen over de A8. Voor Waldbronn afslag 42 nemen, anders bij Pforzheim van de snelweg af (afslag 43) naar het Zuiden. Het is dan nog ongeveer 40 kilometer naar Oberhaugstett.I will check my

Vaste priks:

2e etappe: Zwarte Woud – Bodensee (27)

Indien nodig, eerst van Waldbron ongeveer naar Oberhaugstett; vanaf Oberhaugstett een kort stukje naar Wildberg, dan naar het Zuiden over de A81 langs Horb-, Sulz- en Obendorf am Neckar, langs Rottweil, Trossingen en Geisingen, Engen en Singen naar Schaffhausen

  • route naar laadplein bij de waterval, Lauferstrasse, Uhwiesen, Laufen-Uhwiesen, Bezirk Andelfingen, Zurich, 8248, Switzerland
  • batterijplanner vanaf Oberhaugstett (150 km); vanaf Waldbronn 210 km

Met een korte omweg komen we door Freudenstadt (waar we vanuit Bad Rippoldsau een paar keer geweest zijn); als we de dag van tevoren bellen kunnen we kijken of we bij het Vietnamese restaurant daar kunnen ontbijten.

  • route naar Freudenstadt (45 km, drie kwartier), en
  • route van Fruedenstadt naar het laadplein in Schaffhausen (140 km, een kleine twee uur)
  • aangepaste batterijplanner vanaf Oberhaugstett over Fruedenstadt (170 km); vanaf Waldbronn 200 km

Er zijn 8 geschikte laadpalen beschikbaar naast de waterval, maar LET OP: laden via newmotion/shellrecharge of via een app van swisscharge (de palen staan niet vermeld op abetterrouteplanner.com, en niet op openchargemap.io, wel op https://shellrecharge.com/nl-nl/vind-een-laadpunt)

Daarna van Schaffhausen via Konstanz naar Dornbirn in Oostenrijk. De routeplanner wil het eerste stuk niet langs het meer rijden, misschien is dat twee minuten langzamer, of het is alleen voor fietsers.

3e etappe: Dornbirn – noord Italie (28)

We kunnen door een tunnel onder de hoogste Alpen rijden en een stuk afsnijden, maar we kunnen er ook overheen gaan. We zijn dan langer onderweg, maar er zijn ook leukere plaatsen om uit te stappen.

Davos is wel een bekende plaats in de Zwitserse Alpen, daar zouden we wat kunnen eten en opladen. (Davos valt af, we komen dan aan de verkeerde kant van de Stelviopas aan) De Stelviopas is een van de hoogste bergpassen in de Alpen, die is daar niet ver vandaan de weg over de Alpen naar Italie. We gaan grappig genoeg juist vanuit Italie naar Zwitserland de pas over!

Net ten Zuiden van de Alpen is een groot meer (Garda), daar in de buurt, in Gavardo, heb ik een B&B gevonden die net de dag dat we daar rijden, een vrije kamer heeft.

Een andere optie is om in de buurt van Verona te overnachten. Dat is iets verder rijden, 60 km ongeveer, maar het is ook een mooie plaats. We komen daar zowiezo langs als we naar Ancona (op weg naar het Zuiden) of naar Venetie (dat is nog een redelijk stuk naar het Oosten) gaan.

  • Naar Venetie? Dan overnachten in de buurt van Verona, en in de buurt van Venetie, voor we naar het Zuiden gaan
  • Niet naar Venetie? Dan overnachten in de buurt van het Gardameer, daar kijken, via Verona naar het Zuiden rijden.

Na wat advies, nalezen en overleg, geen Venetie: het is een redelijke omweg, en midden in de zomer op z’n drukst.

Vaste priks:

  • route: die is wat gefragmenteerd, omdat de routeplanner graag door de tunnel gaat in plaats van een toeristische route te nemen. Ik reken met effectief vertrekken om 10 uur ’s ochtends; met pauzes en laden komen we rond 19.30 aan.
    • Vorarlberg-Tirol: de Arlberg-tunnel ligt op de landsgrens, Arlbergpass aanhouden om bovenlangs te gaan. Op de pas zal vast een uitkijk/drinkpunt zijn.
      • 80 km
      • 1 uur rijden
      • niet laden (iets meer dan 50% gebruikt, daarna bergafwaarts)
      • 11 uur
    • Pauze 30 minuten
      • 11.30
    • Tirol-Trontino / Suedtirol:
      • 90 km
      • ruim 1 uur rijden
      • laden in Graun im Vinschgau (ca 90% gebruikt)
      • 12.45
    • Graun im Vinschgau: hapje eten, eindje wandelen langs het meer
      • batterij laden, in ieder geval een half uurtje@22kW
      • 1,5 uur lunch
      • 14.15
    • Trontino-Stelviopas /Passo dello Stelvia:
      • 50 km
      • 45 minuten
      • 15.00
    • Passo dello Stelvia: Op de pas lijkt er een uitkijkpunt te zijn, een paar hotels en parkeerplaatsen. Er is een punt dat ‘Dreisprachenspitz’ heet. Er zal vast iets te drinken en te wandelen zijn.
      • via Prad am Stilfser Joch (Prato allo Stelvio) en Trafoi (dan komen we de Italiaanse kant van de pas op, anders aan de andere kant van de ‘Rotelspitze’/’Punta Rosa’, in Zwitserland. Naar beneden gaan we in ieder geval aan de Zwitserse kant
      • 30 minuten pauze
      • niet laden, we gaan nu alleen maar naar beneden
      • 15.30
    • Stelviopas-PicNic Il Cantoniera: er lijkt een fotopunt te zijn bij deze picnicplaats, daarna gaat het stijl bergafwaarts
      • 13 km
      • 11 minuten
      • 15.40
    • PicNic: korte fotopauze
      • 15 minuten
      • 15.55
    • PicNic Il Cantoniera – Pisogne : Hier avondeten en laatste laadsessie. In Pisogne zijn twee laadlocaties met twee contacten; in zowel Gratacasolo als in Pian Camuno, telkens 5 km terug op de route, zijn er ook twee palen met twee contacten. Langs het meer zelf zijn de laadpalen dun gezaaid, een in Sulzano, een in Iseo. Voorbij het meer, in Brescia, zijn er wel vrij veel laadpalen. Als we hier rond vijven zijn, is het waarschijnlijk nog vroeg voor avondeten in Italie.
      • 120 km
      • ruim 2 uur
      • 17.00
    • Pisogne – avondeten
      • 1.5 uur
      • auto laden
      • 18.30
    • (misschien even kijken: Terme di Bormio , locatie: halverwege de pas en Bormio; bezoeken niet echt de moeite, 44 euro pp)
    • Pisogne-Gavardo : hier overnachten we. Als de rit volgens plan verloopt, is het nog licht. Het Gardameer ligt op ongeveer 10 kilometer afstand, we zouden nog even kunnen gaan kijken.
      • 70 km
      • 1 uur
      • 19.30
    • Gavardo: hier overnachten
  • Batterijplanner voor de hele rit (1x ruim een uur in Graun im Vinschgau, 1x een half uur in Pisogne, om met enkele procenten respijt in Gavardo aan te komen. Tijdens het eten volladen is wel handig, dan halen we het om langzaamladend de volgende ochtend met een volle accu te vertrekken. De dichtstbijzijnde laadpaal bij de Aldi (1,5 km lopen) lijkt gratis te gebruiken, dat zal de beschikbaarheid niet ten goede komen.

4e etappe: Noord Italie – San Marino (29)

Vanuit Gavardo via Verona en San Marino richting Ancona, daar een paar dagen bijkomen aan het strand.

Overnachtingsopties:

De stille vrede is ondertussen geboekt, het wordt de lieve vrede voor families in de heuvels.

  • route van Gavalto via Verona naar San Marino
    • 330 km
    • ruim drie uur, sightseeing niet meegerekend
  • route van San Marino naar Montefiori Conca (dorp, locatie moet nog bevestigd worden)
    • 25 km
    • 40 minuten door het binnenland

Geen etappe – Montefiori Conca (30)

Een dag naar het strand, omgeving bekijken. Er schijnen mooie dorpjes in de buurt te zijn.

5e etappe: San Marino – Marche (31)

Via een strand tussen Rimini en Ancona, of, gezien het uitzicht zoals in beachsearcher te zien, misschien een strand aan de voet van de berg/heuvel bij Ancona, bij Civitanova rechtsaf bij de zee vandaan rijden naar Petrolio.

  • route van Montefiori Conca naar Petriolo
    • 160 km zonder strandstops
    • 2 uur

Geen etappe: Petriolo

Hier een paar dagen blijven, strand bezoeken, omgeving bekijken, verdere plannen maken. In grote lijnen nog uit te werken:

  • Petriolo
    • 2 nachten: een dag bijkomen op het strand, ’s avonds plannen, daarna op pad
  • Napels
    • Pompei/Herculeum/Vesuvius – 1 dag
    • Er zal vast in de baai iets te zien zijn – 1 dag
    • Er is een zomerfestival verder naar het Zuiden, er is vast meer te doen; bootje varen? – 1 dag
    • het is een kleine 400 km rijden, een kleine 5 uur – 1 dag
    • waar slapen?
  • Rome
    • Nog helemaal geen plan; 2 dagen Rome is snel voorbij
    • Omgeving verkennen – 2 dagen
    • Het is 250 km rijden over de snelweg, een kleine drie uur. Misschien is een route (dichter) langs de kust mooier – 1 dag
  • Het is nu nog 1600 km (snelweg) naar Zwolle. Met etappes van 300 km per dag, nog 5 dagen; met een toeristische route al snel 7 dagen.

Rome en verder

  • dag 1 (09) : Rome – Piombino – Elba – Pisa ; overnachten in Pisa
    • Rome weg met volle accu
    • bijna leeg rond Piombino; dichtstbijzijnde laadpalen op ca 10 km;
    • Mikken op rond 12u in Piombino, boot naar Elba
    • 13u op Elba; Napoleon-iets bezoeken, strand
    • 17u boot terug naar Piombino
    • Bij Piombino evt Etruskisch-iets bezoeken en eten in Populonia
    • 100 km naar Pisa, 40-60 minuten laden, 1.5 uur rijden
    • aankomen in Pisa 21-22u
  • dag 2 (10): Pisa – Milaan; overnachten in Milaan
    • volgende ochtend op tijd weg om Zwitserland door te rijden
  • dag 3 (11): in Milaan
  • dag 4 (12): Milaan – Zwarte Woud rond Colmar
  • dag 5 (13): in Colmar
  • dag 6 (14): Colmar – Zwolle
    • kleine 700 km, 2x laden, laat thuis

uiteindelijke route

Ik heb de route bij benadering op Graphhopper uitgetekend.

Print this entry

Geplaatst op

Yunohost SSH toegang

Normaliter hebben Yunohost-gebruikers geen SSH-toegang. Zodoende is het lastig om de bestanden via SSHFS te benaderen. Om de bestanden via SSHFS te benaderen, zijn er twee dingen aan te passen.

  1. SSH toegang beschikbaar maken voor de gebruiker
  2. Toegang op bestandsniveau regelen voor die gebruiker via ACL

1 – SSH toegang

Via het Yunohost forum werd ik gewezen op de SSH-toegang die vanaf (ongeveer) versie 4.2 van Yunohost uitgedeeld kan worden. Ik gebruik voor SSH toegang een afzonderlijke gebruiker, die naast SSH-toegang, geen applicaties toegewezen krijgt.

Gebruiker voor SSH toegang

Via ‘Manage groups and permissions’ kun je SSH-toegang toewijzen:

Maak een nieuwe groep (hier sshfsnc), en geef die SSH-permissie
Voeg de gebruiker die je net gemaakt hebt toe aan de SSH-groep

2 – ACL’s

Via access control lists kun je extra rechten toekennen aan bestanden, naast de reguliere eigenaar/groep/iedereen rechten op bestandsniveau.

De toegangsrechten van Yunohost zijn erg nauw gedefinieerd. Via het bestandssysteem kun je als gebruiker niet bij je eigen bestanden die in Nextcloud staan, en Nexctloud kan niet bij je bestanden in je home-directory. De admin-gebruiker kan ook maar beperkt bij verschillende bestanden komen, alleen root kan overal bij.

Om via de gebruiker met SSH toegang de bestanden uit Nextcloud te benaderen, moeten die vrijgegeven worden via ACL. Hoe dat gaat, heb ik in dezelfde forumthread gepost:

# cd /home/yunohost.app/nexctloud/data/
# setfacl -Rm u:boudewijn_ssh:rx boudewijn/
# setfacl -dRm u:boudewijn_ssh:rx boudewijn/
# setfacl -m u:boudewijn_ssh:rx .
# setfacl -dm u:boudewijn_ssh:rx .

Er is telkens een regel voor de nieuwe default (met -d), en dezelfde voor de rechten op de bestaande bestanden. Daarnaast telkens een recursieve regel (-R) voor de data-directory van gebruiker boudewijn, en een niet-recursieve op de huidige directory (/home/yunohost.app/nextcloud/data/). Setfacl heeft -m nodig, daarmee geef je aan dat het een wijziging/modificatie is.

Synchronisatie

Zolang je via SSHFS enkel bestanden leest, blijft alles werken zoals vanouds. Als je ook bestanden wegschrijft via SSHFS, loopt die actie buiten Nextcloud om. Het bestand wordt daardoor niet in Nextcloud geregistreerd, en is daarvandaan niet zichtbaar. Er is een OCC-opdracht om de opslagruimte te scannen op wijzigingen en de database bij te werken.

WebDAV

Om het toevoegen van bestanden, en alle wijzigingen aan bestanden, meteen in Nextcloud beschikbaar te maken, moet de verbinding via WebDAV gemaakt worden. Het werkt minder snel, maar wordt op meer platformen ondersteund dan SSHFS.

Print this entry

Geplaatst op

LVM thin pool extension

De foto-LV zit bijna vol, nog 32 GB te gaan. Er is meer ruimte nodig: om Nextcloud op online te kunnen upgraden naar de laatste versie, heb ik daar ruimte voor een backup nodig, en dat lukt niet met het huidige aantal (en grootte van) bestanden. De foto’s gaan daarom voor een groot deel naar de andere machine, maar 32 GB is niet voldoende.

De foto’s staan op een samengesteld volume:

  • cache_fotos , een caching-LV op twee SSD’s:
    • cache_fotos_cmeta
    • cache_fotos_sdata
  • data-LV, bestaand uit
    • fotosRO , een read-only LV op langzame SMR schijf
    • fotosRW, een thin LV met ‘external origin’ fotosRO, zelf een beschrijfbaar LV in LV datatlvpool. Die datatlvpool heeft twee onderliggende LV’s
      • datatlvpool_tmeta
      • datatlvpool_tdata

Er kan dus op vijf punten te weinig ruimte ontstaan:

  • fotosRW
  • datatlvpool_tmeta
  • datatlvpool_tdata
  • cache_fotos_cmeta
  • cache_fotos_cdata

Om te controleren op beschikbare ruimte:

  • df -h | grep fotos RW voor LV fotosRW
    df -h | grep fotosRW
    /dev/mapper/data-fotosRW 2.9T 2.8T 32G 99% /home/wbk/photos
    • de 32G zou meer mogen zijn
    • de 99% zou minder mogen zijn
  • lvs -a data |grep twi voor de thin pool
    lvs -a data |grep twi
    datatlvpool data twi-aot— 409.60g 85.25 37.98
    • 85.25 is het percentage tdata in gebruik, er is dus nog ~60 GB (15% van 400 GB) beschikbaar voor alle thin LV’s in deze pool
    • 37.98 is het percentag tmeta in gebruik, er is nog ~150 MB (60% van 250 MB) beschikbaar voor het beheer van de thin LV’s in deze pool
  • lvs -a data |grep Cwi—C voor de cache-LV:
    lvs -a data |grep Cwi—C
    [cache_fotos] data Cwi—C— 48.00g 81.11 9.16 0.00
    • 81.11 is het percentage cdata in gebruik, er is ~10 GB (20% van 48 GB) beschikbaar voor aanvullende caching voor de fotos. Het lijkt dat enkel fotosRO caching heeft, lvs -a |grep C— geeft alleen de -RO LV’s terug
    • 9.16 is het percentage cmeta in gebruik, er is nog 90 MB (90% van 100 MB) beschikbaar voor beheer van het cache

Het belangrijkste is de ruimte op datatlvpool. Als er geen tdata of tmeta meer beschikbaar is, kan het bestandssysteem op fotosRW kapotgaan. Het lijkt of er nog gewoon naar het bestandssysteem geschreven kan worden, er lijkt in dat geval immers nog ruimte beschikbaar. Normaliter wordt de pool automatisch verruimd op het moment en met de percentages vermeld in /etc/lvm/lvm.conf

  • thin_pool_autoextend_threshold = 95
  • thin_pool_autoextend_percent = 10

Het verantwoordelijke proces daarvoor is dmeventd. Controleer of de pool gemonitord wordt door dmeventd met lvs -o+seg_monitor | grep monitored
Met de huidige instellingen wordt dmevendt pas over 40 GB getriggerd de pool te verruimen met 30 GB. Dat kan doorgaan zolang er voldoende ruimte in de bovenliggende VG is. VG data heeft 2 van 7 TB beschikbaar.

Het makkelijkst valt ruimtegebrek op fotosRW op: er kunnen geen bestanden meer naar het bestandsysteem geschreven worden, ‘disk full’. Zolang er nog ruimte in de datatlvpool beschikbaar is, kan het vergroot worden met een simpele lvextend -rL+100G /dev/mapper/data-fotosRW

Geen ruimte op caching-LV’s geeft geen directe problemen: er wordt minder optimaal gecached, maar bestaande cache blijft werken (of misschien wordt de data aangepast om nieuwe/andere bestanden te cachen). Ook het volledig wegvallen van cache geeft enkel een snelheidsvermindering en heeft geen dataverlies tot gevolg.

Afwachten

Deze keer ga ik enkel fotosRW meer ruimte geven, en in de gaten houden wat datatlvpool doet. Met de kennis van nu, verwacht ik dat er nog niets gebeurt op het moment dat fotosRW meer ruimte toegewezen krijgt, maar dat tijdens het verplaatsen van foto’s van Nextcloud naar fotosRW er meermaals een dynamische toewijzing van ruimte aan datatlvpool plaatsvindt.

Terugzoeken van details: zie man 7 lvmthin

Proef op de som

Om de boel in de gaten te houden, heb ik eerst fotosRW groter gemaakt het het bestandssysteem mee laten groeien:

lvextend -rL+100G /dev/mapper/data-fotosRW

Beschikbare vrije ruimte de fotopartitie is toegenomen, terwijl er van VG data geen vrije ruimte afgesnoept is:

root@fractal:~# df -h | grep  -E 'fotosRW|Use'
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW        3.0T  2.8T  128G  96% /home/wbk/photos

root@fractal:~# vgs data            
  /dev/sdd: open failed: No medium found
  VG   #PV #LV #SN Attr   VSize VFree 
  data   7  14   0 wz--n- 7.31t <2.02t

Daarna foto’s kopieren in groepjes van zo’n 5 GB. Net bij het laatste groepje is de 95% aangetikt. De toewijzing van extends uit VG data aan thin LV pool datatlvpool lijkt niet onmiddelijk te zijn, je kan de toewijzing zien groeien door met enige tussenpoos opnieuw de status van VG’s en LV’s op te vragen: 


# Bij afronden laatste batch van de initiele set foto's: 
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 409.60g                               94.73  41.80
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         7.48   
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

# Even later is te zien dat onder 'Data%' de waarde van 94.73 teruggelopen is naar 89.91...
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 450.56g                               89.91  43.48  
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         8.05       
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

# ...en nog weer 
root@fractal:~# lvs data| grep -E 'twi|fotosRW|LSize'
  LV          VG   Attr       LSize   Pool          Origin          Data%  Meta%  
  datatlvpool data twi-aot--- 495.62g                               87.38  46.21                           
  fotosRW     data Vwi-aot---  <2.98t datatlvpool   fotosRO         8.96  
root@fractal:~# df -h | grep -E 'fotosRW|Use'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/data-fotosRW           3.0T  2.8T   72G  98% /home/wbk/photos

Beschikbare vrije ruimte in VG data is afgenomen: 

                             
root@fractal:~# vgs data
  /dev/sdd: open failed: No medium found
  VG   #PV #LV #SN Attr   VSize VFree
  data   7  14   0 wz--n- 7.31t 1.93t

Conclusie: het systeem werkt. Ik weet niet of het nadelig is om meermaals kleine brokjes toe te kennen, in plaats van in een keer een veel groter stuk. Nu staat met 87% bezetting de volgende verruiming van datatlvpool alweer voor de deur.

Print this entry