Doncs com sempre, però la gràcia del tema esta en que després si feu un file per saber quin tipus de fitxer és veureu que s’interpreta la info del MBR i ens informa de les característiques de les particions del disc, realment curiós i útil:
Reading time: < 1 minute
Des de fa un temps estic força interessat en temes de cloud computing i virtualització com aneu nontant per la temàtica dels artícles que vaig penjant. Doncs avui llegint els feeds d'un dels blogs on estic sindicat he trobat aquest video que malgrat ser en anglès crec que descriu de forma molt planera i amb uns dibuixos molt divertits aquestes tecnologies:
Amb el pfqueue podreu gestionar les cues del Postfix v1 i v2, a més de l’exim. Jo en realitat només l’he provat per la v2 de postfix. L’eina malgrat no ser molt ràpida és realment còmode i potent. En poques paraules facilita molt la feina de gestió de les cues. No és senzill jugar amb els IDs dels correus que tenim amb les múltiples cues de postfix. Posar-los en hold, reencuar-los, fer-los flush, eliminar-los, etc. Gràcies a aquesta interficie els veurem amb una llista poden fins hi tot fer clic sobre de cadascún per veure en detall la informació de contexte dels mateixos i el contingut. Després a través de les tecles d’accés ràpid a les accions podrem fer el mateix que si usessim la comanda postsuper i algunes coses més.
Aquesta eina l’he trobat disponible a Gentoo i a Ubuntu 8.04.1 però no a Ubuntu 6.06. Per altre banda, és realment senzill compilar-la i instal·lar-la en una 6.06 així doncs si realment teniu un postfix en aquesta distro ús recomano molt l’eina.
Tot llegint documentació sobre temes de postfix que com sempre ja sabeu que hi estic molt posat he trobat una empresa que es dedica a vendre serveis de relay dels nostres dominis via processos autenticats. És a dir, podem usar el nostre servidor domèstic amb una simple ADSL amb IP dinàmica i a través d’ASMTP podem enviar correus a través d’una IP lliure d’RBLs, registre PTR i altres problemes similars. Per tant, els nostres correus sortiran a la xarxa de forma totalment legítima i ben protegits a través d’aquest enllaç. El millor són els preus del servei que són més que raonables. Per exemple, per moltes PIMES i sistemes domèstics el cost mensual no superaria els 2€-3€.
No us confongueu, els serveis de l’empresa són de relay és a dir, no fan de mail-backup per tant els correus entrants no els guardaran ells i els re-enviaran cap al vostre SMTP sinó alrevés; el que vosaltres envieu usarà com a smart-host el servidor d’aquesta empresa. A més d’aquest servei també fan còpies de seguretat de tot el que s’envia perquè es pugui consultar a posteriori i es comprova que no s’enviin correus duplicats. A més quan vosaltres no estigueu dintre de l’oficina o de casa podreu enviar correus directament contra l’ASMTP com si del vostre servidor de correu es tractés. Tot el correu que s’envia passarà també per un anti-virus per assegurar que no envieu virus sense voler als vostres destinataris, això és realment una descàrrega de feina molt gran pels servidors de la vostre empresa ja que sovint és el que més carrega els servidors de correu.
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:
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.
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!
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-viauser@ip_host localhost:0
El 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:
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.
Després de les ventoleres que esta fent aquests dies a casa i de que un dels SAIs degut a les pujades i baixades de tensió acabes més penjat que un fuet, el servidor ESXi s’ha quedat grogui i no arrencava. O sigui, que com sempre les coses simples i automàtiques acaben donant un error incomprensible sobre el que només es podia fer una recerca per internet per solucionar-lo. L’error: PANIC: Error while reading file: -3, state.tgz
Gràcies als fòrums d’VMWare vaig trobar un thread que ho explicava de forma clara: la solució. En poques paraules i resumint tornem a arrencar el sistema però amb el CD d’instal·lació d’ESXi i li diem que volem reparar el sistema. Després si som persones precabudes tindrem un backup de la configuració del VMWare Infraestructure que a través de la consola d’administració podrem recuperar. Però si com és el meu cas no teniu còpia de seguretat la cosa té un segon problema. Recuperar les màquines que tenim al VMFS que segons ens deia al procés de recuperació no ha estat borrat i per tant conté les màquines virtuals que tenim montades.
Doncs bé, en aquest cas als fòrums d’VMWare vaig trobar una solució aproximada però que pel cas hem va permetre intuir la solució, el que preten explicar la solució és com borrar una màquina virtual després de reparar el sistema. Doncs bé, un cop som dins la consola d’administració d’VMWare Infraestructure que ja no té les nostres màquines virtuals perquè acabem de reparar el sistema el que cal fer ara és anar a la pestanya ‘Configuration’, després dins la secció ‘Harware’ on posa ‘Storage’. Ara a mà dreta veurem el ‘datastore1’ punxem amb el ratolí amb el botó dret i al menú contextual apretem ‘Browse Datastore…’.
Aquí ja hauriem de veure el llistat de directoris que contenen les nostres màquines virtuals, un cop dintre del directori de la màquina que volem recuperar localitzem el fitxer amb extenció ‘.vmx’ , botó dret del ratolí sobre el ftixer i seleccionem l’opció ‘Add to inventory’. Ara ja haurieu de veure la màquina dintre de la pestanya ‘Virtual Machines’ del VMWare Infraestructure. La resta de configuracions que havieu fet dins del VMWare infraestructure s’han perdut. O sigui, que les heu de tornar a fer. Per exemple, en quin ordre s’engeguen les màquines, recursos reservats per les màquines i tota la resta d’ajustaments. Però bé això comparat amb perdre totes les màquines no és res. Oi?
He de reconeixer que malgrat la petada que va fer tot plegat estic molt content amb la simplicitat que ha tingut a l’hora de solucionar-se. M’esperava haver de patir molt més. Cada dia estic més convençut de la gran feina que fa la gent d’VMWare, llàstima que sigui tot tan privatiu i tancat.
Duplicity és un aplicatiu basat en python que de moment no disposa de frontend gràfic, sinó com les coses bones de la vida s’usa des de CLI. Esta orientat a les còpies de seguretat i la seva principal potència resideix en recolzar-se amb rdiffdir/rdiff/rsync per fer còpies de seguretat diferencies/incrementals. Això sembla que no sigui cap tret diferencial si no fos perquè suporta una bona colla de sistemes on enmagatzemar les còpies:
ssh/scp
local file access
rsync
ftp
HSI
WebDAV
Amazon S3
De moment ja he pogut comprovar que tan via Amazon S3 com via FTP, funciona la mar de bé. Això com podeu verure ja té més història, ja que fer un sistema de còpies diferencies i/o incrementals contra un FTP o contra S3, no és trivial. A més esta fet seguint tots els estàndards, és eficient en la gestió d’ampada de banda i suporta xifrat per clau pública i clau privada.
A continuació adjunto un petit cookbook dels paràmetres que jo més uso:
Fer un backup contra un FTP de tot el sistema, el backup es farà incremental sempre que la còpia incremental més vella no tingui més de 7 dies llavors es farà una còpia ‘full’. S’indica que els fitxers que es pujaran a l’FTP tenen una mida de 10Mb. No es copiaran els directoris /dev, /proc, /tmp, /mnt, /media
Per restaurar les còpies de seguretat, cal pensar que sovint el que es vol és recuperar algún fitxer o directori i no pas tota la còpia. Així doncs aquí es tindran en compte aquests detalls.
Com podeu comprovar l’ús de l’eina és ben senzill i fàcil de col·locar dins d’un crontab, però realment si ús calen combinacions més complexes cal que doneu un bon cop d’ull al man duplicity.
UPDATE (2015/08/17) How to install duplicity on Ubuntu 12.04
