minWi blog

Presupongo que perderás soporte, pero puede ser útil para entornos de lab:

http://www.ntpro.nl/blog/archives/1602-Injecting-drivers-into-the-ESXI-installer.html

Cuando alguna de las rutas (origen o destino) del comando scp contiene espacios en blanco (aun “escapandolos” con la barra invertida \), falla mostrando el error “ambiguous target”.

scp <ruta_fichero_origen> <usuario>@<host_destino>:<ruta_con_espacios\ escapados>
scp: ambiguous target

La solución es entrecomillar:

scp <ruta_fichero_origen> <usuario>@<host_destino>:"<ruta_con_espacios\ escapados>"

Puede ocurrir que por diversas causas (fallo de conectividad en el momento exacto, falta de espacio en disco,…) queden snapshots “fantasmas” de máquinas virtuales.

El procedimiento oficial de VMware es el que aparece relatado en esta KB:

http://kb.vmware.com/kb/1002310

Después de haberme pegado bastante con ello, lo dejo aquí por si vale para alguien en el futuro, y le ahorro algún disgusto

NOTA: Tengo poca idea de PHP, SOAP, WSDL, etc., pero creo que al final no me ha quedado del todo mal….

PROBLEMA:

Se quiere integrar un formulario de Drupal (alta de nueva máquina virtual), con un proceso de IT PAM, que crea la máquina virtual, da el alta en la CMDB, etc.

El problema viene en como notificar al IT PAM que hay un nuevo formulario. La primera idea, es crear un proceso que cada X tiempo, verifique si hay un formulario nuevo en base de datos, y si lo hay, procesarlo. Obviamente este comportamiento es un poco “chapucero” y nada elegante.

Investigando un poco el tema, hemos averiguado que IT PAM tiene un servicio web que puede ser consumido, enviandole la petición adecuada, usuario, proceso a desencadenar, etc.

Este servicio web se puede consultar en

http://<itpamhost>:8080/itpam/soap

con ?wsdl al final, para ver el xml.

Se probó a consumir el servicio web utilizando curl, funcionando de manera satisfactoria, creando un xml como este:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:itp="http://www.ca.com/itpam">
   <soapenv:Header/>
   <soapenv:Body>
      <itp:executeStartRequest>
         <itp:auth>
            <itp:user>USUARIO</itp:user>
            <itp:password>PASSWORD</itp:password>
         </itp:auth>
          <itp:objLocation>
            <itp:name>NOMBRE_PROCESO</itp:name>
            <itp:path>PATH_PROCESO</itp:path>
         </itp:objLocation>
       </itp:executeStartRequest>
   </soapenv:Body>
</soapenv:Envelope>

Sin embargo, consumirlo con curl tenía los mismos problemas que el anterior supuesto (habría que comprobar de alguna manera que ha sido actualizada la base de datos), y ejecutar un proceso con un trigger de mysql no es nada recomendable (problemas de seguridad, locking,…)

SOLUCION:

Se creó un fichero .php que realizaba el proceso “manualmente” de manera correcta:

<?php
      // include soap file
      require_once('nusoap/nusoap.php');

      // set end point
      $endpoint = "http://<ITPAMHOST>:8080/itpam/soap";

      // create client
      $client = new nusoap_client($endpoint);

      if ( $client->getError() ) {
        print "Soap Constructor Error: ";
        print_r($client->getError());
      }

      // Human readable
      $request = <<<HEREDOC
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:itp="http://www.ca.com/itpam">
   <soapenv:Header/>
   <soapenv:Body>
      <itp:executeStartRequest>
         <itp:auth>
            <itp:user>USUARIO</itp:user>
            <itp:password>PASSWORD</itp:password>
         </itp:auth>
         <itp:objLocation>
            <itp:name>NOMBRE_PROCESO</itp:name>
            <itp:path>PATH_PROCESO</itp:path>
         </itp:objLocation>
      </itp:executeStartRequest>
   </soapenv:Body>
</soapenv:Envelope>
HEREDOC;

      $msg     = $client->serializeEnvelope($request, '', array(), 'document', 'encoded', '');
      $result  = $client->send($msg,"executeStartRequest");

      if ( $client->fault ) { //soap_fault
        print "Soap Fault :";
        print_r($client->fault->faultcode);
        print_r($client->fault->faultstring);
      }
      elseif ( $client->getError() ) {
        print "Soap Error :";
        print_r($client->getError());
      }
      else {
        print "Result: ";
        print_r($result);
      }

?>

Aprovechando que Drupal es opensource, y teniendo el codigo, se intentó modificar parte del codigo del modulo encargado de la gestión de modulos (webform), sin exito.

Investigando un poco más, se vió que el modulo Webform, tiene una API, que permite ejecutar “cosas” en distintos puntos del proceso (antes de entrar en base de datos, al actualizar, etc.)

Por lo tanto, solo quedaba encontrar como utilizar esa característica para nuestros propositos.

La solución más elegante (y la que se ha usado), es crear un modulo de Drupal nuevo, llamado “itpam”, que utiliza el “hook” _webform_submission_insert cuyo contenido es:

itpam/itpam.info:

; $Id: $
name = ITPAM
description = "Module for notify IT PAM"
package = Administration
core = 6.x
php = 5.1

itpam/itpam.module:

<?php
function itpam_webform_submission_insert ($node, $submission){

if ($node->nid == 104){

      // include soap file
      require_once('nusoap/nusoap.php');

      // set end point
      $endpoint = "http://itpamhost:8080/itpam/soap";

      // create client
      $client = new nusoap_client($endpoint);

      if ( $client->getError() ) {
        print "Soap Constructor Error: ";
        print_r($client->getError());
      }

      // Human readable
      $request = <<<HEREDOC
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:itp="http://www.ca.com/itpam">
   <soapenv:Header/>
   <soapenv:Body>
      <itp:executeStartRequest>
         <itp:auth>
            <itp:user>USUARIO</itp:user>
            <itp:password>PASSWORD</itp:password>
         </itp:auth>
         <itp:objLocation>
            <itp:name>NOMBRE_PROCESO</itp:name>
            <itp:path>PATH_PROCESO/</itp:path>
         </itp:objLocation>
      </itp:executeStartRequest>
   </soapenv:Body>
</soapenv:Envelope>
HEREDOC;

      $msg     = $client->serializeEnvelope($request, '', array(), 'document', 'encoded', '');
      $result  = $client->send($msg,"executeStartRequest");

      if ( $client->fault ) { //soap_fault
        print "Soap Fault :";
        print_r($client->fault->faultcode);
        print_r($client->fault->faultstring);
      }
      elseif ( $client->getError() ) {
        print "Soap Error :";
        print_r($client->getError());
      }
      else {
        print "Result: ";
        print_r($result);
      }
}
}
?>

Este modulo se activa cuando se inserta un registro nuevo en la base de datos (se ha añadido el chequeo $node->nid == 104, que es el correspondiente en este caso, al alta de máquina virtual)

Una vez creado el modulo, y con los permisos adecuados, se activa el modulo desde la interfaz de administración de Drupal, é voilá!

PD.- Falta cambiar un par de detalles, pero como “guia” vale

Una de las cosas que más me apetecía probar de OpenIndiana (vamos, de Solaris), era ZFS. Sin embargo, en la instalación de la versión servidor, no dejaba ninguna opción avanzada de almacenamiento, solamente elegir el disco y si era dedicado o había que particionar.


NOTA: La instalación usando F2,F3,… es un auténtico PITA.
Mi idea era montar un RAID0+1 con cuatro discos.
Más tarde, comprobé que un root pool no se puede extender a más de un disco (o eso creo!), por lo que descarté la idea, y decidí probar un RAID1.
La instalación de OpenIndiana la realicé en una máquina virtual bajo VMware Fusion, con dos discos de 20 GB (vamos, los screenshots de antes).
Una vez instalado, comprobamos el estado de los pooles (solo debería de haber uno, el pool “root”):
zpool status

Comprobamos los discos que tenemos:
format
ctrl+c

NOTA: Seguramente haya alguna forma más limpia de listar los discos, pero esta funciona.

Y procedemos a crear el mirror.
Como el segundo disco es “virgen”, hay que recrear la estructura del otro:
format
elegir disco
fdisk

Crear partición por defecto:

Ahora las particiones (slices) del disco inicial, recrearlas en el nuevo:
format
elegir disco
partition
print


format
elegir disco
partition
elegir slice 0
id de slice = root
tamaño = cylinders -1
label



Una vez creadas las slices, procedemos a “attachear” el disco/slice al rpool:

zpool attach -f rpool c3t0d0s0 c3t1d0s0


NOTA: No se porque hay que “forzar”, pero en todos los sitios donde he buscado, lo pone ;D
Esperamos a que se repliquen los datos (resilvered), e voilà!:

Para que todo quede como es debido, instalamos el cargador de arranque (grub) en el disco nuevo, para que el sistema pueda arrancar en caso de que falle:

installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t1d0s0

Probamos a quitar el primer disco del rpool:

zpool detach rpool c3t0d0s0


Reiniciamos… y funciona!

PD.- Puede que la entrada esté un poco confusa, por el tema de particiones o slices… la verdad es que yo tampoco lo tengo muy claro, así que refleja bien la realidad Prometo documentarme!

Hace unos días, la comunidad detrás de OpenIndiana, ha hecho pública la versión 151a del sustituto del fallido OpenSolaris.
Es una “development release”, con lo cual se supone que no está preparada para entornos de producción, así que avisados estáis
Yo por mi parte, siempre “le he tenido ganas” a los Solaris, pero hasta ahora no me había animado a más que instalarlo en alguna máquina virtual y poco más, pero esta vez parece que estoy aprendiendo algo.
De momento me quedo con que no es todo lo parecido a linux que pensaba, y estoy descubriendo muchas cosas interesantes (ZFS es la caña), y que hay que tener cuidado con algún comando, que en linux cumple un cometido, y en solaris otro totalmente distinto (vease, killall).
Una de las cosas que más me ha llamado la atención de esta versión, es la inclusión de KVM como herramienta de full-virtualization, ya que combinado con ZFS puede dar mucho juego (habrá que ver que tal de performance, ya que KVM está desarrollado en/para linux).

Several years later…