Archive for the ‘Interoperability’ Category

Access Control and Controlling Complexity

Friday, June 13th, 2008

A few days ago, I prepared a Powerpoint presentation and a demo script for a Webinar. The topic under consideration was Implementing Effective Access Control.

The first thing I did was to look for a good definition of “Access Control.” As usual, Wikipedia did the trick, “Access control is the ability to permit or deny the use of a particular resource by a particular entity.” Pretty straightforward.

After defining the term, I demonstrated several different ways that our product (Likewise) provides to implement access controls. I came up with 4 different mechanisms and I know I skipped at least a couple of variations! Likewise lets you implement access controls by placing restrictions on a user account, by manipulating Cells (groups of computers), through access control lists on resources and by using group policy. There are other ways, too, based on setting ACLs on computers and by directly editing configuration files.

On one hand, we can brag about the power of our software. We’ve got enough mechanisms that we can satisfy anyone. Some customers don’t want to use group policy for non-Windows computers; fine, they can use Cell-based mechanisms. Others want a simple Cell architecture and no GP; fine, they use account restrictions or they can set configuration files manually.

On the other hand, when you step back and note the plethora of access control mechanisms, it’s hard not to think that all this should be easier to accomplish.

The real art in software development is providing power while maintaining usability. “Powerful, yet easy to use” has become such an oft-repeated mantra that it has lost all marketing value. Too many programs have promised such but failed to achieve one of the goals (or both!).

Although Apple has a well-earned reputation for delivering capable-yet-usable products, let me mention a couple of others: cars and cameras.

When I look at the dashboard of my car (one with, admittedly, more doodads than most) I note over 100 different buttons that I can press. Controls for windows, wipers, lights, radio, climate, GPS, traction control, locks, cruise control, turn indicators, telephone, parking radar, heat seaters, rear shade, etc. My car has a button that controls whether my door mirrors stick out, pull in or move in and out automatically. If I include “soft” buttons on the touchscreen GPS device, there’s probably more like 200-300 buttons.

In spite of the complexity, it took me less than one hour to learn 95% of the car’s functionality (I still don’t know how to set Address book entries without a Bluetooth phone).

I had a similar experience when I checked out the Canon 40D and Rebel XSi, recently. I was able to flip through the various exposure modes, figure out how to squeeze off multiple shots, and how to perform several other basic camera features. I dutifully noted the “CF” button on the back, but didn’t press it.

Why is that cameras and cars are easier to manipulate than spreadsheets and word processors? You can argue that the latter offer more features, but I think that 200-300 car features is probably comparable to the number of features I use in office products.

I think the key difference is whether or not people have a good existing mental model of how something is supposed to operate. I know, for example, that pretty much any non-American car is going to turn headlights on and off with some stick on the left side of the steering wheel. I’m probably going to pull it back and forth to activate the high beams. I know that there’s going to be an AM/FM band selector for the radio and that there’s going to be a button (probably, with a red triangle on it) that controls the emergency flashers. Every once in a while, I’ll rent an American car and I’ll have to hunt for a headlight know on the dashboard, to the left of the wheel. Every once in a while, too, I talk to someone old enough to remember the metal “pushbutton” on the floor that controlled the high beams on American cars until about 1970.

I knew how to operate the Canon cameras because I already own a Canon camera. Canon is smart enough to minimize UI differences between cameras. They’re also smart enough to exploit common standards or practices. The exposure mode knob is pretty standard on most cameras (with settings for “P”, “M”, “Av” and “Tv” and a bunch of icons). The “CF” button though is not. “CF” stands for “Custom Function”. This is where Canon “hides” about 25 functions that only advanced (or anally retentive) users need to access.

Cameras are a great example of the need to balance power and complexity. The Canon 40D is a formidable instrument. It provides tremendous flexibility over shutter speed, aperture control, flash synchronization, mirror lockup, picture resolution, etc. Either that or you can just put it on “P” and press the shutter.

“Software”, broadly, has no such well-defined model for how it should operate. There are some standard paradigms (for example: establish a selection and then perform an operation on it), but beyond the basics, there is too much variation between applications. For a while, we could count on “File”, “Edit”, “View” and “Help” menus but now Microsoft has gone and messed that up, too. After months of using the new version of Office, I’m still playing “find where they’ve gone and hidden my favorite operation.”

