Ejemplos de usos reales de PICA

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.

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.

#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:

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.

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:

#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:

# ...
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.