general coding rules
- all is in perl language
- use warning and the strict pragma
- declare subroutine's prototype and use them (avoid calls with &)
- exit, die subroutines are forbidden
- try to avoid external dependencies (perl modules or external programs)
- avoid non portable code (on Unix)
- use perltidy to indent and reformat perl script
- use perlcritic to check for bad perl code
you should also have a look at the
Writing Webmin Modules
general module rules
- do not write 'static' modules (cpu), only dynamic ones (load)
- if possible, do not use DERIVE database type : actions are not available on such parameters
- if computing is necessary, make it in aquisition script, not in graph (rrd computing)
- be simple : on config line for one rrd file, and one parameter
acquisition script : module.pl
Begin with the acquisition script. Do not care about rrdtool : just write a perl script which return the parameter, you want to monitor.
Just a hint : do not use the "die" command.
You can stop here and send me your script if you want : almost all the work is done.
If you want to continue, have a look at other acquisition scripts, such as or load.pl (load module), or users.pl (user module) and copy their behavior:
- sysstats-aquisition-lib use (common subroutines)
- rrdtool use (RRDs)
- debug use (print for debugging)
if an operating system need a special acquisition script, you can name it ${module}.pl.${os} (look at netstat module). The module installation will install it before the classic one if os match.
specific coding rules
- no print : cron job should not send mail each minute
- debug messages are to be send by the "debug" subroutine
- messages for problems are to be send by the "warning" subroutine
cgi scripts : module-lib.pl
documentation
you have to first read :
- rrdtool and rrdtutorial man pages
- webminstats internals documentation
specific coding rules
- print function should not be used, except for html code
- debug messages are to be send by the "debug" subroutine
- messages for problems are to be send by the "warning" subroutine : be careful : a valid html page should be open
choose a model
then, you have to choose a model from existing modules :
- load : very simple
- filesopen : depens upon an external command
- ntp : multi-level parameters : host + name
- copy the choose directory to your new module name
- remove all subversion directories (.svn)
- change file names to match your module name
choose parameter database type
customize in your $(module)-lib.pl install_module or create_base subroutines :
choose your parameter database type (see rrdcreate man page):
- GAUGE : used for parameters such as temperatures
- DERIVE : used for growing parameters such as uptime (to avoid)
you have to choose the rra type $(module)-lib.pl general variable :
- AVERAGE : should be used in general
- MAX: for alarms
choose display type
customize in your $(module)-lib.pl graph_data subroutine
choose your parameter display type (see rrdgraph man page):
put default colors in
defaults.cfg file
module configuration
change mod_config and mod_config_save subroutines
icon
choose an icon, put it in images directory, and change module_icon in
module.info file
portability
customize os_support in
module.info file to match module portability.
for example module using /proc are restricted to Linux operating systems
translation files
one file by language :
- en for english (necessary)
- fr for french
- de for german
- es for spanish
- ...
help files
for each module, and for each language : 2 files :
- ${module}.${lang}.html : for display page
- config-${module}.${lang}.html : for configuration page
the default help (no ${lang} ) is in english
wbmtranslator
a new project
wbmtranslator" can help to find missing translations, and missing help files
back to main page
Page changed on 28 january 2011