En la mayoría de las ocasiones no es suficiente sólo con lanzar el comando. Queremos, además, poder procesar la salida recibida de alguna forma.

En python existen muchas formas de lanzar un comando externo, una de ellas es usando subprocess, que tiene algunas características particulares cuando el comando que lanzamos tiene pipes (tuberías).

En sistemas operativos entendemos por una tubería al procedimiento que permite enlazar la salida de un comando como entrada de otro:

In Unix-like computer operating systems (and, to some extent, Microsoft Windows), a pipeline is the original software pipeline: a set of processes chained by their standard streams, so that the output of each process (stdout) feeds directly as input (stdin) to the next one. Each connection is implemented by an anonymous pipe. Filter programs are often used in this configuration. Wikipedia

Un ejemplo sería, en un entorno linux, el siguiente comando que nos cuenta el número de ficheros y directorios que tenemos en un determinado directorio:

Curioso, ¿verdad?

Lo que hemos hecho ha sido ejecutar un ls -l (que muestra cada fichero y cada directorio en una línea) y el resultado, en vez de mostrarlo en pantalla como haría por defecto, se lo hemos pasado al comando wc -l que cuenta el número de lineas que ha recibido como entrada.

El ejemplo que queremos ver es el siguiente:

ipmitool es una herramienta que permite leer la información de los sensores de nuestro ordenador. Nuestro ordenador tiene una serie de sensores que nos informan del estado del sistema, la mayoría de ellos se refieren a la temperatura que hay en la CPU, en la tarjeta gráfica etc.

IPMItool is a utility for managing and configuring devices that support the Intelligent Platform Management Interface (IPMI) version 1.5 and version 2.0 specifications. IPMI is an open standard for monitoring, logging, recovery, inventory, and control of hardware that is implemented independent of the main CPU, BIOS, and OS.

Lo que hacemos con el comando anterior es mostrar la información de todos los sensores, y la salida, en vez de mostrarla en pantalla, la pasamos al comando grep que filtra sólo aquellas que tienen la palabra deg en algún lado: es decir el comando entero sólo muestra la información de aquellos sensores que tengan algo que ver con la temperatura (deg = grados )

La salida esperada sería algo como:

La primera columna es el nombre del sensor, la segunda la temperatura actual. Las tres últimas informan de las temperaturas máximas que el sistema soportará antes de enviar mensajes de warning, de peligro o críticos, respectivamente.

Si queremos procesar esa salida de forma “elegante” para poder realizar algunas operaciones con ellos (guardar histórico, enviar correos…) debemos guardar esos datos en, por ejemplo, un array.

Por extraño que pueda parecernos, python no deja lanzar un comando con un pipe porque entiende, con toda la razón, que son dos procesos que deben enlazarse de la forma correcta:

Es de una lógica aplastante, pero no es nada intuitivo. Una vez que hemos adivinado eso, el resto es relativamente sencillo.

Conviene fijarse en con que gran habilidad hemos convertido la salida del proceso en líneas que luego son procesadas, a través del uso del readline y del split:

La ausencia de vida social, lejos del dolor y la agonía que me auguraba mi psicólogo, permite encontrar breves momentos de paz en estas cosas.

Sad but true.

A veces, cuando estamos realizando esas operaciones, el servidor contra el que lo hacemos puede dar algún fallo por lo que debemos refrescar la página para volver a entrar.

Cada vez que entramos en el sistema Drupal guarda cierta información en las tablas de la base de datos para hacer más rápida la carga (una especie de caché del sistema). Si el servidor nos da algún fallo y refrescamos los datos de esas tablas pueden corromperse y el sistema nos devuelve de forma insistente ese mensaje de error:

drupal 7 PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded;

No sé si existirá una opción mejor, pero una forma de arreglar ese problema es conectarse a la base de datos de Drupal (generalmente a través del administrador que nos provee el servicio de hosting, a través de la línea de comandos o bien con phpMyAdmin), y vaciar todas las tablas relacionadas con la cache del sistema:

Si al vaciar alguna de esas tablas obtenemos un error debemos reparar la tabla afectada.

