Für Webseiten hat der IN-Berlin mehrere Server:

• den Shellserver zum Testen und Hochladen, siehe auch Shell.
• einen Pre-Proxy
• Webserver mit diversen CGI-Plattformen.

Die Webseiten können vom Shellserver shell.in-berlin.de aus bearbeitet werden. Hier kann man sich mit seinem Sitenamen und einem separaten Passwort das sich vom i.d.R. E-Mail-Passwort unterscheidet anmelden.

Wenn man keine weitere Domain hat, dann ist im Home unter websites/public_html/ die Standarddomain http://sitename.in-berlin.de/ erreichbar. Wie unterschiedliche Sitenamen oder Domains funktionieren, ist unter Domains und Sitenamen beschrieben.

Zusätzliche Domains liegen in der Regel unter websites/domain.tld. Subdomains lassen sich auch separat behandeln und in beliebige Verzeichnisse als Documentroot zeigen. Für solche oder ähnliche Sonderwünsche bitte an den Support wenden.

Weiterleitungen von Domains auf andere kann man über .htaccess-Dateien oder über Symlinks einrichten.

Eine automatische Umleitung von einer Webseite auf die Domain example.org würde man mit folgender Datei unter websites/public_html/.htaccess erreichen:

RewriteEngine On
RewriteRule ^/?(.*) https://example.org/$1 [R,L]

Eine Möglichkeit von Weiterleitungen von Domains beim IN-Berlin ist mittels eines Symlink. Ein Symlink ist eine Verknüpfung im Dateisystem. Hierfür würde man in seinen websites/-Ordner gehen, dort das Verzeichnis der alten Webseite löschen und stattdessen einen Symlink auf die neue Webseite anlegen. Wenn man also von example.in-berlin.de (unter public_html/) auf example.org verlinken will, sähe das so aus:

cd ~/websites/
rmdir public_html
ln -s example.org public_html

Auf dem Webserver laufen alle üblichen CGI-Plattformen (Perl, Ruby, Python, SSI, PHP). Falsl bestimmte Module oder CGIs fehlen, bitte an den Support wenden. Eine genaue Beschreibung des Moduls hilft uns, das schnell umzusetzen, am besten schon mit Debian-Paketnamen.

Auf dem Shellserver, auf dem man die Daten bearbeitet und hochläd, kann man dort auch schon Dinge teste (PHP, Perl usw. sind installiert). Allerdings sind manchmal bestimmte Module nicht installiert oder andersherum, auf dem Shellserver, nicht aber auf dem Webserver installiert, oder sie liegen in unterschiedlichen Versionen vor.

Es gibt leider immer mehr Anwendungen, die nicht als CGI auf einem Shared Webhost funktionieren. Es lassen sich ein paar Grundregeln sagen:

• Alles, was als Docker-Container installiert wird, funktioniert nicht.
• Die meiste Software, die exzessiv auf der Shell mit vielen Kommandos installiert werden muss, funktioniert nicht.
• Software, die bei der Installation root sein muss, funktioniert nicht.

Als einzige Alternative bietet sich hier ein VServer an. Auf diesem muss man sich aber selber um die Wartung und sämtliches Setup kümmern, was Fachwissen und kontinulierlicher Zeit voraussetzt.

Wer als Teilnehmer einen Blog laufen lassen will, kann dafür die zentrale Wordpress-Instanz des IN-Berlin benutzen. Auch eigene Domains sind hier möglich. Gegenüber einer eigenen Installation hat das den Vorteil, dass man sich nicht um Installation und Wartung kümmern muss (auch wenn dies bei Wordpress sehr einfach ist). Allerdings hat es auch den Nachteil, dass man selber keine Nutzer und Plugins anlegen kann, sondern nachfragen muss.

Ein Wordpress-Blog bekommt man, indem man sich beim Support meldet.

IN-Berlin unterstützt Let's Encrypt. Wir erstellen standardmäßig für sämtliche Domains auf unseren Servern SSL-Zertifikate von letsencrypt. Zum Ausprobieren: Die eigene Webseite mit https:// statt http:// am Anfang aufrufen.

Mit einer .htaccess-Datei kann man nur https erlauben und unverschlüsselte Verbindungen automatisch umleiten. Eine Internetsuche zeigt man zahlreiche Beispiele, was man damit konfigurieren kann (z.B. auch Passwortschutz für Verzeichnisse). In der offiziellen Dokumentation für mod_rewrite findet man alle Möglichkeiten.

Folgende .htaccess-Datei im Rootverzeichnis einer Webseite (websites/public_html/.htaccess) würde alle Verbindungen auf https umleiten:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Diese Regel würde alle Anfragen von http://www.example.org/irgendwas auf https://www.example.org/irgendwas weiterleiten.

Wir haben einen PostgreSQL- und einen MySQL-Server, auf denen jeder User beliebig viele Datenbanken haben kann. Datenbanken anlegen ändern oder löschen geht im Service-Interface. Die Zugangsdaten werden dort angezeigt, das Passwort kommt per extra Mail. Die Datenbankserver sind, je nach verwendeter Datenbank:

• mysql.in-berlin.de
• postgresql.in-berlin.de

Die Datenbankserver sind nur aus dem IN-Berlin-Netz erreichbar. Um eine Datenbank von seinem eigenen Rechner aus zu erreichen, kann man das mit einem VPN oder einem SSH-Tunnel über unseren Shellserver tun. Alternativ kann man auch vom Shellserver auf den Datenbankserver zugreifen. Dort sind die üblichen Tools mysql und mysqldump bzw. psql und pg_restore und pg_dump installiert.

Als dritte Alternative bieten sich die Webinterface phpmyadmin bzw. phppgadmin an:

• https://user.in-berlin.de/phpmyadmin
• https://user.in-berlin.de/phppgadmin

Das Setup der Webserver des IN-Berlin nennt sich Pre-Proxy: Ein Proxy nimmt zuerst sämtliche http-Anfragen für eine Webseite an und leitet sie transparent im Hintergrund an den Webserver weiter, der die Anfragen verarbeitet.

Damit kann Last besser verteilt werden (z.B. können statische Webseiten gecached werden) und für Wartungen oder Spezialsetups können Webseiten leichter verschoben werden.

Einige Setups werden damit aber auch kompliziert. Bspw. Client-Zertifikate zur Authentifizierung sind z.B. nicht ohne weiteres möglich. Wer so ein Spezialsetup haben will, schreibt am besten den Support an.