Gitlab Update
Hallo
bereits nach 2 Jahren ist unser Gitlab Server hoffnungslos veraltet
Im Einsatz
Ubuntu 1909
Postgre 9.6
Gitlab CE V11
6 Projekte 4 User 1,3 GB Daten.
Die Sache ist also sehr überschaubar
Frage kann ich die Projekte mittels einem Client herunter laden und exportieren. Das aktuellste Gitlab neu installieren. Die 4 User neu anlegen und die Projekte mittels Client wieder einspielen.
Alternativ die Frage - Never change a running system
Ich kann mir auch ein resultierendes Projekt für einen Freelancer in München vorstellen
so long
yumper
bereits nach 2 Jahren ist unser Gitlab Server hoffnungslos veraltet
Im Einsatz
Ubuntu 1909
Postgre 9.6
Gitlab CE V11
6 Projekte 4 User 1,3 GB Daten.
Die Sache ist also sehr überschaubar
Frage kann ich die Projekte mittels einem Client herunter laden und exportieren. Das aktuellste Gitlab neu installieren. Die 4 User neu anlegen und die Projekte mittels Client wieder einspielen.
Alternativ die Frage - Never change a running system
Ich kann mir auch ein resultierendes Projekt für einen Freelancer in München vorstellen
so long
yumper
Please also mark the comments that contributed to the solution of the article
Content-ID: 598953
Url: https://administrator.de/contentid/598953
Printed on: December 3, 2024 at 10:12 o'clock
13 Comments
Latest comment
Gibt es für Euch einen triftigen Grund, die GitLab-Version zu wechseln?
lks
Zitat von @Lochkartenstanzer:
Gibt es für Euch einen triftigen Grund, die GitLab-Version zu wechseln?
Gibt es für Euch einen triftigen Grund, die GitLab-Version zu wechseln?
Das EOL von Ubuntu 19 sollte schon triftig genug sein, wenigstens mal das Betriebssystem zu upgraden. Wobei ich mich an der Stelle frage, warum ihr nicht zur LTS Version gegriffen habt. Die bietet 5 Jahre Updates, bei den Zwischenreleases wie 19 lediglich 9 Monate. Daher würde ich die nur auf Desktops einsetzen und auch dort nur dann, wenn man etwas daraus braucht.
Man sollte grundsätzlich wenigstens EOL Software rechtzeitig migrieren und Sicherheitsupdates zeitnah einspielen. Ansonsten handelt man grob fahrlässig und setzt sich sowie die Benutzer einem erhöhten Sicherheitsrisiko aus.
Zitat von @yumper:
Nein - Gitlab läuft fehlerfrei
Ubuntu 1909 meckert halt bei jedem Login
Zitat von @Lochkartenstanzer:
Gibt es für Euch einen triftigen Grund, die GitLab-Version zu wechseln?
lks
Gibt es für Euch einen triftigen Grund, die GitLab-Version zu wechseln?
lks
Nein - Gitlab läuft fehlerfrei
Ubuntu 1909 meckert halt bei jedem Login
Wieso 1909? Man setzt für sowas nur LTS ein, also 1804 wenn 2004 nicht geht.
Einfach ein downgrade von 1909 auf 1804 machen.
Mit Ubuntu 2004 LTS läuft die Sache nicht mehr
Das ist die Krux, wenn man kein LTS einsetzt.
Läuft also darauf hinaus, daß Du wegen des Supportendes von 1909 entweder auf 2004 upgraden (und GitLAB mit hochziehen) oder auf 1804 downgraden mußt.
Ich persönlich halte von 2004 (sowohl windows als auch Ubuntu) nicht viel und würde eher ubuntu downgraden als GitLAb upgraden. Oder zu debian stable wechseln.
Bei Deinem überschaubaren gitlab-Umfang würde ich ein backup ziehen und mit apt upgraden, wie hier beschrieben.
lks
Zitat von @GNULinux:
Das EOL von Ubuntu 19 sollte schon triftig genug sein, wenigstens mal das Betriebssystem zu upgraden.
Das EOL von Ubuntu 19 sollte schon triftig genug sein, wenigstens mal das Betriebssystem zu upgraden.
Wenn man die Kiste gut abschottet, kann man auch mit 1909 noch eine Weile leben.
Wobei ich mich an der Stelle frage, warum ihr nicht zur LTS Version gegriffen habt. Die bietet 5 Jahre Updates, bei den Zwischenreleases wie 19 lediglich 9 Monate. Daher würde ich die nur auf Desktops einsetzen und auch dort nur dann, wenn man etwas daraus braucht.
Ich würde auch bei Desktops wirklich nur in Ausnahmefällen zu den Zwischenreleases greifen. Die Dinger sind nichts anderes als Alpha- oder Betaversionen.
lks
Hi,
wenn es so überschaubar ist, gilt es ggf. das ganze einfach auf git zu portieren falls ihr "nur" die basisfeatures von git (also alles was versionskontrolle ist) nutzt.
Im zweifel kommt git mit "irgend" einen ssh zugang aus
https://git-scm.com/book/de/v2/Git-Grundlagen-Ein-Git-Repository-anlegen
wenn es so überschaubar ist, gilt es ggf. das ganze einfach auf git zu portieren falls ihr "nur" die basisfeatures von git (also alles was versionskontrolle ist) nutzt.
Im zweifel kommt git mit "irgend" einen ssh zugang aus
https://git-scm.com/book/de/v2/Git-Grundlagen-Ein-Git-Repository-anlegen
Zitat von @yumper:
So lange es läuft wird nichts geändert. Da alles abgeschottet vom Internet läuft kann ich auf Securityupdates verzichten.
So lange es läuft wird nichts geändert. Da alles abgeschottet vom Internet läuft kann ich auf Securityupdates verzichten.
Weitläufiger Irrglaube. Sobald ein Angreifer im Netz ist, hat er mit solchen nicht gepflegten Systemen oft den Jackpot. Vor allem in ein paar Monaten oder Jahren, wenn es noch mehr Exploits gibt. Und ins Netz kommen Angreifer leichter als gedacht. Spätestens bei einem wirklich gezielten Angriff oft nur eine Frage der Zeit.
Solche Risiken bewusst zu ignorieren halte ich für grob fahrlässig. Aber gut, deine Entscheidung - du haftest ja auch, wenn das Teil mal missbraucht wird. Oder auch schlicht und einfach nicht mehr läuft und du keinerlei Unterstützung bekommst, weil die alte Version auch in der Community keiner mehr nutzt. Ist ja nicht so, als geht es dabei "nur" um die Angriffsfläche, auch wenn das ein wichtiger Faktor ist bzw. sein sollte. Alte Software zieht einen Rattenschwanz von potenziellen Problemen mit sich.
Und dann hostet ihr das auf uralter EOL Software die auch zukünftig vor sich hin gammeln wird - wie geil, made my day!
On-Prem Hosting ist die Grundlage für Datenschutz, nicht das alleinige Erfolgsrezept. Wenn die On-Prem Software nicht gepflegt wird, kippt der Sicherheitsgewinn schnell wieder.
Zitat von @yumper:
Hallo
es ist ja auch im internen Netz per Firewall geregelt, wer diesen Server erreichen kann.
Hi, das reduziert die Angriffsfläche je nach Umständen etwas, aber eben nur etwas. Denn es werden ja nach wie Leute darauf Zugriff haben und auch damit aktiv arbeiten. Gerade ein CI Server und Entwickler stehen schon per se im Angriffsfokus. Ich halte solche Workarounds nur in Ausnahmefällen für vertretbar, wenn es keine vernünftige Lösung gibt (z.B. Maschinen-PCs) und der Zugriff auf ein Minimum reduziert wird. In dem Fall gibt es die aber, GitLab ist sogar OS und frei verfügbar. In meinen Augen gibt es hier also keinen sinnvollen Grund, auf Updates zu verzichten. Nur die üblichen Ausreden.Hallo
es ist ja auch im internen Netz per Firewall geregelt, wer diesen Server erreichen kann.
Letztendlich brauchst du das hier auch nicht rechtfertigen, ich habe nur darauf hingewiesen, dass das hinsichtlich Sicherheit und Datenschutz nicht sinnvoll ist. Wenn ihr euch bewusst gegen gängige Sicherheitsstandards stellt ist das eure Entscheidung - ich als außenstehender kann da nur schmunzeln, denn ihr müsst ja auch mit den Konsequenzen leben, sobald es dadurch zu einem Angriff kommt