linux

SSL - Certificado firmado por nuestra propia entidad certificadora

 Mar, 15/10/2013 - 11:34     Sandor

Recientemente nos ha caducado el certificado que corría el servidor Apache de la intranet oficina, lo cual me ha obligado a repasar la documentación para volver a generar unos nuevos certificados (como es algo que no suelo hacer habitualmente, ya había olvidado como hacerlo). El caso es que me he vuelto loco repasando mis enlaces antiguos, así que me he animado a crear una nueva entrada en el blog, que me sirva de ayuda en el futuro (y espero que a vosotros). Hasta ahora tirábamos con un certificado autofirmado, pero después de encontrar esta utilísima guia del blog Tecnología, Sistemas, Seguridad y Ethical Hacking, me he decidido a crear un nuevo certificado creando antes una entidad certificadora propia. Como ha salido todo bien :-), aquí dejo las instrucciones para guiarme en el futuro, gran parte de ellas copiadas directamente de la guia anteriormente comentada, que a su vez, por lo que cuenta el autor, ha sido extraida en gran parte del sitio web www.linuxito.com.ar.

Cómo crear un certificado para Apache, firmado por nuestra propia entidad certificadora, y con arranque automático (sin petición de contraseña al reiniciar el servicio)

Paso 1. Crear la estructura de directorios donde crearemos los certificados

Los certificados que crearemos sólo servirán para uso personal ya que no son firmados por una autoridad de confianza como Verising, como un mecanismo de proveer una forma segura de comunicarse con tus servicios, para que las contraseñas o cualquier dato no viaje plano por la red.
De más está decir que necesitamos OpenSSL instalado en el ordenador que utilizaremos para administrar los certificados o crear las solicitudes de certificado. Yo particularmente trabajo con Debian (stable), por lo que los comandos reproducidos serán los necesarios en la versión que utilizo. No obstante, las indicaciones aquí descritas deberían ser válidas en cualquier distribución Linux.

Para comenzar debemos crear la estructura de directorios donde se almacenará toda la información relativa a nuestra PKI (Public Key Infraestructure):

# mkdir –m 0755 /CA
# mkdir –m 0755 /CA/private
# mkdir –m 0755 /CA/certs
# mkdir –m 0755 /CA/newcerts
# mkdir -m 0755 /CA/crl
  • "CA" será el directorio de trabajo de la Autoridad Certificadora.
  • "certs" será el directorio donde se ubicarán los certificados.
  • "newcerts" es el directorio donde OpenSSL pone los certificados creados en formato PEM (sin encriptar) y en la forma [n° de serie].pem (por ejemplo: 15.pem).
  • "crl" es el directorio donde se coloca la lista de revocación de certificados.
  • "private" es el directorio donde se colocan las claves privadas (este directorio debe tener permisos extremadamente restrictivos, para que sólo sean leídos por root).

Las extensiones de archivos que se generarán en estos directorios serán las siguientes:

  • KEY: Claves privadas (deben tener permisos restrictivos).
  • CSR: Pedido de certificado (estos pedidos serán firmados por la CA para convertirse en certificados, luego pueden ser eliminados).
  • CRT: Certificado (puede ser distribuido públicamente).
  • PEM: Archivos que contienen tanto el certificado como la clave privada (deben tener permisos restrictivos).
  • CRL: Lista de revocación de certificados (puede ser públicamente distribuida).

Para la configuración inicial de OpenSSL, copiamos el archivo de configuración por defecto de OpenSSL (openssl.cnf) al directorio /CA. En Debian se encuentra en el directorio /etc/ssl/openssl.cnf:

# cp /etc/ssl/openssl.cnf /CA
# chmod 0600 /CA/openssl.cnf

Luego creamos dos archivos que funcionan como bases de datos para OpenSSL:

# touch /CA/index.txt
# echo '01' > /CA/serial

Debido a que utilizamos un directorio personalizado para nuestros certificados, se necesitan algunas modificaciones en el archivo /CA/openssl.cnf, así que lo abrimos con nuestro editor de texto preferido (ojo, siempre como root) y nos debe quedar así:

