UUGRN:Infrastruktur: Unterschied zwischen den Versionen

Aus UUGRN
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 10: Zeile 10:
* {{Systeme}}, also echtes Blech mit Strom und Internet, Storage und Betriebssystem drauf.
* {{Systeme}}, also echtes Blech mit Strom und Internet, Storage und Betriebssystem drauf.
* {{Jails}}, Infrastruktur in [[FreeBSD]] zur Trennung mehrerer Dienste voneinander.
* {{Jails}}, Infrastruktur in [[FreeBSD]] zur Trennung mehrerer Dienste voneinander.
* {{HetznerCloud}}, Infrastruktur in virtuellen Servern der Hetzner Cloud
* {{UUGRN:HetznerCloud}}, Infrastruktur in virtuellen Servern der Hetzner Cloud
* {{Dienste}}, durch Software implementierte Infrastruktur
* {{Dienste}}, durch Software implementierte Infrastruktur


Version vom 28. Dezember 2019, 18:03 Uhr

UUGRN betreibt seine Infrastruktur weitgehend eigenständig.

[ Verein: Server: • top4 • higgsBeta ]
[ Vereinsjails: mail • mx1 • mysql • lists • wiki • blogs • pad • proxy • uugrn • shell • irc • bnc • news • ftp • fbsd9 • gitAlpha • calendarAlpha ]
[ Mitglieder-Jails: shell • mile • rabe • trickster • che • friedel • shl • hdi • ltrn ]

öffentliche→  Mailingliste (Mailinglistenarchiv) • Wiki • Pad • IRC • Jobs • Webseite • FTP Für Mitglieder→  Intranetalpha • Shells • Jails • Webspace • MySQL • Usenet • Blogs • BNC • Mailman Infrastruktur→  Mail • DNS • Backup • Proxy • ircbot • Buildsystem

Öffentliche →   • IRC Chat • Drawing Pad • Ascii Pad • Text Pad • Vorstand Infoshare  Für Mitglieder →   • Shell Account • Usenet Zugang  Infrastruktur →   • DNS   <edit>

Unterteilung

  • Netzwerke, IP-Netzwerke
  • Server, also echtes Blech mit Strom und Internet, Storage und Betriebssystem drauf.
  • Jails, Infrastruktur in FreeBSD zur Trennung mehrerer Dienste voneinander.
  • In der Hetzner-Cloud betreiben wir aktuell VMs, die in naher Zukunft die UUGRN-eigenen Dienste übernehmen sollen.

[ Verein: Server: • top4 • higgsBeta ]
[ Vereinsjails: mail • mx1 • mysql • lists • wiki • blogs • pad • proxy • uugrn • shell • irc • bnc • news • ftp • fbsd9 • gitAlpha • calendarAlpha ]
[ Mitglieder-Jails: shell • mile • rabe • trickster • che • friedel • shl • hdi • ltrn ]

öffentliche→  Mailingliste (Mailinglistenarchiv) • Wiki • Pad • IRC • Jobs • Webseite • FTP Für Mitglieder→  Intranetalpha • Shells • Jails • Webspace • MySQL • Usenet • Blogs • BNC • Mailman Infrastruktur→  Mail • DNS • Backup • Proxy • ircbot • Buildsystem

Öffentliche →   • IRC Chat • Drawing Pad • Ascii Pad • Text Pad • Vorstand Infoshare  Für Mitglieder →   • Shell Account • Usenet Zugang  Infrastruktur →   • DNS   <edit>

VM-Konzept

VM-Konzept
Projekt Hostname IPv4 IPv6 Admin Backup-Admin
Mailserver mail.uugrn.org 78.47.100.66 2a01:4f8:c0c:4957::1/64 Sur5r, Zugschlus Anna
Shell-Server shell.uugrn.org 88.99.225.249 2a01:4f8:c0c:4fe4::1/64 Zugschlus
UUGRN-Webserver www.uugrn.org 88.99.226.54 2a01:4f8:c0c:4fe6::1/64 Anna
DNS dns1.uugrn.org 88.99.225.64 2a01:4f8:c0c:4fc9::1/64 Zugschlus
IRC irc.uugrn.org 78.47.187.121 2a01:4f8:c0c:3c0c::1/64 Sdk
XMPP/ZNC chat.uugrn.org tinfoil-hat
Vorstand vorstand.uugrn.org Sdk
Blog blogs.uugrn.org 88.198.77.4 2a01:4f8:c0c:4fea::1/64 Flow
Nextcloud Flow
Pad Andi Sdk
Blech N.N.


