WordPress per PHP direkt von wordpress.org als Zip-Datei auf Server herunterladen und entpacken

Um Prototypen für Kunden zu bauen oder auch für eigene Bastelprojekte muss ich immer mal wieder WordPress neu aufsetzen.

Bei vielen Hostern geht das heute auch als App oder Service relativ vollautomatisch, aber oftmals hat man dann nicht volle Schreibrechte in den WordPress-Verzeichnissen. Also installiere ich lieber selbst.

Da das Herunterladen auf den eigenen Rechner, das lokale Entpacken der Zip-Datei und der anschließende Upload der Daten relativ unspannend und zumindest im FTP-Transfer auch zeitaufwändig ist, lässt sich dieser Vorgang mit einem kleinen Skript weitestgehend automatisieren.

  1. aktuelle deutsche Version von WordPress als Zip-Datei mit cURL direkt auf den Server ziehen
  2. Zip-Datei entpacken
  3. Verzeichnisse und Dateien aus dem Unterordner „wordpress“ auf die aktuelle Verzeichnisebene verschieben
  4. WordPress-Installation anstoßen

Als Skript sieht das dann so aus:

Noch ein paar Worte zur Erläuterung:

  • Die Klasse ZipArchive sollte ab PHP 5.2 zur Verfügung stehen.
  • Das exec-Kommando kann bei anderen Hostern anders heißen, bspw. system etc.

 

Einfache Suchmuster mit RegExp für width und height

In älteren HTML-Dateien findet man gern noch fixe Angaben zu Höhen (height) und Breiten (width).

Um diese mit einem RegExp-fähigen Editor (bspw. Notepad++) zu suchen und ggfls. zu löschen oder zu ändern, helfen diese Suchbegriffe:

height=\"[0-9/. \-]*\"
width=\"[0-9/. \-]*\"
style=\"width\:[0-9/. \-]*px\;\"
style=\"height\:[0-9/. \-]*px\;\"

Pear Mail_Mime und das Encoding der Empfängeradresse (to) mit Umlauten – natürlich auch für weitere Header-Parameter

Gleichwohl man annehmen könnte, dass das Encoding von Umlauten heutzutage – zumindest, sofern man UTF-8 benutzt – selbstverständlich sein sollte, stößt man immer wieder mal Probleme.

Aktuell hatte ich ein kleines Skript, dass per PHP über Mail-Mime Multipart-Mails verschickt. Alles lief rund vier Wochen glatt, bis auf einmal eine Mail partout nicht rausgehen wollte. Stattdessen hat mir der Server freundlicher Weise einen 500er geworfen.

Wie sich nach eingehender Recherche herausstellte, lag es an der Empfängeradresse, welche ich in der Form „Vorname Nachname <email@domain.tld>“ übergab. Der Nachname enthielt nun leider ein ß. Soll ja vorkommen…

Google hin, google her, das Problem war zwar erkannt, wollte sich aber gar nicht so einfach lösen lassen. Ein Encoding über imap_8bit() brachte nicht den erwünschten Erfolg.

Im Endeffekt tat es dann folgende kleine Funktion:
function mb_mime_header($string, $encoding=null, $linefeed="\r\n") {
if(!$encoding) $encoding = mb_internal_encoding();
$encoded = '';
while($length = mb_strlen($string)) {
$encoded .= "=?$encoding?B?"
. base64_encode(mb_substr($string,0,24,$encoding))
. "?=$linefeed";
$string = mb_substr($string,24,$length,$encoding);
}
return $encoded;
}

welche ich folgendermaßen nutze

$to=mb_mime_header("Name der Empfängers","UTF-8")." <email@domain.tld>";

Wie kann ich in Corel Draw die Werkseinstellungen insbesondere auch das Monitorprofil zurücksetzen

Corel Draw zeigt gelegentlich Farben flasch an. Insbesondere erscheint das Weiß viel zu gelblich. Schuld daran scheint ein falsches Monitorprofil zu sein, welches sich aber einzeln nicht löschen lässen.

Die Lösung ist relativ simpel: Corel Draw schließen und neu starten und wenn der Splashscreen erscheint, die F8-Taste gedrückt halten, bis die Frage nach der Rückstellung auf die Werkseinstellungen aufpoppt.

Aber Achtung: Alle sonstigen Einstellungen an der Arbeitsumgebung gehen dabei ebenfalls verloren.

Dieser Tipp sollte mindestens bis Version X5 funktionieren.

Ein PHP-Skript unter Synology DSM per Cronjob regelmäßig ausführen lassen