[ CA_default ]
dir = /CA # Directorio donde se guarda todo <== CAMBIAR ESTA LINEA
certs = $dir/certs # Directorio donde se guardan certificados emitidos
crl_dir = $dir/crl # Directorio donde se guardan crl enviados
database = $dir/index.txt # Archivo índice de la base de datos
#unique_subject = no # Setear en 'no' para permitir que se creen diferentes certificados con el mismo 'subject'
new_certs_dir = $dir/newcerts # Directorio donde se guardan nuevos certificados
certificate = $dir/ca.crt # Certificado de la CA <== CAMBIAR ESTA LINEA
serial = $dir/serial # Número de serie actual
#crlnumber = $dir/crlnumber # El número de crl actual debe comentarse para dejar una CRL V1
crl = $dir/crl.pem # La CRL actual
private_key = $dir/private/ca.key # La clave privada <== CAMBIAR ESTA LINEA
RANDFILE = $dir/private/.rand # Número aleatorio privado
x509_extensions = usr_cert # Extensiones a agregar al certificado

Se puede personalizar aún más para definir políticas para la creación y firmado de los certificados, o definir extensiones deseadas para nuevos certificados.
Los certificados que vamos a crear con esta configuración, son certificados de propósito general y su uso no se restringe sólo a autenticación de servidores. Debe notarse que las claves privadas no serán protegidas por una passphrase, para que cuando los servicios se reinicien no soliciten el ingreso de passphrases. Esto implica que se debe restringir cuidadosamente el acceso de lectura sobre las claves privadas, para que sólo el usuario root, o el usuario privilegiado utilizado por los servicios, pueda leer estos archivos.

¡Ya tenemos nuesta base para comenzar a crear nuestros certificados!

Paso 2. Crear nuestra propia Entidad Certificadora (CA)

Después de terminar la configuración inicial, podemos crear un certificado auto-firmado que será utilizado como el certificado de nuestra CA. Este será utilizado para firmar las solicitudes de certificados:

# cd /CA
# openssl req -config openssl.cnf -new -x509 -extensions v3_ca -days 3650 -keyout private/CA_nombre.key -out certs/CA_nombre.crt
Generating a 1024 bit RSA private key
................++++++
...............++++++
writing new private key to 'private/CA_nombre.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Tu provincia
Locality Name (eg, city) []:Tu ciudad
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Nombre de empresa, proyecto o lo que sea
Organizational Unit Name (eg, section) []:Nombre de departamento o lo que se te ocurra
Common Name (eg, YOUR name) []:Tu nombre
Email Address []:Tu dirección de correo electrónico

Se crearán dos archivos: certs/CA_nombre.crt, certificado de la CA públicamente disponible y con lectura para todo el mundo; private/CA_nombre.key, clave privada del certificado de la CA. A pesar de que está protegida por una contraseña se debe restringir el acceso:

# chmod 0400 /CA/private/CA_nombre.key

Paso 3. Creación del pedido del certificado

Para proceder con la creación de un certificado para un servidor, lo primero que hacemos es generar el pedido de certificado:

#cd /CA
#openssl req -config openssl.cnf -new -nodes -keyout private/apachessl.key -out apachessl.csr -days 3650
Generating a 1024 bit RSA private key
.......................++++++
.....++++++
writing new private key to 'private/apachessl.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]: Tu provincia
Locality Name (eg, city) []: Tu ciudad
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Nombre de empresa, proyecto o lo que sea
Organizational Unit Name (eg, section) []: Nombre de departamento o lo que se te ocurra
Common Name (eg, YOUR name) []: El nombre de tu dominio
Email Address []: Tu dirección de correo electrónico
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
  • La opción "nodes" es necesaria para que la clave privada no sea protegida con una passphrase. Si el certificado no se va a utilizarar para la autenticación de servidores, no se debería incluir en la opción anterior.
  • El "Common Name" (CN) es la información que identifica de forma única al servicio, por lo que debemos asegurarnos de escribirlo correctamente.
  • Personalmente, recomiendo rellenar todos los campos que nos pidan, ya que si los dejamos vacios, se nos rellenarán con los datos por defecto, y en ocasiones pueden inducirnos a pensar que hay algún error en ellos.

Al finalizar se crean dos archivos:

  • apachessl.csr: El pedido de certificado.
  • private/apachessl.key: La clave privada, que no ha sido protegida con una passphrase.

Como anteriormente, se deben crear permisos restrictivos sobre la clave privada, por ejemplo:

# chown root.root /CA/private/apachessl.key
# chmod 0400 /CA/private/apachessl.key

