Skip to content

Home

Jump to bottom
Donald Buczek edited this page Mar 17, 2017 · 18 revisions

Neues Package für /pkg Pfad:

  • Package reservieren:

    Als root@afk das neue Package in /project/config/src/mxpkg mit dem Keyworkd BUILD einbauen und verteilen:

    ssh afk
sudo -s
cd /project/config/src
vi mxpkg
make

    Make verteilt die Datei auf alle Systeme nach /etc/mxpkg und triggert, dass alle Systeme ihre /pkg automount-map (/etc/automount/auto.pkg) daraus neu bauen. Normalerweise sind /pkg-Pfade read-only, aber durch das keyword BUILD werden die Pfade für Packages, die gerade gebaut werden, read-write gemountet.

  • Im eigenen clone von diesem Repository neues build-Script anlegen. z.B.:

    git pull
cp example-1.0-0.build.sh example-1.1-0.build.sh
vi example-1.1-0.build.sh    # update version-number
git add example-1.1-0.build.sh
git commit -m"Add example-1.1-0"

  • Package bauen

    sudo tools/build.sh example-1.1-0

    Beim build werden sicher oft Fehler auftreten, was zu einem Abbruch des builds führen sollte. Man kann sich dem Iterativ nähern:

    vi example-1.1-0.build.sh     # fixe einen Fehler
sudo tools/build.sh example-1.1-0

    bis es klappt. Da die späteren Aufrufe aber nicht mehr bei Null anfangen, sondern in einem Verzeichnis, in dem von den vorherigen Versuchen schon Dateien rumliegen (was gut ist, damit die Iteration oben schneller geht), sollte man zum Schluss sicherstellen, dass das Script nunmehr in der Lage ist, von Null zu bauen. Das build.sh script hat eine Option --purge um alle alten Relikt-Dateien (einschließlich der Downloads) zu löschen.

    Nach Fehlerkorrekturen also ganz zum Schluss

    sudo tools/build.sh example-1.1-0 --purge

    Und bitte auch alle Änderungen am build-Script committen:

    git add example-1.1-0.build.sh
git commit -v
git push

  • Package zumachen

    Als root@afk aus /project/config/src/mxpkg das Keyword BUILD bei dem Package entfernen

    ssh afk
sudo -s
cd /project/config/src
vi mxpkg
make

Debug build problems

  • Einfach mal als build-user selber in den ausgepackten Sourcen rumediteiren und "make" uns sowas versuchen: 
    sudo su - build
cd /package/pkg/example-.1.2.3-0
# whatever...

Ziele

  • Die Build-Scripte sollten auch als User ohne den tools/build.sh funktionieren (Wenn der prefix nicht auf /pkg/ sondern auf etwas zeigt, was der User beschreiben darf)

Package Wrapper

Die Wrapper (/usr/local/package/bin , /usr/local/package/lib) werden einfach auf dem distmaster erzeugt und gedistet. Profile-Files für Packages aus mxpkg werden automatisch in /usr/local/package/lib angelegt, die müssen also nicht von Hand angelegt werden. Den Config-File muss man nur editieren, um ggf. Aliase zu definieren (so dass z.B. prun example cmd identisch ist mit prun example-1.2.3-4 cmd) oder natürlich Programme aus dem Package, die im Pfad sein sollen (so dass z.B. cmd identisch ist mit prun example cmd

ssh deinemuddah
sudo -s
cd /usr/local/package/admin
vi config     # optional
make
Donalds "Überlegungen zu Packages"

  • Komplexe Software

    • kann aus dem einen oder anderen Grund nicht so einfach mit bee nach /usr/bin installiert werden.
      • viele optionale Module
      • eigenes Build-System oder eigene Modulverwaltung
      • Build-System lädt Sourcen oder Module aus dem Internet (nicht reproduzierbar)
      • wird potentiell in mehreren Versionen und/oder Varianten benötigt
      • viele viele GB und Files (?) - zB auch Zeit beim Installieren...
    • Beispiele: Sprachen/Libraries: perl,R,python2,python3,mathematica,node.js,Haskell,qt, ...
    • Beispiele: Anwendungen: inkscape, pandoc, rstudio,cytoscape, ...

  • Probleme bei NFS-Lösungen (/package/...)

    • Einige Software, die fast überall oder im Cluster läuft, ist remote und beschert uns so Netz-Anhängigkeiten, Geschwindigkeitsprobleme, Probleme bei Serverwartung wegen remote-mounts ( python, R, ... )
    • Einige Software wird vor Verfügbarkeit von Netz/nfs/automount benötigt (perl...)

  • Probleme bei lokalen Lösungen "im System" ( /usr/bin, /usr/local/bin ):

    • Nur eine Version möglich (perl)
    • keine langsame Transition oder Test mit alten Varianten möglich

  • Probleme bei allen lokalen Varianten (/usr/bin , /opt/VERSION, ...)

    • Platz ist limitiert ( system-python .vs. scientifiy python (*zig varianten) ) ?

  • Lösungsansatz:

    • komplexe Software wird in ein Directory gebaut und hat einen version und revison-tag ( zB. python-2.7.11-3 )
    • Paket kann entweder remote oder lokal sein
    • Kopien (Master, nfs-server, lokale Platte) per Definition identisch. Einmal eingerichtet ist Paket read-only. Bei Änderungen wird neue Revision gemacht
    • Am besten durch bin:bin owner (und read-only mount ?) forciert
      • NFS readonly: vermutlich nfs performance besser, aber Installation neuer packages/revisions deutlich komplexer
    • Die Auswahl, was lokal ist (und wo) soll nicht unbedingt auf allen Systemen gleich sein
    • Zumindest zur Build-Zeit sollten die Packages direkt dort gebaut werden, wo sie später laufen.

  • Randbemerkungen (warum andere Ideen nicht funktionierten)

    • nicht über Symlinks ( da Build-Systeme und auch Applikation den Zielpfad sehen und leaken)
    • Es wird (leider) in jedem Fall auch automount benötigt, da nicht alle Packages lokal sind und nfs-Mounts nur bei Bedarf gemacht werden sollen
    • Es soll auch kein Directory mit Symlinks zu automount-Pfaden geben (sonst ls -lL tödlich).
    • Direct maps würden automount und nicht-automount verzeichnisse im gleichen Directory ermöglichen. Knock-Out Nachteil: Jedes nicht-lokale Unterverzeichnis wäre ein ständiger autofs kernel mount
    • In autofs-Verzeichnissen manuell zu mounten, ist schwierig, da man darin keine eigenen Directories als mountpoint anlegen kann. Drübermounten geht zwar, aber dann ist der nfs-mount auch da und zudem verdeckt und wird vom automount dismountet.
    • Die "Weiche" lokal oder remote muss also über die automounter-Map erfolgen. Da das per Software-Package (R-3.2.1-0,R-3.2.1-1,...) geht, muss es eine neue Map sein (also nicht /package). Die Map ist nicht auf allen Systemen gleich, da cache unterschiedlich sein kann.
    • Nachteil: Wenn mal was gemountet ist, kann man nicht ändern/dismounten, so lange Prozesse finger drauf haben.

  • Lösungsvorschlag konkretes Beispiel:

    Map für "/pkg" mit autofs

/pkg autofs

R-3.2.1-0 -> server:/somewhere/pkg/R-3.2.1-0 (read-only, package kommt von remote) R-3.2.1-1 -> :/opt(?)/pkg/R-3.2.1-1 (read-only, package wird aus lokaler Kopie geladen) R-3.2.1-2 -> :/scratch/local/R-3.2.1-2 (read-write, nur zum Bauen neuer Revisionen)

Die Maps auf den Systemen können sich unterscheiden (zB. Abhängig von Bedarf oder Plattenplatz)

/opt/pkg/PKG-VER-REV ist lokaler Package (cache). Kann auch auf andere Partition symlinken

server:/somewhere/pkg/PKG-VER-REV ist read-only nfs export. Eventuell redundant, eventuell mit virtueller Adresse für failover möglich(?). server:/somewhere/pkg/PKG-VER-REV Das "somewhere" sollte nicht in bestehende /package zeigen weil

  • /package/whatever/.../PREFIX wäre direkter mountpoint. Wenn der Maintainer von /package/whatever an den Directories ändert, gibt es evtl. stale nfs handle
  • Undurchsichtig, weil aktuell Software in /package/whatever mit PREFIX auf /package/whatever gebaut wird, aber die neue Varianten sollten PREFIX /pkg/XXXX haben.
  • Das neue package-Repository sollte also besser nicht in bestehende /package verteilt werden, sondern eventuell an einer Stelle neu aufgebaut und eventuell repiliziert werden. Beispiel:

/project/packages/pkg

R-3.2.1-0.build.sh    # build script 
R-3.2.1-0.build.log   # build log 
R-3.2.1-0                 # PREFIX, exportiert. Darin Installation und build-Directory 

R-3.2.1-1.build.sh    # build script 
R-3.2.1-1.build.log   # build log 
R-3.2.1-1                 # PREFIX, exportiert. Darin Installation und build-Directory

...

Aus der /pkg map wird dann aber direkt gemountet:

R-3.2.1-0 -ro SERVER:/amd/SERVER/X/Xnnnn/project/packages/pkg/R-3.2.1-0

Diskussion

Abgrenzung zu bee?

  • Alles lokal ?
  • repository ?

/scratch autfs pkg -> /amd/$host/P/pkg und symlink

/pkg autofs

R-3.2.1-0 -> afk:/amd/akf/1/package/pkg/R-3.2.1-1 (read-only, package kommt von remote)

R-3.2.1-1 -> :/amd/$host/P/pkg/R-3.2.1-1 (read-only, package wird aus lokaler Kopie geladen) R-3.2.1-2 -> afk:/amd/akf/1/package/pkg/R-3.2.1-2 (read-write, package wird remote gebaut)

R-3.2.1-3 -> /scratch/tmp/xxxx (read-write, package wird lokal gebaut)

Clone this wiki locally