Gitlab_synology, ich krieg die Kriese

Status
Für weitere Antworten geschlossen.

dany

Benutzer
Mitglied seit
31. Mrz 2008
Beiträge
352
Punkte für Reaktionen
0
Punkte
22
Keine Ahnung was ich falsch mache, aber nach jedem grösseren Update ist mein Gitlab zerschossen. Dabei hat er dieses mal alle User gelöscht. Die Repos sind zwar da aber ohne die Benutzer etwas witzlos. Ich konnte die Repos importieren aber danach nicht auf einen anderen Namespace transferieren. Neu ist nun das gitlab_synology von MariaDB auf Postgresql migriert.

Eigentlich wollte ich gitlab als Sammel-Repo für meine Entwicklungen machen. Ich werde wohl auf gitlab von synology zukünftig verzichten da es mehr Problem (Beim Update) macht und mir die Zeit zu schade ist um es jedes mal wieder zu flicken.

Hat jemand die gleichen Erfahrungen gemacht?

Gruss Dany
 

MikeZulu

Benutzer
Mitglied seit
04. Mai 2016
Beiträge
101
Punkte für Reaktionen
2
Punkte
24
Hey Dani

Ich habe mir GitList unter der WebStation installiert (eigenes VirtualServer). Wollte diesbezüglich von Synology unabhängig sein. Funktioniert einwandfrei. Vielleicht wäre das auch etwas für dich.

Das mache ich wenn immer möglich mit Web-Applikationsn (z.B. COPS, MantisBT etc.) so. Auf diese Weise habe ich auch jeweils die aktuellsten Versionen. Synology ist ja teilweise nicht wirklich aktuell.
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
Ein Benutzer aus dem Forum hat das Synology Gitlab Paket genommen, es aufgemotzt und hält es nun aktuell: https://www.synology-forum.de/showt...t-GitLab/page5&p=768224&viewfull=1#post768224 Dort sind auch Migrationspfade beschrieben.

Altenativ einfach selber Gitlab als Container betreiben: https://www.synology-forum.de/showt...t-GitLab/page3&p=679836&viewfull=1#post679836

Letztes benutze ich mitlerweile seit Jahren ohne irgendwelchen Kummer. Das Gitlab-Image kann man eignetlich immer problemlos aktuallisieren. Beim wechsel des Postgres-Images muss beim Versionsupgrade ein Export gefahren und mit der neuen Datenbank importiert werden. Aber ehrlich gesagt aktuallisiere ich immer nur noch das Gitlab-Image...

Läuft! .. und die Version ist immer aktuell :)
 

dany

Benutzer
Mitglied seit
31. Mrz 2008
Beiträge
352
Punkte für Reaktionen
0
Punkte
22
hallo Zusammen

Ich habe für mich eine gute Lösung gefunden bei der ich gitlab mit gitea getauscht habe. (wurde schon hier im Forum erwähnt)
Das native Dockerimage ist schnell eingrichtet, Backup läuft und was soll ich sagen, es läuft auch bedeutend schneller.
Der Ressourcenverbrauch ist mit ca. 70Mb zu 2Gb wesentlicher geringer.

Wen interesse besteht kann ich meine Erkenntnisse ins Wiki eintragen.

Gruss Dany
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Hallo Zusammen,
ich habe jetzt das gleiche Fehlerbild wie dany.
Heute ein Update von GitLab über das Paketzentrum gemacht. Dabei ist auch die DB Postgresql 9.6 auf 10 Upgegradet worden. Super - Nur irgendwie hat die Migration nicht geklappt.
Alle Benutzer bzw. Einstellungen sind nun weg.

Die Repos sind noch da unter doker/GitLab/gitlab/..

Gibt es eine Möglichkeit das ich die DB-Migration wiederholen kann?
Unter docker/GitLab/postgresql/ gibt es nun zwei Verzeichnisse. Einmal "9.6" und einmal "10". Liegen im "9.6"-er Verzeichnis noch die alten Daten bzw. die alte Datenbank? Kann ich das irgendwie Retten?

