Support » Installation » Debian stretch – Ein automatisches Update konnte nicht beendet werden – Bitte st

  • Ich vermute, dass das Debian Paket mit dem auto-update „feature“ inkompatibel ist. Ich habe bereits versucht die Variable:
    define( ‚WP_AUTO_UPDATE_CORE‘, false );
    zu setzten, was aber nichts hilft, ich bekomme weiterhin die Meldung:

    Ein automatisches Update konnte nicht beendet werden – Bitte starte die Aktualisierung jetzt erneut.

    Im Dashboard und auf allen admin Seiten.

    Was mache ich falsch?

    Bzw.: Ich hätte gerne den Core Upgrade weiterhin über Debian, aber den Plugin Upgrade durchaus automatisch. Gehts das? Was empfehlt ihr?

    lg oe1rsa

Ansicht von 8 Antworten - 1 bis 8 (von insgesamt 8)
  • WordPress ist durch seine weite Verbreitung ein lukratives Ziel für Angreifer. Deshalb ist es wichtig, Sicherheitslücken so schnell wie möglich zu beheben. Daher würde ich auf WordPress‘ eigenen Aktualisierungsmechanismus bauen, statt mich darauf zu verlassen, dass mit einiger Verzögerung ein Installationspaket erstellt wird. (Ich würde sogar noch weiter gehen, und WordPress nie mit solch einem Installationspaket installieren, weil ich nicht weiß, welche Änderungen darin vorgenommen wurden.)

    Zu deiner Fehlermeldung: Schau bitte mal, ob im WordPress-Verzeichnis noch eine Datei .maintenance vorhanden ist. Die wird während der Installation angelegt, um während des Updates Besuchern einen Wartungshinweis anzuzeigen und sollte eigentlich am Ende des Updates automatisch entfernt werden.

    Stimmen auf deinem Server die Dateirechte? Dateien sollten mit 644, Verzeichnisse mit 755 abgelegt werden und einem Nutzer gehören, der PHP ausführen kann. Ggf. kannst du das für Verzeichnisse mit
    find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;
    und für Dateien mit
    find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;
    korrigieren.

    Uff, doch zunächst mal Danke für die schnelle Antwort, obwohl es nicht die Antwort ist die ich erhofft hatte. Ich verstehe schon das Argument, dass in den meisten Fällen ein automatischer Update eine gute Sache ist. Es wäre noch besser wenn das auf eine Art und Weise geschehen würde, die mit Debian kompatibel ist. (Ich träume ja nur.) Im Debian Fall hieße das aber nur: Hände weg vom Debian Paket. Hmm, Debian hat aber über viele Jahre eine sehr hohe Reputation was Sicherheit betrifft. Wenn ich das weiter denke müsste das wordpress Paket eigentlich aus dem Debian Repository verschwinden, oder auf eine Art und Weise installiert werden die sowohl mit der Security Policy von Debian als auch der von WordPress zusammenpasst. (Ich werde vielleicht mal den Mainainer des Debian Paketes kontaktieren…)

    Bis dahin brauche ich aber auch eine Lösung. Natürlich habe ich schon nach dem ominösen .maintenance file gesucht. Nein das ist nicht vorhanden.

    Nein, ich möchte auch nicht so einfach Dateien die in /usr/share/ liegen und root gehören Schreibrechte auf andere User geben. Das widerspricht den Debian guidelines und kommt mir wie eine große Sicherheitslücke vor. Das würde ich nur tun wenn es sich gar nicht vermeiden lässt und ich wordpress komplett neu installieren müsste.

    Weiters habe ich gestern schon das
    define( ‚WP_AUTO_UPDATE_CORE‘, false );
    Flag gesetzt und mit Hilfe von
    https://wordpress.stackexchange.com/questions/5468/an-automated-wordpress-update-has-failed-to-complete-please-attempt-the-updat#5471
    die Meldung entfernt.

    Aber scheinbar hat WordPress trotzdem wieder einen Auto Update versucht. Das erfüllt mich nicht gerade mit grosser Zuversicht, wenn ein Programm eine solche fundamentale Variable scheinbar ignoriert.

    Aber wahrscheinlich sehe ich das falsch 🙁

    lg oe1rsa

    Das sind ja nun einige Punkte, die du da ansprichst …

    Ich habe gerade nochmal einen Blick in das WordPress-Paket im Debian Stretch Repository geworfen. Das Paket enthält aktuell WordPress 4.7.5 – eine im Mai 2017 erschienene Version, für die bereits seit September weitere Updates angeboten werden, die kritische Sicherheitslücken beheben. Aktuell ist WordPress in Version 4.9.1 (29. November 2017) verfügbar und enthält zusätzliches Features. Du installierst also mit dem Paket eine veraltete Version mit kritischen Sicherheitslücken.

    Debian hat aber über viele Jahre eine sehr hohe Reputation was Sicherheit betrifft

    Bezieht sich das nicht auf das Betriebssystem?

    Natürlich habe ich schon nach dem ominösen .maintenance file gesucht.
    Die Datei ist gar nicht „verdächtig, zwielichtig„. Übrigens hilft es sehr, wenn du gleich zu Beginn kurz angibst, was du bereits unternommen hast. Das erspart einige Rückfragen.

    Nein, ich möchte auch nicht so einfach Dateien die in /usr/share/ liegen und root gehören Schreibrechte auf andere User geben. Das widerspricht den Debian guidelines und kommt mir wie eine große Sicherheitslücke vor.

    Wer hat denn sowas behauptet?! Kannst du bitte nochmal nachlesen, was ich empfohlen habe? (Steht übrigens so auch in der Anleitung zum Absichern von WordPress.)

    Weiters habe ich gestern schon das define( 'WP_AUTO_UPDATE_CORE', false ); Flag gesetzt

    Wenn du

    # Disable all core updates:
     define( 'WP_AUTO_UPDATE_CORE', false );

    in der WordPress-Konfigurationsdatei korrekt eingefügt hast, sollten automatische Updates des WordPress-Core durch WordPress selbst deaktiviert werden. Paket-Updates durch Debian sind davon nicht betroffen.

    Das erfüllt mich nicht gerade mit grosser Zuversicht, wenn ein Programm eine solche fundamentale Variable scheinbar ignoriert.

    Wow. Komm mal wieder runter.

    Ich nutze WordPress seit einigen Jahren und gebe in meiner Freizeit mein Wissen gerne kostenlos an andere Anwender weiter, preise WordPress aber nicht „wie sauer Bier“ an. Muss ich auch nicht. WordPress kommt millionenfach zum Einsatz, auch bei stark frequentierten Websites mit hohem Sicherheitsbedarf wie z.B. https://whitehouse.gov. Wenn du aber Bedenken hast, solltest du vielleicht eine andere Software in Erwägung ziehen.

    Ok, vorne weg: Sorry vielmals, falls Du mein Posting als unangemessen empfunden hast. Das war definitiv nicht meine Absicht. Ich finde es nämlich super, dass Menschen wie Du ihre Kenntnisse und Energie in so einem Forum zur Verfügung stellen.

    Ein ehrliches Dankeschön!

    Ja es ist eine Tatsache, dass ich das Wort „ominös“ missverständlich verwendet habe. Ich meinte es im Sinne von „berüchtigt“ insoferne als gefühlte 90% der Treffer im Nezt empfehlen diese Datei zu löschen. Mir war und ist schon klar, dass diese Datei nur die Rolle eines „Flags“ haben konnte und dass sie nicht in irgendeiner Weise gefährlich ist. Ich habe bisher ominös eben in einer anderen Weise verstanden. Vielleicht ist es auch ein unterschiedlicher kultureller Hintergrund. Ich weiß zum Beisiel nicht was Du mit „anpreisen wie sauer Bier“ meinst. Ist das etwas gutes oder schlechtes? Lass uns deshalb bitte lieber wieder zum Thema zurückkehren:

    Kannst du bitte nochmal nachlesen, was ich empfohlen habe? … Verzeichnisse mit 755 abgelegt werden und einem Nutzer gehören, der PHP ausführen kann.

    Ja, ich habe Dich schon verstanden. Bei mir gehören diese Dateien aber derzeit dem root, und die Permissions sind schon (fast) so gesetzt (ich kann nicht verstehen wozu das x-ecute bit gesetzt sein müsste). Ich habe gemeint, dass es im Allgemeinen keine gute Idee ist, wenn eine Web Applikation die unter dem User „xy“ läuft ihre eigenen (ausführbaren) Dateien ändern kann.

    Zurück zum Beginn meiner Anfrage: Wie kommt es, dass WordPress trotz des gesetzten Flags diesen Auto Update weiterhin versucht? Hast Du da vielleicht einen Tipp wie ich weiter vorgehen könnte?

    Btw.: Prosit Neujahr

    Ich habe gemeint, dass es im Allgemeinen keine gute Idee ist, wenn eine Web Applikation die unter dem User „xy“ läuft ihre eigenen (ausführbaren) Dateien ändern kann.

    Das ist wohl ähnlich wie bei Firefox, das auch selbständig Updates ausführt.

    Wie kommt es, dass WordPress trotz des gesetzten Flags diesen Auto Update weiterhin versucht?

    Wo hast du denn die Konstante eingefügt?
    Poste doch bitte mal den Inhalt deiner wp-config.php (Zugangsdaten bitte unkenntnlich machen).

    Häufiger Einsteigerfehler: Es existieren mehrere wp-config.php und es wird an der falschen Stelle eingefügt. (Das heißt nicht, dass du diesen Fehler gemacht hast, ich meine nur, dass das häufig vorkommt und eine mögliche Ursache sein könnte.)

    Verwendest du das WordPress Command Line Interface WP-CLI?

    Wo hast du denn die Konstante eingefügt?

    in einem /etc/wordpress/config-<meindomainname>.php File, das über das debian config eingebunden wird:

    The Debian package installs a wp-config.php script that will
    try to load the real configuration from /etc/wordpress/config-$HOST.php
    or /etc/wordpress/config-$DOMAIN.php (if the URL is „http://blog.example.com“,
    $HOST will be „blog.example.com“ and $DOMAIN will be „example.com“).

    Poste doch bitte mal den Inhalt deiner wp-config.php

    Nur ungern, aber wie gesagt ich weiß, das es aktiv ist, da sich sonst Änderungen die darin gemacht habe nicht ausgewirkt hätten:

    <?php
    # Created by ./setup-mysql-wp 
    define('DB_NAME', 'wordpress');
    define('DB_USER', 'wordpress');
    define('DB_PASSWORD', 'XXXXXX');
    define('DB_HOST', 'localhost');
    define('SECRET_KEY', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx');
    define('WP_CONTENT_DIR', '/var/lib/wordpress/wp-content');
    define('FORCE_SSL_ADMIN', true );
    define('FS_METHOD', 'direct' );
    define('AUTOMATIC_UPDATER_DISABLED', true);
    define('WP_AUTO_UPDATE_CORE', false );
    
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', true);
    define('DOMAIN_CURRENT_SITE', 'XXXXXXXXXXXXXX');
    define('PATH_CURRENT_SITE', '/');
    define('SITE_ID_CURRENT_SITE', 1);
    define('BLOG_ID_CURRENT_SITE', 1);
    
    define( 'AUTH_KEY', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'SECURE_AUTH_KEY', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'LOGGED_IN_KEY', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'NONCE_KEY', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'AUTH_SALT', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'SECURE_AUTH_SALT', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'LOGGED_IN_SALT', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    define( 'NONCE_SALT', 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' );
    ?>

    Verwendest du das WordPress Command Line Interface WP-CLI?

    Nein, das sagt mir nichts. Könnte mir das helfen? Shell Zugang habe ich.

    Btw.:

    Das ist wohl ähnlich wie bei Firefox, das auch selbständig Updates ausführt.

    Bei mir jedenfalls macht er das nicht ohne meine Erlaubnis.

    • Diese Antwort wurde geändert vor 5 Monate, 3 Wochen von  Bego Mario Garde.
    • Diese Antwort wurde geändert vor 5 Monate, 3 Wochen von  Bego Mario Garde. Grund: Code-Formatierung korrigiert

    Die Einträge in der wp-config.php scheinen korrekt zu sein. Wieso trotzdem Updates des WordPress-Core vorgenommen werden, kann ich nicht nachvollziehen.

    WP-CLI ist ein zusätzliches Tool, um WordPress per Terminal zu steuern. Es wäre möglich gewesen, dass über WP-CLI Aktualisierungen vorgenommen werden.

    Mein Verdacht ist im Moment, dass die Multisite-Konfiguration eine Rolle spielen könnte. Plugins können wir wohl als Verursacher ausschließen, da es sich um eine Neuinstallation handelt?

    Wieso du die Daten „ungern“ teilst, kann ich nicht nachvollziehen. Es sind keinerlei Informationen enthalten, die Rückschlüsse auf deine Website geben und ohne Informationen (wie z.B. dass es sich um eine Multisite-Installation handelt), können wir eh nur raten, was die Ursache von Problemen sein könnte.

    Als Workaround könntest du noch versuchen, über das Plugin Easy Updates Manager Updates zu unterbinden. Mehr fällt mir im Moment nicht dazu sein – Sorry.

    Plugins können wir wohl als Verursacher ausschließen, da es sich um eine Neuinstallation handelt?

    Es handelt sich zwar um eine Neuinstallation, aber ich verwende WordPress eigentlich nur deshalb weil der podlove publisher wp benötigt. Ich habe nun nochmals alle config Variablen überprüft und werde das System unter Beobachtung halten. Vielleicht geht’s ja nun doch noch.

    Aber heuer wird das wohl nichts mehr ;-). Vielen herzlichen Dank jedenfalls für Deine Mühe. Ich wünsch Dir ein gutes neues Jahr.

    oe1rsa

Ansicht von 8 Antworten - 1 bis 8 (von insgesamt 8)