LTSP 5 and AIGLX

Woot! LTSP 5 + LDM over SSH (LDM_DIRECTX=False in lts.conf) + Open source radeon driver with AIGLX is working!

Nothing like running compiz smoothly on a dual monitor thin client :D

The problem I was having was that despite the X server on the thin client being fully configured and tested to use hardware acceleration locally, when connected to the terminal server over the secure LDM tunnel I was getting direct rendering with the software renderer which results in a big fail for compiz.

The key to avoiding the software renderer from being used for DRI was setting LIBGL_ALWAYS_INDIRECT=1 as an environment variable. I don’t know why with everything configured correctly that the system defaults to using the software renderer instead of indirect rendering + hardware renderer but at least forcing this environment variable in a global profile script allows for sexy hardware accelerated compiz goodness from securely connected thin clients.

Without the environment variable to force indirect rendering, glxinfo output with the LIBGL_DEBUG=verbose env variable set was complaining that the “drm device” didn’t exist. I suspect this is because glxinfo was expecting to somehow find the /dev/dri/card0 device on the terminal server itself instead of on the thin client and of course it doesn’t exist on the server… the OpenGL card is installed on the thin client!

There must be a way to get this working without the LIBGL_ALWAYS_INDIRECT environment variable but I couldn’t figure it out… this really smells of a hack but since it’s very easy to apply globally and it works just how I expect things to work, I’ll have to leave it in place until the time I can figure out another non-hacky way of getting the results I want with this configuration.

Amber Lamps!

Amber lights actually, to be a bit more accurate.

We’ve got these two IBM p505 servers that actually work pretty well. They were purchased on some kind of clear out two-for-one deal that my predecessor jumped on and while I probably wouldn’t be the guy to buy these machines in the first place, I’ve come to strangely like them. These server run our DNS, DHCP and soon-to-be LDAP stuff. It’s all distributed, replicated and zone-transfered goodness.

However, as of this writing they are both sportin’ a solid amber light on the LightPath diagnostics and the procedure to clear the amber light is… well… rather unclear. I think it’s unclear because we don’t have an HMC (Hardware Management Console) so we don’t get a lot of the spiffy external management features that these systems offer. Add to the fact that we run Linux on these hosts as opposed to AIX, which apparently has OS-level tools for querying the event log and flipping the light switches. I can’t find anything equivalent on Linux for p-Series systems… yet.

[ Read More ]»

A Correction

I need to make a small correction.

In my last post, “Interesting New Developements…“, I mentioned how AIGLX and DRI weren’t working with LDM. Turns out, if I use LDM_DIRECTX=true in lts.conf, that was indeed the case. But if I was using LDM_DIRECTX=false I would receive proper software rendering support reported by glxinfo instead of that BadRequest problem I had with the direct X option. I still haven’t figured out why but I’m sure it’s related to the SSH tunnelling involved in the non-direct X11 connection.

Also, I ragged on LDM quite a bit. Despite the perceived shortcomings, those interface issues can be resolved over time and I hope they will be because the real meat of LDM seems to work pretty well.

Interesting New Developments…

There have been some interesting new developments lately! Here’s a shrunken summary.

At present I’m doing a technology review for implementing a new terminal server. Our existing terminal server is a 4-way AMD Opteron 848 system that’s about 5 years old right now. It runs CentOS 4 and has been so mega-customized over those 5 years, I’ve never wanted to go through the pain of in-place upgrading to CentOS 5. We also have a simple IBM 1U server running Windows 2003 Server for windows purposes. It’s ok but also about 5 years old.

The idea is to roll both these servers into a large single physical server with some kind of virtualization. The large system would also have the resources to run other VMs, as necessary. Development/test boxes or what not.

[ Read More ]»

Yet Another AoE vs. iSCSI Opinion (YAAVIO)

That’s right, folks! Yet another asshole blogger here, sharing his AoE (ATA over Ethernet) vs. iSCSI (Internet SCSI) opinion with the world!

As if there wasn’t already enough discussion surrounding AoE vs. iSCSI in mailing lists, forums and blogs, I am going to add more baseless opinion to the existing overwhelming heap of information on the subject. I’m sure this will be lost in the noise but after having implemented AoE with CORAID devices and iSCSI with an IBM (well, LSI) device and iSCSI with software targets in the past I feel I finally have something share.

This isn’t a technical analysis. I’m not dissecting the protocols nor am I suggesting implementation of either protocol for your project. What I am doing is sharing some of my experiences and observations simply because I can. Read on, brave souls.

[ Read More ]»