Archivo de la categoría: Consola

Chrome da continuos mensajes del tipo «Shockwave Flash has crashed» en Debian Wheezy 7

Me volví loco intentando una solución a través de chrome://plugins, que es la solución que aparece en todas partes. Pero, oye, que nada.

Al final, lo que me lo solucionó sin problemas fue lo que se propone en un foro italiano. Si, está en italiano, pero los comandos se entienden a la perfección, y el problema no tanto pero prestando un poco de atención y con ayuda de Google ya está. El fallo está en el plugin Pepper Flash, que viene incorporado en el Chrome. Resulta que a partir de la versión 37.0.2062.120 de Chrome, el plugin Pepper Flash necesita las librería glibc 2.14 para funcionar. Sin embargo la versión estable de Debian Wheezy proporciona glibc 2.13. Oh, si, Chrome se actualizará sin quejarse de ninguna dependencia, pero el plugin Pepper Flash no parará de lloriquear y de romperse una y otra vez. Puedes comprobar la versión de tu navegador Chrome en el menú, «Información de Google Chrome», si te pasa a ti.

¿Hay alguna solución?. Bueno, nuestro amigo italiano tomberry propone descargar una versión anterior de Pepper Flash y sobreescribir la que viene con el Chrome. Es muy fácil, nos da los comandos listos para ejecutar (eso si, hazte root).

Para amd64 (es decir, la versión 64 bit de Debian):

cd /opt/google/chrome/PepperFlash && sudo wget http://goo.gl/4dJvJE -O libpepflashplayer.so && exit

Para i386 (es decir, la versión 32 bit de Debian):

cd /opt/google/chrome/PepperFlash && sudo wget http://goo.gl/4awX8D -O libpepflashplayer.so && exit

Ignoro qué ocurre en otras versiones de Linux tal que Ubuntu, pero es muy posible que sus librerías glibc estén más actualizadas y no les falle el Pepper Flash. ¡Eh, no te quejes, es el precio que pagas por usar la versión estable de Debian!.

Después de ejecutar el comando no te olvides de que tienes que cerrar todas las ventanas de Chrome y luego volverlo abrir. Hombre, si eres muy paranoico, puedes copiar antes el fichero /opt/google/chrome/PepperFlash/libpepflashplayer.so en un lugar seguro por si ocurre un accidente nuclear o tu ordenador es devorado por un agujero negro. A mi me funcionó como la seda, qué quieres que te diga.

¡¡Eh, un momento!!

Bueno, sí. Estás instalando una versión anterior de libpepflashplayer.so que está colgada en un Dropbox de no-se-quién. Y con privilegios de root. ¿No te fías?. Paranoia cosa fina, ¿eh?.

Vaaale, vale. Vete al directorio /var/cache/apt/archives. Ahí deberías tener todos los paquetes legales de google-chrome que has ido actualizando desde el principio de los tiempos. El sistema los deja ahí almacenados cuando los descarga de los repositorios. Elige una versión anterior a la 37.0.2062.120, descomprímela, pilla el fichero libpepflashplayer.so y copialo a /opt/google/chrome/PepperFlash. Para descomprimir el paquete puedes usar los comandos siguientes (sustituye el número de versión por uno que tengas):

cp /var/cache/apt/archives/google-chrome-stable-35.0.1916.153-1_amd64.deb ~
cd ~
ar x google-chrome-stable_35.0.1916.153-1_amd64.deb
tar --lzma --extract --verbose --file data.tar.lzma
sudo cp opt/google/chrome/PepperFlash/libpepflashplayer.so /usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so

Y ya está, estás instalando un Peeper Flash que procede directamente de los repositorios. ¿Más tranquilo así?. Yo no lo he hecho, preferí vivir peligrosamente, pero debería funcionar.

Instalar Spotify en Linux Debian Wheezy 7.x

Si lo has intentado, sabrás ya que no se puede por culpa de unas dependencias anticuadas (libssl0.9.8). Con todo, aún se puede instalar Spotify en una versión un poco más antigua. Pero no necesito explicártelo porque ya lo hace muy bien Javier Lleó. A mi me funcionó sin problemas. Las gracias, a él.

Fallos en una unidad USB después de hibernar/suspender mi ordenador

Si usas hibernar / suspender en tu ordenador y tienes unidades USB montadas habitualmente, es posible que cuando vuelva a despertar no reconozca las unidades USB y te de algún tipo de error.

