Bei vielen Webhostern, zum Beispiel All-Inkl, wird bei FTP Rechten zwischen 2 verschiedenen FTP Benutzern unterschieden: dem eigenen FTP Account von All-Inkl und dem PHP-User („www-data“), der von Scripten genutzt wird.
Das Thema hatte ich schonmal in „All-Inkl Besitzrechte (FTP) nach WordPress Umzug“ angegriffen, allerdings auf eine ungünstige Art und Weise.
Den Besitzer der betroffenen Dateien/Ordner von dem FTP Account auf die PHP-User umzustellen mag zwar eine Zeit lang helfen. Wenn man jedoch an dieser Datei/Ordner noch etwas ändern/hinzufügen möchte – dann natürlich wieder mit dem normalen FTP-Benutzer – muss man den Besitzer wieder auf den FTP Account zurücksetzen.

Beispiel: wp-content/plugins/testplugin möchte jede Sekunde eine .log Datei beschreiben. Diese kontinuierlichen Änderungen werden natürlich austomatisch von einem Script getan. Dazu muss das Script also Ändern-Rechte auf diese Datei haben. Meine alte Lösung: Den Besitzer des Ordner ‚testplugin‘ einfach auf den PHP-User „www-data“ setzen und dann hat das Script alle Rechte. Möchte ich jetzt aber eine Datei in diesen ‚testplugin‘ Ordner hochladen oder das Plugin automatisch updaten oder iiirgendetwas in der Art … Pustekuchen, Ende im Gelände.

Neue Lösung:
Ach, .htaccess ist schon ein tolles Ding! Um die Rechte der Scripts anzupassen reicht 1 Zeile:

AddHandler php5-cgi .php

Ersetzt die 5 ggf. mit der PHP Version, die auf eurem Server läuft. Nun haben alle PHP Scripte die nötigen Rechte.
Wenn nur einzelne Dateien von diesen Änderungen betroffen sein sollen könnt ihr auch folgendes machen:

AddHandler php5-cgi .phptest

Und die .php Datei, die Rechte braucht, die Endung .phptest verpassen.
Oder ihr benennt die Datei in .phpx um, dann sollte sie auch ohne jegliche .htaccess Änderungen laufen.

Bei der Arbeit mit Hyper-V in Kombination mit Snapshots auf einem Microsoft Serverbetriebssystem ist Vorsicht geboten.
Letzte Woche musste ich leider selber erfahren, dass vor allem beim Erweitern der virtuellen Festplatten einiges beachtet werden muss.

Zuerst einige Grundlagen zu Snapshots. Denn wenn man diese Funktion verwendet – und das wird sicherlich schnell passieren, wenn ihr Hyper-V benutzt – sollte man auch etwas darüber wissen.

Ein Snapshot einer VM ist wie der Name schon sagt eine Art Fotografie des aktuellen Stands. In dem Moment, in dem man den Snapshot Button drückt, wird das System, so wie es ist, gespeichert. Egal ob gerade etwas installiert wird, Musik läuft oder die VM einfach nur an ist. Jederzeit kann man jetzt diesen Stand wiederherstellen.
Beispiel:
Microsoft Office 12 Beta soll getestet werden. Kurz bevor die Installation startet wird ein Snapshot gemacht. Der Stand ist jetzt gespeichert. Jetzt kann man alles installieren und testen. Hat man alles erledigt und möchte das System wieder clean haben wird einfach der Stand des Snapshots wiederhergestellt. Keine Deinstallation, keine Reste im System, alles als wäre nichts seit dem Snapshot passiert.

Wie funktioniert das?
Eine VM basiert auf einer .VHD Datei. Eine „Virtual Hard Disc“ ist die virtuelle Festplatte der Maschine und damit die Arbeitsgrundlage. Hat man eine neue VM erstellt, arbeitet man direkt auf dieser VHD.
Wird ein Snapshot erstellt passiert folgendes: im Ordner der VM wird ein Ordner namens „Snapshots“ erstellt. Eine .XML Datei mit der Hardwarekonfiguration des Systems wird in diesem Ordner erstellt. Die .XML Datei hat als Dateinamen eine eindeutige Kennung (GUID … ist wieder ne andere Geschichte). Ein gleichnamiger Ordner wird ebenfalls erstellt.

Dieser enthält widerum 2 gleichnamige Dateien, eine .BIN und eine .VSV Datei:

Ein weiterer Ordner wird ebenfalls erstellt, dieser hat auch eine GUID als Namen. In diesem befindet sich die .AVHD Datei. Auf diese Datei werden wir gleich unser Augenmerk legen.
Aber vorher: Wiederholung prägt ein also hier eine komplette Übersicht der die Dateitypen:

• .vhd – Die kennen wir alle: dies ist die virtuelle Festplatte, die unser Gastsystem enthält.
• .vmc – Die kennen wir zwar auch alle, bloß gibt es die in Hyper-V nicht mehr … 🙂 In Virtual Server befand sich hier die Hardware-Konfiguration des Gastsystems. In Hyper-V gibt es hierfür eine XML-Datei.
• .bin + *.vsv – diese beiden Dateien zusammen enthalten den Status eines Gastsystems.
• .avhd – Das ist eine ‚Differencing Disk‘, die ihrerseits wieder auf eine *.vhd-Datei zeigt. Das Gastsystem schreibt alle Änderungen dort hinein, was den kuriosen Effekt hat, daß die beiden Dateien zusammen nur größer werden können – selbst wenn Sie Daten von der Festplatte löschen, ist das ja eine Änderung, die brav notiert werden muß …

Nun wurde also ein Snapshot erstellt, die nötigen Dateien auch. Aber wozu der ganze Kram, wie steht das alles in Verbindung?
Grob gesagt; nach einem Snapshot arbeitet man auf einer .AVHD weiter, die sich wiederum auf ein übergeordnetes Element bezieht. Da eine .AVHD eine sogenannte ‚Differencing Disc‚ ist, brauch sie immer ein Original, von dem sie sich unterscheidet denn nur die Unterschiede werden dort abgespeichert. Bei dem ersten Snapshot ist also das Original die .VHD und in den .AVHD werden alle weitern Arbeiten und damit Unterschiede zu diesem Elternelement abgespeichert. Bei dem zweiten Snapshot ist die erste .AVHD das Elternelement und die zweite .AVHD enthält die Unterschiede zur ersten usw usf. Die .VHD Datei wird ab dem 1. Snapshot zusätzlich ‚gesperrt‘. Sie wird Read Only und das sollte man unbedingt beachten. Niemals mit Snapshots an der Original VHD fummeln.
In der .XML stehen Hardwaredetails zu der VM. Am wichtigsten ist die Angabe des jeweils übergeordneten Elternelements:

Anhand dieser Angabe könnt ihr euch also immer das übergeordnete Element raussuchen und den ‚Weg nach oben‘ bis zur Original-.VHD bahnen.
Klingt alles recht simpel aber es wird mit jedem Snapshot unübersichtlicher…

Diese Struktur ist natürlich nur gestellt aber durchaus denkbar. Wenn sich nun ein Fehler unterschleicht kann man schnell den Überblick verlieren.

Wenn bei jedem Snapshot eine .AVHD Datei dazukommt wird es natürlich schnell unübersichtlich. Daher ist es ratsam, wenn alles gut läuft und man gerade nichts testet einfach mal alle Snapshots mit der VHD wieder zu vereinen.
Das schafft Übersichtlichkeit und schützt vor vielen Problemen, die mit Snapshots und .AVHDs einhergehen (komme ich noch drauf zu sprechen).
Wenn die VM heruntergefahren/aus ist: Geht in den Hyper-V Manager zu der VM, im Bereich „Snapshots“, darunter klickt ihr rechts auf den obersten – und damit ältesten – Snapshot und wählt „Snapshot-Unterstruktur löschen“ aus. Dann fängt Hyper-V an zu rödeln und fügt alle AVHDs rückwärts wieder bis zur VHD zusammen. Wenn der Vorgang abgeschlossen ist, ist die VHD um einiges größer und alle Zwischenstände sind gelöscht.
Läuft die VM noch könnt ihr trotzdem die Snapshot-Struktur löschen. Fahrt danach aber die VM runter und nach dem Herunterfahren werden die Dateien gemerked. Also nicht direkt nach dem Herunterfahren kritische Änderungen durchführen sondern den Merge abwarten.

Wir wissen also was Snapshots sind, wie sie aufgebaut sind und wie sie mit der .VHD interagieren.

— ACHTUNG! Nutzt nicht die Funktion „Datenträger bearbeiten…“ in der resten Spalte des Hyper-V Server Managers! Lest den kompletten Absatz, wenn ihr keinen Stress haben wollt! —
Mein eigentliches Problem am Freitag:
Ich hatte eine VM, deren freier Festplattenspeicher zu Ende ging. Also fuhr ich die VM herunter und erweiterte die virtuelle Festplatte über den Manager „Datenträger bearbeiten…“ im Hyper-V Manager. Dort wählt man die .VHD und vergrößert diese. Merkt ihr was?! Wie oben beschrieben wird bei Snapshots die VHD gesperrt und man arbeitet ab diesem Moment ‚auf‘ den .AVHD Dateien, die nur mit der VHD gemerged werden, wenn man es manuell veranlasst. Trotzdem funktioniert das Vergrößern der VHD.
…Kleiner Nachteil: Danach startet die virtuelle Maschine nicht mehr und man hat den Stress, dem ich am Freitag ausgesetzt war. Also lasst es lieber. Bevor ihr eine VHD vergrößert immer vorher die Snapshot-Unterstruktur löschen, damit Hyper-V die VHD komplettiert. Virtuelle Festplatten einer VM solltet ihr sowieso über VM->Rechtsklick->Eigenschaften->Datenträger->Bearbeiten. Dort wird das Bearbeiten der VHD auch gesperrt, falls Snapshots vorhanden sind oder Ähnliches.
Auch das Sichern von .VHD Dateien macht nur sinn, wenn ihr vorher alle .AVHDs merged, also vorher alle Snapshots löscht. Danach könnt ihr dann die vollständige VHD sichern.

Habt ihr trotzdem mal Probleme mit VHDs und AVHDs könnt ihr versuchen sie manuell zu mergen. Dazu kopiert ihr euch die VHD und die vorhandenen AVHDs in einen Extraordner, niemals mit Originaldateien arbeiten wenn es Probleme gibt, und versucht euch mit diesem Tutorial: „How to manually merge Hyper-V snapshots into a single VHD„.
Selber getestet habe ich diese Variante noch nicht aber die Kommentare klingen positiv, es sollte eigentlich klappen.

Viel Wissen zu Hyper-V gibts auch auf dem deutschen Blog von Microsoft Mitarbeiter Ralf Schnell. Er ist Spezialist für Server und Virtualisierung und hat mir am Freitag in meiner Not schnell geholfen und viele Tipps gegeben. Zu diesem Thema lässt sich sein Post „Wie funktionieren Snapshots in Hyper-V“ empfehlen. Von ihm stammen ein Teil der oben verwendeten Bilder. Vielen Dank.

Mehr zum Thema Snapshots auch bei Alfred Menzel.