WordPress Crons als Linux Cronjob einrichten

WordPress – Crons als Linux Cronjob einrichten

WordPress bringt sein eigenes Cron-System mit. Dabei wird nicht aller X Minuten ein Cronjob ausgeführt, sondern es wird pro Seitenaufruf geschaut, ob etwas zu tun ist (Pseudo-Cron). Das kann mitunter zu sehr hässlichen Ladezeiten und Performanceproblemen führen.

Um dieses Problem zu lösen, schaltet man diesen Pseudo-Cron ab und stellt es auf einen echten Linux-Cronjob um. Dazu editiert man die wp-config.php und fügt vor

/* Das war’s, Schluss mit dem Bearbeiten! Viel Spaß beim Bloggen. */

folgendes an:

/** Disable pseudo-cronjobs and run them manually in linux crontab */
define('DISABLE_WP_CRON', 'true');

In Linux können dann die Cronjobs verändert werden. Dazu begibt man sich in die Cron-Tabelle via:

crontab -e

Und fügt folgendes an:

# Call wordpress every minute to start all wordpress cronjobs
* * * * * curl --silent -S https://www.example.com/wp-cron.php?doing_wp_cron

Hierbei wird cURL mit folgenden Parametern aufgerufen:

  • –silent: Unterdrücke die Ausgabe von cURL
  • -S: Ausgabe soll harte Fehler trotzdem enthalten

Im Crontab sieht das dann so aus:

Crontab mit curl für automatische WordPress Updates
Crontab mit curl für automatische WordPress Updates

Best practice

WordPress Crons als Linux Cronjob einrichten
WordPress Crons als Linux Cronjob einrichten

vim – Highlight der letzten Suche entfernen

In vim lässt es sich mit „/SUCHWORT“ ganz einfach suchen.

Eine Suche nach dem Wort „follow“ in vim.
Eine Suche nach dem Wort „follow“ in vim.

Doch manchmal stört danach das Highlightning des Suchwortes. Dies lässt sich über folgenden Befehl wieder entfernen:

:noh
Entfernen des letzten Hightlightings in vim via „:noh“.
Entfernen des letzten Hightlightings in vim via „:noh“.

Der Begriff noh steht hierbei für „No Highlighting“. Es wird dabei nur temporär das Highlighting abgeschalten. Die nächste Suche bringt erneut das Highlighting zu Tage.

Best practice

Best practice: Remove search highlight in vim
Best practice: Remove search highlight in vim

WordPress – Aktualisiert sich nicht automatisch

Immer wieder kommt es vor, dass WordPress keine automatischen Updates mehr vornimmt. Das kann mehrere Ursachen haben.

Fehlende Rechte

Grundsätzlich reicht es aus darauf zu achten, dass alle Unterodner und der Stammorder ( z.B. /var/www/html ) mit dem Nutzer des Webservers versehen sind. Die Lösung hierfür ist also ganz einfach. Auf der Kommandozeile muss der Stammordner und alle dazugehörigen Unterordner dem Webservernutzer zugewiesen werden (in diesem Fall hier „apache“):

chown apache. /var/www/html -R

Unter umständen kann es aber passieren, dass die Rechte zurückgesetzt werden. Um dieses Problem automatisiert in Angriff zu nehmen, wird der obige Kommandozeilenbefehl in den Crontab zur automatischen Ausführung mit aufgenommen. Hierzu ruft man die Cron-Tabelle auf:

crontab -e

