At 10:49 PM 9/19/2006, Feizhou wrote: >>This also points out one of my concerns with the RHEL distribution >>(we have lots of copies we pay RH for, and a few we use CentOS >>for). For some packages, we'd REALLY like a choice of staying on >>the present train, or moving forward. In our case, sendmail-8.13 >>would be useful, and php-5.x would be useful. If there were the >>possibility of getting those -- including bug fixes for security >>updates via normal patch installation methods -- we would be much happier. > >postfix :P > >Except for one security issue and one DOS way back in time, postfix >has been pretty good when it comes to security issues; being as it >is written by a security expert. > >The latest RHEL postfix is 2.2.10 which brings along a lot of lovely >features and it is also a complete dropin for sendmail. Actually, postfix is not a complete dropin for sendmail. There are a number of items it does not do the same way, so if you've got extensive configurations and adjustments, there are differences. I don't disagree postfix is interesting and useful, and has matured well. But there are differences in using it. >Or you can become a sendmail expert and package your own up to date sendmail. We do much with modified configurations, we just prefer to rely on redhat to port and test the bug fixes on the sendmail binaries, as the sendmail.org folks seem to release many releases, and we just don't have the bandwidth to track them and rebuild for our servers as they come up. You could make the same argument for PHP, Apache and a dozen other core application components as "things we should just package ourselves" but we might also need a bit of time in our lives to run the business, rather than building tools. This is why we pay RedHat for bug fixes on our production servers. In talking with a RedHat person at LinuxWorld, they seemed to be getting this feedback from a lot of folks (wanting newer packages, supported, on stable versions of RHEL). Sounded like they were open to the idea, if not sure how they'd actually implement such.