Zvoni
Erfahrenes Mitglied
OK, der Titel klingt dramatischer als es ist, aber ich denke nach dem "Abenteuer" darf ich mir das erlauben...
Was war geschehen?
Der Vorsitzende von meinem Verein (Ich bin Fallschirmspringer, und das ist meine Leidenschaft), hat mich gefragt, was wir denn tun könnten wegen den ganzen Videos.
Er hatte sich an mich gewendet, weil ich so "Computer-affin" bin (Zu Deutsch: Alles Hexenwerk und schwarze Magie für ihn).
Ihm schwebte was vor in der Art: "Und ja, wenn wir nen zentralen Rechner hätten, wo wir die Videos abladen könnten, wäre das geil"
Ich: "Yo. Klingt nach File-Server. Samba drauf, Ordner-Share erstellen, und gut ist"
Er: "Ja, aber ich sollte auch von Zuhause drauf können sollen, da ich die Videos ja auch schneiden muss, und die Videos immer zuerst auf nen USB-Stick oder externe Festplatte kopieren ist irgendwie doof"
Ich: "OK, bauen wir halt noch einen FTP-Server ein"
Er: "Uh, ja. Das sollte sicher sein, weil die Videos sind ja bezahlt. Was machen wir, wenn da was kaputt geht?"
Ich: "OK, zweite Kiste neben dran, und dann Backup laufen lassen."
Er: "Ähhh.....aber dann muss ich ja wissen, auf welchem Server das ganze ist, und ja, kosten darf es auch nix"
Ich: *seufz*.....oO(Das wird jetzt wieder was)
Was ist jetzt das Ergebnis geworden?
Ich habe von meinem Arbeitgeber zwei alte ausgediente Dell Optiplex-Kübel bekommen inkl. Festplatten.
Nach langem grübeln, und auch dem ein oder anderen Ratschlag (Dank an @Technipion und @Bratkartoffel ) sieht das Setup nu wie folgt aus (Beide "Server" exakt gleich):
OS = FreeBSD 12.1 p2
HELL YEAH! wollte ich einfach mal ausprobieren. Und fasse ich es: Das ganze OS ist innerhalb von nicht mal 20 Minuten installiert.
Erster Kampf: Netzwerk.
Da ich nur ein temporäres Netzwerk-Setup hatte (siehe dazu meinen Thread im Netzwerk-Forum --> Danke Brati), wunderte ich mich, wieso meine Linux-Kisten sauber ins Netz kommen (über meinen Laptop als Router), aber die FreeBSD-Kiste nicht, obwohl alle pings erfolgreich waren, bis auf jene welche eine URL hatten.
Also irgendwas mit der Namensauflösung.
OK, Recherche ergab: /etc/resolv.conf ist für Namensserver zuständig. Meinen Laptop eingetragen, und schon gings.
Erster Reboot! Schon ging das Netzwerk wieder nicht. HÄÄÄHHH???? Hab an meinem Verstand gezweifelt.
Kuriosum bei FreeBSD: Hat die Netzwerk-Karte "DHCP" als config, wird bei jedem Neustart die /etc/resolv.conf mit einer default-Datei (die mehr oder weniger leer ist) überschrieben!!!
Lösung: In /etc/dhclient.conf muss ein supersede (bzw. append) Eintrag vorgenommen werden.
BANG! Schon gings! Sogar nach Reboot! Bin danach erstmal genüsslich aufs Klo gegangen, und danach auf den Balkon eine rauchen.
Dann erstmal Pakete installieren.
Nach den Klassikern "sudo" und "nano" erstmal das übliche Gemüse konfigurieren (ssh, wheel braucht kein sudo-passwort usw. --> Keine Angst: Wenn die Kisten produktiv gehen kommt das wieder raus)
Tja, jetzt stand ich vor der Entscheidung: HD2 und HD3 mit welchem Dateisystem? auf HD1 hatte ich ja schon ZFS-on-Root, also nehmen wir es doch auch für die anderen beiden (3 Platten pro Rechner). Einfach einen Mirror-zpool konnte ich aber nicht machen, da dadurch die Ausfallsicherheit nicht gewährleistet war.
Ja, für die Platten selbst schon, aber nicht Rechner-weise. Dazu mehr später.
Also pro Platte einen eigenen zpool erzeugt.
Nach diversen reboots ist es mir das erstemal aufgefallen: Wieso zeigen die zwei Datenplatten immer CORRUPTED an?!?!?!
--> Ich Trottel hatte die Platten selbst in den pool gemountet.
Also nochmal von vorne: GPT erstellt, Partition erstellt (mit ZFS), FORMATIERT, und dann den zpool auf die Partition erzeugt.
BANG! Und weg war das CORRUPTED!
Als nächstes: Samba.
Und schon ging es wieder los (Gabs da mal nicht nen Song, der so ähnlich hies?)
Egal was ich machte, Samba wollte die Ordner nicht exportieren (hatte sogar mal chmod 0777 auf den Ordner gemacht. Nix, Nada, Njet!)
Bis ich dann auf irgendeiner Forums-Seite den Hinweis gefunden habe, dass FreeBSD+ZFS+Samba das in ZFS eingebaute smbshare=on nicht unterstützt.
Was jetzt? Habe dann per Zufall einen Blog gefunden, auf welchem der Autor erklärt, wie man ein ZFS-Dataset dennoch in Samba auf FreeBSD freigeben kann, man muss nämlich zwei acl-Eigenschaften setzen, sowie diverse Tweaks in der smb.conf für den Share vornehmen.
HEUREKA! Es ging. Ich konnte jetzt Samba tanzen mit den Servern. (Da gabs definitiv mal nen Song der so hiess...)
Next: FTP.
Meine Wahl fiel auf ProFTPd.
Installation und default-config funktionierten (mehr oder weniger) out-of-the-box. DefaultRoot auf den Share, diverse Tweaks (Passiv-Ports etc.), und schon kam ich über FileZilla drauf.
Problem: FTP, und nicht FTPS. Wat nu?
OK. mal die man-pages zu ProFTPd durchgewälzt.
Aha. Da gibts Beispiele wie man TLS einsetzt.
OK. Mit den üblichen Werkzeugen die Schlüssel erzeugt, in der config die Einträge vorgenommen, und Los.
Connect ist da, aber wieso bricht es mir dauernd die Verbindung ab?
*GNARF*
Ich Trottel hatte übersehen, dass die Sektion für TLS mit den Worten beginnt "<IfModule mod_tls.c>"
Recherche ergab: Das Modul ist nicht hineinkompiliert, lässt sich aber dynamisch aus der config nachladen.
Gefunden, getan.
LÄUFT!
Next: GlusterFS
Ich hatte mich für GlusterFS entschieden, weil es eigentlich alles erfüllt, was ich brauche:
Ausfallsicherheit pro Platte UND Rechner. Und von aussen sieht alles aus wie ein Ordner auf einem Rechner.
Ich habe für mein Gluster-Volume Distributed Replica 2 genommen: 4 x 250GB HD = 500GB gespiegelter Plattenplatz, und zwar über Kreuz!
HD1 auf S1 ist gespiegelt mit HD1 auf S2 ( !! ), und HD2 auf S1 mit HD2 auf S2.
Heisst: Egal ob ein Rechner komplett ausfällt: Alle Daten sind dennoch zugänglich.
Ähhhh.... wie jetzt? GlusterFS + ZFS + FreeBSD verträgt sich nicht besonders (und wird davon abgeraten)? OCH MENNO!
Also gut. Nochmal von vorne.
Die beiden zpools exportiert, gpart destroy -f ada{1,2} und das ganze mit UFS neu angelegt.
nur dass ich jetzt zwei Mountpoints benötigte inkl Einträge in der fstab, aber das war jetzt wirklich nicht schwarze Magie.
OK, Gluster installiert, gemäss Doku auf deren Seite eingerichtet und die Bricks vorbereitet, das Volume erzeugt, das Volume gestartet.
Hey! Funzt.
OK, wie komm ich jetzt aber da dran? Ich brauche entweder einen Mountpoint für das Volume, oder wie bringe ich Samba bei, das Volume direkt als Share anzusprechen?
Für das mounten habe ich schnell das nötige Kommando gefunden, und den Mountpoint konnte ich auch direkt als Share in Samba exportieren.
Also ab in die fstab und den Eintrag da rein.
Reboot.
Wieso habe ich da eine "mount failed"-Fehlermeldung????
Mist! Das mounten der "late" Dateisysteme findet vor dem Start des Gluster-Daemon statt.
Also fstab-Eintrag wieder raus.
Noch immer nix neues an der "Wie exportiere ich ein Gluster-Volume direkt als Share in Samba?" Doch dann der Lichtblick.
Direkt auf Samba.org in den man-pages fand ich ein "vfs_objects = glusterfs" HOLLA! Das ist doch das was ich brauche.
nano smb4.conf, und eingetragen (mit noch ein paar anderen nötigen optionen), samba neu gestartet, und drauf auf den Share.
"Das Einhängen schlug fehl" HEUL!!!
Ich weiss nicht mehr nach was ich gegooglet habe, aber ich bin dann auf der Freshports-Seite von FreeBSD gelandet in der Sektion für den Port Samba.
Und per Zufall beim lesen bleibt mein Auge auf den "Options" hängen.
Ich hatte nix besseres zu tun, also lesen wir doch mal.
Hä??
Wieso steht da bei Options "GLUSTERFS=OFF"?
*GROLL*
cd /usr/ports/net/samba410
make config
.....und auf einmal kann ich die Option anwählen.
make install clean --> Danach eine rauchen auf den Balkon.
HURRA!
Ich komme auf mein Gluster-Volume direkt per Samba drauf.
Nur: wie bringe ich das jetzt dem FTP-Server bei, dass er das Volume in DefaultRoot anbieten soll? Da brauche ich ja einen eindeutigen Pfad.
Also wieder zurück zum "Mounten-per-fstab"-Problem.
Und die Lösung: Gefunden auf der Bug-Report-Seite von FreeBSD, und zwar mit exakt derselben Begründung wie oben (Late-mount vor glusterd-start).
Man muss die Daemon-Datei von GlusterFS (glusterd) editieren. Einen Eintrag ändern, einen anderen hinzufügen.
Ist sogar offiziell als Patch mit eigener Revision anerkannt dort, nur in den offiziellen Paketen ist noch immer die Revision von davor drin.
Also selbst geändert (brav vorher ein cp glusterd glusterd.bak gemacht), und schon funktionierte das mounten per fstab.
Und schon konnte ich DefaultRoot /mnt/Export machen für den FTP-Server.
Fazit: Es hat sehr viel Spass gemacht, auch mal ein (für mich zumindest) exotisches Betriebssystem kennenzulernen.
Ja, ist schon eine Lernkurve da, aber man kommt eigentlich relativ schnell rein.
P.S.: Ach so ja. Fast vergessen: xorg und Desktop-Umgebung MATE habe ich auch noch installiert, jedoch so, dass beim Booten, die Server auf der Konsole landen
(ist quasi nur so als Beruhigung für unseren Vereinsvorsitzenden, falls ich den mal per Telefon da was machen lassen muss).
Ansonsten werden die Rechner so laufen wie es sich für eien braven und anständigen Server gehört: nämlich kopflos!
Falls jemand Interesse an den Links hat, schreibt mich an (oder ich setze sie mal in den nächsten Tagen hier rein, wenn ich sie denn mal aussortiert bekomme).
Was war geschehen?
Der Vorsitzende von meinem Verein (Ich bin Fallschirmspringer, und das ist meine Leidenschaft), hat mich gefragt, was wir denn tun könnten wegen den ganzen Videos.
Er hatte sich an mich gewendet, weil ich so "Computer-affin" bin (Zu Deutsch: Alles Hexenwerk und schwarze Magie für ihn).
Ihm schwebte was vor in der Art: "Und ja, wenn wir nen zentralen Rechner hätten, wo wir die Videos abladen könnten, wäre das geil"
Ich: "Yo. Klingt nach File-Server. Samba drauf, Ordner-Share erstellen, und gut ist"
Er: "Ja, aber ich sollte auch von Zuhause drauf können sollen, da ich die Videos ja auch schneiden muss, und die Videos immer zuerst auf nen USB-Stick oder externe Festplatte kopieren ist irgendwie doof"
Ich: "OK, bauen wir halt noch einen FTP-Server ein"
Er: "Uh, ja. Das sollte sicher sein, weil die Videos sind ja bezahlt. Was machen wir, wenn da was kaputt geht?"
Ich: "OK, zweite Kiste neben dran, und dann Backup laufen lassen."
Er: "Ähhh.....aber dann muss ich ja wissen, auf welchem Server das ganze ist, und ja, kosten darf es auch nix"
Ich: *seufz*.....oO(Das wird jetzt wieder was)
Was ist jetzt das Ergebnis geworden?
Ich habe von meinem Arbeitgeber zwei alte ausgediente Dell Optiplex-Kübel bekommen inkl. Festplatten.
Nach langem grübeln, und auch dem ein oder anderen Ratschlag (Dank an @Technipion und @Bratkartoffel ) sieht das Setup nu wie folgt aus (Beide "Server" exakt gleich):
OS = FreeBSD 12.1 p2
HELL YEAH! wollte ich einfach mal ausprobieren. Und fasse ich es: Das ganze OS ist innerhalb von nicht mal 20 Minuten installiert.
Erster Kampf: Netzwerk.
Da ich nur ein temporäres Netzwerk-Setup hatte (siehe dazu meinen Thread im Netzwerk-Forum --> Danke Brati), wunderte ich mich, wieso meine Linux-Kisten sauber ins Netz kommen (über meinen Laptop als Router), aber die FreeBSD-Kiste nicht, obwohl alle pings erfolgreich waren, bis auf jene welche eine URL hatten.
Also irgendwas mit der Namensauflösung.
OK, Recherche ergab: /etc/resolv.conf ist für Namensserver zuständig. Meinen Laptop eingetragen, und schon gings.
Erster Reboot! Schon ging das Netzwerk wieder nicht. HÄÄÄHHH???? Hab an meinem Verstand gezweifelt.
Kuriosum bei FreeBSD: Hat die Netzwerk-Karte "DHCP" als config, wird bei jedem Neustart die /etc/resolv.conf mit einer default-Datei (die mehr oder weniger leer ist) überschrieben!!!
Lösung: In /etc/dhclient.conf muss ein supersede (bzw. append) Eintrag vorgenommen werden.
BANG! Schon gings! Sogar nach Reboot! Bin danach erstmal genüsslich aufs Klo gegangen, und danach auf den Balkon eine rauchen.
Dann erstmal Pakete installieren.
Nach den Klassikern "sudo" und "nano" erstmal das übliche Gemüse konfigurieren (ssh, wheel braucht kein sudo-passwort usw. --> Keine Angst: Wenn die Kisten produktiv gehen kommt das wieder raus)
Tja, jetzt stand ich vor der Entscheidung: HD2 und HD3 mit welchem Dateisystem? auf HD1 hatte ich ja schon ZFS-on-Root, also nehmen wir es doch auch für die anderen beiden (3 Platten pro Rechner). Einfach einen Mirror-zpool konnte ich aber nicht machen, da dadurch die Ausfallsicherheit nicht gewährleistet war.
Ja, für die Platten selbst schon, aber nicht Rechner-weise. Dazu mehr später.
Also pro Platte einen eigenen zpool erzeugt.
Nach diversen reboots ist es mir das erstemal aufgefallen: Wieso zeigen die zwei Datenplatten immer CORRUPTED an?!?!?!
--> Ich Trottel hatte die Platten selbst in den pool gemountet.
Also nochmal von vorne: GPT erstellt, Partition erstellt (mit ZFS), FORMATIERT, und dann den zpool auf die Partition erzeugt.
BANG! Und weg war das CORRUPTED!
Als nächstes: Samba.
Und schon ging es wieder los (Gabs da mal nicht nen Song, der so ähnlich hies?)
Egal was ich machte, Samba wollte die Ordner nicht exportieren (hatte sogar mal chmod 0777 auf den Ordner gemacht. Nix, Nada, Njet!)
Bis ich dann auf irgendeiner Forums-Seite den Hinweis gefunden habe, dass FreeBSD+ZFS+Samba das in ZFS eingebaute smbshare=on nicht unterstützt.
Was jetzt? Habe dann per Zufall einen Blog gefunden, auf welchem der Autor erklärt, wie man ein ZFS-Dataset dennoch in Samba auf FreeBSD freigeben kann, man muss nämlich zwei acl-Eigenschaften setzen, sowie diverse Tweaks in der smb.conf für den Share vornehmen.
HEUREKA! Es ging. Ich konnte jetzt Samba tanzen mit den Servern. (Da gabs definitiv mal nen Song der so hiess...)
Next: FTP.
Meine Wahl fiel auf ProFTPd.
Installation und default-config funktionierten (mehr oder weniger) out-of-the-box. DefaultRoot auf den Share, diverse Tweaks (Passiv-Ports etc.), und schon kam ich über FileZilla drauf.
Problem: FTP, und nicht FTPS. Wat nu?
OK. mal die man-pages zu ProFTPd durchgewälzt.
Aha. Da gibts Beispiele wie man TLS einsetzt.
OK. Mit den üblichen Werkzeugen die Schlüssel erzeugt, in der config die Einträge vorgenommen, und Los.
Connect ist da, aber wieso bricht es mir dauernd die Verbindung ab?
*GNARF*
Ich Trottel hatte übersehen, dass die Sektion für TLS mit den Worten beginnt "<IfModule mod_tls.c>"
Recherche ergab: Das Modul ist nicht hineinkompiliert, lässt sich aber dynamisch aus der config nachladen.
Gefunden, getan.
LÄUFT!
Next: GlusterFS
Ich hatte mich für GlusterFS entschieden, weil es eigentlich alles erfüllt, was ich brauche:
Ausfallsicherheit pro Platte UND Rechner. Und von aussen sieht alles aus wie ein Ordner auf einem Rechner.
Ich habe für mein Gluster-Volume Distributed Replica 2 genommen: 4 x 250GB HD = 500GB gespiegelter Plattenplatz, und zwar über Kreuz!
HD1 auf S1 ist gespiegelt mit HD1 auf S2 ( !! ), und HD2 auf S1 mit HD2 auf S2.
Heisst: Egal ob ein Rechner komplett ausfällt: Alle Daten sind dennoch zugänglich.
Ähhhh.... wie jetzt? GlusterFS + ZFS + FreeBSD verträgt sich nicht besonders (und wird davon abgeraten)? OCH MENNO!
Also gut. Nochmal von vorne.
Die beiden zpools exportiert, gpart destroy -f ada{1,2} und das ganze mit UFS neu angelegt.
nur dass ich jetzt zwei Mountpoints benötigte inkl Einträge in der fstab, aber das war jetzt wirklich nicht schwarze Magie.
OK, Gluster installiert, gemäss Doku auf deren Seite eingerichtet und die Bricks vorbereitet, das Volume erzeugt, das Volume gestartet.
Hey! Funzt.
OK, wie komm ich jetzt aber da dran? Ich brauche entweder einen Mountpoint für das Volume, oder wie bringe ich Samba bei, das Volume direkt als Share anzusprechen?
Für das mounten habe ich schnell das nötige Kommando gefunden, und den Mountpoint konnte ich auch direkt als Share in Samba exportieren.
Also ab in die fstab und den Eintrag da rein.
Reboot.
Wieso habe ich da eine "mount failed"-Fehlermeldung????
Mist! Das mounten der "late" Dateisysteme findet vor dem Start des Gluster-Daemon statt.
Also fstab-Eintrag wieder raus.
Noch immer nix neues an der "Wie exportiere ich ein Gluster-Volume direkt als Share in Samba?" Doch dann der Lichtblick.
Direkt auf Samba.org in den man-pages fand ich ein "vfs_objects = glusterfs" HOLLA! Das ist doch das was ich brauche.
nano smb4.conf, und eingetragen (mit noch ein paar anderen nötigen optionen), samba neu gestartet, und drauf auf den Share.
"Das Einhängen schlug fehl" HEUL!!!
Ich weiss nicht mehr nach was ich gegooglet habe, aber ich bin dann auf der Freshports-Seite von FreeBSD gelandet in der Sektion für den Port Samba.
Und per Zufall beim lesen bleibt mein Auge auf den "Options" hängen.
Ich hatte nix besseres zu tun, also lesen wir doch mal.
Hä??
Wieso steht da bei Options "GLUSTERFS=OFF"?
*GROLL*
cd /usr/ports/net/samba410
make config
.....und auf einmal kann ich die Option anwählen.
make install clean --> Danach eine rauchen auf den Balkon.
HURRA!
Ich komme auf mein Gluster-Volume direkt per Samba drauf.
Nur: wie bringe ich das jetzt dem FTP-Server bei, dass er das Volume in DefaultRoot anbieten soll? Da brauche ich ja einen eindeutigen Pfad.
Also wieder zurück zum "Mounten-per-fstab"-Problem.
Und die Lösung: Gefunden auf der Bug-Report-Seite von FreeBSD, und zwar mit exakt derselben Begründung wie oben (Late-mount vor glusterd-start).
Man muss die Daemon-Datei von GlusterFS (glusterd) editieren. Einen Eintrag ändern, einen anderen hinzufügen.
Ist sogar offiziell als Patch mit eigener Revision anerkannt dort, nur in den offiziellen Paketen ist noch immer die Revision von davor drin.
Also selbst geändert (brav vorher ein cp glusterd glusterd.bak gemacht), und schon funktionierte das mounten per fstab.
Und schon konnte ich DefaultRoot /mnt/Export machen für den FTP-Server.
Fazit: Es hat sehr viel Spass gemacht, auch mal ein (für mich zumindest) exotisches Betriebssystem kennenzulernen.
Ja, ist schon eine Lernkurve da, aber man kommt eigentlich relativ schnell rein.
P.S.: Ach so ja. Fast vergessen: xorg und Desktop-Umgebung MATE habe ich auch noch installiert, jedoch so, dass beim Booten, die Server auf der Konsole landen
(ist quasi nur so als Beruhigung für unseren Vereinsvorsitzenden, falls ich den mal per Telefon da was machen lassen muss).
Ansonsten werden die Rechner so laufen wie es sich für eien braven und anständigen Server gehört: nämlich kopflos!
Falls jemand Interesse an den Links hat, schreibt mich an (oder ich setze sie mal in den nächsten Tagen hier rein, wenn ich sie denn mal aussortiert bekomme).