UNIX as Literature or: Why Visual Artists Suck at Shell Scripting

I just read a terrific article entitled "The Elements Of Style: UNIX As Literature" by "feral information theorist" Thomas Scoville. In it, Scoville proposes that UNIX has a certain appeal to literary types because of its reliance on text rather than image, and that the GUI has really been successful because we live in an increasingly visually oriented culture.

This article got me thinking about a few things. The first is that I wonder if the reverse of his premise might also apply to my situation. Since the advent of the UNIX-based Mac OS, I've been forced to use the UNIX command-line. Perhaps not coincidentally, I've been writing more. I write this blog. I write more instructions for my users. And I've become a much better and faster typist (I can almost touch type now). I wonder if there is a relationship between my increasing reliance on and fondness of UNIX and the fact that I now write a great deal about technology. I wonder if it's possible that the former has influenced the latter. I wonder if learning UNIX has fundamentally changed my brain in some small but important ways. Is UNIX responsible for The Adventures of Systems Boy?

The second thing I got thinking about is the idea that, if Scoville's theory holds, visual artists would tend to be pretty lousy and generally uninterested in the command-line. This effects me in a number of ways. For one, I am a visual artist. I used to paint and now I make videos. But I've also always had a strong technical side to my personality and interests, though it took me quite some time to actually warm to UNIX. (I remember my first foreach loop. That was the defining moment for me, really, as there was no way to do anything like that in the GUI.) For two, many of my freelance clients are visual artists. Most of them are fairly clueless as to the intricacies of systems or network setups, which I guess is why they need me. And lastly, I work in an art school and am surrounded by would-be visual artists. I've often lamented the inability of many of my students to grasp fundamental technical concepts, and as I've grown more dependent upon UNIX, I've found it frustrating when trying to teach people basic command-line skills. Artists, by and large, just plain tend to suck at shell scripting. I've usually written this off as people just being generally uninterested in such arcane and sometimes difficult tools as UNIX (as I was myself, initially). But Scoville's theory suggests that visual artists in particular may be especially immune to the charms of the command-line. They just might not be wired for it. I'll have to factor this into my thinking the next time I want to throttle someone for making me describe for the umpteenth time the syntax of ls. It's just not their fault.

The last thing I got to thinking about was Mac OS X. The real beauty of Mac OS X, in my mind, has always been that it unites two distinctly different — both the visual and the linguistic — ways of thinking. Mac OS X employs a visually beautiful GUI over a UNIX foundation. It's the best of both worlds in one system, equally appealing to both the aesthetes and the geeks. This is truly remarkable, and goes one more step in explaining why it's my operating system of choice. For someone like me — a visual artist with strong technical leanings who works with a multitude of other artists — Mac OS X represents the ideal operating system. And whether people realize it or not, I think this has at least something to do with its broader appeal.

I also think I may just have made the perfect career choice when I took a job as a SysAdmin in an art school.

Sandbox and ACLs or: Why I Want to French Kiss Mikey-San

So I recently had a freelance project that involved my first experience with, among other things, Access Control Lists (which we will, from here on out, refer to as ACLs, 'cause I'm not typing that shit a hundred more times today). Briefly, ACLs allow more fine-grained control over file and folder permissions by defining multiple rules for multiple groups and/or users for any given object. ACLs are exceptionally cool. But they're also incredibly complex.

For my freelance project I was assigned the odious task of setting up a share on a Mac server, and this share would be readable by all, but its contents would not, unless explicitly allowed, be readable by members of a particular group. Let me try to clarify this, 'cause it took me a few days to get my head around it: Essentially we had three groups, which we'll refer to as Artists, Producers and Freelancers. Artists and Producers needed full access to everything on the share (which we'll call Share), and Freelancers needed read access. Freelancers, however, needed to be denied access to all subfolders of Share, including newly created folders. Later, if a member of Freelancers needed access, someone from one of the other groups would grant them access to the folder in question on Share.

Complicated? You betcha! Impossible? Surprisingly, no. Though, if you try to do this with Apple's Workgroup Manager (which we'll just call WGM) you'll never be able to. The key lies with two concepts: rule ordering and inheritance. See, ACLs are ordered lists, and the first rule in the list wins. Additionally, "deny" rules always trump "allow" rules, with one crucial exception: explicit allow rules trump inherited deny rules. This was the magic that made our little scenario work. I did not see any mention of this in the Mac OS X Server documentation (though it's entirely possible I missed it). And I certainly did not see any way to reorder rules in the WGM application, inherited or not. Rather than from Apple, I got all my info on rule ordering and precedence from my new best-est pal in the whole wide universe, mikey-san of sightless and born.

