Author: Oriol Rius

Subversion: recuperant el repositori

Reading time: 2 – 2 minutes

subversion.png

Ahir dissabte vaig estar fent updates d’un munt de servidors i com sempre diu la Daphne, si una versió d’algo va perquè carai l’has d’actualitzar. Doncs bé jo diria que quasi tot va quedar al seu lloc excepte el Subversion que després de montar de nou el mòdul WebDAV d’apache i el mòdul DAV_SVN per accedir al SVN des d’HTTP no hi va haver manera de que el repositori funcionés no parava de donar errors extranyíssims que l’oracle de la sabiduria google no em sabia resoldre.

Finalment us explico com ho vaig fer ja que a mi em va salvar la vida i quasi 1000 revisions de versions de software de la feina… bufff! quin descans. El truc és tan senzill com oblidar-se del Berkeley DB que és per on ho intentava arreglar jo. El Berkeley DB (bdb) és el format que usa SVN per guardar la informació al repositori del disc. Cal simplement usar un svnadmin dump i dirigir-lo a un fitxer. Després restaurem aquest fitxer de ‘dump’ al nou repositori amb el svnadmin load. Fàcil,eh!? doncs em vaig tirar més de 3h per descobrir això tan tonto per culpa d’intentar solucionar el tema amb el bdb i no directament amb el propi SVN.

HTTPs, SSL i Certificats en Servidor i Client – Webs privades amb una C.A.

Reading time: 12 – 20 minutes

Com podeu veure aquest post té un parell de títols i suposo que seria molt senzill tenir-ne molts més. Així doncs intentaré descriure la idea del que després explicaré. El que pretenc fer parlant sense tecnisismes és disposar d’un servidor web que només sigui accesible de forma irrefutable i segura pels clients (navegadors) que nosaltres permetem. Això és útil per exemple per bancs, institucions, etc. tot i que en el meu cas és simplement per donar serveis via web als que només tingui accés gent controlada.

key.jpg

Per tal de montar això el que hem de fer és primer de tot montar una entitat de certificació, a la que anomenarem CA (Certifcate Authority). Això ens permetrà emetre tans certificats com volguem tan per servidors com per clients. De fet, perquè això es reconegui publicament només ens caldria que els certificats es signessin per una SA (Signing Authority) o autoritat de confiança. Perquè sapigueu de què parlo alguns exemples d’autoritats d’aquest tipus són: Baltimore, RSA, VeriSign i Thawte. De fet, si volem nosaltres mateixos podem fer d’SA el que no tindrem és la confiança de tercers, ja que no ens reconeixeran com a TA (Trust Authority). Però pel nostre exemple no ens cal així doncs nosaltres mateixos ens ho farem tot.

De fet, tota aquesta història de les entitats de certificació és molt més complexe, però nosaltres només arribarem fins on ens interessa. Intentant simplificar al màxim. Tampoc cal que ens montem una PKI (Public key infrastructure) professional per treballar amb algo tan senzillet. Així doncs, ja tenim clar que hem de montar una CA (root CA) que emetrà emetrà certificats signats per ella mateixa (self-signed certificate). Aquests certificats podràn ser usats per servidors i clients. Així doncs, si montem un servidor que usi aquest certificat podem fer que aquest requereixi que els clients disposin d’un certificat en mode client sinó no podran accedir al servei oferit.

Pel cas que ens interessa el que farem és montar un servidor web, Apache concretament, que només podrà ser accedit pels clients (firefox, netscape, MSIE, etc) que disposin del certificat corresponent.

Què necessitem per montar la CA?

Només cal que tingueu instal·lat el OpenSSL, jo com sempre uso Gentoo i el paquet que he usat és dev-libs/openssl-0.9.7e-r1. El fitxer de configuració més important d’aquest paquet està a /etc/ssl/openssl.cnf. Jo l’he modificat conretament on diu default_days = 365 he canviat el 365 per 3650 així els meus certificats encomptes de ser vigents durant un any seràn vigents durant 10 anys. Si voleu això també es pot alterar a través de la línia de comandes al llençar l’script CA.pl amb el paràmetre -days.

