Volume Number: 16 (2000)
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

Welcome

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.

Background

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.

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.
• Retrospect - <http://www.dantz.com/>
  No treatise on networking is complete without a reference to Retrospect. Retrospect is one of the best backup applications on the market, and holds its own quite well against some very stiff competition. The nice thing about the scripting features in Retrospect is that Dantz makes it very easy to use it along with your email client of choice, so that you can have it email you status, instead of having to check things manually.
• FunnelWeb Pro - <http://www.activeconcepts.com>
  This is a web log analyzer, that will slice and dice your data any way you like, and build you some sweet little 3-D graphs of it all, so that you can easily show what your web servers are doing. A nicely scriptable application, that has a very nice feature set.

There are literally hundreds more applications like these, but to list them all would take me almost the entire magazine. Take a look at the applications you already use, chances are, most are scriptable.

Scripting

So, now that we have the basics of what to do before you script, let's get into the fundamentals of actually scripting the network. These can be illustrated as What, Where, When, Why, and How.

What

The first thing to establish is what exactly is the code you are writing going to accomplish. Remember, you are automating a task, a single task in most cases. Keep your script focused on that task. While it may be fun to think about nifty features, that runs counter to what an administration script is about. In most cases, your script won't have an interface. This is either because you don't need one, or can't run the script if user input is required. The script will also need to be able to run unattended. Since the wee hours of the morning are the slow times on most networks, this is, coincidentally, the best time to run network scripts. Since you most likely don't like being at work at three in the morning, the script needs to be reliable as well as faceless.

For this type of scripting, 'the smaller the better' is not a bad mantra. From a reliability standpoint, two or three smaller scripts, each doing a single task are far better than a large script trying to handle those same two or three tasks. If it gets written, at some point it has to be debugged, and that gets harder exponentially with the size of the script. In general, if it's too big for the Script Editor, it's probably too big.

Where

Since you are going to be running many of these scripts from a single Mac, it behooves you to take some time to plan out your script server. As far as what kind of Mac to use, I would say that is dependant on the type and number of scripts running. From a speed to cost standpoint, I would say nothing less than a G3. Although there are a lot of server applications that run fine on older hardware, scripts are somewhat dependant on the CPU speed. I wouldn't necessarily run out and get a new G4 server, as there is not much, if any G4 - specific optimizations in AppleScript, so any speed increase would be due to overall system speed, as opposed to the Altivec units.

Since AppleScript is CPU - dependant, I would avoid servers that are already under heavy CPU use. In particular, avoid FileMaker Pro servers, (or any database server for that matter), or Retrospect servers. Both of those applications make heavy demands on virtually every system on the Mac, and neither reacts well to being in the background. In addition, if your script is in the background with either one of these applications, or applications of a similar type running, the CPU time the script gets may be so small as to cause timeout issues.

I have found that a not too heavily burdened AppleShareIP server is not a bad choice, as AppleShareIP is essentially a background - only server anyway, and does not make as much demand on CPU as it does on I/O. Make sure that you don't try to push an overloaded AppleShareIP server too hard though, as it will crash, which will do you no good whatsoever.

Obviously, the ideal situation is a standalone Mac. You want to have no earlier than MacOS 8.6 running on it, although 9.0.4, with the current AppleScript updates is a good combination as well. You will want to have some form of scheduling software on the server for your scripts. I have had good luck with iDO, but whichever one works best for you is as good a choice as any other. The nice thing about a script server is that with the exception of RAM, (64MB is just not enough), there is no need to update the stock hardware, so you can use a fairly low - cost configuration as the server.

When

Try to avoid scripts that can only run at specific times. This is not to say that there aren't times that are better to run scripts than others, but avoid scripts that can only run at ten in the morning on Wednesday. For example, trying to install Office 98 on fifteen Macs while you are running your backups is probably not the best example of timing, bandwidth - wise. On the other hand, if you have a lot of mobile users, you may have no choice. The trick here is to avoid that type of situation whenever possible. This is where my earlier admonition about knowing your network thoroughly comes in handy.

