Enterprise IT • 1:06:35
AppleScript and UNIX scripts can make managing your Mac OS X servers and clients a breeze. Learn how to create your own time-saving utilities by automating repetitive tasks using AppleScript, shell scripts, Perl, and the command line version of PHP.
Speakers: Joel Rennich, Andrina Kelly, Josh Wisenbaker
Unlisted on Apple Developer site
Transcript
This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.
Oh, it's great to see the room full like this. If you were here for the session last year, it had gotten moved four times, from like a Wednesday to a Thursday to a Friday to back to a Thursday and then back to a Friday. We had a smaller room, and we had standing room only. And so it really, really warms my heart in the enterprise track and the admin side of OS X to be seeing this many people in this room interested in this stuff. So thank you very much for coming for this. Thank you.
Last year we covered three different kinds of scripts in one hour. This year we're covering four. So guaranteed 25% new material. If you were here at the last year's session, you definitely have 25% more. Last year we talked a little bit about how to choose a language, a little bit more about how the different pieces fit together.
This year I want to talk about getting started with scripting and actually getting motivated about it. So to that end, we've got two people coming up here and I asked them to do some things that they hadn't done before to kind of get into that feeling of stuff. So, AppleScript and UNIX Scripting for System Administrators.
Who's a system administrator? That's beautiful. That's good. Alright, so good, you're in the right place. That's me, Joel Rennich, Consulting Engineer for the Enterprise Consulting Services. You might also know a little website that I run with some other folks. We'll talk about that maybe a little bit in the end. Save the applause for the end, thanks. So, let's get, why are they giving me the heterogeneous network slides? Okay. All right. Introduction to scripting in OS X.
So a little bit of the stuff that we're going to talk about, some script options that you have. Again, AppleScript, shell, Perl, and Python. So we picked up another P. Who was at the Python session? All right, good. We're not going to teach you Python. We're just going to do some sexy cool stuff with it.
All right. And why you're here, right, is lots of cool demo scripts. As fun and exciting as the slides are, actually showing real-life code, doing real-life things, doing things that make your life easier, that gets you napping at 2:30 in the afternoon because life is so good and easy, right? So what script? To that end, there's a lot of scripting languages out there.
Especially if you're new to scripting, you're going to get overwhelmed by a lot of this. This is all the stuff in 10.4 that we ship with. Notice now there's KSH fans. All right, yeah, but definitely, definitely if you're coming from Solaris or whatever else, do a lot of KSH work, we now have KSH here. So that's killer. That's one of the big changes in 10.4 that we took from 10.3. All right, so new to that. A bunch more that we don't have built in, but you're more than welcome to put it in. So a sea of options that are out there.
We talked a little bit last year about picking a scripting language. Still similar ideas here. What I wanted to do when we go through some of these demos, we took a common element, that of creating your own software update server, and we've written that in three different languages.
One person never touched Python until a month and a half ago, and I said, "Hey, why don't you learn Python for me because I'm on the plane a lot and it hasn't been very successful for me to pick it up." So I want you to learn Python. I want you to tell me how you can replicate what we've already done in shell and what we've already kind of done in AppleScript and enable that in Python, and what's the difference between picking scripting languages. All right, so we'll definitely speak to a lot of that as we go through these demos and talk about how you can pick the best scripting language for what you want to do.
The end result of all this, if you read the bullets up here, does the script do what you need? Can you know how to program in it? Is it going to accomplish something? Once you get past that, the actual scripting language is almost secondary, at least in my opinion. All right, we're admins. Beauty is in the eye of the coder. All right? You want it to do something, you want it to work. If it fits those goals, it's a good scripting language for you. It's a good script.
Don't have to defend scripting. I think maybe early on in OS X we did. People weren't used to writing their own stuff, admins. In the OS 9 timeframe, if you weren't an AppleScript developer, if you weren't an AppleScript coder, you probably just sat there and took things as they came your way.
Joel Rennich, If OS 9 couldn't do this, that's okay. I'll find another application. I'll wait until someone makes an application, or I'll just, I'm not going to do that. And hopefully now, nobody here as an admin takes that, okay? Joel Rennich, If you run into something that you can't do, you write a script to fix it.
If you run into something that you have to do over and over again, you write a script to fix it, all right? Joel Rennich, That's what scripting is. That's what we have the power of all these different languages and all these different things to do. Joel Rennich, And that's really what I like out of scripting.
It's not just a hack job. It's not a replacement for network admins. It's not always fast. Nobody ever writes scripts to be the fastest thing on the block, all right? Joel Rennich, Compiled applications are always going to be faster because they're compiled. But scripts are easy to write.
Who writes C? That's not a bad one. That's a little more than I was expecting. All right. Fair enough. All right. So definitely you can go with that option. How to start scripting. Maybe your hands are getting tired, but who's never scripted before? Wow, that's cool. There was about five people. That's very cool. Very cool that we've got that many people doing this many good scripts on there.
If you're new to it, right, what was the first, how did you start scripting? You had a problem. You had a problem that you didn't want to do. You had a problem that you were tired of doing. You had a problem that annoyed you. And that's probably when you wrote your first script. Once you got that first one going, it was a very steep, slippery slope. And probably now you spend more time looking for problems that you can script your way out of.
That certainly is an issue I have. Oh man, that almost works. I don't have any reason for it, but that's a beautiful line of code that I could just do something with. So definitely that's the way to start scripting if you haven't already, is to get a problem. Get a script.
The gateway drugs are AppleScript and Shell, right? We give those away for free. You just go back into your terminal history and you've got a Shell script. You hit the record button or you just start talking about some stuff and you've got an AppleScript. That's the gateway drugs.
Then from there, maybe you move to Perl, maybe you move to Python, maybe you move to any one of the other ones that we talked about before. Tools, we use a handful of different tools up here. My personal favorite is SubEther Edit, if anybody is here from Coding Monkeys.
Well, they already know how to script, I guess. All right. Well, thank you guys for SubEther Edit. It's my personal favorite. I use it a lot. But we also have a big fan of the BB Edit and Text Wrangler. Andrina's coming up here to do Python. She's using that. Might talk a little bit to that and how she likes it. Of course, TextEdit, right? Yay, text edit.
Text edit, all you need to write is script. Okay? Then we've got some AppleScript tools, Script Debugger, FacePan, those kinds of things. There's a couple other development environments. Xcode, of course, we're going to show you an AppleScript Studio app written from scratch as we go through there. And finally, as you get around to getting into scripting, you should never have to write all your code from scratch.
There is so much code out there. Now that you've got Spotlight, I've got a folder full of code snippets, probably a couple hundred different text files. I really like Spotlight because I can put something in that, and I can search just that folder, and I can find when I've used this utility, I can find when I've used that little bit of code before, and then I just cut and paste. I almost get coder's block sometimes when you open up that blank window.
You're like, "Oh man, I've got to start." Where do you start? This is so daunting. I'm going to end up with a couple hundred lines of code when I'm done. You don't have to worry about that. So use the examples, use the scripts that you already have. All the scripts that we're going to do here, we're going to post on AFP 548, so you're going to get them onto there. Since it was such a collection of different scripts, thank you, thank you. It was such a collection of different scripts from different areas, we couldn't really easily get them through legal in time to get put on the DMG. Alright, so, pick them up from the site.
AppleScript, I want to hit real quick. There's one or two new things, and I want to highlight one or two new things that, for the AppleScript that I do, is very important, allows us to do a lot more functionality. And then we've got Josh that's going to come up here and create something useful in 15 minutes or less, hopefully geared towards admins.
AppleScript, start off language control other apps, fully functional in its own right, been around since OS 7. We all know this. Advantages to AppleScript is the big thing is the GUI. There's now other ways of getting Python and Perl and even shell script into GUIs, but by far the easiest is by going through AppleScript or an AppleScript Studio app. By far the easiest to get through all that.
It's probably easy to pick up. Who started with AppleScript? Probably about a third of the audience here started with AppleScript. And once you got to AppleScript, you started getting exciting about scripting. You started learning those techniques, that basic logic, and then you moved your way on to some of the more advanced stuff if you outgrew AppleScript in certain areas. So AppleScript Studio is cool, very cool.
Disadvantages, spoken English syntax, right? Who's gotten confused by AppleScript that they wrote 10 years ago, tried to go back to read it and just was, "Oh my." So that goes back to commenting and making sure you have clean code to begin with. But definitely AppleScript can get a little wordy in there, single-threaded, and it's only on the Mac. All right? That statement has changed a lot in the last couple days, I think. But AppleScript's only on the Mac.
So if you want to write AppleScript, you have to deploy on the OS X on Mac. All right? Here's a sample AppleScript, really quick and cheesy. If you've written AppleScript before, you see what this does. Checks the file size or your free space on your drive, says something, displays an alert, that kind of stuff.
All right? Shows you how easy and simple it is to get into AppleScript. It's just like speaking. The problem is you get used to that and then you want to say, "Computer." Get the coffee, answer all the email, fix all the help desk issues, and then put me in for a tea time at 4:00. So can't get that.
[Transcript missing]
Thank you, Joel. I know Joel asked about who was here that was a sysadmin. How many people here are-- I know this is in the IT track, but how many people are enterprise versus developers in here? Oh, good.
So understanding that outside of this room, probably, most people say enterprise equals Microsoft, how many people have to deal with Exchange at work? Oh, good. And you love Entourage, right? Okay. We have to deal with Entourage at work, and so I've got a couple of different scripts we've developed for Entourage to lead into our AppleScripting here. There were a couple of things we noticed about Entourage that didn't work real well.
It did not -- no, and I like Entourage, sorry. It does not archive calendar items out of your calendar and blows out your storage quotas, and it doesn't follow servers if servers ever change. We've got about 20 Exchange servers at work, and if they remove a user to another server, Entourage just loses its mind. It's a perfect example for AppleScript.
And is there anyone from Apple here on the AppleScript team? Script editing editor team? No? Oh, yes, because -- okay, more people. You've done something beautiful in AppleScript editor in 10.4, and that's you've reworked how we get to look at our dictionaries. And now we have this wonderful-looking interface, and I just would really like to say thank you for doing that.
The first times we ever used AppleScript back on OS 7 and 8 and 9, we didn't have a shell to push around, so AppleScript pretty much exclusively pushed around other applications. You'd tell, hey, Finder, do this, and hey, Word, do this, and hey, Excel, do this. So this first script, of course my comments, a boss entourage around, and what this script does is very simply it looks through a calendar, and it takes anything that is a non-repeating item in your Exchange calendar that is older than 30 days and marks it to an archive status, and then you tell entourage not to archive, not to synchronize that status, and it builds a 30-day dropping off the server, and it turns basically into a personal calendar, which is something you can't do in entourage normally because you only have one calendar. This way the events stay in the user's calendars, they're removed from the Exchange server, the Exchange admins are happy, the users are happy, and they don't have to think about it because you just tell it run every day, and it automatically rolls these things off their calendar.
Looking at it very easily, this one is just AppleScript, and entourage has a little bit of a funny dictionary, and I will say that Microsoft's news groups are very good for getting troubleshooting information, especially on scripting with their apps, and just to take an easy look at this one, we see the basic language of AppleScript, tell application, and you actually name an application, and AppleScript gets really wordy, it is a very natural language. This is a very natural language. which does lead to lots of tell the app of the window, of the hard drive, of the folder, and you get these things that go on and on and on.
But--so this is just a very simple script, and Entourage is not on here, so I'm just gonna show you it a little bit. You get to weird things sometimes in apps. For some reason, Entourage, you have to stick these-- sometimes stick another tell in there that doesn't actually do anything to kind of wake it up to keep it going.
And then AppleScript has some nice ways to handle dates now. If the date comes before the current date, -31, so it just easily is a nice way to calculate out one month ago. So we've deployed this script out with Entourage, which actually has very nice script support. If you see the slash CA on the end, that adds a keyboard shortcut in a Microsoft app, so then users can hit Control-A and archive their calendar anytime they want.
A bigger problem for us with Entourage was the fact that if a server changed, it did not refresh the server, and they move users around servers sometimes for maintenance or other reasons. So this is an example of doShellScript. So doShellScript is a nice new thing we got in OS X with AppleScript, and what it allows us to do is send a command through to the shell.
We get a response back from the shell as text generally, and then we can use that. So here it's very simple. You just enter in So, this is your domains and variables here at the top, and this assumes you're using the AD plugin from Apple, and then it basically uses Discl and it goes out and it looks at the username.
And then it just looks at the current user. And then what it does is it determines where their home server is for exchange. And then it bosses Entourage around and changes the free/busy and it changes the exchange server settings of their account to be able -- of the last exchange account. And it changes it to be able to follow the server then when things move.
The first time in our Macintosh group that they moved some servers after they had started using Entourage, there was this flood of support tickets in the morning because about 15 people could not find anything in Entourage. It was all gone. And so panic sets in. They're designers. They start rioting and running around with pitchforks and things like that. So that's an easy example. Do Shell Script can be very simple. This Do Shell Script is one shot. It's one big, long, piped-up, ugly-said command and a display.
And then you have the disk command. So I hate -- I'm not very good a lot of times with the said commands. So mine look ugly. If people in here probably looking at it, they're like, "Ah, he could have done that one step." But, you know, it works.
Then you can also mix actual shell scripts with the do script command. So here I've got another one that you put a script in there, and you just put this shell script anywhere in your system. The shell script itself is very ugly as well, but basically what it does is it looks at your AD domain and looks for the LDAP service records, and then returns all your LDAP information, ping sorts it by response time, and then you pick a fast one off the top of the list.
We have another issue where they tend to like to upgrade LDAP servers during the day and things. They don't realize Outlook on a PC just goes, oh, I'll use a different one. But on the Mac it's all hard-coded into the exchange settings of Entourage. So this one calls a shell script, which actually writes to a temp file.
And then this goes through, and because I was exceedingly lazy, and it puts dead servers at the top that have zero response time, because sort considers that a lower number, I just take the fifth one off the top of the list. Scripting isn't always about doing everything in exactly the best way possible, but this works really, really well. We've never had more than two dead LDAP servers at any given time, so I went ahead and told it five.
Play it safe. I can roll this out to my users. Now, I don't get a support desk call when all of a sudden the LDAP server freaks out. Their own little help desk people down there can say, oh yeah, hit control R, and it'll refresh your LDAP script.
So those are just some basic examples of just really easy AppleScript. The other stuff that I want to talk about here is-- AppleScript Studio. And in this case, we're going to actually build something. If you came-- Joel and I were out here in January and we did an AppleScript Studio session and we came up with this nifty little app.
called PolicyMaker. PolicyMaker is a front end to PWPolicy, and it allows you to simply set some password policies. PWPolicy picked up a lot of nice features in 10.4. It can now pretty much do anything on a local user as you could do on a password server user on an OS 10 server.
So because of that, we can sit there and set things like maximum filled logins. And one of the nice new flags it picked up in 10.4 is an enable user, so that if a user has hit these policies and become disabled, you can actually use PWPolicy to re-enable the user.
And what you can do with this is you can create a little AppleScript Studio app that's extremely simple that you can give to help desk people. So you don't have to give them Work Group Manager or access to Work Group Manager so they can go in and re-enable something. This way, you can just have them open up a little box, type in the username, and click an unlock button, and it will unlock the user account. So we're going to go through. We're going to give-- a user here a policy. Maxman Feld Logins.
So that's two. How about that? Okay. So now if we come to the command line and we try to switch to that tech user, we can see that he works unless he's already logged. Okay. You know what? We're going to reset his password very quickly here. Okay, now we're ready to go. So we can SU to him. Right? And we've set up a policy though, so if he botches his password a couple times, Now he cannot log in.
He's locked out of his account, as he should be. So using the pwpolicy command, We can start to look at ways to unlock him. And just when you write an AppleScript Studio app and you do anything but do shell script, what you need to do is start looking at what the options and flags and commands are. So I can see here that I want to use an enable user command, which is right here.
I can see that I need to specify an authenticator and a password for the domain, which you can then obfuscate inside when you do a deployment build of your scripting. And I can also see that I can specify a directory node here, but if you don't do anything, it's just going to go down the search list in directory access.
So I can figure out really easily that I can use a PWPolicy command that looks like that. Demo admin, unlock, user tech, enable user. And then very easily, that allows me to re-enable text account. So wouldn't it be nice though if I didn't have to A, hand out a password and mess with the Etsy authorization and make this neutered admin that can do that.
And I don't have to tell people to go to the command line and say type in PW policy. If you guys have helper monkeys, you know that's not going to work. So what we like to do is be able to do it in AppleScript. AppleScript Studio, and one of the most important things about AppleScript Studio apps is giving them nice pithy little names.
So we'll call it Keymaster. And it builds a little app here. This is just standard-looking stuff. You can see inside under Resources the AppleScript Kit Dictionary. So if you ever need a reference when you're looking at building your AppleScript stuff, you don't have to keep flipping back to a PDF. They actually just stick it in every single AppleScript project as another resource you can look at. We've got our basic script here, which currently has nothing in it. And where we want to start is with our nib. So I'm going to open up Main Menu here.
That's fine. And so now I've got my little nib here. And the first thing I like to do is-- is come in, and I'd like to give this the name that matches our application. I'll take out some things. We know we're never going to need a window menu in this application. We know we're never going to need a file menu in this application. I want the window to match the same name.
And then there's something important that I have to do for AppleScript Studio. AppleScript Studio will not look for that window title. It has no clue about what that is. And one of the things I really hate in Xcode is that this list changes. Have you noticed that? Sometimes AppleScript will be command 7, sometimes it'll be command 8.
This time it's command 9, which I've never actually seen it be before. So if anyone can figure out what's going on with that, it'd be nice. Joel Rennich, Andrina Kelly, Josh Wisenbaker And I have an important thing to tell you that I've discovered about the Intel stuff with AppleScript Studio that we'll get to.
But here, I need to give it an AppleScript name. And I'm going to go with "Main" because that's a good generic name. So now I can use AppleScript Studio to call that window by its name of "Main." I'm going to need to change a couple things about this window. I don't want them to resize it. And then I need some little widgets and do-bobs. I need a button. I'm going to go ahead and make this smaller because it doesn't need to be that large.
So there's a button, we'll call it unlock. And then I find if you give these things really easy names, we'll call this one button. That one's kind of hard to miss. And then we've got just other simple things. We'll drag in a text field for the put the username in. We'll call this one-- call this one username. How about that? Just some font text here. And notice how I get all my-- you guys have seen Xcode. You get all your-- the metrics and everything get laid out for you. Say, enter user's short name.
And then I want to take another one here because I like to give status text to my applications. One of my big pet peeves about apps are apps that don't actually tell you when they're doing things or reply that something happened. I need to know whether something was successful or something was not successful and things like that.
And in this case, PWPolicy is going different information. Like if I click on it and it's not disabled, it tells me, hey, that user is not disabled. And I've found out that that's the longest reply I'm going to get from PwPolicy. So I can select that. Go back to Interface Builder, paste that in here, and then I can size this box based on that.
Okay, so I'll save my nib and then I can run it right there. Check it. I do want to make that button the default button. So if I give it the return, and Interface Builder is absolutely wonderful to use. So now I've got this actually functioning little interface, but it's not hooked up to anything yet.
So the way I do that is I go back into AppleScript and I set up a handler when the button is clicked. And I've taken fonts off this machine. Joel Rennich, Andrina Kelly, Josh Wisenbaker Normally this will show up down here. If you pull some of the key Apple system fonts out of a machine, then AppleScript Studio will freak out and it will not show things here. So let me try the other version of Xcode on here. Let me see if I can open up a pre-made one.
How about that?
[Transcript missing]
So if we look back at our nib, if this was functioning in a way-- oh, there it is. OK, good. Notice that this time AppleScript is number eight. I can come in here and I can click on this script. This is the script that this button handler is tied to.
Click Edit and now it starts my little script for me. On clicked the object, add your script here. So let's start adding our script in. After we finish our nib, username, and that needs to be... Status Text. Like I said, easy names make it easy to remember everything.
So the first thing we wanted to do is we want to figure out what the name of the user is in that field. So since I'm nice about this and I've written stuff that I have no clue how it works five or six years later, I'm going to comment the code. Get the username. And here right away, we're going to start seeing the wordiness of AppleScript. So it's tell window main.
And I'll make a variable just the user. So set the user to contents of text field. And then we use our AppleScript name we put in. Can you guys see that? Is that big enough? I just noticed that. Let's try this one more time. Get out of there. Fonts.
288 would be good, but it's not going to let us see that. Which is the command for that? Anyone remember off the top of their head? Option +. Thankfully, Apple has some stuff to help us with this. Zoom on. And that would be Command Option Minus. Which, of course, that's going crazy on.
How's that? Okay, now as long as I don't touch the mouse, we'll be okay. Because I'm using a GUI scripting tool. So we'll set the user main to the contents of the text field username. And that just looks back at whatever's in that field. So we've now set that, and we need to attempt to unlock our user.
And we just put another comment in there. And we need a little bit of error handling. So if the username is equal to nothing, I need a what? Double dash in there? Oh, thank you. There we go. See, the machines start blowing up and things go crazy. Thank you very much. So if the user is equal to nothing, then-- and here we'll start calling that text, that status text field. So contents of text field.
[Transcript missing]
And this is where we go into our PW Policy stuff. So we're going to set the contents of the text field Status text to do shell script. And here's where a little trick comes in. Ooh. Now I need to make that smaller. So I've got my PWPolicy command here, right? So what I want to do is just select this guy.
Is everyone dizzy yet? To do shell script, and we just quote out our shell scripts, and it will, tab it in. And then what I do is I'm going to go and take that user, the user tech, that's the part that I'm pulling from my variable, I want to just replace it. So I delete it, I end the quote, and... The user and another quote. And then I probably need to put a quote on the very end. I already did that.
So you just take your stuff right out of the shell, and you just paste it in here, and then you comment out what you need to do. AppleScript does get really weird with a bunch of different escaping going on sometimes. So you have to make sure that everything is escaped properly.
So then I take that and I say, if the contents-- because I know-- remember I saw that thing where it said is not disabled? So if the contents--
[Transcript missing]
And this is an example of scripting where you have to just get kind of creative. And AppleScript having some nice things to evaluate with does not end with... And at the end of that line, it just said, is not disabled. If it was successful, you saw earlier, there was no return. So I can just say, disabled. So if it doesn't end with disabled, then I know that it actually worked. Then set contents.
of the text field again. There's a lot of this in AppleScript. Did we mention it's wordy? I think I should have had you guys at work. That would be good. So set status test to just user unlocked. And then, of course, all the wonderful Ns. End if, end if, end tell.
And hit enter, and look, it actually worked. It verified the syntax. Isn't that nice when that works the first time? So now I can click Build and Go. And there's my little app. I can put in my username. And I forgot to erase that first. So tech is not marked as disabled.
If we were to use PW Policy, which was the thing we built last time, All right, actually he has a policy already. So if I go back to my sutech, mess up his password, mess up his password, mess up his password. And then I go back to Keymaster, user unlocked. So it actually works.
Despite all everything else. It's nice because you can take this then and you can customize these sort of things. That's the really basic hello world version of this. You can take that then and you can go further and you can take it and extend, say, you make it look with Disco let your search path and build a pick list of your domains you have that someone can select different domains and you can do all sorts of things like that.
Joel Rennich, The other big thing that came in AppleScript Studio and I'll just mention it very briefly is do shell script has it with administrator privileges item that you can run. Joel Rennich, And new intent for So it just with administrator, and you can't read that, can you? Let's see if we can get that one bigger. Hey, that one actually works.
So I'm typing this out here. There. Check that syntax. Yes, and I can't spell, but luckily-- Oh, I misspelled administrator. Admin is great. You guys know what it says. There was a problem that used to be in AppleScript Studio, and that's you had to embed this stuff in your pseudo commands.
And then if you looked at the process listing, it actually was just echoing and piping, and so you would see your administrator username and password in the process, which was a lot of fun. So now it actually has authentication and pulls up the authentication system of the OS. And you can run your results right there. And it does not embed your username and password in the process listing, which is very important.
Thank you very much. Hand it back over to Joel now. Say something about Intel. Oh, yes. Intel. Currently, and I've discovered this in the ADC labs, you cannot build a universal binary on a PowerPC machine. If you try to build an AppleScript Studio universal binary, and specifically AppleScript Studio binary, on a PowerPC machine, it will fail.
You can do it on an Intel machine. We'll build a PowerPC, but it seems right now in Xcode 2.1 you cannot make, and I've tried it on four or five different machines just to make sure it wasn't a variable in the hardware or software of the machines, but no. Right now to build a universal AppleScript binary, you have to use an Intel Mac. Thank you very much. Thank you, Josh.
Something useful, right? Yeah, useful. Cool. So in that, we concentrated a little more on shell last year. I wanted to put a little more AppleScript in here. I do a lot with AppleScript Studio just for putting faces onto things. We'll package a software update system. We'll run a little short here. So we're going to package a couple of different software update systems, and we'll put that onto the site.
So you can take a look at different ways of doing the same thing. Josh has some really cool stuff with that. So once we get off planes and we actually have some time in front of a machine, we'll put more stuff on the site. We promise. We promise. So this will all be up there.
Here's an example of the interaction with the shell commands. That's, again, do shell script. And like we said, cool, killer new thing with 10.4 is that that authentication is done in there. It's done the right way. You get the trampoline. You go from there. You don't get echoed into the command line. So that allows AppleScript Studio apps now to be much, much, much more viable for administration tasks in your environment because you don't have to worry about embedding passwords. You don't have to worry about the security risk that's involved with that.
All right. Shell in like about five minutes or less, right? We'll cruise here. We all have some time for some question and answer. Oldest scripting language around, pretty much, right? Somebody's going to take offense to that because I'm sure there's something else that's older. But it's certainly one of the old guys. Cool stuff that you can do with shell. I use shell as my primary language now. I'm trying to get into Python.
I want to get into Python. But I just naturally fall into shell. And when I write in my sleep, you know when you wake up and you had that dream of all the codes you wrote? That I write in shell. And so that says something to me. But I've got to expand my horizon. So that's one of the things that I've got to do. And I'll be doing over the next couple months. Advantages to shell, most of us already know it.
If you've ever used a terminal, you know it. You've used shell. Now I can just paste it all into a command line or paste it all into a text edit and go from there. Very portable. Some disadvantages that we have here is obviously we don't have a GUI. So for that, I usually use AppleScript Studio.
There are some other GUIs out there that allow you to do that. Some shell script functions are very hard to do. Setting up an SSH connection through just a shell command requires you using expect and some other things. other stuff that really makes your brain hurt after a while.
Simple mail server backup. All right, these are a lot of the kinds of scripts that I write. They're stuff that we don't necessarily have. We've got this beautiful, beautiful, beautiful open directory backup now in 10.4 server, but we don't have a mail server backup yet. So here we can use server admin to shut down the mail system. Just zip it, tar it, rsync it, ditto it, whatever you want to do. Get your mail database off somewhere else, and then start it back up.
And this is why I like shell is because Apple has tried very, very hard to make sure that all the functions that you could ever get in the GUI and then some are available on the command line. Knowing that, you know that you can probably script anything that you want through the admin tools. A very, very powerful, very, very complete way of administrating and helping you with stuff.
So now I want to get into a demo. This is something that I thought was really cool. I didn't know that it was going to work quite as well as it did when I implemented it. At my house, as I'm sure most of you do, I have a couple extra cluster nodes.
I'm a little, I feel a little embarrassed about that. But hopefully I get another seven drives before too long. But with a cluster node, if you've used a cluster node, they can kind of be kind of, they're a different beast. You've either got a remote setup, you've got to do a FireWire target disk mode, Netboot, something else like that. My network, the cats keep stepping on the gig switch and pulling out cables. So I'm not hitting 5.9 up times yet. And I need to be able to do that. I need to be able to have a way to reimage my machines.
And I got very, very tired of doing all of this through Netboot Server and having to have my desktop be a Netboot Server and that kind of stuff. So instead I kind of came up with what I really like, which, I'm going to reach into my bag here.
FireWire Drive. I've got a FireWire Drive and I've got an OS X system on here. That OS X system has a startup item. That startup item goes and formats the drive in my cluster node. It then takes a disk image right off here. ASRs it down onto that freshly formatted partition on that cluster node. When that's all done, it shuts down.
Absolutely no user interaction whatsoever. When it comes back up, I don't know what IP address it's supposed to have. It doesn't know what IP address it's supposed to have. The image is fully configured and fully installed to a generic IP address. So then I take one of my key drives, my thumb drives.
I slide that in there as it boots up, and I've got another startup item that reads in a config file. IP address, serial number, all the other configuration information that I want, and applies that to the cluster node as it goes through. Joel Rennich, Andrina Kelly, Josh Wisenbaker All right.
Now I've got a completely, well, semi-automated. I need somebody to plug this in, use front panel mode, and boot off this. Once you've done that, everything else is done for you. So I need no keyboard. I need no video. I need nothing on this XServe cluster node. That's shell script. That's the stuff that allows me to go home early. So sub-eth edit, and I've got a couple of config files. I can take a quick look and show you this. All right. Pop on here. And it's a really pretty simple setup.
We go through here. Look at the drives. We use DF. So I've modified this for both XSERVs and cluster nodes, depending on how many drives you have. Go through there. Parse that out. Then we go through. We grab ASR. We grab an image, and we image it onto it. Maybe do some other stuff. Maybe I set up an Apache 2 folder.
Maybe I kick some other things off, drop some config files in there. I then copy a config startup item onto there. And once I get that config started, I'm going to go through there. item, it's going to pull from that USB thumb drive that I pop in when I boot up again, all right? All that goes in here, then that deploys an image with a startup item, which is this auto configuration file here.
This goes through and then implements all those that it pulls off of the config file. So then we can use the network setup command, the server setup command, we can set a serial number, we can set an IP address, we can set all of our information here. Not that we necessarily need yet another way to automate deployments.
But this can sometimes come in really handy. This means that I can get airdropped into a client location and I can set up equipment without worrying about keyboards, without worrying about monitors, without worrying about KVM switches, without worrying about networks. How many times have you had to set up a couple machines and the network guy hasn't come in yet? That's a pain.
Remote setup is a lot harder when you don't have a network to work with. So some cool stuff that you can do. This, and it's such a simple, we're probably talking maybe a hundred lines of shell here, but does a really nice, really easy job of going through these. So back to the slides if we could.
So we're going to also we're going to post that code on there so you can take a look at it. We're going to build everything live but and they didn't tell me we had XSERVs here or else except if I get too close to them it's going to do some weird harmonics here. But if I knew that we might have booted some of them off it. It's pretty cool to see except it's not really as graphical as it could be because there's no monitor.
We're also going to post Cheesy Soup. Cheesy Soup is a shell software update system. It goes out, it curls down packages from web servers and then installs them using the package installer command. There's some things I'd like to add to it but I took this and when we get to the Python section in a few minutes I took this shell script that I hadn't touched in probably about a year and I called up Andrina and I said Andrina we need some Python demos.
But we also need some examples of how easy it is to pick up a new scripting language. There was silence at that point on the other phone. So Andrina has taken this and translated it into Python. She's going to walk you through that. So I'm going to leave the sexy cool new stuff for her. We'll post this on the site and you can compare and contrast the differences between those.
I also real quick want to mention interaction with AppleScript. There are some things that AppleScript does really, really well that shell can't even touch. One of them is interfacing with the user and allowing them to pick something. So here's a little 10-line combo. The bit on top is a shell script.
You run that shell script and it calls an AppleScript. That AppleScript pops up a dialog box. So this is not an AppleScript Studio application. This is purely a shell script that has an AppleScript that joins with it. We call it an AppleScript. We call that AppleScript. It pops up a chooser file.
We pick that file. We then echo it back to the shell script, which means we can do something else with it. These go as a combo. You deploy them. You allow somebody to click on. You run a cron job that does that shell script. We then get an interface with it. We get user interaction and pass it back to it.
There's huge amounts of things that we can do with that. I know someone that's working with things like this to allow users to be kicked off semi-gracefully off a machine. You know what I mean? When you're using ARD and you want to do package updates and push those out, but maybe they're still in there, but you want to reboot it because you've just done a 10.4.1 update. So this allows some interaction and we can see if the user is there or not.
So ideas like this really help you take what you want to do and really make them into reality. If you're just coding in one language, if you're just coding in one scripting language, you're really missing out on a lot of stuff. I want to let a bias on the table. I don't think I am worthy of Perl.
I look at Perl, I read Perl, I own half the O'Reilly library on how to program Perl. My brain has been compacted as I grow older, and I have yet to get into Perl as much as I should. For those of you that do Perl, you probably love it and you'll never go anywhere else again. I'm a shell guy. I want to change. I do. I want modules. I want a user community. I want camels on things. Shell doesn't have a fancy animal logo.
But one of these days. For those of you who have gone Perl, you don't go back, right? Maybe? Depends on the simplicity, depends on, well, and so Python's coming up, so we'll address that in a little bit. So Perl present on a lot of UNIX systems. This makes cross-platform, at least on the UNIX side, really, really nice.
If you get Perl on Windows, which is also available, now you can have a script that can go anywhere. All right? So very, very active developer community. Lots of advantages to Perl. Lots of advantages to Perl. The Perl motto is, there's more than one way to do it. All right? And you'll notice that's an incredibly big disadvantage, too. Thank you.
When I do Perl, I spend more time trying to find the right module that I want to use or the right sample code that somebody else has already written that I want to borrow instead of actually coding. So that's one of the things that I've gotten kind of down on Perl. For me, it's got the highest learning curve. Item number two up there is entirely personal opinion, but for me, it's got the highest learning curve. It might have the greatest rewards when you're done, but for me, it's got the highest learning curve to get into there.
Simple Perl script here. Just give you something to chew on when you read the slides. Spins off an SSH process, demonizes it. It's a nice easy way to demonize things. If you want, I'm just kind of running in the background but always there. I wasn't able to do this very easily with shell, so this is something that I had to do with Perl.
I was actually calling this from an AppleScript Studio app that was using shell to call a Perl command and then come back. And it wasn't just because I could. I actually had to for the time. What I want to show you here, another example, This is of a Perl script that I thought was really cool. A friend of mine from Purdue University, they use this.
And what this is, it's a login hook. And so when you log into a system, we need to make sure that we've got some preferences that are what we're looking for. We want to make sure that you have mail preferences that work. We want to make sure that your Mozilla defaults are where they should be.
We want to make sure that you have the user environment that you want. And when they do this, when they create new users, they actually give them preference files. Joel Rennich, Andrina Kelly, Josh Wisenbaker All right, they've created their own preference files. There's no app, there's no Cocoa behind any of that. They just create preference files with the defaults command.
This script runs and it checks for the presence of that pref file. It reads out of the defaults database. It gathers whether something has been done or not before. And then we have a bunch of sub-processes that hinge off that. If the user's already been set up for mail, we don't have to worry about that because there's already that flag and that plist.
When they deploy a user, they can preset the plist and they can say this user doesn't use mail. This user doesn't use a network home folder for music. This user doesn't use Mozilla, so chop that off. And now when this login hook runs, we can customize the login environment for individual users based upon what we want them to have or not have.
If we wanted to even improve this a little more, we could pull this off a website or something else like that. So what this is using, it's using the defaults command. And it's just a shell command or a system call that Perl is using to go in from in there. Once we get those variables, cruise down here towards the bottom and we can see that we spawn off all these and we'll do actions based upon that.
This is cool. Who thought you'd have a preference file for a shell script? Just the frameworks that we already have from within Apple. We can use these command line commands that we've already been using. Who's used defaults just on its own just to find stuff? Defaults is a cool command. Defaults really opens up the abilities that you have out there. I use defaults to massage apps all the time and login hooks. If an app I don't know, iChat wants to check your bandwidth when it goes into a multi-video conference.
I don't want that to happen on behind a firewall on some other stuff. I'm really worried about security. Now I can use defaults to precede that. And I can override and I can put that into the preference file. Here we're using it the other way, which I think is even cooler, where we're creating a preference file and we're pulling from that. Back to the slides if we could.
So a little Perl script you can get up from there. All right. Python. Honest to God, named after the comedy group. No bones about it. It's cool language. Any language that's named after Monty Python is all right by me. Mostly because it opens up a wealth of opportunities for naming things.
I think all the good script names have been taken, so now we're just into the realm of lunacy as we go through things. So definitely Python contributes to that, and I like that. Python is on most UNIX systems, the newer ones. It's a newer language, growing a lot, very active developer community. Some people have defected from Perl to it.
Other people like it better. Some people start with Python because it's a little easier to get into. Very easy to read. It's very easy to go back to code that you've developed before, even if you were bad and didn't comment it. Joel Rennich, Andrina Kelly, Josh Wisenbaker Python is on most UNIX scripts, the newer ones. It's a newer language, growing a lot, very active developer community. Some people start with Python because it's a newer language, growing a lot, very active developer community.
Python disadvantages. It's not still installed by default on some systems, so you've got to be careful when you're deploying. Some people still think it's new. I think it's 10 years or so that Python's been around. But in the world of UNIX, that's just a little baby still. So not quite as easy as shell or AppleScript, so I wouldn't necessarily consider it your first entry into scripting if you wanted to get your feet just kind of dangling in and get a little wet.
Here's a real quick simple Python script. We import an OS module so that we can use OS calls, and then we're going to actually do a system call to a disk util, and we're going to list out drives. And then we would process this from here. So you can see it's still pretty easy to understand. It's not nearly as stupid simple as shell, and it's not nearly as English syntax as AppleScript. So it's kind of a little more towards the programming language side of things, but that does lend itself to other opportunities.
If it's a Python script, you gotta call it something cute. So now we have Shrubbery Soup software update system. This is written in Python. I'm gonna bring Andrina Kelly up here. Andrina helps also with the site. If you've read some of the articles, you might see some from her. All right, so like I said, I called her up about a month and a half ago and I said, "Andrina, We've got to do some Python in this session.
Python's cool. It's becoming exciting and new. I don't know squat about Python. I need somebody that does. And I think, Andrina, that's you. So very gracious, very wonderful. She was able to go through and she was able to start from scratch with Python and create something. So I hand it over to Andrina.
All right. Thanks a lot, Joel. So what we've got here is-- you'll have to excuse my voice. I'm losing my voice today, but we'll carry on. The other scripts, if we'd seen them earlier on today, they tend to use curl. They're HTTP. I want to do something completely different, seeing as, you know, I had to learn something completely different. So we're going to use FTP instead. Now, the other thing about this script is it allows us to pass a host name at execution.
So generally, this script can be used anywhere. You're not going to need to modify the body of this script if you're going to be using it. You put in your name of your FTP server you want to connect to, and then it's going to be interactive throughout to actually download the things from your FTP server.
So we'll just go through this nice and quickly. The first part we've got here is importing some of our modules. There's a selection of things we're importing. We can import an entire module or just a portion of our module, like we're doing with the FTP here. Thank you.
We've created our own definition. I've created this just to make the actual download portion easier later on. I'm not going to get into this in much detail right now, but you'll see it further down and I'll explain what we're doing down there. Now this arguments part here. The argument is what we passed when we executed the script. So our argument is our host name. You can do it to your local host if you just want to play with it and create an FTP server on your local machine. Or it could be halfway across the world.
It's an FTP server. You can do whatever you want. And then we're going to keep on setting our FTP to keep our host name in there. And we're going to connect to our FTP server. This is the first part. Now, this is an anonymous login that I've created here. You can pass arguments one, arguments two, if you wanted to use a username and password. Just for simplicity, we're going to go anonymous.
And the next thing, of course, you want to know what's on your FTP server. There are other commands within FTP. You can change directories. But we're just going to be looking at the actual root of our FTP server here. And we're going to retrieve the lines. So we're just going to get a list of everything that is present on our FTP server. And this is where we go interactive.
Now, for the user, they need to know what we're going to be doing. Otherwise, they just get this prompt and they have no clue what to put in there. So we've got a little bit of text that will spit out at them saying, you can only download one file at a time, but just keep on putting them in. And we'll go from there. And we start off with our while loop. Now, the loop here is an infinite loop, rather appropriate. And it will keep on going until it reaches a condition which will fail.
So if we just continue on, we're just going to start out with the try statement here, and we're going to ignore these two if statements. So the first thing it's going to do is it's going to ask us for the file name. So it's going to prompt the user again, enter the name of the file you want to download, and it's going to accept it as raw input. So your user's going to put in the file name, and great, it's going to match up with something on the server, and it's going to download it. Which brings us down to-- So this is where we're using this handle download definition that we created earlier.
So it's just making this a lot neater and cleaner to read down here. There are some strangenesses when I was trying to do this interactively. It just wasn't working very nicely, and when I created that definition, everything went smooth as butter, so we just kept that in there. We're going to close out, and then because it's a--we're going to then use the OS system call.
It's going to expand the file that we've just downloaded. Everything that we're going to keep on our FTP server is going to be tarred up. If you're going to keep package files on your FTP server and download them, it gets into a right mess because, of course, the package is folders. You all know this, so it's fine.
And we're going to expand it and get rid of the tar file because we don't want mess left around. And being in the spirit of loop back to beginning. And it's going to say, hey, what do you want to do now? If our user is a very bad typer and can't type for their life and put in the wrong file name, part of the try clause here is also an accept statement. Right down at the very bottom here is our accept and just reminding our user politely that they need to learn how to type.
So once we've reminded our user that they can't type and they need to try again, we're going to go back. And this is where we can run into our if statements. If they've forgotten by this point, or it's rolled off the top of their screen, what their list of files are that they can collect from their FTP server, you can just simply enter in list. This is the same command that we had back here at the beginning when we were getting our first initial list.
We're just repeating it, but just so that it can be interactive with the user so they can be reminded. And once they've got everything, they're going to enter queue. That'll quit out of the loop, or enter queue. And not quite out of the loop yet, but it'll actually quit out of the FTP server. It'll close the FTP connection.
And here we're going to get into the OS System Call now. I've used OS System Call for a couple things here that could be done with other Python commands. I've done this just because I started learning Python a month and a half ago. Obviously, I'm going to go back to this once I've had a bit more experience. I'm going to go back and change things up, make it better, throw some more Python stuff in there.
But this particular one is going to be finding in the local directory, it's going to find everything with the--anything that we've downloaded and expanded with the .pkg on the end. And it's going to output it to a file for us. And this OS.SystemCall here is always going to have to stay in OS.SystemCall because there's no such thing as an installer in Python. So we're going to read for each line that we've just created in that PacMan file, and we're going to install from there.
If you're used to using installer and command line, you're going to know that installer needs to run as root. We could have put a root check in at the beginning of this. I haven't done it. And up to this point, you actually don't need to be root. So you can just go and download all these packages. And at this point, it'll just error out of the script and say you don't have the right permissions to do this.
Your packages are still going to be there. They're still going to be ready to install. And then you can either come and do it yourself later or just leave them there. Or even if you just wanted to bring them down, but you actually wanted to install them on another machine, you can just go and download all these packages. just don't get to do it.
And once you've done that, you've made some strawberry soup. All is good. You've got some excellent culinary progress. And we're going to break out of the loop. And this is what puts this out of the script. And that's about it. Hopefully we all run out of names because we're making so many good scripts, right? All the good names are taken. I'm just going to tell you that now.
All the good script names are taken. You've got to go with the silly stuff. You'll be okay. A couple of links for more information, and then we might do a little bit of wrap-up here and hopefully maybe take one or two questions, but we're really, really running tight on time. So, this is the WDC site. You've seen this before. Okay.