forked from ungleich-public/cdist
cdist configuration management
Latest manual: https://www.cdi.st/manual/latest/
Home page: https://www.cdi.st
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
54 lines
1.5 KiB
54 lines
1.5 KiB
Explorer |
|
======== |
|
|
|
Description |
|
----------- |
|
Explorers are small shell scripts, which will be executed on the target |
|
host. The aim of each explorer is to give hints to types on how to act on the |
|
target system. An explorer outputs the result to stdout, which is usually |
|
a one liner, but may be empty or multi line especially in the case of |
|
type explorers. |
|
|
|
There are general explorers, which are run in an early stage, and |
|
type explorers. Both work almost exactly the same way, with the difference |
|
that the values of the general explorers are stored in a general location and |
|
the type specific below the object. |
|
|
|
Explorers can reuse other explorers on the target system by calling |
|
|
|
:: |
|
|
|
$__explorer/<explorer_name> (general and type explorer) |
|
|
|
or |
|
|
|
:: |
|
|
|
$__type_explorer/<explorer name> (type explorer). |
|
|
|
In case of significant errors, the explorer may exit non-zero and return an |
|
error message on stderr, which will cause cdist to abort. |
|
|
|
You can also use stderr for debugging purposes while developing a new |
|
explorer. |
|
|
|
Examples |
|
-------- |
|
A very simple explorer may look like this:: |
|
|
|
hostname |
|
|
|
Which is in practise the **hostname** explorer. |
|
|
|
A type explorer, which could check for the status of a package may look like this: |
|
|
|
.. code-block:: sh |
|
|
|
if [ -f "$__object/parameter/name" ]; then |
|
name="$(cat "$__object/parameter/name")" |
|
else |
|
name="$__object_id" |
|
fi |
|
|
|
# Expect dpkg failing, if package is not known / installed |
|
dpkg -s "$name" 2>/dev/null || exit 0
|
|
|