Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 8 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Par­al­lel zu Last­Pass pro­bie­re ich gera­de seit eini­ger Zeit Enpass (auf mei­ner Ubun­tu-Kis­te und auf mei­nem Android-Han­dy) im Zusam­men­spiel mit mei­ner own­Cloud aus. – Bis jetzt ganz gut …

Hier desh. ganz kurz ein paar Noti­zen zur Installation.

  1. Enpass per PPA instal­lie­ren: https://www.enpass.io/kb/how-to-install-on-linux/
    Von Web Upd8 gibts auch nen schö­nen Arti­kel
  2. .desk­top-Datei erstel­len (s.u.)
  3. Star­ter-Icon her­un­ter­la­den:
    wget https://upload.wikimedia.org/wikipedia/commons/c/c1/Enpass_icon.svg -O ~/.icons/Enpass.svg
  4. fer­tig …

# ~/.local/share/applications/Enpass.desktop
[Desktop Entry]
# https://standards.freedesktop.org/desktop-entry-spec/latest/
Version=5.2
Terminal=false
Type=Application
Name=Enpass
Comment=cross-platform password management solution
Exec=/opt/Enpass/bin/runenpass.sh
# wget https://upload.wikimedia.org/wikipedia/commons/c/c1/Enpass_icon.svg -O ~/.icons/Enpass.svg
Icon=Enpass
# https://standards.freedesktop.org/menu-spec/latest/apa.html
Categories=Security;Settings;System;Utility

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 9 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Auch wenn ich nicht wirk­lich ‚viel‘ code, aber so ab und zu fällt ja doch mal was an … In den letz­ten Jah­ren v.a. aber eher Klein(st)beiträge zu bereits bestehn­dem Code Ande­rer, statt eige­ner Projekte.

2010 ver­such­te ich mei­ne ers­ten Schritt(ch)e(n) mit Git und such­te dafür eine geeig­ne­te Platt­form. – Nur Kom­man­do­zei­le mit eige­nem Git-Ser­ver war mir damals IMHO zu umständ­lich und wohl auch zu ner­dy. ‚Damals‘ gabs zwar schon Git­hub (und dort hat­te ich auch seit 2009 einen unge­nutz­ten Account), aber als F(L)OSS-Verfächter woll­te ich mehr Com­mu­ni­ty und fand letzt­lich Gito­rious, wo ich mir einen Account zuleg­te. (So jeden­falls mei­ne Erinnerung …)

Bei Gito­rious gab es anfäng­lich kei­nen Issue-Tra­cker und die Inter­ak­ti­on über Web­ober­flä­che war, im Gegen­satz zu Git­hub, sehr beschränkt. So kam es im Lau­fe der fol­gen­den fünf Jah­re zur vor­ran­gi­gen Nut­zung mei­nes Github-Accounts.

Im letz­ten Jahr gab es Bedarf für die Zusam­men­ar­beit meh­rer Per­so­nen ein einem Pro­jekt (etwas bug fixing im Code von POLYKON) – dabei soll­te das erst ein­mal nicht in der Öffent­lich­keit pas­sie­ren. Somit schied Git­hub (auf Grund der Kos­ten) aus und ich fand Bit­Bu­cket und erstell­te auch dort einen Account.

In Sum­me hat­te ich bis dahin also drei Accounts bei unter­schied­li­chen Anbie­tern für Git-Repo­si­to­ries gesammelt …

Git­Lab-Logo

Letz­te Woche woll­te ich mal wie­der bei Gito­rious schau­en, was so los ist und stell­te fest, dass Git­Lab den Laden über­nom­men hat und man emp­fiehlt, die eige­nen Gito­rious-Repos auf Git­Lab umzu­zie­hen. Dann habe ich mich also mal bei Git­Lab umge­schaut und schwupps, war der vier­te Account geklickt … 😉

War­um nun noch einen vier­ten Account?

  • GitLabs Web­in­ter­face ist schnell
  • Git­Lab bie­tet nicht­öf­fent­li­che Repos an
  • Git­Lab bie­tet eig. alle (von mir benutz­ten) Fea­tures wie Git­hub (und ist sogar bes­ser ;))
  • Git­Lab gibts in der Com­mu­ni­ty Ver­si­on kostenlos
  • und jetzt der Knal­ler: per Klick konn­te ich (mit etwas Recher­che) alle Repos aus den ande­ren drei Accounts importieren
  • wenn die But­ze iwann (vllt.) mal zu macht, dann kann ich/man das immer noch sel­ber hosten
  • das Icon ist süüüß … 😉

Zusam­men­ge­fasst: Aktu­ell schrumpfe/konsolidiere ich mei­ne Git-Platt­form-Accounts. Gito­riuous is schon weg und gleich kommt noch der Bit­bu­cket-Account dran. Bei Git­hub wer­de ich dann wohl nur noch wg. der Issue- und Pull-Request-Zwe­cke sein, die eige­nen Pro­jek­te kom­men dort auf jeden Fall weg.

Mal schau­en, ob sich das Auf­räu­men lang­fris­tig als klug erwei­sen wird …

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 9 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Ges­tern wollte/musste ich mal wis­sen, was in einem LXC-Con­tai­ner (auf unse­rem Kom­mu­ne-Ser­ver) gemoun­tet ist. – Da das im ers­ten Anlauf nicht ganz so tri­vi­al her­aus zu bekom­men war, hier mal mei­ne klei­ne Gedankenstütze.

