Could not parse object '303b8a83c87d5c6d749926cf02620465a5dcd0f2'

Scheinbar gibt es Probleme beim Aktualisieren von monolog. Alle anderen Abhängigkeiten werden ordentlich aktualisiert.

Was kann man tun?

Ein kurzer Blick in die Ankündigung bringt auch schon die Lösung. Löscht einfach den Ordner vendor/monolog und führt noch einmal bin/vendors install aus. Monolog sollte jetzt ebenfalls aktuell sein.

Das gilt natürlich auch bei der Arbeit mit der Versionsverwaltung. Selbst wenn es sich um Git dreht, das man eigentlich nur auf der Konsole richtig nutzen kann. Nein, auch da muss eine GUI her, also greift man zu TortoiseGit.

Commit, Push, Pull, Log, alles kein Problem, aber schon mal versucht auf einem System mit TortoiseGit ein Repository/Projektordner zu löschen?

Wie „erfreulich“ diese Meldung doch ist, und dank TortoiseGit sieht man sie sogar regelmäßig. Was macht man jetzt? Wie bekloppt auf „Wiederholen“ klicken, bis es irgendwann klappt?

Das geht besser und zwar mit Unlocker. Unlocker bindet sich in das Kontext Menü eures Explorers ein, und erlaubt euch, Dateien wieder freizugeben.

Ein Klick auf „Unlocker“ öffnet nach einem kurzen Moment (und ggf. einer UAC Meldung) ein Fenster, in dem Ihr eine Auflistung aller in Benutzung befindlichen Dateien inkl. der schuldigen Programme findet.

Ein abschließender Klick auf „Alle Freigeben“ und das Repository lässt sich löschen.

Das Tool funktioniert natürlich auch, wenn ein anderes Programm Amok läuft und Dateien und Ordner sperrt. Passt bei der Installation auf, das Installationsprogramm versucht ein paar eBay Verknüpfungen auf eurem Desktop abzulegen. Diese könnt Ihr aber während der Installation abwählen.

Links:

• Unlocker (32 Bit) bei Chip.de
• Unlocker (64 Bit) bei Chip.de

Solltet ihr auch von Fehlermeldungen dieser Art geplagt werden und eine Reparatur von Visual Studio keinen Erfolg gebracht haben, dann schnappt euch eure Installations DVD und installiert die folgenden Pakete nach. Zu finden sind sie im Pfad x:\WCU\DAC.

• DACFramework_deu.msi
• DACProjectSystemSetup_deu.msi
• TSqlLanguageService_deu.msi

Die Meldungen sollten, nach der Installation, verschwunden sein.

Scheinbar haben sich vor einiger Zeit die Dateinamen/Versionen geändert, aber es wurde versäumt die Update Seite zu kontrollieren. Während der Installation versucht Eclipse Dateien herunterzuladen die es auf dem Server nicht (mehr) gibt.

Was kann man also machen?
Die Lösung des Problems ist eigentlich recht einfach. Das einzige was wir hierzu benötigen ist ein Apache Server mit aktiven mod_rewrite, ein Packprogramm und ein Texteditor.

Speichert die content.jar der Update Seite auf eurem PC und entpackt den Inhalt in einen Ordner eurer Wahl. Es sollte jeder handelsübliche Packer, der das ZIP Format versteht, möglich sein.
In dem Zielordner sollte sich jetzt eine content.xml befinden. Öffnet diese mit einem Textprogramm und ersetzt alle Vorkommnisse von 20091116 durch 20091124. Packt die content.xml nun wieder in eine ZIP Datei und nennt diese content.jar.

Erstellt eine .htaccess und fügt folgenden Inhalt ein:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* http://downloads.zend.com/pdt/$0 [L]

Ihr habt jetzt eine .htaccess die jede Anfrage an eine nicht existierende Datei an die offizielle Update Seite weiterreicht.
Legt beide Dateien nun in ein Verzeichnis unterhalb eures Apache Web Roots und tragt die URL als Update Seite bei eclipse ein.

Ihr könnt nun ohne größere Schwierigkeiten den Zend Debugger installieren. Wer keine Lust hat die Änderungen selbst durchzuführen, oder den Text durchzulesen, der kann sich die geänderten Dateien auch herunterladen, oder er trägt http://a2.localdev.de/zend/ als Update Seite ein.

Downloads:

• Zend PDT Update Site Fix

HTTP/1.1 417 Expectation Failed

Dies liegt daran, das die Programme einen Expect: 100-continue Header senden, und als Antwort 100 (Continue) oder 417 Expectation Failed erwarten. Lighty kennt den Header jedoch nicht, und antwortet deswegen mit dem besagten 417 Expectation Failed.

Der Expect: 100-continue Header soll verhindern, das Daten an den Server gesendet werden, die nicht benötigt werden. Erkennt der Server z.B. das er die Anfrage ablehnen muss, kann er dies dem Client mitteilen, noch bevor die POST Daten übermittelt wurden.

Wer dennoch POST Daten an Lighty senden möchte, kann die folgenden Paramter anpassen:

.NET

System.Net.ServicePointManager.Expect100Continue = false;

cURL unter PHP

curl_setopt($objCurl, CURLOPT_HTTPHEADER, array('Expect: '));

cURL auf der Kommandozeile

curl -v -H "Expect: " -F "field=value" http://example.com/upload.php

Alternativ aktualisiert man auf Lighttpd 1.5. Dieser kennt den Expect: 100-continue Header und beantwortet entsprechende Anfragen korrekt.

Browser senden übrigens keinen Expect: 100-continue Header.

Schade das, bei vielen Beschenkten, scheinbar der Firefox abstürzt oder Probleme beim Starten hat.

Dieser Auszug stammt von einem unserer Debian Server und repräsentiert in jeder Zeile einen HTTP 500 Error.

Aug 17 11:44:14 srv1 suhosin[14716]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')
Aug 17 11:44:15 srv1 suhosin[14717]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')
Aug 17 11:44:16 srv1 suhosin[14718]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')
Aug 17 11:44:16 srv1 suhosin[14719]: ALERT - canary mismatch on erealloc() - heap overflow detected (attacker '80.*.*.*', file '../index.php')

Was ist passiert?
Suhosin versucht Attacken auf Sicherheitslücken in PHP bzw. PHP Skripten zu erkennen und zu verhindern. Hierzu überwacht es u.a. den Arbeitsspeicher, und fügt beim Schreiben von Daten noch eigene Informationen hinzu. Sind diese Informationen beim Abrufen fehlerhaft, oder fehlen sie komplett, glaubt Suhosin einen Fehler zu erkennen, und beendet die Ausführung von PHP.

Wie? Wo? Was?
Ob der Kern oder ein Modul von PHP Schuld haben, lässt sich nicht so einfach sagen, da Suhosin zu wenig Informationen liefert. Man geht aber davon aus, das die Fehler in den PHP Modulen stecken.

Was kann ich machen?
Entweder man deaktiviert alle PHP Module nacheinander, bis kein Fehler mehr auftritt, oder man deaktiviert direkt Suhosin. Update: Auch mit ausgeschaltetem Suhosin kann der Fehler auftreten, da das Verhalten durch den Hardened-PHP Patch direkt im Kern steckt. Interessanterweise bringt das deaktivieren von Suhosin eine derartige Senkung mit sich, das ich nur durch eine eindeutige Fehlkonfiguration von PHP den Fehler wieder zu sehen bekam (session.save_handler war auf memcache eingestellt, memcached selber aber nicht gestartet).

Warum Kanarienvogel?
Der Kanarienvogel (canary) in der Fehlermeldung bezieht sich auf den Bergbau. Dort hat man in der Vergangenheit Kanarienvögel mit in den Untergrund genommen, um zu prüfen ob in einem Stollen genug Sauerstoff vorhanden war. Sind die Vögel verendet, wusste man das Gefahr droht, und hat die Arbeit sofort beendet.