Aug 00 Getting Started
Volume Number: 16
Issue Number: 8
Column Tag: Navigation Services
AppleScripting Your Network
by John C. Welch
How to use Apple's second - best kept secret to
make your life easier
As you can guess, I am going to talk about the how's and why's of using AppleScript to
make your life as a network administrator much easier. We'll talk about some of the
reasons for using AppleScript to run networks, and some of the instances when you
would, or would not want to use AppleScript. We'll also take a look at some example
scripts that I use to make my life easier.
Just to give you an idea on where I am coming from in my approach to scripting a
network, I think it's important to give you an idea of what my network consists of.
AER, like most scientific companies, has more than one operating system and hardware
platform that it uses to get the job done. Our primary platform is Sun Solaris 7 on Sun
Sparc hardware. We also make extensive use of SGI's Irix, IBM's AIX on RS/6000s,
and Linux, both on Intel and PPC. Our non-Unix operating systems include Windows
98, Windows NT, Windows 2000, and OS/2 on Intel hardware, and Mac OS 8.6 and
9.0.4 on Apple hardware. My direct responsibility is as the administrator for some
70+ Mac and Wintel machines, with indirect responsibility to everything else.
So, for my needs, any scripting I do, has to be able to handle non-MacOS machines
whenever possible. This makes things, well, interesting at times. But then again, that
makes it fun. We also let the users, and their department heads decide for themselves
what hardware to use, so any standards in that area come from the people using the
equipment, instead of the people fixing it. Managing all this can be a handful, and
without AppleScript, darn near impossible.
Foundations
First of all, before you can script any thing, from a network to email, you need to be
familiar with what you are scripting, and its capabilities, both good and bad. That
means there are some critical pieces of the picture that you must know to script your
network well.
Know Your Network
This means, that for the areas you have responsibility over, you have to know things at
a physical level. You should know has much about the wiring runs, and wiring closets
as possible. Where possible, get a set of blueprints, and diagram where the wire runs
travel, and how they get in and out of the closets. This obviously has to bow to common
sense. If you have twenty buildings in seventeen countries to manage, it may be
impossible to get all the blueprints for you network, but you should put forth a
sincere effort to know where your wires are.
This also means that you need to know your network equipment. Having bright shiny
G4s will save you no time if your hubs are shared 10Mbps to hundreds of users. You
need to know what your network equipment is, and what it can and cannot do as well.
Remember, a network is almost a living organism, and any scripting done in that
environment must be done holistically. It does you no good to have a fantastic script
that requires AppleTalk drive mounting on servers in another subnet, if none of your
routers are passing AppleTalk.
Once you have these parts, then you need to know how your network is laid out
logically as well as physically. You may be one jack over from a file server, but if
your network makes use of VLAN, (virtual LAN) switches, then your logical layout
may have you many subnets away from that same server. Again, depending on what you
need to automate, then the differences between logical and physical layout, and how
aware of them you are make the difference between success and failure.
Know what computers and operating systems are going to be affected by your scripting.
It does no good to write scripts that assume your PCs are running Windows 98 if they
are actually running Windows 2000. On the Mac side, differences in support for
various AppleScript features between versions of the MacOS can complicate your life
to an amazing degree if they catch you by surprise. Along with this, take a little time to
find out what the users thinks that they are using their computers for. The answer
might surprise you, as users have an uncanny ability to customize their computers to
work best for their needs. This is not bad or good, but rather something you need to be
aware of. That computer is their tool first, and yours second. Make sure that by
making your life easier, you don't make theirs harder.
All of the above boils down to knowing how your network is designed and installed, and
why it is set up the way it is. By taking the time to do this, you lay the ground work for
successful scripts.
Tasks
The next step, once you know what you are trying to script at the network level is to
take a look at the tasks that scripting will take over for you. Some common tasks that
lend themselves to scripting are things like software licensing monitoring, software
updates and installations, collecting statistics on various network functions and
resources, monitoring the usage of your network resources, and other such repetitive
tasks. Besides the tasks themselves, you need to look at the frequency of the tasks. A
print queue that hangs up once a year is probably not worth scripting, but the weekly
web log processing is. Take a look at which tasks are cyclical and repetitive, and which
ones happen at such random, or infrequent times as to be easier to do manually.
For the cyclical tasks, take a look at the periods involved. Don't just focus on how often
the task needs to be done, but correlate that to the length of time the task takes. A daily,
hour long task is a better candidate for scripting than a five minute task that runs
every six months. Also, make sure you keep the priorities of the tasks in mind. While
it may be fun to script an oddball job, making sure the critical ones are running when
needed is usually more important.
Planning To Manage
The last section of the foundations of scripting a network is possibly more important
than any of the others. You need to answer the question of whether or not a task should
be scripted. Do you need to automate this task? Is it something that is properly suited
to scripting? Do you need to have your fingers in that particular pie? Remember, you
are doing this for a reason. You need to have a clear goal, a clear idea on what the
desired outcome of your script, or scripts is going to be. Don't just start banging out
scripts because you can.
Ask yourself, "Can this task be automated?" If the answer is yes, then decide on
whether or not it should be. There are a lot of things that are done manually for
non-technical reasons sometimes, and the folks you work with and for may not take
kindly to you changing how things are done because it was Tuesday. Another question to
ask is how mindless is this task. Face it, a lot of the things we do take the intelligence
of a snail, and those things are often begging to be automated. (I have found that
mindless usually holds repetitive's hand, so if a task is one, it's most likely the other
too.) But, if the task needs the help of a roomful of theoretical physicists to run
successfully, you probably don't want to script it.
If you are scripting data or statistics collections, then be very clear on what the
results need to be. Collecting millions of data points automatically with the mother of
all scripts is useless if you miss the one data point you really needed. Although this
may seem almost insultingly simple advice, I've seen people go down the wrong road,
and walked in my own footsteps on that road too many times. Make sure you know what
you are trying to accomplish.
Applications
Don't Reinvent the Wheel
First of all, not everything can be scripted. Face it, there are tasks that will just have
to be run manually. This is not a challenge to your ability as a scripter, just a fact of
life. In any event, it's impossible to script things to the nth degree. Even if you came
close, you would end up spending as much time maintaining the scripts as you did when
you did everything manually. Wasted time is wasted time, regardless of how it
happens. You have to balance time spent scripting and maintaining those scripts
against the time you actually save. If you can't at least break even, figure out another
way to do the task. Remember, time is money, and lots of it too.
Secondly, don't waste a lot of time searching down OSAXen, and memorizing the
AppleScript Language Guide, in a quest to create a network management system in
AppleScript. Play to AppleScript's strengths. It's a system level toolbox, that is at it's
best when it is 'gluing' the abilities of one application or system feature to another,
thereby giving both new capabilities. There are many excellent 'off the shelf'
applications that will do a lot of what you would kill yourself trying to do manually.
Use AppleScript with these applications, not instead of them. Not surprisingly, almost
all network administration applications are scriptable. By taking advantage of the
features in an existing program, you let the program and the computer do all the work,
instead of you. Remember, you're an administrator, not a programmer. Programmers
make tools, administrators use tools. Think like an administrator, and you'll do well.
Scriptable Applications For The Network
Here is a partial list of scriptable applications that I make frequent use of in my
administration duties:
• BBEdit - <http://www.barebones.com>
This is one of the best tools around for doing anything that requires searching
and replacing of text. I know that you can do anything BBEdit does in Perl, but
BBEdit is easier to use, and to script. I use it for everything from parsing
LDIF files to reformatting email address book files. It's fast, easy to use, and
can do almost anything you can think of with text, and it's very scriptable.
• netOctopus - <http://www.netopia.com/software/netoctopus/index.html>
This product allows you to do configuration management, remote installs,
software usage monitoring, collect statistics, almost anything a network
administrator needs to do, and it works on Mac OS and Windows. It's also
completely scriptable, and it allows you to script administration functions on
Windows as well as the Mac OS. You haven't lived until you've done Windows
Registry edits via AppleScript on 30 PCs at once. An amazing tool, and one I
can't live without.
• Timbuktu Pro - <http://www.netopia.com/software/tb2/index.html>
Timbuktu, also from Netopia, fills the one hole in netOctopus's arsenal, that of
remote control. This application gives you total remote control over any Mac
or Windows box, and like netOctopus, it's highly scriptable. This is one of
those tools you never think you need until you try it.