Author: Oriol Rius

duplicity: còpies de seguretat senzilles i potents des de la CLI

2008/11/22 3 Comments

Reading time: 38 – 64 minutes

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

PASSPHRASE=clausimetrica duplicity incremental --full-if-older-than 7D -v4 --volsize 10 --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/mnt --exclude=/media / ftp://user:pass@hostname

- Veure un llistat dels fitxers sobre els que hem fet còpia:

PASSPHRASE=clausimetrica duplicity list-current-files ftp://user:pass@hostname

- Consultar quines còpies hi ha disponibles al repositori:

PASSPHRASE=clausimetrica duplicity collection-status  ftp://user:pass@hostname

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.

- Recuperem tota la còpia de seguretat sencera:

PASSPHRASE=clausimetrica duplicity ftp://user:pass@hostname /tmp/restore

- Recuperem un fitxer o directori:

PASSPHRASE=clausimetrica duplicity --file-to-restore nom_fitxer_o_directori_a_recuperar ftp://user:pass@hostname /tmp/restore

- Recuperem un fitxer o directori concrets de fa 3 dies enrera:

PASSPHRASE=clausimetrica duplicity -t 3D --file-to-restore nom_fitxer_o_directori_a_recuperar ftp://user:pass@hostname /tmp/restore

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

apt-get install -y python-paramiko python-gobject-2 python-dev build-essential python-pip python-software-properties
add-apt-repository ppa:duplicity-team
apt-get update
apt-get install -y duplicity

UPDATE (2016/08/02) Backup full Ubuntu Linux

PASSPHRASE=your_password duplicity incremental --full-if-older-than 7D -v4 --volsize 10 --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / rsync://the_user:the_password@host_server::/path/

Migració de dreamhost a ovh

2008/11/21 2 Comments

Reading time: 1 – 2 minutes

Només informar que si en les properes hores teniu problemes d’accés a la pàgina és perquè estic migrant de dreamhost a ovh. Com ja vaig comentar temps enrera estic molt desconentent del rendiment de CPU i disk que m’està donant el servei de dreamhost i aprofitantq ue acabo el contracte a final d’any he canviat de proveidor encara no tinc migrats gran part dels serveis però el més important que és el blog en principi ja esta migrat ara espero no patir problemes col·laterals de la migració i si tot va bé en les properes 72 hores continuaré migrant serveis.

Només com a detall comentar que per 19.99€+IVA tinc una màquina pròpia que administro jo amb el S.O. que vull i malgrat això hem suposi més feina a priori que no pas els serveis de dreamhost estic convensut que hi acabaré guanyant ja que almenys tot el que passi dependrà de mi, cosa que ja és dir molt a venir de dreamhost.

Control de la velocitats dels ventiladors en Linux (fancontrol)

2008/11/21 No Comments

Reading time: 3 – 4 minutes

Mai havia tingut aquesta necessitat, de fet, coneixa lm-sensors, sensors, fancontrol i pwmconfig que són les eines que he usat per solucionar aquest tema. Però realment no m’havia posat a rascar en aquest tema. Però la veritat és que la cosa no ha estat tan complicada i sembla molt potent. Abans de seguir volia fer notar que el que jo he provat era amb:

Placa base: Intel D945GCLF2
SO: Ubuntu 8.10

Doncs bé, el primer és executar pwmconfig el qual es permetrar detectar quins sistemes de monitorització té el nostres sistema. Quan l’executeu veureu que és un assistent que ens va fent preguntes molt simples. La finalitat del mateix és dir-nos quins mòduls del kernel s’han de configurar i crear el fitxer /etc/fancontrol aquest fitxer és necessari per poder llençar després el fancontrol. Bàsicament per parametritzar el comportament dels ventiladors amb aquests paràmetres:

INTERVAL cada quan s’han de consultar els estats dels sensors
FCTEMPS quins sensors de temperatura té el sistema
FCFANS quins ventiladors té el sistema
MINTEMP Temperatura mínima del sensor X
MAXTEMP Temperatura màxima del sensor X
MINSTART Temperatura mínima a la que ha d’estar el sensor X perquè s’inicii el ventilador
MINSTOP Temperatura mínima a la que ha d’estar el sensor X perquè es pari el ventilador
MINPWM valor PWM mínim que assignem al ventilador
MAXPWM valor PWM màxim que assignem al ventilador