Com ja vaig comentar a l’article: Xarxa Wifi Segura: freeRadius + WRT54G = 802.1x (WPA-radius EAP/TLS), on també s’havia de montar una entitat de certificació la distribució gentoo no instal·la el fitxer CA.pl per defecte i pot ser que no el troveu pel vostre sistema després d’instal·lar el openSSL. Així doncs, jo el que he fet és descomprimir el paquet d’openssl i truere el fitxer directament d’allà i després me l’he copiat a un directori on treballaré a partir d’ara: ~/CA.

Creem la C.A. arrel (root CA)

Un cop dins de ~/CA per generar el certificat de l’entitat arrel (root CA) només cal que feu: perl CA.pl -newca.

$ perl CA.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 1024 bit RSA private key
......................++++++
.............++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:BCN
Locality Name (eg, city) []:BCN
Organization Name (eg, company) [Internet Widgits Pty Ltd]:example CA authority
Organizational Unit Name (eg, section) []:example
Common Name (eg, YOUR name) []:example CA
Email Address []:example@example.com

Veureu que es crea un directori que es diu demoCA i dintre hi ha el fitxer cacert.pem que és el certificat de la nostre root CA.

Emetem un certificat amb la nostre root CA

Primer el que fem és una petició de certificat (request): perl CA.pl -newreq.

$ perl CA.pl -newreq
Generating a 1024 bit RSA private key
...................++++++
.................................................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:BCN
Locality Name (eg, city) []:BCN
Organization Name (eg, company) [Internet Widgits Pty Ltd]:example company
Organizational Unit Name (eg, section) []:example e-comerce department
Common Name (eg, YOUR name) []:www.example.com
Email Address []:example@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem

Obtenim el fitxer: newreq.pem. Fixeu-vos que aquest certificat és pel servidor www.exemple.com. Si voleu emetre un certificat per qualsevol subdomini del domini exmemple.com, podeu posar a ‘Common Name’ el següent *.exemple.com. El que no he provat és posar * a veure si així funciona per qualsevol domini. Tot i que jo diria que no ha de funcionar, sinó el certificat no garintiria que el servidor és qui diu ser.

Signem el certificat emès

Aquest pas és el que hauriem de demanar a la entitat de confiança (TA) la qual després d’enviar-li el nostre certificat ens el tornaria signat (SA). Però que nosaltres som com el ‘joan palom’ (jo me lo guis jo me lo com) doncs ens ho farem nosaltres mateixo amb l’ordre perl CA.pl -sign:

$ perl CA.pl -sign
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            82:9d:18:98:a7:25:24:7e
        Validity
            Not Before: Oct  1 10:50:03 2005 GMT
            Not After : Oct  1 10:50:03 2006 GMT
        Subject:
            countryName               = ES
            stateOrProvinceName       = BCN
            localityName              = BCN
            organizationName          = example company
            organizationalUnitName    = example e-comerce department
            commonName                = www.example.com
            emailAddress              = example@example.com
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                EE:8C:BC:6F:3D:3B:4D:82:56:24:BB:76:E8:39:F3:23:F3:BD:C9:BF
            X509v3 Authority Key Identifier:
                keyid:EE:71:7F:C0:71:39:F1:8A:70:B4:BC:BB:F0:48:B2:77:58:E4:F6:AE
                DirName:/C=ES/ST=BCN/L=BCN/O=example/OU=example/CN=example/emailAddress=example@example.com
                serial:82:9D:18:98:A7:25:24:7D
Certificate is to be certified until Oct  1 10:50:03 2006 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

Ara ja tenim signat el newreq.pem dins del fitxer newkey.pem. A continuació el que farem és extreure la clau privada que hi ha dins del fitxer newkey.pem:

$ openssl rsa < newreq.pem > newkey.pem
Enter pass phrase:
writing RSA key

A newkey.pem hi ha la clau privada del ‘request’.

Renombrem els fitxer per aclarir les coses

Per tal de simplificar una mica tots els conceptes és una bona idea renombrar els fitxers que hem generat:

newcert.pem -> server_cert.pem: certificat signat pel nostre servidor. Això ens permetrà després crear la clau del client.
newkey.pem -> server_key.pem: clau privada (xifrada) en format de texte pla necessaria pel certificat del servidor. La clau privada és la part secreta del certificat, hem d'evitar que tercers la puguin aconseguir.
newreq.pem -> server_req.pem: clau privada xifrada i la petició de certificat original.

Creem el certificat pel client en format pkcs12

Resulta que els nostres navegadors volen els certificats de client en un format que es diu pkcs12 (Personal Information Exchange Syntax Standard) així doncs som-hi:

# openssl pkcs12 -export -in server_cert.pem -inkey server_key.pem -out iestuff.p12
Enter Export Password:
Verifying - Enter Export Password:

Aquí també podria haver canviat el nom del fitxer on es guarda la clau i no posar-li iestuff.p12 com els exemples en que m’he basat, però la mandra és el que té. Bé doncs, ja tenim el nostre fitxer pkcs12: iestuff.p12.

Instal·lem el certificat a l’apache

No us ho creureu però he trigat més estona en fer això que en tota la resta i mira que és senzill, però he aprofitat per actualitzar el servidor i resulta que el nou paquet d’apache per gentoo funciona diferent que l’anterior i no trobava res de res. A partir d’ara parlaré doncs de com fer això en net-www/apache-2.0.54-r31. Però donaré un apunt per estalviar temps als que no useu gentoo.

L’apunt l’únic que s’ha de fer és posar els detalls necessaris perquè funcioni el vostre servidor apache amb SSL i dels fitxers de configuració d’apache només heu de modificar el ‘VirtualHost’ que necessitarà el certificat. Així doncs a partir d’ara el que toca és veure la destresa de cada un amb les infitintes ordres que té l’apache pels seu fitxer de configuració.

NOTA IMPORTANT PER TOTHOM: no oblideu que quan treballem amb un VirtualHost dins de l’espai de configuració del mateix cal user el paràmetre ServerName; doncs bé el que poseu aquí ha de coincidir al 100% amb el que posa al ‘Common Name’ del certificat que heu emès. A més, el vostre DNS ha de resoltre el mnemònic que hagiu usat amb la IP del servidor sinó no funcionarà, a més el nom ha de ser un registre de tipus A i no un CNAME dins la configuració del DNS.

Bé doncs en el paquet de gentoo que comentat el que he fet és modificar el fitxer de configuració del host SSL per defecte, això es fa al fitxer: /etc/apache2/modules.d/41_mod_ssl.default-vhost.conf. Per llençar l’apache amb el host SSL per defecte s’ha de tocar el /etc/conf.d/apache2 perquè es llenci amb les opcions: -D SSL i -D SSL_DEFAULT_VHOST. Amb això el fitxer de configuració 41_mod_ssl.default-vhost.conf passa a tenir validesa. Aqust fitxer l’he modificat ben poc només perquè apunti on he copiat els certificats.

Fixer 41_mod_ssl.default-vhost.conf:

<IfDefine SSL>
  <IfDefine SSL_DEFAULT_VHOST>
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot "/var/www/localhost/htdocs"
ServerName www.exemple.com
ServerAdmin root@localhost
ErrorLog logs/ssl_error_log
<IfModule mod_log_config.c>
        TransferLog logs/ssl_access_log
</IfModule>41_mod_ssl.default-vhost.conf
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/server_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/server_key.pem
SSLCACertificatePath /etc/apache2/ssl/
SSLCACertificateFile /etc/apache2/ssl/cacert.pem
SSLVerifyClient require
SSLVerifyDepth  2
	<Files ~ "\.(cgi|shtml|phtml|php?)$">
    SSLOptions +StdEnvVars
</Files>
	<Directory "/var/www/localhost/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
	<IfModule mod_setenvif.c>
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
</IfModule>
	<IfModule mod_log_config.c>
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</IfModule>
	<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
</IfModule>
	</VirtualHost>
	</IfModule>
	</IfDefine>
</IfDefine>

He tret els comentaris que porta el fitxer perquè no es fassi tan llarg. Però la part més important us la comento a continuació:

ServerName www.exemple.com
SSLCertificateFile /etc/apache2/ssl/server_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/server_key.pem
SSLCACertificatePath /etc/apache2/ssl/
SSLCACertificateFile /etc/apache2/ssl/cacert.pem
SSLVerifyClient require
SSLVerifyDepth  2

