Category: Networking and Internet

bar: linies de progrés per bash

Reading time: 1 – 2 minutes

Una eina senzilla i útil, a més programada totalment en shell script que encara té més merit. Servei per fer coses tan vistoses com un línia de progrés mentre fem un tar, cp, etc.

Una imatge val més que mil paraules…

bar.png

És fàcil i vistosa, oi que si? en l’exemple es veu com descomprimeixo la pròpia eixa amb una barra de progrés generada per ella mateixa.

Doneu un cop d’ull a la web, a mi m’ha agradat molt l’eina i l’he usat per fer un CD d’instal·lació d’una eina de la feina. Per si la web deixés d’existir, que això ja passa amb aquest tipus d’eines deixo una còpia del programa a l’article: bar-1.4.tar.bz2.

inotify, inotify-tools i incron: un gran descobriment per substituir dnotify

Reading time: 4 – 6 minutes

Fa forces anys, vaig parlar del dnotify és una eina que ens permetia saber quan hi havia un canvi en els fitxers d’un directori, llavors aprofitabem per llençar un procés al produir-se l’event. Com que l’arquitectura interna del programa comentat no era massa bona (controlava els canvis a base de fer pooling) i degut a les millores dels nous kernel, s’ha aprofitat el concepte de l’inotify: inotify is a Linux kernel subsystem that provides file system event notification..

Així doncs, les inotify-tools són les eines que ens permeten usar aquesta funcionalitat del kernel des de l’espai d’aplicacions d’usuari. Realment un passada. Permeten vigilar un fitxer, per generar-ne estadístiques, llençar processos associats quan es detecti un determinat canvi en el fitxer, etc. Però potser la funcionalitat que més m’ha interessat és la de la llibreria que ofereix per programar aplicacions usant les funcionalitats de l’inotify.

Concretament aquestes llibreries són les necessaries per compilar el incron. Per mi l’aplicació final més genial de totes: es tracta d’un ‘inotify cron’. Bàsicament l’eina es composa de dues parts d’un dameon i d’una taula d’accions. Aquesta taula s’usa d’una forma semblant al servei de cron. La diferència és que els events no són senyals horaris, sinó captures d’evenets del sistema de fitxers.

Un exemple d’especte que pot tenir el incrontab -l:

/var/mail IN_CLOSE_WRITE abc $@/$#

Això captura l’event cada cop que s’hagi canviat un fitxer (IN_CLOSE_WRITE) dins del directori /var/mail, després llença el programa abc passant com a paràmetre el path/file_name. Com podeu veure la potència és infinita i la simplicitat d’ús és impressionant. Potser el que més m’agrada és el fàcil que és tenir centrilitzats tots els directoris que estic controlant i les accions associades. Per exemple, és ideal per mantenir un RSS de les novetats de música, video, descàrregues, etc.

pfSense deixava de re-enviar paquets misteriosament…

Reading time: 10 – 16 minutes

Intentaré explicar-vos un ‘expedient X’ d’aquells que ja tinc resolts, però que no tinc una explicació al 100% del comportament que tenia el pfSense davant del problema. La conclusió és que el pfSense descartava paquets per tenir massa connexions concurrents, però al ser connexions UDP costava identificar-les. El problema és que de forma completament misteriosa el pfSense descartava els primers X’s paquets cap a qualsevol IP. Aquesta número indeterminat, podia ser des de 2, 3 o 4 paquets fins a 100 o 200. O sigui, que hi havia moments on donava la sensació que s’havia perdut l’enllaç. Com a pecualiaritat de la configuració del firewall (pfSense) comentar que la targeta WAN estava en mode bridge amb la targeta de servidors d’internet. O sigui, que la DMZ rep el tràfic de les IPs públiques que allà hi han filtrat a través d’un bridge d’aquestes dues targetes de xarxa que he comentat.

Exemple, de la pèrdua de paquets que comentava. Ping realitzat a una IP d’internet (la de oriol.joor.net) des del propi firewall. Realment això d’operation not permitted em va tenir molt i molt desoncertat.

# ping 80.35.31.228
PING 80.35.31.228 (80.35.31.228): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
64 bytes from 80.35.31.228: icmp_seq=9 ttl=57 time=117.668 ms
64 bytes from 80.35.31.228: icmp_seq=10 ttl=57 time=86.728 ms

Des de qualsevol de les altres potes del firewall es patia el mateix efecte, fins hi tot si es feien els pings cap a la LAN. La solució vaig trigar quasi 48h en trobar-la, era una bogeria. Ja que al final per localitzar el problema varem aïllar el firewall d’internet i el fenòmen va deixar de passar.O sigui, ja mai passava això d’operation not permitted per molt tràfic que injectessim al firewall, no passava. Així doncs, gràcies a una molt bona idea del Manu varem tancar tot el tràfic des d’internet i varem anar obrint serveis cap a la DMZ, un per un. Fins que vaig descobrir que el servei d’NTP (123/upd) era el que probocava aquest extrany efecte al pfSense.

Després de diverses proves la conclusió, és que hi havia masses connexions concurrents contra el servei que comento. Així doncs, actualment el que he fet és filtrar el número de connexions que permeto contra aquest port:

pfsense.png
<div class="imatge" style="text-align: center;"></div>

Aquestes opcions les podeu trobar editant la Rule, concretament a la sección on posa Advaced Options. Com podeu veure podeu deixar ben limitat quines connexions i quines no deixeu passar cap a un servei.

Potser el més important que he aprés d’aquesta història és no montar mai un firewall que no acompleixi la regla d’or: by default block all. O sigui, tanqueu sempre tot i ja anireu obrint a mesura que faci falta. Però a vegades per voler ser una mica més transigent ho fem alrevés i al final això s’acaba pagant, com en aquest cas. A mi ja no em tornarà a passar, espero que a vosaltres tampoc.

Tip: canviar editor per defecte en Ubuntu

Reading time: 3 – 4 minutes

Una xorrada molt útil si no t’agrada el nano que és l’editor per defecte que porta l’Ubuntu:

update-alternatives --config editor

Amb això podem escollir quin serà l’editor per defecte, simple i molt útil pels amants del vim com jo.

L’últim descobriment: Pocket Controller Pro

Reading time: 1 – 2 minutes

Com que no són hores per estar escribint al blog i porto moltíssimes hores disfrutant amb el PC. O sigui, fent coses per passar-ho bé i al mateix temps productives, que no de feina. Ara no escriure res sobre l’última troballa que he fet pel meu juget.

El Pocket Controller Pro, quedeu-vos en la captura de pantalla des d’on es veu com faig control remot de la meva HTC com si es tractes d’un PC. De moment, ja li he trobat una aplicació genial només instal·lar-ho. Escriure SMS des del PC, sense haver d’usar la pantalla tàctil:

PocketControllerPro.png

Avui he descobert moltes altres eines, com la instal·lació que he fet per primera vegada d’una eina que em va dir l’Ernest fa molt de temps, el Synergy, ús el recomano és realment genial. De fet això ho estic escribint en un WinXP controlat per Synergy a un teclat i un ratolí amb el meu portàtil amb Linux. Realment genial.

Dies de compres… HTC P3300 i Dell XPC m1330

Reading time: 2 – 4 minutes

En aquesta foto podeu veure, com l’antic Siemens S65 que ja ha fet més guerra de la que podeu somiar ahir va deixar el seu lloc al HTC P3300 alias Artemis. Així que ja podem dir que he entrar al món dels Windows Mobile. Casum dena, quina ràbia i tot perquè té el GPS i la Radio que són les dues coses que més il·lusió em fan. Per no parlar de per fi, poder sincronitzar bé els contactes i el calendari de l’evolution que tan uso.

telefons.png

De fet, la HTC no l’he comprat nova. Li he comprat al Pof de segona mà per un preu molt raonable ja que a més, tampoc té WiFi…oooohhhh. El model que ell tenia és un model de O2 sense WiFi. Però bé, espero no trobar-lo gaire a faltar. De fet, com a PDA és molt lenta però no és la meva intenció treure-li el suc en aquest sentit sinó més aviat donar-li un ús semblant a la Blackberry. Això si amb dades de caire més personal i de passada solucionar un parell de problemes de gadgets que porto al damunt.

Ja sé que havia comentat que el meu proper mòbil seria el Nokia N95 però després de tenir-lo a les mans i toquetejar-lo una mica la veritat és que m’ha decebut molt. A més diversos coneguts el tenen i la bateria realment dura un suspir, tan és així que no coneixo ningú que l’utilitzi com a únic mòbil. Realment tot això i d’altres coses com el nyigui-nyogui que el noto, gruixut i moltes d’altre tonteries que no m’han fet el pes he decidit oblidar-me d’ell. Això si, s’ha de reoneixer que té la millor càmara que he vist mai.

Aquest matí, amb en Benja també ens hem comprat una mervalla de la tècnica que no rebrem fins a Setembre, moment en el que ja ús n’explicaré més detalls. Una meravella per cada un, és clar. Però per anar fent boca el portàtil és un Dell XPC m1330 amb Core Duo 2 2.2GHz, 4Gb de RAM, 200Gb SATA i moltíssimes pijades més. De moment però, tocarà tenir paciència fins a rebre la comanda.

Com que ja estava llençant fent compres avui també he comprat a pixmania una microSD de 2Gb per la HTC, uns cascos amb microfon HiFi per veure si m’animo a grabar algún que altre poadcast i screencast que tinc pendent, a més d’un ratolí pel portàtil ja que se m’ha fet malbé el que tenia. Ah! i amb els colors corporatius de movilpoint.com el ratolí.

Ubuntu LiveCD sense CDROM i amb mode persistent

Reading time: 52 – 86 minutes

El gener passat vaig escriure sobre com arrencar un LiveCD d’Ubuntu en mode persistent, és a dir, guardant la configuració en un pendrive o disc dur de forma que els ajustos que fem a la configuració del CD no es perdin. Bé doncs, ara del que es tracta és que fem el mateix però sense el LiveCD. M’explico, l’objectiu és tenir una partició de només lectura al nostre disc dur, o en un altre disc dur on hi hagi el LiveCD copiat. Llavors usem una altre partició per guardar les modifiacions que fem sobre el CD, o sigui, la informació persistent. Això ens permet al propi GRUB tenir modes de recuperació sense haver de posar el CD. A més sempre podrem tornar enrera i tenir una configuració bàsica. I podrem treballar exactament igual que si tinguessim un LiveCD però sense tenir-lo físicament.

La solució és ben senzilla, potser el problema més greu esta en que s’ha de modificar un arxiu de configuració que es diu /scripts/casper i que es troba dintre del fitxer /boot-live/initrd.gz cosa que fa una mica entretingut modificar-lo. A continuació faig un petit cookbook de tots els passos a seguir.

    • Arrenquem des del LiveCD.
    • Creem una nova partició al disc de tipus vfat i la formategem.
    • Montem la partició i hi creem el directori /casper.
    • Copiem el contingut del directori /casper del LiveCD d’Ubuntu dins del nou directori que hem creat a la partició.
    • Suposant que a la partició persistent hi tenim instal·lat el GRUB per arrancar des de LiveCD però cridant-lo des del disc dur la configuració seria semblant a aquesta:
default 0
timeout 30
hiddenmenu
color cyan/blue white/blue
# Calling LiveCD from hard drive
title           mpti
root            (hd0,0)
kernel          /boot-live/vmlinuz boot=casper initrd=new-initrd.gz ramdisk_size=1048576 root=/dev/ram rw quiet splash vga=791 -- persistent
initrd          /boot-live/new-initrd.gz
boot
# Calling LiveCD from hard drive in single user and persistent mode
title           mpti persistent (recovery mode)
root            (hd0,0)
kernel          /boot-live/vmlinuz boot=casper initrd=initrd.gz ramdisk_size=1048576 root=/dev/ram ro single persistent
initrd          /boot-live/new-initrd.gz
boot
# Calling LiveCD from hard drive without persistent and single user mode
title           mpti w/o persistent (recovery mode)
root            (hd0,0)
kernel          /boot-live/vmlinuz boot=casper initrd=initrd.gz ramdisk_size=1048576 root=/dev/ram ro single
initrd          /boot-live/new-initrd.gz
boot
    • Ara toca modificar el fitxer /boot-live/new-initrd.gz que és el que conté la seqüència d’arrencada que ens interessa modificar. Així doncs, anem al directori /boot-live.
    • Per descomprimir el fitxer new-initrd.gz podem fer això:
mkdir new-initrd
cd new-initrd
gzip -dc /boot-live/new-initrd.gz | cpio -id
    • Dintre de /boot-live/new-initrd/scripts hi ha el fitxer casper que hem de modificar, així doncs l’editem.
    • A la línia 257 hi ha la funció is_usb_device que l’hem de deixar com segueix:
is_usb_device() {
#    sysfs_path="${1#/sys}"
#    if /lib/udev/path_id "${sysfs_path}" | grep -E -q "ID_PATH=(usb|pci-[^-]*-usb)"; then
        return 0
#    fi
#    return 1
}
    • Guardem el fitxer de configuració i tornem a crear el fitxer new-initrd, així:
# Fem una còpia l'antic new-initrd.gz per si les mosques
cd /boot-live
cp new-initrd.gz new-initrd.gz.old
# Creem el nou new-initrd.gz
cd new-initrd
find . | cpio --quiet --dereference -o -H newc | gzip -9 > ../new-initrd.gz
cd ..
rm -rf new-initrd
  • Ara ja podem reiniciar i treure el LiveCD ja que tot hauria d’arrencar com si el tinguessim posat.

Al fitxer casper és on es detecta si hi ha algún LiveCD posat a partir del qual es montarà el sistema de fitxers root. L’script busca a molts llocs si troba una unitat de CD, fins hi tot busca pendrives formatejats en vfat amb el contingut del CD, però abans d’intentar montar-los i buscar dintre seu el directori /casper i algún fitxer anomenat *.squashfs comproba que el dispositiu estigui connectat via USB.

Així doncs, la modificació que jo he fet només força que la comprobació d’USB sempre sigui certa, així també intentarà montar les pariticions dels possibles discs durs connectats o d’altres similars. Així doncs, després l’únic que faig és crear una partició vfat, crear-li el directori que busca i copiar el fitxer *.squashfs que és on hi ha el sistema de fitxers squashfs que conté l’arbre de directoris i fitxers del LiveCD.

Malgrat estic content en el resultat obtingut, m’hagués agradat aconseguir el mateix resultat sense haver de modificar els fitxers del initrd.gz ja que això fa que a l’actualitzar l’Ubuntu si hi ha modificacions en l’script casper hauré de mirar-me què ha canviat per actualitzar el meu sistema.

pop2smtp: POP3 (“recojetodo”) a SMTP amb múltiples destins

Reading time: 2 – 3 minutes

Alguns ISPs ens permeten tenir una compte que reculli tot el correu enviat a un domini, això per exemple es pot usar com a mail-backup del nostre domini. Doncs bé a través de fetchmail és molt senzill re-injectar el correu enmagatzemat a una compte POP3 a un servidor SMTP contra un usuari. El més complicat, és si el correu que hi ha a la compte POP3 pot anar a més d’un destí, com el que deia fa un moment en comptes POP3 tipus ‘recojetodo’ o cul de sac com diuen alguns.

Doncs bé, per això he fet un petit script en python que a partir d’un fitxer BSMTP modifica la companda RCPT TO en funció de la informació de l’etiqueta Envelope to que conté una llista de les comptes d’email destí a qui va dirigit el correu. Així doncs, bàsicament la tasca consisteix en buscar quines comptes d’email apareixen a l’etiqueta comentada i després borrem la comanda RCPT TO i creem tantes comandes d’aquest tipus com faci falta en el seu lloc per enviar copies del correu que volem enviar als seus destins. Aquest nou fitxer BSMTP modificat l’injectem al nostre MTA. Aquest MTA serà l’encarregat de processar aquest correus i entregar-los a les comptes destí.

En el meu cas he decidit fer un petit shell script que s’executa des del crontab cada 10min. Aquest script, Crida a fetchmail per obtenir el fitxer BSMTP amb el correu que hi havia a la compte POP3, després crida l’script de python per modificar el fitxer BSMTP d’entrada tal com he comentat i crea un nou fitxer BSMTP de sortida. Finalment aquest fitxer s’injecta via SMTP cridant un petit script que gràcies al NetCat envia per SMTP el contingut del fitxer BSMTP de sortida.

