Pequeños trucos para Windows

Tengo por aquí apuntados unos cuantos pequeños trucos para Windows que he ido descubriendo últimamente y que me han venido muy bien. Me gustaría compartirlos en esta entrada.

Esconder un usuario de la pantalla inicial de selección de usuario

Cuando usamos Windows XP, Vista, 7, etc. con la configuración doméstica de por defecto (en la que sale una imagen para cada usuario y no en la que hay que escribir a mano el nombre del usuario), podemos querer ocultar alguno de los usuarios de dicha pantalla. Eso me pasó a mí recientemente tras instalar el servicio sshd de Cygwin en un Windows 7 (Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.)): pasé de tener en la pantalla de inicio sólo el usuario habitual de Windows a tener también el usuario cyg_server (que aparece como Privileged User). Pude esconderlo con facilidad abriendo el regedit, yendo a:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

y añadiendo una clave “SpecialAccounts” y dentro de ella otra llamada “UserList”. A continuación, dentro de:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\SpecialAccounts\UserList

creamos una entrada de tipo DWORD cuyo nombre sea el nombre del usuario que queremos esconder (en mi caso cyg_server) y con valor cero (0). Tras un reinicio, el usuario que no queremos ver deja de estar disponible.

Hide User Accounts on Windows 7 Logon Hide user account from welcome screen in windows 7

Utilidad para configuración avanzada de usuarios

En Windows XP y Windows Vista, la utilidad estándar para configurar usuarios que encontramos en el Panel del Control es muy “doméstica” y le faltan muchas opciones. La utilidad típica de configurar usuarios que venía con Windows 2000 seguía estando en sus sucesores XP y Vista pero había que lanzarla a mano con el comando:

control userpasswords2

En Windows 7, la utilidad de gestión de usuarios estándar sigue siendo “doméstica” y la utilidad “alternativa” sigue estando disponible, aunque ahora hay que lanzarla con el comando:

netplwiz

Un dato importante es que desde esta utilidad no podremos lanzar la utilidad de gestión avanzada de usuarios y grupos locales en las versiones Home de Windows 7, sólo en las Professional, Ultimate y Enterpise.

How to turn on automatic logon in Windows XP Configure a User Account to Log On Automatically on Windows 7 How to Open “Local Users and Groups” in Windows 7

Extraer los ficheros de un .msi

¿Te ha pasado alguna vez tener un fichero .msi de Windows Installer y necesitar extraer algún fichero de dentro pero sin querer instalar la aplicación? Sólo tienes que ejecutar este comando:

msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo

Por ejemplo:

msiexec /a 7z920-x64.msi /qb TARGETDIR=c:\Temp\7z

El directorio destino se creará si no existe.

Howto: extract files from a .msi file using the Windows command line

Obtener el BSSID y otros detalles adicionales de las redes WiFi al alcance

¿Necesitas saber más detalles sobre las redes WiFi que tienes a tu alcance y no tienes ninguna herramienta adicional, sólo las que trae Windows por defecto? En Windows Vista, 2008 y 7, ¡netsh te puede ayudar! (netsh está disponible en versiones anteriores, pero sólo en éstas lleva funciones de WiFi).

C:\Users\Usuario\Desktop>netshnetsh>wlannetsh wlan>show networks mode=Bssid

Interface name : Wireless Network ConnectionThere are 2 networks currently visible.

SSID 1 : Jazztel_A6 Network type : Infrastructure Authentication : WPA-Personal Encryption : CCMP BSSID 1 : c4:75:0f:2b:b6:25 Signal : 52% Radio type : 802.11g Channel : 1 Basic rates (Mbps) : 1 2 5.5 6 9 11 12 18 24 36 48 54

SSID 2 : WLAN_99 Network type : Infrastructure

Authentication : Open Encryption : WEP BSSID 1 : 01:21:c8:fe:6f:df Signal : 63% Radio type : 802.11g Channel : 9 Basic rates (Mbps) : 1 2 5.5 11 Other rates (Mbps) : 6 9 12 18 24 36 48 54

Netsh Command Reference

Barra de inicio rápido (Quick Launch) en Windows 7

