Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 12 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 …

Article note: *rememberremember!*

I had this problem for a long time, and no one ever proposed a good solution. Recently I got a new answer on my, almost 2 year old, Unix and Linux StackExchange question. This information seems very obscure and so I thought I'd share it, if you too have had this problem and were unable to find this, or at least found finding it hard, consider upvoting the answer.

Problem

You're using a Linux system that you don't have root on, you need to override the DNS of the system. You usually want to do this because you're testing a service (web site) that does not have a proper hostname, but needs one in order to function properly. In the hosting world this comes up often enough.

Solution

You can set the HOSTALIASES environment variable before running your client program. HOSTALIASES is an environment variable that points to a file that is essentially alias value pairs.


$ echo "foo www.google.com" > ~/my_hosts
$ HOSTALIASES=~/my_hosts wget foo
See hostname(7).

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 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.

Seit ein paar Wochen habe ich den own­Cloud-Cli­ent unter Ubun­tu instal­liert. Die­ser lief auch recht gut & brauch­bar – bis auf ein paar klei­ne ‘Macken’. So zum Bei­spiel auch das Pro­blem­chen, wel­ches bei Don­ner­D­rum­mel kurz erklärt ist. Dies war beson­ders nach dem Auf­wa­chen des Rech­ners regel­mä­ßig zu beobachten.

Vor ein paar Tagen erhielt ich dann bei Neu­start des Cli­ents die Mel­dung, dass die Ver­si­on 1.0.3 ver­füg­bar ist. Aller­dings habe ich mich dann gewun­dert, dass ich die­se bei der Soft­ware­ak­tua­li­sie­rung nicht ange­bo­ten bekom­me. Heu­te habe ich dann noch­mal ver­sucht, dem Pro­blem auf den Grund zu gehen und bin über Don­ner­D­rum­mels Bei­trag gestol­pert. Dann habe ich mir noch­mal die Anlei­tung zur Instal­la­ti­on des Cli­ents ange­schaut und fest­ge­stellt, dass ich ein ande­res Repo instal­liert hat­te, als es da ange­ge­ben ist – ich hatte 

"isv:ownCloud:communiy"

in der URL, wel­ches jetzt 

"isv:ownCloud:ownCloud2012"

ist. Offen­sicht­lich hat sich da etwas ‘offi­zi­ell’ geän­dert, was ich bis dato nicht mit­be­kom­men hatte.

Lan­ge Rede, kur­zer Sinn – How­To zum Update des ownCloud-Clients:

  1. "owncloud-client" – Ver­si­on 1.0.2 – voll­stän­dig deinstal­lie­ren (ein Update hat nicht funktioniert).
  2. Das Repo (aus der Anlei­tung; s.o.) kon­trol­lie­ren und korrigieren.
  3. "owncloud-client" – jetzt in Ver­si­on 1.0.3–1 – (neu) installieren.

Voi­la – das ers­te Auf­wa­chen hat den Feh­ler im Cli­ent nicht mehr produziert… 🙂
Schön ist auch, dass der csync-Pro­zess (der im Hin­ter­grund für die Syn­chro­nisia­ti­on zustän­dig ist, nicht mehr mei­ne .xsession-errors-Datei ‘voll­müllt’. Dafür gibt es (jetzt?) im Cli­ent sel­ber einen Knopf, der die Logs anzeigt. (Blöd nur, dass das Fens­ter mit dem Log nicht schließ­bar ist und gera­de nur mit "xkill" been­det wer­den konn­te… *egal*)

Abschlie­ßend bleibt zu sagen, dass obi­ge ‘Anlei­tung’ ohne jeg­li­ches Gewehr mei­ner­seits ver­öf­fent­licht ist und dass ich mich gene­rell sehr über das own­Cloud-Pro­jekt und die alles in allem sehr gut funk­tio­nie­ren­de Soft­ware freue! 🙂

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 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.

…gehö­ren mir!

Letz­te Woche bin ich über unhosted.org – „Per­so­nal data free­dom; A move­ment to sepa­ra­te web apps from user data“ – gestol­pert. Und die haben die Web-App „Lib­re Docs“ auf Basis von Ether­pad Lite geschaf­fen, die das von Lib­re Docs zur Ver­fü­gung gestell­te Ether­pad nutzt, die erzeug­ten Daten bzw. Doku­men­te jedoch in der Cloud ablegt/speichert. Und der Ober­knal­ler dar­an ist, dass die­se Cloud-Schnitt­stel­le mit­tels der Java­script-Cli­ent-Biblio­thek remoteStorage.js, die die Rea­li­sie­rung einer W3C-Spe­zi­fi­ka­ti­on ist, umge­setzt wur­de und somit auch mei­ne eigen Cloud benutzt wer­den kann.

Wie jetzt, mei­ne eige­ne Cloud…!? – Na die, die ich mit own­Cloud auf mei­nem Web­space betrei­be und in der ich schon meine(n) Kalen­der (Cal­DAV), mein Adress­buch (Card­DAV) und ein paar Datei­en (Web­DAV) mit­tels Desk­top (Thun­der­bird & Ubun­tu) und Smart­phone (Android) ver­wal­te und synchronisiere.

Also ich kanns nur emp­feh­len und bedan­ke mich jetzt schon mal bei allen Betei­lig­ten der oben genann­ten Projekte! 🙂

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 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.

Ich ver­ste­he es nicht… – Sys­tem-Update (Ubun­tu Pre­cise; ohne frem­de PPAs) auf Thun­der­bird 12.0.1 und danach funk­tio­niert die manu­ell instal­lier­te Light­ning-Exten­si­on (1.3) nicht mehr.

Nach etwas Suchens bin ich dann zu einer Lösung gekom­men: Instal­la­ti­on der Ver­si­on 1.4.
Aller­dings ist die­se Ver­si­on nur (direkt) über addons.mozilla.org und nicht über die Haupt­sei­te des „Mozil­la Calen­dar“ Pro­jekts erhält­lich. Auf der Pro­jekt­sei­te wird als aktu­el­le Ver­si­ons­num­mer die 1.3 ange­ge­ben… *naja*

Trotz alle­dem: Es funk­tio­niert wie­der alles und die Cal­DAV-Unter­stüt­zung, wel­che IMHO (auch) durch das Team von Inver­se inc. unterstützt/voran getrie­ben wird, ist großartig! 🙂