Ara toca explicar què és això del PWM, doncs bé és la senyal que s’usa per controlar la velocitat del ventilador. Com podem saber els nostres valors PWM a quantes revolucions per minut del venitlador corresponen (RPM), doncs al executar el pwmconfig si ens hi fixem es crea una taula de valors on es veu la correspondència entre PWM i RPM. Així doncs, si per exemple volem que a la mínima temperatura d’un sensor el nostre ventilador estigui parat podem assignar el valor PWM que correspon a 0 RPMs. És molt important que quan el pwmconfig fa les proves pertinents per saber la relació PWM-RPM ens fixem que el ventilador va canviant de velocitat fins a parar-se. Si axiò no passa vol dir que alguna cosa esta fallant i que no es poden controlar els ventiladors. Perquè tot això sigui així només cal llençar el procés fancontrol.

Si el que volem és saber a quines temperatures estan els nostres sensors, el que s’ha de fer és executar la comanda: sensors. Aquesta ens informarà de les temperatures de tots els sensors que ha trobat i la velocitat dels ventiladors. A cotinuació ús poso un screenshot perquè veieu com queda:

sensors

Si llenceu el sensors amb un watch, o sigui, watch sensors podreu veure en temps real com van canviant les velocitats dels ventiladors i les temperatures dels sensors. En el meu cas tot això és més quesuficient pel que vull. Però si el que voleu són eines gràfiques per monitoritzar totes aquestes dades hi ha un munt d’applets, desklets, tray icons i similars tan per kde com per gnome que ús permetran consultar aquestes dades.

podcast 1×13: desafio networking [la solución]

2008/11/20 No Comments

Reading time: < 1 minute A pesar de que la solución se alcanzó y aplico durante los meses de agosto y septiembre, hasta hoy no he podido grabar la solución en este podcast. Espero que haya sabido explicarla bien y que quede claro como se ha hecho para solucionar el problema, sinó preguntad.

El meu primer package de pfSense ‘dd_adv’

2008/10/21 No Comments

Reading time: 4 – 6 minutes

Enllaç directe a la documentació:

HOWTO: advanced dynamic DNS package for pfSense

En aquest article intentaré descriure quins són els passos que he hagut de seguir per fer un package pel pfSense. En aquest cas el package que he fet és la extenció d’una funció que ja té el pfSense però que no es comportava com jo necessito. Concretament estic parlant del servei de ‘dynamic DNS’. S’ha de reconeixer que el suport és per molts serveis públics, i de pagament, per publicar un nemónic per una IP dinàmica. Cosa que el fa molt bo. Però hi ha diversos comportaments del suport que té pfSense per aquestes funcions que no s’ajustaben a les meves necessitats. Tal com esta programat aquest suport el pfSense el que fa és agafar la IP pública de la interficie WAN i cada cop que aquesta canvia es fa l’actualització de la IP pública al servei de DNS remot.

El meu problema bé de dos llocs, per un costat la IP no la tinc assignada a la interficie amb internet, sinó a una altre interficie. Per altre banda, la interficie que té internet no té la IP pública assignada directament a ella sinó que la té un router que a través d’un procés de NAT li dona connectivitat a internet. Així doncs, el problema esta per un costat en saber sobre quina interficie accedirem a internet i per altre banda, quina és la IP pública a través de la qual s’accedeix a la xarxa. De retruc tenim encara un altre problema degut a que la IP pública no esta assignada a l’interficie del pfSense, suposo que és obvi que el problema és que no sabem quan aquesta canvia. Per tant, no sabem quan ho hem d’actualitzar al servei de DNS dinàmica.

La solució que he adoptat és crear un nou servei que a través d’un servei de pooling el que fa és anar preguntant de forma periódica a internet quina és la IP pública que té la nostre interficie. A més s’ha de poder seleccionar quina és aquesta interficie sobre la qual volem verificar quina és la IP pública. Ja que hem de forçar que el tràfic que es genera per descobrir la IP pública surti per la interficie que realment té connexió a internet. Aquesta casuística per extranya que sembli és molt habitual, perquè a una oficina o similar ens podem trobar amb la necessitat de tenir dues línies que van a internet, una que estarà a l’interficie WAN del pfSense i una altre que va per una altre interficie. Sovint a la interficie WAN hi tenim la sortida principal a internet i a una altre interficie la sortida de backup. Un exemple habitual en aquests dies que corren és usar una ADSL a la WAN i una altre sortida a través d’un router 3G de Vodafone o similar per una altre interficie.

Un cop ha quedat clar quin és l’objectiu del package de pfSense, aquest és l’aspecte del que volem aconseguir:

pfsense dynamic DNS advanced settings

La descripció dels passos per fer la configuració el teniu al wiki així si he de fer millores retocs, traduccions i similars crec que és un lloc més apropiat per posar-ho que no pas directament a un article al blog, perquè aquest acabarà sent massa llarg i difícil de referenciar, modificar i mantenir.

Vull destacar la poca documentació i exemples que té el pfSense sobretot pels nous desenvolupadors, ja que moltes vegades m’he hagut de posar a rascar codi o a posar-me a buscar en com ho havien fet altres programadors de ‘packages’ per saber com resoldre els meus problemes. Potser però el més difícil és la part de debugging del paquet ja que moltes vegades et troves amb problemes col·laterals de la programació del paquet que no saps com arreglar i que et fan perdre molt de temps. Per exemple, no sé per quin extrany problema en el procés de depuració deixava a tot el pfSense sense configuració i havia de reinciar i restaruar divereses vegades la configuració de tot el firewall per poder acabar trobant d’on venia el problema. El procés es fa tan llarg i pesat que acabes desesperante.

Zivios: Introducció

2008/10/15 2 Comments

Reading time: 4 – 6 minutes

El mes de Juny vaig parlar-vos de la meva idea de com montar un sistea SSO, concretament era al podcast 1×10. Doncs Zivios malgrat no és literalment una implementació d’aquest sistema si que ens nutreix d’un munt d’eines per tenir un sistema que serveixi de base per aquella idea. De fet, serveix per moltes altres coses i potser la idea que porten els seus creadors és més semblant a crear un sistema de directori (tipus AD) que no pas només un sistema d’SSO. Però sigui com sigui, després d’experimentar unes quantes hores amb el Zivios crec que val la pena que ús en faci cinc cèntims.

Algunes de les funcions de Zivios són:

Identity managament
Single sign-on
User, group and computer provisioning
Remote management of services
Core Infrastructure Services (NTP,DNS, CA, etc)

El projecte esta encara molt i molt verd, tot just s’ha publicat la versió 0.5.1 i les he passat ‘canutes’ per fer coses ben simples o per entendre com usar l’eina degut a la seva poca documentació, tan és així, que fins hi tot vaig haver d’entrar al canal d’IRC que tenen com a suport a parlar amb alguns dels desenvolupadors perquè em donessin un cop de mà per entendre algunes coses. De fet, hi ha diverses coses que pretenc integrar amb Zivios que encara no hem funcionen. Però malgrat totes aquestes notes de poca maduresa del projecte, el tema promet moltíssim i l’enfoc que li han donat a les coses m’encanta.

Per començar, les eleccions de les aplicacions Open Source que han escollit ja m’han semblat un gran què: MySQL, OpenLDAP, Heimdal Kerberos, PHP5, Memcached, Python+Twisted, XMLRPC, OpenSSL i moltes altres eines que formen part del meu dia a dia. Així doncs, no suposa un gran problema anar a mirar les entranyes del Zivios per entendre com funcionen algunes de les seves parts. Totes aquestes eines es combinen en un model client-servidor per tal de poder administrar de forma centralitzada diverses funcions de les estacions de treball, servidors, serveis i d’altres.

Cal destacar també que els serveis que s’administren des de Zivios es poden ampliar mitjançant el desenvolupament de plug-ins. Per exemple, ja hi ha fets plug-ins per samba, asterisk i algún servei més. En el meu cas on estic posant més enfasi és en aconseguir integrar els servidors amb LDAP i Kerberos, així doncs puc tenir una base de dades d’usuaris, grups i autenticació pels accessos als servidors. A més a través de les ACL que té Zivios puc controlar qui pot i qui no entrar als servidors. Per altre banda, també he aconseguit connectar OpenFiler a Zivios, el problema que tinc ara és que no me’n ensurto amb l’autenticació però suposo que és qüestió de temps. Quan aconsegueixi combinar tot això i si els resultats són els esperats espero poder-ho montar com a plug-in.

Per posar un exemple pràctic i perquè es vegi la potència de la idea, podem des del panell de control web de l’eina donar d’alta una localització, dins una oficina, després els seus usuaris, grups d’usuaris, serveis, servidors i estacions de treball. Després podem sobre tots aquests agents definir per exemple, les extencions d’asterisk, els accessos als recursos compartits per samba, el seu sistema d’autenticació centralitzat, configuracions DNS, NTP i moltes d’altres configuracions tot de forma centralitzada còmode i senzilla d’aministrar. A més podem establir usuaris amb certs permisos d’administrador per delegar-los tasques que es podran gestionar des de l’interficie web.

