May 2005 Archives

I got really tired of the fact that my phone was always out of sync with my address book and calendar on my laptop. This is the longest period in my life I've consistently kept a calendar and address book up-to-date and accurate. (The first time, I've really needed to.) Anyway, I decided to fix the problem and came up with a handy little AppleScript to handle the issue. Then, I run it from cron once an hour.

A few concerns:

1. The sync must happen in the background. I don't want to be bothered when it happens. I haven't quite succeeded here, but it's good enough for me.
2. I want to be notified when it fails. I don't want to find out that iSync hasn't succeeded in two weeks when I suddenly really need it and my phone is near and my laptop is not.
3. I don't want iSync open when it doesn't need to be. I have a nasty habit of forgetting to close applications as it is. I don't need yet another icon sitting on the Dock.
4. I don't want to get errors when my phone isn't near my laptop. If I'm away from my laptop with my phone or I've forgotten my phone, I don't want to get a message every hour telling me this. Duh, I know that.

I handle (1) by hiding the iSync window as soon as it opens. This means that it pops up briefly, but Apple is smart enough to not steal focus in this case. I probably could have hacked my way through and figured out how the iSync icon on the menubar activates syncserve, which is how it does it without opening the iSync application. However, I'll save that for the next revision.

I handle (2) and (3) by looping until the sync is complete. I don't know why busy waiting doesn't cause the script to take up more CPU, but I assume that the script engine must have some way of detecting busy waiting or simply nicing it down. Whatever it does, it doesn't cause a problem. I was going to add a sleep in the midst of the loop, but I couldn't find the solution after a few seconds. Again, perhaps a feature for the next revision but it doesn't seem to be a problem. Anyway, once iSync reports it is done, I check the result status. If the result status is happy, I quit. If there are errors, I leave the application open, which will show a popup on the screen (supplied by iSync automatically) containing the error log. Good enough.

The last part (4) was the most fun. I have a copy of Salling Clicker, which automatically connects to my phone via Bluetooth when it can. I check it before each run to see if the phone is connected. If it isn't, we quit without iSync. If it is, we run iSync. Easy. I imagine this script could probably be modified to do something similar by attempting to establish a Bluetooth connection via Address. I could also improve mine by checking to see if I've told it to stop trying to connect and either warning my that iSync won't run or by trying to reactivate the connection.

Finally, to run the script I added the following to my crontab:

5 * * * * /usr/bin/osascript $HOME/bin/iSync-Now.scpt

Okay, enough explanation. If you want the script to check out for yourself. See the attachment link below.

Cheers.

MSAD makes me very nervous. I tend not to trust that which I cannot see and the inner workings of MSAD are blackbox voodoo. Everytime our AD servers have a hiccup (such as the recent failure of one of our mirrored drives on our main domain controller) I get a queasy feeling in my stomach that the end is near.

This is probably the main reason for my strong preference for Open Source software. There have been too many occasions where something broke and I was able to hack a fix together because I could read the code and really understand what was going on. Blackbox programs, like those the CIS department uses from Microsoft and Oracle, bother me because the only way to fix things when something breaks is to either depend upon the providers to have adequate documentation, to become trained in how to fix them, or to pay them for help.

