Rhythmbox e iVoox, horas y horas de entretenimiento

Últimamente me estoy aficionando a los podcast; nunca antes había metido el pie en este mundo, y la verdad es que he encontrado un par que me interesan mucho. Y para seguirlos y poderlos escuchar, me los iba descargando, como todo hijo de vecino.

Hoy he 'caído' en la cuenta de que podía sincronizar mi Rhythmbox con iVoox para que descargara automáticamente las novedades y me las presentara, sin ni siquiera tener que acordarme de hacerlo yo!

Es muy sencillo. Para ello, vete a tu canal de iVoox preferido;  yo me he ido al de los chicos de Vuelo180, que me hacen pasar muy buenos ratos. Desde aquí accedo al podcast; busco la opción de suscribirme vía RSS, y se me abre el XML correspondiente con todas las entradas. Copio la dirección y me voy a mi Rhythmbox, al menú de Podcasts; busco la pestaña 'Añadir' y copio la URL del XML que acabo de copiar. Automáticamente me muestra los últimos podcast de mis podcasteros favoritos... y ahora cada vez que cuelguen alguna cosa, yo seré la primera en enterarme!!!

Bueno, yo lo he hecho desde iVoox, pero teniendo acceso a las suscripciones, puedes hacerlo con cualquier web que almacene podcasts, programas de radio o cualquier tipo de audio al que puedas suscribirte.

Dell: actualizaciones posteriores a una instalación (Debian y RHEL)

Después de mucho tiempo sin atender mucho al blog, hoy os dejo una entrada con una serie de tareas que es interesante hacerlas antes de una puesta en producción. Se trata de una serie de actualizaciones de sistema que normalmente no hacemos, o que como administradores de sistemas las vamos dejando de lado. Pues no! Ahora os ponéis todos a planificar las actualizaciones...

Una vez hemos hecho una actualización nueva, lo lógico en nuestro caso es actualizar el sistema. Yo trabajo normalmente con Red Hat (RHEL) o Debian, así que las actualizaciones de paquetes son muy fáciles. En el caso de Debian es

    > apt-get update --> Actualizamos la lista de paquetes que hay en los repositorios
    > apt-get upgrade --> Actualizamos los paquetes instalados que tienen versiones posteriores de la misma release

En el caso de Red Hat (RHEL), primero tengo que registrar mi sistema y después actualizarlo

    > rhn_register --> Registro mi sistema; necesitas tu usuario y contraseña en la Red Hat Network que te da acceso a las actualizaciones
    > yum update --> Actualizar listado de paquetes y el sistema

Con el sistema actualizado lo vemos todo más claro. Vamos a por actualizaciones más delicadas (iDRAC, BMC, BIOS, etc)

Primero buscamos el paquete que queremos actualizar en
    > http://support.dell.com
Ten a mano la etiqueta de servicio (service tag); te la pedirá la web para redirigirte a los paquetes correctos. Descárgalos e instálalos en tu servidor.

Para instalarlos, el procedimiento genérico es
    A chmod 755 nombre_del_paquete.bin
    B ./nombre_del_paquete.bin -c --> Ejectuarás la instalación, pero en modo prueba, para comprobar si faltan librerías o paquetes. Si falla alguna dependencia, instálala antes de seguir adelante
    C ./nombre_del_paquete.bin --> Instalarás el paquete. Una vez finalizado, ya lo tendrás. Es posible que te pida reiniciar.

Si no localizas alguno de los paquetes, en 'normal': para linux no están todos los paquetes.




Y por último, una herramienta DELL muy útil: el gestor OMSA (OpenManager Server Administrator). Desde aquí podremos hacer un seguimiento y monitorización de aspectos físicos del sistema de una manera muy rápida y sencilla. Yo te recomiendo que lo instales en tu servidor, seguro que te es de ayuda, y una vez lo tengas, lo instalarás en todos los servidores DELL que tengas.


Primero, descargamos el paquete. Según sistema (RHEL, Windows, SLES,... ) y la arquitectura (x86, _64) escogemos el paquete adecuado de
    > http://ftp.dell.com/sysman/
Busca la versión más actualizada; actualmente es la 7 (01/2013). Crea una carpeta en el servidor y descarga el paquete a esa carpeta.

Descomprímelo.

Navega hasta el directorio que has creado y ejectua
    > bash linux/supportscripts/srvadmin-install.sh --express
Una vez finalizada la instalación, levanta el servicio
    > bash linux/supportscripts/srvadmin-services.sh start

Comprueba que puedes acceder
    > https://IP:1311


Si no puedes acceder, comprueba que no tengas algún dispositivo que pueda cortarte el acceso. Recuerda que el propio sistema puede tener un firewall.

Problema en conexiones remotas en Castellano/Español

¿No os ha pasado nunca que al hacer un SSH contra otro servidor (o rsync o scp... etc) por primera vez desde un sistema en castellano/español hacia otro, habéis tenido problemas al teclear 'sí'? Sí, por ese acento precisamente...

# ssh root@Server No se puede establecer la autenticidad del sistema 'Server (Server). RSA la firma de la clave es 52:f1:e9:93:0a:46:ef:64:c7:72:6c:d2:a9:a1:d4:89. ¿Desea continuar con la conexión (sí/no)? sC- Escriba 'sí' o 'no': sC- Escriba 'sí' o 'no': no Verificación de la clave del sistema no satisfactoria. #

A mí hoy casi me vuelve loca. Estoy en un sistema Solaris 10 que, por algún motivo que ahora mismo no comprendo, el sistema escribe bien los acentos, tiene bien configurados los locales, pero al tener que responder esta pregunta del sistema, no los permite.

Pues nada, a sistema que pu#ea, sysadmin que busca un atajo. Y en este caso es este:

# ssh -o "StrictHostKeyChecking no"  root@Server Advertencia: Se ha agregado permanentemente 'Server' (RSA) a la lista de hosts conocidos. Contraseña de root@Server: Last login: Mon Jul 30 18:02:12 2012 from my_IP [root@Server ~]#  #

Ale, y ya me puede poner trabas el jodío, que una se busca las habichuelas!

Hasta otro día, con otro truquito!

Excluir directorios de la protección .htaccess de Apache

Tenemos un site protegido por contraseña en el .htaccess. Qué bien funciona, qué bien nos va... hasta que llega el día en que nos damos cuenta que necesitamos acceder sin tener que validar esa contraseña a un directorio concreto.

Pues es fácil. Basta con definir un .htaccess en la raiz del directorio que queremos que esté disponible, con el siguiente contenido

allow from all               satisfy any

 y ya puedo acceder al directorio teniendo el resto de la web protegida.

Errores ORA-0134 y ORA-27101

Errores:

ORA-0134: ORACLE not availabe
ORA-27101: shared memory realm does not exist

Estos errores suelen darse juntos cuando el Listener de Oracle está levantado, pero la BBDD Oracle no.
Lo único que tenemos que hacer es arrancar el Oracle.

¿Cómo?

Con el usuario

su - oracle

ejecutamos

bash-3.00$ sqlplus "sys as sysdba"

SQL*Plus: Release 11.2.0.3.0 Production on Wed Jun 6 09:58:47 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter password:
Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  689217536 bytes
Fixed Size                  2162384 bytes
Variable Size             629145904 bytes
Database Buffers           50331648 bytes
Redo Buffers                7577600 bytes
Database mounted.
Database opened.
SQL> exit
Disconnected from Oracle Database 11g Release 11.2.0.3.0 - 64bit Production
bash-3.00$

y ya tenemos nuestra BBDD levantada. El error no se volverá a dar (o será otro)

Podéis encontrar más info aquí.

Error "Too many open files" en nGinx

Cuando en los logs del nGinx tenemos el error

Too many open files

significa que hay demasiadas peticiones y que el nGinx no las puede gestionar.

Para solucionarlo de manera puntual (una vez pasada la punta es recomendable volver al estado normal, o al menos ajustarlo a las características del servidor, en caso de que sea necesario dejarlo porque haya aumentado la carga del servidor), añadimos:

ulimit -n 65535

en la siguiente línea después del '#! /bin/sh' en el

/etc/init.d/nginx

Después, editamos el

/etc/nginx/nginx.conf

y modificamos la línea

worker_connections  1024;

y modificamos el valor a

20480

y añadimos la entrada

worker_rlimit_nofile 20480;

justo debajo del parámetro 'worker_processes'

Reiniciamos el nGinx y durante un rato es recomendable monitorizar el servidor y controlar los parámetros básico de sistema para comprobar que estas modificaciones no tiran el servidor. En caso de que el servidor se hunda, habrá que ir bajando el número de conexiones en el

/etc/nginx/nginx.conf

Ambos parámetros modicados (worker_rlimit_nofile y worker_connections) deben ser iguales.

Linux: redimensionar imágenes desde CLI con imagemagick

¿No habéis pensado que sería una pasada poder redimensionar una serie de imágenes de una sola vez sin tener que editarlas una por una? Bueno, a mí sí que me ha pasado, y debo decir que esto me ha salvado más de una vez de una hora de aburrimiento, cuando menos...

La suite ImageMagick trae una serie de programas para la manipulación de imágenes, y es lo que yo suelo utilizar. Tiene muchas opciones y la verdad es que es muy versátil, con lo que me podría extender mucho y no es el caso. Os voy a explicar cómo hago yo para redimensionar imágenes, y las opciones que suelo utilizar para ello. Además, si os interesa, se puede llegar a automatizar e incluirlo en un script que os haga 'el trabajo sucio'. La imaginación al poder!

Casi 1: Voy a redimensionar una carpeta llena de imágenes, todas con el formato 'NOMBRE.JPG', y las quiero al 50% de su resolución actual. Fácil. Desde la línea de comandos y en el directorio donde están las imágenes ejecuto:

for file in `ls -1`; do

   convert $file -resize 50% mod_$file

done

Caso 2: Ahora tengo muchas imágenes, cada una de su padre y de su madre, diferentes tipos de imágenes (JPG, BMP, PNG, etc) y con resoluciones más o menos diferentes, pero las necesito con una resolución de 800x600. Fácil también. Ejecuto

for file in `ls -1`; do

   convert $file -resize 800x600 mod_$file

done

Caso 3: Algo un poco más complicado. Necesito las muestras de las imágenes para hacer una galería (thumbnails). Sigue siendo sencillo. Ejecuto:

for file in `ls -1`; do

   convert $file thumbnail mod_$file

done

Para más opciones, consultar la página man del programa convert, y os haréis una idea de la potencia del mismo.

Para más información, haz click aquí