Linux

GNU, Linux, Debian, y demás fanatismos.

Firewalls personales para Linux

Hoy he desinstalado firestarter. Me hacen falta ciertas reglas de iptables las máquinas virtuales que uso para pruebas, y pensé que con firestarter podría hacerlo sin tener que editar ficheros en línea de comandos. No quería algo tan serio como lo que hago a diario en el trabajo. Quería algo sencillo, relajado, aunque no fuera muy seguro. Al fin y al cabo, es para mi ordenador de escritorio, que ya está detrás de un router/firewall.

Firestarter es muy fácil de usar, pero nunca acabó de funcionar bien del todo. Había permitido que los equipos conectados al interfaz br0 (en el que están las máquinas virtuales) salieran a Internet, pero no funcionaba DHCP. Lo permití desde cualquier sitio y cualquier interfaz, y seguía sin funcionar. Luego descubrí que una VPN que tengo con el ordenador que alberga esta web tampoco funcionaba. Permití todo el tráfico desde la red de la VPN, y seguía sin funcionar. Veía muchos paquetes ICMP rechazados desde sitios que monitorizo con smokeping para ver la salud de la red (extraño, porque era yo quien iniciaba los pings). Permití todos los ICMP ... y seguía sin funcionar.

Hoy he estado buscando alternativas. Hace mucho tiempo había llegado a tres "finalistas": firestarter, otro para KDE que ni recuerdo, y fwbuilder. El problema con el de KDE es que no uso KDE, y el problema con fwbuilder es que, para lo que yo quiero, es demasiado potente. Está muy bien, pero es demasiado para algo tan sencillo como lo que yo quería. Para que se hagan una idea, antes de usar firestarter era un fichero en /etc/init.d con tres o cuatro líneas llamando a iptables.

Pensé en ufw, pero lo descarté porque sólo vale para el propio equipo. Para hacer enmascaramientos y cosas "avanzadas" necesitas hacer algo de magia negra. No hay mucha diferencia entre eso y mis scripts.

Viendo que no hay más remedio, he instalado fwbuilder.

Cosas que no me gustan de fwbuilder:

  • Como ya dije, es demasiado complicado para lo que yo quiero. Necesitas saber de firewalls para usarlo. A mí me da igual, pero no lo recomendaría a alguien que quiere un "firewall de escritorio" típico. Sólo la configuración de un "objeto firewall" ya es bastante liosa si no sabes qué estás haciendo.
  • Necesita entrar por ssh como root en el firewall (localhost, en mi caso) para actualizar las reglas, o con un usuario que por sudo pueda escribir donde las tienes.
  • Es un servicio del sistema. Es decir: no hay un icono en la bandeja del sistema en el que pinchas y puedes cambiar cosas, activar o desactivar el firewall, y todo eso. Tienes que tirar de terminal para hacerlo.
  • Por lo anterior, la instalación requiere que toques cosas en el sistema si quieres que funcione "bien": tienes que configurar un usuario que pueda levantar el firewall con sudo, crear un directorio para las reglas e instalar un script init.d y un fichero en /etc/default que vienen en los ejemplos (no se hace por defecto porque puedes tener el firewall en otro sitio que no sea donde editas las reglas).
  • Mi configuración de fwbuilder tiene cuatro reglas en fitler y una en nat. Para hacerlo, entre media hora y 45 minutos, sobre todo definiendo interfaces y hosts. Soy un poco maniático y estuve buceando entre las opciones de fwbuilder para ver qué podían hacer, pero quitando ese tiempo tardaría un mínimo de 15 minutos en haber configurado mis cuatro reglas.

    Luego hay que añadir otros cinco minutos cuando descubrí que la comunicación desde las máquinas virtuales a Internet funcionaba muy bien, pero no así desde el equipo que hace de firewall. Cuando vi que Google no respondía empecé a sospechar que faltaba afinar un poco el firewall.

    Una vez hecho, no hay mucho más que tocar. Voy a tener durante un tiempo fwbuilder a ver qué resultado da. Me temo que implique volver a lanzar un terminal para activar el firewall cada vez que reinicie (que, por suerte, no es muy a menudo), pero de momento lo asumo. En unas semanas veré si acabo harto y vuelvo a alguna solución más user friendly.

Linux es fácil

Tanto como extirparse un cálculo renal con una cucharilla de postre. Usando los pies.

Sí, estoy un poco mosqueado.

