Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: casual programming and network operations

  • From: batz
  • Date: Sun Sep 08 14:41:55 2002

Would the Net:: modules on CPAN be usefull to you? I have found that
most of the examples in there can give you all you tend to 
need for day to day network administration. There are tftp 
snmp, ftp and other modules for doing basic file transfers. 

They will have to understand things like how to construct 
regular expressions and many of the things you list below, 
however, most of the tasks they will need perl for probably
have modules dedcated to them already, with ample example 
scripts to modify. 

See for details. 

I need to do the same thing for some of my folks, as they 
were "network" people of some sort in previous lives, but 
need to learn basic unix / perl tools to be 
useful for parsing and sorting logs, writing crontabs,
updating their various applications, file version 
management, software version mgmt and patching etc.

There is a book in this somewhere...

"Perl and Unix Utilities for Internetworking and Application
Management"  maybe? 

Anyone from ORA or elsewhere want to give me a small advance 
to write it? :) A nice Macallan (older than me), or even a 
bottle of Bookers will do. 


On 8 Sep 2002, Adam Atkinson wrote:

:Date: 8 Sep 2002 16:14:43 +0100
:From: Adam Atkinson <>
:Subject: casual programming and network operations
:Some of my colleagues appear to think that things like perl are
:so arcane that only I can do them. I have offered to do a _really_
:basic introduction to perl (and unix shell stuff) tailored to
:what my colleagues might possibly use it for, and several people
:have expressed an interest.
:It has to be admitted that I only use quite basic features of perl
:myself, but my own experience has been that it's possible to do
:genuinely useful things knowing only tiny bits of it. (My experience
:with C has been otherwise, at least for the sorts of things I find
:myself wanting to do.)
:My intention is to try to get the message across using real-world
:examples which achieve something clearly useful, without using many
:features of the language. Preferably examples where doing it entirely
:by hand (or with a spreadsheet or editor) would be awkward enough
:that learning 3 things about perl and writing a script seems
:faster and/or more appealing.
:I would, for example, only (or initially?) use examples that use
:standard input and output, since you can achieve plenty that way. And
:no modules until/unless people are sold on the basic idea. And, to
:keep the scripts looking as undaunting as possible, no "die"
:statements, no checking of input, etc. (I know how daunting I find
:"simple" programs 3 pages long)
:Four examples which seem good to me would be:
:(i) going through Apache logs and listing the IP addresses from which
:Nimda attacks came. (via grep | cut | sort | uniq, and/or with perl)
:(ii) removing mysterious binary characters in otherwise clean log
:files (since this has actually happened to us) using tr
:(iii) reversing netmasks, so that lines of the form "
:" can be turned into,say, "access-list 142 permit ip
:(iv) Using cron and expect to log in to a router periodically and do
:something to it. (to be concrete, get data from it and feed it to mrtg)
:Taking (iii) as a concrete example: I have upon occasion been given
:200+ networks I needed to do this to, and it strikes me as a perfect
:applicaction for a perl script that uses only stdin and stdout for
:this audience, though not as a first example. It's a realistic task,
:and doing it by hand for 200 networks would be annoying.
:What are some other ways of doing (iii)? One person I asked said "load
:it into Excel and do search/replaces on the network masks until you've
:covered all those used". This isn't bad, it has to be said. I watched
:someone spend hours doing (ii) with Word, which doesn't feel right at
:To what extent do people feel that "casual grade" unix or Perl
:knowledge to this sort of level is useful in network operations?
:Even if experts are available, I wouldn't like to think it's necessary
:to disturb them for this sort of thing.
:Is it reasonable, when trying to sell some non-programmers on the idea
:that basic scripting is useful and possible, to deliberately omit -w,
:use strict, die, syslog and similar? In a 3-6 line script, that kind
:of stuff would take up more space than the actual "meat" and risk
:going against my "this isn't so hard, really" message.
:If forced to do (i)-(iv) without using scripting of any kind, I'd
:become quite annoyed. To be fair, (iv) clearly has to be scripted.
:Are there other reasonable non-scripting methods of doing (i)-(iii)?
:NB I'm not planning on claiming perl is uniquely wondrous. I just
:don't know enough tcl, python, ruby or rexx to show anyone how to do
:anything with them - and my own experience has been that you can use
:expect without knowing any tcl except some "lindex" stuff to read
:command-line parameters in.
:Does what I propose seem more useful or dangerous? I think my main
:aim is to show useful non-artificial examples as quickly as possible.
:Talking about loop structures, scalars vs arrays vs hashes etc. seems
:like exactly the wrong way to do.
:It seems to me that
:while (<>) {
:can be used as the basis of useful stuff. (Also, one of the main
:messages would be that the most important skill is taking an existing
:script and tweaking it, even if you don't know how some of it works.)
:Of course, I'd tell people that knowing other features as well might
:allow more to be done, but I wouldn't want to push people into using
:modules, objects, references, etc.


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.