Static-Web-Pakete: Unterschied zwischen den Versionen
(Austattungsunterschiede rein, allgemeies .htacces auth raus) |
(Ergänzung zu cron+php.., allgemeines auf Pakete Seite verschoben) |
||
Zeile 5: | Zeile 5: | ||
Der SW-Webspace unterscheidet sich kaum vom DW-Webspace - außer: | Der SW-Webspace unterscheidet sich kaum vom DW-Webspace - außer: | ||
* keine Datenbanken | * keine Datenbanken | ||
* keine Cronjobs | * keine Cronjobs* | ||
* kein CGI, PHP, Python, Perl... | * kein Skripte* (CGI, PHP*, Python, Perl...) | ||
* keine App-Server | * keine App-Server | ||
Zeile 13: | Zeile 13: | ||
Backups und Hot-Standby sind völlig identisch. | Backups und Hot-Standby sind völlig identisch. | ||
*Außer Skripte für den Paket-Admin zu administrativen Zwecken, d.h. | |||
man darf seinen Logfile-Auswertungsprogramm per Cronjob oder | |||
event-handler starten und sogar CGI/PHP als Paket-Admin verwenden, um | |||
die "bunten" Bildchen anzeigen zu lassen. Ebenso darf man ein eigenes | |||
Webfrontend zur Konfiguration des Pakets betreiben. | |||
Das ist ein Entgegenkommen Hostsharings, um SW Pakete auf gleich hohem Niveau | |||
handhabbar zu halten wie DW Pakete. Wir gehen davon aus, dass diese Funktionen | |||
keine nenneswerte Belastung der SW-Server darstellen, weil "administrative Funktionen" nur | |||
sporadisch genutzt werden. | |||
Version vom 27. Mai 2009, 08:30 Uhr
Das Static-Web-Paket besitzt einige Besonderheiten, auf die hier konkret eingegangen werden soll.
Ausstattung
Der SW-Webspace unterscheidet sich kaum vom DW-Webspace - außer:
- keine Datenbanken
- keine Cronjobs*
- kein Skripte* (CGI, PHP*, Python, Perl...)
- keine App-Server
Die grundlegende Technik und Handhabung von Mail, Webspace, Accounts, Logfiles etc, aber auch des nächtlichen, vollständigen Backups und Hot-Standby sind völlig identisch.
- Außer Skripte für den Paket-Admin zu administrativen Zwecken, d.h.
man darf seinen Logfile-Auswertungsprogramm per Cronjob oder event-handler starten und sogar CGI/PHP als Paket-Admin verwenden, um die "bunten" Bildchen anzeigen zu lassen. Ebenso darf man ein eigenes Webfrontend zur Konfiguration des Pakets betreiben.
Das ist ein Entgegenkommen Hostsharings, um SW Pakete auf gleich hohem Niveau handhabbar zu halten wie DW Pakete. Wir gehen davon aus, dass diese Funktionen keine nenneswerte Belastung der SW-Server darstellen, weil "administrative Funktionen" nur sporadisch genutzt werden.
Aufschalten von Subdomains
Auch Subdomains können ganz normal per Dom-Order Formular aufgeschaltet werden.
Für Domains, die nicht bei Hostsharing liegen, wird eine Subdomain direkt mit action=setup per Dom-Order Formular aufgeschaltet.
Domains die bei Hostsharing liegen sind hingegen zunächst vom Domainadmin freizuschalten, damit sie von einem anderen Paket zur vollständigen Verwaltung der Zone aufgeschaltet werden können.
Im Beispiel soll die Subdomain pic.example.org der Domain example.org eines Dynamik-Web Pakets auf ein Static-Web Paket aufgeschaltet werden.
Zunächst wird die Subdomain nochmals explizit auf die HS Nameserver delegiert. Hierdurch wird die Freigabe der Subdomain zur vollständigen Aufschaltung (mit eigem Zonefile) auf ein anderes Paket signalisiert.
(Die Domain ist hier dem User xyz00-abc zugeordnet.)
xyz00-abc@h01 cp /etc/bind/pri.example.org ~/doms/example.org/etc
Editieren des Zonenfiles:
xyz00-abc@h01 vim ~/doms/example.org/etc/pri.example.org
Ersetzen der Seriennummer durch {SIO} und weitere Platzhalter einsetzen (siehe Verwalten der Zonendaten).
Am Ende der pri.example.org sind folgende Zeilen einzufügen:
pic.example.org. IN NS dns1.hostsharing.net. pic.example.org. IN NS dns2.hostsharing.net. pic.example.org. IN NS dns3.hostsharing.net.
Bitte auf die Punkte achten!
Dann folgt ein
xyz00-abc@h01 touch ~/doms/example.org/etc/pri.* \ ~/doms/example.org/etc/zonefile.upd
um das Update in Gang zu setzen.
Bei der Aufschaltung der Subdomain pic.example.org wird entsprechend geprüft ob diese dafür freigegeben ist (und auch nicht zwischenzeitlich von einem anderen Paketadmin aufgeschaltet wurde).
Nun kann das Dom-Order Formular ins ~/etc Verzeichnis des Static-Web Paketes kopiert und ausgefüllt werden.
Aber erst wenn die Änderung des Zonenfiles erfolgreich erfasst wurden, kann der Setup-Auftrag erfolgreich durchlaufen. Prüfen ob die Änderung bereits erfolgreich erfasst wurde: (kann ca. 5 Minuten dauern)
xyz00-abc@h01 dig @dns1.hostsharing.net "pic.example.org" NS | grep '^sw.example.org'
Erst jetzt kann der dom-order mit
xyz00-abc@h01 touch ~/etc/dom-order.upd
erfolgreich angestoßen werden.
Ist ein Fehler aufgetreten, muss das Dom-Order Formular und das File dom-order.upd "getoucht" werden!