La primera línia és la nota que us he posat abans sobre el ServerName, o sigui, posar-lo igual que el ‘Common Name’ del certificat. El certificat signat del servidor SSLCertificateFile, la clau privada del certificat SSLCertificateKeyFile el directori on guardem les entitats de certificació arrel (root CA) SSLCACertificatePath /etc/apache2/ssl/ i el fitxer que conté el certificat de la nostre entitat de certificació arrel SSLCACertificateFile.

Les últimes dues línies són les més interessants: SSLVerifyClient indiquem si cal que el client tingui o no tingui certificat. En aquest cas requerim que el client tingui certificat per funcionar. Finalment a la última línia indiquem quina és la tolerància que donem als certificats que acceptem. És a dir, fins a quina profunditat confiem amb les entitats que poden haver emès aquest certificat. Diguem que és un tecnisisme d’herència entre entitats de confiança jo hi he posat un 2 però podeu posar-hi qualsevol número >1 i funcionarà sense problemes.

Configuració del client

Aquí només us comento com es fa amb el firefox, però amb el MSIE i el Netscape es fa quasi igual, segur que us en sortiu. Jo no només he afegit el certificat client que seria el normal sinó també el certificat de la entitat arrel (root CA) així el navegador no em pregunta cada vegada si ha de confiar amb el certificat que rep d’una root CA que no coneix.

Anem al menú Edit -> Preferences -> Advanced -> Manage Cerficates:

firefox1.png

Ara instal·lem el certificat client, anem a ‘Your Cerficates’ i premem ‘Import’ seleccionem el fitxer i importem el nostre certificat iestuff.p12:

firefox2.png

Per instal·lar el certificat del ‘root CA’ anem a la pestanya ‘Authorithies’ premem ‘Import’ i importem el fitxer cacert.pem:

firefox3.png

Conclusions

Sembla molt llarg tot el procés, però realment no ho és tan simplement que explicant sempre t’allargues més del que realment després has de fer a més he intentat ser força fidel en tot el que he fet en cada pas. Es podria haver simplificat molt més. No patiu per la part del servidor penseu que si us enganxeu el vostre problema és que coneixeu poc l’apache i d’això a tot arreu n’hi ha gent que en sap i de manuals en teniu per aburrir. Pel que fa el tema del client com podeu veure és molt senzill i si la resta esta bé funcionarà a la primera.

Enllaços

Per montar tot això he usat bàsicament dos sites que m’han ajudat moltíssim:

Repetidors GSM/GPRS/UMTS domèstics/SOHO

Reading time: 3 – 5 minutes

Sovint, sobretot la gent que viu en àmbits rurals, tenim problemes de cobertura amb els nostres telefons mòbils a casa, a l’oficina, a l’empresa, etc. Si consultem el tema a l’operador normalment ens diuen que no és viable ampliar la cobertura a la zona on sóm perquè no surt rentable o qualsevol altre motiu que ens tanca les portes a solucionar el problema.

repeater.jpg

Aquest problema malgrat viure al camp no l’havia patit massa, ja que visc a una zona força elevada i aconseguia cobertura de repetidors dels operadors força llunyans. Però al començar a treballar en dades això ja comença a donar alguns problemes importants. Així doncs m’he decidit a donar un cop d’ull al que comento al titol.

El que primer he trobat i que potser és més a l’avast és el material de la gent de xacom. Aquesta colla estan especialitzats en vendre modems gprs i d’altres similars. En el fons venen material de marca blanca remarcat com a xacom, especialment de la marca Siemens.

xacom.gif

Doncs bé Xacom té un aparell molt econòmic que és el CB-128 que malgrat ser un amplificador i no un repetidor es pot usar com a repetidor si connectem dues antenes una de recepció i una d’emisió encomptes de posar directament l’amplificador al connector d’antena del terminal mòbil. No és res de l’altre món però per donar cobertura a una habitació esta prou bé. Tot i amb això només és bi-banda i no soportaria UMTS. De fet, les especificacions no diuen res de GPRS però jo diria que si que hauria de funcionar.

Si busquem per internet podrem trobar el mateix dispositiu venut pel que jo diria que és el seu fabricant original Powertec Telecommunications. Concretament el model CB-128 a la seva botiga online costa uns 190$. als que caldria afegir el cost de les antenes que li volguem posar per millorar la senyal. Sovint amb això en tindrem més que de sobres per molts casos sobretot si parlem d’amplificar veu. Però per dades l’he trobat una mica limitat al no parlar de GPRS ni suportar UMTS.

Cal afegir però que tan Powrtec com Xacom, tenen repetidors propiament dits a les seccions corresponent del seu cataleg de productes. Perquè us feu una idea si parlem de sistemes monobanda i sense parlar de suport de dades, cosa que no vol dir que no funcionin, el cost està a partir dels 400$. Un repetidor per una nau podria costar uns 1000$ més antenes, així doncs per un cost raonable podeu tenir veu a la vostre nau sense cobertura.

andrew

Si voleu posar un repetidor més professional amb suport explicit de GPRS, EDGE, UMTS, etc. us recomano que us mireu els links que hi ha a: mobilecomms-technology.com. Concretament una boníssima empresa que es dedica al tema des de fa temps és Andrew és americana i molt usada arreu del món inclòs el nostre país. A la web anterior podeu trobar un resum del material que heu d’usar d’Andrew per montar un repetidor amb suport 2G, 2’5G i 3G: Andrew – Indoor and Outdoor Mobile Network Coverage and Capacity Solutions.

btscanner – buscant bluetooth

Reading time: 1 – 2 minutes

Una eina que es dedica a buscar i recollir tota la informació possible als dispositius bluetooth que tenim a l’avast, l’interessant és que no executa cap ordre que requereixi emparellar el nostre ordinador amb el dispositiu bluetooth detectat. Realment interessant per mi però no tan per la útilitat directa que té sinó pel fet de poder veure com treballa a nivell de codi. Ja que fins ara poc més havia vist que les bluez-utils que tingués un codi prou simple com per mirar-se’l amb calma.

Una captura de pantalla del btscanner en acció:

btscanner.png

Si voleu provar l’eina: btscanner download obviament pensada per treballar amb linux.

Nus de la corbata

Reading time: < 1 minute

corbata.jpg

Més cops dels que voldria em veig obligat a portar corbata. Però cada cop que me l’he de posar m’han de fer el nus perquè sóc una mica inútil amb els temes manuals. Així que si mai us animeu a aprendre a fer el nus: nudo-de-corbata.com. Jo ja us aviso que de moment no em veig amb ànims d’aprendre cap dels diversos nusos que de forma tan “senzilla” ens ensenyen a la web.

Fa molt de temps em sembla que el Benja em va passar un link semlant a aquest per la mateixa finalitat però la veritat és que ja no el recordava i tal com us he dit continuo sense saber-me fer el nus.

VRA de Vodafone (GPRS/UMTS) amb linux

Reading time: 6 – 10 minutes

Com ja heu anat podent llegir en els últims posts estic provant la targeta 3G de Vodafone. Per poder iniciar un desenvolupament per un tema de feina. Així doncs després de comprobar com funciona amb windows tan amb el software de comunicacions de vodafone (VMC) com a través de l’acceso telefonico a redes del win. M’he decidit a donar-hi un cop d’ull amb Linux. La veritat és que sorprenenment la cosa ha estat molt més senzilla del que em pensava. Fins hi tot he trovat molta més documentació de la que vaig trobar fa més d’1any quan vaig provar la targeta que llavors només era GPRS.

Malgrat tota la documentació que he trobat per internet parlava de la targeta Option model 5000 us puc confirmar que aquesta també aplica al model 6300. Com podreu veure amb les fotos que us penjo a continuació jo he provat les dues la 5000 i la 6300 ja que una la tinc de fa força temps però no tenia targeta per provar-la i l’altre és la que hem comprat pel projecte.

VRA model 5000:

vra5000.jpg

VRA model 6300:

vra6300.jpg

Configurant el sistema

Tornant al tema linux, doncs bé ambdues targetes disposen d’un bridge intern entre un bus PCMCIA i un HUB USB de 3 ports. Així doncs, per tal de que funcionin heu de tenir el vostre sistema PCMCIA configurat i us heu d’assegurar que es llença el modul usbserial i ohci_hcd que seran els que faran carregar el HUB USB que hi ha dins la PCMCIA i fer apareixer els corresponents ports serie per poder accedir al modem. Si mireu els missatges del kernel podreu veure algo semblant a això (dmesg):

