miércoles, 21 de diciembre de 2011

Sudo: instalación y configuración

Para todos aquellos que hemos vivido un tiempo en Ubuntu se nos hace extraño no disponer de sudo para hacer de dictador en el ordenador.


A lo largo de este último mes he estado solucionando "problemillas" en Fedora 16 que han exigido autentificarse como administrador. Eso nos exige, si no tenemos sudo ya instalado, entrar como tal usando su:
su -
y ejecutar luego.
O dar la orden directamente
su - c comando (su --comand comando).

Si queremos instalar sudo y configurarlo para hacerlo más fácil en Fedora lo podemos hacer en el terminal o con la ayuda de easyLife.


Terminal:
1. Instalar sudo

& su -
     palabra de identificación de administrador
# yum install sudo

2. Configuración para que sudo nos reconozca, agregando un usuario a /etc/sudoers (como administrador)

# echo "nombreusuario ALL=(ALL) ALL" >> /etc/sudoers

Al hacer esto el usuario puede utilizar todas las aplicaciones del sistema con SU PROPIA PALABRA DE IDENTIFICACIÓN, sin necesidad de recurrir a la identificación como administrador. Podemos ser incluso más drásticos

# echo "nombreusuario ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

En este caso ni siquiera tenemos que poner una palabra de identificación

Esas dos acciones las podemos hacer también editando directamente sudoers,  identificados como administrador,

# gedit /etc/sudoers

añadiríamos al final la línea


Tengamos en cuenta que sudoers es un fichero "delicado". Si nos equivocamos, puede que bloqueemos el sistema (véase por ejemplo aquí, o aquí).

2. La forma fácil en Fedora: easyLife
Bajamos la última versión, y la instalamos.
La ejecutamos, fácilmente de encontrar


Y luego simplemente tenemos que marcar la configuración de sudo.


Listo.

No podemos olvidar que algunos opinan que es introducir una debilidad en la seguridad de Linux. No es imprescindible, aunque muchos scripts vienen escritos para utilizar sudo. Es algo que tiene que calibrar cada usuario


martes, 20 de diciembre de 2011

Dropbox y los "10000 folders"

Hoy Dropbox me ha fallado por primera vez. Desde hace mucho tiempo, casi tres años, lo que en informática es una era, he trabajado siempre en el directorio de Dropbox. En mi trabajo uso alternativamente 4 ordenadores en sitios distintos y siempre he tenido mi trabajo actualizado en todos mis equipos gracias a Dropbox. Sin embargo, después de arreglar unas fotos ayer por la noche en la intempestiva hora de las 1:30 en mi casa, al llegar a uno de los ordenadores de trabajo... no estaban allí. Al comprobar Dropbox en la red, ¡tampoco estaban! Al volver a casa con retraso en mi trabajo e intentar comprobar por qué Dropbox no había subido las imágenes, recibo un aviso con el siguiente texto:

Unable to monitor filesystem
Please run: echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches
and restart Dropbox to correct the
problem.

Nunca había recibido ese mensaje; buscando en la red he encontrado esta información (ver aquí):

"Monitoring more than 10000 folders
The Linux version of the Dropbox desktop application is limited from monitoring more than 10000 folders by default. Anything over that is not watched and, therefore, ignored when syncing."

Es decir, Dropbox se limita a monitorizar hasta 10.000 directorios. Yo no tengo 10.000 directorios, aunque sí más de 24.000 ficheros. Por suerte nos da la solución. Primero, si hacemos como dicen,

echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches

o bien

sudo sysctl fs.inotify.max_user_watches=100000


en un terminal, inmediatamente Dropbox comienza a sincronizar. Por desgracia eso solo sirve hasta reiniar el sistema. Para fijar esta corrección debemos editar sysctl.conf e introducirle la línea fs.inotify.max_user_watches = 100000 (mirar en este otro sitio). Es decir,



sudo gedit /etc/sysctl.conf (si tenéis sudo instalado y configurado, para los usuarios de Fedora)

