Gitlab Update

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.

Wieso 1909? Man setzt für sowas nur LTS ein, also 1804 wenn 2004 nicht geht.
Einfach ein downgrade von 1909 auf 1804 machen.



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

Wenn man die Kiste gut abschottet, kann man auch mit 1909 noch eine Weile leben.


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

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

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.

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