code in the ruins

• Desktop
• Network shares
• NTLM
• Exchange server (mail, contacts, calendar)
• Remote desktop
• Printing
• Limitations

At home, I use Linux. But at work, I have to use Windows. They don't support Linux desktops, and that's not all: our network has a lot of Microsoft services running that don't play nice with Linux. Still, I've managed to set up a Linux box at work; and slowly, I've managed to get enough things working that I only rarely need to go back to Windows to get something done. Details of what I've worked out are below.

The main goal here is to see what's possible without any assistance from the IT department whatsoever, since that's how most people would be doing this. Fair warning, though: if you violate your company's IT policy or break something you can't fix, you're going to be in a sad, lonely place.

First, some background on what I'm looking to do. I'm a web developer. I have access to several servers where I work - some Windows, some Linux. I need to be able to administer them, and I need to be able to modify files on them. I need to be able to access our Exchange server - mail, contacts, calendar. I need to be able to access our Intranet, which uses NTLM (a.k.a. Integrated Windows Authentication). And there are certain pieces of proprietary software that I have to use. As I said, I haven't gotten everything to work, but I've put together a pretty good setup that solves most of these problems.

Linux on the desktop

The first step is to install Linux onto a workstation. The first option is to just nuke a workstation's hard drive. Non-destructive partitioning is also possible, and you might be able to put a new drive into the machine and dual-boot. Or bring in your own Linux box to use at work. Many of these things will get you into trouble with your IT department, and they may not even be possible if they have password-protected the machine's BIOS or have some means of preventing unauthorized PCs from connecting to the network.

I took option one - nuking a workstation's hard drive. My IT folks can restore a standard drive image, so this seemed like a minimally invasive way to go. So I kissed it goodbye and installed Ubuntu (although I eventually ended up using Kubuntu instead, because of Kontact. But more on that later).

Once I had a running Linux box, I started hooking up the network stuff.

I had to abandon the idea of logging into the Linux box with my Windows domain credentials. It requires that the machine be added to the domain, which requires a domain admininstrator. I created a local account on the machine to use.

Network shares

Thanks to the excellence of Samba, geeks everywhere can access Windows shares flawlessly. Or, almost. Initially, I used Gnome to connect to the various Windows shares I need, and everything was fine. But I began to notice an annoying problem - when opening a file on a Windows share in GEdit, it would tell me that it couldn't access the file. Only after trying again would it open the file. Apparently this is a bug in gnome-vfs. But it was sufficiently troubling that I went looking for a better way to access files on network shares.

I settled on autofs. Autofs will automatically mount a list of, well, anything, somewhere on the filesystem. It has a nifty 'ghost' feature that makes the shares visible, but does not mount them until they're accessed. I listed out my network shares, and now they're all available under /mnt/auto whenever I want them.

The details:

sudo apt-get install autofs smbfs

In /etc/auto.master:

/mnt/auto /etc/auto.misc --timeout=3600 --ghost

In /etc/auto.misc:

share -fstype=cifs,rw,credentials=/path/to/smb.auth,uid=user,gid=grp,file_mode=0644,dir_mode=0755 ://server/share
hidden -fstype=cifs,rw,credentials=/path/to/smb.auth,uid=user,gid=grp,file_mode=0644,dir_mode=0755 ://server/hidden\\$

In /path/to/smb.auth (make sure this file is chmod 600):

username=domainuser
password=domainpassword

Autofs will automatically create the directories /mnt/auto/share and /mnt/auto/hidden. When you (or your applications) access these directories, they'll be mounted and the file ownership and permissions will be set as specified.

The only drawback: it doesn't appear to be possible to mount directories within a share directly. You have to mount the root of the share.

NTLM

Our Intranet uses NTLM for authentication to provide personalized features. Good thing Firefox supports it. One authentication box and you're set until the browser closes.

Exchange Server

We use Exchange Server 2000 and Outlook 2000 where I work. The obvious choice of client for working with Exchange servers in Linux is Evolution, which has had Exchange interoperability for some time now. Unfortunately, I've never gotten the Exchange connector to work. It's possible that our server has WebDAV disabled, or that the authentication box that pops up when I visit my Outlook webmail is getting in the way. At any rate, I had to drop Evolution and look for something else.

I'm able to access the Exchange server via IMAP and retrieve my mail that way. Not perfect, but it works. The calendar (especially meeting request handling) and the user directory are more problematic.

First, the calendar. I first tried Thunderbird with the Lightning extension. It worked reasonably well, but I noticed that it appeared to be getting the time zone of my meetings wrong. When I accepted meeting invitations, the appointments would be scheduled several hours away from when they were actually supposed to occur.

Next, I tried Kontact, which turned out to work very well. For mail, I use IMAP to connect to the server. Kontact can also work directly with Exchange calendars - when I added a new calendar, Exchange was one of the options (though it says it is experimental). Happily, I saw that it added all of my current appointments, complete with notes, other participants, reminders, etc. Creating and editing events worked fine. Meeting requests received by mail have response links, and the meetings are scheduled on the calendar as you'd expect. The only problems I've encountered so far have been performance-related; there are long pauses while communicating with the server, and Kontact has very occasionally become unresponsive.

For the user directory, I was able to get Kontact to connect to our backup domain controller via LDAP. It works well, except there is a hard limit of 1000 records, and Kontact doesn't seem to be able to retrieve more than that. As a result, there are some employees who do not appear in Kontact's local version of the directory. We don't have much more than 1000 employees, so it's not a huge problem.

I should say that I'm a little privileged there. As a normal user, I wouldn't be able to access Active Directory and retrieve records via LDAP in our shop. I happen to have a user account with more abilities that is used by the web-based employee directory that I wrote. However, I believe that most domain controllers will allow a domain user to list records. Could be wrong though.

With mail, appointments, and contacts all managed by Kontact, the integration is quite good - as I've said, meeting requests are handled well, and contacts are conveniently suggested as you compose a new message. It's a very usable setup.

Remote desktop

Obviously, administering a Linux server from Linux via SSH is no problem. Windows servers are easy too, thanks to krdc and rdesktop. Both of these clients make it easy to log in to Windows boxes and do what you need to do.

Printing

We use HP network printers here, which can be accessed directly via TCP/IP on port 9100. They work flawlessly.

Limitations

The only reason I can't drop Windows entirely at this point is because of proprietary software that I still need to use.

As a web developer, I have to use Internet Explorer. It makes me cringe, but I have no choice - when 70% of our visitors still use it, it means I have to test everything in IE before it goes out. I've tried IEs4Linux (IE on Wine), but it was almost unusable - I couldn't type addresses in at all, though I could navigate with the mouse. Not good enough for rigorous testing.

Also, we use Dreamweaver to maintain site templates. Dreamweaver doesn't run on Wine because of its license enforcement component, so I still have to go back to Windows to modify templates. Soon we will be migrating to an open source content management system with a web interface, so I'll be able to drop Dreamweaver for good.

And finally, I need to use either Enterprise Manager or SQL Server Express to work with SQL Server databases. I haven't found anything that runs on Linux and still does everything I need, so it's back to Windows for those tasks. We'll be moving to Oracle gradually, which isn't my first choice but has a better Linux presence since its tools are written in Java.

And that's how I carved out a little Linux niche in my Windows shop.

Update: smbfs is required for mounting Windows shares using autofs.