Wenn man WordPress in einer Netzwerkstruktur betreibt, in der keine Verbindung zu anderen Internetseiten hergestellt werden kann, kommt es bei vielen Aktionen zu langen Wartezeiten bis hin zu Timeouts. Im extremsten Fall kann das dazu führen, das man sich an seinem eigenen WordPress nicht mehr im Backend einloggen kann.

Der Grund dafür ist, das gerade beim Login oder allgemein: Beim Zugriff auf das WordPress-Dashboard, normalerweise ziemlich viele Daten von externen Ressourcen von WordPress geladen und verarbeitet werden. Nachrichten im „WordPress-Nachrichten“-Widget, Informationen ob Updates für WordPress oder Plugins existieren, Twitter-Feeds, … all diese Informationen fragt WordPress bei einem Login im Hintergrund ab und bereitet es für die Anzeige im Dashboard auf. Behindert eine Firewall oder ähnliches diese Zugriffe, wird für jeden dieser Zugriffe eine zeitlang gewartet, ehe für diese Zugriffe ein Timeout erreicht wird. Je mehr Ressourcen hierbei geladen werden, desto länger die Gesamtzeit die das Dashboard benötigt um sich aufzubauen.

In der Regel genügen die WordPress internen Aktionen ohne weitere Plugins um in diesem Fall an die Grenze der definierten PHP max_execution_time() zu geraten. Je nachdem welche Ressourcen im Frontend der Seite verwendet werden, kann es auch sein, das sich die Seite bei Euren Besuchern hierdurch viel langsamer als gewünscht aufbaut.

Die beste Lösung

Die beste Maßnahme diese Probleme zu umgehen ist meiner Meinung nach schlicht und einfach dafür zu sorgen, das WordPress ungehindert auf Ressourcen im Netz zugreifen kann, da sonst wichtige Kerntechniken von WordPress nicht oder nicht optimal funktionieren (Update-Hinweise, laden von News, Abfragen von DNS Informationen, …).

Die zweitbeste Lösung

Sollte es sich, warum auch immer, nicht anders machen lassen als WordPress ohne freien Zugriff auf’s Internet zu betreiben, kann man diese Zugriffe durch einen Eintrag in der wp-config.php – Datei einfach komplett abschalten. Dieses ist in der Regel die bessere Wahl; funktionieren die Zugriffe schließlich ohnehin nicht. Nur kommt es hierbei dann weder zu Script-Timeouts, noch zu langen Ladezeiten:

Funktioniert der Zugriff auf bestimmte Ressourcen, z.B. weil diese Explizit in der Firewall oder einem Proxy freigeschaltet worden sind, kann man diese mit einer weiteren Konfigurationsoption von diesem Block ausnehmen, so das diese dennoch geladen werden:

Benutzt man das Programm telnet unter Linux, wird man beispielsweise mit folgender Meldung begrüsst:

Möchte man diese Verbindung schließen, müsste man den „Escape character“ ( ^] ) eingeben. Nur: Hierbei handelt es sich keinesfalls um die beiden ASCII-Zeichen „^“ und „]“. Bei diesen handelt es sich mehr um die Darstellung eine bestimmten Tastenkombination. Das fiese: Oft kommt man nichtmal mit dem altbewährten Strg+c aus der Sache raus …

Um diesen Escape character einzugeben verwendet man folgende Tastenkombination: STRG + AltGr + 9
Hinweis: Die „+“ Zeichen sollen nicht eingetippt werden, sondern anzeigen, das die drei Tasten gleichzeitig gedrückt werden müssen.

Schon sollte die Konsole sich wieder im telnet-Kommando-Modus befinden. Dort kann man mit dem Befehlt „quit“ wieder auf die normale Linux-Shell:

Jedes Mal, wenn ich mir ein neues Linux-System einrichte, muss ich erst nochmal schnell Googlen oder die Manpage wälzen; daher notiere ich es mir hier jetzt endlich mal:

