Ein Webprojekt ist ein Ordner auf einem Webserver, in dem HTML-, PHP- oder andere Dateien abgelegt (und teilweise auch ausgeführt) werden können. Das ganze ist unter eine URL (z.b. http://meinewebsite.de) abrufbar. Ein Webprojekt kann eine Website wie eine persönliche Homepage, ein Blog, ein E-Shop oder eine sonstige Webanwendung sein. Webprojekte werden in der Regel von Webdesignern und Webmastern erstellt und betreut.
In der Apache-Welt kommt ein Webprojekt einem einzelnen VirtualHost sehr nahe. Ist aber noch ein bisschen mehr. Obwohl es auch möglich ist mehrere Websites in einem Webprojekt zu speichern, raten wir zu: pro Webprojekt eine Website.
Jedes Webprojekt kann Ziel einer oder mehrerer Domains ein. Domains, oder Subdomains dienen als leicht zu merkende Adressen für das Webprojekt innerhalb des WWW. Domains sind kostenpflichtig und können extra bestellt werden.
Beim Anlegen des Webprojektes wird automatisch eine Adresse zum Testen (Test URL) angelegt. Die heißt immer so wie der Webprojektname + test.frbit.de, zum Beispiel: "http://web1.test.frbit.de". Unter dieser Adresse ist das Webprojekt immer zu erreichen.
Das Wurzelverzeichnis (Root) eines jeden Webprojektes ist immer "/var/www/webpackages/" gefolgt von der Nummer des Webprojekts. Die Nummer ist die Zahl im Namen des Webprojektes. Wenn es z.B. "web123" heisst, dann wäre der absolute Pfad "/var/www/webpackages/123". Diese Angabe ist wichtig bei vielen CMS Systemen.
Jedes Webprojekt liegt auf einem Server der eine feste IP und einen festen Namen (bspw: http1.service.frbit.de). Solange sich der Server nicht ändert (dies kann z.B. bei Wartungsarbeiten passieren) sind diese fest für das Webprojekt. Da auf einem Http-Server mehrere Webprojekte laufen ist es wahrscheinlich, dass mehrere Webprojekte die gleich IP haben. Bei speziellen Anforderungen können wir einen Http-Server mit eigener dedizierter IP für ein Webprojekt sperren.
Für jedes Webprojekt wird ein nicht validiertes Gratiszertifikat (SSL Adresse) angelegt, dieses ist unter der Webprojekt SSL-Testadresse https://web123.ssl.frbit.de erreichbar. Aktuelle Browser warnen hier, weil das Zertifikat nicht erkannt werden kann. Das liegt daran, dass es ein selbst ausgestelltes und nicht von dritter Stelle (Thawte, VerySign .. ) verifiziertes Zertifikat ist. Aus diesem Grund eignet sich das Gratiszertifikat nicht für E-Shops im live Betrieb oder ähnliches. Man kann es aber zur Entwicklung nutzen, oder bei Projekten mit begrenzter Besucheranzahl.
Nicht von öffentlicher Stelle validierte Zertfikate können runtergeladen und importiert werden: In der Übersicht des Webprojektes das SSL Zertifikat (fortrabbit-ca.crt) "runterladen". In einem aktuellen Firefox kann es direkt importiert werden.
Außerdem kann jedes Webprojekt mit https://<jede-domain> erreicht werden. Hier beschwert sich dann der Browser allerdings noch mehr, da, wie bschrieben, das Zertifikat auf *.ssl.frbit.de ausgestellt ist. Nur für Testing geeignet!
Auf Anfrage kann ein vorhandenes Zertifikat installiert werden. Dafür muss es im PEM Format vorliegen, wobei neben dem Zertifikat auch der private RSA Schlüssel _ohne_ Passwortschutz enthalten sein muss.
Ein normales Zertifikat ist in der Regel nur auf eine Domain ausgestellt. Wenn mehrere Domains auf das Webprojekt zeigen (nicht als echte Weiterleitung) dann wird bei diesen "Sekundärdomains" eine Browser-Warnung ausgegeben. Günstiger ist es also: eine einzelne Hauptdomain zu verwenden, alle anderen Weiterleiten (redirect). Außerdem sollte die Subdomain 'www.' weg optimiert werden: www.domain.tld > domain.tld.
Das WWW Verzeichnis ist das Root-Verzeichnis, also die oberste Ebene, auf die von außen via Browser auf das Webprojekt zugegriffen werden kann. Verzeichnisse unterhalb des WWW Verzeichnisses können unter "Verzeichnissen" bearbeitet werden. Die folgenden Einstellungen sind erweiterte VirtualHost Direktiven.
Verzeichnisindizes, Auflistung von Ordnerinhalten. Stellt ein, ob eine Verzeichnis Struktur im Browser angezeigt werden soll, sofern keine Index-Datei hinterlegt ist. So kann man zum Beispiel einfach einen Austausch von Daten realisieren, die vorher per FTP hochgeladen wurden. Gut in Kombination mit einem Passwortverzeichnisschutz.
Intelligente Seitenauswahl. Z.B. zum automatischen erkennen von Sprachversionen einer Website. Wenn aktiv kann basierend auf dem Dateinamen und den Spracheinstellungen des Besuchers ein andere Datei angezeigt werden. Z.B.: index.html.fr -> für französisch, index.html.de -> für deutsch
Um das Webprojekt zum Beispiel während der Entwicklung nicht von außen verfügbar zu machen, kann man hier den Ordner www mit einem Verzeichnisschutz versehen. Ist diese Funktion aktiviert wird ein Benutzername und ein Passwort beim Aufrufen der öffentlichen Adresse im Browser abgefragt. Realisiert wird das durch HTTP-Auth über die LDAP Datenbank. Man kann Verzeichnisschutz auch über andere Methoden (z.B. mit .htaccess) realisieren. Man kann auch alle anderen Verzeichnisse innerhalb eines Webprojektes mit Verzeichnisschutz versehen, siehe unten.
Sendmail ist ein Computerprogramm, das E-Mails von einem Computer zum anderen transportiert. Gerne werden E-Mails in Skripten auf Websites zum Beispiel bei Kontaktformularen via Sendmail geschickt. Leider sind Kontaktformulare oft ein Sicherheitsproblem. Hier lässt sich der Absender einstellen. Da Sendmailskripte historisch betrachtet wahrscheinlich die größte Quelle für Spamversand von Webservern sind ist es inzwischen üblich präventive Maßnahmen hierfür zu treffen.
In der Grundeinstellung (Standardabsender) werden alle ausgehenden Mails über /usr/local/bin/sendmail auf einen automatisch erstellten Absender umgeschrieben (Bspw. web123.hosted@frbit.de) und der (vom Mailscript gesetzte) Absender wird in den Reply-To-Header gesetzt.
Man kann diese Verhalten umgehen indem man in dem verwendeten Mailscript entweder SMTP einsetzt (empfohlen) oder eine existierende E-Mailadresse aus MISH mit aktiviertem Postfach angibt. Alle ausgehenden Mails werden dann von diesem Absender verschickt. Hier sollten nur beachtet werden, dass der Absender nicht beliebig gesetzt werden kann, sofern der Versand über unserer Server erfolgt.
Außerdem kann man sendmail über ein Häckchen bei "Versand von allen Domains des MISH Kontos" so freischalten, dass alle Absender (auch von nicht existierenden E-Mail Adressen) der bei MISH registrierten Domains erlaubt werden.
Um dieses Webprojekt zu erreichen gibt es neben der Testadresse und der Möglichkeit direkt Domains zu bestellen, noch die Option hier Domains die bei einem anderen Provider verwaltet werden auf dieses Webprojekt leiten zu lassen. Beim anderen Webhoster (Provider/Registrar) muss der C-Name oder die IP eingetragen werden (siehe unten), hier muss die Domain(s) dem Webserver bekannt gemacht werden.
Hier kann also eine Liste externer Domains angegeben werden, jeweils eine pro Zeile. Das ist dann nötig, wenn die Domain nicht über MISH sondern bei einem anderen Provider (zB 1&1 oder Strato) registriert wurde. Bei diesem Provider muss dann entweder ein CNAME (Ziel am besten die Test-Adresse zB web123.test.frbit.de verwenden.) oder ein A Record (Ziel ist dann die IP des HTTP Servers. Vorsicht, die kann sich bei Wartungsarbeiten ändern) eingerichtet werden. Für extern eingetragene Domains sind natürlich keine E-Mail Adressen möglich.
Achtung, wenn die Domain auch mit dem Vorsatz "www." auf dieses Webprojekt zeigen soll, müssen hier zwei Einträge gemacht werden. Z.B: "hallowach.de" und "www.hallowach.de".
Hier kann die Standard Zeichencodierung (auch bekannt als "default charset" im Apache Webserver) eingestellt werden. Eigentlich sollte hier keine Modifikation nötig sein, die meisten Quellen liefern Meta-Angaben, wie sie codiert sind.
Ein mögliches Anwendungsszenario ist hier: Wenn ein Webmaster vergessen hat, die Codierung anzugeben und seine Dokumente als ISO-8859-1 (das ist ein veralteter Zeichensatz mit weniger Sonderzeichen) gespeichert hat, der Webserver aber versucht diese als UTF-8 (der aktuelle Standardzeichensatz, enthält sehr viele Sonderzeichen) anzubieten, was dazu führt, dass zB alle Umlaute nicht richtig dargestellt werden.
Es werden standard Webserver Fehlerseiten (Zum Beispiel:Wikipedia: 404 Fehler ) beim Anlegen des Webprojektes in das "errors" Verzeichnis kopiert. Diese können dort (via FTP und Texteditor) verändert werden. Im Control Panel kann die Position von anderen Fehlerseiten ausserhalb des "/error-"Verzeichnisses (zB PHP Skripten) definiert werden. Hier sind die Pfade zu den Fehlerseiten von "/www" aus anzugegeben. Liegt die eigene Fehlerdatei beispielsweise unter "/www/eigene-fehlerdatei.php", dann lautet der Pfad "/eigene-fehlerdatei.php" (OHNE "/www").
Das ist der häufigste Fehler: Nicht Gefunden: Die angeforderte Ressource wurde nicht gefunden, der Link ist tot. Dieser Statuscode kann ebenfalls verwendet werden, um eine Anfrage ohne näheren Grund abzuweisen. Standardpfad: /error/404.html
Zugriff verweigert: Die Anfrage kann nicht ohne gültige Authentifizierung durchgeführt werden. Wie die Authentifizierung durchgeführt werden soll, wird im „WWW-Authenticate“-Header-Feld der Antwort übermittelt. Standardpfad: /error/401.html
Zugriff verweigert: Forbidden, Verboten, Unzulässig; Zugriff für den Rechner des User gesperrt. Standardpfad: /error/403.html
Interner Fehler: Dies ist ein „Sammel-Statuscode“ für unerwartete Serverfehler. Standardpfad: /error/500.html
Wartung: Service Unavailable, Vorübergehend nicht verfügbar; Server überlastet, ausgefallen oder in Wartung. Standardpfad: /error/503.html
Derzeit ist nur PHP konfigurierbar, andere Sprachen (Perl, Ruby, Python) werden nur über cgi-bin ermöglicht.
PHP ist eine sehr populäre serverseitig interpretierte Skriptsprache, die zur Erstellung dynamischer Websites oder Webanwendungen dient. PHP verbraucht Ressourcen und kann in unterschiedlichen Größen und Einstellungen gebucht werden. In der Regel wird PHP zusammen mit MySQL eingesetzt, wie zum Beispiel von vielen CMS- und Blog-Systemen (Wordpress, Moveable Type, Joomla, Typo3). Bei uns läuft es derzeit in der Version: PHP5. PHP kann in unterschiedlichen Stufen aktiviert werden:
Da die Ausführung von PHP Ressourcen verbraucht, müssen diese entsprechend berechnet werden. Aktuelle PHP-Pakete und Preise sind der aktuellen Preistabelle zu entnehmen.
PHP Caches speichern kompilierte PHP Skripte zwischen und stellen einen Speicher für Programmoptimierung zur Verfügung. Dies kann eine PHP Anwendung sehr stark beschleunigen. Welcher Cache am "besten" ist hängt stark von der verwendeten Applikation ab.
Der Alternative PHP Cache (APC) ist ein freier und offener Opcode Cache für PHP. Er wurde erdacht um ein freies, offenes und robustes Gerüst zum Cachen und Optimieren von PHP Zwischencode bereitzustellen. APC ist der "aktuellste" Cache und wird voraussichtlich fester Bestandteil von PHP6.
Schneller, flexibler Opcode Cacher für PHP. http://en.wikipedia.org/wiki/List_of_PHP_accelerators#XCache
Der XDebug Profiler kann helfen Speicher-Verbrauch zu ermitteln und PHP Applikationen zu optimieren. Im "Echtbetrieb" sollte er allerdings ausgeschaltet sein, da er die Applikation enorm verlangsamt und zudem extrem große Datenmengen erzeugt. Das so erzeugte Profil der Anwendung kann dann genutzt werden um heraus zu finden welche Teile (der Anwendung) am meisten Ressourcen verbrauchen, unnötig laufen oder fehlerhaft sind. Beim Webprojekt kann man den PHP XDebug Profiler auf zwei verschiedene Arten aktivieren normal (an) oder trigger.
Bei ersterer Option erstellt der Profiler immer eine Ausgabeprofil. Bei Zweitem (trigger) wird das Ausgabeprofil nur erstellt, sofern eine spezieller Parameter (http://meinedomain.tld/path?XDEBUG_PROFILE=1) in der HTTP Anfrage (GET, Query String) übergeben wird. Das erstellte Profil wird den ein Unterverzeichnis des Webprojektes kopiert (/logs/xdebug.cachegrinder."name-des-scripts").
Wir empfehlen nur mit "trigger" zu arbeiten. Und nur temporär! Die geschrieben Profile können schnell bei einem Aufruf einige Hundert Megabyte groß werden!
ACHTUNG: NICHT IM LIVE BETRIEB AN LASSEN! ES WERDEN SCHNELL HUNDERTE MEGABYTE BIS EINIGE ZEHN GIGABYTE PLATTENPLATZ GESCHRIEBEN (UND IN RECHNUNG GESTELLT)!
steht für Common Gateway Interface. Hier geht es nicht um eine einzelne Scriptsprache sondern vielmehr um eine spezielle Art der Benutzung von einer ganzen Reihe von sprachen. Wenn diese Option aktiviert wird, dann können unter /cgi-bin alle ausführbaren Perl, Pyhton und Ruby Skripte genutzt werden.
Verzeichnisse, die unterstrichen sind, haben weitere Inhalte und können geöffnet werden. Der Pfeil zeigt an, dass ein Verzeichnis geöffnet ist. Es werden nur Verzeichnisse angezeigt, Dateien werden nicht angezeigt. Um die Daten zu bearbeiten bietet sich FTP an. Bei den Verzeichnissen selber können Sachen eingestellt werden, die bei FTP nicht gemacht werden können, wie: Verzeichnisschutz, und Directory Listings.
Jedes Verzeichnis kann bearbeitet werden, hier kann ein Verzeichnisschutz aktiviert werden und vom Webprojekt abweichende VirtualHost Direktiven (Indexes & MultiViews) eingestellt werden. Eine Ausnahme bildet das Verzeichnis WWW, hier kann nur der Verzeichnisschutz eingestellt werden.
Hier kann der Verkehr und der Speicherverbrauch über verschiedene Zeiträume hinweg beobachtet werden. Mehr dazu auf der Seite Hosting Statistiken
Viele Open Source und kommerzielle CMS-, Blog- & E-Shop-Systeme können auf MISH installiert werden, da es hier die meist benötigten Grundvoraussetzungen (MySQL, Apache, PHP) gibt. Folgende Systeme sind bereits erfolgreich auf MISH installiert:
Unter Hotlinking versteht man im allgemeinen das verlinken durch einbetten von Fremdinhalten auf einer Seite. Siehe: Wikipedia Hotlinking.
Dies kann man mit einer so genannten .htaccess-Datei verhindern. Siehe auch: Wikipedia Htaccess.
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?meinedomain\.de/ [NC]
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?zweitedomain\.eu/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png|avi|mp3|flv|swf|mpe?g)$ - [F]
Sendmail ist in /usr/local/bin/sendmail
Bitte beachten, dass der "FROM" der ausgehenden Mail auf web123.hosted@frbit.de umgeschrieben wird, sofern keine andere Adresse in den Webprojekt Einstellungen eingestellt wurde und der Absender von keiner bei MISH registrierten Domain des Systemkontos ist.
Image Magick und GD2 sind bereits in einer aktuellen Version installiert, es kann über PHP, Perl, oder direkt über die Bindings angesteuert werden.
Komplexe CMS Systeme wie z.b. Typo3 oder Magento bestehen gerne aus tausenden von kleinen Dateien. Wenn man diese einzeln via FTP hochlädt, ist das ein recht langwieriger Prozess. Wir haben leider noch keine Shellumgebung, wo der Entwickler eine gepackte Datei hochladen und dann lokal entpacken kann. Alternativ haben wir unser WebFTP (http://webftp.frbit.de/). Das bietet auch die Option eine gepackte Datei serverseitig zu entpacken. Benutzer haben uns allerdings von einem Fehler (wahrscheinlich ist es eher ein Feature) berichtet, bei dem zu lange Dateinamen gekürzt werden. Wir raten daher vorerst doch zur langsamen aber sicheren FTPES-Lösung.
Wird ein sehr großes Projekt mit vielen Besuchern und großen Anforderungen an die Ressourcen geplant ? Kein Problem. Wir stellen gerne alles von dedizierten MySQL Servern und eigenen Storage Spaces über dedizierte HTTP Server mit großer Anzahl von laufenden FastCGI Prozessen bis hin zu Load Balancing über mehrere dedizierte Server zur Verfügung. Einfach anfragen!
Szenario: "Eine Applikation möchte von Innen (also von einem MISH Webserver) nach Aussen telefonieren, kommt aber aufgrund von Firewall Restriktionen nicht raus." Zum Beispiel möchte sich ein CMS-System selbstständig updaten, oder einen RSS Feed laden, oder sonstwie über eine REST-API Daten von einem anderen Server beziehen.
Für die meisten populären CMS-Systeme haben wir bereits Ausnahme-Regeln in der Firewall, kontaktieren Sie uns, wir übernehmen das Ziel dann in unsere Firewall.
Normalerweise setzt PHP die Umgebungsvariables 'HTTPS' bei einem Aufruf einer https:// Seite auf true. Aufgrund der Implementierung der Umsonst-Zertifikate ist das hier aber nicht der Fall. $_SERVER[ 'HTTPS' ] wird also false zurück geben, so lange kein eigenes, echtes Zertifikat installiert ist und die URL https://web123.ssl.frbit.de/ genutzt wird.