In aller Kürze:

  1. Auf der Diskstation den SSH-Dienst aktivieren:
    Systemsteuerung => Terminal & SNMP => Häkchen bei „SSH-Dienst aktivieren“ setzen => „Übernehmen“ klicken
  2. Per Putty oder anderem SSH-Cilent mit der Diskstation verbinden:
    Host: diskstation (oder welchen Namen Ihr vergeben habt oder die IP-Adresse)
    User: root
    Password: Das Admin-Password
  3. Crontab bearbeiten:
    cd /etc[RETURN]
    vi crontab[RETURN]
    mit den Cursortasten an das Ende der untersten Zeile gehen
    [i] drücken, um in den Editiermodus zu gelangen
    Daten eintragen, bspw.
    0 6 * * * root curl http://127.0.0.1/ein_verzeichnis/eine_php_datei.php
    für das tägliche Aufrufen des Sripts morgens um 6 Uhr
    Die einzelnen Werte müssen mit Tabstopps getrennt werden!
    [ESC] drücken, um den Editiermodus zu verlassen
    [:][w][q] drücken, um die crontab zu speichern und den vi zu verlassen
  4. Cron neu starten:
    restart crond[RETURN]
    exit[RETURN]

Google Chrome lädt Seiten nicht oder nur unvollständig und zeigt Net::ERR_INCOMPLETE_CHUNKED_ENCODING oder net::ERR_CONTENT_LENGTH_MISMATCH in der Console an

Wenn Eure PHP-Skripte unter Google Chrome nur unvollständige oder auch gar keine Ausgaben erzeugen, liegt dies mittlerweile immer häufiger an den diversen Echtzeitschutzmodulen der Anti-Viren-Softwarepakete.

Diese scheinen erhebliche Probleme zu haben, wenn im Header keine oder eine falsche Content-Length übertragen wird. Sobald man den Echtzeitschutz temporär ausschaltet, tritt das Problem nicht mehr auf.

Dieses Problem tritt – allerdings ohne brauchbare Fehlermeldung – auch in Firefox auf.

Insbesondere wenn Inhalte dynamisch erzeugt werden und Teile bspw. per Include nachgeladen werden, ist jedoch die Content-Length vorher nicht bekannt.

Abhilfe ist relativ einfach, indem  die Ausgabepufferung aktiviert wird.

Startet ggfls. nach dem öffnenden PHP-Tag noch Eure Session und aktiviert dann die Ausgabepufferung mit ob_start(). Am Ende Eures Skripts gebt Ihr dann durch header(„Content-Length: „.ob_get_length()); die korrekte Content-Length an und gebt den Ausgabepuffer mit ob_flush(); aus.

PHP-Skript bricht ohne Fehlermeldungen ab

Ich habe kürzlich im Rahmen eines Projektes ein Skript gebaut, welches ein dynamisches HTML-Formular erzeugt. Das Formular besteht aus ca. 15.000 Zeichen und wird je nach gesetzten Werten erneut über Ajax nachgeladen.

Leider funktionierte das Nachladen nur sporadisch und ohne erkennbares Muster. Die Logfiles wiesen auf keinerlei Fehler hin und auch der Support des Hosters für das Projekt hatte keine rechte Idee, woran es liegen könnte.

Meinem Kunden kann ich aber schlecht erklären, dass seine Anwendung nur gelegentlich funktionert.

Firebug zeigte über die Konsole zwar brav, dass das Skript über Ajax aufgerufen wurde, jedoch war die Übertragung in 4 von 5 Fällen unvollständig, obwohl ein HTTP-Return-Code 200 zurückgegeben wurde. Mit 0.9 Sekunden Laufzeit war auch das Überschreiten etwaiger maximaler Skriptlaufzeiten unwahrscheinlich.

Vorsichtshalber habe ich auch den Speicherbedarf während der Verarbeitung des Skripts mitgeloggt und bei ca. 16 MB Speicherbedarf gabe es auch keine Probleme.

Schließlich habe ich mir über „Live HTTP headers“ die übertragenen Werte des Headers angeschaut und siehe da, für „Content-Length“ wurde nur der Wert 32 übertragen.

Also habe ich vor der Ausgabe des Wertes den entsprechenden Header mit

die korrekte Länge des Contents übergeben und siehe da, die Übertragung funktioniert reibungslos.

Wie kann ich ein php-basiertes Content-Management-System (bspw. WordPress, Joomla, Typo3 etc.) nach einem Hackerangriff von Malware befreien?