If at all possible, early in the morning is a great time. Even the biggest workaholic tends to knock off by three a.m. or so. This is an especially handy time if the script needs an hour or so of high bandwidth to run well. Make sure you are balancing your CPU and I/O capabilities with the script requirements. Don't try to make an hour script fit into a thirty minute time slot. In addition, if you have multiple scripts running, try not to shave the timings too close. The MacOS does a decent job of multitasking, but it does fall down here occasionally. Resist the temptation to see how many scripts you can have running at once, or kicking off within seconds of another one ending. Trying to push your script server too hard, or the timing program too hard is just begging for a painful example of Murphy's law.

Why

Although I talked about this before, it's important enough to repeat. Ask yourself again, why are you writing this script. Remember, you are doing this because you need to do it in a script, not because you can do it in a script. Assess your needs carefully here, and balance them against what the task requires. There are times when manual is better than automatic. The idea behind scripting your administrative duties is to make your life easier, not just as hard in a different way. If a job that normally takes five minutes once a month ends up needing a script that takes twenty minutes to run, a week to write, and is as twitchy as a cat in a room full of rocking chairs is not going to help you in the least. Make very, very sure that the end result of your scripting effort will be better than the current situation.

How

Once again I say plan, plan, plan. Since you are going to be affecting an entire network, you cannot afford to wing it. As professional divers say, "Plan your dive, and dive your plan." In other words, take time, and figure out exactly what you need to do to get the results you want, then write the script to do exactly that, and no more. Of course, with actually writing the script, the tools you use become important.

For just writing the script, getting the code on media, I still prefer Apple's Script editor. It's very basic, and rather Spartan, but I personally find this to be an advantage, as it gets in my way less. Script Editor is a clean sheet of paper, and for some this can be a help. I also really like its dictionary display. If you want a clean display, but with more features, then Smile can be a help too. It's freeware, so if you find you don't like it, then you have only lost download time. It also has a devoted user community, who are more than happy to help you out in discovering Smile's hidden features.

As you get to a point in your script where you need better debugging capabilities then Smile or Script Editor give you, considering a higher end development environment, such as Scripter, or Script Debugger is not a bad idea. Both products do an excellent job, both are well-maintained, and will server you well. Like any tool, I recommend trying both out, and seeing which one fits your needs and your style best. I know that I have left out FaceSpan, which is another excellent development tool, but as that is more of an interface builder, and the idea here is to avoid user intervention, FaceSpan doesn't fit in.

Regardless of the tool used, there are some basic principles to follow. First of all, build the script gradually. Each script has a core function, which should be built first, and tested first. Once the core is done, then any other features that need to be there for the core to function correctly get built. Again, avoid 'feature-it is' like the plague here. It's unnecessary, and witll only cause you problems when you try to implement the script.

The second principle is don't reinvent the wheel unless you have to. As you write scripts, try to write them in a way that lets you use parts of them in other scripts easily. As you do this, you will find that you can build more of your new scripts from old scripts, saving you time on the actual coding phase. In line with this, keep up to date on various scripting resources, links to which can be found on Apple's AppleScript page, at http://www.apple.com/applescript/. There are a lot of examples, as guidebooks, and other resources that quite often have sample code that does a lot of what you want or need to do. As long as it is being given away, take it and use it. Make your life easier.

The final principle is 'Cool is nice, correct is better'. Remember, these scripts have to run day in and day out, without handholding. They need to run correctly at all times, and they need to run reliably at all times. You cannot afford to have a network script that crashes your script server, or other servers, or user machines. By keeping the scripts small and simple, you will find this easier to avoid.

Example Scripts

Now on to the fun part of all of this, actual AppleScripts. All of these are scripts I use in my work, most of them work with other applications, or from within other applications.

Enabling Windows NT 4 sp3 or greater to use plain text passwords

This is one I have had to use on all my Windows NT PCs. Since I have my application installation points on an AppleShareIP server, I need to turn on plain text passwords. By using AppleScript, and netOctopus, I can do this with ease. Besides, there's something fun about doing Windows Registry modifications from a Mac!

property NoSelectionErr : "There is no computer selected. 
	Please select one!"
tell application "netOctopus"
	set theWindow to window "Computers"
	set theSelection to selection of theWindow
	if theSelection exists then
		add registry value of theSelection registry key path
"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Rdr\\Parameters"
registry value name "EnablePlainTextPassword" registry value type number value
registry value "1"
	else
		display dialog NoSelectionErr buttons {"Okay"} with icon stop
	end if
end tell

