oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: administrator

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

Reading time: 2 – 3 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.

L’abans i el després dels servidors de la feina

Reading time: 1 – 2 minutes

Ahir varem estar el Manu i jo posant una mica d’ordre als servidors de la feina, de fet, el que havia de començar com una feina d’1h va acabar convertint-se en unes 4h de posar en solfa i ordre tots els servidors i d’altres dispositus de xarxa de la feina. El bonic d’aquests casos és el resultat final que sempre reconforta, és d’aquelles feines agraïdes. Sobretot si és per tu i no per un client desagraït.

L’abans:

abans.png

i el després:

despres.png

El dia que m’hi posi amb tot el que tinc per casa no acabaré mai. Jo diria que no ho faig ni en un cap de setmana sencer.

Tip: canviar editor per defecte en Ubuntu

Reading time: < 1 minute 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.

Ubuntu LiveCD sense CDROM i amb mode persistent

Reading time: 4 – 6 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.

Backup configuració servidor RADIUS de Windows (2k i 2k3)

Reading time: 1 – 2 minutes

Avui he estat molta estona treballant amb el IAS de Windows, o com li diu la resta del món amb el servidor Radius de Windows. Doncs la gran deliveració de l’Albert ha estat: això quan peti si no ho tinc documentat les passarem negres per tornar-ho a configurar tot. Doncs per això sempre hi ha ens backups i com sempre acostuma a passar per les coses interessants s’ha de fer des de línia de comandes, així doncs aquí teniu la gràcia de tot:

# Fer còpia de seguretat del IAS (backup)
netsh aaaa show config c:\IAS.txt

# Restaurar còpia de seguretat del IAS (restore) netsh exec c:\IAS.txt

Això ho he trobat en el document: Windows 2000: Internet Authentication Service (IAS) and RADIUS on a més hi trobareu molta i molt bona informació conceptual de com funciona el IAS.

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: 3 – 4 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

Fent un tar sense els directoris .svn

Reading time: < 1 minute

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).

SSH tricks: control usuaris i col·lisions en la fingerprint

Reading time: 2 – 3 minutes

Un parell de tricks per l’SSH un pel servidor (sshd) i l’altre pel client (ssh).

Si volem deixar accedir només a alguns usuaris al nostre sistema via SSH s’ha de posar al fitxer /etc/ssh/sshd_config la comanda AllowUsers. Aquest eginy l’he extret de Restrict SSH per user.

Un exemple:

AllowUsers root oysteivi otheradmin

L’altre enginy és molt útil quan programem scripts que usen per exemple: scp, rsync o d’altre similars. A vegades per molt que usem un sistema d’autenticació per clau pública amb ssh això no és suficient perquè hi pot haver un conflicte den la fingerprint que tenim guardada (o no) del servidor on anem a connectar. Llavors se’ns pregunta si volem guardar aquesta fingerprint sinó la tenim guardada o si assumim que hi ha conflicte entre la fingerprint guardada i la que ens esta enviant el sevidor. Per més detalls sobre el problema podeu consultar aquest article de securityfocus SSH Host Key Protection. A més segur que aquest exemple ajudarà a refrescar la memòria sobre el que em refereixo.

 $ ssh ssh-server.example.com
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes

Per tal de controlar el comportament d’aquest event ho podem fer amb el paràmetre StrictHostKeyChecking=[yes|no|ask], això ho podem posar a /etc/ssh/ssh_config o bé a la línia de comandes a través del flag -o.

Exemple forçant la comprovació:

  $ ssh -o 'StrictHostKeyChecking=yes' ssh-server.example.com
  No RSA host key is known for localhost and you have requested strict checking.
  Host key verification failed.

Exemple preguntant la comprovació:

  $ ssh -o stricthostkeychecking=ask ssh-server.example.com
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes