Just some thoughts on hostname/cert lookup stuff
current state
- certs are named after what the minion decides is it's hostname
- store in a flat directory
- cert name -> hostname mappings are 1:1
- globbing for a hostname is essentially just file glob against the
directory of certs names
- groups are simple definations of groupname and list of hosts in group
in /etc/func/groups
- aliases can also be defined (basically, a single entry group)
Pros:
- it's simple
- works for "most" cases
- easy for other tools to see what hosts a overlord would know about
Cons:
- no way for an overlord to know multiple names for a minion (aside
from manually adding aliases)
- [though, it would be possible for say, a minion to report all the
hostnames it knows about, and for certmaster/overlord to create
aliases automtically]
- If certs are not named after the hostname, overlord doesn't work. Mostly
an issue if using non func certs (say, puppet certs)
- cert/hostname stuff is Yet Another List Of Systems that doesn't really
integrate with any existing system lists (be it LDAP, etc)
Some possible approaches
1. abtract away the hostname/cert lookup bits and make it pluggable
- not exactly sure what this api will look like
2. make the above api a chain, so we could do say, DNS lookups, matches
against the local cert db, matches against some other cert directory,
match against LDAP, match against aliases and groups, etc
The above sounds alot like normal NSS setups, so that may be one approach
Doing the "func name" (aka, func "funcname") to certname to hostname mapping
will require some sort of rudimentary db/config file. Simplest case probably
just some sort of config file. Would need to replicated to any hosts that
are acting overlords (much like the certs need to be replicated now).
Any thoughts? Suggestions on what the API should look like?
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
