ACL Policy Daemon for Postfix
Fins ara l’únic policy daemon que usava per postfix és el policyd v1 que esta fet amb C i per temes de rendiment em donava grans funcionalitats, rapidesa i escalavilitat sobretot pel seu backend en MySQL. Però avui m’he vist obligat a instalar el ACL Policy Daemon que esta programat amb Twisted+Python i que a través de la seva capacitat de configurar les regles d’accés al Postfix vai ACLs m’he pogut montar una funcionlitat un pel rebuscada que em calia per un client.
El problema és que aquest client necessita:
- Rebre correu pels seus dominis
- Permetre relay previa autenticació dels seus roadwarriors
Doncs bé això planteja un problema degut a una funcionalitat contradictoria. Si configurem el Postfix perquè rebi correu local, podem protegir aquest correu contre UBE tan com volguem i més però si l’origen especificat en la transacció SMTP indica que el remitent és una compte de correu del mateix domini que el destí (sovint la mateixa compte de correu), aquest correu s’acceptarà com a legítim i no es demanarà autenticació perquè l’MTA on s’està enviant el correu és el destí del mateix. Gràcies a això el correu serà acceptat al MTA i només quedarà a expenses del anti-spam i regles UBE anturar-lo, el qual malgrat via SPF i d’altres similars intentarà aturar aquest correu això no sempre serà possible i menys si els intents d’injecció són de l’ordre de desenes de milers al dia. Ens trobavem que alunes desenes passaben els filtres igualment.
Així doncs, gràcies a aquest policy daemon he pogut programar un regla que diu algo així:
- si IP d’enviant no és local
- si origen del correu és un domini local
- si destí del correu és un destí local
- si l’usuari no s’ha autenticat
- NO es pot enviar aquest correu!
Els clients que estan fora de l’empresa (roadwarriors) sempre que envien un correu ho fan via ASMTP així doncs, si volen enviar un correu a alguna compte del mateix domini que la seva ho faran de forma autenticada. Per altre banda, si un client de correu intern a l’emrpesa intenta enviar un correu ho farà amb una IP local de l’empresa i aquest filtre no el bloquejarà.
Com podeu veure el problema és una mica enrabassat. Per altre banda, si voleu fer un cop d’ull al fitxer de configuració policy.conf (un dels fitxers de configuració del aplicyd) que he creat és de l’estil d’aquest:
acl wl client_address NET_IP/MASK
action nice_users DUNNO
access wl nice_users
acl remitent sender @example.com
acl desti recipient @example.com
acl aut sasl_method (PLAIN|LOGIN)
action rej REJECT Auth required
access remitent desti !aut rej
Malgrat jo he usat el apolicyd per temes molt concrets s’ha de dir que el seu codi font és molt entenedor i simple de modificar, a més de suportar moltíssimes funcionalitats de serie que permeten ajustar les nostres regles de filtrat moltíssim. Realment m’ha sorprès de forma molt positiva no m’esperava que estigués tan ben pensat.
Update VMWare ESXi 3.5 Update2 -> Update3 build 123629
Vaig boig des de fa almenys 2 mesos intentant saber perquè el VMWare ESXi queda freeze en un servidor que al final només hi tenia el pfSense i una Ubuntu 8.04.1 virtualitzats. Tan és així que al final, per saber d’on venia el problema he montat un altre servidor ESXi i he posat una màquina virtual amb pfSense a un i un Ubuntu 8.04.1 a l’altre. Doncs bé, finalment s’ha concretat el problema que venia de l’Ubuntu com que ja sabia de què pecava el tema m’he posat a buscar als forums d’VMWare i resulta que la versió Update 2 del ESXi no suporta Ubuntu 8.04.1, també és mala sort la cosa.
Doncs bé, finalment he vist que a finals de Novembre havia sortit l’Update 3 del ESXi i després de suar una mica intentant baixar-me l’actualització, no ho he aconseguit. Així doncs, m’he baixat una ISO sencera i he començat una instal·lació del ESXi sobre del sistema que ja tenia corrent amb Update 2. Encomptes de dir-li que instal·les des de zero li he dit que fes una reparació (repair) de l’instal·lació actual perquè no toques el ‘local storage’ (datastore1) que per defecte esta al mateix disc. Un cop re-instal·lat he aplicat el que explico a l’article:VMWare ESXi: PANIC: Error while reading file: -3, state.tgz
O sigui, que he tornat a importar totes les màquines que tenia i com que continuo sense haver fet un backup doncs no he pogut restaurar la configuració del VMWare ESXi. Però la qüestió és que he aconseguit actualitzar. Digueu-me radical però quan he vist que el manual de com fer actualitzacions al ESX ocupava 100 pàgines he pensat que això també funcionaria i així ha estat. Si algún dia m’animo a mirar el manual ja explicaré la forma oficial de fer-ho, o bé, si algú ho sap que avisi.
Ara només cal creuar els dits perquè això aguanti més d’una setmana que és el que acostumava a durar el sistema sense quedar-se fregit, o com diuen els aglosaxons: freeze.
vmware: Convertint una màquina virtual (.vmx) a format estàndard (.ovf)
Mai havia tingut la necessitat de fer la converció a OVF d’una màquina virtual, aquest és el format estàndard de les màquines virtuals diria que per tots els sistemes de virtualització malgrat n’hi ha molts que encara no el suporten. Doncs en el meu cas el que he fet és exportar unes màquines virtuals d’un VMWare Server a un VMWare ESXi convertint-les a OVF, l’ideal hagués estat migrar-les directament ja que les utilitats de VMWare OVF Tools ho soporten però al no tenir les màquines en la mateixa xarxa no volia que la migració durés dies i dies i més dies.
El procés: he parat les màquines virtuals, he modificat la configuració de les mateixes per treure el dispositiu de ‘CDROM’ que tenia mapejat contra una .ISO que em donava problemes en el procés i després he fet una cosa tan simple com:
ovftool /path_to_vms/vm_dir/vm_file.vmx /tmp/vm.ovfEl projecte Open Source que implementa OVF el teniu a SourceForge. Malgrat això jo ho he migrat amb les OVF Tools d’VMWare.
Després em pregunten perquè no m’agrada el Windows…
Aquesta tarda he patit un expedient X’s, de fet, tots estem acostumats a ser víctimes d’aquests fenòmens quan treballem amb ordinadors i si és amb Win encara més. La qüestió ha estat amb una placa IB830H. Aquesta placa porta embeded una Intel PRO/100 VE una targeta més que típica i tòpica en sistemes professionals. A més podria afegir que és una de les targetes que més m’agradan. Per si fos poc el seu suport en sistemes de Microsoft estan soportadíssimes, com no podia ser d’altre forma.
Doncs la qüestió és que després d’instal·lar els drivers que havia descarregat des de la web d’intel la targeta es detectava perfectament i si esnifava el canal fins hi tot veia a passar paquets però en cap cas la targeta rebia cap paquet.
Després de fer mil proves i canviar els drivers un munt de vegades, la cosa no ha canviat gens i quan ja estava apunt de llençar la toballola he provat una cosa tan estúpida i simple com:
- Entrar a la BIOS
- Desactivar la targeta de xarxa
- Arrancar el Windows
- Després apaguem
- Tornem a entrar a la BIOS
- Activar la targeta de xarxa
- Tornem a entrar al Windows
- … i ja va tot sense tocar res!!!
Increible, eh!? doncs això és el bonic que té el Windows. He de dir que com sempre passa durant tot aquest procés incert he arrencat amb una CD de Gentoo i la targeta de xarxa sense fer totes aquestes tonteries funcionava perfectament. O sigui, que rebia i enviava paquets sense problemes. Realment això és una altre prova de com el Windows és contraproduent en molts i molts sentits!
Fast trick: accedir a un servidor VNC via SSH
Quasi sense voler acabo de descobrir una funcionalitat molt interessant del vncviewer que en aquest cas estava usant per accedir remotament a un vino-server, el servidor que usa una Ubuntu per exportar la pantalla a través de la xarxa. Doncs bé, resulta que no podia accedir pel port 5900/tcp que és el normal. Doncs bé es veu que també s’hi pot accedir de forma directe per SSH sense fer cap esforç:
vncviewer -via user@ip_host localhost:0El user i la ip_host són per accedir via SSH a la màquina que esta exportant la pantalla.
Per altre banda, si no teniu el vino-server activat i voleu accedir a la consola podeu activar-lo a través de les goconf tools:
# parar el vino server
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled false
# llençar el vino server
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
# fixar un password d'accés:
gconftool-2 -s -t string /desktop/gnome/remote_access/vnc_password qwerty
ciopfs: case-insensitive ext3 via fuse
De tots són conegudes les aplicacions que usen FUSE per obtenir sistemes de fitxers del més inversemblants a través e l’espai d’usuari amb un kernel Linux. Doncs bé, en aquest cas el que hem calia era aconseguir que una partició ext3 en un dels seus directoris fos case-insensitive. O sigui, que no fes ús d’una de les funcions més coneguda del món Linux/Unix, la distinció en majúscules i minúscules en els noms d’arxius i directoris.
Doncs bé, la solució ha estat ciopfs aquesta aplicació que funciona igual que tantes altres aplicacions FUSE, ens permet re-montar un directori en un nou punt però sense sensibilitat en les maj-min. Per cert, com que esta en la seva versió 0.2 no m’ha estat precisament trivial compilar-lo amb una Debian Etch. He hagut de compilar a mà el FUSE i instalal·lar els paquets de ‘dev’ dels requeriments indicats a la documentació del aplicatiu. Espero que mica en mica això millori.