Topic: Update trying to remove Sail

[compsos]

Has anyone else been getting this?

Code: [Select]

Removing: kernel                   i686     2.6.18-348.12.1.el5       installed     49 M
 kernel-PAE               i686     2.6.18-348.12.1.el5       installed     49 M
Removing for dependencies:
 asterisk18               i386     1.8.7.0-2_centos5         installed     0.0
 asterisk18-dahdi         i386     1.8.7.0-2_centos5         installed    3.3 M
 dahdi-firmware           noarch   2.0.6-1_centos5           installed     0.0
 dahdi-linux              i686     2.8.0.1-1_centos5         installed     0.0
 kmod-dahdi-linux         i686     2.7.0-1_centos5.2.6.18_348.12.1.el5  installed     11 M
 kmod-dahdi-linux-PAE     i686     2.7.0-1_centos5.2.6.18_348.12.1.el5  installed     11 M
 kmod-dahdi-linux-fwload-vpmadt032 i686     2.7.0-1_centos5.2.6.18_348.12.1.el5 installed    217 k
 libopenr2                i386     1.2.0-1_centos5           installed    492 k
 sail                     noarch   4.0.0-103                 installed     15 M
 smesailenv               noarch   4.0.0-11                  installed     59 k
The kmods are normal but in the past asterisk, sail smesailenv were safe. On another system it was the kernel update causing the issue.

Is there a correct way to protect the Voip system? Or just separate out the kernel update and do it independently

[SARK devs]

I guess we have a couple of choices and I'd like your input.   At the moment in the rpm we have a dependency for dahdi-linux in the sail rpm.  We could just remove it and then this wouldn't happen.  However, this could lead to someone installing sail without asterisk/dahdi which could cause problems of it's own.  I'm tempted to simply remove the dependency

S

[compsos]

Hi S
I would lean towards removing the dependency.

• On one system the web page only showed about 4 updates but when started had a lot more including the removal. The list posted actually came from a server-manager update.
• If not caught then the whole PBX would need to be reinstalled and configured.
• I usually do updates from the console so I can see what is happening and can easily be stopped, if something is not quiet right. How many would do it this way I do not know.

Is there another way to warn of the missing dependency without linking to the kernel itself? Maybe a script to return the kernel updated version?

Dahdi is being quite a pain at the moment with Digium seemed to have stopped putting kmod rpms in the repository. We have resorted to compiling the source code on each PBX system. So another package handled individually is less of an evil than reinstalling the PBX. Especially if you did not notice it getting removed until too late! Automation does have draw backs sometimes.

Anything we can do to help?

[SARK devs]

OK - Concur

I will remove the dependency and cut a new release

Thanks for you help and input

S

[compsos]

This might be a solution

Code: [Select]

mkdir -p /etc/e-smith/templates-custom/etc/yum.conf/
cp /etc/e-smith/templates/etc/yum.conf/10main_installonlypkgs
nano -w /etc/e-smith/templates/etc/yum.conf/10main_installonlypkgs

add a new line with
installonly_limit=0
ctrl+o & ctrl+x

expand-template /etc/yum.conf
signal-event yum-modify
This allowed the system to update to the latest kernel and not remove the dependent kernel for sail, smesailenv or asterisk18 and packages.

Management of old kernels with this in place will have to be done by admin, but that is easier than rebuilding to whole voip system and getting dahdi back in.

[SARK devs]

Good work. I'm still going to remove the dependency anyway next time I cut a release.   Someone wants to install without dahdi being there then they can, it just won't support conference rooms or IAX2.

It has been removed in release 127, which you should get end of this week.

Best

S

[compsos]

Jeff
It not just Sail Asterisk and Kmod relationship is probably the main culprit. We have moved to compling dahdi to keep up with the kernels.

[SARK devs]

Yes indeed.  This is an issue for any asterisk install. Removing the dependency in Sail separates it from the issue.  It won't make it go away but Sail won't hamper the fix.

Best
S