Category: Networking and Internet

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

Servidor FTP darrera un NAT (pure-ftpd)

Reading time: 2 – 2 minutes

Sovint quan montem un servidor FTP darrera d’un Firewall que fa DNAT per publicar els ports FTP (20, 21, tcp i udp) a internet ens deixa de funcionar l’FTP en mode Passive On. Llavors hem de fer allò tan molest i depenent del client tan difícil; o sigui, fer un Passive Off perquè la transmissió d’arxius, llistats de fitxers, etc. funcioni bé. Doncs avui cansat d’això en un servidor pure-ftpd que tinc montat a la feina i he posat solució ja que sinó tenia als tècnics molt limitats quan es trobaven a casa dels clients.

La cosa ha estat ben senzilla, només he hagut de llençar el pure-ftpd amb el paràmetre -p i especificar un rang de ports per on es faran les connexions passives. Jo he decidit que anessin entre el port 40000 i el 50000. Així doncs, el paràmetre ha quedat així: -p 40000:50000. Després al firewall he redirigit tot aquest rang de ports contra la IP interna del servidor i llestos (fent un DNAT). Ara ja funcionen perfectament els FTP passius.

Si tot això d’FTP passiu i no passiu, ús sona a xinès he trobat una petita web molt bona que explica la diferència entre un sistema i l’altre: Active FTP vs. Passive FTP, a Definitive Explanation (local).

QGRUBEditor – Editor gràfic del fitxer menu.lst del Grub

Reading time: < 1 minute

Sempre va bé tenir una referència d’aquestes aprop per quan hem de modificar el fitxer i no volem anar consultant el man. La veritat és que no l’he provat encara i potser ni el provi mai perquè ja tinc els menu.lst molt per la mà. Però no sé sap mai quan pot fer falta algo així.

qgrub-editor.png

Si voleu més informació del aplicatiu: QGRUBEditor web site.

Web per generar semacode’s

Reading time: 1 – 2 minutes

Com que sempre m’han dit que val més una imatge que mil paraules per explicar algo:

what-is-semacode.png

Per si encara no ha quedat prou clar, adjunto la definició de la pròpia web semacode.org:

Semacode works by embedding a URL (web address) into a sort of two-dimensional barcode which looks like a dense crossword puzzle (pictured) — called the tag. The SDK software contains the capability to detect and decode the tag very rapidly with the camera on your phone. It extracts the URL and sends you to that address using the phone’s built-in browser.

Doncs bé he trobat una web que ens permet generar els nostres pròpis semacodes: semafox. Aquí teniu un semacode amb la URL del meu blog:

semacode.png

De fet, encara no he vist cap aplicació real enlloc de la tecnologia però la veritat és que la veig molt senzilla i potent, ja veurem si aconsegueix triumfar.

Fent un tar sense els directoris .svn

Reading time: 5 – 8 minutes

Després de molts anys d’experiències en Unix/Linux encara de vegades m’ofusco en tonteries com la que comento al títol, què trist,eh!? bé doncs perquè no ús passi com a mi que he trigat quasi 10min per inspirar-me i fer algo tan senzill com això:

tar cvfz fitxer.tar.gz $(find directori/ -type f | grep -v .svn)

Suposo que és obvi entendre que volem fer una còpia en un fitxer comprimit del codi que hi ha a directori sense els fitxers i directoris .svn del control de versions (subversion).

Postfix: Verifiquem recipients des del mailgateway

Reading time: 5 – 8 minutes

El maig de l’any passat vaig publicar un petit manual de com configurar un Postfix per fer de ‘mailgateway’ d’un altre servidor MTA. Doncs bé, avui hi he afegit una funcionalitat que inicialmen creia impossible. Es tracta de comprobar si el correu que estem rebent des de fora i que va dirigit a un usuari local existeix en el servidor destí on enviarem el correu. Fins ara tots els correus amb destí @dominilocal.tld els agafabem i ja era el MTA intern qui el refusava. El problema d’això és que genera un email de resposta del MTA intern cap al host de ‘relay’ (mailgateway) i aquest correu després s’intenta entregar al remitent orignal. Amb el conseqüènt problema de creixement de la cua de missatges sobretot si el remitent és un email problemàtic.

diagrama-xarxa.png

Doncs bé buscant per la documentació de Postfix he trobat que a través del fitxer /etc/postfix/main.cf podia usar la comanda smtpd_recipient_restrictions per afegir una nova restricció que fos verificar el recipient (reject_unverified_recipient). Però això no és el problema. Sinó que el problema esta en després d’això anar a verificar aquest recipient a l’altre host. Això es fa amb la comanda address_verify_local_transport on li indiquem quin és el host que realment té la base de dades d’usuaris.

smtpd_recipient_restrictions =
...
        reject_unverified_recipient
...
address_verify_local_transport=ip_interna_host_MTA

Obviament el MTA intern ha d’estar configurat de forma que no accepti correus per comptes que no existeixin. Per tant, no pot estar configurat amb un cul de sac, o com diuen en castellà amb una direcció de correu ‘recojetodo’. Així doncs, quan un MTA d’internet envii un correu al servidor de relay (mailgateway) aquest obrirà una connexió contra l’MTA intern i verificarà que existeix la compte de correu a través de la comanda RCPT TO, això ens permet no haver d’activar la temuda comanda VERIFY BY, per tal de saber si existeix o no una compte al servidor intern i per tant, refusar en cas de que sigui necessari aquest correu que es preten entregar.

SD flash reader del Dell X300 funciona en linux

