|
|
This is a proposal of new Knot feature: a system of (named) pipes, as a substitute for direct calling of user scripts from knotd process.
|
|
|
|
|
|
The user might want to call a script when an event occurs. First motivation for this is publishing CDS/CDNSKEY records - the user shall react with updating DS record at the parent zone.
|
|
|
|
|
|
The configuration might look like follows:
|
|
|
```
|
|
|
event:
|
|
|
- fifo: /my/scripts/knot_hok_ds.fifo
|
|
|
action: publish_ds
|
|
|
```
|
|
|
and the user script like this:
|
|
|
```
|
|
|
cat /my/scripts/knot_hok_ds.fifo | while read x; do
|
|
|
perform_action "$x"
|
|
|
done
|
|
|
```
|
|
|
|
|
|
Some notes to this solution:
|
|
|
- this avoids `system()` or `popen()` calls by knotd which are known to be very evil
|
|
|
- this avoids active waiting at the script side (would be harmful if many zones)
|
|
|
- `O_NONBLOCK` has to be used at knotd side. If no script is listening on the configured fifo, knot just logs a warning
|
|
|
- just one script can listen at a fifo. However, it is possible to configure more fifos for any set of possible event actions
|
|
|
|
|
|
Some suggestions:
|
|
|
- the emitted action request consists of a single line (terminated with `\n`), with fields separated by colon `:`, fields are: zone, action type, data ... do we need a timestamp?? can colon conflict with zone name or data???
|
|
|
|