Wie parametrisierte Bundles in cf-serverd verwenden?

Question

In meinem cf-serverd des promises.cf habe ich ein Bündel wie

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

Ich habe versucht, es instanziieren mit

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

Aber (mit cfengine-3.8.1) das scheint nicht zu haben ein Effekt. Z.B. cf-serverd -v meldet nur die Zugriffsregeln im Paket generic_rules und der Zugriff auf die Dateien von foo.example.com wird verweigert.

generic_rules (das ist ein einfaches bundle server generic_rules { ... } Bündel) scheint ausgewertet zu werden, wenn nicht die gemeinsame bundlesequence aufgeführt.

Wie kann ich das host_rules Bundle im cf-serverd Setup erweitern?

EDIT:

I Absicht Zugriff auf einige Verzeichnisse zu einem entsprechenden Host nur, das durch seinen Schlüssel identifiziert wird. Ich weiß, dass es möglich ist, $(connection.key) im Pfadnamen zu verwenden, aber nicht mag es, weil

• es unlesbar ist (Dutzende von Verzeichnissen mit sinnlosen MD5=... Namen macht es schwierig das Verzeichnis gehört, zu ‚foo.example finden .com ')

• es schafft Probleme, wenn Client Key ändert (zB weil es kompromittiert wurde oder weil Host neu installiert wird). 'git' (das ist verwendet, um meine cfengine Regeln zu organisieren) unterstützt nicht umbenennen von Dateien/Verzeichnisse und ich würde Geschichte der Änderungen mit 'git mv' verlieren.

Answer 1

Zum Vergleich: https://groups.google.com/forum/#!topic/help-cfengine/ba5i_1UXPrU

Die Verbindungsvariablen von cf-serverd erweitert werden, wenn Clients verbinden. Im Fall von connection.hostname wird die Variable auf den Hostnamen des Verbindungsagenten erweitert, wie durch Reverse-DNS-Lookup von cf-serverd bestimmt. Sie müssen also sicherstellen, dass Sie die richtige Auflösung der umgekehrten DNS haben, um das zu verwenden. Wenn stattdessen die Dateien, die von Host-Namen der Organisation, können Sie sie durch Schlüssel sha organisiert sollten Sie in der Lage sein, jeden Host-Zugriff auf ein eigenes Verzeichnis zu erlauben, so etwas wie die folgenden verwenden:

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) }; 
    } 

Und dann in einem Mittel bündeln Sie tun können dies:

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); 
    } 

Jetzt können Sie ein Verzeichnis für jeden Host in /srv/cfengine3/ für den öffentlichen Schlüssel sha des Host-Namen haben. Jeder Host darf nur auf sein eigenes Verzeichnis zugreifen, da Sie das Verzeichnis den admit_keys in einer 1: 1-Beziehung zugeordnet haben.

Answer 2

Wie es out gedreht wurde, dass cf-serverd nicht solche Bündel nicht unterstützt, ich bin dazu neigt, diese über Listen von Iterieren zu implementieren: kann

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}]) }; 
} 

Shortcuts von

definiert werden

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

Es scheint wichtig zu sein, dass ein admit_hostnames Tag vorhanden ist; sonst wird $(connection.hostname) nicht erweitert.

Answer 3

Zum Vergleich: 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)])" }; 
} 

Getestet habe ich diese auf einem Pre-Release-Version von 3.7.3 und ich brauche nicht einen leeren Host-Namen haben.

Answer 4

Versuchen Sie folgendes:

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}]) }; 
}