Bereichsleitung Administration Rechentechnik/Einarbeitung: Unterschied zwischen den Versionen

Aus Wiki StuRa HTW Dresden
Zur Navigation springen Zur Suche springen
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Entscheidung für FreeBSD ==
== 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 ==
== Medien zur Einarbeitung ==
Zeile 5: Zeile 20:


== Veranstaltungen zur Einarbeitung ==
== Veranstaltungen zur Einarbeitung ==
== [[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 <code>$name</code> ist jetzt für die Rechentechnik beim StuRa und damit direkt für sie, das Rechenzentrum unserer HTW&nbsp;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 [[Referatsleitung studentische Selbstverwaltung & Organisation|eurer zuständigen Referatsleitung]] und den [[Sprecherinnen und Sprecher]]n.


== Hardware ==
== Hardware ==
Zeile 24: Zeile 33:
: 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 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.
:: 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.
== Software ==
<!--
==== Benennung von verwendeter Software ====
!-->
; Siehe auch: [[website:stura/ref/verwaltung/admin/software]]
Mindestens des Dankes und der Transparenz halber Pflegen wir eine "öffentlichkeitswirksame" [[website:stura/ref/verwaltung/admin/software| Seite ''Software'' auf der Website]]. Darüber hinaus gibt es den Artikel [[Software]]. Die Seiten sollen aktuell gehalten werden.


== Zugang ==
== Zugang ==
Zeile 33: Zeile 52:
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 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 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.
Für das "ordentlich" Anmelden wird das (Erstellen, Hinterlegen und) Verwenden persönlichen Schlüsseln (etwa im Sinne von [https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/ 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:
; Siehe auch:
* [https://www.freebsd.org/doc/handbook/openssh.html FreeBSD Handbook: </small>Part ''System Administration'' - Chapter ''Security'' -</small>''OpenSSH'']
* [https://www.freebsd.org/doc/handbook/openssh.html FreeBSD Handbook: <small>Part ''System Administration'' - Chapter ''Security'' - </small>''OpenSSH'']
* [https://www.freebsd.org/doc/en/articles/committers-guide/ssh.guide.html FreeBSD Committer's Guide: ''SSH Quick-Start Guide'']
* [https://www.freebsd.org/doc/en/articles/committers-guide/ssh.guide.html FreeBSD Committer's Guide: ''SSH Quick-Start Guide'']
Erstellen von einem Schlüsselpaar für ssh
:: <!-- Erklärung von den einzelnen ergänzenden Parametern !-->
: <code>[[man:ssh-keygen|ssh-keygen]] [https://wiki.archlinux.org/index.php/SSH_keys#Ed25519 -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"</code>
Ausgeben des geheimen Schlüssels für ssh
: <code>cat ~/.ssh/stura-htw-dresden_server.ssh.key</code>
Ausgeben des öffentlichen Schlüssels für ssh
: <code>cat ~/.ssh/stura-htw-dresden_server.ssh.key.pub</code>
Kopieren des öffentlichen Schlüssels für ssh auf den Server
: <code>[[man:ssh-copy-id|ssh-copy-id]] -p <port-for-ssh-on-server> -i ~/.ssh/stura-htw-dresden_server.ssh.key.pub root@[[Intern:Server|srs]]</code>
:: 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
: <code>[[man:ssh|ssh]] -p <port-for-ssh-on-server> -i ~/.ssh/stura-htw-dresden_server.ssh.key root@[[Intern:Server|srs]]</code>


== Policy ==
== Policy ==
Zeile 67: Zeile 99:
* [[Mail-Adresse#Einrichtung funktion@stura.htw-dresden.de]]
* [[Mail-Adresse#Einrichtung funktion@stura.htw-dresden.de]]
* [[Intern:Mail-Adresse#Einrichtung]]
* [[Intern:Mail-Adresse#Einrichtung]]
== Zusammenarbeit ==
=== [[StuRa]] ===
==== [[Bereich Webservices]] ====
Selbstverständlich gibt es eine gute Zusammenarbeit mit dem [[Bereich Webservices]]. Ohneeinander geht es einander nicht.
Es gibt eine [[Bereich Administration Rechentechnik#Abgrenzung zum Bereich Webservices | Abgrenzung zum Bereich Webservices]], die es allen Beteiligten einfachen machen soll. Das Mitwirken in beiden Bereichen ist gern gesehen, jedoch aber eben keine Pflicht. Die Abgrenzung sollte schon alleine dazu dienen, dass sich Einzelne, die nur eine bestimmte Perspektive an Aufgaben verantwortlich gegenüber sehen konnten, auch einsteigen können. Es soll kein Mensch Angst haben verwaltungstechnische Belange oder Webdesign an der Backe zu haben, obwohl er nur Container oder Hardware machen wollte. Gleichermaßen soll kein Mensch, der sich um die Verwaltung Gruppen mit ihren Berechtigungen kümmern wollte, plötzlich auch ums Netzwerk im Serverschrank kümmern müssen.
=== [[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 <code>$name</code> ist jetzt für die Rechentechnik beim StuRa und damit direkt für sie, das Rechenzentrum unserer HTW&nbsp;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 [[Referatsleitung studentische Selbstverwaltung & Organisation|eurer zuständigen Referatsleitung]] und den [[Sprecherinnen und Sprecher]]n.


== Siehe auch ==
== Siehe auch ==

Aktuelle Version vom 5. Dezember 2017, 10:26 Uhr

Entscheidung für FreeBSD[Bearbeiten]

Server#FreeBSD

Entscheidung für FreeNAS[Bearbeiten]

FreeBSD "zum Klicken"

Entscheidung für Proxmox[Bearbeiten]

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[Bearbeiten]

Veranstaltungen zur Einarbeitung[Bearbeiten]

Hardware[Bearbeiten]

Server als Hardware des StuRa sind

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

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.

Software[Bearbeiten]

Siehe auch
website:stura/ref/verwaltung/admin/software

Mindestens des Dankes und der Transparenz halber Pflegen wir eine "öffentlichkeitswirksame" Seite Software auf der Website. Darüber hinaus gibt es den Artikel Software. Die Seiten sollen aktuell gehalten werden.

Zugang[Bearbeiten]

ssh als üblicher Zugang zu Servern[Bearbeiten]

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

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[Bearbeiten]

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[Bearbeiten]

Mail-Adressen einrichten[Bearbeiten]

Zusammenarbeit[Bearbeiten]

StuRa[Bearbeiten]

Bereich Webservices[Bearbeiten]

Selbstverständlich gibt es eine gute Zusammenarbeit mit dem Bereich Webservices. Ohneeinander geht es einander nicht.

Es gibt eine Abgrenzung zum Bereich Webservices, die es allen Beteiligten einfachen machen soll. Das Mitwirken in beiden Bereichen ist gern gesehen, jedoch aber eben keine Pflicht. Die Abgrenzung sollte schon alleine dazu dienen, dass sich Einzelne, die nur eine bestimmte Perspektive an Aufgaben verantwortlich gegenüber sehen konnten, auch einsteigen können. Es soll kein Mensch Angst haben verwaltungstechnische Belange oder Webdesign an der Backe zu haben, obwohl er nur Container oder Hardware machen wollte. Gleichermaßen soll kein Mensch, der sich um die Verwaltung Gruppen mit ihren Berechtigungen kümmern wollte, plötzlich auch ums Netzwerk im Serverschrank kümmern müssen.

RZ HTW Dresden[Bearbeiten]

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.

Siehe auch[Bearbeiten]