1

[system@pc]$ nc -v -l 10000  | gzip -d > output.file

Some details about the arguments and tools:

• nc: the BSD netcat tool implementation. There exists a GNU implementation often refered as gnu-netcat or netcat-traditional that can be launched either using the nc command or the netcat one.
• -l: listen to incoming TCP transmissions by default bounded to the default localhost hostname. A bounding hostname can be specified after the port number
• -v: verbose output through stderr output stream
• 10000: the listening port
• gzip -d: the gunzip compressor, the option -d sets it in decompressing mode. Since it has no more arguments, the compressed stream is extracted from the pipe and sink to the stdout stream.
• > output.file: redirects stdout stream to the file output.file in current working directory.

Then in the client side:

1

[system@pc]$ cat file.input | gzip | nc -v -w 30 myserver.domain.net 10000

About non previously commented arguments and commands:

• cat file.input |: display file.input content through the standard output stream and redirect it throug pipe.
• gzip |: without commands, compress data stream received from pipe and displays it through the standard output stream. It then redirects this output through pipe.
• | nc -v: transmits raw TCP packages generated from content received from pipe and display verbosed information.
• -w 30: timeout. If the pipe input stream is idle for more than 30 seconds or no connection can be established in that time the process is terminated. If no value is specified, there’s no timeout.
• myserver.domain.net 10000: the destination host name or IP address is myserver.domain.net and the listening port is 10000

El problema que puede aparecer en este punto es que o no sabemos que es exactamente lo que se ha roto o simplemente no sabemos a que paquete pertenece el archivo que se queremos reinstalar. Para ello viene en nuestra ayuda dos opciones de RPM tremendamente útiles.

¿Qué se ha estropeado?

Imaginemos que leyendo a través de un log o de cualquier otra manera hemos averiguado que el problema está involucrado de alguna manera con la librería /usr/lib/awt-gen-aas/12345-2345-libAsd.so. El problema es que con un nombre como ese no tenemos manera de saber a que paquete pertenece. Para solucionar esto podemos hacer una query rpm sobre el archivo para conocer a que paquete pertenece de la siguiente manera, pudiéndonos devolver algo parecido a los siguiente:

[machine@user ~]$ rpm -qf /usr/lib/awt-gen-aas/12345-2345-libAsd.so
rhythmbox-2.90.1-17.git20110927.fc16.x86_64
[machine@user ~]$ _

Por fin sabemos que el paquete que falla es rhythmbox-2.90.1-17.git20110927.fc16.x86_64, que es Rhythmbox. La opción -q o --query especifica que queremos imprimir información sobre un paquete RPM y la opción -f o --file que queremos que se haga sobre un archivo

El comportamiento por defecto es imprimir el nombre del paquete consultado, pero puede configurarse la cadena de salida en base a muchísimas opciones con la opción ----queryformat.

¿Por qué se ha roto?

Una vez localizado el paquete conflictivo, estamos un pasito más cerca de solucionar el problema. Quizás antes de reinstalar todo el paquete nos puede interesar comprobar qué es exactamente lo que se ha estropeado por si tuviese fácil solución. En ocasiones, por ejemplo, el error puede deberse a un archivo que cambió de privilegios o que cambio de usuario o grupo, en cuyo caso la solución es bastante sencilla.

Vamos entonces usar la opción -V de RPM para comprobar si algún elemento del paquete rhythmbox-2.90.1-17.git20110927.fc16.x86_64 está fallando. Algo parecido a lo siguiente podría salir:

[machine@user ~]$ rpm -V 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64'
S........  c /etc/rhythmboc.conf
.M.......  d /usr/share/doc/rhythmbox-2.90.1/help
..5......  g /var/log/rhythmbox.log
...D.....  l /usr/share/doc/rhythmbox-2.90.1/LICENSE
....L....  r /usr/share/doc/rhythmbox-2.90.1/README
.....UG..    /usr/share/rhythmbox/library1.so
.......T.    /usr/share/rhythmbox/library2.so
........P    /usr/share/rhythmbox/library3.so
SM5DLUGTP    /usr/share/rhythmbox/library4.so
missing      /usr/share/rhythmbox/library5.so
[machine@user ~]$ _

La opción -V o --verify comprueba el paquete comparando los archivos de éste cuando estaba recién instalado con el estado de los archivos actualmente en busca de diferencias. Aquellos archivos con conflictos potenciales son mostrados y el resto ignorados

La información se muestra en tres columas:

• La primera columna es un conjunto de 0 a 9 caracteres que señalan las divergencias con el archivo original encontradas. Sus significados son:
  • S: difiere el tamaño del archivo con respecto al original
  • M: difieren los permisos de acceso al archivo con respecto al original
  • 5: difiere la suma de verificación MD5 con respecto al original
  • D: difieren los números mayor y menor del dispositivo/driver con respecto al original
  • L: difiere la ruta del enlace simbólico relacionado al archivo original
  • U: difiere el usuario propietario del archivo con respecto al original
  • G: difiere el grupo propietario del archivo con respecto al original
  • T: la fecha de modificación del archivo con respecto al original
  • P: difiere alguna de las dependencias dependencias del archivo con respecto al original
  • missing: el archivo ha desaparecido del sistema de archivos
• La siguiente columna nos informa de qué tipo fue marcado el archivo en el paquete original, las opciones son:
  • vacío: el archivo es un fichero regular
  • c: el archivo es un fichero de configuración
  • g: el archivo es in fichero fantasma o ghost, esto es, pertenecen al paquete pero no venían en este o estaban destinado a ser modificados. Un ejemplo de este tipo de archivos son los ficheros de log
  • l: el archivo es un fichero de texto con el contenido de la licencia
  • r: el archivo es un fichero de texto con el README del paquete

Existe también una opción muy interesante para extender la acción de la mayoría de los comandos de RPM a todos los paquetes instalados con el modificador -a. Esto nos permite hacer cosas tan molonas como obtener todos los archivos de todos los paquetes que tienen algun problema específico usando grep. Por ejemplo, podemos obtener todos archivos de todos los paquetes del sistema que fallan en la suma md5 con el siguiente comando:

[machine@user ~]$ rpm -Va|grep ^..5

Vale, ¡Pero esto sigue sin funcionar!

Hemos revisado todos los ficheros a conciencia, nos hemos hartado y hemos decidido reinstalar el paquete entero. Tenemos varias alternativas para borrar los paquetes o reinstalarlos automáticamente dependiendo de la distribución, pero la opción multiplataforma es usando el modificador -e de rpm:

[machine@user ~]$ rpm -e 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64'

El modificador -e desinstala un paquete de manera segura, hasta aquí nada del otro mundo. Lo interesante del funcionamiento de esta opción es que los archivos de configuración que desde la instalación del paquete fueron modificados no serán borrados, sino que seran renombrados en el mismo directorio con las extensiones .rpmorig, .rpmsave o similar. De esta manera, cuando reinstalemos de nuevo el paquete con nuestro sistema de gestión de repositorios preferido tendremos tanto el archivo antiguo como el nuevo para realizar la instalación.

El último paso es instalar el paquete de nuevo. Si lo hacemos desde un archivo .rpm, sería tan sencillo como lo que sigue:

[machine@user ~]$ rpm -i 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64.rpm'

O en Fedora desde repositorios:

[machine@user ~]$ yum install 'rhythmbox-2.90.1-17.git20110927.fc16.x86_64'