Help - Search - Members - Calendar
Full Version: RHEL and Iptables breaks a few things. *sigh*
The Planet Forums > Operating Systems > Red Hat Linux
Protollix
SO I ordered a dual xeon box back in June to move my shared hosting clients to. I figured I would go with RHEL since it is actually updated.

big mistake.

I have nothing but problems. I don't know if it's RHEL or the server hardware.

Anyhow, my current problem:
I installed DWMail for my customers, however when using IMAP connections to the server (same server DWMail is installed on) it refuses to grab the attachments. I verified this in Squirrelmail as well (actually, this was what prompted me to buy DWMail).

It took me forever to track this down. I was doing tcpdumps on eth0 and lo. Naturally, lo is the interface DWMail was sending packets to, since it's on the same server. tcpdump showed a flurry of packets go by. So, imap works, you just can't get attachments *when you query the imap message from the same machine*. I can login and view the attachments all day long with Evolution or Thunderbird. I can use DWMail installed on another server to access this very same imap account and it works perfectly.

The root cause (as far as I can tell): iptables.

I issue "service iptables stop" and it works as expected. Now, most people would say I have some broken rules somewhere. Not quite. I can restart iptables, with no rules. I then add a single rule. Any rule, it doesn't matter. Block an ip. Block a port. Allow the SM monitoring IPs in. Once a rule is added to any table, it breaks again.

I then unloaded iptables with rmmod. I then did an "insmod ipchains". Just *loading* that module breaks IMAP.

This was the same symptom I was having with Tomcat on this machine a month ago. Tomcat would just hang when communicating with Apache over (you guessed it) interface "lo".

I compiled IPTables from source. Same problem.

I *can't* update my kernel (currently running 2.4.21-15.0.2.ELsmp) because 2.4.21-15.0.4.ELsmp causes a kernel panic on boot.

I hand rolled a 2.6 kernel. The machine ran, but server loads stayed at 30, reported swap usage was 2gb (even though I had disabled swap at the time) and a host of other problems. Oh another biggie was that 2.6 wouldn't let me go higher than udma2 on my disk drives. It has to be the hardware. What a crappy server for $250/mo icon_confused.gif

I can't afford to move my customers *yet again* to another machine. Has anyone else experienced *anything* like this? I am really one very disgruntled sysadmin right now icon_sad.gif

If SM would let me keep my IPs, that would be great and I would move to a new box icon_sad.gif
dezignguy
Why not use the latest kernel? Maybe it's been fixed already?

The latest kernel for RHEL 3 is 2.4.21-20 (and the smp version for you). Get SM to install it for you if you have at least the Silver plan.

Have you done "up2date -l" to check that you have the updated rpms for everything?
Protollix
While I ahve not tried that specific kernel, I did try the previous 2.4.21-15.0.4 and like I stated in my post, it causes a kernel panic.

Tonight, I think I will update the kernel myself and have SM reboot (and monitor!) the machine while it comes up.

Somehow, I doubt it will be "fixed" as no one else seems to have this problem with this kernel version on this same server setup. But I can hope I guess icon_razz.gif
Protollix
Well, the latest kernel upgrade resulted in a kernel panic as well.

I just ordered a new TC box, hopefully this one will work properly.
damainman
What is a kernal panic? icon_confused.gif
Paul
When a kernel breaks out in a cold sweat and goes:
[size=24][b]ARGH NOO NOO NOO NO ARRRGGHHHHHHH NOOOOOOOOO NOT THE PINK TURNIP

That's what my goldfish told me anyway.

Alternativly,
In Linux, a panic is an unrecoverable system error detected by the kernel as opposed to similar errors detected by user space code. It is possible for kernel code to indicate such a condition by calling the panic function. However, most panics are the result of unhandled processor exceptions in kernel code, such as references to invalid memory addresses. These are typically indicative of a bug somewhere in the call chain leading up to the panic.

Basically, a *nix equivilent of a windows BSOD.
damainman
lol thank you. How would i notice if i'm having a kernal panic though, like what would the log look like and which log?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.