Lo hice y lo entendí

El blog de Vicente Navarro
06 oct

Recuperando los datos de los discos de un fakeRAID

Mi viejo ordenador de sobremesa que no me había fallado nunca desde el 2005 murió hace un par de días. Creo que es la fuente de alimentación, aunque al abrirlo también he descubierto que uno de los anclajes de plástico de la placa base en los que se ancla el ventilador también se había roto y el ventilador no estaba bien sujeto. Sea como sea, he decidido no intentar arreglarlo. Uno ya no tiene tiempo para según que cosas como antes…

Lo único que quedaba era recuperar los datos del sistema. Intentar recuperar los datos de unos discos duros sin daños no sería ningún notición (los conectas a otro ordenador o los pones en una carcasa de disco USB y ya está) si no fuera porque dos de los tres discos duros del sistema estaban en fakeRAID, con RAID 0, tal como conté en Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID.

Cuando monté el ordenador y compré aquellos dos flamantes Maxtor SATA de 200GB ya con la idea de ponerlos en RAID 0, la idea parecía muy buena, sobre todo para alguien como yo que sólo tenía los benchmarks en mente. El rendimiento de los discos en RAID 0 era brutal. Pero claro, mantener un fakeRAID tiene muchas complicaciones: Cuesta más instalar Windows (Integrar drivers de SATA/RAID en un CD de instalación de Windows XP), cuesta más instalar Linux (Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID), te toca andar personalizando los initrd (Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.)… Y por supuesto, que estás corriendo muchos más riesgo de pérdida de datos.

Pero eso sí, el rendimiento era mucho mejor, así que valía la pena… ¿De verdad? Bueno, al principio sí era llamativo (recuerdo que en el SiSoft Sandra batía récords) pero unos pocos años más tarde añadí al sistema un Seagate de 750GB y bueno, resulta que él sólo ya tenía mejor tasa de transferencia que los dos Maxtor de 200GB en RAID 0.

En cualquier caso, estando obsesionado con que si algún día le pasaba algo a uno de los discos lo perdería todo, he sido muy formal haciendo mis backups semanales y aunque no hubiera intentado recuperar el contenido de los discos, los muy pocos cambios de los días previos no hubieran sido ninguna gran pérdida.

Pero bueno, había que intentarlo. Había llegado el momento: Tenía dos discos Maxtor de 200GB en las manos que habían estado en un fakeRAID de una controladora NVIDIA NForce 4 y el reto era ver si sería posible acceder a su contenido. Durante muchos años me había preguntado si se podría hacer. Mi duda principalmente era: ¿Es necesaria la controladora para que poniendo los discos en otro ordenador un Linux pueda entender a los datos del fakeRAID?

Y afortunadamente, la respuesta ha sido que no.

Puse los dos discos en sendas bases convertidoras de SATA a USB, una de ellas una Sharkoon como ésta (a la que se le rompió la tapa, los discos duros ya no se sujetaban bien, y tuve que retirarla y comprar la otra de marca Zaapa):

y tras conectar las bases a un portátil con Linux y al ejecutar el bendito dmraid, el resultado no pudo ser mejor:

# dmraid -ay -v -v -v 
WARN: locking /var/lock/dmraid/.lock
NOTICE: skipping removable device /dev/sdb
NOTICE: /dev/sdd: asr     discovering
NOTICE: /dev/sdd: ddf1    discovering
NOTICE: /dev/sdd: hpt37x  discovering
NOTICE: /dev/sdd: hpt45x  discovering
NOTICE: /dev/sdd: isw     discovering
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi     discovering
NOTICE: /dev/sdd: nvidia  discovering
NOTICE: /dev/sdd: nvidia metadata discovered
NOTICE: /dev/sdd: pdc     discovering
NOTICE: /dev/sdd: sil     discovering
NOTICE: /dev/sdd: via     discovering
NOTICE: /dev/sdc: asr     discovering
NOTICE: /dev/sdc: ddf1    discovering
NOTICE: /dev/sdc: hpt37x  discovering
NOTICE: /dev/sdc: hpt45x  discovering
NOTICE: /dev/sdc: isw     discovering
NOTICE: /dev/sdc: jmicron discovering
NOTICE: /dev/sdc: lsi     discovering
NOTICE: /dev/sdc: nvidia  discovering
NOTICE: /dev/sdc: nvidia metadata discovered
NOTICE: /dev/sdc: pdc     discovering
NOTICE: /dev/sdc: sil     discovering
NOTICE: /dev/sdc: via     discovering
NOTICE: /dev/sda: asr     discovering
NOTICE: /dev/sda: ddf1    discovering
NOTICE: /dev/sda: hpt37x  discovering
NOTICE: /dev/sda: hpt45x  discovering
NOTICE: /dev/sda: isw     discovering
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi     discovering
NOTICE: /dev/sda: nvidia  discovering
NOTICE: /dev/sda: pdc     discovering
NOTICE: /dev/sda: sil     discovering
NOTICE: /dev/sda: via     discovering
NOTICE: added /dev/sdd to RAID set "nvidia_bdehcbaa"
NOTICE: added /dev/sdc to RAID set "nvidia_bdehcbaa"
RAID set "nvidia_bdehcbaa" already active
INFO: Activating stripe raid set "nvidia_bdehcbaa"
NOTICE: discovering partitions on "nvidia_bdehcbaa"
NOTICE: /dev/mapper/nvidia_bdehcbaa: dos     discovering
NOTICE: /dev/mapper/nvidia_bdehcbaa: dos metadata discovered
NOTICE: created partitioned RAID set(s) for /dev/mapper/nvidia_bdehcbaa
RAID set "nvidia_bdehcbaa1" already active
INFO: Activating partition raid set "nvidia_bdehcbaa1"
RAID set "nvidia_bdehcbaa2" already active
INFO: Activating partition raid set "nvidia_bdehcbaa2"
RAID set "nvidia_bdehcbaa3" already active
INFO: Activating partition raid set "nvidia_bdehcbaa3"
RAID set "nvidia_bdehcbaa5" already active
INFO: Activating partition raid set "nvidia_bdehcbaa5"
RAID set "nvidia_bdehcbaa6" already active
INFO: Activating partition raid set "nvidia_bdehcbaa6"
WARN: unlocking /var/lock/dmraid/.lock