Gruß,
Fox

P.S.: Ich bin so ein typischer Endanwender der doch nur will das es tut :/ - Wenn mir jemand eine Step-By-Step Anleitung geben könnte wie ich meine Daten Retten kann wäre ich sehr verbunden! ... Oder ob es überhaupt noch möglich ist irgendwas zu Retten.
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Eine Step-By-Step-Anleitung wäre das Einfachste ;) - Aber es ist ja nicht so, das ich nicht selbst versuche das Problem zu lösen. Leider sind meine Unix-Kenntnisse nicht wirklich ausgeprägt, was alles echt schwierig gestaltet.

Was ich bis jetzt herausgefunden habe:
- Im Postgresql-Container gibt es ein Programm namens pg_upgrade. Mit diesem Programm kann mal wohl eine Migration starten.
- Es wird immer das Programm der höheren postgresql Version verwendet. Also die Version auf die Migriert werden soll.
- Das Programm liegt unter: /usr/lib/postgresql/10/bin/pg_upgrade

Direkt in der Terminal-Console des Doker-Containers "synology_gitlab_postgresql" kann ich das Programm jedoch nicht starten. Er verweigert die Ausführung, da "root" hier anscheinend nicht ausführen darf. Mit sudo gehts auch nicht. Also habe ich mal weiter gegoogelt....

Als nächsten Schritt habe ich mit Putty auf die DiskStation selbst verbunden. Hier habe ich mich dann mit meinem Administratorkonto erfolgreich anmelden können.

- Nach weiterem googeln habe ich herausgefunden, das man mit den Befehlen...
sudo docker container start synology_gitlab_postgresql den gewünschten Docker-Container starten kann und mit "stop" wieder beenden kann. Ich habe den Container also gestartet um auf das pg_upgrade Progrämmchen zugreifen zu können

- Jetzt versuche ich mit docker exec -it synology_gitlab_postgresql /usr/lib/postgresql/10/bin/pg_upgrade -d /var/lib/postgresql/9.6/main -D /var/lib/postgresql/10/main die Migration zu starten. Leider ohne Erfolg :(

Fehler:
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http:// .......



Ich bin ich kein Stück weitergekommen. Ich komme mit diesen Berechtigungen einfach nicht klar und weiß nicht wie ich wo was einstellen muss ...

Mein nächster verzweifelte Versuch hat in der Windows-Welt stattgefunden:
Auf der Postgresql-Website habe ich mir die Sorucen für 9.6 und für 10 heruntergeladen. Versuche ich hier das pg_upgrade auszuführen komme ich schon einen Schritt weiter :) :) - Hier lässt sich bloß die DB für die Migration nicht starten:

Fehler:
C:\Users\Fox\Downloads\pgsql\bin>pg_upgrade -U postgres -d C:\Users\Fox\Downloads\pgsql\bin\postgresql\9.6\main -D C:\Users\Fox\Downloads\pgsql\bin\postgresql\10\main -b C:\Users\Fox\Downloads\pgsql9\bin -B C:\Users\Fox\Downloads\pgsql\bin
Führe Konsistenzprüfungen durch

Führe Konsistenzprüfungen durch
-------------------------------
Checking cluster versions ok

*failure*
Prüfen Sie die letzten Zeilen von »pg_upgrade_server_start.log« oder »pg_upgrade_server.log« für den
wahrscheinlichen Grund für das Scheitern.

Verbindung zur Datenbank fehlgeschlagen: konnte nicht mit dem Server verbinden: Connection refused (0x0000274D/10061)
Läuft der Server auf dem Host »localhost« :):1) und akzeptiert er
TCP/IP-Verbindungen auf Port 50432?
konnte nicht mit dem Server verbinden: Connection refused (0x0000274D/10061)
Läuft der Server auf dem Host »localhost« (127.0.0.1) und akzeptiert er
TCP/IP-Verbindungen auf Port 50432?

konnte nicht mit dem Postmaster für den alten Cluster verbinden, gestartet mit dem Befehl:
"C:\Users\Fox\Downloads\pgsql9\bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "C:\Users\Fox\Downloads\pgsql\bin\postgresql\9.6\main" -o "-p 50432 -b " start
Fehlgeschlagen, Programm wird beendet
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
Eine Step-By-Step-Anleitung wäre das Einfachste ;)
... das stimmt für den Helfenden aber nicht wirklich, oder?!!

Fehler:
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http:// .......

Als normaler Benutzer kann man Docker nicht von der Shell aus verwenden.

So wird man zu root:
Code:
sudo -i

Falls es dann immer noch nicht geht:
- downgrade auf die Version die noch ging; auf Dockerhub bei sameersbn/gitlab schauen wie die Rake-Befehle für Backup und Restore aussehen, Backup erzeugen
- upgrade auf die neue Version; Restore durchführen

Viel Erfolg!
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Nun ja, das ist natürlich wahr. Für den Helfenden ist es immer schwer jemandem zu Helfen der keine Ahnung hat ;) ;)
Deswegen vielen Dank für deine Tipps :)

sudo -i bringt leider nichts. Mit root darf ich anscheinend nicht Ausführen:

up_upgrade: cannot be run as root
Failure, exiting



Deinen Tipp mit dem Downgrade versuche ich später auch noch. Den Befehl zum Backup & Restore habe ich in einem anderen Forumsbeitrag schon gefunden.


Danke und Gruß,
Fox
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
up_upgrade: cannot be run as root
Failure, exiting

Dein Post von gestern ~ 9:00 ist ein typischer Fehler, weil das Docker Kommandozeilen-Werkzeug als nicht root verwendet wird.

Daraus habe ich abgeleitet, dass Du dich auf die Shell mit einem normalen User einloggst haben musst.
Um als normaler User root werden zu können muss man 'sudo -i' oder 'sudo -s' verwenden.

Dein Post von heute 9:24 ist für mich etwas irritierend. Mit welchem Benutzerkonto hat Du Dich eingelogged? als normaler User hätte das funktionieren müssen!!!
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
:confused: So langsam blick ich es einfach nicht mehr

Ich habe jetzt den Tipp verfolgt die alte GitLab Version zu installieren, um ein Backup anzufertigen. Als zweiten Schritt wollte ich aktuelle Version installieren und das Backup zurückspielen...

Auf der Synology-Download-Site http://archive.synology.com/download/Package/spk/Docker-GitLab/ habe ich mir die Version (9.4.4-0050) VOR der momentan Aktuellen (11.0.4-0053) heruntergeladen. Beim installieren des Paketes fragt mich der Wizzard nach Benutzername und Passwort für die Maria10-DB.
WHAT? Wieso denn jetzt MariaDB? Ich war bis dato der Meinung, das in meiner vorherigen Version bereits von MariaDB10 auf Postgresql9.6 umgezogen wurde.
Und vom letzten auf die jetzt aktuelle Version dann ein Upgrade von Postgresql9.6 auf Version 10 erfolgte, bei dem die Migration dann fehlschlug.

Wenn ich mich tatsächlich geirrt haben sollte, sprechen diese zwei Fakten aber für meinen bisherigen Gedankengang:
- Es gibt ein Verzeichnis für 9.6 und 10 auf der HDD (/doker/GitLab/gitlab/postgresql/..)
- In meiner MariaDB10 sind die Daten zu alt. Hier steht nur ein einziges Projekt in den Tabellen.

Sollte es also noch ein Paket zwischen 9.4.4-0050 und 11.0.4-0053 geben .... wo bekomme ich das her?
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
Ich kann dir nicht sagen wie das SPK auf der Syno funktionert. ich habe schon IMMER direkt das Image von Sameersbn genommen, da ich kein Bock auf die veralteten Versionen von Synology hatte. Sprich: ich kann dir nicht sagen wann welche SPK-Version welche Datenbank verwendet hat. Synology hat zwischen den beiden Versionen kein SPK released.

