webseiten
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige ÜberarbeitungLetzte ÜberarbeitungBeide Seiten, nächste Überarbeitung | ||
webseiten [2016/02/20 12:53] – letsencrypt hinzugefügt julian | webseiten [2021/04/26 19:12] – Hinweis auf shell.in-berlin.de chris | ||
---|---|---|---|
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 | ||
- | | + | |
## Webseiten erstellen | ## Webseiten erstellen | ||
- | Hat man keine weitere Domain, so kann man Webseiten | + | Die Webseiten |
- | Hat man weitere | + | Wenn man keine weitere |
+ | Wie unterschiedliche Sitenamen oder Domains funktionieren, | ||
- | Für solche oder ähnliche Sonderwünsche bitte einfach | + | Zusätzliche Domains liegen in der Regel unter `websites/ |
+ | 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]] | ||
- | ## 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, | + | ## Weiterleitungen |
- | 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, | + | Weiterleitungen von Domains |
- | ## SSL/https | + | ### .htaccess |
- | Wer seine Webseite | + | Eine automatische Umleitung von einer Webseite |
- | Hat man das Zertifikat, dann legt man die am besten auf dem Shellserver ab und sagt dem [[kontakt|Support]], | + | RewriteEngine On |
+ | RewriteRule ^/?(.*) https:// | ||
- | Will man nur seine Site `sitename.in-berlin.de` verschlüsseln, | ||
- | Für eigene Domains empfehlen wir drei Möglichkeiten, | + | ### Symlinks |
- | ### letsencrypt | + | Eine Möglichkeit von Weiterleitungen von Domains beim IN-Berlin ist mittels eines [[wd> |
+ | Ein Symlink ist eine Verknüpfung im Dateisystem. | ||
+ | Hierfür würde man in seinen websites/ | ||
+ | Wenn man also von example.in-berlin.de (unter `public_html/ | ||
- | Viele haben schon von [letsencrypt](https: | + | cd ~/websites/ |
+ | rmdir public_html | ||
+ | ln -s example.org public_html | ||
- | ### StartSSL | ||
- | [StartSSL](http: | + | ## Anwendungen |
- | StartSSL verwenden wir auch für unsere sichtbaren verschlüsselten Dienste wie z.B. das Service-Interface oder den Mailserver. | + | 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. | ||
- | Nachteil an StartSSL ist, dass es eine israelische CA ist, und damit auch israelischen Datenschutzbestimmungen und Gesetzen unterliegt. | + | Auf dem Shellserver, auf dem man die Daten bearbeitet |
+ | Allerdings sind manchmal bestimmte Module nicht installiert oder andersherum, | ||
- | ### CACert | + | ### Nicht-shared-webhost-fähige Anwendungen |
- | [CACert](http:// | + | Es gibt leider immer mehr Anwendungen, die nicht als CGI auf einem Shared Webhost funktionieren. Es lassen |
- | 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. | + | * Alles, was als Docker-Container installiert wird, funktioniert nicht. |
+ | * Die meiste Software, die exzessiv | ||
+ | * Software, die bei der Installation root sein muss, funktioniert nicht. | ||
- | 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, | + | Als einzige Alternative bietet sich hier ein [VServer](https:// |
+ | Auf diesem | ||
- | ### Selbstsigniert | + | ### Wordpress |
- | Will man die verschlüsselte Webseite nur für sich selber | + | Wer als Teilnehmer einen Blog laufen lassen will, kann dafür |
- | Besucher müssen natürlich bei jedem Besuch immer wieder eine Warnung wegklicken, um diese Webseite zu sehen. | + | 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 |
- | Wie man ein Zertifikat selber erstellt, findet | + | Ein Wordpress-Blog bekommt |
- | **Beispiel** (auf dem Shellserver einloggen, dann das hier tun): | ||
- | gnrp@Endurance: | + | ## TLS/SSL/https |
- | 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 | + | IN-Berlin unterstützt [Let's Encrypt](https:// |
+ | Zum Ausprobieren: | ||
- | ### SSL-only | + | ### https-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 [[wd> | + | Mit einer [[wd> |
- | Ein Beispiel, wie eine .htaccess-Datei | + | 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](https:// | ||
+ | |||
+ | Folgende | ||
RewriteEngine On | RewriteEngine On | ||
- | RewriteRule ^$ https:// | + | |
+ | | ||
+ | |||
+ | Diese Regel würde alle Anfragen von `http:// | ||
- | Diese Regel würde alle Anfragen von http:// | ||
## Datenbanken (MySQL, PostgreSQL) | ## Datenbanken (MySQL, PostgreSQL) | ||
Wir haben einen PostgreSQL- und einen MySQL-Server, | Wir haben einen PostgreSQL- und einen MySQL-Server, | ||
- | 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 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: | + | Datenbanken anlegen ändern oder löschen geht im [[https:// |
* mysql.in-berlin.de | * mysql.in-berlin.de | ||
* postgresql.in-berlin.de | * postgresql.in-berlin.de | ||
- | Die Datenbankserver sind von allen IN-Berlin-Servern | + | 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 | ||
+ | Dort sind die üblichen Tools `mysql` und `mysqldump` bzw. `psql` und `pg_restore` und `pg_dump` installiert. | ||
- | Alternativ kann man auch die bekannten Webinterfaces | + | Als dritte Alternative bieten sich die Webinterface |
* https:// | * https:// | ||
* https:// | * https:// | ||
- | ## Spezielle Anwendungen/ | ||
- | Für spezielle Anwendungen, | + | ## Besonderheiten des Setups |
- | Erreichbar ist die Anwendung dann unter einer beliebigen Adresse. Da auch dieser Server hinter dem Pre-Proxy | + | 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. |
- | + | ||
- | ## 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, | + | 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, | + | Einige Setups werden |
+ | Wer so ein Spezialsetup haben will, schreibt 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.txt · Zuletzt geändert: 2021/08/24 19:45 von julian