Ok, I have a small dilemma, and I'm hoping someone here has had to do this before.
I have at a site (not PARI) a server running some mission critical software that was written in 1997 for libc5, under AOLserver 2.3. No, source code is not available for that version of AOLserver (it wasn't open-sourced until version 3.0, and the API changed rather dramatically at that point), not that it would help any, as gcc has undergone so many changes since RH5 that a recompile would be very difficult. The software is currently running on Redhat 5.2 (don't laugh; it's got a 2,716-day uptime right now! (yes, that's over 7 years!)) with the libc5 libs loaded. The server hardware is just about ready to fly apart, and I need to see about running this on more modern hardware. Of course, they already have bought the replacement server, a Dell PowerEdge 1850. No way RH 5.2 is going to load on a PE1850 with the megaraid PERC 4e/Si.
Now, I've thought about a couple of possibilities: 1.) QEMU or VMware or similar running a RH5.2 instance under CentOS 4; 2.) Running a libc5 setup on CentOS 4. I'd rather do this, as security fixes would at least be available.
Going back to a RH5 machine and working was a real trip; had to use telnet (no ssh on RH5); Kernel 2.0 is still there, no yum, no chkconfig/service subsystem, etc.
The custom code is written specifically for AOLserver 2.3 in its tcl dialect and using API functions that don't exist in AOLserver 3.0 or later (or it would be a snap to compile AOLserver 4.0.10 on CentOS4 and roll); there's a couple hundred thousand lines of tcl code here, and while they will be contracting a replacement webapp using Plone/Zope, they aren't ready to transition as yet. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 828-862-5554 www.pari.edu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 10, 2006 at 10:26:29PM -0400, Lamar Owen wrote:
2.) Running a libc5 setup on CentOS 4. I'd rather do this, as security fixes would at least be available.
This should be possible. I never tried doing it on CentOS, but I did it on more than one Conectiva 10 machines. They did provide a compat-libc5 package for running old application.
You have to be careful, tho, cause your old AOLServer might need other libraries too.
Even if you can't find something like a compat-libc5 package for CentOS, it should be relatively easy to get the srpm from Conectiva 10 and rebuild it for CentOS. I know I did it for some other packages (including Mutt).
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sat, 2006-06-10 at 21:26, Lamar Owen wrote:
Now, I've thought about a couple of possibilities: 1.) QEMU or VMware or similar running a RH5.2 instance under CentOS 4; 2.) Running a libc5 setup on CentOS 4. I'd rather do this, as security fixes would at least be available.
I'd expect the VMware route to be completely painless and have the least surprises. It doesn't make much sense to throw extra work at something with no future. Security fixes probably won't help with the parts you have to keep running anyway - just firewall access to anything else.
----- Original Message ----- From: centos-bounces@centos.org on behalf of Les Mikesell Sent: Sat, 6/10/2006 10:53pm To: CentOS mailing list Subject: Re: [CentOS] Old (really old) programs under CentOS.
On Sat, 2006-06-10 at 21:26, Lamar Owen wrote:
Now, I've thought about a couple of possibilities: 1.) QEMU or VMware or similar running a RH5.2 instance under CentOS 4; 2.) Running a libc5 setup on CentOS 4. I'd rather do this, as security fixes would at least be available.
I'd expect the VMware route to be completely painless and have the least surprises. It doesn't make much sense to throw extra work at something with no future. Security fixes probably won't help with the parts you have to keep running anyway - just firewall access to anything else.
After more research, I found a copy, in my personal download archives, of the old AOLserver tarball linked with glibc2.1, from 1999. I actually found both the libc5 and the glibc 2.1; a good thing, too, since they're not available from aolserver.com anymore, only the full open source versions are there. There is a compat-glibc package for CentOS 2.1 for glibc2.1 (RedHat Linux 6.2's glibc); seems CentOS 2.1 would be a good fit (and, since this is after all the CentOS list, need to stay on topic).
VMware Server is in beta, and it is free, and it is downloading now....the end result will be a CentOS 2.1 virtual machine with the compat-glibc2.1 running the AOLserver instance, and hosted on VMware Server on CentOS 4. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 828-862-5554 www.pari.edu
On Sun, 2006-06-11 at 00:25, Lamar Owen wrote:
Now, I've thought about a couple of possibilities: 1.) QEMU or VMware or similar running a RH5.2 instance under CentOS 4; 2.) Running a libc5 setup on CentOS 4. I'd rather do this, as security fixes would at least be available.
I'd expect the VMware route to be completely painless and have the least surprises. It doesn't make much sense to throw extra work at something with no future. Security fixes probably won't help with the parts you have to keep running anyway - just firewall access to anything else.
After more research, I found a copy, in my personal download archives, of the old AOLserver tarball linked with glibc2.1, from 1999. I actually found both the libc5 and the glibc 2.1; a good thing, too, since they're not available from aolserver.com anymore, only the full open source versions are there. There is a compat-glibc package for CentOS 2.1 for glibc2.1 (RedHat Linux 6.2's glibc); seems CentOS 2.1 would be a good fit (and, since this is after all the CentOS list, need to stay on topic).
Another possibility would be RH7.3 which is rock-solid and still sort-of supported by the fedora legacy project if the compatibility libs would work. I still have a couple of 7.3 servers running things I've been too lazy to upgrade - and because I don't think the stock mod_perl has worked right again until FC5. The uptime counter has rolled over at least twice on one of them so it hasn't been a problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 11, 2006 at 12:09:45PM -0500, Les Mikesell wrote:
The uptime counter has rolled over at least twice on one of them
Hum ?!?!?!?!
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2006-06-11 at 12:17, Rodrigo Barbosa wrote:
On Sun, Jun 11, 2006 at 12:09:45PM -0500, Les Mikesell wrote:
The uptime counter has rolled over at least twice on one of them
Hum ?!?!?!?!
I think that version has a bug where it rolls at 497 days. It hasn't done 32-bits worth of seconds yet.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 11, 2006 at 12:22:55PM -0500, Les Mikesell wrote:
On Sun, 2006-06-11 at 12:17, Rodrigo Barbosa wrote:
On Sun, Jun 11, 2006 at 12:09:45PM -0500, Les Mikesell wrote:
The uptime counter has rolled over at least twice on one of them
Hum ?!?!?!?!
I think that version has a bug where it rolls at 497 days. It hasn't done 32-bits worth of seconds yet.
You gave a scare :)
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On 6/10/06, Les Mikesell lesmikesell@gmail.com wrote:
I'd expect the VMware route to be completely painless and have the least surprises.
I'll second that. I have some libc5-ware that was originally written for RH5.2 running via the compatibility libraries on a RH6.2 guest operating system in VMware on CentOS 3.6, and it all works perfectly. I start a VNC server from /etc/sysconfig/vncservers that in turn starts up VMware Workstation configured to auto-boot the guest. Then I just have to remember to connect to that VNC and shut down the guest before any reboot of the host.
I have a similar setup using the free VMware player on a different machine with a CentOS 4.3 host, though I haven't yet gotten around to trying to get that to auto-boot.
However, don't expect the latest VMware Tools to work with such an ancient guest OS.