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.