In der Cron-Tabelle muss dann folgendes eingetragen werden:

 * * * * chown apache.apache /var/www/* -R

Versionskontrollsystem in den Verzeichnissen

WordPress schaut vor den Aktualisierungen, ob es .svn, .git, … als Ordner findet. Falls ja, wird stillschweigend das automatische Update abgebrochen. Die einfachste Lösung ist, die Ordner zu löschen. Alternativ kann man das auch über ein Zusatzplugin (manuell) lösen. Der Filter hierzu ist automatic_updates_is_vcs_checkout .

yum – update vs. upgrade

Alle Jahre wieder google ich, warum in der yum-cron.conf folgendes bei default steht:

yum upgrade

Nun stellt sich also die Frage, warum dort nicht folgendes steht:

yum update

Um das herauszufinden, müssen wir uns die Definitionen noch einmal anschauen.

yum update

Hier wird eine Update der Pakete durchgeführt und es werden nur manchmal die alten Pakete gelöscht. Was man unter manchmal zu verstehen hat, kann man gerne der Definition im Manual entnehmen (siehe ganz unten in diesem Artikel).

yum upgrade

Hier wird eine Update der Pakete durchgeführt und die überflüssigen Pakete werden definitiv gelöscht. Das Kommando ist auch ein alias zu:

yum update --obsoletes

Welches sollte verwendet werden?

Der sichere Weg laut Linux Manual ist yum update.

In yum-cron.conf ist dies jedoch nicht der Standard. Man sollte es dort also austauschen.

man yum

yum update vs yum upgrade manpage
yum update vs. yum upgrade manpage

Best practice

yum update vs yum upgrade
yum update vs yum upgrade

Cloudflare – Russland-Probleme beheben

Cloudflare selbst bietet die Möglichkeit, auch in Russland aktiviert zu werden. Doch was passiert eigentlich, wenn eine geblockte Website auf derselben Edge-IP hängt wie meine eigene Website?

Ja – es führt dazu, dass russische Besucher die Seite zum Teil nicht aufrufen können. Das liegt daran, dass eine IP-Blacklist von den russischen Providern geführt wird. Somit sind manche Edge-IPs ganz einfach „verbrannt“.

Die Lösung ist so simple wie logisch:

Einfach ein dediziertes SSL Zertifikat im Business-Plan von Cloudflare hochladen. Das zwingt Cloudflare dazu, einem immer eine eigene IP pro Edge-Knoten zu geben. Auf dieser IP hängt dann kein anderer Kunde *yay*.

[lbmethod_heartbeat:notice] AH02282: No slotmem from mod_heartmonitor

Alle Jahre wieder… CentOS7 mit LAMP Stack installiert, httpd gestartet und schon ist das Apache error_log voll… WARUM? Es nervt! Fehler aus /var/log/httpd/error_log

[lbmethod_heartbeat:notice] [pid 14144] AH02282: No slotmem from mod_heartmonitor

Letztlich ist die Lösung einfach, aber trotzdem hässlich. Das lbmethod_headertbeat_module muss im Apache deaktiviert werden. Hier wird es in /etc/httpd/conf.modules.d/00-proxy.conf auskommentiert

#LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so

Eventuell findet sich später mal eine schönere Lösung, aber selbst hier gibt es keine.

Sendmail mit Gmail SMTP (CentOS, Sendmail)

Ich werd es mir wahrscheinlich nie merken, aber so hier wird aus Gmail ein Relay für Sendmail. Danke an Linuxconfig.org.

# logisch - man braucht erstmal sendmail
yum install sendmail

# dann brauchst die configtools von sendmail
yum install sendmail-cf

# dann die Authentifizierung hinterlegen
# Bei Google muss dazu ein Einmalpasswort hinterlegt werden
mkdir -m 700 /etc/mail/authinfo/
cd /etc/mail/authinfo/
echo 'AuthInfo: "U:root" "I:YOUR GMAIL EMAIL ADDRESS" "P:YOUR PASSWORD"' > gmail-auth
makemap hash gmail-auth < gmail-auth

# in /etc/mail/sendmail.mc direkt vor MAILER(smtp)dnl folgendes hinterlegen:
define(`SMART_HOST',`[smtp.gmail.com]')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
define(`ESMTP_MAILER_ARGS', `TCP $h 587')dnl
define(`confAUTH_OPTIONS', `A p')dnl
TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`authinfo',`hash -o /etc/mail/authinfo/gmail-auth.db')dnl

# bisschen kuchen backen
make -C /etc/mail
# bisschen crypto noch nachinstallieren
yum install cyrus-sasl*

# dann sendmail und crypto neu starten
service saslauthd restart
service sendmail restart

# Und dann noch testen
echo "Subject: sendmail test" | sendmail -v [email protected]

Ach und immer schön an den FQDN denken, aber NICHT www.example.com nehmen. Besser so etwas wie meinhost.example.com (logischerweise mit IP dahinter)

AUTH=client, available mechanisms do not fulfill requirements (CentOS, Sendmail)

Alle Jahre wieder läuft mir dasgleiche sendmail Problem in Verbindung mit Gmail SMTP via Sendmail über den Weg:

Auszug aus /var/log/maillog:

sendmail[7077]: STARTTLS=client, relay=gmail-smtp-msa.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
sendmail[7077]: w1G9b8C0007075: AUTH=client, available mechanisms do not fulfill requirements
sendmail[7077]: AUTH=client, relay=gmail-smtp-msa.l.google.com., temporary failure, connection abort
sendmail[7077]: w1G9b8C0007075: to=<[email protected]>, ctladdr=<[email protected]> (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=120307, relay=gmail-smtp-msa.l.google.com. [IPv6:2a00:1450:400c:c04::6c], dsn=4.0.0, stat=Deferred: Temporary AUTH failure

Hierbei bemängelt Google:

AUTH=client, available mechanisms do not fulfill requirements

Grund: Die Verschlüsselungsmethoden fehlen. Diese lassen sich aber in CentOS relativ einfach nachinstallieren:

yum install cyrus-sasl*

Danach sollten die jeweiligen Dienste noch neu gestartet werden:

service saslauthd restart
service sendmail restart