No es peligroso eliminar los datos de esas tablas, ya que el contenido es creado de forma automática durante la navegación por el sitio, aún así siempre es conveniente realizar una copia de seguridad, eso no hace falta decirlo, ¿verdad?

Un hilo de Ariadna (Breadcrumb o migas de pan en inglés) es una técnica de navegación usada para desarrollar la interfaz gráfica de usuario. Tiene como objetivo que el usuario guarde una ruta de su ubicación dentro de programas o documentos. El término en inglés es breadcrumb, que proviene del cuento clásico Hansel y Gretel. En español, en vez del rastro de migas, se ha acuñado el término evocando el hilo que Ariadna dejó a Teseo para que encontrase el camino de salida en el laberinto del Minotauro. (fuente Wikipedia)

En resumen, un breadcrumb o hilo de Ariadna es ese texto que suele aparecer en la parte superior de algunas páginas web para mostrarnos el camino recorrido. De tal forma que si hemos entrado en un sitio buscando los drivers de nuestra tarjeta gráfica tendremos en la parte superior algo como: inicio / drivers / tarjeta gráfica / modelo. Siendo cada uno de los textos entre las barras un enlace que permite volver a la página de inicio, volver a la sección de drivers y sucesivamente.

En Drupal podemos generar de forma automática los breadcrumbs, pero el sistema lo hace a través de los elementos del menú que hayamos pulsado, para extender su funcionalidad podemos usar el módulo “Menu Breadcrumb“, que admite la posibilidad de añadir de forma automática al breadcrumb el menú al que pertenece la página actual junto con la página actual convertida en enlace.

Sin embargo, existen ocasiones en que esto no es suficiente y necesitamos tener más control sobre lo que se muestra. En el ejemplo anterior, nos gustaría que, hubiésemos llegado como hubiésemos llegado a ella, siempre que se muestre la página de descarga de una determinada tarjeta gráfica se mostrase, además, la ruta: inicio / drivers / tarjeta gráfica, y no sólo inicio / tarjeta gráfica. Es decir, que al usuario siempre le quede claro que se encuentra en esa sección y que puede volver a buscar otros modelos y, por supuesto, volver al inicio.

Para lograr ese comportamiento deberíamos conseguir que al mostrar una página determinada se adjuntase al breadcrumb la ruta anterior con sus enlaces correspondientes, algo que no hace por defecto.

La mejor opción para lograrlo es instalar un módulo y saber un poco, muy poco, de PHP.

En el ejemplo siguiente partiremos del siguiente supuesto:

• Tenemos una página llamada productos cuya url es productos y con identificador node/30
• En la página productos tenemos enlaces al productoA, productoB y productoC, que serán respectivamente node/25, node/30, node/45
• Queremos que al mostrar productoA se muestre en el breadcrumb la ruta inicio / productos / productoA

 
Seguir leyendo

Los módulos necesarios son (customs breadcrumbs y menú breadcrumb):

Una vez instalados y activados debemos crear un disparador que cada vez que el sistema quiera mostrar alguna página de productos (25,30,45) se dispare y, mediante algún comando, adjunte la ruta de productos a nuestro breadcrumb.

En Drupal 7 lo hacemos pulsando sobre la opción de administración “structure”, y eligiendo la opción “custom breadcrumbs”:

Lo que nuestra la siguiente ventana:

En la que debemos elegir “Add a new custom breadcrumb”, bastante obvio por el momento, ¿verdad?

En esta parte es donde debemos elegir como “node type” basic page, esto provoca que cada vez que se carga una página se llama a la función PHP escrita en la parte de Breadcrumb visibility, si la función devuelve true, entonces se modifica la función con los parámetros definidos:

Vayamos por partes:

Breadcrumb visibility:

Este código simplemente crea un array con los valores númericos de las páginas de producto, recordemos que eran 25, 30, 45. Después comprueba si la página actual se encuentra en esa lista y, de ser así, devuelve un verdadero.

Titles:

En caso de que la función anterior haya devuelto verdadero debemos construir nuestro hilo. El hilo se compone de una parte visual, la que se muestra al usuario: inicio / productos / productoA. Y una parte de sistema, las rutas a las que lleva cada paso home / node/20 / node/25.

En la parte de Title es el lugar donde definimos la parte visual:

Es decir, se mostrará al usuario una etiqueta llamada Productos / el título de la página actual, por ejemplo ProductoA.

Paths:

Aquí definimos, por cada etiqueta anterior, la ruta que tiene:

Si lo leemos en orden podemos ver que sería algo como: Por cada página que quiera mostrar evalúa la función PHP, si esta devuelve verdadero pinta en pantalla el contenido de Titles y asigna a cada uno de ellos la ruta establecida en paths.

La función PHP que hemos puesto es bastante versátil, pero podría ponerse cualquier condición, eso sí, hay que tener cuidado de no ser demasiado creativos, porque esa evaluación se disparará en cada página mostrada. Podríamos poner un simple IF con las diferentes páginas, examinar alguna condición externa.. Además, dentro de ese código, tenemos acceso a la variable $node que contiene toda la información relativa a la página actual (nodo).

Uno de los últimos intentos ha sido la inclusión de una interfaz de comandos llamada powershell. Para aquellos que vengan del mundo Unix no será nada revolucionado, e incluso puede ser frustrante cuando intentan usarla porque ha sido hecha al mejor estilo Microsoft: Un tipo de letra horrible, un autocompletar demente y una integración entre las diversas partes un tanto dudosas.

Para terminar de potenciar la interfaz han incluido un lenguaje de programación, de nuevo al estilo de los sistemas Unix, que permita automatizar las operaciones más comunes. Hemos visto en esta página algunos ejemplos sobre como usarlo.

El problema es que Microsoft tiene una capacidad innata para convertir en basura casi todas las buenas ideas que pasan por sus manos, y esto no es más que el siguiente hito en el camino. El sistema no es compatible entre diferentes versiones, hay demasiadas formas de hacer las cosas, y dependiendo desde donde lo ejecutes puedes obtener resultados distintos.

Creación automatizada de directorios y asignación de permisos desde línea de comandos para una lista de usuarios:

Un ejemplo típico de la utilidad de las herramientas de administración mediante consola es la siguiente: Imaginemos que nos han pasado una lista con cien usuarios, y ha sido redactada de la siguiente forma:

Usuario1
Usuario2
Usuario3

Y que queremos, en uno de nuestros servidores, crear un directorio a modo de repositorio con el nombre de casa usuario en el que sólo tenga permiso de acceso dicho usuario.

Desde la interfaz gráfica deberíamos situarnos en el directorio, crear un directorio, ir a las propiedades del mismo y asignar los permisos. Son cien usuarios, pues eso mismo cien veces.

Los permisos se pueden asignar desde la interfaz gráfica, como hemos dicho en el punto anterior, o bien recurrir a la herramienta icacls desde la línea de comandos:

Sin embargo, aun teniendo la herramienta icacls, el crear los directorios uno por uno y asignar los permisos uno a uno es una tarea farragosa e ingrata. Lo ideal sería poder recorrer la lista anterior y, para cada usuario, crear un directorio, borrar los permisos para todo el mundo y agregar los del usuario.

Para hacerlo con el lenguaje de programación de powershell necesitaríamos una manera de ejecutar un comando externo, algo que seguramente exista, pero de todas las opciones probadas no he logrado que funcione ninguna (seguramente por culpa mía, claro)

Al final la opción más sencilla resulto hacer un programa en python y ejecutar los comandos desde allí.

El programa se encarga de abrir el fichero, recorrer cada línea, crear un directorio con ese nombre y asignar los permisos correspondientes. EL truco es que el nombre de usuario se llama exactamente igual que el directorio.

El comando convert, del que ya hemos hablado en otras ocasiones, permite reducir el tamaño de una fotografía a un porcentaje de la original o bien a un tamaño predefinido. Si tenemos un directorio con las fotos y otro llamado thumbs donde queremos guardar las imágenes en un tamaño más reducido (15% del tamaño inicial), podemos escribir lo siguiente en un terminal:

Si, además, somos de los que no nos gusta dar pistas sobre como hemos hecho las fotos siempre podemos hacer un procesado para eliminar toda la información Exif (además ahorramos algo de tamaño). En esta ocasión lo haremos directamente sobre las fotos, sin salvar el original, y con el comando find (por variar):

