¡No a las patentes de Software!

stopsoftwarepatents.eu petition banner

martes, 9 de agosto de 2011

Configuración de Conky

Luego de bastante tiempo sin actualizar el blog, voy a poner mi configuración de Conky que tengo en el portátil (un HP ProBook 4520s).

He utilizado como punto de partida el ConkyWizard porque me ha gustado su disposición inicial de elementos y su gráfico de fondo (con los logos de Ubuntu). A partir de allí he ajustado los parámetros a mostrar.

Secciones a destacar:

En el gráfico de I/O de disco, he usado voffset para "subir" el valor instantáneo, de manera que quede el gráfico a la derecha y el texto en dos líneas a la izquierda. Si no, quedaría un texto y el gráfico en una línea y el valor instantáneo en la línea siguiente (por debajo del gráfico). Una imagen vale mas que mil palabras:
El código es:
${GOTO 36}${font Ubuntu:bold:size=9}${color0}Disks${font}${color}
${GOTO 36}I/O read:${GOTO 90}${diskiograph_read 20,150 008e00 ffb200 -t}
${GOTO 36}${voffset -20}${diskio_read}
${GOTO 36}I/O write:${GOTO 90}${diskiograph_write 20,150 008e00 ffb200 -t}
${GOTO 36}${voffset -20}${diskio_write}
Utilizo tres posibles interfaces de red: eth0 (ethernet cableada), wlan0 (wifi) o ppp0 (una 3G por USB). Como difícilmente tenga activas dos o mas a la vez, no me interesa que se muestren las que no están en uso. La dificultad vino porque la comprobación  if_up que hace Conky da siempre cierto para la eth0. De hecho, el sistema operativo tiene la interfaz en UP aunque no tenga el cable conectado. Afortunadamente he encontrado una opción de configuración de Conky que ajusta el "nivel" de exigencia para que la interfaz esté arriba: if_up_strictness.  De acuerdo a la documentación:
if_up_strictness: How strict should if_up be when testing an interface for being up? The value is one of up, link or address, to check for the interface being solely up, being up and having link or being up, having link and an assigned IP address.
Ajustando el parámetro a if_up_strictness link, puedo poner if_up delante de cada interfaz para que sólo muestre sus variables si está activa. Otra imagen (con la 3G en uso):
El problema es que queda una línea vacía para las secciones (interfaces) no mostradas, pero no es algo que me quite el sueño.

El código correspondiente es:
if_up_strictness link
[... ]
${GOTO 36}${font Ubuntu:bold:size=9}${color0}Network${font}${color}${if_gw}${GOTO 130}GW: ${gw_ip}${endif}
${if_up eth0}${GOTO 36}eth0:${GOTO 120}${addr eth0}
${GOTO 36}Up (${upspeedf eth0}):${GOTO 120}${upspeedgraph eth0 15,110 330099 cc0099 -t}
${GOTO 36}Down (${downspeedf eth0}):${GOTO 120}${downspeedgraph eth0 15,110 330099 cc0099 -t}${endif}
${if_up wlan0}${GOTO 36}wlan0:${GOTO 120}${addr wlan0}
${GOTO 60}$wireless_essid   $wireless_bitrate
${GOTO 60}${wireless_link_bar 10,140} $wireless_link_qual_perc %
${GOTO 36}Up (${upspeedf wlan0}):${GOTO 120}${upspeedgraph wlan0 15,110 330099 cc0099 -t}
${GOTO 36}Down (${downspeedf wlan0}):${GOTO 120}${downspeedgraph wlan0 15,110 330099 cc0099 -t}${endif}
${if_up ppp0}${GOTO 36}ppp0:${GOTO 120}${addr ppp0}
${GOTO 36}Up (${upspeedf ppp0}):${GOTO 120}${upspeedgraph ppp0 15,110 330099 cc0099 -t}
${GOTO 36}Down (${downspeedf ppp0}):${GOTO 120}${downspeedgraph ppp0 15,110 330099 cc0099 -t}
${GOTO 36}Total Up: ${totalup ppp0}  Total Down: ${totaldown ppp0}${endif}
Las otras secciones son bastante "estándar" y se pueden ver en el pantallazo general (donde se ve su transparencia y parte del fondo de escritorio):


