Subversion: Com ignorar tots els arxius excepte els que ens interessa.

Per ignorar-ho tot excepte els php, la comanda seria la següent:

# svn propset svn:ignore "*[!p][!h][!p]

# *.php?*" .

És a dir, cadascuna de les lletres de l'extensió entre [] i negada (amb !) i a la segona lína tal qual entre *. i ?*.

Vist a: http://www.thoughtspark.org/node/38

Opera per fi suportarà peticions CORS

Amb un retràs important respecte la resta de navegadors, finalment Opera suportarà peticions CORS (Cross-Origin Resource Sharing)
http://my.opera.com/core/blog/2011/10/28/cors-goes-mainline

Freqüència i Temperatura de la CPU, i apagat del sistema des de la línia de comandes

Ara que és estiu, amb la calor els portàtils sovint pateixen problemes de temperatura. A continuació algunes de les comandes que es poden executar per crear scripts a mida per gestionar alarmes i accions "proactives" per evitar sobrecalentaments.. funcionen en el meu Ubuntu 11.04, i la gràcia és que no cal tenir privilegis de "root" per executar-les:

Comandes per obtenir la temperatura dels cores de la CPU:
# sensors | grep 'Core 0' | cut -c15-16
# sensors | grep 'Core 2' | cut -c15-16

Comanda per canviar la política de l'escalat de la freqüencia de la CPU (previ un # sudo apt-get install hal)
# dbus-send --print-reply --system --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.CPUFreq.SetCPUFreqGovernor string:powersave

Comanda per suspendre l'ordinador a RAM
# dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend

Establir el monitor primari en Gnome

Actualment, i amb la ubiqüitat del portàtils, les configuracions multi-monitor han esdevingut la norma i no l'excepció. Per això em sorprenen bugs (per omissió) com el del selector de configuració dels monitors de Gnome "gnome-display-properties":

https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/206528

No hi ha una manera visual directe d'establir quin ha de ser el monitor principal... Per sort la solució és senzilla:

xrandr --output VGA1 --primary

on VGA1 és el nom del monitor que ha de ser el primari.


Per llistar els monitor detectats es pot executar xrand sense cap paràmetre. Addicionalment, l'arxiu monitors.xml (situat a en els Ubuntus recents "~/.conf")



No hi ha manera de seleccionar quin monitor ha de ser el primari:

Configuració d'ESMP, un senzill MTA re-enviador de correu sortint.

Moltes vegades es vol poder enviar tot el correu sortint d'una màquina de manera senzilla a través d'un altre servidor, el que es coneix com a relay host. Una possibilitat, en comptes de tenir instal·lat un MTA complet (sendmail, postfix, qmail,... per anomenar-ne alguns) es pot usar esmtp. Aquest paquet ens proporciona aquesta funcionalitat de manera ràpida i efectiva. A tall d'exemple per posar-lo en marxa en un sistema Debian només calen 3 passos:

Pas 1: Instal·lar-lo (en Debian aquesta instrucció també desintal·la exim4, l'MTA per defecte), executar:

# sudo apt-get install esmtp esmtp-run libesmtp5

Pas 2: Editar la configuració tot informant les dades del host a través del que es volen enviar els issatges:

# sudo nano /etc/esmtprc

Concretament cal informar aquestes 3 dades:

hostname = XXXXXXXXXXX:25
username = YYYYYYYY
password = ZZZZZZZZ

Pas 3: Fer una prova de que efectivament funciona:

# echo "Prova" | sendmail adreça@de_correu.vàlida

Permetre crides AJAX des d'un domini diferent (Peticions "Cross-site")

El servidor específica en la resposta HTTP a quins dominis permet efectuar consultes (si és que n'hi ha algun més que el propi d'on es troba allotjat) mitjançant la capçalera "Access-Control-Allow-Origin"

Així doncs si la crida AJAX va cap a un recurs PHP que es trobi en un domini diferent es pot fer si modifiquem l'script PHP perquè retorni una capçalera "Access-Control-Allow-Origin" adequada:

header('Access-Control-Allow-Origin: http://domini_desdonhiha_el_javascript_amb_ajax.com');

o fins i tot per permetre qualsevol origen:

header('Access-Control-Allow-Origin: "*"');

D'altre banda si no es tracta d'un PHP o no ho podem modificar les capçaleres HTTP

per la raó que sigui, l'Apache es pot configurar mitjançant directiva o mitjançant un arxius .httacces per afegir-la, en aquest darrer cas la directiva podria ser:

header add Access-Control-Allow-Origin *

Cal tenir el mòdul "mod_headers" d'apache carregat perquè funcionin aquestes directives. En Debian/Ubuntu seria assegurant-nos que a "/etc/apache2/mods-enabled" existeix el headers.load ( i si no és així enllaçant-li des dels mods-available amb un "ln -s /etc/apache2/mods-available/headers.load /etc/apache2/mods-enabled/headers.load")

Un exemple d'afegir la capçaera mitjançant la directiva a l'arxiu de configuració seria afegir

Header set Access-Control-Allow-Origin "*" a l'arxiu de configuració del lloc web, per exemple dins de la secció que ens interessi. En aquest cas, per què Apache agafi els canvis de configuració caldria reiniciar-lo

sudo /etc/init.d/apache2 reload

Ús del Subversion, pas a pas

Malgrat està una mica "passat de moda" i els projectes mínimament grans sembla s'han passat tots a git o mercurial, Subversion encara és útil en molts casos... A continuació un pas a pas realitzat en un Ubunu 10.04 (LTS) Server, esquemàtic, de com posar en marxa un repositori i la seva utilització bàsica com a "client" del repositori des de la línia de comandes.

De tota manera per als clients, des de la meva experiència, és recomanable usar alguna eina gràfica, i les més recomanables són el TortoisSVN pels clients Windows i el Rabbitvcs per GNU/Linux, apart, és clar, del plug-in Subclipse si es desenvolupa des d'Eclipse.

INSTAL·LACIÓ:

Instal·lar els paquets

# sudo apt-get install subversion libapache2-svn

Configurar un repositori: crear-lo

# mkdir /home/usuari/repositori

# svnadmin create /home/usuari/repositori/projecteX

Configurar un repositori: servir-lo via apache

# sudo chown -R www-data:www-data /home/usuari/repositori/

# sudo nano /etc/apache2/sites-available/default

I afegir-hi :

DAV svn

SVNParentPath /home/usuari/repositori

SVNListParentPath On

AuthType Basic

AuthName "Repositori de Control de Versions"

AuthUserFile /etc/subversion/passwd

Require valid-user

# sudo htpasswd -c /etc/subversion/passwd usuari_http

# sudo apache2ctl restart

Configurar una acció automàtica al servidor després de cada “commit”

# vi /home/usuari/repositori/projecteX/hooks/post-commit

I afegir-hi les accions que volguem, per exemple, actualitzar una carpeta amb els contiguts:

/usr/bin/svn update /var/www/test >> /var/log/svn/deploy.log 2>&1

En aquest exemple, caldrà que “/var/log/svn” existeixi i tingui permisos per l'usuari “www- data”

ÚS:

Importar els continguts el primer cop al repositori

# svn import /home/usuari/prjX_backup file:///home/usuari/repositori/projecteX

Descarregar els continguts del repositori a una carpeta "publica_projecte", el primer cop

# svn co file:///home/usuari/repositori/projecteX /var/www/publica_projecte

Actualitzar la carpeta amb els canvis que hi hagi al repositori

# svn update /var/www/publica_projecte/

Afegir nous continguts a la carpeta i “pujar-los” al repositori

# mkdir /var/www/publica_projecte/nova_carpeta

hi copiem o hi creem els continguts que calgui amb “cp” o com ens sembli...

cd /var/www/publica_projecte

# svn add nova_carpeta

# svn commit

Enviar els canvis fets al repositori

En general qualsevol canvi o modificaió als continguts que es vulguin “pujar” al servidor.

# cd /var/www/publica_projecte

# svn commit

Fonts:

https://help.ubuntu.com/10.04/serverguide/C/subversion.html http://elliotth.blogspot.com/2005/02/better-subversion-post-commit-hook.html

SSH invers.

Ho he fet 30 vegades però cada cop he hagut de buscar els passos exactes.. per futura referència i per si pot ajudar a algú.

Escenari: Volem connectar-nos a un equip a

mb connexió a internet però que no té cap port “accessible” i que només port sortir pels ports 53, 80 i 443 Disposem d'un servidor a Internet amb IP pública i que controlem (anomenem-la IP_PÚB_NOSTRE_SERVER)

1. Al servidor que controlem hi creem un usuari per fer la connexió SSH inversa. Per exemple amb l'script “adduser” dels Debian/Ubuntu.

# sudo adduser tmp

2. Per seguretat, i si ens interessa que aquest compte "tmp" que hem creat, i que serà usat al client no pugui obtenir una un cónsola de comandes al servidor, editem l'arxiu /etc/passwd al servidor ihi canviem el "/bin/bash" del final de la linea de l'usuari "tmp" per /usr/sbin/nologin (o la localització d'aquest nologin... si tenim dubtes, ens assegurem que existeix amb un “locate nologin“)

tmp:x:1001:1001:Temporal,,,:/home/tmp:/usr/sbin/nologin

3. Al servidor editem l'arxiu de configuració del servei ssh a “/etc/ssh/sshd_config” i hi afegim que escolti per algun dels ports que el client pot usar per sortir.. per exemple el 53 (nota: ha de ser un port que estigui “lliure”, és a dir que si tenim per exemple l'apache escoltant pel port 80, no el podrem usar). Cal afegir a sota del Port 22 que hi ha per defecte:

Port 53

4. Reiniciem el servei sshd i anem al client. (p.e. /etc/init.d/ssh restart)

5. Al client fem la comanda del ssh invers pròpiament dit:

# sudo ssh -R 4430:localhost:22 tmp@IP_PÚB_NOSTRE_SERVER -p 53 -N

El primer cop ens demanarà...
The authenticity of host ' IP_PÚB_NOSTRE_SERVER (IP_PÚB_NOSTRE_SERVER)' can't be established. RSA key fingerprint is xx:xx:xx:a1:5f:1a:89:78:90:7b:2e:22:9a:xx:xx:xx. Are you sure you want to continue connecting (yes/no)?

escrivim que sí, i ens demanarà el password de l'usuari “tmp” que hem creat més amunt al server amb l'”adduser” i s'hauria de quedar a l'espera...

6. Només falta que, ara ja des del server, ens connectem al port 4430 del localhost host que realment està redirigit cap al ssh del client:

# ssh USUARI_CLIENT@localhost -p 4430

En aquest exemple, USUARI_CLIENT és un usuari vàlid per fer una connexió ssh al client, i IP_PÚB_NOSTRE_SERVER és la IP pública del nostre servidor, i el port és el 4430 però podria ser qualsevol no tallat.

A Google ho tenen clar, la culpa és de Microsoft.

Per aquells sorpresos que Google hagi decidit deixar d'usar Windows internament tot dient que les falles de seguretat són culpa d'aquest, ho haurien pogut pre-veure llegint el missatge d'error que Google Chrome mostra quan falla inesperadament en un sistema Windows: "Google Chrome no és responsable d'aquests actes", tot referint-se al pet que ha fet l'aplicació fa uns instants

Checking for corrupt, not cleanly closed and upgrade needing tables..

Després d'actualitzar el mysql 5.0 al 5.1 en un Debian Lenny, al reiniciar el servei em donava el següent missatge (un error o warning, pensava jo):

debian:~# /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

En un primer moment em vaig pensar que potser calia executar a mà l'actualitzador de les dades entre versions de mysql. Però no, la seva execució deia que les dades ja estaven actualitzades:

debian:~# mysql_upgrade -p
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
This installation of MySQL is already upgraded to 5.1.44, use --force if you still need to run mysql_upgrade

Total, que després d'una cerca a internet vaig trobar el resultat... El missatge està mal triat amb ganes. A continuació us mostro entre [ ] la part del missatge que es dóna per sobre-entesa...

"[I am now] Checking for corrupt [tables]"
"[I am now checking for ], not cleanly closed [tables] and "
"[I am now checking for ] upgrade needing tables"

És a dir, que mysql simplement va dient què és el que està fent: 1. Comprovar si hi ha taules corruptes, 2. [Comprovar si] hi ha taules tancades inesperadament i, finalment, [Comprovar si alguna taula] necessita ser actualitzada...

Missatges d'error poc amigables

Tot i que no està a l'alçada d'alguns missatge d'error que es poden trobar en el S.O. privatiu més utilitzat al món, de tant en tant el GNU/Linux (concretament GNOME 2.26 a Fedora 11) també te'n pot deixar anar alguna de bona...
Aquest missatge me'l donava després d'intentar tancar el procés d'actualització de la distribució... jo m'he quedat pensant "Millor que no triï Quit, però... si tanco, no estaré també cancel·lant? Aleshores millor cancel·lo, però.... no m'està dient que no puc cancel.lar? per tant.... mmmm....." :)

WAP54G en mode client

Per connectar la meva xarxa amb cable a una xarxa wifi de manera permanent m'han deixat un Linksys WAP54G (versió 2). L'aparell té 2 interfícies, la wifi i un port ethernet. Com que el Firmware per defecte no permet posar el punt d'accés a mode client, i altres invents no són posibles (p.e. WDS) hi he instal·lat una versió del firmware modificada per SveaSoft, el Freya v2.06 (trobat a http://www5.musatcha.com/musatcha/computers/kismet_on_the_linksys_wap54g.htm) i que es pot carregar al dispositiu mitjançant l'opció “upgrade” disponible a la mateixa interfície d'administració que ve de fàbrica amb el dispositiu.

Amb el nou firmware instal·lat i des de l'interfície web d'administració del router es pot acitvar el telnet, de manera que s'hi pugAixò permet fer la configuració del dispositiu sense haver de passar per la limitada interfície web.

El problema és que no me n'he ensortit amb el Freya i he hagut d'instal·lar una versió modificada del OpenWRT, el Freifunk. L'aventura, resumida ha anat així...

El passos fins on l'he aconseguit fer anar amb el Freya, són:

1.- wp ap 0

Canviem el mode de l'acces point per fer de client.

2.- wl scan

Que faci una llista de les xarxes que “veu”