Insgesamt ergibt das Bild keinen Sinn (was nicht bedeutet das es nicht trotzdem so ist).
Wenn die Installation der Altenversion nicht zum Erfolg führt, dann ist dir der einfache weg wohl nicht vergönnt.

Dann würde ich dir Empfehlen bei der aktuellen Version und dem Migrationsversuch über das Kommandozeilen Werkzeug (wie von dir schon herausgefunden) zu bleiben. Dazu muss aber geklärt sein, warum du "docker exec" nicht verwenden kannst (siehe mein vorheriger Post).

Wenn das auch nicht zielführend ist, würde ich den Synology-Support an die Kandare nehmen. Dadurch, dass sie das SPK anbieten, müssen sie auch Support für Versions-Updates übernehmen.

Insgesamt wäre die Empfehlung dich komplett von dem SPK zu lösen und das Image von Sameersbn direkt zu verwenden oder besser noch Gitea statt Gitlab einzusetzen.
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Vielen Dank für die Hilfe! - Ich hab es jetzt tatsächlich geschafft :cool: ... Zumindest Teil1 "Backup-Restore"

Sollten sich Andere ebenfalls so schwer tun wie ich, hier mein Lösungsweg:

1. GitLab über das Paket-Zentrum zunächst wieder deinstallieren.
2. Den neuen (gemounteten) Ordner /docker/GitLab/postgresql/10 löschen.
(Hierbei handelt es sich um Datenverzeichnis: /var/lib/postgresql/10 )
3. Über Docker das Postgresql-Abbild in der alten Version herunterladen.
(In meinem Fall sameersbn/postgresql:9.6-2)
3.1. Den Namen des Containers habe ich "Postgresql96" genannt. Im Grunde ist der Name aber Jacke wie Hose.
3.2. Folgende Umgebungsvariablen habe ich dem Container hinzugefügt:
- DB_USER (Wert = gitlab_user)
- DB_PASS (Wert = gitlab_pass)
- DB_NAME (Wert = gitlab)
- DB_EXTENSION (Wert = pg_trgm)
3.3. Das Daten-Verzeichnis habe ich gemountet: docker/GitLab/postgresql <--> /var/lib/postgresql [rw]
4. Sofern noch nicht geschehen den Container starten
5. Zum Beispiel mit Putty auf die DiskStation verbinden (Egal mit welchem Benutzer)
6. Zum Root wechseln mit: sudo -i
7. Ein Backup der Alt-Daten anfertigen: docker exec {Containername-Alte-Postgresql-Version} pg_dumpall -U postgres > gitlabdump.sql
(Der Dump liegt dann im Daten-Verzeichnis: /docker/GitLab/postgresql)
8. Der Container kann nun heruntergefahren und wieder gelöscht werden.
9. Über das Paket-Zentrum GitLab installieren, aber nicht automatisch nach der Installation starten lassen.
10. Nach der Installation über die Putty-Verbindung den neuen Postgresql-Container aus der GitLab-Installation starten:
docker container start synology_gitlab_postgresql
11. Postgresql-Bash aufrufen: docker exec -it synology_gitlab_postgresql bash
12. Datensicherung zurückspielen: psql -U postgres < gitlabdump.sql
13. Nach Restore den Container manuell stoppen: docker container stop synology_gitlab_postgresql
14. GitLab über das Paket-Zentrum starten.


Beim Aufrufen von GitLab bekomme ich jedoch leider die Meldung "500 - Whoops, something went wrong on our end"
Laut meinem erneutem rumgegoogle könnte der Fehler mit irgendwelchen "Secret Keys" zu tun haben :confused: :confused:

Für einen erneuten Tipp wäre ich natürlich Dankbar! Natürlich google mal parallel weiter ...
 
Zuletzt bearbeitet:

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
Erst einmal gratulation zu Deiner Idee einen 9.6er Container für das Backup zu starten und es in den 10.0er Container einzuspielen.

