webseiten
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Nächste Überarbeitung | Vorherige ÜberarbeitungNächste ÜberarbeitungBeide Seiten, nächste Überarbeitung | ||
webseiten [2014/02/19 00:02] – Externe Bearbeitung 127.0.0.1 | webseiten [2018/02/04 15:26] – julian | ||
---|---|---|---|
Zeile 4: | Zeile 4: | ||
* den Shellserver zum Testen und Hochladen, siehe auch [[shell|Shell]]. | * den Shellserver zum Testen und Hochladen, siehe auch [[shell|Shell]]. | ||
- | * einen Prä-Proxy | + | * einen Pre-Proxy |
- | * verschiedene Webserver, je nach PHP-Version (momentan 5.2 und 5.3). | + | * verschiedene Webserver, je nach PHP-Version (momentan 5.2, 5.3, 5.4, 5.6 und 7.0). |
## Webseiten erstellen | ## Webseiten erstellen | ||
Zeile 15: | Zeile 15: | ||
Für solche oder ähnliche Sonderwünsche bitte einfach den [[kontakt|Support]] kontaktieren. | Für solche oder ähnliche Sonderwünsche bitte einfach den [[kontakt|Support]] kontaktieren. | ||
- | ## CGIs | + | ## Weiterleitungen |
- | 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 [[# | + | Hat man eigene Domains, dann will man evtl. unter allen die gleiche Webseite erreichbar haben, z.B. soll example.in-berlin.de auf example.org weiterleiten. Dafür gibt es prinzipiell zwei Möglichkeiten: |
- | 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, | + | ### .htaccess |
- | ## SSL/https | + | Das kann man erreichen, indem man eine [[wd> |
- | Wer seine Webseite mit SSL bzw. mit https absichern will, braucht als erstes ein [[wd> | + | RewriteEngine On |
+ | RewriteRule ^$ http://www.example.org/ | ||
- | Hat man das Zertifikat, dann legt man die am besten | + | Dann wird man beim Aufruf von example.in-berlin.de direkt |
- | Will man nur seine Site `sitename.in-berlin.de` verschlüsseln, | + | ### Symlinks |
- | Für eigene Domains empfehlen wir drei Möglichkeiten, sich ein Zertifikat zu holen: | + | Die zweite Möglichkeit, eine Weiterleitung einzurichten, |
+ | Wenn man also von example.in-berlin.de (unter public_html/ | ||
- | ### StartSSL | + | cd ~/ |
+ | rmdir public_html | ||
+ | ln -s example.org public_html | ||
- | [StartSSL](http:// | ||
- | StartSSL verwenden wir auch für unsere sichtbaren verschlüsselten Dienste wie z.B. das Service-Interface oder den Mailserver. | + | ## CGIs |
- | Nachteil an StartSSL ist, dass es eine israelische CA ist, und damit auch israelischen Datenschutzbestimmungen und Gesetzen unterliegt. | + | 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 [[# |
- | ### CACert | + | 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, |
- | [CACert](http:// | + | ## SSL/https |
- | + | ||
- | 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, | + | |
- | + | ||
- | ### 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)`, | + | |
- | **Beispiel** | + | IN-Berlin unterstützt [let's encrypt](https:// |
+ | Andere Domains werden umgestellt, sowie das alte Zertifikat zwei Wochen vor dem Ablaufdatum ist. | ||
- | gnrp@Endurance: | ||
- | Generating RSA private key, 4096 bit long modulus | ||
- | ...........................................................................................................................................++ | ||
- | ......................................................................................................................................................................................................................................................................++ | ||
- | e is 65537 (0x10001) | ||
- | | ||
- | gnrp@Endurance: | ||
- | 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 | ### SSL-only | ||
- | Wir richten standardmäßig eine Webseite mit https und mit normalem http ein. Will man nur https erlauben und keine verschlüsselten | + | Wir richten standardmäßig eine Webseite mit https und mit normalem http ein. Will man nur https erlauben und keine unverschlüsselten |
- | Ein Beispiel, wie eine .htaccess-Datei aussieht, die im Root einer Webseite liegt (also z.B. unter `websites/ | + | |
RewriteEngine On | RewriteEngine On | ||
Zeile 81: | Zeile 65: | ||
Wer eine Datenbank braucht, schreibt dafür einfach eine Anfrage an den [[kontakt|Support]], | Wer eine Datenbank braucht, schreibt dafür einfach eine Anfrage an den [[kontakt|Support]], | ||
- | | + | * 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 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. | ||
Zeile 88: | Zeile 72: | ||
Alternativ kann man auch die bekannten Webinterfaces phpmyadmin bzw. phppgadmin benutzen unter: | Alternativ kann man auch die bekannten Webinterfaces phpmyadmin bzw. phppgadmin benutzen unter: | ||
- | | + | * https:// |
- | * https:// | + | * https:// |
## Spezielle Anwendungen/ | ## Spezielle Anwendungen/ | ||
- | Für spezielle Anwendungen, | + | Für spezielle Anwendungen, |
- | Erreichbar ist die Anwendung dann unter einer beliebigen Adresse. Da auch dieser Server hinter dem Präproxy | + | Erreichbar ist die Anwendung dann unter einer beliebigen Adresse. Da auch dieser Server hinter dem Pre-Proxy |
## Besonderheiten des Setups | ## Besonderheiten des Setups |
webseiten.txt · Zuletzt geändert: 2021/08/24 19:45 von julian