python trick: compartir directori via HTTP
A vegades estant en la propia LAN, suem tinta per dir-li a un usuari de windows com ho ha de fer per agafar un fitxer d’un directori del nostre linux. Si teniu python instal·lat, normalment totes les distribucions l’instal·len per defecte a més del paquet HTTP. Podeu fer una cosa tan simple com posar al .bashrc:
alias quickweb='python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"'
Ara aneu al directori on voleu compartir els fitxers i escriviu: quickweb. Això obrirà el vostre port 8000 i qualsevol usuari de la xarxa podrà connectar-se amb el navegador a la vostre IP pel port 8000. Allà es pot veure i descarregar els fitxers que hi teniu. Quan volgueu deixar de compartir el directori només cal fer un Control+C i llestos.
Realment una xorrada molt i molt útil, no? si voleu comprovar què esteu compartint ja ho sabeu: http://127.0.0.1:8000. Més senzill impossible.
Es venen ‘mentiras’ i posta de sol
Fa uns dies que l’Isaac, mon germà. Ha arribat del Perú, on era de vacances d’on m’ha portat una fotografia curiosa d’aquestes que sap que tan m’agraden. No ús ho perdeu perquè l’anunci no té desperdici:
Com haureu vist he aprofitat el pont per descansar i fins hi tot he fet festa a twitter. Així doncs, després d’unes falles ben divertides i d’uns dies de relax per casa amb Estefania ja estic preparat per afrontar aquesta setmana, que al ser més curta encara li tinc més ganes. Això si, té pinta que a nivell de feina serà intensa ja que hi ha alguns temes per tancar amb clients i això sempre acabar sent una tasca dura.
Abans d’acabar aquest post adjuntar aquesta posta de sol d’ahir, com sempre capturada des de casa.
openfiler: potent i complicat de configurar
M’ha costat deu i ajuda posar a funcionar l’openfiler al final ja era una qüestió d’honor. Després de provar amb la versió pre-instal·lada com appliance i amb dues versions instal·lades per mi no hi havia manera de que funcionés tot plegat com volia.
Problema reconeixer volums lògics pre-creats
El primer gran problema ha estat que jo ja tenia un volume group creat, amb dos logic volumes (unitats lògiques d’informació usades per LVM). Doncs bé malgrat el linux me’ls retornava sense problemes amb el vgdisplay i lvdisplay quan anava a l’interficie de l’openfiler no hi havia manera que apareguessin els volums lògics. El grup de volums si que sortia però els lògics no. Doncs bé la solució l’he trobat després de molt buscar pels forums a aquest thread: How to get volumes back after reinstallation without config backup.
La gràcia esta en un script que bàsicament genera un fitxer XML de configuració que usa l’openfiler per saber quins volums hi ha al sistema: /opt/openfiler/etc/volumes.xml. El fitxer és força simple i només té una llista de volums lògics relacionats a un grup de volums. L’script també afegeix al /etc/fstab les línies necessaries perquè aquests volums lògics es montin a l’arrancar el sistema.
Còpia de l’script que he trobat al forum: remake_vol_info.
Problema LDAP amb tots els serveis i especialment amb el SMB
Doncs bé, aprofitant que openfiler porta un servidor LDAP volia gestionar les comptes de tots els serveis a través d’un únic punt. Així doncs, el primer problema ha estat saber com activar el servidor que porta internament perquè la documentació no ho explica massa bé, ja que si anem a serveis i li fem un enable sense donar cap error no s’aixeca ni a la de tres. Aprofito per comentar que la interficie gràfica de l’openfiler és realment pèssima i difícil d’entendre. A més, l’experiència d’usuari esta molt poc cuidada perquè moltes coses donen errors i no ho explica retorna enlloc. Així doncs t’hs de buscar la vida monitoritzant els fitxers de logs del linux que té per darrera.
Llavors he intentat actualitzar el sistema a través de la funció d’update que porta la pròpia interficie. Doncs be, també fallava així doncs ho he provat des de la línia de comandes amb un simple:
conary updateall
La cosa fallava amb el mateix error:
...
Warning: Unhandled exception occured when invoking callback
/user/lib/pgthon2.4/site-packages/conary/streams.py:416
...
Després de googlejar una bona estona, la solució ha estat:
conary update conary --replace-files
conary updateall --replace-files
Amb això he aconseguit finalment fer update. Però el problema amb LDAP continuava igual. Al final he deduit que si posava la informació a accounts -> authentication. Amb el password que he posat al fer la instal·lació per l’usuari de configuració del web la part d’usuaris i grups semblava que s’activa i el LDAP server començava a funcionar tot solet.
<div class="imatge" style="text-align: center;"></div>Així doncs, he pogut accedir a la gestió de comptes i crear un grup d’usuaris i un usuari de proves. Doncs bé, després de suar tinta per entendre tot el tema de gestió de shares i de veure que no hi havia manera d’accedir als recursos compartits de forma autenticada, he decidit aprofitar la meva experiència en linux per veure com estava tot configurat.
La qüestió és que he vist que tan el SMB, com el FTP, HTTP/WebDav, etc. anaben contra PAM però aquest no tenia configurat cap enllaç cap a LDAP, per tant, per molt que estigués funcionant era impossible que mai autentiques cap usuari.
Llavors he executat el authconfig per configurar l’autenticació PAM contra LDAP, i l’he deixat així:
<div class="imatge" style="text-align: center;"><img title="authconfig screenshot" src="http://fitxers.oriolrius.cat/2185/authconfig_thumb.png" alt="authconfig.png"><br><br><a href="http://fitxers.oriolrius.cat/2185/authconfig.png">original size</a></div>Al marcar l’autenticació LDAP per SMB, no ús ho perdeu m’ha dit que faltava el paquet pam_smb, o sigui, el pàquet de PAM que té el handler capaç de gestionar la connexió contra LDAP pel samba. Algú em pot explicar com pretenien la gent d’openfiler autenticar samba amb LDAP si no hi havia això instal·lat? aquí ja he arribat a la conclusió que això de l’openfiler esta verdíssim.
Bé doncs, després de suar una mica amb tot això que comento ja funciona tot contra LDAP a la perfecció!!! realment he de reconeixer que sóc una persona obstinada,eh!? perquè n’hi ha per deixar-ho correr. Després de tot el que he explicat i les hores que he hagut d’invertir per descobrir-ho.
Rendiment OpenFiler virtual
Porto tot el dia fent proves amb l’OpenFiler com a màquina virtual dins del servidor HP que estic montant. Doncs, bé apart dels detalls tècnics volia fer una simple i interessant prova que després de veure el resultat encara em té estorat. He fet un test de velocitat amb el hdparm per saber la velocitat de transferència entre l’ubuntu que fa de servidor d’VMWare i un disc dur de 750Gb:
root@vm0:~# hdparm -t /dev/sdc1
/dev/sdc1:
Timing buffered disk reads: 314 MB in 3.02 seconds = 104.11 MB/sec
Després des de la màquina virtual amb OpenFiler (basat en linux Red Hat) he fet la màteixa prova:
[root@nas0 ~]# hdparm -t /dev/sdb1
/dev/sdb1:
Timing buffered disk reads: 66 MB in 3.05 seconds = 21.65 MB/sec
Malgrat el nom del dispositiu surti diferent el dispositiu és el mateix, això passa perquè en la màquina virtual el dispositiu no és el tercer dispositiu ‘SATA‘, sinó el segon. La màquina virtual té capturat el dispositiu físic, així doncs trobo que la diferència de velocitat és exagerada. També s’ha de comentar que l’OpenFiler no m’ha deixat instal·lar-se en 64bits sobre VMWare i ho he hagut de fer amb 32bits, no sé pas si aquesta diferència tan brutal pot ser deguda a això.
Els recursos que tinc assignats a l’OpenFiler són:
<div class="imatge" style="text-align: center;"></div>Si algú té la possibilitat de fer alguna prova semblant, o l’ha fet que avisi. De totes formes, diria que amb màquines virtuals de 64bits no puc capturar el dispositiu real o això m’ha semblat llegir que deia el VMWare. Gran defecte sota el meu punt de vista.
Reducció ADSL a 1Mbps
Després de molts anys pagant uns 170 d’ADSL per tenir menys de 2Mbps i després de que em canviessin els 512Kbps de pujada per 300kbps fa uns mesos, he decidit reduir la meva ADSL de 2Mbps a 1Mbps. O sigui, que ara ja només tinc 300kbps de pujada. Això suposo que ja ho estareu notant amb la web. Em sap molt de greu per vosaltres però ara només pago 44 al mes i la diferència és ampliament substancial.
Pel que fa al blog, fa dies que estic pensant en canviar-ho tot a oriolrius.cat on fa temps que hi tinc un WordPress en proves amb un lifestream. Realment estic completament peix amb el WP però estic més que cansat del blog:cms i no descarto començar un blog de zero mentre em decideixo a migrar tot el que tinc aquí cap al nou motor de WP. Així doncs, en els propers mesos notareu força canvis en el tema.
Ara que surt e tema del blog, comentar una curiositat ahir l’Alfredo em va passar una web on et diuen el nivell que han de tenir els lectors del teu blog, en funció de certes paraules claus de les que parles. Doncs aquí teniu el nivell que representa que heu de tenir per llegir el meu blog:
Per cert, la web en qüestió és The Blog Readability Test. What level of education is required to understand your blog?.
Istanbul una aplicació per capturar screencast
Abans d’anar al CeBIT vaig capturar uns screencast per tal de fer una demostració de les aplicacions de movilpoint. Doncs bé, malgrat l’edició la va fer el Law amb software propietari la captura la vaig fer Istanbul. Comentar només que les sessions que es capturen queden com videos Ogg Vorbis així doncs, també podem capturar audio al mateix temps que la pantalla. Malgrat això els videos que varem fer a movilpoint estan subtitulats en anglès i no tenen so.
Potser el que més m’agrada és la capacitat d’escollir una aplicació i gravar tot el que aquesta aplicació fa. També és interessant la capacitat de poder marcar una zona de la pantalla on es capturarà. Comentar que si treballeu amb més d’una pantalla el video també pot ser de les pantalles que tingueu. Obviament després és una mica engorrós de mirar. Això si, si teniu més d’un workspace i decidiu canviar mentre esteu gravant el screencast no es mantindrà en l’espai de treball original.