y al final del fichero introducir una línea así

fs.inotify.max_user_watches = 100000

La pregunta que me hago es, ¿por qué ahora y nunca antes? No me lo ha hecho jamás en Ubuntu ni tampoco en este tiempo que llevo en Fedora hasta ayer, que realizó la última sincronización a las 23:59. El único cambio fue el kernel 3.1.5-6.fc16.x86_64 (y otros 80 y tantos paquetes más, entre los cuales no me fijé en ninguno en particular). Si el límite son 10.000 directorios ¿por qué? si no debo tener más de 400. Si son ficheros, ¿por qué no me lo hizo antes?
Misterios de la informática.

lunes, 19 de diciembre de 2011

Unidades USB. Uso de Hubs alimentados

La solución para el uso de los dispositivos externos pasa por dos acciones.
Primero, dar permiso a los dispositivos externos mediante ntfs-config, que hay que arrancar como administrador, en Fedora, por falta de gksu, se hace desde terminal
$ su -
     (password)
# yum install ntfs-config

Para llamar a la aplicación  tenemos que generar directorios -como administrador- que en las últimas actualizaciones de kernel ya no existen (véase aquí)

# mkdir /etc/hal
# mkdir /etc/hal/fdi
# mkdir /etc/hal/fdi/policy

y ya podemos llamar a ntfs-config -seguimos como administrador-

# ntfs-config





donde permitimos el uso de dispositivos externos.

Segundo, y no menos importante, por lo que me ha pasado a mi, poner los lápices USB en un puerto bien alimentado. La copia que tardó 26 minutos se hizo en 2 minutos y medio poniendo el mismo lápiz USB en un hub alimentado, lo que se denomina hub "self-powered", es decir autoalimentado. El intento anterior se hizo en un puerto USB situado en el monitor, que se une mediante un cable de 1m a otro hub sin alimentación. Esto nos indica que el monitor no debe alimentar ese puerto, y por lo tanto no es de extrañar que tardara tanto. Lo que me extraña es que acabara la copia o que se detecte a la unidad.

Queda una prueba por realizar, que es la copia en disco duro. No puedo negar que la temo, por que en los dos últimos intentos he perdido 600GB de material multimedia, pero tarde o temprano la tendré que hacer.

sábado, 17 de diciembre de 2011

Fedora 16. Copia en dispositivos externos NTFS

Una de los problemas que aun estoy teniendo en Fedora es la copia a dispositivos externos. Como es bien sabido, el permiso para copia en dispositivos externos tiene que ser autorizado. Eso me ha pasado en Ubuntu, y también aquí. El problema se resume hasta ahora mismo así:
1. Primer intento. Copia de un fichero de 2,2GB a una unidad USB Kingston DataTraveler 400 de 4GB. Después de hora y media de aburrimiento, lo desmonto y el resultado es que la unidad no tiene el índice de contenidos adecuado y el fichero de 2,2GB no aparece. Son "visibles", en teoría, 4 ficheros más pequeños que habían sido borrados.
2. Segundo intento. Reintento de copia en la misma unidad USB dejándole toda la noche; desmontado normal. Mismo resultado.Por lo tanto deduzco que me está pasando que la copia en los dispositivos externos no está permitido. En Ubuntu siempre lo he solucionado llamando a ntfs-config y permitiendo la copia a dispositivos externos formateados en NTFS con ntfs-3g. Instalo el paquete desde PackageKit (me sigue gustando más Synaptic).


La sorpresa surgió de que al llamar a la aplicación surge este aviso:


Es decir, a aquellos usuarios que nos sentimos cómodos en Linux, pero solamente por que nos hemos movido por Ubuntu, nos entra una pequeña "flojera" al ver que realmente aun no sabemos tanto. Damos por sentado que gksu está instalada "per se", y no es así. En su página Web se puede observar de que aunque se define como librería para uso gráfico de su y sudo, realmente está desarrollada por gente de Debian, y por ello no está instalada en distribuciones rpm. Más aun, ni siquiera está empaquetada por Fedora, así que no está disponible en los repositorios


Tenemos disponible beesu, pero según algunos comentarios en la red genera o puede generar problemas en el arranque de los ordenadores.
Yo lo he intentado solucionar de manera terminal a través de sudo


Sin embargo el resultado, hasta ahora, no es satisfactorio. He copiado el mismo fichero de 2,2GB a un dispositivo Kingston DT R500, teóricamente más rápido en escritura y, aunque sí se ha copiado y funciona en otros ordenadores y en la unidad WDTV, ha tardado más de 20 minutos a una velocidad media final de 1,4 MB/s, que es la décima parte de la velocidad con la que debería copiar este lápiz.

Próximos intentos:
- Ya he instalado, como se ve en la imagen superior, beesu, aunque cuando lo llamo sin su o sudo, no veo que funcione como gksu, que automáticamente daba la posibilidad de autentificarse como administrador y permitir el uso de la aplicación que lo necesitase (aunque en el fondo es también una quiebra en la seguridad). Por ahora no supone ninguna diferencia.
- Me queda por probar dispositivos externos en ext4, para saber si se debe a ser dispositivos externos o por estar formateados en NTFS, que en general, podrían ir más lentos (ver aquí).
- Si funciona más rápido en ext4, lo siguiente será probar discos duros externos en NTFS (no me atrevo desde el último intento con 600GB perdidos).
- Si los DD NTFS funcionan, entonces empezaré a usar diferentes puertos para los lápices.
Seguiremos con el asunto

viernes, 16 de diciembre de 2011

Instalación de JDownloader en Fedora

Al contrario que en Ubuntu, donde ya tenemos un repositorio preparado, en Fedora tenemos que recurrir a un script para instalarlo. Desde el principio me he basado en esta entrada del blog de MeltIt para hacerlo. Empezaremos por instalar Java. En particular yo ya tenía instalada Java libre desde la instalación desde el DVD 64bits.
Bajaremos desde wget el script desde la página de jdownloader. No nos olvidemos que wget no se instala automáticamente en Fedora, así que tendremos que hacer

$ sudo yum install wget

o bien (si no hemos instalado y configurado sudo)

& su -
     poner la palabra de administrador
# yum install wget

Luego ya podemos descargar el script

$ wget http://212.117.163.148/jd.sh

Seguimos las instrucciones de jdownloader para su instalación en Linux
a. Damos permiso de ejecución al script como administrador

# chmod +x jd.sh

b. Lo ejecutamos

$ start jd.sh

Finalmente, desde el mismo terminal nos localizamos en su directorio y ejecutamos
$ cd .jd
$ java -Xmx512m -jar JDownloader.jar


Y listo. Algo más largo que en Ubuntu, pero no muy complicado.



Instalar paquete rar en Fedora

El paquete rar no está en los repositorios de Fedora, así que no podemos aplicar directamente la orden yum install rar. En este caso tenemos que recurir a un repositorio externo, en concreto a ATrpms. Son repositorios para, según sus propias palabras, "Red Hat Linux flavours". Por supuesto, descubrí los repositorios consultando en la red a otros usuarios, en concreto, aquí. Si nos dirigimos a los paquetes de Fedora 16 (en este caso), descubrimos que ahí está el paquete rar. Según las instrucciones encontradas aquí, y las de instalación de ATrpms, podemos instalarlo descargando manualmente los paquetes necesarios, que podemos encontrar para Fedora 16 aquí -bien de 64 bits o 32 bits- y luego instalarlos mediante rpm -Uhv (debería llegar rpm -ihv, ya que vamos a instalar, pero con -U, si el paquete ya estuviera instalado, aseguramos el reemplazo del paquete anterior por el nuevo; además, así recomiendan en las instrucciones de ATrpms). Es decir, una vez bajados, 


sudo rpm -Uhv atrpms-repo-16-4.fc16.x86_64.rpm # 64bits


sudo rpm -Uhv atrpms-repo-16-4.fc16.i686.rpm # 32bits


Con ello los podemos encontrar ya en /etc/yum.repos.d/.


Finalmente, 


sudo yum install rar

Y listo. Ya podemos recuperar los volúmenes perdidos o detectar crc erróneas. Una vez terminado, recomiendo eliminar el paquete, por todas esas razones que ya he dicho muchas veces.

sudo yum remove rar

Un último apunte; solo podremos usar sudo si lo hemos instalado. Si no es así, deberíamos hacer

$ su -
(palabra del administrador)
# rpm ....
# yum ...

La forma más fácil de instalar sudo y que quede configurado es a través de easyLife. Tal que así


jueves, 15 de diciembre de 2011

Java+JDownloader - Consumo de recursos

Si en un momento determinado tenemos una necesidad de recursos para cualquier operación, mejor será que desconectemos JDownloader. Y como prueba, un botón ... quiero decir un htop.


miércoles, 14 de diciembre de 2011

Fedora 16, Gnome Shell, ATI y un driver (o más de uno...)

La última batalla con el ordenador ha sido la que he tenido que he mantenido con los drivers de ATI en el Gnome Shell en Fedora 16. Una vez controlado el fuego provocado por la RAM, y tras la alegría inicial, empezó a congelarse el ordenador. A la primera "congelación", es decir, monitor sin señal y sin respuesta al teclado, asumí que era una suspensión por tenerlo mal configurado en Energía y que no se podía recuperar de la Suspensión. Sin embargo, al repasar lo configuración, no era así. Tras la segunda, asumí que era un fallo de RAM -otra vez- y que memtest no lo había detectado todo. Tras dos horas de memtest parecía claro que no era así. A la tercera decidí no esperar y estuve delante de la máquina hasta que se produjo, y en las líneas que empezaron a salir hasta la congelación de veía claramente que había un conflicto entre el driver ATI (el que pone Fedora directamente) y el sistema. El primer intento de solución fue, mediante easyLife instalar el driver propietario, y eso generó un segundo problema... El monitor, justo tras la aparición de la f de Fedora se ponía en un perfecto negro sin señal (tengo un vídeo que lo demuestra - algún día lo colgaré). Finalmente decidí recurrir a, como diría Bob Esponja, la "vieja fiable", es decir, a una nVidia (G86 GeForce 8500GT) que conservo desde los momentos en que el driver 773 me daba dolores de cabeza (1, 2). Eso, y 59 minutos de instalación y configuración, tras lo cual tenía el sistema con los mismos paquetes y preparado como una hora menos un minuto antes (cronometrado). solución definitiva, voy a comprarme un ordenador básico con gráfica integrada de chip Intel, por que de las tarjetas gráficas estoy hasta los ... pelos, que ya no tengo, por cierto.

martes, 13 de diciembre de 2011

Razón para la instalación y eliminación siguiente del paquete rar. ACTUALIZACIÓN

Han surgido dudas sobre la afirmación que realicé en alguna entrada previa. Las razones son varias; la primera, y quizás poco importante, según la forma de pensar del usuario, es que el paquete rar no es libre, como ya había dicho aquí y podemos comprobar en esta imagen,


donde se ve claramente que es SHAREWARE. Pero, en segundo lugar, provoca alteraciones en el reconocimiento de caracteres al descomprimir ficheros, lo que hace que los ficheros comprimidos no sean correctamente reconocidos y no puedan ser directamente extraídos por las guías gráficas rápidas que usamos. Como ejemplo, estos subtítulos; con el paquete rar instalado aparecen así


y la aplicación encuentra un error y no descomprime los ficheros. Desinstalamos rar y ...


...podemos descomprimir perfectamente los ficheros. Esas son las dos razones.

Para aquellos que, como yo, hayan abandonado el mundo fácil y suave de Ubuntu, haremos una entrada de como instalar el paquete rar en Fedora, ya que no está en los repositorios oficiales iniciales de la distribución.