Die VMs haben derzeit noch keine Forward DNS-Einträge. Das temporäre Anlegen von hostname.new.uugrn.org ist möglich.

Grundsätze

Der "Admin" eines Projekts ist in Auswahl der Art und Weise, das Projekt zu installieren, administrieren und zu betreiben, völlig frei. Das betrifft insbesondere die Auswahl von Betriebssystem, Applikationssoftware, Beiwerk und Administrationstechniken. Auch Automatisierung darf betrieben werden. Der Verein freut sich, wenn die Admins auf dem FIXME ihre umgesetzten Konzepte vorstellen und/oder in IRC oder auf Mailingliste ihre Konzepte zur Diskussion stellen und/oder sich Rat und Hilfe holen.

Die Aufgabe der Admins ist, die Services in ihrer Verantwortung zum Laufen zu bringen und am Laufen zu halten. Vorhandene Daten sollten migriert werden (dort wo nötig).

Keiner muss hier eine Uptime-Garantie abgeben und in Urlaub fahren dürft ihr auch ;)

Wir betreiben hier keine "Mission Critical" Infrastruktur, daher könnt ihr das entspannt sehen.

Anforderungen

Aktuell hier und im daran hängenden Thread beschrieben, die Inhalte dürfen gerne in Wiki-Seiten übertragen werden. Wenn mir jemand beim Anlegen der Seiten hilft (Kategorienamen und Wikibereiche hab ich nicht drauf), kann ich hier selbst weitermachen.

  • Mail
  • Shell
  • Web
  • IRC
  • ZNC/XMPP
  • Blogs
  • Nextcloud
  • Etherpad
  • NNTP
  • DNS

Neuprojekte

  • git
  • Vorstands-VM

Abschussliste

  • proxy: Jede VM hängt direkt am Netz
  • mysql: Kann bei Bedarf auf der VM laufen die es benötigt (lös die Abhängigkeit zu einem zentralen MySql Admin).
  • news/status: Wurde nie gepflegt.
  • acme: Soll auf dem DNS Server laufen.
  • cgiirc: Wird das verwendet?

Administration der Cloud-Server

Für jedes Projekt der obigen Tabelle ist in der Hetzner Cloud Console ein eigenes Projekt angelegt, dem die virtuelle(n) Maschine(n) zugeordnet sind.

Für die Administration der Cloud-Server (Rescue, Reset, Start, Stop) ist ein Hetzner-Account notwendig. Wer sich davor scheut, einen anzulegen, möge sich an Sdk wenden. Um zu einem Projekt hinzugefügt zu werden, muss man seinen Hetzner-Account an den Vorstand melden. Ist man frisch zu einem Projekt hinzugefügt, bekommt man eine Einladung per E-Mail zugeschickt. Nach dem Akzeptieren der Einladung mit einem Browser, der JavaScript erlaubt, sieht man das Projekt und die VMs.

Admins und Metaadmins sind den passenden Projekten zugeordnet und können alle notwendigen Aktionen auslösen. Davon ausgenommen sind Aktionen, die Kosten erzeugen wie z.B. das Löschen und Neu anlegen der VM. Zusätzliche oder größere VMs können vom Vorstand angelegt werden.

Hat man in seinem Hetzner-Account ssh-Keys hinzugefügt, kann beim Anlegen einer neuen VM verfügt werden, welche Keys für root auf der VM hinterlegt werden sollen. Das funktioniert leider nur bei der Neuanlage einer neuen VM, nicht bei der Neuinstallation einer bereits bestehenden VM. In diese muss man sich mit dem bei der Neuinstallation veschickten root-Passwort einloggen oder sich über die Cloud Console ein neues root-Passwort setzen und dann die bevorzugte Zugriffsmethode manuell einrichten.

Bei der Neuinstallation einer VM kann man entweder ein vorgefertigtes Hetzner-Image auswählen oder sich eine virtueller Installer-CD des bevorzugten Betriebssystems in das virtuelle CD-ROM-Laufwerk der VM einlegen lassen und den Installer dann über die virtuelle Konsole bedienen. Auf diese Weise kann man z.B. auch ein Rescue-System der gewünschten Provinienz starten.

Backup / Snapshots

To be defined.

Accountmanagement

To be defined.

Wie es die Distributionen machen

Debian

Debian definiert in https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes:

  • 0-99 belong to the Debian project (static users present on all systems)
  • 100-999 belong to the package manager (dynamically allocated system users, adduser --system)
  • 1000-64999 belong to the local administrator
  • 65000-64999: belong to the Debian project, oinly created on demand
  • 65000-65533: reserved
andere Betriebssysteme

Die Gepflogenheiten anderer Distributionen / Betriebssysteme bite hier einpflegen

Vorschlag

Vorschlag: UUGRN-User sind im Bereich 30000-49000 angesiedelt, M sei die beim Vorstand erfragbare Mitgliedsnummer, dann ist die UI M*100+30000. Die UID zum Mitglied mit der Nummer 53 wäre also 35300.

Im Bereich ab 2000 sind adminsitrative User angesiedelt:

  • 2100: "uugrnadmin" für den Einstieg per ssh, falls der normale User eines Admins nicht funktioniert (darf sudo machen)
  • 2200: "uugrnvorstand" für den Vorstand (darf sudo machen, ssh-Keys von Vorstand + Notfalladmins sind hinterlegt)
  • 2530: zgansible: User für Marcs Ansible

Die Keys der aktuellen Vorstände + Notfalladmins sollten am besten automatischer verteilt werden. Keys rotieren braucht's nicht an dieser Stelle.

Visionen

So ein bischen automagischer Datenaustausch wäre auch ganz nett. Irgend ne API, die man ein wenig zentral füttern und dann abfragen kann.

Sowas wie:

  • gib mir ssh pubkeys für nick foobar (response pubkey)
  • ist foobar mitglied (response ja/nein)
  • gib mir cert für domain.tld (response cert)
  • gib mir mitgliederliste (response liste)

API könnte in dem fall auch ein CSV sein an welches man per SSH rankommt. Oder irgenwas, was auf ne curl Anfrage antwortet (nach basic auth).

Alternativ darf der Vorstand auch über das Rescuesystem in eine VM "einbrechen".

Best Pratices bei der Systemadministration

Die in diesem Abschnitt beschriebenen Praktiken sind keine Verpflichtungen, sondern nur Empfehlungen der "alten Hasen" unter den Systemadministratoren. Es gibt mehr als einen Weg um die Dinge zu tun!, Infrastruktur in virtuellen Servern der Hetzner Cloud

  • Dienste, durch Software implementierte Infrastruktur

Grundsätzliches

Die UUGRN betreibt eigene Systeme zur Erbringung eigener Dienste (Web, Mail etc) und bietet ihren Mitgliedern FreeBSD-Jails und virtuelle Maschinen zur Eigennutzung an.

Aktuell verfügt die UUGRN über Server, also echtes Blech, auf dem sowohl für die eigenen Dienste als auch für die Mitglieder FreeBSD-Jails betrieben werden. Der Ersatz durch echtes Blech mit einer vollwertigen Virtualisierungslösung, die sowohl den Betrieb beliebiger (auf x86_64 lauffähiger) unixoider Betriebssysteme erlaubt als auch Linux-Container und FreeBSD-Jails unterstützt.

Im Moment migrieren wir die eigenen Dienste in die Vorlage:HetznerCloud, um die unabhängige Adminstration der Dienste durch unterschiedliche Menschen einfacher zu machen.

Abgerufen von „https://wiki.uugrn.org/index.php?title=UUGRN:Infrastruktur&oldid=12547“