Publicar vídeos en un blog implementado con Nibbleblog.

Ya hablé en su día de nibbleblog para su uso privado en la intranet del centro. Esta semana he necesitado escribir un post con varios vídeos y paso a contar como los he insertado. Seguramente el sistema vale para cualquier otro blog/gestor de contenidos/página web.

Algunos vídeos eran de Youtube, para ellos cargamos el vídeo en cuestión en Youtube, y damos sobre el con el botón derecho, seleccionando "Copiar código de inserción". Ese mismo código podremos pegar como html en nuestra página.

<iframe src="https://www.youtube.com/embed/PGNG7VZ-qBI?start=840" 
         width="640" height="480" frameborder="0" allowfullscreen="allowfullscreen">
</iframe>

Si queremos que la reproducción empiece en un momento concreto añadimos "?start=" a la URL:

<iframe src="https://www.youtube.com/embed/PGNG7VZ-qBI?start=840" 
         width="640" height="480" frameborder="0" allowfullscreen="allowfullscreen">
</iframe>

Otros vídeos estaban dentro de Google Drive. Para ello seleccionamos el fichero y lo configuramos para compartir con cualquiera que tenga el enlace. Luego, con el botón derecho, damos a "Obtener enlace", eso nos genera algo así como "https://drive.google.com/open?id=0BwESTH0ykuAAUFJJdERodjgwYTZ", pues lo que nos interesa ese el "id=XXXX" ya que eso nos va a servir para obtener el enlace donde va el vídeo embebido para visualizar directamente, que sería lo marcado en rojo:

<iframe src="https://drive.google.com/file/d/0BwESTH0ykuAAUFJJdERodjgwYTZ/preview"
   width="640" height="480">
</iframe>

Y ya está, tarea hecha. Es una pena no tener cosas mas interesantes de momento, pero estamos sobrepasados por el trabajo y tengo todo a medias.

Usar samba para enviar ficheros desde un script.

Un buen administrador de sistemas tiene siempre un montón de soldaditos trabajando para él por toda la red: scripts, tareas puppet, procesos de vigilancia,... A veces nos interesa que nos manden información de vuelta para que otro proceso o nosotros mismos la recopilemos y que esa información nos llegue de una manera sencilla.

En este caso concreto tenía unos scripts que recaban información y necesitaba que me suministrasen un fichero por cada máquina donde se ejecutaban. Para ello se me ocurrieron varias alternativas:

• Que me lo enviasen por correo: instalando y configurando en cada PC un cliente de correo tipo mutt. Demasiado complicado.
• Que se guarde en algún servidor conectando por FTP, SCP, ... Me obliga a habilitar ese servicio en el servidor y buscar la manera de que se pueda guardar el fichero de manera no interactiva sin tener que poner contraseña .
• Hacer facters de puppet y dejar que el propio puppet recopile los datos y los guarde en el servidor en ficheros yaml con sus reports. Si es para algo que va a usarse mucho es una buena solución. Si es para algo rápido e infrecuente no merece la pena trabajarse el facter en Ruby.
• La elegida: escribir el fichero en un recurso Samba de acceso público, sin autenticación. Rápido y sucio, que solo requiere tener instalado smbclient en los PC donde se realiza.

En primer lugar la carpeta compartida de forma promiscua:

# cat /etc/samba/smb.conf
....
map to guest = Bad User
....
[almacen]
comment = Almacen IES
path = /home/almacen
writable = yes
browseable = yes
guest ok = yes
force directory mode = 0777
....

En esta carpeta cualquiera puede leer y escribir sin ningún tipo de autenticación, ideal para scripts que se ejecutan de forma autónoma por toda la red. Ahora vamos a ver un ejemplo de script, que guardará los datos (por ejemplo, nombre del PC y MAC de sus tarjetas de red) en la ruta /home/almacen/deposito y en un fichero con el mismo nombre que el PC:

#!/bin/bash

HOST=$(hostname)

echo  "$HOST" > /tmp/$HOST

ifconfig -a | grep HW | awk '{print $5}' >>/tmp/$HOST

cd /tmp
smbclient -N //172.19.196.14/almacen -c "cd deposito; put $HOST"

exit 0

La clave está en:

smbclient -N //172.19.196.14/almacen -c "cd deposito; put $HOST"

Que conecta a al servidor situado en esa IP y al recurso "almacen" y ejecuta los comandos cd y put para subir el fichero al directorio indicado. Simple, efectivo, rápido y sucio. Lo tiene todo.

La conjura de los necios (IV): Oceanía siempre ha estado en guerra con Eurasia.

Martes 14 de febrero de 2016, informativo de Canal Extremadura:

Versión escrita de la noticia aquí.

Vaya, esto es terrible. Parece ser que una empresa ha decidido que ya no se soporta Linux y hay que moverse a Microsoft. Jara está implementado sobre SAP (que a su vez corre sobre AIX y/o SUSE por lo que se puede leer en Internet) y parece ser que para SAP también es una sorpresa el no soportar Linux, porque en está página actualizada hace 4 meses nos dicen:

Supported Linux Distributions:

The following Linux distributions are tested and certified for use in SAP environments. See also SAP note 171356:

Oracle:

Oracle Linux 7 for x86_64
Oracle Linux 6 for x86_64
Oracle Linux 5 for x86_64

Red Hat:

Red Hat Enterprise Linux 7 for x86_64, IBM System p and IBM System z
Red Hat Enterprise Linux 6 for x86, x86_64, IPF, IBM System p and IBM System z
Red Hat Enterprise Linux 5 for x86, x86_64, IPF, IBM System p and IBM System z
Red Hat Enterprise Linux 4 for x86, x86_64, IPF and IBM System p
Red Hat Enterprise Linux 3 for x86 and IPF (out of maintenance)
Red Hat Enterprise Linux 2.1 for x86 (out of maintenance)
Red Hat Linux 7.1 Professional (out of maintenance)
Red Hat Linux 6.2 (out of maintenance)
Red Hat Linux 6.1 Enterprise Version 1.0 (out of maintenance)

