Sovint quan montem un servidor FTP darrera d’un Firewall que fa DNAT per publicar els ports FTP (20, 21, tcp i udp) a internet ens deixa de funcionar l’FTP en mode Passive On. Llavors hem de fer allò tan molest i depenent del client tan difícil; o sigui, fer un Passive Off perquè la transmissió d’arxius, llistats de fitxers, etc. funcioni bé. Doncs avui cansat d’això en un servidor pure-ftpd que tinc montat a la feina i he posat solució ja que sinó tenia als tècnics molt limitats quan es trobaven a casa dels clients.
La cosa ha estat ben senzilla, només he hagut de llençar el pure-ftpd amb el paràmetre -p i especificar un rang de ports per on es faran les connexions passives. Jo he decidit que anessin entre el port 40000 i el 50000. Així doncs, el paràmetre ha quedat així: -p 40000:50000. Després al firewall he redirigit tot aquest rang de ports contra la IP interna del servidor i llestos (fent un DNAT). Ara ja funcionen perfectament els FTP passius.
Sempre va bé tenir una referència d’aquestes aprop per quan hem de modificar el fitxer i no volem anar consultant el man. La veritat és que no l’he provat encara i potser ni el provi mai perquè ja tinc els menu.lst molt per la mà. Però no sé sap mai quan pot fer falta algo així.
Com que sempre m’han dit que val més una imatge que mil paraules per explicar algo:
Per si encara no ha quedat prou clar, adjunto la definició de la pròpia web semacode.org:
Semacode works by embedding a URL (web address) into a sort of two-dimensional barcode which looks like a dense crossword puzzle (pictured) called the tag. The SDK software contains the capability to detect and decode the tag very rapidly with the camera on your phone. It extracts the URL and sends you to that address using the phone’s built-in browser.
Doncs bé he trobat una web que ens permet generar els nostres pròpis semacodes: semafox. Aquí teniu un semacode amb la URL del meu blog:
De fet, encara no he vist cap aplicació real enlloc de la tecnologia però la veritat és que la veig molt senzilla i potent, ja veurem si aconsegueix triumfar.
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ò:
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).
El maig de l’any passat vaig publicar un petit manual de com configurar un Postfix per fer de ‘mailgateway’ d’un altre servidor MTA. Doncs bé, avui hi he afegit una funcionalitat que inicialmen creia impossible. Es tracta de comprobar si el correu que estem rebent des de fora i que va dirigit a un usuari local existeix en el servidor destí on enviarem el correu. Fins ara tots els correus amb destí @dominilocal.tld els agafabem i ja era el MTA intern qui el refusava. El problema d’això és que genera un email de resposta del MTA intern cap al host de ‘relay’ (mailgateway) i aquest correu després s’intenta entregar al remitent orignal. Amb el conseqüènt problema de creixement de la cua de missatges sobretot si el remitent és un email problemàtic.
Doncs bé buscant per la documentació de Postfix he trobat que a través del fitxer /etc/postfix/main.cf podia usar la comanda smtpd_recipient_restrictions per afegir una nova restricció que fos verificar el recipient (reject_unverified_recipient). Però això no és el problema. Sinó que el problema esta en després d’això anar a verificar aquest recipient a l’altre host. Això es fa amb la comanda address_verify_local_transport on li indiquem quin és el host que realment té la base de dades d’usuaris.
Obviament el MTA intern ha d’estar configurat de forma que no accepti correus per comptes que no existeixin. Per tant, no pot estar configurat amb un cul de sac, o com diuen en castellà amb una direcció de correu ‘recojetodo’. Així doncs, quan un MTA d’internet envii un correu al servidor de relay (mailgateway) aquest obrirà una connexió contra l’MTA intern i verificarà que existeix la compte de correu a través de la comanda RCPT TO, això ens permet no haver d’activar la temuda comanda VERIFY BY, per tal de saber si existeix o no una compte al servidor intern i per tant, refusar en cas de que sigui necessari aquest correu que es preten entregar.
Finalment després de més de dos anys amb el Dell X300 sense poder usar la unitat SD que incorpora avui he pogut configurar-la. De fet, el suport encara és molt ‘beta’ i no fa massa temps que s’ha fet el mòdul pel kernel però com a mínim per llegir el contingut de les fotos que he fet amb la càmara ja va bé.
Vaig a intentar explicar una mica la stiuació de tot plegat, així doncs anem per passos. Com sap la gent que té un Dell X300 al fer un lspci veiem això:
Deduim doncs que aquest bridge cardbus (PCMCIA) és doncs el que realment té el lector de targetes flash SD. Així doncs, primer de tot necessitem tenir compilat el suport PCMCIA al Kernel i després ens podem descarregar el mòdul del kernel. Jo ús recomano que baixeu directametn del SVN perquè així el tindreu patchejat pels útlims kernels, jo ara mateix uso el 2.6.21.
Per baixar la última versió del controlador Ricoh, després compilar-lo i instal·lar-lo:
Ara ja tenim instal·lat al directori de mòduls del kernel el nou controlador: sdricoh_cs. Així doncs, ja el podem carregar juntament amb el mòdul mmc_block. Una llista completa de mòduls relacionats perquè ús funcioni:
Ara si insertem una targeta SD particionada i formatejada dintre del directori /dev tenim aquests nous dispositius:
/dev/mmcblk0/dev/mmcblk0p1
El segon es refereix a la partició, així doncs el podem usar per montar directament la targeta SD:
# mkdir/mnt/sd# mount/dev/mmcblk0p1/mnt/sd
Si no especifiqueu cap paràmetre al carregar el mòdul del kernel sdricoh_cs la targeta es montarà només com a lectura degut a que es considera perillós montar-la com a escriptura, degut a l’estat no estable del controlador. Si voleu montar-la com a escriptura també poseu el paràmetre write=1, jo no ho he provat perquè em conformo en poder llegir encara que sigui un pel lentament el contingut de la targeta, si voleu informació més detallada de tot plegat ús recomano llegir el fitxer README que incorpora el codi font del controlador.
Avui he patit una d’aquelles feines d’administrador tan tontes i que et fan perdre tan de temps. Havia d’instal·lar una Intel PRO/1000 GT QUAD PORT en un servidor Compaq Proliant DL320 per fer de firewall amb un pfSense i el coi de servidor no tenia CDROM. El problema de connectar-li un CD extern és que detectava la tapa oberta i no s’engegava un cop superat aquest tema, com que la BIOS és vella i propietaria, no permetia arrencar amb un CD IDE sinó que volia que uses la controladora que porta instal·lada especialmet per aixo sinó no podia arrencara des de CD per instal·lar el pfSense. Al final he tret un dels disc durs del servidor, encara sort que són IDE, l’he posat a un ordinador nomal i l’hi he instal·lat el pfSense al fer el canvi de PC tot perfecte. Només un però, resulta que la versió 1.0.1 del pfSense no reconeix de forma automàtica la versió GT de la targeta de 4 ports d’intel. Així doncs, he hagut de baixar-me la versió beta de la 1.2 del pfSense que ha carregat el driver em del FreeBSD que reconeix a la perfecció la targeta de 4 ports.
Realment una odissea de dia per fer una cosa ben senzilla. Ho comento perquè no perdeu el temps com jo intentant fer meravelles amb la versió 1.0.1 aneu directament a la 1.2 que malgrat estar en beta funciona molt bé. De moment diria que prou bé com per tenir-la en producció. El firewall finalment m’ha quedat amb 6 targetes de xarxa 2 a 100Mbps i 4 a 1000Mpbs. Dels 4 ports a 1000 n’hi ha 3 que hauran de treballar a plè rendiment quan hagi fet les proves d’estrés ja comentaré què tal. De totes formes, imagino que els resultats seràn excel·lents perquè FreeBSD realment és molt bo fent gestió de tràfic i més amb drivers tan madurs com el em per controlar el hardware d’intel.
Per cert, una altre odissea va ser trobar la targeta d’intel. Ja que malgrat fa molt de temps n’havia comprat una. De fet, el model que havia tocat era el MT i la que he montat avui és la GT, de fet ni el fabricant s’aclareix en decidir quina és la diferència real entre elles. Només anotar per si algún dia se’m torna a oblidar que les targetes les he trobat ben aprop de casa a un proveïdor de Vilafranca del Penedès que es diu ELPO. Bàsicament es dediquen al món dels SAIs però també fan de majoristes d’informàtica en general. El curiós és que en cap més distribuidor oficial de networking d’intel a l’estat la tenien ni me la volien portar.
Si pel motiu que sigui, teniu un pfSense que amb el servei de Dynamic DNS i la vostre interficie WAN no té la IP pública amb la que voleu actualitzar el servei d’IP dinàmica que useu aquí trobareu la solució. Això pot passar per diversos motius:
Hi ha més d’una WAN
La WAN té una IP privada que enllaça amb el router
Accés a internet a través d’una VPN
etc
Doncs bé, concretament en el meu cas tinc dues sortides WAN i per si fos poc la que té IP dinàmica no té la IP asignada pel proveidor sinó una IP privada. Així doncs, buscant pels foros de pfSense he trobat aquesta solució al problema.
Es tracta de modificar el fitxer /etc/inc/dyndns.class. Primer de tot afegim aquest nou mètode (funció) a la classe:
/* Private function for getting real IP *//* Author: Tri Tu */function_checkip(){log_error("DynDns: Running _checkip() for real WAN IP");$ch=curl_init();curl_setopt($ch,CURLOPT_URL,'http://checkip.dyndns.com');curl_setopt($ch,CURLOPT_HEADER,0);curl_setopt($ch,CURLOPT_RETURNTRANSFER,TRUE);$data=curl_exec($ch);curl_close($ch);list($part1,$part2) =split(': ',$data,2);list($ip,$junk) =split('<',$part2);return$ip;}
Després dins del mateix fitxer busquem tots els llocs on apareix:
$wan_ip=get_current_wan_address();
i ho canviem per:
$wan_ip=$this->_checkip();
Si ús fixeu, el tema és tan senzill com dir-li a la classe que per saber quina és la seva IP de WAN ha de cridar la funció anterior, aquesta funció connecta a la típica web que retorna la IP que tenim i a partir d’aquí capturem aquesta IP i l’assignem a la variable que s’usar per saber si ha canviat la nostre IP.
És curiós però fa unes setmanes li donava voltes al cap si valia o no la pena seguir tenint el Beagle consumint recursos a la meva màquina. No perquè no sigui un bon indexador, sinó perquè no tinc la costum d’usar-lo i no el faig servir mai. Així doncs una de dues o l’acabo treient o m’acostumo a usar-lo. La qüestió és que tot navegant fa uns dies vaig trobar el Beagle++ aquest projecte encara en una fase força inicial afegeix capacitats semàntiques al Beagle de sempre. Què carai vol dir això doncs, que per exemple si busquem Spain no només ens donarà resultats de documents relacionats amb la paraula sinó amb paraules derivades també, per exemple, València, Madrid, etc.
Com que el millor exemple sempre és veure-ho funcionar:
Ja fa molt de temps que estic enganxat a MobuzzTV però mai tinc temps de mirar els videocastings que em descarrego. Per altre banda, també he descobert el programa diaria de InternautasTV. Doncs bé, la cosa se’m comença a acumular així doncs he decidit mirar-m’ho des de la BlackBerry mentre vaig en tren, però els videos descarregats no són visibles directament i s’han de convertir. Així doncs aprofitem la potència del mencoder del qual ja en parlava en Pau fa uns dies.