Aquellos de vosotros que, como yo, seáis unos reaccionarios de las nuevas interfaces de usuario (Windows 7, KDE 4, Gnome 3, Unity) seguro que renegaréis de la nueva barra de tareas de Windows 7 y tal vez tratéis de configurarla de la forma más parecida posible a lo que solía ser en versiones anteriores. En tal caso, seguro que os vendrá bien saber cómo volver a añadir la barra de inicio rápido.

Sólo hay que hacer clic con el botón derecho sobre la barra de tareas, ir a “Barras de herramientas”, elegir “Nueva barra de herramientas” y cuando nos pida la localización de ésta, escribir:

%userprofile%\appdata\roaming\microsoft\internet Explorer\Quick Launch

A continuación, haremos clic con el botón derecho sobre la nueva barra y quitaremos las opciones “Mostrar texto” y “Mostrar título” para tener una barra de inicio rápido como siempre.

Cómo usar el inicio rápido en Windows 7

Extender o reducir una partición NTFS de Windows

Imaginemos la siguiente situación bastante típica: Tienes un PC con Windows instalado en una única partición que ocupa todo el disco en el que queremos instalar, por ejemplo, alguna distribución de Linux. ¿Qué haríamos? Pues podríamos arrancar con cualquier LiveCD de alguna distribución de Linux que contenga el GParted (también tiene su propio LiveCD) y usarlo para hacer la partición de Windows más pequeña. Pero ahora, con Windows 7, también podemos usar el propio gestor de discos de Windows para hacerlo muy fácilmente. Lo lanzamos ejecutando:

diskmgmt.msc

Y aquí, haciendo clic con el botón derecho sobre cualquier partición, encontraremos opciones para reducir y ensanchar el tamaño de las particiones (siempre que estas operaciones sean posibles).

Extend a Basic Volume

Shrink a Basic Volume

:wq!

Publicado en Windows | Etiquetas: Cygwin, NTFS, particiones, Windows | 2 Comentarios | Escrito por Vicente Navarro

04 nov

Mantener el reenvío de ventanas X de SSH tras hacer un su

Es muy común que sistemas UNIX/Linux a los que se accede por SSH no permitan acceso directo con root. Hay que autentificarse como un usuario normal y luego, si se necesita acceso de root, se usa su para obtener una shell de root. En sistemas con OpenSSH, en el fichero /etc/sshd/sshd_config encontraremos el parámetro PermitRootLogin, que está a “no” en muchos sistemas. Entre las ventajas de no permitir acceso directo de root está que el usuario -en teoría- no se pasará a root a menos que lo necesite y que queda registrado qué usuarios están/han estado en el sistema.

Pero esta configuración genera problemas con el reenvio de ventanas X11 a través de SSH. Por ejemplo, con sistemas HP-UX y Solaris (luego veremos qué pasa con Linux), cuando accedes por SSH con un usuario reenviando las ventanas X11 y luego haces un su, perdemos el túnel de X11:

$ ssh -X usuarioprueba@solx86Password:Sun Microsystems Inc. SunOS 5.10 Generic January 2005$$ echo $DISPLAYlocalhost:10.0$$ /usr/openwin/bin/xclock$$ su -Password:Sun Microsystems Inc. SunOS 5.10 Generic January 2005## echo $DISPLAY## /usr/openwin/bin/xclockError: Can't open display:

Si ponemos a mano la variable $DISPLAY, el error pasará de ser que no puede acceder al display a que no tiene autorización para usar el display:

# DISPLAY=localhost:10.0# export DISPLAY## /usr/openwin/bin/xclockX11 connection rejected because of wrong authentication.

X connection to localhost:10.0 broken (explicit kill or server shutdown).

Una solución, aprovechando que root puede acceder a los ficheros de todos los usuarios, es modificar la variable $XAUTHORITY para usar el fichero .Xauthority del usuario con el que entramos y no el de root:

# XAUTHORITY=/export/home/usuarioprueba/.Xauthority# export XAUTHORITY## /usr/openwin/bin/xclock

Al entrar a un sistema por SSH con la opción de reenvío de X11 activada, el servidor SSH añade una MIT-MAGIC-COOKIE-1 al fichero $HOME/.Xauthority para que sólo ese usuario (y no otros que estén conectados a la máquina e intenten usar el mismo $DISPLAY) pueda usar su túnel SSH para reenviar ventanas X11. Si el usuario root usa la misma magic cookie, pues podrá entrar sin problemas.

Otra opción para no reemplazar por completo el .Xauthority de root pasa por listar las magic cookies disponibles en el .Xauthority del usuario:

$ /usr/openwin/bin/xauth listclientessh:0 MIT-MAGIC-COOKIE-1 e712f99f148d5bf00e5df9f345635434sistemavncserver:1 MIT-MAGIC-COOKIE-1 d30c3ab6ca017837260ff6221fd80da7solx86/unix:10 MIT-MAGIC-COOKIE-1 1d9076a2068a5e79d1259bea382cec2d

extraemos en formato binario sólo la entrada que nos interesa:

$ /usr/openwin/bin/xauth extract .Xauthority_solx86 solx86/unix:10

y ya como root, unimos la entrada a las existentes y ya podremos acceder al servidor X:

$ su -Password:Sun Microsystems Inc. SunOS 5.10 Generic January 2005# DISPLAY=localhost:10.0# export DISPLAY## /usr/openwin/bin/xauth merge /export/home/prueba/.Xauthority_solx86## /usr/openwin/bin/xauth listsolx86/unix:10 MIT-MAGIC-COOKIE-1 1d9076a2068a5e79d1259bea382cec2d## /usr/openwin/bin/xclock

Y otra opción más sería, tras listar las entradas existentes, simplemente añadir la magic cookie a mano en el .Xauthority de root:

# /usr/openwin/bin/xauth add solx86/unix:10 MIT-MAGIC-COOKIE-1 1d9076a2068a5e79d1259bea382cec2d## /usr/openwin/bin/xclock

Decíamos que en Linux no tenemos este problema. Al pasarnos a root, la variable $DISPLAY se conserva y no necesitamos añadir la magic cookie para que el reenvío de ventanas X11, simplemente, siga funcionando:

# ssh -X usuariopruebap@rh5x64usuariopruebap@rh5x64's password:$$ xclock$$ echo $DISPLAYlocalhost:10.0$$ su -Password:[root@rh5x64 ~]# echo $DISPLAYlocalhost:10.0

Esta magia de los sistemas Linux la proporciona el módulo PAM pam_xauth:

The pam_xauth PAM module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su(1) command to assume another user’s privileges, that user is no longer able to access the original user’s X display because the new user does not have the key needed to access the display. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Así, en el fichero /etc/pam.d/su, típicamente encontraremos una línea como ésta:

session optional pam_xauth.so

El módulo guarda las magic cookies necesarias en diferentes ficheros $HOME/.xauth??????:

# xauth -f .xauthrBGj8r listrh5x64/unix:10 MIT-MAGIC-COOKIE-1 aaceeca9bf499b5c85aba64a3ae42bd0

que, aunque normalmente se eliminan solos al salir, en ocasiones se quedan ahí abandonados. Por ello, en Google podemos encontrar bastantes casos de gente preguntando qué son dichos ficheros .xauthXXXXX y por qué tienen muchos.

Y para finalizar, una mención al Remote X Apps mini-HOWTO, en el que podremos repasar los conceptos básicos sobre cómo ejecutar aplicaciones X11 de un sistema en el servidor X de otro sistema UNIX/Linux.

:wq

Publicado en GNU/Linux, UNIX | Etiquetas: GNU/Linux, HP-UX, OpenSSH, Solaris, SSH, UNIX, X Window System | 8 Comentarios | Escrito por Vicente Navarro

20 oct

Port Knocking

Hace unas semanas leí por primera vez sobre el port knocking en “Security by Default: Una autenticación fuerte para Openvpn“. No conocía la idea y me ha parecido muy interesante y útil. Consiste en enviar una secuencia de paquetes a un sistema que active un servicio que anteriormente estaba cerrado.

Por ejemplo, cualquiera que tenga un sistema con un servidor SSH expuesto a Internet sabrá que no es nada infrecuente encontrar registrados diferentes intentos de intrusión en el sistema (en el /var/log/auth.log en un sistema Debian):

Oct 19 09:31:49 darkstar sshd[13481]: Invalid user fluffy from 202.102.XX.XXOct 19 09:32:02 darkstar sshd[13493]: Invalid user oracle from 202.102.XX.XXOct 19 09:32:08 darkstar sshd[13500]: Invalid user www from 202.102.XX.XXOct 19 09:32:17 darkstar sshd[13508]: Invalid user postmaster from 202.102.XX.XXOct 19 09:32:31 darkstar sshd[13520]: Invalid user file from 202.102.XX.XX

Si el servidor de SSH sólo permite autentificación por clave privada/pública (Autentificación trasparente por clave pública/privada con OpenSSH) podemos estar razonablemente tranquilos de que el intento de intrusión no tendrá éxito. Pero como nunca se puede estar seguro del todo, puede ser buena idea añadir, adicionalmente, un sistema de port knocking para abrir el puerto SSH sólo cuando realmente lo vayamos a usar.

En un sistema basado en Debian, esto se puede hacer muy fácilmente con el demonio knockd, uno de los paquetes oficiales de la distribución. Tras instalar el paquete, tenemos que editar el fichero /etc/default/knockd para permitir que el demonio arranque:

# PLEASE EDIT /etc/knockd.conf BEFORE ENABLINGSTART_KNOCKD=1

y especificarle cualquier opción que queramos usar, especialmente en qué interfaz tiene que escuchar si no es el "eth0":

# command line options# KNOCKD_OPTS="-i eth1"

Hay que tener en cuenta que el knockd siempre ve los paquetes llegar, incluso si los puertos están cerrados y si alguna regla de iptables rechaza el paquete. Podríamos decir que se comporta como el tcpdump, en el sentido de que el interfaz se pone en modo promiscuo y

ve todo lo que llega a él. Pero adicionalmente, según qué paquetes vea, ejecuta una acción. Por cierto, parece que no funciona poner dos interfaces con "-i eth0 -i eth1".

A continuación, tenemos que personalizar el fichero /etc/knockd.conf para especificar qué secuencia de puertos queremos y qué hacer cuando ésta llegue. En el “man knockd” encontramos interesantes ejemplos de uso, pero podemos centrarnos en el más típico que es el que instala Debian por defecto:

[openSSH] sequence = 7000,8000,9000 seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn

[closeSSH] sequence = 9000,8000,7000 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn

Vemos que cuando llega una secuencia de paquetes TCP con el flag de SYN a los puertos 7000, 8000 y 9000 en menos de 5 segundos, el demonio knockd añade una regla de iptables para permitir el acceso al servicio SSH a la IP que ha hecho el port knocking. Y con otra secuencia, podemos cerrar el puerto posteriormente.

Tras configurar el /etc/knockd.conf a nuestro gusto, arrancamos el knockd con “/etc/init.d/knockd start“.

Para mandar la secuencia que active la acción podemos usar, desde otro sistema, el comando knock, que se instala también al instalar el paquete knockd:

[root@clientessh ~]# knock 192.168.100.2 7000 8000 9000

y en el sistema en el que hemos arrancado el knockd vemos cómo los paquetes llegan y se ejecuta la acción planificada para dicha secuencia:

Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 1Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 2Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 3Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: OPEN SESAMEOct 19 21:55:17 darkstar knockd: openSSH: running command: /sbin/iptables -A INPUT -s 192.168.100.1 -p tcp --dport 22 -j ACCEPT

El hecho de que podamos ejecutar cualquier comando nos da total flexibilidad. Por ejemplo, se me ocurre que en vez de, o adicionalmente a añadir o quitar reglas de iptables, también podríamos incluso arrancar o parar el demonio sshd:

[openSSH]

sequence = 7000,8000,9000 seq_timeout = 5 command = /etc/init.d/ssh start tcpflags = syn

[closeSSH] sequence = 9000,8000,7000 seq_timeout = 5 command = /etc/init.d/ssh stop tcpflags = syn

Lo que nos quedaría por ver es qué alternativas tenemos para mandar la secuencia de puertos. Hemos visto que el propio paquete knockd de Debian lleva el comando knock. Pero, ¿hay alternativas? ¿y si queremos hacer port knocking desde Windows? ¿y si queremos hacerlo desde un sistema que no tenga ningún software especial?

La propia página de man de knockd nos sugiere algunas alternativas:

knock is the accompanying port-knock client, though telnet or netcat could be used for simple TCP knocks instead. For more advanced knocks, see hping, sendip or packit.

Una posibilidad para Windows también es el KnockKnock, descubierto gracias a “Add Port Knocking to SSH for Extra Security“:

pero un inconveniente del KnockKnock es que lanza la secuencia más de una vez:

Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 1

Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 2Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 3Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 4Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAMEOct 19 22:38:32 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1 -p tcp --dport 22 -j ACCEPTOct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 2Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 3Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 4Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAMEOct 19 22:38:33 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1 -p tcp --dport 22 -j ACCEPTOct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 2Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 3Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 4Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAMEOct 19 22:38:34 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1 -p tcp --dport 22 -j ACCEPT

Si el comando a ejecutar se puede ejecutar más de una vez sin otros efectos, como es el caso del iptables, nos da igual, pero en otros casos, puede ser un problema.

Otra solución es usar el cliente de telnet de Windows contra los diferentes puertos para activar la secuencia. Para ello, en Windows se puede usar un .bat con este aspecto:

start telnet 192.168.100.2 7000start telnet 192.168.100.2 8000start telnet 192.168.100.2 9000

El resultado no siempre es el deseado. El telnet de Windows envía varios paquetes SYN cuando falla el primero y parece que el knockd no siempre acepta la secuencia. Pero bueno, normalmente antes de 4 o 5 intentos, ya ha funcionado la secuencia.

Por supuesto, el knockd es un punto de fallo adicional en el acceso al sistema. Si le pasa algo a este demonio, nos quedaremos sin poder acceder.

Actualización 21/10/11: Como comentan Dany y SebaMinguez en los comentarios, también podemos configurar port knocking sólo con reglas iptables: Multiple-port knocking Netfilter/IPtables only implementation.

:wq

Publicado en GNU/Linux | Etiquetas: Debian, GNU/Linux, OpenSSH, Redes, Windows | 11 Comentarios | Escrito por Vicente Navarro

07 oct

Accediendo a una red mediante NAT en Linux

En las últimas entradas he tratado bastante de cómo acceder a nodos de una red remota por “métodos no estándar”:

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

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

Cuando digo “métodos no estándar”, me refiero a que normalmente la conectividad entre redes en una intranet o en Internet se consigue con las rutas definidas en los routers de la red. Los routers saben (o deberían saber) cómo llegar de un nodo en la red A a otro nodo en la red B.

Ahora supongamos que estamos en una gran intranet corporativa con muchas subredes. Supongamos también que tenemos un sistema con Linux con dos interfaces Ethernet. Uno de ellos conectado a la red “oficial” y el otro conectado a un switch al que conectamos varios servidores (Linux, Windows, etc.). Necesitamos que dichos servidores puedan llegar a nodos de la intranet “oficial” y necesitamos acceder a ciertos servicios de los servidores desde la intranet. De momento, esos servidores estarán en una “red oculta” o “inalcanzable” para el resto de nodos de la intranet.

El “método estándar” sería que el administrador de la intranet definiera en los routers de la intranet una ruta para que todos los nodos de la red supieran llegar. Pero si eso no es posible o conveniente (lo contrario implicaría mucha burocracia, va a ser una situación temporal, así proporcionamos más seguridad a la red oculta), es cuando tenemos que usar “metodos no estándar”.

Las soluciones usando OpenSSH descritas en entradas anteriores nos resolvían esta situación perfectamente. Pero, ¡ay! Resulta que OpenSSH introduce una sobrecarga importante: Los nodos que mantienen la conexión SSH estarán permanentemente cifrando toda la comunicación, usarán más CPU y la conexión será menos ligera y fluida.

La alternativa, en la que usamos únicamente técnicas estándar del protocolo IP, sería usar NAT. La idea sería que el sistema Linux se comportara como un router ADSL o de cable como los que solemos tener en casa, que hacen NAT y que nos permiten abrir sólo unos pocos puertos para acceder a ciertos servicios de la red interna.

Así, consideremos el siguiente diagrama en el que vemos que el Linux tiene la IP 10.25.25.2 (eth0) en la intranet “oficial” y la IP 172.16.20.2 (eth1) en la red interna “oculta”:

Sigue leyendo »

Publicado en GNU/Linux, Redes | Etiquetas: GNU/Linux, iptables, NAT, OpenSSH, Redes, Windows | 2 Comentarios | Escrito por 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 -vWARN: locking /var/lock/dmraid/.lockNOTICE: skipping removable device /dev/sdb

NOTICE: /dev/sdd: asr discoveringNOTICE: /dev/sdd: ddf1 discoveringNOTICE: /dev/sdd: hpt37x discoveringNOTICE: /dev/sdd: hpt45x discoveringNOTICE: /dev/sdd: isw discoveringNOTICE: /dev/sdd: jmicron discoveringNOTICE: /dev/sdd: lsi discoveringNOTICE: /dev/sdd: nvidia discoveringNOTICE: /dev/sdd: nvidia metadata discoveredNOTICE: /dev/sdd: pdc discoveringNOTICE: /dev/sdd: sil discoveringNOTICE: /dev/sdd: via discoveringNOTICE: /dev/sdc: asr discoveringNOTICE: /dev/sdc: ddf1 discoveringNOTICE: /dev/sdc: hpt37x discoveringNOTICE: /dev/sdc: hpt45x discoveringNOTICE: /dev/sdc: isw discoveringNOTICE: /dev/sdc: jmicron discoveringNOTICE: /dev/sdc: lsi discoveringNOTICE: /dev/sdc: nvidia discoveringNOTICE: /dev/sdc: nvidia metadata discoveredNOTICE: /dev/sdc: pdc discoveringNOTICE: /dev/sdc: sil discoveringNOTICE: /dev/sdc: via discoveringNOTICE: /dev/sda: asr discoveringNOTICE: /dev/sda: ddf1 discoveringNOTICE: /dev/sda: hpt37x discoveringNOTICE: /dev/sda: hpt45x discoveringNOTICE: /dev/sda: isw discoveringNOTICE: /dev/sda: jmicron discoveringNOTICE: /dev/sda: lsi discoveringNOTICE: /dev/sda: nvidia discoveringNOTICE: /dev/sda: pdc discoveringNOTICE: /dev/sda: sil discoveringNOTICE: /dev/sda: via discoveringNOTICE: added /dev/sdd to RAID set "nvidia_bdehcbaa"NOTICE: added /dev/sdc to RAID set "nvidia_bdehcbaa"RAID set "nvidia_bdehcbaa" already activeINFO: Activating stripe raid set "nvidia_bdehcbaa"NOTICE: discovering partitions on "nvidia_bdehcbaa"NOTICE: /dev/mapper/nvidia_bdehcbaa: dos discoveringNOTICE: /dev/mapper/nvidia_bdehcbaa: dos metadata discoveredNOTICE: created partitioned RAID set(s) for /dev/mapper/nvidia_bdehcbaaRAID set "nvidia_bdehcbaa1" already activeINFO: Activating partition raid set "nvidia_bdehcbaa1"RAID set "nvidia_bdehcbaa2" already activeINFO: Activating partition raid set "nvidia_bdehcbaa2"RAID set "nvidia_bdehcbaa3" already activeINFO: Activating partition raid set "nvidia_bdehcbaa3"RAID set "nvidia_bdehcbaa5" already activeINFO: Activating partition raid set "nvidia_bdehcbaa5"RAID set "nvidia_bdehcbaa6" already activeINFO: 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

Publicado en GNU/Linux, Hardware, Windows | Etiquetas: dmraid, GNU/Linux, Hardware, RAID, SATA, Windows | 7 Comentarios | Escrito por Vicente Navarro

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 »

Publicado en GNU/Linux, Redes, UNIX | Etiquetas: GNU/Linux, OpenSSH, Redes, UNIX, Windows | 9 Comentarios | Escrito por Vicente Navarro

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 »

Publicado en UNIX, Windows | Etiquetas: UNIX, Windows | 8 Comentarios | Escrito por Vicente Navarro

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@sistemaThe 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)? yesWarning: 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_hostssistema.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 is77: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:2RSA 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.dominioWarning: 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 noUserKnownHostsFile /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.dominioWarning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.[usuario@sistema ~]$ exit

$ ssh usuario@sistema.dominioWarning: 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

Publicado en GNU/Linux, Redes, UNIX | Etiquetas: Cygwin, GNU/Linux, OpenSSH, UNIX | 9 Comentarios | Escrito por Vicente Navarro

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 »

Publicado en GNU/Linux, Windows | Etiquetas: Thunderbird | 4 Comentarios | Escrito por Vicente Navarro

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:

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

o Problemas con ficheros de vídeo con el audio en AC3 o Soporte de subtítulos o MKV

Mando a distancia Media Servers Almacenamiento, copia de contenidos a través de la red Linux en la PS3

o Prestaciones o Conmutar entre PSUbuntu y XMB o Resoluciones de vídeo disponibles o Memoria RSX como swap o Comentarios finales