Die "Webserver Survival Guide"

[Christoph Maus]

Das Buch für alle Leute, die was über Webserver lernen wollen.
Von der Einrichtung her, bis zur Administration und Sicherung der Server.

Webserver Survival Guide

Software auf CD-ROM

Das Buch über Webserver - vom nickles.de Server Administrator Thomas Wölfer. Ein Hand-On Guide für alle, die sich die schwere Lernphase etwas leichter machen wollen - ganz egal ob man einen Webserver für die Firma betreibt oder aber ein ambitionierter Hobby-Webmaster ist.

Das Buch behandelt die Sicherung von Servern, die Administration und Überwachung, aber auch die effektive Nutzung von vorhandenen Ressourcen: Wie betreibt man eine große und interaktive Webseite ohne den sonst üblichen Serverpark? Wie nutzt man die vorhandene Bandbreite optimal?

Der Einsatz von Squid als Reverse Proxy wird abei genauso behandelt wie die Verwendung von Kompression bei HTTP.

Auch wichtig: Überwachung der Servergesundheit und Einbruchserkennung. Woran erkennt man eigentlich einen Einbruchsversuch, und wie hält man sich über den Arbeitszustand eines (entfernten) Rechners auf dem Laufenden?

Und weil es so schön dazu passt gibts auch noch ein Kapitel das dem interessierten Techniker die Sprache der Werbevermakter erklärt: Wovon das Marketing dort redet und welche Begriffe was bedeuten - nicht der Wichtigste aber auch ein wichtiger Aspekt beim Betrieb eines Servers.

Behandlet werden sowohl der Apache als auch der IIS, MySQL, der SQL-Server, Squid, PHP, ASP und WMI sowie weitere hilfreiche Programme, Programmiersprachen und Technologien. Eben alles, was man beim Betrieb eines Webservers wissen muss.



Erscheinungstermin: 09/2002.

Gibt's hier zum Preis von (naja, nicht ganz billigen) 39,90 € inc. Versand:
http://www.nickles.de/sales/sales_print.php3?id=95


Hab gestern selbst mit Thomas Wölfer gechattet, und er hat mir versichert, dass das Buch min. 2 Jahre Lernphase überflüssig macht.

cm

PS: Der Mann is ein Profi -> 5 Jahre eigene Erfahrung.

[Christoph Maus]

Aso, hab ich vergessen:

Hat ca. 275 Seiten, auch wenn's nicht auf der Bestellseite steht. (weil's noch nicht ganz fertig is)

cm

[Christoph Maus]

Hi, jetzt ist ne Lesoprobe erschienen:

Die Leseprobe
WEBSERVER SURVIVAL GUIDE

Der Webserver Survival Guide ist das Buch über den professionellen Betrieb von Webservern - vom Nickles.de Administrator Thomas Wölfer. Behandelt wird unter anderem der Betrieb, die Sicherung und die Optimierung solcher Systeme. Hier eine Leseprobe.
(Stand vom: 12.9.2002)

Dieser Beitrag ist eine Leseprobe aus dem Buch 'Webserver Survival Guide'.

1 Caching – wie man Rechnerleistung spart
Ich bin ein Gewohnheitstier. Ich rauche seit 20 Jahren die gleiche Zigarettenmarke, trage fast eben so lange Schuhe vom gleichen Hersteller und kann es auch nicht lassen ununterbrochen neue Programmiersprachen, Betriebssysteme und Softwarewerkzeuge auszuprobieren. Außerdem gehe ich immer in die gleichen Lokale. Und da bestelle ich auch immer die gleichen Getränke: Im Sommer gibt’s Weißweinschorle, im Winter Rotwein. Immer wieder.

Das mag nun langweilig erscheinen, es hat aber auch seine Vorteile. Ein Vorteil ist der, dass das Maß an Überfüllung im Lokal völlig gleichgültig ist. Egal wie viele andere Gäste das Lokal hat – wenige Sekunden nach dem Eintreten habe ich sehr verlässlich meinen Drink. Im Sommer Weißweinschorle, im Winter Rotwein. Immer sofort und ohne gefragt zu werden. Dummerweise will ich manchmal auch was anderes trinken, aber dann steht der Wein schon vor mir: Willkommen in der wunderbar ärgerlichen Welt des Caching.