O (por ejemplo si el certificado es para un servidor Apache):

# chown root.apache /CA/private/apachessl.key
# chmod 0440 /CA/private/apachessl.key

Paso 4. Firma del pedido de certificado para generar el certificado para el servidor

A continuación firmamos el pedido de certificado para generar el certificado para el servidor:

# cd /CA
# openssl ca -config openssl.cnf -cert certs/CA_nombre.crt -policy policy_anything -out certs/apachessl.crt -infiles apachessl.csr
Using configuration from openssl.cnf
Enter pass phrase for /CA/private/CA_nombre.key:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Oct 16 07:36:10 2013 GMT
            Not After : Oct 14 07:36:10 2023 GMT
        Subject:
            countryName               = ES
            stateOrProvinceName       = Tu provincia
            localityName              = Tu ciudad
            organizationName          = Nombre de empresa, proyecto o lo que sea
            organizationalUnitName    = Nombre de departamento o lo que se te ocurra
            commonName                = El nombre de tu dominio
            emailAddress              = Tu dirección de correo electrónico
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                B5:9D:90:13:57:C7:3E:4B:5F:1A:41:B7:AA:A4:A2:DB:11:DB:03:F4
            X509v3 Authority Key Identifier:
                keyid:48:09:37:10:7E:A1:3E:42:17:4D:18:44:B6:13:FE:B9:AF:CD:CD:6F

Certificate is to be certified until Oct 14 07:36:10 2023 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
  • La opción "-policy policy_anything" indica que no se requiere que los campos "Country", "State" o "City" coincidan con los de la CA.

Al finalizar se crean dos nuevos archivos:

  • certs/apachessl.crt: Certificado del servidor, que puede hacerse públicamente disponible.
  • newcerts/01.pem: El mismo certificado pero con el número de serie como nombre de archivo, no es necesario.

En este momento podemos eliminar el pedido de certificado, el cual no necesitaremos más (apachessl.csr):

# rm –f /CA/apachessl.csr

Paso 5. Creación de un archivo pkcs12 para instalar en navegadores

Como penúltimo paso, nos queda generar un archivo pkcs12, listo para ser cargado en los navegadores que necesitemos que tengan acceso a nuestro sitio.

# openssl pkcs12 -export -in certs/apachessl.crt -inkey private/apachessl.key -certfile certs/CA_nombre.crt -out apachessl_pck12.p12
Enter Export Password:
Verifying - Enter Export Password:

Paso 6. Copiando nuestros certificados a sus directorios destino

¡Recapitulemos! Con todos estos pasos, hemos generado un certificado autofirmado de Entidad Certificadora, un certificado para servidor firmado por esa Entidad Certificadora, y un archivo pkcs12 para instalar en navegadores. ¿Qué hacemos ahora?

En el servidor:

  • CA_nombre.crt y CA_nombre.key : estos dos archivos forman el certificado correspondiente a nuestra Entidad Certificadora (CA). En mi servidor Debian, hay que copiar el certificado público (extensión .crt) a /etc/ssl/certs y la clave privada (extensión .key) a /etc/ssl/private.
  • apachessl.crt y apachessl.key: estos dos archivos forman el certificado correspondiente al servidor, firmado por nuestra Entidad Certificadora. Como antes, debemos de copiar el certificado público (extensión .crt) a /etc/ssl/certs y la clave privada (extensión .key) a /etc/ssl/private.

Después tendríamos que configurar el servidor web para que usase esos certificados. En apache (el que yo uso), sería algo similar a esto:

SSLEngine on
SSLCACertificateFile '/etc/ssl/certs/CA_minombre.crt'
SSLCertificateFile '/etc/ssl/certs/apachessl.crt'
SSLCertificateKeyFile '/etc/ssl/private/apachessl.key'
SSLVerifyClient require
SSLVerifyDepth 10
# --- opciones varias (mirar en http://httpd.apache.org/docs/2.2/mod/mod_ssl$
SSLProtocol -all +SSLv3
SSLCipherSuite SSLv3:+HIGH:+MEDIUM

