The Module System
Extending the power of Jasager.
The module system is designed to allow users to write their own plug-ins for Jasager. To start small and simple it currently only allows extra features to be added to the drop down list in the associated clients table but it is built so that I can later extend it to add features to all the other areas of Jasager.
The concept is fairly simple, create your module, drop it in the scripts directory and make sure it responds to certain command line parameters. A Jasager script which is ran on start up will poll all the modules and collect the information required to build the drop down list. When a user choses an option from the list, Jasager knows which module to run and runs it passing parameters about the chosen client.
This is how it works in practise... The module must respond when called with the parameter --get_xml with an XML definition of itself in the format
<package>
<information>
<name>Script name</name>
<dropdown>Name to show in drop down list</dropdown>
<description>Description of module</description>
</information>
</package>So, for example, the echo script returns
<package>
<information>
<name>Echo</name>
<dropdown>Echo</dropdown>
<description>Echo back the arguments passed in</description>
</information>
</package>
On startup, Jasager calls all modules in the scripts directory passing the --get_xml parameter and then parses the results to create two files in /tmp, one to hold a mapping from script name to drop down position (script_name_list) and one a snippet of HTML which is included when drawing the drop down list (script_option_list).
When a user choses a module from the drop down the script is looked up in the script name list and then called with the parameters MAC address, SSID and, if the client has an IP address the IP address as the third parameter. Again, using the echo module as an example, it would be called like this
/karma/scripts/echo 32:46:32:B6:AE:B2 DummySSID 192.168.0.14
If the script wants to communicate back to the user it needs to write to the status log in /tmp/status.log. An idea for the future is to have multiple logs and have a tabbed log browser to allow noisy modules to have their own log.
For modules which are larger than a single file all they need to do is to place a stub in the scripts directory which returns the XML and passes the parameters through to the rest of the module when called. The rest of the module can live either in a different directory or even on a remote device, I see this functionality being used to call Nessus on a remote box to do a scan of the client.
If you add a new module while Jasager is running you can update the module list by calling /karma/bin/create_option_list.rb.
Finally, as the modules accept the same parameters as the auto-run scripts they can also be sym-linked into the /karma/etc/rc.assoc and /karma/etc/rc.dhcp directories so they are ran as soon as the client associates or is given an IP address.
RSS