Actualización: Ante la duda de algún amigo de por qué cargo rar teniendo un unrar-free, una simple aclaración: rar lo uso para recuperar volúmenes perdidos, nunca para descomprimir. Una nueva utilidad es la detección de volúmenes con crc errónea, que últimamente son muy frecuentes en nuestras correrías multimedia.

lunes, 12 de diciembre de 2011

Errores en memoria RAM: memtest

La verdad es que llevaba unos meses -aproximadamente desde mayo- bastante fastidiado, ya que el ordenador principal, el que tiene una copia maestra de todo, se bloquea cuando quiere. En esta última semana he tenido dos copias masivas de ficheros con pérdida total del material al colgarse el ordenador en medio de la copia y no guardar el índice en el disco externo. Como estaba cansado de tanta tontería decidí hacer dos cosas; una, pasarme definitivamente a Fedora, que me gusta mucho; dos, antes de poner Fedora, hacer un memtest sobre la RAM del ordenador, ya que es la única explicación lógica de que Linux me haga pantallazos como si fuera Windows. Siempre he tenido un cierto miedo a los fallos de RAM, por que suelen aparecer aleatoriamente y son difíciles de detectar; o eso pensaba yo. Por alguna razón los técnicos informáticos (todos seguidores acerrimos de Windows) se reían de mi diciendo que nunca encontraría el error. Sin embargo, memtest86 v.4.20 había detectado el error a los pocos segundos


Como se ve detecta un error en el MB 1095 de la memoria RAM. Sin embargo, dejé que continuara hasta el final.


A pesar de los 192 errores registrados esta última foto, los errores totales, todos en el MB 1095 y todos con el mismo error (Err-Bits 00000020) llegaron a más de 220. Por suposición extraje el banco A1 de los 4 de 2GB DDR2 del ordenador y volví a pasar el test. Esta vez no apareció ningún error. Por suerte, la RAM la había cambiado hace relativamente poco tiempo (4 bancos de 1GB por 4 de 2GB), por lo que estaba en garantía. Espero que haya reparado el ordenador, por que la otra solución sería cambiarlo y ahora mismo no quiero. Además, escribo esta entrada desde ese mismo ordenador y Fedora 16. Ya solo me queda el ordenador más antiguo con Ubuntu (un 10.04.3). Un día de estos lo cambiaré también. Es más, a pesar de ser bastante antiguo y con poca RAM, voy a intentar Fedora 16, por que funciona de forma muy fluida, más "ágil", desde mi punto de vista, que Ubuntu 11.10 (¿Será culpa de un tal Unity?)..
Para esta solución he aplicado el memtest que viene en el DVD 64bits de Fedora 16, con el que luego he instalado el nuevo sistema. Simplemente como conclusión, gracias memtest.

miércoles, 7 de diciembre de 2011

Una de humor

En ratos libres, además de cambiar de sistema operativo, también buceo en la red para reírme. Pero de estas dos no sé con cual me he reído más:
1. Una de Chuck Norris
Tomada de 9gag

2. Esta de Explorer (no me he podido resistir)

Tomada también de 9gag

No, no vamos a votar para saber cual nos gusta más. Es solo cuestión de reir.

PD. Y, sin darnos cuenta, hemos llegado a las 400 entradas. Nunca creí que pudiera saber tantas letras.

viernes, 2 de diciembre de 2011

Fedora sobre Ubuntu. Esta vez con fotos

Como digo en el título de esta entrada, esta vez estaba con el móvil sacando fotos a todo lo que se movía. No son de mucha calidad, pero nos aporta alguna información más sobre el error debido al directorio home de Ubuntu. Intenté repetir las mismas condiciones de ayer en otro ordenador (el ordenador principal de trabajo). Es un ordenador nuevecito, mucho más potente, y con la diferencia fundamental de que dispone de dos discos duros, unos para sistema más swap (Western Digital Raptor 10.000rpm de 34GB) y otro (WD Caviar Green 1TB) con una sola partición para home. Para no cambiar nada más, instalé Fedora 16 con el mismo CD Live i686 que usé ayer en el otro ordenador. la instalación se hizo de nuevo sobre las mismas particiones/discos de Ubuntu, y como se ve solo se formatea la partición sda1 de sistema