En cada navegador que querais que tenga acceso a vuestro sitio web:

  • Primeramente tendremos que importar el certificado de nuestra Entidad Certificadora. Por ejemplo, para hacerlo en Firefox hay que ir a Herramientas -> Opciones -> Avanzado -> Certificados -> Ver certificados -> Importar y una vez allí importar el archivo CA_nombre.crt que (recuerda) contiene la clave pública de nuestra Entidad Certificadora.
  • Acto seguido, tenemos que importar también el certificado pkcs12 que contiene el certificado de nuestro servidor (en el ejemplo que os he puesto: apachessl_pck12.p12)

Paso 7. Otras operaciones con los certificados generados

Si queremos consultar nuestro certificado, podremos consultarlo con el siguiente comando:

# openssl x509 –subject –issuer –enddate –noout –in /CA/certs/apachessl.crt

O el siguiente:

# openssl x509 –in certs/apachessl.crt –noout -text

Y verificar que el certificado sea válido para autenticación de servidores con el siguiente:

# openssl verify –purpose sslserver –Cafile /CA/certs/CA_nombre.crt /CA/certs/apachessl.crt

Algunos servidores o aplicaciones requieren que el certificado y la clave privada existan en el mismo archivo, esto se puede lograr con el comando:

# cat certs/apachessl.crt private/apachessl.key > private/apache-ssl-cert-key.pem

Entonces se debería restringir el acceso al archivo .pem resultante y borrar apachessl.crt y apachessl.key si no son necesarios.

# chown root.root private/apache-ssl-cert-key.pem
# chmod 0400 private/apache-ssl-cert-key.pem
# rm –f certs/apachessl.crt
# rm –f private/apachessl.key

Si deseamos que un certificado deje de ser válido debemos revocarlo. Esto se puede hacer con el comando:

# openssl ca –config openssl.cnf –revoke certs/apachessl.crt

Hecho lo anterior, ahora debemos generar una nueva CRL (Certificate Revokation List):

# openssl ca –config openssl.cnf –gencrl –out crl/CA_nombre.crl

El certificado de nuestra CA y nuestra lista de revocación (CRL) deben ser distribuidos a aquellos que confíen en nuestra CA para que puedan importarlos en el software cliente (web browser, clientes ftp, clientes de email, etc). Además la CRL debe ser pública. Si queréis mas información sobre el estándar de Infraestructura de Clave Pública, quizás os interese visitar el siguiente enlace: Wikipedia: Infraestructura de clave pública.


En fín, hasta aquí esta pequeña guía que espero os venga bien para, por ejemplo, acceder a vuestras intranets caseras desde cualquier sitio. Las posibilidad son amplias: podeis llevar en un pendrive un Firefox portable con los certificados instalados y ejecutarlo en cualquier PC seguro; podeis instalar en vuestra tablet o móvil android (es lo que yo uso, supongo que en otros sistemas también), los certificados y acceder también desde ellos. Incluso (es lo que yo tengo pensado hacer próximamente), podeis instalar en vuestra intranet algún servidor CalDav y CardDav, para así gestionar vosotros mismos vuestros calendarios y contactos, y compartirlos centralizadamente con los ordenadores de vuestra red local, al igual que con los móviles y las tablets a los que instalemos el certificado.

Si quereis más información, aquí se ha hablado un poco más sobre este tema:

Desactivar ehci_hcd (errores Unable to enumerate USB device)

 Vie, 15/02/2013 - 09:21     Sandor

Antecedentes: estaba ejecutando rsync para realizar mi backup semanal, desde mi disco duro portátil (cifrado con Truecrypt) a otro disco usb conectado al servidor (crifrado con dmcrypt). En un momento del proceso ha ocurrido un error, y he sido incapaz de proseguir con el backup. Incluso era imposible desmontar y volver a montar los dispositivos. El syslog mostraba lo siguiente:

Feb 15 08:24:36 servidor kernel: Buffer I/O error on device dm-0, logical block 124289038
Feb 15 08:24:36 servidor kernel: lost page write due to I/O error on dm-0
Feb 15 08:24:39 servidor kernel: hub 1-0:1.0: unable to enumerate USB device on port 1
Feb 15 08:24:39 servidor kernel: usb 1-6: USB disconnect, address 4
[...]
Feb 15 08:29:30 servidor kernel: hub 1-0:1.0: unable to enumerate USB device on port 6
Feb 15 08:29:30 servidor kernel: usb 1-1: new high speed USB device using ehci_hcd and address 25
Feb 15 08:29:45 servidor kernel: hub 1-0:1.0: unable to enumerate USB device on port 1
Feb 15 08:29:46 servidor kernel: usb 1-6: new high speed USB device using ehci_hcd and address 26
Feb 15 08:30:01 servidor kernel: hub 1-0:1.0: unable to enumerate USB device on port 6
Feb 15 08:30:01 servidor kernel: usb 1-1: new high speed USB device using ehci_hcd and address 27
Feb 15 08:30:16 servidor kernel: hub 1-0:1.0: unable to enumerate USB device on port 1
Feb 15 08:30:16 servidor kernel: usb 1-6: new high speed USB device using ehci_hcd and address 28

