Bearbeiten von „JailServer mit FreeBSD 10.1“

Aus UUGRN

Warnung: Du bist nicht angemeldet. Deine IP-Adresse wird bei Bearbeitungen öffentlich sichtbar. Melde dich an oder erstelle ein Benutzerkonto, damit Bearbeitungen deinem Benutzernamen zugeordnet werden.

Die Bearbeitung kann rückgängig gemacht werden. Bitte prüfe den Vergleich unten, um sicherzustellen, dass du dies tun möchtest, und speichere dann unten deine Änderungen, um die Bearbeitung rückgängig zu machen.

Aktuelle Version Dein Text
Zeile 10: Zeile 10:
 
* Optional ''internes'' Interface ('''LAN'''), ersatzweise wird ein Loopback-Interface verwendet, hier gibt es ein nicht geroutetes RfC1918 Netzwerk mit /24
 
* Optional ''internes'' Interface ('''LAN'''), ersatzweise wird ein Loopback-Interface verwendet, hier gibt es ein nicht geroutetes RfC1918 Netzwerk mit /24
 
* die externe Sichbarkeit von Services soll auf das absolute Minimum reduziert werden, rein intern genutzte Services (zB Datenbanken, Syslog, …) sollen ausschießlich im ''LAN'' zugreifbar sein
 
* die externe Sichbarkeit von Services soll auf das absolute Minimum reduziert werden, rein intern genutzte Services (zB Datenbanken, Syslog, …) sollen ausschießlich im ''LAN'' zugreifbar sein
* Alle maßgeblichen Services sollen in individuellen Jails laufen.
+
* Alle Services sollen in individuellen Jails laufen
* Folgende Services sollten jeweils ein eigenes extern erreichbares Jail erhalten:
+
* '''Webapplikationen''' sollen in Jails mit ausschließlich RfC1918-IP betrieben werden und ausschließlich mittels Proxy und Reverse-Proxy mit der Außenwelt kommunizieren
** '''mail''' (aka mail.sigsys.de, sigsys_mail, zroot/jails/sigsys/mail/, ".2")
+
* '''Mailrouting''' findet in einem dedizierten Jail statt
** '''dns''' (aka dns.sigsys.de, sigsys_dns, zroot/jails/sigsys/dns/, ".3")
+
* Es werden '''2 DNS-Server''' betrieben: Einer direkt auf dem Host für '''allgemeine Verwendung''', zB rekursive Abfragen, einer ausschließlich für '''Domainhosting''' und als '''Hidden Primary''' (eigenes Jail)
** '''proxy''' (aka proxy.sigsys.de, sigsys_proxy, zroot/jails/sigsys/proxy/, ".4")
+
* Alle Services werden durch konservative Konfiguration auf das erforerliche Minimum reduziert, eine Firewall ist in diesem Setup nicht erforderlich (aber generell möglich)
** '''shell''' (aka shell.sigsys.de, sigsys_shell, zroot/jails/sigsys/shell/, ".5")
 
* '''Webapplikationen''' sollen in Jails mit ausschließlich RfC1918-IP ("lan") betrieben werden und ausschließlich mittels Proxy und Reverse-Proxy mit der Außenwelt kommunizieren. Das soll unkontrolliertes ''nach Hause telefonieren'' unterbinden und kann bei Bedarf über den verfügbaren ProxyServer (squid auf proxy.sigsys.lan:3128) abgewickelt werden (zB Umgebungsvariablen setzen für libcurl sofern entsprechend verwendet).
 
* '''Mailrouting''' findet in einem dedizierten Jail statt. Hier erfolgt auch der Zurgriff auf Mailboxen.
 
* Es werden '''2 DNS-Server''' betrieben: Einer direkt auf dem Host für '''allgemeine Verwendung''', zB rekursive Abfragen, einer ausschließlich für '''Domainhosting''' und als '''Hidden Primary''' (eigenes Jail dns.sigsys.de)
 
* SSH-Zugänge (SSH Jumphost etc) und alles, was normale Benutzer auf dem Server tun können soll im '''shell'''-Jail stattfinden.
 
* Alle Jails (mit ausnahme des '''shell'''-Jails) sind ausschließlich über das "lan"-Interface per SSH erreichbar (via shell.sigsys.de /shell.sigsys.lan als Jumphost)
 
* SSH-Zugriff auf den Server (srv01.sigsys.de) direkt sollte wenn möglich gar nicht oder nur stark eingeschränkt ermöglicht werden, normale Benutzeraccounts soll es auf dem Server direkt ohnehin nicht geben.
 
* Alle Services auch in den Jails werden durch konservative Konfiguration auf das erforerliche Minimum reduziert. Eine Firewall ist in diesem Setup somit nicht erforderlich (aber generell möglich, wenn auch sehr komplexx aufgrund der Kommunikationsmatrix zwischen den ganzen Jails).
 
* Kommunikation zwischen internen Services erfolgt ausschließlich über das "lan"-Interface.
 
  
 
== Hardware ==
 
== Hardware ==
Zeile 37: Zeile 28:
 
Die beiden SSDs werden dann später manuell aufgesetzt und hinzugefügt.  
 
Die beiden SSDs werden dann später manuell aufgesetzt und hinzugefügt.  
  
Nach Abschluss der Installation und dem reboot sollte der Server per SSH über das Internet erreichbar sein.
+
Nach der Installation sollte der Server per SSH über das Internet erreichbar sein.
 
 
=== Storage Setup erweitern: SSDs einbinden ===
 
