On setting up Kerberos, OpenLDAP, and NFSv4
So, one of the things that I have wanted to do for a long time is setup the network at home such that it could become easier for us to use, and for me to manage. For some time now, Kerberos, LDAP, and NFSv4 is a combination of things that I have wanted to get going here.
I’d attempted it earlier, when I set up Ubuntu Hardy on my server just before it was officially released. Due to time constraints, I wasn’t able to finish working on it, and that was different with the release of Intrepid.
It was my intent to document everything every step of the way so that it could be made easier for everyone and I could share everything I learned along the way. That didn’t quite happen the way that I wanted, but I did still learn a lot and will be putting the final touches on testing the setup tomorrow, with the hope that it will work as my testing tonight shows it will.
After that, hopefully, I’ll be able to write up a document on setting this up with Ubuntu. There are a lot of documents out there which provide useful information, though this process involved a lot of trial and error and reading of more than 200 pages of printed material for me. That’s not a lightweight task, of course—and I’ve been using computers and UNIX/UNIX-like systems for a very long time. So, yes, currently setting these things up is something of a complex deal.
But, I did learn—well, more reinforce something I knew already—something throughout this little project. I’ve mentioned before that I think that the way Linux systems are distributed probably ought to have something of a better, cleaner division between what is the application software and what is the system software. This is another situation where I think that such a difference would be a wonderful thing in a system. What do I mean?
Well, we see in the Windows world such a division. When you purchase a copy of Windows, you choose one of eleventyone versions that fits your needs (or at least, so you think). We could do something similar for Linux systems, though we could obviously reduce the number of choices under a single brand to something that users would actually care to look at. Ubuntu has done some of this already—they ship different configurations of software by default for server and desktop versions, for example. However, the division between the system and the applications that run on the system is completely nonexistent. For people who very much like to tweak their system, this is something of a mixed blessing. For starters, it makes it easy to modify any single package which comprises the system. However, it can be a bit of a problem when you want to do something task-oriented that involves a mix of application and system software—that is, system software for an application.
I don’t know what the ideal approach is, or would be. It’s something that I’d like to try to figure out, though, at some point. FreeBSD has an interesting layout wherein the system itself is not managed by the package manager and is considered to be an implicit dependency in the package management system, and everything outside of the base system is installed using ports. This is a cool concept. What if someone were to do something similar with a Linux system and create a distribution wherein the base system is a nice tree of source packages which are shipped together in a single unit—and maintained together as a single unit—and then use the package manager to only manage application software?
Doing this is something that would be bound to make some current users unhappy—I wouldn’t expect that a Gentoo user would want to think about playing with such a system when they’re already quite happy with Gentoo, for example. But, if you made a desktop environment and server software to go with it, and made the system segments catered to each purpose, you’d have something that a manager could pull “off the shelf,” so to speak, and immediately put to use. If you have the assurance that the only people that are going to be modifying the base system are people that are very sure they know what they’re doing, then you also make it easier to assume a few things about the base system in various different configurations.
As an example, take a fictional new brand which had two distributions, the server distribution and the desktop/workstation distribution. The install process for both would be relatively fast, with only a few things being configured at set-up time. On a server install, there should be a common set of server software that is easily configurable—using utilities bundled with the server itself. On a workstation install, you’d have a similar thing, with the easy ability to join into any setup that the server supports, or maybe even that other servers running on other operating systems support.
Windows Server includes an interface for quickly configuring things like the Microsoft DNS server and IIS, and when you set up the directory service under it, it is integrated very nicely into the DNS server. For example, when you configure an Active Directory domain, there are automatically DNS records which are published so that Windows workstations can find the AD controller and use the services on it. We need something like that on Linux systems—where one drops a server, say, which can be quickly configured to provide central authentication and storage services and just as quickly get the clients up and running. Then, the solution is very quickly integrated.
What would this require? It’d require a distribution that manages certain classes of software—such as the DNS server, and the LDAP directory service, and the Kerberos authentication system—as system software and not as userland packages. Why? If you don’t, you have to decide things like which implementation of Kerberos you’re going to be using, or which LDAP server you’re going to use. The most common combination, as an example, seems to be MIT Kerberos with the OpenLDAP server, typing these into PAM and then combining them with some sort of networked filesystem such as NFSv4. This is what I did, in fact. There is also something called OpenAFS which can be used to provide the filesystem portion of things.
But, the important part would be that these things are configured by a single piece of software which is tasked with the purpose of integrating these things together. In other words, if you create a server product, you can provide a set of reasonable default choices for the software and also provide easy access to common configurations. Obviously, you’re not going to meet everyone’s needs if you only provide single solutions for each task, though, right? Probably not. But the point isn’t to fit every single possible configuration—the point is to give a quick starting point to launch quickly from and then give the user the ability to focus on doing more advanced things with their software. If I didn’t spend the last three days fussing with Kerberos, LDAP, and NFSv4, for example, I could have spent 30 minutes on the initial setup and then spent another three days putting all the polish on for very little things that I wanted to do. Or I could have spent the time moving my domain’s services—like this blog, or the email domain, or the Jabber domain—onto my own network. Or any number of other things.
Furthermore, if you provide a client which is fully and easily integrated into the server, you can do a great deal more in far less time. The client setup could even be smart enough to look for certain hints on the local network for the installer—say, issuing a few requests to the local DNS server such that it can automatically detect whether or not one is using a directory service and prompt the user during the workstation installation process as to whether or not they want to become part of that collection and configure their workstation to become a functional member of that network automatically. Maybe the network server of this fictional branded distribution could also publish information on the network which provides configuration settings for installed machines in a purely automatic fashion, making it such that if you want to install, you just start the installer and have the workstation configure itself. Then when you have a very large organization, providing a new workstation is a very easy task: Plug it in, install it, and go. This idea could even be extended to provide for different configuration profiles which could be used for very large networks, and I think it’d be better than the systems that exist currently.
To my knowledge, no such distribution exists. There are distributions that come close—I do like Ubuntu Server for its ability to quickly pull down and configure individual pieces of network infrastructure—but there is not (to my knowledge, anyway) any distribution which provides a very high level of quick-setup-and-go for many different things, and provide an easy-to-manage way of doing things with it.
I do think, for sure, that it all starts with removing the base system from the package manager—in effect, using a different method of management of the base system than the package manager provides. I think it’d also make long-term-support releases of desktop and server software much easier, since the line between the system and application software is more clearly drawn.