mogrify es una navaja suiza similar a convert, y también cuenta con numerosas posibilidades que se pueden consultar con el man.

Si miramos la ayuda de convert veremos que permite, además, hacer un sinfín de operaciones con las imágenes, que pueden ser procesadas usando el comando anterior.

Sin embargo ese ejemplo era un módulo que se encontraba disponible para todo el mundo, tanto usuarios registrados como usuarios públicos.

Si queremos añadir algún tipo de control de acceso debemos retocar algo el código anterior, en concreto en el hook de menú:

Es decir, cada vez que se presenta en pantalla el módulo se llama a una función llamada custom_module_access con el parámetro del rol gestor_de proyectos. El rol gestor_de_proyectos, es un rol que hemos creado en la administración de Drupal y en el que hemos incluido al usuario con el que estamos haciendo las pruebas-

La función custom_module_access sería algo así:

Vale, la comparación es bastante mala y se podría programar mucho mejor, pero es una forma sencilla de definir que tanto los administradores como los que pertenezcan al grupo gestor_de_proyectos podrán usar el módulo.

El código completo MiPrimerModuloControlAcceso.

No debemos olvidar que Drupal puede integrarse con un servidor LDAP, por lo que podemos integrar los grupos de acceso a este módulo como grupos de LDAP o, como en este ejemplo, con grupos locales.

Muchas veces sólo es necesaria la instalación de un módulo que, una vez configurado, nos solucione el problema. A veces, sin embargo, es necesario llegar un poco más lejos y debemos ser nosotros quien desarrollemos esos módulos.

Para Drupal tenemos una mini guía sobre el desarrollo de módulos que cubre bastantes aspectos básicos, pero no sobre algunos más complejos.

En el caso que nos ocupa queremos desarrollar un módulo desde cero que permita navegar a través de varios formularios (la mayoría de módulos han sido pensados para hacer operaciones sencillas que no necesitan formularios, ya que muestran la información en la barra de opciones).

Toda la complejidad del asunto gira en torno al hook del menú:

Y la función a la que se llama desde el menú, en este caso de nombre MiPrimerModulo_principal_form, que en vez de limitarse a mostrar el formulario, se encarga de hacer un uso ingenioso de las variables:

Esas variables nos indican en todo momento en que punto de la navegación nos encontramos y, lo que es mejor, los valores que se han ido guardando (para poder volver hacia atrás sin perder el contenido, y también para recopilar la información al final del proceso).

En esta función, que es el punto al que volvemos después de cada formulario, debemos definir que formulario presentamos:

Además, el módulo funcionando crearía una estructura sencilla en la base de datos (que no se usa pero he puesto como ejemplo de uso), y un entrada en el menú principal disponible para todos los usuarios:

Se puede descargar el código completo aquí. Ese código, y otros ejemplos, se pueden encontrar en este enlace, pero no son ejemplos completos como este que se ha desarrollado aquí.

En el código adjunto también se encuentra el fichero module.install que proporciona la manera de crear el esquema de la base de datos al instalar el módulo. Si en algunas de las pruebas no se genera bien el esquema, debemos desinstalar (no deshabilitar) el módulo para que Drupal entienda que lo hemos borrado del todo y volver a instalarlo (para que Drupal vuelva a leer el module.install). Si sólo se deshabilita, Drupal no vuelve a leer el module.install.

Otro ejemplo sobre la creación de módulos puede verse aquí.

Si hacemos la copia combinándola con un tar “al vuelo”, los resultados suelen ser bastante mejores:

(asumimos como /Datos/Origen el directorio de origen, y /Datos/Destino como directorio destino)

La solución entonces es hacer la instalación desde el propio USB:

(Si asumimos como unidad de DVD la unidad d: y la f: como unidad de USB)

Abrimos una venta de MSDOS (ejecutar CMD) o buscarla en el menú de Windows.

Nota: En algunos sitios el comando bootsec lo ejecutan sin las dos últimas opciones. Esto da problemas (al menos en nuestro caso)

