Benutzer-Werkzeuge

Webseiten-Werkzeuge


webseiten

**Dies ist eine alte Version des Dokuments!**

Webseiten

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

  • den Shellserver zum Testen und Hochladen, siehe auch Shell.
  • einen Prä-Proxy
  • verschiedene Webserver, je nach PHP-Version (momentan 5.2 und 5.3).

Webseiten erstellen

Hat man keine weitere Domain, so kann man Webseiten einfach in seinem Home unter websites/public_html/ anlegen. Alles in diesem Ordner ist dann unter http://sitename.in-berlin.de erreichbar. Wie genau es mit unterschiedlichen Sitenamen oder Domains läuft, ist unter Domains und Sitenamen beschrieben.

Hat man weitere Domains, so sind diese in der Regel verfügbar unter websites/domain.tld. Subdomains lassen sich natürlich auch separat behandeln und in beliebige Verzeichnisse als Documentroot zeigen.

Für solche oder ähnliche Sonderwünsche bitte einfach den Support kontaktieren.

CGIs

Auf dem Webserver laufen alle üblichen CGIs (Perl, Python, SSI, PHP5, usw.). Falls einem ein bestimmtes Modul oder ein CGI fehlt, sollte man entweder darüber nachdenken, den Applikationsserver zu benutzen, oder beim Support nachzufragen, ob dieses Paket nachinstalliert werden kann.

Da die Daten des Webservers auch auf dem Shellserver verfügbar sind, kann man dort schon Dinge testen (PHP, Perl usw. sind installiert). Allerdings kann es je nach Migrationsstand auch dazu kommen, dass bestimmte Programme auf dem Shellserver nicht installiert sind (oder andersrum, installiert, aber nicht auf dem Webserver), oder in einer anderen Version als auf dem Webserver vorliegen.

SSL/https

Wer seine Webseite mit SSL bzw. mit https absichern will, braucht als erstes ein x509-Zertifikat und dazu einen Schlüssel (dieser muss uns ohne Passwort gegeben werden). In einem Zertifikat stehen explizit die Domains drin, die erlaubt sind, d.h. man braucht für jede Domain, die man hat, ein eigenes Zertifikat, oder muss ein Zertifikat für alle erstellen. Als Schlüssellänge nehmen wir mindestens 2048 Bit.

Hat man das Zertifikat, dann legt man die am besten auf dem Shellserver ab und sagt dem Support, wo sich das Zertifikat und der Schlüssel befinden, und dann wird es einem eingerichtet (hier nicht erwarten, dass es allzu schnell geht - die Einrichtung in unserem Setup ist relativ kompliziert und braucht eine Weile).

Will man nur seine Site sitename.in-berlin.de verschlüsseln, und keine eigene Domain, dann reicht eine Anfrage beim Support. Wir sind schon bei StartSSL und CACert angemeldet und auch nur wir können für Subdomains von in-berlin.de Zertifikate erstellen.

Für eigene Domains empfehlen wir drei Möglichkeiten, sich ein Zertifikat zu holen:

StartSSL

StartSSL ist eine CA, die Privatpersonen kostenlose Zertifikate ausstellt. StartSSL ist in allen gängigen Browsern enthalten, d.h. man erhält keine Warnungen, sondern direkt eine sichere Verbindung, wenn man auf die entsprechende Webseite geht. Wir können bei der Erzeugung eines StartSSL-Zertifikates leider nicht helfen, aber es gibt eine Anleitung auf der Webseite, wie das geht. Hier braucht man nur Kontrolle über die Domain und kann sich dann online verifizieren.

StartSSL verwenden wir auch für unsere sichtbaren verschlüsselten Dienste wie z.B. das Service-Interface oder den Mailserver.

Nachteil an StartSSL ist, dass es eine israelische CA ist, und damit auch israelischen Datenschutzbestimmungen und Gesetzen unterliegt.

CACert

CACert ist ein Projekt, das Vertrauen dadurch aufbaut, dass alle Teilnehmer des Projekts mal ein Dokument zur Verifikation der Persönlichkeit (Vereinsregisterauszug, Personalausweis, Reisepass) vorgelegt haben. In der Wikipedia findet sich eine genauere Beschreibung, wie die Verifikation abläuft.

Die einfachste Version ist es, zu einer Veranstaltung oder einem Ort zu gehen, wo CACert-Assurer sind. Man kann auch auf der Webseite nachsehen, ob man welche in der Gegend hat, mit denen man sich mal treffen kann.

Nachteil an CACert ist, dass es in gängigen Browsern nicht enthalten ist. Das heißt, man muss entweder das Root-Zertifikat von der CACert-Webseite einspielen (wie man das überprüft, steht auf den Teilnahmeformularen von CACert), oder aber immer die Warnungen ignorieren, und dann könnte man sich Zertifikate auch gleich sparen.

Selbstsigniert

Will man die verschlüsselte Webseite nur für sich selber benutzen, dann kann auch ein selbstsigniertes Zertifikat reichen. Dann braucht man dieses Zertifikat nur einmal zu akzeptieren bzw. nur einmal den Fingerprint zu checken, und kann danach immer auf diese Webseite zugreifen. Besucher müssen natürlich bei jedem Besuch immer wieder eine Warnung wegklicken, um diese Webseite zu sehen.

Wie man ein Zertifikat selber erstellt, findet man im Internet zahlreiche Anleitungen. Am einfachsten ist es wohl, auf unserem Shellserver die Befehle von openssl zu benutzen (konkret: genrsa(1), req(1)).

Beispiel (auf dem Shellserver einloggen, dann das hier tun):

gnrp@Endurance:~$ openssl genrsa -out domain.tld.key 4096
Generating RSA private key, 4096 bit long modulus
...........................................................................................................................................++
......................................................................................................................................................................................................................................................................++
e is 65537 (0x10001)

gnrp@Endurance:~$ openssl req -new -key domain.tld.key -x509 -days 730 -subj "/C=DE/CN=www.example.org/" -out domain.tld.crt

Als erstes erstellt man sich einen Schlüssel mit 4096 Bit, der in der Datei domain.tld.key abgespeichert wird. Danach erstellt man sich ein selbstsigniertes Zertifikat, das zwei Jahre (730 Tage) gültig ist, ausgestellt für die Domain www.example.org.

SSL-only

Wir richten standardmäßig eine Webseite mit https und mit normalem http ein. Will man nur https erlauben und keine verschlüsselten Verbindungen mehr, so kann man das mit einer .htaccess-Datei machen. Ein Beispiel, wie eine .htaccess-Datei aussieht, die im Root einer Webseite liegt (also z.B. unter websites/public_html/.htaccess):

RewriteEngine On
RewriteRule ^$ https://www.example.org/$1 [R]

Diese Regel würde alle Anfragen von http://www.example.org/irgendwas auf https://www.example.org/irgendwas weiterleiten, also genau der gleiche Pfad, nur verschlüsselt.

Datenbanken (MySQL, PostgreSQL)

Wir haben einen PostgreSQL- und einen MySQL-Server, auf denen jeder User beliebig viele Datenbanken haben kann. Wer eine Datenbank braucht, schreibt dafür einfach eine Anfrage an den Support, welchen Datenbanktyp (MySQL oder PostgreSQL) er haben will und welchen Namen die Datenbank haben soll. Dann legen wir die an und legen euch i.d.R. in euer Homeverzeichnis eine nur für euch lesbare Datei mit dem Usernamen, dem Datenbanknamen und dem Passwort. Die Datenbankserver sind, je nach verwendeter Datenbank:

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

Die Datenbankserver sind von allen IN-Berlin-Servern erreichbar. Wenn man seine Datenbank z.B. von seinem eigenen Rechner aus erreichen will, kann man das mit einem SSH-Tunnel über unseren Shellserver oder mit einem VPN tun. Ansonsten kann man auch vom Shellserver aus auf den Datenbankserver zugreifen, dort sind die üblichen Tools mysql und mysqldump bzw. psql und pg_restore und pg_dump installiert.

Alternativ kann man auch die bekannten Webinterfaces phpmyadmin bzw. phppgadmin benutzen unter:

Spezielle Anwendungen/Applikationsserver

Für spezielle Anwendungen, die einen eigenen Webserver mitbringen, haben wir einen Applikationsserver. Auf diesem Applikationsserver kriegt man auf Anfrage beim Support einen Account und einen Port zugewiesen. Danach kann man sich dort einloggen und seine eigene Software installieren (als User), und muss sie nur dazu bringen, auf diesem Port zu lauschen.

Erreichbar ist die Anwendung dann unter einer beliebigen Adresse. Da auch dieser Server hinter dem Präproxy hängt, kann man hier eine beliebige Domain nehmen und muss dafür nicht extra den speziellen Port angeben, ein Webseitenbesucher sieht hiervon nichts.

Besonderheiten des Setups

Das Setup vom IN-Berlin ist nicht unüblich, aber doch für viele unerwartet: Es gibt einen Proxy, der zuerst sämtliche http-Anfragen für eine Webseite annimmt, und diese dann erst an den eigentlichen Webserver weiterleitet, der die Anfragen bearbeitet.

Dies hat den Hintergrund, dass damit deutlich besser Last abgefangen werden kann (sich nicht ändernde Seiten müssen nicht jedes mal neu erstellt werden, sondern können im Proxy im Cache gehalten werden), und für Wartungen oder Spezialsetups kann man Webseiten leichter auf anderen Servern ablegen, ohne, dass sich die IP ändert.

Manchmal verhindert es aber auch, dass man bestimmte Dinge tut – Client-Zertifikate zur Authentifizierung sind z.B. nicht ohne weiteres möglich, wenn man sowas will, muss man den Support anschreiben.

webseiten.1395962106.txt.gz · Zuletzt geändert: 2014/03/28 00:15 von julian