Eigener Root Server?

Guten Morgen allerseits,

im Gespräch mit @igami ist nochmal der Bedarf bzgl. eigener Hardware aufgefallen. Auf einem eigenen Root Server könnten wir uns austoben und unsere Projekte und Dienste selbst hosten.

Wir könnten uns die Verwaltung aufteilen und einige Mitglieder haben in der Vergangenheit bereits aktiv ihre Hilfe angeboten. Die benötigten Fähigkeiten haben wir also im Verein.

Mir fallen ein:

  • Website
  • Gitlab
  • Forum
  • Nextcloud
  • FreeIPA
  • Mailserver
  • Projekte
  • Minecraft Server? :slight_smile:

Mein Vorschlag wäre z.B. eine Spendenanfrage bei Hetzner. Persönlich habe ich bisher gute Erfahrungen bei denen gemacht.

Bei der Hardware würde meiner Ansicht nach dieses Modell reichen:

  • Domain
  • 500GB Backup Space

Man kann zwischen HDD und SSD wählen - ich sehe aktuell nicht, warum wir so viel Speicherplatz (2TB) benötigen. Weiterhin würde ich vorschlagen die Domain bei dem jeweiligen Hoster zu hinterlegen, sofern die Verwaltung dort auch gut ist.

1 Like

Guten Morgen,

Hetzner nutze ich Privat und Beruflich und kann das wärmstens empfehlen. Eventuell könnte man dort auch eine bestimmte Anzahl an cloud Server nutzen, anstatt eines Root Servers. Funktion ist die gleiche, aber man ist etwas flexibler. Speicherplatz kann man dazu buchen und auf den gewünschten Servern einbinden. Falls die Flexibilität gewünscht ist.

Grüße

1 Like

Dann tauchen wir demnächst vielleicht auch unter Engagement auf :slight_smile:

https://www.hetzner.com/de/unternehmen/engagement/bildung

2 Like

Ja, die Cloud Option ist auch eine gute (sehr flexible) Idee. Ich frage mich nur, wie man das Anfragen könnte. Es ist immerhin sehr dynamisch. :face_with_raised_eyebrow: Aktuell finde ich es einfacher, „nur“ einen Server anzufragen.

Auf dem Rootserver können wir einen Hypervisor unserer Wahl installieren wie z.B. Proxmox. Mit LXC können wir einfach kleine Container für Projekte bereit stellen. Geht ja schon in die Richtung von Hetzner Cloud, nur selbst verwaltet.

Ich werde mich dieses Wochenende gerne an ein Anschreiben setzen. Inspiration nehme ich von unseren bisherigen. :slight_smile:

2 Like

In der Telegram Gruppe gab es noch einige Erfahrungsberichte und Meinungen zu dem Thema. Ich versuche mal darauf einzugehen und pro/contra zu ermitteln. Generell wurde diskutiert, welche Form ein „eigenes“ Hosting haben sollte.

Physische Hardware selbst gekauft bzw. gespendet:

Pro:

  • Volle Kontrolle über verwendete Komponenten
  • Hypervisor unserer Wahl kann installiert werden, alles weitere kann in Container oder VMs. Volle Flexibilität im Rahmen der Ressourcen. Es ist weitestgehend egal, welche OS wir virtualisieren.

Contra:

  • Sehr hoher Aufwand für Anschaffung, Wartung und Zusammenbau
  • Volle Verantwortung über deren Zustand und die Reparatur
  • Monitoring erforderlich
  • Hardwareausfall ist möglich. Das macht alle unsere Dienste kurzfristig, schlimmstenfalls langfristig nicht erreichbar
  • Nach der Anschaffung muss immer noch eine Installation im RZ erfolgen
  • Ersatzteile müssen selbst beschafft werden
  • Ersatzteile müssen ohne Remote Hands selbstständig eingebaut werden
    • Wenn das RZ weit weg ist, ist ein Austausch nicht problemlos möglich
  • Ohne RZ sind die Bedingungen nicht für zuverlässigen 24/7 Betrieb optimal
  • Aufrüstung aufwendig
  • Volle Verantwortung über die installierte Software und Dienste und Wartung (Sicherheit, Datenschutz…)

Gemietete physische Hardware:

Pro:

  • Erprobte Hardware „von der Stange“
  • Vermieter kümmert sich um Anschaffung der Hardware
  • Vermieter kümmern sich um Reparatur
  • Bei einem „guten“ Anbieter sind die Bedingungen in einem RZ für 24/7 Betrieb geeignet
  • Kontrolle über verwendete Komponenten durch gebuchte Optionen
  • Hypervisor unserer Wahl kann installiert werden, alles weitere kann in Container oder VMs. Volle Flexibilität im Rahmen der Ressourcen. Es ist weitestgehend egal, welche OS wir virtualisieren.

Contra:

  • Monitoring erforderlich
  • Im günstigen Segment wird nur Consumer Hardware eingesetzt
  • Hardwareausfall ist möglich. Das macht alle unsere Dienste kurzfristig, schlimmstenfalls mittelfristig nicht erreichbar
  • Volle Verantwortung über die installierte Software und Dienste und Wartung (Sicherheit, Datenschutz…)
  • Aufrüstung nur sehr begrenzt möglich

Vserver:

Pro:

  • Kein Hardware Monitoring erforderlich, Reparatur ist nicht unser Job
  • Ausfall der Hardware ist für uns weitestgehend keine Gefahr
  • Aufrüstung problemlos möglich
  • Läuft auf Enterprise Hardware
  • Container sind problemlos möglich (auch bei den physischen Systemen.)

Contra:

  • Kein Hypervisor. Nested Virtualisation ist suboptimal. Verwendung anderer Betriebssysteme wie *BSD und Windows in einer VM ist keine wirkliche Option.
  • beschränkte Flexibilität - ggf. müssen wir mehrere VMs beim Anbieter mieten.
  • Volle Verantwortung über die installierte Software und Dienste und Wartung (Sicherheit, Datenschutz…)

Externe Dienste (Github etc.)

Pro:

  • Anbieter kümmert sich um Wartung, Installation, Betrieb und die Sicherheit der Systeme
  • Kein Monitoring nötig
  • Wir benutzen das System nur, keine größere Administration erforderlich.

Contra:

  • Wir sind abhängig vom Anbieter
  • Ausfall des Anbieters hat direkt Einfluss auf uns
  • Wo hat die Firma ihren Sitz, wo werden die Daten gespeichert? Können wir das mit unseren Werten vereinbaren?
  • Wir haben keine Kontrolle über die Systeme (ist auch ein Vorteil.)

Ich hoffe, ich konnte das einigermaßen gut vergleichen. Meiner Meinung nach ist der Root-Server immer noch der beste Mittelweg, aufgrund der Flexibilität im Umgang mit anderen Betriebssystemen. Weiterhin entspricht es unserer Philosophie, unabhängig zu sein und Dinge selber zu machen, mit all der Verantwortung die dazu gehört. Wir brauchen aber natürlich ein Konzept, um die zuverlässige Wartung und Verwendung der Systeme zu gewährleisten. Daher: Das ist ein gemeinsames Projekt!

1 Like

Hier kommt es meiner Meinung nach darauf an um welche Daten es sich handelt.

Ich bin dafür unsere Projekte auch auf Codeberg, Github und Gitlab bereitzustellen, da andere davon profitieren und daran partizipieren sollen. Dabei sollten wir auf eine geeignete Lizenz achten (z.B. CC-BY für CAD und Workshops und MIT für Software).
Auch die Website ist öffentlich, sodass der Hoster relativ egal ist.

Bei persönlichen Daten (Nextcloud, E-Mail, FreeIPA) sollten wir auf den Standort achten.

Für diese Dienste bin ich, wie Jens auch, für einen gemieteten Root-Server (im besten Fall gesponsert).
Hardware bei uns im Space zu Betreiben hätte noch weitere Anforderungen bzgl. Klimatisierung und Netzanschluss.

Bei weiterem Überlegen finde ich GitHub als unser Code Repository auch sehr sinnvoll. Mir gefällt die internationale Gemeinschaft, welche ggf. commits einreicht. Für einen persönlich dient es auch als Vorzeigeobjekt für mögliche Bewerbungen, wenn man einige spannende Projekte hat.

Ich bin aber noch nicht so überzeugt davon, das auf die anderen Plattformen zu spiegeln. Was mit mit Funktionen wie Issues, übersichtlicher Pull Requests und Diskussionen? Macht ein einfacher lokaler Spiegel zwecks Sicherung z.B. in Gitea https://gitea.io/en-us/ nicht mehr Sinn? Wenn es so fragmentiert ist, macht es das doch nicht einfacher? Ich würde Git* auch von Dokumenten, Dokumentationen, Binärdateien und Protokollen befreien, die nichts mit unserer (verwendeten) Software und deren Konfiguration zu tun haben. GitLab finde ich unübersichtlich und zu mächtig für Vereinsarbeit, da gibt es z. B. BookStack, welches das viel zugänglicher macht: https://www.bookstackapp.com/

