Ich stellte fest, dass der web-updater (bzw. auf der Konsole updater/updater.phar ausführen) nicht mehr funktioniert. Sinnlose Fehlermeldung, dass „dist“ ein Verzeichnis zu viel wäre.
Bin mir nicht sicher, ob durch ständiges upgraden via der updater.phar Methode die updater.phar Datei selbst nicht aktualisiert wurde, oder warum das bei diesem Versionsupdate jetzt auftrat.
Bin bei gleichem Server Ubuntu 20.04 mit php 7.4 von 23.0.4 auf 23.0.9 und 24.0.5 und der Updater hat in allen Schritten gewohnt problemlos funktioniert.
ja, kann sein. Kann aber auch sein, dass der updater.phar bei mir aus historischen Gründen nicht akutell war. Das kannst du bei dir ja checken, welche Version der hat. (einfach rauszukriegen:
namespace NC\Updater;
class Version {
function get() {
return 'v24.0.0beta3-1-g67bf13b dirty';
}
}
Das war bei mir zum Fehlerzeitpunkt garantiert ca. v20, obwohl ich mit der NC schon längt ja bei 24.x war (kommend von… hm, ca. 12.x?)
VG, Tobias
Sprich beim ersten boot, geht erstmal gar nix. man muss dann das Datenbankpasswort nochmal in der datenbank manuell aktualisieren mit dem normalen Passwort und dann läufts wieder.
beim php update muss man den Pfad an allen möglichen ecken ändern, apache, redis, usw. aber das kann man meist gut an den Fehlermeldungen schließen wo es noch hakt.
also der oben beschriebene Postgres Fehler ist erstmal einiges schockierender… wenn man net weiss woran es liegt
bei der php Version aus dem normalen apt repository hatte ich noch ein Problem mit openssl, da gab es Fehlermeldungen im nextcloudprotokoll. das liegt daran dass auch openssl in ner anderen Version verwendet wird, als auf Ubuntu 20.04 . Auswirkungen hab ich keine so richtig gemerkt, bin aber dann trotzdem auf php 8.1.9 gegangen, wo dieser bug behoben ist
Noch nicht.
Aber mit einer anderen Maschine: Empfehlenswert ist vor dem upgrade von networkManager auf netplan zu wechseln, wenn man das nicht schon getan hat…
ja, ich habe das gestern nicht ausführen können. Ich hatte eine Maschine (meinen docker-host), die hatte zunächst nicht upgraden wollen, weil „aufs“ noch verwendet wurde statt „overlay2“ als einzig unterstütztes System unter 22.04.
Danach ging zwar das Upgrade auf 22.04 durch, aber ich hatte keinen DNS mehr. (ob das an systemd-resolve und konsorten liegt, oder an anderer Stelle, hab ich nicht untersucht) Hab mir die Quellen nicht aufgeschrieben, aber „das Internet“ sagte durchweg: Da hilft nur update auf netplan. Daher schlage ich vor, das vorher zu machen…
Mein Beispiel vorher unter /etc/network/interfaces
auto ens18
iface ens18 inet static
address 172.16.17.5
netmask 255.255.255.0
network 172.16.17.0
broadcast 172.16.17.255
gateway 172.16.17.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 10.16.1.1
dns-search linuxmuster.whatever.your.domain
Ich gebe zu, dass die Nameserver nicht identisch sind. Im „neueren“ netplan habe ich die dMZ-Adresse der Firewall als DNS eingetragen. im „älteren“ interfaces ist die server-adresse eingetragen.
hinweis: „gateway4“ in netplan ist deprecated und daher sollte man eine default route setzen
Das letzte Update auf 24.0.7 (müsste es sein), hat mir meine Instanz zerschossen, weil die ldap-Konfiguration zwar vorher lief, aber anscheinend nicht ok war. Ich habe zwei Einträge mit unterschiedlichen Benutzergruppen, die eine heißt s02, die andere sollte wohl s01 heißen, hat aber keinen Namen mehr, weil ein anderer Fehler den anscheind irgendwann entfernt hat. In der Praxis muss man dann immer auf "" arbeiten, also leerer String. Bis zum Update war das kein Problem, mit dem Update musste ich alles nach s03 migrieren und "" deaktivieren. Falls also jemand einen kryptischen SQL- Fehler bekommt, es könnte daran liegen. Leider habe ich den Fehler nicht mehr da…
Deine Konfiguration verstehe ich jetzt nicht so ganz.
Ausser man hat zwei verschiedene LDAP Server (Adressen) kann man doch alles mit einer Konfiguration s01 machen, auch verschiedene Benutzergruppen auf demselben LDAP server oder etwa nicht?
bei baseDN kann man mehrere LDAP-Kontexte eingeben.
aber wie immer sind die ldap Geschichten in Nextcloud etwas heikel. Ist da ne falsche Konfiguration drin, ist schnell der server nicht mehr erreichbar und die Konfiguration via Occasion in Kommandozeile der einzige Ausweg.
Ja, Du hast vollkommen Recht, das hätte auch mit einer Konfiguration laufen können. Aber ich habe sukzessive Benutzergruppen hinzugefügt, weil die Filter sonst zu kompliziert geworden wären. Deshalb habe ich tatsächlich zwei Konfigurationen auf dem gleichen Server. Plan ist auch, dass die zusammengelegt werden. Zu dem Zeitpunkt, wo ich das eingerichtet hatte, war ich froh, dass es überhaupt funktioniert.
eine kleine „Warnung“: wenn ihr geteilte Ordner in einem separaten Ordner unter Euren Dateien zusammenfasst (das geht über die Konfigurationsdatei mit der Variable share_folder=...), würde ich derzeit nicht auf 24.0.7 oder höher updaten!
Bei uns wurden danach die Tauschordner zwar noch angezeigt, waren aber nicht mehr aufrufbar.
Da wir im Kollegium viel mit Nextcloud machen (und gerade Konferenzen laufen, die darauf zurückfreifen), war das eine etwas unnette Überraschung.
Es gibt ein Issue dazu - insofern ggf. noch etwas warten.
eine kleine „Warnung“: wenn ihr geteilte Ordner in einem separaten
Ordner unter Euren Dateien zusammenfasst (das geht über die
Konfigurationsdatei mit der Variable |share_folder=…|), würde ich
derzeit nicht auf 24.0.7 oder höher updaten!
non-enterprise-version:
update 29.08->29.09 pdf viewer wird deaktiviert. den gibts erst ab version 29.10 wieder
update 28.09->29.09->30.02 ohne Probleme.
allerdings gibt es kein funktionierendes bbb plugin für nc30.02