L’script amb l’estructura de directoris empaquetat en un fitxer: pop2smtp_r1.tar.gz.

Segur que hi ha formes més elegants de resoldre el problema, però la veritat no les he sabut trobar.

Clonant una Ubuntu

Reading time: 32 – 53 minutes

Disposava d’un servidor en una màquina virtual d’VMWare que esta en producció i per tant, no era bona idea apagar-lo. La idea era montar una altre màquina física igual per posar-la en producció per quan la primera falli. Doncs bé, havia de montar una màquina igual que la de producció amb la mateixa configuració del servidor en producció. La cosa se m’ha allargat una mica malgrat els passos són simples. Bàsicament m’he trobat amb problemes tontos que per no estar habituat a usar Ubuntu m’han portat més temps del previst.

Per començar del host en producció aconseguim un llistat del paquets instal·lats, llencem la següent comanda des del directori i l’usari root:

dpkg --get-selections | grep -v deinstall > llista_paquets

A continuació ja podem fer tots els processos des de la màquina que anem a instal·lar. En la segona màquina he instal·lat una Ubuntu Server 6.06.1 LTS (Long Time Support) igual que en la primera, he fet una configuració de servidor normal (no LAMP) configurant el hardware adequat perquè tot funcioni. Un cop acabada la instal·lació:

# Copiem configuració del APT de producció al nou servidor
rsync -cavz root@ip_produccio:/etc/apt/ /etc/apt/
# Actualitzem repositori
apt-get update
# Actualizem paquets bàsics de la distribució
apt-get dist-upgrade
# Copiem llistat de fitxers de producció
rsync -cvz root@ip_produccio:/root/llista_paquets /root/
# Marquem paquets a instal·lar en local
dpkg --set-selections < llista_paquets
# Entrem al gestor de paquets dselect
dselect
# Ara premem la tecla 'I' i després 'intro' perquè comenci la
# descarrega i instal·lació de paquets
# Finalment premem la tecla 'Q' i 'intro'

En aquest punt ja tenim els mateixos paquets instal·lats en producció que en la nova màquina. Ara s’ha de copiar les configuracions de les aplicacions que tenim en marxa. La idea és copiar tot /etc i tot /var. Tot i que això s’ha de fer molt en compte i s’ha de depurar molt, per poder saber sempre si l’hem liat en algún moment. Ja que per exemple, no cal copiar tots els directoris de logs tot i que si estem en una LAN i no són molts megues tampoc passa res si ho copiem. El més crític, és no sobre-escriure fitxers com /etc/fstab que poden variar segons la arquitectura de les màquines. En el meu cas no calia tenir en compte gran cosa més, però penseu que hi ha aplicacions que tenen fitxers de configuració en llocs poc habituals i això també s’hauria de copiar. A més és vital que no oblideu que no només s’han de copiar els fitxers, sinó també els seus atributs, o sigui, permisos i propietaris.

Una bona idea per copiar el directori /etc és crear un fitxer amb la llista de fitxers i/o directoris que no volem copiar, en el meu cas: (exclude_list.txt)

/etc/fstab
/etc/modprobe.d
/etc/modutils

Després amb la següent comanda sincronitzem els fitxers i els seus permisos del servidor de producció al nou servidor:

rsync -cavz --delete --exclude-from=exclude_list.txt root@ip_publica:/etc/ /etc/

La resta de configuracions es poden copiar amb el mateix procés.

glsof – Arxius usats pels processos

Reading time: 1 – 2 minutes

Molts ja coneixereu lsof, bàsicament aquesta eina fa una cosa tan senzilla i potent a la vegada com dir-nos quins fitxers estan sent usats en cada moment per un procés que esta corrent en el sistema. Això és realment útil per moltes situacions, per exemple, quan volem desmontar una unitat del sistema i no hi ha manera de fer-ho perquè algún procés té obert algún fitxer d’aquella unitat, doncs amb aquesta eina podriem saber quin procés és i prendre les mesures oportunes.

Doncs bé, només volia comentar que avui casuament he descobert el glsof que simplement és un entorn gràfic basat en GTK per usar la comanda lsof. Això en entorns d’escriptori ens simplifica moltíssim la feina d’aprenentatge dels molts paràmetres que suporta lsof.

glsof.png
Scroll to Top