Highpoint has finally updated their Linux Open Source Driver for the RR174x series of SATA RAID adapters. I’m hoping that this will resolve the inability to compile the driver under newer versions of the Linux kernel, such as for the updates that have been issued for Fedora 7. However, my Linux box at home is currently turned off, since I’m on vacation. I won’t have a chance to test it until I get back, but I thought other users of this hardware might be interested!
I have to start by giving the punch line first: I’m just appalled at Novell’s support story around SLES and SLED 10. In this article, I’ll explain why. Continue reading
It was busy in June and July over at $WORK, so I didn’t get a chance to write any entries here. Some of the work I’ve been doing include turning off all legacy servers (among the legacy servers are only 2 FreeBSD boxes and a handful of HP/UX dinosaurs, but the rest of the production environment is SUSE Linux Enterprise), shepherding the BlueArc storage upgrade through (a huge pallet containing disks, controllers, disk shelves, and a replacement Fibre Channel switch arrived last week), and, of course, planning our upgrade to a modern Apache/Java environment. This will consist of Apache 2.x with a Tomcat 5.5 back end — a far cry from our current Apache 1.x and Tomcat 3.x setup.
One of the major challenges is getting Tomcat 5.5 running on SLES 9 under a Java 1.5.x virtual machine. Actually, it’s not so much the “running” part — I’m sure that since it’s Java, it would just run if I did the old tar zxvf tomcat-5.5.tar.gz && make && make install dance. But we’re after sensible package management here, and that means trying to make SLES 9 behave the standard way. SLES 9 is missing a lot of the “standard” tools that folks use to manage Java apps; it has no jpackage-utils built-in, it doesn’t use the alternatives system, and it can’t talk to Yum repositories out of the box. The work instructions I developed here hack up the base OS a bit to bolt on these tools, but ultimately do the job.
The long-term solution, of course, is to move to either SLES 10 or RedHat Enterprise Linux 5. SLES 10 ships Tomcat 5.0.x out of the box (just like SLES 9) so on the surface, it doesn’t seem like much of an improvement. But they have moved to the alternatives system; jpackage-utils is bundled with the base system, and ZMD (for what it’s worth) will talk to Yum repositories. (Of course, that’s in theory: in practice, as with many Novell tools, it’s broken.) RHEL 5 seems like the obvious answer, since it ships Tomcat 5.5 right out of the box.
Anyway, that’s a bit of a digression. Here are my directions for getting Tomcat 5.5 installed and properly package-managed on SLES 9 with JPackage. Continue reading
|10||Ordering CDs from Bill Gates’ Amazon.com wishlist just like RRDtool claims to do when running configure.|
|9||Booting Windows XP and running CHKDSK.|
|8||Defragmenting /usr/lib so that Mono can run more efficiently.|
|7||Converting your /var partition from ext3 to FAT-16.|
|6||Drawing the Windows “flying folders” in the background.|
|5||Downloading patches from the RedHat Network and then pretending them came from Novell.|
|4||Installing IPX/SPX for Linux and registering with any eDirectory servers it can find.|
|3||Launching Python for Windows to run the old version of rug that didn’t suck (as badly).|
|2||Upgrading the TCP/IP stack on your computer to support Web 2.0.|
And the number one thing ZMD is doing while waking up:
|1||Downloading YUM and creating YUM repositories so that when you throw ZMD out the window in frustration, you can still update your software.|
On June 16th, SDF Public Access UNIX system will celebrate its 20th anniversary!
Twenty years ago, SDF-1 was a 300 bps dialup BBS running on an Apple ][e computer system, and has evolved over time into a twelve node DEC Alpha cluster running the NetBSD operating system. SDF users, of which I am one ([email protected]), pride themselves on the fact that theirs is one of the last bastions of “the real INTERNET”, out of the reach and scope of the commercialism and advertising of the DOT COM entities. I recall fondly the days before commercial traffic was permitted on the NSFNet, and oftentimes wish that we could return to those days when everyone knew their proverbial neighbours.
If you’re interested in SDF, lifetime membership is very affordable at $36. You can find out more information about SDF here. You won’t find any fancy Web 2.0 widgets, but you can definitely still use Gopher 1.0!
I just upgraded to Fedora (no longer “Core”) 7 and decided to finally install Adobe Acrobat Reader for Linux. Normally I’ve used the built-in “Document Viewer”, but I needed to fill in a PDF form, and only Reader will allow you to do that.
Upon installing Reader, I found it would loop forever, printing expr: syntax error on the screen. Fortunately, someone has already solved this problem:
Now it works perfectly. Thanks, Javier Arturo RodrÃguez!
There are a few other annoyances with Fedora 7. One is that Azureus crashes right after startup using the Sun JVM 1.6.0_01 (Update 1). I’m also getting a strange BUG: warning on system startup which apparently has been fixed in CVS.
I also had to perform an upgrade using Yum instead of booting off the installation CD and doing a binary upgrade, because my system has a Highpoint 1740 SATA RAID adapter and a driver disk is not yet available from Highpoint for this. My procedure for upgrading using Yum and keeping the system functional was as follows:
- Upgrade using the procedure described in the Yum Upgrade FAQ as above. This involved a lot of manual dependency munging, specifically me having to massage an upgrade of mkinitrd and nash manually.
- Build the Highpoint rr174x driver for the new kernel and install it into the initrd. This involved a magic incantation of the sort cd /usr/src/rr174x-linux-src-1.02/product/rr174x/linux/ && make install KERNELDIR=/usr/src/kernels/2.6.21-1.3194.fc7-x86_64.
- Resolve .rpmsave/.rpmnew conflicts (basically mergemaster for Linux)
- Fix up /boot/grub/grub.conf to make sure the new kernel is there (for some reason it wasn’t)
- Comment out old /dev/hd*-format devices in /etc/fstab because Fedora has switched to using libata entirely, so even old PATA devices now use the /dev/sd* notation.
- Reboot and cross fingers.
- Fix up disk device names in /etc/fstab with the new sd* name.
- Reconfigure samba so girlfriend can access MP3s again. 🙂
Altogether, not the most painful upgrade I’ve done, but I would have preferred to do the binary upgrade using the installer CD. Only if Highpoint would release its drivers as open source and then they could be incorporated into the kernel tree…
As some of you know, I run SUSE Linux Enterprise Desktop (SLED) on my CBC-issued desktop. CBC.ca also uses a combination of SUSE Linux Enterprise Server 9 and 10 systems to produce and host the website, and most of the corporate infrastructure is Novell-based (Novell Groupwise is the corporate e-mail system, the file servers are all Netware, etc.) I use SLED because it gives me the right balance of being a UNIX-like operating system, and giving me access to corporate file shares through eDirectory. But let me be clear: I use SLED because it’s UNIX-like, just as we use SLES on the servers because it’s UNIX-like. One element of SLED/SLES that is distinctly not UNIX-like is the package management toolchain, ZenWorks Linux Management (ZLM). And that really bothers me.
On the other end of the spectrum from my last post, I decided this evening to install NetBSD 3.1 on the SGI Indy that fellow BSD user Jeff Buan gave me a few months ago. This system would have cost an obscene amount of money back in the day (1993) but now, it’s probably worth about $10. These boxes are pretty close to as rock-bottom as you can get these days:
mainbus0 (root): SGI-IP22 [SGI, 690887b5], 1 processor int0 at mainbus0 addr 0x1fbd9880: bus 66MHz, CPU 133MHz
Jeff had problems giving it away until I took it as a challenge 🙂
Speaking of challenges (pun intended), the last time I tried to install anything on an SGI server, the victim box was an SGI Challenge L — a 200kg fridge-sized monster that my friend Naveen had muscled from the Department of Astrophysics at U of T. It required a 220V power converter that he ended up buying from the House of 220, and a custom-soldered RS-422 serial cable to get on the console. I hoped the Indy would be easier to set up.
I’m writing this entry under SuSE Linux Enterprise Desktop (SLED) 10, which I recently installed on my CBC-issued ThinkPad T42. The laptop came with Windows XP installed, which I decided to retain in a dual-boot configuration, because there are still certain tools at CBC (like our antiquated Visual Basic-based â€œGuests & Boardroomsâ€ booking system) that still require Windows. I did manage to get Remedy ARS to run properly under Wine, however (the latest version, 0.9.28, that is; earlier versions had weird problems rendering dropdowns).
I decided to evaluate SLED because of a number of reasons:
- I am fairly satisfied with my OpenSuSE-based CBC-issued desktop, and wanted to see what a â€œvendor-supportedâ€ branch of OpenSuSE would look like;
- Novell Client for Linux is only officially supported under SLED, although I have it installed under OpenSuSE, with some hackery (like --force and --nodeps manual installation of RPMs);
- There is a rumour flying about the IT grapevine that in the not-too-distant future, CBC will be converting many of its desktops to run SLED.
My expectations for SLED were somewhat low. Although I fully expected everything to work as advertised in the product literature, I worried that the feature set would lag behind the cutting-edge by at least twelve months, as is the norm with RedHat Enterprise Linux (RHEL). For example, I was surprised to see a 2.6.16.x Linux kernel; had I installed RHEL, I would probably be running a 2.4.x kernel.
I decided to put SLED through the paces by trying out a few things that it advertises as working, but with which I’ve had problems in the past:
- stable wireless networking
- wireless networking with WPA2-PSK encryption for my home
- NovellVPN client which purportedly talks to Nortel Contivity VPN concentrators (used at CBC)
- NetworkManager for switching connection profiles
- suspend/resume to disk
- Evolution connectivity to Groupwise servers using the Groupwise SOAP interface
- On-board Intel modem
Finally, I wanted to play around with the Xgl display effects, and to see how well that worked (and whether it looks as nifty as my colleagues claim)
I have to say that after a couple of weeks of using SLED that I’m very impressed. This is perhaps the nicest-looking Linux distribution I’ve ever used, and everything does â€œjust workâ€. Wireless networking is stable and functional, which is absolutely unprecedented for me under Linux. The NovellVPN client does in fact talk to CBC’s Contivity VPN with no problems. And all the problems that have plagued NetworkManager in the past seem to have disappeared. Connection profile switching is as seamless as Mac OS X, which is more than can be said for the IBM Access Connections hackery that is required under Windows.
There’s only one challenge remaining for me, and that’s to see if I can get PPTP working under SLED. This is because the CBC in-building wireless network requires it; association to the AP requires no authentication or encryption, but in order to get onto the BAN, a PPTP VPN connection through a Bluesocket concentrator must be made. I’ll keep you all posted as to my progress!
And yes, the Xgl desktop effects are very nifty — but my laptop’s video card is woefully underpowered, so sometimes X fails to start with Xgl turned on. However, on a desktop machine with a decent video card, I’m sure they would perform perfectly.