Eignetlich war meine Hoffnung, dass Du den alten Gitlab Container "regulär" hoch bekommst und dann Dein Backup über die rake-Jobs aus dem Gitlab-Contaiener anstartest. Das exportiert nämlich die gesammten Daten von Gitlab und nicht nur die Datenbank.

Du kannst feststellen, ob die SECRETS bei dir vorhanden sind:
Code:
docker inspect {containername oder id des gitlab containers | jq '[.[] | .Config |.Env ]'

Dort sollten die Einträge für folgendes zu sehen sein:
- GITLAB_SECRETS_DB_KEY_BASE (eingeführt in 8.0.0) , wenn wenn weg oder geändert, können CI-Secrets nicht mehr verwendet werden.
- GITLAB_SECRETS_OTP_KEY_BASE (eingeführt in 8.11.0), wenn weg oder geändert: kein Login mehr auf Basis von 2FA möglich.
- GITLAB_SECRETS_SECRET_KEY_BASE (eingeführt in 8.11.0), wenn weg oder geändert, sind Passwort Wiederherstellungstoken in Emails ungültig, bzw. werden ersetzt.

Was Du dir aber nicht anzeigen lassen kannst ist, ob die SECRETS gleich geblieben sind.

Normalweise stellt Gitlab beim ersten Start fest, dass das Datenbank-Schema in der Version x.y.z vorliegt und feuert bei Bedarf Migrationsskripte ab.
Seit der Einführung der GITLAB_SECRETS habe ich eingetlich nichts mehr an meiner Konfiguration verändert und die Migrationen laufen jedes mal problemlos durch.
 
Zuletzt bearbeitet:

Tommi2day

Benutzer
Mitglied seit
24. Aug 2011
Beiträge
1.164
Punkte für Reaktionen
63
Punkte
68
Mir war das mit den Gitlab Containern auf die Dauer auch zu doof und bin auf eine echte VM umgestiegen. Man kann sich ein fertiges Image runterladen oder macht eine minimale Ubuntu installation, trägt das Gitlab Repository ein und installiert es sich nach seinen eigenen Vorstellungen, z.B. welche DB. Der Umstieg hat bei mir mit der in Gitlab integrierten Backup/Wiederherstellung funktioniert. Jetzt bekomme brauche ich nur noch apt update zu machen, wenn eine neue Version angezeigt wird.
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Das mit dem Fehler 500 habe ich nicht gerade biegen können.

Also bin ich wieder einen Schritt zurück und habe versucht eine alte GitLab Version (10.3.6) zu installieren. Nach einigem rumprobieren hat das auch geklappt. Danach konnte ich einen Backup über GitLab starten (sudo docker exec -it synology_gitlab /bin/bash /sbin/entrypoint.sh app:rake gitlab:backup:create)

Wenn ich mir das *.tar-File ansehe, sieht alles super aus. Die Postgresql9.6 Daten und die Repos selbst sind im Paket. YAY!


Nun bin ich wieder zu meiner aktuellen Version gewechselt und wollte den Restore (sudo docker exec -it synology_gitlab /bin/bash /sbin/entrypoint.sh app:rake gitlab:backup:restore) starten. Leider kam sofort die Ernüchterung: Der Restore schlägt fehl, da ich eine neuer Version von GitLab einsetze :mad: :mad:

GitLab version mismatch:
Your current GitLab version (11.0.4) differs from the GitLab version in the backup!
Please switch to the following version and try again:
version: 10.3.6



Jo super! Da kann ich schon ein Backup erstellen und nun das. Gibt es jetzt eine super tolle Migrationsroutine, die mir das Backup in die neue Version einlesen kann, oder ist dieses Backup absolut nutzlos?


Gruß,
Fox


Nachtrag:
Wenn ich GitLab deinstalliere und aus meiner Sicherung (Versionierung des Ordners /docker/GitLab) die Verzeichnisse vor dem GitLab-Paket-Update wiederherstelle und danach dann GitLab erneut installiere, steht im Protokoll des GitLab Containers:
gitlab already exists
Migrating database...
Clearing chache


Aber ich sehe absolut kein Ergebnis. In der angeblich migrierten Datenbank ist null Inhalt :/
 
Zuletzt bearbeitet:

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
Nun bin ich wieder zu meiner aktuellen Version gewechselt und wollte den Restore (sudo docker exec -it synology_gitlab /bin/bash /sbin/entrypoint.sh app:rake gitlab:backup:restore) starten. Leider kam sofort die Ernüchterung: Der Restore schlägt fehl, da ich eine neuer Version von GitLab einsetze :mad: :mad:

GitLab version mismatch:
Your current GitLab version (11.0.4) differs from the GitLab version in the backup!
Please switch to the following version and try again:
version: 10.3.6

Schöner, mist.. Das war mir nicht bewusst. Ich hatte Backup und Restore schon im Einsatz aber wohl innerhalb der selben GitLab version.
Sorry, ich hätte gedacht, dass dies von allen Lösungen die richtige und eleganteste sein sollte...


Nachtrag:
Wenn ich GitLab deinstalliere und aus meiner Sicherung (Versionierung des Ordners /docker/GitLab) die Verzeichnisse vor dem GitLab-Paket-Update wiederherstelle und danach dann GitLab erneut installiere, steht im Protokoll des GitLab Containers:
gitlab already exists
Migrating database...
Clearing chache


Aber ich sehe absolut kein Ergebnis. In der angeblich migrierten Datenbank ist null Inhalt :/

"Migration database" zeigt an, dass das Datenbank-Schema migriert wurde, NICHT das von einer Datenbank-Version auf eine andere migriert wurde.


Ich nehme an die "alte Version 10.3.6" hast Du direkt mit dem Sameersbn Image gesartet in Kombination mit der "alten" 9.6er Datenbank.
Sprich, wenn du bei der 9.6er Datenbank bleibst und auf das aktuelle Sameersbn Image aktualliserst? Dann würde "nur noch" die Datenbank-Migration auf 10.0 fehlen, oder?
 

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Ja, die Pakete habe ich direkt mit dem Sameersbn Image gestartet.
Das mit dem Backup ist echt frustrierend - Ich finde GitLab grundsätzlich echt super. Aber das man ein Backup nur in der gleichen Version zurückspielen kann ist echter Müll.

Ich verstehe auch nicht warum diese besch***ene Zwischenversion nicht mehr auf Synology herunterladbar bist. Im Changelog steht auch kein einziges Wort davon. Hier gibt es einen riesigen Sprung von 9.4.4 auf 11.0.4. Die Version dazwischen (10.6.4 laut Google Recherche) ist nirgendwo auffindbar. Dieses bräuchte ich als "Synology-SPK".

Ich hab jetzt mal probiert eine 9.4.4 zu installieren. Die Umgebungsvariablen des GitLab-Docker Containers von MariaDB auf meine Postgresql 9.6 umzuhängen und dann zu starten. Danach war mein Masterplan nochmal ein "Synology-Update" auf die aktuelle 11.0.4 durchzuführen. Sodass dieses Update auch meine Daten migriert....

Starten konnte ich die 9.4.4 mit Postgres 9.6 - allerdings bekomme ich auch hier den Error 500 beim aufrufen der Seite. Ein Backup via Bash funktioniert tadellos.
Ungeachtet dessen, das die Website den Fehler 500 wirft, habe ich das "Update" über das Paket-Zentrum gestartet.... Jedesmal wenn er die Docker Images heruntergeladen hat kommt allerdings "Update fehlgeschlagen" und er löscht alles wieder.


Mir geht langsam echt die Fantasie aus was ich noch probieren könnte um das wieder gerade zu biegen. Ich bin grundsätzlich ein Mensch der gern immer alles Updatet .. aber sollte ich das jemals wieder zum laufen bekommen werde ich diesen Sch**ß absolut unangetastet lassen.



Ich hab für heute genug ... mal sehen was mir morgen blödes einfällt, das ich noch nicht probiert habe ....
 

haydibe

Benutzer
Sehr erfahren
Mitglied seit
12. Apr 2016
Beiträge
1.468
Punkte für Reaktionen
356
Punkte
103
Ja, die Pakete habe ich direkt mit dem Sameersbn Image gestartet.
Das mit dem Backup ist echt frustrierend - Ich finde GitLab grundsätzlich echt super. Aber das man ein Backup nur in der gleichen Version zurückspielen kann ist echter Müll.

Ich verstehe auch nicht warum diese besch***ene Zwischenversion nicht mehr auf Synology herunterladbar bist. Im Changelog steht auch kein einziges Wort davon. Hier gibt es einen riesigen Sprung von 9.4.4 auf 11.0.4. Die Version dazwischen (10.6.4 laut Google Recherche) ist nirgendwo auffindbar. Dieses bräuchte ich als "Synology-SPK".

Laut GitLab Release Note (https://www.synology.com/de-de/releaseNote/Docker-GitLab) war der Sprung wirklich von 9.4.4 auf 11.0.4
Ich habe aber auch schon erlebt, dass andere SPKs mit Macken (damals irgend ein Docker page) wieder entfernt werden.

Zu deiner 10.6.4: kann es sein, dass Du die "gepimpte" Version von jboxberger verwendet hast?
https://github.com/jboxberger/synol...ynology-gitlab-jboxberger-aio-10.6.4-0100.spk
 
Zuletzt bearbeitet:

Fox7

Benutzer
Mitglied seit
20. Sep 2018
Beiträge
13
Punkte für Reaktionen
0
Punkte
0
Hmm. An der Diskstation ist alles aus über das Paket-Zentrum installiert worden. Von dem her würde ich deine Frage mit Nein beantworten.

Ich verstehe nur nicht warum Version 9.4.4. noch mit MariaDB10 arbeitet und in der nächsten Version eine Postgresql10 zum Einsatz kommt. Warum habe ich dann eine 9.6 überhaupt installiert bekommen?

Wie bereits zuvor erwähnt, habe ich rein inhaltlich in der MariaDB10 nicht die aktuellen GitLab-Datensätze stehen. Dort ist nur mein Startprojekt zu finden. In der Postgresql9.6 sind alle meine Projekte (Sind nur 3 + die Wiki-Repos).
Somit ist das für mich ein Indiz, das es wohl noch eine Version dazwischen gegeben haben muss. Diese ist aber nirgendwo dokumentiert. Als hätte ich mir alles eingebildet :(
Fakt ist jedoch das in meiner MariaDB10 nur ein Projekt rumdümpelt. Sprich - der Inhalt ist alt. In der durch Geisterhand installierten Postgresql9.6 hingegen ist mein aktueller GitLab Datenbestand.

Ist es mit geringem Aufwand möglich meine Repos, die auf der Festplatte liegen, in das neu installierte (leere) GitLab zu importieren? Dann fehlen mir zwar die Benutzer und Einstellungen - aber diese muss ich dann halt per Hand wieder neu konfigurieren.
Ich sehe auf der GitLab-WebSite nur die Möglichkeit Repos zu Importieren, die zuvor auch über GitLab exportiert wurden. Gibt es denn keine Möglichkeit einfach das Verzeichnis /docker/GitLab/gitlab/repositories/.. komplett importieren zu lassen?

Nachtrag:
Die Antwort zu meiner Frage konnte ich ziemlich schnell herausfinden und erfolgreich testen:

Einfach die Repositories in ein anderes Verzeichnis verschieben: /docker/GitLab/gitlab/repositories --> /docker/GitLab/gitlab/repositoriestoimport und dann z.B. über die GitLab Docker Console folgenden Befehl für den Import verwenden: sudo -u git -H bundle exec rake gitlab:import:repos['/home/git/data/repositoriestoimport/'] RAILS_ENV=production

Den Rest werde ich händisch wieder konfigurieren. Hauptsache die Repos sind wieder online.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat