Bereichsleitung Administration Rechentechnik/Einarbeitung

Entscheidung für FreeBSD

Server#FreeBSD

• FreeBSD#Jails
• FreeBSD#ZFS
• freie Software
• Stabilität
• …

Entscheidung für FreeNAS

FreeBSD "zum Klicken"

Entscheidung für Proxmox

Ab 2017 wurde sich als - wegen einem der neuen Mitglieder - mit Proxmox auseinandergesetzt. Die AG DSN nutzt beispielsweise Proxmox. In Anlehnung an die frühere

Medien zur Einarbeitung

• YouTube: Channel bsdconferences (video content about BSD)

RZ HTW Dresden

Das RZ unserer HTW Dresden wünscht sich gern (möglichst konkrete) Ansprechstelle.

Wie vielen Stellen an unserer HTW Dresden fällt es dem RZ schwer zu begreifen, dass es beim StuRa schwer möglich ist langfristige (mehrjährige) Ansprechpersonen zu benennen. Ferner begreifen das RZ den StuRa wie eine beliebige andere Dienststelle, etwa eine Fakultät.

Daher ist es insbesondere wichtig, dass dem RZ bekannt ist, wer gerade die Ansprechstelle ist. Letztlich läuft das es aber auf "persönliche" Bezüge hinaus. Die Aussage Frau oder Herr $name ist jetzt für die Rechentechnik beim StuRa und damit direkt für sie, das Rechenzentrum unserer HTW Dresden, die zentrale Ansprechperson. wäre wohl dem RZ am liebsten.

Sinnvoll ist auch das Abklären, wer was "Anweisen" darf. Bitte besprecht das immer mit eurer zuständigen Referatsleitung und den Sprecherinnen und Sprechern.

Hardware

Server als Hardware des StuRa sind

• dicke Berta und
• fette Elke.

Darüber hinaus gibt es noch weitere Server als Hardware. Das sind mindestens

• mollige Dörte Konferenz Sächsischer Studierendenschaften/Server,
• Fachschaftsrat Elektrotechnik/Server und
• Fachschaftsrat Wirtschaftswissenschaften/Server.

Die Server gehören zu anderen Organisationen. Die Hardware wurde "nur" beim StuRa angesiedelt. Das hat mehrere Gründe. Maßgeblich ist der Serverschrank und damit Verbundenes. Wegen den Servern für den StuRa gab es ja ohnehin den Betrieb. So kam es dazu, dass durch die gute Zusammenarbeit auch der Hardware anderer Obdach gewährt wurde. (Es wäre ja vollkommener Quatsch, dass sich die anderen Organisationen einen weiteren Serverschrank und sowas besorgt hätten.)

Die Server anderer Organisationen sollten auf dem Schirm gehalten werden. In jedem Einzelfall ist zu bewerten wie die gemeinsame Betreuung der Hardware erfolgen muss. Praktisch bedeutet das, dass bei dieser Hardware nicht einfach ohne Absprache Maßnahmen vorgenommen werden können. Oder anders gesagt: Entscheidungen können nicht einfach nur im Bereich Administration Rechentechnik gefällt werden.

Zugang

ssh als üblicher Zugang zu Servern

Warum ssh verwendet wird bedarf hoffentlich keiner Erklärung, oder?