Vemos que el dmraid revisa todos los discos para ver si encuentra metadatos de una de las controladoras fakeRAID que soporta. En este caso, encuentra metadatos de una controladora NForce (“nvidia metadata discovered“) en los discos /dev/sdc y /dev/sdd y así, es capaz de descubrir las particiones que podemos montar sin problemas y recuperar los datos.

Por tanto, la lección que he aprendido esta semana es que la controladora fakeRAID realmente no aporta nada más que el soporte en la BIOS para poder arrancar de los discos en RAID, pero ciertamente, todo el resto del trabajo lo hace la CPU y el sistema operativo. Y de hecho, por eso es un fakeRAID, porque la controladora realmente no hace que la existencia de un RAID sea transparente para el sistema operativo. Como nota curiosa, en el sistema también tenía MS-DOS, y el MS-DOS no necesitaba un driver especial para poder estar instalado en un sistema con fakeRAID como sí necesitan Windows y Linux, por lo que parecería que el RAID sí era transparente para MS-DOS, pero porque en realidad MS-DOS usa llamadas a la BIOS para acceder al disco y era en este caso la BIOS la que hacía el trabajo extra.

:wq

05 nov

VPN con OpenSSH

Tras Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH y Reenvío dinámico de puertos / montar un servidor SOCKS con SSH, puede ser buena idea hablar de cómo crear una VPN improvisada entre dos redes cuyos nodos no pueden llegar de una red a la otra exceptuando un sistema de una de las redes que puede crear una conexión OpenSSH con otro sistema de la otra red.

OpenSSH permite esto desde su versión 4.3, y es tan sencillo que en la página man de ssh se describe en apenas 5 párrafos (sección SSH-BASED VIRTUAL PRIVATE NETWORKS). La parte no tan sencilla es la de gestionar las rutas.

Además, como digo, esta configuración es adecuada para una red improvisada y no como solución definitiva porque, como indica la propia página de manual, la sobrecarga por el protocolo SSH es muy alta:

     Since an SSH-based setup entails a fair amount of overhead, it may be
     more suited to temporary setups, such as for wireless VPNs.  More
     permanent VPNs are better provided by tools such as ipsecctl(8) and
     isakmpd(8).

Vamos a trabajar con el escenario mostrado en el siguiente esquema:

Tenemos dos oficinas de una misma empresa conectadas internamente y a Internet con el típico router/switch ADSL que tiene una única IP pública y que hace NAT para compartirla. Ahora queremos interconectarlas, de forma que todos los nodos de una oficina accedan a los de la otra y viceversa. En la primera de ellas se usa la subred 192.168.10.0/24 para la red local, y en la segunda, la subred 172.16.20.0/24. En la configuración del NAT del router ADSL de la segunda oficina abrimos el puerto 22 de SSH y lo redirigimos hacia el nodo servidorssh172 (172.16.20.2), que está ejecutando el sshd de OpenSSH. La IP pública de la segunda oficina debería ser fija o tal vez se podría usar un servicio de DNS dinámico. El nodo clientessh192 (192.168.10.2) de la primera red establecerá una conexión OpenSSH con el nodo servidorssh172 (172.16.20.2) de la segunda red usando la IP pública de la segunda oficina.

Sigue leyendo »

28 oct

Unidades montadas y enlaces simbólicos en Windows

Supongamos que tenemos el típico sistema UNIX en el que hay varios sistemas de ficheros,el de /, uno para /usr, otro para /var, otro para /home, etc. ¿Qué haríamos si necesitáramos más espacio en alguno de ellos?

Lo más típico sería tratar de extender el sistema de ficheros, especialmente si estamos usando LVM, ya que sólo necesitaríamos algo de sitio libre en el VG. En Linux, si estamos usando particiones de toda la vida, también podríamos extender el sistema de ficheros con aplicaciones como GParted.

Otra opción bastante típica es la de montar un nuevo sistema de ficheros allí donde necesitemos espacio. Por ejemplo, si necesitamos más sitio en /opt/applicacionX porque ahí vamos a instalar una aplicación que necesita mucho espacio, podemos montar ahí un nuevo sistema de ficheros con todo el espacio necesario.

Si no tenemos espacio disponible en los discos, pero sí en otros sistemas de ficheros, siempre podemos hacer la típica chapucilla de crear un enlace simbólico del sistema de ficheros sin sitio a algún directorio del sistema de ficheros con suficiente espacio libre.

Hace unos días me encontré con una situación similar, pero en Windows. Me quedé sin espacio en C: y lo necesitaba para que cierta aplicación pudiera funcionar bien. Explorando las opciones que tenía, resulta que todas estas cosas que típicamente hacemos en sistemas UNIX también las podemos hacer en Windows.

Sigue leyendo »

29 jun

Evitando problemas con la “host key” en sesiones no interactivas de OpenSSH

Cuando usamos el comando ssh de OpenSSH (típicamente desde sistemas UNIX o desde Cygwin) para conectarnos a una máquina remota por primera vez, normalmente (con la configuración por defecto más usual) recibimos un mensaje como el siguiente para advertirnos de que es la primera vez que nos conectamos a dicha máquina y que si aceptamos la clave del host remoto:

$ 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

17 ene

Cambiar la ordenación por defecto de elementos en Thunderbird

Desde que uso Thunderbird, una de las pocas cosas que siempre me ha molestado es que cuando creas una nueva carpeta, la ordenación por defecto que va a usar es por fecha ascendente. Es decir, los elementos (típicamente correos) se ordenan de forma que los correos más antiguos están arriba y los más nuevos están abajo. Si tienes muchos a la vista, los últimos recibidos directamente no son visibles a menos que usemos la barra de desplazamiento:

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)

Sigue leyendo »

26 oct

Comentarios sobre la Playstation 3 como reproductor multimedia para una televisión de tubo y sobre GNU/Linux en la Playstation 3

Hace unas semanas estuve buscando un disco duro multimedia con toma de LAN para reemplazar mi vetusto reproductor de DVD (y DivX, Xvid, etc.) que ha satisfecho todas mis necesidades desde hace más de 5 años hasta que me he cansado de ir grabando todo lo que quería ver en DVDs.

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:

Convertidor S-Video a SCART

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:

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.

Playstation 3

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

Sigue leyendo »

22 ago

Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions

Tengo por aquí un sistema Linux en el que exporto el directorio $HOME de los usuarios por red a través de Samba/CIFS.

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 usuarios 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

Sigue leyendo »

13 jun

Reenvío dinámico de puertos / montar un servidor SOCKS con SSH

En la entrada anterior, Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH, vimos todas las posibilidades que tenemos a nuestra disposición para el reenvío de puertos (port forwarding)… pero para el reenvío de puertos estático. Es decir, allí sólo vimos casos en los que queríamos acceder únicamente a un puerto de otro sistema encauzándolo por dentro de la conexión SSH.

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.

Sigue leyendo »

24 may

Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH

La función típica del protocolo de red Secure Shell (SSH) es acceder en modo terminal a un sistema remoto y ejecutar allí comandos de forma segura gracias a que los datos van cifrados. Pero además, a través de esa conexión de datos segura, es posible crear túneles (reenviar puertos / port forwarding) entre los extremos conectados de forma que las conexiones TCP/IP se encauzan a través de la conexión SSH con lo que podemos conseguir saltarnos cualquier firewall o bloqueo de puertos siempre que tengamos la posibilidad de conectar con SSH.

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

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.

Túneles SSH: Sin túnel

Sigue leyendo »

16 may

rsync siempre sincroniza ciertos ficheros. Ver los segundos de la fecha de un fichero.

Tengo una memoria USB de 8 GB en la que suelo sincronizar con rsync (Backups con rsync) algunos ficheros de mi ordenador principal que quiero llevar siempre conmigo.

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

Sigue leyendo »

 Anterior 1 2 3 4 5 6 7 8 ... 16 17 18 Siguiente
Tema LHYLE09, creado por Vicente Navarro