Cortes intermitentes de red

En uno de los lugares donde trabajo estamos "sufriendo" una serie de cortes intermitentes y secuenciales de la red. Para empeorar las cosas, mi trabajo en ese lugar de basa fundamentalmente de manejo de herramientas en la red, con lo cual me tiene bastante frustrado. Para demostrar lo que digo, solo hay que ver el resultado del monitor (Véase en la parte inferior el "Histórico de la red")

Bajo estas circunstancias estamos muy frecuentemente bajo el aviso de los navegadores de "Resolviendo la dirección de..." y a esperar. A mi me pasa de forma continua, y soy el que más se queja. No sé si es por que solo me afecta a mi, por que soy el que más usa la red, por que soy el más quisquilloso (o protestón) o por lo que sea, pero tengo que encontrarle solución. Como la comunicación de este edificio es accesoria a otro que está cerca, puede que sea ahí donde está el problema. Empezaré por averiguar que les pasa a los demás de mi planta y luego las otras. Mal momento para ello, por que la gente empieza las vacaciones.

Búsqueda de ficheros a través de una cadena de texto interna. Otra de terminal

Hoy estaba buscando datos antiguos en mi directorio Documentos. Es bastante complejo, por que ese directorio contiene lo que viene a ser la copia de todo mi trabajo desde 1990. En conjunto contiene 172612 ficheros -algunos muy repetidos con pequeñas variaciones- en 115,6GB, comprobado con filelight.

Yo siempre he usado kdirstat, pero en Ubuntu 11.04 no está disponible en los repositorios y me he pasado a este nuevo -para mi- mapa de disco duro, que no está nada mal. Bueno, no nos dispersemos. Como es natural es muy difícil encontrar un fichero ahí, sobre todo cuando no recordamos como se llama. Decidí buscarlo a través de una búsqueda de texto interno; mediante una cadena que estaba seguro que tenían que contener, pude encontrar 5 copias distintas para poder extraer la información deseada. La orden final en terminal, basándonos finalmente en algunos comentarios realizados a este blog, fue:

find /ruta/ -type f -exec grep -il CADENA {}\;

aunque se logran los mismos resultados con

find /ruta/ -type f | xargs grep -i CADENA

Es conveniente estudiar los man de los diferentes comandos (man find y man grep) para entender que hace cada cosa. Realmente había dado muchas ordenes basándome es mis limitados conocimientos de terminal, pero lo que hacía que no pudiera encontrar los ficheros era la falta de -i, que hace que no se diferencien mayúsculas y minúsculas (man grep: "Ignore case distinctions in both the PATTERN and the input files"). Esos ficheros estaban escritos en mi época oscura de Windows y tenía cierta tendencia a llamar a las variables con mayúscula inicial, y por ello me fallaba siempre mi cadena de búsqueda.

Ubuntu 11.04 y el formateo en NTFS de los discos duros

He tenido un nuevo "poltergeist" en el formateo en NTFS de un disco duro. En este caso he "intentado" formatear un Western Digital Caviar Green de 2TB en una caja Conceptronics para discos SATA. El disco es de la misma marca y modelo que utilizo en mi ordenador principal como home. El disco que hace de home fue formateado en la instalación de 11.04 en ext4 sin ningún problema. Modelos similares WD Caviar Green de 1TB y 1,5TB formateados a NTFS los uso habitualmente en cajas Conceptronics idénticas a la del disco en cuestión para almacenar material y poder disponer de él en Linux, en Windows y en WD TV Player. Para formatearlo, he seguido mi rutina habitual. Monto el disco ("OEM", tomado de una caja que trae un montón iguales y sin formato) en una caja Conceptronics, lo detecto con gparted y configuro un formateo en NTFS; lo vuelvo a montar con Palimpsest y empiezo la copia de los ficheros; sorprendentemente (no tanto, por que es la segunda vez que me pasa), la velocidad de copia prevista es de 200 a 300kb por segundo, con lo que nos amenaza con miles de horas de copia. Visto el resultado tras varios minutos sin aumento de la velocidad, lo desmonto e intento formatear desde Palimpsest, aun suponiendo que el efecto será el mismo, ya que recurrirá a los mismos paquetes que gparted. Sorprendentemente, se niega a formatear ya que dice que el "daemon" está capturado. Directamente reinicio el equipo y vuelvo a intentarlo con palimpsest sin pasar por gparted, pero me dice lo mismo (¿qué error es este?). Por tanto, sigo las indicaciones de hckorootx en los comentarios de la entrada anterior sobre discos duros y de la entrada que realizó a partir de eso en nosinmiubuntu, y en terminal defino el disco con fdisk y luego lo formateo con mkntfs. Mejor dicho, lo intento, por que el equipo se bloquea completamente sin respuesta a atajos de teclado de reinicio gráfico (ni el moderno en Ubuntu AltGr+ImpPant+K ni el tradicional Ctrl+Alt+Backspace) ni tampoco a los atajos AltGr+ImpPant+REISUO. Otro factor que me sorprendió, y que debemos tener en cuenta sobre un posible bug, fue que las características del disco varían según el formateo con gparted o fdisk. Por desgracia, cuando hacemos estas cosas no nos paramos a guardar los resultados. Como lo haré próximamente, tengo que grabar las lecturas de los discos. Por supuesto, podemos culpar al disco o a la caja, pero le hice un formateo rápido en Windows XP (mismo disco, misma caja) y lo puse a copiar en Ubuntu y ya lo hace a una velocidad razonable (18-19MB/s). Esto nunca me había pasado antes, y nunca he tenido que formatear discos en NTFS en Windows desde que uso Ubuntu 7.10. Algun bug tiene que estar ahí dentro, pero no he encontrado nada parecido en la red y no sé como definir lo que está pasando.

Hardware: PS3 y Plextor

Tengo dos problemas de hardware. El primero, la PS3 nuevecita se recalienta a los 5 minutos de encenderla. Hasta ahora solo había cambiado los firmwares y luego la apagaba, así que nunca estuvo mucho tiempo encendida. Pero el otro día los peques ya quisieron jugar y al cargar el juego ya avisó de que estaba sobrecalentado y se apaga, sin volver a encender en un tiempo largo (queda el piloto rojo parpadeando). Por lo que he visto en la red es un fallo bastante frecuente en los modelos 40 (este) y 60, ya que no funcionan los ventiladores recién salidos de fábrica. Bien podía SONY hacer control de calidad y comprobar el funcionamiento, por ejemplo teniéndolas encendidas 12 horas y comprobando que no se calientan pero, quien hace hoy control de calidad salvo el consumidor con sus reclamaciones. A devolver y que me den una nueva, que tiene 1 mes y medio. También, según he visto en la red, hasta tengo suerte, por que me avisa, aunque sea de forma inmisericorde, ya que otras directamente ponen luz amarilla -"señal de muerte"- y no vuelven a arrancar.
El segundo problema es solo de espacio. Tengo una capturadora de vídeo Plextor PX-TV402U con la que he digitalizado cientos de vídeos en los años 2005 y 2006. Sin embargo desde entonces no la he vuelto a usar, salvo para digitalizar algún sonido. Además, funciona en Windows XP utilizando PlexTools (en teoría, hay drivers para Linux, pero nunca me he propuesto intentarlo). En resumen, no la voy a usar más, ya que no me quedan vídeos que digitalizar, así que si alguien quiere usarla, está a su disposición. Si no, tendré que subastarla en eBAY, cosa que jamás he hecho. La he empaquetado con todos sus cables y mando a distancia y me la he sacado de encima, por que ocupa bastante y genera una gran cantidad de cables. Por cierto, funciona perfectamente, "like new", ya que es Plextor (recuerdo los lectores de CDs Plextor, mi grabadora Yamaha, ambos SCSI, y los copieteos masivos que hacía con ellos. Que tiempos aquellos, y que calidad de hardware, pero esa es otra historia).

