Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[e1] Migration von owncloud 10.0.4 nach nextcloud 12.0.4
6 views
Skip to first unread message
Fabian Törner
Jan 7, 2018, 3:20:15 PM1/7/18
to
Hallo zusammen,
weiß jemand von euch wie ich meine Daten von OC nach NC übertragen
bekomme - zur Not auch händisch?
Ich würde dann gern übergangsweise beide Cloudlösungen parallel laufen
lassen wollen :)
Das Migrationsscript aus dem eisfair nextcloud v1.3.2 Paket greift bei
der der OC 10.0.4 nicht.
Nun die Frage ob ich das irgendwie händisch übertragen bekomme ?!
Wenn jemand eine Idee hat - ich würde mich freuen :)
Vielen Dank & viele Grüße
Fabian
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
weiß jemand von euch wie ich meine Daten von OC nach NC übertragen
bekomme - zur Not auch händisch?
Ich würde dann gern übergangsweise beide Cloudlösungen parallel laufen
lassen wollen :)
Das Migrationsscript aus dem eisfair nextcloud v1.3.2 Paket greift bei
der der OC 10.0.4 nicht.
Nun die Frage ob ich das irgendwie händisch übertragen bekomme ?!
Wenn jemand eine Idee hat - ich würde mich freuen :)
Vielen Dank & viele Grüße
Fabian
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Marcus Roeckrath
Jan 7, 2018, 4:00:02 PM1/7/18
to
Hall Fabian,
Fabian Törner wrote:
> weiß jemand von euch wie ich meine Daten von OC nach NC übertragen
> bekomme - zur Not auch händisch?
> Ich würde dann gern übergangsweise beide Cloudlösungen parallel laufen
> lassen wollen :)
Welche Daten sollen denn migriert werden?
--
Gruss Marcus
Fabian Törner wrote:
> weiß jemand von euch wie ich meine Daten von OC nach NC übertragen
> bekomme - zur Not auch händisch?
> Ich würde dann gern übergangsweise beide Cloudlösungen parallel laufen
> lassen wollen :)
--
Gruss Marcus
Fabian Törner
Jan 7, 2018, 4:20:17 PM1/7/18
to
Hallo Marcus,
Am 07.01.2018 um 21:57 schrieb Marcus Roeckrath:
> Welche Daten sollen denn migriert werden?
ähhm - alle?!
etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
Unterbaus dann NC :)
Am 07.01.2018 um 21:57 schrieb Marcus Roeckrath:
> Welche Daten sollen denn migriert werden?
etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
Unterbaus dann NC :)
Holger Bruenjes
Jan 7, 2018, 4:36:50 PM1/7/18
to
Hallo Fabian
Am 2018-01-07 um 22:11 schrieb Fabian Törner:
> ähhm - alle?!
>
> etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
> Unterbaus dann NC :)
hmm, ohne Garantie und ohne meine Hilfe
Vielleicht so
oc Datenbank dump erstellen, im dump die Tabellenprefixe oc gegen nc
tauschen, Datenbankdump importieren
Holger
Am 2018-01-07 um 22:11 schrieb Fabian Törner:
> ähhm - alle?!
>
> etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
> Unterbaus dann NC :)
Vielleicht so
oc Datenbank dump erstellen, im dump die Tabellenprefixe oc gegen nc
tauschen, Datenbankdump importieren
Holger
Marcus Roeckrath
Jan 7, 2018, 4:50:02 PM1/7/18
to
Hallo Fabian,
Fabian Törner wrote:
>> Welche Daten sollen denn migriert werden?
>
> ähhm - alle?!
>
> etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
> Unterbaus dann NC :)
Tja, wenn es die NC-Migrationsroutine nicht schafft, wird es manuell auch
nicht wirklich gehen.
Eine Übertragen der Daten aus den OC-Tabellen in die entsprechenden
NC-Tabellen dürfte sich verbieten, denn vermutlich gibt es da keine
1:1-Beziehung.
Das dürfte sich also verbieten.
Also wird man Teilbereiche aus den entsprechenden Clientanwendungen heraus
aus OC ex- und dann wieder in NC importieren.
Zunächst also in NC wieder alle User anlegen, dürften ja eine übersichtliche
Zahl sein.
Kontakte oder Kalenderdaten würde ich z. B. mittels TB ex/importieren. Mit
dem Export aus OCs Weboberfläche habe ich schlechte Erfahrungen gemacht,
wenn von TB/Lightning angelegte Kalenderdaten enthalten sind und diese
scheinbar TB-Eigenheiten enthalten (mehrtägige Kalendereinträge mit
unterschiedlichen Kategorien für einzelne Tage).
Von Anwender abgelegte Dateien sollte man einfach von den
OC-Datenverzeichnissen in die von NC kopieren können und NC diese bei
Gelegenheit auch wieder in seine Datenbank hinterlegen. Mögliche Freigaben
für andere User gehen dabei aber verloren.
Was benutzt du noch in owncloud?
--
Gruss Marcus
Fabian Törner wrote:
>> Welche Daten sollen denn migriert werden?
>
> ähhm - alle?!
>
> etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
> Unterbaus dann NC :)
nicht wirklich gehen.
Eine Übertragen der Daten aus den OC-Tabellen in die entsprechenden
NC-Tabellen dürfte sich verbieten, denn vermutlich gibt es da keine
1:1-Beziehung.
Das dürfte sich also verbieten.
Also wird man Teilbereiche aus den entsprechenden Clientanwendungen heraus
aus OC ex- und dann wieder in NC importieren.
Zunächst also in NC wieder alle User anlegen, dürften ja eine übersichtliche
Zahl sein.
Kontakte oder Kalenderdaten würde ich z. B. mittels TB ex/importieren. Mit
dem Export aus OCs Weboberfläche habe ich schlechte Erfahrungen gemacht,
wenn von TB/Lightning angelegte Kalenderdaten enthalten sind und diese
scheinbar TB-Eigenheiten enthalten (mehrtägige Kalendereinträge mit
unterschiedlichen Kategorien für einzelne Tage).
Von Anwender abgelegte Dateien sollte man einfach von den
OC-Datenverzeichnissen in die von NC kopieren können und NC diese bei
Gelegenheit auch wieder in seine Datenbank hinterlegen. Mögliche Freigaben
für andere User gehen dabei aber verloren.
Was benutzt du noch in owncloud?
--
Gruss Marcus
Marcus Roeckrath
Jan 7, 2018, 4:50:02 PM1/7/18
to
Hallo Holger,
Holger Bruenjes wrote:
>> ähhm - alle?!
>>
>> etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
>> Unterbaus dann NC :)
>
> hmm, ohne Garantie und ohne meine Hilfe
>
> Vielleicht so
>
> oc Datenbank dump erstellen, im dump die Tabellenprefixe oc gegen nc
> tauschen, Datenbankdump importieren
Wenn die DB-Struktur 1:1 identisch wäre, könnte das auch die NC eigene
Migrationsautomatik.
Ich halte das aufgrund abweichender Tabellen-Strukturen für nicht möglich.
--
Gruss Marcus
Holger Bruenjes wrote:
>> ähhm - alle?!
>>
>> etwas genauer -> wünschenswert wäre eine 1:1 Kopie nur anstatt OC als
>> Unterbaus dann NC :)
>
> hmm, ohne Garantie und ohne meine Hilfe
>
> Vielleicht so
>
> oc Datenbank dump erstellen, im dump die Tabellenprefixe oc gegen nc
> tauschen, Datenbankdump importieren
Migrationsautomatik.
Ich halte das aufgrund abweichender Tabellen-Strukturen für nicht möglich.
--
Gruss Marcus
Fabian Törner
Jan 7, 2018, 5:30:15 PM1/7/18
to
Hallo Marcus,
Am 07.01.2018 um 22:41 schrieb Marcus Roeckrath:
> Tja, wenn es die NC-Migrationsroutine nicht schafft, wird es manuell auch
> nicht wirklich gehen.
doch es gibt Berichte, dass die das schafft.
Halt nur noch nicht alle Eventualitäten - bei meiner recht einfachen und
überschaubaren Installation nehme ich an, dass es funktionieren könnte.
Und wenn nicht, nicht schlimm habe ja ein backup und wenn sollten ja
eigentlich auch nur die Daten im NC unbrauchbar sei und nicht die von OC :)
Im Changelog des neuen NC 12.0.4 steht drin, das Daten von OC 10.0.4
nach NC 12.0.4 migriert werden können. [1] [2]
Leider wird bei NC nur beschrieben wie man OC durch NC ersetzt mit
eisfair ist ja ein parallel Betrieb möglich...
Siehe dazu auch den Beitrag von Jürgen [3].
> Eine Übertragen der Daten aus den OC-Tabellen in die entsprechenden
> NC-Tabellen dürfte sich verbieten, denn vermutlich gibt es da keine
> 1:1-Beziehung.
>
> Das dürfte sich also verbieten.
s.o. - aber wenn es so nicht geht ....
> Also wird man Teilbereiche aus den entsprechenden Clientanwendungen heraus
> aus OC ex- und dann wieder in NC importieren.
>
> Zunächst also in NC wieder alle User anlegen, dürften ja eine übersichtliche
> Zahl sein.
>
> Kontakte oder Kalenderdaten würde ich z. B. mittels TB ex/importieren. Mit
> dem Export aus OCs Weboberfläche habe ich schlechte Erfahrungen gemacht,
> wenn von TB/Lightning angelegte Kalenderdaten enthalten sind und diese
> scheinbar TB-Eigenheiten enthalten (mehrtägige Kalendereinträge mit
> unterschiedlichen Kategorien für einzelne Tage).
>
> Von Anwender abgelegte Dateien sollte man einfach von den
> OC-Datenverzeichnissen in die von NC kopieren können und NC diese bei
> Gelegenheit auch wieder in seine Datenbank hinterlegen. Mögliche Freigaben
> für andere User gehen dabei aber verloren.
... dann evtl. über den Umweg wie von Dir beschrieben.
> Was benutzt du noch in owncloud?
ich benutze eigentlich nur Kontakte/Kalender und ein paar Daten.
Aber gibt es nicht evtl. doch eine Möglichkeit der automatischen
Verarbeitung?
Bei dem händischen Umweg ist mir der Weg evtl. zu lang :(
Ich habe ja auch eine Testmaschine - dort kann eh nichts kaputt gehen.
Vielen Dank & viele Grüße
Fabian
[1] https://nextcloud.com/changelog/
[2] https://github.com/nextcloud/server/issues/7245
[3]
https://web.nettworks.org/forum/index.php?t=msg&th=8573&goto=60625&#msg_60625
Am 07.01.2018 um 22:41 schrieb Marcus Roeckrath:
> Tja, wenn es die NC-Migrationsroutine nicht schafft, wird es manuell auch
> nicht wirklich gehen.
Halt nur noch nicht alle Eventualitäten - bei meiner recht einfachen und
überschaubaren Installation nehme ich an, dass es funktionieren könnte.
Und wenn nicht, nicht schlimm habe ja ein backup und wenn sollten ja
eigentlich auch nur die Daten im NC unbrauchbar sei und nicht die von OC :)
Im Changelog des neuen NC 12.0.4 steht drin, das Daten von OC 10.0.4
nach NC 12.0.4 migriert werden können. [1] [2]
Leider wird bei NC nur beschrieben wie man OC durch NC ersetzt mit
eisfair ist ja ein parallel Betrieb möglich...
Siehe dazu auch den Beitrag von Jürgen [3].
> Eine Übertragen der Daten aus den OC-Tabellen in die entsprechenden
> NC-Tabellen dürfte sich verbieten, denn vermutlich gibt es da keine
> 1:1-Beziehung.
>
> Das dürfte sich also verbieten.
> Also wird man Teilbereiche aus den entsprechenden Clientanwendungen heraus
> aus OC ex- und dann wieder in NC importieren.
>
> Zunächst also in NC wieder alle User anlegen, dürften ja eine übersichtliche
> Zahl sein.
>
> Kontakte oder Kalenderdaten würde ich z. B. mittels TB ex/importieren. Mit
> dem Export aus OCs Weboberfläche habe ich schlechte Erfahrungen gemacht,
> wenn von TB/Lightning angelegte Kalenderdaten enthalten sind und diese
> scheinbar TB-Eigenheiten enthalten (mehrtägige Kalendereinträge mit
> unterschiedlichen Kategorien für einzelne Tage).
>
> Von Anwender abgelegte Dateien sollte man einfach von den
> OC-Datenverzeichnissen in die von NC kopieren können und NC diese bei
> Gelegenheit auch wieder in seine Datenbank hinterlegen. Mögliche Freigaben
> für andere User gehen dabei aber verloren.
> Was benutzt du noch in owncloud?
Aber gibt es nicht evtl. doch eine Möglichkeit der automatischen
Verarbeitung?
Bei dem händischen Umweg ist mir der Weg evtl. zu lang :(
Ich habe ja auch eine Testmaschine - dort kann eh nichts kaputt gehen.
Vielen Dank & viele Grüße
Fabian
[2] https://github.com/nextcloud/server/issues/7245
[3]
https://web.nettworks.org/forum/index.php?t=msg&th=8573&goto=60625&#msg_60625
Marcus Roeckrath
Jan 8, 2018, 4:30:02 AM1/8/18
to
Hallo Fabian,
Fabian Törner wrote:
Fabian Törner wrote:
> Aber gibt es nicht evtl. doch eine Möglichkeit der automatischen
> Verarbeitung?
>
> Verarbeitung?
>
> Ich habe ja auch eine Testmaschine - dort kann eh nichts kaputt gehen.
Mit der Testmaschine sollte es doch gehen:
Onwcloud in gleicher Version wie auf der Produktivkiste installieren.
Owncloud-Daten per Datenbankbackup von der Produktivkiste auf den Testserver
übertragen (owncloud vorher stoppen).
Migration wie von Nextcloud vorgesehen unter Ersetzung von OC durch NC
vornehmen.
NC-Paket auf Produktivsystem installieren, NC stoppen; Backup der NC
Datenbackup auf Testssystem erstellen und auf Produktivsystem einspielen;
NC starten.
--
Gruss Marcus
Taxena Gasparov
Jun 3, 2019, 4:04:49 AM6/3/19
to
Hallo,
Am 08.01.18 um 10:21 schrieb Marcus Roeckrath:
ab dann Parallelbetrieb (falls technisch überhaupt möglich) oder nur noch nextcloud).
Geht dies per eisman-Update irgendwie oder nach der offiziellen Anleitung [1] oder weder noch?
*) alle Dateien, Kalender, Adressbuch, Einstellungen, Freigaben, Einstellungen der oc-Nutzer sollen erhalten
bleiben.
Dank
Taxi
Am 08.01.18 um 10:21 schrieb Marcus Roeckrath:
>> Ich habe ja auch eine Testmaschine - dort kann eh nichts kaputt gehen.
> Mit der Testmaschine sollte es doch gehen:
ohne Testmaschine, aber mit Backup, würde ich gerne von owncloud 1.7.1 nach nextcloud migrieren* (entweder
> Mit der Testmaschine sollte es doch gehen:
ab dann Parallelbetrieb (falls technisch überhaupt möglich) oder nur noch nextcloud).
Geht dies per eisman-Update irgendwie oder nach der offiziellen Anleitung [1] oder weder noch?
*) alle Dateien, Kalender, Adressbuch, Einstellungen, Freigaben, Einstellungen der oc-Nutzer sollen erhalten
bleiben.
Dank
Taxi
Juergen Edner
Jun 3, 2019, 6:58:49 AM6/3/19
to
Hallo Taxi,
> ohne Testmaschine, aber mit Backup, würde ich gerne von owncloud 1.7.1 nach nextcloud migrieren* (entweder
> ab dann Parallelbetrieb (falls technisch überhaupt möglich) oder nur noch nextcloud).
> Geht dies per eisman-Update irgendwie oder nach der offiziellen Anleitung [1] oder weder noch?
>
> *) alle Dateien, Kalender, Adressbuch, Einstellungen, Freigaben, Einstellungen der oc-Nutzer sollen erhalten
> bleiben.
generell kann man Nextcloud parallel zu OwnCloud installieren
und betreiben, da separate Datenbanken verwendet werden.
Ich selbst habe jedoch die letzte Migration mit einer Owncloud-
Paketversion 1.6.4 getestet und biete deshalb keine automatische
Dateiübernahme bei der Paketinstallation an.
Generell würde ich folgende Vorgehensweise testen:
1. Nextcloud parallel zu Owncloud installieren und dabei möglichst
den selben Datenbank-Account verwenden.
2. Über den Webbrowser sicher stellen, dass ein Nextcloud-Zugriff
möglich ist.
3. Owncloud-Datenbank exportieren:
/var/install/config.d/owncloud.sh --maintenance-on
/var/install/config.d/owncloud.sh dump-sql-db /tmp/owncloud-db-dump.sql
4. Nextcloud-Datenbank mit Owncloud-Daten überschreiben und die
Datenbanktabellen umschreiben:
/var/install/config.d/nextcloud.sh restore-sql-db
/tmp/owncloud-db-dump.sql
/var/install/config.d/nextcloud.sh rename-sql-db-tables
Prinzipiell sollte dann wieder eine Anmeldung in Nextcloud möglich
sein.
Gruß Jürgen
--
Mail: jue...@eisfair.org
> ohne Testmaschine, aber mit Backup, würde ich gerne von owncloud 1.7.1 nach nextcloud migrieren* (entweder
> ab dann Parallelbetrieb (falls technisch überhaupt möglich) oder nur noch nextcloud).
> Geht dies per eisman-Update irgendwie oder nach der offiziellen Anleitung [1] oder weder noch?
>
> *) alle Dateien, Kalender, Adressbuch, Einstellungen, Freigaben, Einstellungen der oc-Nutzer sollen erhalten
> bleiben.
und betreiben, da separate Datenbanken verwendet werden.
Ich selbst habe jedoch die letzte Migration mit einer Owncloud-
Paketversion 1.6.4 getestet und biete deshalb keine automatische
Dateiübernahme bei der Paketinstallation an.
Generell würde ich folgende Vorgehensweise testen:
1. Nextcloud parallel zu Owncloud installieren und dabei möglichst
den selben Datenbank-Account verwenden.
2. Über den Webbrowser sicher stellen, dass ein Nextcloud-Zugriff
möglich ist.
3. Owncloud-Datenbank exportieren:
/var/install/config.d/owncloud.sh --maintenance-on
/var/install/config.d/owncloud.sh dump-sql-db /tmp/owncloud-db-dump.sql
4. Nextcloud-Datenbank mit Owncloud-Daten überschreiben und die
Datenbanktabellen umschreiben:
/var/install/config.d/nextcloud.sh restore-sql-db
/tmp/owncloud-db-dump.sql
/var/install/config.d/nextcloud.sh rename-sql-db-tables
Prinzipiell sollte dann wieder eine Anmeldung in Nextcloud möglich
sein.
Gruß Jürgen
--
Mail: jue...@eisfair.org
Marcus Roeckrath
Jun 3, 2019, 11:30:01 AM6/3/19
to
Hallo Taxena,
Taxena Gasparov wrote:
>>> Ich habe ja auch eine Testmaschine - dort kann eh nichts kaputt gehen.
>> Mit der Testmaschine sollte es doch gehen:
>
> ohne Testmaschine, aber mit Backup, würde ich gerne von owncloud 1.7.1
> nach nextcloud migrieren* (entweder ab dann Parallelbetrieb (falls
> technisch überhaupt möglich) oder nur noch nextcloud). Geht dies per
> eisman-Update irgendwie oder nach der offiziellen Anleitung [1] oder weder
> noch?
Laut Aussage von Jügen lassen sich owncloud und nextcloud durchaus parallel
betreiben.
> *) alle Dateien, Kalender, Adressbuch, Einstellungen, Freigaben,
> Einstellungen der oc-Nutzer sollen erhalten bleiben.
Du musst schon selbst die Daten usw. übertragen, IMHO wird da nichts
automatisch aus der jeweils andeen Cloud übernommen oder die DB parallel
von beiden benutzt, was IMHO garnicht geht, denn owncloud und nextcloud
haben sich inzwischen soweit voeinander entfernt, dass ich da auch
Unterschiede in der Datenbankstruktur erwarte.
--
Gruss Marcus
Taxena Gasparov wrote:
>>> Ich habe ja auch eine Testmaschine - dort kann eh nichts kaputt gehen.
>> Mit der Testmaschine sollte es doch gehen:
>
> ohne Testmaschine, aber mit Backup, würde ich gerne von owncloud 1.7.1
> nach nextcloud migrieren* (entweder ab dann Parallelbetrieb (falls
> technisch überhaupt möglich) oder nur noch nextcloud). Geht dies per
> eisman-Update irgendwie oder nach der offiziellen Anleitung [1] oder weder
> noch?
betreiben.
> *) alle Dateien, Kalender, Adressbuch, Einstellungen, Freigaben,
> Einstellungen der oc-Nutzer sollen erhalten bleiben.
automatisch aus der jeweils andeen Cloud übernommen oder die DB parallel
von beiden benutzt, was IMHO garnicht geht, denn owncloud und nextcloud
haben sich inzwischen soweit voeinander entfernt, dass ich da auch
Unterschiede in der Datenbankstruktur erwarte.
--
Gruss Marcus
Taxena Gasparov
Jun 5, 2019, 3:53:12 AM6/5/19
to
Hallo Jürgen,
Am 03.06.19 um 12:58 schrieb Juergen Edner:
nextcloud ist dieser sodann auch vorhanden. :-) Aber mit separaten DBs wohl eher nicht. :-)
> Generell würde ich folgende Vorgehensweise testen:
>
> 1. Nextcloud parallel zu Owncloud installieren und dabei möglichst
> den selben Datenbank-Account verwenden.
habe in der Konfiguration die Anpassungen (trusteddomain, DB,...) gemacht, aber bei Übernahme kommt Warnung:
> Warning: OWNCLOUD_APPS_1_DIR='/var/www/htdocs/nextcloud/apps2' has apps settings been set although the directory does not exist!
Die Prüfung ergab, nicht nur /var/www/htdocs/nextcloud/apps2 gibt es nicht, sondern auch kein
/var/www/htdocs/nextcloud
Installations-Loganzeige:
> Downloading required packages ...
> Done!
> Installation of: nextcloud (1.7.1) ...
> An installed Owncloud package was found, but data cannot be migrated
> to Nextcloud, because the installed package version is too new and a
> database downgrade is not supported.
> Press ENTER to continue
> loading initial configuration file ...
> modifying parameter(s) ...
> - OWNCLOUD_TRUSTED_DOMAIN, '' -> 'domainnamme.dyndns.dd'
> ... read documentation for modified parameter(s)!
> Remember that START_OWNCLOUD='no' has currently been set!
> Press ENTER to continue
> * Restarting Apache ... [ OK ]
> Successfully installed: nextcloud (1.7.1)!
> Press ENTER to continue
/var/nextcloud existiert, wieso /var/www/htdocs/nextcloud nicht? /var/www/htdocs/owncloud scheint nicht
überschrieben worden zu sein mit den nextcloud-Daten.
Dank
Taxi
Am 03.06.19 um 12:58 schrieb Juergen Edner:
> generell kann man Nextcloud parallel zu OwnCloud installieren
> und betreiben, da separate Datenbanken verwendet werden.
ok, ich hatte damit "harten" Parallelbetrieb gemeint, also ich trage einen Termin in owncloud ein, in
> und betreiben, da separate Datenbanken verwendet werden.
nextcloud ist dieser sodann auch vorhanden. :-) Aber mit separaten DBs wohl eher nicht. :-)
> Generell würde ich folgende Vorgehensweise testen:
>
> 1. Nextcloud parallel zu Owncloud installieren und dabei möglichst
> den selben Datenbank-Account verwenden.
> Warning: OWNCLOUD_APPS_1_DIR='/var/www/htdocs/nextcloud/apps2' has apps settings been set although the directory does not exist!
Die Prüfung ergab, nicht nur /var/www/htdocs/nextcloud/apps2 gibt es nicht, sondern auch kein
/var/www/htdocs/nextcloud
Installations-Loganzeige:
> Downloading required packages ...
> Done!
> Installation of: nextcloud (1.7.1) ...
> An installed Owncloud package was found, but data cannot be migrated
> to Nextcloud, because the installed package version is too new and a
> database downgrade is not supported.
> Press ENTER to continue
> loading initial configuration file ...
> modifying parameter(s) ...
> - OWNCLOUD_TRUSTED_DOMAIN, '' -> 'domainnamme.dyndns.dd'
> ... read documentation for modified parameter(s)!
> Remember that START_OWNCLOUD='no' has currently been set!
> Press ENTER to continue
> * Restarting Apache ... [ OK ]
> Successfully installed: nextcloud (1.7.1)!
> Press ENTER to continue
/var/nextcloud existiert, wieso /var/www/htdocs/nextcloud nicht? /var/www/htdocs/owncloud scheint nicht
überschrieben worden zu sein mit den nextcloud-Daten.
Dank
Taxi
Juergen Edner
Jun 5, 2019, 3:59:30 AM6/5/19
to
Hallo Taxi,
> Installations-Loganzeige:
da die Pakete aus historischer Sicht die gleichen Wurzeln haben.
Der Grund für die nicht entpackten Daten geht aus den Meldungen
eindeutig hervor, siehe oben ;-)
> Installations-Loganzeige:
...
>> modifying parameter(s) ...
>> - OWNCLOUD_TRUSTED_DOMAIN, '' -> 'domainnamme.dyndns.dd'
>> ... read documentation for modified parameter(s)!
>> Remember that START_OWNCLOUD='no' has currently been set!
^^^^^^^^^^^^^^^^^^^
>> modifying parameter(s) ...
>> - OWNCLOUD_TRUSTED_DOMAIN, '' -> 'domainnamme.dyndns.dd'
>> ... read documentation for modified parameter(s)!
>> Remember that START_OWNCLOUD='no' has currently been set!
>> Press ENTER to continue
>> * Restarting Apache ... [ OK ]
>> Successfully installed: nextcloud (1.7.1)!
>> Press ENTER to continue
>
> /var/nextcloud existiert, wieso /var/www/htdocs/nextcloud nicht? /var/www/htdocs/owncloud scheint nicht
> überschrieben worden zu sein mit den nextcloud-Daten.
Die Parameter im Nextcloud-Paket beginnen ebenfalls mit "OWNCLOUD",
>> * Restarting Apache ... [ OK ]
>> Successfully installed: nextcloud (1.7.1)!
>> Press ENTER to continue
>
> /var/nextcloud existiert, wieso /var/www/htdocs/nextcloud nicht? /var/www/htdocs/owncloud scheint nicht
> überschrieben worden zu sein mit den nextcloud-Daten.
da die Pakete aus historischer Sicht die gleichen Wurzeln haben.
Der Grund für die nicht entpackten Daten geht aus den Meldungen
eindeutig hervor, siehe oben ;-)
Taxena Gasparov
Jun 5, 2019, 4:19:19 AM6/5/19
to
Hallo Jürgen,
Am 05.06.19 um 09:59 schrieb Juergen Edner:
/var/www/htdocs/nextcloud womöglich erzeugt.
Gerade bei meinem Versuch den nextcloud-Parameter START_OWNCLOUD auf 'yes' zu setzen, müsste ich bei der
Übernahme der Konfiguration per Ignorierung der Warnung dies tun oder soll ich, damit die Warnung evtl.
nicht kommt, den nextcloud-Parameter OWNCLOUD_APPS_1_DIR='/var/www/htdocs/owncloud/apps2' setzen?
Dank
Taxi
Am 05.06.19 um 09:59 schrieb Juergen Edner:
> Die Parameter im Nextcloud-Paket beginnen ebenfalls mit "OWNCLOUD", da die Pakete aus historischer Sicht
> die gleichen Wurzeln haben. Der Grund für die nicht entpackten Daten geht aus den Meldungen eindeutig
> hervor, siehe oben ;-)
eindeutig finde ich es in dieser Konstellation nicht, falls du die Meldung:
> die gleichen Wurzeln haben. Der Grund für die nicht entpackten Daten geht aus den Meldungen eindeutig
> hervor, siehe oben ;-)
> Remember that START_OWNCLOUD='no' has currently been set!
meinst und du andeuten willst, dass ein START_OWNCLOUD='yes' den Ordner und die Dateien in
/var/www/htdocs/nextcloud womöglich erzeugt.
Gerade bei meinem Versuch den nextcloud-Parameter START_OWNCLOUD auf 'yes' zu setzen, müsste ich bei der
Übernahme der Konfiguration per Ignorierung der Warnung dies tun oder soll ich, damit die Warnung evtl.
nicht kommt, den nextcloud-Parameter OWNCLOUD_APPS_1_DIR='/var/www/htdocs/owncloud/apps2' setzen?
Dank
Taxi
Juergen Edner
Jun 5, 2019, 5:11:04 AM6/5/19
to
Hallo Taxi,
> eindeutig finde ich es in dieser Konstellation nicht, falls du die Meldung:
>> Remember that START_OWNCLOUD='no' has currently been set!
> meinst und du andeuten willst, dass ein START_OWNCLOUD='yes' den Ordner und die Dateien in
> /var/www/htdocs/nextcloud womöglich erzeugt.
genau so sieht es aus. Nur wenn START_OWNCLOUD='yes' gesetzt wird,
greifen die erforderlichen Funktionen, Ordner werden angelegt und
Dateien extrahiert.
> Gerade bei meinem Versuch den nextcloud-Parameter START_OWNCLOUD auf 'yes' zu setzen, müsste ich bei der
> Übernahme der Konfiguration per Ignorierung der Warnung dies tun oder soll ich, damit die Warnung evtl.
> nicht kommt, den nextcloud-Parameter OWNCLOUD_APPS_1_DIR='/var/www/htdocs/owncloud/apps2' setzen?
Die angesprochene Meldung sollte an dieser Stelle eigentlich nicht
erscheinen und ich habe schon verschiedene Tests implementiert um
sie zu verhindern. Jedoch ist es nicht immer einfach eine bestimmte
Situation nachzuvollziehen.
> eindeutig finde ich es in dieser Konstellation nicht, falls du die Meldung:
>> Remember that START_OWNCLOUD='no' has currently been set!
> meinst und du andeuten willst, dass ein START_OWNCLOUD='yes' den Ordner und die Dateien in
> /var/www/htdocs/nextcloud womöglich erzeugt.
greifen die erforderlichen Funktionen, Ordner werden angelegt und
Dateien extrahiert.
> Gerade bei meinem Versuch den nextcloud-Parameter START_OWNCLOUD auf 'yes' zu setzen, müsste ich bei der
> Übernahme der Konfiguration per Ignorierung der Warnung dies tun oder soll ich, damit die Warnung evtl.
> nicht kommt, den nextcloud-Parameter OWNCLOUD_APPS_1_DIR='/var/www/htdocs/owncloud/apps2' setzen?
erscheinen und ich habe schon verschiedene Tests implementiert um
sie zu verhindern. Jedoch ist es nicht immer einfach eine bestimmte
Situation nachzuvollziehen.
Taxena Gasparov
Jun 5, 2019, 5:56:31 AM6/5/19
to
Hallo Jürgen,
auch bei Ignorierung der Warnung geht's nicht viel weiter:
> Checking configuration file ...
>
> Warning: OWNCLOUD_APPS_1_DIR='/var/www/htdocs/nextcloud/apps2' has
>
> Activate configuration now (y/n) [yes]?
> nextcloud version (eisfair-1): v1.7.1
> Database type : mysql (mariadb55)
> Database server: localhost:3306
> Trusted domain(s): www.domainnamme.dyndns.dd
> Apache2 SSL support: enabled
> MySQL PHP7 support: enabled
> MySQL support: enabled
> MySQL binary logging: disabled
> Mail support: enabled
> PHP7-WEB Redis cache: enabled
> PHP7-CLI Redis cache: enabled
> Redis support: enabled
> PHP7-WEB memory limit: < 512M, check parameter PHP7_MEMORY_LIMIT!
> PHP7-CLI memory limit: < 512M, check parameter PHP7CLI_MEMORY_LIMIT!
> PHP7-CLI configuration access: possible
> /var/install/config.d/nextcloud.sh: Zeile 5816: /var/www/htdocs/nextcloud/.TyE2OiB.gtWG04c.php: Datei oder Verzeichnis nicht gefunden
> PHP7-WEB module test failure, make sure that the web server is running!
> PHP7-WEB IMAGICK module: enabled, but not loaded!
> PHP7-WEB INTL module: enabled, but not loaded!
> PHP7-WEB OPCACHE module: enabled, but not loaded!
> PHP7-WEB PCNTL module: enabled, but not loaded!
> PHP pre-requisites not met, fix it and re-run configuration!
> Press ENTER to continue
auch erneuter Konfigdurchlauf endete identisch.
Taxi
auch bei Ignorierung der Warnung geht's nicht viel weiter:
> Checking configuration file ...
>
> Warning: OWNCLOUD_APPS_1_DIR='/var/www/htdocs/nextcloud/apps2' has
> been set although the directory does not exist!
> Configuration file was saved as nextcloud.2019-06-05-11-43-46 in /etc/backup.d.
>
> Activate configuration now (y/n) [yes]?
> nextcloud version (eisfair-1): v1.7.1
> Database type : mysql (mariadb55)
> Database server: localhost:3306
> Trusted domain(s): www.domainnamme.dyndns.dd
> Apache2 SSL support: enabled
> MySQL PHP7 support: enabled
> MySQL support: enabled
> MySQL binary logging: disabled
> Mail support: enabled
> PHP7-WEB Redis cache: enabled
> PHP7-CLI Redis cache: enabled
> Redis support: enabled
> PHP7-WEB memory limit: < 512M, check parameter PHP7_MEMORY_LIMIT!
> PHP7-CLI memory limit: < 512M, check parameter PHP7CLI_MEMORY_LIMIT!
> PHP7-CLI configuration access: possible
> /var/install/config.d/nextcloud.sh: Zeile 5816: /var/www/htdocs/nextcloud/.TyE2OiB.gtWG04c.php: Datei oder Verzeichnis nicht gefunden
> PHP7-WEB module test failure, make sure that the web server is running!
> PHP7-WEB IMAGICK module: enabled, but not loaded!
> PHP7-WEB INTL module: enabled, but not loaded!
> PHP7-WEB OPCACHE module: enabled, but not loaded!
> PHP7-WEB PCNTL module: enabled, but not loaded!
> PHP pre-requisites not met, fix it and re-run configuration!
> Press ENTER to continue
auch erneuter Konfigdurchlauf endete identisch.
Taxi
Marcus Roeckrath
Jun 5, 2019, 10:43:43 AM6/5/19
to
Hallo Taxena,
Gasparov Taxena schrieb am Wed, 05 June 2019 11:56
Zitat:
Eine owncloud-Konfiguration läuft sauber durch? Kann ich mir bei
vergleichbar aktueller owncloud-Version nicht vorstellen.
--
Gruß Marcus
Gasparov Taxena schrieb am Wed, 05 June 2019 11:56
> Hallo Jürgen,
>
> auch bei Ignorierung der Warnung geht's nicht viel weiter:
>
> auch bei Ignorierung der Warnung geht's nicht viel weiter:
> > PHP7-WEB memory limit: < 512M, check parameter
> > PHP7_MEMORY_LIMIT!
> > PHP7-CLI memory limit: < 512M, check parameter
> > PHP7CLI_MEMORY_LIMIT!
Du musst das memorylimit in php7 hochsetzen.
> > PHP7_MEMORY_LIMIT!
> > PHP7-CLI memory limit: < 512M, check parameter
> > PHP7CLI_MEMORY_LIMIT!
Zitat:
> > PHP7-WEB IMAGICK module: enabled, but not loaded!
> > PHP7-WEB INTL module: enabled, but not loaded!
> > PHP7-WEB OPCACHE module: enabled, but not loaded!
> > PHP7-WEB PCNTL module: enabled, but not loaded!
Such mal im Forum, da hatten wir diese Fehlermeldungen IMHO schon.
> > PHP7-WEB INTL module: enabled, but not loaded!
> > PHP7-WEB OPCACHE module: enabled, but not loaded!
> > PHP7-WEB PCNTL module: enabled, but not loaded!
Eine owncloud-Konfiguration läuft sauber durch? Kann ich mir bei
vergleichbar aktueller owncloud-Version nicht vorstellen.
--
Gruß Marcus
Taxena Gasparov
Jun 5, 2019, 11:57:06 AM6/5/19
to
Hallo Marcus,
Am 05.06.19 um 16:43 schrieb Marcus Roeckrath:
owncloud Konfiguration läuft durch, es sind die aktuellsten Versionen, nc und oc 1.7.1:
> Checking configuration file ...
> PHP7-CLI memory limit: >= 512M
> PHP7-CLI configuration access: possible
> creating logrotate configuration ...
> creating cron script ...
> setting access rights of '/var/www/htdocs/owncloud' ...
> wait [ .. ]
> setting access rights of '/var/owncloud' ...
> wait [ . ]
> checking owncloud install/upgrade requirements ...
> checking 4-byte database settings ...
> - default character set : utf8 (-> utf8mb4)
> - default collation name: utf8_general_ci (-> utf8mb4_general_ci)
> - InnoDB large prefix : off (-> on)
> - InnoDB file format : antelope (-> barracuda)
> - InnoDB file per table: off (-> on)
> creating owncloud configuration ...
> creating cron job ...
> owncloud maintenance mode: disabled
> checking owncloud install/upgrade requirements ...
> finished.
> Do you want to restart the webserver now (recommended) (y/n) [yes]?
Im Gegensatz dazu ist bei nextcloud die erste ausbleibende Zeile "creating logrotate configuration ...",
womöglich weil angeblich die php-Datei /var/www/htdocs/nextcloud/MJwcE3hfjtqjOV.S.php nicht vorhanden ist.
Soll ich den nextcloud-Ordner /var/www/htdocs/nextcloud/ manuell erstellen?
Dank
Taxi
Am 05.06.19 um 16:43 schrieb Marcus Roeckrath:
> Du musst das memorylimit in php7 hochsetzen.
> ...
> Such mal im Forum, da hatten wir diese Fehlermeldungen IMHO schon.
>
> Eine owncloud-Konfiguration läuft sauber durch? Kann ich mir bei
> vergleichbar aktueller owncloud-Version nicht vorstellen.
die Limits waren auf jeweils 256M, Änderung auf 512M hat Problem nicht beseitigt.
>
> Eine owncloud-Konfiguration läuft sauber durch? Kann ich mir bei
> vergleichbar aktueller owncloud-Version nicht vorstellen.
owncloud Konfiguration läuft durch, es sind die aktuellsten Versionen, nc und oc 1.7.1:
> Checking configuration file ...
>
> Activate configuration now (y/n) [yes]?
> owncloud version (eisfair-1): v1.7.1
> Activate configuration now (y/n) [yes]?
> Database type : mysql (mariadb55)
> Database server: localhost:3306
> Trusted domain(s): www.domainnamme.dyndns.dd
> Apache2 SSL support: enabled
> MySQL PHP7 support: enabled
> MySQL support: enabled
> MySQL binary logging: disabled
> Mail support: enabled
> PHP7-WEB Redis cache: enabled
> PHP7-CLI Redis cache: enabled
> Redis support: enabled
> PHP7-WEB memory limit: >= 512M
> Database server: localhost:3306
> Trusted domain(s): www.domainnamme.dyndns.dd
> Apache2 SSL support: enabled
> MySQL PHP7 support: enabled
> MySQL support: enabled
> MySQL binary logging: disabled
> Mail support: enabled
> PHP7-WEB Redis cache: enabled
> PHP7-CLI Redis cache: enabled
> Redis support: enabled
> PHP7-CLI memory limit: >= 512M
> PHP7-CLI configuration access: possible
> creating logrotate configuration ...
> creating cron script ...
> setting access rights of '/var/www/htdocs/owncloud' ...
> wait [ .. ]
> setting access rights of '/var/owncloud' ...
> wait [ . ]
> checking owncloud install/upgrade requirements ...
> checking 4-byte database settings ...
> - default character set : utf8 (-> utf8mb4)
> - default collation name: utf8_general_ci (-> utf8mb4_general_ci)
> - InnoDB large prefix : off (-> on)
> - InnoDB file format : antelope (-> barracuda)
> - InnoDB file per table: off (-> on)
> creating owncloud configuration ...
> creating cron job ...
> owncloud maintenance mode: disabled
> checking owncloud install/upgrade requirements ...
> finished.
> Do you want to restart the webserver now (recommended) (y/n) [yes]?
Im Gegensatz dazu ist bei nextcloud die erste ausbleibende Zeile "creating logrotate configuration ...",
womöglich weil angeblich die php-Datei /var/www/htdocs/nextcloud/MJwcE3hfjtqjOV.S.php nicht vorhanden ist.
Soll ich den nextcloud-Ordner /var/www/htdocs/nextcloud/ manuell erstellen?
Dank
Taxi
Juergen Edner
Jun 5, 2019, 12:21:19 PM6/5/19
to
Hallo Taxi,
> die Limits waren auf jeweils 256M, Änderung auf 512M hat Problem nicht beseitigt.
ich habe schon zig Installationen durchgeführt und noch nie das von Dir
beschriebene Problem festgestellt. Willst Du die Software parallel zur
existierenden ownCloud-Software installieren oder hast Du eine virtuelle
Maschine etc. konfiguriert?
>> Activate configuration now (y/n) [yes]?
>> owncloud version (eisfair-1): v1.7.1
>> Database type : mysql (mariadb55)
Nur nebenbei erwähnt, Du solltest irgendwann auch einmal MariaDB auf
eine aktuelle Version umstellen ;-)
> Im Gegensatz dazu ist bei nextcloud die erste ausbleibende Zeile "creating logrotate configuration ...",
> womöglich weil angeblich die php-Datei /var/www/htdocs/nextcloud/MJwcE3hfjtqjOV.S.php nicht vorhanden ist.
Es bringt nichts den Versuch zu starten manuell einzugreifen, wenn die
Umgebung noch nicht korrekt konfiguriert ist. Die angesprochene Datei
wird dynamisch erzeugt um zu prüfen, ob die PHP-Webmodule korrekt
geladen wurden. Die Datei wird wieder gelöscht sobald der Test
abgeschlossen ist.
> Soll ich den nextcloud-Ordner /var/www/htdocs/nextcloud/ manuell erstellen?
Nein. Gibt es eine Möglichkeit einmal remote auf Deinen Server zu
schauen, mittels Teamviewer etc.? Falls ja, schicke mir die Details
einmal per PM zu. Ich hätte gerade einmal etwas Zeit ;-)
Die Installation des Paketes sollte bei einem korrekt konfigurierten
Webserver normalerweise kein Problem sein.
> die Limits waren auf jeweils 256M, Änderung auf 512M hat Problem nicht beseitigt.
beschriebene Problem festgestellt. Willst Du die Software parallel zur
existierenden ownCloud-Software installieren oder hast Du eine virtuelle
Maschine etc. konfiguriert?
>> Activate configuration now (y/n) [yes]?
>> owncloud version (eisfair-1): v1.7.1
>> Database type : mysql (mariadb55)
eine aktuelle Version umstellen ;-)
> Im Gegensatz dazu ist bei nextcloud die erste ausbleibende Zeile "creating logrotate configuration ...",
> womöglich weil angeblich die php-Datei /var/www/htdocs/nextcloud/MJwcE3hfjtqjOV.S.php nicht vorhanden ist.
Umgebung noch nicht korrekt konfiguriert ist. Die angesprochene Datei
wird dynamisch erzeugt um zu prüfen, ob die PHP-Webmodule korrekt
geladen wurden. Die Datei wird wieder gelöscht sobald der Test
abgeschlossen ist.
> Soll ich den nextcloud-Ordner /var/www/htdocs/nextcloud/ manuell erstellen?
schauen, mittels Teamviewer etc.? Falls ja, schicke mir die Details
einmal per PM zu. Ich hätte gerade einmal etwas Zeit ;-)
Die Installation des Paketes sollte bei einem korrekt konfigurierten
Webserver normalerweise kein Problem sein.
Marcus Roeckrath
Jun 5, 2019, 12:49:26 PM6/5/19
to
Hallo Taxena,
Gasparov Taxena schrieb am Wed, 05 June 2019 17:57
nextcloud-Konfiguration erneut posten.
--
Gruß Marcus
Gasparov Taxena schrieb am Wed, 05 June 2019 17:57
> Im Gegensatz dazu ist bei nextcloud die erste ausbleibende Zeile
> "creating logrotate configuration ...",
> womöglich weil angeblich die php-Datei
> /var/www/htdocs/nextcloud/MJwcE3hfjtqjOV.S.php nicht vorhanden ist.
Kannst du bitte nach Korrektur der MemoryLimits die Meldungen aus der
> "creating logrotate configuration ...",
> womöglich weil angeblich die php-Datei
> /var/www/htdocs/nextcloud/MJwcE3hfjtqjOV.S.php nicht vorhanden ist.
nextcloud-Konfiguration erneut posten.
--
Gruß Marcus
Marcus Roeckrath
Jun 5, 2019, 2:08:38 PM6/5/19
to
Marcus Roeckrath schrieb am Wed, 05 June 2019 18:49
Du kannst auch mal im Skript /var/install/config.d/nextcloud.sh in der
Zeile 215 das # wegnehmen und dadurch den Debug-Output aktivieren, denn
du nach Aufruf der Konfiguration als /tmp/nextcloud-.....log findest und
dann (je nach Länge) hier postest oder Jürgen und mir per PM
zusendest.
--
Gruß Marcus
Zeile 215 das # wegnehmen und dadurch den Debug-Output aktivieren, denn
du nach Aufruf der Konfiguration als /tmp/nextcloud-.....log findest und
dann (je nach Länge) hier postest oder Jürgen und mir per PM
zusendest.
--
Gruß Marcus
Taxena Gasparov
Jun 5, 2019, 6:54:50 PM6/5/19
to
Hallo Jürgen,
Am 05.06.19 um 18:21 schrieb Juergen Edner:
> Gibt es eine Möglichkeit einmal remote auf Deinen Server zu
> schauen, mittels Teamviewer etc.?
nein, derzeit nicht.
Habe die nextcloud-Installation deinstalliert, dabei wurde der owncloud-user gelöscht und jetzt ist owncloud
nicht mehr funktional:
> Exception occurred while logging exception: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [1045] Benutzer 'owncloud'@'localhost' hat keine Zugriffsberechtigung (verwendetes Passwort: Ja)
> #0 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
> #1 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
> #2 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
> #3 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform()
> #4 /var/www/htdocs/owncloud/lib/private/DB/Connection.php(144): Doctrine\DBAL\Connection->setTransactionIsolation(2)
> #5 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
> #6 /var/www/htdocs/owncloud/lib/private/DB/ConnectionFactory.php(145): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
> #7 /var/www/htdocs/owncloud/lib/private/Server.php(530): OC\DB\ConnectionFactory->getConnection('mysql', Array)
> #8 /var/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
> #9 /var/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(108): Pimple\Container->offsetGet('DatabaseConnect...')
> #10 /var/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\AppFramework\Utility\SimpleContainer->query('DatabaseConnect...')
> #11 /var/www/htdocs/owncloud/lib/private/Server.php(1215): OC\ServerContainer->query('DatabaseConnect...')
> #12 /var/www/htdocs/owncloud/lib/private/Server.php(405): OC\Server->getDatabaseConnection()
> #13 /var/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
> #14 /var/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(108): Pimple\Container->offsetGet('AppConfig')
> #15 /var/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\AppFramework\Utility\SimpleContainer->query('AppConfig')
> #16 /var/www/htdocs/owncloud/lib/private/Server.php(1145): OC\ServerContainer->query('AppConfig')
> #17 /var/www/htdocs/owncloud/lib/private/Server.php(585): OC\Server->getAppConfig()
> #18 /var/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
> #19 /var/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(108): Pimple\Container->offsetGet('AppManager')
> #20 /var/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\AppFramework\Utility\SimpleContainer->query('AppManager')
> #21 /var/www/htdocs/owncloud/lib/private/Server.php(1413): OC\ServerContainer->query('AppManager')
> #22 /var/www/htdocs/owncloud/lib/private/legacy/app.php(346): OC\Server->getAppManager()
> #23 /var/www/htdocs/owncloud/lib/private/legacy/app.php(110): OC_App::getEnabledApps()
> #24 /var/www/htdocs/owncloud/lib/base.php(577): OC_App::loadApps(Array)
> #25 /var/www/htdocs/owncloud/lib/base.php(994): OC::init()
> #26 /var/www/htdocs/owncloud/index.php(53): require_once('/var/www/htdocs...')
> #27 {main}
Gibt es eine einfache Routine, das zu beheben oder nur das Backup einzuspielen?
Dank
Taxi
Am 05.06.19 um 18:21 schrieb Juergen Edner:
> Willst Du die Software parallel zur
> existierenden ownCloud-Software installieren oder hast Du eine virtuelle
> Maschine etc. konfiguriert?
parallel, nix virtuell.
> existierenden ownCloud-Software installieren oder hast Du eine virtuelle
> Maschine etc. konfiguriert?
> Gibt es eine Möglichkeit einmal remote auf Deinen Server zu
> schauen, mittels Teamviewer etc.?
Habe die nextcloud-Installation deinstalliert, dabei wurde der owncloud-user gelöscht und jetzt ist owncloud
nicht mehr funktional:
> Exception occurred while logging exception: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [1045] Benutzer 'owncloud'@'localhost' hat keine Zugriffsberechtigung (verwendetes Passwort: Ja)
> #0 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
> #1 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
> #2 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
> #3 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform()
> #4 /var/www/htdocs/owncloud/lib/private/DB/Connection.php(144): Doctrine\DBAL\Connection->setTransactionIsolation(2)
> #5 /var/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
> #6 /var/www/htdocs/owncloud/lib/private/DB/ConnectionFactory.php(145): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
> #7 /var/www/htdocs/owncloud/lib/private/Server.php(530): OC\DB\ConnectionFactory->getConnection('mysql', Array)
> #8 /var/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
> #9 /var/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(108): Pimple\Container->offsetGet('DatabaseConnect...')
> #10 /var/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\AppFramework\Utility\SimpleContainer->query('DatabaseConnect...')
> #11 /var/www/htdocs/owncloud/lib/private/Server.php(1215): OC\ServerContainer->query('DatabaseConnect...')
> #12 /var/www/htdocs/owncloud/lib/private/Server.php(405): OC\Server->getDatabaseConnection()
> #13 /var/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
> #14 /var/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(108): Pimple\Container->offsetGet('AppConfig')
> #15 /var/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\AppFramework\Utility\SimpleContainer->query('AppConfig')
> #16 /var/www/htdocs/owncloud/lib/private/Server.php(1145): OC\ServerContainer->query('AppConfig')
> #17 /var/www/htdocs/owncloud/lib/private/Server.php(585): OC\Server->getAppConfig()
> #18 /var/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
> #19 /var/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(108): Pimple\Container->offsetGet('AppManager')
> #20 /var/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\AppFramework\Utility\SimpleContainer->query('AppManager')
> #21 /var/www/htdocs/owncloud/lib/private/Server.php(1413): OC\ServerContainer->query('AppManager')
> #22 /var/www/htdocs/owncloud/lib/private/legacy/app.php(346): OC\Server->getAppManager()
> #23 /var/www/htdocs/owncloud/lib/private/legacy/app.php(110): OC_App::getEnabledApps()
> #24 /var/www/htdocs/owncloud/lib/base.php(577): OC_App::loadApps(Array)
> #25 /var/www/htdocs/owncloud/lib/base.php(994): OC::init()
> #26 /var/www/htdocs/owncloud/index.php(53): require_once('/var/www/htdocs...')
> #27 {main}
Gibt es eine einfache Routine, das zu beheben oder nur das Backup einzuspielen?
Dank
Taxi
Juergen Edner
Jun 6, 2019, 2:50:02 AM6/6/19
to
Hallo Taxi,
> Habe die nextcloud-Installation deinstalliert, dabei wurde der owncloud-user gelöscht und jetzt ist owncloud
> nicht mehr funktional:
folgende SQL-Befehle werden zum Erzeugen des Users und dem Setzen
der Zugriffsrechte genutzt:
CREATE USER '${db_user}'@'${DB_HOST}' IDENTIFIED BY '${db_pass}';
GRANT ALL PRIVILEGES ON ${DB_NAME}.* TO '${db_user}'@'${DB_HOST}'
IDENTIFIED BY '${db_pass}';
> Habe die nextcloud-Installation deinstalliert, dabei wurde der owncloud-user gelöscht und jetzt ist owncloud
> nicht mehr funktional:
der Zugriffsrechte genutzt:
CREATE USER '${db_user}'@'${DB_HOST}' IDENTIFIED BY '${db_pass}';
GRANT ALL PRIVILEGES ON ${DB_NAME}.* TO '${db_user}'@'${DB_HOST}'
IDENTIFIED BY '${db_pass}';
Taxena Gasparov
Jun 6, 2019, 10:19:01 AM6/6/19
to
Hallo Jürgen,
Am 06.06.19 um 08:50 schrieb Juergen Edner:
Mit nextcloud 1.6.4 noch probiert, identisches Problem, auch wenn ich den (nichtexistierenden) mysql-User
nextcloud als OWNCLOUD_DB_USER eintrage.
Bei Gelegenheit probier ich die offizielle Migrationsanleitung https://nextcloud.com/migration/.
Danke trotzdem für deine Anleitung.
Wegen mariadb Update:
Ich sollte von mariadb55 auf mariadb102 wechseln?
Falls ja, wenn ich die Doku
> Es können mehrere Versionslinen nebeneiander auf einer Maschine installiert werden. Somit kann, wenn eine
> Anwendung auf einer bestimmten älteren Version angewiesen ist, auch eine Neue Versionsline für aktuelle
> Anwendungen installiert werden.
>
> Zwischen den Versionslinen können die Datenbanken nicht vollautomatisch verschoben werden. Das lässt
> sich über die Menüfunktionen Backup und Restore erledigen. Es ist somit auch möglich wieder auf der
> vorherigen Versionsline zu bleiben, wenn die Anwendung doch nicht mit der Neuen Versionsline zurecht
> kommen will.
richtig verstehe, installiere ich mariadb102, schalte alle Anwendungen mit Zugriff auf mariadb55 aus*,
exportiere (Backup) alle DBs (auch mysql?) und importiere (Restore) alle in mariadb102 und schalte danach
die Anwendungen mit Zugriff auf mariadb102 ggf. mit vorheriger Umkonfiguration wieder ein. Richtig?
*) fraglich aber z.B. ob owncloud per Konfigurationsparameter START_OWNCLOUD oder per Wartungsmodus
ausgeschaltet werden soll/muss.
Dank
Taxi
Am 06.06.19 um 08:50 schrieb Juergen Edner:
> folgende SQL-Befehle werden zum Erzeugen des Users und dem Setzen der Zugriffsrechte genutzt:
> CREATE USER '${db_user}'@'${DB_HOST}' IDENTIFIED BY '${db_pass}'; GRANT ALL PRIVILEGES ON ${DB_NAME}.*
> TO '${db_user}'@'${DB_HOST}' IDENTIFIED BY '${db_pass}';
Danke, damit hat's geklappt, owncloud läuft wieder.
> CREATE USER '${db_user}'@'${DB_HOST}' IDENTIFIED BY '${db_pass}'; GRANT ALL PRIVILEGES ON ${DB_NAME}.*
> TO '${db_user}'@'${DB_HOST}' IDENTIFIED BY '${db_pass}';
Mit nextcloud 1.6.4 noch probiert, identisches Problem, auch wenn ich den (nichtexistierenden) mysql-User
nextcloud als OWNCLOUD_DB_USER eintrage.
Bei Gelegenheit probier ich die offizielle Migrationsanleitung https://nextcloud.com/migration/.
Danke trotzdem für deine Anleitung.
Wegen mariadb Update:
Ich sollte von mariadb55 auf mariadb102 wechseln?
Falls ja, wenn ich die Doku
> Es können mehrere Versionslinen nebeneiander auf einer Maschine installiert werden. Somit kann, wenn eine
> Anwendung auf einer bestimmten älteren Version angewiesen ist, auch eine Neue Versionsline für aktuelle
> Anwendungen installiert werden.
>
> Zwischen den Versionslinen können die Datenbanken nicht vollautomatisch verschoben werden. Das lässt
> sich über die Menüfunktionen Backup und Restore erledigen. Es ist somit auch möglich wieder auf der
> vorherigen Versionsline zu bleiben, wenn die Anwendung doch nicht mit der Neuen Versionsline zurecht
> kommen will.
richtig verstehe, installiere ich mariadb102, schalte alle Anwendungen mit Zugriff auf mariadb55 aus*,
exportiere (Backup) alle DBs (auch mysql?) und importiere (Restore) alle in mariadb102 und schalte danach
die Anwendungen mit Zugriff auf mariadb102 ggf. mit vorheriger Umkonfiguration wieder ein. Richtig?
*) fraglich aber z.B. ob owncloud per Konfigurationsparameter START_OWNCLOUD oder per Wartungsmodus
ausgeschaltet werden soll/muss.
Dank
Taxi
Marcus Roeckrath
Jun 6, 2019, 1:40:01 PM6/6/19
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
> exportiere (Backup) alle DBs (auch mysql?) und
> importiere (Restore) alle in mariadb102
Die mysql würde ich nicht so einfach übernehmen und ich habe es auch nicht
> importiere (Restore) alle in mariadb102
getan.
Wenn du diese importierst, sollte man anschliessend noch die
mariadb-Upgrade-Routine
/usr/lib/mysql/102/bin/mysql_upgrade
ausführen, damit strukturelle Änderungen an dieser internen Datenbank
vorgenommen werden.
--
Gruss Marcus
Taxena Gasparov
Jun 7, 2019, 3:17:47 AM6/7/19
to
Hallo Marcus,
Am 06.06.19 um 19:36 schrieb Marcus Roeckrath:
Ist die DB-Migration irgendwo offziell dokumentiert, denn es standen oder stehen vermutlich jede Menge Leute
vor dieser Aufgabe?
Im wiki https://web.nettworks.org/wiki/display/e/Datenbanken steht dazu nichts.
Taxi
Am 06.06.19 um 19:36 schrieb Marcus Roeckrath:
> Die mysql würde ich nicht so einfach übernehmen und ich habe es auch nicht
> getan.
> Wenn du diese importierst, sollte man anschliessend noch die
> mariadb-Upgrade-Routine
> /usr/lib/mysql/102/bin/mysql_upgrade
> ausführen, damit strukturelle Änderungen an dieser internen Datenbank
> vorgenommen werden.
Danke für deine Hilfestellung.
> getan.
> Wenn du diese importierst, sollte man anschliessend noch die
> mariadb-Upgrade-Routine
> /usr/lib/mysql/102/bin/mysql_upgrade
> ausführen, damit strukturelle Änderungen an dieser internen Datenbank
> vorgenommen werden.
Ist die DB-Migration irgendwo offziell dokumentiert, denn es standen oder stehen vermutlich jede Menge Leute
vor dieser Aufgabe?
Im wiki https://web.nettworks.org/wiki/display/e/Datenbanken steht dazu nichts.
Taxi
Marcus Roeckrath
Jun 7, 2019, 5:20:01 AM6/7/19
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
>> Die mysql würde ich nicht so einfach übernehmen und ich habe es auch
>> nicht getan.
>> Wenn du diese importierst, sollte man anschliessend noch die
>> mariadb-Upgrade-Routine
>> /usr/lib/mysql/102/bin/mysql_upgrade
>> ausführen, damit strukturelle Änderungen an dieser internen Datenbank
>> vorgenommen werden.
>
> Danke für deine Hilfestellung.
> Ist die DB-Migration irgendwo offziell dokumentiert, denn es standen oder
> stehen vermutlich jede Menge Leute vor dieser Aufgabe?
> Im wiki https://web.nettworks.org/wiki/display/e/Datenbanken steht dazu
> nichts.
Ich meine, ich hätte schonmal die Schritte in einem Beitrag in dieser NG
>> nicht getan.
>> Wenn du diese importierst, sollte man anschliessend noch die
>> mariadb-Upgrade-Routine
>> /usr/lib/mysql/102/bin/mysql_upgrade
>> ausführen, damit strukturelle Änderungen an dieser internen Datenbank
>> vorgenommen werden.
>
> Danke für deine Hilfestellung.
> Ist die DB-Migration irgendwo offziell dokumentiert, denn es standen oder
> stehen vermutlich jede Menge Leute vor dieser Aufgabe?
> Im wiki https://web.nettworks.org/wiki/display/e/Datenbanken steht dazu
> nichts.
(grob) beschrieben.
Bitte bemühe mal die Forumsuche unter forum.nettworks.org.
--
Gruss Marcus
Holger Bruenjes
Jun 7, 2019, 6:04:04 AM6/7/19
to
Hallo Taxi
Am 07/06/2019 um 09.17 schrieb Taxena Gasparov:
> Danke für deine Hilfestellung.
> Ist die DB-Migration irgendwo offziell dokumentiert, denn es standen oder stehen vermutlich jede Menge Leute
> vor dieser Aufgabe?
> Im wiki https://web.nettworks.org/wiki/display/e/Datenbanken steht dazu nichts.
Nunja, es gibt zu den Datenbanken ja auch eine Dokumentation,
entweder im Paket
setup
3. Package documentation
2. View documentation
x. View mariadb102 documentation
x. View mariadb55 documentation
oder auch ueber die Haupt Dokumentation
https://www.eisfair.org/fileadmin/eisfair/doc/node27.html
https://www.eisfair.org/fileadmin/eisfair/doc/node55.html#mysqldatabase
Holger
Am 07/06/2019 um 09.17 schrieb Taxena Gasparov:
> Danke für deine Hilfestellung.
> Ist die DB-Migration irgendwo offziell dokumentiert, denn es standen oder stehen vermutlich jede Menge Leute
> vor dieser Aufgabe?
> Im wiki https://web.nettworks.org/wiki/display/e/Datenbanken steht dazu nichts.
entweder im Paket
setup
3. Package documentation
2. View documentation
x. View mariadb102 documentation
x. View mariadb55 documentation
oder auch ueber die Haupt Dokumentation
https://www.eisfair.org/fileadmin/eisfair/doc/node27.html
https://www.eisfair.org/fileadmin/eisfair/doc/node55.html#mysqldatabase
Holger
Taxena Gasparov
Jun 8, 2019, 3:26:37 AM6/8/19
to
Hallo Marcus,
Am 07.06.19 um 11:19 schrieb Marcus Roeckrath:
https://web.nettworks.org/forum/index.php?t=msg&th=9179&goto=66224&#msg_66224
und folgende. Allerdings ist mir das alles zu vage und warte lieber angesichts der Gesamtlage* mit dem
Umstieg bis es einen zuverlässig beschriebenen Weg gibt.
*) Installation mariadb102 möglich, aber ordentliche Grundkonfiguration unmöglich:
Nach ersten Konfigdurchlauf:
> Checking configuration file ...
>
> Configuration file was saved as mariadb102.2019-06-07-11-05-52 in /etc/backup.d.
>
Was tut pwgen bei Antwort mit "y" bzw.
> Set Password for MariaDB/MySQL user root: (y/n) [yes]?
> Create password with pwgen (y/n) [yes]?
> Set new 'root' password on server 'mariadb55'
> * Stopping MariaDB/MySQL database server 5.5 ..... [ OK ]
> * Starting MariaDB/MySQL database server 5.5 .. [ OK ]
> * Stopping MariaDB/MySQL database server 5.5 ..... [ OK ]
> * Starting MariaDB/MySQL database server 5.5 .. [ OK ]
> * Stopping MariaDB/MySQL database server 10.2 ... [ OK ]
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Press ENTER to continue
leider kein Zugriff auf die SQL-Console:
> MariaDB/MySQL Server 'root' password is required.
> Please set the root password.
Nach Suche, wo man das root Passwort setzt, mit
> 4 Change MariaDB user password
probiert, leider kein Erfolg, vielleicht weil da nur in mariadb55 statt mariadb102 rumgeschrieben wird:
> Create password with pwgen (y/n) [yes]? n
> Now enter the new password:
> Password:?
> Retype password:?
> Set new 'root' password on server 'mariadb55'
> * Stopping MariaDB/MySQL database server 5.5
> * Starting MariaDB/MySQL database server 5.5
> * Stopping MariaDB/MySQL database server 5.5
> * Starting MariaDB/MySQL database server 5.5
Scheinbar keinerlei Bearbeitung von mariadb102. Wieso das?
Taxi
Am 07.06.19 um 11:19 schrieb Marcus Roeckrath:
> Ich meine, ich hätte schonmal die Schritte in einem Beitrag in dieser NG
> (grob) beschrieben.
> Bitte bemühe mal die Forumsuche unter forum.nettworks.org.
das Beschreibungsähnlichste was ich fand, ist:
> (grob) beschrieben.
> Bitte bemühe mal die Forumsuche unter forum.nettworks.org.
https://web.nettworks.org/forum/index.php?t=msg&th=9179&goto=66224&#msg_66224
und folgende. Allerdings ist mir das alles zu vage und warte lieber angesichts der Gesamtlage* mit dem
Umstieg bis es einen zuverlässig beschriebenen Weg gibt.
*) Installation mariadb102 möglich, aber ordentliche Grundkonfiguration unmöglich:
Nach ersten Konfigdurchlauf:
> Checking configuration file ...
>
> Configuration file was saved as mariadb102.2019-06-07-11-05-52 in /etc/backup.d.
>
> Activate configuration now (y/n) [yes]?
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Activate configuration now (y/n) [yes]?
>
Was tut pwgen bei Antwort mit "y" bzw.
> Set Password for MariaDB/MySQL user root: (y/n) [yes]?
> Create password with pwgen (y/n) [yes]?
> Set new 'root' password on server 'mariadb55'
> * Stopping MariaDB/MySQL database server 5.5 ..... [ OK ]
> * Starting MariaDB/MySQL database server 5.5 .. [ OK ]
> * Stopping MariaDB/MySQL database server 5.5 ..... [ OK ]
> * Starting MariaDB/MySQL database server 5.5 .. [ OK ]
> * Stopping MariaDB/MySQL database server 10.2 ... [ OK ]
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Press ENTER to continue
leider kein Zugriff auf die SQL-Console:
> MariaDB/MySQL Server 'root' password is required.
> Please set the root password.
Nach Suche, wo man das root Passwort setzt, mit
> 4 Change MariaDB user password
probiert, leider kein Erfolg, vielleicht weil da nur in mariadb55 statt mariadb102 rumgeschrieben wird:
> Create password with pwgen (y/n) [yes]? n
> Now enter the new password:
> Password:?
> Retype password:?
> Set new 'root' password on server 'mariadb55'
> * Stopping MariaDB/MySQL database server 5.5
> * Starting MariaDB/MySQL database server 5.5
> * Stopping MariaDB/MySQL database server 5.5
> * Starting MariaDB/MySQL database server 5.5
Scheinbar keinerlei Bearbeitung von mariadb102. Wieso das?
Taxi
Taxena Gasparov
Jun 8, 2019, 3:28:48 AM6/8/19
to
Hallo Holger,
Am 07.06.19 um 12:04 schrieb Holger Bruenjes:
> https://www.eisfair.org/fileadmin/eisfair/doc/node27.html
> https://www.eisfair.org/fileadmin/eisfair/doc/node55.html#mysqldatabase
es wird erwähnt, dass die Datenbankversionen parallel betrieben werden können, aber in keinem der Dokumente
konnte ich eine Beschreibung der Migration finden, auch nicht das Wort "mysql_upgrade", das ja unentbehrlich
zu sein scheint.
Taxi
Am 07.06.19 um 12:04 schrieb Holger Bruenjes:
> Nunja, es gibt zu den Datenbanken ja auch eine Dokumentation,
> ..
> https://www.eisfair.org/fileadmin/eisfair/doc/node27.html
> https://www.eisfair.org/fileadmin/eisfair/doc/node55.html#mysqldatabase
es wird erwähnt, dass die Datenbankversionen parallel betrieben werden können, aber in keinem der Dokumente
konnte ich eine Beschreibung der Migration finden, auch nicht das Wort "mysql_upgrade", das ja unentbehrlich
zu sein scheint.
Taxi
Holger Bruenjes
Jun 8, 2019, 4:06:23 AM6/8/19
to
Hallo Taxi
Am 08/06/2019 um 09.26 schrieb Taxena Gasparov:
> *) Installation mariadb102 möglich, aber ordentliche Grundkonfiguration unmöglich:
> Nach ersten Konfigdurchlauf:
>> Checking configuration file ...
>>
>> Configuration file was saved as mariadb102.2019-06-07-11-05-52 in /etc/backup.d.
>>
>> Activate configuration now (y/n) [yes]?
>> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
>>
> Was tut pwgen bei Antwort mit "y" bzw.
pwgen setzt das Passwort automatisch
pwgen -1s 12
> Scheinbar keinerlei Bearbeitung von mariadb102. Wieso das?
hmm, stoppe bitte mariadb55
/etc/init.d/mariadb55 stop
echo 'datetime' >/srv/mysql/102/new-install
und die configuration fuer mariadb102 ausfuehren
danach dann mariadb55 wieder starten
/etc/init.d/mariadb55 start
das Datenbank root Passswort ist fuer alle MariaDB/MySQL
Installationen das gleiche
Holger
Am 08/06/2019 um 09.26 schrieb Taxena Gasparov:
> *) Installation mariadb102 möglich, aber ordentliche Grundkonfiguration unmöglich:
> Nach ersten Konfigdurchlauf:
>> Checking configuration file ...
>>
>> Configuration file was saved as mariadb102.2019-06-07-11-05-52 in /etc/backup.d.
>>
>> Activate configuration now (y/n) [yes]?
>> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
>>
> Was tut pwgen bei Antwort mit "y" bzw.
pwgen -1s 12
> Scheinbar keinerlei Bearbeitung von mariadb102. Wieso das?
/etc/init.d/mariadb55 stop
echo 'datetime' >/srv/mysql/102/new-install
und die configuration fuer mariadb102 ausfuehren
danach dann mariadb55 wieder starten
/etc/init.d/mariadb55 start
das Datenbank root Passswort ist fuer alle MariaDB/MySQL
Installationen das gleiche
Holger
Marcus Roeckrath
Jun 8, 2019, 4:10:01 AM6/8/19
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
>> Bitte bemühe mal die Forumsuche unter forum.nettworks.org.
>
> das Beschreibungsähnlichste was ich fand, ist:
>
https://web.nettworks.org/forum/index.php?t=msg&th=9179&goto=66224&#msg_66224
> und folgende. Allerdings ist mir das alles zu vage und warte lieber
> angesichts der Gesamtlage* mit dem Umstieg bis es einen zuverlässig
> beschriebenen Weg gibt.
Es gibt noch einen anderen Beitrag, den ich in meinem vorigen Beitrag
>
> das Beschreibungsähnlichste was ich fand, ist:
>
https://web.nettworks.org/forum/index.php?t=msg&th=9179&goto=66224&#msg_66224
> und folgende. Allerdings ist mir das alles zu vage und warte lieber
> angesichts der Gesamtlage* mit dem Umstieg bis es einen zuverlässig
> beschriebenen Weg gibt.
erwähnt und kommentiert habe.
Eine exakte Anleitung kann ich aber nur schreiben, wenn ich einen Umstieg
irgendwann mal wieder machen muss; alles andere ist grobe Erinnerung an ein
früheres Vorgehen.
> *) Installation mariadb102 möglich, aber ordentliche Grundkonfiguration
> unmöglich: Nach ersten Konfigdurchlauf:
--
Gruss Marcus
Marcus Roeckrath
Jun 8, 2019, 4:10:01 AM6/8/19
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
>> Nunja, es gibt zu den Datenbanken ja auch eine Dokumentation,
>> ..
>> https://www.eisfair.org/fileadmin/eisfair/doc/node27.html
>> https://www.eisfair.org/fileadmin/eisfair/doc/node55.html#mysqldatabase
>
> es wird erwähnt, dass die Datenbankversionen parallel betrieben werden
> können, aber in keinem der Dokumente konnte ich eine Beschreibung der
> Migration finden, auch nicht das Wort "mysql_upgrade", das ja
> unentbehrlich zu sein scheint.
Ob unentbehrlich bliebe die Frage, aber ich würde es so machen.
>> ..
>> https://www.eisfair.org/fileadmin/eisfair/doc/node27.html
>> https://www.eisfair.org/fileadmin/eisfair/doc/node55.html#mysqldatabase
>
> es wird erwähnt, dass die Datenbankversionen parallel betrieben werden
> können, aber in keinem der Dokumente konnte ich eine Beschreibung der
> Migration finden, auch nicht das Wort "mysql_upgrade", das ja
> unentbehrlich zu sein scheint.
Ich habe bei der letzten Migration die mysql-DB garnicht importiert, sondern
die paar User eben mit den gleichen Einstellungen wieder eingetragen.
Jürgen hat das Vorgehen mal hier
https://web.nettworks.org/forum/index.php?t=msg&goto=64751&&srch=mariadb102+3306+3307+j%C3%BCrgen#msg_64751
in einigen Punkten zusammengefasst; das hier von 100 nach 102 migriert wurde
ist dabei egal, du machst es halt von 55 nach 102).
1. Existierende Datenbank: mariadb100 -> Port 3306
2. Neuinstallation mariadb102 -> 3307
3. Export der Daten aus mariadb100 und Import in mariadb102.
4. Stoppen und Deaktivieren von mariadb100.
5. Ändern des Ports für mariadb102 von 3307 auf 3306.
6. Starten von mariadb102.
Ausgehend von dieser Überlegung würde ich es eventuell auch so machen,
nachdem man möglichst alle Dienst, die auf die Datenbanken zugreifen
gestoppt hat:
1. Existierende Datenbank: mariadb100 -> Port 3306
2. Neuinstallation mariadb102 -> 3307
3. Export der Daten aus mariadb100
Den Schritt kann man auch dadurch erledigen, dass man automatisch erzeugten
DB-Backups aus /srv/mysql_backup/55/ nach /srv/mysql_backup/102/ kopierst,
sofern du für alle Datenbanken auch das crongesteuerte Backup eingerichtet
hast. Sonst machst du nun im Menu erstmal ein Backup aller Datenbanken.
4. Stoppen und Deaktivieren von mariadb100.
5. Ändern des Ports für mariadb102 von 3307 auf 3306.
Ob man nun sofort nach Deaktivieren von mariadb55 schon mariadb102 auf 3306
legen kann, könnte ich erst nach Probieren sagen; ich hatte damals nach
meiner Erinnerung die Vorversion schon an dieser Stelle entsorgt.
Man kann auch zunächst mariadb55 auf z. B. 3308 und dann mariadb102 auf 3306
legen.
6. Starten von mariadb102.
Ich würde nun mariadb102 starten, und zunächst mysql-DB importieren und zwar
im Menu aus den een kopierten Backups.
Dann die Upgradeprozedur
/usr/lib/mysql/102/bin/mysql_upgrade -k -s
durchführen.
7. Import der DB-Backups im Menu auch für die anderen DBs
8. Deinstallation von mariadb55
PS: Deine mariadb55 ist aktuell?
--
Gruss Marcus
Taxena Gasparov
Jun 8, 2019, 4:52:05 AM6/8/19
to
Hallo Holger,
Am 08.06.19 um 10:06 schrieb Holger Bruenjes:
Wie logge ich mich damit in die DB ein, wo ist das automaitsche PW lesbar hinterlegt? Oder geht das dann nur
per Bruteforce? :-)
> /etc/init.d/mariadb55 stop
> echo 'datetime' >/srv/mysql/102/new-install
> und die configuration fuer mariadb102 ausfuehren
> danach dann mariadb55 wieder starten
> /etc/init.d/mariadb55 start
exakt so getan...
> Checking configuration file ...
>
> Configuration file was saved as mariadb102.2019-06-08-10-23-19 in /etc/backup.d.
aber scheinbar keine Änderung bewirkt, wenn ich SQL-Console starten will:
SQL-Console bei mariadb55 funktioniert (noch) tadellos.
mariadb55 Version: 2.12.3
Taxi
Am 08.06.19 um 10:06 schrieb Holger Bruenjes:
> pwgen setzt das Passwort automatisch
> pwgen -1s 12
hat das (Sicherheits-)Vorteile?
> pwgen -1s 12
Wie logge ich mich damit in die DB ein, wo ist das automaitsche PW lesbar hinterlegt? Oder geht das dann nur
per Bruteforce? :-)
> /etc/init.d/mariadb55 stop
> echo 'datetime' >/srv/mysql/102/new-install
> und die configuration fuer mariadb102 ausfuehren
> danach dann mariadb55 wieder starten
> /etc/init.d/mariadb55 start
> Checking configuration file ...
>
> Configuration file was saved as mariadb102.2019-06-08-10-23-19 in /etc/backup.d.
>
> Activate configuration now (y/n) [yes]?
> * MariaDB/MySQL database server 10.2 is already running ... [ WARN ]
> Activate configuration now (y/n) [yes]?
>
> Set Password for MariaDB/MySQL user root: (y/n) [yes]?
> Set Password for MariaDB/MySQL user root: (y/n) [yes]?
> Create password with pwgen (y/n) [yes]? n
> Now enter the new password:
> Password:?
> Retype password:?
> * Stopping MariaDB/MySQL database server 10.2 .. [ OK ]
> Now enter the new password:
> Password:?
> Retype password:?
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Press ENTER to continue
aber scheinbar keine Änderung bewirkt, wenn ich SQL-Console starten will:
> MariaDB/MySQL Server 'root' password is required.
> Please set the root password.
>
> Press ENTER to continue
> Please set the root password.
>
SQL-Console bei mariadb55 funktioniert (noch) tadellos.
mariadb55 Version: 2.12.3
Taxi
Taxena Gasparov
Jun 8, 2019, 4:54:00 AM6/8/19
to
Hallo Marcus,
Am 08.06.19 um 10:08 schrieb Marcus Roeckrath:
Taxi
Am 08.06.19 um 10:08 schrieb Marcus Roeckrath:
> Welche Version von mariadb55 ist bei dir bislang installiert?
mariadb55 Version: 2.12.3
Taxi
Marcus Roeckrath
Jun 8, 2019, 5:20:01 AM6/8/19
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
>> Welche Version von mariadb55 ist bei dir bislang installiert?
>
> mariadb55 Version: 2.12.3
Ok, das ist aktuell.
>
> mariadb55 Version: 2.12.3
--
Gruss Marcus
Marcus Roeckrath
Jun 8, 2019, 5:20:01 AM6/8/19
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
>> pwgen setzt das Passwort automatisch
>> pwgen -1s 12
>
> hat das (Sicherheits-)Vorteile?
> Wie logge ich mich damit in die DB ein, wo ist das automaitsche PW lesbar
> hinterlegt? Oder geht das dann nur per Bruteforce? :-)
Du musst ja nicht die automatische Passwortvergabe nutzen, ich vergebe das
>> pwgen -1s 12
>
> hat das (Sicherheits-)Vorteile?
> Wie logge ich mich damit in die DB ein, wo ist das automaitsche PW lesbar
> hinterlegt? Oder geht das dann nur per Bruteforce? :-)
auch lieber selber, damit ich ein schwieriges aber zu merkendes Passwort
vergeben kann.
Hinterlegt wird das root-Passwort in allen Fällen unter /root/.my.conf.
--
Gruss Marcus
Holger Bruenjes
Jun 8, 2019, 5:22:41 AM6/8/19
to
Hallo Taxi
Am 08/06/2019 um 10.52 schrieb Taxena Gasparov:
> Am 08.06.19 um 10:06 schrieb Holger Bruenjes:
>> pwgen setzt das Passwort automatisch
>> pwgen -1s 12
>
> hat das (Sicherheits-)Vorteile?
> Wie logge ich mich damit in die DB ein, wo ist das automaitsche PW lesbar hinterlegt? Oder geht das dann nur
> per Bruteforce? :-)
hmm, das Datenbank root Passwort wird im ~root abgelegt und ist fuer
alle installierten MariadDB/MySQL Versionen identisch.
Aus Sicherheitsgruenden solltest Du Dich auch nie mit dem root
Passwort einloggen und die root Rechte nur fuer local belassen.
Du kannst Dir einen user anlegen der alle Rechte besitzt von
ueberallher. Das root Passwort wird dann nur local fuer die updates
und backup benutzt.
>> /etc/init.d/mariadb55 stop
>> echo 'datetime' >/srv/mysql/102/new-install
>> und die configuration fuer mariadb102 ausfuehren
>> danach dann mariadb55 wieder starten
>> /etc/init.d/mariadb55 start
den Port hast Du aber schon unterschiedlich gesetzt?
>
> exakt so getan...
>> Checking configuration file ...
>>
>> Configuration file was saved as mariadb102.2019-06-08-10-23-19 in /etc/backup.d.
>>
>> Activate configuration now (y/n) [yes]?
>> * MariaDB/MySQL database server 10.2 is already running ... [ WARN ]
ahh, da ist ein Fehler, der Server laeuft ja weiter
stoppe alle Prozesse fuer mariadb102
ps ax | grep mysql/102
und dann nochmal bitte
Holger
Am 08/06/2019 um 10.52 schrieb Taxena Gasparov:
> Am 08.06.19 um 10:06 schrieb Holger Bruenjes:
>> pwgen setzt das Passwort automatisch
>> pwgen -1s 12
>
> hat das (Sicherheits-)Vorteile?
> Wie logge ich mich damit in die DB ein, wo ist das automaitsche PW lesbar hinterlegt? Oder geht das dann nur
> per Bruteforce? :-)
alle installierten MariadDB/MySQL Versionen identisch.
Aus Sicherheitsgruenden solltest Du Dich auch nie mit dem root
Passwort einloggen und die root Rechte nur fuer local belassen.
Du kannst Dir einen user anlegen der alle Rechte besitzt von
ueberallher. Das root Passwort wird dann nur local fuer die updates
und backup benutzt.
>> /etc/init.d/mariadb55 stop
>> echo 'datetime' >/srv/mysql/102/new-install
>> und die configuration fuer mariadb102 ausfuehren
>> danach dann mariadb55 wieder starten
>> /etc/init.d/mariadb55 start
>
> exakt so getan...
>> Checking configuration file ...
>>
>> Configuration file was saved as mariadb102.2019-06-08-10-23-19 in /etc/backup.d.
>>
>> Activate configuration now (y/n) [yes]?
>> * MariaDB/MySQL database server 10.2 is already running ... [ WARN ]
stoppe alle Prozesse fuer mariadb102
ps ax | grep mysql/102
und dann nochmal bitte
Holger
Taxena Gasparov
Jun 12, 2019, 2:34:15 AM6/12/19
to
Hallo Holger,
Am 08.06.19 um 11:22 schrieb Holger Bruenjes:
> ahh, da ist ein Fehler, der Server laeuft ja weiter
> stoppe alle Prozesse fuer mariadb102
> ps ax | grep mysql/102
> und dann nochmal bitte
getan, aber ...
> Checking configuration file ...
...und SQL Console Login weiterhin nicht möglich bei mariadb 102 (bei mariadb55 geht er):
Am 08.06.19 um 11:22 schrieb Holger Bruenjes:
> den Port hast Du aber schon unterschiedlich gesetzt?
ja.
> ahh, da ist ein Fehler, der Server laeuft ja weiter
> stoppe alle Prozesse fuer mariadb102
> ps ax | grep mysql/102
> und dann nochmal bitte
> Checking configuration file ...
> Activate configuration now (y/n) [yes]?
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Set Password for MariaDB/MySQL user root: (y/n) [yes]?
> Create password with pwgen (y/n) [yes]? n
> Now enter the new password:
> Password:?
> Retype password:?
> * Stopping MariaDB/MySQL database server 10.2 .. [ OK ]
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Press ENTER to continue
...der Server wird vor dem Passwortsetzen wieder gestartet.
> Set Password for MariaDB/MySQL user root: (y/n) [yes]?
> Create password with pwgen (y/n) [yes]? n
> Now enter the new password:
> Password:?
> Retype password:?
> * Stopping MariaDB/MySQL database server 10.2 .. [ OK ]
> * Starting MariaDB/MySQL database server 10.2 . [ OK ]
> Press ENTER to continue
...und SQL Console Login weiterhin nicht möglich bei mariadb 102 (bei mariadb55 geht er):
> MariaDB/MySQL Server 'root' password is required.
> Please set the root password.
> Press ENTER to continue
Taxi
> Please set the root password.
> Press ENTER to continue
Juergen Edner
Jun 12, 2019, 4:12:47 AM6/12/19
to
Hallo Taxi,
> ...der Server wird vor dem Passwortsetzen wieder gestartet.
> ...und SQL Console Login weiterhin nicht möglich bei mariadb 102 (bei mariadb55 geht er):
wie genau versuchst Du dich an der Konsole an der MariaDB 10.2-Datenbank
anzumelden, d.h. welchen Befehl gibst Du dafür genau ein?
> ...der Server wird vor dem Passwortsetzen wieder gestartet.
> ...und SQL Console Login weiterhin nicht möglich bei mariadb 102 (bei mariadb55 geht er):
anzumelden, d.h. welchen Befehl gibst Du dafür genau ein?
Taxena Gasparov
Jun 12, 2019, 5:10:08 AM6/12/19
to
Hallo Jürgen,
Am 12.06.19 um 10:12 schrieb Juergen Edner:
> d.h. welchen Befehl gibst Du dafür genau ein?
jetzt mit diesen Befehlen:
> root@eis 2.8.16:~ # mysql -P 3306 -S /run/mysql/55/mysql.sock -u root -p
> Enter password:
> Welcome to the MariaDB monitor. Commands end with ; or \g.
> Your MariaDB connection id is 1460
> Server version: 5.5.57-MariaDB eisfair-1 build
>
> Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
>
> MariaDB [(none)]> \q
> Bye
> root@eis 2.8.16:~ # mysql -P 3308 -S /run/mysql/102/mysql.sock -u root -p
> Enter password:
> ERROR 1045 (28000): Benutzer 'root'@'localhost' hat keine Zugriffsberechtigung (verwendetes Passwort: Ja)
> root@eis 2.8.16:~ #
Taxi
Am 12.06.19 um 10:12 schrieb Juergen Edner:
> wie genau versuchst Du dich an der Konsole an der MariaDB 10.2-Datenbank
> anzumelden,
bisher via Unteruntermenüpunkt 8 "SQL Console" des Untermenüs 8 "MariaDB Tools".
> anzumelden,
> d.h. welchen Befehl gibst Du dafür genau ein?
> root@eis 2.8.16:~ # mysql -P 3306 -S /run/mysql/55/mysql.sock -u root -p
> Enter password:
> Welcome to the MariaDB monitor. Commands end with ; or \g.
> Your MariaDB connection id is 1460
> Server version: 5.5.57-MariaDB eisfair-1 build
>
> Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
>
> MariaDB [(none)]> \q
> Bye
> root@eis 2.8.16:~ # mysql -P 3308 -S /run/mysql/102/mysql.sock -u root -p
> Enter password:
> ERROR 1045 (28000): Benutzer 'root'@'localhost' hat keine Zugriffsberechtigung (verwendetes Passwort: Ja)
> root@eis 2.8.16:~ #
Taxi
Marcus Roeckrath
Jun 12, 2019, 5:37:18 AM6/12/19
to
Hallo Taxena,
Gasparov Taxena schrieb am Wed, 12 June 2019 11:10
dort mal die Ausgabe der Userliste in beiden Datenbanksystemen. Mir
scheint, als wären in mariadb102 nicht alle Rechte für Root angelegt
worden.
--
Gruß Marcus
Gasparov Taxena schrieb am Wed, 12 June 2019 11:10
> > root@eis 2.8.16:~ # mysql -P 3308 -S /run/mysql/102/mysql.sock
> > -u root -p
> > Enter password:
> > ERROR 1045 (28000): Benutzer 'root'@'localhost' hat keine
> > Zugriffsberechtigung (verwendetes Passwort: Ja)
> > root@eis 2.8.16:~ #
Gehe bitte in das Tools Menu von mariadb55 und mariadb102 und poste von
> > -u root -p
> > Enter password:
> > ERROR 1045 (28000): Benutzer 'root'@'localhost' hat keine
> > Zugriffsberechtigung (verwendetes Passwort: Ja)
> > root@eis 2.8.16:~ #
dort mal die Ausgabe der Userliste in beiden Datenbanksystemen. Mir
scheint, als wären in mariadb102 nicht alle Rechte für Root angelegt
worden.
--
Gruß Marcus
Juergen Edner
Jun 12, 2019, 5:38:14 AM6/12/19
to
Hallo Taxi,
>> root@eis 2.8.16:~ # mysql -P 3308 -S /run/mysql/102/mysql.sock -u root -p
>> Enter password:
>> ERROR 1045 (28000): Benutzer 'root'@'localhost' hat keine Zugriffsberechtigung (verwendetes Passwort: Ja)
>> root@eis 2.8.16:~ #
bei der Parameterangabe kombinierst Du zwei gegensätzliche Parameter
miteinander, d.h. einmal einen Netzwerk- und eine Socket-Parameter.
Wenn Du also über den lokalen Socket auf die Datenbank zugreifen willst,
sollte folgender Aufruf funktionieren. Die Angabe des Ports, des Users
und einer Passwortabfrage sollte nicht erforderlich sein:
mysql -S /run/mysql/102/mysql.sock
>> root@eis 2.8.16:~ # mysql -P 3308 -S /run/mysql/102/mysql.sock -u root -p
>> Enter password:
>> ERROR 1045 (28000): Benutzer 'root'@'localhost' hat keine Zugriffsberechtigung (verwendetes Passwort: Ja)
>> root@eis 2.8.16:~ #
miteinander, d.h. einmal einen Netzwerk- und eine Socket-Parameter.
Wenn Du also über den lokalen Socket auf die Datenbank zugreifen willst,
sollte folgender Aufruf funktionieren. Die Angabe des Ports, des Users
und einer Passwortabfrage sollte nicht erforderlich sein:
mysql -S /run/mysql/102/mysql.sock
Taxena Gasparov
Jun 12, 2019, 5:46:13 AM6/12/19
to
Hallo Marcus,
Am 12.06.19 um 11:37 schrieb Marcus Roeckrath:
List all MariaDB/MySQL user
+-----------+-----------+-------------+-------------+------------+
| user | host | select_priv | insert_priv | grant_priv |
+-----------+-----------+-------------+-------------+------------+
| root | localhost | Y | Y | Y |
| backup | localhost | Y | Y | Y |
| owncloud | localhost | N | N | N |
| roundcube | localhost | Y | N | N |
+-----------+-----------+-------------+-------------+------------+
Press ENTER to continue
mariadb102:
Am 12.06.19 um 11:37 schrieb Marcus Roeckrath:
> Gehe bitte in das Tools Menu von mariadb55 und mariadb102 und poste von
> dort mal die Ausgabe der Userliste in beiden Datenbanksystemen.
mariadb55:
> dort mal die Ausgabe der Userliste in beiden Datenbanksystemen.
List all MariaDB/MySQL user
+-----------+-----------+-------------+-------------+------------+
| user | host | select_priv | insert_priv | grant_priv |
+-----------+-----------+-------------+-------------+------------+
| root | localhost | Y | Y | Y |
| backup | localhost | Y | Y | Y |
| owncloud | localhost | N | N | N |
| roundcube | localhost | Y | N | N |
+-----------+-----------+-------------+-------------+------------+
Press ENTER to continue
mariadb102:
Taxena Gasparov
Jun 12, 2019, 5:47:29 AM6/12/19
to
Am 12.06.19 um 11:38 schrieb Juergen Edner:
> mysql -S /run/mysql/102/mysql.sock
> mysql -S /run/mysql/102/mysql.sock
Holger Bruenjes
Jun 12, 2019, 6:08:45 AM6/12/19
to
Hallo Taxi
setze bitte im mariadb55 Menue das Passwort fuer root neu.
ist dieses Passwort dann in ~root/.my.conf vorhanden?
Holger
ist dieses Passwort dann in ~root/.my.conf vorhanden?
Holger
Taxena Gasparov
Jun 12, 2019, 6:29:29 AM6/12/19
to
Hallo Holger,
Am 12.06.19 um 12:08 schrieb Holger Bruenjes:
Auch beim Ändern über das mariadb102 Menü wird das Passwort in die Datei .my.conf geschrieben.
Taxi
Am 12.06.19 um 12:08 schrieb Holger Bruenjes:
> setze bitte im mariadb55 Menue das Passwort fuer root neu.
> ist dieses Passwort dann in ~root/.my.conf vorhanden?
ja.
> ist dieses Passwort dann in ~root/.my.conf vorhanden?
Auch beim Ändern über das mariadb102 Menü wird das Passwort in die Datei .my.conf geschrieben.
Taxi
Holger Bruenjes
Jun 12, 2019, 6:57:30 AM6/12/19
to
Hallo Taxi
Am 12/06/2019 um 12.29 schrieb Taxena Gasparov:
> ja.
> Auch beim Ändern über das mariadb102 Menü wird das Passwort in die Datei .my.conf geschrieben.
ok, stoppe mariadb102
/etc/init.d/mariadb102 stop
starte sie ohne NETZ
/etc/init.d/mariadb102 --skip start
das password dann setzen,
${passwort} ersetzen ;-)
/usr/lib/mysql/102/bin/mysql --socket=/run/mysql/102/mysql.sock \
--database=mysql \
--user=root \
-e "update user set password=PASSWORD('${password}') \
where user='root'; \
flush privileges;"
/etc/init.d/mariadb102 restart
Holger
Am 12/06/2019 um 12.29 schrieb Taxena Gasparov:
> ja.
> Auch beim Ändern über das mariadb102 Menü wird das Passwort in die Datei .my.conf geschrieben.
/etc/init.d/mariadb102 stop
starte sie ohne NETZ
/etc/init.d/mariadb102 --skip start
das password dann setzen,
${passwort} ersetzen ;-)
/usr/lib/mysql/102/bin/mysql --socket=/run/mysql/102/mysql.sock \
--database=mysql \
--user=root \
-e "update user set password=PASSWORD('${password}') \
where user='root'; \
flush privileges;"
/etc/init.d/mariadb102 restart
Holger
Taxena Gasparov
Jun 12, 2019, 10:02:27 AM6/12/19
to
Hallo Holger,
Am 12.06.19 um 12:57 schrieb Holger Bruenjes:
> ok, stoppe mariadb102
> ...
> /etc/init.d/mariadb102 restart
Danke, jetzt klappt der Zugriff per SQL Console und die Auflistung der user.
Taxi
Am 12.06.19 um 12:57 schrieb Holger Bruenjes:
> ok, stoppe mariadb102
> ...
> /etc/init.d/mariadb102 restart
Danke, jetzt klappt der Zugriff per SQL Console und die Auflistung der user.
Taxi
Holger Bruenjes
Jun 12, 2019, 12:11:47 PM6/12/19
to
Hallo Taxi
Am 12/06/2019 um 16.02 schrieb Taxena Gasparov:
> Danke, jetzt klappt der Zugriff per SQL Console und die Auflistung der user.
hmm, was mich dabei verwundert, es wird im Skript genauso gemacht.
Nungut, es hat geklappt. Super. :-)
Holger
Am 12/06/2019 um 16.02 schrieb Taxena Gasparov:
> Danke, jetzt klappt der Zugriff per SQL Console und die Auflistung der user.
Nungut, es hat geklappt. Super. :-)
Holger
Taxena Gasparov
Jan 11, 2021, 7:01:35 AM1/11/21
to
Hallo eisfair-Leute,
Am 12.06.19 um 18:11 schrieb Holger Bruenjes:
>>> Database type : mysql (mariadb55)
>
> Nur nebenbei erwähnt, Du solltest irgendwann auch einmal MariaDB auf
> eine aktuelle Version umstellen ;-)
nachdem vor ein paar Monaten die MariaDB-Umstellung gehakt und dadurch vorerst die
owncloud-/nextcloud-Migration verhinderte, habe ich mit MarcusRs Anleitung [1] inzwischen auf mariadb103
umgestellt.
Derzeit und seit Monaten läuft owncloud 1.8.1 fehlerfrei. Zeitmangel und früheres Upgradeproblem [2] haben
mich von Updates/-grades und Umstieg auf nextcloud abgehalten.
Laut Paketsuche gibt es derzeit folgende eigen- und nächst- Wolken im Angebot:
owncloud 1.9.3
owncloud 1.10.2
owncloud 1.11.0
nextcloud 1.9.5
nextcloud 1.10.3
nextcloud 1.11.1
Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen Upgradepfad von owncloud 1.8.1 auf
nextcloud 1.11.1?
Dank
Taxi
[1] https://web.nettworks.org/wiki/pages/viewpage.action?pageId=63963157
[2] https://lists.spline.inf.fu-berlin.de/pipermail/eisfair/2019-June/035110.html
Am 12.06.19 um 18:11 schrieb Holger Bruenjes:
> hmm, was mich dabei verwundert, es wird im Skript genauso gemacht.
> Nungut, es hat geklappt. Super. :-)
Am 05.06.19 um 18:21 schrieb Juergen Edner:
> Nungut, es hat geklappt. Super. :-)
>>> Activate configuration now (y/n) [yes]?
>>> owncloud version (eisfair-1): v1.7.1
>>> Database type : mysql (mariadb55)
>
> Nur nebenbei erwähnt, Du solltest irgendwann auch einmal MariaDB auf
> eine aktuelle Version umstellen ;-)
nachdem vor ein paar Monaten die MariaDB-Umstellung gehakt und dadurch vorerst die
owncloud-/nextcloud-Migration verhinderte, habe ich mit MarcusRs Anleitung [1] inzwischen auf mariadb103
umgestellt.
Derzeit und seit Monaten läuft owncloud 1.8.1 fehlerfrei. Zeitmangel und früheres Upgradeproblem [2] haben
mich von Updates/-grades und Umstieg auf nextcloud abgehalten.
Laut Paketsuche gibt es derzeit folgende eigen- und nächst- Wolken im Angebot:
owncloud 1.9.3
owncloud 1.10.2
owncloud 1.11.0
nextcloud 1.9.5
nextcloud 1.10.3
nextcloud 1.11.1
Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen Upgradepfad von owncloud 1.8.1 auf
nextcloud 1.11.1?
Dank
Taxi
[1] https://web.nettworks.org/wiki/pages/viewpage.action?pageId=63963157
[2] https://lists.spline.inf.fu-berlin.de/pipermail/eisfair/2019-June/035110.html
Marcus Röckrath
Jan 11, 2021, 7:20:02 AM1/11/21
to
Hallo Taxena,
Taxena Gasparov wrote:
Taxena Gasparov wrote:
> nachdem vor ein paar Monaten die MariaDB-Umstellung gehakt und dadurch
> vorerst die owncloud-/nextcloud-Migration verhinderte, habe ich mit
> MarcusRs Anleitung [1] inzwischen auf mariadb103 umgestellt.
Nur so zur Info: Gibt es Anregungen/Verbesserungsvorschläge zu dieser
> vorerst die owncloud-/nextcloud-Migration verhinderte, habe ich mit
> MarcusRs Anleitung [1] inzwischen auf mariadb103 umgestellt.
Anleitung.
> Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen
> Upgradepfad von owncloud 1.8.1 auf nextcloud 1.11.1?
Anders als bei OpenOffice vs. LibreOffice odr OpenElec vs. LibreElec, bei
den das zum "Untergang" der Open-Varianten geführt hat, sind sowohl own-
als auch nextcloud in aktiver Entwicklung.
--
Gruß Marcus
[eisfair-Team]
Juergen Edner
Jan 12, 2021, 3:24:05 AM1/12/21
to
Hallo Taxi,
> Derzeit und seit Monaten läuft owncloud 1.8.1 fehlerfrei. Zeitmangel und früheres Upgradeproblem [2] haben
> mich von Updates/-grades und Umstieg auf nextcloud abgehalten.
>
> Laut Paketsuche gibt es derzeit folgende eigen- und nächst- Wolken im Angebot:
> owncloud 1.9.3
> owncloud 1.10.2
> owncloud 1.11.0
> nextcloud 1.9.5
> nextcloud 1.10.3
> nextcloud 1.11.1
>
> Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen Upgradepfad von owncloud 1.8.1 auf
> nextcloud 1.11.1?
prinzipiell sollte es wieder möglich sein von der kommenden
ownCloud-Paketversion v1.11.1 auf die Nextcloud-Paketversion
v1.11.2-Paket zu migrieren.
Ich beabsichtige neue Pakete zu veröffentlichen, sobald dass Nextcloud
20.0.5 veröffentlicht wurde. Aus diesem Grund bitte ich Dich noch um
etwas Geduld bevor Du dich an eine Migration wagst.
> Derzeit und seit Monaten läuft owncloud 1.8.1 fehlerfrei. Zeitmangel und früheres Upgradeproblem [2] haben
> mich von Updates/-grades und Umstieg auf nextcloud abgehalten.
>
> Laut Paketsuche gibt es derzeit folgende eigen- und nächst- Wolken im Angebot:
> owncloud 1.9.3
> owncloud 1.10.2
> owncloud 1.11.0
> nextcloud 1.9.5
> nextcloud 1.10.3
> nextcloud 1.11.1
>
> Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen Upgradepfad von owncloud 1.8.1 auf
> nextcloud 1.11.1?
ownCloud-Paketversion v1.11.1 auf die Nextcloud-Paketversion
v1.11.2-Paket zu migrieren.
Ich beabsichtige neue Pakete zu veröffentlichen, sobald dass Nextcloud
20.0.5 veröffentlicht wurde. Aus diesem Grund bitte ich Dich noch um
etwas Geduld bevor Du dich an eine Migration wagst.
Juergen Edner
Jan 12, 2021, 3:32:37 AM1/12/21
to
Hallo Marcus,
>> Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen
>> Upgradepfad von owncloud 1.8.1 auf nextcloud 1.11.1?
>
> Muss man wirklich von owncloud auf nextcloud migieren?
>
> Anders als bei OpenOffice vs. LibreOffice odr OpenElec vs. LibreElec, bei
> den das zum "Untergang" der Open-Varianten geführt hat, sind sowohl own-
> als auch nextcloud in aktiver Entwicklung.
dies mag sicherlich sein, jedoch kommt es auch immer darauf an in welche
Richtung sich ein Programm entwickelt, welche Funktionen es bietet und
wie dynamisch die Entwicklung ist. Hier sehe ich persönlich eine höheren
Einbindung der Community, mehr Dynamik und eine größere Funktionsbreite
bei dem Nextcloud-Projekt - aber dies liegt wie immer im Auge des
Betrachters.
Da ownCloud zukünftig von PHP zu GO als Plattform wechseln wird, habe
ich auch noch nicht entschieden, ob ich das Paket zukünftig weiter
pflegen werde, da dies vermutlich eine sehr große Überarbeitung des
Paketes erfordert. Darüber hinaus nutze ich persönlich Nextcloud ;-)
>> Hat jemand einen Tipp/eine Empfehlung/Anleitung zum erfolgreichen
>> Upgradepfad von owncloud 1.8.1 auf nextcloud 1.11.1?
>
> Muss man wirklich von owncloud auf nextcloud migieren?
>
> Anders als bei OpenOffice vs. LibreOffice odr OpenElec vs. LibreElec, bei
> den das zum "Untergang" der Open-Varianten geführt hat, sind sowohl own-
> als auch nextcloud in aktiver Entwicklung.
Richtung sich ein Programm entwickelt, welche Funktionen es bietet und
wie dynamisch die Entwicklung ist. Hier sehe ich persönlich eine höheren
Einbindung der Community, mehr Dynamik und eine größere Funktionsbreite
bei dem Nextcloud-Projekt - aber dies liegt wie immer im Auge des
Betrachters.
Da ownCloud zukünftig von PHP zu GO als Plattform wechseln wird, habe
ich auch noch nicht entschieden, ob ich das Paket zukünftig weiter
pflegen werde, da dies vermutlich eine sehr große Überarbeitung des
Paketes erfordert. Darüber hinaus nutze ich persönlich Nextcloud ;-)
0 new messages