usb 5-1: new full speed USB device using ohci_hcd and address 2
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
drivers/usb/serial/usb-serial.c: USB Serial support registered for Option 3G data card
option 5-1:1.0: Option 3G data card converter detected
usb 5-1: Option 3G data card converter now attached to ttyUSB0
option 5-1:1.1: Option 3G data card converter detected
usb 5-1: Option 3G data card converter now attached to ttyUSB1
option 5-1:1.2: Option 3G data card converter detected
usb 5-1: Option 3G data card converter now attached to ttyUSB2
usbcore: registered new driver option
drivers/usb/serial/option.c: Option Card (PC-Card to) USB to Serial Driver: v0.4

El que us pot portar a confusió és quan mireu els dispositius USB que teniu connectats al sistema (lsmod):

# lsusb
Bus 005 Device 002: ID 0af0:5000
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 003: ID 413c:8000 Dell Computer Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 004: ID 0d3d:0001 Tangtop Technology Co., Ltd
Bus 001 Device 001: ID 0000:0000

Podeu veure que a la primera línia malgrat no hi ha cap descripció té un dispositiu connectat del venedor amb el codi: 0x0af0 (idVendor, o sigui, Option) i el model del dispositiu: 0x5000 (idProduct). Com podeu veure ara mateix el que tinc connectat és la targeta model 5000 la 6300 simplement apareix aquest número enlloc de l’altre.

Jo he fet les proves amb un kernel 2.6.13.2 (amb udev, devfs ja no es suporta a la v.2.6.13). Si el que vull és verificar que se m’han creat els ports serie amb els que accediré al modem puc fer algo tan senzill com:

$ ls -l /dev/tts
total 0
crw-rw----  1 oriol tty   4, 64 Sep 25  2005 0
crw-rw----  1 oriol tty   4, 65 Sep 25  2005 1
crw-rw----  1 oriol tty   4, 66 Sep 25  2005 2
crw-rw----  1 oriol tty   4, 67 Sep 25  2005 3
crw-rw----  1 root  tty 188,  0 Sep 25 17:29 USB0
crw-rw----  1 root  tty 188,  1 Sep 25 17:28 USB1
crw-rw----  1 root  tty 188,  2 Sep 25 17:28 USB2

Notes sobre el kernel

Aneu en compte perquè no es configura igual la targeta per kernels >2.6 i <2.6.13 que pels >2.6.12. Més informació al link [2] de la secció de links. Els primers només necessiten el mòdul usbserial i ohci_hcd. Els més nous porten un mòdul dins la secció USB Serial del kernel especific pels mòdems GPRS/UMTS de la marca Option (CONFIG_USB_SERIAL_OPTION=m). Per tant, heu d’usar els dos mòduls anteriors més el modul específic.

Accedint al modem amb el minicom per introduir el PIN

El primer que hem de fer és introduir el codi PIN de la targeta SIM, notareu que quan la targeta esta configurada i encara no em entrat el PIN els dos LEDs que porta un fa pampallugues de color verd i l’altre de color vermell després d’entrar el PIN la vermella hauria de desapareixer.

Per posar el PIN de moment no he buscat cap sistema que ho fassi automàticament. Així doncs ho he fet a mà. Amb el minicom la configuració que he usat per entrar-hi és la següent: (minicom -s)

minicom.png

Per introduir el PIN només em d’entrar al minicom i escriure: AT+CPIN=”1234″, sent 1234 el nostre PIN. Si el PIN és correcte el modem ens tornarà un OK i al cap d’uns 30s el llumet vermell s’apagarà.

Aprofitant que estem al minicom podem aprofitar per llençar algunes ordres més a través de les comandes AT:

  • AT+CSQ torna el nivell de senyal que estem revent. Per tenir una connexió acceptable en GRPS/UMTS hem de rebre almenys un nivell 12. Jo a casa només rebo entre un 5 i un 9 per això em falla tan l’enllaç.
  • AT&V ens permet consultar les configuracions que porta la targeta de serie.
  • AT_OPSYS=”0,2″ només acceptem enllaços per GPRS
  • AT_OPSYS=”1,2″ només UMTS.
  • AT_OPSYS=”2,2″ preferiblement GPRS.
  • AT_OPSYS=”3,2″ preferiblement UMTS.

Configurant el dial-up

Com a programa per gestionar les connexions a internet he usat el gnome-ppp. Recordeu que l’usuari que llenci aquest aplicatiu ha de tenir permisos (amb read+write n’hi ha prou) sobre el dispositiu de modem (en el meu cas /dev/tts/USB0). La configuració del dia-up és molt simple us la poso en aquestes captures:

screen1.png
screen2.png
screen3.png
screen4.png

Conclusió

Bé doncs, amb tot això n’haurieu de tenir prou per poder configurar les VRA 5000 o 6300 de Vodafone. No oblideu que per molt Vodafone que posi, l’empresa que realment fabrica les targetes és OPTION. Per aconseguir ajuda per internet sempre pot ser útil. Tot el que he explicat aquí ho he extret els links que us engaxo a continuació.

Links

Servidors web i de fitxers i servidor web alimentat amb patates

Reading time: 2 – 2 minutes

Primer de tot comentar que no m’he pogut aguantar més i m’he configurat la targeta 3G al portatil amb el guindows… la cosa de moment només puc dir que va i no va… o sigui, hi ha moments que va prou ràpid i d’altres en que es queda tonto i has de recarregar les pàgines perquè funcionin. Potser el més destacable és comprobar que el SSH funciona. Que tinc una IP pública i que a més tinc tots els ports visibles des d’internet, o almenys això sembla de moment. Però els KBytes sumen i sumen i la informació rebuda no compensa. Sort de la tarifa plana… això continua igual de malament que fa 1 any quan ho vaig provar per primer cop.

Tornant a l’article en qüestió us penjo una granja de servidors:

serverfarm.jpg

Doncs si nois és una micro-granja de servidors amb dos servidors un de web i un de fitxers, potser els més petits del món o això diu el seu autor. Més informació sobre aquesta curiositat tan interessant a: WebACE I (servidor web) i WebACE II (servidor de fitxers).

Del mateix autor la seva última creació, el servidor web alimentat per l’energia que generen les patates:

spud.jpg

Si voleu veure com funciona amb tot detall aquest micro-servidor a base de patates: Spud.

VRA de Vodafone

Reading time: 2 – 4 minutes

vra.gif

Acabo d’arribar a casa: BIEN!!! Com haig d’anar de cansat entre la feina d’aquí i la d’Andorra. Tan viatjar i a més la m___ de connexió que tinc a allà d’alt que fa més d’1 setmana que tinc la VRA de Vodafone 3G amb tarifa plana i encara ni l’he obert. Com que el tràfic de dades no té roaming a Andorra doncs la veritat tampoc l’he pogut provar.

Això si tants quilòmetres amunt i avall tinc una d’informació inútil que vaig aprenent per la carretera, què és informació inútil. Per exemple, a Andorra hi ha un hotel molt famós que es diu: Roc blanc doncs a Ponts, un dels famosos pobles pels que es passa per anar a Andorra des de casa meva hi ha un hotel que es diu: pedra negra. Interessant,eh!?

Doncs res nanos, altres efectes d’anar tan avui i avall és tenir dies com el que m’espera demà, no us perdeu l’horari que m’espera:

  • 9:00-9:15 trucada d’un projecte de seguretat nou
  • 9.15-10:30 reunió per montar una nova vpn per un client
  • 10:30-13:00 reunió amb l’equip de programació d’AS2
  • 13:00-14:00 reunió amb partner del projecte movilpoint
  • 16:00-18:00 reunió pel tema d’una web de música

Com mola el meu dia,eh!? això si quan plegui me’n penso anar de pet cap a casa em fotre una dutxa ben relaxant i entraré en mode vegetal fins dilluns així que si algú em parla i no li contesto que no s’ho prengui com algo personal perquè la setmana que vé no pinta molt millor 🙂

UpDate: podeu veure més informació sobre les primeres proves amb la VRA a: Servidors web i de fitxers i servidor web alimentat amb patates.

