After starting to use
[Bad link], I wanted to switch my Drupal cron jobs over to it. I’d previously been running these jobs the standard way, loading a URL for each of my Drupal sites with
curl. That curl command was run by the
cron; Site5 allows editing of your crontab directly or through its Backstage Web interface.
I started with the basics. Drush was installed in my home directory, with an alias under ~/bin in my Site5 account. I replaced my curl command one-for-one with the following:
This didn’t work out well. I was getting a huge number of mail messages, indicating problems with the cron jobs. The messages typically contained “tput: No value for $TERM and no -T specified.” Needless to say, this was rather frustrating, so after some trial and error, I modified the command as follows, and that has been working better for me.
The biggest change is that I specify PHP, rather than Drush, directly. This was done so that I could increase the PHP memory limit for the cron job significantly, to 64M, while running Drush. I’m sure that this increase was needed partly due to the number of modules I have installed on my main site (which has an even larger default PHP memory limit in its php.ini). My research indicated that I needed to do this for Drush since it doesn’t access the Drupal sites in the same way loading a page does.
The other noticeable change is that I provide the path to the drush.php file rather than pointing to the Drush alias.
The McAfee DAT update 5958 was issued on April 21, 2010, and created quite a situation. Heretofore, I will remember what transpired as “the events of April 21.”
I think that someday, examining what happened would make an interesting case study in crisis management. A lot of the incident unfolded on the Internet — and
[Bad link]. The company even became a trending topic, as seen in this screenshot I took after lunchtime (I think around 2 PM Eastern time, although I only saved later):
The 5958 DAT was available on McAfee’s publicly-accessible HTTP and FTP download repositories until at least 1 PM Eastern, when I was checking on them.
The Windows and Mac anti-malware products from McAfee share DAT updates, which provide virus definitions. I was able to update VirusScan for Mac OS X to 5958 with no ill effects in the midst of the developing situation. (The problem only appears to have affected Windows XP systems.) Later, when McAfee had posted a newer update as version 5959, I was also able to download that.
Based on reports I saw on Twitter and the Web, McAfee was overwhelmed by this — particularly its call center and its Web-based customer forums. This allowed a lot of speculation and misinformation — along with humor — to break out.
I’ve saved this undoctored screen shot for a while. I figure I’ll end with it, even though it’s unrelated to the events of April 21.
I came across
[Bad link] and thought it was worthwhile to write down for later. If you want to get the screen or Desktop resolution of a Mac via Python, you can do so with PyObjC.
First, let’s get the information about the main screen:
If you want just the horizontal and vertical resolution from that blob of data, you can pull the width and height out:
This might be useful in situations where you don’t have any of the “hundred of portable libs in Python that give you access to that information” — such as in your stock Mac OS X Python installation. To clarify: I’m in no way meaning to belittle that there are portable libraries that would let you do the same thing, but you also have to program for your audience and its constraints. One of the reasons I appreciate Python over some scripting languages is that you get so much capability in the Standard Library. However, on Mac OS X, you don’t get modules like pygame by default (yet … and maybe never) while you do get PyObjC.
I’ve had occasion to create some installer packages lately, and the topic of assigning a version number to them has rattled around in my head. The version number of an installer package is shown in the Finder’s Get Info windows, and in the preview pane of column view, so it has some usefulness just for telling one installer apart from another. And, importantly, the version number provides a way for Installer to determine whether a package has previously been installed and simply needs to be upgraded.
At first, I was just going to assign the date in YYYYMMDD format as the version, just to “keep things simple” by using:
Then I was rebuilding the packages several times a day, and wanted to distinguish between the builds, so I switched to YYYYMMDD.hhmm.
This seemed ridiculous after a day. Although I could distinguish between builds, the installers I was building weren’t really changing per se. They were the same payload and scripts and resources, just rebuilt by the command line packagemaker tool using
[Bad link], and
My package sources are already checked into
[Bad link] repositories, so this made a good deal of sense. It meant that I’d have to use tags to identify a version number — it would no longer be as automatic as using the current date. However, certain parts of the version string would be automatic, and the only manual part would be tagging revisions in Hg.
I had already bookmarked
[Bad link] a while back, but had forgotten about it and never done much of anything with it. If I followed the Semantic Versioning standard, I’d create a “semver” tag to set up the repository, and then a new “vX.Y.Z” tag for actual releases thereafter. Steve further suggested the use of the “latest tag distance” and “short node hash” for the Hg revision, and that information is automatically available from Hg.
Semantic Versioning states, “when tagging releases in a version control system, the tag for a version MUST be ’vX.Y.Z’ e.g. ’v3.1.0’.” I felt I would have to strip the “v” from the version tag to use it cleanly as a package version. This results in commands like the following, where I’ve used sed to remove that character:
This is something I can build into makefiles for use with The Luggage, so I’m going to try it out. On first glance, I think it even fits in nicely with the concept of The Luggage. It automates much of the version-assignment process. And, it takes advantage of version control for both repeatable results and peer review.
I came across an interesting “problem” with Active Directory binding on Mac OS X Leopard. The symptoms were:
[Bad link], I threw the book at this problem. It ended up taking quite some time to troubleshoot, and the answer ended up being very simple. However, it wasn’t on my normal list of culprits.
The biggest clue I found, besides the symptoms above, was that the DirectoryService debug logs yielded this during Active Directory logins from loginwindow:
It didn’t seem like a smoking gun, but I’d never come across this “false” response on a bound system before. So, what group was so important to the login process that the DirectoryService debug logs cared enough to note the failure? I was darned if I knew, and I had no other promising clues at that point.
So, I investigated that group further, and found it by its UUID using dsmemberutil:
Well, that helped a little, but the name would have helped a lot more. I had to find which group corresponded to the GID of 200. That GID was not at all familiar to me, but it was under 500, so there was a pretty good chance it came from Mac OS X.
This was my eureka! moment. I wasn’t entirely sure, but I was pretty confident that the “com.apple.access_loginwindow” group was the access control list group for the loginwindow process. Loginwindow controls all graphical logins to Mac OS X, and is the parent process of each GUI login session.
Looking up the group’s description confirmed that it was the ACL group. I did the lookup in Workgroup Manager, which was set to view the DSLocal directory service. While I was there, I also checked the membership: it listed only the computational group “localaccounts.” The “localaccounts” group is essentially a query that returns all accounts in the local directory service.
Well, that would certainly prevent Active Directory users from logging in with loginwindow. The ACL consulted the membership of the “com.apple.access_loginwindow” group to determine who was allowed to log in via the GUI. Because it contained only the “localaccounts” group, the ACL was preventing all non-local users from logging in.
Not knowing how this group was handled or even what had last edited it, I compared the affected system to a different AD-bound Leopard computer, which also had Workgroup Manager. (It’s handy to have the Mac OS X Server Admin Tools deployed out to your computers even if you don’t have a server to maintain.) The second computer didn’t have the group at all, which perplexed me a bit.
However, that made me reasonably sure I could simply delete that group. I backed it up from the filesystem at the command line, just to make sure, and then deleted it with Workgroup Manager on the affected computer.
After that, logins for all Active Directory accounts I tried proceeded normally at the loginwindow on that system.
With the problem solved, I sought more information about the workings of the “com.apple.access_loginwindow” group. I confirmed that it is created when the “Allow network users to login in at login window”
option is turned on in System Preferences > Accounts > Login Options. This should be turned on by default, and that initial state results in no “com.apple.access_loginwindow” group at all.
Since the option is on by default, the really simple solutions to this kind of problem are:
Deleting the “com.apple.access_loginwindow” group removes it completely and reinstates login capability for both local and network user accounts.
Toggling the System Preferences option back on, adds the “netaccounts” group to the “com.apple.access_loginwindow” group, reenabling login for both local and network users. It does not, however, remove the group “com.apple.access_loginwindow,” which remains on the system afterwards.
Here's what that looks like in Workgroup Manager:
To prevent this on managed clients, I could see a system administrator proactively creating and managing the membership of the “com.apple.access_loginwindow” group. To ensure that managed clients bound to an Active Directory allow both local and network users to log in, make sure the group is populated with the appropriate nested groups: “localaccounts” and “netaccounts.”
Jesper Noehr explains why
[Bad link] for removing extensions from filenames with Python. I think he’s absolutely right on that score, and I would agree. The lstrip() and rstrip() methods shouldn’t be used for this purpose.
However, like the only commenter on that post, I’d also recommend os.path.splitext() as the proper tool for the extension-removing job.
Let’s take some example filenames you might come across on Mac OS X Snow Leopard:
If we had a list of filenames (or file paths) like this — perhaps created by os.walk() or
[Bad link] — we couldn’t easily use Jesper’s recommended solution. The replace() string method would give us a much harder time dealing with the range of filenames and extensions in that list. In the case where you don’t know the filename extensions in advance, replace() breaks down. The replace() method would have to be looped with many possible filename extensions.
What we need is a way to split filename from extension, even if we don’t know the extension beforehand. The os.path.splitext() alternative does just that, returning a tuple. Here, I’ll import the os module and then use a list comprehension to run os.path.splitext() through every filename in the list above.
It becomes a simple matter to get just the filename from the tuple, as I do here by modifying the list comprehension to just get the zeroth item from it:
Note that several interesting conditions are handled by os.path.splitext():
I had an odd situation over the weekend that resulted in the inability to view the passwords associated with keys in my Mac OS X user keychain. Every time I clicked on the “Show password” checkbox in a key’s detail window, I’d get an “Access to this item is restricted” dialog.
Needless to say, this was disconcerting. I happened to have a lot of data in that keychain — this is what I get for keeping the same one around since Mac OS X 10.0 or 10.1. While I could revert to a backup, the newest backup wasn’t as recent as I would like. Plus, I just wanted to know why the problem had cropped up.
[Bad link]. If anyone would be able to help with the obscure corners of keychains, I figured the people there would.
Very promptly, I got
[Bad link], which led me to check the validity of the code signature on the Keychain Access utility.
Clearly, the signature and the application didn’t match. Something was amiss.
I reinstalled Mac OS X 10.6.2 on the system, using the latest combo update installer package, and cleared up the problem signature mismatch.
In retrospect, although I wouldn’t have thought of this being a problem, this breakage between the signature and the app — and its affect on my ability to view stored passwords — gives me confidence that thought has been put into the code signing mechanism in Mac OS X. You wouldn’t want a compromised app displaying your unencrypted keychain items, after all.
I had interesting things happen when I ran out of disk space today.
The most notable one was that I saw “Process completed” — or some variant of that — every time I tried to open a Terminal window with a new shell session. I briefly staved it off by specifying Bash as my shell, but then it came right back after opening another tab or two in Terminal. Consulting Google led me to
[Bad link]. On a lark, I tried deleting /usr/bin/login as one poster suggested. It worked!
…But only for a little while. The problem returned. In the meantime, I had freed up some disk space because I’d realized I couldn’t save files anywhere (“But ~/Pictures is writable!”). Clearly something else had become an issue, because disk space was available.
Then I found
[Bad link]. The more permanent solution from that thread appears to be the removal of corrupted Apple System Log databases. Once I did that and restarted the ASL service, all was well and has stayed that way so far.
Filling up my disk must have corrupted the logs as they were being written or rotated, and led to this cascade failure. Like I said, interesting!
One of the posters in the second Apple Discussions thread indicated that the underlying database corruption issue is addressed in Snow Leopard. However, it seems that you could still see this on Leopard — my experience was with a recently-patched Mac OS X 10.5.8 system.
[Bad link] replaces the Apple Maintenance Program (AMP) as the primary way to purchase ongoing software upgrade rights for a school, college, or university’s fleet of Macintosh computers. The Apple Education Licensing Program (AELP? or just ELP?) is a yearly, renewable license.
I think this is a big deal because it’s awfully close to what I’ve asked Apple for year after year — especially at venues like WWDC (at least when they have presented the opportunity for giving constructive feedback).
The ELP licensing for Mac OS X is actually a bundle — called the “Mac Software Collection” — of the operating system combined with the iLife and iWork suites. (It aligns with the same bundle of software in the standalone “Mac Box Set.”) I believe that the bundling of iLife is the biggest win, because it provides upgrade rights to software that is bundled with every new Mac but frequently updated. If you are managing a larger group of Macs over several years, the licensing and deployment issues involved with iLife could be complex — moreso because it’s the kind of software that people want on their computers. It also doesn’t hurt that Keynote is included — anecdotally, it appears to sell a lot of Macs in organizations all by itself.
The ability to keep the operating system and core applications from the Mac Software Collection up-to-date across a range of Macs with a single renewable license could be a tremendous savings in administrative overhead.
Organizations must cover 100 percent of their installed base of owned or leased Macs, at least for the Mac Software Collection. This may be a deal-breaker for a number of universities and perhaps other organizations that tend to be decentralized in their operations.
Apple’s other software can also be obtained through ELP, but can be purchased to cover 100 percent of computers at the departmental level. It is possible that the exact nature of the organizational unit is at the organization’s discretion.
ELP allows the flexibility to cover faculty/staff home use as well as students, should the organization elect to pay for that additional coverage.
Each ELP purchase appears to incur a one-time 10 percent enrollment fee. If an organization doesn’t renew for a year but then buys again later, it may be subject to the enrollment fee again. And, if you have a lot of departments seeking Apple’s Pro Apps or IT-related software, those 10 percent charges could add up to significant overhead. I’m not sure if there’s a clear way to allow two or three departments to get the software they want without requiring an entire educational institution’s Macs be covered.
As part of the introduction of ELP, educational institutions are being encouraged to move to the new licensing program before December 13, 2009, through a waiver of the enrollment fee. It appears possible to crossgrade from AMP to ELP, at least if you talk to your Apple account team.
I am not aware whether Apple has rolled out something similar to organizations outside education.
I had a handy script I wrote on a plane years ago that let me block off my Entourage calendar at specific times each weekday for a given week. The times for these events were created by concatenating some strings and converting the result into an AppleScript date object. I mention that merely for background, and because it was an incredibly geeky way to automate the tedious process of blocking off lunch on my calendar (without resorting to recurring events).
I found that my script didn’t work in Snow Leopard — despite flawless operation across several successive major versions of Mac OS X. The dates themselves remained correct, but the times were all coming up as 12:00 a.m. instead of what was expected.
For example, here’s a simplified reproduction scenario you can try on Snow Leopard:
It turns out that the fix is easy if not exactly obvious: remove the periods from “a.m.” and “p.m.” before converting strings to date objects. (I use the periods because I follow the
So, there is a workaround in the unlikely event you encounter the same problem with your scripts.