yumper
Goto Top

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

Content-ID: 598953

Url: https://administrator.de/contentid/598953

Printed on: December 3, 2024 at 10:12 o'clock

Lochkartenstanzer
Lochkartenstanzer Aug 25, 2020 at 15:55:12 (UTC)
Goto Top
Zitat von @yumper:

Alternativ die Frage - Never change a running system

Gibt es für Euch einen triftigen Grund, die GitLab-Version zu wechseln?

lks
yumper
yumper Aug 25, 2020 at 15:59:29 (UTC)
Goto Top
Zitat von @Lochkartenstanzer:

Zitat von @yumper:

Alternativ die Frage - Never change a running system

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
Mit Ubuntu 2004 LTS läuft die Sache nicht mehr

so long

Yumper
GNULinux
GNULinux Aug 25, 2020 updated at 16:09:06 (UTC)
Goto Top
Zitat von @Lochkartenstanzer:
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.
Lochkartenstanzer
Lochkartenstanzer Aug 25, 2020 at 16:09:01 (UTC)
Goto Top
Zitat von @yumper:

Zitat von @Lochkartenstanzer:

Zitat von @yumper:

Alternativ die Frage - Never change a running system

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. face-smile
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
Lochkartenstanzer
Lochkartenstanzer Aug 25, 2020 at 16:13:27 (UTC)
Goto Top
Zitat von @GNULinux:

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
NetzwerkDude
NetzwerkDude Aug 25, 2020 at 16:30:45 (UTC)
Goto Top
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 face-smile

https://git-scm.com/book/de/v2/Git-Grundlagen-Ein-Git-Repository-anlegen
yumper
yumper Aug 25, 2020 at 16:49:34 (UTC)
Goto Top
Hallo

extern auf git portal geht wegen VSNFD nicht.

Denke werde auf Ubuntu 1804 Downgraden.

Backup ist dank Hyper-V VM kein Problem

so long

Yumper
NetzwerkDude
NetzwerkDude Aug 25, 2020 at 19:24:25 (UTC)
Goto Top
ein internes git repository ist ein beliebiger server mit ssh zugang - nicht zu verwechseln mit git hub
yumper
yumper Aug 26, 2020 at 11:36:47 (UTC)
Goto Top
Zitat von @NetzwerkDude:

ein internes git repository ist ein beliebiger server mit ssh zugang - nicht zu verwechseln mit git hub

Hallo

Unser Gitlab CE ist ein internes Github mit Zugang über Port 80/443

Mein Fazit

So lange es läuft wird nichts geändert. Da alles abgeschottet vom Internet läuft kann ich auf Securityupdates verzichten.
Haben ja mit einer internen Access 2003 Datenbank das gleiche Problem. Die komplizierten Versionsipgrades sind ein echter Nachteil.
Bei Jira/Conference ist das wesentlich besser gelöst. Man stelle sich nur vor es wäre bei Excel auch so face-sad

So long

Yumper
GNULinux
GNULinux Sep 05, 2020 at 11:00:58 (UTC)
Goto Top
Zitat von @yumper:
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.

Zitat von @yumper:
extern auf git portal geht wegen VSNFD nicht.

Und dann hostet ihr das auf uralter EOL Software die auch zukünftig vor sich hin gammeln wird - wie geil, made my day! face-big-smile
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.
yumper
yumper Feb 14, 2021 at 18:39:47 (UTC)
Goto Top
Zitat von @GNULinux:

Zitat von @yumper:
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.

Zitat von @yumper:
extern auf git portal geht wegen VSNFD nicht.

Und dann hostet ihr das auf uralter EOL Software die auch zukünftig vor sich hin gammeln wird - wie geil, made my day! face-big-smile
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.

Hallo

es ist ja auch im internen Netz per Firewall geregelt, wer diesen Server erreichen kann.

So long

Yumper
GNULinux
GNULinux Feb 16, 2021 at 08:08:10 (UTC)
Goto Top
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.

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 face-wink
yumper
yumper Feb 17, 2021 updated at 23:46:35 (UTC)
Goto Top
Zitat von @GNULinux:

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.

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 face-wink

Hallo

die Sache klärt sich eh bald

Das Projekt in dem Gitlab eingesetzt wurde ist abgeschlossen. Die ganze Abteilung wird um organisiert / verlagert. Es gibt dann niemanden mehr der darauf zugreift

so long

Yumper