Changes between Version 1 and Version 2 of Dingbot
- Timestamp:
- 09/20/13 21:17:05 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Dingbot
v1 v2 9 9 = Background = 10 10 11 Dingbot's purpose is to run on a newly-provisioned node, and do any one-time setup tasks that aren't otherwise done for you automatically. To use it, you'd put something like 12 11 Dingbot's purpose is to run on a newly-provisioned node, and do setup tasks that aren't otherwise done for you automatically. To use it, you'd put something like 13 12 14 13 {{{ 15 14 <services> 16 <install url="CONFIG-URL" install_path="/ tmp" />17 <install url="DINGBOT-URL" install_path="/ tmp" />18 <execute shell="/bin/bash" command="sudo / tmp/dingbot/dingbot CONFIG-FILE HOSTNAME"/>15 <install url="CONFIG-URL" install_path="/opt" /> 16 <install url="DINGBOT-URL" install_path="/opt" /> 17 <execute shell="/bin/bash" command="sudo /opt/dingbot/dingbot CONFIG-FILE HOSTNAME"/> 19 18 </services> 20 19 }}} … … 33 32 = Operation = 34 33 35 The script starts by checking for the presence of a /.dingbot-done file (and just prints a message and exits, if one exists), and finishes by creating that file, so it should only ever actually do anything once, even though it runs every time the node boots. If it does do anything, it logs to `dingbot-{output,errors}-$TIMESTAMP.log` files in `/var/log`.36 37 34 The simplest way to see what it does is to look at the code, which is commented in astonishingly verbose detail. 38 35 … … 41 38 = Configuration = 42 39 43 Dingbot uses a JSON configuration file to specify things that different experimenters might want to do differently, such as set up certain user accounts, or install certain software packages. You can also use it to do different things on different nodes in your experiment: If you always want to do the same things on all your nodes, you can use the same config file in all of your rspecs; or if you want different things on different nodes, you can have as many different config files as you want, just put the appropriate URL into the appropriate `<node>` section in each rspec. 40 Dingbot uses a JSON configuration file to specify things that different experimenters might want to do differently, such as set up certain user accounts, or install certain software packages. You can also use it to do different things on different nodes in your experiment: If you always want to do the same things on all your nodes, you can use the same config file in all of your rspecs; or if you want different things on different nodes, you can have as many different config files as you want, just put the appropriate URL into the appropriate `<node>` section in each rspec. There's also a general pre- and post-execution hook where you can put an arbitrary command (which could run a script full of arbitrary commands). 44 41 45 42 Because the `<install url=...>` element expects a .tar.gz file, the config file also needs to be in a tarball. … … 49 46 {{{ 50 47 { 48 "prehook": "touch -r /etc/issue /.dingbot-pretest", 49 "posthook": "touch -r /etc/issue /.dingbot-posttest", 51 50 "packages": [ "fping", "iperf", "rsync", "sudo" ], 52 51 "users": … … 85 84 Dingbot makes various simplifying assumptions about its environment; see the code for more details. (The word "FIXME" is a good indicator.) 86 85 87 One significant limitation of Dingbot is that i t only runs once, so if it encounters any transient failures (e.g. it can't install software packages because the node temporarily can't reach the package repo, for whatever reason), it doesn't automatically retry or anything. Using a real system configuration management system (like Cfengine, Puppet, Chef, Salt, etc) could make this more robust.86 One significant limitation of Dingbot is that if it encounters any transient failures (e.g. it can't install software packages because the node temporarily can't reach the package repo, for whatever reason), it doesn't automatically retry or anything. Using a real system configuration management system (like Cfengine, Puppet, Chef, Salt, etc) could make this more robust. 88 87 89 88 Other more comprehensive experimenter tools include post-boot scripts as well, and do everything Dingbot does and a whole lot more. It was originally written to make life easier for one casual amateur experimenter, and isn't really intended to be a comprehensive solution for a wide range of people. But if it helps you use GENI, or serves as a starting point for your own ideas, or just amuses and entertains you, all the better.