La forma más rápida de evitar problemas es desmontar todas las unidades USB justo antes de hibernar y volver a montarlas después de despertar. Podemos automatizarlo todo para que ocurra sin tener que hacer nada, solo hay que añadir un script en el directorio /etc/pm/sleep.d/ (suponiendo que usas un sistema Debian o Ubuntu). Observa el script, es muy sencillo, y cámbialo según tus necesidades. Recuerda que, como cualquier script, debe tener permisos de ejecución.

#!/bin/sh
case "$1" in
       hibernate|suspend)
             umount /media/LinBkp1
             umount /media/LinBkp2
             ;;
       thaw|resume)
             mount /media/LinBkp1
             mount /media/LinBkp2
             ;;
       *)
             exit 0
             ;;
esac

Debian no reconoce mi Kindle Touch

Si, si lo reconoce. Incluso podrás montarlo con el comando mount manualmente después de enchufar el kindle al ordenador por USB. Pero no será reconocido automáticamente ni será detectado por Calibre aunque lo hagas.

Para que haga todo eso necesitas instalar las mtp tools (apt-get install mtp-tools mptfs libmtp8). Y con eso ya está. Ahora debería reconocerlo de forma automática tanto Debian como Calibre en cuanto lo conectes por USB.

No puedo logarme en mi QNAP NAS, solo me deja cambiar la contraseña

Un buen día, la página web de configuración de mi QNAP NAS 219P dejó de permitirme al acceso a la página de administración. Eso significa que no podía reconfigurarlo a través de la web. Solo me permitía cambiar la contraseña, nada más que eso.

Bien, cuando un usuario normal (no admin) del NAS accede a la página web, el único servicio al que tiene acceso es el cambio de contraseña. Solo cuando entra el usuario admin accederá no solo al cambio de contraseña, sino a todos los servicios de configuración del NAS.

En otras palabras, si accediendo como admin, tu NAS solo te ofrece el cambio de contraseña, significa que tiene un fallo en el sistema que le impide saber que el usuario admin tiene privilegios de administrador. Eso normalmente, se configura a través del grupo, que está contenido en el fichero /etc/config/group y contiene algo así:

administrators:x:0:admin
everyone:x:100:admin
guest:x:65534:guest
transmission:x:101:

Vale. Para solucionar esto, tendrás que acceder al QNAP usando SSH. Así que haz un «ssh admin@<ip_del_qnap» y lógate con tu contraseña. Comprueba que el fichero /etc/config/group contiene la primera entrada, la que se corresponde con «administrators:x:0:admin». No importa que esté en la primera línea o en la tercera, pero tiene que estar.

En mi caso, el fichero /etc/config/group solo contenía basura que parecía código html. Algún software había sobreescrito el fichero. En cambio, había un fichero llamado /etc/config/group_tmp que sí contenía las entradas correctas. Símplemente moví el fichero /etc/config/group_tmp a /etc/config/group y reseteé el QNAP. Eso solucionó el problema y ya pude logarme como admin.

Si tu no ves un fichero /etc/config/group_tmp al que echar mano, siempre puedes usar el fichero original de fábrica del QNAP, que es /etc/default_config/group. Cópialo (no lo borres) a /etc/config/group y reinicia.

Muy útil, que el QNAP te permita acceder por SSH. Ya son dos, los lios gordos de los que me ha sacado…

Muchas gracias a Phuture y NocturnalFilth, del QNAP NAS Community Forum, que encontraron la solución un año antes que yo. No me deis las gracias, dádselas a ellos. ;-)

Login remoto a otra máquina con VNC

En otro truco, hace días, os hablaba de VNC para acceder a otra máquina de tu red local.

Pero esto se queda un poco corto. Supongamos que quieres un verdadero login remoto, es decir, convertir la máquina remota en un verdadero ordenador multiusuario, de tal forma que un usuario pueda entrar en su escritorio  de forma remota, al mismo tiempo que otro usuario accede al suyo en la propia máquina remota.

Asumo que en tu máquina ya tienes un servidor VNC funcionando y configurado (por ejemplo, en mi caso, Xvnc4). No es muy complicado, de todas formas: solo tienes que instalar el paquete vnc4server con apt-get (en el caso de Ubuntu) y después arrancar el servidor con el comando vncserver. Te pedirá una contraseña para que protejas el acceso, así que dásela. Pero de todas formas, en el método que describo a continuación, se desactiva la autentificación propia de VNC porque usará la autentificación de tu propio escritorio.

Bien, para hacer un login remoto como usuario, hay que combinar XDMCP con VNC, de tal forma que se active el servidor VNC de la máquina remota bajo demanda, sin que tengas que hacerlo a mano cada vez (nada de SSH para activar el servidor).

Para ello, en primer lugar, debes crear un puerto específico destinado a VNC en la máquina remota echando mano del demonio xinetd. Edita el fichero /etc/services y añade una línea que diga esto:

vnc    5908/tcp   #Xvnc

Esto activa el puerto 5908 para el servicio VNC. Vale, ahora tienes que decirle al ordenador remoto lo que tiene que hacer cada vez que reciba una petición de acceso en ese puerto. Para ello crea un fichero /etc/xinetd.d/vnc que diga tal que esto:

# Default: on

# Descripcion: El servidor vnc se activa bajo demanda
service vnc
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = :8 -inetd -once -query localhost -depth 24 -geometry 1280x1024 -securitytypes=none
}

El parámetro «server» dice qué programa atenderá la petición de acceso (en este caso, el servidor VNC), y el parámetro «server_args» dice con qué parámetros se activa (en este caso dice que se usará la pantalla 8, que se pondrá en marcha con el acceso y se detendrá cuando se cierre, que el servidor hará una conexión local XDMCP, que tendrá una profundidad de color de 24 bits, con un escritorio de 1280×1024 y que se desactiva la autenticación de VNC).

¿Ya?. Vale, ahora reinicia el servicio xinetd con un «sudo /etc/init.d/xinetd restart«.

Vale, ahora tienes que activar XDMCP en sí mismo. Esto dependerá de qué gestor de pantallas uses. Si estás usando gdm (Gnome), que es lo más habitual, entonces edita el fichero /etc/gdm/custom.conf y en el apartado [xdmcp] cambia la línea «Enable=false» por «Enable=true«. Esto es lo que ocurre en Ubuntu, para ser más exactos. En otros sistemas puede que te venga mejor ejecutar gdmsetup, o si usas KDE  editar los ficheros de configuración de kdm, o en otros sistemas los de xdm (si no usas ni Gnome ni KDE). En cualquiera de los casos, ya sea en gdm, kdm o xdm, tienes que acceder a la configuración y activar la opción XDMCP. Para localizar los ficheros en cuestión te puede ayudar el comando «find /etc -name gdm» por ejemplo, o averiguar cómo hacerlo en tu sistema buscando en Google (por ejemplo «ubuntu habilitar xdmcp»)

Vale, ahora reinicia el servidor gráfico o mejor resetea la máquina entera. Con esto ya has terminado en la máquina remota.

Ahora vete a la máquina cliente, abre un terminal y teclea: «vncviewer selene:5908«. Bien, obviamente, no tienes que teclear esto exactamente, sino el nombre (o la IP) de tu propia máquina remota.

Y ahora deberías abrirse en tu pantalla algo así:

La máquina remota ofreciendo login a través de VNC

Tecleas tu contraseña de usuario y et voila:

La máquina remota dándote acceso a tu escritorio

La máquina remota dándote acceso a tu escritorio

Google Chrome ya no recuerda mis contraseñas

Un día abres tu navegador todo confiado y te encuentras conque en todas tu páginas favoritas estás deslogado en la página de entrada. Curiosamente tu contraseña está ahí, con todos sus asteriscos, pero no has entrado automáticamente, tienes que darle al botón.

Pulsas la casilla de «Recuérdame», le das al botón. Entras a la página. Luego cierras el navegador y vuelves a abrirlo. Otra vez deslogado. La contraseña está ahí otra vez, pero no te ha recordado. Que desconsiderado…

Vas a preferencias, borras los datos de navegación, borras las cookies, te aseguras de que la casilla «Permitir que se establezcan datos locales» está marcada en «Configuración de contenido». Vuelves a intentarlo y nada, no te recuerda.

Bien, no me anduve con contemplaciones.  Yo lo solucioné así:

  1. Entré en «Preferencias», «Cosas personales» y me aseguré de que tenía configurada una cuenta de Gmail para mantener sincronizados los marcadores y esas cosas.
  2. Cerré el navegador.
  3. Abrí una consola y borré la carpeta «.config/google-chrome» de mi Home (yo tengo copias de seguridad actualizadas a diario, ¿las tienes tu?).
  4. Abrí de nuevo el navegador. Está desconfigurado, así que lo primero que hace es preguntarte qué portal de búsqueda quieres (obviamente, Google, ¿no?).
  5. Se abre el navegador pero virgen, sin marcadores ni nada.
  6. Vas a «Preferencias», «Cosas personales» y configuras la cuenta de Gmail para sincronización. Automáticamente vuelven a aparecer todos tus marcadores y esas cosas.
  7. Entro en todas mis páginas favoritas. Cierro el navegador.
  8. Lo abro y ahora sí me recuerda y entro directamente ya logado. :-)

No, no me ando con chiquitas…

Hotot se queda colgado diciendo «Loading Resources…»

No puedes iniciar el cliente de Twitter Hotot, porque se queda colgado diciendo «Loading Resources…» sin hacer nada más. Lo que es peor, si esperas que una actualización lo solucione vas de cráneo, porque seguirá haciendo lo mismo.

Solución: Algo ha pasado con los ficheros de configuración de Hotot y están corruptos. Bórralos y deja que sean creados de nuevo.

[lacofi@cecile ~]$ rm -Rf .config/hotot
[lacofi@cecile ~]$ rm -Rf .cache/hotot

Ahora arranca Hotot y te pedirá que introduzcas tu cuenta de Twitter.

Notas sobre la actualización de Ubuntu 11.10 (Oneiric Ocelot) a 12.04 (Precise Pengolin)

En la actualización, se desactivan automáticamente todos los repositorios de terceros, por lo que habrá que reactivarlos o actualizarlos posteriormente.

Hay determinado software que te dará algún problema extra.

Dropbox

Dropbox no consigue reiniciarse una vez actualizado el sistema a 12.04.

Este problema me surgió en la actualización de Cecile, pero no es una instalación fresca en Sophie. Para imitar una instalación fresca:

  1. Ejecuta el comando «echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches». Sio no lo haces, te lo pedirá él de todas formas en cuanto lo inicies.
  2. Borra tu carpeta Dropbox (haz antes una copia de seguridad, claro).
  3. Borra la configuración (es decir, el directorio «.dropbox» de tu Home)
  4. Ahora inicia de nuevo dropbox.

Con esto, en mi sistema funcionó y empezó a sincronizar de nuevo. Eso si, preparate para esperar un buen rato, porque tendrá que bajarse de nuevo todos los ficheros desde la nube. Curiosamente no funcionó a la primera sino al segundo o tercer intento.

Curioso, muy curioso.

VMware

O VMplayer, da igual. No funcionan en Ubuntu 12.04. El problema es que fallará la compilación de los módulos vmnet debido a cambios en el kernel 3.2 que usa esta versión de Ubuntu.

Afortunadamente, hasta que los chicos de VMware se den por aludidos y saquen una versión corregida compatible con Ubuntu 12.04, hay disponible un parche creado por la comunidad. Bájatelo a tu ordenador. Descomprimelo. Vete a la carpeta donde se ha descomprimido, y ejecuta el script «patch-modules_3.2.0.sh» como root. Deja que el script trabaje y parchee las fuentes. Cuando termine (no tardará mucho), arranca de nuevo VMware.

Esto funciona para la versión de VMware 8.0.2. Si quieres instalar la nueva versión VMware 8.0.3 volverá a fallar la compilación, así que tendrás que ejecutar de nuevo el script. Pero antes tienes que editarlo y cambiar la línea donde pone «vmreqver=8.0.2» por «vmreqver=8.0.3» para después ejecutar el script.

Si aplicas el parche a VMware 8.0.2 y después actualizas a 8.0.3 el parche no dejará que lo vuelvas a ejecutar. Para que funcione, tendrás que borrar el fichero /usr/lib/vmware/modules/source/.patched como root.

El fichero .xsession-errors crece sin control en Ubuntu 11.10

En Ubuntu 11.10 (Oneiric  Ocelot), me he encontrado conque con cierta frecuencia el /home se queda sin espacio. El motivo es que hay un fichero que crece exponencialmente ocupándolo todo. Me refiero, claro, al fichero .xsession-errors de tu Home. Si borras el fichero con «rm» te encuentras conque no liberas espacio en absoluto y, aunque el fichero no existe, el espacio sigue constando como ocupado. Solo después de resetear el sistema volverás a tener ese espacio libre.

Se trata de un bug conocido. La nueva distribución Ubuntu 12.04 (Precise Pangolin) lo soluciona (más bien lo parchea) volcando los errores del subsistema gráfico a un fichero de /tmp con lo que los logs son borrados en cada reseteo del sistema. Pero si eres como yo y tu ordenador está siempre encendido, los logs nunca serán borrados y el fichero seguirá creciendo exponencialmente aunque esté en /tmp.

La solución definitiva es decirle al sistema de log que ese registro de errores se vaya directamente al agujero negro. Para ello edita el fichero /etc/X11/Xsession, edítalo como root, y en él verás una linea que dice:

ERRFILE=$HOME/.xsession-errors


Cambia esa entrada para que diga:

ERRFILE=/dev/null


Resetea el sistema. Ya está. Ahora el fichero de errores no ocupará espacio porque se irá a carajo según se vaya creando.

Muchas gracias a los miembros de Ubuntu Forums, como siempre ahí, al rescate.