Es gibt ein Sicherheitsfeature bei openSSH, welches einen warnt wenn man sich zu einem Host/einer IP verbinden möchte und sich die ID des Zieles seit dem letzten Mal verändert hat. Das macht zwar durchaus Sinn und ich finde das generell eine gute Sache. Aber es kann wirklich sehr nerven, besonders wenn man mit DHCP arbeitet und die Zielrechner dauernd Ihre IP durchtauschen, man mit virtuellen Maschinen arbeitet und diese nur kurz benutzt werden oder häufig per SSH auf Live-CD-Systeme konnektiert.

Normalerweise muss man die entsprechende Zeile in der Datei ~/.ssh/known_hosts die angemeckerte Zeile löschen; z.B. bei:

müsste man die Zeile 3 entfernen.

Hierzu muss man etwas wie „sed -i 3d ~/.ssh/known_hosts“ losjagen oder die Datei in einem Editor von Hand bereinigen. Wie schon gesagt: Auf Dauer sehr nervig!

Wenn einem das nur vereinzelt passiert, kann man sich mit Kommandozeilenoptionen helfen: „ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@192.168.1.12„; ist jedoch schon eine recht sportliche Aufgabe sich das a) zu merken und b) jedes Mal wegzutippen.

Wem das permanent passiert, kann dieses Verhalten dauerhaft einstellen. Und zwar sowohl global wie auch userbasiert. In beiden Fällen müssen die beiden o.g. Optionen in die passende Config-Datei eingetragen werden:

UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Um diese Einstellung global zu setzen (nicht empfohlen), trägt man diese Optionen in die Datei „/etc/ssh/ssh_config“ ein.

Um diese Einstellung nur für einen bestimmten User zu setzen, trägt man diese Optionen in die Datei „~/.ssh/config“ ein.

Das ganze hebelt natürlich den als Sicherheitsmaßnahme gegen „Man-in-the-middle“ – Attacken gemeinten Schutz vor diesem Angriffstyp aus. Um das ganze wenigstens etwas sicherer zu machen, kann man auch nur einzelne Hosts und Hostbereiche derart von dieser Regel ausnehmen. Die Beispielhafte Syntax dazu lautet dann:

Möchte man dieses immer und für alle Verbindungen deaktivieren, lässt man die „Host“ – Zeile einfach weg.

Aber Achtung: Bitte nur anwenden wenn Ihr wisst was Ihr tut! Das ganze hebelt, wie gesagt, einen sinnvollen Schutz des SSH Systems aus.

[follow_me]

Auf einem meiner Rechner läuft ein kubuntu 15.04. In dessen Repo befindet sich die Version 1.7.0~beta1+really1.6.4+dfsg-1 des Paketes owncloud-client. Installiert man dieses, bekommt man unter KDE Plasma beim Anmelden folgende Fehlermeldung angezeigt:

„ownCloud wird für eine funktionierende Taskleiste benötigt. Falls Sie XFCE einsetzen, dann folgen Sie bitte diesen Anweisungen. Anderenfalls installieren Sie bitte eine Taskleisten-Anwendung wie ‚trayer‘ und versuchen Sie es erneut.“

Fehlermeldung der Repo-Version von owncloud unter Ubuntu 15.04: "ownCloud wird für eine funktionierende Taskleiste benötigt."

Fehlermeldung der Repo-Version von owncloud unter Ubuntu 15.04: „ownCloud wird für eine funktionierende Taskleiste benötigt.“

Hierbei handelt es sich offenbar um einen Übersetzungsfehler, welcher in aktuellen Versionen bereits behoben ist: https://github.com/owncloud/client/issues/2180

Dennoch: Auch mit einer korrekten Fehlermeldung bleibt es dabei: Diese Version spuckt einen Fehler aus.

Abhilfe kann man schaffen, indem man den Anweisungen auf der ownCloud-Homepage folgt um den aktuellen Desktopclient für Ubuntu zu installieren. Ein laufender ownCloud Client sollte zuvor beendet werden. Das Paket owncloud-client muss zuvor nicht deinstalliert werden, da es durch die folgenden Schritte aktualisiert wird:

Anschließend befindet sich die aktuelle Version des ownCloud Clients (derzeit 1.8.3) auf dem System und die Fehlermeldung sollte der Vergangenheit angehören.

Wir hatten im Rahmen der jüngst in der Bash bekannt gewordenen Sicherheitslücken die zweifelhafte Ehre, für nicht länger supportete SuSE Linux Systeme diese aus den Source-RPMs neu zu kompilieren. Dabei fielen uns in der darin enthaltenen .spec – Datei komische Variablen wie %{_mandir} oder %{_libdir} auf, die wir nicht zuordnen konnten. Ein Auszug:

./configure --build=%{_target_cpu}-suse-linux \
--prefix=/usr \
--with-curses \
--mandir=%{_mandir} \
--infodir=%{_infodir} \
--libdir=%{_libdir}

Dieses sind RPM interne Variablen, welche mit folgendem Aufruf ausgegeben werden können:

rpm --eval '%_libdir'
rpm --eval '%_mandir'
...

Manchmal hat man es im Alltag mit Dingen zu tun, da steht man selbst wenn man es Live vor sich sieht fassungs- und sprachlos davor und fragt sich … eigentlich garnichts mehr. Für manche Dinge gibt es einfach keine Worte; man sucht sie trotzdem, weil man es nicht einfach so stehen lassen KANN.
So mir gerade wieder geschehen; meine Hilflosigkeit ein geeignetes Wort dafür zu finden, möchte ich verarbeiten, indem ich hier berichte was geschehen ist und trage die Hoffnung, das es jemand anderem den gleichen Ärger ersparen möge.

(mehr …)

… als wenn der Kram unter MacOSX nicht dadurch, das jeder Installer seine eigene Prozedur zur Installation mitbringt, undurchsichtig genug wäre, ist das erste Fenster welches mir angezeigt wird, nachdem ich Outlook für Mac installiert habe folgender:

Office4Mac Fail

Office4Mac Fail

Ja, welchen nehme ich denn bloß … ? Egal, haben alle keine Funktion! 😉 Und ohne diese Registrierung fällt die weitere Outlook-Erfahrung leider komplett in’s Wasser; auch Neustarten bringt nichts. Wieder einmal: Danke, Apple, für eine weitere CD teuren Software-Mülls in meinem Regal.

Das Problem

Vor einiger Zeit sollte ich mal einen neuen Mac Rechner vorbereiten und unter (vielem) anderem Adobe Photoshop darauf installieren. Ich habe natürlich erstmal alles sauber vorbereitet: Platte formatiert, MacOS installiert, Updates eingespielt, User eingerichtet, unzählige kleine Programme installiert, … nach ein paar Stunden war Adobe Photoshop an der Reihe. Es begrüßte mich diese nette Anzeige:

Screen+Shot+2013-08-26+at+9.15.18+AM

(Zugegeben: Oberflächlich) Im Internet gesucht, am Ende sogar den Adobe Support angerufen (schließlich hat man ja für einen Ar*** voll Geld diese Software gekauft): Keine Ahnung. Gut angelegtes Geld also … Danke @Adobe!

Schließlich wurde ich im Blog eines Users namens „Sum Random Guy“ fündig (mehr …)

Ich hatte vor einiger Zeit auf einem Sabayon Linux System das Problem, das ich unter Skype absolut nichts verstehen konnte. Aus dem Kopfhörer drang nur eine Art „knirschen“; da es auch beim Skype Echo Service auftrat, war klar das es an mir und nicht an der Gegenseite liegt. Es trat jedoch nur bei Skype auf; keine andere Anwendung war hiervon betroffen.

Ich verwende KDE und damit unter Sabayon Standardmäßig PulseAudio. Ein Beitrag der User „ball“ und „swordfish“ brachten mir letzten Endes die Lösung, indem Sie im ArchLinux Forum auf Bug #50510 im FreeDesktop.org Bugtracker verwiesen:

Wenn man Skype wie folgt mit einer Wert von 30 in der Umgebungsvariable PULSE_LATENCY_MSEC startet, gibt es von jetzt auf gleich keine Probleme mehr:

bash -c „PULSE_LATENCY_MSEC=30 skype %U“