Active Directory is a huge product that we store a ton of information in—you can't help but do so on a Windows network. Microsoft Windows won't really talk to another directory system unless you severely coerce it to. (For example, Novell's NDS replaces Active Directory functionality by basically gutting Windows and replacing every security system on completely. Of course, Novell makes me nervous for the same reason Microsoft does.)

Anyway, I mostly wanted to simply voice the fact that blackbox software makes me very nervous. The more important that software is to my day-to-day life, the more nervous I get. MSAD makes me very, very nervous.

Well, for those who visit ~Sterling, you may have noticed my MS Report. I "cheated" a slight bit in that I mixed my academics with work. The basis of my work was an agent-based system for managing accounts. Basically, I designed a system that used a centralized workflow system to create jobs. Then, multiple independent agents would carry out the duties of these jobs. The original implementation wasn't very nice to work with or very robust. It was also grossly incomplete.

In the time since, I finished implementing the rest of the system and revamped the implementation a few times. Originally, I thought it would be neat to be language independent through the use of a simple HTTP communication protocol using simple text that could be parsed by even Bash with little fuss. Well, that wasn't such a great idea because it required implementing both ends of a communication protocol with any change. So, I gave in and reimplemented agent to workflow communication using SOAP over HTTP---far superior and still mostly language independent. The likelihood of wanting a bash-based agent is slim anyway. I've also added a protocol for automatically installing agent updates and handling of a number of new fields, etc.

Tonight I just finished the basis for a mini-language for writing new agents. The problem was that all the agents were written in Perl and it took between one and three days to write new ones, test them, and install them. Initial installation also required touching each agent-running machine to update the crontab. Furthermore, I had to be careful with the updates because a change that failed compilation could prevent automatic updates from functioning, which meant I needed to manually reinstall.

Thus, I've written an extremely simple language that embodies the needs of all agents. It includes a header (I call the "exordium" 'cause I'm a dork) with metadata information about the agent, such as name, description, version, etc. This information may be used for automatic updates and scheduling, but doesn't affect the actual agent execution. The rest of the file contains the agent program itself (I call the "coadjutor" also 'cause I'm a dork).

The coadjutor language includes a very few commands to do things. The REQUIRE command requires that a ticket in the workflow system contain certain basic information prior to being acted upon at all. The CHECK command validates the information in a ticket and reports an error if there are problems. The SET command alters information in a ticket. The WHEN and FOREACH commands allow for limited control of program flow. The COMMAND, OPTION, and EXEC commands execute an external program. These can also utilize a very simple set of boolean and scalar expressions. Any complicated work or extensions can be done through the use of external programs and Perl functions defined in a special package.

At this point, I think the direction of the system needs to change. Development up to this point has been completely proprietary for CIS. I think I'm going to start generalizing the system and then I'll probably release it under the Artistic License and I think I'm going to start looking now for places to formally publish some information about it.

The next directions I will be heading are to completely generalize the engine beyond account administration. It could quite easily be used to run programs on groups of machines in the department or recover backup files or notify users of other problems.

The new system won't depend upon a workflow system, but upon more general data sources. A data source would be any system that can provide distinct records to the agents such that each agent iterates over the records and takes action on the basis of the information in those records. A workflow system might be one such record system. An LDAP directory might be another. A SQL table could be another. The agents will also have a hook either to the workflow or some sort of logging system where the agent can put in requests for jobs to be undertaken by other agents or even the systems administrators themselves. In this way, I can generalize the system so that it no longer depends directly upon RT and so that the agents can do new things like, check that all users have a username that matches the campus wide eID system, or check that all users have a high enough quota and notify them if not. I could even have an agent that attempts to install agents on all machines in the department for which it knows the administrative password.

This will also make it general enough to be useful beyond our little department. I think I may have something more general available this summer.

I discovered something on my own today about the my Mac. Over the years, I've determined that it takes about 6 months to leave the newby stage, 1 year to leave the novice stage, and 3 years of using a particular operating system or deep-featured application (vim or LaTeX, for example) before you can become an expert. Obviously, this varies a bit, but one of my more favorite epigrams is "Patience is waiting months and years, not mere days or weeks or hours."

Anyway, I'm patiently learning more and more of the Mac esoterica and stumbled onto a nifty thing today. I was setting up SCPlugin, which is a Subversion plugin to the Finder (i.e., the Mac alternative to TortoiseSVN for Windows). Anyway, part of the process requires telling the SCPlugin preference pane where to find your Subversion.

This is a problem because I have it installed in a fairly typical location: "/usr/local/bin/svn". However, the Finder (and the rest of the GUI) is completely (or now I know, not quite completely) ignorant of the "/usr" directory. You see, you wouldn't want to confuse the typical Mac luser, I guess, with all the gritty details of Unix. However, there's a trick.

I was trying to figure out a way to get there when I tried to type "/" in the search bar of the "Open" window. Bingo! We have a winner. It pops up a window titled "Go to the folder", you type in any path you like and it shows up. Neat. This is also a handy short cut because browsing the file system is for slow sissies. I'll be moving faster from now on.

Anyway, this is probably common knowledge, but I'm just stepping away from the novice stage, so I'm still picking up bits and pieces.

I'm constantly amazed at some of the really great ideas Apple chooses to ruin. I, like many other Apple groupies, picked up my copy of Tiger (i.e., that's the code name of the latest version of Mac OS X for the uninitiated). Anyway, there are some nifty features, there are some features that will be cooler once there are more plugins available, and there are a few misfires.

Mail's Smart Folders are one of those failures, IMO. A "Smart Folder" is like the "vFolder" of Evolution or the "Virtual Folder" of Mozilla or Thunderbird. The basic concept is that you create a search for some mail and then create a folder which always contains an updated search. This way, you can avoid the risk of filing a message inproperly and can make it possible to sort your mail without taking hours. Since I receive hundreds of email messages a day (sysadmins get a lot of log information and error notifications in the form of email, plus spam, plus help requests, plus personal messages, etc.), I was looking forward to this feature. I thought I might be able to replace my traditional folders. Well, I was wrong.

Basically, it works great, except that the available search options are too limited. If they had made it as useful as the "Rules" feature, it would have been enough. But, instead it's crippled to the point where it is incomplete . I've attached a comparison of the options for Rules and the options for Smart Folders. The considerably larger menu is for the Rules. There may be a solution I haven't yet found yet since Apple often does include undocumented or little documented features for the power users that buy the Mac sycophant magazines. However, it should have been a no brainer.

Apple, why!? Why cripple something that you've already added in another place? Why?