UUGRN:HetznerCloud: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „In der Hetzner-Cloud betreiben wir aktuell VMs, die in naher Zukunft die UUGRN-eigenen Dienste übernehmen sollen. {{Navigationsleiste UUGRN}} {{Navigationsle…“) |
Keine Bearbeitungszusammenfassung |
||
Zeile 10: | Zeile 10: | ||
{|- class="wikitable" | {|- class="wikitable" | ||
|+ VM-Konzept | |+ VM-Konzept | ||
! | ! Projekt | ||
! Hostname | ! Hostname | ||
! IPv4 | ! IPv4 | ||
Zeile 80: | Zeile 80: | ||
| | | | ||
|} | |} | ||
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/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! |
Version vom 12. Dezember 2019, 21:07 Uhr
In der Hetzner-Cloud betreiben wir aktuell VMs, die in naher Zukunft die UUGRN-eigenen Dienste übernehmen sollen.
Übersicht
• Community
• Verein
• Mitgliedschaft
• Unterstützung
• Mitgliederversammlung
• Vorstand
• Satzung
• Impressum
• Webseite
• Merchandising
• Chronik>
Kernangebote:
Real Life
• UnixStammtisch
• FIXME Treffen
• Die Mailingliste
• IRC
• Alle Angebote
• Infrastruktur
• Alle Dienste
• Alle Systeme
• FAQ
[ 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
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.
- 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!