Croncheck nach Maria DB Update funktioniert nicht mehr

[mikew]

Ich nutze das nützliche Tool: https://dev4me.com/modules-snippets/opensource/croncheck/
Nach einem Update der DB auf Server-Version: 10.5.23-MariaDB wird die Checksum (ich denke, so funktioniert das Script ?) nicht mehr gespeichert
und dadurch werden immer ALLE Dateien als verändert/hinzugekommen erkannt:

New files were added:
/kontakt.php -> 07.09.20234 15:23
/unser-team.php -> 05.08.2023 17:29 ...usw.

croncheck.php lief bisher mit
php 5.4.16
und nun mit php 7.4.33

Ich vermute aber, dass das Problem ehe beim DB Update zu suchen ist.
Das DB Feld "md5" ist immer leer !

[ruebenwurzel]

Hallo,

- für Hilfe zu dem Snippet ist es am Besten du wendest dich direkt an den Autor
- bezüglich der Cron Jobs wäre dein Provider der richtige Ansprechpartner, vielleicht hat der ja auf dem Server was verändert. Das hat aber mit WebsiteBaker zunächst mal nix zu tun. Hast du denn Fehlermeldungen in WebsiteBaker? Welche Version von WebsiteBaker hast du im Einsatz? Was für eine PHP und MariaDB Version ist bei dir im Einsatz?

[hgs]

Bei mir geht es ohne Probleme.

1. Aufruf

 
https://gyazo.com/23a0782a0e06e66d52f710195efcb81d
2. Aufruf

 
https://gyazo.com/7d83236e91a68ffd375eacba9f7e3edd
Es ist allerdings die aktuelle WB-Version 2.13.4 mit php 8.2
MariaDB ist die gleiche Version wie bei dir

Das Feld md5 ist bei mir auch leer
 
https://gyazo.com/a0d8ef467d511a65a7d111cc04bddf7e

[sternchen8875]

Ich vermute aber, dass das Problem ehe beim DB Update zu suchen ist.
Das DB Feld "md5" ist immer leer !

kann ich bestätigen und wenn du mich als Laien fragst, geht das auch garnicht, zumindest nicht so, wie du es beschreibst.
Ich wüßte auf Anhieb auch nicht, wie das (im Script) funktionieren sollte, hab diesen Code noch nicht gefunden.

der md5Hash geht ja auf Dateiebene und dient als zusätzliches Sicherheitsfeature, er ist, wenn in den Einstellungen auf true, Teil des Arrays, der in der DB unter data serialisiert gespeichert wird.


Beim Vergleich von alt gegen neu wird dann auch der md5Hash mit geprüft. Als Hintergrund muß man wissen, das man sehr wohl den Inhalt einer Datei und deren Speicherdatum so manipulieren kann, das es nach außen nicht auffällt, aber dann einen geänderten md5Hash bekommt. Alles, was neu an Dateien hinzugekommen ist, kommt dann serialisiert ins Feld added, die veränderten Dateien ins Feld modified und gelöschte Dateien dann ins Feld removed.

Wenn du nun nichts änderst an deinen Dateien, sollte in der DB nur das Feld data einen längeren Eintrag bekommen, die anderen oben genannten dann einen Leereintrag vom Serialize() - ein a:0:{}
Schaut man nun in die Datenbank, würde man wohl einen md5Hash erwarten, z.b. vom current-Array, der dann im Feld data steht, das würde dann wohl auch die nächste Prüfung beschleunigen, weil eben nur noch ein Wert verglichen werden muß. Allerdings sehe ich keinen Code dafür, weder in der aktuellen, noch in den Vorgänger-Versionen.
Wenn das früher so funktioniert haben soll, wäre ich sehr erstaunt.
P.S.: es gibt auch keine globale Funktion, weder bei WB, noch in den Forks und auch keine solche Funktion innerhalb von PHP.

In deinem Eingangs-Post stehen jetzt nur zwei Dateien drin, die sich verändert haben. Würde der Vergleich nicht funktionieren, sollten im Feld added alle Dateien drin stehen, beginnend im Account-Ordner
Schau bitte, das in der Datei croncheck.php $silent als false definiert ist (~ Zeile 13), bei $checkmd5 eine Zeile zuvor ist es egal, ob true oder false
Für einen sauberen Test kannst du die Tabelle "croncheck" in der DB einfach löschen. Niemand benötigt alte Vergleiche (meine ich). Dann rufst du die Datei croncheck.php im Browser auf. Ist sie fertig, drückst du auf Reload oder STRG + F5 oder STRG + R
In diesem zweiten Durchlauf sollten dann nur ganz wenige Dateien auftauchen, bei mir halt die error-log, weil ich im lokalen Test keine Mails versende.

Der zweite Durchlauf schaut bei mir im Report so aus

Something has changed on http://wb1645

New files were added:

/croncheck.php -> 17-12-2023 16:35

These files are changed:

/var/log/php_error.log.php -> 17-12-2023 16:03

These files have been removed:

/cron/croncheck.php -> 17-12-2023 16:03


The script was running for 2.6521079540253 seconds

Schau mal, was dann rauskommt und poste ggf die Kopie des Reports, gern auch privat, wenn du möchtest, das es "unter uns" bleibt