:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
Hmm, blijkbaar is het toch nog steeds niet in orde. "Zomaar" een scrub gestart, zonder vooraf de status te bekijken (ook geen mail ontvangen dat iets zou zijn). Vervolgens meteen na starten de status bekijken en "al" (van nu, of eerder):
Waarbij de SMART data ook nog steeds pico bello is:
Toch maar eens gaan kijken wat ik hier nu weer mee ga doen... In principe kan (/wilde ik mogelijk sowieso al) ik de redundant NVME drive uit de NAS halen (mirror setup). In principe zou ik dan (middels een tweede systeem met dubbel NVME) een volledige clone kunnen doen (en niet vergeten de EFI partitie te clonen), middels een nieuwe pool en send & receive. Evt zou ik dan ook tijdelijk op die drive kunnen draaien, en als dan alles in orde zou zijn / blijven de pool recreëren op de huidige SSD. Maarja, blij wordt ik er niet van en "vertrouwen" in het systeem is momenteel ook nogal "laag" (zij het het PCtje zelf, zij het de SSD, ergens gaat toch iets serieus mis).
Edit:
En na tweede scrub is weer alles weg
(zonder clear tussendoor dus)
Edit2:
* zucht *. Dus de status van de scrub die om 10:03 was afgerond was "alles in orde" maar om 10:20 blijkt toch dat alweer iets aan de hand is...
Vanavond dus maar eens rebooten en wellicht even de SSD eruit halen en opnieuw er in zetten. Dit is naar mijn idee te random om daadwerkelijk een issue te zijn.
code:
1
2
3
4
5
6
7
| errors: Permanent errors have been detected in the following files:
<0x8a2f>:<0x0>
<0x9636>:<0x0>
<0x54cc>:<0x0>
<0x73cc>:<0x0>
<0xad2>:<0x0> |
Waarbij de SMART data ook nog steeds pico bello is:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02) Critical Warning: 0x00 Temperature: 63 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 1% Data Units Read: 8,333,344 [4.26 TB] Data Units Written: 20,073,813 [10.2 TB] Host Read Commands: 50,353,712 Host Write Commands: 606,935,533 Controller Busy Time: 930 Power Cycles: 138 Power On Hours: 480 Unsafe Shutdowns: 66 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0 Temperature Sensor 1: 63 Celsius Temperature Sensor 2: 66 Celsius Thermal Temp. 2 Transition Count: 1 Error Information (NVMe Log 0x01, 16 of 64 entries) No Errors Logged |
Toch maar eens gaan kijken wat ik hier nu weer mee ga doen... In principe kan (/wilde ik mogelijk sowieso al) ik de redundant NVME drive uit de NAS halen (mirror setup). In principe zou ik dan (middels een tweede systeem met dubbel NVME) een volledige clone kunnen doen (en niet vergeten de EFI partitie te clonen), middels een nieuwe pool en send & receive. Evt zou ik dan ook tijdelijk op die drive kunnen draaien, en als dan alles in orde zou zijn / blijven de pool recreëren op de huidige SSD. Maarja, blij wordt ik er niet van en "vertrouwen" in het systeem is momenteel ook nogal "laag" (zij het het PCtje zelf, zij het de SSD, ergens gaat toch iets serieus mis).
Edit:
En na tweede scrub is weer alles weg
(zonder clear tussendoor dus)Edit2:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| `--> sudo zpool status -v rpool
pool: rpool
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:03:13 with 0 errors on Mon Aug 14 10:03:05 2023
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
nvme-Samsung_SSD_980_1TB_<knip>-part2 ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
rpool/user/<knip>@pyznap_2023-08-14_09:45:11_frequent:<0x0> |
* zucht *. Dus de status van de scrub die om 10:03 was afgerond was "alles in orde" maar om 10:20 blijkt toch dat alweer iets aan de hand is...
Vanavond dus maar eens rebooten en wellicht even de SSD eruit halen en opnieuw er in zetten. Dit is naar mijn idee te random om daadwerkelijk een issue te zijn.
[ Voor 20% gewijzigd door RobertMe op 14-08-2023 10:23 ]
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Moest even lachen. Want dat had ik zelf inderdaad ook al 'een beetje' geconcludeerd op basis van wat ik had gelezen. 't is meer een soort whishfull thinking dat het wel iets toevoegd
panasonic 5KW L-serie | 300L SWW | 3700+3200 Wp oost-west
:strip_exif()/u/340453/crop67a669ce4f1f4_cropped.webp?f=community)
Op mijn servertje heb ik 32GB geheugen aan ram, waarvan 24GB voor ARC. Opslagruimte is een nvme ssd van 2TB. Ik denk dat in mijn geval L2ARC toevoegen de boel juist zou vertragen. Als ik ergens nog voor een prikkie 2x32GB kan kopen, dan overweeg ik dat te doen, omdat het kan. 
Als snelheid een 'probleem' is in een thuisomgeving, dan is meer geheugen toevoegen in mijn ogen de beste oplossing en niet L2ARC. Zeker met de huidige geheugenprijzen.
Als snelheid een 'probleem' is in een thuisomgeving, dan is meer geheugen toevoegen in mijn ogen de beste oplossing en niet L2ARC. Zeker met de huidige geheugenprijzen.
Daarbij komt ook nog dat het pas echt goed werkt met Enterprise SSD's met een hoge QD=1 prestatie. Consumenten SSD's vinden dit soort workflows helemaal niet leuk.:
[...]
Moest even lachen. Want dat had ik zelf inderdaad ook al 'een beetje' geconcludeerd op basis van wat ik had gelezen. 't is meer een soort whishfull thinking dat het wel iets toevoegd
Sinds de 2 dagen regel reageer ik hier niet meer
Ah, gelukkig heb ik 64GB ramgeheugen geprikt afgelopen weekend. Hoe heb je dat gereserveerd als ARC? *zoekt het even op.:
Op mijn servertje heb ik 32GB geheugen aan ram, waarvan 24GB voor ARC. Opslagruimte is een nvme ssd van 2TB. Ik denk dat in mijn geval L2ARC toevoegen de boel juist zou vertragen. Als ik ergens nog voor een prikkie 2x32GB kan kopen, dan overweeg ik dat te doen, omdat het kan.
Als snelheid een 'probleem' is in een thuisomgeving, dan is meer geheugen toevoegen in mijn ogen de beste oplossing en niet L2ARC. Zeker met de huidige geheugenprijzen.
Ik denk dat snelheid vooral een probleem was, doordat ik op een AMD zacate boardje uit 2011 werkte tot vorige week.
panasonic 5KW L-serie | 300L SWW | 3700+3200 Wp oost-west
Bijv. de product: Intel DC S3710 2,5" of de product: Intel SSD DC S3510. Dan zie je ook direct de prijsverschillen t.o.v. consumenten SSD's
Sinds de 2 dagen regel reageer ik hier niet meer
Die S3510 zijn nog een beetje te betalen zie ik. Maar loopt idd wel lekker op t.o.v. consumentenspul.:
[...]
Bijv. de product: Intel DC S3710 2,5" of de product: Intel SSD DC S3510. Dan zie je ook direct de prijsverschillen t.o.v. consumenten SSD's
panasonic 5KW L-serie | 300L SWW | 3700+3200 Wp oost-west
En dan ook nog MLC? En geen SLC. * RobertMe heeft toentertijd nog een van de eerste semi betaalbare SSDs gekocht, Intel, 120GB, SLC opslag. Vervolgens kwam MLC en was dat toch best wel tricky. Want toch wel wat trager door die 2 bits per cel en slijtage zou er ook hoger door worden (lees: sneller stuk). En toen kwam TLC en weer hetzelfde verhaal. En toen kwam QLC en weer hetzelfde verhaal.:
[...]
Bijv. de product: Intel DC S3710 2,5" of de product: Intel SSD DC S3510. Dan zie je ook direct de prijsverschillen t.o.v. consumenten SSD's
:strip_exif()/u/13821/savale.gif?f=community)
:strip_icc():strip_exif()/u/269054/crop6064049cee9ab_cropped.jpg?f=community)
/u/172597/crop5e1225c8b1011.png?f=community)
No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.
:strip_exif()/u/54579/Static.gif?f=community)
/u/200133/artemis_square_e_60-60.png?f=community)
/u/11437/wandcontactdoos.png?f=community)
Ja, maar niet met Bifurcation, dan heb je een PCIe Switch nodig.
Soms ook wel een PLX Chip genoemd.
Die krengen zijn duur en vreten vaak energie helaas
Soms ook wel een PLX Chip genoemd.
Die krengen zijn duur en vreten vaak energie helaas
[ Voor 22% gewijzigd door FireDrunk op 28-08-2023 12:46 ]
Even niets...
Zonder al teveel details weg te geven wil ik even vermelden dat ik bovenstaande script heb aangepast naar mijn smaak en wensen en het werkt hier ook prima.
Ik zit intussen nog steeds met dit issue
Op een gegeven moment wel uitgesloten dat het niet ligt aan de backup kant, want ook mijn on-side backup naar "de grote bak" triggert dit issue. Nu wel eens de "hack" gedaan met snapshot => snapshot => send --raw -i @1@2 > /tmp/... => rollback -r @1 => zfs receive -F -v ... < /tmp/... (bron). En "leuk" genoeg: de lijst aan snapshots van "mijn" dataset heeft van vandaag allemaal snapshots met "Used: 0B". Behalve die "restored" snapshot (dus de tweede), die is 8K. Dus het lijkt wel alsof daar iets in zit terwijl de daadwerkelijke data dus niet veranderd is (vantevoren is het ook 0B, en na rollback => receive dus 8K).Hopelijk dus dat "het werkt". Moet ik alleen weer wat actiever gaan monitoren. Had nu wel een lijstje met errors maar allemaal met de hex verwijzingen, van intussen dus verwijderde snapshots. Dus dan weet ik niet of de error in "mijn" dataset zat of in een van de andere. Dus weer beetje opletten of "mijn" dataset geen errors (meer) geeft (heb ik wel gezien, dat ook "mijn" dataset de error gaf).
Edit:
Na het destroyen van het snapshot (/beide snapshots) is die 8K used als sneeuw voor de zon verdwenen (uiteraard had ik verwacht dat die in het latere (frequently) snapshot zou belanden).
[ Voor 4% gewijzigd door RobertMe op 05-09-2023 22:43 ]
/u/125951/crop567a86fe6aeb0.png?f=community)
:strip_icc():strip_exif()/u/65843/chef60x60.jpg?f=community)
Ik draai al jaren stabiel een FreeNas/TrueNas server zonder problemen. Een tijdje terug liep deze echter vol, waarna ik de HDD's ben beginnen vervangen door nieuwe (4x4TB -> 4x10TB, met 1 redundante schijf).
Ik heb de disks 1 voor offline gehaald en vervangen, elke keer met een resilver getriggered door de "replace disk" actie in Truenas. Alle disks zijn gechecked voor SMART errors en ok bevonden.
Bij het resilveren van de derde disk liep het echter fout; plots was m'n pool status "degraded". Eerst enkel die disk, dan een 2de en ondertussen alle disks (heb ook de 4de vervangen nadat de vorige resilver voltooid was).
Ik heb wat gegoogled, maar ik vind meer over SMART errors dan echte "degraded" disks. Van wat ik begrijp, zou een resilver moeten helpen. Kan me ook moeilijk voorstellen dat al die disks ineens slecht zijn (zijn NAS geschikte disks, nieuw).
Iemand een idee?
/f/image/roTjPZoMhbsfF5chedVMfyl6.png?f=fotoalbum_large)
:fill(white):strip_exif()/f/image/WHEFEG2vlG5rvhEsmfjtJMHS.png?f=user_large)
Ik heb de disks 1 voor offline gehaald en vervangen, elke keer met een resilver getriggered door de "replace disk" actie in Truenas. Alle disks zijn gechecked voor SMART errors en ok bevonden.
Bij het resilveren van de derde disk liep het echter fout; plots was m'n pool status "degraded". Eerst enkel die disk, dan een 2de en ondertussen alle disks (heb ook de 4de vervangen nadat de vorige resilver voltooid was).
Ik heb wat gegoogled, maar ik vind meer over SMART errors dan echte "degraded" disks. Van wat ik begrijp, zou een resilver moeten helpen. Kan me ook moeilijk voorstellen dat al die disks ineens slecht zijn (zijn NAS geschikte disks, nieuw).
Iemand een idee?
:fill(white):strip_exif()/f/image/roTjPZoMhbsfF5chedVMfyl6.png?f=user_large)
:fill(white):strip_exif()/f/image/wo2mEHm1yf3dCirvRwJnYSIH.png?f=user_large)
TLDR: hieronder een veel te lange post die waarschijnlijk voor niemand interessant is en eigenlijk maar zijdelings iets met ZFS te maken heeft - maar voor het geval er hier toch iemand is die er wat aan heeft (en omdat ik stiekenm wel een beetje trots ben dat ik het werkend gekregen heb) doe ik het toch hier plaatsen. Al zou het beter in een TweakBlog passen...
Naar aanleiding van @RobertMe in:
RobertMe in "Het grote ZFS topic"
...en
RobertMe in "Het grote ZFS topic"
...wilde ik iets vergelijkbaars doen. Ik heb hier een Debian 'stable' Linux server met ZFS & native encryption er op. Enkel heb ik in tegenstelling tot @RobertMe de hele disk (minus de /boot spullen) encrypted, dus zijn oplossing kon ik niet gebruiken.
Ik had destijds al de initrd/initramfs uitgebreid met een dropbear oplossing - iets wat je overal op het internet wel kan terugvinden - zodat ik na een reboot via SSH kon inloggen om het systeem te unlocken. Werkt leuk, maar vereist interactie. Zo had ik onlangs 's-nachts een stroomstoring in de wijk; het systeem gaat automatisch uit en automatisch aan wanneer de spanning weer terugkomt - en staat vervolgens de rest van de nacht te wachten tot ik de boel unlock. Niet gewenst.
Dus, wat was mijn doel: unlock-mogelijkheid via keyboard (standaard), via ssh/dropbear (niet standaard maar ook niet ongebruikelijk) en met een externe key die automagisch via ssh opgehaald wordt. En dat alles in een initramfs ingebouwd.
De externe key heb ik op een Raspberry Pi Zero 2 W en een bijpassende PoE/ETH/USB hat. Verbruikt 2W en hoeft verder niets te doen behalve een wachtwoord te antwoorden. Enkel een ethernet-kabeltje (power-over-ethernet) er aan, verder helemaal niets.
Config van de pi: Was leuk om uit te zoeken en nog leuker om het werkend te krijgen. Debuggen is wel een uitdaging, vooral veel met echo en sleep statements gewerkt. Kan ook zinnig zijn om zo'n initrd file uit te pakken en te inspecteren (unmkinitramfs).
Er zal vast wel het nodige aan te merken zijn op wat ik gemaakt heb, maar wellicht heeft iemand er wat aan.
Naar aanleiding van @RobertMe in:
RobertMe in "Het grote ZFS topic"
...en
RobertMe in "Het grote ZFS topic"
...wilde ik iets vergelijkbaars doen. Ik heb hier een Debian 'stable' Linux server met ZFS & native encryption er op. Enkel heb ik in tegenstelling tot @RobertMe de hele disk (minus de /boot spullen) encrypted, dus zijn oplossing kon ik niet gebruiken.
Ik had destijds al de initrd/initramfs uitgebreid met een dropbear oplossing - iets wat je overal op het internet wel kan terugvinden - zodat ik na een reboot via SSH kon inloggen om het systeem te unlocken. Werkt leuk, maar vereist interactie. Zo had ik onlangs 's-nachts een stroomstoring in de wijk; het systeem gaat automatisch uit en automatisch aan wanneer de spanning weer terugkomt - en staat vervolgens de rest van de nacht te wachten tot ik de boel unlock. Niet gewenst.
Dus, wat was mijn doel: unlock-mogelijkheid via keyboard (standaard), via ssh/dropbear (niet standaard maar ook niet ongebruikelijk) en met een externe key die automagisch via ssh opgehaald wordt. En dat alles in een initramfs ingebouwd.
De externe key heb ik op een Raspberry Pi Zero 2 W en een bijpassende PoE/ETH/USB hat. Verbruikt 2W en hoeft verder niets te doen behalve een wachtwoord te antwoorden. Enkel een ethernet-kabeltje (power-over-ethernet) er aan, verder helemaal niets.
Config van de pi:
- standaard raspberry pi OS er op, want met een Debian install kreeg ik de ethernet poort niet goed werkend.
- Behalve een eigen login-user heb ik ook een user "key_owner" aangemaakt. In de home-dir van die user heb ik een file "unlock_key.txt" met daarin het ZFS unlock password.
- Vervolgens een SSH public/private keypair aangemaakt (ssh-keygen) en de public key gebruikt om een .ssh/authorized_keys te maken:
code:1
command="cat unlock_key.txt" ssh-rsa AAAAB4NzaC1Yc2EA...bdydCC9TOQE0= key_owner@rpi3-20230612
- Let op het eerste stukje van die regel: het command zorgt er voor dat iemand die met ssh als key_owner inlogt (en daarvoor de private key gebruikt) dus geen command prompt krijgt, maar direct het unlock-password ontvangt.
- Vervolgens overlay filesystem aangezet zodat er geen writes naar de SD-kaart meer plaats vinden. Handig, want als er dan een stroomstoring optreedt vind er geen corruptie plaats.
- file toegevoegd: /etc/initramfs-tools/key_owner.id_rsa. Niet heel spannend, de private key behorende bij de key_owner user van de Raspberry Pi. File protections op 400.
- file toegevoegd: /etc/initramfs-tools/conf.d/fetch_remote.conf. Inhoud:
code:1 2 3
SERVER=192.168.1.6 USER=key_owner KEY=/etc/key_owner.id_rsa
...spreekt denk ik voor zich. IP adres van de Raspberry, de ssh username om mee in te loggen en de locatie van de private key. Let op: dat is de locatie binnen de initramfs, dus NIET de locatie op het systeem zelf (die staat al bij de vorige bullet). - file toegevoegd: /etc/initramfs-tools/hooks/fetch_remote_key. Deze file (of eigenlijk al die hook scripts) wordt uitgevoerd bij het aanmaken/updaten van initramfs, dus dit beinvloed wat er in de initramfs komt. Inhoud:
Het grootste deel is de standaard template; het meest interessante stuk is het kopieeren van spullen: De eerder genoemde private key (en voor de zekerheid de protections weer op 400), een 'fetch_remote_loop.sh' script die verderop nodig is en wat executables/configs die niet standaard in de initramfs zitten.
- file toegevoegd: /etc/initramfs-tools/scripts/init-premount/fetch_remote.sh. Dit script wordt uitgevoerd tijdens het opstarten, voordat het filesysteem unlocked nodig is. Ongeveer gelijk met dropbear. Inhoud:
Ook hier, het eerste stuk is wat standaard template. Daarna bovengenoemde config uitvoeren zodat wat variabelen gedefinieerd zijn en middels een 'nohup' het feitelijke key-ophaal-script starten. De PID van dat script wordt vervolgens opgeslagen in /run/fetch_remote.pid. Ik twijfel nu even of de nohup wel echt nodig is - maar kwaad zal het niet kunnen. Wellicht dat dit script ook in nfs-premount zou kunnen, volgens de documentatie wordt 'ie dan pas uitgevoerd wanneer het netwerk klaar is - maar maakt niet echt uit doordat het systeem hier blijft proberen de key op te halen tot het gelukt is.
- file toegevoegd: /etc/initramfs-tools/scripts/fetch_remote_loop.sh. Was wellicht een meer elegante plek voor te bedenken. Inhoud:
Ook hier weer wat copy/paste van de dropbear scripts, dus niet alles snap ik helemaal, maar goed: om de vijf secondes via ssh proberen de sleutel op te halen en als dat lukt het filesystem unlocken. Meeste werk zat nog in het ssh commando zelf: de 'QUIET' optie zorgt er voor dat je echt enkel het wachtwoord ontvangt en geen meldingen over afgesloten verbindingen enzo. En ook: StrictHostKeyChecking=no, want anders wil het systeem aan je vragen of de onbekende raspberry pi wel OK is om mee te verbinden (en kan dat niet, want geen tty of zo). Zie dit topic voor de achtergrond.
- file toegevoegd: /etc/initramfs-tools/scripts/init-bottom/fetch_remote.sh. Deze wordt uitgevoerd als het filesystem unlocked is en zorgt er voor dat het fetch_remote_loop.sh process hierboven wordt afgeschoten en niet eeuwig door blijft lopen. Inhoud:
Ook hier weer heel veel copy/paste van het dropbear script. Waarbij ik niet echt een goed idee heb hoe dit alles werkt - behalve de PID ophalen van het loop-script hierboven en daar een kill op doen.
- En dat is het wel zo'n beetje. Vervolgens 'update-initramfs -u' en dan is het klaar.
Was leuk om uit te zoeken en nog leuker om het werkend te krijgen. Debuggen is wel een uitdaging, vooral veel met echo en sleep statements gewerkt. Kan ook zinnig zijn om zo'n initrd file uit te pakken en te inspecteren (unmkinitramfs).Er zal vast wel het nodige aan te merken zijn op wat ik gemaakt heb, maar wellicht heeft iemand er wat aan.
Knap staaltje werk!:
TLDR: hieronder een veel te lange post die waarschijnlijk voor niemand interessant is en eigenlijk maar zijdelings iets met ZFS te maken heeft - maar voor het geval er hier toch iemand is die er wat aan heeft (en omdat ik stiekenm wel een beetje trots ben dat ik het werkend gekregen heb) doe ik het toch hier plaatsen. Al zou het beter in een TweakBlog passen...
Naar aanleiding van @RobertMe in:
RobertMe in "Het grote ZFS topic"
...en
RobertMe in "Het grote ZFS topic"
...wilde ik iets vergelijkbaars doen. Ik heb hier een Debian 'stable' Linux server met ZFS & native encryption er op. Enkel heb ik in tegenstelling tot @RobertMe de hele disk (minus de /boot spullen) encrypted, dus zijn oplossing kon ik niet gebruiken.
Ik had destijds al de initrd/initramfs uitgebreid met een dropbear oplossing - iets wat je overal op het internet wel kan terugvinden - zodat ik na een reboot via SSH kon inloggen om het systeem te unlocken. Werkt leuk, maar vereist interactie. Zo had ik onlangs 's-nachts een stroomstoring in de wijk; het systeem gaat automatisch uit en automatisch aan wanneer de spanning weer terugkomt - en staat vervolgens de rest van de nacht te wachten tot ik de boel unlock. Niet gewenst.
Dus, wat was mijn doel: unlock-mogelijkheid via keyboard (standaard), via ssh/dropbear (niet standaard maar ook niet ongebruikelijk) en met een externe key die automagisch via ssh opgehaald wordt. En dat alles in een initramfs ingebouwd.
De externe key heb ik op een Raspberry Pi Zero 2 W en een bijpassende PoE/ETH/USB hat. Verbruikt 2W en hoeft verder niets te doen behalve een wachtwoord te antwoorden. Enkel een ethernet-kabeltje (power-over-ethernet) er aan, verder helemaal niets.
Config van de pi:Dan het lastigere stuk: de initramfs aanpassing. Dat heb ik grotendeels gebaseerd op wat dropbear ook doet - ik heb dus flink wat copy/paste toegepast. Je kan veel leren en afkijken van wat er in /usr/share/initramfs-tools staat - en vervolgens je eigen aanpassingen doen in /etc/initramfs-tools. Ook de man-page bekijken helpt wel wat. Wat ik dus heb gedaan:
- standaard raspberry pi OS er op, want met een Debian install kreeg ik de ethernet poort niet goed werkend.
- Behalve een eigen login-user heb ik ook een user "key_owner" aangemaakt. In de home-dir van die user heb ik een file "unlock_key.txt" met daarin het ZFS unlock password.
- Vervolgens een SSH public/private keypair aangemaakt (ssh-keygen) en de public key gebruikt om een .ssh/authorized_keys te maken:
code:
- Let op het eerste stukje van die regel: het command zorgt er voor dat iemand die met ssh als key_owner inlogt (en daarvoor de private key gebruikt) dus geen command prompt krijgt, maar direct het unlock-password ontvangt.
- Vervolgens overlay filesystem aangezet zodat er geen writes naar de SD-kaart meer plaats vinden. Handig, want als er dan een stroomstoring optreedt vind er geen corruptie plaats.
En: dat werkt. En ook via dropbear/ssh inloggen werkt nog.
- file toegevoegd: /etc/initramfs-tools/key_owner.id_rsa. Niet heel spannend, de private key behorende bij de key_owner user van de Raspberry Pi. File protections op 400.
- file toegevoegd: /etc/initramfs-tools/conf.d/fetch_remote.conf. Inhoud:
code:
...spreekt denk ik voor zich. IP adres van de Raspberry, de ssh username om mee in te loggen en de locatie van de private key. Let op: dat is de locatie binnen de initramfs, dus NIET de locatie op het systeem zelf (die staat al bij de vorige bullet).- file toegevoegd: /etc/initramfs-tools/hooks/fetch_remote_key. Deze file (of eigenlijk al die hook scripts) wordt uitgevoerd bij het aanmaken/updaten van initramfs, dus dit beinvloed wat er in de initramfs komt. Inhoud:
[...]
Het grootste deel is de standaard template; het meest interessante stuk is het kopieeren van spullen: De eerder genoemde private key (en voor de zekerheid de protections weer op 400), een 'fetch_remote_loop.sh' script die verderop nodig is en wat executables/configs die niet standaard in de initramfs zitten.- file toegevoegd: /etc/initramfs-tools/scripts/init-premount/fetch_remote.sh. Dit script wordt uitgevoerd tijdens het opstarten, voordat het filesysteem unlocked nodig is. Ongeveer gelijk met dropbear. Inhoud:
[...]
Ook hier, het eerste stuk is wat standaard template. Daarna bovengenoemde config uitvoeren zodat wat variabelen gedefinieerd zijn en middels een 'nohup' het feitelijke key-ophaal-script starten. De PID van dat script wordt vervolgens opgeslagen in /run/fetch_remote.pid. Ik twijfel nu even of de nohup wel echt nodig is - maar kwaad zal het niet kunnen. Wellicht dat dit script ook in nfs-premount zou kunnen, volgens de documentatie wordt 'ie dan pas uitgevoerd wanneer het netwerk klaar is - maar maakt niet echt uit doordat het systeem hier blijft proberen de key op te halen tot het gelukt is.- file toegevoegd: /etc/initramfs-tools/scripts/fetch_remote_loop.sh. Was wellicht een meer elegante plek voor te bedenken. Inhoud:
[...]
Ook hier weer wat copy/paste van de dropbear scripts, dus niet alles snap ik helemaal, maar goed: om de vijf secondes via ssh proberen de sleutel op te halen en als dat lukt het filesystem unlocken. Meeste werk zat nog in het ssh commando zelf: de 'QUIET' optie zorgt er voor dat je echt enkel het wachtwoord ontvangt en geen meldingen over afgesloten verbindingen enzo. En ook: StrictHostKeyChecking=no, want anders wil het systeem aan je vragen of de onbekende raspberry pi wel OK is om mee te verbinden (en kan dat niet, want geen tty of zo). Zie dit topic voor de achtergrond.- file toegevoegd: /etc/initramfs-tools/scripts/init-bottom/fetch_remote.sh. Deze wordt uitgevoerd als het filesystem unlocked is en zorgt er voor dat het fetch_remote_loop.sh process hierboven wordt afgeschoten en niet eeuwig door blijft lopen. Inhoud:
[...]
Ook hier weer heel veel copy/paste van het dropbear script. Waarbij ik niet echt een goed idee heb hoe dit alles werkt - behalve de PID ophalen van het loop-script hierboven en daar een kill op doen.- En dat is het wel zo'n beetje. Vervolgens 'update-initramfs -u' en dan is het klaar.
Er zal vast wel het nodige aan te merken zijn op wat ik gemaakt heb, maar wellicht heeft iemand er wat aan.
Heb je ook nog overwogen om de ZFS key encrypted op de Pi te zetten, met het unlock password op de server? Persoonlijk heb ik daarvoor gekozen omdat in mijn geval de "ZFS key host" (router) ook weer gebackupd wordt en het systeem altijd aan staat en kinda leesbaar is. Als for whatever reason de key files uitlekken heeft de "ontvanger" er nog steeds niks aan doordat die de encrypted key file niet kan lezen.
En het password voor de file te decrypten staat dan op de /boot partitie die (uiteraard) niet gebackupd wordt.
Bij diefstal van de server ontbreekt dus toegang tot de encrypted key (file) die op de router staat. En bij diefstal van de backup ontbreekt het password om de encrypted file te openen.
Dank!
Ik heb er wel kort over nagedacht (en sluit niet uit zo iets nog te gaan doen), maar kon voor mijzelf nog geen goede reden verzinnen waarom het nodig zou zijn.
Het unlock password staat plain-text op de Pi en dat voelde wel wat ongemakkelijk - maar als bij diefstal de Pi gestolen wordt heb je er niets aan zonder de server (en andersom), je hebt ze beide nodig. De server wordt gebackupped, maar enkel wat user-data gaat (encrypted) naar een externe backup. Het systeem zelf wordt 100% gebackupped maar enkel naar een lokale machine, dus de toegangsinformatie om bij de Pi te komen is enkel lokaal aanwezig.
Dus, wat is dan de mogelijkheid voor een inbreker om aan het unlock-password te komen: de Pi stelen, of op een of andere manier inbreken op m'n netwerk (en dan root-toegang op de Pi te krijgen). Allemaal behoorlijk onwaarschijnlijke scenario's, dus zag ik geen reden om het password encrypted op de Pi te zetten.
Maar goed, het is denk ik niet ingewikkeld om erbij te doen. De basis ligt er en werkt.
:strip_icc():strip_exif()/u/38800/i_m_weasel-char.jpg?f=community)
/u/342733/wtd_s.png?f=community)
:strip_exif()/u/1054665/crop5be31086906cf_cropped.gif?f=community)