Church Tools - Auto Updater

dennis-eisen

ChurchTools AutoUpdater

Das hier geht an alle, die ChurchTools selbst hosten...

Allgemein

Michael Lux (@milux) und Ich hatten keine Lust mehr ChurchTools ständig von Hand per FTP zu aktualisieren, deshalb haben wir einen "kleinen" Auto Updater für ChurchTools 3.x entwickelt.
Die Benutzung unseres Updaters ist denkbar einfach und sollte auch ohne Programmier-Kenntnisse nicht überfordern.

View project on GitHub

Funktionen

Folgender Funktionsumfang ist in unserem Skript momentan enthalten:

Schutz des Skripts mit per Query-String übergebenem Passwort.
Verifikation, ob ein Update verfügbar ist.
Herunterladen der ZIP-Datei vom ChurchTools SeaFile Server
Entpacken der ZIP-Datei und Ersetzung der index.php und des system-Verzeichnisses (Einspielen des Updates)

Bei Fragen stehen wir gerne zur Verfügung!

Installation

Vor dem erstmaligen Aufrufen der update.php müsst Ihr einen Hash für euer gewähltes Passwort erstellen.
Dafür zuerst durch den Aufruf von https://churchtools_domain.xyz/createHash.php?EUER_PASSWORT einen Passwort-Hash erzeugen!
Danach müsst ihr den dort erstellten Hash in der update.php bei define('HASH', 'PUT IN YOUR OWN HASH HERE'); eintragen.
Wenn ihr jetzt noch bei define('SEAFILE_DIR', '/d/xyz1234567/'); den Pfad auf die Stelle anpasst, bei der ihr die ChruchTools-Updates herunter ladet, ist das Skript einsatzbereit!
(Ihr bekommt bei Updates per E-Mail einen Link zu einer SeaFile-Seite, die i.d.R. so aussieht: https://seafile.churchtools.de/d/xyz1234567/, kopiert davon einfach den hinteren Teil!)

Nun das Update-Skript im Root-Verzeichnis der ChurchTools Installation (neben index.php, system, files, etc.) ablegen und per Cronejob einmal am Tag (z.B. bei uns 4:00 Uhr) so aufrufen:
https://churchtools_domain.xyz/update.php?EUER_PASSWORT

Die meisten Hosting-Provider bieten Cronjobs für ihre Kunden an.
Wenn ihr keine Cronjobs anlegen könnt, könnt ihr auch einen kostenlosen externen Dienst wie https://www.cron-job.org/ dafür verwenden.

This post is deleted!

dennis-eisen

@nico Hallo Nico, was genau willst du uns damit sagen? Weitere Informationen wären für eine Hilfestellung unabdingbar.

Im Installationstext verwendet Ihr die upload.php; angelegt habt Ihr lt. GitHub aber die update.php

dennis-eisen

@nico Danke für den Hinweis, wurde geändert.

daniel_

sehr schick. @dennis-eisen wir sind auch bei all-INKL. Ich habe aber den "system"-ordner als PHP-User laufen. Würde der Updater trotzdem funktionieren oder muss ich vorher wieder auf FTP-User umstellen? Wenn ich das "system" im FTP User belasse, bekomme ich immer Fehlermeldungen ohne Ende

merhard

Wäre es nicht sinnvoll, wenn Churchtools das gleich in ihr System mit integriert?

dennis-eisen

@daniel_h Also unser Skript funktioniert auch wunderbar, wenn der system Ordner dem PHP-User zugeordnet ist. Ich finde es allerdings interessant, den bei uns sind alle Ordner dem FTP-User zugeordnet und es gibt keine Probleme:
Kannst du mir bitte die Fehlermeldungen wenn du auf FTP-User umstellst und den Inhalt deiner .htaccess als private Nachricht schicken?

@merhard Das wäre natürlich wunderbar, aber ohne jemanden auf den Schlips treten zu wolle, dass dauert wohl noch ein wenig.
Das wäre dann aber eher ein Beitrag für die Kategorie Feature-Wünsche... Wenn du einen erstellen solltest, würdest du dafür definitiv einen Upvote von mir bekommen!

jmrauen

Sieht super aus, unter welche Lizenz stellt Ihr das, dürften wir das direkt in CT einbauen?

milux

@daniel_h sagte in Church Tools - Auto Updater:

sehr schick. @dennis-eisen wir sind auch bei all-INKL. Ich habe aber den "system"-ordner als PHP-User laufen. Würde der Updater trotzdem funktionieren oder muss ich vorher wieder auf FTP-User umstellen? Wenn ich das "system" im FTP User belasse, bekomme ich immer Fehlermeldungen ohne Ende

Da unser Skript rein PHP-basiert ist, müssen die Zugriffsrechte alle auf dem PHP-Nutzer liegen.
Das ist eine Grundvoraussetzung, damit das Skript funktioniert!
Allerdings gibt es auch eine Möglichkeit, dieses Problem mit den unterschiedlichen Usern komplett aus der Welt zu schaffen. Bei uns machen wir das seit jeher so, deswegen die verwundete Reaktion von Dennis, der dieses Problem aus der "Steinzeit" gar nicht mehr kennt.
Wenn du statt Apache-Modul FPM verwendest, um die PHP-Skripte aufrufen zu lassen, läuft ALLES über den "FTP-User". Das kann man inzwischen sogar direkt im KAS einstellen, unter (Sub)Domain > Bearbeiten (Schaltfläche rechts in der Zeile der betreffenden (Sub)Domain) > PHP Version > auswählen "X.Y (CGI/FPM)".
Dann einfach alle Rechte rekursiv auf den "FTP-User" übertragen, und nie wieder Kopfschmerzen mit Rechten.

milux

@jmrauen
Wir planen, das Skript unter MIT-Lizenz zu stellen, also sehr permissiv, sodass ihr es auch vermarkten könnt.

AAABER: Wie genau würdest du dieses Skript denn einbauen wollen?
Der gruselige von Besuchern getriggerte Pseudo-Cronjob ist dafür i.m.h.o absolut nicht geeignet...

MichaelG

Und er sollte auch auf manuell gestellt werden können, da wir viel über die API machen und beim Update auf 3.1 z.B. sich ein paar Sachen geändert hatten, die dann Teile unserer HP nicht mehr richtig funktionieren haben lassen.

milux

@MichaelG Bin ich offen gesagt dagegen, weil es gibt einfach Leute, die das einspielen von (v.a. sicherheitskritischen) Updates gerne bis zum Sankt-Nimmerleins-Tag verschleppen.
Vielleicht wäre es ein guter Mittelweg, dem Admin im Falle eines Updates eine Mail zu schicken, und nach einer Übergangszeit von z.B. einer Woche ohne Rückmeldung das Update automatisch einzuspielen.

Ich finde es auch generell sehr unsauber, dass ohne Rückwärtskompatibilität innerhalb einer Major-Version die API-Semantik geändert wird, sowas sollte nicht passieren! @jmrauen, damit meine ich euch.

jmrauen

Habe nochmal darüber nachgedacht: Die Kontrolle sollte beim Kunden bleiben, wir würden nicht bei denen automatisch ohne dass sie es wünschen Updates einspielen.
Da Ihr es so gut gelöst habt, würde ich dann von festen Integration in ChurchTools absehen. Wer es haben möchte, kann sich das dann ja einfach selbst einrichten.

MichaelG

@jmrauen Also mit einer Funktion das selbst zu Triggern fände ich das schon gut. Wie z.B. bei Wordpress. Da klick ich einmal auf und muss nicht mit FTP Client und Drag and Drop arbeiten

dennis-eisen

Wir haben eine neue Version unseres Auto Updaters veröffentlicht:
https://github.com/dennis-eisen/CT_AutoUpdater

Diese erkennt jetzt auch inkonsequente Versionnummern (z.B. 3.11b).
Außerdem erkennen wir die Notwendigkeit eines Updates nicht mehr an der hinterlegten Versionsnummer in constants.php sondern am Filedate der constants.php. Somit sind wir nicht mehr auf eine konsequente Anpassung der Versionsnummer von Seitens der ChurchTools Entwickler angewiesen.

@jmrauen Warum ist das aktuelle Update - 3.11b - nicht in der constants.php zu finden. Laut dieser ist immer noch die Version 3.11 installiert?

jmrauen

Guter Hinweis, werden wir nächstes Mal berücksichtigen. Bisher gab es kein Auto-Updater:)

