Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- public:webhosting:container_administration [2016/08/05 19:37] – jankow@datenkollektiv.net
+++ public:webhosting:container_administration [2019/11/28 17:25] (aktuell) – [Zugangsdaten] rasch
@@ Zeile 1: / Zeile 1: @@
 ====== Container basiertes Webhosting - unser Container-Hafen ======
-Mit dem "Container-Haven" bietet das Datenkollektiv ein Container-basiertes Webhosting an. Container sind eine Art der Virutalisierung, die sich gegenüber einer kompletten Virtualisierung durch deutlich bessere Performance auszeichnet und sehr wenig Ressourcen benötigt. Dies ermöglicht, eine Vielzahl von Containern parallel auf einem Server zu betreiben. Die einzelnen Container verhalten sich dabei wie eigenständige Server. Gegenüber einfachem "Webspace" hat das viele Vorteile:
+  * [[container_admin_alt|Ältere Dokumentation auf altem Server mit Webdav-Zugang]]
-  * Die Dateien in einer Instanz gespeichert sind, sind vollständig gegenüber anderen Instanzen isoliert
+Mit dem "Container-Haven" bietet das Datenkollektiv ein Container-basiertes Webhosting an. Container sind eine Art der Virutalisierung, die sich gegenüber einer kompletten Virtualisierung durch deutlich bessere Performance auszeichnet und sehr wenig Ressourcen benötigt. Dies ermöglicht, eine Vielzahl von Containern parallel auf einem Server zu betreiben. Die einzelnen Container verhalten sich dabei wie eigenständige Server.
+Gleichzeitig sorgen wir im Hintergrund für die nötigen Betriebssystem-Updates. Sie müssen sich als Nutzer_in also nur um Ihre Web-Applikationen kümmern - sofern Sie nicht auch dort z.B. das vorinstallierte Wordpress nutzen. Auch dort kümmern wir uns um die Updates.
+Dies ist sozusagen ein **Mittelweg** zwischen **"einfachem Webspace"** und einem **V-Server** mit den folgenden Vorteilen:
+  * Die Dateien in einer Instanz, sind vollständig gegenüber anderen Instanzen isoliert
   * Bei hoher Sicherheit haben die einzelnen User große individuelle Konfigurationsmöglichkeiten
+  * Wir kümmern uns um Sicherheitsupdates
+  * Ein tägliches Backup der Daten erfolgt automatisch
 Wenn Sie sich für Container-basiertes Webhosting interessieren, [[:kontakt|sprechen Sie uns an]].
@@ Zeile 10: / Zeile 17: @@
 Als Zugangsdaten sind notwendig:
-  * URL, unter der der Container verwaltet wird - üblicherweise der Domain-Name wie z.B. example.org
+  * ein Username für den Container (in der Regel "webcXXX")
-  * ein Username für den Container (in der Regel "user")
+  * ein Passwort, das bei der Einrichtung übermittelt wird. (Passwort-Änderung unter: https://ldap.dknuser.de/)
-  * ein Username für den "Container-Hafen" (für das direkte ssh-Login, in der Regel der Domain-Name, in dem "." durch "_" ersetzt ist, also z.B. example_org)
+  * URL, unter der der Container verwaltet wird - üblicherweise der Domain-Name wie z.B. USERNAME@webc???.hosting.dknuser.de
-  * ein Username für die Mysql-Datenbanken (in der Regel der Domain-Name, in dem "." durch "_" ersetzt ist, also z.B. example_org)
+  * der Username und ein Passwort für die Mysql-Datenbanken ist identisch mit dem Usernamen des Containers. Das Passwort wird bei der Einrichtung übermittelt.
-  * ein Passwort (anfangs identisch gesetzt: User-Passwort u. Datenbank-Passwort
-Für einige Zwecke (sFTP, direkter SSH-Zugriff ist ein privater Schlüssel notwendig. Der zugehörige öffentliche Schlüssel muss auf den Servern entsprechend konfiguriert werden. Zum Einrichten bitte an den [[support@datenkollektiv.net|Support]] wenden.
 ===== Zugang zum Container =====
-Es gibt mehrere Möglichkeiten des Zugangs zum Container. Datei-Up- und Download lässt sich am einfachsten über Webdav vornehmen. Vollen Zugang zum Container kann über "ssh" erfolgen. Dateiupload über sFTP ist möglich - allerdings nur in Verbindung mit einem ssh-Tunnel.
+Es gibt mehrere Möglichkeiten des Zugangs zum Container. Datei-Up- und Download lässt sich am einfachsten über sftp vornehmen.
-==== ssh - Secure-Shell ====
+Alle wichtigen Informationen dazu gibt es in der initialen E-Mail nach der Erstellung eines neuen Containers.
-Der Container selbst ist nicht direkt von außen zu erreichen, sondern nur über einen weiteren Server - unseren Containerhafen. Damit das klappt, benötigen wir einen "öffentlichen SSH-Schlüssel" von Ihnen.
+===== sftp =====
-<WRAP center round important 60%>
+Der SFTP-Zugang ist:
-Damit das Login klappt, muss "ssh Agent Forwarding" aktiviert sein.
-Das kann z.B. bei OpenSSh erreicht werden, in dem entweder in die globale ''/etc/ssh_config'' oder die private ''~/.ssh/config'' Konfiguration folgendes eingefügt wird:
+  USERNAME@USERNAME.hosting.dknuser.de
-<code>
-host *
-    ForwardAgent yes
-</code>
-</WRAP>
+==== Dateirechte ====
-**Direkter Zugriff auf den Container**
+Standardmäßig haben alle Dateien, die per sftp hochgeladen werden folgende Rechte:
+  * Benutzer: der Benutzer, der die Dateien hochlädt
+  * Gruppe: www-data
+Wenn der Webserver selbst auch in die Verzeichnisse schreiben können soll oder Dateien ändern soll (z.B. nötig, wenn ein CMS wie wordpress Dateien von einem Upload speichern soll, Plugins installieren können soll oder ein Update aus der Weboberfläche heraus passieren soll, müssen die Verzeichnisse und Dateien auch für die Gruppe ''www-data'' schreibbar sein.
-Falls entsprechend konfiguriert, kann der Container direkt mit
+Das lässt sich mit einem
+  chmod 664 (für Dateien)
+  chmod 775 (für Verzeichnisse)
+mit einem sftp-client erledigen.
-  ssh username@container.datenkollektiv.net
+Wenn es damit Schwierigkeiten gibt, bitte an den Support wenden.
-erreicht werden.
+===== Datenbanken konfigurieren =====
-<WRAP center round important 60%>
+Die Datenbanken sind unter folgender URL zu erreichen:
-Bitte beachten: Über diesen Weg ist nur ssh möglich. Kopieren ist weder über sFTP noch über scp oder sshfs möglich. Dies liegt an der Konfiguration auf unseren Servern, durch die der Zugang nur über einen "SSH-Proxy" möglich ist.
-</WRAP>
-**Zugriff über einen SSH-Tunnel**
+  * https://sqladmin.dknuser.de/phpmyadmin/
-Um auch scp oder sFTP zu ermöglichen, muss ein SSH-Tunnel gelegt werden. Dies lässt sich auf Linux-Systemen einfach mit
+Das Login ist zweistufig. Aus Sicherheitsgründen ist ein ht-Passwort vorgeschaltet, Usernamen und Passwort sind identisch mit denen des Zugangs (sftp-User/Passwort)
-  ssh -L 2222:test-001:22 username@container.datenkollektiv.net
+Login mit Datenbank-Username und Passwort. Dort können beliebige Datenbanken erstellt werden, deren Namen mit dem Usernamen gefolgt von einem "_" beginnen müssen. Also z.B.
+  USERNAME_wordpress
-Der Server ist dann unter ''user@localhost'' auf Port 2222 zu erreichen. Also z.B.:
+Als Datenbank-Server muss in den eigenen Instanzen dann folgendes eingetragen werden:
-  scp -P 2222 file user@localhost:
+  sql0.datenkollektiv.net
-==== Webdav ====
+===== Wordpress =====
-Ausgewählte Verzeichnisse des Containers sind über Webdav zu erreichen. Die Webdav-Adresse lautet dabei in der Regel:
+In den Containern ist evtl. eine Wordpress-Instanz vorinstalliert. Diese Wordpress-Instanz kommt aus den Debian-Repositories. Es ist immer etwas älter als das aktuelle Release. Dafür ist es gut ins System integriert - und bekommt über Debian Sicherheitsupdates - allerdings nicht immer sofort.
-  https://webdav.example.org/
+Das Daten-Verzeichnis für diese Installation, auf das per sftp zugegriffen werden kann liegt direkt unter ''/wordpress/wp-content/''.
-Der Zugriff erfolgt dabei auf das Verzeichnis ''/srv'' auf dem Container.
+===== Eigenes Wordpress installieren =====
-<WRAP center round tip 60%>
+Alternativ lässt sich aber auch leicht ein eigenes Worpress im Webroot installieren. Das SFTP-Verzeichnis ist dann ''/www/'' - dort kann dann z.B. ein Verzeichnis ''wordpress'' angelegt werden.
-Achtung: Bei Webdav kann es Probleme mit Leerzeichen und Sonderzeichen in Dateinamen geben. Diese gilt es in jedem Fall zu vermeiden. Insbesondere Dateien mit Leerzeichen können nicht angelegt werden. Leider ist das bei einigen Dateimanagern die Standard-Einstellung ("Neue Datei"). In diesem Fall hilft, eine Datei lokal anzulegen und zu kopieren.
-</WRAP>
+Für diese Wordpress-Instanz ist dann entsprechend dieses Verzeichnis zuständig - und nicht das der systemweiten Installation (siehe oben), z.B.:
+  /www/wordpress/wp-content
-Andere Verzeichnisse können über Symlinks erreicht werden. Per SSH-Zugriff können auf diese Weise beliebige Verzeichnisse per Webdav verfügbar gemacht werden.
+Bei einer selbst installierten Wordpress-Instanz im Webroot muss ggf. die Webserver-Konfigurtion angepasst werden, die sich unter
+  /nginx/sites-user
+befindet.
-===== Dateien hochladen =====
+Siehe auch unten: [[#Webserver konfigurieren]]
-Am einfachsten funktioniert das per Webdav. Für alle Plattformen gibt es dazu Webdav-kompatible Dateibrowser. Unter Linux-Desktops funktionert das z.B. mit der Funktion "Mit Server verbinden".
+Die Zeile
+  server_name webc08.hosting.dknuser.de;
+muss an den tatsächlichen Seitennamen angepasst werden, also z.B.:
+  server_name example.org;
-Auf diese Weise können Dateien kopiert oder bearbeitete werden als ob sie auf dem lokalen Rechner liegen würden. Neben der verbesserten Sicherheit gegenüber "ftp" ist dies auch intuitiver und einfacher.
+Da der Webserver im Container hinter einem Webproxy liegt, muss ggf. in der Wordpress-Config
+  wp-config.php
-===== Datenbanken konfigurieren =====
+folgendes vor der Zeile
+  require_once(ABSPATH . 'wp-settings.php');
+hinzugefügt werden:
-Die Datenbanken sind unter folgender URL zu erreichen:
+<code>
-  https://mysql.datenkollektiv.net/dknmysqladmin/
+/**
+ *  * Handle SSL reverse proxy
+**/
+if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
+            $_SERVER['HTTPS']='on';
-Login mit Datenbank-Username und Passwort. Dort können beliebige Datenbanken erstellt werden, deren Namen mit dem Usernamen gefolgt von einem "_" beginnen müssen. Also z.B.
+if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
-  example_org_wordpress
+            $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
+}
+</code>
+  * vgl. auch: https://www.variantweb.net/blog/wordpress-behind-an-nginx-ssl-reverse-proxy/
-===== Wordpress installieren =====
+Sinnvoll ist es auch Wordpress so zu konfigurieren, dass die Instanz selbst Dateien hochladen kann - sonst klappt z.B. das automatische Installieren von Plugins nicht. Dazu bedarf es folgender Zeile in der wp-config.php (wiederum vor der letzten Zeile ''require_once(ABSPATH . 'wp-settings.php');'':
-In den Containern ist eine Wordpress-Instanz vorinstalliert. Sollte diese noch nicht initialisiert sein, so kann das über einen SSH-Zugang erfolgen. Im Home-Verzeichnis findet sich eine README Datei, in denen die Befehle stehen, die ausgeführt werden müssen, um Datenbank und Wordpress Instanz zu konfigurieren.
+  define('FS_METHOD','direct');
 ===== Eigene html-Seiten / Php-Skripte =====
-Der Webroot liegt unter ''/var/www/html/'' - und ist per webdav zugänglich. Alle Dateien und Skripte können dort hochgeladen werden.
+Der Webroot liegt unter ''/www/html/'' - und ist per sftp zugänglich. Alle Dateien und Skripte können dort hochgeladen werden.
-===== E-Mail-versand ermöglichen =====
+===== Webserver konfigurieren =====
-Für den E-Mail-Versand ist innerhalb der Container das Programm ssmtp installiert. Dieses muss noch konfiguriert werden, das lässt sich ebenfalls über webdav vornehmen, die Konfigurationsdatei sind unter /etc/ssmtp/* verlinkt.
+Fortgeschrittene User_innen können auch die Webserver-Konfiguration selbst verändern. Dazu sind Kenntnisse in der Konfiguration des Nginx-Webservers nötig. Außerdem muss beachtet werden, dass der Webserver hinter einem Webproxy liegt - und z.B. nicht auf alle Header-Variablen direkt zugegriffen werden kann. Außerdem geschieht die Verbindung zum Webproxy grundsätzlich über Port 80 und http. Sämtliche Konfiguration von Zertifikaten geschieht auf dem Proxy-Server durch die Administratoren des datenkollektiv.
-Zur Konfiguration von ssmtp siehe z.B.: https://wiki.archlinux.org/index.php/SSMTP
+Der Basis-Webroot-Pfad für das Verzeichnis ''www'' ist:
-===== Webserver konfigurieren =====
+  /var/www/
+Um Änderungen am Webserver wirksam zu machen, muss dieser neu gestartet werden. Dazu bitte in der Datei
+  /www/nginx_reload.txt
+Die Werte entsprechend setzen:
+  reload=0
+  restart=1
+Nach einer Minute wird der Webserver automatisch neu gestartet (die Werte in der ngnix_reload.txt sind dann wieder zurück auf ''0'' gesetzt).
+Beispiele:
+==== Eigene Wordpress-Installation ====
+<file text wordpress.conf>
+## http://wiki.nginx.org/WordPress
+server {
+    listen  80;
+    listen [::]:80;
+    server_name			 example.org;
+    root                         /var/www/wordpress;
+    index                        index.php;
+    location = /favicon.ico {
+        log_not_found            off;
+        access_log               off;
+    }
+    location = /robots.txt {
+        allow                    all;
+        log_not_found            off;
+        access_log               off;
+    }
+    location / {
+        # This is cool because no php is touched for static content.
+        # include the "?$args" part so non-default permalinks doesn't break when using query string
+        try_files                $uri $uri/ /index.php?$args;
+    }
+    location ~ \.php$ {
+        include                  /etc/nginx/fastcgi_params;
+        fastcgi_param            SCRIPT_FILENAME         $request_filename;
+        fastcgi_index            index.php;
+        fastcgi_intercept_errors on;
+        fastcgi_pass             unix:/var/run/php7.0-fpm-www-data.sock;
-Fortgeschrittene User_innen können über einen SSH-Zugriff auch die Webserver-Konfiguration selbst verändern. Dazu sind Kenntnisse in der Konfiguration des Nginx-Webservers nötig. Außerdem muss beachtet werden, dass der Webserver hinter einem Webproxy liegt - und z.B. nicht auf alle Header-Variablen direkt zugegriffen werden kann. Außerdem geschieht die Verbindung zum Webproxy grundsätzlich über Port 80 und http. Sämtliche Konfiguration von Zertifikaten geschieht auf dem Proxy-Server durch die Administratoren des datenkollektiv.
+    }
-Der Default-User hat die Rechte, die Dateien unter /etc/nginx/sites-available und /etc/nginx/sites-enabled/ zu bearbeiten und per
+    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
+        expires                  max;
+        log_not_found            off;
+    }
+}
+</file>
-  sudo service nginx restart
+==== Statische Seite unter /www/html/ ====
-oder
-  sudo service nginx reload
-den Webserver neu zu starten.