Comentarios bloqueados

No, yo no bloqueo los comentarios. Los eliminaría si son malsonantes, pero hasta ahora nunca he tenido que borrar mensajes en este blog (sí en otro muy diferente a este). Pues resulta que en la anterior entrada sobre formateo y discos duros, nuestro amigo y compañero hckorootx nos estaba dando información bastante útil sobre el formateo en terminal y sobre el tipo de disco que estaba dentro de la carcasa de un Carbon Packard Bell. Resulta que nos incluía un enlace a un documento PDF (ftp://ftp.packardbell.com/pub/itemnr_old/CS036A00/Grafite_and_Carbon_Disassembly_Manual.pdf), pero lo había intentado antes dando la dirección obtenida de la búsqueda a través de Google, que viene siendo http://www.google.com seguido de 3 líneas de caracteres seguidos. Nos lo envió al menos 4 veces y ninguna pudo verse en el blog, aunque yo las recibía por correo electrónico. O sea, que google no deja que publiquemos sus búsquedas (aunque por lo visto bing sí puede). El enlace bloqueador es (http://www.google.com/url?sa=t&source=web&cd=3&ved=0CC0QFjAC&url=ftp%3A%2F%2Fftp.packardbell.com%2Fpub%2Fitemnr_old%2FCS036A00%2FGrafite_and_Carbon_Disassembly_Manual.pdf&rct=j&q=carbon%20packard%20bell%20pdf&ei=e2EcTuOwGc3m-gbV1P3QCA&usg=AFQjCNEFhAAY2a4eoallY5kx9Vc7Gn03Yg&sig2=JFERb0aTDvQyOPD_FedKeA&cad=rja); a ver si a mi sí me deja. Como podemos ver, el resultado de picar en el es el mismo.

Formateo de discos duros

Un compañero me ha pasado un disco duro para que le copiara unos ficheros (¿donde están los diskettes de antes? con 600 arreglábamos el asunto). Al ver el disco me doy cuenta de que esta en formato FAT32, es decir, inutilizabe (no admite ficheros de más de 4GB).
A través de gparted se lo pasé mediante formateo rápido a NTFS, pero resulta que el disco no funcionaba bien (nautilus calculaba 900 horas para copiar el directorio). La única solución fue un formateo completo, y así funcionó razonablemente (900GB en 9 horas).
Sí iscario, lo hice con un ordenador con Windows, ya que no sé como decirle a gparted que haga un formateo completo (unas cuantas horas que tardó el tal Windows) y no sabía que tamaño de cluster darle al disco; mkfs.ntfs asigna por defecto 4096, que en los Western Digital está bien, pero en este disco no estaba seguro, así que le dejé a Windows XP que decidiera por si mismo. Además, como en casa tengo todavía un ordenador con Windows XP, era la forma más fácil y rápida. De todas maneras, tengo usar más el terminal.

Ficheros rev en compresiones multivolumen rar

Siempre me había preguntado para que servían los ficheros rev en las compresiones rar multivolumen, ya que, como sabéis los que hayáis bajado este tipo de ficheros comprimidos y divididos, son totalmente prescindibles.
O eso pensaba yo. En una compresión dividida en 65 partes más 3 rev (a quien queremos engañar, una película en formato matroska en descarga directa) fui incapaz de conseguir el paquete 16. Y ahí viene el interés de los ficheros rev, llamados en la página rarlab como volúmenes de recuperación; dice:

"Recovery volumes or .rev files are special files which can be created by WinRAR/RAR and allow the reconstruction of missing and damaged files in a volume set..."

Es decir, podemos reconstruir un paquete perdido. De hecho, podemos reconstruir tantos paquetes como volúmenes de recuperación tengamos. Dicho y hecho. En una máquina virtual de Windows (grande, por que el volumen a trabajar era alrededor de 20GB), con todos los ficheros rar y rev en el mismo directorio, con una versión de prueba de winrar v.4, mediante reparar y llamando al primer rev, el compresor ha sido capaz de generar el paquete 16 al no encontrarlo. Le llevó alrededor de 45 minutos. Ahora, después de haber estudiado mejor el paquete rar (inicialmente me equivocaba de comando), creo que no es necesario usar Windows. Si instalamos temporalmente el paquete rar
$ sudo apt-get install rar
si hacemos
$ man rar
y nos fijamos en los últimos comandos ...

vemos que mediante el comando rc sería posible.

rar rc paquete16.rar

Según algunos blogs y foros, estaba intentándolo mediante comando r, y no me funcionaba, pero después de leer la página oficial rarlab y haberme fijado más en man rar, supongo que con rc funcionará. Quizá fuera recomendable acortar los nombres de los paquetes y volumenes de recuperación, sin caracteres extraños, por lo que digo después. Luego, una vez reconstruido el/los paquete/s perdido o dañado, también sería recomendable eliminar el paquete rar; en primer lugar, es shareware; segundo, el sistema de manejo de caracteres que utiliza hace que muchas veces no sea capaz de reconocer caracteres extraños, como la ñ (a mi ya me ha pasado hoy mismo) y los administradores gráficos de descompresión (file roller o xarchiver), con rar instalado, presentan problemas con determinados ficheros con nombres que lleven caracteres fuera de los ascii tradicionales (típico subtítulo que termina en español; extraemos el ingles pero no reconoce el español, que para el es espaALGORAROol).

¿Explorer en Linux?

Como decía hace unos días, he tenido que activar un proxy para acceder a ciertas características de mi Universidad. Después de muchos problemas en los navegadores de Linux, decidí configurar un Explorer en una máquina virtual de Windows XP. Alguna vez tenía que ser la primera y por fin voy a usar Explorer. Sin embargo, en ocasiones pasan cosas tan curiosas como esta...

Parece que Explorer está funcionando directamente en Linux. Simplemente estaba probando las diferentes formas de configurar la ventana de VirtualBox y en un momento determinado quedó así. Podemos reir un rato. Solo falta poner el icono de Explorer en Unity para que quedara perfecto.

Firefox y la asociación a aMule

Decidí instalar Ubuntu 11.04 en mi ordenador principal (POR FIN) completamente de cero, sin mantener el directorio home, para evitar acúmulo de errores de configuraciones previas. Además, otra razón era instalar Firefox completamente limpio, evitando las decenas de extensiones que llevo acumulando desde Windows (el directorio donde Firefox lo guarda casi todo, .mozilla/firefox/xxxxxxxx.default me acompaña desde hace mucho tiempo, ya que lo he mantenido a lo largo del tiempo en Windows y luego en Linux). El problema es que de repente ya no se asociaba directamente un click sobre un hash ed2k en Firefox y su translación a aMule.

Por supuesto se puede copiar y pegar, pero es algo muy incómodo, aparte de que yo suelo trabajar en Firefox en el Área de trabajo 1 y aMule suele estar en el área 8 (cada uno tiene sus manías). Como es natural, revisando en la red, lo primero que se ve es que tenemos que tener instalados amule-gnome-support para la manipulación de enlaces ed2k y amule-utils, que como se ve, ya estaban:

En general, un montón de blogs y foros (entre ellos el anterior, o este, o este otro, señalan como solución la siguiente:
- Abrir Firefox y teclear en la barra de direcciones about:config
- En la lista con el botón derecho seleccionar nuevo - lógico y añadir  network.protocol-handler.external.ed2k, al que se le dará valor true
- De nuevo botón derecho, esta vez nuevo - cadena y se añade network.protocol-handler.app.ed2k, con valor /usr/bin/ed2k
- Reiniciar Firefox
En Ubuntu 11.04 con Firefox 5.0 me volvió a dar una ventana de error como la anterior. Sin embargo, en Ubuntu 10.10 y Firefox 4.01 ya me envió a una ventana donde podemos señalar la aplicación que utilizará el hash ed2k

Ahí, en elegir, buscaremos /usr/bin/ed2k, sin olvidad marcar la casilla de Recordar mi elec... para no tener que hacerlo cada vez. Sin embargo, para llegar hasta esta ventana en Firefox 5.0 en 11.04 he tenido que añadir en about:config una línea más, como indica aquí:
- botón derecho - nuevo - lógico, network.protocol-handler.expose.ed2k, con valor de "falso". Después de esto ya me ha salido la ventana anterior y he podido generar la asociación Firefox-aMule.
Comentando estos problemas con hckorootx, señaló, después de haber estudiado el asunto, que about:config queda registrado al cerrar Firefox en el fichero prefs.js. Pensando en la posible edición manual mediante editor de texto sin pasar por about:config, las líneas nuevas encontradas en ese fichero tras la comparación con kdiff3 han sido (como se ve se alteran otros valores debido simplemente por el uso normal de Firefox):

Esta imagen es la comparación del fichero prefs.js (antes de instalar nada, tras la aplicación de las líneas en about:config y el tercero tras asociar Firefox con ed2k) con Ubuntu 10.10 y Firefox 4.01, por lo que no fue necesario aplicar la última acción que señalé arriba. En el ordenador con 11.04 y Firefox 5.0, ese fichero muestra una línea más que podemos ver en esta imagen

hckorootx también señaló la idea de que Aplicaciones (dentro de las preferencias de Firefox), donde queda registrada la asociación con ed2k

se registra en el fichero mimeTypes.rdf. La diferencia tras lograr la asociación Firefox-aMule fue, analizada con kdiff3

Yo lo seguiré arreglando a través de about:config. Para gente valiente como tú, hckorootx, que además sabéis más de programación y terminal, ahí tenéis las diferencias. Espero que sirva de ayuda para los que se encuentren de nuevo con este problema y no se acuerden como lo habían solucionado (yo no me acordaba de nada en absoluto).

Menos mal que nos teníamos Dropbox

Empecemos con una pequeña introducción o "Historia da Arte", como dicen los proyectos. Respecto a mi, son un individuo que trabaja mucho con la herramienta informática y en diferentes lugares, por lo que suelo tener al menos 3 ordenadores encendidos las 24 horas. A ellos les podemos sumar 2 más, un portatil y un netbook, que suelo utilizar solo en los desplazamientos de más de un día. La sincronización del trabajo en los 5 ordenadores la realizo a través de Dropbox, directamente en cuatro de ellos, en los que está instalado, o a través de la conexión a la página Dropbox en el netbook. Respecto al ambiente de trabajo, puedo decir que uno de los ordenadores está situado en un sitio donde la "estabilidad" energética es, digamos, "variable", por lo que dispone de un SAI que genera estabilidad y un cuarto de hora de mantenimiento sin alimentación externa.
Estado al día de ayer
En un momento determinado durante la mañana, en el despacho energéticamente inestable se produjo un estado de irregularidad que llevó al apagado de todos los equipos; el problema es que yo estaba en otro ordenador a kilómetros de distancia, trabajando con un documento en particular, protagonista de esta historia. Debido a alguna coincidencia estilo Murphy, debí guardar la versión final del fichero cuando se estaba apagando el otro PC; el resultado final fue un archivo de 0 bites, con lo que el trabajo de varios días se había perdido. En condiciones normales debería tener copia de seguridad, pero como trabajo directamente sobre Dropbox, no suelo copiar ese directorio, salvo en las copias mayores.
Resultado
Todo parecía indicar que habría que escribir de nuevo el documento (o pasar por tesseract los papeles impresos con las últimas correcciones que tenía en la mesa pero...
pero Dropbox conserva las versiones anteriores de los documentos, con lo cual restauré la última con el texto final y listo.

A pesar de los problemas de los últimos días y los posibles agujeros de seguridad, yo al menos puedo dar gracias a Dropbox. Estoy tentado de probar también Wuala y SpiderOak, por que en la variedad está el gusto, pero gracias de nuevo, Dropbox.