Sollten wir wirklich Projektmanagement brauchen, scheint mir OpenProject geeignet zu sein: https://www.openproject.org/

Dann hat jedes Tool nach UNIX Philosophie genau seinen Zweck und ist auch stark darin. :smiley:

Nur GitHUB zu verwenden finde ich in sofern ungünstig, als das man da nur öffentliche Repos haben kann.

Seit 2019 kann man auch private Repos kostenlos haben. Weiterhin sollten wir uns das anschauen: https://github.com/nonprofit

1 Like

Ah, damit sollte das klappen, ansonsten hatte ich halt in erinnerung, das die Zahl an privaten Repos limitiert war.

Das dachte ich bis gestern auch, dann war ich auch verwundert. :smiley:

Der C3PB (Hackerspace Paderborn) hat einen EX41s bei Hetzner. Der scheint grob ähnlich zu sein zu dem AX41-NVME, den ihr ins Auge gefasst habt. Allerdings inzwischen etwas in die Jahre gekommen und mit HDD statt SSD - dafür 4x mehr Speicher. Die beiden HDDs nutzen wir als Raid1, d.h. wir haben 2 TB verfügbar. Wir sind damit sehr zufrieden.

Überlegt euch gut, ob ihr wirklich SSDs braucht. Die Geschwindigkeit merkt ihr in der Praxis vermutlich wenig, wenn ihr nicht mit sehr vielen Nutzern darauf zugreift. Gerade wenn ihr Container oder VMs für Projekte einrichtet und CAD Daten in Gitlab/NextCloud ablegt, könnte 512 GB irgendwann knapp werden. Andererseits sind wir 60 Mitglieder (von denen aber nur 1/3 bis 1/5 richtig aktiv sind) und die 2 TB sind aktuell noch vollkommen ausreichend. Es wäre also gut möglich, dass ihr mit 512 GB noch lange zufrieden seid.

Bei uns war klar, dass wir einen Root-Server nehmen und keinen vServer, weil wir die Platten verschlüsselt haben. Auf einem vServer wäre das sinnlos.

Zusätzlich haben wir noch einen Server im Keller stehen. Der ist über unsere sehr langsame Unitymedia Leitung angebunden und eignet sich nicht für Dinge, die im Internet verfügbar sein sollen. Er ist aber sehr gut geeignet für Experimente. Auf den Hetzner-Server haben nur wenige Zugriff, weil teilweise Datenschutz relevant ist (Mailserver, private Git-Repositories, etc.). Auf den Server im Keller kann jedes Mitglied zugreifen und auf dem Proxmox VMs oder Container für Projekte einrichten. Das ist für euch vielleicht nicht ganz so relevant, weil ihr hauptsächlich ein Makerspace seid. Bei uns ist der Makerspace nur ein Teil des Vereins und es fließt auch viel Zeit in Raumsteuerung, IRC-Bot und andere Projekte.

Zusätzlich steht im Keller noch ein Fileserver, z.B. für Bilder von Projekten. Es ist hilfreich den lokal zu haben, statt dass man die Bilder über unsere langsame Internetverbindung hochlädt. Größere Mengen an Speicherplatz werden online auch schnell teuer, während wir bei uns einfach das einbauen, was gespendet wurde, weil es irgendwo übrig war. Im Prinzip gibt es keinen Grund, warum Proxmox und FIleserver nicht auf derselben Hardware laufen können, aber den Fileserver nehmen wir teilweise zu Veranstaltungen mit.

Wenn ihr die Infrastruktur selbst hosten möchtet, überlegt euch vorher gut, wie viel Zeit ihr dafür zur Verfügung habt. Bei uns sind da diverse Monate reingeflossen. Vieles ist sicher auch over-engineered, aber es kostet immer viel Zeit - nicht nur einmal am Anfang, sondern man muss sich regelmäßig darum kümmern, wenn Dinge kaputtgehen oder wichtige Updates anstehen. Ich möchte euch sicherlich nicht davon abbringen, es selbst zu hosten. Alles andere würde dem Gedanken eines Makerspace/Hackerspace widersprechen, denke ich :wink:

