MSM installation ticking along nicely 
at www.deddington.org.uk. Many thanks to the patient replies to my various posts.
Of course, maintenance now kicks in. Currently at 3.18.3 on top of PHP 5.1.6, Apache 2.2.3, Postgres 8.1.11 (over a current CentOS5 virtual server ie yum check-update lists nothing).
Any reason to upgrade PHP or Postgres? Reasons not to? I'm trying to walk the fine line between staying current (bug/security fixes primarily) and breaking what already works.
In general, how does one find out what is the most recent safe version of PHP, Postgres etc that should be used with a MSM release? As distinct from the minimum version requirements. Apologies if I've overlooked some docs.
thanks, martin
[quote]MSM installation ticking along nicely at www.deddington.org.uk. Many thanks to the patient replies to my various posts.
Of course, maintenance now kicks in. Currently at 3.18.3 on top of PHP 5.1.6, Apache 2.2.3, Postgres 8.1.11 (over a current CentOS5 virtual server ie yum check-update lists nothing).
Any reason to upgrade PHP or Postgres? Reasons not to? I'm trying to walk the fine line between staying current (bug/security fixes primarily) and breaking what already works.
In general, how does one find out what is the most recent safe version of PHP, Postgres etc that should be used with a MSM release? As distinct from the minimum version requirements. Apologies if I've overlooked some docs.
thanks, martin[/quote]
No reason to upgrade core packages generally if there are no vendor updates. There are some improvements to postgres performance in the newer releases, but nothing huge from 8.1. I would upgrade Matrix though - there are some nice new features, and some bugfixes.
Thanks Justin. Upgraded to 3.18.5 earlier this evening.
cheers, martin
One of the main selling points of an Enterprise Linux distribution, i.e. RHEL/OEL/CentOS, is that the major versions of packages do not change for the life of the release, giving you stability for 24+ months on your production server infrastructure. At the same time, bug fixes and security patches are backported by the vendor into the stable release, so there is no requirement to "roll-your-own" version of software packages in order to maintain compliance with security and audit policy.
However, particularly in Australia, I've found many external auditing companies are not aware of this backporting process, so they look purely at the major version reported by the binary to determine how up-to-date the software is. This can lead to issues where the vendor has already backported a particular security patch from a more recent version but obviously the major version has not changed. You need to make your auditors aware that you are running a fully patched Enterprise Linux distribution.
This is the key advantage of running a commercial Enterprise Linux distribution. I'm obviously biased towards Oracle Enterprise Linux, but Red Hat and SUSE are the same.