Bearbeiten von „UUGRN:HetznerCloud“

In der Hetzner-Cloud betreiben wir aktuell VMs, die in naher Zukunft die UUGRN-eigenen Dienste übernehmen sollen.

{{Navigationsleiste UUGRN}}
{{Navigationsleiste Netze}}
{{Navigationsleiste Systeme}}
{{Navigationsleiste Dienste}}

== VM-Konzept ==

{|- class="wikitable"
|+ 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 [http://lists.uugrn.org/uugrn/19/11/17285.html 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 [https://console.hetzner.cloud/projects 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!
@@ Zeile 156: / Zeile 156: @@
 To be defined.
-==== Wie es die Distributionen machen ====
+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.
-===== 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)
@@ Zeile 197: / Zeile 169: @@
 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!