Desde la actualización de Ubuntu "Jaunty" a "Karmic" tenía varios "problemillas". El primero, que no funcionaba el dongle USB Wifi, con lo que no tenía Internet. El segundo, que no funcionaba el sonido. Nada importante, como ven. Lo normal en una actualización entre distribuciones (presuntamente) estables. Para que luego digan de Debian.

El problema de la Wifi lo solucioné cambiando de dongle (por suerte, tenía dos distintos). El problema del sonido lo arreglé tocando la configuración de pulseaudio tras una furiosa búsqueda en Google y Launchpad. pulseaudio es como un supositorio: sabes que a largo plazo será bueno para ti, pero el mal rato que vas a pasar mientras te lo ponen no te lo quita nadie. Ahora mismo hay mucha gente a la que le da problemas, pero es una arquitectura superior que permite mucho más de lo que permitían los servidores de sonido actuales. Todas las distribuciones lo han adoptado, y a pesar de lo que parece, en general funciona bien.

Pero lo dicho: un supositorio.

El cambio que tuve que hacer en la configuración de pulseaudio fue mínimo: descomentar una línea y ya está. Pero para alguien que se acabe de instalar Ubuntu no sería tan fácil. Tendría que bucear entre los bugs de Ubuntu, saber qué es ALSA, saber qué es pulseaudio ... No sería fácil. En absoluto.

Y lo de hoy fue la guinda. Me di cuenta de que no me funcionaba la entrada de línea. Ahí es donde enchufo la salida del multiefectos de la guitarra, con lo que si no hay entrada de línea, no hay sonido de guitarra. Pensé que sería cuestión de jugar un poco con alsamixer, como otras veces que he actualizado el kernel. Pero no: a pesar de que los volúmenes estaban bien, y de que en el monitor de pulseaudio se veía que había sonido en la entrada de línea, no se oía nada de lo que entraba por ahí.

La primera búsqueda de Google me llevó a probar a indicar un parámetro model para el módulo snd-hda-intel, según esta lista. Ya lo había probado hacía tiempo cuando tuve otros problemas con la tarjeta de sonido, y aunque entonces lo arregló, ahora no hubo suerte. De hecho, el problema que tenía entonces era el mismo que el de ahora, y un par de búsquedas más me hicieron recordar qué era lo que había tenido que hacer: activar el analog loopback de la tarjeta, uno de los "switches" de alsamixer.

Que no aparecía por ningún lado.

Seguí buscando y vi que a otra gente le había pasado lo mismo: el control de analog loopback había desaparecido. En ese bug se indicaba una entrada del changelog de ALSA en el que se decía que, como daba muchos problemas, lo habían quitado por defecto. Ahora se podía activar con el hint "loopback = yes".

Por supuesto, ni idea de a qué se refería con lo de "hint", ni cómo aplicarlo.

En el bug no lo explicaban. Siempre se agradece que te digan parte de la solución a tu problema para que puedas probarte a ti mismo encontrando el resto. Eso curte. Crea carácter. Distingue a los hombres de los niños. Si yo estuviera probando Ubuntu, al llegar aquí hubiera tirado el ratón por la ventana en un ataque de frustración y hubiera instalado Windows.

Media hora y varias búsquedas en Google más tarde, encontré un documento llamado "More notes on HD-Audio driver" que está en los fuentes de ALSA. Este pequeño fichero de 16 páginas de amena documentación técnica, en texto plano, es lo que cualquier usuario medio podría leer y comprender en un momento para hacer troubleshooting de sus problemas de sonido. Si "usuario medio" implica varios años de experiencia con Linux, claro.

En la sección "HD-Audio Reconfiguration" explica que el módulo snd-hda-intel se puede reconfigurar en caliente usando los ficheros de /sys. En este punto es necesario incluir el texto original, para gozarlo en toda su gloria:

The following sysfs
files are available under each codec-hwdep device directory (e.g. 
/sys/class/sound/hwC0D0):

vendor_id::
  Shows the 32bit codec vendor-id hex number.  You can change the
  vendor-id value by writing to this file.
subsystem_id::
  Shows the 32bit codec subsystem-id hex number.  You can change the
  subsystem-id value by writing to this file.
revision_id::
  Shows the 32bit codec revision-id hex number.  You can change the
  revision-id value by writing to this file.
afg::
  Shows the AFG ID.  This is read-only.
mfg::
  Shows the MFG ID.  This is read-only.
name::
  Shows the codec name string.  Can be changed by writing to this
  file.
modelname::
  Shows the currently set `model` option.  Can be changed by writing
  to this file.
init_verbs::
  The extra verbs to execute at initialization.  You can add a verb by
  writing to this file.  Pass three numbers: nid, verb and parameter
  (separated with a space).
hints::
  Shows / stores hint strings for codec parsers for any use.
  Its format is `key = value`.  For example, passing `hp_detect = yes`
  to IDT/STAC codec parser will result in the disablement of the
  headphone detection.
init_pin_configs::
  Shows the initial pin default config values set by BIOS.
driver_pin_configs::
  Shows the pin default values set by the codec parser explicitly.
  This doesn't show all pin values but only the changed values by
  the parser.  That is, if the parser doesn't change the pin default
  config values by itself, this will contain nothing.
user_pin_configs::
  Shows the pin default config values to override the BIOS setup.
  Writing this (with two numbers, NID and value) appends the new
  value.  The given will be used instead of the initial BIOS value at
  the next reconfiguration time.  Note that this config will override
  even the driver pin configs, too.
reconfig::
  Triggers the codec re-configuration.  When any value is written to
  this file, the driver re-initialize and parses the codec tree
  again.  All the changes done by the sysfs entries above are taken
  into account.
clear::
  Resets the codec, removes the mixer elements and PCM stuff of the
  specified codec, and clear all init verbs and hints.

Pero ahí estaba: el fichero hints, que es a lo que se referían en el changelog. Supuse entonces que lo que había que hacer era añadir loopback = yes a ese fichero, tal que así:

echo "loopback = yes" > /sys/class/sound/hwC0D0/hints

Y luego, reconfigurar la tarjeta:

echo 1 > /sys/class/sound/hwC0D0/reconfig

Con eso ya aparecía el control de analog loopback en alsamixer, y ya funcionaba el sonido de la entrada de línea.

¡Jo, qué fácil era!

Si es que al final uno se da cuenta de que no es que Linux sea difícil: es sólo que no se ha parado a buscar durante hora y media entre bugs, posts de foros y documentación técnica. Cualquiera podría hacerlo.

Creo que éste tampoco será el año de Linux en el escritorio.

PS: y por encima, un bot me ha llenado de spam varias de las entradas del weblog. Ya ni del capcha se puede fiar uno.

¿Quién teme a la Ubuntu feroz?

Mucha gente del mundo Debian dice que Ubuntu va a acabar con la distribución. Que la corrompe, que la prostituye, etc etc. Pero no es así. De hecho, estos días he visto una noticia que significa más bien lo contrario: Google publica una preview de Chrome para Linux, y las distribuciones soportadas son ... Ubuntu y Debian. ¿Dónde están Red Hat y Suse? ¿Y las otras distribuciones basadas en Debian (Xandros, por ejemplo, famosa por venir con los Eee PC)?

Me parece que el soporte de Chrome para Debian es un efecto colateral del soporte de Ubuntu. Ubuntu es tan popular que no puede ser ignorada. Y Debian, como mamá de Ubuntu, se beneficia.

A todos los que les guste Debian debería gustarles Ubuntu. Es el triunfo de la filosofía Debian, envuelta para regalo. Es la prueba fehaciente de que los cimientos de la distribución están tan bien hechos que pueden soportar una distribución para servidor y una distribución para escritorio que haga más viable eso de "dominar el mundo" que dijo Linus hace tanto tiempo.

Así que si tenemos Google Chrome para Debian, es gracias a Ubuntu. Y si permitir a los "debianitas" usar el latest and greatest software es la forma en la que Ubuntu va a acabar con Debian ... no sé. Se me ocurren peores formas de morir.

 

Frustraciones del "tuning" de escritorio

No sé si les habrá pasado lo mismo: un día, por probar, arrancan una sesión con otro escritorio distinto al que usaban. XFCE en lugar de Gnome, Gnome en lugar de XFCE, KDE en lugar de LXDE, lo que sea. No les gusta, y vuelven al de siempre. Y entonces se dan cuenta de que hay cosas que han cambiado: los tipos de letra no se ven igual y los temas de GTK/Gnome no funcionan, o funcionan a medias.

A mí me cabrea mucho (me cabrean mucho muchas cosas, que conste; es un problema que tengo). Y como pensé que habrá gente a la que también le cabree, les voy a contar de forma muy breve cómo arreglarlo. Los dos temas van por separado: tipografías por un lado, aspecto de GTK por otro.

Lo de las tipografías en Linux es una historia complicada. Uno de los protagonistas es un software llamado fontconfig. A grosso modo, controla cómo se ven las fuentes en la pantalla. Es el que tenemos que tocar para, por ejemplo, configurar el antialiasing de las letras.

