Big Brother Network Monitoring System
Sean MacGuire is the primary author of Big Brother. In the finest tradition of decentralized shared software development, Sean solicits improvements, suggestions and enhancements from all. He then skillfully incorporates them as appropriate into the Big Brother distribution. Thus, like Linux, Big Brother is in a dynamic state of positive evolution with contributions from a cast of thousands (at least dozens). This constrained anarchy produces interesting results with an international flavor.
Jacob Lundqvist of Sweden is actively improving the paging interface. He has done a superb job of enhancing the paging portion, adding support for alphanumeric and SMS pagers. Darren Henderson (Maine, US) added AIX support. David Brandon (Texas, US) added proper IRIX support and Jeff Matson (Minnesota, US) made some IRIX fixes. Richard Dansereau (Canada) ported Big Brother to SCO3 and provided support for other df's. Doug White (Oregon, US) made some paging script bug fixes. Ron Nelson (Minnesota, US) adapted BB to Red Hat Linux. Jac Kersing (Netherlands) made some security enhancements to bbd.c. Alan Cox (Wales) suggested some shell script security modifications. Douwe Dijkstra (Netherlands) provided SCO 5 support. Erik Johannessen (Minnesota, US) survived SunOS 4.1.4 installation. Curtis Olson (Minnesota, US) survived IRIX, Linux and SunOS installations. Gunnar Helliesen (Norway) ported Big Brother to Ultrix, OSF and NetBSD. Josh Wilmes (Missouri, US) added Solaris changes for new ping stuff.
Many other unsung heroes around the world are undoubtedly working to enhance BB at this very moment.
I am (ab)using Big Brother in ways not originally envisioned by its creator, Sean MacGuire. Texas Agricultural Extension's networks are wildly heterogeneous mixtures of different operating systems and protocols, rather than a homogeneous Unix-based network. I would like to see Big Brother learn about IPX/SPX protocols for Novell connectivity monitoring. I would also like to see Big Brother data collection modules for Macintosh, Novell, OS/2, Windows 3.1x, Windows'95 and Windows NT. Rewriting Big Brother in Perl might better serve these disparate platforms, if I could only find the time.
We now monitor around 122 hosts. Only 20 are actually Unix-based hosts that run Big Brother's bb program internally. Some 28 are Novell servers, 39 are routers, and the rest are a mixture of Macintosh, OS/2, Windows 3.1x, Windows'95 and Windows NT machines running one or more types of servers (34 FTP or 26 HTTP). We also find it useful to monitor our 31 PopMail post offices and 43 mail hosts and gateways. We are checking connectivity on three DNS servers as well, since they are mission critical.
Big Brother (or, as I now affectionately refer to it, “Big Bother”) is now alerting us to outages five or more times daily. Typically, the system administrator receives a page. BB's display is checked and the info file is used to traceroute and ping the offending machine to validate the outage. Many connection outages involve routers, DSU/CSUs and multiplexors as well as the actual host. BB's display allows us to quickly see a pattern that aids in diagnosis. The ability to dynamically traceroute and ping the host from the html info page also helps to rapidly determine the actual point of failure. If the administrator paged cannot correct the problem, he relays it to the responsible person or agency.
Before we installed Big Brother, we were frequently notified of these failures by frustrated users telephoning us. Now, we are often aware of what has failed before they call. The users are also becoming aware that they can monitor the network through the WWW interface. In many instances, we are able to actually correct the problem before it disturbs our users. It is difficult to accurately measure the time saved, but we estimate that Big Brother has had a net positive effect overall.
We have a machine in a publicly visible area displaying the brief view of Big Brother. The green, yellow, red and blue screen splashes are clearly visible far down the hall, helping our network team to be more aware of problems as they occur. The accessibility of the WWW page has made Big Brother useful even to people at the far ends of our network. Thus, Big Brother has become a helpful member of our network team. Maybe now I'll have time to be bored.
Paul Sittler (p-sittler@tamu.edu) is a human being in the service of Texas Agricultural Extension, a part of the Texas A&M University System. As a human being he is, of course, a skilled tool-maker. He enjoys playing with technology and tries to make it useful to others of his species. He is a shy man of simple tastes, who still has a discriminating palate with respect to German wine. He is multilingual, being at least marginally conversant in several human languages and competent in several computer dialects as well. He was born with a peculiar genetic defect that requires him to disassemble and reassemble things rather than merely use them.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Why Python?
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Linux Systems Administrator
- Dynamic DNS
13 sec ago - Reply to comment | Linux Journal
58 min 46 sec ago - Reply to comment | Linux Journal
1 hour 48 min ago - Not free anymore
5 hours 50 min ago - Great
9 hours 38 min ago - Reply to comment | Linux Journal
9 hours 46 min ago - Understanding the Linux Kernel
12 hours 45 sec ago - General
14 hours 30 min ago - Kernel Problem
1 day 33 min ago - BASH script to log IPs on public web server
1 day 5 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
rtzrtzhrhfghfghh
rtzrtzhrhfghfghh