Container basiertes Webhosting - Dokumentation für alte Umgebung (outdated)
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, sprechen Sie uns an.
Zugangsdaten
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 „user“)
- 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)
- ein Username für die Mysql-Datenbanken (in der Regel der Domain-Name, in dem „.“ durch „_“ ersetzt ist, also z.B. example_org)
- 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 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.
ssh - Secure-Shell
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.
Damit das Login klappt, muss „ssh Agent Forwarding“ aktiviert sein. Entweder als Option auf der Kommandozeile mit -A bei OpenSSH oder als Konfigurationsparameter in der ssh_config. 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:
host *
ForwardAgent yes
Direkter Zugriff auf den Container
Falls entsprechend konfiguriert, kann der Container direkt mit
ssh -A username@container.datenkollektiv.net
erreicht werden.
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.
Zugriff über einen SSH-Tunnel
Um auch scp oder sFTP zu ermöglichen, muss ein SSH-Tunnel gelegt werden. Dies lässt sich auf Linux-Systemen einfach mit
ssh -L 2222:test-001:22 username@container.datenkollektiv.net
Der Server ist dann unter user@localhost auf Port 2222 zu erreichen. Also z.B.:
scp -P 2222 file user@localhost:
Webdav
Ausgewählte Verzeichnisse des Containers sind über Webdav zu erreichen. Die Webdav-Adresse lautet dabei in der Regel:
https://webdav.example.org/
Die Zugangsdaten lauten:
- Loginname ist immer:
user - Passwort ist das nach dem Anlegen übermittelte
Der Zugriff erfolgt dabei auf das Verzeichnis /srv auf dem Container.
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.
Andere Verzeichnisse können über Symlinks erreicht werden. Per SSH-Zugriff können auf diese Weise beliebige Verzeichnisse per Webdav verfügbar gemacht werden.
Dateien hochladen
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“.
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.
Für Mac-Os Nutzer: Uns wurde berichtet, dass integrierte Webdav Support des „Finders“ verschiedene Probleme macht. Mit anderen generischen Webdav-Clients funktioniert es aber auch unter Mac-Os.
Datenbanken konfigurieren
Die Datenbanken sind unter folgender URL zu erreichen:
https://mysql.datenkollektiv.net/dknmysqladmin/
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.
example_org_wordpress
Wordpress installieren
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.
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.
E-Mail-versand ermöglichen
Wir erlauben per Default keinen unauthentifizierten E-Mail-Versand aus den Containern mit dem normalen Unix-Mail-Kommando. Erstens würde das bedeuten, dass falsch Konfigurierte Server schnell zu Spam-Schleudern würden und außerdem könnten damit E-Mails mit falschen Absendern etc. verschickt werden. Stattdessen kann ein E-Mail Account konfiguriert werden, über den alle E-Mails aus den Containern verschickt werden. Das ist auch die zuverlässigste Methode, bei der es seltener dazu kommt, dass andere Mailserver die Mails als Spam abweisen, weil der Hostname oder der E-Mail-Absender nicht bekannt ist.
Dafür 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.
Zur Konfiguration von ssmtp siehe auch z.B.: https://wiki.archlinux.org/index.php/SSMTP
Beispielkonfiguration:
Account an den alle System E-Mails gehen sollen: your_receiving_account@notraces.net Account über den die E-Mails verschickt werden: youroutgoingaccount@notraces.net (username/password als AuthUser/AuthPass eintragen) Mailserver, auf dem der Account existiert, über den die E-Mails verschickt werden mit Port: mail.datenkollektiv.net:587
Per Webdav die Datei /etc/ssmtp/ssmtp.conf öffnen und editieren:
# # Config file for sSMTP sendmail # # The person who gets all mail for userids < 1000 # Make this empty to disable rewriting. root=your_receiving_account@notraces.net # The place where the mail goes. The actual machine name is required no # MX records are consulted. Commonly mailhosts are named mail.domain.com mailhub=mail.datenkollektiv.net:587 # Where will the mail seem to come from? # rewriteDomain=example.org # The full hostname (the container-default-hostname) hostname=your.container.hostname # Use SSL/TLS before starting negotiation UseTLS=Yes UseSTARTTLS=Yes # Username/Password # das muss mit dem konfigurierten Account in revaliases korrespondieren. AuthUser=USERNAME AuthPass=VERY-SECRET_PASSWORD # Are users allowed to set their own From: address? # YES - Allow the user to specify their own From: address # NO - Use the system generated From: address FromLineOverride=NO
Jetzt muss noch die Datei /etc/ssmtp/revaliases konfiguriert werden. In ihr wird jedem lokalen Nutzer ein Mailaccount zugeordnet. Wichtig ist dabei neben root auch der Nutzer www-data - da über ihn normalerweise Mails vom Webserver verschickt werden.
# sSMTP aliases # # Format: local_account:outgoing_address:mailhub # # Example: root:your_login@your.domain:mailhub.your.domain[:port] # where [:port] is an optional port number that defaults to 25. root:youroutgoingaccount@notraces.net www-data:youroutgoingaccount@notraces.net
Webserver konfigurieren
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
sudo service nginx restart
oder
sudo service nginx reload
den Webserver neu zu starten.