3.- wl scanresults

Per que ens mostri el resultat de l'scan anterior

4.- wl join XarxaWifiOnVolemConectarnos

Que es connecti a la xarxa “XarxaWifiOnVolemConectarnos”. Sense cap més paràmetre ja que és tracta d'una xarxa sense seguretat WEP ni WPA ni res.

5.- wl status

Mostra l'estat de la wifi, per assegurar-nos que efectivament s'ha associat amb la xarxa que volem

Fins aquí bé. El problema l'he tingut al moment de fer funcionar l'enrutament ip...

D'una banda les targetes venen en un “bridge” o pont (el br0) entre elles que resultava amb la impossibilitat de configurar l'eth1 (la wifi) independentment.

6.- brctl delif br0 eth1

Treiem l'eth1 del pont de tarjetes.

7.- ifconfig eth1 X.X.X.X netmask Y.Y.Y.Y

Configurem l'adaptador inalàmbric amb l'IP i màscara que toqui.

Arribat aquest punt, em semblava que la cosa estava feta ja que amb un ping es veien hosts de la xarxa wifi.

El problema és que no he trobat cap manera de fer NAT de sortida pels meus hosts... la solució amb iptables ( algo com iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -o eth1 -j MASQUERADE) per emmascarar els hosts de la meva xarxa no es pot usar ja que no hi ha iptables.

Després de buscar debades per Internet, he decidit canviar d'estratègia... buscar un firmware diferent.

La versió 2 del WAP54G és un dispositiu força limitat i per això finalment m'he decantat per una versió específica pel WAP54G del Freifunk (en Català!), que és una versió especial reduïda del OpenWrt: http://wiki.freifunk.net/Freifunk_Firmware_(English)#WAP54G

Per instal·lar-lo des d'on ho havia deixat amb el Freya, m'han calgut 2 coses:

8.- nvram set boot_wait=on;nvram commit

Per activar que el dispositiu esperi uns segons després de cada reiniciada, temps durant el qual es pot transferir mitjançant el protocol “tftp” un nou firmware.

I, finalment, transferir-lo tal i com expliquen al web de Freifunk.

La configuració amb el nou firmware l'he feta mitjançant la interfície web i el manual del lloc web i m'ha funcionat a la primera :-)

Finalment, tot i que no té gaire relació amb l'entrada (una mica sí), deixo un enllaç a molta documentació super completa sobre la tecnologies de les xarxes inalàmbriques que he trobat mentre resolia el que explico en aquest post: http://www.wilac.net/index_pdf.html