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.