immerda:FAQ:Webhosting
Häufige Fragen zu Webhosting
Dies ist eine Wikiseite mit häufigen Fragen zu Webhosting. Diese Seite ist nicht abschliessend und kann jederzeit durch dich und andere ergänzt oder verbessert werden. Füge deine Fragen und allfälligen Antworten einfach hinzu! Solltest du dir unsicher sein, so zögere nicht uns zu kontaktieren!
Weitere Informationen zur Benützung von Webhosting findest du auf der entsprechenden Wiki-Seite
Kann ich/können wir bei euch meine/unsere Seite hosten?
Sicher kannst du das. Beachte dazu die Wiki-Seite um ein neues Webhosting zu bestellen.
Kann unsere Seite oder Teile davon auch mit SSL geschützt werden?
Ja, wir setzen dabei auf unsere eigene CA und euer Webhosting ist automatisch mit einem Zertifikat dieser Zertifizierungsstelle ausgerüstet.
Für euer Webhosting haben wir auch die Möglichkeit, dass ihr ein eigenes Zertifikat haben könnt. Kontaktiert uns diesbezüglich einfach.
Ich möchte meine Seite oder Teile davon auf https umleiten, wie mache ich das?
Am einfachsten kommst du mit dieser Frage zu uns, dann können wir dir hierbei helfen. Ansonsten, wenn du bereits andere Rewrite-Regeln in .htaccess Dateien aktiviert hast, kannst du dies folgendermassen machen:
RewriteEngine On RewriteCond %{HTTPS} !=on RewriteCond %{HTTP:X-Forwarded-Proto} !=https RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Meine xy-Skripte haben keine Schreibberechtigung!
Unsere Umgebung ist per default so abgesichert, dass nur beschränkt Schreibrechte bestehen.
Bei Seiten, welche bereits auf die neuere Umgebung migriert wurden (einfach daran zu erkennen, ob ihr per SFTP auf eure Seite zugreift), ist die Schreibberechtigung einfach handbar: Die Ordner oder Dateien mit Schreibrechten für die Skripte müssen auch Schreibrechte für die Gruppe haben.
Es ist nicht notwendig die Schreib- und Leserechte global (chmod 777) zu vergeben und wir raten davon auch dringend ab, da die von uns eingeführte Userseparation so durch euch eigentlich wieder aufgehoben wird!
Wie kann ich die Zugriffe auf meine Webseite analysieren?
Eine Auswertung der access_log des Webservers bringt keine zuverlässigen Daten bzgl. der Zugriffe. Wir haben vor den Webserver einen Cache-Proxy geschaltet, der (hoffentlich) einen Großteil der Zugriffe abfängt, um die Belastung der Server zu reduzieren. Die access_log des Webserver enthalten daher nur einen Teil der Zugriffe.
Falls ihr an einer aussagekräftigen Statistik interessiert seid, könnt ihr diese bei uns "bestellen". Zur Erstellung der Statistik setzen wir Piwik ein. Die dabei entstehenden Logs sind vollständig anonymisiert und enthalten keine rückverfolgbaren IP-Adressen.
Nachdem meine Seite auf einen neuen Server geschoben wurde, meldet mein SFTP Programm, dass der Schlüssel nicht verifiziert werden konnte. Was kann ich tun?
Neuer Server führt zu neuem Schlüssel. D.h. du musst den alten entfernen, sowie den Fingerprint des neuen mit den von uns publizierten vergleichen.
Unter Linux Systemen wirst du den alten Schlüssel meistens so los:
ssh-keygen -f ~/.ssh/known_hosts -R ftp.$MEINE_SEITE
Wie kann ich meine Webseite mit einem Passwortschutz ausstatten?
Angenommen ihr habt ein Wiki und wollt, dass nur die Mitglieder der Gruppe Zugang haben. Dann sollte beim Aufruf der Seite ein Fenster erscheinen, in das Benutzername und Passwort eingeben werden muss.
Sagen wir die URL, unter der das Wiki aufgerufen wird, hiesse: www.example.org/wiki/index.php. Um den Passwortschutz einzurichten, müssen zwei Dateien angelegt werden: .htaccess und .htpasswd. Diese Dateien werden per ftp-Client in das Verzeichnis (den Ordner) /wiki geladen. Das ist alles.
Die .htaccess - Datei muss folgendes beinhalten:
- AuthName „hier-steht-ein-text“ (Text erscheint im Zugangsfenster, Gänsefüßchen bleiben)
- AuthType Basic
- AuthUserFile /var/www/vhosts/example.org/www/wiki/.htpasswd
- require valid-user
Statt example.org muss euer Domainname gesetzt werden. Und falls der nachfolgende Ordner im Verzeichnis nicht wiki heißt, ebenfalls entsprechend angepasst werden.
In der .htpasswd - Datei stehen die autorisierten BenutzerInnen und Passwörter und zwar in folgender Form:
- Anna:s295lg7923
- Arthur:57nkms94ngl
- Bodo:.......
Die Zeichenfolge hinter den Vornamen ist der Hashwert des Passwortes. Denn die Passwörter stehen nicht im Klartext, sondern müssen verschlüsselt, „gehasht“ werden. Einfach und komfortabel geht das auf dieser Seite: https://htpasswd.immerda.ch/
Der Punkt vor dem Dateinamen zeigt an, dass es sich um unsichtbare Dateien handelt. Die meisten ftp-clients, wie z.B. FileZilla, zeigen auch die unsichtbaren Dateien an.
Die .htaccess-/.htpasswd-Dateien nicht mit LibreOffice/OpenOffice oder MS Word erstellen, sondern mit einem einfachen Text-Editor. Siehe z.B.: https://www.zdv.uni-mainz.de/3571.php
Wer sich in das Thema .htaccess und Passwortschutz vertiefen will, findet hier ausführliche Anleitungen und Erklärungen: http://de.selfhtml.org/servercgi/server/htaccess.htm#verzeichnisschutz
Wichtig: Aus Performance Gründen ist bei vielen Webhostings nicht aktiviert, dass .htaccess Dateien beachtet werden. Setzt euch doch mit uns in Verbindung, falls ihr das Gefühl habt, dass die Dateien nicht beachtet werden.
Macht ihr regelmässig Backups von unserer Seite oder sollen wir das selber machen?
Jein. Also wir betreiben keinen Backupservice, den ihr selbstständig zum restoren benötigen könnt. In der Planung sind Skripte, mit welchen ihr von eurem Webhosting ganz einfach ein Backup machen könnt.
Weiter schauen wir schon, dass wenn wir Hardware-Ausfall haben (oder ähnliches) eure Seite, mit möglichst aktuellen Daten, wieder online kommt. Aber diese Backups könnt ihr soweit selber nicht gebrauchen, also wenn ihr mal was verhauen habt oder so, weil ihr etwas umbaut, dann können wir euch da nicht weiter helfen.
Wenn ihr auf Nummer sicher gehen wollt, resp. ihr mal etwas grösseres umbaut und von exakt dem Stand vor dem Umbau ein Backup haben möchtet, dann macht selber eines. Dies soweit noch von Hand, bis wir dir Skripte zur Hand haben.
Ist ein veraltetes Theme auf meiner Seite ein Einfalltor für einen Hack? Soll ich unbedingt auf eine andere Version des Themes wechseln, auch wenn mir die alte besser passt?
Eine gute Frage, die aber nicht ganz einfach zu beantworten ist.
An und für sich können Themes natürlich auch Sicherheitslücken beinhalten und sollten somit auch geupdated werden. Dazu muss aber nicht ein neues Theme verwendet werden, sondern einfach das alte sollte nach wie vor gewartet werden. D.h. wenn etwas bekannt wird, sollte es entsprechend geflickt werden.
Ob dies der Fall ist, findest du vermutlich am besten heraus, wenn du explizit nach Lücken für dein Theme suchst und schaust, ob es noch entsprechend geflickt wurde. Solche Informationen findest du sicher auf der Webseite deines Themes, resp. in Foren deines CMS.
Grundsätzlich, sind die Möglichkeiten bei Themes für schlechten Code sicher kleiner und es ist deshalb unwahrscheinlicher, dass es Lücken aufweist. Auf der anderen Seite, werden Themes, aber eher auch durch unerfahrenere ProgrammiererInnen entwickelt und sind sicher auch nicht so gut reviewed, wie offizieller Code des CMS. Bei den offiziellen Themes von CMS, sollte man aber schon einen gewissen Standard erwarten dürfen und auch, dass es noch 1,2 Release weiter gepflegt wird.