Enter: Sandbox.

Sandbox is a cool, free, little utility whose sole purpose in life is to enable ACL management on non-server versions of Mac OS X. It even has some pretty informative documentation. Amazingly, however, Sandbox gives you way more and better control over your ACLs than Mac OS X Server's WGM app, particularly with regards to rule ordering. With Sandbox, you can explicitly set a rule as "inherited," and you can explicitly set the order of rules. You can't do either of these things in WGM, which is quite infuriating considering how important ordering is in ACLs.

Like the Command-Line: This is How it Looks in Sandbox

(click for larger view)

So, using Sandbox, I created a rule for Share that gave full access to Share for Artists and Producers, and that forced inheritance of these permissions to any subfolders of Share (so Share and its subfolders are always accessible to Artists and Producers). Then I created an "allow" rule which granted Freelancers read permissions on Share, but which did not propagate those permissions to subsequent subfolders (so Share is readable by Freelancers, but none of its subfolders are — if this rule is not propagated, which it's not, there is no rule on subfolders, and POSIX permissions take over, granting "world," and thus Freelancers, read access to subfolders of Share, so we need a deny rule next). Finally, I created a "deny" rule for Freelancers that disallowed them access to Share and any of its subfolders. This rule is inherited and occurs before the "allow" rule (so denial of access is propagated to subfolders of Share, essentially acting like a umask, but does not apply to the actual Share folder). The key here is that, in order for this deny rule to not override the allow rule, it must be inherited (remember, explicit "allow" rules trump inherited "deny" rules), and, once it has been set to "inherited," it must occur before the deny rule. Neither of these astonishing feats can be accomplished with WGM. Both can with Sandbox.

That "Deny" is Out of Order: Here's How it Looks in WGM

(click for larger view)

And that is why I want to French kiss mikey-san. Whoever he is.

UPDATE:

All the above was done on a test machine. (Thanks be to the joys of education work that actually allows me to build test servers!) Putting this plan into practice was one more, extra, added layer of tricky. You see, the share on which we wanted to set this up was already in use by the client. Yup, it was already populated with all manner of data, none of which had any ACLs applied.

The final nail in this coffin was to propagate the ACLs in WGM. But this had to be done such that all subfolders and files had the inherited properties we wanted, but the top-level "Share" had it's original properties. Remember: our top-level Share should be readable by Freelancers, but it's descendants should not, so the top-level permissions are different from all the subfolders and files. Had we simply propagated our "Share" permissions through the entire tree, Freelancers would have read-access to everything, and this was verboten. The trick was to remove the "allow:read" rule from "Share" and then propagate permissions. After the propagation was finished (about 10-15 minutes later — it was a large amount of data) we reapplied the "allow:read" rule to "Share" and all seems cool.

This may seem like an obvious solution, but I wanted to make a note of it as ACLs — at least complex ones like these — seem to befuddle even the most logical minds, and certainly mine. So for thoroughness' sake, there you have it.

Remote Network (and More!) Management via the Command-Line

There's a lot you can do in the Terminal in Mac OS X. It's often the most expedient method of achieving a given task. But I always get stuck when it comes time to make certain network settings via the command-line. For instance, in the lab all our machines are on Built-In Ethernet, and all are configured manually with IP addresses, subnet masks, routers, DNS servers and search domains. But sometimes we need to make a change. While I suppose it's easy enough to go over to the computer, log in, open the System Preferences, click on the Network pane, and configure it by hand in the GUI, this becomes a problem when you have to interrupt a staff member busily working on whatever tasks staff members tend to busily work on. Also, it doesn't scale: If I have to make a change on all 25 Macs in the lab, the above process becomes tedious and error-prone, and exponentially so as we add systems to the network. When performing such operations on multiple computers, I generally turn to Apple's wonderful Remote Desktop. But ARD (I'm still using version 2.2) lacks the ability to change network settings from the GUI. Fortunately, there is a way.

