2016-03-21 1 views
0

Dans promises.cf de mon cf-serverd J'ai un paquet commeComment utiliser les bundles paramétrés dans cf-serverd?

bundle server host_rules(key, host) { 
    access: 
     "/srv/cfengine3/$(host)" 
     admit_keys  => { "$(key)" }; 
} 

j'ai essayé de instancier avec

body common control { 
     bundlesequence => 
     { 
     generic_rules, 
     host_rules("MD5=362c5fcf568b492f78ae392229299c05", "foo.example.com"), 
     }; 
} 

Mais (avec cfengine-3.8.1), cela ne semble pas avoir un effet. Par exemple. cf-serverd -v signale uniquement les règles d'accès dans le lot generic_rules et un accès aux fichiers de foo.example.com est refusé.

generic_rules (qui est un simple paquet bundle server generic_rules { ... }) semble être évalué lorsqu'il n'est pas répertorié le commun bundlesequence.

Comment puis-je développer l'ensemble host_rules dans la configuration de cf-serverd?

EDIT:

intention I de donner accès à certains répertoires uniquement à un hôte correspondant qui est identifié par sa clé. Je sais qu'il est possible d'utiliser $(connection.key) dans le chemin, mais n'aime pas parce que

  • il est illisible (ayant des dizaines de répertoires avec des noms sans signification MD5=... rend la difficulté de trouver le répertoire appartenant à « foo.example

  • il crée des problèmes lorsque la clé du client change (par exemple parce qu'il a été compromis ou parce que l'hôte sera réinstallé). 'git' (qui est utilisé pour organiser mes règles cfengine) ne supporte pas le changement de nom des fichiers/répertoires et je perdrais l'historique des changements avec 'git mv'.

Répondre

0

Pour référence: https://groups.google.com/forum/#!topic/help-cfengine/ba5i_1UXPrU

Les variables connexion sont développées par cf-serverd lorsque les clients se connectent. Dans le cas de connection.hostname, la variable se développe dans le nom d'hôte de l'agent de connexion comme déterminé par une recherche DNS inverse de cf-serverd. Donc, vous devez vous assurer que vous avez une bonne résolution de DNS inverse afin de l'utiliser. Si, au lieu d'organiser les fichiers par nom d'hôte, vous les organisé par sha clé que vous devriez être en mesure de permettre à chaque accès hôte à son propre répertoire en utilisant quelque chose comme ce qui suit:

bundle server my_special_access_rules 
    { 
    access: 
     # /srv/cfengine3/MD5=0a9082478b1a1466f6e56fd5e48db8c4/directory full of files 
     "/srv/cfengine3/$(connnection.key)" 
      shortcut => "host_cfinput", 
      admit_keys => { $(connetion.key) }; 
    } 

Et puis dans un faisceau agent que vous pouvez faire ceci:

bundle agent have_a_copy_of_my_files 
    { 
    files: 
     # Using the shortcut 
     "/tmp/myfiles/." 
      copy_from => remote_dcp("host_cfinput", $(sys.policy_hub)), 
      depth_search => recurse(inf); 

     # Without using the shortcut 
     "/tmp/another_myfiles/." 
      copy_from => remote_dcp("/srv/cfengine3/$(sys.key_digest)/.", $(sys.policy_hub)), 
      depth_search => recurse(inf); 
    } 

maintenant vous pouvez avoir un répertoire pour chaque hôte /srv/cfengine3/ du nom de la clé publique sha de l'hôte. Chaque hôte est seulement autorisé à accéder à son propre répertoire depuis que vous avez mappé le répertoire à l'admit_keys dans une relation 1: 1.

+0

merci pour cette idée mais je n'aiment pas avoir la clé dans le chemin. J'ai mis à jour ma question avec des détails. – ensc

0

Comme il a été tourné out que cf-serverd ne supporte pas ces faisceaux, je tends à mettre en œuvre ce par itérer sur les listes:

bundle server host_list { 
    vars: 
     "keymap" data => parsejson(' 
     { 
     "foo.example.com" : ["MD5=362c5fcf568b492f78ae392229299c05"], 
     }'); 

     "hosts" slist => maparray("$(this.k)", keymap); 

    access: 
     "/srv/cfengine3/$(hosts)" 
     admit_keys  => { $(keymap[${hosts}]) }; 

     "/srv/cfengine3/KEYS/$(hosts)" 
     admit_keys  => { $(keymap[${hosts}]) }; 
} 

Les raccourcis peuvent être définis par

 "/srv/cfengine3/$(connection.hostname)" 
     admit_hostnames => { }, 
     shortcut  => "host_cfinput"; 

Il semble important qu'une étiquette admit_hostnames soit présente; sinon $(connection.hostname) n'est pas développé.

1

Pour référence: https://groups.google.com/d/msg/help-cfengine/ba5i_1UXPrU/xaWciJoIDQAJ

bundle server my_host_access_rules 
{ 
    vars: 
    # You can build a map of hostname to keys. 
    # You might prefer to do this in an external data file formated as 
JSON and 
    # use readjson to read it in. 
    # 
    # { 
    # "hub":  "SHA=e...", 
    # "host001": "SHA=b..." 
    # } 

    "name_to_key[hub]" string => 
"SHA=ee29780b3c86d486699f97e30c5924431475b1b06e02c2724dd925c1524afef6"; 
    "hosts" slist => getindices(name_to_key); 

    access: 
    # Grant access to the directory named for the currently iterated 
host to the public key sha for that host. 
    "/srv/cfengine3/$(hosts)/." 
     admit_keys => { "$(name_to_key[$(hosts)])" }; 
} 

J'ai testé cela sur une version préliminaire de 3.7.3 et je n'avais pas besoin d'avoir un nom d'hôte vide.

+0

l'existence d'un (admitjhostnames) vide (au moins) vide est intéressante pour le cas 'shortcut' avec $ (connection.hostname)' faisant partie du nom d'hôte. Je l'ai testé avec 3.8.1 seulement, pas avec 3.7.x – ensc

+1

Je me méfierais en utilisant le raccourci en développant toutes les variables non connectées que vous attendez de différer entre les agents de connexion pour le chemin donné. –

0

Essayez ceci:

bundle server host_list { 
    vars: 
     # Each host should only have one key 
     "keymap" data => parsejson(' 
     { 
      "foo.example.com" : "MD5=362c5fcf568b492f78ae392229299c05", 
     }'); 

     "hosts" slist => getindices(keymap); 

    access: 
     "/srv/cfengine3/$(hosts)" 
     admit_keys  => { $(keymap[${hosts}]) }; 

     "/srv/cfengine3/KEYS/$(hosts)" 
     admit_keys  => { $(keymap[${hosts}]) }; 
}