Eigene Website auf Userpages einrichten

Jeder Nutzer an der Universität Koblenz kann mit seiner Uni-Kennung eine eigene Homepage (Webseite) erstellen, die über die URL https://userpages.uni-koblenz.de/~<kennung> aufgerufen werden kann. <kennung> ist dabei der erste Teil der Uni-Koblenz Email-Adresse. Der Zugriff auf die Webseiten der Kennung mustermann mit der Email-Adresse mustermann@uni-koblenz.de wäre dementsprechend über die URL https://userpages.uni-koblenz.de/~mustermann möglich.

Wer überlegt ein eigenes Wordpress zu betreiben, sollte dies nicht auf Basis von userpages tun, sondern die unter dem Punkt "Zentral gewartete Wordpress-Instanz" vorliegende Beschreibung lesen.

Dateien hochladen

Die für die Webseite notwendigen Daten müssen in das public_html-Verzeichnis der jeweiligen Benutzer-Kennung abgelegt werden, in dem mindestens eine index.html oder eine index.php-Datei abgelegt sein muß. Das public_html-Verzeichnis befindet sich direkt im Windows Z:-Laufwerk, bzw. dem Linux-Home-Verzeichnis.

Der Zugriff auf das Home-Verzeichnis ist alternativ auch via ssh (scp) z.B. über den Linux-Rechner penguin2.uni-koblenz.de oder mit Hilfe eines SFTP-fähigen Clients (z.B. FileZilla) über ftphost.uni-koblenz.de jeweils nach erfolgreicher Benutzerauthentifikation möglich. Auch ein Zugriff über smb ist wie im Profil unter dem Punkt Heimatverzeichnis beschrieben einrichtbar.

Bitte beachten Sie: Diese (privaten) Homepages dürfen auf keinen Fall zu kommerziellen Zwecken genutzt werden! Sollten wir Hinweise auf kommerzielle Nutzung finden, wird die betreffende Seite sofort und ohne Nachfrage gesperrt!

Zugriffsrechte setzen

Damit die eigenen Webseiten aufgerufen werden können, müssen die Rechte insbesondere des eigenen Home-Verzeichnisses als auch des Unterverzeichnisses public_html so gesetzt sein, das der Web-Server die Dateien darin lesen darf.  Auf der anderen Seite gilt es die eigenen Webseiten vor Zugriffen durch andere Nutzer über das Dateisystem  zu schützen. Daher sollte das eigene Home-Verzeichnis nicht für jedermann les- und schon gar nicht für alle Nutzer schreibbar sein.

Die minimal notwendigen Rechte sind folgende: der Benutzer nobody, als auch der Benutzer wwwrun müssen das eigene Z:-Laufwerk (Linux-Home-Verzeichnis der jeweiligen Benutzer-Kennung, in dem das public_html-Verzeichnis liegt)   als auch public_html und die Dateien selbst lesen und die Verzeichnisse betreten dürfen.

Diese Rechte können auf dem Linux-Rechner penguin2.uni-koblenz.de gesetzt werden. Meldet man sich dort mit ssh (unter Windows dient das Programm putty dem gleichen Zweck)  unter der eigenen Benutzer-Kennung z.B. mustermann an, reichen folgende Kommandos zum Setzen der notwendigen ACLs, die einzeln nacheinander  eingegeben und jeweils mit der Eingabe-Taste abgeschlossen werden müssen.

chmod 700 ~
nfs4_setfacl -a A::wwwrun@linuxdc.uni-koblenz.de:RX ~
nfs4_setfacl -a A::nobody@linuxdc.uni-koblenz.de:RX ~
nfs4_setfacl -a A::wwwrun@linuxdc.uni-koblenz.de:RX ~/public_html
nfs4_setfacl -a A::nobody@linuxdc.uni-koblenz.de:RX ~/public_html
nfs4_setfacl -a A::wwwrun@linuxdc.uni-koblenz.de:R ~/public_html/index.php
nfs4_setfacl -a A::nobody@linuxdc.uni-koblenz.de:R ~/public_html/index.php
chmod g+rx ~ ~/public_html

Durch diese Rechte-Vergabe haben nur der Benutzer selbst als auch die genannten Web-Server Nutzer wwwrun und nobody lesenden Zugriff auf die Dateien im Home- und public_html -Verzeichnis. Anderen Nutzern ist der Zugriff jetzt nicht mehr möglich.

Benutzer-Authentifizierung via .htaccess

Authentifizierung via AuthBasic

Ein älteres, AuthBasic genanntes Verfahren zur Authentifizierung von Benutzern ähnelt der gerade beschriebenen Shibboleth-Variante sehr, wie man an der unten angegebenen .htaccess-Beispeil-Datei sehen kann.

# AuthBasic
AuthName "Private"
AuthType Basic
AuthBasicProvider ldap-ko-uid ldap-ko-mail
Require user mustermann musterfrau
# require valid-user

