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

  • 0
  • 0
  • 0
  • 0

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

  • 0
  • 0
  • 0
  • 0

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

  • 0
  • 0
  • 0
  • 0

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 13 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 bin kein PHP-Pro­gram­mie­rer, aber für mei­ne B.A.-Arbeit mache ich es (mehr recht als schlecht) & bekom­me dabei manch­mal fast ne Krise…

So zum Bsp. in den letz­ten bei­den Tage. – Da wur­de aus einer klei­nen 40zeiligen Funk­ti­on (die die gewoll­ten Grund­funk­tio­na­li­tä­ten lie­fert) ein klei­nes Mons­ter mit 164 Zei­len… – Aber jetzt isses halt echt viel schö­ner & die Bedar­fe Aller sind befriedigt… 😉

Außer­dem noch schnell nen Link zu dem Pro­jekt RIPS: http://rips-scanner.sourceforge.net.
Damit kann man off­line PHP-Code auf Feh­ler & Schwach­stel­len prü­fen las­sen… – Sehr nett! (Aber bit­te nicht nur dar­auf verlassen. ;))

*sound­jetzt­gehts­ins­bett-wink*

  • 0
  • 0
  • 0
  • 0

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

An die­ser Stel­le soll es heu­te mal kurz um ein Pro­blem­chen und des­sen ‘Lösung’ gehen, wel­ches mich ges­tern (fast) den gan­zen Tag beschäf­tigt hat.

Ich hat­te die Auf­ga­be zu lösen, mit­tels eines HTML-For­mu­lars und PHP ein Bild (als BLOB) in einer MyS­QL-Daten­bank abzu­le­gen. – Eigent­lich ja nicht all­zu schwie­rig, denn Anlei­tun­gen & Code-Schnip­sel dazu gibts im Netz wie “Sand am Meer”…

Am Ende ent­schied ich mich für die Vari­an­te, die hoch­ge­la­de­ne Datei ohne file hand­ler (fopen, fread, fclo­se) in die DB zu hexen. Denn man kann recht ein­fach mit­tels mit­tels der glo­ba­len PHP-Varia­ble “$_FILES” auf die (mit­tels POST) hoch­ge­la­de­ne Datei zugrei­fen.

if (isset($_FILES['bild']) && is_uploaded_file($_FILES['bild']['tmp_name']) && $_FILES['bild']['size'] > 0) {
$mimetype = $_FILES['bild']['type'];
$blob = bin2hex(file_get_contents($_FILES['bild']['tmp_name']));

Da ich beim Insert immer die Mel­dung bekam, dass ich einen Feh­ler in der SQL-Syn­tax habe, wenn ich für den BLOB mysql_real_escape_string(file_get_contents($_FILES['bild']['tmp_name'])) oder addslashes(file_get_contents($_FILES['bild']['tmp_name'])) (wie bspw. hier beschrie­ben) benutzt habe, habe ich letzt­lich die Funk­ti­on bin2hex() für das Spei­chern der binä­ren Daten (des Bil­des) in der MEDI­UM­B­LOB-Spal­te der DB verwendet. 

Nach ein paar Test-Uploads stell­te ich dann jedoch fest, dass grö­ße­re Bil­der nicht hoch­ge­la­den wer­den kön­nen – wg. der Begren­zung auf dem Ser­ver. Also habe ich etwas gesucht und die dafür zustän­di­gen PHP-Ein­stel­lun­gen bzw. ‑Varia­blen gefun­den. Die­se spuck­ten mir aller­dings aus, dass mei­ne max. Upload-Grö­ße 32MB beträgt, was bei einem Upload von einem ca. 1,5MB gro­ßen Bild jedoch nicht ’stimm­te’. Denn da kam dann dann die MyS­QL-Mel­dung “Got a packet big­ger than ‘max_allowed_packet’ bytes” und der Daten­satz wur­de nicht in die DB geschrieben.

‘Gut, dass die MyS­QL-Mel­dung so aus­sa­ge­kräf­tig ist’, dach­te ich mir und such­te erneut nach einer Lösung… – Und sie­he da, auch dazu gibt es Lösun­gen, wie bspw. die­se. Ärger­lich war nur, dass ich den gan­zen Tag der Mei­nung war, dass der MyS­QL-Para­me­ter “max_allowed_packet” dyna­misch zur Lauf­zeit des Ser­vers per PHP beein­fluss­bar ist. *gml*
Dies kam zum Bei­spiel auch daher, dass das Aus­le­sen des Para­me­ters (mit mysql_query("SHOW VARIABLES LIKE 'max_allowed_packet'")) und das Neu­set­zen des Wer­tes (mit­tels mysql_query("SET max_allowed_packet=16777216;")) zwar anstands­los funk­tio­nier­te, aber lei­der den Upload nicht ver­bes­ser­te. Trotz des neu gesetz­ten Wer­tes (auf 16MB), war die Upload­gren­ze in Wirk­lich­keit immer noch beim Stan­dard­wert 1MB.

Lan­ge Rede, kur­ze Erkenntnis:
Das Ändern des MyS­QL-Wer­tes “max_allowed_packet” zur Lauf­zeit per PHP funk­tio­niert (i.d.R.) nicht. (Man kann, wenn man MyS­QL-Root-Rech­te mit sei­nem Log­in hat, ver­su­chen, den glo­ba­len MyS­QL-Para­me­ter zu ver­än­dern.)
Man muss/sollte/kann die Ein­stel­lung ser­ver­sei­tig vor­neh­men und ent­we­der dau­er­haft den Ein­trag max_allowed_packet=16MB; in der my.cnf machen oder mit MyS­QL-Root-Rech­ten den Wert mit­tels SET max_allowed_packet=16777216; zur Lauf­zeit ändern (dann ist die­ser bei einem Neu­start aller­dings wie­der weg).

Außer­dem ist anzu­mer­ken, dass die BLOBs in der DB irgend­wie (ca.) dop­pelt so groß sind/werden, wie die Ori­gi­nal-Datei­en. – Aus einem Bild mit 991K wird bspw. (bei mir) ein BLOB mit 2.03MB. *strange&doof* (Bit­te jetzt kein Bas­hing, ob es über­haupt sinn­voll ist, Bil­der direkt in der DB zu spei­chern. – Es muss die­ses Mal so sein!)

  • 0
  • 0
  • 0
  • 0