My only excuse when preparing my talk was that, at least, we only make matters a little more complicated. For the most part, the access control mechanisms that we provide are ones with which our customers should already be familiar (on Windows computers). We extend these mechanisms to work with UNIX, Linux and Mac OS X computers adding “only one” new one: the Cell concept. Here, too, we associate Cells with AD organizational units rather than inventing a parallel administration entity.

By the way, if you want to watch the recorded Webinar, you can see it here.

Sneakernet, revisited

Thursday, June 12th, 2008

In case you read my post, Email, the New “Sneakernet”, you might have been left wanting to know more about how to use Samba. There are plenty of sites and books dedicated to the topic, but here’s a quicky post on how to most easily use Samba.

To make your Linux, UNIX or Mac files available to Windows clients, do this:

  1. Make sure you have a reasonably recent version of Samba on your Linux, UNIX or Mac machine. 3.x is generally good; 2.x is not.
  2. Edit or create /etc/samba/smb.conf to look like this:
  3. [global]
    workgroup = WGNAME
    netbios name = MYMACHINE

    [SHARENAME]
    path = /PATHTOSHARE
    public = yes
    guest ok = yes

    Where WGNAME is whatever you want to use as your Windows “workgroup name”, MYMACHINE is your computer’s “netbios” (short, network) name — one that ideally matches your DNS name, SHARENAME is the public name of your “share” (for example, “BobsHomeDir”) and PATHTOSHARE is the file system path that you want to make available as that share (for example, “/home/bob”).

  4. After creating or editing the /etc/samba/smb.conf file, you must start/restart the smbd daemon. Do this with:
  5. /etc/init.d/smbd restart

    (Note: Different versions of UNIX, Linux and Mac OS X do this differently).

  6. To access the files shared in step 2, on your windows machine, type:
  7. net use * \\MYMACHINE\SHARENAME

    Replacing MYMACHINE and SHARENAME as needed.

Doing the reverse, accessing Windows files from Linux/UNIX/Mac is easier. You don’t need to configure anything or run any daemons:

  1. As above, make sure you have a reasonably recent version of Samba.
  2. Run the smbclient program from the command line. It’s arguments look like this:
  3. smbclient -U DOMAIN\\username //WINCOMP/SHARENAME

    Replace DOMAIN and username with the Active Directory short domain name and username of a user that has access to the computer whose files you’re trying to reach . Replace WINCOMP with the name of that computer. You can use its short, Netbios, name or its fully qualified DNS name (e.g. wfsshare or wfsshare.corp.mycompany.com). Replace SHARENAME with the name of the “share” on the Windows computer. Note the use of a double “backslash” when specifying the username and domain. When using the command line shell on Linux/UNIX/Mac, you typically need to type in two backslashes when you want one. The backslash is a special “escape” character and you need two of them to end up with just one. No kidding.

  4. The smbclient program will prompt you for the password of the username that you specified. Type it in.
  5. The program will display a prompt and wait for you to type a command. At this point, pretend you are in ftp. Use the ls command to list available files. Use cd to change remote directories. Use get to retrieve a file. mget is also useful because it supports wildcards. put and mput can be used to copy files from Linux/UNIX/Mac to Windows. Use bye to quit.

There is an alternative to using smbclient. You can use the “smb filesystem”. This approach lets you “mount” a Windows disk into the Linux/UNIX/Mac filesystem so that you can access its files like you would any local file. Here’s how you do that:

  1. Create a “mount point” in your file system. This is where you want your Windows files to appear. On Linux, the media directory is often used for flash drives and other transient “disks”. You might want to use it for this purpose, too:
  2. mkdir /media/fromwindows

    (Replace fromwindows with whatever you want).

  3. Use the mount or mount.cifs command to mount your Windows share to the mount point. I’d try the second form first:
  4. mount.cifs //WINCOMP/SHARENAME /media/fromwindows -o user=USERNAME,password=PASSWORD

    WINCOMP and SHARENAME are as used earlier. USERNAME and PASSWORD are the username and password of a user that has permissions to access the given Windows file share.

  5. If your system complains that it doesn’t know mount.cifs try this instead:
  6. mount -t cifs //WINCOMP/SHARENAME /media/fromwindows -o user=USERNAME,password=PASSWORD

If this doesn’t work, try substituting smbfs for cifs. If that doesn’t work, just email the damned files!

E-Mail – the New "Sneakernet"