Grundlagen zum Caching
Unter Caching versteht man Verfahren bei denen Daten zwischengespeichert werden. Die Zwischenspeicherung ist dafür da, damit eine spätere Anforderung nach den gleichen Daten schneller erledigt werden kann als das normal möglich ist. Im IT Bereich ist Caching deutlich weiter verbreitet als in Lokalen – und besonders im Internet ist das Cachen von Informationen extrem wichtig. Das ist auch der Grund warum sich gleich drei Kapitel dieses Buches mit verschiedenen Aspekten des Caching beschäftigen.

Weltweites, Site-weites Caching
Man kann bei der Erzeugung von dynamischen Webseiten Caching verwenden, man kann sogar ganze Websites cachen. Letzteres wird von Anbietern wie Akamai Technologies sogar weltweit durchgeführt: Mehr dazu erfahren Sie im Kapitel über Squid. Außerdem cachen auch ISPs Seiten die häufig abgefragt werden – das verringert den Traffic, der von Dial-Up Kunden erzeugt wird.

Caching im Browser
Natürlich cachen auch Browser Daten von Webseiten. Dabei werden die zuletzt besuchten oder geladenen Seiten und Dateien auf der lokalen Festplatte des Anwenders zwischengespeichert. Sowohl der Netscape als auch der Opera und der Internet Explorer bieten diese Möglichkeit, die dem Surfer ein schnelleres Surf-Verhalten vorgaukelt: Statt eine Seite immer wieder neu zu laden, wird sie einfach aus den lokalen Cache-Daten ausgelesen und angezeigt.

Das ist praktisch, denn eine lokal gespeicherte Seite wird natürlich deutlich schneller angezeigt als eine die erst per HTTP geladen werden muss. Doch dieses Vorgehen hat auch seine Nachteile. Was, wenn der Seiteninhalt sich in der Zwischenzeit verändert hat? – Der Surfer bekommt diesen Tatbestand dann gar nicht mit: Das liegt kaum im Interesse des Webseitenbetreibers. Noch schlimmer wird die Sache, wenn das Cachen von Caching-Proxies beim ISP übernommen wird. Dann hat weder der Surfer noch der Seitenbetreiber tatsächlich einen Einfluss darauf, welche Version einer Seite beim Surfer nun wirklich ankommt.

Zumindest ist das in der Theorie so, denn in der Praxis gibt es sehr wohl Einflussmöglichkeiten. Letztlich raten weder der Browser noch der Cache-Proxy des ISP nicht, wie lange eine Seite wohl Gültigkeit haben könnte, sondern versuchen das Verfallsdatum zu ermitteln. Wenn man als Seitenbetreiber die Browser der Clients und die Caching-Proxies der ISPs dabei richtig unterstützt, dann ist das Caching von Webseiten für alle von Vorteil.

Wie man das richtig macht, erfahren Sie im Rest dieses Kapitels.


Caching und das Verfallsdatum – welches nehmen ?
Über ein Detail muss man sich beim Caching von Webseiten immer im klaren sein: Egal ob man selbst etwas unternimmt oder nicht – irgendwo im Zuge der Seitenauslieferung kommt garantiert irgend eine Form des Caching zum Zuge: Im dümmsten Fall resultiert die dann aber darin, dass jede Datei auf dem Webserver von jedem Client immer und immer wieder angefordert wird – völlig gleichgültig ob sie sich nun verändert hat oder nicht. Allein das ist ein Grund sicherzustellen, dass zumindest auf der eigenen Seite – also auf dem Server – alles richtig gemacht wird.

Wie bereits erwähnt ist die elementare Grundlage des Cachen von Webseiten das Verfallsdatum der betroffenen Daten. Dummerweise ist das aber nicht ganz ohne weiteres eindeutig zu klären, zumindest nicht ohne Mithilfe des Webserver Admins.

