Agent
The dux agent allows a host to regularly retrieve a tasklist from somewhere else and apply it to itself.
Pros and cons
Advantages
- hosts handle themselves, no need for a centralized server which can reach every machine, be compatible with everything (execution environments), have root-level access to every machine...
- hosts don't need to have an open port and an SSH server running behind it with some root-level user able to connect. Hosts stay simple clients as they should : they open some random port, initiate some connection protocol, get the tasklist from the server then close everything.
- no need for complex key managment (have server's key authorized everywhere, or play with multiple keys...) which can drive beginners to turn to classic username/password system, using same password everywhere, or even worse...
- you can replicate your tasklist to multiple servers, one per subnet for example, and have a better control over data flows through firewall rules and such
Disadvantages
- in a way, you loose the initiative on your hosts : if you want a new tasklist to be applied immediatly, you have to configure agents to check tasklist updates very often, which can be a burden for your network if you have many hosts. A compromise has to be found between tasklist checking frequency and networking ressources.
- you don't need to install an SSH server, have keys/hosts authorized and everything, but now you need to install the dux agent and configure it on every host. So, even if it's just installing a deb/rpm package and modifying a text file somewhere, preliminary work is still required.
TODO
Create a watcher which will be listening for hosts results. This watcher can be passed to agents as an endpoint where they can send their results, allowing the user to monitor which host did what. This way, we find back our centralized architecture but we avoid having SSH servers with root-level access everywhere.