Wednesday, June 11th, 2008

As you can read in my “About” page, I’ve been involved with computing for a long time. Although the industry has seen tremendous progress during that time, every once in a while, something comes along that makes me think it is still 1980.

In the early days of personal computing (about 25 ago), when IBM PCs and Apple IIs started appearing on corporate desktops but before “LANs” became commonplace, the term “sneakernet” was used to refer to communicating information by physically walking it over. You’d write out your WordPerfect file to a 5-1/4″ “floppy” (which actually was “floppy”) then stroll over to your intended recipient. Pretty simple.

Later, even this simple scenario was complicated by the advent of 720Kb, 1.4Mb and 2.8Mb 3.5″ floppies (no longer “floppy”) and differences between IBM and Apple formats. The Mac used a weird variable speed technique that the PC could not read.

Even when networks started showing up in office settings, sneakernet remained popular. Early networks required that file exchange be accomplished by writing the data to a “file server” and then having the recipient read it from the agreed location. Connecting to a file server required magic NetWare or LANMAN command-line incantations.

“Windows for Workgroups” and, later, Windows 95 made PC networking much easier. Meanwhile Apple had a very easy to use network based in AppleTalk, yet another example of Apple’s willingness/bias towards doing things their own way.

It did not take long for the industry to consolidate on standards. AppleTalk, like “token ring” and other competing protocols gave way to Ethernet. Netbios and IPX gave way to TCP/IP. For a while, file sharing was not too hard. Users could easily “share” folders or store things in their automatically shared Public folders and use these file file exchange. It was okay to wear dress shoes to work and leave the sneakers at home.

The arrival and broad adoption of the Internet introduced new challenges that reversed this trend. The Internet made possible the effective use of WANs (wide-area networks) and the connection of companies and company branches that were not normally connected in a private network. Sharing files through sneakernet, now, became impossible because sneakers would not get you from New York to Japan or Australia (at least, not without getting them wet). On the other hand, sharing files through simple operating system mechanisms also became (almost) impossible, mostly, due to security concerns.

Within their LANs, companies often have liberal policies regarding what type of network traffic is allowed to occur. File sharing protocols work within these corporations because the necessary TCP/IP ports are available and communication to/from these ports is permitted. Corporations typically separate their internal LANs from the external Internet by using firewalls. Firewalls are typically appliances (or dedicated computers running networking software) that control what type of information is allow to flow between the internal LAN and the external Ethernet. The TCP/IP ports required for file sharing are usually blocked by firewalls. No IT director wants random strangers on the Internet to be able to access computers in their corporate LANs and to read shared files.

The net result (no pun intended) is that sharing files across the Internet has gotten complicated again. Some companies will set up special FTP servers outside their firewalls. Others might use Internet “collaboration” web sites to facilitate file sharing. More often than not, I see people simply e-mailing files to each other. Crude but simple. The electronic equivalent of sneakernet.

Another thing that makes file sharing complicated even within a LAN is the use of different operating systems. Once again, Apple is involved here but, this time, it’s got plenty of company. Mac OS X is based on the FreeBSD operating system – a UNIX variant. Mac OS X has the same challenges that Linux and all flavors of UNIX (AIX, Solaris, HPUX) have. In order for these systems to “talk” to Microsoft systems, they have to do one of two things: they have to “look like” a Windows client to get data from a Windows server or they have to look like a Windows server so that Windows clients can get data from them. (FTP is, again, an option in LANs but a relatively painful one).

The Samba open source software can help with both of these. Samba, for example, provides the smbclient utility that allows UNIX systems to get data from Windows servers using an FTP-like interface (but without requiring the Windows servers to run any FTP software). Samba also provides the smbd service (daemon) that allows a UNIX computer to look like a Windows server so that it can be accessed by Windows clients.

Setting up a Samba server can be a difficult task, especially if you want it to be integrated with Microsoft Active Directory and to supports its user authentication features. There’s a great 700+ page book that describes how to do it. Nevertheless, there’s no better way to do this. If you’re willing to forego AD security, setting up Samba is a lot easier.

Beyond Samba, there’s also the “smb file system” smbfs and some commercial products to allow Linux and Mac OS X to act like a Windows client. Additionally, Apple and Linux vendors have begun to build such functionality into their standard graphical “shells”.

Perhaps, in another 25 years, we’ll have it all worked out.