Seite 6 von 6 ErsteErste ... 456
Ergebnis 51 bis 59 von 59
  1. #51
    Anwender
    Registriert seit
    12.04.2016
    Beiträge
    510

    Standard

    Top-Arbeit raffnix! Gute Idee auf der Arbeit von Synology aufzusetzen und es einfach besser (aktueller) zu machen!

  2. #52

    Standard

    Moin, muss diesen Thread mal wieder reanimieren. Hatte die letzten Tage ein Problem mein Gitlab zu aktualisieren. Nach mehrmaligen Einspielen des Backups und Auffinden diverser logs kann ich den Fehler nun eingrenzen.

    Ich hab wie in der Vergangenheit in der docker-compose.yml die Versionsnummer für gitlab und postgresql erhöht, und staunte nicht schlecht, als ich eine jungfräuliche Gitlab Installation vorfand.

    Was war geschehen: beim Sprung von postgresql Version 9.6-2 auf 10 wurde die Datenbank nicht korrekt übertragen :-(
    Ich hab inzwischen eine Kombi aus Gitlab 11.4.0 und postgresql 9.6-2 am laufen.

    Wie bekomme ich die postgresql auf 10? Ich bräuchte einen wink mit dem Zaunpfahl...

    Anbei logs aus dem postgresql Verzeichnis des Dockerordners

    Code:
    -----------------------------------------------------------------
      pg_upgrade run on Sun Oct 28 17:43:02 2018
    -----------------------------------------------------------------
    
    command: "/usr/lib/postgresql/10/bin/pg_dumpall" --host /var/lib/postgresql --port 50432 --username postgres --globals-only --quote-all-identifiers --binary-upgrade  -f pg_upgrade_dump_globals.sql >> "pg_upgrade_utility.log" 2>&1
    Code:
    -----------------------------------------------------------------
      pg_upgrade run on Sun Oct 28 17:43:02 2018
    -----------------------------------------------------------------
    
    command: "/usr/lib/postgresql/9.6/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/9.6/main" -o "-p 50432 -b -c config_file=/var/lib/postgresql/9.6/main/postgresql.conf --hba_file=/var/lib/postgresql/9.6/main/pg_hba.conf --ident_file=/var/lib/postgresql/9.6/main/pg_ident.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "pg_upgrade_server.log" 2>&1
    waiting for server to start....LOG:  database system was shut down at 2018-10-28 17:27:45 UTC
    LOG:  MultiXact member wraparound protections are now enabled
    LOG:  database system is ready to accept connections
     done
    server started
    
    
    command: "/usr/lib/postgresql/9.6/bin/pg_ctl" -w -D "/var/lib/postgresql/9.6/main" -o "-c config_file=/var/lib/postgresql/9.6/main/postgresql.conf --hba_file=/var/lib/postgresql/9.6/main/pg_hba.conf --ident_file=/var/lib/postgresql/9.6/main/pg_ident.conf" -m smart stop >> "pg_upgrade_server.log" 2>&1
    waiting for server to shut down...LOG:  received smart shutdown request
    .LOG:  shutting down
    LOG:  database system is shut down
     done
    server stopped
    
    
    command: "/usr/lib/postgresql/10/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/10/main" -o "-p 50432 -b -c synchronous_commit=off -c fsync=off -c full_page_writes=off -c config_file=/var/lib/postgresql/10/main/postgresql.conf --hba_file=/var/lib/postgresql/10/main/pg_hba.conf --ident_file=/var/lib/postgresql/10/main/pg_ident.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "pg_upgrade_server.log" 2>&1
    waiting for server to start....2018-10-28 17:43:07.983 UTC [1418] FATAL:  data directory "/var/lib/postgresql/10/main" has group or world access
    2018-10-28 17:43:07.983 UTC [1418] DETAIL:  Permissions should be u=rwx (0700).
     stopped waiting
    pg_ctl: could not start server
    Examine the log output.
    Code:
    -----------------------------------------------------------------
      pg_upgrade run on Sun Oct 28 17:43:02 2018
    -----------------------------------------------------------------
    
    Performing Consistency Checks
    -----------------------------
    Checking cluster versions                                   ok
    Checking database user is the install user                  ok
    Checking database connection settings                       ok
    Checking for prepared transactions                          ok
    Checking for reg* data types in user tables                 ok
    Checking for contrib/isn with bigint-passing mismatch       ok
    Checking for invalid "unknown" user columns                 ok
    Creating dump of global objects                             ok
    Creating dump of database schemas
                                                                ok
    
    *failure*
    Consult the last few lines of "pg_upgrade_server.log" for
    the probable cause of the failure.
    
    connection to database failed: could not connect to server: No such file or directory
    	Is the server running locally and accepting
    	connections on Unix domain socket "/var/lib/postgresql/.s.PGSQL.50432"?
    could not connect to target postmaster started with the command:
    "/usr/lib/postgresql/10/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/postgresql/10/main" -o "-p 50432 -b -c synchronous_commit=off -c fsync=off -c full_page_writes=off -c config_file=/var/lib/postgresql/10/main/postgresql.conf --hba_file=/var/lib/postgresql/10/main/pg_hba.conf --ident_file=/var/lib/postgresql/10/main/pg_ident.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start
    10 Jahre Synology@home
    DS216+II - 8GB RAM (DSM 6.1.6 - 15266), DS111 (DSM 6.1.6-15266), DS107+ (DSM 3.1-1638 - ausgemustert)

  3. #53
    Anwender
    Registriert seit
    18.11.2012
    Beiträge
    31

    Standard

    Hi,

    hast du schon versucht ein GilLab Backup zu machen, dann einen Clean Install mit der 11.4.0 + PSQL 10 und dann den Restore?

    Backup (CRON=1 => no info output): /volume1/docker/gitlab/backups
    Code:
    sudo /usr/local/bin/docker exec -it synology_gitlab bash -c "sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1"
    Restore:
    Code:
    /usr/local/bin/docker exec -it synology_gitlab bash -c "sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production BACKUP=<timestamp_of_backup>"
    Quelle: https://docs.gitlab.com/ee/raketasks...p_restore.html

    Gruss

  4. #54

    Standard

    Aha, das wäre ein Weg - muss ich mich mal einlesen. Ich verwende nicht das Synology gitlab Paket, sondern den weiter vorne beschriebenen sameersbn Ansatz.

    Danke, Alexander
    10 Jahre Synology@home
    DS216+II - 8GB RAM (DSM 6.1.6 - 15266), DS111 (DSM 6.1.6-15266), DS107+ (DSM 3.1-1638 - ausgemustert)

  5. #55
    Anwender
    Registriert seit
    18.11.2012
    Beiträge
    31

    Standard

    Zitat Zitat von xelarep Beitrag anzeigen
    Aha, das wäre ein Weg - muss ich mich mal einlesen. Ich verwende nicht das Synology gitlab Paket, sondern den weiter vorne beschriebenen sameersbn Ansatz.

    Danke, Alexander
    synology_gitlab ist hier der container name, dir kann natürlich abweichen. Das Synology Paket verwendet auch das sameersbn/gitlab image, daher sollten die obigen Befehle mit Anpassung des Containernamen klappen.

  6. #56
    Anwender
    Registriert seit
    20.09.2018
    Beiträge
    13

    Standard

    Hi raffnix84,

    gerne würde ich das aktuellere GitLab Paket von dir (https://github.com/jboxberger/synology-gitlab) nutzen. Von Synology selbst wird anscheinend ja kein Update mehr geliefert :/

    Ich hätte eine oder mehrere (dumme) Fragen zur Installation. Auf der GitHub-Seite steht, das man das SPK über die "Standard" Synology GitLab Installation bügeln kann.

    This is an upgraded and improved GitLab package which uses the stock Synology Package from Synology Repo and can be installed over the original package.

    Da ich schon viel Ärger mit dem wiederherstellen meiner GitLab-Daten hatte, wollte ich zur Sicherheit nochmals Nachhaken ..

    - Das SPK kann einfach über das Paketzentrum über den Button "Manuelle Installation" installiert werden? Wird dann das bestehende DockerImage wie bei einem Stock-Update aktualisiert?
    - Was würde passieren, wenn es wieder ein "Offizielles" Update über Synology gibt? Würden solche Updates überhaupt noch angezeigt werden? Wenn ja, wahrscheinlich keinesfalls Updaten..?

    Danke für ein kurzes Feedback


    Gruß,
    Fox

  7. #57
    Anwender
    Registriert seit
    18.11.2012
    Beiträge
    31

    Standard

    Hi Fox,

    du kannst von einem Standard Paket direkt zu dem modifizierten Paket upgraden. Ich teste hier 3 Update Szenarien vor dem Upload.
    1) Stock 9.4.4-0050 to Mod: https://github.com/jboxberger/synolo...44-0050-to-mod (maria_db zu psql migration erfolgt automatisch)
    2) Stock 11.0.4-0053 to Mod: https://github.com/jboxberger/synolo...04-0053-to-mod
    3) Und natürlich untereinander.

    Misstrauen und Vorsicht sind bei so einer wichtigen Infrastruktur gesund daher gilt wie immer "BACKUP, BACKUP, BACKUP und nochmals BACKUP"
    BACKUP: https://github.com/jboxberger/synology-gitlab#backup
    RESTORE: https://github.com/jboxberger/synology-gitlab#restore
    Für die ganz vorsichtigen besteht noch die Möglickeit einen mysql/psql dump und die gitlab ordner zu sichern.

    Zitat Zitat von Fox7 Beitrag anzeigen
    - Das SPK kann einfach über das Paketzentrum über den Button "Manuelle Installation" installiert werden? Wird dann das bestehende DockerImage wie bei einem Stock-Update aktualisiert?
    Genau, mein Packet macht nichts anderes, ich nutze die originalen srkipte von synology und habe die lediglich um ein paar kleine Features wie z.B. das behalten der ENVIRONMENT Variablen erweitert.
    Bei der Manuellen Installation muss du allerdings eine Einstellung vornehmen dass du auch Paketen ohne Signatur vertraust. Das sagt dir dann das DSM aber auch.

    Zitat Zitat von Fox7 Beitrag anzeigen
    - Was würde passieren, wenn es wieder ein "Offizielles" Update über Synology gibt? Würden solche Updates überhaupt noch angezeigt werden? Wenn ja, wahrscheinlich keinesfalls Updaten..?
    Ja das Update wird dann ganz normal im DSM angezeigt werden und kann auch installiert werden. Von meiner Seite aus funktioniert das ohne Probleme, da lege ich auch Wert darauf. Keiner soll von mir und meinem Update Zyklus abhängig sein. Wenn Synology eine höhere Version als meine raus bringt sollte es funktionieren auch wenn sie alles auf links drehen würde. Da mein Paket dem original entspricht müsste auch das neue Paket die Migration problemlos durchführen können, sonst hätten die auch das Problem vom Stock 11.0.4-0053 auf ihr neues Paket zu migrieren.

    Bei der Migration werden deine Daten nicht angefasst, Nach der Installation geht GitLab selbst hin und schaut sich die DB Version an und zieht die notwendigen Schema Updates nach. Ich denke das es Problematisch sein kann wenn du z.B. ein downgrade versuchst von 11.9.8-0053 auf Stock 11.0.4-0053. Ich denke hier wird das DSM meckern und ich könnte mir auch vorstellen dass es mit GitLab Probleme geben könnte, allerdings besteht durch die die inkrementellen schema updates sogar eine reale chance das dein downgrade lauffähig wäre.

    Wenn du vor jeder Migration und Update ein oder zwei Backups machst bist du auf der sicheren Seite. Ich hatte auch schon ab und zu den Fall dass GitLab selbst die schema updates vermasselt hat, seit dem teste ich das ganze immer und so ein Gitlab 10 mal zu installieren/deinstallieren kostet viel Zeit :-).

    Ich werde am Wochenende das Paket auf 11.10.4 (oder neuer hochziehen), wenn du noch also ein bis zweit Tage warten willst kannst du direkt die neue Version mitnehmen.

    Gruss

  8. #58
    Anwender
    Registriert seit
    20.09.2018
    Beiträge
    13

    Standard

    Hi raffnix84,

    zunächst einmal vielen Dank für deine schnelle Antwort! Backups werden seit meinem letzten Problemen mit GitLab / Syno-Update mittlerweile täglich erstellt. Da habe ich aus meinen Fehlern definitiv gelernt.

    Ansonsten bleibt mir nur zu sagen wie Hammergeil ich es finde, dass sich jemand solche Mühe gibt ein solches Paket für die "Allgemeinheit" zu erstellen und dieses auch noch up-to-date zu halten! Vielen Dank!!


    Momentan habe ich die letzte Version von GitLab installiert, die man über die normalen Synology-Updates bekommt. (11.0.4-0053). Ich warte gerne noch die nächsten Tage ab um mir deine 11.10.4 zu laden.




    Gruß,
    Fox

  9. #59
    Anwender
    Registriert seit
    20.09.2018
    Beiträge
    13

    Standard

    Hi raffnix84,

    leider komme ich erst jetzt dazu dein Paket zu installieren. Vor einigen Sekunden ist mir noch eine DSM Aktualisierung und ein paar Aktualisierungen für installierte Pakete aufgeploppt.

    DSM 6.2.2. hab ich installiert, alle Aktualisierungen zu den Paketen auch ... bis auf eine GitLab Aktualisierung. Hier gibt es ein "gewaltiges" Update von 11.0.4-0053 auf 11.0.4-0054.

    Dieses werde ich natürlich nicht installieren und stattdessen dein Paket verwenden. Jedoch hätte ich eine Frage zu deinen Versionsnummern. Warum hast du bei deinen Paketen auch stehts "-0053" verwendet? Hat das einen besonderen Grund?


    Gruß,
    Fox

Seite 6 von 6 ErsteErste ... 456

Ähnliche Themen

  1. Wie DVBLink über https:// erreichbar machen?
    Von Tommes im Forum Video Station
    Antworten: 13
    Letzter Beitrag: 20.12.2015, 15:02
  2. DSM Update: Webstation über HTTPs von extern nicht mehr erreichbar
    Von mike399845 im Forum Disk Station Manager
    Antworten: 27
    Letzter Beitrag: 26.03.2015, 13:05
  3. phpMyAdmin von extern über https nicht erreichbar
    Von Daniel85 im Forum Webserver
    Antworten: 6
    Letzter Beitrag: 02.10.2013, 14:59
  4. Antworten: 0
    Letzter Beitrag: 22.10.2012, 20:12
  5. MySQL von extern erreichbar machen
    Von TopTobi im Forum Sonstiges
    Antworten: 2
    Letzter Beitrag: 12.07.2012, 14:59

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •