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>netsh
netsh>wlan
netsh wlan>show networks mode=Bssid

Interface name : Wireless Network Connection
There 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!

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Cygwin, NTFS, particiones, Windows

Entradas relacionadas

• Usando ntfsclone y dd para clonado por red con netcat (2)
• Trabajando con Cygwin (2)
• Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (2)
• Recuperación de particiones perdidas con gpart (2)
• Instalar un Cygwin portable en una memoria USB (2)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (2)

Feed enhanced by Better Feed from Ozh

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@solx86
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$
$ echo $DISPLAY
localhost:10.0
$
$ /usr/openwin/bin/xclock
$
$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
#
# echo $DISPLAY
#
# /usr/openwin/bin/xclock
Error: 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/xclock
X11 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 list
clientessh:0  MIT-MAGIC-COOKIE-1  e712f99f148d5bf00e5df9f345635434
sistemavncserver:1  MIT-MAGIC-COOKIE-1  d30c3ab6ca017837260ff6221fd80da7
solx86/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 list
solx86/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@rh5x64
usuariopruebap@rh5x64's password:
$
$ xclock
$
$ echo $DISPLAY
localhost:10.0
$
$ su -
Password:
[root@rh5x64 ~]# echo $DISPLAY
localhost: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 list
rh5x64/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

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 8 comentarios
Etiquetas: GNU/Linux, HP-UX, OpenSSH, Solaris, SSH, UNIX, X Window System

Entradas relacionadas

• VPN con OpenSSH (3)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (3)
• Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (3)
• Evitando problemas con la “host key” en sesiones no interactivas de OpenSSH (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)
• Autentificación trasparente por clave pública/privada con OpenSSH (3)

Feed enhanced by Better Feed from Ozh

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.XX
Oct 19 09:32:02 darkstar sshd[13493]: Invalid user oracle from 202.102.XX.XX
Oct 19 09:32:08 darkstar sshd[13500]: Invalid user www from 202.102.XX.XX
Oct 19 09:32:17 darkstar sshd[13508]: Invalid user postmaster from 202.102.XX.XX
Oct 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 ENABLING
START_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 1
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 2
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: Stage 3
Oct 19 21:55:17 darkstar knockd: 192.168.100.1: openSSH: OPEN SESAME
Oct 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 2
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:32 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:32 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 19 22:38:33 darkstar knockd: Prueba: running command: /sbin/iptables -A INPUT -s 192.168.100.1    -p tcp --dport 22 -j ACCEPT
Oct 19 22:38:33 darkstar knockd: 192.168.100.1: Prueba: Stage 1
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 2
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 3
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: Stage 4
Oct 19 22:38:34 darkstar knockd: 192.168.100.1: Prueba: OPEN SESAME
Oct 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 7000
start telnet 192.168.100.2 8000
start 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

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

Entradas relacionadas

• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (5)
• VPN con OpenSSH (4)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (4)
• Accediendo a una red mediante NAT en Linux (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)
• Hosting casero HOWTO (3)

Feed enhanced by Better Feed from Ozh

• 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”:

(...)

Leer el resto de Accediendo a una red mediante NAT en Linux (976 palabras)

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 2 comentarios
Etiquetas: GNU/Linux, iptables, NAT, OpenSSH, Redes, Windows

Entradas relacionadas

• VPN con OpenSSH (4)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (4)
• Port Knocking (4)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)

Feed enhanced by Better Feed from Ozh

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

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

Entradas relacionadas

• Tres formas de instalar GRUB (3)
• La odisea de ampliar la memoria a 4 GiB (3)
• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID (3)
• Wake on LAN (2)
• VPN con OpenSSH (2)
• Usando ntfsclone y dd para clonado por red con netcat (2)

Feed enhanced by Better Feed from Ozh

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.

(...)

Leer el resto de VPN con OpenSSH (1,114 palabras)

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

Entradas relacionadas

• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (5)
• Port Knocking (4)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (4)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (4)
• Accediendo a una red mediante NAT en Linux (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)

Feed enhanced by Better Feed from Ozh

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.

(...)

Leer el resto de Unidades montadas y enlaces simbólicos en Windows (683 palabras)

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 8 comentarios
Etiquetas: UNIX, Windows

Entradas relacionadas

• VPN con OpenSSH (2)
• Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (2)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (2)
• Wake on LAN (1)
• VFD, la disquetera virtual para Windows (1)
• Usando ntfsclone y dd para clonado por red con netcat (1)

Feed enhanced by Better Feed from Ozh

$ 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

Entradas relacionadas

• VPN con OpenSSH (3)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (3)
• Mantener el reenvío de ventanas X de SSH tras hacer un su (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)
• Backups con rsync (3)
• Usando ntfsclone y dd para clonado por red con netcat (2)

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

Entradas relacionadas

• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (1)
• Los plugins, el arma secreta de Firefox (1)

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

Entradas relacionadas

• ¿Por qué obtenemos una imagen en blanco y negro al usar un adaptador de S-Video a Euroconector? (3)
• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG (2)
• La pesadilla de compartir partición entre Linux y Windows (2)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (2)
• Cómo mantener los acentos y las eñes al montar NTFS, FAT o smbfs y al compartir directorios con Samba (2)
• Arrancar Linux, Windows y MS-DOS de una memoria USB (2)

Feed enhanced by Better Feed from Ozh