UpDate 2: mentre espero que vingui la reunió de les 16h m’he connectat amb la VRA que ara automàticament m’ha passat a 3G des de l’oficina de Cornellà. La cosa va molt millor que des de casa, ni punt de comparació. No diria que és com una ADSL de 256 però de moment pel que veig poc li té que envejar. Aquesta afegit l’estic fent des de la VRA. He vist com a nota curiosa que la IP que em sortia des de casa era del tipus 212.x.x.x i la que m’ha sortit des de Cornellà és 62.x.x.x no sé si canviarà segons si uso 3G o GPRS ja us ho comentaré.

Canviar el directori d’spool de windows

Reading time: 3 – 5 minutes

Les cues d’impresió al windows estan a: %SystemRoot%\system32\spool\PRINTERS si pel motiu que sigui necessitu canvi la localització d’aquestes cues, podeu editar la següent entrada del registre:

System Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers]
Value Name: DefaultSpoolDirectory
Data Type: REG_SZ (String Value)
Value Data: Full path to printer spool directory

NOTA: no oblideu que perquè això tingui efecte cal re-iniciar el sistema.

FONT: Changing the Default Printer Spool Directory (Windows NT/2000/XP)

Passant nou firmware a un Cisco via tftp

Reading time: 2 – 4 minutes

cisco.gif

Seguint amb la línia d’explicar tonteries sobre els Cisco, coses molt simples que passen poc sovint i que quan passen mai recordem com es feien. Avui vull fer-me un petit apunt a com carregar un nou IOS a un router de Cisco.

Primer cal que tinguem al nostre PC instal·lat un servidor de TFTP amb el nou IOS apunt per descarrega. Un bon manual per configurar el atftp en gentoo: Gentoo Linux based Netboot HOWTO (cache)mireu-vos només la secció: The tftpd Daemon. Després cal connectar-se al router amb el cable de consola de Cisco (DB9-RJ45) com sempre amb el minicom (programa terminal que uso des de linux per configurar els routers, equivalent a l’hyperterminal del win). Recordeu que la configuració serie és 9600bps, 8 bits dades, sense control de fluxe i 1 bit stop (9600 8N1).

Posem al portatil, per exemple, la següent configuració: 10.0.0.2/255.255.255.0 i a la fastethernet interface del cisco: 10.0.0.1/255.255.255.0.

Router>enable
Router#
Router# config t
Router(config)# interface fastethernet 0/0
Router(config-if)# ip address 10.0.0.1 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)#exit
Router(config)#exit
Router# wr mem
Destination filename [startup-config]?  enter

Comproveu que podeu ‘pinguejar al router’. Després de confirmar que tenim enllaç només cal assegurar-nos de que el servidor TFTP i el IOS estan apunt per ser descarregats pel router.

Comença el procés interessant, el canvi de IOS:

Router#copy tftp flash
Address or name of remote host []? 10.0.0.2   /* ip portatil */
Source filename []? c1700-y7-mz.122-15.T7.bin /* nom del IOS */
Destination filename [c1700-y7-mz.122-15.T7.bin]? enter /* nom IOS al router */
Accessing tftp://10.0.0.2/c1700-y7-mz.122-15.T7.bin...
Erase flash: before copying? [confirm] ? enter
Erasing the flash filesystem will remove all files! Continue? [confirm] enter
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erasedee
Erase of flash: complete
Loading c1700-y7-mz.122-15.T7.bin from 10.0.0.2 (via FastEthernet0): !!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 6393852 bytes]
	Verifying checksum...  OK (0x5D11)
6393852 bytes copied in 78.804 secs (81136 bytes/sec)
Router#
Router#reload
Proceed with reload? [confirm] enter

Ja tenim el nou IOS al router ara quan acabi de rebotar podem comprovar que així és:

Router>en
Router#sh version
Cisco Internetwork Operating System Software
IOS (tm) C1700 Software (C1700-Y7-M), Version 12.2(15)T7,  RELEASE SOFTWARE (fc2)
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Sat 09-Aug-03 06:42 by ccai
Image text-base: 0x80008120, data-base: 0x80AB2194
	ROM: System Bootstrap, Version 12.2(7r)XM2, RELEASE SOFTWARE (fc1)
	Router uptime is 23 minutes
System returned to ROM by reload
System image file is "flash:c1700-y7-mz.122-15.T7.bin"
Scroll to Top