|
|
| (16 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| Das Static-Web-Paket besitzt einige Besonderheiten, auf die hier konkret eingegangen werden soll. | | Das Static-Web-Paket gibt es seit mehreren Jahren nicht mehr. Daher ist diese Seite fast leer. |
|
| |
|
| == Ausstattung ==
| | {{Textkasten|gruen|SW nur bis 04/2013 bestellbar|Das SW-Paket ist nicht mehr buchbar! Bestandspakete werden solange es relevante Nutzerzahl gibt weiter geführt.}} |
| | |
| Der SW-Webspace unterscheidet sich kaum vom DW-Webspace - außer:
| |
| * keine Datenbanken
| |
| * keine Cronjobs
| |
| * kein 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.
| |
| | |
| Was heißt das konkret?
| |
| | |
| Unsere Systeme sind z.Zt. (Mai 2009) hochwertige HDD mit RAID 5, demnächst RAID 10.
| |
| D.h. wir brauchen jetzt 1,5-fachen, dann doppelten Speicherplatz. Aber
| |
| wir haben auch ein Hot-Standysystem, was jederzeit sofort mit aktuellen
| |
| Daten (nicht Daten von gestern) starten kann. Also nochmal Faktor 2.
| |
| Zusätzlich haben wir noch jede Nacht inkrementelle Backups.
| |
| | |
| Insgesamt braucht damit 1 GB Webspace:
| |
| | |
| 2 GB (auf dem Produktiv-System, RAID 10, 15k RPM SAS-Platten)
| |
| 2 GB (auf dem Standby-System, RAID 10, 15k RPM SAS-Platten)
| |
| 4 GB (auf dem Backup-System, RAID 5, SATA-Platten)
| |
| | |
| Also 1 GB Webspace wird durch die Redundanz auf extrem teuren
| |
| Festplatten vervierfacht und auf vergleichswiese preiswerten Festplatten
| |
| nochmal vervierfacht.
| |
| | |
| Nun können wir aber nicht alle System "vollhauen", sondern müssen
| |
| Reserve behalten, damit die Benutzer auch nachbestellen können. Außerdem
| |
| sind neue Server nicht gleich "optimal ausgelastet". Wir kalkulieren mit
| |
| rund 50% Auslastung der Festplatten.
| |
| | |
| Damit entfällt preislich also noch mal etwa das Doppelte auf das eine 1
| |
| GB Webspace - und HS hat noch nichts daran verdient: da sind die Server
| |
| nicht drin, die Anbindung nicht, der Rackspace nicht, der Strom nicht,
| |
| die Hostmaster nicht und auch der Vorstand nicht - und auch nicht die
| |
| Last, die das Backup nächtlich erzeugt.
| |
| | |
| Aber warum ist DW dann teurer als SW? DW erzeugt mehr komplizierte
| |
| Schreib- und Lesezugriffe auf die HDDs als SW, vor allem durch
| |
| Datenbanken. Auch ändern sich viel schneller größere Datenvolumina, so
| |
| dass das Backup anspruchsvoller ist. (Ein Kunststück ist bereits, das
| |
| Backup nachts "fertig" zu bekommen, damit es tagsüber nicht bremst.)
| |
| | |
| (Anmerkung: Schaut mal, was bei DELL so ein 2x QuadCore, 48 GB RAM, 4x
| |
| SAS Server kostet...)
| |
| | |
| Man könnte natürlich abspecken: kein Backup oder nächtlich nur ein paar
| |
| Pakete/jedes Paket einmal die Woche, kein RAID 10, sondern nur 5 oder
| |
| gar nicht, kein SAS, sondern nur SATA...
| |
| | |
| Aber wollen wir das? Oder wollen wir Qualitätshosting.
| |
| | |
| | |
| | |
| == 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.)
| |
| | |
| <pre><nowiki>
| |
| xyz00-abc@h01 cp /etc/bind/pri.example.org ~/doms/example.org/etc
| |
| </nowiki></pre>
| |
| | |
| Editieren des Zonenfiles:
| |
| | |
| <pre><nowiki>
| |
| xyz00-abc@h01 vim ~/doms/example.org/etc/pri.example.org
| |
| </nowiki></pre>
| |
| | |
| Ersetzen der Seriennummer durch '''{SIO}''' und weitere Platzhalter einsetzen (siehe [[Verwalten der Zonendaten]]).
| |
| | |
| Am Ende der pri.example.org sind folgende Zeilen einzufügen:
| |
| | |
| <pre><nowiki>
| |
| pic.example.org. IN NS dns1.hostsharing.net.
| |
| pic.example.org. IN NS dns2.hostsharing.net.
| |
| pic.example.org. IN NS dns3.hostsharing.net.
| |
| </nowiki></pre>
| |
| | |
| Bitte auf die Punkte achten!
| |
| | |
| Dann folgt ein
| |
| | |
| <pre><nowiki>
| |
| xyz00-abc@h01 touch ~/doms/example.org/etc/pri.* \ ~/doms/example.org/etc/zonefile.upd
| |
| </nowiki></pre>
| |
| | |
| 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)
| |
| | |
| <pre><nowiki>
| |
| xyz00-abc@h01 dig @dns1.hostsharing.net "pic.example.org" NS | grep '^sw.example.org'
| |
| </nowiki></pre>
| |
| | |
| | |
| Erst jetzt kann der dom-order mit
| |
| <pre><nowiki>
| |
| xyz00-abc@h01 touch ~/etc/dom-order.upd
| |
| </nowiki></pre>
| |
| erfolgreich angestoßen werden.
| |
| | |
| Ist ein Fehler aufgetreten, muss das Dom-Order Formular und das File dom-order.upd "getoucht" werden!
| |
| | |
| | |
| ----
| |
| [[Kategorie:Pakete bei HS]]
| |
| [[Kategorie:HSDoku]]
| |
