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.
Pardon the nit-picking, but...the correct title is Perl for System Administration, not "Perl for System Administrators".
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 think offtopic threads like this one are a great way to lose karma. No only will you lose it, but everyone who replies to you will lose karma too.
Pissing off mac loyalists is the best though. I dropped 25 karma in a day that way.
--Shoeboy
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.
Hmm... So I guess my designation as 'Systems Programmer' means that I don't really exist, right?
[and yes, I do crimp my own cables... at home at least, because I'm cheap. But it's a bitch finding places that'll sell cat5 stranded and stranded ends, as everyone seems to only stock solid cable in this area, and expect you to pay out the ass for pre-made patch cables]
Build it, and they will come^Hplain.
That was my point. There are some things that deserve to be off the bottom of the scale. There are movies that should not be watched and books that should not be read because they are such a waste of precious hours.
The net will not be what we demand, but what we make it. Build it well.
--
--
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.
Well, I just happened to get a first post, with a +1 bonus. There goes three right there. Pretty soon I'll have to stop this crap and start whoring again.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
> Why does everybody seem to think that since OOP was created there is no longer a need for procedural programming?! ;)
/. worth reading! Don't be so boring serious!
You forget functional and logic programming, you bastard
> From the Jargon file "Real Programmers Don't Document: If it was hard to write, it should be hard to read"
Most of the time, Perl isn't hard to write, so it shouldn't need to be hard to read. Except for the regexps, of course, which are _allways_ harder to write than to read (despite what newbies seing a regexp for the first tim e thinks).
> It's easy to obfuscate any language
Of course. But most languages doesn't come with _auto_obfuscation_...
Trolls are what makes
--The knowledge that you are an idiot, is what distinguishes you from one.
I think you're right. Most programmers have to do some system administration. Many sysadmins have to acquire programming skills.
But what I'm finding is that any computer owner has to be a sysadmin for their own system. The tasks are different and vary in depth and patience required from platform to platform, but they're all there. Linux raises the bar -- in order to run your own Linux box, you have to become a *nix sysadmin.
The only situations I can think of where I haven't had to be a sysadmin is when I worked for places large enough to hire their own.
Tweet, tweet.
Alright, I see your point. There's a difference between the skillset of this person who we call a "sysadmin" and... well, me. Software developer for years, UNIX/PC/Mac/TI-994A user for years more. Generally computer savy. But mediocre at system administration.
Yet I don't think it's incorrect to say that every computer owner -- who doesn't have someone to do it for them -- has to do system administration tasks. And that (from what I've read) is what the folks at Nautilus (the Eazel folks) figured out: that most often, it's not a matter of mastering UI that makes computers hard to use for people. Most folks can learn to navigate a GUI or use a CLI just fine. They just aren't sysadmins, but they're called on to do system administration anytime they install software or change a setting from what it was out of the box.
Tweet, tweet.
I bought this when it was released several months ago, and it's been a very useful tool. I also got a chance to meet the author at LISA 2000 where he was giving a tutorial on the same topic, as well as speaking at O'Reilly's booth.
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.
Sometimes I think that the best way to lose karma around here is to compile a well-thought-out, on topic, insightful post. The way moderation goes, you'll probably be hit with "troll", "flamebait", and "overrated". Example: my original post somehow got an "underrated." Of course, the simple explanation is that that moderator was a /. denizen, modding up an obvious crap post. The other funny explanation is that the moderator was a sadist, and seeing my wish to lose karma, purposely modded my up just to watch me squirm.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
Could we have a single Perl-related article on slashdot where the comments actually deal with the article at hand, and don't degenerate in to a general discusion of 1) Perl, 2) the readability and maintainability thereof, or 3) the inferiority or superiority of Perl as compared with Python or any number of other languages?
Uninformed generalizations are a dime a dozen.
--Bruce Fields
I have a pretty strong suspicion that you're just trolling but on the off-hand chance you're not I'll try to make a somewhat educated rebuttal. Note that I'm not a CS major (computational chemistry), but that I do program a lot and I have done so for money. In other words, I tend to have a very pragmatic outlook on computer science.
Object Orientation -- Leaving aside the large and very valid debate about whether or not OO is a panacea (it's not IMHO, grotty OO code is still grotty, as is grotty functional lang code, et al.), bondage-and-discipline languages that try to force developers into doing something are not a good thing. Why? People get pissed off about the restrictions and find ways around them. Example: #define private public in a C++ header file. If you subscribe to the ``efficient market'' theory (lots of smart people looking at the same problem will arrive at roughly the same answer (c.f. the stock market and share valuation)), and believe that strict programming languages are a good thing, then why isn't everything being written in Ada today? (Oh, and the ``Real programming languages'' bit is really idiotic. I guess Linus was just using those toy languages C and asm when he coded linux's kernel...)
Readabilty -- is a function of the programmer, not the language. Regexps are line noise but they are the most effective way of transmitting meta-lingual patterns, so it's just a sub-language like any other proigramming language (you're programming matches on text instead of bits on a chip). It's just as easy to write bad Java as it is bad perl, and it's _really_ easy to write bad C (don't forget the obfuscated C contest has been around longer than the obfuscated perl one).
Standardization -- Nothing is constant in the IT industry. Just ask the guys who wrote the DB code for the airlines back in the 60's before the whole relational db / SQL revolution. Standards for a langugae are of overblown importance anyway, just go and try to tell me that advanced (read: uses all the advantages of the environment) C++ code for VC++6 and g++ are the same, even if you use "Standard C++". :-) To use one of your examples against you (of a "real" programming langugae), Java isn't standardized. Sun could decide tomorrow that "well, we never did like the + operator so we're deprecating it in favor of $%$(*@ as the addition operator". Secondly, since when do businesses recode everything as soon as a new release of somethig comes out? 4 of the last 5 places I've done contract work for were still using RH 6.0 and perl 5.005. (The other place was using 6.2 and 5.005) Thirdly, the language is communaly designed so it is highly unlikely core language features are going to change night-and-day in one or even two releases.
Maintainability -- so in essence you're saying every programmer before and after you is a Forrest Gump? Uh, yeah. Basically this boils down to the same thing listed under readabilty: to get good code you need good (disciplined and technically proficient) coders. Try arriving on a consensus in your coding dept as to code standards (<-- this will be much more effective if the coders themselves come up with it that a dictate from on high), and make sure you hire good (see de above) people. The rest will work out. COBOL and VB are popular in business becuase they just want something that will get the job done, and since both of the langugaes were designed to fit into the "problem space" of business, they are a path of least resistance. (They are the "good enough" solutions, although I think and hope that Java is beginning to replace them.)
As to your original thesis that perl isn't used by real programmers, well, I have about 200Kb of genome analysis code that ties into some hefty vis libs written in OpenGL that proves it wrong. :-) I.e. I think that's outside of the realm of webdev and sysadmin (which perl is very good for but is hardly it's sole strong point)
This is not to say that everything should be done in perl. All true masters of their trades[1] realize that no one tool is the perfect one for all tasks, so each should be used in accordance with its strengths. I.e. I'm not going to be writing any kernel modules in perl any time soon, kOrbit notwithstanding.
[1] I'm not claiming I am one, just noting a fact. Michaelangelo used more than one brush painting the Cistine Chapel. (I think that's the guy, but even if I'm forgetting the name the point stands.)
--
News for Geeks in Austin, TX
Developers changing IP settings at will for test purposes, causing quite a few duplicate IP addresses.
Public storage areas losing 300MB or more overnight, due to someone installing pirated software on their project data area.
Backing up entire workstations to the same project area during the day, slowing down our filesserver to a crawl whilst at the same time consuming all of that segments LAN utilisation.
Hardware breaking due to one developer believing he knew what to do with a screwdriver. Also during one training course *EVERY* PC in our training room had it's memory tinkered with in some way.
Complete disregard for file permissions. Chmod everything to 777 recursivly, as it works.
Borrowing AUI to UTP transceivers from important equipment, believing them to be network cards.
Installing a demo network for an important client whilst using Parrallel port NICs, then wondering why the demo ran slowly. (I was out of the office that week).
'Installing' Windows based software to the network, eating bandwidth when executing the code. Very common in our office. My boss (a developer) did this with a 30-40 user roll-out of an Office suite at an important client. I had to fly out there on a weekend to fix it.
They must keep forgetting how to spell dictionary.com :D
"Free your mind and your ass will follow"
I would say an oyster, but that's to obvious.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
Every computer owner (well, almost every) does indeed have to do some system administration. I wouldn't dream of arguing that point. That doesn't make them a sysadmin, though; anymore than programming admin tasks in perl makes a sysadmin a programmer. It's a matter of which task is your major job and/or skill.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Ummm... "impossible" to do large-scale development, meaning Perl actually prevents this?
So C's not a real programming language, then?
Yeah, that's Perl's fault. Impossible.
Yeah, Java never deprecates any features. Nothing in the C or C++ standards ever changed or broke existing code. And Pascal (the real programming language you mentioned, still used for so many groundbreaking large-scale projects) certainly is standardized -- who cares that none of the popular Pascal implementations came anywhere near the standards?
And any idiot will, which is where the fun begins. But then, I thought we were talking about Serious Professional Programmers.
What's next, Slashdot for Illogical, Ill-Informed Posters?
-paul"Irony is so September 10th"
Matt Miller, alt.fan.spinnwebe
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
The Macintosh, for example, has no concept of multiple users (OS X not being covered).
Before any other Mac users rush in to flame the reviewer by pointing out that Mac OS 9 in fact does support multiple users, I would like to point out that it, in fact, does suck rocks and is incredibly brain-damaged compared to even Windows 9x's multiple-user capabilities. About the only thing it's good for is putting up a login password at startup (which can quite easily be circumvented) and for impressing your easily-impressed friends by using the voiceprint verification password thingy, which never works unless you:
a) are in a silent room
b) are speaking into a wired microphone
c) are setting it up for the first time (always fails after then)
Can't wait for OS X.....
--
I use Macs for work, Linux for education, and Windows for cardplaying.
I'm not convinced that Perl couldn't do this job, but I think I see your point:
... it's a requirement impossed by an earlier (possibly poor, possibly good) choice. #1 could arguably be a true virtue of MS products.
1) MS products have the virtue of being more highly integrated with other MS products. In some cases, this is an advantage
2) If you're writing something for someone with an investment (knowledge or technical) in a certain system, it's to their advantage for you to make that investment work best.
#2 is not necessarily a virtue of VB
Tweet, tweet.
I'm surprised you could POST IN ALL CAPS.
cpeterso
*pat pat*
That's nice, little boy. Run along and play now.
With an attitude like that, I already know what I think of his programming skills.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I myself, hate programing. Dispise it. I can deal with scripting up to a couple of hundred lines say, when its for making my life easier - like say automating sysadmin tasks.
Being able to program a IP stack is one thing. Being able to set up and configure a computer on a IP network is another.
The trades are as diffent as a profesional mechanic and a profesional driver. Mechanics can usaly drive, and drivers might have a mechanical backgroud, but there sure as hell not the same job.