Nach der Installation durch bsdinstall mit ZFS auf zwei '''1TB-Festplatten''' (Western Digital Red / WDC WD10JFCX-68N6GN0, als /dev/ada3 und /dev/ada4) existiert ein zpool namens "zroot", der etwa so aussieht:
 
 
 
<pre>
 
# zpool status
 
  pool: zroot
 
state: ONLINE
 
  scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb 15 03:48:59 2015
 
config:
 
 
 
        NAME                              STATE    READ WRITE CKSUM
 
        zroot                              ONLINE      0    0    0
 
          mirror-0                        ONLINE      0    0    0
 
            gpt/zfs0                      ONLINE      0    0    0
 
            diskid/DISK-WD-WXK1E848AH8Pp3  ONLINE      0    0    0
 
 
 
errors: No known data errors
 
</pre>
 
 
 
Aus Performancegründen sollen sowohl Lese als auch Schreibzugriffe über SSDs (Flash-Speicher) beschleunigt werden. Dazu existieren 2 verschiedene SSDs mit jeweils 120GB Nutzapazität:
 
 
 
* '''Corsair Force GT''' / SandForce Driven SSDs
 
* '''SPCC Solid State Disk'''
 
 
 
==== SSDs mit GPT partitionieren ====
 
 
 
Die beiden SSDs sind als "ada0" und "ada1" im System eingebunden. Mittels "gpart" wird folgendes GPT-Setup erzeugt:
 
 
 
* Alle Offsets sind 1m-Aligned (4k-Alignment wäre auch ausreichend, 1m ist je nach Speicherorganisation der SSDs ggf. hilfreich)
 
* 512k für den BootLoader
 
* 16GB für swap (wird via /etc/fstab eingetragen, evtl vorhandener swap auf HDDs deaktivieren)
 
* 32GB für '''ZIL''' (ZFS Intent Log) oder kurz '''log'''
 
* 64GB für '''L2ARC''' (ZFS Cache) oder kurz '''cache'''.
 
 
 
<pre>
 
=>      34  234441581  ada0  GPT  (112G)
 
        34          6        - free -  (3.0K)
 
        40      1024    1  freebsd-boot  (512K)
 
      1064        984        - free -  (492K)
 
      2048  33554432    2  freebsd-swap  (16G)
 
  33556480  67108864    3  freebsd-zfs  (32G)
 
  100665344  133775360    4  freebsd-zfs  (64G)
 
  234440704        911        - free -  (456K)
 
 
 
=>      34  234441581  ada1  GPT  (112G)
 
        34          6        - free -  (3.0K)
 
        40      1024    1  freebsd-boot  (512K)
 
      1064        984        - free -  (492K)
 
      2048  33554432    2  freebsd-swap  (16G)
 
  33556480  67108864    3  freebsd-zfs  (32G)
 
  100665344  133775360    4  freebsd-zfs  (64G)
 
  234440704        911        - free -  (456K)
 
</pre>
 
 
 
Die '''ada2''' und '''ada3''' sind die Festplatten, die von '''bsdinstall''' eingerichtet wurden, hier nur der Vollständigkeit halber gezeigt:
 
<pre>
 
=>        34  1953525101  diskid/DISK-WD-WXK1E848AH8P  GPT  (932G)
 
          34          6                              - free -  (3.0K)
 
          40        1024                            1  freebsd-boot  (512K)
 
        1064    8388608                            2  freebsd-swap  (4.0G)
 
    8389672  1945135456                            3  freebsd-zfs  (928G)
 
  1953525128          7                              - free -  (3.5K)
 
 
 
=>        34  1953525101  ada3  GPT  (932G)
 
          34          6        - free -  (3.0K)
 
          40        1024    1  freebsd-boot  (512K)
 
        1064    8388608    2  freebsd-swap  (4.0G)
 
    8389672  1945135456    3  freebsd-zfs  (928G)
 
  1953525128          7        - free -  (3.5K)
 
</pre>
 
 
 
Sinngemäß ist für /dev/ada0 und /dev/ada1 jeweils folgendes auszuführen:
 
