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 = [EMAIL PROTECTED] from = [EMAIL PROTECTED] to = [EMAIL PROTECTED] 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 _______________________________________________ smokeping-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