ARD comes with command-line tools. They're buried deep in the ARD application package, for some reason, making them a serious pain to get at, but they're there and they're handy as hell in situations like the above. You can use these tools to set up virtually anything normally accessible via the System Preferences GUI. Including network settings. There are two main commands for doing this:
systemsetup for making general system settings, and networksetup for making network settings.

Both commands are located in the folder:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support

You'll need to type the full path to use the commands, or cd into the directory and call them thusly:

./networksetup

Or you can do what I do and add an alias to them in your .bash_profile:

alias networksetup='sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/networksetup'

There are no man pages for these commands, but to get an idea of what they do and how they work, just run them without any arguments and they'll print a list of functions. Or you can run the commands with the -printcommands flag to get an abbreviated list of functions. There is also a PDF reference online. The syntax for these tools is not always straightforward, but by and large looks something like this:

networksetup -option <"network service"> <parameter 1> <parameter 2> <etc...>

For "network service" you'll want to enter the name of the interface as it's called in the preference pane, surrounded by quotes. You also need to run these commands as root. Here's an example that makes network settings (IP address, subnet mask and router, respectively) for Built-In Ethernet:

sudo networksetup -setmanual "Built-In Ethernet" 192.168.1.100 255.255.255.0 192.168.1.1

Here's an example for setting multiple search domains:

sudo networksetup -setsearchdomains "Built-In Ethernet" systemsboy.blog systemsboy.blog.net

Why these tools aren't included in the GUI version of ARD is almost as confounding as the fact that they're buried deep within the guts of the app. The wordy syntax doesn't help either (I'd much prefer typing "en0" to "Built-In Ethernet" any day). But despite being difficult to access, I've found these commands to be unbelievably useful from time to time. And though I certainly do hope to edify TASB readers as to the existence and use of these tools, I must confess, my main reason for this post is as a reminder to myself: I'm always forgetting where the damn things are and what the hell they're called.

So there you have it. Remote network (and more!) management via the command-line.

Please resume admin-ing.

UPDATE:
So a scenario occurred to me which might be a bit tricky with regards to the above information: Say you want to change the router setting for your 25 lab macs. Nothing else, just the router. The obvious way to do this would be to send a networksetup command to all of your Macs via ARD. The problem is that the networksetup command has no way of specifying only the router address, without setting the IP address and subnet mask as well. The only way to set the router address is with the -setmanual flag, and this flag requires that you supply an IP address, subnet mask and router address, respectively:

sudo networksetup -setmanual "Built-In Ethernet" 192.168.1.100 255.255.255.0 192.168.1.1

If you send this command to every Mac in your lab, they'll all end up with the same IP address. This will wreak havoc in numerous ways, the worst of which will be the fact that you now have lost all network contact with said lab Macs and will have to go and reset all the IP addresses by hand on each machine. The solution is to specify the current IP address on each machine, which you could do by sending an IP-specific version of the command to each machine individually. But that sort of defeats the purpose of using ARD in the first place. A better way is to substitute a variable in place of the IP address option in the above command. The variable will get the IP address of the machine it's run on. This is what I use:

ifconfig -m en0 | grep "inet " | awk {'print$2'}

This command sequence will get the IP address for the en0 interface, which is what Built-In Ethernet uses. If your machines are on wireless, you can use en1 in place of en0:

ifconfig -m en1 | grep "inet " | awk {'print$2'}

So, instead of entering the IP address in the networksetup command, we'll enter this command sequenc e in backticks. The command we'd send to our lab Macs would look something like this:

sudo networksetup -setmanual "Built-In Ethernet" `ifconfig -m en0 | grep "inet " | awk {'print$2'}` 255.255.255.0 192.168.1.1