Nach einem Hackerangriff und entsprechendem Malware-Befall ist guter Rat meist teuer. Oftmals wird der eigene Webauftritt durch den Provider gesperrt, so dass man nicht irgendein Plugin installieren kann, um die Probleme zu beheben.

Es bleibt nur die gute alte Handarbeit, falls es nicht ein garantiert Malware-freies Backup gibt. Und auch dieses Backup ist nur die halbe Miete, da der Angreifer diese Version ja offensichtlich problemlos infiltrieren konnte.

Variante A – Ihr habt ein aktuelles, garantiert sauberes Backup

Wenn Ihr diesbezüglich sicher seid, dann löscht den gesamten Webauftritt per FTP und leert die zugehörigen DB-Tabellen bspw. per PHPMyAdmin.

Anschließend kopiert Ihr das saubere Backup per FTP auf den Server, legt per .htaccess einen Verzeichnisschutz auf den gesamten Auftritt und spielt dann das DB-Backup ein.

Ihr habe jetzt wieder eine laufende Installtion Eures CMS, auch wenn diese von außen nicht für Andere zugänglich ist. Installiert nunmehr sämtliche Updates für Euer CMS, die Plugins, Themes / Templates etc.

Härtet Eurer CMS durch die Installation eines entsprechenden Plugins (bei WordPress bspw. Sucuri Scan). Überlegt Euch weiterhin, ob Ihr Kommentarfunktionen benötigt und insbesondere, ob Eure Besucher Dateien uploaden müssen. Falls nicht, deaktiviert diese Funktionen und schützt entsprechende Verzeichnisse durch eine .htaccess.

Ändert sämtliche Zugangsdaten – auch das FTP-Passwort!

Theoretisch müsstet Ihr jetzt noch die Logfiles durchsuchen und schauen, ob Ihr nachvollziehen könnt, wie der Angriff zustande kam. Oftmals endet diese Suche – nicht zuletzt mangels hinreichendem Hintergrundwissen – ergebnislos. Ihr könnt aber vorsichtshalber trotzdem Euren Provider fragen, ob er in den Logfiles Hinweise auf den Angriff gefunden hat.

Entfernt nun den Verzeichnisschutz für Euren Auftritt und beobachtet für die nächsten Tage und Wochen Euren Auftritt sehr aufmerksam. Regelmäßige Backups und Updates verstehen sich von selbst.

Variante B – Ihr habe kein sauberes Backup und Ihr traut Euch auch nicht, einfach eine frische Version des CMS einzuspielen

Trauriger Weise dürfte das der Normalzustand sein. Da Lamentieren nicht hilft, ist es dann an der Zeit, in die virtuellen Hände zu spucken.

Achtet darauf, dass Euer Virenscanner aktuell und eingeschaltet ist. Zieht dann per FTP ein vollständiges Backup Eures CMS. Wenn das Backup vollständig ist, lasst Ihr mindestens einen Virenscanner und einen Malware-Checker (bspw. Malwarebytes Anti-Malware) über den Backup-Ordner laufen. Etwaige Funde behebt Ihr sowohl im Backup als auch direkt auf dem Server.

Nehmt jetzt ein Tool, welches Dateien inhaltlich durchsuchen kann (bspw. Agent Ransack) und lasst alle Dateien des Backups nach