long story short

root@host:~/# ls -lha /proc/$(lxc-info -n container -p | awk '{print $2}')/root/home

Erklärbär

Szenario

  • LXC-Ver­si­on: 0.7.5 (ja ich weiß, is alt … ;))
  • Host = hn
  • Con­tai­ner = container
  • Mount = in der fstab (host:/var/lib/lxc/container/fstab) ist das host:/home mit der Zei­le "/home home none bind 0 0" ein­ge­bun­den (d.h. also, dass beim Star­ten des LXC-Con­tai­ners des /home vom Host beim Start des Con­tai­ners in den Con­tai­ner gemoun­tet wird; dabei ist home als rela­ti­ver Pfad zum / angegeben)

Das Problem

Wenn man nun auf dem Host wis­sen will, wie das /home im Con­tai­ner aus­sieht (ls -lha /var/lib/lxc/container/rootfs/home) wird man fest­stel­len, dass es ganz anders aus­sieht, als erwar­tet. – Hin­ter­grund ist, dass der obi­ge Mount in einem tem­po­rä­ren File­sys­tem (also nicht wie ein normaler/echter Mount) ein­ge­hängt wird.

Hier mal die Aus­ga­be, die mit einem Stan­dard-LXC-Tem­p­la­te (Ubun­tu) erzeugt wird:

root@host:~/# ls -lha /var/lib/lxc/container/rootfs/home
total 4.0K
drwxr-xr-x  3 root   root     19 Aug 18  2012 .
drwxr-xr-x 22 root   root   4.0K Feb  7 14:15 ..
drwxr-xr-x  2 ubuntu ubuntu   54 Aug 20  2012 ubuntu

Die Lösung

Nach etwas Recher­che stieß ich auf den Blog-Post „LXC 1.0: Advan­ced con­tai­ner usa­ge“ des LXC-Ent­wick­lers Sté­pha­ne Gra­ber, in dem der Trick (und eini­ge Hin­ter­grün­de) erklärt werden.

Jeder Con­tai­ner hat eine eige­ne Pro­zess­num­mer (pid). Die­se bekommt man mit lxc-info -n container -p heraus.
Der im tem­po­rä­ren Datei­sys­tem ein­ge­häng­te Mount befin­det sich unter host:/proc und dort wie­der unter der jewei­li­gen PID.
Also ange­nom­men unser Con­tai­ner hat die PID 1234, dann fin­det man des­sen root-File­sys­tem (inkl. aller Mounts) unter host:/proc/1234/root/.

Wir benö­ti­gen also zuerst die PID des Con­tai­ners (lxc-info -n container -p) und danach kön­nen wir uns das File­sys­tem anzei­gen las­sen (ls -lha /proc/PID/root/). – Bei­de Befeh­le kann man nun kombinieren.

mit LXC 1.x

In oben genann­ten Blog-Post wird für das Eru­ie­ren der PID lxc-info -n container -p -H (ange­passt!) ange­ge­ben. Dabei ste­hen die Schal­ter -n container für den Con­tai­ner­na­men, -p für die Aus­ga­be der PID und -H (wahr­schein­lich; sie­he unten) für die nume­ri­sche Aus­ga­be der PID. 

Die Kom­bi­na­ti­on der bei­den Befeh­le zum Anzei­gen des Root-Datei­sys­tems für den Con­tai­ner sieht dann so aus: ls -lha /proc/$(lxc-info -n container -p -H)/root/ (ange­passt!).

mit LXC 1.x (in meinem Fall 0.7.5)

Da ich ATM aller­dings noch nicht die Ver­si­on 1.x ver­wen­de, funk­tio­niert der Tipp (aus dem Blog-Post für die Ver­si­on 1.x lei­der nicht (so ganz).
Denn in 0.7.5 gibt es den Schal­ter -H bei der Aus­ga­be der PID mit lxc-info -n container -p nicht, so dass man nicht nur die PID, son­dern den Text pid: 1234 zurück bekommt. :-/

Aller­dings ist das nicht so dra­ma­tisch, denn man kann sich ja mit awk behel­fen (und somit den Schal­ter ersetzen/emulieren). 🙂
lxc-info -n container -p | awk '{print $2}' lie­fert nur die zwei­te ‚Spal­te‘ der lxc-info-Aus­ga­be, also die num­me­ri­sche PID.

Ergo hier nun mei­ne Lösung zum Anzei­gen des Root-Datei­sys­tems des Containers:

root@host:~/# ls -lha /proc/$(lxc-info -n container -p | awk '{print $2}')/root/home
total 4.0K
drwxr-xr-x  3 root   root    19 Aug 18  2012 .
drwxr-xr-x 22 root   root  4.0K Feb  7 14:15 ..
drwxr-xr-x  2 user1  user1       […]         user1
drwxr-xr-x  2 user2  user2       […]         user2
drwxr-xr-x  2 user3  user3       […]         user3

… wie­der was gelernt … 😉 – Aller­dings wohl nicht für lan­ge, denn das Update auf die Ver­si­on 1.x steht ja vor der Tür …