No sé cómo hace Gnome para guardar la configuración de tipografías. Yo toqueteo un poco el asistente hasta que encuentro una configuración que me gusta (que viene siendo antialiasing con LCD subpixel, y luego suavizado a nivel "Leve", o "Ligero", según la traducción). Anteayer probé un momento KDE 4.1, a ver si se había redimido de sus pecados; y como no era así, volví a Gnome (que conste que antes tenía XFCE, pero eso es otro tema). Y las tipografías estaban todas mal. El antialising era distinto. Fui inmediatamente al asistente de Gnome para ver qué había cambiado. Nada: todo seguía igual, pero aquello se veía ... mal (hacen falta años y mala baba para entender la importancia de estas tonterías). Probé a cambiar todo lo cambiable y vi que apenas se notaba diferencia. Horror.

Entonces recordé algo: el fichero ~/.fonts.conf. fontconfig toma la configuración de varios sitios: primero la configuración general de /etc, luego la configuración de usuario. Y esa configuración está en el fichero ~/.fonts.conf. Comprobé que tenía ese fichero, y mirando el contenido vi que podría tener que ver con las diferencias que notaba (había un hinting = full en un sitio que era sospechoso). En otros tiempos hubiera buscado en Internet cómo funcionaba, pero voy viejo y me hago cómodo. Eliminé el fichero y santas pascuas. Al volver al asistente de Gnome para las tipografías, todo volvió a funcionar. Una cosa solucionada.

Después estaba el tema del tema (ríanse, es un chiste). Quería cambiar el aspecto del tema en Gnome, y sólo cambiaban algunas cosas. Esto lo lleva GTK, y cómo no, también tiene un fichero de configuración de usuario: ~/.gtkrc-2.0 (si tienen un fichero llamado ~/.gtkrc-1.2, son ustedes miembros de la vieja guardia o llevan demasiado tiempo sin actualizar su distribución). De paso descubrí que los bookmarks del navegador de ficheros de GTK (el que se lanza cuando le dan a "Abrir" o "Guardar como" en aplicaciones GTK) se guardan en ~/.gtk-bookmarks. Cosas de escribir ~/.gtk y pulsar "Tab".

Para abreviar, apliqué la misma receta a este fichero que al de fontconfig, y volví al asistente. Todo correcto. Mucho mejor.

Aparte de estos comportamientos extraños que achaco a que XFCE, KDE y Gnome usan formas ligeramente diferentes de guardar los settings, una cosa que siempre me ha molestado mucho de Gnome es que por defecto sólo te permite configurar unos pocos atajos de teclado. Por ejemplo: sólo trae dos escritorios virtuales por defecto, y por lo tanto, sólo trae atajos de teclado para cambiar entre dos escritorios. Increíble. Muy pocas cosas tiene en pantalla esta gente si les llegan dos escritorios. Otra: no hay ningún atajo de teclado para lanzar un terminal, hay que irse al menú o crear un lanzador en la barra. Gnome debe de estar hecho para gente que no usa el teclado, o algo así. No sé.

Para cambiar algunas de estas cosas se puede ir al asistente de Gnome, pero para otras hay que tirar de una utilidad llamada gconf-editor. ¿Recuerdan todo lo que, años ha, criticábamos de Windows porque tenía un "registro" en el que estaba gran parte de la configuración, que tiene un interfaz ridículamente complejo y que de vez en cuando se corrompe y obliga a configurar todo otra vez? Pues GConf es lo mismo, pero en Linux. Miren cuántas cosas buenas aprendemos de Windows.

Con gconf-editor se pueden cambiar los atajos de teclado de Metacity, el window manager que usa Gnome. No hay capturador de keystrokes, hay que introducir la combinación a mano (por ejemplo, "<Control>F5"). La tecla Windows es "<Super>", por si se lo preguntaban. Para definir un atajo que lance una aplicación primero hay que definir el atajo para run_command_1, y luego, en otra parte, definir lo que hace ese run_command_1. Todo muy user friendly, como pueden ver.

En fin. Ya me he desahogado por hoy. Para compensar, me apunto contarles otro día las grandezas de Ardour. Vayan mirando para abrir boca.

Una nueva generación de Open Source

Zimbra. SugarCRM. Alfresco. Funambol. Hyperic HQ. Openbravo. Incluso Websphere, de IBM. ¿Qué tienen en común todas estas aplicaciones? Todas son lo que se ha llamado Commercial Open Source: open source sí, pero a vaquiña polo que vale.

Syndicate content