Passant d’una Ubuntu real a una de Virtual (VMWare)
Aquesta setmana he clonat un sistema montat en Ubuntu, d’una màquina real a una màquina virtal corrent dins d’un VMWare Server. La veritat pensava tenir més problemes, però finalment la cosa ha estatm és senzilla del que pensava. Intentearé explicar-vos els passos que he seguit, espero no deixar-me cap detall important ja que ho faré de memòria.
-
- Servidor nou
- Creem una màquina virtual amb la VMWare Server Console.
- Instal·lem una Ubuntu 6.06 LTS (la mateixa versió qu hi ha a la màquina que volem clonar)
- A diferencia de la original aquesta la montem amb LVM, això va ser un capritxu meu no una necessitat
- Un cop finalitzada la instal·lació estàndard i fetes les actualitzacions, instal·lem el servidor d’ssh
- Servidor original
- Creem un fitxer de text amb aquest contingut, l’anomenaré exclude.txt:
/proc
/sys
/dev
/mnt
/cdrom
/tmp
/etc/fstab
/etc/mtab
/boot
/etc/iftab
-
- Ara ve l’hora de la veritat i usant rsync començo a clonar la màquina:
rsync -cavz --exclude-from=exclude.txt /* root@IP_NOVA_MAQUINA:/
- Apaguem o desconnectem cable de xarxa
- Server nou
- Reiniciem la màquina, jo ho vaig fer a sac, o sigui… apretant botó reset de la màquina virtual. Digueu-me radical però vaig pensar que era el millor en aquest cas.
bar: linies de progrés per bash
Una eina senzilla i útil, a més programada totalment en shell script que encara té més merit. Servei per fer coses tan vistoses com un línia de progrés mentre fem un tar, cp, etc.
Una imatge val més que mil paraules…
És fàcil i vistosa, oi que si? en l’exemple es veu com descomprimeixo la pròpia eixa amb una barra de progrés generada per ella mateixa.
Doneu un cop d’ull a la web, a mi m’ha agradat molt l’eina i l’he usat per fer un CD d’instal·lació d’una eina de la feina. Per si la web deixés d’existir, que això ja passa amb aquest tipus d’eines deixo una còpia del programa a l’article: bar-1.4.tar.bz2.
inotify, inotify-tools i incron: un gran descobriment per substituir dnotify
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.
Binding SSH des de PHP
Mai m’hagués imaginat que arribaria a poder fer coses tan interessants i de forma tan neta des del PHP, però pel que he pogut comprobar és força senzill. El que necessitava era poder fer SCPs des del PHP. Doncs bé, hi ha un mòdul de PHP que permet fer no noés això sinó fins hi tot SSH i autenticacions tan via paraula de pass com via clau pública-privada. Realment útil.
Si com jo esteu interessant en aquesta idea, la pròpia web de PHP en té un manual de com programar amb PHP usant funcions d’SSH. Però si voleu començar pel principi i a més voleu alguns exemples molt senzills una bona recomanció és el howto (local) d’en Kevin van Zonneveld realment senzill i útil. Jo ho he montat en una Ubuntu Server Dapper 6.06 LTS, ho comento perquè quan ell diu que instal·leu el paquet openssl-dev, no existeix en el sistema que he usat. Cal que instal·le libssl-dev en el seu lloc i tot funcionarà bé. També comentar que només m’ha funcionat amb la llibreria libssh-0.14 les versions més noves donen erros de compilació al mòdul SSH2 de PHP.
pfSense deixava de re-enviar paquets misteriosament…
Intentaré explicar-vos un ‘expedient X’ d’aquells que ja tinc resolts, però que no tinc una explicació al 100% del comportament que tenia el pfSense davant del problema. La conclusió és que el pfSense descartava paquets per tenir massa connexions concurrents, però al ser connexions UDP costava identificar-les. El problema és que de forma completament misteriosa el pfSense descartava els primers X’s paquets cap a qualsevol IP. Aquesta número indeterminat, podia ser des de 2, 3 o 4 paquets fins a 100 o 200. O sigui, que hi havia moments on donava la sensació que s’havia perdut l’enllaç. Com a pecualiaritat de la configuració del firewall (pfSense) comentar que la targeta WAN estava en mode bridge amb la targeta de servidors d’internet. O sigui, que la DMZ rep el tràfic de les IPs públiques que allà hi han filtrat a través d’un bridge d’aquestes dues targetes de xarxa que he comentat.
Exemple, de la pèrdua de paquets que comentava. Ping realitzat a una IP d’internet (la de oriol.joor.net) des del propi firewall. Realment això d’operation not permitted em va tenir molt i molt desoncertat.
# ping 80.35.31.228
PING 80.35.31.228 (80.35.31.228): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
64 bytes from 80.35.31.228: icmp_seq=9 ttl=57 time=117.668 ms
64 bytes from 80.35.31.228: icmp_seq=10 ttl=57 time=86.728 ms
Des de qualsevol de les altres potes del firewall es patia el mateix efecte, fins hi tot si es feien els pings cap a la LAN. La solució vaig trigar quasi 48h en trobar-la, era una bogeria. Ja que al final per localitzar el problema varem aïllar el firewall d’internet i el fenòmen va deixar de passar.O sigui, ja mai passava això d’operation not permitted per molt tràfic que injectessim al firewall, no passava. Així doncs, gràcies a una molt bona idea del Manu varem tancar tot el tràfic des d’internet i varem anar obrint serveis cap a la DMZ, un per un. Fins que vaig descobrir que el servei d’NTP (123/upd) era el que probocava aquest extrany efecte al pfSense.
Després de diverses proves la conclusió, és que hi havia masses connexions concurrents contra el servei que comento. Així doncs, actualment el que he fet és filtrar el número de connexions que permeto contra aquest port:
<div class="imatge" style="text-align: center;"></div>
Aquestes opcions les podeu trobar editant la Rule, concretament a la sección on posa Advaced Options. Com podeu veure podeu deixar ben limitat quines connexions i quines no deixeu passar cap a un servei.
Potser el més important que he aprés d’aquesta història és no montar mai un firewall que no acompleixi la regla d’or: by default block all. O sigui, tanqueu sempre tot i ja anireu obrint a mesura que faci falta. Però a vegades per voler ser una mica més transigent ho fem alrevés i al final això s’acaba pagant, com en aquest cas. A mi ja no em tornarà a passar, espero que a vosaltres tampoc.
L’abans i el després dels servidors de la feina
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:
i el després:
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.