Using XML Modules in Perlby Nathan Patwardhan, coauthor of Perl in a Nutshell, 2nd Edition
For various reasons, updating Perl in a Nutshell was a challenge.
Given the new material that crept into the source kit between Perl 5.005 and the upcoming release of Perl 5.8, as well as things that demanded to be added or updated in the text, I knew that there was much to do. When I learned that the book update was going to be done in XML/DocBook instead of the original format (troff, then FrameMaker), the task of the update became even loftier, so I wasn't quite jumping for joy.
On the other hand, far be it for me to slam XML. In fact, prior to the second edition of Perl in a Nutshell, I hadn't used it with any regularity. Admittedly, as a system administrator, I hadn't found a specific use for XML. And I was already equally familiar with POD, HTML, and *roff, all of which offered some level of "WYSIWYGALAC" (What-you-see-is-what-you-get-at-least-after-conversion). I didn't quite know how XML would fit into my daily work, and, as it related to the update of Perl in a Nutshell, I didn't want to inflict pain on the O'Reilly production staff whilst they untangled my markup during the book production process.
But this article isn't a narrative about me writing Perl books, my favorite tool for text processing, or killing the O'Reilly production staff softly with ill-conceived markup. This article is really a revelation of a practical use I've found for XML, and a couple of things that I took with me after updating Perl in a Nutshell. I'll cover a couple of interesting XML-related Perlthings as well: XML::Simple and XMLRPC::Lite, and how I've come to use these Perlthings in my daily job.
At work, we'd been generating documentation for our servers in the old-fashioned way: copying and pasting IP addresses, (disk) partition tables, patch information, and so forth, into a Microsoft Word document, and placing this document on a shared drive. Not only was the process monotonous (no offense to my employer!), it was prone to error, since it didn't take much to "lose something in the translation" between a copy 'n' paste and inserting information into a table. Given that our documentation, in part, was used to track system changes, faulty data could mean the difference between truly finding a flawed server configuration, and being the victim of a typographical error. There had to be a better way! Right?
When I think of bread and butter, I think of sourdough and margarine. But, call me hungry, I also think of Perl's text-processing capabilities. Add some nifty modules and Val Kilmer in Thunderheart (read: pure magic), and you've got yourself an application.
And so it began.
I jotted down a grocery list of functionality that I'd write into my system self- documentation application, which included:
System information (network configuration, [disk] partition tables, and so on) would be auto-generated.
Auto-generated system information would live in a data structure, like a
%HoH(hash of hashes). This data structure would be stored (cached) to disk, and this cache would be referred to upon subsequent executions of the system-reporting.
The system would pass the data structure (
%HoH) over the wire to a "reporting server", which would expand the data structure as XML. This XML would represent the system information in a table-like format. That is, if you applied a stylesheet to the XML, you could easily generate a (HTML) table from the XML.
The final system report would use a (XML) template from which static content, Perl code, and the data structures were merged into a single document.
While there's more to the application than listed above, this article is intended to present a couple of concepts in short-form, so I'll stick to the crux of what I did with XML. I used the following to implement the points above:
Standard Perlstuff here:
qx(), and so on.
Standard Perlstuff here:
At the heart of my self-documentation system is having the "client" machines do as little as possible: generate configuration information, cache it, and pass it to a "reporting server". Given this client/server model, much consideration was given to how system configuration information would be passed from the client to the server. Immediately, I ruled out things like ftp, rcp, scp, rdist, rsync, and similar. While each of these implementations would allow me to pass data from one host (a "client") to another (a "server"), I simply didn't want to pass user information (login and password) over the network; nor did I want to allow the admin user to have a null (RSA) key so that the administrator could have full permissions to pass system configuration information between the client and the server. Thus, ftp, rcp, and the others were eliminated. Further, even if I did something so evil as allowing root to gain access to a machine (even securely) without a password, such an implementation wouldn't answer the question of passing a data structure as is between the client and the server. Even if I used http and passed my system configuration in name/value pairs, I still wouldn't have answered the question of dealing with my data structure as is.
Pages: 1, 2