Due to an otherwise unrelated hardware failure (long story) I've been forced to return an older Fedora Core system into service as a mail server. It's primary service is as a file server and Samba server to many dozen machines on an internal network and this new service is accomplished via port forwarding. When it was young, it was also the primary mail server. It's a high-end system in roughly mid-life, and it's running Fedora Core 16.
It has two NICs on an internal LAN.
Years ago, for reasons lost to history, its /etc/sysconfig/network-scripts/ifcfg-xxx files were gently hacked, and no originals were preserved (apparently). Perhaps regenerating them somehow would help solve this problem, but I don't know how to do that.
Most recently, it took to its resumed duties of email services with mixed success. It would only occasionally receive emails and mostly behave mute to inbound SMTP connections. It was eventually discovered, with much bloodshed, that SMTP reception , in particular, demonstrably unlike SSH, for example, requires that the return route MUST be identical to the route the inbound SMTP packets take. For practical purposes, this means that it won't receive email unless the default gateway is set to the ONE gateway sending it forwarded (port 25) packets (with the one exception of local-subnet systems). OK, that figured out, it was receiving just fine.
But now that there was some attention paid to it, it was observed how bizarre the system's /etc/sysconfig/network-scripts/ifcfg-xxx files were! For one thing, it was far from clear how it even knew what it's IP address should be - the only file that included a non-DHCP address wasn't even named like an an existing or recognized card. Of the two cards, one card was visible in ifconfig, and the other via route, but both were in neither!
Obviously this had to be rectified!
That is, of course, when things got worse!
There was a long drawn out battle which raged - a dozen reboots or more - until it was observed that NetworkManager was getting involved even when NO config file asked it to be involved. The default route only stabilized correctly when NetworkManager was disabled completely. Now, with the upstart at bay, completely silenced, everything seemed OK, except when people tried sending email!
Which is all the time, of course.
...And, with more pain, it was confirmed; enable NetworkNamager and it refuses to have the default route where it belongs following reboot and disable it and it just refuses to send email, though it pings and browses web sites just fine.
I'm stumped. It's just not tennable that someone has to manually hack the route following reboot... and besides, even if you did that, I've been unable to find a configuration in which it both sends and receives at the same time...
Great problem to have at 5PM on a Friday! (I'm having my Friday the 13th today instead of last week. -frown- )
UPDATE:
I gave up with editing the ifcfg scripts, and just removed them both (all), and re-enabled Network Manager. I control it by using DHCP from another internal system - stupid solution, but it works. One lesson learned: NetworkManager is NOT your friend - the reason the ifcfg scripts were mangled was likely because Network Manager kept inserting its nasty self...
