Category Archives: Linux

Feisty sin bordes de ventanas al iniciar sesión Gnome

Si al iniciar tu sesión desde Ubuntu 7.04 ves que se han ido los bordes de las ventanas (y además le cuesta bastante iniciarse los programas de inicio que tengas) es debido a un bug, ya reportado, que se carga el inicio del manejador de ventanas por defecto (y por ello no se ven los bordes y le cuesta iniciarse los programas de inicio, debido a que están esperando a que el window manager termine de iniciarse, puesto que “va antes que ellos”).
 
Si inicias ahora a mano el manejador de ventanas, verás que funciona todo como siempre perfectamente, pero es un poco chapuzas y totalmente inaceptable esa solución. El problema está en el fichero ~/.gnomerc que lo ha sobreescrito compiz. ¿Solución? simple, borrar el fichero ($ rm ~/.gnomerc).

Seguridad en VNC, que falta le hace (iptables & ssh)

VNC es un sistema para poder visualizar escritorios remotos. En ubuntu viene ya de serie, concretamente vino un servidor vnc integrado con gnome. Vnc es un mal sistema para trabajar, hace no mucho comenté una alternativa muy superior, pero según qué casos, vnc sigue siendo un método válido y acertado (mayormente cuando no queremos iniciar una nueva sesión y queremos ver el escritorio del usuario que está logeado actualmente).
 
El grave problema de vnc es su total falta de seguridad. Para paranoicos que no confían ni en ellos mismos, entre los que me incluyo, es algo que no se puede consentir. Hay que solucionar este problema, o dejar de usarlo. Los problemas evidentes de seguridad que se derivan del uso de vnc son claros: ataques de fuerza bruta (esto viene acentuado por el límite en vino de un máximo de 8 caracteres de longitud de la clave), ataques man-in-the-middle y sniffeo de la conexión. Unido a que todo se transmite en claro, es un autentico agujero de seguridad y se puede aprovechar para robo de contraseñas y datos sin conocimiento.
 
¿Qué hacer? Pues gracias a nuestro amigo ssh podemos encriptar todas las comunicaciones (con lo cual, resolvemos los problemas de man in the middle y sniffeo). Usaremos un tunel ssh para conectarnos al servidor vnc remoto. Esto significa que en el ordenador al cual queremos conectarnos, tendrá que estar, además del servidor vnc (vino en nuestro caso), un servidor ssh ($ sudo aptitude install ssh). Ahora desde el cliente, solo tenemos que ejecutar lo siguiente para conectarnos usando el cliente vnc xvncviewer ($ sudo aptitude install xvncviewer):

ssh -C -o CompressionLevel=9 -f -L 5900:localhost:5900 USUARIO@SERVIDOR_REMOTO sleep 15 ; xvncviewer localhost:5900

¿Qué cojones hace todo eso?. Con -C y CompressionLevel decimos que comprima los datos, siendo que vnc genera un tráfico considerable, es una buena opción activar esta opción para ganar algo de rendimiento. Con -f estamos diciendo que se cierre la conexión cuando se deje de usar. Y, aquí viene la magia, con -L estamos creando un tunel desde el puerto 5900 local (el primer número), al puerto 5900 del servidor remoto (lógicamente tienes que cambiar el usuario y el servidor_remoto por los que corresponda). Luego, inmediatamente después de ejecutar el comando ssh (el cual establece el túnel y ejecuta un estúpido sleep 15, dormir 15segundos) ejecutamos el cliente vnc hacia el puerto 5900 de nuestro ordenador cliente, lo cual significa que se va a conectar, mediante el túnel creado, al ordenador remoto. Y entonces tendremos que introducir nuestra contraseña antes de 15 segundos, puesto que sino el sleep terminará y dado que se ejecuta el comando ssh con la opción -f, el túnel se cerraría.
 
Aún nos falta evitar ataques de fuerza bruta. Ya que vamos a usar un túnel ssh para conectarnos al puerto 5900 (el puerto que usa el servidor vnc). No hay ninguna razón para dejar este puerto abierto. Por lo tanto la solución más efectiva será filtrar todo el tráfico entrante a este puerto desde cualquier ordenador remoto. Esto viene a ser dos lineas de iptables

iptables -A INPUT -s 127.0.0.1 -p tcp -m tcp –dport 5900 -j ACCEPT
iptables -A INPUT -p tcp -m tcp –dport 5900 -j DROP

Aceptamos conexiones locales al puerto 5900 tcp, y denegamos el resto. Yo uso un fichero con todas las reglas del cortafuegos poniéndolo en /etc/init.d/cortafuegos y creando luego un enlace para que se ejecute al inicio ($ sudo ln -s /etc/init.d/cortafuegos /etc/rc2.d/S99cortafuegos), aunque posiblemente haya otros métodos mejores. La idea es esa, cerrar el puerto.
 
¿Qué hemos conseguido con todo este tinglado? Hemos eliminado absolutamente toda la falta de seguridad de VNC, y hemos pasado “la pelota” al servidor ssh, nuestras conexiones vnc ahora serán tan seguras como lo son las conexiones al servidor ssh.

Montando unidades por red, samba.

Actualmente es bastante común tener una subred en casa, o en el trabajo. Y claro, si metemos el factor windows, siempre tiene que estar tocando la moral. Pero bueno, una vez instalados los paquetes de samba, se pueden montar fácilmente unidades compartidas. El único factor a tener en cuenta, cuando el servidor que comparte dichas unidades es un windows, serán los acentos (y eñes, y similares), debido al charset diferente que usa Windows por defecto. Este pequeño problema se resuelve indicando qué codificación usar (utf8, como debe ser).
 
Además, si se requiere identificación, podemos usar un fichero (quitándole permisos de lectura para todo el mundo salvo para root, por problemas de seguridad obvios) con el formato siguiente

username=usuario
password=clavecita

Y a la hora de montar la unidad, indicamos ese fichero como nuestros “credenciales“. En definitiva, suponiendo que dicho fichero se encuentra, por ejemplo, en /etc/credentials_HOST, usaríamos la siguiente orden

$ sudo mount -t cifs //HOST/CARPETA_COMPARTIDA /mnt/HOST -o credentials=/etc/credentials_HOST -o iocharset=utf8

Cambiando claro el HOST por el que fuera, el recurso compartido por el que fuese y el directorio donde quieres que se monte por el que más rabia te dé.
 
Finalmente un comentario más, puesto que no encontré la respuesta por ningún lado, y por listas y foros únicamente había gente preguntandolo, pero nadie respondía. Si te encuentras con el siguiente error

mount error 79 = Can not access a needed shared library
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Se debe a que has indicado un charset inválido (por ejemplo utf-8, con el guión), fíjate, y ponlo bien hombre!

Problemas con la cámara digital

Un poco de culturilla general antes, ¿no?. Actualmente, todo sistema Linux usa udev, un gestor de dispositivos que maneja los nodos de /dev, el sucesor de devfs. udev se ejecuta en espacio de memoria de usuario y es simplemente un demonio que se queda escuchando mensajes que le envía el kernel (se conecta un dispositivo, se desconecta, etc…) y hace lo que tenga que hacer (de acuerdo a unas reglas que pueden ser configuradas).

Las cámaras digitales, al conectarse por usb, al final son manejadas por udev. Si al conectar la cámara nos encontramos con un problema similar a este:

An error occurred in the io-library (‘Could not claim the USB device’): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device.

O, en español:
Se ha producido un error en la biblioteca de entrada-salida (‘No se pudo reclamar el dispositivo USB’): No se pudo reclamar la interfaz 0 (Operación no permitida). Debe asegurarse de tener acceso de lectura/escritura al dispositivo y que ningún otro programa o módulo del núcleo (como sdc2xx, stv680, spca50x) esté utilizándolo.

Puede ser debido a dos cosas, una de ellas que estamos usando ubuntu edgy y hemos actualizado un paquete (libgphoto2-2), el cual, actualmente, tiene un pequeño bug respecto a las reglas udev. Miramos el fichero /etc/udev/rules.d/45-libgphoto2.rules en la linea 3

BUS!=”usb*”, GOTO=”libgphoto2_rules_end”

¡Eso está mal! Puesto que los eventos de las nuevas versiones udev no tienen propiedades BUS, por lo tanto, esa linea hará que todo el contenido del fichero sea inutil. Tenemos que cambiarlo a algo como esto:

SUBSYSTEM!=”usb_device”, GOTO=”libgphoto2_rules_end”

Reiniciamos udev, y ya podremos conectar la cámara sin problemas :).

$ sudo /etc/init.d/udev restart

 
Otro problema que puede surgir (si lo de arriba no te ha sido útil, prueba esto), es que nuestra cámara no esté en el fichero de reglas. Esto se puede solucionar fácilmente. Ejecutamos lo siguiente para saber el IDVendor e IDProduct de nuestra cámara (estando conectada la cámara por usb):

$ lsusb
(…)
Bus 004 Device 005: ID 04a9:30fc Canon, Inc.
(…)

Lo que nos interesa es lo que he marcado en negrita, ese código es el IDVendor:IdProduct respectivamente. Ahora editamos el fichero /etc/udev/rules.d/45-libgphoto2.rules añadiendo una linea (junto con el resto de reglas que aparecen en él) que indique lo siguiente:

SYSFS{idVendor}==”04a9“, SYSFS{idProduct}==”30fc“, MODE=”0660″, GROUP=”plugdev”

Cambiando los Id’s por los que nos hayan salido en el comando anterior. Ahora solo queda reiniciar udev y conectar de nuevo nuestra cámara.

$ sudo /etc/init.d/udev restart

Y fiesta!

Nvidia al poder

nvidia_corporate_logo_p.jpg
Si instalas los drivers de nvidia en tu ubuntu, una de las cosas que jode bastante es cuando hay actualizaciones del kernel, puesto que debido a dicha actualización, los drivers quedarán inservibles, puesto que toca instalarlos de nuevo para que se cree (compile) un nuevo módulo.

Hasta ahora la solución que usaba era directamente bloquear el paquete y no actualizar, pero gracias al magnifico instalador de nvidia, podemos pasarle un parámetro (al instalador) para que genere únicamente el módulo (sin necesidad de tener que desinstalar el driver y volver a instalarlo, es tontería puesto que instalado ya está, simplemente necesitamos compilar un nuevo módulo para el nuevo kernel). Ejecutamos el instalador (si lo borraste, este es el link de la última versión a día de hoy) con la opción -K para que únicamente compile el módulo.

$ sudo ./NVIDIA-Linux-x86-1.0-9746-pkg1.run -K # o --kernel-module-only

Y como recuerdo, hay que saber que siempre podemos usar esta opción para cuando haya nuevas versiones:

$ sudo nvidia-installer --update

[Actualizado 11 feb]: al poner lo del update, miré si tenía el nvidia-installer la opción -K y si que la tiene, pero al ejecutarlo falla, quizá solo funcione si al instalar por primera vez los drivers se le indica de alguna forma que guarde el binario…

iWeather, el tiempo como debe ser

Cuando hace poco se me jodió el disco duro y tuve que reinstalar todo desde cero. Uno de los problemas que me encontré fue encontrar el desklet que usaba desde hace mucho tiempo para ver el tiempo que va a hacer (iWeather). Lo normal sería que estuviese en la web del programa, gdesklets, pero por razones del destino no está. Después de una busqueda por google logré descargarlo de algún foro raro gracias a alguien que lo había subido sin linkearlo a la página de gdesklets (que eran la mayoría :P).

Aparte de eso, he hecho algunos cambios para que se muestren los porcentajes de posibilidad de lluvia, y eliminado otras cosas (¿a quién cojones le importa la presión atmosférica?) que no me gustan que salgan. Aquí una imagen de como se vería

iweather.jpg

Por si alguien lo quiere, aquí lo dejo en descarga, ya que, como he dicho antes, por motivos que desconozco, no está para descargar en la página del programa.