Sota el meu punt de vista el projecte és molt ambiciós i veig difícil que pugui arribar a madurar prou com per poder fer tot el que s’apunta des d’un inici. Però sent pragmàtics només amb el que ja es dibuixa ara mateix i per gestionar les parts més comuns entre diversos sistemes ja em conformo. És a dir, com a evolució natural del sistema NIS i servei de SSO, crec que ja és més que vàlid. Després si puc fer que s’integri amb software appliances que uso de forma habitual crec que puc arribar a tenir un gestor de la infraestructura de xarxa més que decent. Quan parlo de software appliances ara mateix tinc al cap sobretot OpenFiler i pfSense.

PowerTOP – aprofitem millor la bateria del portàtil

2008/10/08 1 Comment

Reading time: 5 – 8 minutes

Ha hagut de passar gairebé un any perquè comenci a treure-li partit al portàtil. No pas pel complicat que és sinó perquè no hi he dedicat temps per un motiu o per altre, doncs bé, en el meu afany d’anar mica en mica aprofitant tot el que m’ofereix el Dell XPS m1330 m’he posat a ajustar-lo una miqueta perquè la bateria em redeixi més. Sovint treballo endollat a casa o a la feina i per tant, no tinc la necessitat de tirar de cap de les dues bateries que tinc. Però últimament he agafat la costum de llegir feeds des del llit a primera hora i a escriure algún que altre post des del mateix lloc. Així doncs, en aquests casos i per tal d’agilitzar el tema tiro de bateria.

Una eina que he m’ha sorprès moltíssim a l’hora d’estudiar quines parts del portàtil consumien més i com fer que això no passi ha estat el PowerTOP, aquesta eina té una funcionalitat que realment m’ha encantat. A part de totes les informacions tècniques que ens dona per analitzar el consum a la part inferior de la pantalla ens mostra suggeriments de com podem millor el rendiment del nostre equip: canviar certes opcions del kernel, modificar registres de /proc, para algún dimoni que no és vital, desactivar dispositius com el bluetooth, wifi o ethernet si no els estem usant… etc. Però el millor és que en alguns casos no només ens informa del que hem de fer o podem fer, sinó que a més ens facilita el procés a través de tecles d’accés ràpid. Per exemple, et recomana que apaguis el bluetooth i si prems ‘B’ ho fa ell per tu.

Pel que fa a la resta d’informació presentada a la pantalla de l’eina podem trobar tres grans zones diferenciades de la pantalla, a la part superior hi ha els estats ‘C’, bàsicmaent C0 és l’estat en que la CPU esta executant alguna comanda i els altres estats són diferents nivells d’IDLE. Obviament quan més temps passem a l’estat C3 menys estem usant la CPU i menys consumim.

Sota tenim la quantitat de ‘wakeups’ que rep la CPU per segon, o sigui, la quantitat de vegades que algún procés força a la CPU executar alguna comanda. Obviament quan més baix sigui aquest número menys CPU consumirem, això esta en relació directe amb els estats ‘C’ comentats abans, és clar.

Per últim a la part inferior de la pantalla tenim un llistat dels 10 processos que més ‘wakeups’ generen, aquí podem veure quines parts del portàtil estan consumint més. En el meu cas el ‘firefox’, la targeta gràfica ‘nvidia’, les ‘X’ i la ‘wifi’. És important notar que quan parlem de processos no tenen perquè ser processos de sistema, sinó que poden ser interrupcions, parts del kernel, etc.

Una altre d’aquestes senzilles, potents i molt útils.

NOTA de l’Elri (2008/12/15): em comenta via correu que una bona opció per no despertar tan la CPU en un Dell XPS m1330 com el que tinc jo és afegir a la secció ‘Screen’ això:

Option         "OnDemandVBlankInterrupts" "True"

Habilitar l’SSH a un VMWare Server ESXi

2008/10/07 No Comments

Reading time: 1 – 2 minutes

Des d’ahir estic evaluant un HP ML110 G5 amb 2Gb de RAM com a servidor de màquines virtuals amb VMWare Server ESXi. El primer trick que m’he afanyat ha aconseguir és habilitar l’SSH del servidor ja que al no portar un sistema operatiu com a host, sinó que el propi VMWare Server ESXi ja el porta un linux incrustat esta tot molt restringit.

Els passos:

At the ESXi console, press alt+F1
Type: unsupported
Enter the root password
At the prompt type “vi /etc/inetd.conf”
Look for the line that starts with “#ssh”
Remove the “#” (press the “x” if the cursor is on the character)
Save “/etc/inetd.conf” by typing “:wq!” or “ZZ“
Restart the management service “/sbin/services.sh restart”

TCP bouncer amb failover

2008/10/03 No Comments

Reading time: 2 – 4 minutes

Al projecte GATv2 fa un parell de dies que hi he publicat un subprojecte que anomeno tcp-fwd. Es tracta d’un petit i simple aplicatiu programat amb Python i Twisted. La funcionalitat és molt senzilla es tracta d’un bouncer TCP que en cas de no poder connectar amb el primer destí on re-enviar el tràfic TCP ho prova amb el segon, sinó el tercer i així fins a tants servidors com s’hagin definit. Si no es pot acabar establint la connexió es desconnecta l’enllaç TCP cap al bouncer. O sigui, el comportament és transparent pel client original. Pels que no estigueu familiaritzats amb la funcionalitat d’un bouncer la intentaré explicar. Es tracta d’un socket TCP que escolta en un port i actua com un reverse proxy. O sigui, quan rep una connexió acte seguis s’obre una altre connexió cap al servidor i si aquesta es pot establir llavors connecta la primera connexió amb la segona.

L’inconvenient més gran que veig en aquesta idea és que la connexió que arriba al servidor final no té com a origien la IP del client, sinó la IP del servidor que fa de bouncer això fa que el fitxer de logs del servidor final no tingui la informació IP del client que realment s’ha connectat. Malgrat axiò hi ha escenaris en que aquesta eina és molt útil, ja que no sempre el més important són aquests logs sinó que el client acaba obtenint el servei que volia de forma trasparent i el sistema de failover que uso sempre segueix la mateixa seqüència de prova i error per cada socket que s’obre, així doncs, el sistema de failover és instantani i no perd ni una sola crida.

Una de les aplicacions per les que l’estic usant és per fer l’entrega de correu a un postfix. Es tracta d’un servidor de correu que només fa filtratge de correu i els correus que passen els filtres s’entreguen al servidor de correu real de l’empresa, doncs bé, per saber quin és el servidor de l’empresa uso el fitxer de configuració /etc/postfix/transport on s’indica segons el domini el servidor on entregar el correu. Però no he sabut veure com dir-li més d’un servidor de correu on fer l’entrega. Així doncs, el que faig és posar com a IP i port de transport una IP localhost i un port al atzar, llavors el postfix entrega el correu al bouncer situat en aquesta IP localhost i és el bouncer que intenta connectar aquest socket amb algún dels servidors de correu interns. Per tant, el tema és completament transparent pel postfix i els servidors que reben el correu tenen la mateixa IP origen que si ho haguessin rebut directament del postfix.

Suposo que la idea ha quedat ben definida, sinó ja sabeu que podeu fer-me les preguntes que calguin. El codi del projecte el teniu a: tcp-fwd.

ssldump depuració de tràfic xifrat

2008/10/02 No Comments

Reading time: 2 – 2 minutes

Tothom coneix el TCPdump i fins hi tot hi ha gent com jo que l’usem a diari, de fet, no fa massa temps vaig re-descobrir el TCPflow (ja l’havia descobert abans, però vaig cometre el gran error d’oblidar-lo). Doncs bé, el problema d’aquestes eines és que són molt útils per tràfic sense xifrar però quan es tracta de tràfic xifrat amb SSL/TLS com ara HTTPs o d’altres protocols que viatgen xifrats i volem saber perquè no funcionen hem de recorrer a eines com el ssldump.

SSLdump permet seguir el fluxe de les conexions TCP xifrades amb SSLv3/TLS. Obviament per aconseguir desxifrar el contingut de l’enllaç hem de facilitar-li els certificats corresponents a l’eina. Però no només ens permet depurar a nivell de dades que corren per TCP sinó que també ens dona informació del propi protocol de xifrat descrita de forma humana. O sigui, que podem saber si el problema de l’enllaç és produeix durant el procés de handshake, ChangeCipherSpec o dins del protocol.

El que jo feia fins ara per poder analitzar el contingut d’un protocol que viatge xifrat és ajudar-me de l’eina sslproxy. La qual feia de bouncer al servidor de protocol o al client, així doncs obtenia un tram de la conexió que no anava xifrat i a través del tcpflow o el tcpdump podia obtenir el tràfic en clar. La tècnica és enginyosa i útil però ferragosa en comparació al ssldump.