Máquina Virtual de VMware cambia de hora luego de arranque (reinicio)

Fue así:

Tenía una máquina virtual que cada vez que arrancaba cambiaba la hora. En los logs no había información que indicara de donde provenía el cambio de hora así que revisé la configuración regional, la hora del BIOS de la máquina virtual, servidores NTP configurados y no nada con la respuesta.

Lo que ignoraba es que una vez que se instalan las vmware tools estas traen una opción para sincronizar la hora entre el guest host (máquiva virtual) y el anfitrión (bare metal donde corre el hipervisor).

En este caso el anfitrión es un esxi 5.5 y con el vsphere se cambia la configuración en NTP Servers: “Configuration” ->”Time Configuration” y acá podés ajustar la hora o detener el NTP.

Ventilador acelerado después de suspensión en portátil HP con kernel 3.11.10-21-desktop

Después de estar suspendida mi portátil acelera los ventiladores causando bastante ruido.

Luego de un tiempo ha empezado a interferir con el correcto funcionamiento de la tarjeta de red inalámbrica y el teclado.

Me encontré con una solución temporal para después de cada suspensión en los foros de arch linux:

for i in {1..15}; do echo 0 > /sys/class/thermal/cooling_device$i/cur_state; done

glibc incompatible con bash después de actualizar

El amigo de un amigo actualizó su versión de bash para superar la vulnerabilidad conocida como shellshock en openSUSE 12.3:

zypper update bash

Luego de la actualización empezó a obtener mensajes de error:

Target initialization failed:
rpmdb2solv -r ‘/’ -p ‘/etc/products.d’  > ‘/var/cache/zypp/solv/@System/solvBx3cgH’
/bin/sh: /lib/libc.so.6: version `GLIBC_2.15′ not found (required by /bin/sh)

Puedo intuir que la versión de bash no encontraba compatibilidad con la versión de Libc instalada. No suena lógico que teniendo una dependencia esta no se actualice durante el zypper up. Pero bueno, yendo al grano.

Estaba en una situación en la que no podía actualizar el resto de paquetes porque estos usaban bash y bash no estaba ejecutandose correctamente por la incompabilidad. zypper, yast, export, setenv no podían ser ejecutados.

La solución fue descargar glibc-2.15-22.9.1.i686.rpm e instalarlo usando –replacefiles para que omitiera conflictos y reemplazara los paquetes por los nuevos:

rpm -ivh –replacefiles glibc-2.15-22.9.1.i686.rpm

Nombre personalizado de grabaciones en asterisk-cdr-viewer

Por defecto asterisk-cdr-viewer usa el UNIQUEID de cada llamada como el nombre del archivo a buscar, esto para ofrecer la descarga de las grabaciones.

Para habilitar esta funcionalidad seguimos los siguientes pasos:

1. Como indica el ReadMe editamos el archivo config.inc.php para darle un valor acorde con nuestra configuracion a las variables $system_monitor_dir y $system_audio_format.
2. Grabar usando el UNIQUEID como nombre de archivo o usar el nombre personalizado en la funcion formatFiles.

El UNIQUEID resulta poco legible para identificar fechas de llamadas si deseamos manipularlas en grandes cantidades o con expresiones regulares, por ejemplo, cuando deseamos respaldar o borrar grabaciones de llamadas pasadas que nos ocupen mucho espacio en disco.

Por ello es preferible usar el formato propio y cambiar el valor de la cadena, en mi caso el valor fue:

$recorded_file = ‘Entrante_’.str_replace(‘ ‘,’_’,str_replace(array(‘-‘,':’),”,$row[‘calldate’])).’-‘.$row[‘src’].’-Ext_’.substr($row[‘dst’],-4);

“Booting from local disk… Boot failed: press a key to retry” con una controladora B120i de por medio

Últimamente me las encontré con la frustrante experiencia de querer usar el RAID por hardware de una tarjeta controladora B120i usando openSuSE y otras distros. Lo que me parecía más extraño de todo el caso es que configurando el arreglo en el ACU (Array Configuration Utility de HP) el instalador seguía viendo los discos por separado.

Me indagué con la documentación de HP y se requería deshabilitar IOMMU en el BIOS, cargar un driver (citado como DUD image) durante la instalación de la distro y únicamente estaba soportado SLES, RHEL y VMWARE en los sistemas operativos linux.

Rescatando un RAID 5

Esta semana, y por primera vez, me encontré con un arreglo de discos fallido. Sabía que ese día tenía que llegar, temía con que pasara pero a fin de cuentas ya me encontraba en esa situación.
Se trataba de un RAID 5 con 4 discos de 1TB de una NAS Seagate BlackArmor 440/420. Según mi checklist mental el primer paso era identificar cual disco había fallado, luego reemplazarlo por uno idéntico (seagate hace incapie en que deben usarse únicamente discos fabricados por ellos en el equipo), realizar algún procedimiento de reconstrucción de RAID y listo.
Para mi sorpresa todos los discos tenían sus tablas de particiones correctas y pasan el health check del mismo NAS.
Me puse a investigar y me encontré con que era un error recurrente en ese modelo y que como primer paso recomendaban hacer un upgrade del firmware. Actualicé manualmente al 4000.1411 pero el mensaje de error no varió: “Volume not found”.

FLISOL 2014 Nicaragua

http://flisol.info/FLISOL2014/Nicaragua