Dear all:

Just to let you know, I've come up with a patch to de-couple the
web-frontend from the gmetad server, the patch is available here:

http://therealms.org/oss/ganglia/ganglia-web-decouple.patch

Patch was done against 3.1.7.

Here's how to setup RRD Server and apply the patch:

1) Make sure your version of RRDTool supports running as a server, man
rrdtool and look for "RRD Server"
2) Add the rrdsrv entry to /etc/services as indicated in the manpage
3) Create an entry for rrdsrv for inetd, the following can be placed
in /etc/inetd.d (or wherever your inetd configuration files are
located):

service rrdsrv
{
        disable         = no
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rrdtool
        server_args     = - /var/lib/ganglia/rrds
        cps             = 100 30
        only_from       = <ip of your web frontend>
}

* Put the ip address of your web frontend in "only_from"
* Adjust "cps" as necessary

4) Test by telneting to RRD Server at port 13900

Now that the RRD Server is setup, it's time to patch the frontend code:

1) Make a copy of your frontend code, eg. cp /var/www/html/ganglia
/var/www/html/ganglia.decouple
2) Download the patch to  /var/www/html/ganglia.decouple
3) cd into the directory and run `patch -p0 < ganglia-web-decouple.patch`
4) Edit conf.php and change $ganglia_ip and $rrdserv_port to the IP of
your gmetad server and the RRD Server port (13900) respectively
5) Edit gmetad.conf and make sure that the webserver is in
"trusted_host" directive
6) Re-load gmetad

That should be it!  Check your httpd error logs if things don't work properly.

For those interested in the technical details, I have created 2 new
functions to abstract calls relating to RRDTool:

1) rrdtool_exec()
2) rrd_exists()

Please refer to the comments for more information regarding what they
do specifically.

Again, I must stress that there is NO authentication between the
frontend code and the RRD Server, other than the directive only_from
which restricts only the frontend IP can communicate with the RRD
Server at the specified port, so please only use in a "safe"
environment.

Comments welcome, even just to say you've tried it and it works.

Thanks,

Bernard

On Wed, Mar 10, 2010 at 11:59 AM, Bernard Li <bern...@vanhpc.org> wrote:
> Hi Eric:
>
> On Wed, Mar 10, 2010 at 7:37 AM, Eric Shubert <e...@shubes.net> wrote:
>
>> That's great news to me. This was one of the questions I had when I
>> first learned about ganglia.
>>
>> I've recently begun using ganglia to monitor several vmware hosts and
>> guests, and am very much interested in this type of configuration. I
>> would like to keep the data collection on the vmware hosts/guests, but
>> run the frontend on a separate (remote) host.
>>
>> What are the security implications?
>
> From the man page of rrdtool for "RRD Server":
>
> "NOTE: that there is no authentication with this feature! Do not setup
> such a port unless you are sure what you are doing."
>
> It does run rrdtool in a chroot (usually the root directory where your
> rrd files are located, i.e. /var/lib/ganglia/rrds), however, since
> there is no authentication, the port is basically wide open meaning
> out of the box folks on the network could do things like "ls" and
> "mkdir" in the root directory.
>
> It would be nice if we could add the functionality of restricting
> certain commands from being executed remotely, much like the -P
> feature of rrdcached.
>
> Cheers,
>
> Bernard
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general

Reply via email to