Do I delete virtualmin-bleed.repo after upgrading PHP to 5.2.17

I have fresh installed Virtualmin on CentOS release 5.8 (Final) and it came with PHP 5.1.6 and it was must for me to have higher version of PHP. So after reading,php_and_virtualmin/#bleeding_edge_php_packages and,virtualmin_bleeding_edge_packages, I have successfully upgraded PHP to PHP 5.2.17.

Now considering several warnings from Virtualmin documentation pages like “We do not recommend using third party packages, including ours, unless you must have the bleeding edge versions of the provided packages. They are very likely not as stable or reliable as packages provided by the RHEL OS repository.” should I delete “virtualmin-bleed.repo” from repo list or it needs to be there for the system to function properly?


It doesn’t need to be there… and a lot of folks do disable it until there’s something else that they want from that repo.

If you didn’t need it – I’d suggest disabling it rather than deleting it though. You can do that by setting “enabled=0” in the .repo file.


Thanks Eric for the suggestion. As always you are completely right - why to delete when I can only disable!

PHP 5.2.17 is over a year old, and is end of life. Do your applications work with PHP 5.3.3? There is a php53 package supplied by redhat/centos that will be kept up to date security wise.

I know that, but for some reason script of Virtualmin installs even older version of PHP. And I need 5.2.17 for specific reason - trying to integrate Virtualmin with Ubersmith and Ubersmith reqyures 5.2 series. I tried to it install on 5.3.3, unfirtunately, it did not go well.


Just to clarify – the default PHP version on CentOS 5 is PHP 5.1.6 – that’s what you’re seeing on a new CentOS 5 install.

So the options for getting a newer PHP version are to either use the version in the bleed repo, or to use the PHP 5.3 version available in the php53 package.

The Ubersmith system requirements suggest that it works with PHP 5.3 – if you’re interested in using that version, feel free to post about the problems you’re having. Some PHP compatibility issues can be resolved by setting cgi.fix_pathinfo to “0” in $HOME/etc/php.ini.

If that doesn’t help, you could also try using mod_php instead of FCGI or CGI.



Thank you very much for your time and always readiness to help. But I had mentioned in the very beginning that

I have successfully upgraded PHP to PHP 5.2.17.
. In my previous post, which has not been approved yet for some reason, I was replying to Ip86.