This will set the subnet mask and router address — both of which would generally be consistent across machines on any given network — but will leave the unique IP address of each machine intact. You can try this on your own system first to make sure it works. Open the Network System Preference pane, and then run the command in Terminal. You'll see the changes instantly in the preferences pane, which will even complain that an external source has changed your settings. If all goes well, though, your IP address will remain the same while the other settings are changed. You should now be able to safely change the router address of all your machines using this command in ARD (remember to specify the full command path though). Save that sucker as a "Saved Task" and you can do this any time you need to with ease.

Huzzah!

Publish iCal Calendars on the Internet for Free

Addendum: Aug 21, 2010

I wanted to let folks know that the information in this post is pretty old, and these days there are better options for sharing calendars. Most notably, Google Calendar sharing. The method used in the post you're about to read is a one-way share in which the publishing computer is the only one that can make changes, and all subscribing calendars have read-only access. This is limited, I know, but at the time it was readily available and plenty of functionality for most people who just wanted a free option for calendar sharing from their main machine. Nowadays, though, Google Calendar sharing gives the same level of ease-of-use and true, server-based, two-way calendar syncing, allowing you to edit you calendars from any computer (including iPhones). It truly is superior, and I highly recommend it.

So, if you're still interested in the one-way Box.net method, I leave it up for posterity. Otherwise, Google Calendar sharing is probably the way to go.

Happy calendaring!

Original Post

Ever want to share your iCal calendars on the 'net? Well, I have. Unfortunately, iCal publishing requires a server that runs the WebDAV protocol. Apple's .Mac offers such a service, and .Mac, indeed, uses WebDAV. But .Mac costs money, and I've never seen a compelling enough reason to pay for it. Setting up iCal on a Macintosh server is also fairly easy, but it's an awful lot of trouble to go to and a waste of resources if all you're interested in is sharing your iCal calendars. But today I've discovered an easier — and free — way to do just that.

Box.net offers 1 GB of online file storage for free. The data is accessible via the web, so you can get to it from any connected computer. They have a web interface for accessing you files. On Windows they also have client software that lets you access your data as though it were on a shared volume, right from the Desktop. But on the Mac you can connect to it right from the Finder using the ever-trusty "Connect to Server..." command (or command-k) in the "Go" menu. How is this possible you ask? Because the Mac Finder has WebDAV accessibility built right in. And because box.net shares it's data via the WebDAV protocol.

If you haven't put it together yet, this means you can use your free box.net account to host your iCal calendars. The process would go something like this:

1. Sign up for a free box.net account. It's easy as pie, and faster than a bat out of hell. Give 'em your email, a password, and you are d-o-n-e, done. (NOTE: Obviously, to share the calendar with others, they'll need the URL and the box.net username and password, so you might want to make sure you set this account up with information you don't mind giving out. Use a second, private account for stuff you want to keep secure.)
2. To access your box.net account via the Finder, click "Connect to Server..." and type "https://www.box.net/dav" into the URL field of the connection window. (NOTE: Some folks are unable to connect using the "https" protocol. If this fails for you, try it with "http" instead. Either one works for me.) You will be prompted for username (the email you used to register the account) and your box.net password. Enter these and your online data will appear on the Desktop in a volume called "dav" which will be pre-populated with a few default folders.
3. But to publish your iCal calendar, just open iCal, select the calendar you want to share and choose "Publish" from the "Calendar" pulldown menu.
   

   (click for larger view)

4. In the dialog box that follows, name your calendar (or keep the existing name if it suits you), for "Publish on:" select "Private Server," enter "https://www.box.net/dav/Documents" for the "Base URL:" and enter your box.net username and password in the "Login:" and "Password:" fields respectively. (NOTE: Here, too, secure http sometimes fails, so if you have trouble try using "http" instead of "https".)
   

   (click for larger view)