Aber unterschätzt den Aufwand nicht und bildet ein Admin-Team, damit der Pflege-Aufwand nicht an nur 1-2 Personen hängen bleibt. Bei uns übernimmt die Pflege normalerweise derjenige, der den Service eingerichtet hat. Dadurch verteilt es sich.

Falls ihr mit Ansible+Debian und/oder NixOS arbeitet, kann ich euch wahrscheinlich unsere Config zur Verfügung stellen (muss ich aber mit den Urhebern klären). In jedem Fall können wir Erfahrungen austauschen und vielleicht ein paar Tipps zum Start geben, wenn ihr daran Interesse habt.

Wir zahlen einfach für den Server. Falls ihr Erfolg habt mit Sponsoring, sollten wir das auch mal ausprobieren :slight_smile:

1 Like

Offtopic: Wie entschlüsselt ihr die Daten nach einem Reboot?

Das übliche: SSH-Server im initrd.

Auf dem privaten Server habe ich ein paar Skripte, die vorher noch grob die Hardware checken. Für den Vereinsserver haben wir das einfach gehalten.

Das heißt natürlich, dass nach einem unerwarteten Reboot die Webseite down ist, bis ein Admin das Passwort eingibt. Das passiert so selten, dass das in der Praxis kein Problem ist.

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 :wink:

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 :wink:

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 :wink:

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.

Ich denke, ein Server im Vereinsumfeld muss nicht das gleiche, professionelle Niveau haben wie bei Freifunk oder bei der Arbeit. Im Verein ist das schon ok, wenn der Dienst ein paar Stunden weg ist, weil man an der Hardware schraubt. Und Monitoring ist auch eher unnötig: Die Nutzer wissen, bei wem sie sich melden. Und wenn’s dann nen Tag dauert, ist auch niemand böse. Wenn jemand Spaß daran hat, kann man’s natürlich trotzdem bauen.

Ich denke, die relevante Frage ist nicht, ob die Maker oder die Hacker im Titel stehen. Das mag ein erster Hinweis auf die Interessen sein, aber auch nicht mehr als das. Bei uns hat sich die Ausrichtung über die Jahre deutlich gewandelt, aber das Label ist gleich geblieben :wink:

Die Frage ist eher, ob ihr genügend Maker habt, die Spaß daran haben, die Software aufzusetzen und zu pflegen. Und ich sage absichtlich Spaß - weil das WIssen kommt, sobald man sich damit befasst (etwas Basiswissen und grundlegende Linux-Kenntnisse braucht’s natürlich schon). Aber wenn man keinen Spaß daran hat und dabei ständig denkt „lieber Dinge mit Holz machen“ (oder Metall?), dann lässt man’s besser bleiben.

Es ist vollkommen ok, eine fertige Lösung zu nutzen. Habt nur ein Auge darauf, dass ihr euch keinen zu großen Lock-In einfangt: Ein Git kann man schnell von Github wegziehen, die Issues eher nicht. Webseite umziehen ist auch kein Problem, wenn euch die Domain gehört (was vermutlich schon der Fall ist). Viele Software kann man nur dann umziehen, wenn man an die Datenbank kommt - und wenn man auf der Ebene Zugriff hat, kann man es vermutlich auch fast direkt selber aufsetzen. Einige Dinge gehen vermutlich nur mit Lock-In. Solange man das bewusst auswählt, spricht auch da nicht gegen, denke ich.

Falls ihr euch aktuell gegen einen richtigen Server entscheidet, überlegt euch trotzdem irgendwo einen kleinen Server hinzustellen, z.B. ein vServer mit Minecraft oder ein RaspberryPi in den Vereinsräumen. Das gibt euch die Chance zum Ausprobieren. Wenn jemand mal eben ein CodiMD oder EtherCalc haben möchte, wirft er das da drauf. Und vielleicht merkt ihr dann, dass es doch Mitglieder gibt, die Spaß daran haben. Bei uns hat es eigentlich immer mit kleinen Dingen angefangen. Oft ist der Start eine kleine Erweiterung für unseren Bot. Da ist die Hürde besonders niedrig.

Das ist ein bisschen so wie bei uns die Nähmaschine: Es gibt zwar selten Projekte, die hauptsächlich aus Nähen bestehen, aber wir waren schon oft froh, sie zu haben. Natürlich kann man nicht jedes Werkzeug haben, aber es ist immer schade, wenn ein Projekt daran scheitert.

Danke für eure Erfahrungsberichte! Die Herausforderungen halte ich für machbar, da wir alle auch nicht vollkommen unerfahren sind. Meinem Eindruck nach sind die Grenzen zwischen Hacker- und Makerspace fließend. Und eine reine Werkstatt sind wir nicht, dafür machen wir zu viel mit IT. Ich sehe hier Chancen, dass uns das bereichert und unsere Zielgruppe erweitert. :slight_smile:

Technische Details wie RAID1, Rechtesystem, sichere Authentifizierung, Backups und Verschlüsselung sehe ich als selbstverständliches Must-have an, über die Umsetzung kann man diskutieren. Es soll auch zuverlässig funktionieren. :slight_smile: Zumindest bei Hetzner kann man sich temporär eine KVM anschließen lassen, die dann über das Webinterface erreichbar. Ist keine IPMI, brauchen wir aber nicht. Wir haben aktuell keinen Bedarf nach Enterprise Hardware oder maximaler Ausfallsicherheit. Ein kleines externes Monitoring, welches einfach eine Mail schickt beim Ausfall halte ich aber für sinnvoll.

Eine HDD scheint mir im günstigen Segment bei uns gerade auch die bessere Wahl. Sollte die Performance zu schlecht sein, muss man wohl aufrüsten. Dann lohnt es sich aber auch, da der Bedarf definitiv vorhanden ist.

Ich denke es bieten sich auch zahlreiche Möglichkeiten für Mitglieder einen HV öffentlich bereitzustellen, wo womöglich eigene Projekte z.B. in Containern laufen können. Ein Admin sollte das dann begleiten. Ein Rollenkonzept und eine Trennung von kritischen Systemen ist da selbstverständlich. Man könnte Zugriff zu Projekten z.B. über einen VPN lösen, damit diese nicht direkt aus dem Internet erreichbar sind. Oder spricht da was gegen?

Gute Planung und Dokumentation helfen, das System langfristig zu warten. Es ist auch schön, wenn sich mehr als eine Person mit etwas auskennt. Da müssen wir wohl eine Lösung finden.:slight_smile:

Ein gelegentlicher Einblick und Austausch zur Orientierung würde uns sicherlich helfen.

Die Erreichbarkeit über IPv6 ist doch letztendlich eine Frage der Zeit. Die Eigentümerfrage und das angewendete Gesetz ist für mich eine Frage der Werte… Aktuell bin ich mich mit Github fein, aber das ändert sich vielleicht, wenn Onkel Donald seinen Putschversuch erfolgreich durchgeführt hat.

Eine Variante die ich mag. Spricht aus deiner Sicht sonst was gegen private Repos auf Github? Ja, die können Theoretisch reingucken - aber mir geht es darum, dass Zugang erst einmal nur beschränkt ist.

Danke für die Erweiterung der Tabelle. Damit sollten wir einen Einkaufsratgeber aufmachen. :smiley: Ich tendiere immer noch zu „Buy“ wegen der Einfachheit. Mit der Entsorgung der Platten hast du aber einen guten Punkt, da müssen wir in den Vertrag gucken und ggf. nachfragen!

Einen dicken Server nur für Minecraft? Eher nicht. Aber wir spielen schon häufiger mit dem Gedanken, die Services selbst bereit zu stellen.

Ein sehr guter Punkt. Da kann man aber schauen, wie so die Politik in der Vergangenheit war. Weiterhin sollte es gut erprobte Software sein mit guter Dokumentation! Mir gefallen sehr die Projekte von RedHat. Die Pakete in RHEL sind vielleicht nicht so zahlreich im default, dafür aber quasi für 10 Jahre gepflegt. Als freie Variante nutzt man einfach CentOS und Co. und verwendet die RHEL Doku, welche sich an ein Unternehmensumfeld richten. Da fand ich neben dem ArchWiki bisher die tiefste und verständlichste Dokumentation, welche einen zum Einstieg mit etwas Vorwissen auch gut einführt. Eine Subscription braucht man dafür nicht. Wenn man noch ein System wie CentOS einsetzt, funktioniert auch alles auf Anhieb und muss nicht zwangsläufig auf exklusive Besonderheiten der anderen Distribution achten.

Hat sich von euch mal jemand ovirt angeschaut? Ich habe es mal in meinem Homelab ausprobiert, fand es aber zu mächtig für einen kleinen Server.

Das System sollten wir natürlich in einem Laborsystem vorbauen und Erfahrung sammeln. Ich habe noch entsprechende Hardware, die wir z.B: in den Space stellen können.