El último paso es arrancar el equipo y desde la BIOS indicar que debe arrancar desde el USB.

En Linux existe una solución muy sencilla para evitar ese problema, y es cifrar todas las particiones que sean elegidas para guardar los datos (generalmente el home del usuario, aunque es conveniente hacerlo con el swap).

El cifrado de particiones no afecta al rendimiento general del equipo, y ha sido pulido hasta convertirse en una opción estándar que suele ser ofrecida incluso durante la instalación, aunque siempre es mejor hacer las cosas a mano hasta saber cual es el funcionamiento real.

Eso es lo que intentaré explicar en los siguientes puntos. Como configurar un sistema linux ya instalado para que tenga cifradas las particiones de datos.

Creando la partición

Como trabajamos con una distribución basada en Red Hat (CentOS), las particiones de datos suelen estar guardadas en un contenedor LVM. En mi caso sigo sus reglas y en la instalación hago un contenedor LVM con todo el espacio que me queda para datos y sólo creo un partición swap. Luego, según lo voy necesitando lo voy asignando.

Creamos una partición de 10G para el home de los usuarios:

Borrar la información y cifrar los datos

Si el disco es nuevo o no nos importan mucho los datos que había dentro podemos saltar este paso. En caso contrario es buena idea no dejar ni rastro de los datos antiguos, aunque puede llevar bastante tiempo:

En este punto tenemos la partición lista para ser cifrada. Lo haremos con un cifrado AES de 256 bits, suele ser la opción recomendada aunque si miramos el manual podemos ver los tipos de cifrados soportados.

Acabamos de crear una partición cifrada dentro de nuestro contenedor LVM. Ahora intentaremos trabajar sobre ella:

Con estos comandos hemos abierto la partición cifrada y la hemos llamado homecr. Ya podemos trabajar sobre ella, aunque antes es necesario formatearla:

Este dispositivo funciona exactamente como cualquier unidad de disco. Es decir, podemos habilitarla y empezar a trabajar sobre ella:

Montaje automático de la partición en el arranque

Obviamente la forma de trabajar presentada en el punto anterior no es nada práctica: cada vez que arrancase el sistema deberíamos entrar en modo texto y escribir en la consola:

Antes de poder entrar en modo gráfico y comenzar a trabajar con un usuario.

Lo ideal sería que el sistema, de forma automática y transparente, localizase la partición cifrada, nos pidiese la clave y, además, nos la montase en el directorio indicado.

Los dos primeros pasos se solucionan editando el fichero /etc/crypttab

Que, según el man, tiene el siguiente formato:

En el ejemplo anterior, que teníamos una partición LVM llamada /dev/mapper/VolGroup00-LogVolHome sobre la que mapeábamos un dispositivo llamado homecr, quedaría:

No hemos rellenado el campo password_file_path ni el campo de opciones. El primero porque queremos que el sistema, durante el arranque, se detenga un momento para pedirnos la contraseña, y el segundo por que es lo suficientemente inteligente para detectar el tipo de cifrado (a no ser que probemos opciones exóticas)

El último paso es decirle al sistema que monte de forma automática el dispositivo creado en la partición home. Sí, eso se hace en el /etc/fstab, donde añadiremos la siguiente línea:

Si salvamos el fichero y reiniciamos la máquina esta, durante el arranque, se detendrá para pedirnos la contraseña del dispositivo cifrado. Una vez introducida de forma correcta continuará el arranque normal y nos dejará el sistema con la partición home cifrada lista para ser usada.

Partición swap y temporal

Todo esto funciona bien para particiones de datos. Sin embargo existen particiones especiales de las que solemos pedir otro tipo de comportamiento. Me refiero a las particiones de tipo swap y los directorios temporales. No habría ningún problema en tratar estas dos particiones como dos particiones normales y cifrarlas según el procedimiento anterior, sin embargo suele ser habitual iniciarlas al arranque totalmente vacías. Para ello lo que se hace es generar una clave de forma automática leyéndola del /dev/urandom (lo cual de forma implícita destruye el contenido).

En /etc/crypttab:

En /etc/fstab:

Y, algo parecido podríamos hacer con el tmp: