[Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)

Ralf Mattes rm at mh-freiburg.de
Mo Sep 11 23:00:59 CEST 2017


Am Montag, 11. September 2017 21:47 CEST, Urs Liska <ul at openlilylib.org> schrieb:

> > Das nistet sich hoffentlich dort ein wo Du es hinlegst.
>
> Nicht, wenn ich es per apt über das Package installiert habe.
> Tatsächlich liegt das Home-Verzeichnis und die Installation in
> /var/opt/gitlab :-O

Das ist dann aber kein offizielles Debian-Paket, oder? Das fände ich
dann aber schon eher unschön. Ursprünglich war '/opt' mal ein Bereich in
den der Admin unter kommerziellen Unixen Software hinlegen konnte ohne
dass die Installation des Herstellers  berührten. Unter Linux war das
eigentlich (dank GNUs configure & make & make install) eher unüblich,
da liegt so was unter /usr/local. Der Unterschied: beim GNU-Modell liegt
ein Softwarepaket vertreut über /usr/local/lib, /usr/local/bin, /usr/local/include,
im Vendor-Model gibt's für jede Software _ein_ Verzeichnis unter /opt.

> > Unter Debianoiden sollten Server inzwischen unter '/srv' liegen
> > (gaaanz früher gab's da das '/var/www' :-)
>
> Hm:
> https://wiki.debian.org/FilesystemHierarchyStandard sagt einerseits:
>     /srv/ => "Site-specific data which is *s*e*rv*ed by the system (Not
> part of FHS)."
> andererseits:
>     /var/ => "*Var*iable data, such as logs, databases, *websites*, and
> temporary spool (e-mail..) files"

Wie gesagt, /srv/ ist neuer (und Debian-spezifisch).

> Das habe ich vor. Ich überlege noch, ob ich bei der Gelegenheit die
> Daten von /var/www/vhosts auch nach /srv verschieben soll. Ich muss nur
> sehen, dass das auch tatsächlich funktioniert. nginx kann ich das leicht
> beibringen, ich weiß aber nicht, ob vielleicht in irgendwelchen Apps
> absolute Pfade hinterlegt sind. Na ja, ich muss das wohl erstmal als
> *Kopie* machen und dann alle Subdomains testen ...

Da das ja alles inzwischen Scripte sind reicht meist ein 'find -type f | xargs grep '/var/www'


> >
> > Wenn Du viele bestehende Nuter mit Schlüsseln hast dann melde Dich wegen der Migration.
>
> Darauf werde ich vielleicht zurückkommen. Es sind brutto 63 User, von
> denen aber sicher etliche bei der Gelegenheit rausfallen.

Gut, melde Dich einfach.

> Die andere
> Frage ist, ob man auch Issues bzw. Projekte von Gitlab importieren kann.
> Von den etwas mehr als 100 offenen Issues können sicher auch ein paar
> verloren gehen, aber eigentlich will man das ja auch nicht ...

Urgs, kniffelig. Aber ohne würde ich das nicht migrieren.

> <...>
> Nun ja, über die Omnibus-Packages ist die Installation eigentlich nicht
> wirklich aufwendig gewesen. Problematisch wurde es nur bei Updates, die
> i.d.R. nicht reibungslos abliefen. Dann gibt es keine verlässliche
> Dokumentation, sondern nur zahllose Tipps und Tricks, die für
> unterschiedliche Versionen total unterschiedlich sind, so dass man
> nichts damit anfangen kann.

Was mich an solchen Installationsmonstern eher schreckt ist nicht die eigentliche
Installation (da halte ich mich für recht fit) sondern der Administrationsoverhead.
Es ist ja inzwischen schreckliche Mode geworden dass so ziemlich jede Scriptsprache
und oft sogar die einzelnen Frameworks ihre eigenen Dependency Managers mitbringen
(npm für Node, composer für php, maven etc.)
Als Resultat hat man dann auf einem Server oft zig Versionen der gleichen Software.
Das ist bei Fulnerabilities ein echtes Problem. Die meisten Admins _wissen_ inzwischen
gar nicht mehr was sie in welchen Versionen am Laufen haben. Grausig.

Gruss RalfD




Mehr Informationen über die Mailingliste Flug