Grundsätzlich betrachtet sind Verfallsdaten keine sonderlich aufwendige Geschichte. Das Verfallsdatum von Lebensmitteln im Kühlschrank berechnet sich beispielsweise wie folgt:

Mindestens haltbar bis = Aktuelles Datum – 14 Tage

Das gilt zumindest für meinen Kühlschrank und natürlich auch nur dann, wenn sich etwas im Kühlschrank befindet das zumindest ansatzweise an Nahrungsmittel erinnert. Bei anderen Kühlschränken mag das anders sein.

Verfallsdaten bei Webseiten
Im Fall von Webseiten ist die Sache etwas schwieriger gestrickt. Eine Datei, die von einem Webserver ausgeliefert wird ist nämlich mit einer ganzen Reihe von Daten versehen. Folgende Daten kommen ins Spiel, wobei einige davon nur bei bestimmten Betriebssystemen vorliegen:
:arrow: Das Datum, an dem die Datei angelegt wurde
:arrow: Das Datum, an dem die Datei zuletzt verändert wurde
:arrow: Das Datum, an dem die Datei zuletzt zum Lesen geöffnet wurde
:arrow: Das Datum, an dem die Datei zuletzt vom Webserver ausgeliefert wurde
:arrow: Das Datum, an dem die Datei zuletzt von einem bestimmten Client angefordert wurde
:arrow: Das Datum, an dem die Datei in einem Proxy-Cache abgelegt wurde und so weiter und so fort.


Was man nun natürlich erreichen möchte ist, dass die Clients die Daten abrufen diese nur dann – und wirklich nur dann – abrufen, wenn sich der Inhalt der Datei auch verändert hat. Das geht natürlich nicht, denn der Client kann den Abruf ja erzwingen: Man kann dem Client (oder dem Proxy) aber zumindest die Informationen liefern die er braucht um herauszufinden, ob eine Datei noch gültig ist oder nicht.

Obwohl sich Proxies und Browser teilweise unterschiedlich verhalten kann man beide mehr oder minder mit den gleichen Informationen versorgen, und deshalb wird im Folgenden immer nur der Begriff »Client« verwendet, wenn es um die Seite einer HTTP-Verbindung geht, die eine Datei anfordert.

Letzten Endes gibt es nur ein einziges Verfallsdatum einer Datei, und das ist dann, wenn der Webserver-Admin (bzw. das Marketing, der Chef, die Werbe- oder die Presseabteilung) beschließt, das die Datei veraltet ist. Das macht die Sache aber etwas unhandlich, denn der Client kann dieses Datum nicht erraten. Also muss man es ihm mitteilen, und dafür gibt es verschiedene Wege.

Meta-Tags: Fürs Cachen nicht das Wahre
Viele Webautoren verlassen sich bei der Angabe eines Verfallsdatums auf HTML Meta-Tags. Diese Meta-Tags befinden sich im Bereich einer Webseite und sind einfach einzubauen: Praktisch alle ernstzunehmenden Webseiten-Editoren (Notepad, VI,…) lassen das Einfügen eines solchen Meta-Tags einfach in Form einer Textbearbeitung zu, andere Programme wie Dreamweaver oder Frontpage haben dafür eigene Befehle und Optionen.

So schön nun Meta-Tags sind und so leicht sie einzufügen sind: Sonderlich effektiv ist diese Methode nicht.

Und das das so ist hat mehrere Gründe. Einer davon ist besonders leicht vor Augen zu führen: Nehmen Sie doch mal Ihren bevorzugten HTML–Editor (Notepad) und versehen Sie damit die .GIF-Datei, die Ihr Firmenlogo enthält, mit einem Meta-Tag.

Genau: Das geht nicht.

Nun setzt sich eine Webseite aber meist aus ein bisschen Text und einer Menge an Bildern zusammen. Die Startseite von www.nickles.de besteht zum Beispiel aus ca. 70 KB HTML und JavaScript und verwendet dann aber noch circa 40 Bilder (von denen einige mehrmals auf der Seite verwendet werden) die zusammengenommen nochmals ca. 100 KB Umfang haben.

