OS = CentOS.6.3 (freepbx)
Asterisk-11.3.0
FreePBX-2.11.0.0rc1.4
Most of our hosts run CentOS-6.4. The FreePBX distro is based on CentOS-6.3. There seems to be no regular updates to this distro and we are somewhat concerned in consequence.
We considering adding the CentOS repo to the FreePBX host and using yum priorities to prefer FreePBX but to take up updates from CentOS as they become available, particularly the update to 6.4 which is now several months old.
My question is simple: Will doing this blow our newly installed FreePBX system out of the water?
I would not do that. We control our repos so we can test each item. The release you are on is 3.211.63-x and that whole release track is based and tested on the 6.3 repos that we have.
Their is a 4.211.64-x track that is based on Centos 6.4
This bit in the recommended upgrade script appears a bit harsh don’t you think? Particularly since it gives no opportunity to stop at processing this point. And why the recursive delete? Yum does not descend into subdirectories in my experience.
echo
echo " Replace repos with only FreePBX Distro since some people have added other repos which can break updates"
echo " `date` Replace repos with only FreePBX Distro since some people have added other repos which can break updates" >> /var/log/pbx/upgrade/"$upgradeversion"
echo
rm -rf /etc/yum.repos.d/*
Could not the repositories be renamed rather than deleted?
Or at least have the user be prompted before the existing directory contents are permanently removed?
echo "/etc/yum.repos.d contains:"
ls -l /etc/yum.repos.d
echo ""
read -p "Remove all these files from /etc/yum.repos.d? " -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
rm -f /etc/yum.repos.d/*
else
echo "Exiting upgrade. /etc/yum.repos.d must be cleared"
echo "to proceed with the upgrade. Please move the contents"
echo "of /etc/yum.repos.d somewhere safe and try again."
exit
fi
Presumably system operators have good and sufficient reasons for installing additional repositories, some of which may have customizations made to them. I am not sure that simply blowing people's work away is at all a friendly thing for an upgrade script to do.
In any case, later in the same script I see this:
# Update all other RPM's to Centos 6.2
echo " Updating all remaining RPMS now to Centos 6.2"
echo " `date` Updating all remaining RPMS now to Centos 6.2" >> /var/log/pbx/upgrade/"$upgradeversion"
yum -y update
rm -rf /etc/yum.repos.d/Cent*
Why is this section present and where are the CentOS repo files coming from? Again I see a superfluous but potentially destructive recursive switch given to the forced remove. Why? I infer that the reference to CentOS-6.2 is simply a cut-and-paste oversight. Is this inference correct?
You’ll see the same thing with other “all-in-one” distributions such as PBX in a Flash; they like to take over the entire system. My advice – if you’re not interested in doing your own install – is to get a virtual machine set up and try the upgrade yourself. Test extensively, but chances are it won’t break anything. I used PiaF as a base install, but have never run any of their update scripts or anything like that.
I selected FreePBX because it was based on CentOS-6.3 and as this (VOIP) was a new endeavour I conjectured that at least having a familiar base OS would be worth having. I usually build hosts starting with a minimal install of CentOS and then add in things as the need becomes apparent.
As the setup I have is essentially a crash and burn unit until we go live I will experiment with updating directly from the CentOS repos and report what I encounter.
Ok well you have been warned. Something as simple as the kernel upgrade will break things like dahdi and other items that are kernel dependent. If you decide to use your own repos they are at your own risk. We choose to blow off all other repos to make sure the scripts dont upgrade RPMs that are not in our repos. Its all about safety for the average user. Advanced users can not use the scripts or build their own ISOs.
And I believe that I comprehend your point about controlling the packages in a turnkey solution. No argument about that.
That said, there are a lot of non-kernel packages (188 as of this morning) installed on FreePBX that in the CentOS base distribution require patches that FreePBX has not yet made available. And that is a concern of mine. Specifically, this unreleased update https://rhn.redhat.com/errata/RHSA-2013-0772.html.
I am perfectly willing to use exclude= in the config files to eliminate kernel updates. Presumably anything dependent upon a specific kernel in FreePBX would then be left alone. Are there other, non-kernel related package changes of which I should be aware?
Regardless of what I choose to do or not do with respect to these updates, it still seems to me to be a questionable behaviour to have an upgrade script unilaterally and irrecoverably destroy the contents of a system configuration directory without providing reasonable notice. In other words while the delete action can still be forestalled and not simply dropping a line to the effect of: “Oh, by the way, we just deleted everything in this directory. Hope you had nothing of importance in there.”
I have to offer my opinion. This is a phone system, it’s not an application you install on your own server.
If you want to try and roll your own I suggest you do it from the beginning on your own OS and configure the repo’s and manage your own security policies.
The distro is designed to be a specific function inside a private network SQL vulnerabilities are meaningless to us since we only allow SQL from localhost.
As an example, Cisco doesn’t issue OS patches for the Linux that is underneath CUCM.
If you need the granularity you are expressing I suggest you roll your own system as the developers goals and policies are going to conflict with your own.