Software ↑
Config
Download
Install
Modules
Procmon
Scriptlets
Security
Usage
This is the really funny part :-)
You can extend the functionality of nabou by writing "inline scripts", (I name them "scriptlets" from now on). All of this stuff is done inside the nabou configuration file. You can define any number of scriptlets. After defining a scriptlet you can refer to it by using the directory block option
chk_custom name
The parameter to chk_custom must be the name of a defined scriptlet. nabou will call this scriptlet on every file within a directory. That means, you need to refer to a scriptlet on a per-directory basis. See the example below.
The scriptlet itself must be written in valid perl5. nabou will save this code in an anonymous sub and call it using a closure. This sub will get 3 arguments from nabou, a File object, the current directory and a string containing the current message for the current file.
If the message is empty no other check found something, if is is not empty it contains the explanation of what nabou already found about this file.
The File object needs some further explanation: You can access every file attribute by using the -> notation. Possible attributes are size, uid, atime and so on (see dbformat.txt for more available attributes).
Beside of these, there are two more attributes: filename and md5. filename returns the file name of the current file (the absolute file name!). md5 returns the checksum of the current file. This maybe a MD5 checksum but can also be SHA1 or MD2, which depends on your configuration(see use_algo above!).
If you want complete integration of the scriptlet into the nabou workflow, then you need to return a message, you don't have to print it just out to STDOUT!
One or more script(s) must be defined using the >. Inside the block you need to define the code using a so called here-document. The name of this here document must be the script-name followed by an end identifier after the magical << characters.
Nabou will read everything in until the end identifier occurs. There is no space, tabulator or anything else allowed after this identifier! The name that you give the scriptlet will be used later for referencing to, by using the chk_custom attribute in the directory block.
An example says it all:
--- snip ---
<script>
test <<EOF
my($file, $dir) = @_;
return "SIZE of " . $file->filename . ": " .
$file->size . " bytes\n";
EOF
</script>
<directory /tmp/test> chk_md5 1 chk_mode 1 chk_custom test </directory> --- snap ---
In this example nabou will run the following sub:
sub {
my($file, $dir) = @_;
return "SIZE of " . $file->filename . ": " .
$file->size . " bytes\n";
}
on every file it finds in /tmp/test.
Additional you access the complete global namespace of nabou. This is powerful, but also danger. But a really good use of this is that you can access the %config hash, which contains a data structure of the whole configuration. You could create your own configuration block, which will be used by your scriptlet! An example custom config block (which will simply ignored by nabou itself, but it will be loaded into %config!):
<test> user max pass nim9w port 31733 </test>
Inside your scriptlet you can access the values inside
$user = $config{test}->{user};
or
$pass = $config{test}->{pass};
There are two sciptlet names which have a special purpose: BEGIN and END. The BEGIN scriptlet will be executed only once at startup IF it exists, and the END scriptlet will be executed only once at the end respectively IF it exists. This is very usefull if you want to open e file or database, which your scriptlet(s) later can use.
An example:
<script>
test <<EOF
my($file, $dir) = @_;
print TEST " DIR: $dir\n";
print TEST "FILE: " . $file->filename . "\n\n";
return "";
EOF
BEGIN <<EOF
open TEST, ">/home/thomas/nabou/test" or die $!;
EOF
END <<EOF
close TEST;
EOF
</script>
<directory /usr>
chk_custom test
</directory>
As you can see, the "test" scriptlet, which will be executed for every file under /usr prints a line to a filehandle "TE". Under normal circum- stances this wouldn't be possible, because it were not opened somewhere before. But if you define a BEGIN scriptlet as in the example above, which opens this filehandle, then the "test" scriptlet can access this handle.
A note about return values of scriptlets: If you don't want the scriptlet to cause a match, then you need to return an empty string:
return "";
otherwise it would be a match and appear in the nabou report!
If you want to share variables over different scriptlets, then you might use the special hash %my to store stuff in. You cannot define new global variables in scriptlets.
Invalid, not allowed example:
<script>
BEGIN <<EOF
$main::blah = 1;
EOF
blubb <<EOF
print "$main::blah\n";
EOF
</script>
In this example we are trying to define a global variable, but this $main::blah will be local to the "BEGIN" scriptlet in any case.
Instead you should do this:
<script>
BEGIN <<EOF
$my{blah} = 1;
EOF
blubb <<EOF
print "$my{blah}\n";
EOF
</script>
Do not define members in the %my hash with the my keyword. This has already been done in nabou itself for you.