tomzi

Hi,

Ich finde dieses Tool wirklich klasse, ich wollte nur fragen, ob ihr es noch ein bischen erweitern könntet:

-> automatischen DB Dump von churchtools anlegen (@jmrauen gibt es da eine API in CT wie man den dump über dieses php skript anstossen könnte? Den dump braucht man, falls was beim update schief läuft.
-> alle heruntergeladenen zip + dumpfiles sollen archiviert werden am server.

manualUpdate.php
updateNotifier.php
-> es wäre auch cool zusätzlich zwei andere Tools für nicht so abenteuer freundliche autoupdate zu haben, wo man nur notifieziert wird als CT Admin (nicht das email dass an die bei CT registrierte person geht), falls ein update verfügbar ist. Dann rufe ich die url zu manaulUpdate.php auf, dort finde ich infos wie,

welches update is verfügbar
link zu den release notes
'Perform update' button -> dann wie gehabt das autoupdate ausführen

restorePreviousRelease.php

Über diesen link, könnte man ein beliebige vorher gespeicherte Version (CT_Version + dump) wieder herstellen.

Was denkt ihr?

dennis-eisen

@tomzi Deinen Vorschlag zu den DB-Dumps finde ich gut. Diesen werde ich auch im eigenen Interesse zeitnah einpflegen (sollte keine große Schwierigkeit darstellen).

Deinen zweiten Vorschlag zu den manuellen Updates finde ich an sich auch gut, leider fehlt mir für diese Umsetzung die Motivation. Von unserer Seite aus benötigen wir diese Funktionalität nicht und daher werde ich dies wohl auch nicht umsetzen.

merhard

Kann es sein, dass der Auto Updater nicht mehr funktioniert?
Ich hab auch einen Fehler, an dem es vermutlich liegt. es gibt garkeine ".zip" Datei mehr in dem Verzeichnis aus dem er das update laden will. Das ist jetzt eine .tar.gz

drstone

@merhard sagte in Church Tools - Auto Updater:

Kann es sein, dass der Auto Updater nicht mehr funktioniert?
Ich hab auch einen Fehler, an dem es vermutlich liegt. es gibt garkeine ".zip" Datei mehr in dem Verzeichnis aus dem er das update laden will. Das ist jetzt eine .tar.gz

Ja, liegt an der .tar.gz die sonst immer eine .zip war. Außerdem war bei 3.18.1 update nicht ein 'churchtools' ordner gepackt, sonder ein 'churchtools-3.18.1', was den nächsten Fehler verursachen würde.

@jmrauen: Könnt ihr das immer als zip gepackten "churchtools" Ordner hochladen? Oder muss das script hier auf mehrere Varianten angepasst werden?

:thorsten

dennis-eisen

Ab sofort gibt es eine neue Version (2.0) unseres Church Tools - Auto Updater:
https://github.com/dennis-eisen/CT_AutoUpdater/releases/tag/2.0

Bei Fragen oder Problemen dürft ihr euch gerne an uns wenden.

Wir haben den Updater um folgende Funktionen erweitert:

implemented ".tar.gz" support
added push notification
added locking (to prevent concurrent update)

merhard

Das mit Pushbullet hättet ihr auch gerne erklären dürfen. Dazu steht nix in der Readme und auch hier wird es nicht erklärt.
Und dann kommt da ein komischer fehler, wenn man die push.inc.php einfach mit hochlädt.

dennis-eisen

@merhard In der push.inc.php (Zeile: 16-23) ist alles Wissenwerte zu Pushbullet erklärt:

Pushbullet, put in your own credentials below and set service to "true" if needed
Our pushbullet integrations requires the pushbullet libary of ivkos:
https://github.com/ivkos/Pushbullet-for-PHP
Import the Pushbullet libary into the root of your webspace,
if you want to use this service and remove the hastag from the subsequent line.

Solltest du die Push-Benachrichtigungen nicht benötigen, musst du einfach die Datei push.inc.php nicht mit hochladen, bzw. wieder löschen. Unser Skript erkennt dies automatisch und es sollte kein Fehler ausgegeben werden. Eigentlich dürfte aber auch kein Fehler ausgegen werden, wenn du die push.inc.php trotzdem mit hochgeladen hast. Ich werde mir das anschauen.

Danke aber trotzdem für den Hinweis, ich werde dies auch in die Readme einpflegen und noch ein wenig erweitern.

Soweit nun alles klar?

merhard

Jupp, danke. Alles klar.

fujifan

Hallo,
seit heute Abend bekomme ich leider folgendes angezeigt:

"### ChurchTools - Auto Updater ###
No valid ChurchTools 3 download found in HTML!"

Bisher hat immer allers funktioniert. Das Update von 3.22.1 auf 3.22.2 lief noch. Von 3.22.2 auf 3.22.3 will er nun nicht. Ideen?

milux

Kann den Fehler leider nicht bestätigen... Bei uns funktioniert es tadellos, das HTML ist korrekt.
Vielleicht war der SeaFile-Server vorübergehend offline oder so?

fujifan

Also ich kann das nicht bestätigen. Das Update auf 3.22.4 macht er auch nicht; gleiche Meldung. Der SeaFile-Server lässt sich problemlos abrufen...und wenn ich dann unmittelbar die Update.php aufrufe, kommt dann diese Meldung....

metowa20

Geht denn der Updater noch? Obwohl ein Update vorhanden war, ist es nicht durchgelaufen. Für frühere Versionen kann ich nichts sagen, da ich jetzt erst damit anfange, aber das Update von 3.50.1 auf 3.51 musste ich von Hand machen, der Updater hats nicht gemerkt.

metowa20

geht mittlerweile. Weiß nicht woran es lag.

seetalchile

Offenbar besteht doch ein Problem... Auf Version 3.54 mussten wir nun manuell aktualisieren.

Der AutoUpdater zeigt folgende Meldung: No valid ChurchTools 3 download found in HTML!

Kann das sonst auch jemand bestätigen?

Meine Schnellanalyse zeigt, dass beim Abruf der Seafile-URL mittels file_get_contents() nicht derselbe Quelltext zurückkommt wie beim Abruf via Browser, d.h. die File-Auflistung ist nicht im Quelltext vorhanden. Besteht hier womöglich ein Problem seitens Seafile?

metowa20

Richtig. Ging bei uns auf 3.54.1 jetzt auch nicht. Musste das Update manuell machen.
Weiß aber auch nicht, wie ich das debuggen kann. Bin halt eher Anwender

j.gross

@seetalchile Kann ich bestätigen. Scheint ein einem Seafile Update seitens Churchtools zu liegen wodurch der Updater nichts mehr findet.

drstone

https://github.com/dennis-eisen/CT_AutoUpdater/issues/3

@jmrauen Ist es möglich einen eignen AuthToken für den Updater zu bekommen und einfacher und sicherer die zip files zu bekommen?

AGraf

Bei uns funktioniert der Auto Updater auch nicht mehr.
Es kommt die Meldung: "No valid ChurchTools 3 download found in HTML!"
Beim Analysieren ist mir aufgefallen, dass im Htmlcode der abgerufenen Seafile-Seite kein href-Eintrag mit dem Download-Link vorhanden ist. Er wir vermutlich jetzt nach dem Laden der Seite per Java-Script gesetzt.

dennis-eisen

Wir haben den AutoUpdater gefixt, er ist wieder voll funktionsfähig.

seetalchile

@dennis-eisen sieht sehr gut aus - herzlichen Dank!

metowa20

@dennis-eisen ebenso. TOP!
Vielen Dank, scheint zu funktionieren

fujifan

@dennis-eisen Ich habe erst jetzt Zeit gehabt, mich dieser Baustelle zu widmen - bei uns lief er auch schon ein paar Monate nicht mehr. Habe gerade die neuste Version geladen (3 Tage alt) und bekomme nun die Meldung: "No valid ChurchTools 3 download found in JSON!".
Habe ich etwas falsch gemacht?