forked from ungleich-public/cdist
180 lines
5.2 KiB
Text
180 lines
5.2 KiB
Text
Rethinking ideas of last talk.
|
|
|
|
What if types are formal / have formal arguments?
|
|
What if cdist can do all the parsing stuff and the real
|
|
functionality comes out of the library (similar to cfengine)?
|
|
|
|
What if the library is integral part of cdist?
|
|
|
|
|
|
conf/lib/$name/
|
|
attributes/
|
|
a
|
|
b
|
|
c
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
I'm not sure whether this design is in fact helpful.
|
|
But it's clearly necessary to have a directory per type, so a type can
|
|
have helpers.
|
|
|
|
|
|
conf/lib/$name/
|
|
init?
|
|
|
|
|
|
Prepare some very minimal (non functional) framework for library integration?
|
|
Like parsing for command line arguments?
|
|
|
|
--------------------------------------------------------------------------------
|
|
Real configurations versus types:
|
|
|
|
Types are reusable code: For instance etc_resolv.
|
|
|
|
Configurations are types used and configured.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Style
|
|
|
|
__type <id> --option1 <arg1>
|
|
|
|
<id> = everything your filesystem permits, but may not start with a period (".").
|
|
If <id> == ., it setups the standard attributes.
|
|
|
|
seems to be quite good usable. cdist can easily -----parse--- this.
|
|
|
|
Nope. We don't parse. We let the shell execute.
|
|
|
|
So whatever is __type will get executed.
|
|
|
|
__type must probably be part of some cdist specific path.
|
|
|
|
Which again could be
|
|
|
|
conf/lib/$name
|
|
|
|
Which could result in the directory
|
|
|
|
conf/lib/.$name for helpers
|
|
|
|
That style could include a mandority --help, --args arguments
|
|
and would thus be independent of the language used (can, but does
|
|
not must be shell).
|
|
|
|
How to solve standard configurations that way?
|
|
|
|
EASY AS WELL!
|
|
|
|
__type <either option or magic> --option1 <arg1>
|
|
|
|
for instance
|
|
|
|
__type . --option1 <arg1>
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
Type paths
|
|
At least (at maximum)? 2:
|
|
user + system
|
|
|
|
Easy to do.
|
|
|
|
--------------------------------------------------------------------------------
|
|
Types: Name types types or name types modules?
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
Where to place/start the configuration?
|
|
|
|
wherever it is: name it configuration!
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
cdist installation / paths:
|
|
|
|
/etc/cdist/ # CDISTBASEDIR
|
|
config/ # CDISTCONFIGDIR
|
|
types/ # CDISTUSERTYPEDIR
|
|
|
|
$prefix/lib/cdist/types/ # CDISTSYSTYPEDIR
|
|
|
|
|
|
cdist environment:
|
|
$__loaded_from # path where $type has been loaded from
|
|
PATH=$CDISTUSERTYPEDIR:$CDISTSYSTYPEDIR:$PATH
|
|
|
|
--------------------------------------------------------------------------------
|
|
Recommendation (not a must):
|
|
Put helpers for types into the typedir/.$typename
|
|
|
|
All types should be prefixed by "__" to prevent clashes with the system
|
|
binaries.
|
|
--------------------------------------------------------------------------------
|
|
Type commands (__bla) could get generated by cdist and cdist could use that
|
|
to generate the actual cconfig part.
|
|
|
|
This leads up to the next section
|
|
|
|
--------------------------------------------------------------------------------
|
|
How to write my own type named "coffee":
|
|
|
|
Create the directory /etc/cdist/types/coffee/
|
|
Create the file /etc/cdist/types/coffee/README containing a description of the type.
|
|
If your type supports attributes, create the directory /etc/cdist/types/coffee/attributes.
|
|
For each attribute, create the file
|
|
/etc/cdist/types/coffee/attributes/$attribute_name which contains
|
|
|
|
a short description on the first line
|
|
then a blank line
|
|
then a long description (probably over several lines)
|
|
|
|
If you think your type may be useful for others, submit it for inclusion
|
|
into cdist at cdist -- at -- l.schottelius.org.
|
|
|
|
Create /etc/cdist/types/coffee/init which reads $configinput
|
|
(either via cconfig or via environment) and outputs a block of
|
|
shell code suitable for running on the client.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
cdist exec steps:
|
|
|
|
- check for valid types, abort if user (re-)defined system types
|
|
- generate __type binaries (aliases?), which contains cdist logic
|
|
to analyse types and check for correct arguments
|
|
- execute /etc/cdist/config/init (MAIN CONFIG) which in turn
|
|
calls __type binaries
|
|
- __type binaries (which are all the same, multicall!) generate
|
|
cconfig
|
|
- Run real type/init binaries with respective cconfig dir as path,
|
|
which must generate shellcode to be executed.
|
|
- Create the temporary shellscript containing all the code and execute
|
|
it on the client.
|
|
|
|
--------------------------------------------------------------------------------
|
|
Support metaargs like --depends?
|
|
If so, they need to be forbidden for types.
|
|
--------------------------------------------------------------------------------
|
|
Shell code generator:
|
|
|
|
- use subshells for each shellcodeblock
|
|
- create one main function (to ensure transfer is complete)
|
|
|
|
Example:
|
|
|
|
cdist_apply_$hostname()
|
|
{
|
|
|
|
# repeat this block for every type/id defined
|
|
echo "Executing block from $type_$id ..."
|
|
(
|
|
code
|
|
)
|
|
|
|
}
|
|
|
|
cdist_apply_$hostname
|