Encuentro Alternativo

Hoy me tope con un error a nivel de resolución de nombres en un servidor RHEL 5.5 que administro, en particular al tratar de correr yum update saltaba este error:

[Errno 4] IOError: ‘Temporary failure in name resolution’

Loaded plugins: dellsysid, rhnplugin, security
There was an error communicating with RHN.
RHN support will be disabled.
Error communicating with server. The message was:
Temporary failure in name resolution
http://linux.dell.com/repo/hardware/latest/platform_independent/rh50_64/repodata/repomd.xml: 
[Errno 4] IOError: 'Temporary failure in name resolution'
Trying other mirror.
http://linux.dell.com/repo/hardware/latest/system.ven_0x1028.dev_0x02a5/rh50_64/repodata/repomd.xml: 
[Errno 4] IOError: 'Temporary failure in name resolution'
Trying other mirror.
http://www.jasonlitka.com/media/EL5Server/x86_64/repodata/repomd.xml: [Errno 4] IOError:
Trying other mirror.

El problema era que el puerto 53 UDP de salida necesita estar abierto para resolver el nombre del repo.
Solución: abrir el puerto en nuestro firewall, o bajar el firewall momentáneamente

Hoy me encontré con este error en un servidor RHEL 5.5, al parecer el paquete gzip generaba un fallo al intentar actualizarse usando yum update:

Updating       : gzip
Error unpacking rpm package gzip-1.3.5-11.el5_4.1.i386
error: unpacking of archive failed on file /bin/gunzip: cpio: rename
 
Failed:
gzip.i386 0:1.3.5-11.el5_4.1

El problema, al menos en mi caso, radicaba en que el archivo /bin/gunzip tenía activado el caracter de inmutabilidad, haciéndolo resistente a cualquier cambio.

[root@li28.server.com:~]lsattr /bin/gunzip
----i-------- /bin/gunzip

Para solucionarlo, quitamos la propiedad inmutable, corremos yum update y problema arreglado:

[root@li28.server.com:~]chattr -i /bin/gunzip

[root@li28.server.com:~]yum update gzip

Running Transaction
 Updating       : gzip
 Cleanup        : gzip  
 
Complete!

Curioso error encontré al instalar Fedora 11 sobre una notebook del trabajo, la notebook es una Acer Aspire 9802AWKMI.

Al parecer Fedora 11 trae por defecto el uso de Ext4 como sistema de archivos, el programa de instalación (Anaconda) me pedía que formateara como Ext4, pero al formatear me decía que la partición boot tenía que ir en Ext3 con este error:

Your partition does not match the live image you are installing from. It must be formatted as ext4

La solución más práctica que se me ocurrió en ese momento fue esta:

1.- Crear una partición primaria formateada con ext3 para montar /boot
2.- Crear la otra partición formateada con Ext4 para la raíz del sistema /

Enjoy

Hace unos días me proponía a actualizar un sistema RHEL 5.x y me vi con este mensaje:

[root@server ~]# yum check-update
Loaded plugins: rhnplugin, security
There was an error communicating with RHN.
RHN channel support will be disabled.
Error communicating with server. The message was:

Error Message:
RHN Proxy could not successfully connect its RHN parent. Please contact your system administrator.
Error Class Code: 1000
Error Class Info: RHN Proxy error.
Explanation:
An error has occurred while processing your request. If this problem
persists please enter a bug report at bugzilla.redhat.com.
If you choose to submit the bug report, please be sure to include
details of what you were trying to do when this error occurred and
details on how to reproduce this problem.

Luego de investigar y leer, mucha gente decía que era el satélite de la RHN que realizaba sus backups a ciertas horas, que esperara un par de horas y volviera a intentarlo. Y efectivamente fué así, esperé 1 hora y en todos los servidores ya estaba funcional de forma normal, así que vamos a pensar qu esi, que bajaba el servicio para realizar backups

Yum: [Errno -1] Metadata file does not match checksum

Este es un error bastante común en servidores RHE 5 o CentOS que usan el manejador de paquetes Yum, hoy al intentar actualizar algunos servidores me encontré con casos aislados que presentaban este error. Luego de investigar un rato pude arreglarlo, solamente había que correr:

yum clean all

Sin embargo, si eso no soluciona el problema recomiendo correr:

yum clean metadata dbacache headers

Eso debería encargarse de arreglarlo