Lo hice y lo entendí

Tengo la costumbre de recompilarme un kernel a medida en todos los Linux que instalo para mí. En parte es costumbre de hace muchos años de cuando en cada nueva versión aparecían increíbles novedades y una gran cantidad dispositivos soportados nuevos. Ahora ya no es necesario, y con el kernel que traen por defecto casi todas las ditribuciones te puedes apañar muy bien.

Sin embargo, suele ser necesario tener el kernel recompilado para añadir drivers no oficiales, parches y todas esas aplicaciones que necesitan compilarse un módulo del kernel para trabajar, y estoy pensando, por ejemplo, en el parche del bootsplash, en el driver binario de NVidia, en el kqemu, en los módulos del VMWare, en el driver para mi WebCam o para mi tarjeta WiFi.

Pues bien, hace poco tuve que pasar del kernel 2.6.19 al 2.6.20.6 tras una amable sugerencia de mi querido NTFS-3G al que yo no osé contradecir:

Why do I get “WARNING: Deficient FUSE kernel module detected”?

The FUSE technology used by ntfs-3g consists of two major parts: a library and a Linux kernel driver. The message means that you either have the faulty FUSE 2.6.2 release, or the library (FUSE package) is safe but the kernel driver is not. When you install or upgrade the FUSE package then it installs only the library, not the kernel driver. In other words, ntfs-3g and FUSE is safe but not your kernel.

Solution: Please ask your distribution developers to fix the Linux kernel problem. The Linux kernel must be upgraded either to at least version 2.6.20, or the FUSE kernel driver must be upgraded to a safe version which is also included in the FUSE package for Linux kernel version 2.6.9 and later.

Sigue leyendo »

Linux is about choice: Linux va de poder elegir libremente entre múltiples alternativas para hacer lo mismo… Necesitas un servidor de correo y tienes el sendmail, el qmail, el exim,…, necesitas un editor de textos y tienes el vi, el emacs, el joe, el nano,…, necesitas un escritorio y tienes GNOME, KDE, Xfce,…, necesitas una distribución de Linux y tienes Fedora, Suse, Debian, Ubuntu, Gentoo…. Aunque tanta posibilidad de elección es lo maravilloso del software libre para muchos, para otros muchos, es lo malo, ya que la diversidad genera dispersión de usuarios y que se reduzca el know-how de determinadas aplicaciones.

No es fácil decir si de la diversidad nacen los flames (como Red Hat vs Suse, Debian vs Ubuntu vs Gentoo, KDE vs GNOME, vi vs emacs, Linux vs ***BSD) porque los usuarios de un producto realmente quieren que los usuarios del contrario se pasen a usar el suyo o para demostrar su superioridad ante los que usan el otro o por qué, pero ciertamente, aparecer, aparecen… Y realmente, parece que está demostrado que no es posible convencer a nadie en este tipo de discusiones.

Dicho esto, yo tenía curiosidad por saber qué distribuciones y escritorios usaban los famosos de este mundillo… no por generar nuevas discusiones, sino pura curiosadad por saberlo y por ver si podía encontrarlo buceando por Internet. Ha sido muy difícil en la mayoría de los casos y los resultados no son siempre ni lo satisfactorios, ni lo recientes, ni lo exactos que desearía, pero en cualquier caso, aquí están, con las fuentes de la información incluidas en los enlaces…

Sigue leyendo »

El nohup es un comando de los históricos de UNIX. Cuando en un terminal físico (terminal serie), virtual (xterm, konsole, putty, telnet, ssh, etc.), o en la consola cerramos la sesión (cerrando la ventana si estamos en un entorno gráfico, con el comando exit, o pulsando Control+D en la shell), el proceso que gestiona dicho terminal (getty, mgetty, sshd, telnetd, etc.) manda una señal SIGHUP a los procesos que cuelgan bajo ellos, normalmente, la shell, y en Linux, típicamente bash. Tal y como podemos leer en la página de man de bash, la shell, a su vez, manda dicha señal a todos los procesos que cuelgan bajo ella y, de hecho, incluso los despierta si están parados:

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell
resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to
ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a
particular job, it should be removed from the jobs table with the disown builtin (see
SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

Ante la señal SIGHUP normalmente todos los procesos reaccionan simplemente saliendo, lo cual es un problema si queremos que nuestro programa siga ejecutándose en el sistema una vez que hayamos dejado la shell. Para evitar que esto ocurra, tradicionalmente se ha usado el comando nohup. Adicionalmente, el bash, desde la versión 2.0, también tiene el comando interno disown como podemos leer en el párrafo anterior.

Sigue leyendo »

Recientemente un familar muy cercano se ha comprado un flamante portátil HP Pavilion dw9286ea. Es, y será durante unos meses, un ordenador impresionante, con Intel® Core™ 2 Duo T5600, 2GB de RAM, dos discos de 120Gb, NVIDIA® GeForce™ Go 7600 con 512Mb de memoria dedicados, pantalla BrightView de 17″ y para redondear, sintonizador de DVB-T y mando a distancia.

Viene con Windows Vista, y aunque el Knoppix va de maravilla en él, su propietario prefiere tener Windows XP, ya que los programas de CAD no van bien en Vista ni en términos de rendimiento ni en términos de compatibilidad. En cualquier caso, aunque no usara CAD yo apoyaría la decisión, ya que el Windows Vista parece un sistema operativo mucho más bloated que el veterano XP. Y de cualquier forma, parecería conveniente esperar a que el SP1 apareciera antes de que acabe el 2007.

Sigue leyendo »

Estaba intentando hacer un CGI muy sencillo usando bash (como lo que quería hacer era algo muy específico de bash, no he querido usar ni Perl, ni PHP). La única dificultad que he encontrado ha sido obtener las distintas variables que el método GET pasa al CGI a través de la variable $QUERY_STRING, que normalmente tiene este aspecto:

QUERY_STRING='parametro1=valor1&parametro2=valor2&parametro3=valor3'

Estaba yo ya comenzando a darle vueltas a una Expresión Regular para interpretar dicha salida cuando he decidido buscar en Google para ver si alguien tenía una solución más completa que la que yo ya tenía a medias. He llegado al artículo CGI Scripting Tips for Bash or SH que propone lo siguiente para extraer del QUERY_STRING la variable que nos interese:

PARAMETROX=`echo "$QUERY_STRING" | grep -oE "(^|[?&])parametrox=[^&]+” | sed “s/%20/ /g” | cut -f 2 -d “=”`

Y es que con bash y sus compañeros sed, awk, cat, grep, etc. aún se puede hacer casi de todo, incluso un weblog o un servidor web. Como las Expresiones Regulares son tan excepcionalmente útiles como complicadas a la hora de usarlas, me he decidido a comentar algunos ejemplos, comenzando por el que me ha llevado a este artículo.

Sigue leyendo »

Todos los ficheros y directorios en un sistema UNIX tienen asociado un número compuesto de cuatro cifras en octal. Los tres dígitos menos significativos (least significant digit) especifican los permisos que tienen los usuarios sobre ese fichero (lectura (r), escritura (w) y ejecución (x) para el usuario, los usuarios pertenecientes al grupo o para otros):

sst rwx rwx rwx
421 421 421 421
S   U   G   O

S=SUID, SGID y Sticky Bit
U=Usuario
G=Grupo
O=Otros

Esto forma parte de los conocimientos básicos y mínimos de cualquier usuario de UNIX y podemos leer sobre ello en Permisos de ficheros del manual Seguridad en UNIX y Redes. También es muy conocida la existencia de los bits SUID y SGID, formados por los dos bits más significativos del octal más significativo. Aplicados sobre un fichero ejecutable, permiten que el programa se ejecute como si lo hiciera el usuario propietario (SUID) o el grupo propietario(SGID) del fichero.

Pero el propósito de esta entrada es resaltar la curiosidad, bastante menos conocida, de aplicar el bit menos significativo de la cifra octal más significativa (el que en el esquema anterior he marcado con una t), el Sticky Bit, a un directorio (aplicado a un fichero no se usa para nada en la gran mayoría de los UNIX modernos). En el man del chmod leemos:

Sigue leyendo »

En el pasado a menudo he tenido problemas con los acentos y las eñes al montar particiones FAT o NTFS o al montar o compartir directorios usando Samba. Esto ocurre porque GNU/Linux usa distintos juegos de caracteres que Windows y DOS. En esta entrada vamos a tratar de aclarar todos los aspectos que pueden impedirnos disfrutar de nuestra apreciadas eñes cuando nos enfrentamos con ficheros cuyo origen o destino sea un sistema operativo de Microsoft.

Existe una multitud de juegos de caracteres. Podemos ver muchos de ellos en popular character encodings . Allí vemos el Windows-1252, el CP850, el ISO 8859-1 (Latin 1), el ISO 8859-15 (Latin 9) o el Unicode (con su sistema de codificación de longitud variable más típico, el UTF-8) , que son los que más nos interesan para el asunto que nos ocupa aquí en España. En el artículo de la WikiPedia Western Latin character sets tenemos una tabla mostrándonos las diferencias entre estos juegos de caracteres.

Antes de poner manos a la obra, es conveniente que verifiquemos que el bash nos muestra correctamente acentos, eñes y si acaso, el símbolo del euro € escribiendo en un terminal áéíóúÁÉÍÓÚñÑ€. Si no salen bien, puede ser por dos motivos principalmente:

1. El bash no está correctamente configurado para mostrar acentos. Esto ocurría bastante hace unos años, y era necesario hacer todo tipo de ajustes. Sin embargo, en las distribuciones actuales normalmente no es necesario hacer nada.
2. La fuente usada en el terminal que estamos usando (Consola de Linux, Putty, Konsole, GNOME Terminal, etc.) no lleva acentos o no están correctamente mapeados.

Sigue leyendo »