RE: Alternative Data Transport In Big Brother?

"Trent Melcher" <[email protected]> Thu, 24 Apr 2003 11:18:56 -0500
Newsgroups gmane.network.bb4.devel
Message-ID <[email protected]>
Another alternative, you may want to look into, is if the admins at the
hospital/hospitals dont block high numbered port going out and its alright
with them you could change Big Brother to listen on a high numbered port,
granted you would have to change all the clients too to send out on this
port.  Just a thought though.

Trent

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Christopher Koelbl
Sent: Thursday, April 24, 2003 10:29 AM
To: [email protected]
Subject: Re: {bbd} Alternative Data Transport In Big Brother?


Thanks for the info.  Modifying bbfetch still seems like my best bet.  The
real trouble here is that in most cases, I have oneway ftp access available
to me, and that is from the hospital back to my central server.   Almost all
of the external scripts/modifications to BB that allow this type of thing
use a pull methodology originating from the central server.  I need to
create a push method where the central server just routinely polls for new
information that has come in.

--Chris

----- Original Message -----
From: "Nick Metrowsky" <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 23, 2003 4:29 PM
Subject: Re: {bbd} Alternative Data Transport In Big Brother?


> Hi Chris:
>
> Take a look at bb-central-1.5.tar.gz on ftp.deadcat.net. This Big
> Brother plug-in uses SSH (scp) to connect to a client host, gather the
> data, and processes the data on the central Big Brother host, i.e. will
> send e-mail, update the displays, etc.  Some of the report modules
> support only Tru64 UNIX, but can easily be modified to support other
> UNIX variants via 'If" statements. bb-central is written in perl to
> performing reporting generation and shell script generation to gather
> the data. Please see the README file in the kit. By the way, SSH is set
> up in trusted mode between the central server and all the clients. You
> must log in, via SSH, between the central server and each client once,
> so SSH sets up the key exchange between hosts. If you use fully
> qualified domain names, make sure you supply the full domain name when
> connecting, as SSH treats fully qualified domain names different from
> non-fully qualified domain names. Finally, Big Brother is case sensitive
> on both types of host names.
>
> In addition to perl, you might want to add MRTG and RRDtool for graph
> generation to your chosen host. I set up a standalone UNIX host, with
> all network services disabled, except for SSH. I installed Apache on the
> main host. Generally, the bb-central, with all the graph generations,
> should be set up to run four times per hour. Monitoring up to 50 hosts
> should be reasonable for this configuration.
>
> I hope you find this information useful.
>
> Nick
>
>
> Christopher Koelbl wrote:
> > I'm a sysadmin who has to administer servers that are only accessible
> > via crappy VPN clients.  As such, a monitoring program like Big Brother
> > is extremely useful to me by helping me keep an eye on things.  One
> > problem, however, is transferring the data from a remote location back
> > to my local BBDISPLAY.  Why would I want to do that?  Because at these
> > locations, we are not always allowed to have access to a mail server to
> > send notifications (Hospital security policies).  So here is my
question:
> >
> > Has anyone modified big brother to use an alternative communications
> > method between servers such as ftp or scp?  If so, does this transfer of
> > data come before or after email notifications of failures occur?
> >
> > I am not yet a big brother developer, but the need for remote monitoring
> > is become increasingly important.  Manually checking servers at each
> > location becomes more and more unfeasible with every additional client.
> >
> > Many thanks for any info.  In the meantime, I'll be digging through the
> > various code and scripts to see how this modifcation might occur.
> >
> > --Chris
> >
> > Christopher Koelbl
> > Systems Administrator
> > eko systems inc.
> > (703) 849-1477 x50
> > [email protected] <mailto:[email protected]>
> >
>
>
> --
> ========================================================================
> Nick Metrowsky                   | http://users.americanisp.net/~nmetro/
> 3624 Oakwood Drive               | E-Mail: [email protected]
> Longmont, CO 80503-7560          | Phone: (303)485-5696
> ========================================================================
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
> To unsubscribe from this list send e-mail to mailto:[email protected]
> with unsubscribe bbd in the BODY of the message.
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
> To unsubscribe from this list send e-mail to mailto:[email protected]
> with unsubscribe bbd in the BODY of the message.
>

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list send e-mail to mailto:[email protected]
with unsubscribe bbd in the BODY of the message.


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=
To unsubscribe from this list send e-mail to mailto:[email protected]
with unsubscribe bbd in the BODY of the message.