En estos casos acostumbraba a reiniciar el servidor (en una pequeña oficina son cosas que se pueden hacer sin perder la cabeza :-D), pero buscando en la red he visto cómo solucionar esto:

cd /sys/bus/pci/drivers/ehci_hcd/
sudo sh -c 'find ./ -name "0000:00:*" -print| sed "s/\.\///">unbind'

Ejecutando estos sencillos pasos volveremos a dejar el soporte usb ehci listo para volver a conectar de nuevo los dispositivos. Ahora solo queda cruzar los dedos y volver a realizar el backup :)

Fuente: Geekdeus -> Unable to enumerate USB device (Disabling ehci_hcd)

Categoria: 
Etiquetas: 

Asegurar servidor SSH

 Lun, 14/05/2012 - 18:18     Sandor

Aquí van algunos consejos para proteger el acceso remoto a un servidor linux, corriendo Secure Shell (SSH).

CONFIGURAR CORRECTAMENTE EL SERVIDOR SSH

  • NOTA: el archivo de configuración, al menos en Debian, se encuentra situado en /etc/ssh/sshd_config
  • Protocol 2
    La versión 1 del protocolo tiene algunas vulnerabilidades conocidas, así que quitamos su soporte, obligando a acceder utilizando únicamente la versión 2 del protocolo.
  • ListenAddress ip
    Comprueba que el servidor escuche únicamente la interfaz de red que quieras realmente (puede que sólo te interese acceder a tu pequeño servidor casero desde tu propia red local, y tengas activado por defecto la escucha en todas las IPs, incluida la pública).
  • PermitRootLogin No
    Es indispensable que el usuario root no pueda acceder via SSH. Siempre podremos escalar privilegios, una vez hayamos accedido al servidor, a través de su o sudo, pero es importante que el usuario root no pueda acceder directamente desde el servidor SSH.
  • Listen num-puerto
    Cambiando el puerto de escucha por defecto pondremos otra piedra en el camino de aquellos que pretendan entrar remotamente en nuestro sistema. Hay formas de deducir qué programa está escuchando un puerto, pero al menos se lo pondremos un poquito más dificil a aquellos que hacen uso de scripts automatizados.
  • PermitEmptyPasswords No
    Ya que estamos intentando aumentar la seguridad de acceso a nuestro sistema, parece lógico prohibir las contraseñas vacías, ¿no? :-)
  • AllowUsers usuario1 usuario2 ...
    Si como yo, administras una pequeña red local, probablemente solo quieras dar acceso SSH a uno o dos usuarios, así que ¿por qué no limitar el acceso al servidor solamente a esos usuarios?
  • AllowGroups grupo1 grupo2 ...
    Si por el contrario hay más usuarios que acceden via SSH, tal vez sería interesante filtrar el acceso al servidor SSH, permitiendo solamente aquellos usuarios que pertenezcan a un determinado grupo.
  • PasswordAuthentication Yes
    Mediante esta directiva configuramos si permitimos la autenticación mediante clave al servidor SSH. El acceso tradicional al servidor se realiza mediante usuario y clave, aunque si prohibimos este acceso mediante usuario/clave (PasswordAuthentication No), aumentaremos la seguridad, dejando el acceso solamente a través de pares de claves públicas y privadas (si has usado alguna vez un programa de cifrado tipo GPG o similar ya sabrás a qué me refiero).
  • Hay otras directivas que incrementan la seguridad, como LoginGraceTime, MaxAuthTries, MaxStartups y algunas otras, aunque considero que estas de aquí arriba son las más importantes. Como siempre un simple man sshd_config te te permitirá profundizar más en las directivas de configuración.

AUTENTICACION SSH BASADA EN PARES DE CLAVES

  • Para deshabilitar el acceso con usuario/clave, y habilitar el acceso con pares de claves, necesitaremos comprobar que el servidor SSH (recuerda: /etc/ssh/sshd_config) está configurado correctamente:
# Desactivamos la autenticación via usuario/clave:
PasswordAuthentication No
# Activamos la autenticación con pares de claves:
PubkeyAuthentication yes
# Definimos el archivo donde irán las claves de acceso autorizadas.
# Como mi partición home está cifrada, defino que las claves se almacenen,
# de manera centralizada, dentro de /etc/ssh. Hay más información al respecto
# (importante el tema de los permisos en las carpetas) en la siguiente URL:
# https://help.ubuntu.com/community/SSH/OpenSSH/Keys
AuthorizedKeysFile /etc/ssh/%u/authorized_keys
# Activamos la atenticación RSA
RSAAuthentication yes
  • Una vez configurada la parte del servidor correctamente, lo que haremos será crear, en nuestra máquina cliente (desde la que accedemos al servidor) una clave pública que copiaremos luego al servidor. El par de claves (pública y privada) las podremos generar mediante el comando ssh-keygen -t rsa (si estamos bajo GNU/Linux), o usando el programa puttygen.exe del cliente PuTTY (si estamos en un entorno MS Windows). Para este ejemplo, suponemos que hemos llamado a la clave pública ssh-publico.key y a la clave privada ssh-privada.key.ppk.
  • Para subir la clave pública a nuestro servidor SSH, haremos uso de la utilidad scp (pscp si usamos PuTTY):
scp ssh-publico-key usuario@nuestroservidor:/etc/ssh/usuario
  • Reiniciamos el servidor sshd y voilà, ya podemos acceder usando el par de claves RSA.

Teneis más información sobre este último tema en los siguiente enlaces:

Etiquetas: 

Partir y juntar archivos grandes en GNU/Linux

 Lun, 16/01/2012 - 11:10     Sandor

Hoy me ha surgido, en el servidor de la oficina, la necesidad de partir un archivo de 20 Gb en partes más pequeñas. Buscando un poco por ahí, he visto que existe la utilidad split, que hace precisamente eso:

split -btamaño miarchivogrande prefijodelosarchivospequeños

Para juntar los archivos pequeños y volver a crear el archivo grande, la nunca bien valorada :) utilidad cat nos servirá a la perfección:

cat prefijodelosarchivospequeños* > minuevoarchivogrande

 

Etiquetas: 

Modificando el firmware del O2Media MR6000

 Mar, 27/12/2011 - 20:04     Sandor

O2Media MR6000

 

Según os comenté el otro día, estoy intentando mejorar, dentro de mis posibilidades, el firmware para el O2Media MR6000. Para trastear con él, aquí os cuento las herramientas que he utilizado.

El archivo install.img del firmware es en realidad un archivo comprimido en formato tar. Por lo que si le cambiamos la extensión y lo descomprimimos con un sencilo tar xvf install.tar tendremos acceso al contenido. La última actualización a día de hoy, descargada de la web de O2Media, mostraría esto:

-rw-r--r-- 1 root root  143300 dic  8  2010 arial.ttf
-rw-r--r-- 1 root root 1773344 dic  8  2010 audio_firmware.install.bin
-rwxr-xr-x 1 root root    1816 dic  8  2010 configuration.xml
-rwxr-xr-x 1 root root   43400 dic  8  2010 flash_erase
-rwxr--r-- 1 root root 2199940 dic  8  2010 install_a
-rwxr-xr-x 1 root root  163948 dic  8  2010 mkfs.jffs2
-rwxr-xr-x 1 root root   56792 dic  8  2010 mkyaffs2image
-rwxr-xr-x 1 root root   61580 dic  8  2010 nandwrite
drwxr-xr-x 3 root root    4096 dic 27 18:57 package2
    -rwxr--r-- 1 root root  1873552 dic  8  2010 bluecore.audio
    -rwxr--r-- 1 root root 51265536 dic  8  2010 squashfs1.img
    -rw-r--r-- 1 root root     5379 dic  8  2010 usr.local.etc.tar.bz2
    -rwxr-xr-x 1 root root  2324208 dic  8  2010 video_firmware.bin
    -rwxr-xr-x 1 root root  4206726 dic  8  2010 vmlinux.develop.avhdd.mars.nand.bin
