Slashdot Mirror
Perl for System Administration
The Scoop Despite being what some call 'the purest distillation of Unix thought,' Perl has earned a place on many Windows and Macintosh machines for its power and flexibility. Unix administrators have developed and honed small scripts for decades, but their brethren elsewhere have had no such luck until recently. Enter ActiveState, IndigoPerl, and MacPerl, to provide the tools, this book the knowledge. Floating subtle suggestions between pragmatic tips and tricks, David N. Blank-Edelman weaves nets, strong and sophisticated, for the perpetual battle against encroaching entropy. What's to Like? Anything that saves a beleagured sysadmin time is very good. Any one chapter read in isolation will yield at least one new idiom, if not many ideas on improving efficiency and accuracy. The central theme of the book ('make things better by using a database to store all of your information') is an excellent and timely idea. It's not essential to the presented examples, but has the potential to simplify your work dramatically. Besides maintaining a central repository for usernames, accounts, network information, and passwords, it allows automated configuration file building. Imagine never hand-editing DNS records again, or having to enter user data only once.
The sample code is clean and understandable, taking full advantage of many CPAN modules. When competing modules exist, Blank-Edelman demonstrates each, with an eye to advantages and disadvantages. This pragmatic analysis governs other discussions, especially concerning cross-platform and Pure Perl versus glue-code isses. Realizing that most networks combine many different clients (Unix flavors, the Windows cousins, and Apple machines), the author provides solutions to the same problem on all applicable platforms.
Though pushing the envelope on certain technologies (at the expense of others), the Appendices provide adequate introduction. The LDAP and SNMP sections stand out in particular. The author provides enough background, whether on Active Directory, TCP packet construction, or e-mail headers, to flesh out his examples. A table at the end of each chapter lists all modules covered, authors and versions, CPAN ids, and alternate download sites. In addition, the book provides many links to further information on techniques, RFCs, references, and vendors. If you're left wondering where to go to learn more, it will be your own fault.
What's to Consider? The book assumes a working knowledge of Perl. Anyone who's made it through 'Learning Perl' or 'Elements of Programming With Perl' should have no trouble -- complex idioms and module peculiarities receive sufficient explanation. Beware, though, that the sample code does not enable warnings or run under strict mode. (Production programs need error checking, which, the author explains, could easily double the size of his examples.)Not all sections apply to all OSs. The Macintosh, for example, has no concept of multiple users (OS X not being covered). These differences could hinder the text, but are clearly marked and can be skipped with no ill effects. Besides, few networks are homogenous, and astute readers will learn more about the system in general from the similarities and differences.
Some common administrative tasks have been left out in favor of emerging or more complex technologies. There's nothing on managing printers or backups. A sysadmin of reasonable experience who makes it through the book will have gained a proper mental framework to tackle other tasks, though.
The Summary Perl for System Administrators is packed with useful tips, making the most of Perl's ecological niche. Whether you're a junior administrator venturing out into the wild world for the first time, or a seasoned BOFH, you'll find something to digest here. You might even get some free time out of it. Table of Contents- Introduction
- Filesystems
- User Accounts
- User Activity
- TCP/IP Name Services
- Directory Services
- SQL Database Administration
- Electronic Mail
- Log Files
- Security and Network Monitoring
- The Five-Minute RCS Tutorial
- The Ten-Minute LDAP Tutorial
- The Eight-Minute XML Tutorial
- The Fifteen-Minute SQL Tutorial
- The Twenty-Minute SNMP Tutorial
You can purchase this book at ThinkGeek.
I'll admit that I've rarely done things with Perl outside web development and system administration. And Perl doesn't often seem to be the best choice for large projects. Still, it's been useful outside of those contexts often enough and some of your objections seem crazy enough that I feel compelled to reply. Even though I know 37 other people will.
First off, the biggest idea I take issue with is that web development isn't programming. Web applications can match other applications in their scale and the engineering effort required. You come up with requirements, you spec, you code, you test. The fact that the UI comes through a browser through a web server doesn't change this. And boy, I *long* for the wasted months of youth that could have been saved if I had only used Perl for some of these projects instead of C.
OK, some line by line responses:
Object orientation - Perl's oop features are available, but not enforced. Real programming languages like java and pascal try to enforce good programming methodologies. This is a good thing, and the reason we don't code in assembly anymore.
People still code in assembly sometimes. Why? When it gives them an advantage they're looking for. Ditto for Perl. Except Perl arguably has a larger set of advantages. OK, most people really do a lot of the things we think of as for assembly in C. But wait. C's object orientation features aren't enforced -- they're nearly non-existent (though you can and should learn to do OO in plain ol' C). Alright, C++. Which has a dozen workarounds for its OO features and doesn't enforce their use. Still pretty popular for all sorts of things. I assume some people find its feature set useful somehow.
Readability - I know that it's possible to write readable perl, but nobody does it. Go search cpan, look at how many people bother to explain their line noise looking regexes. If programmers are allowed to be lazy, they will.
Been said before, will be said again (at least by me): bad code can be (and is) written in ANY language. Especially C and/or C++. Which are still widely used by developer for their advantages.
(That said, Perl programmers really do seem to gloat sometimes over their terseness and cleverness. Great, guys... just don't put it in code someone else has to maintain. Same goes for you clever C programmers).
Standardization - Perl isn't standardized. There's no guarantee that ANY language feature will work in future releases. Do you want to stake your buisness on that?
Well, for one thing, I don't have a problem staking my business on that because any version of Perl is pretty much freely available.
And furthermore, in practice, I find that Perl is as portable as anything I've written in C or Java or Pascal. Maybe more. The problems with all the latter languages are usually with libraries and class frameworks and proprietary extensions, but they're still there. The only problem I've ever had with Perl portability has to do with certain features not being available on *nix but not DOS/win32. And so I put some extra effort in and wrote cross-platform Perl.
Maintainability - Perl is damned near impossible to maintain bin the real world. Combine terseness with "there's more than one way to do it" and you have a recipe for disaster. Competent programmers can maintain another competent programmers perl code, but when was the last time you were assigned to maintain good code?
When was the last time your were assigned to maintain good code in any language?
This is practically the same argument as readability above. All the same responses apply.
When was the last time someone competent was hired to maintain yours?
Three weeks ago.
There's a reason why COBOL and VB are so popular in buisness, and that's that any idiot can write and maintain them.
This is a virtue? COBOL and VB have virtues that Perl has not? Ahhhh... ok.
Tweet, tweet.
I would expect a book titled, "Perl for System Administrators" to assume no knowledge of Perl. The language has it's system administrative niche in the ability to create small programs between maybe 1 and 100 lines for tasks involving some quick text processing or glueing two applications together. In other words, the tasks you would most likely find Perl applicable for involving System Administration are the tasks that wouldn't require in-depth knowledge of Perl, but would instead simply require a foundation in Perl, a thorough grounding in regular expressions, and most importantly, a solid description of how to program secure Perl code.
Ok, sadly I have to admit to buying this book right after it came out. This book is trash. It is redundant and insipid. If you are a "system administrator", you should probably know how to do these things anyway. Of course, one of the problems with the book is the author never defines administrator as "solaris admin" or "nt admin", so he has to gloss over all the really good stuff. As an example of how dumb and boring this book is, in one of the chapters he has you implement log rotation with a perl script. GOOD CALL! Maybe when I boot up my copy of SunOS 2.1 I'll have to roll my own log rotation, but just about every UNIX has that now. If you have to have this book, just steal it. It's not worth the forty something bucks they want for it. I have to say I usually like O'Reilly books, and this is the only one I haven't liked in a while.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
this sig limit is too small to put anything good h
Most of the reviews from people so far, bitching about it, seem to either be coming from system admins trying to learn perl (bitching that using it requires a knowledge of perl), or perl programmers bitching that it doesn't teach them system administration.
If you want to learn perl -- buy Learning Perl. If you want to learn system adminstration, get the Unix Systems Administration Handbook. They're both good entry level books in their field.
Perl for System Administrators was to me, more like the Cookbook -- it tells you about lots of things that you can do with the language, as 90% of the perl books out there seem to focus on text processing [eg, HTTP interfaces] Personally, I got it as a reference for work I'm doing with HTTP interfaces to LDAP. Most of the rest of the book either I don't need to worry about right now, or I've already done before, so is only useful if I want to find out why the way I did it was wrong.
This is a _very_ niche book, as you need to know both system administration and perl, and actually care about one of the chapters in the book. If you fit into that category, it'll probably be of immense help. I know it was to me.
Build it, and they will come^Hplain.
--
--
We have fought the AC's, and they have won.
In part this is because the reviewers here mostly review books they've taken the time to read all the way through. Those books tend to have several qualities:
These add up to scores above 5 on a scale from 1 to 10. Perhaps what Slashdot needs is for a few of us to admit some of our book-buying mistakes and review the real dogs. And for any of you out there who have ever been given a really bad book, this is an opportunity:
Review the 3 out of 10 books! Hey, consider it a challenge. Find a book in a subject area that should be reviewed on Slashdot, but that richly deserves a 0 on a scale from 1 to 10. There has to be at least one. Warn us all before we waste our money!
The net will not be what we demand, but what we make it. Build it well.
Just remember, any programmer could do a System Admin's job, but we have better uses for our time.
Yeah, right. Developers are the ones who like to assign null passwords and "chmod 777" everything so that annoying little things like system security and permissions don't get in the way of their code-monkeying. Of course, once they get root'ed, or someone recursively deletes an entire code tree that was mode 777, who do they turn to for salvation? The sysadmin.
but every book that gets reviewed on slashdot get an 8 or a 9. use a scale of 1 to 3 if your spread is 3 points!
i'm not saying i've never found slashdot's reviews helpful, just optimistic. (and positive reviews of the two mysql books [o'reillys and new riders] tricked me into buying books significantly weaker then the online docs)
thanks kellan
ps. if your getting sick of o'reilly, manning is has put out a number of truly quality offerings lately.
Object orientation
Why does everybody seem to think that since OOP was created there is no longer a need for procedural programming?!
Readability
From the Jargon file "Real Programmers Don't Document: If it was hard to write, it should be hard to read"
Standardization
Every try to build a Visual C++ project with gcc?
Maintainability
It's easy to obfuscate any language
Now get back under your bridge, troll.
--Dave