SUSE:

SUSE Linux Enterprise Server 12 for x86_64 and IBM System z
SUSE Linux Enterprise Server 11 for x86_64, IPF, IBM System p and IBM System z
SUSE Linux Enterprise Server 10 for x86, x86_64, IPF, IBM System p and IBM System z
SUSE Linux Enterprise Server 9 for x86, x86_64, IPF, IBM System p and IBM System z (out of maintenance)
SUSE Linux Enterprise Server 8 for x86, IPF and IBM System z (out of maintenance)
SUSE Linux Enterprise Server 7 for IA32 and IBM System z (out of maintenance)
SUSE Linux Enterprise Server for IA32 (out of maintenance)

Supongo que quizá la noticia leída por torso parlante de turno quiere decir que la empresa que da soporte a Jara ha decidido usar SAP sobre Windows y el SES, que parece no tener ningún poder sobre dicha empresa, ha agachado la cabeza y ha dicho "Amén, amo".

Jara tiene su pequeña historia tragicómica. Según cuentan los anales el contrato estipulaba que debía correr sobre software libre, lo ganó IBM y una vez con el poder decidió hacerlo en SAP, que debe ser lo mas próximo al concepto germánico de la libertad. La Junta de Extremadura fue una vez mas un organismo pusilánime que aceptó este cambalache sin penalizar para nada a IBM (ya se sabe,... débil con el poderoso, poderoso con el débil). Recuerdo haber leído hace tiempo en algún blog acusaciones de lo oscurantista del proceso, insinuando sobornos, pero igual lo he soñado porque no lo encuentro ya en Internet. Derecho al olvido, lo llaman.

Bueno, yo venía aquí a hablar de mi libro. En el minuto 1:45 del vídeo la voz en off dice:

El año pasado ya se licitó un contrato millonario para adquirir licencias de Microsoft para las aulas extremeñas. De momento, este proceso se ha paralizado.

Algo que ya comenté aquí. Ya sabemos, si lo dice la telepantalla será verdad: Oceanía siempre ha estado en guerra con Eurasia.

Ejecutar tareas puppet sin servidor puppet.

Tengo unas cuantas máquinas aisladas en una red que no pertenece a mis dominios en las que quiero ejecutar tareas puppet creadas por mi, pero no puedo usar el servidor puppet de dicha red.

¿Existe alguna manera de ejecutar tareas puppet sin tener servidor puppet?. Si, usando "puppet apply". Para ello creamos (o copiamos desde nuestro servidor puppet oficial) en una ruta local, por ejemplo "/root/puppet", un árbol de directorios con los distintos módulos:

# tree /root/puppet
puppet/
├── siatic_ajustes
│   ├── files
│   │   ├── 14-init.conf
.   .   . 
.   .   .
.   .   .
│   │   └── Siatic.desktop
│   ├── LEEME
│   └── manifests
│       └── init.pp
└── siatic_pkgsync
    ├── files
    │   ├── mayhave
    │   ├── maynothave
    │   └── musthave
    ├── leeme.txt
    └── manifests
        └── init.pp

Ahora, si localmente queremos ejecutar siatic_pkgsync haremos:

# puppet apply --modulepath=/root/puppet/ -e "include siatic_pkgsync"

Y ya está. Sencillo...¿no?. Este truco también puede usarse para probar in situ sobre una de las máquinas una tarea puppet que estemos desarrollando para luego propagar a otras máquinas.

Tenía que decir algo más, pero no tengo ahora ganas de que los mercaderes ocupen mi templo, así que pongo esto:

Salud.

Clonado de monitor y cañón con distintas resoluciones.

Sobre resoluciones y xrandr para jugar con ellas ya hemos hablado aquí y aquí.

Vamos a ver como solucionar cuando tenemos una pantalla y un cañón de vídeo que soportan distintas resoluciones y queremos tenerlos clonados con unas resoluciones fijas, independientemente de la que tenga configurada el usuario en su configuración de "Pantalla" de las Preferencias del sistema de XFCE.

En nuestro caso, las pizarras+PC que hemos recibido tienen una resolución máxima de 1280x720 para el cañón de vídeo y de 1920x1080 para el monitor. El monitor se conecta por el puerto VGA-? y el cañón por HDMI-?. Pongo la interrogación porque a priori es imposible saber que número va ahí: no sé si depende del PC, de la temperatura en la superficie de Marte o de las probabilidades de formar gobierno de Pedro Sánchez, la cuestión es al ser variable no se puede poner de forma fija.

El script sería:

#!/bin/sh

#Primero borramos displays.xml del perfil XFCE del usuario para anular cualquier configuración que tuviere.
test -e  $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml  &&  rm  $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

#Averiguamos los id correctos de las salidas HDMI y VGA
HDMI=$(xrandr | grep " connected" | grep HDMI | cut -d" " -f1)
VGA=$(xrandr | grep " connected" | grep VGA | cut -d" " -f1)

#Fijamos la resolución, clonamos y escalamos.
xrandr --output $VGA --mode 1920x1080 --pos 0x0 --rotate normal --output $HDMI --mode 1280x720 --pos 0x0 --rotate normal --same-as $VGA --scale-from 1920x1080
exit 0

Lo ideal para automatizar su ejecución en el PC sería crear un acceso directo al mismo con un fichero .desktop y finalmente meterlo en /etc/xdg/autostart para que se ejecutase con cada inicio de sesión, algo sencillo.