outime ha tenido el detallazo de grabar la instalación gráfica de Etch y colgar el vídeo en Youtube, para regocijo general y placer de los debianitas que, como yo, quizá no podamos verlo (gracias al dist-upgrade).
Pues hala, a disfrutarlo :D
27 febrero 2007
26 febrero 2007
Configurando el lector de tarjetas MMC
Ya va para dos años que tengo el portátil, y aún tenía algo pendiente de hacer: configurar el multilector de tarjetas. Lo intenté una vez con Sarge, pero no lo conseguí y tampoco le dí demasiada importancia. Tampoco es que lo necesite, así que lo dejé aparcado. Pero ayer (tarde de domingo y sin nada interesante que probar) me dí el "de hoy no pasa". Ahora sé (antes no había investigado mucho el tema) que cuando probé con Sarge no tenía ninguna posibilidad de conseguirlo: el módulo no se incluyó en el kernel hasta la versión 2.6.17.
Lo primero es identificar el dispositivo. Para ello tiramos de lspci:
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
06:06.4 Generic system peripheral [0805]: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
Mi multilector es un Texas Instruments de un modelo que, por lo que he visto en Google, es bastante habitual encontrar. Como vemos, el kernel reconoce dos dispositivos: es lector de MMC y el de SD. Del segundo no voy a hablar, ya que para ello es necesario el módulo tifm, que no viene incluído en los kernels oficiales. Quizá algún día escriba sobre el tema.
El módulo necesario, el sdhci, está disponible a partir de la versión 2.6.17 del kernel Linux, así que un Sarge con kernel oficial de Debian no puede manejarlo (Sarge tiene un 2.6.8, si no recuerdo mal), pero en Etch ya contamos con un 2.6.18 en los repositorios, así que no hay problema. La alternativa es compilar el kernel uno mismo, recordando incluir los módulos necesarios.
Fijémonos en el identificador de dispositivo. En mi caso es 06:06.3, pero en el vuestro puede ser cualquier otro. Ejecutamos (como root) lspci -xxx | grep -A 5 06:06.3 (recordad sustituir el identificador de dispositivo por el vuestro):
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
00: 4c 10 33 80 06 01 10 02 00 00 80 01 08 80 80 00
10: 00 40 10 b0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 81 30
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 07 04
40: 00 00 00 00 01 00 02 7e 00 00 00 00 00 00 00 00
Ese es el resultado que obtengo yo. Fijaos en la línea que empieza por "40:" (la última), en el valor de casilla que hay bajo el "0a". En mi caso es 00, pero, por lo que he visto por ahí, puede tener un valor de 40 o de 60 también. En cualquier caso, tenemos que cambiar el segundo 0 por un 2 (si es 40, debe quedar como 42, si 60, 62; en mi caso debe quedar como 02). Si alguien quiere saber por qué, que lo investigue y luego me lo cuente, porque no tengo ni idea. El caso es que funciona. Para conseguirlo ejecutamos el siguiente comando:
setpci -s 06:06.3 4c.b=02
De nuevo recordaros sustituir el 06:06.3 por el identificador del dispositivo en vuestro caso particular, y el 02 por lo que corresponda. Si volvemos a ejecutar el lspci -xxx | grep -A 5 06:06.3 veremos que ahora devuelve lo correcto:
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
00: 4c 10 33 80 06 01 10 02 00 00 80 01 08 80 80 00
10: 00 40 10 b0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 81 30
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 07 04
40: 00 00 00 00 01 00 02 7e 00 00 00 00 02 00 00 00
Bien, pues ya está todo listo: cargamos los módulos necesarios con modprobe (hay que cargar los módulos sg, sd_mod, mmc_core, mmc_block y sdhci), y veremos algo así:
sdhci: Secure Digital Host Controller Interface driver, 0.12
sdhci: Copyright(c) Pierre Ossman
sdhci: SDHCI controller found at 0000:06:06.4 [104c:8034] (rev 0)
ACPI: PCI Interrupt 0000:06:06.4[A] -> GSI 22 (level, low) -> IRQ 177
mmc0: SDHCI at 0xb0109000 irq 177 DMA
mmc1: SDHCI at 0xb0108c00 irq 177 DMA
mmc2: SDHCI at 0xb0108800 irq 177 DMA
Ya podemos insertar la tarjeta MMC. El led parpadea y (si teneis bien configurado el automount) Konqueror nos abre una instancia con el contenido de la tarjeta. Podeis también acceder a su contenido a través del directorio /media/MMC. Me encanta :D
Una cosa más. Debemos asegurarnos de que en arranques sucesivos todo esté como lo hemos dejado. Para ello editamos el archivo /etc/modules para incluir los módulos que hemos cargado, de forma que se vuelvan a cargar en cada arranque del sistema. Por último, editamos el /etc/rc.local y añadimos, antes de exit 0, el comando setpci -s 06:06.3 4c.b=02. Y listo. Por fin puedo usar el lector de MMC que tengo de adorno desde hace casi dos años :D
Una última recomendación: una tarjeta MMC es un dispositivo de almacenamiento como cualquier otro. Cuando hagais un intercambio de datos con el dispositivo recordad hacer un sync y desmontarlo antes de sacarla del lector, si no quereis perder datos. Que aproveche.
Lo primero es identificar el dispositivo. Para ello tiramos de lspci:
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
06:06.4 Generic system peripheral [0805]: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
Mi multilector es un Texas Instruments de un modelo que, por lo que he visto en Google, es bastante habitual encontrar. Como vemos, el kernel reconoce dos dispositivos: es lector de MMC y el de SD. Del segundo no voy a hablar, ya que para ello es necesario el módulo tifm, que no viene incluído en los kernels oficiales. Quizá algún día escriba sobre el tema.
El módulo necesario, el sdhci, está disponible a partir de la versión 2.6.17 del kernel Linux, así que un Sarge con kernel oficial de Debian no puede manejarlo (Sarge tiene un 2.6.8, si no recuerdo mal), pero en Etch ya contamos con un 2.6.18 en los repositorios, así que no hay problema. La alternativa es compilar el kernel uno mismo, recordando incluir los módulos necesarios.
Fijémonos en el identificador de dispositivo. En mi caso es 06:06.3, pero en el vuestro puede ser cualquier otro. Ejecutamos (como root) lspci -xxx | grep -A 5 06:06.3 (recordad sustituir el identificador de dispositivo por el vuestro):
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
00: 4c 10 33 80 06 01 10 02 00 00 80 01 08 80 80 00
10: 00 40 10 b0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 81 30
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 07 04
40: 00 00 00 00 01 00 02 7e 00 00 00 00 00 00 00 00
Ese es el resultado que obtengo yo. Fijaos en la línea que empieza por "40:" (la última), en el valor de casilla que hay bajo el "0a". En mi caso es 00, pero, por lo que he visto por ahí, puede tener un valor de 40 o de 60 también. En cualquier caso, tenemos que cambiar el segundo 0 por un 2 (si es 40, debe quedar como 42, si 60, 62; en mi caso debe quedar como 02). Si alguien quiere saber por qué, que lo investigue y luego me lo cuente, porque no tengo ni idea. El caso es que funciona. Para conseguirlo ejecutamos el siguiente comando:
setpci -s 06:06.3 4c.b=02
De nuevo recordaros sustituir el 06:06.3 por el identificador del dispositivo en vuestro caso particular, y el 02 por lo que corresponda. Si volvemos a ejecutar el lspci -xxx | grep -A 5 06:06.3 veremos que ahora devuelve lo correcto:
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
00: 4c 10 33 80 06 01 10 02 00 00 80 01 08 80 80 00
10: 00 40 10 b0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 81 30
30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 07 04
40: 00 00 00 00 01 00 02 7e 00 00 00 00 02 00 00 00
Bien, pues ya está todo listo: cargamos los módulos necesarios con modprobe (hay que cargar los módulos sg, sd_mod, mmc_core, mmc_block y sdhci), y veremos algo así:
sdhci: Secure Digital Host Controller Interface driver, 0.12
sdhci: Copyright(c) Pierre Ossman
sdhci: SDHCI controller found at 0000:06:06.4 [104c:8034] (rev 0)
ACPI: PCI Interrupt 0000:06:06.4[A] -> GSI 22 (level, low) -> IRQ 177
mmc0: SDHCI at 0xb0109000 irq 177 DMA
mmc1: SDHCI at 0xb0108c00 irq 177 DMA
mmc2: SDHCI at 0xb0108800 irq 177 DMA
Ya podemos insertar la tarjeta MMC. El led parpadea y (si teneis bien configurado el automount) Konqueror nos abre una instancia con el contenido de la tarjeta. Podeis también acceder a su contenido a través del directorio /media/MMC. Me encanta :D
Una cosa más. Debemos asegurarnos de que en arranques sucesivos todo esté como lo hemos dejado. Para ello editamos el archivo /etc/modules para incluir los módulos que hemos cargado, de forma que se vuelvan a cargar en cada arranque del sistema. Por último, editamos el /etc/rc.local y añadimos, antes de exit 0, el comando setpci -s 06:06.3 4c.b=02. Y listo. Por fin puedo usar el lector de MMC que tengo de adorno desde hace casi dos años :D
Una última recomendación: una tarjeta MMC es un dispositivo de almacenamiento como cualquier otro. Cuando hagais un intercambio de datos con el dispositivo recordad hacer un sync y desmontarlo antes de sacarla del lector, si no quereis perder datos. Que aproveche.
25 febrero 2007
Repositorios de Beryl para Etch
Aún no los había puesto, así que ahí van:
deb http://debian.beryl-project.org etch main
deb-src http://debian.beryl-project.org etch main
No olvideis importar la clave para la verificación de paquetes de apt:
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 3FF0DB166A7476EA
gpg --armor --export 3FF0DB166A7476EA | sudo apt-key add -
deb http://debian.beryl-project.org etch main
deb-src http://debian.beryl-project.org etch main
No olvideis importar la clave para la verificación de paquetes de apt:
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 3FF0DB166A7476EA
gpg --armor --export 3FF0DB166A7476EA | sudo apt-key add -
OpenSSH le enseña las bragas al mundo
Hace unas semanas empecé a subir a mi cuenta de Googlepages todos los tutoriales en PDF que tenia en el disco duro cuya licencia lo permitiera. Uno de ellos fue OpenSSH le enseña las bragas al mundo, un gran tuto que explica, de cabo a rabo, cómo funciona el protocolo SSH, las bases de la criptografía asimétrica, etc.
Ese tutorial ya no está colgado. A su autor, David, no le gusta cómo quedó y me ha pedido que lo elimine. Promete avisar cuando la versión revisada esté lista y pueda ser colgado de nuevo. Esperaremos :)
A cambio (y creo que ganamos con el cambio) me permite publicar el vídeo (335 Mb) de una charla con esa misma temática que dio en PoLinux. Es un vídeo de 78 minutos en el que, de una forma clara y amena, David nos explica todos los entresijos del protocolo SSH y su implementación por parte de OpenBSD, OpenSSH. Una joya imprescindible.
De paso en el FTP de PoLinux encontraremos, junto a ese vídeo, otros también muy interesantes. Desde luego los chicos de PoLinux se lo montan de lujo. Gracias David :)
Ese tutorial ya no está colgado. A su autor, David, no le gusta cómo quedó y me ha pedido que lo elimine. Promete avisar cuando la versión revisada esté lista y pueda ser colgado de nuevo. Esperaremos :)
A cambio (y creo que ganamos con el cambio) me permite publicar el vídeo (335 Mb) de una charla con esa misma temática que dio en PoLinux. Es un vídeo de 78 minutos en el que, de una forma clara y amena, David nos explica todos los entresijos del protocolo SSH y su implementación por parte de OpenBSD, OpenSSH. Una joya imprescindible.
De paso en el FTP de PoLinux encontraremos, junto a ese vídeo, otros también muy interesantes. Desde luego los chicos de PoLinux se lo montan de lujo. Gracias David :)
24 febrero 2007
Archivos de configuración de los kernels oficiales de Debian
A partir de ya (lo traigo calentito, oiga, el anuncio es de hace media hora) se pueden obtener en Debian Official Kernel Configuration files los archivos de configuración de los kernels que hay en los repositorios de Debian.
Normalmente estos archivos se distribuyen como parte de los paquetes linux-image, pero ahora ya se pueden obtener independientemente del binario del kernel. ¿Y para qué? Bueno, pues por si quereis compilar un kernel igual al oficial pero necesitais alguna opción que éste no trae, o por si quereis comprobar si uno de los kernels oficiales lleva activada una opción que os interesa antes de instalarlo, o por si quereiss consultar las opciones que tiene activadas un kernel oficial que ya está archivado...
¿Y cómo usarlo? Pues como cualquier otro .config. Se descarga, se descomprime, se copia en la raíz del código fuente del kernel como .config y se hace un make oldconfig.
Normalmente estos archivos se distribuyen como parte de los paquetes linux-image, pero ahora ya se pueden obtener independientemente del binario del kernel. ¿Y para qué? Bueno, pues por si quereis compilar un kernel igual al oficial pero necesitais alguna opción que éste no trae, o por si quereis comprobar si uno de los kernels oficiales lleva activada una opción que os interesa antes de instalarlo, o por si quereiss consultar las opciones que tiene activadas un kernel oficial que ya está archivado...
¿Y cómo usarlo? Pues como cualquier otro .config. Se descarga, se descomprime, se copia en la raíz del código fuente del kernel como .config y se hace un make oldconfig.
22 febrero 2007
Zenity: cuadros de diálogo en tus shell scripts
Todo el que usa Linux tarde o temprano acaba haciéndose algún shell script. Desde pequeños scripts que automatizan tareas engorrosas, hasta auténticos monstruos de más de quinientas líneas, los scripts son realmente necesarios en algún momento u otro. Yo los uso a diario: para hacer copias de seguridad periódicas, para cambiar la configuración de la wi-fi, para sincronizar dispositivos... Incluso he publicado alguno de ellos ya aquí.
Zenity es una utilidad que hace realmente fácil el mostrar cuadros de diálogo con GTK+ en tus shell scripts. Su uso es realmente sencillo y el resultado muy llamativo.
Zenity retorna al script distintos valores dependiendo de la acción del usuario sobre el cuadro de diálogo, de forma que puedas usarlos para lanzar condicionales o para capturar variables (VARIABLE=`zenity --entry`, por ejemplo). La caña, vamos. Un sencillo ejemplo:
if (`zenity --question`); then zenity --info; else zenity --error; fi
El resultado:
zenity --question devuelve 1 (o, lo que es lo mismo, true) si el usuario pulsa "Aceptar", y 0 (o false) si pulsa "Cancelar".
Las posibilidades son muchas y muy variadas, y su uso no puede ser más sencillo. man zenity para ver todas las posibilidades que ofrece ;)
Zenity es una utilidad que hace realmente fácil el mostrar cuadros de diálogo con GTK+ en tus shell scripts. Su uso es realmente sencillo y el resultado muy llamativo.
Zenity retorna al script distintos valores dependiendo de la acción del usuario sobre el cuadro de diálogo, de forma que puedas usarlos para lanzar condicionales o para capturar variables (VARIABLE=`zenity --entry`, por ejemplo). La caña, vamos. Un sencillo ejemplo:
if (`zenity --question`); then zenity --info; else zenity --error; fi
El resultado:
zenity --question devuelve 1 (o, lo que es lo mismo, true) si el usuario pulsa "Aceptar", y 0 (o false) si pulsa "Cancelar".
Las posibilidades son muchas y muy variadas, y su uso no puede ser más sencillo. man zenity para ver todas las posibilidades que ofrece ;)
21 febrero 2007
¿Por qué aún no se ha liberado Etch?
El domingo, Martin F. Krafft (maintainer de todos estos paquetes) dio una charla durante la primera SkyCon titulada Debian Etch: how to scratch the itch (Why we have not yet released and what you can do about it), en la que explicaba por qué aún Etch no ha pasado a estable. madduck ha liberado la presentación de la charla para que los que no estamos "dentro" del Proyecto sepamos qué está ocurriendo. En ella se puede ver un repaso sobre cómo funciona Debian por dentro, cómo se gestionan las actualizaciones, los ciclos de las releases, etcétera, incluyendo un gráfico explicativo del ciclo de un paquete, desde el código fuente hasta que llega a los repositorios de stable.
A lo que vamos: ¿por qué aún no se ha liberado Etch? Las razones son múltiples, pero se reducen a una: "porque aún no estamos preparados". Filosofía Debian en estado puro: si no tiene la calidad necesaria, no hay nada que hacer. Digan los plazos lo que digan.
Visto en detalle, hay tres grandes grupos de razones para el retraso: técnicas, de supervisión (management) y razones sociales.
Razones técnicas
Razones de supervisión
Razones sociales
* Dunc-tank fue la idea promovida por el actual DPL de pagar a los desarrolladores con fondos del Proyecto para acelerar el desarrollo y poder cumplir los plazos. Ya hablamos de ello en su día. Por el contrario, dunc-bank es una especie de búsqueda de bugs agresiva. Como dice Martin: "creemos que la calidad absoluta es más importante que mantener las promesas de liberación que otros hicieron por nosotros".
No sé, a mí me da la impresión de que se respira un cierto aire de "mosqueo" dentro del Proyecto, como que los DD (Debian Developers) no están muy de acuerdo con las decisiones que ha venido tomando el DPL en torno a la liberación de Etch, y que eso se está notando. Y lo entiendo: Debian no es una empresa. Aquí las cosas se hacen por amor al arte. Y se hacen bien, o no se hacen.
Pues eso, esperaremos.
A lo que vamos: ¿por qué aún no se ha liberado Etch? Las razones son múltiples, pero se reducen a una: "porque aún no estamos preparados". Filosofía Debian en estado puro: si no tiene la calidad necesaria, no hay nada que hacer. Digan los plazos lo que digan.
Visto en detalle, hay tres grandes grupos de razones para el retraso: técnicas, de supervisión (management) y razones sociales.
Razones técnicas
- Aún hay más de 100 bugs RC (release-critical, críticos para la liberación) y el número tiende a permanecer estancado (en estos momentos son exactamente 96)
- El kernel no está funcional (acapara aproximadamente el 30% de los bugs RC)
- El instalador se ve demorado por el kernel
Razones de supervisión
- Previsión de la fecha de liberación demasiado ambiciosa/irreal
- No haber tenido en cuenta los ritmos de resolución de los bugs RC de liberaciones anteriores
- Estadísticas de conteo de los bugs RC confusas (tres fuentes)
- Poner Etch como frozen demasiado pronto
Razones sociales
- Desacuerdo acerca de dunc-tank y creación de dunc-bank *
- Pérdida de tiempo en discusiones
- Desmotivación de los desarrolladores
* Dunc-tank fue la idea promovida por el actual DPL de pagar a los desarrolladores con fondos del Proyecto para acelerar el desarrollo y poder cumplir los plazos. Ya hablamos de ello en su día. Por el contrario, dunc-bank es una especie de búsqueda de bugs agresiva. Como dice Martin: "creemos que la calidad absoluta es más importante que mantener las promesas de liberación que otros hicieron por nosotros".
No sé, a mí me da la impresión de que se respira un cierto aire de "mosqueo" dentro del Proyecto, como que los DD (Debian Developers) no están muy de acuerdo con las decisiones que ha venido tomando el DPL en torno a la liberación de Etch, y que eso se está notando. Y lo entiendo: Debian no es una empresa. Aquí las cosas se hacen por amor al arte. Y se hacen bien, o no se hacen.
Pues eso, esperaremos.
20 febrero 2007
Sistemas basados en BeOS
Al hilo de la entrada sobre Haiku, me ha parecido interesante hacer un repaso de los distintos sistemas disponibles basados en BeOS: OSBOS (Open Standards BeOS-compatible Operating Systems).
BeOS es un sistema operativo desarrollado por Be Inc. en 1990. Es un sistema monousuario, con un microkernel modular. En el enlace podeis leer más acerca de sus características y su historia.
Lo que nos interesa ahora es que varios proyectos open source "recrean" (recordemos que BeOS es un sistema propietario) BeOS 5. Veamos los más interesantes:
Haiku OS, del que ya hemos hablado hace poco.
BlueEyedOS, inspirado en BeOS pero con un kernel Linux. Las APIs son de BeOS, reescritas con algunos cambios. En el momento de escribir esto la web está caída. Sinceramente, no sé si es temporal o es que el proyecto también ha fenecido.
Cosmoe. Como el anterior, Cosmoe utiliza unas APIs muy similares a las de BeOS, corriendo sobre un kernel Linux. De hecho, muchos programas para BeOS pueden ser recompilados y usados en Cosmoe.
Zeta OS es, sin duda, el más interesante. Inicialmente desarrollado por yellowTAB (en esa época era Zeta BeOS), en la actualidad está a cargo de Magnussoft. Yo mismo lo tuve conviviendo con Debian y FreeBSD bastante tiempo durante la época de yellowTAB.
Sequel, basado en un microkernel de licencia BSD. Aunque me temo que este proyecto está también muerto.
BeOS es un sistema operativo desarrollado por Be Inc. en 1990. Es un sistema monousuario, con un microkernel modular. En el enlace podeis leer más acerca de sus características y su historia.
Lo que nos interesa ahora es que varios proyectos open source "recrean" (recordemos que BeOS es un sistema propietario) BeOS 5. Veamos los más interesantes:
Haiku OS, del que ya hemos hablado hace poco.
BlueEyedOS, inspirado en BeOS pero con un kernel Linux. Las APIs son de BeOS, reescritas con algunos cambios. En el momento de escribir esto la web está caída. Sinceramente, no sé si es temporal o es que el proyecto también ha fenecido.
Cosmoe. Como el anterior, Cosmoe utiliza unas APIs muy similares a las de BeOS, corriendo sobre un kernel Linux. De hecho, muchos programas para BeOS pueden ser recompilados y usados en Cosmoe.
Zeta OS es, sin duda, el más interesante. Inicialmente desarrollado por yellowTAB (en esa época era Zeta BeOS), en la actualidad está a cargo de Magnussoft. Yo mismo lo tuve conviviendo con Debian y FreeBSD bastante tiempo durante la época de yellowTAB.
Sequel, basado en un microkernel de licencia BSD. Aunque me temo que este proyecto está también muerto.
19 febrero 2007
Charla sobre *BSD en IRC
Leo en 120% Linux que el 11 de marzo hay una charla en IRC sobre sistemas *BSD. Copio y pego directamente:
Resumen de la charla
La charla trata sobre la familia de sistemas *BSD y sobre FreeBSD, se hablará sobre la historia de estos sistemas y la diferenciación de estos sistemas en cuanto a GNU/Linux. Veremos cuáles son los tres principales sistemas operativos *BSD y cuál es la licencia de éstos. Ya ahondando un poco más en FreeBSD, veremos las tres distintas versiones que tiene y cómo gestionan las aplicaciones mediante compilaciones e instalaciones de paquetes binarios ya precompilados junto a las opciones que da el sistema operativo para optimizar el rendimiento de la máquina.
Cita
La cita es el Domingo 11 de marzo a las 19.00 de la tarde (hora española) en el canal #eldemonio del servidor freenode (cómo no) del IRC.
Ponente
\Shadowfox\ -> hackresearch
Resumen de la charla
La charla trata sobre la familia de sistemas *BSD y sobre FreeBSD, se hablará sobre la historia de estos sistemas y la diferenciación de estos sistemas en cuanto a GNU/Linux. Veremos cuáles son los tres principales sistemas operativos *BSD y cuál es la licencia de éstos. Ya ahondando un poco más en FreeBSD, veremos las tres distintas versiones que tiene y cómo gestionan las aplicaciones mediante compilaciones e instalaciones de paquetes binarios ya precompilados junto a las opciones que da el sistema operativo para optimizar el rendimiento de la máquina.
Cita
La cita es el Domingo 11 de marzo a las 19.00 de la tarde (hora española) en el canal #eldemonio del servidor freenode (cómo no) del IRC.
Ponente
\Shadowfox\ -> hackresearch
Probando Haiku OS
Haiku es un nuevo sistema operativo open source (aún está en desarrollo) basado en BeOS que, según me entero gracias a Linuzeros, se presentó en Google el día 13 de febrero (vídeo de la presentación, en inglés).
¿Open source y basado en BeOS? Esto sólo puede traer cosas buenas, así que merece la pena probarlo. En su web hay disponibles dos imágenes de prueba, una raw y otra para VMWare. Podemos bajar una u otra desde la página de descargas de Haiku.
La imagen raw es una imagen de disco duro que podemos "instalar" usando dd, pero para probarla no hace falta tanto: basta con tirar de QEMU. Para ello arrancamos la máquina virtual con las siguientes opciones:
qemu -boot c -hda haiku.image -m 512 -k es
Con -boot c le decimos que arranque desde disco duro, especificando con -hda haiku.image que ese disco duro es la imagen que hemos descargado (primero hay que descomprimirla, claro, viene en .tar.bz2). -m 512 indica la cantidad de RAM que queremos asignar a la máquina virtual, mientras que -k es establece el teclado en español. También podeis usar si quereis la opción -full-screen, eso va al gusto :)
Pues bien, ahí tenemos ya nuestra máquina virtual con Haiku, un sistema nuevo listo para experimentar con él. Me encantan estas cosas... :D
¿Open source y basado en BeOS? Esto sólo puede traer cosas buenas, así que merece la pena probarlo. En su web hay disponibles dos imágenes de prueba, una raw y otra para VMWare. Podemos bajar una u otra desde la página de descargas de Haiku.
La imagen raw es una imagen de disco duro que podemos "instalar" usando dd, pero para probarla no hace falta tanto: basta con tirar de QEMU. Para ello arrancamos la máquina virtual con las siguientes opciones:
qemu -boot c -hda haiku.image -m 512 -k es
Con -boot c le decimos que arranque desde disco duro, especificando con -hda haiku.image que ese disco duro es la imagen que hemos descargado (primero hay que descomprimirla, claro, viene en .tar.bz2). -m 512 indica la cantidad de RAM que queremos asignar a la máquina virtual, mientras que -k es establece el teclado en español. También podeis usar si quereis la opción -full-screen, eso va al gusto :)
Pues bien, ahí tenemos ya nuestra máquina virtual con Haiku, un sistema nuevo listo para experimentar con él. Me encantan estas cosas... :D
16 febrero 2007
Creando un entorno de pruebas con chroot
Tenía pensado escribir un post sobre este tema, pero se me han adelantado. Y me alegro. Me alegro porque ni de lejos habría sido tan bueno como el que ha escrito Miriam Ruiz. En Creando un entorno chroot para pruebas (que también podeis leer en Planeta Debian, ya que Miriam es desarrolladora de nuestra distro preferida) explica detalladamente y paso a paso cómo hacerlo, añadiendo además algunos consejos y truquillos (se nota que basados en la experiencia personal) muy útiles a la hora de llevar a cabo la experiencia, como la "recetilla" para iniciar el entorno enjaulado en una tty en el arranque del sistema.
Pero es que no se queda ahí y va aún más lejos facilitándonos un script que hace todo esto de forma automatizada.
También, relacionado con el tema, os recomiendo echar un vistazo a otro magnífico tutorial escrito por ella: Enjaulando al Apache.
Mi más sincero agradecimiento :)
Pero es que no se queda ahí y va aún más lejos facilitándonos un script que hace todo esto de forma automatizada.
También, relacionado con el tema, os recomiendo echar un vistazo a otro magnífico tutorial escrito por ella: Enjaulando al Apache.
Mi más sincero agradecimiento :)
15 febrero 2007
La Constitución de Debian
Conforme el Proyecto Debian fue creciendo desde sus comienzos, pronto se hizo evidente que eran necesarias una serie de reglas "semiformales" que ayudaran en la resolución de conflictos. El resultado es la Constitución de Debian. Ésta describe la estructura organizativa para la toma de decisiones en el Proyecto, especificando a la vez qué poderes se conceden a cada individuo dentro de esa estructura.
Hasta el momento ha habido cuatro versiones de esta Constitución. La primera, la versión 1.0, fue ratificada en diciembre de 1998. La versión actual es la v1.3, en vigor desde el 24 de septiembre de 2006.
Su comienzo es toda una declaración de intenciones:
A continuación enumera las seis entidades con voz en la toma de decisiones dentro del Proyecto:
Cualquier persona puede ocupar varios puestos, con la excepción de que el Secretario del Proyecto no puede ser a la vez el Líder del Proyecto ni el Presidente del Comité Técnico. Podeis ver el organigrama actual del Proyecto aquí. También os recomiendo, si os interesa conocer la forma en que se toman las decisiones en el Proyecto, la lectura tanto de la Constitución como del resto de enlaces que he ido poniendo. Todo un ejemplo de organización.
Hasta el momento ha habido cuatro versiones de esta Constitución. La primera, la versión 1.0, fue ratificada en diciembre de 1998. La versión actual es la v1.3, en vigor desde el 24 de septiembre de 2006.
Su comienzo es toda una declaración de intenciones:
El Proyecto Debian es una asociación de individuos que han hecho causa común para crear un sistema operativo libre.
A continuación enumera las seis entidades con voz en la toma de decisiones dentro del Proyecto:
- Los Desarrolladores, mediante una Resolución General o una elección
- El Líder del Proyecto
- El Comité Técnico o su Presidente
- El Desarrollador que trabaja en una tarea determinada (esto se refiere a toma de decisiones respecto a esa tarea)
- Delegados nombrados por el Líder del Proyecto para una tarea específica
- El Secretario del Proyecto
Cualquier persona puede ocupar varios puestos, con la excepción de que el Secretario del Proyecto no puede ser a la vez el Líder del Proyecto ni el Presidente del Comité Técnico. Podeis ver el organigrama actual del Proyecto aquí. También os recomiendo, si os interesa conocer la forma en que se toman las decisiones en el Proyecto, la lectura tanto de la Constitución como del resto de enlaces que he ido poniendo. Todo un ejemplo de organización.
11 febrero 2007
Opera en USB
Opera @USB es una versión del navegador más rápido de toda la "intesné" para llevar y ejecutar desde un USB stick.
Es la solución perfecta para no tener que depender del navegador que haya instalado cuando te conectas desde una máquina que no sea la tuya, para llevar tus marcadores contigo (los podemos importar copiando el $HOME/.opera/opera6.adr en el directorio del programa y eligiendo Archivo - Importar y exportar - Importar marcadores de Opera), etc. La única pega es que es para Windows. Pega según se mire, porque generalmente una máquina "que no sea la tuya" es un equipo Windows.
Además, como podeis ver por el icono que presenta en la esquina superior izquierda (la copa de vino en lugar de la "O"), se ejecuta perfectamente con WINE bajo Linux.
Opera @USB viene también con los plugins para Windows de serie, por lo que podremos, por ejemplo, visualizar páginas con Shockwave, para el que no hay versión de Linux (o no lo conozco, ¿alguien sabe algo de esto?). Y en sólo 6 Mb de espacio! Viene, incluso, con algún plugin de más, como podeis ver:
:D
Es la solución perfecta para no tener que depender del navegador que haya instalado cuando te conectas desde una máquina que no sea la tuya, para llevar tus marcadores contigo (los podemos importar copiando el $HOME/.opera/opera6.adr en el directorio del programa y eligiendo Archivo - Importar y exportar - Importar marcadores de Opera), etc. La única pega es que es para Windows. Pega según se mire, porque generalmente una máquina "que no sea la tuya" es un equipo Windows.
Además, como podeis ver por el icono que presenta en la esquina superior izquierda (la copa de vino en lugar de la "O"), se ejecuta perfectamente con WINE bajo Linux.
Opera @USB viene también con los plugins para Windows de serie, por lo que podremos, por ejemplo, visualizar páginas con Shockwave, para el que no hay versión de Linux (o no lo conozco, ¿alguien sabe algo de esto?). Y en sólo 6 Mb de espacio! Viene, incluso, con algún plugin de más, como podeis ver:
:D
10 febrero 2007
Alternando escritorios virtuales
Una de las cosas que más me gustan de un escritorio Linux es que es capaz de manejar más de un escritorio (valga la redundancia) virtual, y es una de las cosas que más chocan a los usuarios de Windows (pobres, si supieran...) la primera vez que ven uno.
Normalmente para alternar entre escritorios usamos la combinación de teclas [Ctrl]+[Tab] o bien el applet de la barra de tareas, pero hay formas más cool de hacerlo.
Komposé
Komposé es una pequeña aplicación para KDE que una vez instalada (apt-get install kompose) y ejecutada nos muestra un tray icon que al pinchar sobre él nos muestra una pantalla con los escritorios que tenemos en ejecución y las ventanas abiertas en ellos:
Basta pinchar en la zona correspondiente al escritorio al que querais ir.
3dDesktop
3dDesktop (apt-get install 3ddesktop) es un programa basado en la arquitectura cliente-servidor que hace uso de la aceleración 3D (con OpenGL) para alternar entre escritorios de una manera bastante menos prosaica. Tras ejecutar el servidor 3ddeskd (podemos incluirlo en .kde/Autostart o la ruta equivalente de Gnome), al ejecutar el cliente 3ddesk nos muestra una pantalla de este estilo (las capturas no son mías):
El número sobre la pantalla informa del escritorio que hay al frente en ese momento. Podemos controlarlo tanto con el teclado como con el ratón, aunque esta última forma es mucho más cómoda (click derecho/izquierdo o rueda: rotación; click con los dos botones a la vez: selección de escritorio).
Las opciones son múltiples, y las podemos configurar de forma sencilla editando el archivo /etc/3ddesktop/3ddesktop.conf.
Happy switching :D
Normalmente para alternar entre escritorios usamos la combinación de teclas [Ctrl]+[Tab] o bien el applet de la barra de tareas, pero hay formas más cool de hacerlo.
Komposé
Komposé es una pequeña aplicación para KDE que una vez instalada (apt-get install kompose) y ejecutada nos muestra un tray icon que al pinchar sobre él nos muestra una pantalla con los escritorios que tenemos en ejecución y las ventanas abiertas en ellos:
Basta pinchar en la zona correspondiente al escritorio al que querais ir.
3dDesktop
3dDesktop (apt-get install 3ddesktop) es un programa basado en la arquitectura cliente-servidor que hace uso de la aceleración 3D (con OpenGL) para alternar entre escritorios de una manera bastante menos prosaica. Tras ejecutar el servidor 3ddeskd (podemos incluirlo en .kde/Autostart o la ruta equivalente de Gnome), al ejecutar el cliente 3ddesk nos muestra una pantalla de este estilo (las capturas no son mías):
El número sobre la pantalla informa del escritorio que hay al frente en ese momento. Podemos controlarlo tanto con el teclado como con el ratón, aunque esta última forma es mucho más cómoda (click derecho/izquierdo o rueda: rotación; click con los dos botones a la vez: selección de escritorio).
Las opciones son múltiples, y las podemos configurar de forma sencilla editando el archivo /etc/3ddesktop/3ddesktop.conf.
Happy switching :D
Elecciones Debian Project Leader 2007
Algo que se me había pasado por alto (imperdonable) es que desde esta semana estamos de elecciones, y es que el lunes comenzó el periodo de candidaturas para DPL.
El Debian Project Leader es elegido en una votación en la que todos los desarrolladores de Debian tienen derecho a voto. Para la elección del DPL, cuyo cargo dura un año, Debian utiliza el método Condorcet, en el que los votantes hacen una lista de los candidatos en orden de preferencia.
El DPL actual, cuyo mandato termina el día 17 de abril, es Anthony Towns, promotor, si lo recordais, del controvertido DUNC. Podeis consultar una lista de los líderes anteriores en la historia de Debian.
A lo que vamos. El calendario de las elecciones es el siguiente:
Periodo de candidaturas: Del 4 al 25 de febrero
Periodo de campaña: Del 25 de febrero al 18 de marzo
Periodo de votaciones: Del 18 de marzo al 8 de abril
El día 8 de abril a las 00:00:00 UTC termina el periodo de votaciones, y para el 17 de abril tendremos nuevo (o el mismo si lo reeligen, claro) DPL.
El Debian Project Leader es elegido en una votación en la que todos los desarrolladores de Debian tienen derecho a voto. Para la elección del DPL, cuyo cargo dura un año, Debian utiliza el método Condorcet, en el que los votantes hacen una lista de los candidatos en orden de preferencia.
El DPL actual, cuyo mandato termina el día 17 de abril, es Anthony Towns, promotor, si lo recordais, del controvertido DUNC. Podeis consultar una lista de los líderes anteriores en la historia de Debian.
A lo que vamos. El calendario de las elecciones es el siguiente:
Periodo de candidaturas: Del 4 al 25 de febrero
Periodo de campaña: Del 25 de febrero al 18 de marzo
Periodo de votaciones: Del 18 de marzo al 8 de abril
El día 8 de abril a las 00:00:00 UTC termina el periodo de votaciones, y para el 17 de abril tendremos nuevo (o el mismo si lo reeligen, claro) DPL.
09 febrero 2007
Etch está al caer
Hace poco un lector y comentarista habitual del blog, kumo, me preguntaba aquí mismo si sabía cuánto faltaba para que Etch pasara a stable.
Este gráfico representa la evolución en el número de bugs críticos en Debian (pinchando sobre él accedereis a la web de bugs de Debian). Lo que nos interesa es la línea verde. Esta línea marca el número de bugs que conciernen a la próxima release, en estos momentos Etch. Su número es, en el momento de escribir esto, exactamente 101 (no, cinco no, en decimal, ciento uno :D), y bajando a velocidad considerable (en las últimas horas se han cerrado cinco, uno de ellos concerniente a amsn 0.95, y se ha abierto uno). Observad el mínimo en el mes de junio de 2005: fue el paso de Sarge a stable. ¿Sabeis lo que esto significa?
EXACTO!! Que estamos a muy poquitos bugs de la nueva release! :P
Este gráfico representa la evolución en el número de bugs críticos en Debian (pinchando sobre él accedereis a la web de bugs de Debian). Lo que nos interesa es la línea verde. Esta línea marca el número de bugs que conciernen a la próxima release, en estos momentos Etch. Su número es, en el momento de escribir esto, exactamente 101 (no, cinco no, en decimal, ciento uno :D), y bajando a velocidad considerable (en las últimas horas se han cerrado cinco, uno de ellos concerniente a amsn 0.95, y se ha abierto uno). Observad el mínimo en el mes de junio de 2005: fue el paso de Sarge a stable. ¿Sabeis lo que esto significa?
EXACTO!! Que estamos a muy poquitos bugs de la nueva release! :P
08 febrero 2007
Crear un LiveCD de Debian
Esta mañana mi akregator me daba una agradable sorpresa: ServoMac explica en su blog (en mallorquín) cómo crear un LiveCD de Debian. La verdad es que me ha llamado mucho la atención porque no tenía ni la más mínima idea de que fuera tan fácil, y como ServoMac se ha enrollado y me ha dado permiso para fusilarle el post, pues lo hago :)
Básicamente es tan sencillo como instalar el paquete live-package, que provee la utilidad make-live. Con esto, el tema se reduce a hacer
make-live -d [sarge|etch|sid] -p [lista o archivo con los paquetes a incluir] -m [mirror]
Para ponernos las cosas más fáciles, en /usr/share/make-live/lists/ tenemos varias listas predefinidas que podemos usar (gnome-full, kde-full, minimal, standard, x11...), con lo que no tenemos ni que calentarnos la cabeza haciendo listas de paquetes y pensando en dependencias. Fácil fácil :)
sudo make-live -d etch -p /usr/share/make-live/lists/kde-full-i18n -m ftp://ftp.es.debian.org/debian/
Una vez ejecutado el comando (y descargados los paquetes) se nos creará el directorio debian-live, en el que encontraremos la ISO como binary.iso, y a tostar.
Gracias ServoMac :D
Básicamente es tan sencillo como instalar el paquete live-package, que provee la utilidad make-live. Con esto, el tema se reduce a hacer
make-live -d [sarge|etch|sid] -p [lista o archivo con los paquetes a incluir] -m [mirror]
Para ponernos las cosas más fáciles, en /usr/share/make-live/lists/ tenemos varias listas predefinidas que podemos usar (gnome-full, kde-full, minimal, standard, x11...), con lo que no tenemos ni que calentarnos la cabeza haciendo listas de paquetes y pensando en dependencias. Fácil fácil :)
sudo make-live -d etch -p /usr/share/make-live/lists/kde-full-i18n -m ftp://ftp.es.debian.org/debian/
Una vez ejecutado el comando (y descargados los paquetes) se nos creará el directorio debian-live, en el que encontraremos la ISO como binary.iso, y a tostar.
Gracias ServoMac :D
07 febrero 2007
EyeOS
Últimamente se está hablando mucho de los sistemas operativos on-line. Son sistemas escritos en PHP que se ejecutan en un servidor web y a los que el usuario accede (y maneja) mediante el navegador.
Existen actualmente varios de ellos (al final dejo una lista de enlaces) pero me ha llamado la atención especialmente EyeOS por dos motivos: es open source y está hecho ¡por españoles!
El que sea open source es algo importante, y no sólo por motivos filosóficos: además de poder acceder a él on-line podemos descargarlo y usarlo en local. Para ello necesitaremos, evidentemente, un servidor web con soporte para PHP, pero eso no es problema. Por algo GNU/Linux lleva el Apache "de serie".
El código fuente pesa poco más de un mega. Sólo tenemos que descomprimirlo en la raíz del servidor y darle todos los permisos (chmod 777) al directorio %%ServerRoot%%eyeOS/etc/. A partir de ahí podemos acceder al sistema a través de la dirección http://localhost/eyeOS/
Al acceder el sistema nos pide que elijamos el idioma e introduzcamos una contraseña para root. Tras eso accedemos ya al escritorio, donde vemos un mensaje de bienvenida con algunas indicaciones generales (pinchar en las imágenes para ver a tamaño completo)
Leemos la introducción (en inglés aunque elijas español en la configuración inicial) o cerramos, pulsando sobre el círculo que hay en la esquina superior derecha de la ventana (muy a lo MacOS). Ya estamos en el escritorio:
El fondo de escritorio se puede cambiar fácilmente por uno de los que tengas en tu disco duro, o bien usar el navegador que lleva el sistema para descargar uno de internet :P. También se puede cambiar el theme y ajustar algunas cosillas del aspecto, pero de momento no vamos a hacer nada de eso: estamos logueados como root. Lo primero es crearnos un usuario.
Nos vamos al menú eyeOptions (la llave inglesa de la barra superior) y hacemos scroll hasta encontrar la opción que estamos buscando
Después sólo queda cerrar sesión usando el botón rojo que hay abajo a la derecha, sobre el reloj, y acceder con el usuario que hemos creado:
Ahora sí podemos trastear con el sistema todo lo que queramos. Podeis encontrar un manual de usuario en PDF aquí (en inglés), aunque realmente no es necesario: es todo muy intuitivo.
EyeOS tiene las utilidades básicas que puedas necesitar:
Un navegador web, eyeNav:
un completo editor de textos, eyeEdit:
un lector de RSS y algunas cosas más, que os dejo descubrir a vosotros. También podeis descargar e instalar nuevas aplicaciones desde EyeApps como eyePDF, eyeEncryptionPad, eyeAmp, etc.
Otros sistemas operativos on-line
CrayThur
DesktopTwo
Glide
Goowy
Orca
Xindesk
YouOS
Existen actualmente varios de ellos (al final dejo una lista de enlaces) pero me ha llamado la atención especialmente EyeOS por dos motivos: es open source y está hecho ¡por españoles!
El que sea open source es algo importante, y no sólo por motivos filosóficos: además de poder acceder a él on-line podemos descargarlo y usarlo en local. Para ello necesitaremos, evidentemente, un servidor web con soporte para PHP, pero eso no es problema. Por algo GNU/Linux lleva el Apache "de serie".
El código fuente pesa poco más de un mega. Sólo tenemos que descomprimirlo en la raíz del servidor y darle todos los permisos (chmod 777) al directorio %%ServerRoot%%eyeOS/etc/. A partir de ahí podemos acceder al sistema a través de la dirección http://localhost/eyeOS/
Al acceder el sistema nos pide que elijamos el idioma e introduzcamos una contraseña para root. Tras eso accedemos ya al escritorio, donde vemos un mensaje de bienvenida con algunas indicaciones generales (pinchar en las imágenes para ver a tamaño completo)
Leemos la introducción (en inglés aunque elijas español en la configuración inicial) o cerramos, pulsando sobre el círculo que hay en la esquina superior derecha de la ventana (muy a lo MacOS). Ya estamos en el escritorio:
El fondo de escritorio se puede cambiar fácilmente por uno de los que tengas en tu disco duro, o bien usar el navegador que lleva el sistema para descargar uno de internet :P. También se puede cambiar el theme y ajustar algunas cosillas del aspecto, pero de momento no vamos a hacer nada de eso: estamos logueados como root. Lo primero es crearnos un usuario.
Nos vamos al menú eyeOptions (la llave inglesa de la barra superior) y hacemos scroll hasta encontrar la opción que estamos buscando
Después sólo queda cerrar sesión usando el botón rojo que hay abajo a la derecha, sobre el reloj, y acceder con el usuario que hemos creado:
Ahora sí podemos trastear con el sistema todo lo que queramos. Podeis encontrar un manual de usuario en PDF aquí (en inglés), aunque realmente no es necesario: es todo muy intuitivo.
EyeOS tiene las utilidades básicas que puedas necesitar:
Un navegador web, eyeNav:
un completo editor de textos, eyeEdit:
un lector de RSS y algunas cosas más, que os dejo descubrir a vosotros. También podeis descargar e instalar nuevas aplicaciones desde EyeApps como eyePDF, eyeEncryptionPad, eyeAmp, etc.
Otros sistemas operativos on-line
CrayThur
DesktopTwo
Glide
Goowy
Orca
Xindesk
YouOS
04 febrero 2007
Portknocking: cerradura de combinación en el firewall
Como sabeis, Linux implementa un firewall por kernel: iptables. Con él podemos crear y/o modificar reglas para permitir, denegar o redirigir las conexiones en nuestro sistema. Es un sistema altamente confiable y muy seguro. Pero es un sistema estático: cumple las reglas impuestas por root, y nada más.
Para que entendais lo que quiero decir nada mejor que un ejemplo. Podemos poner una regla de iptables que rechace las conexiones a nuestro puerto 22 (SSH):
Esto blindará el acceso por el puerto 22, impidiendo que nadie pueda acceder a nuestro servidor SSH. Sin duda aumenta la seguridad, pero ¿y si somos nosotros los que queremos acceder a él desde un equipo remoto?
Se pueden, por supuesto, construir reglas que permitan el acceso a una IP dada, incluso a una dirección MAC dada (iptables es muy versátil), pero eso tiene dos inconvenientes:
La solución es una ingeniosa técnica llamada portknocking.
Firewall activo: portknocking
Esta técnica consiste en bloquear los servicios de un host, pero manteniendo un demonio a la escucha de intentos de conexión en determinados puertos (cerrados). Cuando un cliente intente conectar a estos puertos según una secuencia determinada, el demonio variará temporalmente las reglas de iptables para permitirle acceder. Sigamos con el ejemplo de antes.
Digamos que quiero acceder a mi equipo remotamente usando el servidor SSH, pero no quiero dejarlo permanentemente expuesto en Internet, arriesgándome a que sufra ataques brute force o con algún exploit 0-day. Pongamos también que quiero acceder a él desde diversas máquinas (el trabajo, la casa de la novia, un cibercafé...) que pueden no ser siempre las mismas, y que además aunque lo fueran no crearía reglas que permitiesen a su IP/MAC acceder, ya que soy muy paranoico y sé que alguien podría spoofear esas IP/MAC para conseguir acceso.
La solución sería dropear todas las conexiones entrantes, pero mantener un demonio knockd en background escuchando los puertos, digamos, 2546, 3101, 6969, 21732 y 4400, puertos que estarían cerrados. Yo puedo configurar knockd de forma que, si alquien intenta conectar con esos puertos por ese orden y en un intervalo de treinta segundos, varíe las reglas del cortafuegos permitiendo a esa IP acceder al puerto 22.
¿Cómo implementarlo?
Nada más sencillo:
apt-get install knockd
knockd es un servidor de portknocking que escucha todo el tráfico de una interfaz determinada (de momento sólo soporta Ethernet y PPP). Cuando detecta una secuencia determinada de knocks ejecuta un comando definido en su archivo de configuración, que puede perfectamente ser una regla de iptables para permitirnos el acceso al servicio que deseemos.
Como clientes, debemos envíar los paquetes a los puertos que hayamos establecido previamente para que knockd nos brinde acceso. Eso es fácil de hacer con cualquier herramienta que genere paquetes TCP o UDP, como por ejemplo GSpoof o Nemesis (aunque la finalidad de estas herramientas es otra, generar e inyectar paquetes con las cabeceras TCP/IP manipuladas: sí, para hacer ataques de IP spoofing, por ejemplo). También podemos hacerlo "artesanalmente" con un simple cliente telnet.
Como veis el portknocking nos da a la vez seguridad, confiabilidad y versatilidad, convirtiendo nuestro cortafuegos estático en un firewall activo que nos permite variar sus reglas adaptándose a nuestras necesidades.
Para que entendais lo que quiero decir nada mejor que un ejemplo. Podemos poner una regla de iptables que rechace las conexiones a nuestro puerto 22 (SSH):
iptables -t filter -A INPUT -p tcp --dport 22 -j DROP
Esto blindará el acceso por el puerto 22, impidiendo que nadie pueda acceder a nuestro servidor SSH. Sin duda aumenta la seguridad, pero ¿y si somos nosotros los que queremos acceder a él desde un equipo remoto?
Se pueden, por supuesto, construir reglas que permitan el acceso a una IP dada, incluso a una dirección MAC dada (iptables es muy versátil), pero eso tiene dos inconvenientes:
- Disminuye la seguridad, siendo vulnerable a ataques de IP spoofing y de MAC spoofing
- Nos encontramos atados a esa IP o a esa MAC: si necesitamos acceder desde cualquier otra no podremos hacerlo
La solución es una ingeniosa técnica llamada portknocking.
Firewall activo: portknocking
Esta técnica consiste en bloquear los servicios de un host, pero manteniendo un demonio a la escucha de intentos de conexión en determinados puertos (cerrados). Cuando un cliente intente conectar a estos puertos según una secuencia determinada, el demonio variará temporalmente las reglas de iptables para permitirle acceder. Sigamos con el ejemplo de antes.
Digamos que quiero acceder a mi equipo remotamente usando el servidor SSH, pero no quiero dejarlo permanentemente expuesto en Internet, arriesgándome a que sufra ataques brute force o con algún exploit 0-day. Pongamos también que quiero acceder a él desde diversas máquinas (el trabajo, la casa de la novia, un cibercafé...) que pueden no ser siempre las mismas, y que además aunque lo fueran no crearía reglas que permitiesen a su IP/MAC acceder, ya que soy muy paranoico y sé que alguien podría spoofear esas IP/MAC para conseguir acceso.
La solución sería dropear todas las conexiones entrantes, pero mantener un demonio knockd en background escuchando los puertos, digamos, 2546, 3101, 6969, 21732 y 4400, puertos que estarían cerrados. Yo puedo configurar knockd de forma que, si alquien intenta conectar con esos puertos por ese orden y en un intervalo de treinta segundos, varíe las reglas del cortafuegos permitiendo a esa IP acceder al puerto 22.
¿Cómo implementarlo?
Nada más sencillo:
apt-get install knockd
knockd es un servidor de portknocking que escucha todo el tráfico de una interfaz determinada (de momento sólo soporta Ethernet y PPP). Cuando detecta una secuencia determinada de knocks ejecuta un comando definido en su archivo de configuración, que puede perfectamente ser una regla de iptables para permitirnos el acceso al servicio que deseemos.
Como clientes, debemos envíar los paquetes a los puertos que hayamos establecido previamente para que knockd nos brinde acceso. Eso es fácil de hacer con cualquier herramienta que genere paquetes TCP o UDP, como por ejemplo GSpoof o Nemesis (aunque la finalidad de estas herramientas es otra, generar e inyectar paquetes con las cabeceras TCP/IP manipuladas: sí, para hacer ataques de IP spoofing, por ejemplo). También podemos hacerlo "artesanalmente" con un simple cliente telnet.
Como veis el portknocking nos da a la vez seguridad, confiabilidad y versatilidad, convirtiendo nuestro cortafuegos estático en un firewall activo que nos permite variar sus reglas adaptándose a nuestras necesidades.
Sun envía gratis Solaris 10 (otra vez)
La primera ocasión la dejé escapar como un tonto: me llegó el aviso de Correos, lo metí en la cartera, y cuando por fin fui a recogerlo... habían pasado dos días del límite y habían devuelto el envío :@
Pero esta vez no me pasará igual. Sun Microsystems está, de nuevo, enviando DVDs con Solaris 10 y el Developer Tools Software Kit, de forma gratuita, a todo el que lo pida. El DVD incluye:
También se puede descargar la imagen ISO de los servidores de Sun, pero pesa 4 Gb. Además, como buen friki es obligado tenerlo en su carátula original ;)
Pero esta vez no me pasará igual. Sun Microsystems está, de nuevo, enviando DVDs con Solaris 10 y el Developer Tools Software Kit, de forma gratuita, a todo el que lo pida. El DVD incluye:
- Sistema operativo Sun Solaris 10, para plataformas x86 y SPARC
- Sun Studio 11
- Java Studio Creator 2 Update 1
- Java Studio Enterprise 8
- Netbeans 5.0
También se puede descargar la imagen ISO de los servidores de Sun, pero pesa 4 Gb. Además, como buen friki es obligado tenerlo en su carátula original ;)
03 febrero 2007
02 febrero 2007
Wardriving con la fonera
De los hacks que se han publicado hasta ahora para la fonera (1, 2, 3...) este sin duda me parece el mejor: Wardriving con la fonera.
Hay que adaptarle a la fonera un módulo GPS, una antena omnidireccional y un adaptador para mechero del coche, instalarle el firmware OpenWRT, y el demonio fonerawd (programado por el propio autor del hack y liberado bajo licencia GPL).
En fin, que lo mejor que podeis hacer es leer el artículo original, donde explica con detalle cada paso y se pueden ver las fotografías del proceso, incluso una muestra del resultado.
Un diez.
Hay que adaptarle a la fonera un módulo GPS, una antena omnidireccional y un adaptador para mechero del coche, instalarle el firmware OpenWRT, y el demonio fonerawd (programado por el propio autor del hack y liberado bajo licencia GPL).
En fin, que lo mejor que podeis hacer es leer el artículo original, donde explica con detalle cada paso y se pueden ver las fotografías del proceso, incluso una muestra del resultado.
Un diez.
Suscribirse a:
Entradas (Atom)