The first line sets up an error message which is there to tell me that I need to select a computer to run the scrip on. The next line sets the variable theWindow to the netOctopus window called 'Computers', which is a listing of all the computers, Mac and PC that netOctopus is currently managing. The third line sets theSelection to the computer selected in theWindow. This will be the computer that the script runs against. The if statement that follows makes sure that theSelection actually exists. If it doesn't, that means that no computer was selected, and the else clause is invoked, which displays our error message from the first line, and exits the script. If theSelection is valid, the line following the if statement comes into play. This line tells the netOctopus agent on the target PC to go down the registry path "HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Rdr\\Parameters" and add a new value to the key at that path. (The reason for the double '\' characters is that that character is both the file path delimiter for windows, and has special meaning in AppleScript. The double '\' allows that character to be passed as a text value. To see what actually is sent to the PC, just remove one '\' from the path.) The new value is named "EnablePlainTextPassword", is of type "number", and has a value of "1", indicating that it should be enabled. Once the script runs, the PC gets rebooted, and voila! Plaintext passwords. A very handy and useful script that is only twelve lines long.

Manually Scan Windows 9X drives with Norton AntiVirus

As anyone who has had to deal with 'Melissa', and her offspring are aware of, keeping ahead of virii is both difficult and critical. This script takes advantage of Norton AntiVirus's command-line scanner, and netOctopus's ability to run command-line PC programs to allow you to remotely scan drives on Windows machines. The script is very similar to the first one. In fact there are only two or three lines that differ, so I will only go over those lines.

property NoSelectionErr : "There is no computer selected. 
	Please select one!"
property thePath : "C:\\Program Files\\Norton Antivirus"
property theExecutable : "navdx.exe"
tell application "netOctopus"
	set theWindow to window "Computers"
	set theSelection to selection of theWindow
	if theSelection exists then
		execute PC installer of theSelection executable path thePath executable
theExecutable execute using any drive letter parameter "/L /B+ /M+ /HEUR:3 /S+
/REPAIR /DOALLFILES /ZIPS"
	else
		display dialog NoSelectionErr buttons {"Okay"} with icon stop
	end if
end tell

The second and third lines set up the path and application variables that are used in the script. The eighth line of the script is the one that does all the work. It tells netOctopus to run a PC installer on the selected computer. (This is actually the way to have netOctopus run any program that can be started from a command line, it doesn't have to be an installer.) The path and executable are gotten from the variables thePath and theExecutable. The parameters to the executable are telling Norton Antivirus to scan all files on the drives, using maximum sensitivity, scanning inside of compressed files, and to repair any infected files that are found. A script that can save you a lot of trouble, and it is again, about twelve lines long.

There are a lot of scripts that I and others use daily, but I think I've made my point. By using AppleScript, and scriptable management applications, and taking advantage of the resources available from Apple and others, not only can you automate the tasks I demonstrated above, but everything from creating desktop printers and network configurations, to doing address book file conversion between email programs. I hope this article is a help, and I've included some links to various scripting resources in the references section.

References

http://www.apple.com/applescript/

This is the best place to start, as it has all of the Apple information on AppleScript, as well as all the links I have below.

http://www.mainevent.com/

The makers of Scripter, one of two professional - level AppleScript Development environment.

http://www.lists.apple.com/lists.taf?function=subscribeinfo&listname=AppleScript-Users&digest=Yes&listType=Discussion

This is where to sign up for the Apple AppleScript User's list. If you do almost any scripting, this is one of the best sources for help. Almost anyone who is anyone in the world of AppleScript is on this list, and the quality of help that I have received from it has always been absolutely top notch.

http://www.AppleScriptSourcebook.com/

Bill Cheeseman's site. If it isn't on Apple's site, then it's probably here. An absolutely fantastic resource.

http://www.prefab.com/player.html

The makers of PreFab Player, an application that allows you to use AppleScript with applications that either aren't scriptable, or have very poor scripting implementations.

http://www.latenightsw.com/

The makers of Script Debugger, the other professional level development environment for AppleScript.

http://www.tandb.com/smile/

John Welch <jwelch@aer.com> is the Mac and PC Administrator for AER Inc., a weather and atmospheric science company in Cambridge, Mass. He has over fifteen years of experience at making computers work. His specialties are figuring out ways to make the Mac do what nobody thinks it can, and showing that the Mac is the superior administrative platform.