Die AuthBasic-Authentifizierung ist der Shibboleth-basierten Authentifizierung zunächst sehr ähnlich. Auch hier wird der Benutzer beim Besuch einer so geschützten Webseite zur Eingabe seiner Kennung oder seiner Email-Adresse und dem zugehörigen Passwort aufgefordert. Ein wesentlicher Nachteil gegenüber Shibboleth besteht jedoch bezüglich des eingegebenen Passworts, weshalb AuthBasic nicht mehr verwendet werden sollte.

Bei einer AuthBasic-Authentifizierung eines Benutzers kann der Betreiber der Webseite das eingegebene Passwort im Klartext sehen. Aus diesem Grund ist die AuthBasic-Authentifizierung ab dem userpages-Server für PHP 8.0 (userpages8.uni-koblenz.de) nicht mehr verfügbar. Die Shibboleth-basierte Authentifizierung kann mit userpages74.uni-koblenz.de (PHP 7.4) und neueren userpages-Servern verwendet werden.

Authentifizierung über eine eigene Benutzerdatenbank

Neben der Möglichkeit beim Aufruf einer Webseite eine Benutzerauthentifizierung eines an der Universität Koblenz existierenden Benutzers auszulösen, besteht für den Betreiber einer Webseite über .htaccess auch die Möglichkeit eine in einer Datei stehende eigene Benutzerdatenbank mit Benutzernamen und zugehörigen Passwörtern anzulegen. Das folgende Beispiel zeigt die hierzu benötigte .htaccess-Datei:

# htpasswd-Pfad z.B.: /home/user/htpasswd
AuthUserFile /home/user/htpasswd
AuthBasicProvider file
require user anyuser

In diesem Fall kann ein Besucher der Webseite mit der oben stehenden .htaccess-Datei sich mit dem Benutzernamen anyuser authentifizieren, der zuvor vom Betreiber der Webseite in der Benutzerdatenbank /home/user/htpasswd mit einem von ihm bestimmten Passwort eingetragen wurde. Die Benutzerdatenbank htpasswd sollte dabei nie in das Verzeichnis public_html gelegt werden, sondern besser z.B. ins eigene Home-Verzeichnis wie oben für den Benutzer user angedeutet, wo sie nicht über Webzugriffe erreichbar ist.

Die Erstelung und Verwaltung der htpasswd-Datei erfolgt mit dem Programm htpasswd2, d.h. mit Hilfe dieses Programms kann der Webseitenbetreiber Paare von je einem Nutzernamen und einem verschlüsselten Passwort für die Anmeldung erzeugen und löschen. Das htpasswd2 -Programm steht allerdings nur Linux-Nutzern zur Verfügung (z.B. auf linux.uni-koblenz.de).

Windows-Nutzer können auf freie Passwort-Generatoren zurückgreifen, z.B. auf http://www.htaccesstools.com/htpasswd-generator/. Die dort erzeugten Nutzername/Passwort-Paare müssen dann mittels Notepad in der Benutzerdatenbank eingetragen bzw gelöscht werden.

CGI-Skripte verwenden

Für dynamische Web-Inhalte können auch sogenannte CGI-Skripte ausgeführt werden. Diese Dateien müssen  die Endung .cgi haben und werden dann unter den Rechten des jeweiligen Benutzers ausgeführt.

PHP verwenden

Auf userpages kann zum Aufbau der eigenen Webseiten auch PHP verwendet werden. PHP-Skripte laufen immer mit den Rechten des Benutzers, dem die PHP-Dateien gehören, nicht mit den Rechten des Webservers (wwwrun) . Dabei besteht die Wahl zwischen verschiedenen PHP-Versionen.

• PHP Version 5  
  Skripte werden mittels suphp unter den Rechten des Benutzers ausgeführt. Skripte z.B. der Benutzer-Kennung mustermann, werden daher mit den Rechten der Kennung mustermann ausgeführt. Die Version 5 von PHP gilt inzwischen als veraltet.

• PHP Version 7 und 8 
  Skripte werden mit benutzerspezifischen php-fpm-Pools unter den Rechten des jeweiligen Benutzers ausgeführt. Skripte z.B. der Benutzer-Kennung mustermann, werden daher mit den Rechten der Kennung mustermann ausgeführt.
  php-fpm ist sehr performant, da es nach dem ersten Aufruf einer PHP-Seite eines Nutzers für eine gewisse Zeit einen php-Prozess aktiv läßt, um weitere PHP-Seiten-Anfragen bearbeiten zu können. Dadurch entfällt ein ansonsten bei jedem weiteren Seitenaufruf notwendiger Neustart des PHP-Interpreters.

Auswahl der PHP-Version

Die Auswahl der PHP-Version kann über die hierzu eingerichtete PHP-Versions-Seite jederzeit geändert werden. Der Aufruf dieser Webeite funktioniert nur von innerhalb des Universitäts-Netzwerks aus, oder über eine VPN-Verbindung zur Universität.

Obwohl unabhängig von der gewünschten PHP-Version immer über userpages.uni-koblenz.de auf Webseiten zugegriffen wird, erfolgt die Bearbeitung der Anfragen je nach konfigurierter PHP-Version transparent für den Nutzer auf unterschiedlichen Servern. Ist für eine Benutzer-Seite z.B. PHP 7.4 aktiviert, wird eine Anfrage auf eine Webseite wie beispielsweise https://userpages.uni-koblenz.de/~mustermann auf dem Server userpages74.uni-koblenz.de/~mustermann bearbeitet. Ist PHP8 aktiviert, werden Anfragen über userpages.uni-koblenz.de hingegen automatisch und nicht sichtbar für den Benutzer auf userpages8.uni-koblenz.de bearbeitet.

Dieser Umstand kann für eine "sanfte" PHP-Umstellung einer Webseite genutzt werden, die bisher auf z.B. PHP7.4 basierte und in Zukunft mit PHP8 genutzt werden soll. In diesem Fall kann man die bestehende Webseite einfach über den userpages-Server aufrufen, auf dem PHP8 verwendet wird, also über https://userpages8.uni-koblenz.de/~user. In diesem Fall wird unabhängig von einer gemachten PHP-Versions-Einstellung des Benutzers user immer PHP8 verwendet.

Wenn alles funktioniert kann schließlich die PHP-Version für den Benutzer user generell auf PHP8 geändert werden, so das anschließend auch bei Zugriffen über https://userpages.uni-koblenz.de/~user automatisch PHP8 verwendet wird.

Da PHP sich schnell weiterentwickelt, kann ein testweiser Wechsel auf eine neue PHP-Version durchaus auch dazu führen, das die Webseite zunächsnicht mehr funktioniert und erst an die neue PHP-Version angepasst werden muß.

Zugriffe über spezifische userpages-Server dürfen aber nur vorübergehend für Tests erfolgen, auf Dauer muss der Zugriff immer über userpages.uni-koblenz.de (mit gewünschter PHP-Einstellung) erfolgen nicht über z.B. userpages8. Öffentlich darf immer nur die https://userpages.uni-koblenz.de -URL verwendet werden niemals eine Versionsspezifische URL wie https://userpages74.uni-koblenz.de/...

Benutzerspezifische PHP-Einstellungen

Die Skriptsprache PHP kennt zahlreiche Einstellungen. Ein Teil dieser Einstellungen kann von jedem Benutzer einzeln,  lokal verändert werden. Auf diese Weise kann z.B. die log-Datei für Fehlermeldungen in das eigene Verzeichnis umgeleitet werden, so das mögliche Fehlermeldungen sichtbar werden.

Alle Benutzer-eigenen PHP-Einstellungen müssen in einer Datei .user.ini gesammelt werden, die genau in dem Verzeichnis liegen muss, in dem auch die PHP-Datei liegt, die im Browser aufgerufen wird.
Es darf natürlich mehrere .user.ini-Dateien in unterschiedlichen Verzeichnissen geben.

Eine Beispiel-.user.ini-Datei des Benutzers mustermann könnte wie unten stehend aussehen

; comments in this file only by using: ";"
; In php-fpm and php user settings can locally only be set in a
; .user.ini file residing in the very same directory like
; the php script executed. Changing a setting here might
; take up to 5min to become effective because of caching.
; .user.ini files in other parent directories are *not* searched
; Settings that can be changed in a .user.ini are limited. See:
; http://php.net/manual/de/configuration.file.per-user.php
; http://www.php.net/manual/en/ini.list.php
; Trying to set php values in .htaccess leads to an apache error.
;
display_errors = On; # Display Error messages in Browser
html_errors = On; # Also show HTML-errors
max_execution_time = 15; # The maximal execution time for scripts
; where to write error log messages
error_log = /home/mustermann/public_html/error_log.txt;

Werden Einstellungen in einer .user.ini-Datei vorgenommen bzw verändert, kann es aufgrund von caching bis zu 5min dauern, bis das diese Einstellungen wirksam werden.

Anbindung einer Datenbank

Für den Aufbau einer Webseite ist es nicht ungewöhnlich, das eine Datenbank benötigt wird. Hier bietet sich der zentrale MariaDB-Server an, auf dem jeder Nutzer der Universität Datenbanken anlegen kann.

Zentral gewartete Wordpress-Instanz

Für alle an Wordpress interessierten Benutzer gibt es die Möglichkeit der Nutzung einer zentral gepflegten Wordpress-Installation, mittels derer Sie schnell und sicher eine Homepage anbieten können. Informationen zur Einrichtung, Verwaltung und dem Zugriff auf die eigene Homepage finden Sie unter wp.uni-koblenz.de.

Bitte beachten Sie: Diese (privaten) Homepages dürfen auf keinen Fall zu kommerziellen Zwecken genutzt werden! Sollten wir Hinweise auf kommerzielle Nutzung finden, wird die betreffende Seite sofort und ohne Nachfrage gesperrt!