Después continuo en una instalación normal


hasta que termina correctamente.


A continuación, después del reinicio, comienza la configuración inicial


hasta que nos avisa, al igual que ayer, de que ya existe un directorio con el mismo nombre en home y tenemos que decidir si lo utilizaremos -y así haremos para recrear el mismo error- o si escogemos otro nombre de usuario. Al no ser así, cambia los atributos del directorio:


Nos permite arrancar


Pero nos aparece el mismo error


En la parte inferior del monitor surge un mensaje de error que pido que nos muestre


El problema es que no me lo enseña directamente. Sin embargo consigo tocando en la parte superior que me muestre la imagen de la aplicación Security alert (activa, como se ve en la parte superior del monitor) y la imagen de lo que está detrás del icono del error


Sin embargo no puedo activar los detalles, ya que realmente no he arrancado el sistema y solo es una imagen de lo que está detrás.
La instalación correcta la realicé simplemente cambiando el nombre del directorio desde el propio CD Live para no cambiar el nombre del usuario. Una vez montado el disco, se localiza en /media identificado por su UUID. Un simple mv nombre_antiguo nombre_nuevo y se instaló perfectamente. Luego se mueven los datos importantes de uno a otro (por ejemplo, en este ordenador está la copia con todos los correos de Thunderbird) y el sistema arranca y se configura de forma normal.


Parece como si el demonio de dbus no pudiera lanzar algo de lo que depende el arranque. Seguiré buscando información, pero yo pensaba que los ficheros icc eran de niveles de color.

Fedora sobre Ubuntu. Error al compartir home

Estoy en un cambio desde Ubuntu a Fedora. Después de instalar con éxito Fedora sobre Ubuntu en el portátil decidí cambiar el sistema también en uno de los ordenadores de trabajo. Decidí instalarlo directamente sobre la particiones de Ubuntu, al igual que había hecho con el portátil. Una inicial de sda1 para sistema (/), con formateo a ext4 y en la extendida sda5 en ext4 sin formatear para home (nombre de usuario idéntico) y sda6 swap. La instalación la realicé desde el CD Live i686 en unos minutos y permite el arranque y comienza la configuración. En un punto avisa de que ya existe un directorio idéntico al que va a generar para home pide permiso para utilizarlo como tal y cambiar sus permisos o si preferimos cambiar a otro. Autorizo el cambio de permisos (un par de minutos de espera) y ya llama a la pantalla de entrada. Sin embargo, al poner la contraseña y entrar salta un error (calidad baja de imagen sacada con el teléfono). Daba un mensaje del Asistente de problemas, y guardé la imagen (o eso me parecía a mi) pero luego no fui capaz de encontrarla, así que supongo que la guardó en RAM; de todas maneras, no explicaba la causa de lo que pasaba


Entonces hice un segundo intento; antes de la instalación borré desde el arranque del CDLive todo fichero de configuración y todos los directorios ocultos, dejando solo .mozilla y datos y luego instalé. El resultado fue el mismo. Finalmente instalé completamente de limpio formateando todo el disco y funcionó (estoy escribiendo en él). Entre las posibles causas para este error, hckorootx ha sugerido un posible cambio de la UUID de la partición que incluye el directorio home. Las UUID de las particiones cambian mediante un MD5 sobre la estructura de ficheros al reformatearla, pero como no se ha formateado, a lo mejor no coincidiría con la que Fedora ha calculado al instalar. Sin embargo, eso no pasó en el portátil. En él, al haber cambiado el nombre del usuario, cambio también el directorio, y el que tenía todas las configuraciones de ubuntu no fue utilizado en el arranque. Desde mi punto de vista, al instalar Fedora sobre Ubuntu debemos evitar usar el mismo directorio de usuario en home, ya que las "herencias" de Ubuntu no coinciden con los nuevos deseos de Fedora.