Eugene wrote: > > For those who love adventures, note that it is possible to install 2.4 > kernel on a RaQ3/4 without touching the rest of the system (aside from > obligartory BIOS reflashing); kernel RPMs are somewhere on ftp-eng.
Not that I love adventures but I did this to one machine because some sort of network based Denial of Service thing was knocking over my fully patched Raq4r machine several times a day. It was running an updated BIND and gShield/IPchains was used to block all other access, there were no public web services or anything. Only the 2.4.19C1_III-1 kernel works if you have more than one disk (i.e. Raq4r), the earlier kernel will not let you see the 'hdc" drive due to an IRQ detection problem. With this kernel I was able to install the RH 7.2 IPtables RPM and the latest gShield to firewall the box. The machine has been stable for 12 days now, life appears to be good again. I suspect that there are "other issues" with the 2.2 kernel but have no hard data to prove it other than I made the problem go away by going to 2.4. Some other notes; the "storage" start-up script doesn't work very well with the 2.4 kernel. I had to disable it as it caused in the order of a 15-20 minute delay booting the machine. The script is probably not required unless you have external SCSI drives and in that case you could probably work around the issue easily by populating fstab. I have not tried any other services on the box besides BIND and IPtables, I have no idea if there is other collateral damage. Drastic DNS problems required drastic measures and I didn't care what else I broke on that machine. You also have to do a --force on all the Kernel and module RPM installs as they scribble on the old files. I keep a few 20G drives around as spares and just used dd to move my good filesystems onto a spare drive to play with. I would never go with this upgrade route if I didn't have extra Raqs laying around, extra disks, a Linux PC to mount the Cobalt drives in, a serial console and a UPS on the machine being flashed. The whole thing falls into the fairly high risk category. I have no idea where I am going next, by doing this I have created issues related to the application of future packages on the box. I have a bunch of these Raq4r machines and they are making me VERY nervous. I am toying with the idea of just turning them into generic Linux servers with a minimal install and hand building all the critical daemons with no extraneous modules and such. I don't like the ancient kernel aspect of the Raq4, the old libraries and the myriad of other outdated software. The slow release of updates for published vulnerabilities compounds the issue. I have learned my lesson, open source software is good, open source software with a proprietary layer is bad, very bad . . . This issue is not unique the Raq, I have seen the same thing played out with some other commercial solutions in my environment in the past year. Big vendors with too much "Cathedral" in their development process, while they are ensuring that they don't release a patch that breaks every customers server, half of the customers servers have been burned down by a worm. There has got to be a balance there someplace if they want to keep selling the product. Okay I digressed into a rant . . . Sorry. Eric > > Eugene > > _______________________________________________ > cobalt-security mailing list > [EMAIL PROTECTED] > http://list.cobalt.com/mailman/listinfo/cobalt-security > _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
