The Microsofting of Linux

by Tom Adelstein

I love free software - free as in freedom. I'll take a free beer too. I didn't know about those things back in 1998 when I finally got Slackware to boot on my DEC Prioris and suddenly had a fast version of , ah, UNIX. Naw, this was free .

I immediately attempted to work that server into a project in an all Microsoft shop at Cap Gemini US. Somewhere along the line one of the tech support guys grabbed it and locked it in a closet where others attempted to scavenger it. I got it back and took it home where it eventually became my workstation.

One of the cool things about Linux? Remote administration. I could log into the server from afar and do stuff. I didn't have to go down to the data center, use a KVM switch and look at a NT GUI.

I remember remote administration, industrial strength servers running on Intel processors that scaled and lots of developers working on the core system. Those were the days when geeks were men!

Well, I just got another dose of Microsoft in the form of Fedora Linux. I started installing their free directory server and what a mess. Actually, it's a kluge. It's broke like Red Hat 5.0 was broke. But now, you have to use a KVM switch and look at a desktop even after you figure out how to make it work.

By the way, kluge has another spelling and here's the definition:

(I found a definition of kluge on Wikipedia that I like better than any I have seen before)

A kludge (or kluge) is a clumsy or inelegant solution to a problem. In engineering, a kludge is a workaround using unrelated parts cobbled together. People demonstrating the force of the term often say that it takes a skilled craftsman intimate with the task, the material at hand, and the operating environment to construct a workaround clunky enough to be called a kludge.

That's the definition of Fedora Directory Server. It reminds me of the broken NT servers on which I got certified - that's in passing tests not crazy. Broke and in need of workarounds.

Last week, we attempted to get the console to work but to no avail. What was wrong? Here's what the documentation said and what we did to work around the problem:

Try to start up the admin console (this is a graphic user interface, so you'll need to be running X):
# cd /opt/fedora-ds
# ./startconsole -u admin -a

If you get this sky-is-falling output:
GC Warning: Out of Memory! Returning NIL!
GC Warning: Out of Memory! Returning NIL!
GC Warning: Out of Memory! Returning NIL!
Exception in thread "main" java.lang.OutOfMemoryError
--No stacktrace available--

then you have a Java package problem.

As this was written, the Java packaged with Fedora (gcj) did not quite work with Directory Server, even though it's version 1.4.2. Check to find any updates or fixes. If the problem has not yet been resolved, change one line in the start-console script. Remove the -ms8m and -mx64m options (bold in this example to help you find them) from /opt/fedora-ds/startconsole.

Of course, that didn't work.

This week we get a new message from the folks at Fedora:

Java runtime. The JRE is required in order to use the Console. Either the Sun or the IBM JRE version 1.4.2 or later is required. Unfortunately, the console does not (yet) build and run with the open source GNU gcj/Classpath java implementation, but we are working on it. We thought that gcc/gcj 4.1 included with Fedora Core 5 would work, but it still has many problems, so your best bet is to use Sun or IBM JRE.

So, I built Java the hard way. I wound up at another URL and it said:

Fedora Core 4 users are advised not to use the Java RPM provided by Sun. It contains Provides that conflict with names used in packages provided as part of Fedora Core 4. Because of this, Sun Java might disappear from an installed system during package upgrade operations. Fedora Core 4 users should use either the RPM from or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is recommended for stability purposes.

I won't put you through the pain, you can go to and see it for yourself. I built it even though the contributor wrote the instructions for FC4. I found broken links. So, I went looking for the packages and found them on other sites.It all worked.

But here's a rub. doesn't work. But a workaround exists:

The JPackage java RPMs support switching between java implementations using the "alternatives" system.

[localhost ~]$ sudo /usr/sbin/alternatives --config java

There are 3 programs which provide 'java'.

Selection Command
1 /usr/share/java/
2 /usr/lib/jvm/jre-1.4.2-gcj/bin/java
*+ 3 /usr/lib/jvm/jre-1.5.0-sun/bin/java

Enter to keep the current selection[+], or type selection number: 2
[localhost ~]$ java -version
java version "1.4.2"
gij (GNU libgcj) version 4.0.0 20050519 (Red Hat 4.0.0-8)

So, you can switch to number 3 to run Fedora Directory server and back to number 2 to run Slick.

Final Thoughts

I like the command line. I'm not a big GUI guy unless no alternative exists. So with the console in a state of disrepair, I tried searching FDS from the command line. Then I went to another GUI tool, LDAP Administrator from Softerra. I got a picture of Fedora Directory Server's DIT. Oooooh is it ugly. I like to think I'm a pretty good LDAP admin, modeler, etc. but I don't wanna work on FDS unless they get that console working.

And if they do: Well, get a KVM switch, hope that it's good one and you can keep your keyboard and mouse running when you change to another console and back. Cause you're going to need to run X and you might as well get used to those admin tools in System->Admin->?


2006-08-29 16:44:50
This is why i steer away from Linux every day and use FreeBSD when ever possible.
Red hat and Suse are both at a point of being almost impossible to manage without X .
if you need to use linux in a corporate environment now days the only hope you have is the news about HP adopting Debian support.
too bad commercial success means conforming to bad practice.
2006-09-01 15:32:34
FDS is sucky to install because it's an old, monolith closed source product that was recently oss'ed and is bringing alot of baggage along with it.

Considering what it used to take to build FDS when it was first open sourced, it's come a long way, obviously there are a ways to go. Considering the feature set that FDS gives you vs say, openldap, it's worth the hassle, someday it won't suck so bad.

Also, why are you using a KVM when Windows provides remote desktop out of the box?

2006-09-01 17:13:14
Jorge wrote:

"Also, why are you using a KVM when Windows provides remote desktop out of the box?"

Would you like someone to edit this out of your comment or do you prefer to look like an idiot?

2006-09-06 08:26:32
I think it is a reflection of societal intelligence that everyone wants to have a GUI system. So many people are terrified of the command line, but this needn't be the case. The "average" user of GUI systems like Windows don't realize that the GUI can offer only a small subset of a program's full functionality.