[smokeping-users] Do I need multiple instances to have smokeping maintain separate URLs?

[James Long]

On Sat, Mar 24, 2007 at 11:23:12AM +0100, Tobi Oetiker wrote:
> 
> the trick is to run multiple instances of smoekping.cgi with
> different config files ...
> 
> using @include you can setup a system where you have a single
> smokeping daemon and multiple smokeping.cgi instances ...
> 
> cheers
> tobi


Thank you for your reply.

All: In respect for Tobi's time, please -- if other knowledgeable 
smokeping users can step in and correct my mistaken assumptions, 
please do.  This is by no means a private conversation.

Also, please note that while I am making seemingly factual statements, 
I am just stating my understanding.  I fully expect and welcome 
corrections, and users who may find this message in an archive
should not construe any validity to my stated assumptions.  Many of 
them surely will be incomplete, oversimplified, and/or wrong.

I'm afraid I'm not a perl person, which is why I had hoped this could 
be done either within a single config file, or by simple modifications 
to per-instance config files with no modifications to the smokeping 
source.  Given that this goal may not be possible, I am designing
a way to run multiple smokeping instances with the minimum number
of hacks to the source.

Please bear with me while I restate my rudimentary understanding of 
the way smokeping works, to make sure that I'm starting out on sound 
footing.  It helps my confidence when I know that what I'm planning 
has a chance of working!  :)

Also note that my file paths will be for BSD, if that matters.

Here goes:


Smokeping has two parts: the daemon that executes probes and stores
the result in the RRD database; and the web CGI that responds to
HTTP requests to navigate and display the accumulated statistics
on the client's web browser.  I'll refer to these as the daemon, and 
the CGI, respectively.  For now, I will disregard the rc.d start-up
script, although that will need per-instance customizations also.
I am also ignoring smokemail, and possibly other bits I do not use at 
present.


The daemon has a straight-forward command-line switch to specify the
config file to use:  --config=/path/to/file.  By using a separate
config file for each instance, it is possible to use the same
daemon executable, while storing probe results in segregated areas.
Separate instances of the CGI can then read stats from its corresponding
area, and generate graphs and HTML without overwriting graphs and
HTML generated from another instance's RRD databases by other 
instances of the CGI.  Actually, it appears that the CGI does not
store any HTML.  It just generates it on the fly.  Only the graphs
are stored, and even so, some graphs are generated on the fly, such
as when one "zooms in" on a specific time range of a graph.  True?


The following variables in the config file MUST be unique for each
instance (XX shows where an instance-specific string would be used
to ensure uniqueness):

imgcache = /usr/local/smokeping/XX-htdocs/img
imgurl   = /XX-smokeimg
datadir  = /usr/local/var/XX-smokeping
piddir  = /usr/local/var/XX-smokeping
cgiurl   = http://example.com/XX-smokeping/smokeping.cgi

Nit picks: 

- in imgcache, it's the htdocs directory that must be instantiated,
as there are other things that get stored beneath there, not just
the img directory.

- the cgiurl can be instantiated a number of ways.  If only one
instance is needed per virtual host, then effectively the "example.com"
(the virtual web hostname) becomes the unique string, and there is
no need for XX- in the URL.

- there are many ways to place the XX- in paths, with different
trade-offs, such as /usr/local/var/smokeping/XX/ for datadir, or
/usr/local/smokeping/XX/htdocs/img, or even placing htdocs img
and var all under a single /usr/local/smokeping/XX:
 
/usr/
  local/
    smokeping/
      XX/
        htdocs/
        img/
        var/

to keep all of instance XX together.  Is there any reason to
prefer one style over another?  I chose XX- over XX/ just to do
less cd-ing.  The last example would make cloning and deleting
instances pretty convenient, to be able to cp or rm a whole
directory to add or remove an instance.  Hopefully adding/
deleting instances will be infrequent.  Moving var has impacts
on the rc.d startup script and its PID file logic.


Some variables MAY be unique, but need not be:

Owner    = Ex Ample
contact  = support at example.com
from = XX-smokealert at example.com
to = XX-smokeadmin at example.com
tmail = /usr/local/etc/smokeping/tmail
syslogfacility = local0
(and probably lots of others)


Some variables NEED NOT be unique, and may be shared by any or all 
smokeping instances without ill effects:


mailhost = localhost
sendmail = /usr/sbin/sendmail
# specify this to get syslog logging
binary = /usr/local/sbin/fping
(and most any other custom binary, provided that it doesn't do 
something dumb like name temporary files in such a way that 
collisions are possible.  But with parallel probles, that would 
cause problems in even one instance, no?)

Sharing probe binaries has the advantage that one can write/install
a custom probe once, then use it in any number of concurrent smokeping 
instances.

That's about all I can see in the rudimentary config file I use.


The smokeping daemon is trivial to instantiate, because it has a 
command line option to specify the config file.  All files in 
/usr/local/smokeping/lib/ can be shared by any and all instances
of the daemon AND the CGI with no conflicts.


The CGI has no mechanism to allow the caller to pass it a config file 
name.  The config file name is hardcoded into the CGI source code.
However, since the CGI is installed in smokeping's htdocs directory,
and the htdocs directory is instantiated, each instance gets its
own copy of the CGI stored in /usr/local/smokeping/XX-htdocs/.
A local diff(1) file can be maintained for each instance, to track
the changes of that specific instance compared to the source 
distribution, and used to hack the config file name in each copy of 
the CGI.  Again, I don't know perl -- surely there is a more elegant 
way?


Once one has instantiated the CGI by passing a config file specific
to each instance, multiple simultaneous copies of the CGI can run
without conflict, because they are reading RRD data from separate
instances of $datadir and writing HTML and graphs to separate
instances of $imgcache.


Obvious bits I've omitted would be that the web server must also
instantiate the URL for each instance of the CGI, and map the
appropriate URL to the corresponding filename of the CGI.  Apache
has no problem with this, something like:

    ScriptAlias /smokeping/smokeping.cgi /usr/local/smokeping/XX-htdocs/smokeping.cgi
    Alias /XX-smokeimg/ /usr/local/smokeping/XX-htdocs/img/

included in each customer's virtual host definition should do.
If multiple instances are to have URLs in a single virtual domain,
then that might have to become:

    ScriptAlias /smokeping/XX-smokeping.cgi /usr/local/smokeping/XX-htdocs/smokeping.cgi
    Alias /XX-smokeimg/ /usr/local/smokeping/XX-htdocs/img/
    ScriptAlias /smokeping/YY-smokeping.cgi /usr/local/smokeping/YY-htdocs/smokeping.cgi
    Alias /YY-smokeimg/ /usr/local/smokeping/YY-htdocs/img/
    ScriptAlias /smokeping/ZZ-smokeping.cgi /usr/local/smokeping/ZZ-htdocs/smokeping.cgi
    Alias /ZZ-smokeimg/ /usr/local/smokeping/ZZ-htdocs/img/

As said above, if one can guarantee that a single virtual domain will 
have at most one instance of smokeping, then $imgurl would
not have to be instantiated, and the Apache Alias line could be just:

    Alias /smokeimg/ /usr/local/smokeping/XX-htdocs/img/


So am I on the right track here?  Do any of these assumptions hold?
What have I missed?

My chief concern is that this be maintainable.  Specifically, when I
upgrade smokeping, I don't want to have to worry about patching a lot
of executables if I don't have to.  As currently described, I'm still
going to have to maintain a "smokeping.cgi.diff-XX" for each instance,
and clone and patch a lot of copies of smokeping.cgi, but that's 
easy to script.  If I knew more perl, perhaps there'd be a way to 
write  each instance of smokeping.cgi as just a wrapper around the One 
True smokeping.cgi that comes from the source distribution.  That task 
is beyond my perl skills at the present.


Thank you for reading this far, and for your generous assistance.

Jim