UUGRN:HetznerCloud

Aus UUGRN

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/XMPP irc.uugrn.org 78.47.187.121 2a01:4f8:c0c:3c0c::1/64 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/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.

Vorschlag: Ein User "uugrnvorstand", der sudo machen darf, und auf dem die Keys der aktuellen Vorstände + Notfalladmins hinterlegt sind, am besten mit automatischer Verteilung . Keys rotieren braucht's nicht an dieser Stelle.

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".

Not-Root-Zugang für den Vorstand

To be defined.

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!

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