Für Webseiten stellt IN-Berlin mehrere Server bereit:

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

Webseiten erstellen

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 i. d. R. vom E-Mail-Passwort unterscheidet, anmelden.

Wenn man keine weitere Domain hat, dann ist im Homeverzeichnis unter websites/public_html/ die Standarddomain https://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

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

.htaccess

Eine automatische Umleitung von einer Webseite auf die Domain example.org kann man mit folgender Datei unter websites/public_html/.htaccess konfigurieren:

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

Eine andere Möglichkeit zur Weiterleitung von Domains ist mittels eines Symlinks. Ein Symlink ist eine Verknüpfung im Dateisystem. Dies funktioniert daher nur für Domains, die auf dem selben Server liegen. Hierfür kann 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, sieht die Befehlsfolge dafür wie folgt aus:

cd ~/websites/
rmdir public\_html
ln -s example.org public\_html

Anwendungen / CGIs

Auf dem Webserver laufen alle üblichen CGI-Plattformen (Perl, Ruby, Python, SSI, PHP). Falls bestimmte Module oder CGIs fehlen, bitte an den Support wenden. Eine genaue Beschreibung des Moduls hilft uns, das schnell umzusetzen. Gebt am besten direkt den Namen des zu installierenden Debian-Pakets mit an, falls dieser bekannt ist.

Auf dem Shellserver, auf dem man die Daten bearbeitet und hochlädt, 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. Dies liegt daran, dass wir nur einen Shellserver, aber Webserver mit unterschiedlichen PHP-Versionen anbieten.

Nicht-shared-webhost-fähige Anwendungen

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

  • 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 kontinulierliche Zeit voraussetzt.

Wordpress

Wer als Teilnehmer einen Blog laufen lassen möchte, 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 inzwischen sehr einfach geworden ist. Allerdings hat es auch den Nachteil, dass man selber keine Nutzer und Plugins anlegen kann, sondern den Support bemühen muss.

Einen Wordpress-Blog kann man sich vom Support initial einrichten lassen.

TLS/SSL/https

IN-Berlin stellt TLS-Zertifikate über den kostenfreien Dienst Let’s Encrypt aus. Wir erstellen standardmäßig für sämtliche Domains die auf unseren Servern betrieben werden TLS-Zertifikate. Zum Ausprobieren: Die eigene Webseite mit https:// statt http:// am Anfang aufrufen.

https-only

Mit einer .htaccess-Datei kann man nur https erlauben und unverschlüsselte Verbindungen automatisch umleiten. Folgende .htaccess-Datei im Rootverzeichnis einer Domain (websites/public_html/.htaccess) leitet alle Verbindungen auf https um:

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

Diese Regel leitet alle Anfragen von http://www.example.org/irgendwas auf https://www.example.org/irgendwas um.

Datenbanken (MySQL/MariaDB, PostgreSQL)

Wir haben MySQL/MariaDB- und PostgreSQL-Server, auf denen jeder Teilnehmer mit einem Webtarif beliebig viele Datenbanken erstellen kann. Datenbanken anlegen, ändern oder löschen kann man im Service-Interface. Datenbank- und Benutzername werden dort angezeigt, das Passwort kommt nach der Erstellung per E-Mail. Die Namen der Datenbankserver sind, je nach verwendeter Datenbank, folgende:

  • 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:

Besonderheiten unseres Setups

Das Setup der Webserver des IN-Berlin ist in sofern besonders, als dass zunächst alle Anfragen über einen sog. Pre-Proxy laufen. Ein Proxy nimmt zuerst sämtliche http-Anfragen für eine Webseite entgegen 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 auch gecached werden, und für Wartungen oder Spezialsetups können Webseiten leichter verschoben werden. Einige Setups werden damit aber auch kompliziert. Beispielsweise sind Client-Zertifikate zur Authentifizierung nicht ohne weiteres möglich. Wer so ein Spezialsetup haben will, schreibt am besten den Support an.