[Orca-users] Re: Multiple hosts

[Darren Dunham]

>
> What is the correct way to send data that orcallator collects from
> multiple hosts to a centralized location? Just use NFS?

Orca doesn't handle that question at all.  It just runs and expects to
see the files.

NFS is fine, or you could use something like rdist/rsync/SAMBA.

It's best if orca have pretty fast access to it, so you may not want to
have orca read from a remote NFS server, but that's probably better than
having orca write the RRDs and HTML to a NFS server.

At the moment, my source files are on NFS shares from the clients, but
RRDs and HTML are local.  My first priority is in getting the box a
little beefier, but after that I'll probably work on putting in some
rsync stuff to move the files around.

> Is there a built-in functionality to send new data to the host that
> creates graphs via some sort of daemon that runs on it and listens
> for incoming connections with new data?

No.  Nothing like that.  I can imagine something like that, but once you
start talking networking services, you start talking privacy and
authentication issues too.  At the moment, buy not doing it at all,
users have the obliga^H^H^H^H^Hopportunity to use whatever they're
comfortable with.

> (BTW, is this a topic for the orca-developer group?)

If you're talking about changing orca to do the above, yes.  However I
think you'd need to have a very good reason for doing so.  I'm guessing
it would simply be a lot of work to integrate it into the current 'orca'
program.

Of course, you could develop and run a new (separate) daemon that reads
the orca configuration file and accepts the data and writes to the
source files.  Then users could choose to run it or not as need be.
Again, I think such a program would have to have advantages beyond
scripting up a 'rsync' over 'ssh' bit before you'd bother. 

The main "problem" with doing rsync/ssh is getting them set up properly
for the first time.  If you've never used them, it could be frustrating.
A separate client/server program set and protocol could be easier for
users to set up and use, but would presumably have more "security" style
issues.

--
Darren Dunham                                           ddunham at taos.com
Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >