There are many guides out there to help you configure your Linux system as an LDAP and Kerberos client to an Active Directory server. Most of these guides solve the problem of authentication by embedding a username and password into a configuration file somewhere on your system. While this works, it presents some problems:

• If you use a common account for authentication from all of your Linux systems, a compromise on one system means updating the configuration of all of your systems.
• If you don’t want to use a common account, you need to provision a new account for each computer…
• …which is silly, because if you join the system to Active Directory there is already a computer object associated with the system that can be used for authentication.

This document describes how to configure a Linux system such that queries generated by nss_ldap will use either the current user’s Kerberos credentials, or, for the root user, credentials stored in a Kerberos credentials cache.

I recently set up a git repository server (using gitosis and gitweb). Among the required features of the system was the ability to publish the git repository to a read-only Subversion repository. This sounds simple in principle but in practice proved to be a bit tricky.

Git makes an excellent Subversion client. You can use the git svn … series of commands to pull a remote Subversion repository into a local git working tree and then have all the local advantages of git forcing the central code repository to change version control software. An important aspect of this model is that:

Problem 1: Failover

The problem

Many applications only allow you to configure a single LDAP server. This can lead to unnecessary service outages if your directory service infrastructure is highly available (e.g., you are running Active Directory) and your application cannot take advantage of this fact.

A solution

We can provide a level of redundancy by passing the LDAP connections through a load balancing proxy. While this makes the proxy a single point of failure, it is (a) a very simple tool and thus less prone to complex failure modes, (b) running on the same host as the web application, and (c) is completely under our control.

As part of a project I’m working on I wanted to get a rough idea of the activity of the Apache virtual hosts on the system. I wasn’t able to find exactly what I wanted, so I refreshed my memory of curses to bring you vhoststats.

This tools reads an Apache log file (with support for arbitrary formats) and generates a dynamic bar chart showing the activity (in number of requests and bytes transferred) of hosts on the system. The output might look something like this (but with colors):

This document provides an example of using OpenLDAP’s meta backend to provide a unified view of two distinct LDAP directory trees. I was frustrated by the lack of simple examples available when I went looking for information on this topic, so this is my attempt to make life easier for the next person looking to do the same thing.

The particular use case that motiviated my interest in this topic was the need to configure web applications to (a) authenticate against an existing Active Directory server while (b) also allowing new accounts to be provisioned quickly and without granting any access in the AD environment. A complicating factor is that the group managing the AD server(s) was not the group implementing the web applications.

After encountering a number of problems trying to filter Blogger feeds by tag (using services like Feedrinse and Yahoo Pipes), I’ve finally put together a solution that works:

• Shadow the feed with Feedburner.
• Enable the Convert Format Burner, and convert your feed to RSS 2.0.
• Use Yahoo Pipes to filter the feed (because Feedrinse seems to be broken).

This let me create a feed that excluded all my posts containing the fbpost tag, thus allowing me to avoid yet another postgasm in Facebook when adding new import URL to notes.

I was poking around in a command shell on my Droid to see what was available. While it’s a pretty restricted environment, there’s a number of commands available in /system/bin, including dexopt.

Apparently dexopt isn’t something I’m supposed to poke at:

$ dexopt
Usage: don't use this

Hah.

The MBTA has a trial web service interface that provides access to realtime location information for select MBTA buses, as well as access to route information, arrival prediction, and other features. More information can be found here:

http://www.eot.state.ma.us/developers/realtime/

The service is provided by NextBus, which specializes in real-time location information for public transit organizations. The API (sorry, PDF) is very simple and does not require any sort of advance registration.

At the moment, the service only provides coverage for a small number of routes (39, 111, 114, 116, 117). I hope they expand the coverage of this service in the near future!

VNC clients use the RFB protocol to provide virtual display capabilities. The RFB protocol, as implemented by most clients, provides very poor authentication options. While passwords are not actually sent “in the clear”, it is possible to brute force them based on information available on the wire. The RFB 3.x protocol limits passwords to a maximum of eight characters, so the potential key space is relatively small.

It’s possible to securely connect to a remote VNC server by tunneling your connection using ssh port forwarding (or setting up some sort of SSL proxy). However, while this ameliorates the password problem, it still leaves a VNC server running that, depending on the local system configuration, may accept connections from all over the world. This leaves open the possibility that someone could brute force the password and gain access to the systsem. The problem is exacerbated if a user is running a passwordless VNC session.

I learned something new today: it appears that the underlying authorization mechanism used by NFS limits your group membership to 16 groups. From http://bit.ly/cBhU8N:

NFS is built on ONC RPC (Sun RPC). NFS depends on RPC for authentication and identification of users. Most NFS deployments use an RPC authentication flavor called AUTH_SYS (originally called AUTH_UNIX, but renamed to AUTH_SYS).

AUTH_SYS sends 3 important things:

• A 32 bit numeric user identifier (what you’d see in the UNIX /etc/passwd file)
• A 32 bit primary numeric group identifier (ditto)
• A variable length list of up to 16 32-bit numeric supplemental group identifiers (what’d you see in the /etc/group file)

We ran into this today while diagnosing a weird permissions issue. Who knew?