when i run yum list | grep pear i see that php-pear 1.1.6.2 isn’t from centos. it comes from jasons repo : utterrambling which provides php 5.2.6 (centos is on 5.1.6 i think)
You might want to look in the virtualmins bleeding edge repo, i believe it has php 5.2.6 too.
I’m still trying to get to grips with the structure, so sorry for dumb questions.
I don’t know enough of the architecture of where things are and how to point to somehwre else to get the updates. I can download them and try a manual upgrade
I though it would be possible to do this via Virtualmin and the PHP Pear modules section, but the list of modules to install seems out of date.
tried to upgrade using:
pear upgrade PEAR
but this says things are out of date.
pear/Archive_Tar requires PEAR Installer (version >= 1.5.4), installed version is 1.4.9
pear/PEAR dependency package "pear/Archive_Tar" installed version 1.3.1 is not the recommended version 1.3.3, but may be compatible, use --force to install
No valid packages found
upgrade failed
not sure I want to go down the route of bleeding edge, too many risks.
While I agree with you that going down the bleeding edge path is risky, I suspect using our bleeding edge PHP packages is the least risky option you have, if you need a very recent version of PEAR.
Oh, wait…it doesn’t appear that pear is even built from the PHP src.rpm, anymore. That’s weird. But it means that php-pear is not in the bleeding edge repo, at all, right now. I’ll make sure a new version gets added, ASAP.
Joe,
thanks. if you thinks it’s ok, then I’ll give it a try. will wait for your update.
I have html emails, not with attachments or images though. have been looking inot it and I will see if I can add the code to do so, using Pear would be much easier though :o)
You could do it either way. It is slightly more complicated to do it with yum, since you’d also want to edit the .repo file and add includePkgs for just the packages you want (php-pear, in this case).
We generally disable SELinux. There are way too many little gotchas like this that pop up, at this point, even with the most relaxed standard policy, and the tools for correcting issues are still really weak. Virtualmin does have some support for adding SELinux policy, but it’s still pretty minimal, and we need to do a lot more testing on systems with various SELinux policies in place (CentOS and the latest Fedora, for example are pretty wildly divergent at this point, so we couldn’t use the same policy modifications across the two).
During install using install.sh SELinux gets disabled, and it’s still how we run on our servers.
Anyway, now that most of our supported distributions have roughly agreed that SELinux is the way forward for more advanced access control in Linux (for several years, Debian/Ubuntu and others were chasing AppArmor instead), we’ll spend some more time with it in the coming months.
