Totgesagte leben länger, so heißt es. Auch dieses Blog war lange und auch schon öfter totgesagt. Für mehrere Jahre fand sich hier nurmehr eine Sedo-Verkaufsseite. Doch irgendetwas fehlte mir in letzter Zeit. Ein Ablageplatz, eine Deponie, ein Sammelsurium für Ideen, Aufgaben, die mir so begegnen (alltägliche, wie auch PC-), interessantes Zeug, das ich so finde und was weiß ich noch alles.
Das Bloggen als solches ist in Zeiten von Twitter und Facebook ziemlich unpopulär geworden. Und letztgenannte sterben ja auch bereits zugunsten neuerer, noch schnellerer, noch unübersichtlicherer Medien aus. Doch hier geht es nicht um Popularität. Wenn auch nur ein Besucher mal wieder auf die Seite kommt und sich denkt: "Verdammt, das hier spart mir viele Stunden mühsamen Suchens und Probierens." - dann erfüllt dieser Blog bereits seinen Zweck.
Ich hoffe nur, ich kann die Aktivität auch aufrecht erhalten. Etwa einmal die Woche sollte schon drin sein.
Wer sich gestern oder heute in sein Magento Backend eingeloggt hat, hat direkt eine Nachricht zu sehen bekommen, dass eine schwere Sicherheitslücke gefunden wurde, die geschlossen werden muss. Eigentlich liegt diese Sicherheitslücke nicht in Magento, sondern im Zend Framework, welches Magento benutzt. Es ist aber gut, dass man da trotzdem drauf hingewiesen wird, denn über diese Lücke ist es bei gewissen Serverkonfigurationen möglich, absolut jede Datei auf dem Server auszulesen (auch /etc/passwd und ähnlich sensible Files).
Dagegen schützen kann man sich, in dem man das XMLRPC von Magento patcht, sagt die hauseigene Quelle. Was sie nicht sagt, wie man den Patch durchführt.
Ihr braucht dafür einen SSH-Zugang zu eurem Server. Loggt euch ein und wechselt in das Verzeichnis, in dem euer Magento installiert ist. Dort befindet sich dann auch ein "lib"-Verzeichnis.
Führt nun je nach eurer Magentoversion folgendes aus:
Community Edition 1.4.0.0 bis 1.4.1.1
Wenn alles geklappt hat, erhaltet ihr als Ausgabe die Auflistung zweier Dateien im lib-Verzeichnis. Das wars, ihr habts geschafft!
Anschließend könnt ihr die patch-Datei wieder löschen.
Es ist auch möglich, XMLRPC in Magentos Zend komplett zu deaktivieren, dazu habe ich eine schöne Anregung bei den Webguys gefunden.
Das hat eigentlich auch nichts mit Magento zu tun. Indirekt aber schon.
Seit kurzem verwende ich den VMWare Player um Kopien der Live-Installation unseres Magento zu erstellen und Änderungen daran zu testen, bevor ich sie wieder ins Livesystem übertrage. Davor verwendete ich Oracle VirtualBox. Den Wechsel habe ich gemacht, weil bei VirtualBox ständig die vboxsvc.exe hängen bleibt und einen CPU-Kern voll auslastet. Sowas gibts bei VMWare Player nicht.
Ich schweife ab. Jedenfalls bekam das Debian im VMWare Player eines Tages keine Verbindung mehr zur Außenwelt. Die Netzwerkkarte des Gastes war auf "Bridge" gestellt, in meinem Windows habe ich nichts geändert und mein Router fungierte brav als DHCP-Server. Doch das beeindruckte das Gastsystem nicht. ifconfig lieferte mir zurück, dass eth0 keine IP oder irgendetwas hatte. Also führte ich dhclient eth0 aus (die Netzwerkkarte sollte natürlich schon gestartet sein, falls nicht könnt ihr sie mit ifup eth0 bzw. ifconfig eth0 up starten. dhclient gab nach einigen Versuchen auf. Das sah dann etwa so aus:
DHCPREQUEST on eth0 to 255.255.255.255 port 67
Dhcpdiscover on eth0 to 255.255.255.255 port 67 interval 6
Dhcpdiscover on eth0 to 255.255.255.255 port 67 interval 8
Dhcpdiscover on eth0 to 255.255.255.255 port 67 interval 11
Dhcpdiscover on eth0 to 255.255.255.255 port 67 interval 17
Dhcpdiscover on eth0 to 255.255.255.255 port 67 interval 12
Dhcpdiscover on eth0 to 255.255.255.255 port 67 interval 7
No DHCP Offers received
No working leases in persistent database - sleeping.
Und da stand ich nun - was tun? Ich suchte lange nach Lösungen. Fand dann erstmal noch heraus, dass die VMWare Tools mir die /etc/resolv.conf verbogen hatten, doch da brachte eine Änderung logischerweise nichts.
Nach langem Googlen war ich schon fast versucht aufzugeben und auf ein "Host only network" umzustellen oder solchen Quatsch, doch dann fand ich endlich die Lösung. Kurz zusammengefasst: der DHCP-Request wird von VMWare auf die falsche Netzwerkkarte geleitet. Das passiert in meinem Fall anscheinend, weil VirtualBox noch parallel installiert ist. Das DHCPDISCOVER landet somit auf dem VirtualBox-Interface und nicht auf der normalen Netzwerkkarte. Nur wie ändert man das?
Die Lösung liefert die eben verlinkte Seite:
1. erstmal ein cmd.exe mit Administratorrechten ausführen (einfach cmd in die Startleiste von Windows 7 eingeben, auf das Ergebnis rechtsklicken und als Administrator ausführen)
2. Geht dahin, wo ihr euren Installer von VMWare-player liegen habt.
3. Führt ihn so aus: VMware-player-3.0.0-203739.exe /e c:\vmware
Die Versionsnummer ist bei euch vermutlich eine andere.
4. Geht im Explorer in C:\vmware
5. Öffnet die Datei 'network.cab', z.B. mit 7-zip
6. Entpackt ihren Inhalt nach C:\Program Files (x86)\VMware\VMware Player, oder wo ihr eben euer VMWare Player liegen habt.
7. Öffnet nun in dem Installationsverzeichnis die vmnetcfg.exe.
8. Wählt das VMNet0 aus, ganz oben.
9. Achtet darauf, dass "Bridged" unten ausgewählt ist in dem Dropdownfeld.
10. Wählt explizit die Netzwerkkarte aus, die fürs Bridging verwendet werden soll.
11. Klickt OK.
Das wars, wenn ihr euren VMWare Player jetzt neustartet (bzw. öffnet), sollte euer Gast per DHCP ein Lease erhalten können .
Vor kurzem hatte ich den merkwürdigen Fall, dass geänderte Direktiven in der /etc/nginx/nginx.conf keinerlei Auswirkung hatten. Dabei habe ich doch nginx wie immer neu geladen:
nginx -s reload
Das wurde mir mal so beigebracht, und der Server war praktisch nicht down, der Reload verläuft fast nahtlos.
Doch beim Ändern des root, von location- oder server_name-Direktiven habe ich nun die Erfahrung gemacht, dass das nicht ausreicht.
Ein stinknormales:
/etc/init.d/nginx restart
brachte hingegen Linderung. Die neuen Konfigurationen wurden geladen. Eine Downtime von wenigen Sekunden muss man aber in Kauf nehmen.
Falls einer von euch auch mal darüber stolpert, kann er es sich ja ergooglen .
Vielleicht kommst du ja auch aus der IT-Branche. Und rein zufällig hast du ein Profil bei XING, weil es - zumindest vor ein paar Jahren - irgendwie Pflicht war, als netzaffiner Informatiker auf Arbeits- und Jobsuche dort angemeldet zu sein.
Man kann bei Xing eigentlich sehr schön auswählen, was man bietet, was man sucht und was man hat (wir reden hier von Arbeit). Doch selbst, wenn man, so wie ich, nichts anderes sucht als ein wenig Networking (Ausbau des Vitamin B) und nette geschäftlicher Kontakte, sowie auch seine derzeitige Arbeitsstelle angegebene hat, wird man mit Stellenangeboten überhäuft.
Das wäre ja nun irgendwo schmeichelhaft, á la "Juhu, die streiten sich um mich!", doch liest man mal kurz in die Angebote hinein, merkt man schnell, dass es sich hier um massenhaft gestreutes Blocktextblabla handelt, nach dem Motto "wir schreiben 500 an, 4 melden sich und einen nehmen wir und in einem halben Jahr setzen wir ihn wieder an die Luft. Ein bisschen wie Spam, nur mit etwas weniger illegalem Hintergrund.
Lohnt es sich dann, überhaupt noch bei Xing zu bleiben, als "kleiner Fisch" ohne ein Riesennetzwerk, das man nur darüber pflegen kann? Und selbst die, die große Netzwerke haben, sind die dann nicht eher bei linkedin (eine Art Sozialem Netzwerk für Geschäftsführer und andere Hochranginge) als bei dem doch mittlerweile etwas in die Jahre gekommenen Xing? Warum Geld für die Premiummitgliedschaft zahlen, wenn man mit etwas Google und Facebook doch die CEOs auch viel direkter erreichen kann?
.
Vor kurzem hatte ich den merkwürdigen Fall, dass geänderte Direktiven in der /etc/nginx/nginx.conf keinerlei Auswirkung hatten. Dabei habe ich doch nginx wie immer neu geladen:
.
Vielleicht kommst du ja auch aus der IT-Branche. Und rein zufällig hast du ein Profil bei