Simple Hotel Style Wake-Up Calls – THE MODULE

[tshif]

Version 1.2.4 introduced a dependency on the function xml2array which doesn't appear to be on the stock PIAF builds. (I tried this on the CentOS 5.5 bits with Asterisk 1.6) I'll file a bug over on the issue tracker for it.

I'd rather not remove this dependancy if I dont HAVE to. That function has a lot of stuff we may want to use moving forward.

How hard is it to install this dependancy? Can it be done with YUM?

 

[jroper]

Hi

I've just done yum install php* and still have the same problem here - so I suspect that the positively ancient version of PHP supplied by CentOS does not support this feature.

Anyone want a PBX based on Ubuntu LTS?

Joe

 

[Bitnetix]

Centos's PHP is its weakest link. Why they continue to provide 5.1 is beyond me.

But upgrading to 5.2 is straightforward and has yet to cause us issues.

Here's what we do, unless I missed a step:

###
### Upgrading to PHP 5.2:
###
cat > /etc/yum.repos.d/CentOS-Testing.repo << EOF
# CentOS-Testing
# !!!! CAUTION !!!!
# This repository is a proving grounds for packages on their way to CentOSPlus and CentOS Extras.
# They may or may not replace core CentOS packages, and are not guaranteed to function properly.
# These packages build and install, but are waiting for feedback from testers as to
# functionality and stability. Packages in this repository will come and go during the
# development period, so it should not be left enabled or used on production systems without due
# consideration.
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
includepkgs=php*
EOF

yum upgrade
yum install php-devel
pecl channel-update pear.php.net
pecl install fileinfo

You'll need to reboot at this point.

 

[jroper]

Hi

You may have to do chown -R asterisk:asterisk /var/lib/php/session/ after this is done.

I may also be tempted with setting enabled to 0, and using the command yum --enablerepo=c5-testing install php blah blah blah

This way, it will not draw from the testing repo for any other installs and uprades.

Joe

 

[Bitnetix]

Yes, you'll need the chown. That's farther down in our installation script. Didn't catch that it was missing here. Thanks, Joe.

Also, you can do what you want with the repo being enabled/disabled. The only thing it includes is "includepkgs=php*" so in the worst case, you'll upgrade to PHP 5.3 from 5.2.

We run this once, and pretty much never touch yum again on our running boxes.

 

[tshif]

COuld the module installer be made smart enough to yum the php upgrade on its own? People should have a choice to OPT OUT of the upgrade I suppopse... Thoughts?

 

[jroper]

Hi

This is operating system level stuff, which runs as root, yes, you could add the asterisk user to the sudoers file, but in security terms, this is the stuff of nightmares. Just don't

The system would have to be prepared first, with a conscious action by Admin.

Joe

 

[tshif]

Ok - this has been added to the Wiki.

But the statement "Packages in this repository will come and go during the development period, so it should not be left enabled or used on production systems without due
consideration." suggests that this process sets up a change to yum that will leave this enabled.

What as to be done to this script fragment to disable this repository after the process is run to prevent folks from running afoul of getting other unwanted dev packages?

Feel free to make those changes directly in the Wiki - Joe and Bitnetix both have permissions there.

 

[jroper]

The includepkgs=php* line ensures that this repository is only used for PHP packages, and as my previous comment, setting enabled to 0, and using the command yum --enablerepo=c5-testing install php blah blah blah will ensure that the repository will only be used when specifically called with --enablerepo=c5-testing

So that would be a belt and braces approach

Joe

 

[Bitnetix]

The PHP 5.2 upgrade is a non-standard CentOS upgrade path. It makes use of a non-supported repository provided by Fedora downstreamed to RHEL downstreamed to Centos 5. No one really "distrusts" this repository, but it does contain things that are NOT sanctioned in CentOS 5.5 at this time.

As Joe said, having the "includepkgs=php*" in the repository configuration means that it will only upgrade PHP packages. Changing "enabled=1" to "enabled=0" would require a command line decision to enable this repository in order to perform this upgrade.

This upgrade only needs to be done once and once it's working, the repository can be ignored. So the includepkgs and enabled statements together should ensure that no one accidentally updates their PHP to 5.2 without intending to.

MEANWHILE, over in sanctioned RHEL->CentOS land, PHP or components of PHP, MAY be upgraded outside the CPEL repository listed above. So you run the risk of not being in sync with the CentOS repository when you perform this upgrade.

This is why we do this once, and a yum update once, and a bunch of other installs once, and then pretty much turn off the yum command on a working system. If it ain't broke, it don't need to be fixed in production.

 

[rossiv]

Has any progress been made on multiple wake up calls?

 

[tshif]

Nope. Wanna step up and do some coding to help get it there?

 

[rossiv]

I'm not much of a coder, but I will take a stab at it. Is all of the caller-interaction in wakeupphp in /var/lib/asterisk/agi-bin?

 

[tshif]

All the caller interactions are in the hotelwakeup/bin folder. Youll want to look into wakeconfirm and wakupphp. Best of luck in your efforts - this would be a cool addition.

 

[rossiv]

I got so far as adding option "3" to schedule a second wake up call and it makes the call file and calls like a normal call. Can delete it when it calls. Had to comment out these here to avoid deleting the 1st wake up call, but this one does not remove duplicates now either.

// Delete any old Wakeup call files this one will override 
                for ($i=0; $i < $outc; $i++ )
                {
                    if( file_exists( "$parm_call_dir/$out[$i]" ) )
                    {
                        //if ($parm_debug_on)
                        //    fputs( $stdlog, "Unlinking Old File [$parm_call_dir/$out[$i]]\n" );
                        
                        //unlink( "$parm_call_dir/$out[$i]" );
                    }
                }

Everything functions normally about the 2nd wake up call, except I have not figured out how to list it on the main "2" option delete menu. I will post my modified wakeupphp somewhere so you guys can look. Any preference?

--Edit: I've been editing /var/lib/asterisk/agi-bin/wakeupphp - is that not right?
Another semirelated note, I (not paying attention) deleted everything in my agi-bin directory. I copied all the files from a new purple incred install back to the silver. Should everything still work? If not, does anyone have a silver that would want to help me out? --Looks like I have all the files I had before, luckily Putty kept my last ls in its window so I could compare.

 

[rossiv]

For some reason, when I re-create wakeupphp, shortly after my changes are overwritten. Is there another file besides /var/lib/asterisk/agi-bin/wakeupphp?

 

[tshif]

That file is a symlink from /modules/hotelwakeup/agi-bin

You must work on it there.

 

[rossiv]

That would explain my problem - and problem solved. Right now, if multiple calls are scheduled, it says "Hello. You have requested a wake up call for XX XX AM/PM. You have requested a wake up call for XX AM/PM. That is before I changed anything. You want me to post changed code?

 

[tshif]

But you said you didnt change anything?

 

[rossiv]

Umm....I don't remember that.. But I did change stuff. I added a good bit of code.