php,httpd upgrade

i was wondering when a php upgrade will be available (5.2.x). Also, i noticed that yum has an upgrade for httpd that doesn’t appear in Virtualmin.
Installed version (rpm -qi httpd)

Version : 2.2.3 Vendor: (none)
Release : 7el5.2vm Build Date: Tue 23 Oct 2007 09:35:18

yum upgrade founds:
httpd x86_64 1:2.2.3-11.el5.3vm virtualmin 2.7 M

plus updates to httpd_manual, kernel, initscripts, and mod_ssl

Are these updates safe to install with yum? and if they are, why they don’t appear in Virtualmin.

i was wondering when a php upgrade will be available (5.2.x).

That’s not how it works. We don’t randomly replace packages provided by your OS by versions we like better. See the FAQ:

http://www.virtualmin.com/component/option,com_openwiki/Itemid,48/id,frequently_asked_questions/#when_i_installed_virtualmin_professional_an_old_version_of_mysql_php_apache_dovecot_etc._was_installed._what_s_going_on

That said, for CentOS 5 we do provide a bleeding edge repository that has 5.2.8. We don’t recommend it, but it’s better to use our packages (which are based very closely on the OS standard packages) than random packages you find on the Internet.

http://www.virtualmin.com/component/option,com_openwiki/Itemid,48/id,php_and_virtualmin/#bleeding_edge_php_packages

Are these updates safe to install with yum?

httpd and mod_ssl should be. I’m surprised it doesn’t appear in the Virtualmin package updates module. Sounds like maybe a bug.

kernel and initscripts are not something we touch. We do recommend you run the latest OS-provided versions of everything on your system, whenever possible, for security and stability reasons. Upgrading the kernel is somewhat dramatic, however, and requires a reboot, so should be planned for.

We’ve been hesitant to have the Virtualmin package updates module list non-hosting related packages, because people seem to assume that everything that appears there is “approved” or “recommended” by us…and when something goes wrong, we catch the blame, no matter where the package came from, or if the user is even using our recommended best practices with regard to package sources and such. (You’d be amazed at the amount of flak we catch over packages installed from non-OS sources that we have no control over, and that we explicitly recommend against.)