El fichero completo de configuración se puede descargar aquí.

lunes, 30 de noviembre de 2009

Redirección de puertos con iptables

He querido habilitar la recepción de traps SNMP en el agente de un software de monitorización (Hyperic, muy recomendable) en Linux. Como el agente no se ejecuta como root no puede escuchar por el puerto 162/udp. En lugar de cambiar de usuario, he decidido redirigir todo lo que llega al 162 hacia el 1620, puerto no restringido. Además, para verificar que llegan traps, he habilitado una regla de LOG. Los comandos han sido:
iptables -t nat -A PREROUTING -p udp --dport 162 -j LOG
iptables -t nat -A PREROUTING -p udp --dport 162 -j REDIRECT --to-port 1620
Con esto veo en /var/log/kern.log lo que llega y luego se reenvía al puerto en que escucha el agente.

miércoles, 26 de noviembre de 2008

Error del "memory allocator" y los logs

Al intentar arrancar una instancia de LDAP daba un fallo y aparecía el siguiente mensaje en el fichero de log de errores:
[25/Nov/2008:16:40:25 +0100] - Fedora-Directory/1.0.1 B2005.342.161 starting up
[25/Nov/2008:16:40:25 +0100] - Detected Disorderly Shutdown last time Directory Server was running, recovering database.
[25/Nov/2008:16:40:28 +0100] memory allocator - cannot calloc 0 bytes; trying to allocate 0 or a negative number of bytes is not portable and gives different results on different platforms.
Luego de revisar el estado de la máquina y su memoria, desesperado por no conseguir encontrar la causa del problema, se me ocurrió buscar el mensaje en Google. Encontré un mensaje en el foro que decía que el error aparece cuando el fichero de control de rotación de logs estaba corrupto. En mi caso, el fichero access.rotationinfo tenía tamaño 0. Lo he borrado y ¡voilá! Al reiniciar, arranca correctamente.

martes, 27 de mayo de 2008

Migración a una instancia replicada

En este post trataré la migración de datos de una instancia LDAP (Fedora Directory Server) a otra replicada en Multi Master.

Requisitos:
  • Haber exportado los datos de la instancia origen y haber copiado las modificaciones sobre el schema (los ficheros 99user.ldif y 9?xxx.ldif de slapd-{instancia}/config/schema).
  • Haber copiado la configuración de los índices adicionales (si los hubiera). Esto se ve en la consola de administración, pestaña configuration rama "{máquina}/Data/sufijo/userRoot" y pestaña Indexes.
  • Haber creado la instancia destino, con los parámetros de configuración necesarios (memoria, ubicación de logs, etc.) y la replicación establecida. (Hay otro post con estos datos)
Procedimiento:
  • Una vez configuradas y arrancadas las instancias destino, se deben importar los datos. Se puede realizar desde la consola de administración de una de las instancias, que utiliza los mecanismos propios de LDAP y, en consecuencia, replica los datos en la otra instancia. Otra opción es utilizar el comando ldif2db (como root).
    • cd /opt/fedora-ds/slapd-instancia
    • ./stop-slapd
    • ./ldif2db -n userRoot -i /var/tmp/fichero.ldif
    • ./start-slapd
  • Llegado este punto, los datos están en una instancia. Desde la consola de administración, en la pestaña Configuration, rama "{máquina}/Replication/userRoot/'{acuerdo de replicación}'", se debe hacer clic con el botón derecho sobre el último elemento de la rama (el 'acuerdo' a la izquierda) y seleccionar "Initialize consumer". Esto desencadenará una replicación completa desde un nodo al otro.
  • Finalmente, queda recrear los índices adicionales (si los hubiera) desde la consola de administración. Lamentablemente se debe realizar a mano en las dos instancias (si alguien sabe como exportarlo, que me avise).