-rwxr-xr-x 1 root root 1623760 dic  8  2010 video_firmware.install.bin

Por cierto, he identado los archivos que aparecen dentro del directorio package2. El archivo squashfs1.img, dentro de la carpeta package2, contiene la imagen de la carpeta root del sistema. Para descomprimirla, copiamos squashfs1.img a una carpeta aparte y descomprimimos con:

unsquashfs  squashfs1.img

Esto nos creará una carpeta llamada squashfs-root con el contenido descomprimido. Después de trastear con el contenido, podremos volver a crear la imagen con un sencillo:

mksquashfs * ../squashfs1.img

El archivo usr.local.etc.tar.bz2 se puede descomprimir con un sencillo:

tar jxvf usr.local.etc.tar.bz2

Según leo en esta entrada de todopvr: el directorio /usr/local es el único directorio del firmware que se monta como lectura/escritura y por tanto que se puede tocar por el usuario con conocimientos de linux y telnet. Suele estar en ese directorio el fichero de canales, los ficheros de bases de datos para las programaciones y también en un directorio "IMS" todo lo que tiene que ver con internet, como las emisoras de radio, o las páginas de meteorología, RSS o vídeos y precisamente por estar ahí se pueden "modificar" y crear ficheros rss/html para acceder a distintos servicios de internet, por ejemplo a cosas distintas de Youtube.

Si alquien quiere trastear y no quiere andar compilando los archivos para comprimir/descomprimir, podeis descargar los archivos de este enlace: yaffs-utils-linux.tgz

Por ahora solo he dado este primer paso. Los siguientes serán trastear con los scripts IMS, a ver si puedo meter los del firmware de Bluetimes (en el que funciona Youtube y la radio online), dentro del de la última actualización de O2Media.

Seguiremos informando... ;)

Categoria: 

Forzando la instalacion de un firmware en el O2Media MR6000

 Sáb, 24/12/2011 - 10:32     Sandor

O2Media MR6000

Hace unas semanas he comprado en PcComponentes el reproductor multimedia O2Media MR6000. Para las características que tiene está bien de precio, aunque a mi entender es un aparato solo para geeks, ya que de lo que dice que hace, a lo que realmente hace, va un trecho.

El caso es que llevo trasteando algunos días, instalando en el aparato diferentes firmwares. Y claro, de tanto trastear algún día tenía que pasar que me equivocara y el aparato se quedara colgado al meterle un firmware que no estaba destinado a él :-)

Por un momento ya pensaba que tenía un bonito pisapapeles, pero rebuscando en la red he dado con el foro MPCClub, y he descubierto que hay un sistema para forzar la actualización del firmware aún cuando no tienes acceso al menú del aparato.

Consiste en:

  • Apagar el aparato del interruptor de atrás.
  • Introducir un pendrive, formateado en FAT32, con el firmware que quieras instalar en el directorio raiz.
  • Presionar la tecla de arranque (la del propio aparato, no la del mando a distancia).
  • Teniéndola presionada, encender el aparato.

Con esto el aparato se actualizará y nuestro cacharro habrá vuelto a la vida.

Categoria: 

Linux: montar volumen Truecrypt NTFS desde la consola

 Vie, 10/12/2010 - 22:03     Sandor

Hoy me he encontrado con que he tenido que montar una partición Truecrypt bajo Linux, usando la línea de comandos. Vago que es uno :-) me apunto aquí la chuletilla, para futuras referencias y por si a alguien le puede ser de utilidad.

El comando quedaría algo así:

truecrypt --filesystem='ntfs-3g'  --mount /dev/sdb2 /mnt/truecrypt  --fs-options='uid=1000,gid=1001,umask=0002'

Obviamente, es necesario tener instalado el soporte NTFS en linux, mediante el paquete ntfs-3g, así como el propio Truecrypt. Las opciones de --mount son autoexplicativas: primero la partición y luego la ruta destino para el montaje. Como parámetros a ntfs-3g (fs-options), le ordenamos que monte la partición como el usuario con id 1000 y grupo con id 1001, con unos permisos (umask) de 0002 que pondrá los archivos con los permisos 664 y los directorios con 775.

Para algo más de información, podeis ojear estas páginas que he encontrado en la red:

Cambiar permisos selectivamente

 Dom, 14/02/2010 - 10:13     Sandor

