Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:administration [2020/01/16 15:42]
flacco [DNS Forwarder anpassen]
+++ invis_server_wiki:administration [2021/08/17 05:50]
flacco [Online Updates]
@@ Zeile 405: / Zeile 405: @@
   * **Fix Groupshare ACLs** - Damit können „verkorkste“ Zugriffs-ACLs für die Gruppen-Arbeitsverzeichnisse in der Gruppen-Freigabe auf die Anfangswerte zurück gesetzt werden. Gleichzeitig werden Verzeichnisse, die manuell auf der obersten Ebene der Gruppen-Freigabe angelegt wurden umbenannt, indem die Endung „-bitte_Support_anrufen“ an die Verzeichnisnamen anhängt wird.
   * **Software-Versionen prüfen** - Gibt die Versionsnummern wichtiger auf dem Server installierter Software aus.
+  * **Benutzerdaten bereinigen** - (Ab Version 14.2) Wird ein Benutzerkonto gelöscht, verbleiben dessen Kopano- und ownCloud-Daten im jeweiligen System. Sie können über diese Funktion unter Angabe des Benutzernamens **endgültig** gelöscht werden.
 Die Integration weiterer Scripts ist in Planung.
@@ Zeile 706: / Zeile 707: @@
 Sorgen Sie dafür, dass Ihr invis Server über den Maintenance-Zeitraum der zugrunde liegenden openSUSE Version immer mit den aktuellen Sicherheits-Updates versorgt wird.
-invis-Server bringen seit Version invisAD 10.1 ein "Updater Script" mit. Gedacht ist es als "fire & forget" Updater für funktionsunkritische Sicherheitsaktualisierungen. Es werden dabei bestimmte Updates wie etwa solche installierter SQL-Dienste und auch Updates die einen Neustart erfordern ausgeklammert. Das Script kümmert sich selbsttätig um das Neustarten betroffener Dienste und die Anwendung des invis //**afterup**// Scripts. Rufen sie es einfach ohne weitere Optionen auf:
+Dabei ist zwischen dem Aktualisieren aller installierten Pakete und dem exklusiven Installieren von Sicherheitsupdates der Distribution. Ersteres ist nicht ganz frei von Gefahren. Beim Aktualisieren aller Pakete könnte beispielsweise auch das invis-Server Setup-Paket installiert werden. Das ist solange ungefährlich, wie dieses Paket keine strukturellen Änderungen am Server vornimmt. Ist dies doch der Fall kann die Funktionsweise des Servers erheblich gestört werden. Lesen Sie dafür hier im Wiki die Beschreibungen im Abschnitt Server Upgrade.
-<code>
+Wenn Sie wissen, was Sie tun läuft eine vollständige Aktualisierung wie folgt ab:
-invis:~ # invis-updater
-</code>
-Eine vollständige Aktualisierung können Sie mit //**zypper**// durchführen:
 <code>
@@ Zeile 720: / Zeile 717: @@
 </code>
-Es ist weder notwendig noch ratsam ein "Distribution Upgrade" mit **//zypper dup//** durchzuführen.
+//**Hinweis:** Es ist weder notwendig noch ratsam ein "Distribution Upgrade" mit **zypper dup** durchzuführen!//
 Möchten Sie lediglich die Sicherheitspatches der Distribution installieren können Sie dies mit "YaST Online Update" (kurz: you) erledigen:
@@ Zeile 728: / Zeile 725: @@
 </code>
+Dabei werden definitiv nur Patches installiert, die keine strukturellen Veränderungen am Setup mitbringen.
 ==== SMTP-Relay / SMTP-Auth  für Postfix einrichten ====
 invis Server sind meist via DSL mit dem Internet verbunden, verfügen also nicht über eine dauerhafte Internet-Anbindung. Das macht sie aus Sicht vieler Internet-Mailserver **zurecht** nicht vertrauenswürdig. Um aus dieser Situation heraus zuverlässig Emails versenden zu können, wird für den Mailversand eine Relais-Station (Relay-Server) benötigt, die uns vertraut. Dabei handelt es sich eigentlich um nichts anderes als die Konfiguration eines Postausgangsservers, so wie das auch in Mail-Clients gemacht wird.
@@ Zeile 799: / Zeile 797: @@
 Nebenstehend erläutert ein Ablaufdiagramm die Funktionsweise des Scripts.
-Es ist dem Script, im Unterschied zu seinen Vorgängern, nicht mehr möglich noch gültige Zertifikate zu erneuern. Damit verstößt //**inviscerts**// nicht mehr gegen gängige Regeln der Zertifikatsverwaltung.
 Die voreingestellten Lebensdauern der Server- und Client-Zertifikate beträgt 730 Tage, also 2 Jahre. Die Lebensdauer der CA selbst liegt bei 10 Jahren. Ändern lässt sich dies in: <file>/etc/easy-rsa/vars</file> Notwendig ist das aber nicht.
@@ Zeile 831: / Zeile 827: @@
 Weitere Informationen zum Umgang mit easyRSA sind im deutschsprachigen Wiki von OpenVPN zu finden: [[http://wiki.openvpn.eu/index.php/Erzeugen_einer_PKI_mit_EasyRSA|OpenVPN Wiki]]
+**Individuelle Zertifikate**
+Werden weitere individuelle Server- oder Client-Zertifikate, so ist dies direkt mit dem Kommando ''easy-rsa'' möglich.
+//**Hinweis:** Dabei ist zu beachten, dass Googles Chrome-Browser inzwischen verlangt, dass Server-Zertifikate das Attribut SubjectAltNames enthalten. Ohne dieses Attribut erfolgt immer eine Zertifikatswarnung.//
+Ein Beispiel für ein Server-Zertifikat:
+<code>
+invis:~ # easyrsa --subject-alt-name="DNS:host.example.loc" build-server-full host.example.loc nopass
+</code>
+Die Option "nopass" am Ende des Kommandos sorgt dafür, dass der private Schlüssel seinerseits nicht mit einem Passwort verschlüsselt wird. Im Falle von Server-Zertifikaten erleichtert das den Umgang damit, da dem Server-Dienst ansonsten immer das Passwort mitgegeben werden müsste. Bei vielen Diensten ist dies gar nicht möglich.
+Beispiel für ein Client-Zertifikat:
+<code>
+invis:~ # easyrsa --subject-alt-name="DNS:host.pe.loc" build-client-full host.pe.loc nopass
+</code>
+Zum Erstellen von Zertifikaten wird immer das Passwort des privaten CA-Schlüssels benötigt.
+Neue Zertifikate werden in: <file>/etc/easy-rsa/example.loc/issued</file> und die zugehörigen privaten Schlüssel in: <file>/etc/easy-rsa/example.loc/private</file> abgelegt.
+**PKCS#12**
+Werden Schlüsselpaare in PKCS12-Containerformat benötigt, können diese nach Erstellung der Schlüsselpaare als solche exportiert werden:
+<code>
+invis:~ # easyrsa export-p12 host.example.loc
+</code>
+Dabei fragt das Kommando nach einem Export-Passwort. Soll die p12-Datei nicht Passwort-verschlüsselt werden, kann die Passworteingabe durch einfaches Drücken der Enter-Taste quittiert werden.
+Zu finden sind die erstellten p12-Dateien in:  <file>/etc/easy-rsa/example.loc/private</file>
+**Öffentlichen Schlüssel extrahieren**
+<code>
+server14:~ # openssl x509 -in hostname.crt -noout -pubkey > hostname-public.pem
+</code>
 === Zertifikate von Let's Encrypt (ab invis Version 12.1) ===
@@ Zeile 996: / Zeile 1033: @@
 Jetzt können Sie in phpVirtualBox die Fernsteuerung der virtuellen Maschinen via RDP konfigurieren.
+==== Router Tausch ====
+Wird der Router für den Internetzugangs getauscht, hat das auch Auswirkungen auf den invis-Server. Klar sollte sein, dass beim neuen Router wieder die für den invis-Server erforderlichen Portweiterleitungen eingerichtet werden (80/TCP, 443/TCP, 1194/UDP sowie die verschobenen Ports für HTTPs Zugriff aufs invis-Portal und den SSH-Zugriff (beides TCP)). Die beiden verschobenen Ports können Sie den Dateien <file>/etc/ssh/sshd_conf</file> und <file>/etc/apache2/listen.conf</file> entnehmen.
+So Ihr invis-Server seine externe IP-Adresse per DHCP vom Router erhält sorgen Sie dafür, dass er für seine IP-Adresse im Router eine feste Reservierung erhält.
+Für den nicht unwahrscheinlichen Fall, dass Ihr invis-Server nach dem Router-Tausch eine neue IP-Adresse erhält, müssen Sie diese in die Apache-Konfiguration für die Erneuerung der Let's Encrypt Zertifikate eintragen.
+Zu finden ist die anzupassende Stelle der Konfiguration in: <file>/etc/apache2/vhosts.d/vh-dehydrated.conf</file>
+Tragen Sie dort im VirtualHost-Tag die neue IP-Adresse ein und starten Sie den Webserver neu.
+<code>
+# Alias definition for dehytrated wellknown output directory for challenge-hooks
+# Stefan Schaefer - stefan@invis-server.org
+<Virtualhost 192.168.178.21:80>
+    ServerName dhxxx.example.de
+    DocumentRoot /srv/www/htdocs/dehydrated
+...
+</code>
+<code>
+invis:~ # systemctl restart apache2.service
+</code>