El comando ldif2db requiere acceso exclusivo a la base de datos del LDAP. Por eso hay que pararlo previamente (si no, sale un aviso y aborta). Es mucho mas rápido que el ldif2db.pl y que la consola de administración, que utilizan el protocolo LDAP.

La opción "Initialize consumer" realiza un borrado de datos del nodo consumidor (destino) antes de replicar. Como es una nueva instalación, nos da igual y es la opción mas rápida.

Los índices adicionales se mantienen en el fichero maestro de configuración: el dse.ldif. Es por esto que he optado por recrearlos manualmente. No se si habría problemas si copiara el fichero de una máquina a otra.

jueves, 20 de marzo de 2008

Convertir videos flv a xvid

Una buena utilidad de conversión es ffmpeg. Para no perder calidad, es recomendable mantener los parámetros del video, sólo cambiando el formato (codec). Para ver los datos del fichero original se puede ejecutar:
ffmpeg -i video1.flv
Sobre el final debe haber una sección con información similar a:
Input #0, flv, from 'video1.flv':
Duration: 00:12:36.8, start: 0.000000, bitrate: 56 kb/s
Stream #0.0: Video: flv, yuv420p, 320x240, 29.97 fps(r)
Stream #0.1: Audio: mp3, 22050 Hz, stereo, 56 kb/s
El comando a ejecutar entonces sería:
ffmpeg -i video1.flv -ab 56 -ar 22050 -b 500 -s 320x200 -vcodec xvid -acodec mp3 video.avi
Las opciones han sido:
  • -i video1.flv: fichero de entrada
  • -ab 56: audio bitrate (obtenido del video original)
  • -ar 22050: frecuencia de muestreo del audio (obtenido del video original)
  • -b 500: video bitrate (ciencia infusa) ;-)
  • -s 320x200: tamaño del video (obtenido del video original)
  • -vcodec xvid: codec a utilizar (el que se desee, se pueden ver los disponibles ejecutando ffmpeg -formats)
  • -acodec mp3: codec de audio (obtenido del video original)
  • video.avi: fichero de salida
Actualización:

Con el método anterior el vídeo resultante queda bastante "pixelado". He encontrado un mejor resultado ejecutando:
ffmpeg -i video1.flv -vcodec xvid -acodec mp3 video.avi
Se ve que de esta forma, el resto de parámetros se configura como el original.

Como todo el tema multimedia, hay que basarse mucho en el "prueba y error".

martes, 5 de febrero de 2008

Errores de sincronización entre réplicas de LDAP

Recientemente, el log de errores de dos instancias configuradas en Multi Master Replication mostraban lo siguiente:
[26/Jan/2008:00:00:00 +0100] NSMMReplicationPlugin - agmt="cn="Replication to MaquinaTal"" (maquinatal:389): Incremental protocol: event update_window_opened should not occur in state wait_for_changes
Este error (no grave) se da por la programación de los momentos para replicar. El script mmr.pl utilizado para crear la replicación (ver post mas antiguos en este blog) configura lo siguiente:
  • nsDS5ReplicaUpdateSchedule => "0000-2359 0123456"
Que significa que realizará las actualizaciones cada minuto durante todo el día ("0000-2359") de los siete de la semana ("0123456"). El error no se da si las dos réplicas están como "Always in sync", con lo que las actualizaciones se realizan en cuanto ocurran.
Este parámetro se puede configurar desde la consola del servidor o eliminando el atributo nsDS5ReplicaUpdateSchedule.

miércoles, 9 de enero de 2008

Añadir líneas con sed

Recientemente he tenido que añadir un nuevo "objectClass" a todos los objetos de una rama de un LDAP. Para ello he exportado la rama a un fichero LDIF y he ejecutado el siguiente comando (todo en la misma línea):
sed '/objectClass: inetOrgPerson/{G;s/$/objectClass: nuevosAtributosGrupo/;}' fichero.ldif > nuevo.ldif
Este comando busca la cadena "objectClass: inetOrgPerson" y agrega "objectClass: nuevosAtributosGrupo" a continuación en una nueva línea.

(Obtenido de http://www.student.northpark.edu/pemente/sed/sedfaq4.html)