5. You might also want to check or uncheck some of the checkboxes at the bottom, depending on your needs.
6. Finally, hit "Publish" to publish the calendar. You'll see your calendar now sports the "I'm Published" icon just to its right.
7. To subscribe to this calendar (say, from another computer), choose "Subscribe" in the"Calendar" pull-down menu.
8. In the URL field enter:

   "http://www.box.net/dav/Documents/YourCalendar.ics"

   (where "YourCalendar" is the name of the calendar you just published).

   

   (click for larger view)

   Be careful NOT to enter "https" here. Just use the "http" protocol to subscribe. Enter your box.net username and password at the prompt and you'll suddenly find yourself subscribed to your own calendar.

   

   (click for larger view)

9. A final note: Updates to the calendar take some time. Hitting refresh too often (like every minute or so) on a subscribed calendar will generate an error. Just wait and let iCal do it's thing and it will keep everthing up to date. No pun intended.

I'm not sure if many people will find this useful. But to me it seems like a good way to share you iCal calendars, either between remote locations (like work and home) or between groups of people, like friends, family or members of an organization. And hey, it's completely free. How cool is that?

UPDATE 1:

A lot of people have written in with great suggestions, alternatives to and variations on this process, including a page for similarly configuring Sunbird. Please read the comments for more useful information.

UPDATE 2:

I have added a note to the publishing instructions in this article regarding the use of "https". In a nutshell, both publishing and subscribing sometimes fail because of problems with secure http. This is something I receive a lot of comments about and I just wanted to clear things up. If you are having trouble either publishing or subscribing, try doing so using "http" instead of "https". While somewhat less secure, it tends to be far more reliable.

Three Platforms, One Server Part 8: A Minor Snafu

So far we've hit only one very minor snag in our migration to a single, unified authentication server for Mac, Windows and Linux. Since Mac and Linux behave so similarly with regards to authentication — in fact, I'd say they're practically identical — and since Windows is so utterly, infuriatingly different, you can expect most of our problems to happen on the Windows side. At this point it should go without saying. This latest snag is no exception.

Today we discovered that applications to be used by network users on Windows machines must be installed by a network user, and this network user must be a domain admin. Put another way, if a Windows application is installed by a local administrator, it will not be fully accessible by users who authenticate via the domain hosted by the Authentication Server. Typical.

The solution is fairly easy, albeit kind of a pain. On each client workstation, you must give the network admin user (i.e., a user whose account exists only on the authentication server) full access to the "C" drive. You heard me: On each computer. Giving full access to a user on Windows requires logging in as a local admin and granting the network user full access rights. Windows then changes the access permissions on every file on the machine, which takes a long-ass time. You heard me: long-ass.

If we had to do this on every machine by hand, I'd be grumpy about it (but I'd do it anyway). Fortunately, we'll be building our Windows boxes from clones, which means we only have to do this once on a master build. the change should propagate via the clones after that. So I'm a pretty happy camper. And we're back on track.

Still, Windows, what the fuck?

And just to be clear on this, I honestly don't know enough about Windows or Active Directory to understand why this is happening. All I know is what we've observed, which is that Windows apps fail to run properly for network users when installed by local users. We tried matching the users and groups we'd had on the old Windows Server, but that did no good. Setting full access locally for a networked user was the only thing we could find that worked. It's very possible, however, that there's a better solution than the one we're using. If anyone can enlighten me, I'm all ears.

Oh, and yes, our network user has full access privileges for the directory domain. Confused? Me too.

More to come...

UPDATE: I found a better solution. A network user can be added to the "Administrators" group via the Users and Groups control panel. Doing so is not particularly intuitive, but it works and saves us the trouble of having to modify permissions on the entire "C" drive.

Windows "Advanced" Users and Groups: By "Advanced" I Think They Mean "Annoying"
(click image for larger view)

It essentially requires logging in as a local Administrator, navigating to the "Advanced" window in Users and Groups, and then adding the user to the "Administrator" group.

Group Properties: Do We Really Need This Window?
(click image for larger view)

Windows doesn't see a network user unless she's logged in, so you have to know how to enter a network user. It should look something like this: DOMAIN\user, where "DOMAIN" is your Active Directory Domain, and "user" is the user name.

Add the User Here: Who'd a Thunk It?
(click image for larger view)

You can find more complete instructions here, which is where I got these images.

Fun stuff.