Reading time: 25 – 41 minutes

Finalment després de més de dos anys amb el Dell X300 sense poder usar la unitat SD que incorpora avui he pogut configurar-la. De fet, el suport encara és molt ‘beta’ i no fa massa temps que s’ha fet el mòdul pel kernel però com a mínim per llegir el contingut de les fotos que he fet amb la càmara ja va bé.

Vaig a intentar explicar una mica la stiuació de tot plegat, així doncs anem per passos. Com sap la gent que té un Dell X300 al fer un lspci veiem això:

...
02:03.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
02:03.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
...

Deduim doncs que aquest bridge cardbus (PCMCIA) és doncs el que realment té el lector de targetes flash SD. Així doncs, primer de tot necessitem tenir compilat el suport PCMCIA al Kernel i després ens podem descarregar el mòdul del kernel. Jo ús recomano que baixeu directametn del SVN perquè així el tindreu patchejat pels útlims kernels, jo ara mateix uso el 2.6.21.

Per baixar la última versió del controlador Ricoh, després compilar-lo i instal·lar-lo:

svn co https://sdricohcs.svn.sourceforge.net/svnroot/sdricohcs sdricohcs
cd sdricohcs
cd sdricoh_cs
make
make install

Ara ja tenim instal·lat al directori de mòduls del kernel el nou controlador: sdricoh_cs. Així doncs, ja el podem carregar juntament amb el mòdul mmc_block. Una llista completa de mòduls relacionats perquè ús funcioni:

Module                  Size  Used by
mmc_block               6408  2
sdricoh_cs              7180  0
mmc_core               20244  2 mmc_block,sdricoh_cs
pcmcia                 28204  2 sdricoh_cs
yenta_socket           21260  4
rsrc_nonstatic          9856  1 yenta_socket
pcmcia_core            29712  4 ide_cs,pcmcia,yenta_socket,rsrc_nonstatic

Ara si insertem una targeta SD particionada i formatejada dintre del directori /dev tenim aquests nous dispositius:

/dev/mmcblk0
/dev/mmcblk0p1

El segon es refereix a la partició, així doncs el podem usar per montar directament la targeta SD:

# mkdir /mnt/sd
# mount /dev/mmcblk0p1 /mnt/sd

Si no especifiqueu cap paràmetre al carregar el mòdul del kernel sdricoh_cs la targeta es montarà només com a lectura degut a que es considera perillós montar-la com a escriptura, degut a l’estat no estable del controlador. Si voleu montar-la com a escriptura també poseu el paràmetre write=1, jo no ho he provat perquè em conformo en poder llegir encara que sigui un pel lentament el contingut de la targeta, si voleu informació més detallada de tot plegat ús recomano llegir el fitxer README que incorpora el codi font del controlador.

Per més informació:

pfSense: amb una Intel Quad PRO/1000 cal una versió >1.0.1

Reading time: 2 – 4 minutes

Avui he patit una d’aquelles feines d’administrador tan tontes i que et fan perdre tan de temps. Havia d’instal·lar una Intel PRO/1000 GT QUAD PORT en un servidor Compaq Proliant DL320 per fer de firewall amb un pfSense i el coi de servidor no tenia CDROM. El problema de connectar-li un CD extern és que detectava la tapa oberta i no s’engegava un cop superat aquest tema, com que la BIOS és vella i propietaria, no permetia arrencar amb un CD IDE sinó que volia que uses la controladora que porta instal·lada especialmet per aixo sinó no podia arrencara des de CD per instal·lar el pfSense. Al final he tret un dels disc durs del servidor, encara sort que són IDE, l’he posat a un ordinador nomal i l’hi he instal·lat el pfSense al fer el canvi de PC tot perfecte. Només un però, resulta que la versió 1.0.1 del pfSense no reconeix de forma automàtica la versió GT de la targeta de 4 ports d’intel. Així doncs, he hagut de baixar-me la versió beta de la 1.2 del pfSense que ha carregat el driver em del FreeBSD que reconeix a la perfecció la targeta de 4 ports.

intelquad.jpg

Realment una odissea de dia per fer una cosa ben senzilla. Ho comento perquè no perdeu el temps com jo intentant fer meravelles amb la versió 1.0.1 aneu directament a la 1.2 que malgrat estar en beta funciona molt bé. De moment diria que prou bé com per tenir-la en producció. El firewall finalment m’ha quedat amb 6 targetes de xarxa 2 a 100Mbps i 4 a 1000Mpbs. Dels 4 ports a 1000 n’hi ha 3 que hauran de treballar a plè rendiment quan hagi fet les proves d’estrés ja comentaré què tal. De totes formes, imagino que els resultats seràn excel·lents perquè FreeBSD realment és molt bo fent gestió de tràfic i més amb drivers tan madurs com el em per controlar el hardware d’intel.

Per cert, una altre odissea va ser trobar la targeta d’intel. Ja que malgrat fa molt de temps n’havia comprat una. De fet, el model que havia tocat era el MT i la que he montat avui és la GT, de fet ni el fabricant s’aclareix en decidir quina és la diferència real entre elles. Només anotar per si algún dia se’m torna a oblidar que les targetes les he trobat ben aprop de casa a un proveïdor de Vilafranca del Penedès que es diu ELPO. Bàsicament es dediquen al món dels SAIs però també fan de majoristes d’informàtica en general. El curiós és que en cap més distribuidor oficial de networking d’intel a l’estat la tenien ni me la volien portar.

Scroll to Top