Perl for System Administration

Chromatic, indefatigueable, has come up with another review. This time through the door he's gathered his reactions to Perl for System Administrators, one of the growing list of titles to help bridge the gap between SysAdmin and programmer.

Perl for System Administrators author David N. Blank-Edelman pages 430 publisher O'Reilly and Associates rating 9 reviewer chromatic ISBN 1-56592-609-9 summary A royal buffet of ideas to stimulate system administrators

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

1. Introduction
2. Filesystems
3. User Accounts
4. User Activity
5. TCP/IP Name Services
6. Directory Services
7. SQL Database Administration
8. Electronic Mail
9. Log Files
10. Security and Network Monitoring

1. The Five-Minute RCS Tutorial
2. The Ten-Minute LDAP Tutorial
3. The Eight-Minute XML Tutorial
4. The Fifteen-Minute SQL Tutorial
5. The Twenty-Minute SNMP Tutorial

You can purchase this book at ThinkGeek.

Comments

Re:Get a clue timothy (s'possed to be funny?)

[weston]

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.

An impassioned plea for negative reviews

[dsplat]

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!

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:

1. They are at least somewhat readable.
2. They serve a useful purpose.
3. Their content is basically correct.

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:

• You took a class and the instructor was flogging his own book, because with the author there to explain everything that wasn't clear in print it met a standard of usefulness slightly above that of a paperweight.
• Your manager gave you a book that explains what eLinuxOpenPerlML can do and expected you to use it as a coding reference. Unfortunately, the closest it ever came to an example of code was a few browser screen shots.
• You found a copy of some thick but useless tome in your cube when you moved in. The past two occupants hadn't even broken the spine, or even blown off the dust.

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!