Benutzer-Werkzeuge

Webseiten-Werkzeuge


webseiten

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
webseiten [2014/03/30 16:43] – [Webseiten] chriswebseiten [2021/08/24 19:45] (aktuell) – Andere PHP-Versionen entfernt julian
Zeile 5: Zeile 5:
  * den Shellserver zum Testen und Hochladen, siehe auch [[shell|Shell]].  * den Shellserver zum Testen und Hochladen, siehe auch [[shell|Shell]].
  * einen Pre-Proxy  * einen Pre-Proxy
- verschiedene Webserver, je nach PHP-Version (momentan 5.2 und 5.3).+ * Webserver mit diversen CGI-Plattformen. 
  
 ## Webseiten erstellen ## 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` erreichbarWie genau es mit unterschiedlichen Sitenamen oder Domains läuft, ist unter [[DomainSitename|Domains und Sitenamen]] beschrieben.+Die Webseiten können vom Shellserver `shell.in-berlin.de` aus bearbeitet werdenHier kann man sich mit seinem Sitenamen und einem separaten Passwort das sich vom i.d.R. E-Mail-Passwort unterscheidet anmelden.
  
-Hat man weitere Domainsso 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.+Wenn man keine weitere Domain hatdann ist im Home unter `websites/public_html/` die Standarddomain `http://sitename.in-berlin.de/erreichbar. 
 +Wie unterschiedliche Sitenamen oder Domains funktionieren, ist unter [[DomainSitename|Domains und Sitenamen]] beschrieben.
  
-Für solche oder ähnliche Sonderwünsche bitte einfach den [[kontakt|Support]] kontaktieren.+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 [[kontakt|Support]] wenden.
  
-## 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 [[#Spezielle_Anwendungen_Applikationsserver|Applikationsserver]] zu benutzen, oder beim [[kontakt|Support]] nachzufragen, ob dieses Paket nachinstalliert werden kann.+## Weiterleitungen
  
-Da die Daten des Webservers auch auf dem Shellserver verfügbar sind, kann man dort schon Dinge testen (PHP, Perl uswsind 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.+Weiterleitungen von Domains auf andere kann man über .htaccess-Dateien oder über Symlinks einrichten.
  
-## SSL/https+### .htaccess
  
-Wer seine Webseite mit SSL bzw. mit https absichern will, braucht als erstes ein [[wd>x509|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.+Eine automatische Umleitung von einer Webseite auf die Domain example.org würde man mit folgender Datei unter `websites/public_html/.htaccess` erreichen:
  
-Hat man das Zertifikat, dann legt man die am besten auf dem Shellserver ab und sagt dem [[kontakt|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).+    RewriteEngine On 
 +    RewriteRule ^/?(.*https://example.org/$1 [R,L]
  
-Will man nur seine Site `sitename.in-berlin.de` verschlüsseln, und keine eigene Domain, dann reicht eine Anfrage beim [[kontakt|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:+### Symlinks
  
-### StartSSL+Eine Möglichkeit von Weiterleitungen von Domains beim IN-Berlin ist mittels eines [[wd>https://de.wikipedia.org/wiki/Symbolische_Verknüpfung|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:
  
-[StartSSL](http://startssl.com) 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+    cd ~/websites/ 
 +    rmdir public_html 
 +    ln -s example.org public_html
  
-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.+## Anwendungen / CGIs
  
-### CACert+Auf dem Webserver laufen alle üblichen CGI-Plattformen (Perl, Ruby, Python, SSI, PHP). 
 +Falsl bestimmte Module oder CGIs fehlen, bitte an den [[kontakt|Support]] wenden. 
 +Eine genaue Beschreibung des Moduls hilft uns, das schnell umzusetzen, am besten schon mit Debian-Paketnamen.
  
-[CACert](http://cacert.org) ist ein Projektdas Vertrauen dadurch aufbautdass alle Teilnehmer des Projekts mal ein Dokument zur Verifikation der Persönlichkeit (VereinsregisterauszugPersonalausweis, Reisepassvorgelegt habenIn der Wikipedia findet sich eine genauere Beschreibungwie die Verifikation abläuft+Auf dem Shellserverauf dem man die Daten bearbeitet und hochlädkann man dort auch schon Dinge teste (PHPPerl usw. sind installiert). 
 +Allerdings sind manchmal bestimmte Module nicht installiert oder andersherumauf dem Shellserver, nicht aber auf dem Webserver installiert, oder sie liegen in unterschiedlichen Versionen vor.
  
-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. +### Nicht-shared-webhost-fähige Anwendungen
  
-Nachteil an CACert istdass es in gängigen Browsern nicht enthalten istDas 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.+Es gibt leider immer mehr Anwendungendie nicht als CGI auf einem Shared Webhost funktionierenEs lassen sich ein paar Grundregeln sagen:
  
-### Selbstsigniert+ * 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.
  
-Will man die verschlüsselte Webseite nur für sich selber benutzen, dann kann auch ein selbstsigniertes Zertifikat reichenDann braucht man dieses Zertifikat nur einmal zu akzeptieren bzwnur einmal den Fingerprint zu checken, und kann danach immer auf diese Webseite zugreifen+Als einzige Alternative bietet sich hier ein [VServer](https://www.in-berlin.de/provider/vserver.html) an
-Besucher müssen natürlich bei jedem Besuch immer wieder eine Warnung wegklicken, um diese Webseite zu sehen.+Auf diesem muss man sich aber selber um die Wartung und sämtliches Setup kümmern, was Fachwissen und kontinulierlicher Zeit voraussetzt.
  
-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)`).+### Wordpress
  
-**Beispiel** (auf dem Shellserver einloggendann das hier tun):+Wer als Teilnehmer einen Blog laufen lassen willkann 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.
  
-    gnrp@Endurance:~$ openssl genrsa -out domain.tld.key 4096 +Ein Wordpress-Blog bekommt manindem man sich beim [[kontakt|Support]] meldet.
-    Generating RSA private key4096 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+## TLS/SSL/https
  
-Wir richten standardmäßig eine Webseite mit https und mit normalem http einWill man nur https erlauben und keine verschlüsselten Verbindungen mehr, so kann man das mit einer [[wd>htaccess|.htaccess-Datei]] machen+IN-Berlin unterstützt [Let's Encrypt](https://letsencrypt.org/). Wir erstellen standardmäßig für sämtliche Domains auf unseren Servern SSL-Zertifikate von letsencrypt. 
-Ein Beispielwie eine .htaccess-Datei aussieht, die im Root einer Webseite liegt (also z.B. unter `websites/public_html/.htaccess`):+Zum Ausprobieren: Die eigene Webseite mit `https://` statt `http://` am Anfang aufrufen. 
 + 
 +### https-only 
 + 
 +Mit einer [[wd>htaccess|.htaccess-Datei]] kann man nur https erlauben und unverschlüsselte Verbindungen automatisch umleiten
 +Eine Internetsuche zeigt man zahlreiche Beispielewas man damit konfigurieren kann (z.B. auch Passwortschutz für Verzeichnisse). 
 +In der offiziellen Dokumentation für [mod_rewrite](https://httpd.apache.org/docs/current/mod/mod_rewrite.html) 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     RewriteEngine On
-    RewriteRule ^$ https://www.example.org/$1 [R]+    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.
  
-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) ## Datenbanken (MySQL, PostgreSQL)
  
 Wir haben einen PostgreSQL- und einen MySQL-Server, auf denen jeder User beliebig viele Datenbanken haben kann. 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 [[kontakt|Support]], welchen Datenbanktyp (MySQL oder PostgreSQL) er haben will und welchen Namen die Datenbank haben sollDann legen wir die an und legen euch i.d.R. in euer Homeverzeichnis eine nur für euch lesbare Datei mit dem Usernamendem Datenbanknamen und dem Passwort. Die Datenbankserver sind, je nach verwendeter Datenbank:+Datenbanken anlegen ändern oder löschen geht im [[https://service.in-berlin.de/|Service-Interface]]. Die Zugangsdaten werden dort angezeigtdas Passwort kommt per extra Mail. Die Datenbankserver sind, je nach verwendeter Datenbank:
  
  * mysql.in-berlin.de  * mysql.in-berlin.de
  * postgresql.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 [[shell|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.+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 [[shell|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.
  
-Alternativ kann man auch die bekannten Webinterfaces phpmyadmin bzw. phppgadmin benutzen unter:+Als dritte Alternative bieten sich die Webinterface phpmyadmin bzw. phppgadmin an:
  
  * https://user.in-berlin.de/phpmyadmin  * https://user.in-berlin.de/phpmyadmin
  * https://user.in-berlin.de/phppgadmin  * https://user.in-berlin.de/phppgadmin
  
-## Spezielle Anwendungen/Applikationsserver 
  
-Für spezielle Anwendungen, die einen eigenen Webserver mitbringen, haben wir einen Applikationsserver. Auf diesem Applikationsserver kriegt man auf Anfrage beim [[kontakt|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.+## Besonderheiten des Setups
  
-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 angebenein Webseitenbesucher sieht hiervon nichts. +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 weiterder die Anfragen verarbeitet.
- +
-## 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.+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.
  
-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.+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 willschreibt am besten den [[kontakt|Support]] an.
  
-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 [[kontakt|Support]] anschreiben. 
webseiten.1396190599.txt.gz · Zuletzt geändert: 2014/03/30 16:43 von chris