Deepest Sender y el problema con las fechas en blogger

He estado buscando más usuarios con el mismo problema que yo con Deepest Sender + blogger + fechas, y finalmente he encontrado este post que explicaba cómo solucionarlo. Parece que en la siguiente versión, aparecerá ya solucionado. La idea:

1. Descargar a disco la extensión "deepest sender-0.8.0-firefox+sm.xpi".
2. Descomprimir con file-roller el fichero a un directorio temporal.
3. Descomprimir el fichero jar con el código (he tenido que abrir una terminal, aún no se hacerlo desde GNOME) y ejecutar lo siguiente:

   cd ~/prueba/chrome
   mkdir jar
   cd jar
   /opt/jdk1.5.0/bin/jar xvf ../deepestsender.jar

4. Editar el fichero ~/prueba/chrome/jar/content/protocols/atom.js y en la línea 63 cambiar this.date.toISO8601String(4); por this.date.toISO8601String(5);.
   
5. Lo siguiente es rehacer lo que acaba de deshacer:

   cd ~/prueba/chrome/jar
   rm -f ../deepestsender.jar
   /opt/jdk1.5.0/bin/jar cvf ../deepestsender.jar * 
   cd ..
   rm -fr jar

6. Luego con file-roller he vuelto a crear un fichero ZIP con el contenido de la carpeta ~/prueba/, y después le he cambiado la extensión para renombrarlo a deepest_sender-0.8.0-firefox+sm-modificado.xpi.
   

Esta entrada ya está publicada directamente con Deepest Sender que he modificado, y lo he dejado en mi cuenta de freedrive.

Deepest Sender como editor de blogs

Anoche me quedé desilusionado cuando descubrí que BloGTK está por mejorar y esta mañana he empezado a mirar, para ver las alternativas que tenemos en Linux para la edición de blogs. Me he encontrado con la extensión Deepest Sender para Firefox, que es con la herramienta que estoy escribiendo esta entrada.

La impresión general es bastante buena:

1. Soporta edición WYSIWYG
2. Está totalmente en castellano. El hecho de que no esté en castellano, lo asocio a un problema de inmadurez del software.
3. Los botones para la edición son los que deben ser, aunque probablemente le falte la edición del formato de texto, y no tener que recurrir a la pestaña Fuente para editar en HTML. Tener que editar código en HTML directamente lo asocio a un problema de accesibilidad del software.
   
4. El deshacer no funciona todo lo bien que debiera, cuando cambiamos de pestañas.
5. Permite editar el titulo del post.
6. Tampoco envía las imágenes, por lo que al final tengo que modificar las entradas a mano y subir las imágenes.
7. No me permite publicar por que me muestra un error con la ¿fecha (= WTF!?)?
8. Lo mejor de todo es que entre las opciones de configuración podemos configurar si queremos que nos detecte los títulos de las ¿ canciones (=WTF!?)?
   

Sentencia: No puedo usarlo, aunque está más maduro que BloGTK, a pesar de que no puedo publicar nada.

Posteando con BloGTK

Leyendo Microsiervos y aprendiendo de los maestros, he leído que ellos usan ecto para editar sus posts en MacOsX, aunque también existe una versión para Windows. Entonces me he preguntado: ¿existirá algo parecido para Gnome?. La respuesta que primero he encontrado es BloGTK, y he creado esta nueva entrada usándolo a él como editor, y no haciéndolo en la incómoda interfaz web.

Como estoy en mi semana Fedora, me he instalado la versión de Fedora Core7 que me sugiere el propio administrador de paquetes de FedoraCore8 (actualizada hace una hora), en plan usuario windows sin abrir una consola ni nada de eso: todo con el ratón. Me ha instalado la versión 1.1-8.fc7

No es muy allá o aún no la controlo lo suficiente, porque he detectado los siguientes problemillas:

1. No tiene botones para la inserción de listas ordenadas e itemizadas (lo que viene siendo <ol> y <ul>)


2. No me permite cambiar el título de los post que envío


3. No se encarga de subirme las imágenes el programa: A la hora de insertar imágenes, me pide la URL ¿y las dimensiones? ...error: Debería pedirme el fichero donde las tengo, y que él se encargara del resto


4. Los botones no funcionan bien en la pestaña de previsualización


5. En la pestaña "Edit Post" puedo modificar los Tags HTMLs alegremente sin que se compruebe que es HTML válido


6. No está en castellano


7. No sé para qué sirve la pestaña Advanced

En resumen ... que no está muy usable... resulta casi tan incómodo como la web.

Mi primer paquete SRC.RPM y RPM

Desde hace ya tiempo, me estaba planteando aprender a crear paquetes RPMs con los scripts y proyectos que voy haciendo en mis diferentes clientes, porque no siempre tenemos a mano el CVS donde lo desarrollé. La idea sería...

1. Saber construir el paquete perfectamente (./configure, make, make install, etc) desde los fuentes.
   
2. Hacer un fichero SPEC
3. Crear el SRC.RPM
4. Construir el RPM para RHEL3, RHEL4, RHEL5, etc
5. Publicar los RPMs en repositorios YUM marcados como updates.
6. Configurar los equipos, para que periódicamente actualicen estos repositorios.

Hoy me he decidido por fín a empezar con esto. Ya había leído mucha información sobre cómo poder hacerlo:

• Maximum RPM es la referencia absoluta.
• RPM HOWTO es lo primero que leí

Al final lo más fácil es lo siguiente. Primero copiamos el fuente a /usr/src/redhat/SOURCES/.

cp nagios-plugins-1.4.3.tar.gz /usr/src/redhat/SOURCES/

Luego nos creamos un fichero SPECs (nagios-plugins.spec).

Name: nagios-plugins
Version: 1.4.3
Release: 1
Summary: Conjunto de plugins para los clientes Nagios

Group: Applications/System
License: GPL
URL: http://nagiosplug.sourceforge.net/
Source0: http://dl.sf.net/sourceforge/nagiosplug/%{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

Packager: IBM78M 
Vendor: Nagios Plugins - Consejeria Turismo
Provides: nagios-plugins


%description
Nagios monitors hosts and services on your network. Actual host
and service checks are performed by separate plugins which return
the host or service status to Nagios. This site is devoted to
making the plugins as useful and reliable as possible.


%prep
%setup -q


%build
./configure --prefix=/usr/local/nagios
make %{?_smp_mflags}


%install
rm -Rf $RPM_BUILD_ROOT
make DESTDIR=${RPM_BUILD_ROOT} install



%clean
rm -Rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root)
/usr/local/nagios/libexec/*
/usr/local/nagios/share/locale/*/LC_MESSAGES/nagios-plugins.mo


%changelog
* Wed Mar 26 2008 Ignacio Barrancos 
- Initial build.

Ahora creamos el SRC.RPM mediante:

rpmbuild -bs nagios-plugins.spec

Una vez lo hemos creado (nos lo dejará en /usr/src/redhat/SRPMS/nagios-plugins-1.4.3-1.src.rpm), ya podremos crear el paquete binario:

rpmbuild -bb  SPECS/nagios-plugins.spec

Extraer ficheros de un paquete RPM sin instalarlo

Esta mañana he necesitado extraer ficheros de un paquete RPM que estaba en RH3 para RH4 ... ¿cómo se hace esto? ... pues está bien explicado en http://www.cyberciti.biz/tips/how-to-extract-an-rpm-package-without-installing-it.html. Es suficiente con ejecutar el siguiente comando:

rpm2cpio PAQUETE | cpio -idmv

Y nos deshará el paquete en el directorio actual.

Como cambiar la zona horaria a un Linux

Al actualizar el ESX a 2.5.3-Path14 me he encontrado con la hora del sistema que estaba mal. La he ajustado con nuestro servidor NTP interno, y tampoco, claro que ha sido entonces cuando me he dado cuenta de la zona horaria que estaba usando no era la de Paris/Madrid: ¿Cómo cambiar la zona horaria de nuestro servidor Linux?, pues siguiendo esta secuencia de pasos, que me he molestado en traducir.

