SysAdmin Adventures

I wish I understood why LDAP support is so unbelievably piss-poor in so many software products. So many organisations use LDAP as their core user directory (whether OpenLDAP, Active Directory or some other LDAP implementation) or have a directory service that will provide its data via an LDAP interface. I see people screaming for LDAP support in everything, but so little support from software coders/vendors; I can only assume because they personally don’t have much LDAP experience. Just about every F/OSS software project claims to have LDAP support, but because someone who didn’t totally understand the application itself wrote some add-on code to make it work. This leaves everyone else following poor instructions for adding-in support to an application that really should be supporting LDAP natively from day one.

For Request Tracker from BestPractical, I ended up re-writing the very limited user-contributed code that already existed into a fully-fledged extension for LDAP support. But it’s still not easy for RT administrators because my extension is not part of the core RT code; it is tacked-on over the top and, while I try to make it as easy as possible, people still run into problems with implementation. Also, when they need new features and I don’t have the time to implement them (which I don’t), they’re left up the creek with no paddle because the core development team didn’t write it and don’t intend to pick it up and code new features into it. In the case of RT, there is the suggestion that the LDAP code will be integrated into the next big version (RT4), but it is literally years too late.

At the moment I am having intense headaches over Foswiki, the fork of TWiki. This is the type of system that was born for use in organisations with existing user databases, but still getting it to take its user information out of LDAP is a NIGHTMARE. The basic principle is simple: have some perl code do an LDAP bind when a user tries to login, and if successful, do a search on their information and then map that information into the application based on a simple variable map. It’s how LDAP works in every app I’ve ever come across. But, to get this working in Foswiki you have to install four extensions (LdapContrib, LdapNgPlugin, GluePlugin & NewUserPlugin), you have to go through activating and configuring each plugin, and telling the login system which one of the three (confusing and not well documented) options it should use for each of the processes, then you have to go into the Wiki pages themselves and start again. You have to write (in a special Wiki code you won’t be familiar with) your own templates for gathering the LDAP information and then code up how you’re going to pass this to the NewUserPlugin so that during auto-registration some magical process can take place to update the user’s information. And I’m willing to bet that if I want the information to stay up to date with the LDAP database I will need a fifth plugin to check for changes during login as Login doesn’t normally handle user information, that’s a registration thing.

It’s the same all over. Pick pretty much any F/OSS web-app you like that requires a user database and you will find that LDAP support is either not-present, tacked on haphazardly, or is available only via user-contributed code of varying quality and documentation.

DEVELOPERS: PLEASE FOR THE LOVE OF GOD GET YOUR ACTS TOGETHER!!


When you design an application like these, your user authentication and information systems need to be able to handle an LDAP (or sql for that matter) back-end. It’s really not difficult. In most languages the template code for the ldap searches and binds has been done for you, you just have to use it. I do what I can to provide good code to help people get LDAP working in their apps but it is not easy and there’s only one of me.

LDAP is easy, but each individual application has its own way of doing user authentication. If I want to put LDAP code into an app, it means I have to understand the nuances of the code and then write around it. In systems such as RT and Foswiki, the authentication systems are so complex it can take weeks to get up to speed with how they work, even with direct input from the developers themselves. I just don’t have the time to learn every authentication system ever written. If the developers themselves took a moment to realise how simple it is to add LDAP support to code they already understand, and then to get off their arses and *do* it, life would be a lot easier for everyone and it wouldn’t be so hard to implement these systems in company networks. That means we could finally start pulling away from “pay someone else to do it” mentality that has companies throwing thousands of pounds at piss-poor software vendors just to save from spending the time working out how to do it themselves.

Another Monday morning, another failed fibre GBIC in an Allied Telesyn switch. Yay(!). And so cheap at £80 apiece to replace. I wouldn’t mind so much if these switches worked well, but they really really don’t.

• Web interface sometimes works, sometimes doesn’t. If it can be arsed to provide the images (because ALL links are image links), it does so at its own discretion and provides no guarantee the right image will be in the right place.
• Switches enjoy failing completely at random intervals prompting a hard-reset.
• Sometimes, when they feel like challenging me, a single port will have a hissy-fit requiring that I reallocate the device plugged into the port, or hard-reset the whole switch.
• Upon reboot, the switch with the VLAN suddenly has a selective memory and forgets to put the VLAN back in place and so the segregated customer network suddenly has full internal network access.
• And, of course, there’s the GBICs, which die on average once every three months or so.

Thanks SO much Allied Telesyn,
No love.

Many manufacturers make low-quality hardware because it’s cheaper and they can sell it for less. Often, cheap hardware is just what you need; unless you’re buying UPGuards branded equipment. In this building we have a little bit of a power issue because instead of 230V we get between 240V and 255V depending on which way the wind is blowing. This may be the cause this may not be the cause, but the fact of the matter is, we have had somewhere in the region of 80 UPGuards PSUs, and I have replaced approximately 65-70 of them so far, and more die every month. Every time I have replaced one of these it has been with a bog-standard HEC 350W PSU and, let me be clear on this, not one of the HEC PSUs has failed on me yet. Not a single solitary one. These are not expensive or high quality PSUs, just cheap bog-standard quality.

If the HEC PSUs are fine, there is NO excuse for UPGuards to have nearly a 90% failure rate.

Buyer beware!

I understand that there are rare situations in which an initrd can be useful. For example, when hardware is constantly being swapped out, or when you absolutely must have an identical kernel image, or if you are using LUKS for your / partition. However, in general an initrd is, in my opinion, a completely pointless level of complexity that you are better off without.

I’m currently managing in excess of 15 completely different Slackware installs across lots of different hardware and not one of them is running a “huge” kernel, or an initrd. If a module is absolutely essential to your system’s ability to boot, why in hell haven’t you compiled it into your kernel? It’s like having a your starter-motor in your car disconnected from the battery, but having a relay on its own mini-battery connect it up when you turn the ignition.. why would you do it? What’s the point? The car will not start without it, why is it not hard wired into the system? It’s the same for the kernel. If the system won’t start without it, compile it into the kernel. Don’t play about with an injection system you don’t even need.

Ok, so your root device is inside RAID & LVM on a GPT partition. So, compile in mdadm support for your RAID level, LVM support and GPT partition support; job done.

For the less experienced, it’s also a good way to learn the basics of kernel compilation without needing to do much more than follow a standard process. All you need to do is use the config from the generic kernel you were going to boot anyway, and knowledge of what filesystem your root device is installed with and what storage controller your disk uses. Go into the kernel config, add them in [*], make, make modules_install, move and symlink the new kernel, update lilo, reboot. Once you’ve done it twice, it becomes so routine and easy you’ll wonder why you haven’t been doing it forever.

Then, once you’re more familiar with the process, you can start removing other parts of the kernel you don’t need, especially hardware controllers for hardware you don’t have, with each step making your kernel smaller and your system leaner and faster.

Have kernel, will compile.

Post followed-up by:
Compiling your own Slackware kernel