Entries in Life

I'm a little frustrated that when I talk about manageability, people get confused. Manageability makes it simple for system administrators to deploy desktops and for users to share data.

This isn't just about setting up servers. Ubuntu, based on Debian, is great as a server OS.

This isn't just about automating tasks. Landscape or puppet can help out here, but that only goes so far. They'll take care of monitoring, package updates, and automating tasks.

A sysadmin of an office or an IT group for a larger organisation still needs some central management interface for all his users. He needs to make it easy for people to share data across a network and have unified, secure credentials for login, email, and web access. If a user's login account isn't the same as their email account — if they can't use the same address book in their desktop mail client as they do in webmail — then you have a management problem.

There is a known solution to this problem. Kerberize your apps and make them speak LDAP. Many applications already have this capability. The manageability problem that Ubuntu has is not really a lack of capability, it is one of integration. System and Network administrators tend to understand the problem better than developers of desktop or server software, but most of them already have their hands full managing their own organisation and don't have time or, often, the capability to start integrating all the software and configuration into something that anyone can deploy easily.

And so, Microsoft continues to win on the desktop. Not because an individual PC running Windows is easier for most people to use, but because its easier to set up Active Directory to work with Outlook and Exchange than it is to roll your own directory service with the tools available out of the box on Ubuntu. Bug #1 will never be solved until directory services and authentication are integrated into every aspect of Ubuntu.

Now, as frustrated as I am that most people don't seem to understand the problem when I talk about it, I am pleased to see that others are aware of the problem, and have actually put some effort into planning out an approach to solving it.

The best example of this would be the EDUbuntu people. Their EDUbuntu User Managment blueprint is a great outline of exactly what needs to take place to solve this managability problem.

But they created this blueprint over four years ago and almost nothing has happened on it.

Launchpad is littered with similar blueprints (below) that show other people's aborted efforts to solve part or all of the problem. Unfortunatly, no one group has really tried to spear-head this and so most of these efforts (at least when I did my survey a few months ago) are dead or dying.

I'd really like to get this problem solved so that setting up an Ubuntu-based directory service would be as easy — easier, even — as setting up Active Directory.

Look over the blueprints below, find a place you can help. Let's get this moving forward!

• Turnkey identity management
• Identity management reference/test config
• Default LDAP DIT for user and group management
  
• implement simply DIT for Ubuntu server
• Make Ubuntu authenticate against Network Authentication services
• Single User Interface to Join and Participate in Microsoft Active Directory Domains
• Architecture of a directory infrastructure
• Enable user login to leverage a directory infrastructure
• Identity management and network authentication in Hardy
• Integrated Active Directory Logon
• 389 Directory Server Inclusion in Karmic
• Directory service included in Ubuntu Server
• Configuration of services to integrate with a directory
• Enable services to leverage a directory infrastructure
• Open Directory Service package
• Integrate OpenDS in Jaunty
• Search for a published printer in an Active Directory
• EdubuntuUserManagement
• Easy active directory integration for EDUbuntu
• An integrated directory server for Ubuntu-server
• LDAP Integration
• Ubuntu Server MS Integration Proxies
• Seamless integration into a Windows domain environment (Active Directory)
• Make a LDAP Server as easy to install as a LAMP Server
• Managing the directory
• System Security Services Daemon for Ubuntu
• Make LDAP the default configuration backend for Ubuntu
• Create new tasksel tasks for common server use cases
• Free Identity Policy Audit infrastructure for Ubuntu as the freeipa.org project
• Authentication/Authorization/Access control/Accounting/Auditing services in the cloud
• Extend mail stack in Ubuntu-server
  

(This is a copy of the message I sent to the UbuntuNGO mailing list.)

As a system administrator for several years (I got my first sysadmin job back in ‘97), I've been frustrated with the lack of manageability of Linux systems. To reduce the cost of managing desktop systems, directory services that provide single-sign-on and centralized management capabilities are needed.

Sure, there are things you can cobble together, there are ways you can integrate Ubuntu into an AD network (see this article on “Seamless Smartcard login” for an example), but these things are more complicated than they need to be.

And, while I don't think the goal should integration with AD, when Microsoft provides tools to easily manage computers throughout an organization, the cost of supporting Microsoft systems is going to be less since the cost of licensing is nothing compared to the cost of paying for the increasingly complex IT support Ubuntu requires without Directory services support built in.

No, this isn't a specifically NGO goal, but it is integral to the goal that UbuntuNGO has of getting NGOs to adopting Ubuntu on the desktop.

I went through Launchpad looking for blueprints pertaining to management and directory services and found a number of initiatives. The problem, though, is the hodgepodge of efforts and lack of focus.

Directory services integration is absolutely vital to getting NGOs and others to adopt Ubuntu on any sort of scale. Canonical and Ubuntu have done a great job of providing an excellent out-of-the box experience for the individual user, but scaling that up to groups of non-technical users needs work.

We can make management of Ubuntu systems on a network just as easy as the use of a Ubuntu itself is, but it will take some work and we can't expect that a great desktop experience will solve all problems.

I'm interested in your thoughts.

Ok, it's been a couple of weeks since I posted the 64bit Linux installer for Google Gears. And some people have asked for the diff or a smaller installer. Fair enough. There they are.

The directions for compiling your own are simple enough. Here is a cut-n-paste list of directions:

svn co http://gears.googlecode.com/svn/trunk gears
cd gears
curl http://mah.everybody.org/gears.diff | patch -p0
chmod +x third_party/gecko_1.9/linux/gecko_sdk/bin/xpidl
cd gears
make

If you look at the diff, you'll see there is nothing particularly 64bit-ish about it. Its mostly just fixing warnings and declarations.

So the real question I have is: Why doesn't Google offer 64bit builds?

(Now, if only I could come up with an Ubuntu package for this…)

Often, when setting up email on a server, you want to receive email from local processes (cron jobs, etc) but don't want email accounts to be abused by spammers.

For example, on Ubuntu systems you might have a cron job that runs as www-data that you want to get mail from, but you don't want spammers sending email to www-data@example.com. I just had a client ask me to fix this problem for them, so I thought I'd share the solution I came up with.

Typically, the /etc/aliases file directs mail from all these extra accounts (like www-data, nobody, etc) to root and you're expected to set up an forwarder for root (e.g. mah@example.com).

Instead of directing mail for all these accounts to root, I created a locked out account. The only purpose of this account is to verify that only locally generated email is sent on to the end recipient. No more Viagra spam for www-data@example.com!

To set up the locked out account:

$ sudo /usr/sbin/useradd localmail
$ sudo /usr/sbin/usermod -L -s /dev/null localmail
$ echo '"|exec /usr/bin/procmail"' | sudo -u localmail tee ~localmail/.forward
$ echo <<EOF | sudo -u localmail tee ~localmail/.procmailrc
# replace example.com with whatever domain locally generated email has
:0:
* !^Return-Path: .*example.com
/dev/null

:0:
!root
EOF

This works with postfix, but I haven't tried other MTAs.

Since I run 64bit Ubuntu, I couldn't use use Google Gears. Which was annoying. The Google Gears site says 64bit OSes are not supported.

But it is open source.

So I grabbed the source code, tweaked a few things here and there and I now have Google Gears up and running on my 64bit OS. It hasn't crashed and burned yet, but I haven't really tested it heavily yet, either (suggestions welcome).

Anyway, here's the XPI to install it. I'll post the source soon. Or maybe just the diffs to the Google Gears list.