Mehr Gründe gegen Meta-Tags Mit einem Meta-Tag im HTML-Code der Seite würde man die Haltbarkeit also für weniger als 50 Prozent des echten Seitenumfanges festlegen, denn alle Bilder hätten ja keine Haltbarkeitsinformationen. Dummerweise sind aber die Bilder meist deutlich statischer als der echte HTML-Code: Das Firmenlogo, ein »empty.gif« für Platzierungszwecke und ähnliche Bilder werden sich aller Wahrscheinlichkeit nach nie ändern während sich der HTML-Code der Startseite selbst (hoffentlich) alle paar Tage verändert. Genau die Elemente die am besten vom Client gecached werden könnten, werden also nicht gecached und darum immer wieder abgerufen. Dumme Sache.

Ein weiteres Problem mit Meta-Tags ist die Tatsache, das solche Tags normalerweise nur vom Browser betrachtet werden: Der liest den kompletten HTML- Code und somit auch die Meta-Tags, während Proxies sich mit diesen Details normalerweise nicht beschäftigen.

Eine Haltbarkeitsinformation in Form von Metatags hat also zum einen nur für den schlecht zu cachenden Teil einer Webseite überhaupt Bedeutung und wird obendrein nur von einem Teil der Clients überhaupt berücksichtigt. Darum sind Pragma: No-Cache oder ähnliche Metatags zwar ganz lustig und können vielleicht auch dazu dienen, ahnungslose Graphiker zu Beeindrucken, für viel mehr sind sie aber nicht gut.

HTTP-Header: Der richtige Weg zur schnellen Seite
Eine Webseite setzt sich aus diversen Bestandteilen zusammen. Da ist zum einen der ganz normale HTML-Teil. Dann gibt’s CSS-Informationen und Skripte (in Form von JavaScript, JScript oder einer der anderen Skriptsprachen die von den verschiedenen Browsern auf unterschiedlichen Stufen unterstützt werden) wobei sowohl CSS als auch Scripte nicht unbedingt innerhalb des eigentlichen HTML Dokumentes eingebettet sein müssen. Schließlich kann eine Seite noch Bilder in diversen Formaten, sowie Objekte oder Referenzen auf Objekte enthalten: Diese sind immer außerhalb des eigentlichen HTML untergebracht.

Fordert eine Client nun eine Webseite über deren URL an, dann wird zunächst der reine HTML Code angefordert und dann werden – je nach verwendeter HTTP-Version in unterschiedlichen Reihenfolgen und Verbindungsarten – die eingebetteten Elemente, die nicht auf der HTML Seite untergebracht sind, angefordert. Für jedes angeforderte Element existiert nun ein HTTP-Header. Dabei handelt es sich um einen kleinen Datensatz, der Informationen über die betreffende Datei enthält. Dieser HTTP Header wird grundsätzlich versendet – ganz gleichgültig, ob man am Server etwas konfiguriert hat oder nicht. Welche Informationen der Header ab konkret enthält, das ist von der Konfiguration des Servers abhängig.


Verfallsdaten übertragen mit HTTP-Headern
Genau in diesen HTTP-Headern ist auch das Verfallsdatum für alle verwendeten Dateien richtig aufgehoben, denn der HTTP-Header wird von allen Clients berücksichtigt – und er kann für jede Datei einzeln festgelegt werden.

Wird eine Datei per HTTP angefordert, dann sendet der Server zunächst einmal den HTTP-Header für diese Datei, dann eine Leerzeile und schließlich den eigentlichen Inhalt der angeforderten Datei. Ein typischer HTTP-Header sieht folgendermaßen aus:


[code:1:d4dd1f8483]HTTP/1.0 200 OK
Date: Thu, 30 May 2002 14:02:13 GMT
Server: Apache
Last-Modified: Wed, 24 Oct 2001 16:36:29 GMT
ETag: "1df30a-50b-3bd6ee0d"
Accept-Ranges: bytes
Content-Length: 1291
Content-Type: text/html
Age: 155160
X-Cache: HIT from www.nickles.de
Connection: keep-alive[/code:1:d4dd1f8483]


