$ ssh usuario.dominio@sistema
The authenticity of host 'sistema (10.22.31.45)' can't be established.
RSA key fingerprint is 7d:2f:1e:69:21:e9:06:f3:d9:fd:36:0a:9e:6c:47:10.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Actualización 5/7/2010: Como en el ejemplo anterior, en todos los ejemplos que siguen veremos que el comando ssh no nos pregunta la contraseña porque hemos configurado Autentificación trasparente por clave pública/privada con OpenSSH.

Dicha clave se almacena en el fichero $HOME/.ssh/know_hosts:

$ tail -1 known_hosts
sistema.dominio,10.22.31.45 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAng/LUBaJa0qATdMMkmB3ufytR/BauKbCyz+Dvg0NMPUE2EF6zy5o3zSVMRlrgUmKakA3DoUez5oOaaSlR4d5ZZjOfsBmnn5dp7M0QtY681HYny1QQFUpRxNbARP3X8+2jlnWjOEBOmk+N8pRJCURUwkjSMs81ThAiZoIv8sVYYbNzKDpL8RaDTqEN0Xn+1dHJdeLrt+Hsl6GzX8f+SoWwkNVmt8Nc8T7vzrG93Xku6XXdOh5SKeTDXv+0shJUziPQApEwR0gcc+7L0hBEAw4GU1ctGnC22aVDkyqTKlbORq2YoufDErq+wv8lwgZKYd5AbOuvuwX7w9c8P+P+jKw==

Actualización 5/7/2010: Que aparezca el nombre de los hosts en claro en el fichero known_hosts es un problema de seguridad, ya que permite a un atacante que haya conseguido acceder a nuestro sistema conocer fácilmente otras máquinas que pueden ser objeto de ataque. Para evitar el problema, desde OpenSSH 4.0, es posible ofuscar el nombre de la máquina en el known_hosts con un hash. Sólo es necesario usar la opción “HashKnownHosts yes” en /etc/ssh_config o en $HOME/.ssh/config y ejecutar “ssh-keygen -H” para ofuscar el nombre de los hosts en nuestro known_hosts actual: Hashing the OpenSSH known_hosts File. Algunas distribuciones de Linux ya están implementando esto por defecto.

Si la máquina remota es víctima de algún tipo de ataque, si se ha reinstalado, si se ha sustituido por otra máquina con la misma IP o si, por cualquier motivo, la máquina remota no manda la clave de host que corresponde con la que tenemos almacenada, la próxima vez que intentemos conectarnos a ella, obtendremos un error como el siguiente:

$ ssh usuario@sistema.dominio
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
77:8b:3f:5c:95:18:30:2b:83:fe:21:73:d2:16:85:64.
Please contact your system administrator.
Add correct host key in /home/usuario/.ssh/known_hosts to get rid of this message.
Offending key in /home/usuario/.ssh/known_hosts:2
RSA host key for sistema.dominio has changed and you have requested strict checking.
Host key verification failed.

Y no podremos volver a conectarnos a menos que eliminemos la entrada vieja del known_hosts y volvamos a intentarlo. En dicho caso, volverá a pedirnos que aceptemos la nueva clave remota del host remoto, como al principio.

Si tenemos algún proceso no interactivo que se base en SSH, el que nos pregunte si aceptamos la clave del host remoto es un problema importante. En dichos casos, podemos evitar que nos lo pregunte y hacer que el ssh local la acepte siempre automáticamente poniendo el siguiente parámetro en el /etc/ssh_config (para todos los usuarios) o en el $HOME/.ssh/config (sólo para el usuario actual):

StrictHostKeyChecking no

Tras ponerlo comprobaremos que, efectivamente, la clave del host remoto se añade automáticamente al known_hosts la primera vez que accedemos a un nodo sin preguntar:

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Pero esto puede no ser suficiente. Hay veces en las que la clave del host remoto siempre o muy a menudo cambia. Por ejemplo, puede ocurrir cuando hacemos un “ssh localhost” tras crear algún tipo de túnel que cada vez acabe en una máquina diferente (Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH) o cuando trabajamos con multitud de máquinas físicas o virtuales (con éstas pasa especialmente a menudo) en las que reutilizamos frecuentemente la IP de unas máquinas en otras, etc.

Que la clave del host cambie frecuentemente es una simple molestia en sesiones interactivas (que nos obliga a buscar y a eliminar la entrada correspondiente del known_hosts), pero un auténtico problema cuando queremos usar ssh de forma no interactiva. En dichos casos, podemos solucionarlo usando el “StrictHostKeyChecking no” como antes, pero además, añadiendo ahora “UserKnownHostsFile /dev/null” en el $HOME/.ssh/config (no parece conveniente usarlo en el /etc/ssh_config y que aplique a todos los usuarios) para indicarle al comando ssh que en lugar de usar $HOME/.ssh/known_hosts para almacenar las claves de hosts, queremos usar /dev/null:

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Así conseguimos que, como las claves en realidad no se guardan, siempre que nos conectemos a una máquina se acepte automáticamente su clave de host, haya cambiado o no haya cambiado:

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$ exit

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Sobra decir que estas opciones suponen la eliminación de una medida de seguridad base del sistema SSH, con lo que se está más expuesto a posibles ataques.

:wq

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Cygwin, GNU/Linux, OpenSSH, UNIX

Feed enhanced by Better Feed from Ozh

Para gustos, los colores. Pero en mi opinión, que ésa sea la ordenación por defecto es muy inconveniente en un cliente de correo en el que normalmente quieres tener siempre los últimos correos a la vista. Por supuesto, es tan fácil cambiar el orden como hacer click sobre el título de la columna, una operación muy típica. Además, Thunderbird recuerda la última ordenación que hemos elegido individualmente para cada carpeta para la próxima vez que arranquemos la aplicación. Sin embargo, será necesario hacerlo para cada nueva carpeta que creemos cuando, tras haber copiado algunos correos, nos demos cuenta de que no están como esperábamos.

Ya había intentado alguna vez investigar si era posible cambiar este comportamiento sin éxito, pero hace poco, tras migrar a Thunderbird 3, lo volví a intentar y ¡bingo!, di con la solución en forma de bug de Thunderbird y de interesante discusión al respecto: Bug 86845 – Sort order for mail/news not configurable by default (back-end part)

(...)

Leer el resto de Cambiar la ordenación por defecto de elementos en Thunderbird (577 palabras)

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Thunderbird

Feed enhanced by Better Feed from Ozh

En Sobre las VIA EPIA (II): Mi ordenador basado en una SP8000E mostré el sistema basado en una VIA EPIA que monté como teórica solución para todo: Reproductor multimedia, decodificador/grabador de TDT, servidor doméstico, punto de acceso a Internet desde el salón, etc.

Sin embargo, más de dos años después, veo que como servidor doméstico y como punto de acceso a Internet lo he usado muchísimo. Como decodificador/grabador de TDT lo he usado muy poco, pero sólo porque realmente no veo la TDT ni siento necesidad de grabar nada de ella. Y como reproductor multimedia también muy poco, sólo para formatos raros que no funcionaban en el reproductor de DVD. La razón es sencillamente que la calidad de su salida S-Video es muy inferior a la de la señal RGB del SCART de cualquier reproductor de DVDs.

Ya comenté algo sobre las señales que transporta el Euroconector/SCART y la importante mejora de calidad de la señal RGB en ¿Por qué obtenemos una imagen en blanco y negro al usar un adaptador de S-Video a Euroconector?, pero conviene recalcarlo, puesto que mucha gente no sabe que el Euroconector soporta transmitir dos tipos de señales de vídeo, S-Video y RGB, siendo el segundo tipo muy superior al primero en nitidez y calidad de los colores. En la mayoría de reproductores de DVD podemos elegir (como se veía en la entrada sugerida) si el Euroconector debe enviar señal RGB o señal YUV (la que se usa en S-Video y en el vídeo compuesto). Sin embargo, no todos los televisores aceptan la señal RGB. Incluso en televisores que la aceptan, puede que sólo lo hagan en algunos de los Euroconectores (en televisores Sony marcados con 3 puntitos).

Por eso, un HTPC silencioso, de bajo consumo y con una caja adecuada (como los que configura el Tendero Digital) será, en la mayoría de los casos, la solución ideal para el salón siempre y cuando el televisor sea una pantalla plana con conectores VGA, HDMI o DVI. Pero en el caso de seguir usando una televisión de tubo, como es mi caso (y sin ánimo de cambiarla de momento, que ya expresé en La resolución 1366×768 mi preferencia por las pantallas de tubo para contenidos de definición estándar), no hay ningún PC (o al menos no es fácil de encontrar) con salida SCART/RGB que envíe señal de definición estándar y de alta calidad al televisor.

Por tanto, era imprescindible que el disco multimedia tuviera Euroconector con capacidad de enviar señal RGB. Esto no resulta tan fácil, puesto que muchos de los discos actuales te permiten conectarlos a un televisor usando un cable de Euroconector pero sólo a través de la salida de vídeo compuesto y usando un adaptador:

Otros discos sí que llevan Euroconector pero no indican ni en la caja ni en la documentación si éste es capaz de enviar señal RGB, que no todos lo hacen. Finalmente, otros sí que lo especifican claramente, a veces incluso en la caja y otras veces sólo en las especificaciones.

Tras una intensa búsqueda, estos modelos con LAN y SCART/RGB me parecieron interesantes:

• Woxter i-Cube X-Div 35 XP Rec, que no soporta MKV. El modelo que sí lo soporta es el Woxter i-Cube 750 MKV, pero en éste el Euroconector no parece que pueda sacar señal RGB, o al menos el manual no lo menciona.
• Storex AivX-385HDRW, que soporta MKV usando un PC con Windows como servidor de transcodificación.
• o2media HMR-600W, con TDT.

Pero luego en los foros todos tenían sus pegas: que si tarda mucho en abrir los directorios, que si no se puede copiar de la red y reproducir al mismo tiempo, que si a veces se cuelga, que si se calienta…

Hasta que leyendo referencias en algún foro encontré que alguien decía algo así como: ¿Pero para qué queréis un disco duro multimedia existiendo la Playstation 3? Indagué un poco la nueva pista y descubrí que la Playstation 3 parecía ser una opción mucho mejor que cualquier disco duro multimedia. Sobre todo, porque tras el reciente anuncio (18 de Agosto) de la Playstation 3 Slim (con 120GB o 250GB de disco), que ha salido al precio de 299€, el modelo anterior de 80GB se encuentra en tiendas hasta por 259€. Viendo que ninguno de los discos multimedia mencionados anteriormente baja de unos 240€, es cuando empezamos a ver la conveniencia de una PS3. Y cuando te enteras de que la nueva PS3 Slim no permite la instalación de Linux como todos los modelos anteriores es cuando te planteas definitivamente si no es el momento ideal de hacerte con una PS3 de 80GB de las que permite instalar Linux antes de que desaparezcan de las estanterías de las tiendas.

Pero comparar la PS3 con un disco duro multimedia no es comparar peras con peras y manzanas con manzanas, ya que no son exactamente el mismo producto:

• El disco interno de la PS3 (80GB) es mucho más pequeño que el de los discos duros multimedia (500GB, 1TB, 1.5TB)
• La PS3 no se puede mover y transportar tan fácilmente como un disco duro multimedia
• La PS3 tiene lector de Blu-Ray, por lo que podemos leer DVDs y CDs también
• La PS3 también nos sirve para jugar y si instalamos Linux sus posibilidades se multiplican
• La PS3 no se puede usar simplemente como disco duro externo USB de gran capacidad

Sin embargo, si sólo buscas un reproductor multimedia con disco integrado para el salón con SCART/RGB y red, como es mi caso, la PS3 parece una mucho mejor opción, así que acabé por comprar una Playstation clásica de 80GB.

Y tras unas semanas de uso, éstas son las peculiaridades que me parece interesante comentar de la PS3 como reproductor multimedia:

• SCART/RGB
• Formatos de vídeo soportados
  • Problemas con ficheros de vídeo con el audio en AC3
  • Soporte de subtítulos
  • MKV
• Mando a distancia
• Media Servers
• Almacenamiento, copia de contenidos a través de la red
• Linux en la PS3
  • Prestaciones
  • Conmutar entre PSUbuntu y XMB
  • Resoluciones de vídeo disponibles
  • Memoria RSX como swap
• Comentarios finales

(...)

Leer el resto de Comentarios sobre la Playstation 3 como reproductor multimedia para una televisión de tubo y sobre GNU/Linux en la Playstation 3 (5,326 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 29 comentarios
Etiquetas: FAT, GNU/Linux, MKV, Playstation 3, S-Video, SCART, Televisión

Feed enhanced by Better Feed from Ozh

Para conseguir tal cosa, apenas es necesario descomentar unas líneas de la configuración por defecto de Samba en Debian y Ubuntu (/etc/samba/smb.conf) y releer la configuración (sudo /etc/init.d/samba reload):

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares.  This will share each
# user's home directory as \\server\username
[homes]
   comment = Home Directories
   browseable = no

Normalmente un usuario tiene en su $HOME todos los ficheros que pueda necesitar, pero en los PC a menudo tenemos otros sistemas de ficheros (unidades externas, particiones grandes que se comparten entre sistemas operativos, etc.) en los que los usuarios guardan otros ficheros. Por ejemplo, yo tengo unas particiones adicionales que suelo montar en /mnt/e y en /mnt/i con los permisos adecuados para que los usuarios puedan escribir en ellas. En el $HOME de los usuario tengo unos enlaces simbólicos a estos sistemas de ficheros:

vicente@servidorcifs ~ $ pwd
/home/vicente

vicente@servidorcifs ~ $ ll e i
lrwxrwxrwx 1 vicente vicente 7 2008-04-30 20:51 e -> /mnt/e/
lrwxrwxrwx 1 vicente vicente 7 2008-07-17 15:11 i -> /mnt/i/

Pues bien, ¿qué diríais que pasa cuando monto //servidorcifs/vicente/ desde otro sistema e intento acceder a //servidorcifs/vicente/e/ o a //servidorcifs/vicente/i/?

Pues que si intento acceder desde Windows, los enlaces e, i aparecerán como un directorio más al que puedo acceder y en donde encuentro los ficheros de /mnt/e/, /mnt/i/ que hay en la máquina. Este es el comportamiento deseado en este caso.

Sin embargo, si intento acceder desde otro Linux (con una versión reciente de Samba), tras montar el sistema de ficheros remoto:

vicente@clientecifs ~ $ sudo mount -t cifs -o username=vicente //servidorcifs/vicente /mnt/smb/

lo que ocurrirá es que en la máquina donde hemos montado el sistema de ficheros CIFS, los enlaces simbólicos e, i se verán como lo que son, enlaces simbólicos, y apuntarán a los directorios /mnt/e/, /mnt/i/ del cliente de CIFS, no del servidor de CIFS, con lo cual no tendremos acceso a los ficheros del usuario:

vicente@clientecifs ~ $ ll /mnt/smb/e /mnt/smb/i
lrwxrwxrwx 1 vicente vicente 7 2008-04-30 20:51 /mnt/smb/e -> /mnt/e/
lrwxrwxrwx 1 vicente vicente 7 2008-07-17 15:11 /mnt/smb/i -> /mnt/i/

vicente@clientecifs ~ $ cd /mnt/smb/e
-bash: cd: /mnt/smb/e: No such file or directory

(...)

Leer el resto de Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (1,033 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 7 comentarios
Etiquetas: GNU/Linux, Kernel, Samba, UNIX, Windows

Feed enhanced by Better Feed from Ozh

Sin embargo, en aquella entrada nos dejamos en el tintero el reenvío dinámico de puertos y varios lectores lo echaron de menos, de modo que esta entrada tratará de complementar a aquélla (muchas gracias a todos por la sugerencia).

Cuando hablamos de hacer dynamic port forwarding con SSH, de lo que estamos hablando exactamente es de convertir el SSH en un servidor SOCKS. ¿Y qué es un servidor SOCKS?

¿Sabes para qué sirve un proxy web? Probablemente sí, muchas empresas usan uno. Se trata de un sistema directamente conectado a Internet que permite que los clientes de una intranet sin acceso a Internet puedan navegar por la web si configuran sus navegadores para que hagan sus peticiones a través del proxy (aunque también hay proxies transparentes). Un proxy web, además de permitir la salida a Internet, también cacheará las páginas, imágenes, etc. ya descargadas por algún cliente para no tener que descargarlas para otro cliente. Además, permite filtrar los contenidos y monitorizar la actividad de los usuarios. Sin embargo, su función básica es la de reenviar tráfico HTTP y HTTPS.

Un servidor SOCKS le daría un servicio similar a la intranet de una empresa que el que proporciona un servidor proxy pero no está limitado a HTTP/HTTPS, sino que permite reenviar cualquier trafico TCP/IP (con SOCKS 5 también UDP).

Por ejemplo, imaginemos que queremos usar nuestro correo usando POP3 o ICMP y SMTP con Thunderbird desde una intranet sin acceso directo a Internet. Si sólo tenemos un proxy web disponible, la único sencillo que nos quedaría sería usar algún webmail (aunque si es un webmail también podríamos usar la extensión Webmail de Thunderbird). También podríamos aprovecharnos del proxy montándonos un túnel por HTTP. Pero lo más sencillo sería que la red tuviera un servidor SOCKS disponible que nos permitiera usar POP3, ICMP y SMTP a través de él sin ningún inconveniente.

(...)

Leer el resto de Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (974 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 5 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, SOCKS, Thunderbird, UNIX, wget, Windows

Feed enhanced by Better Feed from Ozh

Como este tema está muy tratado por toda la red:

• Wikipedia: SSH Tunneling
• O’Reilly: Using SSH Tunneling
• ssh.com: Tunneling Explained
• ssh.com: Port Forwarding
• SecurityFocus: SSH Port Forwarding
• Red Hat Magazine: SSH Port Forwarding

en esta entrada no entraremos en los detalles del reenvío de puertos, sino que pretende ser una chuleta, una referencia rápida (cheat sheet) de cómo reenviar puertos TCP con OpenSSH en los 8 diferentes escenarios que se pueden dar. Otros clientes de SSH como PuTTY también permiten el reenvío de puertos, pero la configuración se hará con un interfaz gráfico. Nosotros nos centraremos en OpenSSH.

En los siguientes ejemplos y situaciones supondremos que tenemos una red externa y una red interna y entre ambas redes, la única conexión posible es una conexión SSH entre el nodo de la red external externo1 y el nodo de la red interna interno1. El nodo externo2 está en la red externa y tiene conectividad total con externo1. El nodo interno2 está en la red interna y tiene conectividad total con interno1.

(...)

Leer el resto de Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (1,089 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 18 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, UNIX, VNC

Feed enhanced by Better Feed from Ozh

Teóricamente, el rsync sólo debería de sincronizar aquellos ficheros que han cambiado con respecto a la sincronización anterior. Sin embargo, yo detectaba que ciertos ficheros (no todos) siempre eran sincronizados, incluso aunque ejecutara el rsync dos veces seguidas.

Este comportamiento puede ser fácilmente reproducido. Creo 5 ficheros, esperando un segundo de tiempo entre la creación de uno y del siguiente (ese segundo de diferencia es clave en el asunto, en breve se verá por qué):

$ for i in 1 2 3 4 5; do echo test > fichero$i; sleep 1; done

$ ll
total 20
-rw-r--r-- 1 vicente vicente 5 2009-05-16 10:09 fichero1
-rw-r--r-- 1 vicente vicente 5 2009-05-16 10:09 fichero2
-rw-r--r-- 1 vicente vicente 5 2009-05-16 10:09 fichero3
-rw-r--r-- 1 vicente vicente 5 2009-05-16 10:09 fichero4
-rw-r--r-- 1 vicente vicente 5 2009-05-16 10:09 fichero5

Nota: Fijémonos en que en la salida de ls no se ven los segundos; volveremos sobre ello más adelante.

Sincronizo los ficheros en una memoria USB por primera vez:

$ rsync -av /tmp/prueba_rsync /media/disk/
sending incremental file list
prueba_rsync/
prueba_rsync/fichero1
prueba_rsync/fichero2
prueba_rsync/fichero3
prueba_rsync/fichero4
prueba_rsync/fichero5

sent 374 bytes  received 111 bytes  970.00 bytes/sec
total size is 25  speedup is 0.05

Y la segunda vez (y todas las siguientes) que lo intento tras desmontar y volver a montar la memoria USB, ¡me volverá a sincronizar varios de los ficheros!:

$ rsync -av /tmp/prueba_rsync /media/disk/
sending incremental file list
prueba_rsync/
prueba_rsync/fichero1
prueba_rsync/fichero3
prueba_rsync/fichero5

sent 284 bytes  received 79 bytes  242.00 bytes/sec
total size is 25  speedup is 0.07

La clave del problema está en que la memoria USB está formateada en FAT o FAT32 y tal y como leemos en rsync FAQ: rsync recopies the same files, FAT sólo almacena para el tiempo de modificación de los ficheros, valores pares para los segundos; es decir, la precisión máxima es de 2 segundos:

Another common cause involves sending files to an Microsoft filesystem: if the file’s modified time is an odd value but the receiving filesystem can only store even values, then rsync will re-transfer too many files. You can avoid this by specifying the –modify-window=1 option.

Aunque a mí me parece algo muy curioso en lo que no me había fijado nunca, en la entrada de la Wikipedia para el sistema de ficheros FAT: File Allocation Table sí que aparece documentado en la caja lateral de características:

Date resolution 2 s

(...)

Leer el resto de rsync siempre sincroniza ciertos ficheros. Ver los segundos de la fecha de un fichero. (607 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 21 comentarios
Etiquetas: CMD, Explorer, GNU/Linux, ls, rsync, Windows

Feed enhanced by Better Feed from Ozh

En esta entrada veremos cómo conseguir configurar nuestra distribución Debian o Ubuntu para conectarnos a una red WiFi encriptada con WEP o con WPA usando la línea de comandos. También veremos cómo modificar el fichero /etc/network/interfaces para que el sistema se conecte automáticamente a una red WiFi durante el arranque.

Para que no interfiera con mis pruebas, he deshabilitado el NetworkManager antes de comenzar con las mismas (lo que causará que nos desconectemos de las redes que éste gestione):

$ sudo /etc/init.d/NetworkManager stop

También he verificado si el demonio wpa_supplicant está corriendo en segundo plano y lo he matado con un simple kill. Hablaremos más adelante de este proceso.

(...)

Leer el resto de Configurar WEP y WPA en línea de comandos y en el arranque en Debian y Ubuntu (1,422 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Debian, GNU/Linux, seguridad, Ubuntu, WEP, WiFi, WPA

Feed enhanced by Better Feed from Ozh

Aunque hay soluciones parciales (Semisecure Login Reimagined), la solución definitiva, como siempre, pasa por usar HTTPS o, lo que es lo mismo, HTTP sobre SSL. Desde la versión 2.6, WordPress permite usar SSL fácilmente para el panel de administrador. Así que me puse a hacer pruebas para configurar SSL en mi servidor web.

Sin embargo, ocurre una cosa muy interesante con el protocolo SSL cuando se usa con HTTP: que no se pueden servir fácilmente múltiples sitios virtuales encriptados con SSL desde una misma IP.

En el contexto de los servidores web, hablamos de sitios virtuales (Apache Virtual Host documentation) cuando servimos páginas de diferentes dominios desde un único servidor, en muchos casos compartiendo la IP y en otros, cada dominio con una IP diferente, posiblemente con interfaces virtuales. Cuando usamos HTTP sin SSL, el servidor sabe qué página en concreto estamos solicitando porque el cliente HTTP (el navegador) lo indica en la cabecera Host:

GET /blog/ HTTP/1.1
Host: www.vicente-navarro.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Sin embargo, cuando se usa SSL, la negociación entre los extremos y la encriptación ocurre en una capa inferior, antes de que éstos comiencen a usar el protocolo HTTP. Por ello, no es trivial configurar diferentes certificados para diferentes sitios web virtuales. En la configuración típica, sólo podremos usar un certificado compartido para todas las páginas que se sirvan por HTTPS desde un único servidor web, a menos que usemos una IP diferente para cada sitio: Apache SSL/TLS Strong Encryption: FAQ: Why can’t I use SSL with name-based/non-IP-based virtual hosts?, Apache SSL/TLS Strong Encryption: FAQ: Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?.

Para este inconveniente hay workarounds (TLS Support for name-based virtual servers) y soluciones definitivas con el Server Name Indication (SNI). Apache 2.2 no soporta SNI, pero el módulo de Apache mod_gnutls (incluido en Debian Lenny: libapache2-mod-gnutls) nos permitiría usarlo. Desafortunadamente, aunque Firefox (>=2), Safari, Chrome y Opera soportan esta extensión del protocolo, Internet Explorer 6 e Internet Explorer 7 para Windows XP no soportan SNI, por lo que no podemos usarla de momento por motivos obvios.

Por todos estos motivos, descubrí que con los hostings profesionales no resulta fácil o, mejor dicho, barato, tener un servidor SSL. Es lo que me va a impedir a mí poder configurar SSL para el panel de administración de LHYLE.

Sin embargo, podemos seguir estudiando cómo podríamos hacerlo si lo que tenemos es un Hosting Casero o si le hemos contratado un servidor dedicado a nuestro proveedor de hosting.

(...)

Leer el resto de Crear los certificados SSL para nuestro servidor web HTTPS con Apache, OpenSSL y Debian Lenny (3,046 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 3 comentarios
Etiquetas: Apache, Debian, Firefox, GNU/Linux, Internet Explorer, OpenSSL, seguridad, wget

Feed enhanced by Better Feed from Ozh

Para quien no lo sepa, WEP (Wired Equivalent Privacy) es un algoritmo de encriptación para redes WiFi que ha demostrado ser extremadamente débil. Para solucionarlo se creó otro sistema, el WPA, y posteriormente, el aún más robusto WPA2. A la mayoría de lectores del blog sí que les serán muy conocidas las siglas WEP, WPA y WPA2 de cuando configuran su red WiFi doméstica, tanto en el router, como en el ordenador, aunque para usar WPA2 en Windows XP es necesario instalar la actualización KB917021, incluida en el SP3.

En el estado actual de las cosas, la clave de una red WiFi encriptada con una clave WEP de 104 bits se puede recuperar fácilmente consiguiendo capturar entre unos 40000 y 90000 paquetes que contengan vectores de inicialización débiles (aircrack-ptw). Además, con las técnicas adecuadas, es muy fácil conseguir que un AP (Access Point) mande todos esos paquetes a gran velocidad, siendo posible conseguirlos en cuestión de minutos.

En cambio, la clave de una red WiFi encriptada con WPA sólo puede ser recuperada por fuerza bruta, de forma que si la clave es suficientemente compleja, la potencia computacional necesaria puede ser simplemente inalcanzable hoy en día, incluso usando la tecnología CUDA de NVidia para ayudar a romper WPA.

(...)

Leer el resto de ¿Aún sigues con encriptación WEP para tu WiFi? (1,291 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 24 comentarios
Etiquetas: aircrack-ng, GNU/Linux, seguridad, WEP, Wi-Fi, WPA

Feed enhanced by Better Feed from Ozh

Uno de los temas que más ganas tenía de probar son las recientemente estrenadas capacidades de aceleración de vídeo de alta definición en H.264 en Linux usando los últimos drivers cerrados de NVidia (versión > 180.x), algo que descubrí recientemente que por fin era posible:

• nvNews: New Video Decode and Presentation API
• Phoronix: NVIDIA Driver Brings PureVideo Features To Linux
• Phoronix: NVIDIA VDPAU Benchmarks

Recordemos que en Windows, la aceleración del vídeo por hardware se hace mediante la API de DXVA, y que en Linux teníamos la API XvMC. Sin embargo la XvMC es bastante limitada y, hasta el momento, los fabricantes (NVidia, ATI/AMD, Intel, VIA) sólo han desarrollado soporte para acelerar MPEG2, aunque esta API también podría ayudar con el vídeo comprimido con MPEG4. En la entrada: Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG, ya estuvimos viendo con los resultados de pruebas reales los grandes beneficios que, con una CPU tan modesta como las VIA conseguíamos usando la aceleración de la GPU.

Pero en realidad, fuera de esos casos tan concretos como el de los procesadores VIA, a nadie le preocupaba en los últimos años la aceleración de vídeo por hardware. Cualquier ordenador reciente era totalmente capaz de mover cualquier vídeo de resolución estándar comprimido en MPEG2 o MPEG4 sin ningún problema. Pero, ¡ay!… llegó la alta definición y yo, con mi Athlon 64 X2 4600+, ya no era capaz de mover una película a resolución 1080p Full HD sin dar saltos de vez en cuando.

Pero gracias a los Reyes Magos y a la tecnología NVidia PureVideo, de nuevo voy a poder disfrutar de la alta definición sin traumas para mi CPU.

Sin embargo, es lamentable que los tres grandes fabricantes no se hayan puesto de acuerdo en una API común, como lo era el XvMC o lo es el DXVA de Windows. La nueva API de NVidia que permite la aceleración de vídeo de alta definición es la VDPAU (Video Decode and Presentation API for Unix) (Phoronix: XvMC To Support More Video Standards?, Phoronix: Mplayer, FFmpeg Gain VA-API Support); la especificación de AMD/ATI es la XvBA (X-Video Bitstream Acceleration) (Phoronix: AMD’s X-Video Bitstream Acceleration); y finalmente, la de Intel es la VaAPI (Video Acceleration API). Una vez más, cada fabricante tirando para su lado y los perjudicados, los usuarios y, sobre todo, Linux, que no va a poder contar con una API unificada frente a lo que ocurre en Windows.

En cualquier caso, veamos cómo conseguir esta aceleración en una Ubuntu 8.10.

(...)

Leer el resto de Aceleración por hardware de vídeo de alta definición H.264 en Linux con los nuevos drivers 180.x de NVidia (1,544 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 35 comentarios
Etiquetas: drivers, GNU/Linux, H.264, Hardware, NVidia, Ubuntu, VDPAU, XvMC

Feed enhanced by Better Feed from Ozh

Yo no tengo especial interés en hacer lo mismo con las imágenes de este blog. Al principio de tener la página, sí que detecté muchas páginas que “robaban” imágenes sin citar el origen, pero lo grave no era eso, porque que te copien una imagen en un sitio como este no tiene mayor importancia. Lo realmente grave era que yo detectaba el “robo” porque encima hacían hotlinking a las imágenes de mi sitio, sisándome parte del escaso ancho de banda que yo tenía dado que era un hosting casero. De cómo evitar esto en la medida de lo posible ya hablé en: Hosting casero HOWTO.

El “robo” de imágenes normalmente ocurre porque alguien copia un artículo entero (lo cual es totalmente legítimo si se respeta la Creative Commons), incluidas imágenes (si es con hotlinking ya no me parece tan legítimo) o porque alguien la ha encontrado en los buscadores de imágenes. El tráfico que traen los buscadores de imágenes, según la temática de la página, normalmente es muy poco agradecido: Necesito una imagen para un proyecto, la busco, la copio y se acabó… ¿De qué iba la página de donde he cogido la imagen? ¿Y a quién le importa? Por eso yo, en mi robots.txt, prohíbo que se indexen las imágenes (Remove an image from Google Image Search). No es el tipo de visitante que espero para mis entradas.

Sin embargo, en ciertos casos, como el de una tienda online, tiene mucho sentido que sus imágenes se puedan encontrar fácilmente. En varias ocasiones he tenido que buscar un adaptador de algún tipo y lo he localizado mucho más fácilmente en la búsqueda de imágenes que en la textual y casualmente, los sitios suelen ser tiendas que los venden. Todo perfecto.

Ésos son los casos en los que puede resultar más interesante aplicar una marca de agua a las imágenes del sitio. Como decía, no tengo ningún especial interés en hacerlo, pero sí que en su momento me intrigó el cómo hacerlo, y el resultado es el que podéis leer aquí.

Si nos centráramos en WordPress, existe un plugin, el Marekki’s Watermark, que yo he probado, y que me ha dado muy buena sensación. Sin embargo, no me han gustado dos cosas: que sea necesario modificar los ficheros estándar de WordPress para instalar el plugin y que te suba las nuevas imágenes ya con marca de agua sin mantener ninguna copia del archivo original. A mí me gusta mucho más conservar la imagen original fácilmente disponible para así poder variar o eliminar la marca de agua cuando queramos.

Vamos a ver cómo podríamos hacerlo en nuestra página actual que funcione con Apache y con las excelentes herramientas de ImageMagick. Por si alguien no lo conoce, ImageMagick es una colección de utilidades para editar imágenes en la línea de comandos. Sus posibilidades son infinitas y se trata de un software que nunca deja de sorprendernos. Si no existiera, habría que inventarlo. Tenemos un montón de tutoriales en Examples of ImageMagick Usage.

(...)

Leer el resto de Servir con Apache imágenes con marca de agua (watermark) (604 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Apache, GNU/Linux, hosting, ImageMagick, shell, WordPress

Feed enhanced by Better Feed from Ozh

Sin saber realmente por qué me está ocurriendo esto, este problema me sirve para hablar del IPerf, una pequeña utilidad que nos sirve para medir el ancho de banda efectivo entre dos sistemas de la red usando TCP o UDP. Como está disponible para Windows, y para los diferentes sistemas UNIX (en Debian y Ubuntu existe un paquete en la distribución estándar), podemos usarla entre dos nodos cualquiera conectados a una red para ver el ancho de banda real que, tras quitar las cabeceras y los retardos que introducen los dispositivos de red intermedios, nos queda.

En un extremo la ejecutaremos en modo servidor, con la opción -s:

debian $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.3 port 53490
[  4]  0.0-10.3 sec    116 MBytes  94.1 Mbits/sec

En el otro extremo, en modo cliente, con la opción -c. Por defecto, ambos extremos usan el puerto 5001:

ubuntu $ iperf -c debian
------------------------------------------------------------
Client connecting to debian, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.3 port 53490 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec    116 MBytes  96.3 Mbits/sec

Vemos que, de una red de 100 Mbps salen 94-96 Mbps. No está mal.

(...)

Leer el resto de Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (719 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 14 comentarios
Etiquetas: dd, Debian, GNU/Linux, netcat, OpenSSH, pv, Redes, Ubuntu, wget, Windows, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

Sin embargo, mientras que la salida del ntfsclone nos dice qué porcentaje de la imagen lleva leído o escrito, el dd no dice absolutamente nada hasta que finaliza. Como clonar un disco de muchos Gigabytes puede ser una tarea bastante larga, puede ser muy útil introducir entre los comandos de la tubería un pv para saber por dónde va la copia.

Sor Zitroën (¡gracias!) ha sido tan amable de indicarme que sí que hay una forma de obtener estadísticas del trabajo que lleva hecho dd, y que está hasta documentado en la página de man de dd:

Sending a USR1 signal to a running `dd' process makes it print I/O statistics to  standard
error and then resume copying.

       $ dd if=/dev/zero of=/dev/null& pid=$!
       $ kill -USR1 $pid; sleep 1; kill $pid

       18335302+0  records  in  18335302+0  records  out 9387674624 bytes (9.4 GB) copied,
       34.6279 seconds, 271 MB/s

Podría haber añadido esta nota como corrección a la anterior entrada, pero me ha gustado tanto, es una funcionalidad tan interesante y hasta ahora desconocida para mí, que he pensado que tiene entidad propia para comentarlo de forma separada.

Así, si estamos haciendo clonando un disco a través de la red, como veíamos previamente:

sisdest $ sudo nc -lp 2222 | dd of=/dev/hda

sisorig $ sudo dd if=/dev/hda | nc -q 0 sisdest 2222

En otro terminal (en cada una de las máquinas) podemos hacer un “ps -ef | grep dd” para buscar el PID del proceso y luego, al hacer el kill, en el terminal donde habíamos lanzado el dd, encontraremos, en la salida de error, las estadísticas del trabajo hecho hasta el momento por dd:

sisdest # ps -ef | grep dd
root     23772 23745  5 19:24 pts/1    00:00:01 dd of /dev/hda
sisorig # kill -USR1 23772
sisorig # kill -USR1 23772

sisorig # ps -ef | grep dd
root     34675 24619 28 11:23 pts/1    00:00:05 dd if /dev/hda
sisdest # kill -USR1 34675
sisdest # kill -USR1 34675

sisdest # nc -lp 2222 | dd of=/dev/hda
340522+0 records in
340522+0 records out
174347264 bytes (174 MB) copied, 21.9449 seconds, 7.9 MB/s
363920+0 records in
363920+0 records out
186327040 bytes (186 MB) copied, 23.4599 seconds, 7.9 MB/s

sisorig # dd if=/dev/hda | nc -q 0 sisdest 2222
242172+0 records in
242172+0 records out
123992064 bytes (124 MB) copied, 17.1812 seconds, 7.2 MB/s
270881+0 records in
270881+0 records out
138691072 bytes (139 MB) copied, 19.0057 seconds, 7.3 MB/s

Y una vez más vemos que los sistemas UNIX, día tras día, aún tienen la capacidad de sorprendernos con esas pequeñas funcionalidades medio ocultas que están siempre a la espera de que las descubramos.

:wq

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | Sin comentarios
Etiquetas: dd, GNU/Linux, netcat, UNIX

Feed enhanced by Better Feed from Ozh

Imaginemos, para empezar, el caso de que queremos hacer una imagen de una de las particiones NTFS de nuestro sistema. Puede ser para su posterior recuperación o puede ser para usar esa imagen con otros sistemas (y, por tanto, clonar el actual). Pero, desafortunadamente, no tenemos espacio en otra partición del sistema para almacenar el fichero de imagen localmente tal y como hacíamos en Alternativas al Ghost para crear imágenes de NTFS en Linux: Partimage y ntfsclone.

Si vamos a usar Partimage, no vamos a tener ningún problema para escribir la imagen remotamente, ya que es precisamente una de sus funcionalidades: la posibilidad de tener un servidor de imágenes de Partimage donde podemos escribir todas las imágenes de nuestros sistemas a través de la red.

Centrémonos, por tanto, en el ntfsclone, y en cómo usarlo a través de la red. La propia página de man del ntfsclone nos sugiere cómo hacerlo a través de SSH:

Backup an NTFS volume to a remote host, using ssh. Please note, that ssh may ask for a password!

    ntfsclone --save-image --output - /dev/hda1 | \\
    gzip -c | ssh host 'cat > backup.img.gz'

Restore an NTFS volume from a remote host via ssh. Please note, that ssh may ask for a password!

    ssh host 'cat backup.img.gz' | gunzip -c | \\
    ntfsclone --restore-image --overwrite /dev/hda1 -

Sin embargo, a mí me gusta más usar netcat para este propósito. netcat se autodenomina “la navaja suiza de TCP/IP”, y es verdad que lo es. De las varias implementaciones existentes, si usamos la original (cuyo autor es *Hobbit*) y leemos su README (en Debian/Ubuntu en /usr/share/doc/netcat-traditional/README.gz), veremos unos pocos ejemplos de sus posibilidades, suficientes para sorprendernos de la enorme versatilidad de esta herramienta.

(...)

Leer el resto de Usando ntfsclone y dd para clonado por red con netcat (917 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 6 comentarios
Etiquetas: dd, GNU/Linux, netcat, NTFS, ntfsclone, OpenSSH, partimage, pv, Windows

Feed enhanced by Better Feed from Ozh

El manual de VirtualBox denomina a esta forma de configurar la red entre el guest y el host Host Interface Networking (HIF). En su sección “6.8 Host Interface Networking and bridging on Linux hosts“, “6.8.1.1 Debian and Ubuntu hosts“, el manual nos detalla cómo conseguir configurar el sistema host para que el sistema guest pueda acceder a sus interfaces. Básicamente, los comandos que nos propone ejecutar en el host son:

1. sudo apt-get install bridge-utils

2. Añadir al fichero /etc/network/interfaces:

auto br0
   iface br0 inet dhcp
   bridge_ports eth0

3. sudo /etc/init.d/networking restart

4. sudo VBoxAddIF vbox0 <user> br0

Bueno, pues haciendo eso, lo que conseguiremos será perder la conectividad en el host y no tendremos red ni en el sistema real ni en el virtual.

Como sí que nos explica bien el manual de Ubuntu de VirtualBox en su sección de networking, sólo falta un detalle para que todo funcione bien, y es especificar que el interfaz real del sistema host lo pongamos a manual en el fichero /etc/network/interfaces, no a automático, que es lo que normalmente se tiene por defecto:

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
   bridge_ports eth0

Haciendo esto, sí que nos funcionará bien la red en el sistema real y en el virtual.

Pero, ¿de qué va todo esto? ¿Qué es el interfaz br0? ¿Y en qué consiste el interfaz vbox0?

(...)

Leer el resto de Host Interface Networking en VirtualBox sobre Debian/Ubuntu (1,151 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 16 comentarios
Etiquetas: Debian, GNU/Linux, QEMU, Ubuntu, VirtualBox

Feed enhanced by Better Feed from Ozh

Por ejemplo, en entradas anteriores vimos cómo instalar manualmente GRUB en una memoria USB para poder arrancar múltiples sistemas operativos desde ella:

• Arrancar Linux, Windows y MS-DOS de una memoria USB
• Arrancar MS-DOS desde una memoria USB

También vimos cómo, en caso de estar trabajando sobre un fakeRAID, el instalador de la distribución no es capaz de instalar GRUB con éxito, teniendo que hacerlo nosotros mismos manualmente:

• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID

Esta entrada pretende resumir las diferentes técnicas que ya habíamos visto previamente en un único documento que sirva de referencia, así como dar algunos detalles adicionales sobre el funcionamiento interno de GRUB. Por supuesto, toda esta información ya existe, como no podía ser de otra forma, en el manual de GRUB.

(...)

Leer el resto de Tres formas de instalar GRUB (1,714 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: dmraid, GNU/Linux, GRUB, memorias USB, ms-sys, RAID

Feed enhanced by Better Feed from Ozh

Es una noticia buena para los usuarios de Linux AMD64 después de tanto tiempo pidiéndolo, porque el plugin de Flash es vital para nuestros sistemas de escritorio si queremos tener una experiencia completa en el uso de la web hoy en día. Su alternativa abierta, el Gnash, aún no está preparado para reemplazarlo completamente. La única opción que teníamos era usar el plugin de 32 bits con el nspluginwrapper (Sobre el plugin de Flash en Firefox/Iceweasel en Debian AMD64: El nspluginwrapper aceptado en Testing), una opción que, aunque nos saca del apuro, es muy inestable y nos obligaba muy a menudo a reiniciar el navegador porque el plugin de Flash dejaba de funcionar.

Es una noticia muy mala para los usuarios de Linux porque es lamentable que en nuestro sistema, que nos gustaría ver libre de todo el software propietario, tengamos que pasar por el aro de dos cosas: del dichoso plugin de Flash y de los drivers cerrados. No es casualidad que a menudo sean componentes de software de nuestros sistemas que desearíamos que fueran algo más estables. Es muy desafortunado que tengamos que depender de que los señores de Adobe sean magnánimos con los pobres bichos raros que usan Linux de 64 bits para poder usar lo que todo el mundo usa, Internet.

Y por supuesto, también es lamentable que diseños web que se podrían hacer de forma perfectamente estándar y llamativa con un poco de CSS, HTML y JavaScript, acaben siendo pasto del todopoderoso y monopolístico Flash para desesperación de aquello que llamamos accesibilidad. El uso de Flash para reproducir vídeos en la web es razonable, aunque sería mucho más deseable que se usara cualquiera de los formatos de vídeo abiertos disponibles. Donde sí tiene perfecta cabida, hay que reconocerlo, es en el campo de las animaciones, como los juegos online o los típicos esquemas interactivos que a menudo nos presentan los periódicos en su edición digital.

Bueno, yo he probado hoy esta nueva versión del plugin en mi Ubuntu 8.10 y he de decir que funciona. No lo he probado intensivamente, pero funciona bien con algún juego (¿habéis probado el Play 99 Bricks?) y con Youtube, Metacafe y ZappInternet. Sin embargo, me da la sensación de que usa muchísima CPU.

Para instalarlo, he desinstalado el paquete flashplugin-nonfree:

 $ sudo dpkg -P flashplugin-nonfree
(Reading database ... 134935 files and directories currently installed.)
Removing flashplugin-nonfree ...
Purging configuration files for flashplugin-nonfree ...

y he hecho un autoremove para que elimine el nspluginwrapper también:

$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  nspluginwrapper
The following packages will be REMOVED:
  nspluginwrapper
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 483kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 134928 files and directories currently installed.)
Removing nspluginwrapper ...
Processing triggers for man-db ...

Finalmente, he descargado el fichero libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz y lo he descomprimido en el directorio ~/.mozilla/plugins. Sólo contiene una librería:

~ $ wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.d21.1.linux-x86_64.so.tar.gz

~ $ cd .mozilla/plugins/

~/.mozilla/plugins $ tar xvf ~/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
libflashplayer.so

Tras reiniciar el navegador, en el about:plugins ya veremos:

Shockwave Flash

File name: libflashplayer.so
Shockwave Flash 10.0 d20

Para instalar el plugin para todos los usuarios del sistema, habría que copiar la nueva librería en /usr/lib/mozilla/plugins/.

En fin, que la noticia deja un sabor muy agridulce. Es como cuando el driver de NVidia va mal y la actualización del driver cerrado arregla el problema. Se agradece la actualización, pero ésta no mitiga la impotencia que da depender de la voluntad que tenga una empresa para arreglar fallos o no hacerlo.

Actualización 20/11/08: The Inquirer: Instalación y rendimiento Adobe Flash 64bits en Linux

:wq

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 14 comentarios
Etiquetas: AMD64, drivers abiertos, Firefox, Flash, GNU/Linux, Ubuntu

Feed enhanced by Better Feed from Ozh

Otros fabricantes desarrollaron otros tipos de terminales, con el mismo concepto, pero incompatibles con otros sistemas, como este HP 700/96, que aún se sigue usando en algunos CPD hoy en día:

Los ordenadores personales, como el PC y los Apple o los Commodore, Spectrum, Amstrad CPC, etc. siguieron otro camino para mostrar la información al usuario, ya que, o bien usaban un sistema de vídeo propietario para mostrar texto y gráficos (p.e. MDA o VGA), o bien se conectaban directamente al televisor.

Los grandes servidores UNIX (basados en AIX, HP-UX, Solaris, etc.) o similares (por ejemplo, basados en OpenVMS, o z/OS) han llegado a nuestros días permitiendo la conexión de un terminal serie para usar la consola, pero cada día es más infrecuente su uso, ya que han sido sustituidos por consolas LAN (accedemos por Telnet o por SSH a una dirección IP diferente a la propia del sistema) o por consolas Web (una página web donde nos aparece la consola), que, por supuesto, nos permiten interactuar con la máquina incluso durante el arranque y la parada.

Hoy en día los terminales serie están bastante en desuso. Sin embargo, los emuladores de terminal están en pleno apogeo, bien sean para conectarnos por Telnet, por SSH, o, por supuesto, por el puerto serie/módem (ya lo vimos en Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP). Por cierto, ¿qué tipo de terminal emulan la mayoría de emuladores de terminal como mínimo? Pues, por supuesto, el famoso VT100. Pero como otros fabricantes hicieron otros terminales con sus propios protocolos, secuencias de escape y capacidades, hay múltiples tipos de emuladores de terminal. Las emulaciones de terminal ansi y vt100 (y tal vez xterm) son las más usadas.

(...)

Leer el resto de Emuladores de terminal. GNU screen: El multiplexador de sesiones de terminal. (1,373 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 21 comentarios
Etiquetas: GNU screen, GNU/Linux, PuTTY, termcap, terminal, terminfo

Feed enhanced by Better Feed from Ozh

Sin embargo, a mí sí que me gusta mucho salir a la consola. Y especialmente, me gusta ver el arranque detallado del sistema. Si me conformara con ver el bonito logotipo de Debian o de Ubuntu mientras espero a que arranque el sistema, nunca habría descubierto problemas como los que conté en Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel y en Disk might not be spun down properly. Update shutdown utility..

Es por eso que para mí es importante contar con una resolución en la consola adecuada a la pantalla que esté usando, para que las letras se vean lo más nítidas posibles y sin que sean monstruosamente grandes. La resolución la podemos especificar con el parámetro del kernel vga=DDD o vga=0xHHH, donde DDD es el número del modo VESA que queremos utilizar en decimal y HHH es el mismo número en hexadecimal. El único requisito es que el kernel haya sido compilado con soporte del driver de framebuffer VESA:

$ grep FB_VESA /boot/config-2.6.27-7-generic
CONFIG_FB_VESA=m

Lo único que necesitamos saber es qué modos VESA acepta nuestro adaptador gráfico y qué números tienen. Los más comunes (800×600, 1024×768, 1200×1024, etc.) son bien conocidos, y es a lo que dediqué precisamente la tercera entrada de este blog: Modos VESA aceptados por el kernel de Linux.

Sin embargo, el advenimiento de infinidad de portátiles y pantallas con resoluciones nativas poco convencionales (1680×1050, 1400×1050, 1400×900, etc.) no nos facilita precisamente el saber qué modos soportará nuestra pantalla y nuestro adaptador gráfico ya que, en ocasiones, el modo ni siquiera está estandarizado.

(...)

Leer el resto de vga=ask y los modos VESA disponibles en el sistema (1,044 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 8 comentarios
Etiquetas: Debian, GNU/Linux, GRUB, Kernel, Ubuntu, VESA, X Window System

Feed enhanced by Better Feed from Ozh

Las herramientas que incluye son:

• iostat(1) reports CPU statistics and input/output statistics for devices, partitions and network filesystems.
• mpstat(1) reports individual or combined processor related statistics.
• pidstat(1) reports statistics for Linux tasks (processes) : I/O, CPU, memory, etc.
• sar(1) collects, reports and saves system activity information (CPU, memory, disks, interrupts, network interfaces, TTY, kernel tables,etc.)
• sadc(8) is the system activity data collector, used as a backend for sar.
• sa1(8) collects and stores binary data in the system activity daily data file. It is a front end to sadc designed to be run
  from cron.
• sa2(8) writes a summarized daily activity report. It is a front end to sar designed to be run from cron.
• sadf(1) displays data collected by sar in multiple formats (CSV, XML, etc.) This is useful to load performance data into a database, or import them in a spreadsheet to make graphs.

En Debian y Ubuntu, tras instalar el paquete (apt-get install sysstat), ya podemos ver datos instantáneos. Todos los comandos aceptan como parámetros:

[ interval [ count ] ]

con los que le decimos al comando cuántos valores queremos y cada cuántos segundos. Por ejemplo, 5 valores de uso de CPU separados un segundo:

$ sar 1 5
Linux 2.6.27-7-generic (sistema) 	11/08/2008 	_x86_64_

10:17:37 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:17:38 AM     all      2.45      0.00      1.47      0.00      0.00     96.08
10:17:39 AM     all      1.96      0.00      0.98      0.00      0.00     97.06
10:17:40 AM     all     11.17      0.00      2.91      0.00      0.00     85.92
10:17:41 AM     all     13.11      0.00      1.94      0.00      0.00     84.95
10:17:42 AM     all      3.37      0.00      2.88      0.00      0.00     93.75
Average:        all      6.42      0.00      2.04      0.00      0.00     91.54

(...)

Leer el resto de sysstat, la colección de herramientas de monitorización de rendimiento (1,299 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 10 comentarios
Etiquetas: Debian, GNU/Linux, memoria RAM, rendimiento, swap, sysstat, Ubuntu

Feed enhanced by Better Feed from Ozh

Si lo pensamos detenidamente, tener una partición de swap, es tener una cantidad de espacio ahí abandonada y que en rarísimas ocasiones veremos usar. Y si el kernel llega a usarla, hemos de prepararnos, en la mayoría de los casos, a experimentar un sistema extraordinariamente pesado, con lo que si es una situación habitual, más nos vale comprar una ampliación de la memoria. De nuevo, recalcar que me refiero a sistemas domésticos. En un servidor, la memoria swap nos puede ayudar a absorber un pico puntual de trabajo que sólo se da en ocasiones aisladas y que no podemos dejar de atender.

Para nuestro sistema doméstico, resulta mucho más conveniente un fichero de swap, igual que hacen todos los Windows basados en NT con el pagefile.sys. Las ventajas son muchas:

• Lo podemos poner en la partición/sistema de ficheros que queramos
• Podemos borrarlo para liberar espacio si éste nos hace falta
• Podemos crear uno nuevo en cualquier momento
• No supone tener un espacio en disco bloqueado inservible para otros propósitos
• Posiblemente su rendimiento sea algo peor que el de una partición dedicada de swap, pero si la memoria swap llega a tener que usarse intensivamente, el rendimiento será ya nefasto, ¿qué más da que sea un poco peor?

Y, además, lo último, lo de que el rendimiento es peor parece que ni siquiera es cierto. En la LKML leemos que usando kernels 2.6 el rendimiento de un fichero de swap no es peor que el de una partición de swap (Jesper Juhl: a swap file is just as fast as a swap partition):

With a 2.4.x kernel swap files were slower than swap partitions, but with the 2.6 kernel a swap file is just as fast as a swap partition.

(...)

Leer el resto de Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (2,097 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 15 comentarios
Etiquetas: dd, GNU/Linux, HP-UX, Kernel, memoria RAM, rendimiento, swap, sysstat, UNIX

Feed enhanced by Better Feed from Ozh

La última vez que he sido consciente de mi enorme desconocimiento ha sido esta semana, cuando fruto de un comportamiento que me parecía ilógico me enredé con manuales y documentación de diferentes shells. ¿Habrá mucha gente capaz de dominar casi todos los aspectos de la shell?

Vayamos al grano… El problema que tuve fue que un script muy sencillo que en ksh funcionaba sin problemas, en bash no hacía lo que esperaba. El problema estaba en una línea como esta:

comando | read a b c

(...)

Leer el resto de Redirigir la salida de un comando a un read con una tubería (pipe) (1,288 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: GNU/Linux, shell, UNIX

Feed enhanced by Better Feed from Ozh

De igual forma, aunque yo he podido usarlo con Debian 4.0 Etch y anteriores, la Debian 5.0 Lenny ya no incluirá el ms-sys.

¿Por qué ambas distribuciones han decidido eliminar este paquete tan útil de sus repositorios?

Pues por problemas de licencia, ya que a pesar de ser GPL, el ms-sys lleva código que es directamente un volcado de los sectores de arranque de Microsoft (Why ms-sys was removed on hardy?, ms-sys — RoSponsor; contains non-free code, ms-sys contains MBRs which are copyrighted by Microsoft, ms-sys boot loader license).

Si queremos usarlo -a pesar de las dudas que hay sobre su licencia-, tendremos que descargarlo y compilarlo. Sólo es necesario descomprimirlo, un make y un make install para tenerlo funcionando en apenas unos segundos.

Y la verdad es que creo que coincidiréis conmigo en que esto no parece que lo haya programado así, directamente en hexadecimal, el autor del ms-sys, ¿verdad?

/usr/src/ms-sys-2.1.3/inc $ cat mbr_2000.h
/* First 446 bytes of MBR from Windows 2000, XP and 2003 */
/* This is English version. Bytes 0x12c onwards vary with language. */
/* Last two bytes 1b6 and 1b7 point to language-specific messages.  */
/* Support of other languages is an exercise for the reader!        */
unsigned char mbr_2000_0x0[] = {
  0x33, 0xc0, 0x8e, 0xd0, 0xbc, 0x00, 0x7c, 0xfb, 0x50, 0x07, 0x50, 0x1f,
  0xfc, 0xbe, 0x1b, 0x7c, 0xbf, 0x1b, 0x06, 0x50, 0x57, 0xb9, 0xe5, 0x01,
  0xf3, 0xa4, 0xcb, 0xbd, 0xbe, 0x07, 0xb1, 0x04, 0x38, 0x6e, 0x00, 0x7c,
  0x09, 0x75, 0x13, 0x83, 0xc5, 0x10, 0xe2, 0xf4, 0xcd, 0x18, 0x8b, 0xf5,
  0x83, 0xc6, 0x10, 0x49, 0x74, 0x19, 0x38, 0x2c, 0x74, 0xf6, 0xa0, 0xb5,
  0x07, 0xb4, 0x07, 0x8b, 0xf0, 0xac, 0x3c, 0x00, 0x74, 0xfc, 0xbb, 0x07,
  0x00, 0xb4, 0x0e, 0xcd, 0x10, 0xeb, 0xf2, 0x88, 0x4e, 0x10, 0xe8, 0x46,
  0x00, 0x73, 0x2a, 0xfe, 0x46, 0x10, 0x80, 0x7e, 0x04, 0x0b, 0x74, 0x0b,
  0x80, 0x7e, 0x04, 0x0c, 0x74, 0x05, 0xa0, 0xb6, 0x07, 0x75, 0xd2, 0x80,
  0x46, 0x02, 0x06, 0x83, 0x46, 0x08, 0x06, 0x83, 0x56, 0x0a, 0x00, 0xe8,
  0x21, 0x00, 0x73, 0x05, 0xa0, 0xb6, 0x07, 0xeb, 0xbc, 0x81, 0x3e, 0xfe,
  0x7d, 0x55, 0xaa, 0x74, 0x0b, 0x80, 0x7e, 0x10, 0x00, 0x74, 0xc8, 0xa0,
  0xb7, 0x07, 0xeb, 0xa9, 0x8b, 0xfc, 0x1e, 0x57, 0x8b, 0xf5, 0xcb, 0xbf,
  0x05, 0x00, 0x8a, 0x56, 0x00, 0xb4, 0x08, 0xcd, 0x13, 0x72, 0x23, 0x8a,
  0xc1, 0x24, 0x3f, 0x98, 0x8a, 0xde, 0x8a, 0xfc, 0x43, 0xf7, 0xe3, 0x8b,
  0xd1, 0x86, 0xd6, 0xb1, 0x06, 0xd2, 0xee, 0x42, 0xf7, 0xe2, 0x39, 0x56,
  0x0a, 0x77, 0x23, 0x72, 0x05, 0x39, 0x46, 0x08, 0x73, 0x1c, 0xb8, 0x01,
  0x02, 0xbb, 0x00, 0x7c, 0x8b, 0x4e, 0x02, 0x8b, 0x56, 0x00, 0xcd, 0x13,
  0x73, 0x51, 0x4f, 0x74, 0x4e, 0x32, 0xe4, 0x8a, 0x56, 0x00, 0xcd, 0x13,
  0xeb, 0xe4, 0x8a, 0x56, 0x00, 0x60, 0xbb, 0xaa, 0x55, 0xb4, 0x41, 0xcd,
  0x13, 0x72, 0x36, 0x81, 0xfb, 0x55, 0xaa, 0x75, 0x30, 0xf6, 0xc1, 0x01,
  0x74, 0x2b, 0x61, 0x60, 0x6a, 0x00, 0x6a, 0x00, 0xff, 0x76, 0x0a, 0xff,
  0x76, 0x08, 0x6a, 0x00, 0x68, 0x00, 0x7c, 0x6a, 0x01, 0x6a, 0x10, 0xb4,
  0x42, 0x8b, 0xf4, 0xcd, 0x13, 0x61, 0x61, 0x73, 0x0e, 0x4f, 0x74, 0x0b,
  0x32, 0xe4, 0x8a, 0x56, 0x00, 0xcd, 0x13, 0xeb, 0xd6, 0x61, 0xf9, 0xc3,
  0x49, 0x6e, 0x76, 0x61, 0x6c, 0x69, 0x64, 0x20, 0x70, 0x61, 0x72, 0x74,
  0x69, 0x74, 0x69, 0x6f, 0x6e, 0x20, 0x74, 0x61, 0x62, 0x6c, 0x65, 0x00,
  0x45, 0x72, 0x72, 0x6f, 0x72, 0x20, 0x6c, 0x6f, 0x61, 0x64, 0x69, 0x6e,
  0x67, 0x20, 0x6f, 0x70, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6e, 0x67, 0x20,
  0x73, 0x79, 0x73, 0x74, 0x65, 0x6d, 0x00, 0x4d, 0x69, 0x73, 0x73, 0x69,
  0x6e, 0x67, 0x20, 0x6f, 0x70, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6e, 0x67,
  0x20, 0x73, 0x79, 0x73, 0x74, 0x65, 0x6d, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x2c, 0x44, 0x63
};
/* Next four bytes used for Windows Disk Signature / Drive serial number */
/*
unsigned char mbr_2000_0x1b8[] = {
                                                  0x00, 0x00, 0x00, 0x00,
  0x00, 0x00
};
*/

Siendo estrictos, es verdad que el ms-sys lleva código de Microsoft, aunque sólo sean varios trozos de menos de 512 bytes, por lo que es razonable la decisión que han tomado los desarrolladores de Debian y Ubuntu. Pero, ¡qué lastima dejar de tener a mano una herramienta tan útil! Ya podría Microsoft liberar estos míseros bytes de código por el bien de la interoperabilidad…

:wq

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 5 comentarios
Etiquetas: Debian, GNU/Linux, Microsoft, ms-sys, Ubuntu

Feed enhanced by Better Feed from Ozh

La imagen que creamos allí era, por defecto, de tamaño fijo (no dinámico), de modo que ocupaba en el disco duro el mismo espacio del que disponía la memoria USB, en mi caso 8 GB (que no 8 GiB):

-rwxr-xr-x  1 root    root    8000004096 2008-09-26 23:41 imagen_mem_usb.img*
-rw-------  1 vicente vicente 8000666112 2008-10-05 18:57 imagen_mem_usb.vdi*

Como vimos en Montar imágenes de disco vdi de VirtualBox, podemos convertir dicha imagen de tamaño fijo en una de tamaño dinámico y además, eliminando los bloques no usados, con “vditool SHRINK“:

$ vditool SHRINK imagen_mem_usb.vdi
vditool    Copyright (c) 2004-2008 innotek GmbH.

Shrinking VDI image file="imagen_mem_usb.vdi"...
progress: 0%Log created: 2008-09-27T12:19:10.484950000Z
Executable: /usr/lib/virtualbox/vditool
Arg[0]: /usr/lib/virtualbox/vditool
Arg[1]: SHRINK
Arg[2]: imagen_mem_usb.vdi
Dumping VDI image "imagen_mem_usb.vdi" mode=r/w fOpen=0 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=8000004096
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=7630 cBlocksAllocated=7630
Header: offBlocks=512 offData=31232
Header: Geometry: C/H/S=15501/16/63 cbSector=512 Mode=2
Header: uuidCreation={53bea69e-c21b-4273-be9e-df3fa8f1ffd7}
Header: uuidModification={7a7be4b9-188a-42b2-298e-07eaa266a651}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=31232
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0
...........10%..........20%..........30%..........40%..........50%
..........60%..........70%..........80%..........90%..........100%
Dumping VDI image "imagen_mem_usb.vdi" mode=r/w fOpen=0 File=00000004
Header: Version=00010001 Type=2 Flags=0 Size=8000004096
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=7630 cBlocksAllocated=7621
Header: offBlocks=512 offData=31232
Header: Geometry: C/H/S=15501/16/63 cbSector=512 Mode=2
Header: uuidCreation={53bea69e-c21b-4273-be9e-df3fa8f1ffd7}
Header: uuidModification={7a7be4b9-188a-42b2-298e-07eaa266a651}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image:  fFlags=00000000 offStartBlocks=512 offStartData=31232
Image:  uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0

The operation completed successfully!

Sin embargo, en este caso no conseguimos apenas ningún ahorro de espacio:

-rwxr-xr-x  1 root    root    8000004096 2008-09-26 23:41 imagen_mem_usb.img*
-rw-------  1 vicente vicente 7993326080 2008-09-30 21:04 imagen_mem_usb.vdi*

La imagen compactada es tan sólo 8000666112-7993326080=7340032 bytes más pequeña que la anterior. Esto es debido a que el proceso de compactación de vditool sólo es capaz de ahorrarnos los bloques que contengan íntegramente ceros, y en el caso de mi memoria USB, fruto de innumerables movimientos de ficheros, ya vemos que son muy pocos los bloques que continuaban conteniendo exclusivamente ceros. Es bien sabido que cuando borramos un fichero, su contenido sigue estando íntegramente en el disco y sólo anotamos en las estructuras del sistema de ficheros que ese espacio que antes usaba tal fichero, ahora está disponible para cualquier otro fichero. Y eso es en lo que se basan los programas de recuperación de ficheros eliminados para hacer su trabajo con mayor o menor éxito según sea el sistema de ficheros y según las operaciones de ficheros que se hayan realizado desde el borrado.

Por tanto, normalmente las imágenes de disco que hayan tenido mucho trajín de archivos y que no tengan mucho espacio sobrante, tendrán pocos bloques que puedan ser eliminados durante la compactación, ya que esos bloques es muy posible que contengan restos de ficheros ya eliminados y no contengan solo ceros.

(...)

Leer el resto de Compactar imágenes de disco de VirtualBox: vditool vs VBoxManage (1,061 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 2 comentarios
Etiquetas: dd, GNU/Linux, VirtualBox, Windows

Feed enhanced by Better Feed from Ozh

Haz el cambio → Reinicia → Comprueba si funciona → Vuelve a arrancar normal

se repite una y otra vez…

Siempre he pensado que sería muy útil poder arrancar esa memoria USB desde una herramienta de virtualización como VirtualBox o VMWare para poder hacer allí tranquilamente las pruebas. Sin embargo, aunque VWMWare permite el acceso a dispositivos USB, si no me equivoco, no permite arrancar desde ellos. El VirtualBox-OSE (la versión GPL), directamente no permite el acceso a dispositivos USB. El VirtualBox normal sí lo permite pero el arranque de un dispositivo USB no es una opción del menú de arranque de su BIOS.

Otra solución sería permitir acceso directo al disco USB /dev/sdX desde el entorno de virtualización. Como el VirtualBox lo trataría como un disco normal, no podríamos simular los problemas que a menudo tienen las BIOS y los sectores de arranque con el hecho de que el disco sea USB, pero al menos podríamos comprobar que, al menos todo parece ir bien. En VirtualBox, la forma de dar acceso a un disco físico es ésta:

VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/sda

consistente en crear un fichero vmdk enlazado a un disco físico. Sin embargo, la versión 1.5.6 de VirtualBox-OSE, la que lleva Ubuntu Hardy, no incluye este comando. En Debian Lenny, la versión de VirtualBox-OSE incluida, la 1.6.2, sí que lleva el “createrawvmdk“ y funciona bien. Si queremos poder tener acceso directo a discos en Ubunty Hardy, podemos descargar la versión completa (y cerrada) de VirtualBox, que además de incluir características que no lleva la OSE (VirtualBox Editions), está compilado y empaquetado para la mayoría de las distribuciones más conocidas, incluyendo los módulos del kernel necesarios. Por supuesto, no podemos hacer esto por defecto con los permisos de un usuario normal, ya que no podrá acceder a un fichero de dispositivo /dev/sdX directamente ni para hacer el createrawvmdk ni para luego arrancar el sistema dentro de VirtualBox. Tendremos que usar root o ajustar los permisos.

(...)

Leer el resto de Probar en VirtualBox una memoria USB de arranque (724 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: dd, GNU/Linux, memorias USB, particiones, VirtualBox

Feed enhanced by Better Feed from Ozh

• Sobre el BartPE. Arrancar Windows/BartPE desde una memoria USB.
• Arrancar Linux, Windows y MS-DOS de una memoria USB

La verdad es que durante este tiempo, apenas lo he usado, ya que siempre que he necesitado recuperar algún sistema o hacer alguna operación sin arrancar el sistema operativo principal, siempre he contado con mi inestimable Knoppix. Sin embargo, recuerdo un par de ocasiones en las que me vino muy bien porque un sistema Windows se había cerrado mal, la partición NTFS necesitaba un chkdsk y, por tanto, el NTFS-3G no la podía montar. El BartPE me sacó del apuro, ya que pudo montar las unidades NTFS sin problemas.

En las entradas anteriores en las que traté el BartPE vimos que el mayor inconveniente de ponerlo en una memoria USB era que la partición tenía que ser FAT, con una tamaño máximo de partición de 2 GiB y un tamaño de cluster excesivamente grande (ver La pesadilla de compartir partición entre Linux y Windows). Esto quizá no era mayor problema cuando las memorias USB eran de 512 MiB o de 1 GiB, pero hoy en día sí lo es. También lo es si queremos instalar el BartPE en un disco duro externo USB.

Además, las posibilidades que tenemos con el BartPE son mucho mayores ahora, porque además de poder añadirle plugins, algo limitado y que necesita un esfuerzo para crearloso, al menos, para buscarlos y configurarlos correctamente, tenemos una enorme variedad de aplicaciones portables (p.e. PortableApps) que podemos usar sin problemas y sin preinstalación desde BartPE.

Bueno, el caso es que tenía un poco abandonado el tema del BartPE hasta que hace unos días Alfredo Lozano me habló de una utilidad que había usado él para conseguir instalar un BartPE en una memoria USB formateada en FAT32. La he probado y ¡es realmente buena! Funciona con FAT y con FAT32 y además, como en vez de cargar una imagen ISO bien grande en memoria, funciona como un disco duro grabando los ficheros individualmente en la memoria USB, sólo carga los ficheros que necesita en ese momento. Así, en vez de necesitar hasta los 20 minutos que pueden necesitar algunas BIOS en cargar unos 250 MiB, la carga es muchísimo más rápida, tanto con FAT como con FAT32.

Pasemos ahora a ver cómo usar la utilidad que nos lo facilita y posteriormente pasaremos a entender cómo funciona por dentro.

(...)

Leer el resto de Arrancar BartPE desde memorias USB en FAT32, ¡y mucho más rápido! (2,655 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 53 comentarios
Etiquetas: BartPE, FAT, GNU/Linux, GRUB, Knoppix, memorias USB, MS-DOS, ms-sys, Windows

Feed enhanced by Better Feed from Ozh

Así, a menudo he tratado de divulgar el problema que existe con los drivers para los chipsets gráficos de VIA, tanto aquí:

• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG
• Petición para que VIA tome una postura clara respecto a Linux
• VIA anuncia una iniciativa para mejorar los drivers de Linux (con un par de actualizaciones)

como en Barrapunto:

• Petición para que VIA cree drivers decentes para Linux
• Petición a VIA para que cree drivers decentes de Linux (II)
• Petición a VIA para que cree drivers decentes de Linux (III)
• Petición para que VIA cree drivers decentes para Linux
• VIA anuncia una iniciativa para mejorar los drivers libres para Linux
• VIA publica un driver abierto para Xorg

Y es que existe una necesidad de que VIA facilite (creándolo directamente o ofreciendo la documentación adecuada) un driver abierto y de buena calidad para Linux. Es algo que nos beneficia mucho a nosotros, los usuarios, pero aún más a la propia VIA. ¿Alguien piensa que los modestos procesadores y chipsets de VIA pueden tener algún futuro con un Windows Vista que va a pedales en sistemas de última generación? Evidentemente, no. Su nicho de mercado estrella es el de sistemas enfocados a ser usados con aplicaciones de Internet de bajo consumo, como es el caso de los miniportátiles o nettops.

VIA necesita que su hardware funcione bien en Linux más incluso que nosotros los usuarios. Pensemos en cuáles son los miniportátiles más conocidos que hay en el mercado en el momento de escribir estas líneas: Está el Asus EEE, con procesador de Intel (Celeron o Atom), el Acer Aspire One, también con Intel Atom y el HP Mini Note 2133, el único con hardware de VIA. Todos ellos ofrecen la opción de usar Linux en ellos, como no podía ser de otra forma si queremos hacer un uso eficiente de nuestro “débil” hardware. ¿Es posible que VIA rasque algo en este mercado sin sacar drivers decentes?

Cuando en Enero promovimos la petición online para que VIA creara o facilitara drivers decentes, yo creo sinceramente que sí que conseguimos algo: no que VIA por fin diera su brazo a torcer y lo que antes era un no rotundo pasara a ser un si en letras gigantes. Nuestro logro fue, posiblemente, conseguir que esos directivos de VIA encorbatados y que probablemente nunca habían visto otra cosa que no fuera Windows se dieran cuenta de que algo iba realmente mal en su colaboración con la comunidad de Linux que tan necesaria les iba a resultar en los próximos meses.

Colaborar con la comunidad de software libre no es exactamente lo que ha hecho VIA de crear el sitio http://linux.via.com.tw/ y decir: ¡Ea! ¡Ahí tenéis los drivers que queríais! ¡Pesados! No, eso ya lo teníamos peor o mejor en viaarena.com. Colaborar con la comunidad es enviar parches a los desarrolladores del kernel, mantenerlos, colaborar con los chicos de openChrome para mejorar lo existente, o al menos crear documentación útil. En cualquier caso, podemos consolarnos con que menos es nada.

Cuando en Julio VIA anunció el fichaje de Harald Welte muchos pudimos hacernos ilusiones de que el panorama podía cambiar y que podríamos encontrarnos con una colaboración honesta con la comunidad.

Sin embargo, pese a la aparente voluntad de VIA de cambiar las cosas con este movimiento, parece que nos vamos a encontrar con un escollo mucho más grande que ha estado persiguiendo al software abierto desde hace años: las patentes.

(...)

Leer el resto de ¿Tendremos algún día un driver abierto de VIA completo? (1,533 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 5 comentarios
Etiquetas: drivers, drivers abiertos, GNU/Linux, openChrome, VIA, VIA EPIA

Feed enhanced by Better Feed from Ozh

En Windows 95 se introdujo la característica de que las aplicaciones se pudieran desinstalar desde el panel de control y, sobre todo, la mentalidad de que los programas de Windows debían facilitar su desinstalación. Esta forma de trabajar sigue en Windows hasta hoy en día. Esto mejoró algo las cosas en lo que respecta a la limpieza del sistema. Hay programas que hacen un mejor trabajo, hay programas que hacen un peor trabajo, pero la realidad, y en esto coincidiremos casi todos, es que a pesar de ello, conforme pasa el tiempo para una instalación de Windows en la que frecuentemente se instalan y desinstalan aplicaciones, su limpieza y, sobre todo, su rendimiento, van bajando dramáticamente, conduciendo al software rot (rot=putrefacción) y a la necesaria y bien conocida tarea de reinstalar Windows.

Es por todo esto que cuando en tiempos del Windows 98 descubrí el Ghost, mi forma de trabajo con Windows cambió para siempre. Antes lo habitual era no querer probar nuevos programas ni hacer grandes virguerías no fuera que el Windows se ensuciara mucho. Desde entonces la política siempre ha sido crear una imagen muy limpia y estable de Windows y no cortarme en absoluto haciendo cualquier prueba, más o menos destructiva que quiera hacer, sin pensar si dañará más o menos a la actual instalación de Windows. El proceso es tal que así con cada nuevo ordenador que cae en mis manos:

1. Se instala Windows y se personaliza con las opciones, programas y utilidades que realmente usamos siempre.
2. Se crea una imagen de la partición de Windows.
3. Se usa Windows con total libertad sin ningún temor a que “se ensucie”.
4. La única limitación es que está totalmente prohibido guardar datos personales en la unidad de Windows, la C. Los documentos y archivos que van cambiando (por ejemplo, los ficheros .pst de Outlook o la caché de Google Desktop) han de crearse en otras particiones. Las aplicaciones portables ayudan mucho a seguir esta filosofía de trabajo. Por ejemplo, es posible tener las versiones portables de Firefox y Thunderbird en otra partición de forma que una recuperación de la imagen no nos haga perder todas sus personalizaciones. No creo que sea necesario recordar cuán importante es hacer backup de esos datos de otras particiones.
5. Tras X semanas (cuando sea necesario, pero sin dejar que pase excesivo tiempo) se recupera la imagen. Si necesita alguna actualización, se vuelve a crear una nueva imágen con los últimos retoques.

(...)

Leer el resto de Alternativas al Ghost para crear imágenes de NTFS en Linux: Partimage y ntfsclone (2,592 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 24 comentarios
Etiquetas: dd, GNU/Linux, NTFS, NTFS-3G, ntfsclone, partimage, wget, Windows

Feed enhanced by Better Feed from Ozh

• Es software libre, a diferencia del VMWare
• Es muchísimo más rápido que el QEMU
• Es mucho más estable que el KQEMU

Sin embargo, respecto al VMware tiene algunas desventajas como que la creación de interfaces de red no es tan sencilla, sino que requiere acudir al manual y hacer algunas operaciones en la línea de comandos. Además, el formato de sus imágenes nativas de disco, el vdi, no es tan estándar/común como el vmdk o el formato raw que puede usar QEMU y que es sólo una copia directa bit a bit de un disco duro.

Respecto a estas imágenes vdi, he estado investigando si se pueden montar directamente como dispositivo loop. Para montar imágenes de VMware podemos usar el VMware DiskMount, una utilidad que incluye el comando vmware-mount. Para montar imágenes raw de QEMU podemos seguir el procedimiento que vimos en: Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. ¿Se puede hacer algo parecido con las imágenes vdi?

Pues sí que es posible hacer operaciones similares gracias a la utilidad de VirtualBox vditool:

$ vditool
vditool    Copyright (c) 2004-2008 innotek GmbH.

Usage:   vditool <Command> [Params]
Commands and params:
    NEW Filename Mbytes          - create new image;
    DD  Filename DDFilename      - create new image from DD format image;
    CONVERT Filename             - convert VDI image from old format;
    DUMP Filename                - debug dump;
    RESETGEO Filename            - reset geometry information;
    COPY FromImage ToImage       - make image copy;
    COPYDD FromImage DDFilename  - make a DD copy of the image;
    SHRINK Filename              - optimize (reduce) VDI image size.

(...)

Leer el resto de Montar imágenes de disco vdi de VirtualBox (1,431 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 34 comentarios
Etiquetas: GNU/Linux, particiones, QEMU, VirtualBox, VMWare

Feed enhanced by Better Feed from Ozh

Como ya vimos en Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco., las particiones son apenas 64 bytes en el primer sector (512 bytes) del disco duro, el que llamamos MBR (Master Boot Record). Bueno, para ser exactos, en el MBR sólo se pueden guardar las 4 particiones (apenas 16 bytes para cada partición) primarias que podemos tener en el sistema de particiones de los PC, o 3 primarias más 1 extendida que puede almacenar un número indefinido de particiones lógicas en el EBR (Extended Boot Record).

Pues bien, un cambio que podamos hacer en esa tabla de particiones por ejemplo con el fdisk de Linux en principio sólo nos estará modificando la información del MBR y/o del EBR, pero en principio no la del sitio donde está la partición, a menos que el programa de gestión de particiones haga cosas más agresivas, algo que suele hacer, por ejemplo, el administrador de discos de windows. Además, si el gestor de particiones que usemos también tiene la capacidad de formatear particiones recién creadas, y es eso lo que seleccionamos, también es altamente probable que perdamos irremediablemente nuestros datos.

Me acuerdo de una vez, hace muchos años, que me cargué la tabla de particiones, ya no recuerdo cómo. Como en aquella ocasión no conocía ninguna herramienta de recuperación de particiones, me tocó armarme de paciencia, recordar de cuánto tamaño era más o menos cada partición e ir probando durante varias horas a crear particiones con el fdisk de Linux empezando un poco más aquí y empezando un poco más allá hasta que conseguí dar con un conjunto de particiones que se montaban sin errores y conseguí no perder mis datos. Hice una recuperación de particiones manual. No fui difícil pero sí muy pesado.

Más recientemente también me ha pasado alguna vez tocar la partición que no era pero, esta vez sí, ya conocía el genial gpart y pude recuperarlas sin apenas despeinarme. Aunque el nombre sea muy parecido, no debemos confundir el gpart (Guess PC-type hard disk partitions), una herramienta de recuperación de particiones, con el GParted (Gnome Partition Editor), un gestor de particiones que nos permite crearlas, eliminarlas, moverlas, copiarlas e incluso cambiarles el tamaño, llegando a igualar y superar al antiguo rey en este campo: el famoso Partition Magic.

(...)

Leer el resto de Recuperación de particiones perdidas con gpart (1,125 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 12 comentarios
Etiquetas: dd, GNU/Linux, gpart, particiones, PC, Windows

Feed enhanced by Better Feed from Ozh

Pues bien, la semana pasada le compré otros dos módulos Kingston de 1 GiB exactamente iguales que los originales para ampliar la memoria a un total de 4 GiB. La memoria es de una marca y modelo oficialmente soportados por esta placa base.

Yo ya sabía que algo que en teoría debería de ser pinchar & listo (plug & play) a menudo causa problemas, ya que, ¿cuántas veces no nos hemos encontrado con memorias de las que la placa sólo reconocía la mitad? ¿o que colgaban el ordenador a la primera de cambio? ¿o que nos obligaba a bajar la velocidad del bus o los parámetros de memoria en los parámetros de la BIOS? En este caso, no ha sido menos, ya que la dichosa ampliación de memoria me ha tenido un buen número de horas en vilo de saber si algún día podría usar esos 4 GiB de RAM en mi sistema.

Tras pinchar la memoria me encontré la primera cosa extraña: La BIOS había bajado la velocidad de la memoria de 400 MHz a 333 MHz. La verdad es que algo así ya me lo esperaba, ya que precisamente uno de las preguntas de las FAQ de la A8N-SLI es, precisamente:

Why does the memory run at 333MHz if I use four DDR400 512MB/256MB memory modules on A8N-SLI?

To be more compatible and stable with some memory modules, the default clock will be at 333MHz if four DDR400 memory modules are plugged on the A8N-SLI. But you still can set at 400MHz manually in the Bios to gain better performance. Moreover, in order to get best performance and compatibility, please choose those memory modules which are verified by us. You can get the QVL from the link below:

http://www.asus.com/products.aspx?l1=3&l2=15&l3=148&model=375&modelmenu=1

Así que entré en la BIOS, puse la configuración de la memoria en Manual, seleccioné la velocidad de 400 MHz y… el ordenador se colgaba instantes después del comienzo del arranque de cualquier sistema operativo. Y es que al poner la configuración manual de la memoria, los otros parámetros de la memoria como CAS# latency, RAS# to CAS# delay, Min RAS# active time o Row Precharge Time dejaban de configurarse automáticamente, así que tuve que volver a poner la memoria en Auto / 333 MHz y entrar en Linux para ver los parámetros de los DIMMs usando el decode-dimm.pl.

(...)

Leer el resto de La odisea de ampliar la memoria a 4 GiB (2,110 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 22 comentarios
Etiquetas: AMD64, GNU/Linux, Hardware, memoria RAM, Windows

Feed enhanced by Better Feed from Ozh

• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres
• Notas sobre la función wptexturize de WordPress, sobre los navegadores que convierten el código HTML a UTF-8 y sobre Unicode/UTF-8
• Cómo mantener los acentos y las eñes al montar NTFS, FAT o smbfs y al compartir directorios con Samba

Si bien muchos visitantes pueden tener claro ¿qué es un juego de caracteres?, también es posible que muchos otros se sientan un poco perdidos entre todas estas siglas y no entiendan por qué los nombres de los ficheros o su contenido, que se ven bien en un sistema operativo, no se ven bien en otro.

Teoría básica de ordenadores es que éstos sólo saben de unos y ceros. Afortunadamente, con unos y ceros, gracias al sistema binario se puede representar cualquier número. Por tanto, los ordenadores básicamente sólo saben manejar números.

Parecerá una perogrullada, pero en este punto es necesario recordar que las letras no son números. Mientras que los unos y ceros se convierten en un número decimal como los que solemos usar de forma natural, no hay ninguna regla matemática que asocie unos y ceros con una letra.

Sin embargo, sí que podemos definir reglas arbitrarias para que los ordenadores puedan trabajar con letras asociando letras/caracteres determinados a un número determinado, lo que llamaremos “juego de caracteres“. El juego de caracteres más famoso es el ASCII (American Standard Code for Information Interchange), creado en 1960 para los teletipos de la época. Es un sistema en el que a cada carácter le asignamos un número de 7 bits (del 0 al 127) que nos permite tener 128 caracteres, de los cuales 33 son de control necesarios en los antiguos teletipos pero mayormente obsoletos hoy en día, y los 95 restantes son los números 0-9, las letras mayúsculas (sin la “Ñ”) A-Z, las letras minúsculas (sin la “ñ”) a-z, así como los siguientes signos de puntuación:

En este sistema, por ejemplo a la “a” le corresponde el número 97 y a la “J” el número 74.

Es evidente que el juego de caracteres ASCII presenta una visión bastante anglocéntrica de la informática, ya que es excluyente con todas las personas que tenemos el vicio de usar lenguas distintas al inglés y necesitamos caracteres como la ñ, la ç o la ß. Es por eso que cuando los teletipos quedaron atrás y los ordenadores trajeron los “bytes” o, lo que es lo mismo, los números de 8 bits (del 0 al 255), los juegos de caracteres pudieron empezar a usar 128 caracteres más de los que tenía ASCII, en los que se incluyeron los símbolos necesarios para idiomas europeos diferentes al inglés.

(...)

Leer el resto de Juegos de caracteres: ASCII, CP850, ISO-8859-15, Unicode, UTF-8, etc. (3,467 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 16 comentarios
Etiquetas: acentos, ASCII, convmv, CP437, CP850, eñe, GNU/Linux, HTML, iconv, internacionalización, ISO-8859, juegos de caracteres, Unicode, UTF-16, UTF-8, Windows, Windows-1252

Feed enhanced by Better Feed from Ozh

Así, si desde Windows hacemos un SSH con algún emulador de terminal a un sistema Linux que use ISO-8859-15 en el que exista un fichero que se llame “test-áéíóúñÑ€.txt” y no usamos ningún tipo de traslación, en el emulador de terminal veremos que el símbolo del euro ha sido reemplazado por un “¤” porque ese es el símbolo que está en la posición del euro en ISO-8859-1.

-rwx------  1 root    root         0 2007-02-11 23:36 test-áéíóúñѤ.txt*

Pero hay emuladores de terminal como el PuTTY que nos permiten elegir el juego de caracteres del sistema al que nos conectamos y traducir de dicho juego de caracteres al de Windows:

(...)

Leer el resto de El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (1,614 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 12 comentarios
Etiquetas: acentos, backup, convmv, Cygwin, Debian, eñe, FAT, filesystems, GNU/Linux, iconv, internacionalización, ISO-8859, juegos de caracteres, NTFS-3G, PuTTY, Samba, Ubuntu, Unicode, UTF-8, Windows, Windows-1252

Feed enhanced by Better Feed from Ozh

En la página de las distribuciones que han obtenido la certificación de alguna versión LSB aparecen, cómo no, las más comerciales: las Red Hat, SUSE o Madriva así como la OpenSUSE 10.2. No aparece ninguna Debian y de Ubuntu sólo sale la 6.06, aunque no es algo que sus desarrolladores ignoren, ya que tenemos la página Debian and the Linux Standard Base, en la página de LSB Distribution Status aparece como planned y además hay varios paquetes encaminados a conseguir la compatibilidad con la LSB:

$ apt-cache search lsb
alien - install non-native packages with dpkg
insserv - Reorder boot sequence based on LSB init.d script dependencies
lsb - Linux Standard Base 3.1 support package
lsb-appchk2 - LSB v2.x Application checking tool
lsb-appchk3 - LSB v3.x Application checking tool
lsb-base - Linux Standard Base 3.1 init script functionality
lsb-build-base2 - LSB v2.x Development tools base package
lsb-build-base3 - LSB v3.x Development tools base package
lsb-build-cc2 - LSB v2.x Development environment lsbcc package
lsb-build-cc3 - LSB v3.x Development environment lsbcc package
lsb-build-desktop3 - LSB v3.x Development tools desktop package
lsb-core - Linux Standard Base 3.1 core support package
lsb-cxx - Linux Standard Base 3.1 C++ support package
lsb-desktop - Linux Standard Base 3.1 Desktop support package
lsb-graphics - Linux Standard Base 3.1 graphics support package
lsb-pkgchk3 - LSB v3.x package checking tool
lsb-qt4 - Linux Standard Base 3.1 Qt4 support package
lsb-release - Linux Standard Base version reporting utility
lsb-rpm - Red Hat package manager for LSB package building

La LSB es incluso un estándar ISO desde 2005 (ISO/IEC 23360), aunque no está extenta de polémica, ya que hay quien piensa que esto de la LSB es un negociete que se han montado cuatro que viven de hacer estándares para viajar y ganar buenos sueldos a costa de las distribuciones importantes, ya que en realidad los tests destinados a certificar no son los más adecuados (Linux Standard Base approved as international standard, Do you still think the LSB has some value?).

Bueno, sea como sea, el asunto es que un subconjunto de la LSB es el Filesystem Hierarchy Standard. Mientras que la LSB es un mamotreto ilegible, la FHS es un documento de apenas 52 páginas muy conciso, útil y casi de imprescindible consulta para cualquiera que quiera meterse de verdad en el mundo Linux y quiera enterarse bien de cosas como por qué hay ficheros que se guardan en /usr/bin/, y no en /sbin/ o en /usr/share/, /usr/sbin/ o /usr/local/bin/. El FHS es la base del capítulo 16 del documento “core” de la LSB y lo podemos descargar suelto de The home of the Filesystem Hierarchy Standard (FHS).

(...)

Leer el resto de La Linux Standard Base está hecha… ¡en Windows! (462 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 22 comentarios
Etiquetas: DocBook, FHS, GNU/Linux, LSB, Windows, WTF

Feed enhanced by Better Feed from Ozh

Un RAID por hardware es aquél en el que la controladora de discos se encarga de que la agregación de discos sea totalmente transparente para el sistema operativo, de forma que éste sólo vea un disco donde realmente hay varios. En este caso, como todo el trabajo extra de gestión del RAID lo hace la controladora, no hay sobrecarga para la CPU.

Un RAID por software es cuando el sistema operativo es el que tiene acceso directo a los discos y es él el que monta el RAID a partir de esos discos de forma transparente para las aplicaciones que ven sólo un disco donde realmente hay varios. En este caso, el trabajo de gestión del RAID lo tiene que hacer enteramente la CPU.

Un fakeRAID es una mezcla de ambas cosas. En realidad es un RAID por software: el trabajo lo hace la CPU que tiene que hacer un trabajo extra para mantener el RAID consistente, pero un fakeRAID está soportado por el chipset y por la BIOS, de forma que en el momento del arranque es transparente para los diferentes sistemas operativos si ahí hay un disco real o es un RAID. Así, aunque tanto Windows como Linux soporten su RAID propietario por software, yo en mi sistema puedo conseguir arrancar sin problemas Linux, Windows y MS-DOS desde la pareja de discos en RAID 0 de forma totalmente transparente. El fakeRAID supone una forma de que todos los sistemas operativos acepten una forma de RAID por software común. Y por eso le llaman fakeRAID (fake=falso, falsificación), porque parece que nos estén vendiendo un robusto RAID por hardware cuando es un simple RAID por software en el que el chipset tiene poca intervención.

(...)

Leer el resto de Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID (1,930 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 52 comentarios
Etiquetas: Debian, dmraid, filesystems, GNU/Linux, GRUB, initrd, Kernel, RAID, Ubuntu

Feed enhanced by Better Feed from Ozh

Los habituales de este blog sabrán que tengo un par de placas VIA EPIA (una SP8000E y una EX10000EG) y que en diferentes entradas he tratado de explicar mi experiencia con ellas en Linux:

• Sobre las VIA EPIA (I): Introducción al formato Mini-ITX y a las placas EPIA
• Sobre las VIA EPIA (II): Mi ordenador basado en una SP8000E
• Sobre las VIA EPIA (III): Linux en una SP8000E
• Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG
• Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux
• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG

A menudo me preguntan que qué tal van estas placas en Linux y la respuesta rápida y directa, escondida entre los centenares de líneas de las entradas anteriores es: Las placas VIA EPIA (y podemos generalizar hablando de cualquier placa basada en un procesador y en un chipset de VIA) funcionan excepcionalmente bien como servidores domésticos de bajo consumo y nulo ruido y también funcionan razonablemente bien para tareas de escritorio 2D (navegar, correo, mensajería instantánea, ofimática, etc.), aunque según el driver y el chipset, también podemos encontrarnos con notorios cuelgues e inestabilidades del driver.

(...)

Leer el resto de VIA anuncia una iniciativa para mejorar los drivers de Linux (1,849 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 16 comentarios
Etiquetas: drivers, GNU/Linux, openChrome, VIA, VIA EPIA

Feed enhanced by Better Feed from Ozh

• ¿Realmente queremos tener un hosting casero?
• El servidor
• El proveedor de Internet
• El dominio
• El sistema operativo
• El router
• El servidor web
  • Configuración de los sitios virtuales
  • Poniendo en marcha la nueva configuración
  • MaxClients
  • Moderación con el tamaño de lo que publicamos
  • Un poco de SEO para ahorrar ancho de banda
  • Apache HTTP server benchmarking tool
• El servidor de correo
  • Correo con nuestro propio dominio con Google Apps
• Otras cuestiones
  • Backups
  • El sistema de respaldo
  • Los cortes de corriente
  • Mantenimiento remoto
  • ¿P2P y hosting casero?
  • Scripting
• Conclusión

(...)

Leer el resto de Hosting casero HOWTO (10,593 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 129 comentarios
Etiquetas: Apache, backup, blog, ddclient, Debian, DNS, DynDNS, exim, GNU/Linux, Google, hosting, Internet, modem, MySQL, OpenSSH, PHP, rsync, shell, SMTP, spam, VIA EPIA, wget, WordPress, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

Veréis, yo tengo una línea en el fichero /etc/fstab para que al arrancar me monte automáticamente un directorio compartido por samba de otro sistema:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
[...]
//sistemaremoto/supercoco /mnt/sistemaremoto smbfs uid=supercoco,credentials=/etc/sistemaremotosmb 0 0

La opción credentials=/etc/sistemaremotosmb la uso para no tener la contraseña a usar tan visible. Usando un archivo diferente, le puedo poner permisos muy restrictivos. Es lo que aconseja la página de man de mount.smbfs

credentials=<filename>
   specifies a file that contains a username and/or password. The  for-
   mat of the file is:

          username = <value>
          password = <value>

   This  is  preferred  over  having passwords in plaintext in a shared
   file, such as /etc/fstab. Be sure to protect  any  credentials  file
   properly.

Así que mi fichero /etc/sistemaremotosmb tenía este aspecto:

# cat /etc/sistemaremotosmb
username = supercoco
password = barriosesamo

# ll /etc/sistemaremotosmb
-rw------- 1 root root 38 2008-02-09 07:44 /etc/sistemaremotosmb

Pues bien, hace unos días actualicé los paquetes de Lenny/Testing y a continuación me encontré con el siguiente problema al intentar montar el directorio compartido:

# mount /mnt/sistemaremotosmb/
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

(...)

Leer el resto de El SMB ha muerto, viva el CIFS: mount error 13 = Permission denied (762 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 16 comentarios
Etiquetas: Debian, GNU/Linux, Kernel, Samba

Feed enhanced by Better Feed from Ozh

En esta entrada voy a contar un extraño problema de corrupción que he tenido con MySQL y cómo lo he solucionado a mi manera. Yo estoy aún empezando con MySQL y estoy un poco verde, así que seguro que he hecho alguna barbaridad que si alguno de vosotros detecta me encantaría que mencionara en los comentarios.

Yo tengo en /var/lib/mysql/ tres bases de datos, una de WordPress, otra de pruebas de WordPress y otra para MythTV:

# ll
total 20588
drwxr-xr-x  9 mysql mysql     4096 2008-01-27 20:47 ./
drwxr-xr-x 50 root  root      4096 2008-01-27 14:17 ../
-rw-r--r--  1 mysql mysql        0 2008-01-10 10:20 debian-5.0.flag
-rw-rw----  1 mysql mysql  5242880 2008-01-27 20:48 ib_logfile0
-rw-rw----  1 mysql mysql  5242880 2006-12-20 20:42 ib_logfile1
-rw-rw----  1 mysql mysql 10485760 2008-01-27 20:48 ibdata1
drwx------  2 mysql root      4096 2008-01-27 20:47 mysql/
-rw-------  1 mysql mysql        4 2006-12-20 20:42 mysql_upgrade.info
-rw-------  1 mysql mysql        6 2007-02-26 11:40 mysql_upgrade_info
drwx------  2 mysql mysql    12288 2006-12-23 11:22 mythconverg/
drwx------  2 mysql mysql     4096 2007-11-11 21:10 wordpress/
drwx------  2 mysql mysql     4096 2008-01-27 13:20 wordpress_dev/

También está la base de datos principal “mysql” que contiene información que necesita almacenar MySQL, como usuarios, privilegios y cosas así.

(...)

Leer el resto de Corrupción en MySQL: ERROR 2006 (HY000): MySQL server has gone away (3,051 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 10 comentarios
Etiquetas: Debian, GNU/Linux, MySQL, MythTV, WordPress

Feed enhanced by Better Feed from Ozh

La libtrash es una librería que, cuando se carga, intercepta las llamadas al sistema: unlink() y unlinkat(). Con esta intercepción podemos, en vez de efectivamente borrar el fichero, moverlo a un directorio de papelera. Esto ya suelen hacerlo los escritorios como KDE o GNOME a más alto nivel, pero si en un momento dado hacemos un rm desde un terminal, el fichero no irá a la papelera del escritorio.

Lo primero, claro, es instalar la librería. Afortunadamente, en Debian y en Ubuntu ya tenemos un paquete listo en los repositorios, que podemos instalar fácilmente con apt-get:

# apt-get install libtrash

(...)

Leer el resto de La libtrash, la papelera de la línea de comandos (1,468 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Debian, GNU/Linux, libtrash, papelera, Ubuntu

Feed enhanced by Better Feed from Ozh

Como hemos ido viendo en distintas entradas sobre las VIA EPIA, la verdad es que casi todo el hardware de VIA se puede configurar en Linux sin problemas. Casi todo excepto el procesador gráfico, que en muchas ocasiones es una fuente horrible de problemas.

Desde hace unos días se viene hablando animadamente en el foro de VIA sobre este tema: Decent Linux Drivers: Seriously, what is going on? y finalmente, el usuario Effenberg0x0 ha creado una:

Petición Online para solicitar unos drivers decentes de VIA para Linux (petitiononline.com)

Tanto si tenemos hardware de VIA y estamos directamente afectados por estos problemas como si sólo somos usuarios de Linux y queremos que este sistema operativo crezca, mejore, que nadie tenga problemas de hardware mal soportado y que los fabricantes (en este caso VIA) comiencen a tenernos un poco más de respeto, creo que es importante firmar. Puede ser buena idea también difundir la petición entre los conocidos que tengamos que puedan estar interesados en este tema. ¡Demostrémosles que los usuarios de Linux cada vez somos más y que no deberían de ignorarnos tan alegremente! (Relacionado: La importancia de comprar hardware con drivers abiertos, Pero, ¿qué les pasa a los fabricantes de hardware?).

Para que todo el mundo pueda entender bien lo que está firmando, he considerado conveniente traducir la petición.

(...)

Leer el resto de Petición para que VIA tome una postura clara respecto a Linux (931 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 27 comentarios
Etiquetas: drivers, GNU/Linux, Hardware, VIA, VIA EPIA

Feed enhanced by Better Feed from Ozh

I firmly believe that, all else being equal, the differences between the Windows desktop, the Macintosh desktop, and the Linux desktop are negligible. With the proper applications, all three platforms will be capable of providing a satisfactory experience for any user. All three platforms have both free and commercial products available for personal productivity, web browsing, and basic multimedia. Yet, Windows dominates. Why? After all …

Por otro, el comentario del administrador de IT de los colegios de la zona de que tienen que usar Citrix para que los adultos usen Windows porque es a lo que están acostumbrados, mientras que los niños no tienen ningún problema con Linux:

“One key to all this is that we’re using Citrix (as the bridge) to run Windows apps on thin-client terminals — which the adults are most used to — on the new SUSE Linux 10.1 servers,” Carver told DesktopLinux.com. “The kids, well, they adjust to new operating systems and applications very quickly, so a changeover to Linux is no big deal.”

(...)

Leer el resto de El mito de que Windows es fácil (II) (373 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 7 comentarios
Etiquetas: GNU/Linux, Windows

Feed enhanced by Better Feed from Ozh

Un Seagate FreeAgent Pro es un disco duro externo de hasta 750GB con USB 2.0, eSata y Firewire (algunos modelos sólo USB 2.0) con este aspecto:

Pues bien, para empezar, viene formateado con NTFS, algo que los usuarios de Linux podemos superar fácilmente usando NTFS-3G o cambiando el sistema de ficheros, pero que por de pronto, ya les obliga a poner en las especificaciones técnicas que en Mac OSX sólo se puede usar para lectura:

Operating System
Windows XP Home, Professional Edition or Windows 2000 Pro
Mac OSx 10.3, 10.4 as read only

Lo que es un desprecio bastante importante a Linux, también lo es para Mac OSX, pero con la diferencia de que mientras que Linux tiene una cuota de mercado -de sistemas que navegan por Internet con él- de un 0.63%, Mac OSX tiene una cuota de mercado de un 7.31% (Mac OS X market share sets new record at the end of 2007).

(...)

Leer el resto de Pero, ¿qué les pasa a los fabricantes de hardware? (718 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 12 comentarios
Etiquetas: drivers, GNU/Linux, Hardware

Feed enhanced by Better Feed from Ozh

Mirando las estadísticas desde el primer día, veo que esa entrada tiene cerca de tres veces más visitas que la segunda que más visitas tiene y es la única que tiene más visitas que la página principal del blog. Por supuesto, también es la que ha generado más comentarios con mucha diferencia.

Hay entradas que han tenido una cierta repercusión, que han salido en páginas importantes, que se han comentado bastante en los foros… ¡Pero no! Resulta que es esa y precisamente esa la que más visitas tiene.

Y que sea esa y no otra, os prometo que me tortura la moral un día tras otro cuando veo las estadísticas.

Con todos ustedes… “Lo hice y lo entendí” tiene el gusto de presentarles… ¡a la peor pesadilla de su creador! ¡TACHÁN!

(...)

Leer el resto de El mito de que Windows es fácil (2,379 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 46 comentarios
Etiquetas: blog, GNU/Linux, hoygan, Windows

Feed enhanced by Better Feed from Ozh

rsync es una herramienta para sincronizar los ficheros y directorios que tenemos almacenados en un sitio en otro diferente minimizando la transferencia de datos (Wikipedia: rsync). En realidad, rsync son dos cosas: un algoritmo de delta compression para sincronizar dos ficheros similares y una utilidad que usa dicho algoritmo junto con otras técnicas para hacer mirroring de ficheros y directorios en otro sitio transfiriendo la mínima cantidad de datos posible.

(...)

Leer el resto de Backups con rsync (3,566 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 82 comentarios
Etiquetas: backup, Cygwin, GNU/Linux, OpenSSH, rsync, Windows

Feed enhanced by Better Feed from Ozh

Cómo hacer esto en concreto varía entre implementaciones de cliente y servidor de SSH, pero si estamos usando OpenSSH, que es lo estándar tanto en Linux y *BSD, como en Cygwin, sólo hay que seguir unos sencillos pasos que vamos a ver a continuación.

(...)

Leer el resto de Autentificación trasparente por clave pública/privada con OpenSSH (534 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 11 comentarios
Etiquetas: Debian, GNU/Linux, OpenSSH, PuTTY, SSH

Feed enhanced by Better Feed from Ozh

Pues bien, tras una de las frecuentes actualizaciones de Lenny/Testing me encuentro estos errores:

Checking battery state...
/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
SG_IO: bad/missing ATA_16 sense data
 HDIO_DRIVE_CMD failed: Input/output error

/dev/sdb:
 setting Advanced Power Management level to 0xfe (254)

/dev/sdc:
 setting Advanced Power Management level to 0xfe (254)

/dev/sdd:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Invalid argument

/dev/sde:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Invalid argument

/dev/hda:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error

/dev/hdb:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error

Hace ya varios meses de que saltara la bomba aquella de que Ubuntu dañaba los discos duros: Linux no mata discos duros, se mueren solos. Y precisamente en aquella ocasión, pudimos ver que Debian Etch no ejecutaba ningún comando hdparm (fuera de lo especificado en /etc/default/hdparm, claro), por lo que el comportamiento que tuviera el disco sería el que el fabricante le pusiera por defecto, y de ahí la afirmación de que ni Ubuntu, ni Debian, ni ningún Linux estropeaban el disco duro por este motivo, sino que era cosa de los fabricantes que hacían una tecnología de discos duros que por defecto se comportaba de forma dañina para los propios discos.

(...)

Leer el resto de A vueltas con el “hdparm -B” en Debian Lenny (1,067 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 11 comentarios
Etiquetas: APM, clicks, Debian, GNU/Linux, hdparm, Ubuntu

Feed enhanced by Better Feed from Ozh

La motivación de un ladrón será mayormente económica y en la inmensa mayoría de los casos no buscará específicamente nuestro portátil, ya que muchas veces será un efecto colateral de un robo más amplio (robo en una vivienda, en un coche, del equipaje durante un viaje…). Sin embargo, también puede darse el caso de que nuestro portátil haya desaparecido por motivos relacionados con la información que contiene.

(...)

Leer el resto de ¿Piensas en si un día te roban el portátil? (2,293 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 27 comentarios
Etiquetas: backup, cifrado, ddclient, Debian, DynDNS, geolocalización de IP, GNU/Linux, rsync, seguridad, TrueCrypt, Windows

Feed enhanced by Better Feed from Ozh

¿Por qué podemos querer compilar el kernel? Pues normalmente porque tengamos algún hardware que no esté soportado por el kernel estándar de la distribución (por ejemplo, en este blog, lo hemos usado mucho cuando hablábamos de compilar los drivers gráficos para los chipsets de las VIA EPIA) o porque haya alguna aplicación que necesite crear módulos del kernel para poder trabajar, como por ejemplo el VMWare o el kqemu. En Cómo mantener los acentos y las eñes al montar NTFS, FAT o smbfs y al compartir directorios con Samba también lo usamos para modificar el juego de caracteres a usar por defecto. Hace poco, en Probando la netconsole de Linux, también nos hizo falta recompilarlo, así como en Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel y en Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.

La mayoría de las distribuciones esperan que se compile e instale el kernel con sus herramientas específicas. En el caso de Debian y Ubuntu, normalmente con la herramienta make-kpkg del paquete kernel-package, como podemos leer en:

• The Debian GNU/Linux FAQ Chapter 9 – Debian and the kernel
• Debian Reference Chapter 2 2.7 Debian and the kernel
• Debian Reference Chapter 7 – The Linux kernel under Debian
• Ubuntu Documentation Kernel/Compile
• How To Compile A Kernel – Debian Etch
• How To Compile A Kernel – The Ubuntu Way

Y de hecho, las distribuciones ya suelen llevar sus fuentes del kernel preparadas a su medida:

# apt-cache search linux-source
linux-patch-debian-2.6.22 - Debian patches to version 2.6.22 of the Linux kernel
linux-source-2.6.22 - Linux kernel source for version 2.6.22 with Debian patches
linux-tree-2.6.22 - Linux kernel source tree for building Debian kernel images

Sin embargo yo, como buen abuelo cebolleta de Linux, sigo haciéndolo como lo he hecho toda la vida, de una forma totalmente independientemente de la distribución usada.

Lo primero es descargar el kernel deseado de www.kernel.org. Los kernels disponibles en este sitio son denominados vanilla kernels, indicando con este nombre que son puros en el sentido de que son tal cual los desarrolladores del kernel los han liberado. Posteriormente las distribuciones suelen distribuir kernels parcheados para añadir funcionalidades que no existen en el kernel vanilla (por ejemplo, el bootsplash o la hibernación con TuxOnIce) o para añadir soporte a hardware que no está aún soportado. No es raro ver en las listas de distribución de proyectos que incluyen parches del kernel que antes de permitirte abrir un bug te pidan que pruebes con un parche vanilla para descartar que los parches de tu distribución estén causando el comportamiento indeseado.

(...)

Leer el resto de Compilar el kernel de Linux (1,725 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 30 comentarios
Etiquetas: Debian, GNU/Linux, GRUB, initrd, Kernel, patch, Ubuntu, VMWare

Feed enhanced by Better Feed from Ozh

Por haber nombrado a la HVR3000 comenzaron a llegar bastantes visitantes que buscaban cómo configurarla en Linux. Dos de ellos, Alberto y Sergio, comenzaron a tratar el tema en los comentarios y posteriormente se les unió X04n 2.0 que con las pistas previas dio con la solución definitiva, que documentó de forma excelente. Yo no tengo una HVR3000, por lo que no puedo probar personalmente si realmente funciona, pero como creo que sí, he pensado que no está de más dedicarle una entrada.

El problema de la HVR3000 es que, aunque aparece en el Documentation/video4linux/CARDLIST.cx88 de las fuentes de un kernel 2.6.22.10:

 53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T  [0070:1404,0070:1400,0070:1401,0070:1402]

y está definida en el fichero drivers/media/video/cx88/cx88-cards.c:

        [CX88_BOARD_HAUPPAUGE_HVR3000] = {
                /* FIXME: Add dvb & radio support */
                .name           = "Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T",
                .tuner_type     = TUNER_PHILIPS_FMD1216ME_MK3,
                .radio_type     = UNSET,
                .tuner_addr     = ADDR_UNSET,
                .radio_addr     = ADDR_UNSET,
                .tda9887_conf   = TDA9887_PRESENT,
                .input          = {{
                        .type   = CX88_VMUX_TELEVISION,
                        .vmux   = 0,
                        .gpio0  = 0x84bf,
                },{
                        .type   = CX88_VMUX_COMPOSITE1,
                        .vmux   = 1,
                        .gpio0  = 0x84bf,
                },{
                        .type   = CX88_VMUX_SVIDEO,
                        .vmux   = 2,
                        .gpio0  = 0x84bf,
                }},
                .mpeg           = CX88_MPEG_DVB,
        },

vemos la nota “/* FIXME: Add dvb & radio support */“, indicando que aún no hay soporte de la mayor parte de funciones de la tarjeta.

El desarrollador del proyecto V4L Steve Toth (por la dirección de correo parece que es empleado de Hauppauge) estuvo trabajando hasta Octubre de 2006 en el soporte de esta tarjeta: hvr3000 development repository. En la lista de distribución de DVB de linuxtv.org, Steve contó que sus drivers son, de momento, una proof of concept ([linux-dvb] Hauppauge WinTV HVR 3000 Questions):

they are not ready for merging into the mainline and are proof of
concept patches to handle multiple DVB frontends on a single shared
transport bus. They worked fairly reliably last I tried, although they
need to cleanup and sanity checks before any merge could occur.

Pero claro, por aquellas fechas el último kernel disponible era el 2.6.18 y desafortunadamente estos drivers no funcionan en kernels posteriores ([linux-dvb] HVR-3000: fixed by downgrading kernel, any ~stoth/hvr3000 patches for >2.6.18 kernels?):

> Does anyone know if any *working* patches exist to get Steve Toth’s HVR-3000
> driver (currently in hg under ~stoth/hvr3000) working on newer kernels? I got
> it to compile fairly well, it just didn’t do much after it was compiled…

The best bet is to compile steven’s branch (~stoth/hvr3000) with vanilla
kernel 2.6.18. Changes introduced in this branch include support for
multiple exclusive frontends on a single bus, it’s somehow experimental
and it will need several changes prior to include in the main branch.

Analog works ok, DVB-T ok, DVB-S working with some troubles with diseq.

En un mensaje a la lista más reciente (Jul/07) nos enteramos de que la inclusión de drivers para esta tarjeta está a la espera de la inclusión de multi-protocol code en el V4L. ¿Tal vez porque tiene que soportar a la vez DVB-T y DVB-S como decía Steve (“handle multiple DVB frontends on a single shared transport bus“)? ([linux-dvb] [Fwd: Re: OHauppauge WinTV HVR-3000 or 4000]):

The HVR-3000 is “supported” by a branch created by Steven Toth. It’s
not seen any updates in a while, and currently (as far as I know)
doesn’t compile with kernels after 2.6.18. It’s working ok for me here
though. I think the reason for no updates / lack of inclusion in
mainline dvb is that he is waiting for some sort of multi-protocol code
to be implemented into the mainline dvb code.

La Hauppauge WinTV-HVR-4000 es una tarjeta que además de soportar TV analógica, DVB-T y DVB-S como la HVR3000, soporta DVB-S2 (emisiones por satélite en alta definición) y TDT en alta definición (a España aún no ha llegado). Pues bien, en la lista de distribución hablan a menudo también de la HVR4000 relacionándola con la HVR3000 porque el soporte de ambas parece que va relacionado. En ese contexto, me temo que es totalmente desalentador para los propietarios de una HVR3000 oir de boca de Steve hace menos de un mes (11/11/07) que mejor olvidar la HVR3000 y comprar una HVR4000 en eBay ([linux-dvb] Future of HVR3000?):

James A R Brown wrote:
> I guess this email is more for Steve and Manu.
>
> It is very pleasing to see the work going on for the HVR4000 and pushing
> the multiproto tree back into the main tree.
>
> Infact its a breath of fresh air as I have sadly watched the HVR3000
> branch be stripped to DVB-T and merged in without the DVB-S Support and
> was actually wondering if the card would be simply passed over by
> LinuxTV. It probably almost has by the HVR4000, but then again HVR3000
> is becoming a cheap card in the UK. (1/2 price of HVR4000)
>
> So my question is, once HVR4000 and multiproto are back in the main
> tree, are there any plans to also merge in the HVR3000 tree with
> multiproto support or should I stick them on ebay and look to the HVR4000?

Use ebay.

- Steve

(...)

Leer el resto de Configurar una Hauppauge WinTV-HVR-3000 en Linux (1,303 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 84 comentarios
Etiquetas: CX88, Debian, DVB-S, DVB-T, GNU/Linux, Hauppauge WinTV-HVR-3000, Kernel, patch, V4L

Feed enhanced by Better Feed from Ozh

It can be used either built-in or as a module. As a built-in,
netconsole initializes immediately after NIC cards and will bring up
the specified interface as soon as possible. While this doesn't allow
capture of early kernel panics, it does capture most of the boot
process.

No confundamos la netconsole de Linux con la “LAN Console” de los grandes sistemas UNIX, que es simplemente un chip independiente del sistema que redirige la salida de la consola serie típica a un pequeño servidor de telnet, por ejemplo, y que nos permite interactuar con la consola por la red pero exactamente igual que si estuviéramos conectados con cualquier tipo de terminal serie. La netconsole de Linux es más bien un netlogging o un “kernel-level network logging via UDP packets” tal y como se referían a ella cuando sacaron el primer parche que lo permitía: [patch] netconsole – log kernel messages over the network. 2.4.10.

La forma de usarla es:

It takes a string configuration parameter "netconsole" in the
following format:

 netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]

   where
        src-port      source for UDP packets (defaults to 6665)
        src-ip        source IP to use (interface address)
        dev           network interface (eth0)
        tgt-port      port for logging agent (6666)
        tgt-ip        IP address for logging agent
        tgt-macaddr   ethernet MAC address for logging agent (broadcast)

Examples:

 linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc

  or

 insmod netconsole netconsole=@/,@10.0.0.2/

Built-in netconsole starts immediately after the TCP stack is
initialized and attempts to bring up the supplied dev at the supplied
address.

The remote host can run either 'netcat -u -l -p <port>' or syslogd.

En el kernel por defecto de Debian el netconsole viene como módulo, no integrado en el kernel:

# grep -i netconsole /boot/config-2.6.18-5-686
CONFIG_NETCONSOLE=m

(...)

Leer el resto de Probando la netconsole de Linux (1,249 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: consola, Debian, GNU/Linux, GRUB, syslog, terminal

Feed enhanced by Better Feed from Ozh

El puerto de red asignado al syslog es el 514/UDP:

# grep syslog /etc/services
syslog          514/udp

Sin embargo, el proceso syslogd de Debian no se conecta a ese puerto porque no escucha mensajes de la red por defecto. Si queremos que lo haga, tenemos que editar el fichero /etc/default/syslogd, que en la configuración estándar no contiene ninguna opción:

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD=""

Si queremos que escuche de la red, hemos de especificar la opción -r:

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD="-r"

que sirve precisamente para esto:

       -r     This option will enable the facility to receive message from the
              network using an internet domain socket with the syslog  service
              (see  services(5)).   The default is to not receive any messages
              from the network.

y reiniciar el proceso con “/etc/init.d/sysklogd restart“. Tras esto, podremos comprobar que el demonio funciona con la opción deseada

# ps -ef | grep syslog
root      4547     1  0 17:35 ?        00:00:00 /sbin/syslogd -r

y que el proceso está escuchando en el puerto 514/UDP:

# netstat -a | grep syslog
udp        0      0 *:syslog                *:*

Puesto que los mensajes del Zyxel van a llegar por la facility local2, podemos querer establecer un fichero de log específico para él en el /etc/syslog.conf (para que se relea después de modificarlo, haremos un “/etc/init.d/sysklogd reload“):

local2.* /var/log/zyxel.log

Si quisiéramos que fuera un sistema Linux (por ejemplo, una Debian) el que mandara ciertos mensajes a un syslog remoto, podríamos hacerlo simplemente poniendo en el syslog.conf una línea como:

local3.* @sistemaremoto.dominio

Tras releer la configuración, con una sencilla prueba con el comando logger:

logger -p local3.info "Mensaje de prueba"

veremos que, efectivamente, el mensaje aparece en el sistema remoto en varios logs configurados para recibir mensajes de la prioridad formada por la pareja facility/level que hemos especificado:

# grep "Mensaje de prueba" /var/log/*
/var/log/messages:Dec  8 18:18:15 ordenador logger: Mensaje de prueba
/var/log/syslog:Dec  8 18:18:15 ordenador logger: Mensaje de prueba

Recordemos que las facilities son:

• auth, security ¹
• authpriv
• cron
• daemon
• ftp
• kern
• lpr
• mail
• mark (sólo para uso interno)
• news
• sys-log
• user
• uucp
• local0 → local7

y los levels:

• debug
• info
• notice
• warning, warn ¹
• error, err ¹
• crit
• alert
• emerg, panic ¹

1. En los casos en que aparecen dos etiquetas juntas, la segunda es equivalente a la primera y está obsoleta.

Si tomamos una traza de red vemos que el protocolo (BSD syslog Protocol) es extraordinariamente sencillo (RFC 3164):

Podemos ver que la prioridad es un byte que contiene la facility (5bits) y el level (3bits).

Con un simple netcat también podemos mandar mensajes a un syslogd remoto que esté escuchando la red, aunque no pongamos la cabecera con la prioridad y la fecha del evento:

# echo "Nuevo mensaje de prueba con el netcat" | netcat -q 0 -u 192.168.1.20 514

y en el /var/log/syslog remoto encontramos el mensaje:

Dec  8 18:39:15 ordenador Nuevo mensaje de prueba con el netcat

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Debian, GNU/Linux, syslog, UNIX, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

En los escritorios moderno, es fácil configurar la ventana para mantener el xconsole en primer plano.

Aunque la documentación de xconsole diga que accede a /dev/console, en muchas distribuciones (Make xconsole work), para evitar multitud de problemas que ocasiona engancharlo al /dev/console relacionados con la no posibilidad de teclear en las ventanas (sólo con hacer un “xconsole -file /dev/console“, se puede comprobar inmediatamente), normalmente las distribuciones crean una named pipe en /dev/xconsole:

# ll /dev/xconsole
prw-r----- 1 root adm 0 2007-12-08 12:27 /dev/xconsole|

en la que el syslogd escribe, como vemos en el /etc/syslog.conf de Debian:

# The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
# you must invoke `xconsole' with the `-file' option:
#
#    $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
#      busy site..
#
daemon.*;mail.*;\
        news.err;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       |/dev/xconsole

Si queremos que algún usuario distinto de root pueda usar el xconsole, habrá que asignarlo al grupo adm (al menos en Debian), pero parece más conveniente simplemente crear un acceso directo usando kdesu o gksu para que nos pregunte el password de root antes de ejecutar el xconsole:

Para limpiar los mensajes actuales de la ventana del xconsole, podemos hacer un CONTROL+C sobre ella, como descubrimos en el fichero /etc/X11/app-defaults/XConsole:

*text.baseTranslations:         #override\
        Ctrl<KeyPress>C:        Clear() \n\
        <KeyPress>Clear:        Clear()

Si queremos una especie de equivalente al xconsole en la consola de texto, el syslog.conf estándar de Debian ya nos ofrece una configuración perfectamente válida. Descomentando estas las líneas que envían varias áreas de syslog al /dev/tty8 podremos verlos simplemente pulsando ALT+8 o ALT+CONTROL+8 si estamos en las X:

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
daemon,mail.*;\
        news.=crit;news.=err;news.=notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       /dev/tty8

Tras los cambios al syslog.conf, podemos hacer un /etc/init.d/sysklogd reload para que el cambio tenga efecto.

Hay que tener en cuenta que cualquiera con acceso físico a la máquina (incluso sin usuario válido) podrá ver estos mensajes que pueden llevar información sensible, de forma que hay que usarlo con mucha precaución. Por eso está deshabilitado por defecto.

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Debian, gksu, GNU/Linux, kdesu, syslogd, X Window System, xconsole

Feed enhanced by Better Feed from Ozh

Los PCs no están bien preparados para tener como única posibilidad de entrada/salida un terminal serie. Al menos no durante el arranque y para configurar la BIOS. Una vez que el sistema operativo o el GRUB toma el control ya sí que podemos usar el puerto serie para gestionar el ordenador. Pero es precisamente en circunstancias muy dramáticas cuando nos puede interesar especialmente controlar el arranque remotamente. Por eso hay fabricantes de servidores x86 cuyos sistemas permiten redirigir la salida de la BIOS a un puerto serie, como por ejemplo la HP BIOS Serial Console. Para ampliar información sobre servidores con esta posibilidad, podemos leer sobre IPMI y sobre Out-of-band management o Lights-out management. En la web en japonés sobre la tarjeta Lights-Out 100 de HP podemos ver capturas de una BIOS por el puerto serie.

En cualquier caso, en PCs normales no tenemos esta posibilidad. El primer momento en el que podemos comenzar a redirigir la salida estándar es en el GRUB. El segundo momento es al arrancar el kernel de Linux. El tercero es cuando el sistema operativo ya está totalmente arriba.

Veamos cómo acceder a la consola por el puerto serie una vez que el sistema está arriba y luego veremos qué dificultades presentan los otros casos.

(...)

Leer el resto de Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP (2,559 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 18 comentarios
Etiquetas: consola, Debian, GNU/Linux, GRUB, minicom, modem, PPP, RAS, terminal, UNIX

Feed enhanced by Better Feed from Ozh

Sin embargo, parece un despropósito que el servidor web tenga que estar comprimiendo una y otra vez los mismos contenidos. Supone estar forzando al procesador a usar ciclos que pueden sernos necesarios para otra tarea en algo que debería de poder evitarse. Afortunadamente, gracias al módulo mod_cache, podemos conseguir evitar esta sobrecarga inútil para el servidor.

En realidad, este módulo tiene su máxima utilidad para configurar Apache como servidor Proxy o como Proxy Inverso (mediante el mod_proxy), ya que gracias a la caché, podemos evitar que Apache vuelva a pedir el mismo contenido al servidor final repetidas veces. Para un servidor normal, no parece que una caché pueda proporcionarnos una gran mejora de rendimiento, incluso aunque cacheemos en memoria. Sin embargo, si lo combinamos con el mod_deflate, sí que podemos conseguir que los documentos servidos se almacenen ya comprimidos en la caché ahorrándonos así un elevado e inútil uso de la CPU causado por la compresión repetidas veces de lo mismo.

El documento de referencia para conocer cómo Apache cachea a través del mod_cache es el Apache HTTP Server Version 2.2: Caching Guide, y proporciona sus servicios a través de otros tres módulos que dependen de él: mod_disk_cache, mod_mem_cache, mod_file_cache.

El mod_file_cache es el menos flexible de los tres. Sirve para cachear ficheros concretos en disco o memoria, pero si modificamos alguno de dichos ficheros sólo podremos conseguir que Apache sirva la versión actualizada con un reinicio del gestor:

So whenever one of the mapped files changes on the filesystem you have to restart the server. To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. You should update files by unlinking the old copy and putting a new copy in place. Most tools such as rdist and mv do this.

El mod_mem_cache nos permite cachear los ficheros en memoria. Sin embargo, lo que teóricamente podría suponer un a gran mejora de rendimiento del servidor, puede quedarse en mucho menos por dos motivos (In-Memory Caching):

• Por un lado, forzar a Apache a usar una gran cantidad de memoria para cachear los ficheros del sistema puede causar que el sistema se vaya quedando corto de memoria para otras tareas llegando a swapear y causando que el rendimiento caiga en picado.
• Por otro lado, los sistemas operativos modernos hacen un excelente trabajo cacheando ficheros que se usan frecuentemente, especialmente si hay memoria de sobra. Además, saben perfectamente cuándo el fichero se ha modificado y hay que renovarlo en la caché y saben cuando hay que dejar de cachear porque el sistema se va quedando corto de memoria. ¿Realmente necesitamos que Apache cachée esos mismos ficheros?

El mod_disk_cache va almacenando en un directorio los documentos que se van solicitando, así como sus cabeceras. Si el mod_deflate está activo y hay unos clientes que aceptan compresión y otros que no, se cacheará el documento comprimido y sin comprimir. Por supuesto, no debemos olvidar que la caché del sistema operativo está actuando, así que estos ficheros de caché, si hay memoria suficiente, también serán cacheados en memoria por el kernel.

Por tanto, el mecanismo de caché para almacenar el contenido comprimido que parece más conveniente en muchas situaciones es el del mod_disk_cache y en él nos vamos a centrar en lo sucesivo.

(...)

Leer el resto de Usando el mod_cache de Apache para que el mod_deflate no incremente la carga del servidor (1,492 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Apache, Debian, GNU/Linux, HTTP, mod_cache, mod_deflate, mod_disk_cache

Feed enhanced by Better Feed from Ozh

En efecto, si tomamos una traza de red (p.e. con WireShark) de una petición de un navegador (p.e. Iceweasel) a un servidor web, veremos que éste le dice al servidor web que acepta el contenido comprimido por gzip o por deflate (es decir, zlib):

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.8-1)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

En Firefox, podemos usar el parámetro del about:config network.http.accept-encoding para especificar exactamente qué queremos tener para esa entrada de la cabecera, siendo el valor por defecto “gzip,deflate“.

Por su parte, el servidor web Apache 2 es capaz de atender esas peticiones de compresión por medio del módulo mod_deflate.

En Debian, el módulo ya viene en el paquete estándar de apache2:

# dpkg -S deflate.load
apache2.2-common: /etc/apache2/mods-available/deflate.load

Sin embargo, no viene activado por defecto. Para habilitarlo, tenemos que crear un enlace en el directorio mods-enabled:

# cd /etc/apache2/mods-enabled/
# ln -s ../mods-available/deflate.load deflate.load

Además, tendremos que elegir las opciones de configuración que más nos puedan interesar. Como la compresión de según qué tipos de ficheros con según qué versiones de navegador puede dar problemas, una solución que nos comprime prácticamente todos los ficheros de texto típicos de una página sin crear mayores problemas es usar la directiva AddOutputFilterByType diciéndole que comprima ficheros HTML, CSS, JavaScript y de texto:

AddOutputFilterByType DEFLATE text/html text/plain text/css application/x-javascript

Tras esto, es conveniente revisar que la sintaxis es correcta con un “apache2ctl configtest” y reinciar el servidor para que se use la nueva configuración sin cortar las conexiones existentes al servidor web con un “apache2ctl graceful“.

Tras aplicar estos cambios, la contestación del servidor web a la petición anterior del navegador será ésta, aceptando la compresión y enviando la página comprimida a continuación:

HTTP/1.1 200 OK
Date: Fri, 23 Nov 2007 16:14:42 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7
X-Powered-By: PHP/5.2.0-8+etch7
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Fri, 23 Nov 2007 16:14:43 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 22266
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Si queremos comprobar el buen funcionamiento de este módulo, podemos usar el wget, versátil herramienta que nos permite descargar documentos desde línea de comandos mediante HTTP y FTP.

Por defecto, el wget manda unas cabeceras muy sencillas:

GET / HTTP/1.0
User-Agent: Wget/1.10.2
Accept: */*
Host: www.example.com
Connection: Keep-Alive

Vemos que usa HTTP 1.0 y no indica ningún Accept-Encoding. Sin embargo, podemos usar la opción de línea de comandos --header para modificar las cabeceras y aceptar compresión.

Así, vemos que el fichero raíz de un servidor web que ocupa 78 KiB:

$ wget http://www.example.com
--18:10:02--  http://www.example.com
           => `index.html'
Resolving www.example.com... 10.12.34.56
Connecting to www.example.com|10.12.34.56|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [        <=>                          ] 80,206        40.26K/s

18:10:05 (40.18 KB/s) - `index.html' saved [80206]

únicamente ocupa 22 KiB si se pide comprimido:

$ wget --header="Accept-Encoding: gzip" http://www.example.com
--18:13:51--  http://www.example.com
           => `index.html'
Resolving www.example.com... 10.12.34.56
Connecting to www.example.com|10.12.34.56|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 22,143 (22K) [text/html]

100%[====================================>] 22,143        --.--K/s

18:13:55 (5.19 MB/s) - `index.html' saved [22143/22143]

Sin embargo, si examinamos ese fichero descargado, vemos que no es el fichero HTML que esperábamos, sino un fichero comprimido con gzip:

$ file index.html
index.html: gzip compressed data, from Unix

Sería necesario descomprimir el fichero para encontrar que tiene el tamaño y el contenido esperado:

$ mv index.html index.html.gz
$ gzip -d index.html.gz
$ ll index.html
-rw-r--r-- 1 root root 80206 2007-11-23 18:13 index.html
$ file index.html
index.html: HTML document text

Comprimir las páginas web antes de enviarlas supone una gran ventaja en circunstancias de ancho de banda limitado. Sin embargo, no hay que olvidar que el servidor tiene que estar permanentemente comprimiendo ficheros, lo que puede ocasionar que la CPU no dé abasto. Por tanto, hay que tener muy presente, antes de habilitar esta opción, si en situaciones de carga extraordinaria la limitación de nuestro servidor web está en la carga de CPU o en el ancho de banda disponible.

Finalmente, comentar que en la página www.http-compression.com podemos leer sobre qué navegadores soportan la compresión de las páginas, que son prácticamente todas las versiones modernas de los navegadores comunes: Firefox, Konqueror, Opera e Internet Explorer.

Por cierto, ¿sabías que example.com, example.org y example.net son dominios reservados para usar como ejemplo en la documentación?

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 13 comentarios
Etiquetas: Apache, Debian, GNU/Linux, gzip, HTTP, mod_deflate, wget, zlib

Feed enhanced by Better Feed from Ozh

attempt to access beyond end of device
sdb: rw=0, want=3636361172, limit=398297088
attempt to access beyond end of device
sdb: rw=0, want=3636361176, limit=398297088

Y uno de los problemas que me generaban estos errores es que me llenaban el buffer circular de mensajes del kernel y no podía ver los mensajes de arranque del kernel con dmesg.

Yo tengo dos discos Maxtor SATA iguales en RAID 0 usando los servicios de la placa con el chipset NVidia NForce 4. El RAID se activa automáticamente durante el arranque gracias a que el initrd ejecuta el comando dmraid durante el arranque (ya salió esto en Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.). Tras ejecutar el dmraid, unos nuevos ficheros de dispositivo que representan al disco lógico formado por los dos discos físicos son creados en /dev/mapper/ :

# ll /dev/mapper/
total 0
drwxr-xr-x  2 root root     180 2007-11-18 22:03 ./
drwxr-xr-x 14 root root    5880 2007-11-18 21:04 ../
crw-rw----  1 root root  10, 63 2007-11-18 22:03 control
brw-rw----  1 root disk 254,  0 2007-11-18 22:03 nvidia_bdehcbaa
brw-rw----  1 root disk 254,  1 2007-11-18 22:03 nvidia_bdehcbaa1
brw-rw----  1 root disk 254,  2 2007-11-18 22:03 nvidia_bdehcbaa2
brw-rw----  1 root disk 254,  3 2007-11-18 21:03 nvidia_bdehcbaa3
brw-rw----  1 root disk 254,  4 2007-11-18 22:03 nvidia_bdehcbaa5
brw-rw----  1 root disk 254,  5 2007-11-18 22:03 nvidia_bdehcbaa6

Los ficheros de dispositivo de los discos físicos (en mi caso /dev/sdb y /dev/sdc) no tienen ninguna utilidad desde ese momento.

(...)

Leer el resto de Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel (1,367 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 10 comentarios
Etiquetas: dd, Debian, dmraid, GNU/Linux, hal, initrd, Kernel, patch, udev

Feed enhanced by Better Feed from Ozh

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Con la vistas puesta en un asunto que tal vez trate en una futura entrada, estaba haciendo unas pruebas de guardar el código desde el navegador a un fichero .html y he descubierto algunas cosas interesantes…

La función wptexturize de WordPress

En primer lugar, que WordPress tiene una función/filtro llamado wptexturize (en wp-includes/formatting.php) que nos arregla el aspecto de algunos signos de puntuación. Por ejemplo, si al editar la entrada escribimos:

"prueba"

la función wptexturize, al crear la página final, lo sustituiría por

“prueba”

que es equivalente a

“prueba”

y que, renderizado por el navegador, queda con fancy quotes (comillas de apertura y cierre diferenciadas):

“prueba”

En What is Texturize? encontramos más ejemplos, y si queremos saber exactamente qué y cómo lo hace, podemos consultar el código de la función. También hay que tener en cuenta que hay fuentes que sacan las fancy quotes exactamente igual que las estándar, así que es posible que según la fuente usada no lo notemos.

Algunos navegadores guardan el código HTML codificado

La segunda cosa que he descubierto es que cuando guardas una página codificada en UTF-8 que tienes abierta en Firefox o en Internet Explorer, los códigos HTML como “ o ” (podemos consultar todos los códigos HTML en Character entity references in HTML 4) son sustituidos por sus secuencia de bytes correspondiente para formar el código UTF-8 que corresponde. Konqueror no lo hace así y deja los códigos tal y como van en la página.

Por ejemplo, supongamos que creamos un fichero HTML con el siguiente código:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Prueba</title>
</head>
<body>
Una palabra &ldquo;entrecomillada&rdquo; como ejemplo.
</body>
</html>

(...)

Leer el resto de Notas sobre la función wptexturize de WordPress, sobre los navegadores que convierten el código HTML a UTF-8 y sobre Unicode/UTF-8 (751 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Firefox, GNU/Linux, Icewesel, iconv, internacionalización, Internet Explorer, ISO-8859, juegos de caracteres, Unicode, UTF-8, WordPress, wptexturize

Feed enhanced by Better Feed from Ozh

# mount -t smbfs -o username=supercoco //pcconwindows/compartido /mnt/smb/
Password:
8070: tree connect failed: ERRDOS - ERRnomem (Insufficient server memory to perform the requested function.)
SMB connection failed

no le eches la culpa al Samba (como hizo un usuario de Ubuntu Feisty). Se trata de un problema conocido de Windows (Error message: “Not enough server storage is available to process this command”) y se puede solucionar fácilmente aumentando el parámetro IRPStackSize en el registro (Description of the IRPStackSize parameter in Windows 2000, in Windows XP, and in Windows Server 2003).

El IRPStackSize es:

The IRPStackSize parameter specifies the number of stack locations in I/O request packets (IRPs).

y ahí lo dejamos, porque no me atrevo a tratar de interpretar qué significa eso exactamente.

Su valor por defecto es de 15 (decimal) y el rango de valores permitido es de 11 (0xb hexadecimal) a 50 (0×32 hexadecimal) y se puede modificar en la siguiente rama del registro de Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Pero es muy posible que la primera vez no exista, por lo que tenemos que crear una nueva entrada DWORD para IRPStackSize e introducir el valor deseado. Yo he probado con 50 y, tras reiniciar (esto no lo dice el documento de Microsoft), el error ha desaparecido.

La pista sobre este problema me la ha dado un post a la lista de distribución de Samba ¡del 2002!: [Samba] Samba & W2K shares: ERRnomem: Insufficient server memory to perform the requested function

Finalmente, usar valores de 33 a 38 puede causar problemas: Event ID 2021 is logged even though lots of non-paged pool memory is available in Windows Server 2003.

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 5 comentarios
Etiquetas: GNU/Linux, Samba, Windows

Feed enhanced by Better Feed from Ozh

Yo sabía que existía el proyecto Suspend2, recientemente renombrado a TuxOnIce, y que parece ser que está dando muy buenos resultados. Pero fue cuando en la lista de novedades del kernel 2.6.20 leí que ya se incluían en el kernel grandes mejoras en la infraestructura necesaria para soportar la hibernación, que me decidí a retomar el tema.

Según leo en el artículo Suspend2 de la Wikipedia, parece que hay un tira y afloja entre los desarrolladores sobre si la parte que implementa Suspend2 debe de ir en el kernel o en el espacio de usuario. De momento, aún necesita parchear el kernel.

En cualquier caso, no hay que hacer muchas cosas para poder probar el TuxOnIce en una distribución que aún no lo soporte por defecto, y casi todas ellas vienen documentadas en el capítulo 2 del Software Suspend HOWTO. Resumiendo, hay que:

1. Verificar que tenemos bastante espacio en la swap para almacenar todo el contenido de la memoria. Si no lo hay, se puede usar compresión o un fichero dedicado a esto.
2. Parchear el kernel, compilarlo, instalarlo y arrancar con él.
3. Hacer un pequeño cambio en los scripts del initrd.
4. Añadir una opción de arranque al GRUB/LILO.
5. Ejecutar el script hibernate.

(...)

Leer el resto de Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (1,891 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 14 comentarios
Etiquetas: ar, cpio, Debian, dmraid, GNU/Linux, GRUB, hibernar, initrd, Kernel, patch, Suspend2, tar, TuxOnIce, UNIX

Feed enhanced by Better Feed from Ozh

• Configuración errónea de Ubuntu podría acortar la vida del disco duro de los portátiles
• Ubuntu podría acortar la vida del disco duro de los portátiles

Pues qué malo que es el Ubuntu ese, ¿no? Pues a mí no me lo parece, la verdad. A mí me parece que los fabricantes de discos duros nos están vendiendo productos artificialmente poco duraderos. Vayamos por partes.

Resulta que hay una tecnología de fabricación de discos duros llamada de Load/Unload (Un Whitepaper muy aconsejable en PDF sobre el tema: Ramp : Ramp Load/Unload Technology in Hard Disk Driver, encontrado en Broken HDDs) cada vez más extendida, sobre todo en discos duros de portátil. Consiste en que el cabezal de lectura/escritura, en vez de estar permanentemente volando sobre el disco, se aparca frecuentemente, lo que teóricamente permite una mayor duración del disco, menor consumo y mayor protección contra golpes.

Sin embargo, no se puede aparcar la cabeza un número indefinido de veces, sino que estos discos están preparados para un número máximo de ciclos de carga/descarga del cabezal que según el disco en cuestión puede ser de orden de 300K o 600K ciclos (K=1000). No es que justo cuando se llegue a ese número el disco va a dejar de funcionar de repente, sino que a partir de ahí el fabricante ya considera que puede dejar de hacerlo en cualquier momento. Paul nos cuenta que en varios de sus discos ha llegado a 600K, 900K y 1200K ciclos de carga/descarga antes de que empezaran a dar problemas. Pero eso sólo ¡en un año!

Yo me interesé por el problema nada más leer sobre él porque el disco de 2.5″ de marca Western Digital que tengo conectado a la EPIA EX10000EG (apareció de pasada en la entrada Sobre las VIA EPIA (V) ) hacía clicks muy frecuentemente. Lo notaba mucho porque cuando el disco se quedaba idle durante unos segundos, al volver al trabajajo casi siempre hacía un click que me disgustaba mucho pero que pensaba que sería normal (es un disco nuevo y tras varios tests no había encontrado ningún error). Ahora sé que cada vez que se oye uno de esos clicks lo más normal es que sea el cabezal en un ciclo de carga/descarga.

Pues bien, resulta que consultando los parámetros S.M.A.R.T. del disco con el comando smartctl, me encuentro con que el disco ya ha usado 7755 ciclos:

# smartctl -a /dev/hdc | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7755

Y no penséis que esta máquina se tira encendida semanas y semanas, ¡no!. Para llegar a ese número de ciclos, ese disco sólo ha pasado por una instalación de Debian y por todas las pruebas que le hice a la EX10000EG, incluyendo varios ratos de reproducción de vídeo. Por tanto, que haya consumido ya 7755 ciclos, que podría ser alrededor del 3% de los que el fabricante permite antes de que el disco sea declarado como “envejecido”, es una auténtica barbaridad.

En unas pruebas rápidas he podido ver que el número de ciclos crece muy rápidamente en pocos minutos y sin apenas usar la máquina:

Sun Oct 28 02:11:51 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7744
Sun Oct 28 02:15:51 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7753
Sun Oct 28 02:16:28 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7754

Como se comenta en los enlaces que hablan del problema, con el comando “hdparm -B” podemos modificar el nivel de gestión de energía que ha de tener el disco (usando APM):

# man hdparm
[...]
-B     Set  Advanced  Power  Management  feature,  if  the drive supports it. A low value means
       aggressive power management and a high value means better performance. A  value  of  255
       will disable apm on the drive.
[...]

Podemos reducirlo al máximo:

# hdparm -B 254 /dev/hdc

/dev/hdc:
 setting Advanced Power Management level to 0xFE (254)

O incluso deshabilitarlo:

# hdparm -B 255 /dev/hdc

/dev/hdc:
 setting Advanced Power Management level to disabled

El caso es que tras hacer lo último, el valor de Load_Cycle_Count en la salida del smartctl ya no crece más que en una unidad cuando arranco, así que me lo he puesto en el fichero /etc/rc.local, para que se ejecute siempre durante el arranque. Los clicks también han desaparecido, así que todo es mucho mejor ahora.

Y es que en este sistema, aunque le puse un disco de 2.5″ para que no consumiera mucho porque la fuente es tan sólo de 60W, tampoco necesito que sea muy estricto en materia de ahorro de energía como si se tratara, por ejemplo, de un portátil trabajando con baterías, y prefiero evitar un envejecimiento prematuro del disco.

El problema con Ubuntu, el que ha creado toda esta alarma, es que en modo laptop, que no está habilitado por defecto, el fichero /etc/acpi/power.sh configura el disco para que ahorre energía de la forma más agresiva posible, con -B 1, haciendo que el disco tenga muchos más ciclos de carga y descarga y muchos más clicks:

function laptop_mode_enable {
...
    $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
    $HDPARM -B 1 /dev/$drive 2>/dev/null
}

En un bug report del problema que ya tiene bastantes meses, alguien ha probado con distintos valores de -B:

-B 128 -> 23 cycles in 10 minutes
-B 160 -> 29 in 10'
-B 180 -> 0 in 10'
-B 196 -> 0 in 10'
-B 200 -> 0 in 10'

Se ha generado alarma por Ubuntu e incluso en algunas otras distribuciones pero, en realidad, hay firmwares y BIOS que ya activan modos APM agresivos durante el arranque, como leemos en Problem with hard drive clicking, y como me ha pasado a mí mismo, que estaba sufriendo el problema con una Debian que no toca absolutamente nada de los parámetros del disco.

¿Y el problema no pasa en Windows? Pues yo no tengo ningún disco que haga clicks y que tenga Windows para probar si tras un rato de funcionamiento el valor de Load_Cycle_Count crece, pero yo esperaría que sí, ya que Windows suele optimizar bastante bien el consumo de energía en portátiles (los fabricantes de los mismos en realidad lo prueban todo en Windows).

Sí que puede ocurrir que en Linux los ciclos de carga y descarga ocurran mucho más a menudo, porque en Linux el kernel y los procesos se dedican a escribir muy frecuentemente en disco, siendo los periodos en los que el disco está idle mínimos. Cualquiera que haya intentado que un disco duro se quede parado tras un periodo de inactividad del sistema en Linux, se habrá dado cuenta de que no es una tarea fácil:

• sync: why disk cannot spin down
• Linux Hard Disk Spin-Down
• HOWTO HDD spindown small server

Pero para mí, me parece que lo más importante a recalcar es que en raíz, esto no es un problema de ningún sistema operativo, ni de ninguna distribución: ni Ubuntu, ni Debian, ni Fedora, ni Windows. No perdamos de vista que esto es un problema generado artificialmente por los fabricantes de discos duros que hacen su hardware con absurdas limitaciones.

Y, por cierto, no olvidemos que este es un problema sólo de los discos que se fabrican con esta tecnología de load/unload, a los que también podríamos llamar click-powered hard disks. En otros discos, dicho contador ni se estrena:

# smartctl -a /dev/sdb | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count        0x0032   253   253   000    Old_age   Always       -       0

Una curiosidad para acabar: ¿Sabías que con la opción -M del hdparm puedes configurar tu disco para que intente hacer menos ruido?

:wq

Actualización 1/1/08: En A vueltas con el “hdparm -B” en Debian Lenny vuelvo a tratar el tema, enfocándolo esta vez a ver cómo están tratando el problema los desarrolladores de Debian en Lenny.

Actualización 2/5/08: Hace tiempo que está en los comentarios, pero creo que es importante recalcar que en lugar de añadir el comando “hdparm -B 254” al fichero /etc/rc.local, es mejor editar el fichero /etc/hdparm.conf y poner algo así (cambiando el fichero de dispositivo y el valor de apm según nuestras necesidades):

/dev/sda {
apm = 254
}

Seguido por el comando:

update-rc.d hdparm defaults

para que el hdparm se ejecute durante el arranque.

Actualización 5/5/08: Parece que en Ubuntu Hardy Heron no hay /etc/init.d/hdparm, de modo que probablemente siga siendo buena idea usar el /etc/rc.local.

Actualización 24/5/08: La página Bug #59695 High frequency of load/unload cycles on some hard disks may shorten lifetime contiene una excelente explicación del problema así como una lista de discos duros afectados y del valor de “hdparm -B” más conveniente para solucionar el problema en ellos. Me ha gustado especialmente el siguiente párrafo:

The disk Load_Cycle_Count issue appears to be caused by a combination of two problems — The first is overly-aggressive power management from what might be considered buggy hardware. The second is that Ubuntu appears to be touching the hard drive on a regular basis for one reason or another.

ya que afirma claramente lo que yo siempre he defendido en esta entrada: Que esto es un problema de los fabricantes de discos duros. Que se agrava por cómo Linux usa el disco duro, de acuerdo, pero en primer lugar es un problema de cómo los fabrican.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 166 comentarios
Etiquetas: APM, clicks, Debian, GNU/Linux, hdparm, SMART, Ubuntu

Feed enhanced by Better Feed from Ozh

Para intentar aclarar el problema, primero nos tenemos que fijar en las unidades de medidas que define el estándar CSS 2.1. Por un lado tenemos las unidades de medidas relativas a otra unidad:

• em: the ‘font-size’ of the relevant font
• ex: the ‘x-height’ of the relevant font
• px: pixels, relative to the viewing device

Podemos pensar que un número de pixels px no es una unidad de medida relativa, pero sí que lo es si pensamos que la página se puede mostrar en papel si la imprimimos o en monitores muy grandes, muy pequeños, en un proyector. Tú pones px cuando diseñas la página web pero luego ese pixel puede medir físicamente un centímetro si se muestra en un proyector. De ahí la relatividad de dicha medida.

Para una pantalla, el estándar indica como referencia que estando los ojos a una distancia de un brazo (28″) de la pantalla, un pixel ha de verse con un tamaño de 0.26mm (1/96 in) o, lo que es lo mismo, 96 DPI:

Por otro lado, tenemos las unidades de medida absolutas para las que es necesario conocer las dimensiones físicas del dispositivo de salida:

• in: inches — 1 inch is equal to 2.54 centimeters.
• cm: centimeters
• mm: millimeters
• pt: points — the points used by CSS 2.1 are equal to 1/72nd of an inch.
• pc: picas — 1 pica is equal to 12 points.

Vemos que pt se define como puntos de 72 DPI.

(...)

Leer el resto de Los DPI en los navegadores web de Windows y Linux (1,058 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 3 comentarios
Etiquetas: antialiasing, CSS, DPI, Firefox, fuentes, GNU/Linux, HTML, Iceweasel, Internet Explorer, Windows

Feed enhanced by Better Feed from Ozh

En esta entrada, vamos a intentar entender qué supone un valor u otro de DPI en distintos entornos y cómo configurarlo:

• Los DPI en Windows
• Los DPI en Linux
• Los DPI en los navegadores

(...)

Leer el resto de Los DPI en pantalla en Windows y Linux (2,855 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 6 comentarios
Etiquetas: accesibilidad, antialiasing, DPI, fuentes, GNOME, GNU/Linux, KDE, Keith Packard, resolución, Windows, X Window System

Feed enhanced by Better Feed from Ozh

DISK MIGHT NOT BE SPUN DOWN PROPERLY. UPDATE SHUTDOWN UTILITY
For more info, visit http://linux-ata.org/shutdown.html

Bueno, en realidad sé exactamente lo que pone porque lo he buscado en las fuentes del kernel, porque no da tiempo a leerlo entero, sino que más bien es un rápido flash del que únicamente se queda en la mente algo así como “el disco no se ha parado bien”. El mensaje lo podemos encontrar en drivers/ata/libata-scsi.c:

/* XXX: This is for backward compatibility, will be
 * removed.  Read Documentation/feature-removal-schedule.txt
 * for more info.
 */
if ((qc->dev->flags & ATA_DFLAG_SPUNDOWN) &&
    (system_state == SYSTEM_HALT ||
     system_state == SYSTEM_POWER_OFF)) {
        static unsigned long warned = 0;

        if (!test_and_set_bit(0, &warned)) {
                ata_dev_printk(qc->dev, KERN_WARNING,
                        "DISK MIGHT NOT BE SPUN DOWN PROPERLY. "
                        "UPDATE SHUTDOWN UTILITY\n");
                ata_dev_printk(qc->dev, KERN_WARNING,
                        "For more info, visit "
                        "http://linux-ata.org/shutdown.html\n");

Como el propio mensaje indica, tenemos que acudir a: Serial ATA (SATA) shutdown info, donde podremos obtener una explicación del problema.

Antes de apagar un disco duro, tenemos que guardar lo que contiene la caché y aparcar las cabezas de lectura/escritura para que no aterricen sobre la superficie magnética, lo que podría dañarla. Es raro que tal cosa ocurra, en cualquier caso, ya que si se apaga el sistema de golpe, la controladora del disco es capaz de aparcar la cabeza sin corriente externa para evitar problemas, pero no es aconsejable en absoluto hacerlo así. Puede hacer ruidos extraños y reducir la vida del disco.

En Linux, para hacer esto, tenemos los drivers IDE/ATA de toda la vida, los que en el “make menuconfig” encontramos en:

Device Drivers → ATA/ATAPI/MFM/RLL support (CONFIG_IDE)

Este driver, aunque funciona bien, tiene muchos hacks para permitir compatibilidad hacia atrás con viejos dispositivos. Así que cuando aparecieron los discos SATA, los desarrolladores decidieron partir con una implementación limpia del estándar ATA, en principio para acoger los drivers de SATA pero en la que también se van añadiendo drivers PATA. Ese driver, en el “make menuconfig” lo encontramos en:

Device Drivers → Serial ATA (prod) and Parallel ATA (experimental) drivers (CONFIG_ATA)

y la página del proyecto es, precisamente, linux-ata.org: Serial ATA (SATA) for Linux.

Este nuevo driver trata los discos SATA como si fueran discos SCSI, tal y como leemos en la descripción de estos drivers en la ayuda del kernel:

CONFIG_ATA:

If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or
any other ATA device under Linux, say Y and make sure that you know
the name of your ATA host adapter (the card inside your computer
that "speaks" the ATA protocol, also called ATA controller),
because you will be asked for it.

NOTE: ATA enables basic SCSI support; *however*,
'SCSI disk support', 'SCSI tape support', or
'SCSI CDROM support' may also be needed,
depending on your hardware configuration

Pues bien, en los drivers IDE de toda la vida se lanzaban los comandos FLUSH CACHE y STANDBYNOW antes de apagar el sistema. Sin embargo, el nuevo driver se basa en SCSI y en sistemas SCSI varios hosts pueden acceder a un mismo disco, por lo que aparcar sus cabezas antes de la parada del sistema puede molestar a otro host que aún esté usando ese disco. Por tanto, en el nuevo driver (<=2.6.21) el comando STANDBYNOW no es lanzado durante la parada.

El driver del kernel 2.6.22 se actualizó para que se lanzaran los comandos FLUSH CACHE y STANDBYNOW antes de: power off, suspend-to-ram y suspend-to-disk, pero desafortunadamente, la inmensa mayoría de implementaciones del comando shutdown de las diferentes distribuciones aún no son compatibles con este cambio.

Por ejemplo, hasta ahora, algunas implementaciones de shutdown lanzaban el comando STANDBYNOW explicítamente, sin cubrir casos como el sleep-to-disk.

Por tanto, la situación actual queda así:

1. El shutdown lanza un FLUSH CACHE (no en todas las distribuciones)
2. El shutdown lanza un STANDBYNOW y para el disco
3. La parada del kernel comienza
4. El driver SATA lanza un FLUSH CACHE
5. El driver SATA lanza un STANDBYNOW (nuevo con el 2.6.22)

Primer problema: algunas distribuciones no guardan la caché del disco antes de pararlo. Segundo problema: los pasos 4 y 5 podrían arrancar de nuevo un disco ya parado.

En definitiva, es necesario actualizar el comando shutdown en todas las distribuciones, cosa que ninguna de ellas ha hecho aún.

En Debian hay un bug abierto para que modifiquen este problema: #426224 Please update shutdown to support libata drivers in newer kernels

En Ubuntu también hay un bug: #114683 New libata/scsi spindown functionality in 2.6.22 requires changes in userland shutdown(8), con interesante información en la discusión, que, curiosamente, ha sido cerrado como inválido porque “a Ubuntu no le afecta el problema” (¿no dicen los desarrolladores del driver SATA que ninguna distribución ha arreglado el problema aún?):

As discussed with the libata upstream, we don’t need to change our /sbin/reboot utility at all. The 2.6.22 kernel will notice that we have made no attempt to flush the caches or shutdown the disk, and will perform it for us.

Hace poco, también salió el tema en la bitácora del usuario chavi en Barrapunto: Aparcando el disco duro, que, entre otras cosas, nos indica que podemos encontrar los paquetes sysv-rc, sysvinit y sysvinit-utils que solucionan el problema en Debian entre los paquetes no oficiales de Roland Stigge.

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 17 comentarios
Etiquetas: Debian, GNU/Linux, IDE, Kernel, SATA

Feed enhanced by Better Feed from Ozh

El procesador gráfico que lleva la VIA EPIA EX10000EG es el UniChrome™ Pro II, integrado en el chipset CX700M2. Según VIA, este chipset es capaz de:

Integrated VIA UniChrome™ Pro II 3D/2D AGP graphics with MPEG-2/4 and WMV9 video decoding acceleration

No tengo ni idea de si tales afirmaciones son ciertas en Windows (no he probado esta placa con dicho sistema operativo) o son fruto de la benevolencia de alguien en el departamento de marketing de VIA, pero veamos hasta dónde podemos sacarle punta a dichas afirmaciones en Linux.

En principio, leyendo la Operating Guide de la placa, vemos que, aunque sea sobre el papel, VIA nos manifiesta un fuerte compromiso con el soporte de Linux en sus placas:

Linux Driver Support

VIA EPIA EX mainboards have a very high degree of support under Linux.

Support and drivers are provided through various methods including:

• Drivers provided by VIA
  • Using a driver built into a distribution package
  • Visiting VIA Arena website at www.viaarena.com for latest updates on a monthly basis
• Installing a third party driver (such as the ALSA driver from the Advanced Linux Sound Architecture project for integrated audio)

For OEM clients and system integrators developing a product for long term production, other code and resources may also be made available. You can submit a request either through the Developers portal on VIA Arena, or through your VEPD support contact. Alternatively, VIA can work further towards providing additional drivers to suite your specific needs.

Como hemos visto en entradas anteriores (Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, Sobre las VIA EPIA (III): Linux en una SP8000E), en las que nos hemos dejado absolutamente todos los elementos del hardware configurados a la perfección, podemos aceptar la afirmación anterior sin titubeos.

Sin embargo, aún nos queda configurar los gráficos en esta placa, y nos vamos a encontrar con varios problemas. El primero es que según leemos en la página de man(4) del driver via actual (7.1) de X.Org, este chipset no está soportado aún:

DESCRIPTION
       via is an Xorg driver for VIA chipsets that have  an integrated Unichrome graphics engine.

       The via driver supports the CLE266, KM/N400, K8M/N800, PM/N800  and  CN400  chipsets  from
       VIA,  including  2D acceleration and the Xv video overlay extensions.  Flat panel, TV, and
       VGA outputs are supported, depending on the hardware configuration.

       3D direct rendering is available using experimental drivers  from  Mesa  (www.mesa3d.org).
       There  is  also  an  XvMC client library for hardware acceleration of MPEG1/MPEG2 decoding
       (available on the CLE266, PM/N800, K8M/N800, and CN400 chipsets) that uses the Direct Ren-
       dering  Infrastructure  (DRI).   The  XvMC  client library implements a non-standard "VLD"
       extension to the XvMC standard.  The current Direct Rendering Manager (DRM) kernel  module
       is available at dri.sourceforge.net.

Si nos pasamos al driver openChrome, nos encontramos con que tenemos que usar la rama experimental para tener soporte del chipset CX700M2 pero que, desafortunadamente, aún no soporta aceleración MPEG2/4 por XvMC.

Nos queda el driver oficial de VIA. Cuando hice la tanda anterior de artículos alrededor de la SP8000E, dado que encontré buen soporte del procesador gráfico tanto en el driver oficial de X.Org como en el openChrome, ni me preocupé en probarlo, ya que en muchos foros leía comentarios bastante negativos al respecto. Sin ir más lejos, en The Different Unichrome family display drivers podemos leer:

The VIA proprietary drivers

The proprietary drivers from VIA contain support for most chipsets, mpeg2 and mpeg4 acceleration, but are of low quality and often unstable. In addition, the 3D driver leaves your system open for attack by malicious clients, and furthermore, applications that accelerate mpeg2 and mpeg4 must be run as root, which is a very bad idea if they contain vulnerabilities (and they do). Avoid using these drivers unless you know what you are really doing! The drivers can be found here. Also, these drivers are distribution specific and a driver for different distribution other than yours might not work.

El desarrollador del driver unichrome.sf.net (que no funciona en chipsets modernos como el CN400 o el CX700, por cierto), Luc Verhaegen, también dice:

Despite VIA’s failure to properly understand and cooperate with Free and Open Source Software communities, this driver is very important. Thanks to VIA’s code releases, however irregular, entangled and buggy, a lot is known about the unichromes, and it is possible to do just about anything you want with them.

Por cierto, Luc tuvo un rifirafe con la moderadora de los foros de VIA, Fiona Gatt en VIA stops providing source: XF40070 is binary only y XF40070 topic locked: Last post removed tras decir en su diario lindezas sobre el driver de VIA tales como:

So, let us review where VIAs stands with respect to free software:

• Complete and prolonged (3y+) inability to work with actual free software developers.
• Crappy code and sporadic releases, totally unfit for direct use.
• Very bad handling of licensing, with proprietary licenses popping up once in a while.
• An NDA that, when VIA says so, forces signee to breach the GPL.
• Distributes tarball with the binary “libddmpeg.so” and labels the lot as “open source” in direct violation of The Open Source Definition.
• No longer distributes a DRI driver now, after having provided DRI binaries for a bit inside their “open source” tarballs. This used to be all source at one point.

En esta ocasión, y puesto que la aceleración de vídeo es importante en mis pruebas, es impensable no probarlo. Así que, ¡vamos allá!.

• Los preparativos del kernel
• El driver VESA
• El driver openChrome
  • Notas sobre el XvMC
• El driver de VIA
  • Las aplicaciones que pueden sacar provecho del driver de VIA
  • La S3 Utility
• El driver de framebuffer
• La salida de TV
• Pruebas: Gráficas de rendimiento de la aceleración MPEG2/4 por hardware
  • Conclusiones sobre la reproducción de vídeo en EPIA-Linux a la vista de los resultados
  • ¿Es posible reproducir contenido en HD con esta placa en Linux?

(...)

Leer el resto de Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG (7,773 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 47 comentarios
Etiquetas: Debian, EX10000EG, GNU/Linux, Kernel, MPEG2, MPEG4, openChrome, patch, SP8000E, Televisión, VIA, VIA EPIA, XvMC

Feed enhanced by Better Feed from Ozh

• IDE
• SATA
• Ethernet
• Audio
• Sensores
• CPU
  • Generador de números aleatorios
  • Gestión de la frecuencia del procesador
  • Bit NX
  • VIA Padlock
• Gráficos, vídeo acelerado por HW

(...)

Leer el resto de Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux (2,113 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 14 comentarios
Etiquetas: Debian, EX10000EG, GNU/Linux, IDE, Kernel, OpenSSL, SATA, VIA, VIA EPIA, VIA Padlock

Feed enhanced by Better Feed from Ozh

El emerge viene a ser una unión de los comandos de Debian dpkg, apt-get, apt-cache y apt-build. Nigún misterio por esa parte…

Sin embargo, el equery que, como su propio nombre indica, se usa para hacer queries a la base de datos de paquetes, resulta muy útil. Por ejemplo, se puede obtener la lista de paquetes que dependen de uno dado (ejemplo copiado de Gentoolkit):

# equery depends pygtk
[ Searching for packages depending on pygtk... ]
app-office/dia-0.93
dev-python/gnome-python-2.0.0-r1
gnome-extra/gdesklets-core-0.26.2
media-gfx/gimp-2.0.4
x11-libs/vte-0.11.11-r1

También nos permite obtener un árbol de dependencias de un paquete dado, pero en este caso no se trata de los paquetes de los que depende el paquete, sino de sus dependencias:

# equery depgraph cdrtools
Displaying dependencies for app-cdr/cdrtools-2.01_alpha37
`-- app-cdr/cdrtools-2.01_alpha37
 `-- sys-libs/glibc-2.3.4.20040808 (virtual/libc)
  `-- sys-kernel/linux-headers-2.4.22 (virtual/os-headers)
   `-- sys-apps/baselayout-1.10.4
    `-- sys-apps/sysvinit-2.85-r1
     `-- sys-apps/gawk-3.1.3-r1
      `-- sys-apps/util-linux-2.12-r4
          `-- sys-apps/sed-4.0.9
        `-- sys-libs/ncurses-5.4-r4
            `-- sys-apps/pam-login-3.14
            `-- sys-libs/pam-0.77-r1
                 `-- sys-libs/cracklib-2.7-r10
               `-- sys-apps/miscfiles-1.3-r1
              `-- app-arch/gzip-1.3.5-r1
              `-- sys-apps/portage-2.0.50-r10

En Debian, a menudo quiero eliminar un paquete y las dependencias no me lo permiten:

 # dpkg -P libxine1
dpkg: dependency problems prevent removal of libxine1:
 totem-xine depends on libxine1 (>= 1.1.2-5).
dpkg: error processing libxine1 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libxine1

Es posible que esté tan convencido de querer eliminar el paquete que me decida incluso a eliminar sus dependencias:

# dpkg -P totem
dpkg: dependency problems prevent removal of totem:
 gnome-desktop-environment depends on totem (>= 1.4.3).
dpkg: error processing totem (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 totem

Pero claro, llegados a este punto, me temo que el gnome-desktop-environment no lo quiero eliminar. De momento, los paquetes ya me los ha dejado marcados como que no los quiero instalados para aprovechar la mínima ocasión para eliminarlos:

# dpkg -l | egrep -v ^ii
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name             Version              Description
+++-================-====================-============================================
pi  libxine1         1.1.2+dfsg-4         the xine video/media player library, binary
pi  totem            2.16.5-3             A simple media player for the Gnome desktop

Como a mí me da manía dejarlos así, pues en este punto haría un “apt-get --reinstall install libxine1 totem” para que vuelvan a estar en estado ii.

La forma elegante de prever y al mismo tiempo tantear si podríamos borrar el paquete sería haber usado el “dpkg -P” con una de las tres opciones que evitan que la acción se haga en realidad:

       --no-act | --dry-run | --simulate
              Do everything which is supposed to be done, but  don't  write  any  changes.
              This  is  used  to  see what would happen with the specified action, without
              actually modifying anything.

              Be sure to give --no-act before the action-parameter, or you  might  end  up
              with  undesirable  results. (e.g. dpkg --purge foo --no-act will first purge
              package foo and then try to purge package --no-act, even though you probably
              expected it to actually do nothing)

Pero bueno, esta forma de trabajar por tanteo me parece un atraso tras haber visto lo que puede hacer el equery.

(...)

Leer el resto de Mostrar un árbol de los paquetes instalados que dependen de otro en Debian (1,090 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 5 comentarios
Etiquetas: bash, Debian, dpkg, enscript, Gentoo, shell

Feed enhanced by Better Feed from Ozh

Pues bien, desde entonces vengo usando el NTFS-3G continuamente, habiendo visto cómo el driver cada vez funciona mejor y más rápido. Szabolcs Szakacsits, el principal desarrollador del proyecto, tiene todos mis agradecimientos por haber conseguido algo que se había hecho esperar tanto (soporte seguro de lectura y escritura de NTFS en Linux) y con tanta calidad.

En fin, el caso es que desde el principio me venía fijando en que cuando hacía según qué operaciones de escritura en la partición NTFS usando un usuario distinto de root me encontraba con el error:

cp: preserving times for 'foo': Operation not permitted

Y los ficheros se creaban con la fecha actual en lugar de la suya. Por ejemplo:

$ ll torvalds-says-linux.au
-rw-r--r-- 1 supercoco users 41493 2006-10-27 21:24 torvalds-says-linux.au
$ cp -p torvalds-says-linux.au /mnt/e/
cp: preserving times for `/mnt/e/torvalds-says-linux.au': Operation not permitted
$ ll /mnt/e/torvalds-says-linux.au
-rwxrwxrwx 1 root root 41493 2007-09-10 22:31 /mnt/e/torvalds-says-linux.au

Esto no ocurre con root:

# ll torvalds-says-linux.au
-rw-r--r-- 1 supercoco users 41493 2006-10-27 21:24 torvalds-says-linux.au
# cp -p torvalds-says-linux.au /mnt/e/
# ll /mnt/e/torvalds-says-linux.au
-rwxrwxrwx 1 root root 41493 2006-10-27 21:24 /mnt/e/torvalds-says-linux.au

Tenía pendiente investigar la causa pero no le estaba dando mucha importancia. Hasta que hace unos días pasé todas las fotos de la tarjeta de memoria de la cámara de fotos y a continuación me di cuenta de que los ficheros habían perdido la fecha y hora correctas, algo que me molestó mucho. No es una pérdida irreparable, porque dichos datos siguen estando en la cabecera Exif de las fotos, pero sí fue muy molesta.

En realidad la solución estaba a tiro de Google en forma de hilo de los foros de NTFS-3G y con contestación del propio szaka (Szabolcs Szakacsits): cp: preserving times for ‘file’: Operation not permitted.

El problema estaba en que yo montaba la partición poniendo lo siguiente en el /etc/fstab:

/dev/sdb6  /mnt/e ntfs-3g rw,defaults,umask=000,locale=en_US.ISO-8859-15    0       0

y resulta que si se especifica una de las opciones uid, gid o [udf]mask, es el propio FUSE el que verifica dichas opciones y gestiona los permisos.

Teniendo en cuenta que ntfs-3g funciona con el setuid de root:

# ll /usr/bin/ntfs-3g
-rwsr-xr-- 1 root fuse 40440 2007-08-08 19:50 /usr/bin/ntfs-3g

Extracto del man de ntfs-3g:

If ntfs-3g is set setuid-root then non-root users will be also able to mount block devices
or via /etc/fstab if the 'user' or 'users' mount(8) option is specified. The ntfs-3g  pro-
cess drops the root privilege after successful mount and runs unprivileged afterwards.

FUSE hace lo correcto según el estándar POSIX al rechazar la operación, como nos cuenta Szabolcs:

I have the result of the investigation. FUSE is right. Things worked
as they should. The operation indeed mustn't be permitted in such cases
according to the POSIX standard.

Namely utimes(2) doesn't permit changing the time stamps because the
effective uid of the cp process doesn't equal the uid of the file
__AND__ the new time stamps are not the current time, __EVEN_IF__
the user has write permission to the file. This is how POSIX wants.

Por tanto, si quitamos el umask=000 que, en cualquier caso, es el valor que se toma por defecto, FUSE no hará las comprobaciones y las horas y fechas se escribirán correctamente, aunque no estemos con el usuario root.

Esta es la línea de mi /etc/fstab ahora:

/dev/sdb6  /mnt/e ntfs-3g rw,defaults,locale=en_US.ISO-8859-15    0       0

Por cierto, ¿a alguien le ha llamado la atención el fichero que he usado de prueba? El fichero de audio (formato au) torvalds-says-linux.au es muy antiguo y al reproducirlo oímos a Linus Torvalds pronunciar Linux. Pronunciación que se usa de referencia desde entonces. Se puede reproducir en un sistema Linux con OSS simplemente haciendo:

cat torvalds-says-linux.au > /dev/audio

Supuso una enorme alegría para mí la primera vez que conseguí configurar una tarjeta de sonido en Linux y oír a Linus. Yo encontré el fichero en uno de mis viejos CDs de InfoMagick. Hoy en día está en múltiples sitios y formatos. Por ejemplo, en la página de Paul Slanden.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: filesystems, GNU/Linux, NTFS-3G

Feed enhanced by Better Feed from Ozh

En concreto, si ya somos capaces de arrancar la instalación de Debian por la red, alterando el fichero de configuración del PXELINUX podemos lograr que el sistema que arranca de la red use el kernel que nos interese y, a continuación, montar por NFS el sistema de ficheros que tendremos preparado en otra máquina.

El primer paso es crear una instalación de Debian dentro de un directorio del servidor de arranque (en mi caso /exports/peggy, donde peggy es el nombre del sistema que arrancará Debian de la red) usando el útil comando debootstrap

# mkdir -p /exports/peggy
# debootstrap --arch i386 etch /exports/peggy http://ftp.es.debian.org/debian/

El debootstrap no instala un kernel por defecto, así que entramos en la nueva instalación con chroot para instalar uno:

# chroot /exports/peggy
# apt-get install linux-image-686 libc6-i686
# exit

Ahora vamos a crear un nuevo fichero de configuración para el PXELINUX. Como podemos leer en la documentación del PXELINUX, el fichero default, que es el que ya tenemos, es el último que se intenta cargar. Antes de eso, el gestor de arranque por red trata de usar un fichero con un nombre como 01-<direccion MAC en minúsculas y con guiones como separadores de bytes>. Por ejemplo, si la dirección de nuestro sistema es 00:41:64:ED:29:D3, necesitaremos un fichero con el nombre 01-00-41-64-ed-29-d3 en /var/lib/tftpboot/pxelinux.cfg/.

(...)

Leer el resto de Configurar un sistema Debian diskless (307 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Debian, DHCP, filesystems, initrd, NFS, PXELINUX, TFTP

Feed enhanced by Better Feed from Ozh

Con esta configuración necesitaríamos arrancar de la red para poder hacer algo y estaríamos hablando de un sistema diskless.

Si queremos que el sistema sea autónomo, además de las piezas anteriores, necesita un sistema de almacenamiento propio (disco duro, memoria USB, unidad óptica, disquetera) del que arrancar, que normalmente será un disco duro. Supongamos que tenemos un sistema mínimo sólo con un disco duro, queremos instalarle Debian y no tenermos una unidad óptica externa ni nada que podamos usar para hacer la instalación estándar. En ese caso, necesitaremos arrancar la instalación por red.

Es un proceso bastante sencillo, aunque necesitaremos una cierta infraestructura en otro sistema ya instalado del que el sistema a instalar obtendrá todo lo necesario. La máquina a instalar ha de soportar arrancar desde la red por PXE, una combinación de DHCP y TFTP que permite asignar una dirección IP al sistema cliente y a continuación pasarle los ficheros necesarios para que lo haga.

En mi caso, como el router ADSL que uso ya es servidor de DHCP, es deseable evitar posibles interferencias al montar un nuevo servidor DHCP a pesar de que, según la Wikipedia, esto en teoría se podría evitar:

The PXE Client/Server Protocol was designed so it can be used in the same network as an existing DHCP environment without interference

Por ello, y como el PC destinado a servidor de arranque tiene dos interfaces de red, uno normalmente sin usar (eth0) y otro conectado al router (eth1), yo prefiero independizar ambas redes, de tal forma que si conectamos con un cable cruzado la toma de red del sistema a instalar con el interfaz sin usar, estamos listos para comenzar la configuración del sistema.

(...)

Leer el resto de Iniciar una instalación de Debian por red (612 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 3 comentarios
Etiquetas: Debian, DHCP, PXELINUX, SYSLINUX, TFTP, wget

Feed enhanced by Better Feed from Ozh

A mí, desde luego, sí, y por eso me puse a ver cómo poner un FVWM con el sabor de aquél en una Debian moderna. Y lo digo porque el FVWM puede tomar más aspectos diferentes que un camaleón, como podemos ver en la página de capturas de pantalla de FVWM. Por tanto, voy a proponer, con unos pocos y sencillos pasos una forma para disfrutar un ratito de un FVWM “retro” con una Debian actual. En este viaje al pasado no vamos a romper nada ni vamos a cambiar nada de la configuración actual que podamos tener para arrancar KDE, Gnome, o lo que sea que estemos usando, ya que entiendo que nadie quiera usar esta configuración para siempre…

1) Instalamos el paquete fvwm1:

# apt-get install fvwm1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  librplay3
The following NEW packages will be installed:
  fvwm1
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/297kB of archives.
After unpacking 831kB of additional disk space will be used.
Selecting previously deselected package fvwm1.
(Reading database ... 146100 files and directories currently installed.)
Unpacking fvwm1 (from .../fvwm1_1.24r-51.2_amd64.deb) ...
Setting up fvwm1 (1.24r-51.2) ...

2) Copiamos este fichero system.fvwmrc-menu a /etc/X11/fvwm/. Opcionalmente, antes de hacerlo, podemos querer hacer un backup del archivo system.fvwmrc-menu que pone Debian por defecto.

3) Ejecutamos “update-menus” para añadir todos los programas instalados en el sistema al menú de FVWM. En Debian, el fichero system.fvwmrc-menu es una plantilla a partir de la cual el update-menus crea un system.fvwmrc con un menú con todos los programas. Igual que hace con cualquier gestor de ventanas instalado en el sistema.

4a) Si estamos usando un Display Manager o Login Manager como kdm, gdm o xdm, lo paramos con /etc/init.d/kdm stop, /etc/init.d/gdm stop o /etc/init.d/xdm stop. Si estábamos en una sesión gráfica se cerrará y volveremos a la consola de texto.

4b) Si solemos entrar en las X Windows con startx, salimos.

5) Si existe el fichero ~/.xinitrc en el $HOME de nuestro usuario, podemos hacer una copia de seguridad o renombrarlo temporalmente. En cualquier caso, editamos el fichero ~/.xinitrc y en la primera línea ponemos “fvwm“.

6) Ejecutamos startx y ¡volvemos 12 años atrás!

¿Qué cambios lleva el fichero system.fvwmrc-menu que propongo sobre el de por defecto de fvwm1?

(...)

Leer el resto de Configurar un FVWM con sabor clásico en Debian (400 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Debian, FVWM, Slackware, X Window System

Feed enhanced by Better Feed from Ozh

Siendo el caso del Epson Perfection 2480 uno de los casos más fáciles que podemos encontrar para configurar un dispositivo hardware que no esté directamente soportado por el kernel, nos toca reconocer que a Linux aún le queda un buen camino que recorrer en el área del reconocimiento automático del hardware, algo que sin el apoyo real de los fabricantes nunca será posible del todo. Este dispositivo está bien soportado en Linux, pero como el firmware es cerrado, no puede ser incluido en distribuciones que tengan un mínimo reparo a las licencias del software que incluyen.

En la época de Windows 95 anterior a la llegada del 98 teníamos otro escáner, un Mustek Paragon 6000p de puerto paralelo. Estábamos contentos con aquel escáner, aunque como el 486 no tenía EPP/ECP, la velocidad de transmisión de imágenes al PC era lamentable. Pero bueno, el caso es que cuando salió Windows 98, Mustek no sacó drivers para este nuevo sistema operativo. Incluso hoy en día, si vamos a la página de drivers del 600 III EP Plus (¡el 6000p no está!) vemos que sólo hay drivers para Windows 95. ¿Qué pasó? Pues que si migraba no tenía escáner. Ahí me di cuenta de que si el escáner estaba soportado en Linux con un driver abierto (sí que lo está, aunque no sé desde cuándo), jamás me tendría que preocupar en adelante porque un dispositivo hardware dejara de estar soportado. Desafortunadamente, aquel escáner tuvo una muerte temprana, pero si aún estuviera funcionando, yo, en 2007, más de 10 años más tarde, podría poneros capturas obtenidas con él con mi Debian, pero desde luego no podría hacer lo mismo con Windows XP ni con Vista.

Estos problemas le ocurrieron a mucha gente cuando Windows 98 no aceptaba los drivers de Windows 95 y el fabricante no hacía drivers para dispositivos de un año o dos de antiguedad para Windows 98. Volvió a ocurrir cuando muchos dispositivos quedaron en la cuneta en el paso a Windows 2000. Ahora, como los drivers de Windows 2000 sirven para Windows XP, llevamos mucho tiempo sin vivir estos problemas y se nos habían olvidado, pero con la salida de Vista, de nuevo está ocurriendo que ante la ausencia de drivers para Vista, muchos tienen que elegir entre su hardware o Vista (que yo lo tendría claro, pero en fin, para gustos están los colores).

Es el paraíso de los fabricantes. No me extrañaría que desearan con todas sus fuerzas que con cada nueva versión Microsoft cambiara el formato de sus drivers para que todos los usuarios tiraran a la basura sus dispositivos totalmente funcionales y compraran nuevos compatibles con el nuevo Windows Tuerto de turno.

Y es que comprar hardware para el que exista un driver en Linux te garantiza que tu hardware morirá cuando tú quieras, no cuando quiera el fabricante dejar de soportar el dispositivo porque con dos años ya está obsoleto.

Pero no sólo eso: Hay esforzadísimos programadores de drivers de Linux que se lo curran muchísimo para, contra el viento y la marea de los fabricantes que no proporcionan las especificaciones de sus dispositivos, crear drivers usando ingeniería inversa de los drivers de Windows. Su labor es altamente loable, pero no hemos de conformarmos con eso. Un driver obtenido por ingeniería inversa normalmente será de peor calidad que uno hecho a partir de las especificaciones. Así que, como dicen los americanos, tenemos que votar con nuestros euros y favorecer a los fabricantes que proporcionan las especificaciones de su hardware o, incluso mejor, que favorecen e impulsan la creación de drivers abiertos.

El poder está en nuestras manos si lo usamos bien. Si te vas a comprar una tarjeta WiFi fíjate en que Ralink hace un esfuerzo grande para que tengamos buenos drivers para sus chips, fíjate en que Intel proporciona los mejores drivers abiertos de procesadores gráficos de hoy en día, fíjate en que con la ayuda para hacer drivers para Linux que proporciona VIA a los desarrolladores y los que ella misma distribuye, las placas VIA EPIA van mejor en Linux que en Windows…

…y fíjate en que si ahora mismo NVidia y ATI cerraran sus puertas, nos quedaríamos con tarjetas gráficas compradas por entre 100 y 600€ que en pocos meses no servirían para nada que no fuera 2D.

Por tanto, por favor, antes de comprar cualquier hardware nuevo, comprueba previamente si está soportado en Linux. Estarás favoreciendo a los fabricantes que colaboran con la comunidad de código abierto, estarás perjudicando a los que no lo hacen y, sobre todo, saldrás ganando tú. Es posible que no uses Linux ni quieras usarlo en el futuro, pero haciéndolo así sabes que dentro de 10 años, si quieres volver a usar ese dispositivo que tienes en el armario, podrás hacerlo, aunque tenga que ser con Linux.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 12 comentarios
Etiquetas: drivers, GNU/Linux, Windows

Feed enhanced by Better Feed from Ozh

Ya no lo habíamos vuelto a usar desde entonces, pero hace unos días lo recuperé para escanear los CDs de la entrada Los Linux de mi vida. Como no podía ser de otra forma, lo hice en mi Debian, así que os voy a contar los pasos que hay que seguir para ello.

1) Instalar el SANE (Scanner Access Now Easy), si no lo está ya:

apt-get install libsane

El paquete libsane-extras contiene soporte para algunos escáneres adicionales.

2) Desde la página lista de escáneres soportados por SANE vamos a la página del driver SnapScan, que es el que hace falta para este dispositivo, que nos informa de que necesitamos obtener el fichero de firmware esfw41.bin de los drivers de Windows.

2a) Descargamos el driver del Epson Perfection 2480 para Windows, que es un fichero zip autodescomprimible. Lo descomprimimos con unzip y obtenemos varios ficheros, uno de los cuales es el ModUsd.cab. Si lo descomprimimos con cabextract encontraremos finalmente el esfw41.bin.

O también:

2b) Si tenemos el driver instalado en Windows, copiamos el fichero de c:\windows\system32

3) Copiamos el fichero esfw41.bin al sitio que deseemos del sistema de ficheros

4) Editamos el fichero /etc/sane.d/snapscan.conf y especificamos el sitio donde hemos dejado nuestro fichero de firmware:

# Change to the fully qualified filename of your firmware file, if
# firmware upload is needed by the scanner
firmware /mi/path/esfw41.bin

5) Editamos el fichero /etc/group y añadimos el usuario que vaya a hacer uso del escáner (no se debe usar root para esto) al grupo scanner.

scanner:x:110:supercoco

6) Usamos unos de los frontends de SANE para escanear, como por ejemplo el XSane, casi tan bueno o más que el software oficial Epson para Windows.

¡Ya está! Como veis, no tiene ninguna complicación. Al final, si no fuera por el fichero de firmware y por tener que darle permisos al usuario para escanear, no habría que hacer nada, sólo pinchar y usar (plug & play).

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Debian, drivers, Epson Perfection 2480, GNU/Linux, SANE

Feed enhanced by Better Feed from Ozh

Corría el año 1994 cuando me compré un flamante 486DX2 66MHz con 4MB de RAM, 400MB de disco y una Cirrus Logic CL-GD5428. Era una máquina impresionante, porque ya tenía bus PCI además del típico VESA Local Bus de la época. Como siempre ocurre en el mundillo, a pesar de la fortuna que costó, pronto hubo que añadirle 4MB más y ponerle otro disco duro más grande. En sus primeros meses de vida, mi potentísimo ordenador usó MS-DOS 6.2 y Windows 3.1. Aunque le sacaba buen provecho, notaba que algo no iba fino del todo: El MS-DOS era muy limitado y en el Windows 3.1, las inestabilidades del sistema eran continuas.

En ese mismo año salió el OS/2 3.0 Warp, sistema operativo que pudo ser algo y no lo fue. Salió en muy buen momento, antes del Windows 95 y todo eran ventajas: Multimedia, Internet, multitarea real, soporte completo de aplicaciones de Windows 3.1 y MS-DOS, no se colgaba nunca… El precio muy razonable (yo aún lo tengo original) y hubo una fuerte campaña de publicidad por parte de IBM: ¿Alguien se acuerda de los anuncios de Antonio Resines diciendo que él guardaba su colección de bigotes en OS/2?. Sin embargo, no cuajó. Tal vez porque con 4MB (muy pocos tenían más de eso: 4MB adicionales valían sobre 30000 ptas) no iba demasiado bien, o tal vez porque todo el mundo estaba demasiado expectante ante la inminente salida del Windows 95. Con el OS/2 le puse mis primeros cuernos a Microsoft.

Por aquellos días alguien me ofreció probar una cosa llamada Linux (era la primera vez que oía tal palabra) que era como si fuera UNIX, algo que sí me sonaba algo más, pero vamos, que sólo eso, sonarme. Lo asociaba a un MS-DOS (por lo de las letras blancas sobre fondo negro) en el que se podían hacer muchas cosas serias.

Me decidí a probarlo. Copiarme los disquetes (era lo único que teníamos para meter cosas en el ordenador por aquél entonces) del tal Linux iba a ser costoso para mi, porque hacían falta unos 30 disquetes en una época en la que cada caja valía unas 1000 ptas, y eso si eran sin marca.

(...)

Leer el resto de Los Linux de mi vida (2,963 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 60 comentarios
Etiquetas: Debian, Gentoo, InfoMagic, Knoppix, LFS, Mandrake, OpenLinux, OS/2, QEMU, Red Hat, Slackware, Suse, Ubuntu

Feed enhanced by Better Feed from Ozh

Si estás pensando en comprar esta tarjeta, es posible que también te interese considerar a los modelos superiores, la WinTV-HVR-1300, con codificador de MPEG2 por hardware y la WinTV-HVR-3000, con soporte adicional de DVB-S (emisiones por satélite en digital) .

(...)

Leer el resto de Configuración de una Hauppauge WinTV-HVR-1100 en Linux (2,257 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 56 comentarios
Etiquetas: CX88, Debian, DVB-T, GNU/Linux, Hauppauge WinTV-HVR-1100, Hauppauge WinTV-HVR-3000, Kernel, lirc, MythTV, V4L

Feed enhanced by Better Feed from Ozh

La única pega por la que me he sentido siempre atado ha sido el plugin de Flash Player, ya que aunque existe para Linux, Adobe aún no se ha dignado a sacarlo para plataformas de 64 bits. Ni siquiera tras la salida del Flash 9:

When will a 64-bit version of Adobe Flash Player for Linux be available?

The Adobe Flash Player team is working on support for 64-bit platforms as part of our ongoing commitment to the cross-platform compatibility of Adobe Flash Player. We have not yet announced timing or release dates.

Que no se me entienda mal… yo odio el abuso de los contenidos en Flash, como todo hijo de vecino que entiende cómo funciona una web y la indexación de contenidos por los buscadores y la accesibilidad y todo eso. Sin embargo, entiendo que el producto tiene su nicho de mercado legítimo en los contenidos multimedia, como juegos, animaciones, aplicaciones interactivas y… ¿cómo no? En vídeos. Mientras que tradicionalmente ha sido un lío configurar un Linux para poder ver bien los vídeos incrustados en páginas web, el Flash Player ha llegado y nos ha resuelto todos los problemas de un tacazo. ¿Qué internauta linuxero de hoy en día tiene problemas para ver vídeos de YouTube o similares con el plugin de Flash Player?

(...)

Leer el resto de Sobre el plugin de Flash en Firefox/Iceweasel en Debian AMD64: El nspluginwrapper aceptado en Testing (785 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 33 comentarios
Etiquetas: AMD64, Debian, Firefox, Flash, Iceweasel

Feed enhanced by Better Feed from Ozh

No te vuelvas loco… El cliente de DHCP pump, que es el que lleva por defecto Knoppix, no es capaz de obtener una IP por DHCP de un 660HW-61 (al menos no el mío con firmware V3.40(PT.0)b46 de Telefónica). Hay incluso un bug de Debian abierto que expone el problema: Bug#362207: pump does not get IP address from Zyxel Prestige 660HW-61.

Como hay varios clientes de DHCP para Linux:

# apt-cache search "dhcp client"
dhcdbd - D-Bus interface to the ISC DHCP client
dhcp-client - DHCP Client
dhcp3-client - DHCP Client
dhcpcd - DHCP client for automatically configuring IPv4 networking
pump - BOOTP and DHCP client for automatic IP configuration
resolvconf - nameserver information handler
udhcpc - very small DHCP client

la solución es usar uno de los otros, siendo el dhcp3-client el que instala Debian por defecto y funciona bien con este router.

Si estamos con Knoppix o con algún otro LiveCD, como no podemos instalar un cliente diferente, tendremos que asignar la IP manualmente tras eliminar todos los pump que puedan estar corriendo con un “killall -9 pump” seguido de un “ps -ef | grep pump“. El pump puede tardar un poco en morir, así que esperamos a que lo haga y a que no salga en la lista del ps. A continuación, si nuestro interfaz ethernet es el eth0, nuestro router tiene la IP 192.168.1.1/24 y la dirección que queremos asignarle al sistema es la 192.168.1.40, para especificar la IP, añadir la IP del servidor de nombres (en este caso el propio router) y añadir la ruta por defecto haremos:

# ifconfig eth0 192.168.1.40 netmask 255.255.255.0 up

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:D4:C3:D2:F2
          inet addr:192.168.1.40  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4248 (4.1 KiB)  TX bytes:2128 (2.0 KiB)
          Interrupt:16 

# echo 'nameserver 192.168.1.1' >> /etc/resolv.conf

# cat /etc/resolv.conf
# Insert nameservers here
# nameserver 127.0.0.1
nameserver 192.168.1.1

# route add default gw 192.168.1.1

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 4 comentarios
Etiquetas: Debian, DHCP, pump, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

• Arrancar Knoppix desde una memoria USB usando SYSLINUX
• Arrancar MS-DOS desde una memoria USB
• Sobre el BartPE. Arrancar Windows/BartPE desde una memoria USB.

podemos comenzar a trabajar en confeccionar una memoria USB con varios sistemas operativos unidos con el GRUB. La tarea consiste en ordenar todo lo que hemos hecho en entradas anteriores de forma coherente para acabar con todo junto, pero no revuelto, en la misma memoria USB.

Nos vamos a encontrar con un inconveniente muy importante: El BartPE necesita una partición FAT16 para arrancar de USB, no le sirve una FAT32. Por un lado, el tamaño máximo de partición de FAT16 es de 2GB (con un escandaloso tamaño de clúster de 32Kb), con lo que no podríamos ponerlo en memorias USB más grande. Por otro lado, he descubierto que hay muchos más problemas para arrancar MS-DOS desde USB usando FAT16 que usando FAT32, especialmente si usamos el comando ms-sys.

(...)

Leer el resto de Arrancar Linux, Windows y MS-DOS de una memoria USB (1,819 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 26 comentarios
Etiquetas: BartPE, dd, FAT, GNU/Linux, GRUB, Knoppix, memorias USB, MS-DOS, ms-sys, SYSLINUX, Windows

Feed enhanced by Better Feed from Ozh

Pero hay veces que, estando lejos, nos puede interesar encender ese otro ordenador de forma remota porque necesitamos un fichero que tenemos en él o necesitamos hacer algo en él. Para esas situaciones, lo mejor es tener el Wake on LAN (WoL) preparado en esa máquina y las utilidades necesarias para activarlo en la máquina que no solemos apagar.

El WoL es posible en los PCs actuales gracias a las fuentes de alimentación ATX que, cuando el ordenador está apagado, siguen alimentando a ciertas partes de la placa base permitiendo asimismo el Wake on Ring y la posibilidad de arancar el PC sólo pulsando una tecla del teclado o que se encienda a una determinada hora.

(...)

Leer el resto de Wake on LAN (1,947 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 70 comentarios
Etiquetas: ATX, C, DynDNS, fuentes de alimentación, GNU/Linux, PC, Wake-on-LAN, Windows, Zyxel 660HW

Feed enhanced by Better Feed from Ozh

Es importante aclarar que este procedimiento no es como si instaláramos Knoppix en disco con su partición ext2/ext3, con su partición swap, etc. Se trata simplemente de copiar el fichero que contiene el filesystem cloop a la memoria USB y arreglarlo todo un poco lograr que arranque como si se tratara del propio CD/DVD.

En versiones antiguas de Knoppix esto era especialmente difícil porque era necesario obtener el fichero /boot/isolinux/minirt.gz del CD/DVD, descomprimirlo, montarlo (mount -o loop minirt /mnt/puntomontaje) y editar el fichero linuxrc para que se cargaran los módulos de uhci, ohci, ehci y usb_storage y además, revisar el script para asegurarnos de que se recorrían las unidades USB en busca de una que contuviera el famoso directorio KNOPPIX con los ficheros de Knoppix. Tras esto, había que volver a empaquetar el minirt.gz y dejarlo en su sitio. Con distintas variaciones, había muchos tutoriales que le daban vueltas al tema, como el de Knoppix-ES: Arrancar Knoppix desde una memoria USB

(...)

Leer el resto de Arrancar Knoppix desde una memoria USB usando SYSLINUX (1,940 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 22 comentarios
Etiquetas: FAT, filesystems, GRUB, Kernel, Knoppix, LiveCD, memorias USB, ms-sys, SYSLINUX

Feed enhanced by Better Feed from Ozh

Una referencia importante a la hora de poner Linux en una VIA EPIA es el EPIA HowTo, que desafortunadamente ha dejado de mantenerse, pero aún es una fuente importante de información sobre el tema.

Como comentaba en el primer artículo de la serie, las EPIA con procesador VIA C3 Nehemiah y C7 aceptan cualquier distribución optimizada hasta 686, lo que nos permite instalar prácticamente cualquier distribución de 32 bits actual. Cualquiera de ellas puede funcionar sin tocar gran cosa de la configuración por defecto. En esta entrada voy a contar más bien los detalles que hay que tener en cuenta para optimizar al máximo nuestra EPIA centrándome, como no puede ser de otra forma, en lo que tengo a mano, una SP8000E. Todo lo que comente es válido para una SP13000 y probablemente gran parte lo sea para las placas basadas en el chipset CN700.

(...)

Leer el resto de Sobre las VIA EPIA (III): Linux en una SP8000E (1,642 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 70 comentarios
Etiquetas: epiOS, GNU/Linux, IDE, Kernel, openChrome, SP8000E, VIA, VIA EPIA, VIA Padlock, XvMC

Feed enhanced by Better Feed from Ozh

Yo diría que había leído anteriormente sobre el tema, pero no consigo acordarme ni dónde ni cuándo, así que me he preguntado si estaría equivocado y esto llevaría poco tiempo circulando, pero en los históricos del artículo de la Wikipedia en Inglés se puede ver que alguien añadió el ejemplo en el 2004.

Hay Fork Bombs para todas las plataformas, pero la más bonita que he visto es esta para bash:

  ){  :& };:

(...)

Leer el resto de Fork Bombs, ulimit y limits.conf (962 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 17 comentarios
Etiquetas: Debian, fork bomb, GNU/Linux, Kernel, ulimit, Windows

Feed enhanced by Better Feed from Ozh

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.

(...)

Leer el resto de Cómo solucionar incompatibilidades entre una versión de VMWare y un kernel más reciente (477 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 6 comentarios
Etiquetas: Debian, Kernel, NTFS-3G, QEMU, VMWare

Feed enhanced by Better Feed from Ozh

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…

(...)

Leer el resto de ¿Qué distribución/escritorio prefieren 10 protagonistas del Software Libre? (1,835 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 37 comentarios
Etiquetas: Alan Cox, Andrew Tridgell, distribuciones, Donald Knuth, escritorios, Ian Murdock, Keith Packard, Linus Torvalds, Miguel de Icaza, Richard Stallman, Theo de Raadt

Feed enhanced by Better Feed from Ozh

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.

(...)

Leer el resto de Sobre la señal SIGHUP: nohup, disown, trap (1,183 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 15 comentarios
Etiquetas: bash, C, Debian, disown, GNU/Linux, nohup, patch, shell, SIGHUP, trap, UNIX

Feed enhanced by Better Feed from Ozh

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.

(...)

Leer el resto de Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (1,917 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: aMule, awk, Debian, ed2k, expresiones regulares, GNU/Linux, grep, sed, shell, UNIX

Feed enhanced by Better Feed from Ozh

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:

(...)

Leer el resto de El Sticky Bit y el SGID en directorios (377 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 11 comentarios
Etiquetas: Debian, filesystems, GNU/Linux, Sticky Bit, UNIX

Feed enhanced by Better Feed from Ozh

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.

(...)

Leer el resto de Cómo mantener los acentos y las eñes al montar NTFS, FAT o smbfs y al compartir directorios con Samba (1,094 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 28 comentarios
Etiquetas: acentos, CP850, Debian, eñe, FAT, filesystems, GNU/Linux, internacionalización, ISO-8859, juegos de caracteres, Kernel, NTFS, NTFS-3G, Samba, Unicode, UTF-8

Feed enhanced by Better Feed from Ozh

Esto se hace realidad gracias a tres componentes de Linux:

• El Linux Hotplugging, que se encarga de cargar automáticamente los módulos/drivers para los dispositivos que el kernel detecta, bien en el arranque, bien dinámicamente.
• El udev, que permite usar nombres lógicos en los ficheros de dispositivo (los que están bajo /dev).
• El HAL – Hardware Abstraction Layer, que es el que permitiría que, por ejemplo, al conectar una cámara de fotos nos saliera en el escritorio una aplicación de gestión de fotos, pero también se encargaría, por ejemplo, de montar automáticamente las memorias USB al conectarlas.
• El D-Bus, usado por el HAL para comunicar a todos los procesos interesados en la máquina los eventos de hardware que se vayan produciendo.

El documento de GNOME Integración de Hardware en el Escritorio cuenta todo esto muy bien en el capítulo El núcleo Linux y sus ayudantes.

Pero en este artículo quería centrarme en el udev. Yo tengo un montón de dispositivos de almacenamiento USB: Un dedo de 256MB (Kingston), otro de 512MB (sin marca aparente), otro de 8GiB (TrekStor) , un enclosure Venus DS3 con un disco Maxtor estándar de 250GB y finalmente, el típico lector de tarjetas de memoria (SD, CF, MS). Además también tengo por ahí un reproductor de MP3, la cámara de fotos, etc. El caso es que me resultaba muy desagradable tener que buscar cada vez en la salida del dmesg el fichero de dispositivo que le había tocado a cada cacharrito para poder montarlo. La solución a mi problema era el udev.

(...)

Leer el resto de Creación de reglas udev para personalizar el nombre de los ficheros de dispositivo de las memorias USB (1,946 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 17 comentarios
Etiquetas: dbus, Debian, filesystems, GNU/Linux, hal, Kernel, memorias USB, udev

Feed enhanced by Better Feed from Ozh

rwxr-xr-x  8 root root    4096 2007-03-21 20:51 .
drwxr-xr-x 20 root root    4096 2006-11-18 11:34 ..
-rw-------  1 root root    6805 2007-03-19 19:56 .bash_history
-rw-r--r--  1 root root     535 2006-11-11 11:10 .bashrc
drwxr-xr-x  2 root root    4096 2006-11-21 21:16 .config
-rw-r--r--  1 root root  605281 2006-11-21 21:16 .fonts.cache-1
-rw-r--r--  1 root root       0 2007-03-21 20:51 mi_fichero
-rw-r--r--  1 root root     110 2004-11-10 17:10 .profile
-rw-------  1 root root    4394 2007-03-14 21:13 .viminfo
-rw-------  1 root root       0 2006-10-13 19:31 .Xauthority
-rw-------  1 root root     135 2006-10-13 19:31 .xsession-errors

cuando yo hubiera querido que me devolviera, como estoy acostumbrado, lo siguiente, para poder ver fácilmente qué archivos son los míos y cuáles son los de configuración (unos abajo y otros arriba del listado):

rwxr-xr-x  8 root root    4096 2007-03-21 20:51 .
drwxr-xr-x 20 root root    4096 2006-11-18 11:34 ..
-rw-------  1 root root    6805 2007-03-19 19:56 .bash_history
-rw-r--r--  1 root root     535 2006-11-11 11:10 .bashrc
drwxr-xr-x  2 root root    4096 2006-11-21 21:16 .config
-rw-r--r--  1 root root  605281 2006-11-21 21:16 .fonts.cache-1
-rw-r--r--  1 root root     110 2004-11-10 17:10 .profile
-rw-------  1 root root    4394 2007-03-14 21:13 .viminfo
-rw-------  1 root root       0 2006-10-13 19:31 .Xauthority
-rw-------  1 root root     135 2006-10-13 19:31 .xsession-errors
-rw-r--r--  1 root root       0 2007-03-21 20:51 mi_fichero

(...)

Leer el resto de La variable LC_COLLATE y la ordenación en la salida del comando “ls” (325 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Debian, GNU/Linux, internacionalización, LC_COLLATE, ls

Feed enhanced by Better Feed from Ozh

#/bin/bash
cd /var/log/apache2
BAKFILE=access.log.`date +%g%m%d%H%M`
mv access.log $BAKFILE
apache2ctl graceful
sleep 600
gzip $BAKFILE

Aparte de que el logrotate está mucho más indicado para este propósito, el misterio se ha desvelado gracias a un amable lector de barrapunto. Resulta que el apache2ctl está en /usr/sbin, no en /usr/bin ni en /bin, que son los únicos directorios que vienen en el PATH del cron por defecto ya que ni el /etc/profile ni el .bashrc ni similares se ejecutan en ningún momento antes del comando.

(...)

Leer el resto de El PATH del cron. Avisos de mail. Sesiones interactivas y de login de Bash. (650 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: Apache, bash, cron, Debian, exim, GNU/Linux

Feed enhanced by Better Feed from Ozh

Las particiones FAT son las que históricamente más juego nos han dado. Desde que FAT soporta nombres largos, por allá por los tiempos en los que el Windows 95 compartía un disco de 400MB con la SlackWare 96 y con un OS/2 3 Warp, las distintas versiones de FAT nos han facilitado la vida a aquellos que no nos hemos conformado con el sistema operativo que los chicos de Bill han tenido a bien meter en nuestras casas.

Pero llegaron los ficheros de más de 4 GB y las particiones de más de 32 GB y la situación empeoró mucho. En las particiones FAT32 no podemos crear ficheros de más de 4GB y no hay ningún workaround posible. Respecto al tamaño de la partición, ningún sistema operativo de Microsoft deja crear particiones FAT32 de más de 32GB, pero podemos hacerlas, por ejemplo con el fdisk de Linux y usarlas desde Windows sin problema.

(...)

Leer el resto de La pesadilla de compartir partición entre Linux y Windows (454 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: FAT, filesystems, GNU/Linux, NTFS-3G, Windows

Feed enhanced by Better Feed from Ozh

Sin embargo, durante muchos meses he tenido una Gentoo en uno de mis PCs. Si quieres usar Gentoo como toca, te tienes que compilar el paquete antes de instalarlo. También puedes usar paquetes precompilados, pero para eso no nos ponemos Gentoo, ¿no? El paquete se compila -en teoría- optimizado para la máquina en cuestión, y obtenemos algo de mejora en el rendimiento. Tenemos que pagar a cambio el coste de largos tiempos de espera compilando paquetes, algo que, pese a que Gentoo me gusta en general, me desespera.

Debian es todo lo contrario en ese aspecto: los paquetes vienen compilados para 386 y la optimización, por tanto, nula (ojo, Debian sí que nos deja escoger un kernel más apropiado para nuestra plataforma, algo que sí es muy importante). En esto hemos ganado mucho con la Debian AMD64, ya que ésta sí está totalmente optimizada si tienes un procesador de 64 bits.

(...)

Leer el resto de Gentooizar Debian con apt-build (924 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 4 comentarios
Etiquetas: apt-build, Debian, Gentoo, OpenSSH, OpenSSL, patch

Feed enhanced by Better Feed from Ozh

El Qemu emula diferentes plataformas sobre diferentes sistemas operativos. Si usamos el KQemu, recientemente liberado como GPL, el emulador pasa a usar virtualización y la velocidad del sistema operativo “virtualizado” está en el orden de la que obtendríamos con, por ejemplo, VMWare. VMWare es más maduro y estable pero el Qemu tiene muchas opciones con las que jugar fácilmente.

Pues bien, el Qemu soporta varios tipos de formato de imágenes del disco duro. Una de ellas es la “raw”, que es como si fuera un dd completo de un disco físico. Para montar una imagen “raw” del qemu se puede usar el siguiente comando:

mount -o loop,offset=32256 imagen_disco /path/punto_montaje

Está claro que lo que hace el comando es buscar el sitio dónde empieza la primera partición para usar la imagen como si se tratara de una “imagen de la partición”, no una “imagen del disco”, pero ¿por qué 32256? ¿tanto espacio hay libre antes de la primera partición? ¿casi 32Kb?

(...)

Leer el resto de Montar una imagen raw de Qemu. Los primeros 32 Kbytes de un disco. (962 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: dd, GNU/Linux, GRUB, particiones, PC, QEMU

Feed enhanced by Better Feed from Ozh

Los más típicos son:

Hexadecimal

Decimal

En la entrada de la WikiPedia sobre modos VESA aparecen los códigos para modos más raros aparecidos en las últimas tandas de portátiles.

En el Documentation/svga.txt del kernel tenemos algunos datos sobre el uso del parámetro “vga=XXX”.

También es posible obtener el código de ese modo VESA tan raro que sólo tu tarjeta tiene mirando la salida del Xorg.0.log. A esos códigos, como bien nos explica la WikiPedia, hay que sumarles 512 ó 0×200 según corresponda para poder usarlos como parámetro del kernel durante el arranque.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Sin comentarios
Etiquetas: GNU/Linux, Kernel, VESA

Feed enhanced by Better Feed from Ozh