<small>(abgekupfert unter auf [http://blog.ociru.net/2013/04/05/zfs-ssd-usage blog.ociru.net] und auch sehr gut erklärt in [https://www.michaelwlucas.com/nonfiction/freebsd-mastery-storage-essentials FreeBSD Mastery: Storage Essentials], ebook von  [https://www.michaelwlucas.com/ Michael W Lucas])</small>
 
 
 
<pre>
 
# gpart destroy ada0
 
# gpart destroy ada1
 
# gpart create -s gpt ada0
 
# gpart create -s gpt ada1
 
# gpart add -t freebsd-boot -a 1m -s 512k -l ssdboot0 ada0
 
# gpart add -t freebsd-boot -a 1m -s 512k -l ssdboot1 ada1
 
# gpart add -t freebsd-swap -a 1m -s 16G -l ssdswap0 ada0
 
# gpart add -t freebsd-swap -a 1m -s 16G -l ssdswap1 ada1
 
# gpart add -t freebsd-zfs -a 1m -s 32G -l log0 ada0
 
# gpart add -t freebsd-zfs -a 1m -s 32G -l log1 ada1
 
# gpart add -t freebsd-zfs -a 1m -s 64G -l cache0 ada0
 
# gpart add -t freebsd-zfs -a 1m -s 64G -l cache1 ada1
 
</pre>
 
 
 
==== GPT-ZFS Bootloader ====
 
Auf die jeweils erste Partition (adaXp1) soll noch der aktuelle Bootloader installiert werden. Je nachdem von welchen Disks der Server vom BIOS her nachher bootet sollte in jedem Fall ein gültiger Bootloader gefunden werden, der in der Lage ist das ZFS auf den verfügbaren GPT-Partitionen zu finden.
 
 
 
<pre>
 
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
 
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
 
</pre>
 
 
 
Nach Major-RELEASE Upgrades von FreeBSD, bei denen auch ZFS signifikant erneuert wurde, sollte dieser Vorgang für alle verfügbaren Boot-Devices wiederholt werden, also auch ada2 und ada3 sofern vorhanden.
 
 
 
Die jeweils zum RELEASE gehörende Version von /boot/gptzfsboot sollte ausgerollt werden. Das gilt insbesondere bei Uprgade von ZFS Version <28 (FreeBSD 7.x, 8.x)!
 
 
 
/boot/pmbr wird als ''protective MBR'' bezeichnet und erzeugt einen Pseudo-MBR, der verindern soll, dass ein nicht GPT fähiges OS (zB WinXP) die Platte irrtümlich als "Frei" erkennt und anfängt dinge damit zu tun.
 
 
 
Mehr dazu unter [https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot RootOnZFS/GPTZFSBoot] im FreeBSD-Wiki.
 
 
 
==== GPT-Partitionen auf SSD als ZFS log und cache einbinden  ====
 
 
 
Die nun so geschaffenen GPT-Devices können nun als '''log''' und '''cache''' dem bereits existierenden zpool ('''zroot''') zugefügt werden. Dabei sei deutlich zu erwähnen:
 
 
 
* SSDs tendieren dazu kaputt zugehen. Das ist im Falle von ZFS besonders für das ZIL schädlich. Entsprechend wird ZIL hier als '''mirror''' betrieben. Aufgrund der Verschiedenen SSDs ist die Wahrscheinlichkeit eines gleichzeitigen Ausfalls relativ gering. Sollte eine SSD kaputt gehen, sollte bis zum Ersatz zumindest das log-Device ("ZIL") aus dem zpool auskonfiguriert werden!
 
* cache ("L2ARC") kann nicht ausfallsicher gebaut werden. Das ist auch nicht erforderlich, da Lesefehler im Cache automatisch zu einem Lesevorgang auf der Festplatte führt. Ein physisch beschädigtes cache-device sollte allerdings auskonfiguriert werden.
 
 
 
Der folgende Befehl fügt dem bestehenden "zroot" nun log und cache aus den oben erzeugten GPT-Devices hinzu:
 
<pre>
 
# zpool add zroot log mirror /dev/gpt/log0 /dev/gpt/log1 cache /dev/gpt/cache0 /dev/gpt/cache1
 
</pre>
 
 
 
 
 
Der zpool sieht danach so aus:
 
<pre>
 
# zpool status
 
  pool: zroot
 
state: ONLINE
 
  scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb 15 03:48:59 2015
 
config:
 
 
 
        NAME                              STATE    READ WRITE CKSUM
 
        zroot                              ONLINE      0    0    0
 
          mirror-0                        ONLINE      0    0    0
 
            gpt/zfs0                      ONLINE      0    0    0
 
            diskid/DISK-WD-WXK1E848AH8Pp3  ONLINE      0    0    0
 
        logs
 
          mirror-1                        ONLINE      0    0    0
 
            gpt/log0                      ONLINE      0    0    0
 
            gpt/log1                      ONLINE      0    0    0
 
        cache
 
          gpt/cache0                      ONLINE      0    0    0
 
          gpt/cache1                      ONLINE      0    0    0
 
 
 
errors: No known data errors
 
</pre>
 
 
 
==== swap-Partitionen von HDD auf SSD umbiegen ====
 
Von bsdinstall wurde bereits swap-Speicher auf den Festplatten eingerichtet. Dieser soll entfallen zugunsten von swap-Partitionen auf SSDs.
 
Auch wenn die oben angelegten 2x 16GB freebsd-swap üppig erscheinen (ergibt immerhin 32Gb swap), der Platz ist auf den SSDs ohnehin günstig und schnell vorhanden.
 
 
 
Abgesehen von klassischem "paging" kann der in Summe nun 32GB große swapspace verwendet werden für
 
* /tmp als swap basierte RAM-Disk (swap backed memory disk, ''md'')
 
* crash dump Partition (''dumpon=AUTO'')
 
 
 
 
 
1. Zunächst prüfen, dass genug RAM frei ist und swap nicht anderweitig genutzt wird, dann swap deaktivieren:
 
<pre>
 
# swapoff -a
 
</pre>
 
 
 
2. Anschließend in /etc/fstab sinngemäß folgnde Änderungen (hier dargestellt als unified diff) durchführen:
 
<pre>
 
--- /etc/fstab.orig    2015-02-18 02:06:47.466768456 +0100
 
+++ /etc/fstab  2015-02-15 03:25:40.010168828 +0100
 
@@ -1,4 +1,8 @@
 
# Device              Mountpoint      FStype  Options        Dump    Pass#
 
-/dev/ada0p2            none    swap    sw              0      0
 
-/dev/ada1p2            none    swap    sw              0      0
 
+#/dev/ada0p2          none    swap    sw              0      0
 
+#/dev/ada1p2          none    swap    sw              0      0
 
+
 
+/dev/gpt/ssdswap0      none    swap    sw      0      0
 
+/dev/gpt/ssdswap1      none    swap    sw      0      0
 
+
 
fdesc                  /dev/fd        fdescfs rw 0 0
 
</pre>
 
 
 
Die '''GPT-Labels''' "ssdswap0" und "ssdswap1" wurden zuvor mittels "gpart add … -t freebsd-swap -l ssdswap0 …" erzeugt. Man könnte hier generell auch /dev/ada0p1 und /dev/ada0p2 verwenden, was aber bei Wegfall von einzelnen Devices oder Neu/Umverkabelung von SATA-Ports zu Problemen führt (andere Numerierung! der ada-Devices).
 
 
 
3. swap nun wieder aktivieren:
 
<pre>
 
# swapon -a
 
</pre>
 
 
 
===== mögliche Nutzung von swap für /tmp =====
 
 
 
Verantwortlich für die Erzeugung einer "swap-based memory disk für /tmp" ist das Startscript '''/etc/rc.d/tmp''', welches wie folgt parametrisiert werden kann:
 
 
 
;Aus rc.conf(5):
 
<pre>
 
    tmpmfs      Controls the creation of a /tmp memory file system.  Always
 
                happens if set to ``YES'' and never happens if set to ``NO''.
 
                If set to anything else, a memory file system is created if
 
                /tmp is not writable.
 
 
 
    tmpsize    Controls the size of a created /tmp memory file system.
 
 
 
    tmpmfs_flags
 
                Extra options passed to the mdmfs(8) utility when the memory
 
                file system for /tmp is created.  The default is ``-S'',
 
                which inhibits the use of softupdates on /tmp so that file
 
                system space is freed without delay after file truncation or
 
                deletion.  See mdmfs(8) for other options you can use in
 
                tmpmfs_flags.
 
</pre>
 
 
 
;aus mdmfs(8):
 
<pre>
 
    By default, mdmfs creates a swap-based (MD_SWAP) disk with soft-updates
 
    enabled and mounts it on mount-point.
 
</pre>
 
 
 
 
 
Generell könnte über diesen Mechanismus auch /tmp-Speicher für die jails angeboten werden, der beim Start eines Jails (vorab) automatisch bereitgestellt wird.
 
Nach der Änderung der Storages ist ein Neustart vom Server hilfreich, bevor man anfängt viel Arbeit in das Setup zu investieren!
 
 
 
==== swap space für crash dumps ====
 
Der FreeBSD-Kernel kann im Falle einer Kernelpanic seinen gesamten Speicher oder auszüge daraus für eine spätere Analyse auf ein "dump-device" schreiben (sofern die Kernel-Panic nicht durch das Storage-Subsystem ausgelöst wurde).
 
 
 
Dies kann eine dedizierte crashdump-Partition sein, üblicherweise wird hier allerdings eine (ausreichend große) swap-Partition verwendet. Nach dem dann folgenden Reboot wird dieser crash-dump vor der Initialisierung von Swap automatisch gefunden und nach /var/crash kopiert, wo er post mortem analysiert werden kann.
 
 
 
Da der Server 16GB RAM hat sind die (beiden) SWAP-Partitionen ebenfalls 16GB groß, aber nicht aufgrund der "SWAP = 2xRAM"-Regel sondern eben für die crash-dumps.
 
 
 
;aus rc.conf(5):
 
<pre>
 
    dumpdev    (str) Indicates the device (usually a swap partition) to
 
                which a crash dump should be written in the event of a system
 
                crash.  If the value of this variable is ``AUTO'', the first
 
                suitable swap device listed in /etc/fstab will be used as
 
                dump device.  Otherwise, the value of this variable is passed
 
                as the argument to dumpon(8).  To disable crash dumps, set
 
                this variable to ``NO''.
 
 
 
    dumpdir    (str) When the system reboots after a crash and a crash dump
 
                is found on the device specified by the dumpdev variable,
 
                savecore(8) will save that crash dump and a copy of the ker-
 
                nel to the directory specified by the dumpdir variable.  The
 
                default value is /var/crash.  Set to ``NO'' to not run
 
                savecore(8) at boot time when dumpdir is set.
 
</pre>
 
  
 
=== Grundkonfiguration des Servers (afterboot)===
 
=== Grundkonfiguration des Servers (afterboot)===
 
==== Namen, IP-Adressen, Domains ====
 
Alle in den folgenden Beispielen verwendeten IP-Adressen und Hostnamen ensprechen einem real existierenden Server, dessen Aufbau hier beschrieben wird.
 
 
{| class=wikitable
 
! Bezeichnung
 
! Wert
 
! Bemerkung
 
|-
 
! Hostname des Servers
 
| srv01.sigsys.de
 
|
 
|-
 
! Domain(s)
 
| sigsys.de und sigsys.lan
 
| analog zu den IP-Netzen
 
|-
 
! IPv4
 
| 164.177.170.96/29
 
| externe IP-Adressen auf em0
 
|-
 
! IPv4
 
| 10.253.2.0/24
 
| interne IP-Adressen auf "lan" (=lo1)
 
|-
 
! IPv6
 
| 2a03:2500:1:8::/64
 
| externe IPv6-Adressen auf em0
 
|-
 
|}
 
  
 
==== Software installieren ====
 
==== Software installieren ====
Die Installation eines vorkompilierten Paketes erfolgt einfach mittels "pkg install paketname".  
+
Die Installation eines vorkompilierten Paketes erfolgt einfach mittels "pkg install paketname". Pakete können mittels "pkg search" gesucht werden.
Pakete können mittels "pkg search" gesucht werden. Mehr info unter ''man 7 pkg'' (bzw pkg(7)) und pkg(8).
 
  
 
* pkg (das bootstrappt sich selbst beim erstmaligen Aufruf von "pkg")
 
* pkg (das bootstrappt sich selbst beim erstmaligen Aufruf von "pkg")
Zeile 325: Zeile 48:
 
* vim-lite
 
* vim-lite
 
* wget
 
* wget
 +
  
 
==== Grundkonfiguration /etc/rc.conf ====
 
==== Grundkonfiguration /etc/rc.conf ====
Zeile 407: Zeile 131:
 
</pre>
 
</pre>
  
Weitere "Härtungen" (zB authorized_keys nur für root zugreifbar, hosts_access(5), sshd-via-xinetd, …) finden hier ersteinmal nicht statt.
+
Weitere "Härtungen" (zB authorized_keys nur für root zugreifbar, ...) finden hier ersteinmal nicht statt  
 
 
Abschließend sshd neu starten (die bestehende SSH-Session bleibt dabei erhalten!):
 
<pre>
 
# service sshd restart
 
Performing sanity check on sshd configuration.
 
Stopping sshd.
 
Waiting for PIDS: 664.
 
Performing sanity check on sshd configuration.
 
Starting sshd.
 
</pre>
 
 
 
… und direkt im Anschluss unbedingt von extern mit einer neuen ssh-Session prüfen, dass der Login noch klappt!
 
 
 
Die noch offene SSH-Session ist evtl. hilfreich, falls das Setup doch nochmal korrigiert werden muss!
 
  
 
==== sendmail einrichten ====
 
==== sendmail einrichten ====
Zeile 427: Zeile 137:
 
<pre>
 
<pre>
 
# make
 
# make
cp freebsd.mc srv01.sigsys.de.mc
 
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/  /usr/share/sendmail/cf/m4/cf.m4 srv01.sigsys.de.mc > srv01.sigsys.de.cf
 
cp freebsd.submit.mc srv01.sigsys.de.submit.mc
 
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/  /usr/share/sendmail/cf/m4/cf.m4 srv01.sigsys.de.submit.mc > srv01.sigsys.de.submit.cf
 
 
</pre>
 
</pre>
  
Zeile 471: Zeile 177:
  
 
Die Aktivierung dieser Konfiguration erfolgt abschließend mit  
 
Die Aktivierung dieser Konfiguration erfolgt abschließend mit  
 +
 
<pre>
 
<pre>
# make      
+
# make
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/  /usr/share/sendmail/cf/m4/cf.m4 srv01.sigsys.de.mc > srv01.sigsys.de.cf
 
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/  /usr/share/sendmail/cf/m4/cf.m4 srv01.sigsys.de.submit.mc > srv01.sigsys.de.submit.cf
 
 
 
 
# make install
 
# make install
install -m 444 srv01.sigsys.de.cf /etc/mail/sendmail.cf
 
install -m 444 srv01.sigsys.de.submit.cf /etc/mail/submit.cf
 
 
 
# service sendmail restart
 
# service sendmail restart
Stopping sendmail.
 
Waiting for PIDS: 5095.
 
Starting sendmail.
 
 
</pre>
 
</pre>
  
Zeile 662: Zeile 360:
 
Jails werden über das Hostsystem mit der Systemzeit versorgt, daher muss der Daemon nicht auf dem '''lan'''-Interface lauschen. Hier exemplarisch nur die Einstellung dass der Daemon ausschlielich auf '''localhost''' lauscht.
 
Jails werden über das Hostsystem mit der Systemzeit versorgt, daher muss der Daemon nicht auf dem '''lan'''-Interface lauschen. Hier exemplarisch nur die Einstellung dass der Daemon ausschlielich auf '''localhost''' lauscht.
  
== Jails ==
+
=== Storage Setup erweitern: SSDs einbinden ===
=== Grundlagen zu Jails ===
+
Nach der Installation durch bsdinstall mit ZFS auf zwei '''1TB-Festplatten''' (Western Digital Red / WDC WD10JFCX-68N6GN0, als /dev/ada3 und /dev/ada4) existiert ein zpool namens "zroot", der etwa so aussieht:
* Neu seit FreeBSD 9.x: Konfiguration mittels jail.conf (old-style aber immernoch supported!)
+
 
* Neue Jails anlegen, ganz einfach!
+
<pre>
* Jails einzeln Starten/Beenden/Neustarten mittels jail(8) und jail.conf(5)
+
# zpool status
* ZFS und Jails
+
  pool: zroot
* Automatisch Starten/Beenden von Jails beim Systemboot
+
state: ONLINE
 +
  scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb 15 03:48:59 2015
 +
config:
 +
 
 +
        NAME                              STATE    READ WRITE CKSUM
 +
        zroot                              ONLINE      0    0    0
 +
          mirror-0                        ONLINE      0    0    0
 +
            gpt/zfs0                      ONLINE      0    0    0
 +
            diskid/DISK-WD-WXK1E848AH8Pp3  ONLINE      0    0    0
 +
 
 +
errors: No known data errors
 +
</pre>
 +
 
 +
Aus Performancegründen sollen sowohl Lese als auch Schreibzugriffe über SSDs (Flash-Speicher) beschleunigt werden. Dazu existieren 2 verschiedene SSDs mit jeweils 120GB Nutzapazität:
 +
 
 +
* '''Corsair Force GT''' / SandForce Driven SSDs
 +
* '''SPCC Solid State Disk'''
 +
 
 +
==== SSDs mit GPT partitionieren ====
 +
 
 +
Die beiden SSDs sind als "ada0" und "ada1" im System eingebunden. Mittels "gpart" wird folgendes GPT-Setup erzeugt:
 +
 
 +
* Alle Offsets sind 1m-Aligned (4k-Alignment wäre auch ausreichend, 1m ist je nach Speicherorganisation der SSDs ggf. hilfreich)
 +
* 512k für den BootLoader
 +
* 16GB für swap (wird via /etc/fstab eingetragen, evtl vorhandener swap auf HDDs deaktivieren)
 +
* 32GB für '''ZIL''' (ZFS Intent Log) oder kurz '''log'''
 +
* 64GB für '''L2ARC''' (ZFS Cache) oder kurz '''cache'''.
 +
 
 +
<pre>
 +
=>      34  234441581  ada0  GPT  (112G)
 +
        34          6        - free -  (3.0K)
 +
        40      1024    1  freebsd-boot  (512K)
 +
      1064        984        - free -  (492K)
 +
      2048  33554432    2  freebsd-swap  (16G)
 +
  33556480  67108864    3  freebsd-zfs  (32G)
 +
  100665344  133775360    4  freebsd-zfs  (64G)
 +
  234440704        911        - free -  (456K)
 +
 
 +
=>      34  234441581  ada1  GPT  (112G)
 +
        34          6        - free -  (3.0K)
 +
        40      1024    1  freebsd-boot  (512K)
 +
      1064        984        - free -  (492K)
 +
      2048  33554432    2  freebsd-swap  (16G)
 +
  33556480  67108864    3  freebsd-zfs  (32G)
 +
  100665344  133775360    4  freebsd-zfs  (64G)
 +
  234440704        911        - free -  (456K)
 +
</pre>
 +
 
 +
Die '''ada2''' und '''ada3''' sind die Festplatten, die von '''bsdinstall''' eingerichtet wurden, hier nur der Vollständigkeit halber gezeigt:
 +
<pre>
 +
=>        34  1953525101  diskid/DISK-WD-WXK1E848AH8P  GPT  (932G)
 +
          34          6                              - free -  (3.0K)
 +
          40        1024                            1  freebsd-boot  (512K)
 +
        1064    8388608                            2  freebsd-swap  (4.0G)
 +
    8389672  1945135456                            3  freebsd-zfs  (928G)
 +
  1953525128          7                              - free -  (3.5K)
 +
 
 +
=>        34  1953525101  ada3  GPT  (932G)
 +
          34          6        - free -  (3.0K)
 +
          40        1024    1  freebsd-boot  (512K)
 +
        1064    8388608    2  freebsd-swap  (4.0G)
 +
    8389672  1945135456    3  freebsd-zfs  (928G)
 +
  1953525128          7        - free -  (3.5K)
 +
</pre>
 +
 
 +
Sinngemäß ist für /dev/ada0 und /dev/ada1 jeweils folgendes auszuführen:
 +
<small>(abgekupfert unter auf [http://blog.ociru.net/2013/04/05/zfs-ssd-usage blog.ociru.net] und auch sehr gut erklärt in [https://www.michaelwlucas.com/nonfiction/freebsd-mastery-storage-essentials FreeBSD Mastery: Storage Essentials], ebook von  [https://www.michaelwlucas.com/ Michael W Lucas])</small>
 +
 
 +
<pre>
 +
# gpart destroy ada0
 +
# gpart destroy ada1
 +
# gpart create -s gpt ada0
 +
# gpart create -s gpt ada1
 +
# gpart add -t freebsd-boot -a 1m -s 512k -l ssdboot0 ada0
 +
# gpart add -t freebsd-boot -a 1m -s 512k -l ssdboot1 ada1
 +
# gpart add -t freebsd-swap -a 1m -s 16G -l ssdswap0 ada0
 +
# gpart add -t freebsd-swap -a 1m -s 16G -l ssdswap1 ada1
 +
# gpart add -t freebsd-zfs -a 1m -s 32G -l log0 ada0
 +
# gpart add -t freebsd-zfs -a 1m -s 32G -l log1 ada1
 +
# gpart add -t freebsd-zfs -a 1m -s 64G -l cache0 ada0
 +
# gpart add -t freebsd-zfs -a 1m -s 64G -l cache1 ada1
 +
</pre>
 +
 
 +
==== GPT-Partitionen auf SSD als ZFS log und cache einbinden  ====
 +
 
 +
Die nun so geschaffenen GPT-Devices können nun als '''log''' und '''cache''' dem bereits existierenden zpool ('''zroot''') zugefügt werden. Dabei sei deutlich zu erwähnen:
 +
 
 +
* SSDs tendieren dazu kaputt zugehen. Das ist im Falle von ZFS besonders für das ZIL schädlich. Entsprechend wird ZIL hier als '''mirror''' betrieben. Aufgrund der Verschiedenen SSDs ist die Wahrscheinlichkeit eines gleichzeitigen Ausfalls relativ gering. Sollte eine SSD kaputt gehen, sollte bis zum Ersatz zumindest das log-Device ("ZIL") aus dem zpool auskonfiguriert werden!
 +
* cache ("L2ARC") kann nicht ausfallsicher gebaut werden. Das ist auch nicht erforderlich, da Lesefehler im Cache automatisch zu einem Lesevorgang auf der Festplatte führt. Ein physisch beschädigtes cache-device sollte allerdings auskonfiguriert werden.
 +
 
 +
Der folgende Befehl fügt dem bestehenden "zroot" nun log und cache aus den oben erzeugten GPT-Devices hinzu:
 +
<pre>
 +
# zpool add zroot log mirror /dev/gpt/log0 /dev/gpt/log1 cache /dev/gpt/cache0 /dev/gpt/cache1
 +
</pre>
 +
 
 +
 
 +
Der zpool sieht danach so aus:
 +
<pre>
 +
# zpool status
 +
  pool: zroot
 +
state: ONLINE
 +
  scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb 15 03:48:59 2015
 +
config:
 +
 
 +
        NAME                              STATE    READ WRITE CKSUM
 +
        zroot                              ONLINE      0    0    0
 +
          mirror-0                        ONLINE      0    0    0
 +
            gpt/zfs0                      ONLINE      0    0    0
 +
            diskid/DISK-WD-WXK1E848AH8Pp3  ONLINE      0    0    0
 +
        logs
 +
          mirror-1                        ONLINE      0    0    0
 +
            gpt/log0                      ONLINE      0    0    0
 +
            gpt/log1                      ONLINE      0    0    0
 +
        cache
 +
          gpt/cache0                      ONLINE      0    0    0
 +
          gpt/cache1                      ONLINE      0    0    0
 +
 
 +
errors: No known data errors
 +
</pre>
  
=== ZFS Setup für Jails ===
+
==== swap-Partitionen von HDD auf SSD umbiegen ====
Jedes Jail soll ein eigenes ZFS-Volume verwenden. Das ermöglichst später die automatische Erstellung von Snapshots beim Starten oder Beenden von Jails oder damit dann feingranulare Rollbacks nach fehlgeschlagenen Upgrades innerhalb von Jails, ohne dass benachbarte Jails zwangsweise mit zurückgerollt werden.
+
Von bsdinstall wurde bereits swap-Speicher auf den Festplatten eingerichtet. Dieser soll entfallen zugunsten von swap-Partitionen auf SSDs.
 +
Auch wenn die oben angelegten 2x 16GB freebsd-swap üppig erscheinen (ergibt immerhin 32Gb swap), der Platz ist auf den SSDs ohnehin günstig vorhanden und darüber hinaus kann (später) auch /tmp als "langsame" RAM-Disk mit swap-Persistenz mit verwendet werden (siehe unten)
  
  
=== Jails beim Booten automatisch starten ===
+
1. Zunächst prüfen, dass genug RAM frei ist und swap deaktivieren:
Das Script /etc/rc.d/jail wurde seit FreeBSD 4.x bis FreeBSD 9.x kontinuierlich weiter entwickelt. Es basierte darauf, dass alle Parameter für alle Jails in ''jail_* variables'' in '''/etc/rc.conf''' gepackt wurden. Da Jails als solche seit FreeBSD 8.x drastisch an Komplexität zugenommen haben (feingranulare Properties, MultiIP/NoIP/IPv6(only) etc) war es nicht mehr praktikabel alle möglichen Parameter auf diesem Weg (/etc/rc.conf) zu verwalten.
 
  
Das jail(8)-Tool hatte lange Zeit 2 getrennte Syntaxe:
+
<pre>
 +
# swapoff -a
 +
</pre>
  
;historischer Stil (alle Parameter müssen direkt an jail(8) übergeben werden, komplexe Dinge musste das Startscript mit Variablen aus /etc/rc.conf erledigen):
+
2. Anschließend in /etc/fstab sillgemäß folgnde Änderungen (hier dargestellt als unified diff) durchführen:
 
<pre>
 
<pre>
    jail [-hi] [-n jailname] [-J jid_file] [-s securelevel]
+
--- /etc/fstab.orig    2015-02-18 02:06:47.466768456 +0100
          [-l -u username | -U username] path hostname [ip[,..]] command ...
+
+++ /etc/fstab  2015-02-15 03:25:40.010168828 +0100
 +
@@ -1,4 +1,8 @@
 +
# Device              Mountpoint      FStype  Options        Dump    Pass#
 +
-/dev/ada0p2            none    swap    sw              0      0
 +
-/dev/ada1p2            none    swap    sw              0      0
 +
+#/dev/ada0p2          none    swap    sw              0      0
 +
+#/dev/ada1p2          none    swap    sw              0      0
 +
+
 +
+/dev/gpt/ssdswap0      none    swap    sw      0      0
 +
+/dev/gpt/ssdswap1      none    swap    sw      0      0
 +
+
 +
fdesc                  /dev/fd        fdescfs rw 0 0
 
</pre>
 
</pre>
  
;aktueller Stil mit Support für /etc/jail.conf, wobei jail(8) einen Großteil der Kompelexität selbst implementiert.
+
3. swap nun wieder aktivieren:
 
<pre>
 
<pre>
    jail [-dhilqv] [-J jid_file] [-u username] [-U username] [-cmr]
+
# swapon -a
          param=value ... [command=command ...]
 
    jail [-dqv] [-f conf_file] [-p limit] [-cmr] [jail]
 
    jail [-qv] [-f conf_file] [-rR] [* | jail ...]
 
    jail [-dhilqv] [-J jid_file] [-u username] [-U username] [-n jailname]
 
          [-s securelevel] [path hostname [ip[,...]] command ...]
 
 
</pre>
 
</pre>
  
Beim "old-style" war es praktisch nicht möglich Jails zu verwalten ohne dabei das '''/etc/rc.d/jail-Startscript''' zu verwenden, welches signifikant komplexe Dinge getan hatte und dennoch spürbare Grenzen hatte. Zusätzliche Jailmanagement Tools wie "ezjail" haben mit eigenen Methoden um /etc/rc.d/jail herum das ein Stück weit erträglicher gemacht für den Administrator.
+
===== mögliche Nutzung von swap für /tmp =====
 +
 
 +
Verantwortlich für die Erzeugung einer "swap-based memory disk für /tmp" ist das Startscript '''/etc/rc.d/tmp''', welches wie folgt parametrisiert werden kann:
  
'''Neuartige Jails''' kann man nun sehr einfach mittels jail(8) verwalten, zB '''jail -c ''jail_name''''' zum Starten (''create'') oder '''jail -r ''jail_name''''' zum Beenden (''remove''), wobei alle mit ''jail_name'' assoziierten Parameter aus /etc/jail.conf kommen.  
+
;Aus rc.conf(5):
 +
<pre>
 +
    tmpmfs      Controls the creation of a /tmp memory file system.  Always
 +
                happens if set to ``YES'' and never happens if set to ``NO''.
 +
                If set to anything else, a memory file system is created if
 +
                /tmp is not writable.
  
Damit konnte die Komplexität des '''/etc/rc.d/jail'''-Startscript drastisch reduziert werden und es ist auch nicht mehr erforderlich dieses Startscript ansich zu nutzen.
+
    tmpsize    Controls the size of a created /tmp memory file system.
  
=== Jails aus diesem Beispielsetup ===
+
    tmpmfs_flags
 +
                Extra options passed to the mdmfs(8) utility when the memory
 +
                file system for /tmp is created.  The default is ``-S'',
 +
                which inhibits the use of softupdates on /tmp so that file
 +
                system space is freed without delay after file truncation or
 +
                deletion.  See mdmfs(8) for other options you can use in
 +
                tmpmfs_flags.
 +
</pre>
  
{| class=wikitable
+
;aus mdmfs(8):
! Jail
+
<pre>
! Namen, Adressen
+
    By default, mdmfs creates a swap-based (MD_SWAP) disk with soft-updates
! Bemerkungen
+
    enabled and mounts it on mount-point.
|-
+
</pre>
| sigsys_mail (.2)
 
| mail.sigsys.de, mail.sigsys.lan, 164.177.170.98/32, 2a03:2500:1:8:2::/128, 10.253.2.2/32
 
| MX für eingehende E-Mails, intern SmartHost für alle anderen Systeme
 
|-
 
| sigsys_dns (.3)
 
| dns.sigsys.de, dns.sigsys.lan, 164.177.170.99/32, 2a03:2500:1:8:3::/128, 10.253.2.3/32
 
| Domain-Hosting, Hidden Primary DNS Server
 
|-
 
| Jail sigsys_proxy (.4)
 
| proxy.sigsys.de, proxy.sigsys.lan, 164.177.170.100/32, 2a03:2500:1:8:4::/128, 10.253.2.4/32
 
| Ein- und ausgehender Proxy (apache und squid) für HTTP-Anwendungen und vergleichbare Anwendungen
 
|-
 
| Jail sigsys_shell (.5)
 
| shell.sigsys.de, shell.sigsys.lan, 164.177.170.101/32, 2a03:2500:1:8:5::/128, 10.253.2.5/32
 
| Benutzerzugriffe via SSH, allgemeine/klassische Nutzung als Shell-Server, Jumphost für SSH nach innen ("lan")
 
|-
 
| Jail sigsys_mysql (.64)
 
| mysql.sigsys.lan, 10.253.2.64/32
 
| MySQL-Datenbank
 
|-
 
| Jail sigsys_xmpp (.66)
 
| xmpp.sigsys.de, xmpp.sigsys.lan, 2a03:2500:1:8:66::/128, 10.253.2.66/32
 
| Jabber als "IPv4 hidden Service" via proxy.sigsys.de, extern erreichbarer Service für IPv6
 
|-
 
| Jail sigsys_web04 (.131)
 
| web04.sigsys.lan, 10.253.2.131/32
 
| Einer von mindestens 7 internen Webserver-Jails für verschiedenste Anwendungsfälle (Homepages, Blogs, Wikis, Tools, …), zugreifbar nur via Reverse-Proxy auf proxy.uugrn.{de,lan}
 
|-
 
|}
 
  
 +
Generell könnte über diesen Mechanismus auch /tmp-Speicher für die jails angeboten werden, der beim Start eines Jails (vorab) automatisch bereitgestellt wird.
  
  
 
[[Kategorie:FreeBSD]]
 
[[Kategorie:FreeBSD]]
 
[[Kategorie:HowTo]]
 
[[Kategorie:HowTo]]

Bitte kopiere keine Inhalte, die nicht Deine eigenen sind!

Du gibst uns hiermit Deine Zusage, dass
  • Du den Text nicht aus Wikipedia kopiert hast
  • Du den Text selbst verfasst hast
  • oder der Text entweder
    • Allgemeingut (public domain) ist
    • oder der Copyright-Inhaber seine Zustimmung gegeben hat.
Wichtig
  • Benutze keine urheberrechtlich geschützten Werke ohne Erlaubnis des Copyright-Inhabers!
  • Falls dieser Text bereits woanders veröffentlicht wurde, weise bitte auf der 'Diskussion:'-Seite darauf hin.
  • Bitte beachte, dass alle UUGRN-Beiträge automatisch unter der der Creative Commons Lizenz stehen.
  • Falls Du nicht möchtest, dass Deine Arbeit hier von anderen verändert und verbreitet wird, dann drücke nicht auf "Artikel Speichern".

Bitte beantworte die folgende Frage, um diese Seite speichern zu können (weitere Informationen):

Abbrechen Bearbeitungshilfe (wird in einem neuen Fenster geöffnet)