Me apunto aquí una pequeña chuleta con información sobre cómo cambiar los permisos de los directorios de forma selectiva. Es decir, cambiar los permisos solamente a los directorios, o a los archivos, de una determinada ruta.

Para seleccionar solamente los directorios dentro de una ruta determinada, tendremos que echar mano del comando find. Brevemente, la cosa quedaría así:

find /home/usuario -type d -print0 | xargs -0 chmod 775

Esto cambiaría los permisos de todos los directorios bajo /home/usuario, a 775. Podríamos hacer algo similar para los archivos:

find /home/datos -type f -print0 | xargs -0 chmod 664

Categoria: 
Etiquetas: 

Linux hasta en la sopa

 Mié, 03/02/2010 - 09:14     Sandor

Ayer fue un día de esos en los que te das cuenta de que lo que empezó siendo la simbiosis entre un proyecto de sustitución de Minix por parte de un estudiante (Linus Torvals) de la Universidad de Helsinki, y el proyecto GNU iniciado por Richard Stallman, ha ido poco a poco copando nichos de mercado, hasta poderlo encontrar en las tripas de mucha de la cacharrería electrónica que invade nuestro mundo.

Digo que fue ayer porque, al descargarme por la mañana el manual de la tele LG 32LF pude leer un "Aviso de software de código abierto", advirtiendo que la tele incluye un kernel 2.6, busybox, lzo, uClibc y Nanox (The Nano X-Window System).

Algo más tarde me fuí al IKEA y al pagar en una de esas cajas rápidas se bloqueó el lector de tarjetas de crédito, por lo que tuvieron que resetear mi TPV. Al reiniciarlo, pude ver las familiares líneas de arranque de un sistema GNU/Linux (solo me faltó andar listo y hacerle una foto con el móvil).

Tal vez este año tampoco sea el año de Linux en sistemas de escritorio, pero parece que avanza a buen ritmo en otro tipo de entornos...

Etiquetas: 

Recuperando archivos de un backup de Plesk Parallels

 Mar, 05/01/2010 - 21:50     Sandor

Como os comenté hace unas entradas, he comenzado a trabajar con ConfigBox para poner en marcha Petra Por T. Habituado a los backups de Sync, en los que los recibo en un práctivo archivo ZIP, el nuevo formato de ConfigBox se me ha antojado un poco raro. ¿La diferencia? Sync utiliza cPanel como panel de administración para los alojamientos contratados, mientras que ConfigBox utiliza Plesk Parallels.

Con Plesk, te bajas un archivo .gz, pensado exclusivamente para poderlo subir tal cual si necesitamos restaurar la copia. Pero a mí me interesaba poder extraer el contenido, para poder trabajar en local con una copia del web. El problema es que al descomprimirlo se crea un fichero nuevo, sin extensión. Buscando en la red, he encontrado una solución para extraer su contenido desde linux:

Comprobar que tenemos instalado munpack (en Debian, un aptitude install mpack lo instalará).

		zcat archivo_backup.gz > archivo_backup
		cat archivo_backup | munpack

Con esto extraeremos los archivos del backup. En mi caso he tenido que agregar la extensión tar manualmente. En dominio.httpdocs.tar y dominio.httpsdocs.tar están los archivos de nuestro sitio web, mientras que los archivos de extensión .mysql contendrán un volcado SQL de las bases de datos que tenemos. Además, también tendremos los logs, y alguna otra cosa más (dump.xml) que no se muy bien para qué sirve :-?

 

Etiquetas: 

Páginas

Sobre PlanetaInopia

Sandor Inopia nació en Bilbao, un lunes cualquiera, justo 1904 años después de que Nerón se suicidara, diciendo ¡Qué artista muere conmigo!, y 192 años después de que Volta descubriera la pila eléctrica. Mientras celebraba su quinto cumpleaños, Elvis daba su último concierto, y celebrando los siete, Muhammad Ali se retiraba del boxeo.

Sobre PlanetaInoipa, blog personal de Sandor Inopia (Sandor Saiz Ortuondo)

Yo no tengo la ambición de Nerón, la inteligencia de Volta, la voz de Elvis, o la fuerza de Alí, pero a veces me gusta escribir y darme a conocer a los demás. Por eso este blog, que espero te guste.

Comentarios recientes