Ejemplos de usos reales de PICA

En este apartado se dan ejemplos reales de usos que le hemos dado a PICA, que muestran diversas características del programa.

Distribución de claves RSA

Para no estar continuamente escribiendo claves a la hora de acceder a los servidores por SSH, hemos distribuido nuestras claves públicas en varios servidores y activado los agentes RSA. La propia distribución de las claves puede hacerse de forma automática con PICA. A continuación presentamos el extracto de objects.conf donde se definen los ficheros a distribuir, y su contenido.

Ejemplo 14. Distribución de claves RSA: extracto de objects.conf

group RSAAuth {
    # Fichero de autorización de SSHv2
    file ssh_auth {
         path = '/root/.ssh2/authorization';
         source = "SSH/authorization.cfg";
    }
    file sysadm1.pub {
         path = '/root/.ssh2/sysadm1.pub';
         source = "SSH/sysadm1.pub";
    }
    file sysadm2.pub {
         path = '/root/.ssh2/sysadm2.pub';
         source = "SSH/sysadm2.pub";
    }
    # ...
    # Resto de las definiciones de ficheros de clave pública
}
        

Por supuesto, podríamos haber generado dinámicamente las entradas para los ficheros de clave pública, pero no creemos que valga la pena, por seguridad y porque probablemente no serán muchas.

Ejemplo 15. Distribución de claves RSA: fichero authorization.cfg

#perl
my @return;
# Obtenemos los ficheros de clave leyendo los miembros del grupo
# SSHAuth, pero saltándonos el fichero 'ssh_auth'
my @keys=grep(/\.pub$/,members('SSHAuth'));
foreach my $key (@keys) {
  push @return,"Key $key\n";
}
# Devolvemos la lista (se imprimirá en la versión final del
# fichero)
@return;
#lrep
        

Después de preprocesarse, el fichero contendrá los nombres de los ficheros «lógicos» (es decir, lo que va después de file) que terminen en .pub, uno por línea, precedidos de Key, es decir, algo como esto:

Ejemplo 16. Distribución de claves RSA: ejemplo de fichero authorization creado automáticamente

Key sysadm1.pub
Key sysadm2.pub
...
        

Creación de varios ficheros a partir de un solo fuente

Otra de las posibilidades que nos brinca PICA es concentrar en un solo fuente todas las variaciones necesarias de un fichero, mediante condicionales. Por ejemplo, podemos querer instalar en la misma máquina dos ficheros iguales a partir del mismo fuente. Este caso se nos dio en los servidores primarios de nombres, en los que además queríamos guardar ficheros de ejemplo de los secundarios para publicarlos en web. Para ello, no nos hizo falta nada especial: pudimos aprovechar el mismo fuente para ambas versiones.

Ejemplo 17. Declaración de los servidores DNS

hostgroup dnsservers {
    members { fobos, deimos, mercurio, ulpnet, ulpnet2 }
}
hostgroup dnsmaster {
    members { ulpnet, ulpnet2 }
}
hostgroup doc {
    members { ulpnet, ulpnet2 }
}
	

Como vemos, tenemos declarados los grupos de máquinas que dan servicio DNS, los que son servidores principales, y los que hacen de servidor de documentación (que coinciden con los servidores principales de nombres). Los objetos se declararon de la siguiente manera:

Ejemplo 18. Declaración de los objetos a instalar

#if (ingroup('dnsservers'))
group DNS {
    file named.conf {
         path = '/etc/named.conf';
         source = "DNS/named_conf.cfg";
    }

    ## Documentación del servicio
#  if (ingroup('doc'))
    # ...
    file named.conf.sample {
       path = '<#$docdir#>/Servicios/DNS/named.conf.sample';
       source = 'DNS/named_conf.cfg';
    }
#  fi
}
#fi
	

De esta forma, sabemos que ambos ficheros se van a sacar del mismo fuente (DNS/named_conf.cfg), y que los ficheros de ejemplo siempre terminan en .sample. Con esta información tenemos suficiente para poder distinguir con el preprocesador. El contenido del fichero named.conf.cfg será algo como:

Ejemplo 19. Contenido parcial del fichero named.conf.cfg

# ...
zone "ulpgc.es" {
#if ((ingroup('dnsmaster')) && ($picaobject !~ /\.sample$/))
   type master;
   file "mydb.db";
   also-notify {
      # ...
   };
#else
   type slave;
   file "mydb.db.bak";
   masters {
      # ...
   };
#fi
};
# ...
	

Así, cada vez que se vaya a instalar cualquier fichero en los servidores de nombre primarios, se comprobará el nombre del fichero (el nombre del objeto en el fichero de configuración, no del fuente). Si termina en .sample, el contenido será el de un servidor secundario de DNS; si no, será la configuración de un DNS primario. Si la máquina donde va a instalarse es un secundario, no hay posible ambigüedad, siempre se instala la versión de servidor secundario.