Kategorie: FreeBSD

How to remove ZIL (log device) from pool

Ich habe mich entschieden gehabt, von meinen beiden Pools, einem raid1 und einem raid5 die ZIL-devices (zfs intention log; „write cache“) zu entfernen. Im internet war nur zu finden, daß dies auf einen Fehler hinausläuft und nicht möglich sei.
Jetzt stand bei mir das FreeBSD upgrade von 12 auf 13 an. Das FB12 wurde heruntergefahren, die System-SSD von 512 auf 1000GB upgegraded und auf die Neue das aktuelle FreeBSD 13R installiert.
Logischerweise lief der zpool import der raid-pools in Fehler, auch ein zpool import -f <pool> schlug fehl. Es bestand aber die Möglichkeit mit einem zpool import -fm den pool zu importieren, mit zpool status sich das fehlende device mit ID anzeigen zu lassen und danach mit dem zpool remove <ID> <pool> das zil-device zu entfernen. Das scheint zu funktionieren. Glücklicherweise waren die partition-IDs, welche verwendet wurden, viel höher als die existenten…

Beim neuen openZFS kann man ohne größeren Umstände das entsprechende zil-device einfach löschen!

I have decided to eliminate my ZIL-device from my zpools, one raid1 and one raid5, implemented with ZIL-devices (zfs intention log, „write cache“). In internet I only found comments, that this is not possible.
Now, these days, I upgraded my home server from FreeBSD 12 to FreeBSD 13. The FreeBSD12 was shutdown, I have exchanged the boot-system-disk and I have installed the new FreeBSD 13 on the new disk.
Rebooting in the new system, the import of the old raid-pools fails. Also, importing with zpool -f also fails, due of „missing devices“. It was possible to import them with zpool import -fm <pool>. With zpool status you get the IDs of the missing devices and with zpool remove <pool> <ID> you can remove now the missing ZIL-devices.
Be patient, that there are no available partitions configured on the system disks, in my case, the partition numbers are higher than they are available (the device name nvd0 didn’t changed).

With the new openZFS it is possible to delete the zil-device!

bonnie++ performance Disk IO-Werte unter FreeBSD mit zfs

Hier mal ein paar performance Messungen unter FreeBSD. Messungen sind ja alle sehr relativ, der eine mag das Andere, ich mag bonnie.
Die Messungen fanden statt auf einem i5-6600, 32GB Ram und FreeBSD 12.2, bonnie++1,98. Filesystem ist ZFS. Der Cache ist 29GB groß, das ZIL 1GB.

Samsung SSD 950 PRO 512GB

bonnie benchmark Samsung SSD 950Pro
Die 950PRO dient auch als cache und ZILs für einen Raid1 und einen Raid5-zpool

Die 950 Pro wurde abgelöst – durch eine SanDisk Extreme Pro 1TB. Sie dürfte baugleich mit der WD Black Series sein, WD kaufte SanDisk vor längerem.
Die performance Messungen fanden unter FreeBSD 13-Release statt.

SanDisk Extreme Pro 1TB

SanDisk Extreme Pro 1TB mit cache für zRaid unter FreeBSD 13.R

Raid1 mit 2x Seagate Barracuda 4TB

Bei der initialen Erstellung meines Raid1 bestehend aus 2 Seagate 4TB Festplatten des Typs ST4000DM004 hatte ich einfach den zpool create mit den raw-devices verwendet – und damit das sector 63 Problem:

2x4GB false sec63
raid1 mit cache und log (L2ARC - 29GB, logs 1GB beides auf nvme)
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1        64G  287k  99 10.4m   1 8373k   1  720k  99  2.7g  99 200.0   4
Latency             29770us      437s      430s   14303us     391us     859ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 165.746758   0 +++++ +++ +++++ +++ 566.048702   1
Latency             28743us      41us   54405ms    1516us      20us    5952ms

Dann habe ich das sector 63 Problem behoben:

gpart show ada3
=>        40  7814037088  ada3  GPT  (3.6T)
          40        2008        - free -  (1.0M)
        2048  7814033408     1  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

gpart show ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40        2008        - free -  (1.0M)
        2048  7814033408     1  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

Danach interessiert man sich dafür, wofür man sich die Arbeit gemacht hat und macht mal ein paar performance Messungen, angefangen mit einer Single-disk, über Zuschaltung von cache und zuletzt dem ZIL (log):

single disk, mit zfs 
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-single 64G  306k  98  105m   7 30.1m   2  727k  98  179m   6 145.7   1
Latency             28417us   38531us    1541ms   45365us     173ms     478ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-single     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4154.577626   8 +++++ +++ +++++ +++ 3948.968091   7
Latency              1598us      36us     967ms    1535us      24us     468ms


raid1 - "naggisch"
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1        64G  299k  97 76.8m   6 40.8m   3  702k  96  232m   8 220.6   2
Latency             28550us   38345us     861ms   68444us     175ms     325ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4145.272690   8 +++++ +++ +++++ +++ 3683.089828   7
Latency              1502us      30us     899ms    1463us      83us     441ms


raid1 mit cache (L2ARC - auf 29GB nvme)
[root@alpina /raid1]# bonnie++ -r 32768 -m alpinaR1_cache -u root
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1_cache  64G  230k  89 68.9m   5 39.8m   3  720k  99  235m   8 241.0   3
Latency             33220us    7303ms     623ms   29652us     269ms     341ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1_cache      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 2690.164896   5 +++++ +++ +++++ +++ 4142.792682   8
Latency              1511us      37us    2925ms    1473us      25us     558ms


raid1 mit cache und log (L2ARC - 29GB, logs 1GB beides auf nvme)
[root@alpina /raid1]# bonnie++ -r 32768 -m alpinaR1_cache_log -u root
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1_cache_ 64G  258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1_cache_log  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.157708   7
Latency              1560us      36us    1601ms    1470us      26us     580ms

und hier nochmal das listing im direkten Vergleich:

single disk, mit zfs im Vergleich zur Raid1 config
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-single 64G  306k  98  105m   7 30.1m   2  727k  98  179m   6 145.7   1
Latency             28417us   38531us    1541ms   45365us     173ms     478ms
alpinaR1_cache_log   258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms

Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-single     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4154.577626   8 +++++ +++ +++++ +++ 3948.9680 7
Latency              1598us      36us     967ms    1535us      24us     468ms
alpinaR1_cache_log   /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.1577 7
Latency              1560us      36us    1601ms    1470us      26us     580ms



2x4GB Raid1 mit false sec63 im Vergleich zur "bereinigten" config:

Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-sec63       287k  99 10.4m   1 8373k   1  720k  99  2.7g  99 200.0   4
Latency             29770us      437s      430s   14303us     391us     859ms
alpinaR1_new         258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms

Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-sec63      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 165.746758   0 +++++ +++ +++++ +++ 566.048702 1
Latency             28743us      41us   54405ms    1516us      20us    5952ms
alpinaR1_new         /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.1577 7
Latency              1560us      36us    1601ms    1470us      26us     580ms

Interessant empfinde ich, daß ein Spiegel unter dem Strich erkennbar schlechtere Werte liefern kann, als die Single-disk – ausgenommen beim seq-output rewrite und seq-input-block.
Ansonsten ist der Vergleich zwischen alter RAID1 und neuer ganz passabel – man sieht deutlich schlechtere Werte in der alten RAID1-config:
seq. output Block 10MB/s zu 78MB/s,
rewrite 8k3 zu 46m,
seq Input Block 2.7g zu 229m??? ein schlechterer Wert dafür mit wesentlich weniger Last
random seeks
und allgemein weniger CPU-Last… und vor allem sieht man wesentlich geringere Latenzen -> hat sich also meiner Meinung nach gelohnt, also wird irgendwann später das Raid5 auch umgestellt!

Raid5 mit 4x Seagate IronWolf 6TB

Leider hatte ich auch bei der initialen Erstellung meines raidz1 Volumes (Raid5) aus 4x 6TB Festplatten (Seagate Ironwolf 5400rpm, ST6000VN001) nicht GPT zur Partitionierung verwendet, sondern die raw-devices direkt mit zpool angesprochen. Jetzt habe ich die Umstellung vorgenommen und vorher wie nachher bonnie++ Messungen vorgenommen (zpool in allen Fällen mit gleichen Daten gefüllt zu etwa 80%):

Benchmarking mit sector63 Fehler, mit cache, mit ZIL
Benchmarking raidz1 ohne cache ohne ZIL
Benchmarking raidz1 mit cache ohne ZIL
Benchmarking raidz1 mit cache mit ZIL

Signifikanteste Verbesserungen mit korrektem Blockalignment sieht man beim sequential Output: 244 zu 311MB/s, beim rewrite von 116 zu 169MB/s, beim sequential Input Block von 296 zu 502MB/s – interessanterweise hierbei überall mit mehr CPU-Last zu vorher (meine Theorie: Daten kommen logisch sauberer im alignment auf die Platte und somit sind schneller die Parity-Berechnungen erforderlich).
Random seeks haben sich verbessert von ~138/sec zu ~173/sec.
Weitere Verbesserungen zu sehen beim sequential create die Latenz hat sich von ~12,800µs auf ~1450µs verbessert und beim Random Create von 178ms zu ~1500µs.

Das sind so die signifikantesten Verbesserungen des RAID5 Stapels, welche sich beim benchmarking zeigen. Ich unterstelle, daß ich in der Praxis bestimmt nicht soviel merken werde. Mit der Umstellung ist aber ein mögliches Bottleneck beseitigt.

Die Werte mit ZIL als Verbesserung erachte ich als vernachlässigbar, in Relation zu der damit einhergehenden Gefahr eines Total-filesystem-Verlustes mit dem Hops-gehen eines ZILs. Dafür macht man kein RAID5, um Datenverlusten vorzubeugen. Also wird beim nächsten Umbau der Systemplatte der ZIL verschwinden.

FreeBSD, ZFS und dedup

Ein paar dedup-Erfahrungen möchte ich hier mitteilen…

Dedup ist ein feature im zfs, welches Daten auf Blocklevel-Ebene dedupliziert. Wird also eine Datei zweimal in zfs-Volume kopiert, wird sie nur einmal ihren Speicherplatz beanspruchen. Aktuell habe ich in meinem Serverchen 2 zpools, einen Raid1-basierten (2x4TB) mit aktiviertem dedup und einen mit Raid5 (4x6TB).
Da dedup sehr viel memory für die Verwaltung benötigt (die sogenannten ddt-tables), wurde auf einer nvme für jeden zpool neben einem 1GB großes ZIL (zfs intent log; Pufferung von metadaten im synchronen IO) ein 29GB großer cache für den L2ARC (hier werden die ddt-Tabellen verwaltet).

[maulwurf@alpina ~]$ zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
WD14TB    12.7T  10.5T  2.24T        -         -    12%    82%  1.11x  ONLINE  -
archiv    21.8T  16.8T  5.01T        -         -    24%    77%  1.14x  ONLINE  -
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.45T   180G        -         -    47%    95%  1.17x  ONLINE  -
root       382G   257G   125G        -         -    40%    67%  1.03x  ONLINE  -

Im zpool raid1 liegt ein zfs Volume „backup“, in welches regelmäßig eine WordPress-Seite gesichert wird, sowie eines für Musik-Dateien…
Im zpool archiv befindet sich ein Time Machine-Volume (zusätzlich ein Archiv für große files), auf welches 2 High-Sierra Systeme sowie 2 Big Sur Systeme (macOS) Installationen gesichert werden.
Die Idee ist einfach: Da fallen einige „Dubletten“ an, welche hervorragend dedupliziert werden können… leider gibt aber die zpool-Statistik nur Infos aus, welche den pool als Ganzes betreffen. Im Zuge einer Optimierung der zpool device Verwaltung, muss der zpool archiv noch neu eingerichtet werden.
Für die Reorganisierung wurde eine externe Backup-Festplatte mit 14TB angeschafft, das Kopieren des zfs mit den Backupdaten (9TB/~27,000 files) via zfs send/receive geschah recht zügig mit rund 150MB/s. Danach erfolgte das gleiche Verfahren mit dem Time Machine-Volume (3.75TB/~190,000 files), welches eine Woche brauchte, anfänglich mit rund 30MB/s, letztlich bei knapp 7.6MB/s im Schnitt landete für transferierte 4.14TB (Ausgabe vom Transfer mit -v Option). Was mich verwundert, warum ~400GB mehr transferiert wurden, als vom Urpsrungsvolume angegeben wurden – die Verwunderung wird dann vom Ärger verdrängt, wenn man feststellen darf, daß beim Ziel-zpool keine compression aktiviert war…
Nunja, die Backup-Platte hat keinen L2ARC-cache, was ich als mögliche Ursache für den langsamen Transfer sehe (hat sich beim Wiederherstellen mehr oder minder bestätigt)…
Der Restore war wesentlich erfreulicher, hat er das DatenVolume beim Backup noch um rund 400GB erhöht, behielt der Prozess es diesmal bei und die Datentransferrate lag bei beachtlichen 63MB/s für das dedup-Volume.
Jetzt kommt die Frage, hat der L2ARC cache ausgereicht?, hierzu ist folgende Ausgabe als Ergebnis interessant, beim monitoring hat man die Nutzung prima verfolgen können:

maulwurf@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       4.93T  16.9T    177  2.77K  5.32M  72.4M
  raidz1    4.93T  16.9T    177  2.77K  5.32M  72.4M
    ada0p1      -      -    46    532  1.30M  26.3M
    ada1p1      -      -     43    531  1.28M  25.7M
    ada2p1      -      -     43    531  1.44M  26.3M
    ada4p1      -      -     44    532  1.42M  25.6M
  nvd0p6     128K   960M      0      0      1  24.9K
cache           -      -      -      -      -      -
  nvd0p7    19.5G  9.52G    504     41  1.20M  3.09M
----------  -----  -----  -----  -----  -----  -----

von den zur Verfügung stehenden 29GB (L2ARC cache) werden in etwa 2/3 genutzt, für dieses Volume also ausreichend (?)- der ZIL wird fast gar nicht verwendet (mehr oder minder logisch)…
Jetzt kopier ich noch das rund 300GB große Backup-Volume vom raid1 pool in den raid5 – 

11:08:51    303G   raid1/backup@backup
received 303GB stream in 5217 seconds (59.5MB/sec)
[root@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       5.31T  16.5T    176  2.76K  5.02M  71.2M
  raidz1    5.31T  16.5T    176  2.76K  5.02M  71.2M
    ada0p1      -      -     46    532  1.22M  25.9M
    ada1p1      -      -     43    531  1.21M  25.2M
    ada2p1      -      -     43    531  1.35M  25.9M
    ada4p1      -      -     44    532  1.33M  25.2M
  nvd0p6     256K   960M      0      0      1  48.2K
cache           -      -      -      -      -      -
  nvd0p7    18.6G  10.4G    515     41  1.22M  3.05M
----------  -----  -----  -----  -----  -----  -----

Man sieht hier sogar noch eine Abnahme der cache (L2ARC) Nutzung.

Interessant zur Berechnung benötigter Ressourcen ist der Artikel „dedup or not dedup„, in welchem auch beschrieben wird, wieviel voraussichtlich an ARC-Speicher benötigt wird, in meinem hier betrachteten Falle (vor Umstellung):

[root@alpina ~]# zdb -b raid1 

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
3.87T completed (3323MB/s) estimated time remaining: 277098hr 45min 20sec        
	No leaks (block sum matches space maps exactly)

	bp count:              35419785
	ganged count:                 0
	bp logical:       4477203583488      avg: 126404
	bp physical:      4252535812096      avg: 120061     compression:   1.05
	bp allocated:     4270123028480      avg: 120557     compression:   1.05
	bp deduped:        463651233792    ref>1: 1992696   deduplication:   1.11
	Normal class:     3806470971392     used: 95.50%

	additional, non-pointer bps of type 0:     132437
	Dittoed blocks on same vdev: 1466474

[root@alpina ~]# zdb -b archiv

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
17.5T completed (14304MB/s) estimated time remaining: 341616hr 56min 05sec        
	No leaks (block sum matches space maps exactly)

	bp count:             111509014
	ganged count:                 0
	bp logical:      14381112954368      avg: 128968
	bp physical:     13922814364672      avg: 124858     compression:   1.03
	bp allocated:    19192156401664      avg: 172113     compression:   0.75
	bp deduped:        710846349312    ref>1: 3355041   deduplication:   1.04
	Normal class:    18481309908992     used: 77.06%

	additional, non-pointer bps of type 0:     197376
	Dittoed blocks on same vdev: 1664068

Rechnet man den Speicherbedarf für den pool raid1 aus (bp count: 35419785 x 320bytes), kommt man auf ~10GB; bei knapp 32GB Ram und der Kausalität, daß für dedup nur ca 25% vom ARC genutzt werden, ist der Hauptspeicher definitiv zu klein.
Der pool archiv mit seinem Time Machine-Volume würde um die 33GB beanspruchen wollen.

Somit habe ich mittlerweile den Entschluss gefasst, auf dem RAID1 keine Deduplikation mehr zu verwenden und das backup-zfs auf das archiv umzuziehen, sowie den L2ARC für archiv auf 96GB zu erweitern.

Das „Ende“ aktuell vom Lied:

[maulwurf@alpina ~]# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.19T   443G        -         -    41%    88%  1.19x  ONLINE  -
raid5     21.8T  17.2T  4.60T        -         -     6%    78%  1.16x  ONLINE  -
root       382G   259G   123G        -         -    41%    67%  1.03x  ONLINE  -

References:
zfs dedup or not dedup
zfs, arc overview
memory requirements dedup/L2ARC

FreeBSD 12 und apache im jail

echo "a.b.c.d  wwwhost.guckux.test wwwhost" >> /etc/hosts
iocage create -r 12.1-RELEASE -n www ip4_addr="em0|192.168.178.44"

Erzeugen eines host-Eintrages für den jail.
Erstellen eines jails mit FreeBSD 12.1-RELEASE, mit dem jail-Namen „www“ und einer IP-Adresse gehörig zum interface em0.

iocage start www

Starten des jails „www“.

iocage pkg www install apache24
alternativ:
iocage console www
pkg install apache24
echo "apache24_enable="YES"" >> /etc/rc.conf

Hiermit installieren wir mit dem package tool das apache environment in der iocage „www“.
Alternativ kann man das im jail selbst tun, ich bevorzuge die Installation vom „Hypervisor“ System selbst, da dann Pakete zB für andere jails nicht wiederholt geholt werden (ausser es gibt aktuellere 😀 ). Aktuell bei mir allerdings, wird die Anzeige, zur Bestätigung, ob man die Pakete installieren möchte, nicht angezeigt – heisst blind „Y“ tippen und Enter 😉
Dann muss er noch enabled werden, damit er startet, wenn man den jail startet.

Dann machen wir es gleich richtig machen und wollen das mit SSL konfigurieren:

iocage console www
mkdir /etc/ssl/private
mkdir /etc/ssl/certs
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/selfsigned.key -out /etc/ssl/certs/selfsigned.crt

Die Verzeichnisse gibt es noch nicht, werden aber benötigt – danach generieren wir den key und werden nach verschiedenen Parameter gefragt:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Hessen
Locality Name (eg, city) []:Gross-Gerau
Organization Name (eg, company) [Internet Widgits Pty Ltd]:guckux.de
Organizational Unit Name (eg, section) []:testing
Common Name (e.g. server FQDN or YOUR name) []:wwwhost.guckux.test
vi /usr/local/etc/apache24/httpd.conf
und
LoadModule ssl_module libexec/apache24/mod_ssl.so
LoadModule authn_socache_module libexec/apache24/mod_authn_socache.so
LoadModule ssl_module libexec/apache24/mod_ssl.so
Include etc/apache24/extra/httpd-ssl.conf

Die LoadModule einkommentieren (aktivieren) und das ssl aktivieren.

Wir erstellen eine Sicherheitskopie von der ssl Konfiguration und bearbeiten unsere config:

cp /usr/local/etc/apache24/extra/httpd-ssl.conf \ /usr/local/etc/apache24/extra/httpd-ssl.conf.bak
vi /usr/local/etc/apache24/extra/httpd-ssl.conf
# General setup for the virtual host
DocumentRoot "/usr/local/www/apache24/data"
ServerName wwwhost.guckux.test:443
ServerAdmin user@host
ErrorLog "/var/log/httpd-error.log"
TransferLog "/var/log/httpd-access.log"
ServerName wwwhost.guckux.test:443
ServerAdmin user@host
SSLCertificateFile "/etc/ssl/certs/selfsigned.crt"
SSLCertificateKeyFile "/etc/ssl/private/selfsigned.key"
SSLStaplingCache "shmcb:/var/run/ssl_stapling(32768)"
SSLSessionCache         "dbm:/var/run/ssl_scache"
und die Änderungen im https-ssl.conf vornehmen.

Wenn ich nichts vergessen habe - sollte es das gewesen sein ;)

FreeBSD – zfs Konfiguration

der home-Server hat folgende Funktionalitäten:

  • Fileserver
  • Backup-Server (mit LTO-3 SCSI)
  • Austausch-Verzeichnis
  • Bilderverwaltung (digikam mit MariaDB)
  • Icinga – monitoring

Die zfs-konfiguration liefert stabile 100MB/s über das GigaBit-Netz lesend und schreibend.
Die Konfiguration ist folgendermaßen:
– M.2 NVME (SSD) für Betriebssystem, L2ARC und ZIL
– 2x 4TB RAID1 – mirroring für wichtiges
– 4x 3TB RAID5 – für Archiv-Kram

Das Betriebssystem wurde auf der NVME installiert, und mit gpart zusätzlich je 2 partitionen für das ZIL (1GB) und L2ARC (29GB) angelegt (einmal für das RAID1 und einmal für das RAID5).

Normalerweise gewinnt zfs an Performance, wenn man viele vdevs anlegt, nunja, soviel Platten habe ich nicht, respektive meine Zielkonfiguration ist hier ein „Kompromiss“.
Standardmäßig aktiviere ich die lz4 Kompression für die zpools und deren zfs-partitionen.
Für das Foto-Archiv, welches noch um Dubletten bereinigt werden muss, ist auch das DeDup aktiviert, das frisst aber Ressourcen! Aktuell ist das „nur“ Faktor 1.37.

zpool create family mirror ada5 ada4  (Erzeugung des RAID1)
zfs set compression=lz4 family        (lz4 Kompression aktivieren)
zpool add family log nvd0p5           (ZIL hinzufügen von nvme)
zpool add family cache nvd0p6         (L2ARC hinzufügen)

zpool create archiv raidz /dev/ada0 /dev/ada1 /dev/ada2 /dev/ada4
zpool add -f archiv log nvd0p6
zpool add archiv cache nvd0p7

auf weitere partitionserstellungen gehe ich jetzt nicht ein 🙂
Gemountet werden die zpools selbst nicht, nur die erzeugten partitionen, alle unter /data/, damit etwas Struktur drinnen ist…
Ich bevorzuge mehrere Partitionen, dies ermöglicht auch die Backups etwas einfacher zu strukturieren. 10TB auf Band sichern ist etwas stressig.

HomeServer

Vor 3 Jahren löste ich meinen home-Server in einem riesigem „Eye-Tower 920“ ab – es musste etwas Neues her, wesentlich leiser und stromsparender.

Meine Komponenten:

Coolmaster Silencio 550 Gehäuse
be quiet! STRAIGHT POWER10 400W ATX24
GigaByte G1.Sniper B7 B150
Intel Core i5-6500 3200 1151 BOX
SSD SanDisk Extreme Pro 1TB M.2
2x 16GB DDR4 Riegel (um später vielleicht noch was zuzustecken)
5x Seagate 6TB IronWolf 7200 SATA-3
2x Seagate 4TB ST4000DM004 5400 SATA-3
ein alter SATA-Controller, um die die vielen SATAs anschließen zu können
Tandberg LTO-3 SCSI-Streamer.

Das dazugehörige Betriebssystem.

FreeBSD – Systemaktualisierung

In den Anfangszeiten nutzte ich lange das ctm um den source zu aktualisieren, vor einigen Jahren wurde dieser beerdigt und ich bin auf svn umgestiegen. Alte Gepflogenheiten ändert man nicht, also kein „freebsd-update“ oder „Package-update“ – immer selbst kompilieren…

svn checkout scv://svn.freebsd.org/base/stable/12 /usr/src/

dies kopiert/aktualisiert unter /usr/src mit den aktuellsten Änderungen.

im /usr/src findet sich dann das README, in welchem die Aktualisierung beschrieben wird, mit make buildworld und make buildkernel, make installkernel.
Hat man eine multicore-Architektur zur Verfügung, kann man mit <make -j 4 buildworld> die Kompilierung auf 4 cores erweitern.
Beim buildkernel wurde mir davon abgeraten. Wenn ich einen Versionssprung mache, oder der compiler aktualisiert wird, baue ich das System nach der ersten Aktualisierung und reboot gleich nochmal neu…

Eine sehr praktische Sache ist auch der „Ports“ Bereich, hier sind die Programme, welche nicht Bestandteil des Betriebssystems sind, also zB firefox, thunderbird, Samba, gimp, u.v.m.

Die Ports-source holt man sich mit:

svn checkout svn://svn.freebsd.org/ports/head /usr/ports/

Als erstes empfehle ich die Installation vom portmaster:

cd /usr/ports/ports-mgmt/portmaster/
make install

damit manage ich die Port-Installationen und Aktualisierungen.
Wichtig!!! – auch hier gibt es einen Readme (im Ports-Verzeichnis), welcher vor Aktualisierungen unbedingt gelesen werden sollte (bei Neu-Installationen ist das hinfällig 😉 )
Der portmaster löst einem erforderlichen Abhängigkeit auf und klappert alles in einem Rutsch ab – Beispiel:

portmaster -d --force-config sysutils/rsync

Bei einer Neu-Installation ist das Mutterverzeichnis wichtig, ohne geht es nicht. Bei Aktualisierungen reicht der Port-Name.
–force-config bewirkt, das bei verfügbaren Optionen diese vor der Kompilierung aktiviert oder deaktiviert werden können. Manchmal sind das Sachen wie CUPS für zum Drucken oder SSE-Unterstützung und so…
-d steht dafür das unter Ports/distfiles/ die alten Pakete ohne Nachfrage gelöscht werden (aufgeräumt).

Irgendwann, wenn man mal das System aktualisiert hat, will man auch die Ports, zB wegen Sicherheitsfixes aktualisieren, dann möchte man sich zB eine Liste erstellen lassen, was alles aktualisiert werden möchte:

portmaster -L | egrep -B1 '(ew|ort) version|Aborting|installed|dependencies| IGNORE|marked|Reason:|MOVED|deleted' | grep -v '^--' | less

Das less kann jeder handhaben wie er möchte, ist aber praktisch, mal drüber zu schauen und querzuchecken mit dem README, ob man ggfs das ein oder andere zu beachten hat. Speziell vorherige Läufe zwecks DeInstallationen oder library-Umstellungen…

Wenn man alles Aktualisieren möchte, bietet sich auch:

portmaster -a -d

Damit werden alle Ports aktualisiert, für welche Updates verfügbar sind.

FreeBSD – wie ich dazu kam

FreeBSD nutze ich seit Version 2, also etwa seit 1992.

Meine ersten Gehversuche hatte ich damals mit einer DLD 0.99pl15 (linux) und wurde irgendwie gar nicht glücklich damit. Da ich 1990 vom Apple //e auf Macintosh umstieg, war der Mac für mich das ideale System geworden. Netzwerktechnisch verstand dieser allerdings nur Appletalk, dafür gab es in der freien unix-Welt 2 Lösungen: CAP (Columbia Appletalk Package) und netatalk. Beide bedingten allerdings ein paar Spezifitäten im TCP-Stack, welche unter Linux damals nicht verfügbar waren. Unter BSD aber.

Also, FreeBSD probiert (und netBSD auch mal 😀 )

Dez 1994 kam FreeBSD 2.2.5, unter welchem ich rund 8 Jahre die Quark LU2 (Maus-Mailbox) betrieben habe (inclusive manchem Systemupdate) – welche damit die schnellste Tauschbox im MausNet wurde, ohne daß die Outfiles vorgepackt sein mussten.

Mittlerweile betreibe ich FreeBSD in der Version 13-STABLE, seit Jahren bevorzuge ich den STABLE-tree, da dieser für Stabilität und Security steht.

Der Server.