1. Primero, sacamos una copia del fichero actual, por si hubiera que volver atrás:
   

   mv /etc/localtime  /etc/localtime.old



2. Crear un enlace simbólico a la zona que queremos que tenga nuestro servidor:
   

   ln -s  /usr/share/zoneinfo/Europe/Madrid  /etc/localtime



3. Ajustar la hora con nuestro servidor...
   

    ntpdate ntp.carm.es



4. ... y por último ajustar el reloj hardware, para que cuando reiniciemos el equipo, no hayan muchas diferencias de hora:

    hwclock --systohc



5. Crear el directorio para el ajuste horario
   

    mkdir /var/lib/ntp/drift -p
   chown -R ntp.ntp /var/lib/ntp



6. Actualizar el fichero de configuración para NTP, esto está en /etc/ntp.conf
   

   ## Indica que solo el localhost puede usar el servicio.
   ## Es la forma de indicar que no se quieren escuchar peticiones
   ## UDP, lo que nos convertiria en servidores tambien
   restrict default nomodify notrap noquery
   restrict 127.0.0.1
   
   ##
   ## Quien sera nuestra referencia horaria
   server  ntp.carm.es      # El NTP Corporativo
   server  127.127.1.0      # Nuestro reloj interno
   
   ## Nuestro reloj interno lo metemos en un stratum alto
   ## por si es que no estuviera disponible el Coporativo
   fudge   127.127.1.0 stratum 10
   
   ## Aqui se indica donde se escribe esa correccion.
   ## Normalmente se escribe un valor cada hora.
   ## OJO CON LOS PERMISOS DEL FICHERO.
   driftfile /var/lib/ntp/drift
   
   ## Sin autenticacion
   authenticate  no

7. Actualizar el fichero /etc/ntp/step-tickers, ejecutando:
   

    echo 'ntp.carm.es' > /etc/ntp/step-tickers
   

8. Iniciar el servicio y configurar para que arranque con el sistema:

    /etc/init.d/ntpd start
   chkconfig --level 35 ntpd on

Luego, para saber si estamos si tenemos nuestro reloj ajustado o no, podemos ejecutar "ntpq -p".

Actualización de servidores VMware ESX 2.5.X

En mi nuevo lugar de trabajo, me he encontrado con un servidor VMware ESX Server 2.5.3 build-24171. He estado mirando en Internet y parece que se corresponde con la versión 2.5.3-Patch1. No es necesario explicar la necesidad de mantener estos sistemas actualizados. Para comprobar si existen actualizaciones pendientes de este producto, debemos acceder a http://www.vmware.com/download/esx/esx2_patches.html, y buscar nuestra versión. En nuestro caso, comprobé que existía hasta el parche 14. Lo descargué, leí atentamente las instrucciones que se indicaban y realicé la siguiente secuencia de pasos.

1. Parar todas las máquinas virtuales que tuviéramos arrancadas en el servidor.
2. Copiar el parche que me había descargado al directorio /tmp de nuestro servidor ESX.
3. Como no tenemos una instalación del ESX desde la SAN, reinicio la máquina con la opción "linux" en LILO para evitar que arranque con el kernel de VMware (vmkernel).
   

   /sbin/lilo -R linux
   reboot

4. Una vez haya arrancado la máquina, descomprimir el parche y lanzar la actualización
   

   cd  /tmp
   tar -xzvf esx-2.5.3-56529-upgrade.tar.gz
   cd  esx-2.5.3-56529-upgrade
   ./upgrade.pl
   

Una vez ha terminado la actualización nos preguntará, si queremos reiniciar el servidor. Responderemos que sí, y la actualización ya estará terminada. El siguiente paso, debería ser el de reinstalar VMware Tools en las máquinas virtuales que teníamos instaladas en el equipo. Sería bueno que antes de instalar nuevos sistemas, comprobáramos las notas de instalación y configuración que nos indican en la web de soporte de VMware, dependiendo del tipo de sistema que vayamos a instalar.