Open Source Network Administration
- SNMP (a protocol for managing network devices and hosts)
- MRTG (the Multi Router Traffic Grapher - a bandwidth utilization meter)
- Neo (a network device administration tool that speaks SNMP)
- Oak (a syslog watcher and digester)
- Nagios (an active network/host monitoring tool)
- Flow Tools (tools for processing Cisco NetFlow data)
This book also discusses more basic debugging tools such as ping, traceroute, tcpdump and others. Finally, Kretchmar provides some pointers on building your own tools using bash, perl, sed and awk.
Kretchmar is a network engineer for MIT and has gotten a lot of practical experience in managing large networks and unruly hosts. In this book, he imparts a large amount of that experience in over 200 quick-reading, no-nonsense pages. He tells you what a tool can do, how to get it and build it and provides examples of some typical uses. While beginning network administrators will feel comforted that he takes enough time to explain the tools he talks about, experienced ones can safely jump right to his equally well-explained configuration examples without missing anything crucial.
This book read so quickly and was so straightforward that it really inspired me to fix up some areas of my network monitoring that I knew were lacking, but hadn't bothered to fix. In particular, his chapter on Oak motivated me to implement an instant messaging infrastructure (like one he mentions using at MIT) to receive event notices quickly and without dependence on e-mail. While it's no bible (my staple, the Unix System Administration Handbook, is over 800 pages), this book provides a great start on quite a few great tools - many of which I plan to investigate soon.
I was a bit puzzled at his inclusion of instructions for building each tool when most of them are simply ./configure; make; make install. Only one of the tools seemed to actually merit building instructions. At least you can't say he isn't thorough.
I give this book nine stars (out of ten) simply because it really made me realize how easy it is to configure a lot of automation that Ive been wanting. The cover price of U.S. $44.99 strikes me as a bit high in the market, but it is significantly discounted at most online book stores. I still have to recommend The Unix System Administration Handbook first, however. It is more expensive, but contains much more scope and detail than this book. Those who have digested USAH, though, should consider picking this book up from your favorite e-tailer.
You can purchase Open Source Network Administration from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. Reviewer, Virginia Tech alum and CHUUG member Josh Malone has been a Unix Systems and Network Administrator in Charlottesville, VA for three years.
I'd say, we all know how MIT loves its pranks/hacks. This has to be one intersting and challenging job. Someone should publish a book (or just a website) on the pranks/hacks that happens on their network. For the most part the other pranks are all well documented, bu I'd love to see what these kids cook up for the New Admin.
Last book review, 9/10
Book before that, rated Excellent
Before that, two thumbs up
Oh, MY GOD, an 8!
What gives? Can we get an unbiased review, please?
Unfortunately, that's the exact attitude that many employers take. Apparently nothing impresses them about a candidate except:
1. An ability to kiss ass.
2. Knowing less than the employer.
Maybe I'm mistaken, but isn't the point to hire people smarter/more knowledgeable than yourself? Otherwise, you should be able to do the job yourself!
Javascript + Nintendo DSi = DSiCade
Check your link again. The first book on your list is not the book we're talking about. The book we're talking about is the fourth down the page you linked to.
Here is another list of all its prices. Barnes and Noble seems to be the better deal if you want it new and Half.com seems to be the better deal if you're willing to get it used.
Unlike traditional media, which has a staff responsible for reviewing new books, Slashdot's book reviews are submitted by users. There is little, if any, incentive, to read the books that are worthless or of little value.
I don't really have a problem with high ratings in book reviews on Slashdot these days, it seems likely that the reviewer really does think that the book deserves 9/10. I think that the lack of low reviews means that people aren't willing to invest resources in buying, reading and reviewing a book that they don't like. I personally will never finish a book that strikes me as low quality. I would also never review a book that I haven't finished.
:)
Judging books before really reading the entire thing is much easier than it sounds. It's very easy to go down to Narnes and Boble and flip through a book and assess it's value within a couple of minutes.
To me, book reviews like this present book reviews to me that I might be interested in. If you really have that much of a problem with the reviews, go find a crappy book yourself and review it.
My blog
Still haven't gotten over that rejection letter from the MIT Undergrad Admissions Office, eh?
-Shane
I love teh int4rw3b!!!!!111one1
http://perl-oak.sourceforge.net/downloads/Oak-1.8. tar.gz
Here is a link to the files referenced in the book: http://web.mit.edu/ktools/
Regards,
Timothy Boyden
Systems Administrator
MIT Department of Facilities
Charlie Daniels was accused, during an interview, of not being that great a musician and simply hiring people better than himself to back him, making him just look good.
To which Charlie replied, roughly," I'm just a front man. Of course they're better than me. If they weren't I wouldn't have hired them.
Charlie knows something.
You'll never see a job ad that says "Wanted: Really Smart Guy."
No boss really wants that guy around the place. Despite some of your other respondents this fairly common knowledge with lots of anecdotal evidence.
Robert Townsend, author of "Up the Orininization" and former President of both Avis and American Express wrote that every company should have a Bullshit guy. This is a guy whose only job is to wander around and yell "Bullshit!" any time he sees any in a company practice. It' would take a reasonably smart guy to fill this position.
And what boss would have him, wandering around yelling "Bullshit!" at all the policies he implemented?
I take the idea a bit further though. Every company of any size should have a position that's called "The Smart Guy." Officially. That's what it would say on his cards and everything.
No official duties other than being smart, curious, informed and the interest to keep himself informed, on nearly anything.
Anybody in the company could talk to "The Smart Guy." Network's down and you can't figure it out? Go talk to The Smart Guy. Maybe he doesn't know the answer, in fact he probably doesn't, but talking to someone smart might helf you think about the problem in a way that allows its solution.
Extrapolate.
You'll never, ever see this position advertised. Not because it's not a good idea, but because every boss thinks that he's The Smart Guy. He wouldn't be "boss" otherwise. Right?
KFG
Consider:
OSS developers should recognize Longhorn for what it is: Microsoft trying to be competetive for the first time in years. Don't expect another crap OS from them.
First-rate people hire first-rate people. Second-rate people hire third-rate people.
Ahh, but it's *sooo* true.
My workplace recently needed a new lead sysadmin. I reccomended one of the best sysadmin/system-level-programmer types I knew. Everyone who interviewed him agreed he was the best person we'd talked to -- except the VP of Engineering, who refused to hire him (but wouldn't say why).
Well, a few weeks go by, we haven't found anyone else who's up to snuff, so the VP gives in and hires this guy. Then the VP finds out that when he tries to micromanage system administration (and do things in order of visibility rather than dependency order) that the IT team actually starts *pushing back*, telling him exactly why his plans will take more time in the long run, require extra work, result in poorer service overall, etc etc.
The VP of Engineering no longer talks to the IT lead, or anyone else on IT if he can avoid it -- yet IT is dramatically more productive and provides better service to the engineering staff than was previously the case. Funny how that works, eh?
(And the other funny thing is that I don't really have a problem posting this here -- even if our dear VP of Engineering *does* find it. Frankly, I think I'd rather enjoy the outcome if he tried to fire me over this).