Das ist auch für eigene Webseiten leicht zu überprüfen. Dazu verbindet man sich zunächst einfach per Telnet mit dem eigenen Webserver auf dessen Webserver-Port:

telnet www.MeinServer.com 80

und schickt diesem dann nachdem die Verbindung hergestellt wurde eine entsprechende Anfrage:

GET / HTTP/1.1

Hier endet die Leseprobe. Im folgenden gibt es noch das komplette Inhaltsverzeichnis der Buches.





1 Caching – wie man Rechnerleistung spart
1.1 Grundlagen zum Caching
1.1.1 Weltweites, Site-weites Caching
1.1.2 Caching im Browser
1.2 Caching und das Verfallsdatum: Welches nehmen ?
1.2.1 Verfallsdaten bei Webseiten
1.3 Meta-Tags: Fürs Cachen nicht das Wahre
1.3.1 Mehr Gründe gegen Meta-Tags
1.4 HTTP-Header: Der richtige Weg zur schnellen Seite
1.4.1 Verfallsdaten übertragen mit HTTP-Headern
1.4.2 Zwei Möglichkeiten: Expires und Cache-Control
1.4.3 Verfallsdatum festlegen
1.4.4 Expires-Header setzt Last Modified Time automatisch
1.4.5 Neueren Datums: Cache-Control und ETags
1.5 HTTP-Header mit Apache
1.5.1 Passende Module laden
1.5.2 Verfallsdatum mit Basisregeln festlegen
1.5.3 Max-Age wird automatisch gesetzt
1.6 HTTP-Header mit IIS
1.7 Header programmatisch erzeugen
1.8 HTTP-Header mit CGI
1.9 HTTP-Header mit PHP
1.10 HTTP-Header mit ASP
1.11 Testen: Header-Viewer und Cachebility-Engine
1.12 Dinge, die man nicht cachen will ....
1.13 Caching per HTTP-Header: Vorteile und Gefahren

2 Dynamische Webseiten – Last reduzieren
2.1 Dynamische Seiten erzeugen
2.1.1 Dynamik: Unterschiede zwischen Client und Server
2.1.2 Dynamische Webseiten: Das Problem
2.2 Verzicht auf dynamische Seiten – zumindest nach außen
2.2.1 Dynamikverzicht: Eine Beispielseite
2.2.2 Der Trick: Dynamik on demand – aber einmalig
2.2.3 404: Error-Document geschickt nutzen
2.2.4 Altes Skript baut neues File
2.3 Ein Beispielskript
2.3.1 Beispielskript Schritt für Schritt erläutert
2.3.2 Auf den ersten Blick: Die Änderung bringt nichts
2.3.3 Seiten per Zeitplan löschen – und dadurch erzeugen
2.4 Ein Seitenblick: Last reduzieren mit empty.gif
2.5 Webseiten entdynamisieren: Vorteile und Gefahren

3 Bandbreite sparen, Geld sparen - HTTP-Kompression mit Apache und IIS
3.1 Bandbreitenverbrauch verringern, Last runter Seiten komprimieren
3.1.1 Einsparungen kurz nachgerechnet
3.2 Noch ein Vorteil: Schneller surfen
3.2.1 Grundsatz stimmt – andere Faktoren können stören
3.3 Seite komprimiert ausliefern
3.3.1 Content-Encoding vs. Transfer-Encoding: Oder doch nicht?
3.3.2 Kompression ist ein Spezialfall des Encodings
3.4 Transfer-Encoding mit Apache
3.4.1 Apache braucht Module
3.4.2 mod_gzip konfigurieren leicht gemacht
3.5 Logfile-Format anpassen
3.5.1 Apache braucht ein neues Logfile-Format
3.6 HTML komprimieren mit dem IIS
3.7 Probleme mit komprimierten Webseiten
3.7.1 Ein letzter Hinweis
3.8 HTTP-Kompression: Vorteile und Gefahren

4 Squid, das Powertool
4.1 Alternativen zum Squid
4.2 Grundlegendes zu Proxys
4.2.1 Dumm: 1 LAN + 2 Browser = 2 Anfragen
4.2.2 Wünsche des LAN-Admins
4.2.3 Proxys steigern (meist) das Tempo
4.3 Reverse Proxy
4.3.1 Proxy für eingehende Anfragen
4.3.2 Wo wird gespart?
4.3.3 Sparen, wo es weh tut
4.4 Ein paar Performancedaten
4.4.1 Alles hat seinen Preis, auch der Squid
4.5 Auch nicht schlecht: Squid fürs LAN
4.6 Vergleichbarer Einsatz, höhere Kosten
4.7 Ein Beispiel-Setup unter Linux mit Apache
4.7.1 HTTPD antwortet nicht…
4.7.2 Startskripts konfigurieren: Reihenfolge wichtig
4.7.3 Komische Bindung: Der Grund ist die 302
4.7.4 Nächster Schritt: Squid konfigurieren
4.7.5 HTTP-Port setzen
4.7.6 Stoppwörter festlegen und Caching teilweise ausschalten
4.7.7 Speichermenge und Objektgrößen festlegen
4.7.8 Welches Serverchen hättens denn gern?
4.8 Beispiel 2: Squid auf dem einem, IIS auf zweitem Rechner
4.9 Squid einsetzen: Vorteile und Gefahren

5 Server überwachen
5.1 Standardtools sind vorhanden
5.1.1 Monitoring: Was beobachten?
5.2 Beispiele für Linux und Apache
5.2.1 Ein Minibeispiel
5.2.2 Beispielskript anpassen und selbst verwenden
5.2.3 Festplattenfüllung als HTML-Seite
5.3 Serverüberwachung beim IIS
5.3.1 Monitoring-Skripts mit ASP
5.3.2 Überwachung mit WMI
5.3.3 Monitoring mit APS und WMI: Ein Beispielskript
5.4 Ein Task-Manager mit ASP
5.4.1 Prozesse töten übers Web
5.5 Der Dienste-Manager in ASP
5.5.1 Dienste per Browser verwalten
5.6 Server überwachen: Vorteile und Gefahren

6 Angriffe auf den Webserver – Was steckt dahinter?
6.1 Unerwünschte Nutzung oder Angriff?
6.1.1 Ist der Dienst offen, ist es kein Angriff
6.1.2 Unterscheidung unerheblich: Die Nachteile sind immer da
6.1.3 Der Angriff: Die ersten Schritte
6.1.4 Automatische Löchersuche: Der Normalfall
6.1.5 Selber testen mit Telnet
6.2 Port-Scans: Wie Sie aussehen
6.2.1 Sinnlose Versuche von Mensch oder Maschine
6.3 Was denn nun: Angriff oder nicht?
6.3.1 Angriff oder Hardwaredefekt: Ein Beispiel
6.3.2 Lösung per Zufall: Glück gehabt
6.4 Gefahren durch Angriffe auf den Server

7 Server sichern
7.1 Nur sinnvolle Dienste laufen lassen
7.1.1 Beste Regel: Maximal zwei sichtbare Dienste
7.1.2 Dienste betreiben: Intern oder extern?
7.1.3 Interne Dienste: Besser auf eigenem Rechner
7.2 Unterschiedliche und sichere Passwörter verwenden
7.2.1 Herr der Ringe für Anfänger
7.3 Demilitarisierte Zonen – DMZs betreiben
7.3.1 DMZ per Hardware
7.4 Unerwünschte Accounts, zu viele Accounts
7.5 Sichere Kommunikationswege – sichere Server
7.5.1 Die Lösung: SSH
7.6 Validierung von Benutzereingaben
7.7 Einbrüche erkennen
7.8 Up-to-date bleiben
7.9 Apache-Server unter Linux sichern
7.10 Dienste hier, Module da: Alles nachsehen
7.10.1 Seitenblicke auf TMP-Verzeichnisse
7.11 IIS sichern
7.11.1 Apache und IIS: Schwer zu vergleichen
7.11.2 IIS: Nicht nur ein Webserver
7.12 Wichtiger Unterschied: IIS 4 oder 5 ?
7.12.1 Ports sperren
7.13 Paketfilter einsetzen
7.13.1 Grundlagen für Paketfilter
7.13.2 IIS mit Filtern dichtmachen: Ein Beispiel
7.14 Weitere Anmerkungen zum IIS
7.15 Skript-Mappings entfernen
7.15.1 Weitere wichtige IIS-Tools
7.16 Server sichern: Vorteile und Gefahren

8 Einbruchserkennung mit Snort
8.1 Traffic beobachten
8.1.1 Quellcode verfügbar
8.1.2 Snort-Einträge verstehen
8.2 Ein Seitenblick: TCPDUMP
8.2.1 Kinderkram, aber lustig: Kiddies erschrecken
8.3 Einsatz von Snort: Nur Vorteile

9 Nettes degradieren: Wie man Last richtig verkraftet
9.1 Besser eigene Fehlermeldungen als die von Serverprozessen
9.1.1 Funktionen nach Wichtigkeit sortieren
9.1.2 Funktionen mit größter Lasterzeugung finden
9.1.3 Funktionen nach und nach abschalten
9.2 GetLoad() mit PHP
9.3 GetLoad() mit ASP
9.4 Last verkraften: Vorteile und Gefahren

10 Backupstrategien und Testmöglichkeiten
10.1 Ärger sofort: Ausfall im Webserver
10.1.1 Einfache Regel: Ersatz sofort
10.2 Backups einspielen dauert immer länger, als man denkt und noch länger
10.2.1 Was es alles zu sichern gilt
10.3 Vorteile vom Backup-Server im Einsatz
10.4 Backup in VMWare – Staging Server ohne Hardware
10.5 Kurzer Seitenblick: Hardware, die besser hält
10.6 Zurück zum Staging-Server
10.6.1 Netzwerk im Rechner
10.6.2 Virtuelle Platten: Prima zu sichern
10.7 Normales Sichern der Webseite
10.7.1 Verschiedene Transfermöglichkeiten
10.7.2 Backupversand per E-Mail in PHP
10.7.3 Backupversand per Mail unter Windows
10.8 Problematischer: Datenbankdaten
10.8.1 Einfach: MS-SQL Server
10.8.2 Etwas schwieriger: MySQL
10.8.3 Ein Angebot: Backup als Volltextsuche
10.8.4 Backup und Transfer: Ein Beispiel
10.8.5 Daten wieder einspielen, Beispiel Teil 2
10.9 Was tun ohne mysqldump?
10.10 Backup Strategien – Vorteile und Gefahren

11 Dynamic DNS – Selber hosten ohne Standleitung
11.1 Die Probleme mit dem DNS
11.2 Lösungen mit DynDNS
11.3 DynDNS-Clients: Automatisch updaten
11.3.1 Updatetempo ist wichtig
11.4 Windows IP Setup: Besonders beachten
11.5 DynDNS – Vorteile und Gefahren

12 Technisches Spielzeug – Dinge, die helfen können
12.1 Laptops und Funknetze
12.2 Mehr Netzwerkkarten und Kabel
12.3 Festplatten, besser doppelt
12.4 Monitor-Umschalter
12.5 Datenbankadministration
12.6 Mailserver
12.7 SSH mit Java
12.8 Ein letztes Wort zu Tools

13 Logfile-Analyse oder ein kurzer Ausflug in die Marketingsprache
13.1 Page-Impressions
13.2 Visits – Besucher zählen
13.3 Hits
13.4 IVW
13.5 Ad-Impressions
13.6 Rich-Content-Ads und Fullsize-Ads
13.7 TKP
13.8 Klickraten
13.9 Cost-Per-Click und Cost-Per-Order
13.10 Seitenstatistiken und wie man sie aufstellt
13.11 Logfile-Analyse: Vorteile und Gefahren

Stichwortverzeichnis

Quelle: http://www.nickles.de/c/s/23-0015-251-1.htm


Bestellformular unter http://www.nickles.de/sales/sales_print.php3?id=95
Preis: 39,95 €
Umfang: 239 Seiten Hardcover plus CD


cm