Am 11.09.2017 um 23:00 schrieb Ralf Mattes:
Am Montag, 11. September 2017 21:47 CEST, Urs Liska
<ul(a)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?
Nein, Omnibus ist ein System, um Ruby-Anwendungen in Pakete zu pressen.
Nach der Installation wird das aber per apt upgrade (und vorher update)
verwaltet.
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).
Mein Link war auch Debian-spezifisch, und es war eben unter /var
ebenfalls noch "Websites" gelistet. Aber ich werde hier nicht auf den
alten Zöpfen beharren - das /var/www/vhosts passte mir sowieso irgendwie
nicht, zumal die "vhosts" AFAICS auch sehr nach Apache riecht und daher
sowieso nicht mehr so richtig passt.
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'
Ich habe es schon probiert, den gesamten Ordner mit "cp -a" kopiert und
dann die base-Adresse per sed nur in den nginx-Dateien geändert. Nach
meinem ersten Test haben alle Domains und Anwendungen anstandslos
funktioniert, d.h. sie hatten wohl alle ausschließlich das
Wurzelverzeichnis und ggfs. Datenbankanbindungen. Ich werde das eine
Weile beobachten und erst dann die ursprünglichen Daten löschen, aber
soweit ich sehe, sollte alles reibungslos funktioniert haben.
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.
Ja, es geht ja irgendwo auch ums Prinzip ;-)
<...>
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.
Was du nicht sagst. Ich erinnere da nur an einen Debug-Nachmittag, der
genau aus diesem Grund sehr lang geworden ist ... [1]
Herzliche Grüße
Urs
[1]
Ich hatte einen Git hook, der nicht funktionierte. Nachdem wir alle
Möglichkeiten ausgereizt hatten, die Umgebungsvariablen in den Griff zu
bekommen, stellte sich heraus, dass auf dem Server zwei unterschiedliche
Node.js-Versionen installiert waren, und der Hook eine Funktion aufrief,
die in der tatsächlich verwendeten Node-Version noch nicht vorhanden war.
Gruss RalfD
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org