durchsuchen. Insbesondere Funde von „eval(base64_encode(“ und „eval(gzinflate(“ guckt Ihr Euch genauer an. Wenn diese von kryptischen Zeichenfolgen gefolgt werden, handelt es sich mit großer Wahrscheinlichkeit um Malware. Aber auch alle anderen Funde solltet Ihr gewissenhaft prüfen. Behebt die jeweiligen Befälle jedoch nur auf dem Server, so dass Ihr im Worst Case ein Backup habt.

Wenn Ihr alle Dateien gesäubert habt, werft auch noch einen Blick auf die Datenbank und durchsucht diese komplett nach „%<iframe%“, und „%<noscript%“. Löscht verdächtige Inhalte, nachdem Ihr ein DB-Backup erstellt habt.

Legt per .htaccess einen Verzeichnisschutz auf den gesamten Auftritt und bittet Euren Provider ggfls., den Zugriff auf die Seite wieder zu erlauben..

Ihr habe jetzt wieder eine laufende Installtion Eures CMS, auch wenn diese von außen nicht für Andere zugänglich ist. Installiert nunmehr sämtliche Updates für Euer CMS, die Plugins, Themes / Templates etc.

Härtet Eurer CMS durch die Installation eines entsprechenden Plugins (bei WordPress bspw. Sucuri Scan). Überlegt Euch weiterhin, ob Ihr Kommentarfunktionen benötigt und insbesondere, ob Eure Besucher Dateien uploaden müssen. Falls nicht, deaktiviert diese Funktionen und schützt entsprechende Verzeichnisse durch eine .htaccess.

Ändert sämtliche Zugangsdaten – auch das FTP-Passwort!

Theoretisch müsstet Ihr jetzt noch die Logfiles durchsuchen und schauen, ob Ihr nachvollziehen könnt, wie der Angriff zustande kam. Oftmals endet diese Suche – nicht zuletzt mangels hinreichendem Hintergrundwissen – ergebnislos. Ihr könnt aber vorsichtshalber trotzdem Euren Provider fragen, ob er in den Logfiles Hinweise auf den Angriff gefunden hat.

Entfernt nun den Verzeichnisschutz für Euren Auftritt und beobachtet für die nächsten Tage und Wochen Euren Auftritt sehr aufmerksam. Regelmäßige Backups und Updates verstehen sich von selbst.

 

Kopieren / Clonen einer Festplatte mit defekten Sektoren (oder auch ohne)

Hardwarebetreuung – egal ob einzelene Rechner oder ganze Netzwerke – waren mein erstes Standbein. Irgendwann war ich aber genervt von den wiederkehrenden Problemen mit Netzwerkdruckern, nicht gepflegten Backups etc. Also habe ich diesen Zweig meiner Tätigkeiten ad acta gelegt.

Privat kommt man aber trotzdem nicht darum herum, sich gelegentlich mit defekten Festplatten & Co. auseinanderzusetzen. Aktuell hatte eine Freundin ein „kleines“ Problem mit ihrem Laptop. Um es genau zu sagen, die Festplatte hatte diverse defekte Sektoren und das System (Windows 7) fuhr nur noch unter Protest und endlos langen Festplattenüberprüfungsvorgängen hoch. Immerhin!

Sie besorgte also auf meinen Rat hin eine neue 500 GB SSD von Samsung. Die Dinger laufen in mehreren meiner Rechner seit geraumer Zeit ohne zu mucken. Die von Samsung mitgeliefert Clone-Software funktioniert normaler Weise auch sehr zufriendstellend und kopiert selbst die Systempartition aus dem laufenden Betrieb heraus lauffähig auf die neue SSD. Leider verweigert sie den Dienst, wenn sie auf defekte Sektoren trifft.

Also musste eine andere Variante her. Ich probierte es mit der Live-CD von GParted, aber auch hier waren die defekten Sektoren der Knackpunkt.

Letztendlich landete ich bei Ubuntu Rescue Remix. Die aktuelle Version (zur Zeit 12.04) war schnell als ISO heruntergeladen, auf eine CD gebrannt und im Laptop gestartet.

Nach dem Hochfahren der Live-CD lässt man sich mit

die vorhandenen Festplatten anzeigen. In meinem Fall hatte das (leicht defekte) Quelllaufwerk die Bezeichnung /dev/sda und die neue SSD am USB-SATA-Adapter die Bezeichnung /dev/sdb.

Den ersten Kopierdurchgang startet man dann mit

-n (–no-split) sorgt dabei dafür, dass er sich nicht lange an defekten Dateien aufhält, sondern erstmal das rettet, was problemlos lesbar ist.

–force sorgt dafür, dass die neue SSD tatsächlich komplett überschrieben wird.

Nachdem dieser erste Kopiervorgang durchgelaufen ist, kann man dann, sofern es Probleme mit dem Quelllaufwerk gab, einen zweiten  Kopiervorgang starten:

-d (–direct) sorgt dafür, dass direkt auf die Festplatte zugegriffen wird.

-r3 (–max-retries=3) sorgt dafür, dass drei Mal versucht wird, defekte Sektoren einzulesen.

 

Das WordPress-Plugin Sucuri zeigt nach dem Einschalten zusätzlicher Scanner auf der Settings-Seite nur noch einen Serverfehler 500

Ja nach Konfiguration Eures Webservers laufen nicht alle Scanner von Sucuri problemlos durch. Das wäre nicht so tragisch, wenn man die jeweilige Scan-Engine einfach wieder über die Settings abschalten könnte.

Leider funktioniert das nicht immer, denn bereits beim Aufruf der Settings bekommt man einen 500er geworfen.

Um trotzdem an die Einstellungen über Settings zu gelangen, reicht es, an die URL „&no_scan=1“ (ohne Anführungszeichen) anzuhängen. Schon gibt es wieder Zugriff auf die Settings.

© 2016 StableWeb / CMS-EDV

Theme by Anders NorenUp ↑