Codeberg höre ich hier zum ersten Mal; aus meiner Sicht nimmt man entweder Github – wenn man Erreichbarkeit über IPv6 verzichtbar findet und auch mit Microsoft als Eigentümer kein Problem hat – oder Gitlab, um seine öffentlichen Projekte ›der‹ Öffentlichkeit zugänglich zu machen.
Was man aber immer im Auge haben sollte: dort ist man Gast auf Systemen, die nach US-Recht arbeiten — siehe yt-dl kürzlich.
Im Rahmen der »Freifunk OWL«-Idee arbeiten FFKGT & FFLIP mit einem selbst gehosteten Gitlab für die nicht-öffentlichen Dinge (konkrete Konfiguration, Inventar) und Github für öffentliche Inhalte (Playbooks). Der Github-Teil soll noch Gitlab gespiegelt werden.
Second that. Und immer auf Spiegelung setzen (RAID1). Massenspeicherlebensdauer ist endlich, ein Restore ungemein aufwändiger als ein simpler Datenträgertausch.
FFLIP wie FFKGT wird an einigen Standorten z. Zt. ausgebremst, da wir nur 2 300er SAS-Platten, oder noch kleinere SSDs, in den Systemen stecken haben: da ist dann nach ~12 x 20 GB-VMs plus OS halt Schicht im Schacht, auch wenn noch RAM & CPU frei wären.
Second that. Wie auch schon im Telegram-Channel ausgeführt, das ist eine Make-or-Buy-Entscheidung, die verschiedene Implikationen hat. Schon der Betrieb eines Servers im Internet, zumal eines Hypervisors, kostet Zeit; Automatisierung wiederum kann da sehr helfen. Bei einem Makerspace würde ich tendentiell erwarten, daß dieser sich sowenig Aufwand mit seinen digitalen Angeboten aufbürdet wie möglich (also i. d. R. zu »Buy« tendiert); bei einem Hackspace hingegen würden mich externe Lösungen wundern 
Eigene Hardware vs. betriebene Hardware, dazu hat Jens oben schon was geschrieben, was ich hier für die beiden Hwarewareoptionen etwas umstellen möchte:
| Eigene physische Hardware |
Gemietete physische Hardware (»Root-Server«) |
Pro:
-
Volle Kontrolle über verwendete Komponenten.
-
Nutzbarkeit gewünschter Serverhardware; HW bleibt Eigentum (defekte HDDs/SSDs).
-
Fernwartung (IPMI & Co.) je nach gewählter Serverhardware gegeben (ggf. 2. Port und »VPN-Dongle« notwendig).
-
Hypervisor nach Wahl kann installiert werden, alles weitere kann in Container oder VMs. Volle Flexibilität im Rahmen der Ressourcen.
-
Günstige Angebote für non-profits verfügbar.
|
Pro:
-
Kontrolle über verwendete Komponenten durch buchbare Optionen.
-
vom Hoster i. d. R. massenhaft gestellte und insofern ›erprobte‹ Hardware.
-
Hoster kümmert sich um Anschaffung und Instandhaltung der Hardware.
-
Hypervisor nach Wahl kann installiert werden, alles weitere kann in Container oder VMs. Volle Flexibilität im Rahmen der Ressourcen.
-
Monatlicher Fixpreis für gemietete Komponenten.
|
Contra:
-
Eigenes (externes) Monitoring erforderlich.
-
Aufwand (Zeit, Geld) für Anschaffung sowie Wartung und Aufbau.
-
Volle Verantwortung über die HW inkl. Ersatzteilen.
-
Hardwareausfall ist möglich. Das macht alle Dienste kurzfristig, schlimmstenfalls langfristig, nicht erreichbar.
-
Volle Verantwortung über die installierte Software und Dienste und Wartung (Sicherheit, Datenschutz).
-
Je nach RZ Kosten für Remote-Hands-Tätigkeiten oder jene nicht möglich (dann muß jemand für jede Aktion selbst hinfahren).
-
Je nach RZ pauschalierte oder nutzungsabhängige Bepreisung; insbesondere Strom wird mehr und mehr nutzungsabhängig weiterberechnet, inkl. Zuschlag für USV, Kühlung. (HP Proliant G8 mit 24 Threads, 128 GB RAM, 6x 900 GB HDD schluckt bei Load von 6 um die 150 Watt.)
|
Contra:
-
Eigenes (externes) Monitoring erforderlich.
-
Wenn keine Serverhardware, i. d. R. kein IPMI (doof bei panic() des Kernels); ggf. KVM-over-IP gegen Zusatzkosten verfügbar.
-
Hardwareausfall ist möglich. Das macht alle Dienste kurzfristig, schlimmstenfalls mittelfristig, nicht erreichbar.
-
Volle Verantwortung über die installierte Software und Dienste und Wartung (Sicherheit, Datenschutz).
-
Aufrüstung nur begrenzt möglich (Angebote des Hosters).
-
Ersetzte Datenträger bleiben Eigentum des Hosters (ggf. Datenschutzproblem und vertragliche Lösung evtl. notwendig).
|
|
Im Freifunk-Bereich nutzen wir i. d. R. »gut abgehangene« Server (3+ Jahre alt, teils günstig zu bekommen, wenn aus Abschreibung raus), also ein bis zwei Generationen hinter den aktuellen CPUs, dafür meist 2 6-oder-mehr-Core-Multithread-CPUs und mind. 2 GB RAM/Thread.
Jein, das hängt ganz von den Parametern ab. Üppig viele Cores, viel RAM und viele Plattenslots laden zwar ein, NAS & HV auf der gleichen Büchse zu machen, aber wenn wegen Plattentausch nicht nur das NAS sondern auch der HV abgeschaltet werden muß, ist das mehr als nur lästig. Sofern eine direkte Abhängigkeit sowieso besteht (der HV die lokalen Platten nutzt), sieht das wieder anders aus.
Beides möchte ich als guten Rat hervorheben
Und dazu raten, im Hinterkopf haben, daß Open Source nicht zwingend bedeutet, daß die Lösung frei nutzbar bleibt. So hat das OpenNebula-Projekt stumpf die Upgraderoutinen so umgewandelt, daß ein Versionsupgrade nur noch mittels Close-Source-Package, für non-profits zu bekommen auf Anfrage über die dahinter stehende Firma, möglich ist. Man will so die Einnahmen durch Supportverträge erhöhen; dieses negative Beispiel könnte auch andere Open-Source-Projekte mit Firmen als Träger/Treiber ermutigen, die freie Nutzung einzuschränken.
Am wenigsten Aufwand dürften Github/Gitlab (s. o.) für Code und eine VM bei einem Hoster für Web-Kram (Forum, Webseite) sein. Das bei einem Hoster zusammenzuziehen bringt Synergieeffekte, Webseite und Forum bei verschiedenen Hostern zu betreiben hingegen Redundanz. Und egal, was man tut, an’s Offsite-Backup (inkl. Plan für Restore) denken. Ob ein vereinseigener Mindcraft-Server eine eigene VM, oder alles zusammen einen eigenen Server, rechtfertigt: not my call
Ah, FTR: Hetzner SMB-Storage-Boxen eignen sich nicht als Storage für VMs: nach Arbeiten durch Hetzner zeigen die zugewiesenen FQDNs ggf. auf andere IPs, Unix’ mount arbeitet aber auf IP-Adressebene …
HTH.
Aktuell finde ich es einfacher, „nur“ einen Server anzufragen.