Für die Server (als Host) sollte eigentlich nie ein Anmelden mit dem Account root möglich sein. Gar kann es sein, dass es gar keinen Account root gibt. (Bei vielen Systemen, insbesondere in der Welt von GNU/Linux ist das ja sogar ohnehin üblich.) Daher sollte für jede Person ein persönlicher Account angelegt werden. Das teilen von einem Account (durch mehrere Personen) ist nicht angedacht (als #Policy untersagt).

Für das "ordentlich" Anmelden wird das (Erstellen, Hinterlegen und) Verwenden persönlichen Schlüsseln (etwa im Sinne von How To Setup SSH Keys on a Linux / Unix System) dringlich angeraten. Also einfach den Menschen, die aktuell administrativen Zugriff haben, das Pseudonym oder den bürgerlichen Namen nennen und passend den personenbezogenen öffentlichen Schlüssel für ssh bereitstellen und eintragen lassen.

Siehe auch

• FreeBSD Handbook: Part System Administration - Chapter Security - OpenSSH
• FreeBSD Committer's Guide: SSH Quick-Start Guide

Erstellen von einem Schlüsselpaar für ssh

ssh-keygen -t Ed25519 -f ~/.ssh/stura-htw-dresden_server.ssh.key -C "mein persönlicher Schlüssel für ssh zur Verbinden mit dem Server vom StuRa HTW Dresden"

Ausgeben des geheimen Schlüssels für ssh

cat ~/.ssh/stura-htw-dresden_server.ssh.key

Ausgeben des öffentlichen Schlüssels für ssh

cat ~/.ssh/stura-htw-dresden_server.ssh.key.pub

Kopieren des öffentlichen Schlüssels für ssh auf den Server

ssh-copy-id -p <port-for-ssh-on-server> -i ~/.ssh/stura-htw-dresden_server.ssh.key.pub root@srs

Alternativ könnte sich auch einfach auf den Server angemeldet werden und die Ausgabe des öffentlichen Schlüssels für ssh mit einem Editor in die Datei ~/.ssh/authorized_keys eingetragen werden.

Verbinden auf den Server per ssh

ssh -p <port-for-ssh-on-server> -i ~/.ssh/stura-htw-dresden_server.ssh.key root@srs

Policy

Nachfolgende Prinzipien sind zwangsläufig anzuwenden. Eine Änderung bedarf der Klärung im Bereich Administration Rechentechnik.

Achtung

Die nachfolgende Aufzählung ist (noch) nicht abschließend. Nicht benannte oder fragwürdige Verhaltensweisen sind mit dem Bereich Administration Rechentechnik zu klären.

• Dokumentation findet im Wiki statt!
  • Vom Wiki kann an weitere Stellen (als Orte) verwiesen werden.
  • Dokumentation soll mindestens so nachvollziehbar sein, dass (nahezu) ein Reproduzieren möglich wäre.
• Passwörter sind spätestens bei der Erzeugung zu dokumentieren.
  • Passwörter sind nicht (vollständig) im Wiki abzulegen. Jedoch kann (soll) eine Liste der Passwörter (ohne die Passwörter selbst) mit Hinweisen bei Intern:Server#Zugangsdaten vervollständigt sein.
  • Passwörter sind zentral in einem dafür vorgesehenen Ordner#Zugangsdaten abzulegen.
• Für Verbindungen zum administrativen Zugriff erfolgen ausschließlich per ssh.
  • Die Verwendung von http oder anderen Protokollen zum administrativen Zugriff ist ausschließlich durch die Verbindung per ssh vorgesehen. Alles andere ist nicht erwünscht und soll abgestellt werden.
• Ausschließlich personenbezogene Accounts sind anzulegen und zu verwenden.
  • Accounts für Gruppen sind nicht vorgesehen. Das Teilen von Passwörtern ist daher auch nicht vorgesehen. Personenbezogene Accounts können selbstverständlich Gruppen (etwa mit bestimmten Rechten) zugeordnet werden. Das Erstellen von Gruppen und das Zuweisen von bestimmten Rechten ist geeignet zu dokumentieren.
  • Die Bezeichnung eines jeden Accounts zum administrativen Zugriff muss nachvollziehbar sein. Pseudonyme sind selbstverständlich zulässig. Personenbezogene Pseudonyme müssen aber immer erreichbar sein. (Das kann klassischer Weise per Mail-Adresse pseudonym@stura.htw-dresden.de gelöst sein.)
  • Im Zweifelsfall (ohne Pseudonym) sind Accounts als CamelCase aus dem bürgerlichen Namen, als VornameNachname, zu bezeichnen.
  • Für die Erstellung von üblichen Accounts (durch den Bereich Administration Rechentechnik und den Bereich Webservices) gilt grundsätzlich das Prinzip CamelCase aus dem bürgerlichen Namen, als VornameNachname, als Bezeichnung.

E-Mail

Mail-Adressen einrichten

• Mail-Adresse#Einrichtung person@stura.htw-dresden.de
• Mail-Adresse#Einrichtung funktion@stura.htw-dresden.de
• Intern:Mail-Adresse#Einrichtung

Siehe auch

• Server/Einarbeitung