ViciBox Cluster no update/connection to Telephony Server

[inthegenes]

Let me just say I am delighted to be using VICIdial again. Love the additions in version 4.

I am however having an issue with getting my DB/Web server connected to my Telephony Server in my cluster config.

Here is my build.
The DB/Web Server is a Dell 2950 Dual Quad Core server with 8GB of RAM, 146GB SAS drives, Raid 1.
The OS was installed using the ViciBox 4.0.3 preload iso. We ran into an issue installing the Telephony Server however (no CD drive) and had to do a scratch install. We couldn't get the ViciBox iso to install via flash (issue with kiwi boot loader) so we installed OpenSUSE 11.4 and used the vici-install-11.1.sh script (after updating the repository links from 11.1 to 11.4). The Telephony server is a Super Micro Dual Quad Core blade server with 16 GB RAM, 160 SATA drives, Raid 1.

[quote]DB Server Specs:
OpenSuSE v.12.1 64-bit
Kernel v.3.1.10-1.16
Asterisk v.1.4.44-vici
DAHDI v.2.6.1
LibPRI v.1.4.12
Sangoma Wanpipe v.3.5.28
Amfletec VoiceSync v.1.3.0.1
OpenR2 v.1.3.2 for MFC/R2 support
ViciDial SVN Trunk v.2.6-375a build 120831-1523 revision 1858
etc.

uname -a => Linux Vici-DB1 3.1.10-1.16-default #1 SMP Wed Jun 27 05:21:40 UTC 2012 (d016078) x86_64 x86_64 x86_64 GNU/Linux[/quote]

Telphony server specs:
[quote]OpenSuSE v.11.4 64-bit
Asterisk v. 1.4.21.2-vici
DAHDI v.2.5.1
LibPRI v.1.4.12

uname -a => Linux Vici-Dial1 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 x86_64 x86_64 x86_64 GNU/Linux[/quote]

We ran through the installation for the DB using the vicibox-install command with no issue. Everything is up and running fine, I can log into the GUI etc. Everything is being saved to the DB, the works.

For the Telephony server I got the vici-install-11.1.sh script to work after a few minor tweaks. Asterisk is installed and can run independently. The right parameters are set for the server to act solely as a Telephony/Agent server during the install, write to server is select in the GUI. At first everything seems fine if I start Asterisk using the command asterisk. But nothing is being written to the configuration files, the sip-vicidial.conf file remains empty after adding phones in the GUI.
After searching the forum quite a bit I stumbled upon a post where Matt explained how the update process works and that the start_asterisk_boot.pl script has to be used for the configuration files to be written. However, when I run the start script I get the following output:

[quote]started screen
changed directory
started new screen session
detached screens
raised ulimit open files
Asterisk started... screen logging on[/quote]

But Asterisk does not start and the following error messages are found in /var/spool/mail/root

[quote]From root@linux.local Tue Mar 26 19:00:01 2013
Return-Path: <root@linux.local>
X-Original-To: root
Delivered-To: root@linux.local
Received: by linux.local (Postfix, from userid 0)
id D8E5728731; Tue, 26 Mar 2013 19:00:01 -0400 (EDT)
From: root@linux.local (Cron Daemon)
To: root@linux.local
Subject: Cron <root@Vici-Dial1> /usr/share/astguiclient/AST_vm_update.pl
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20130326230001.D8E5728731@linux.local>
Date: Tue, 26 Mar 2013 19:00:01 -0400 (EDT)

problem connecting to "localhost", port 5038: Connection refused at /usr/share/astguiclient/AST_vm_update.pl line 177

From root@linux.local Tue Mar 26 19:00:03 2013
Return-Path: <root@linux.local>
X-Original-To: root
Delivered-To: root@linux.local
Received: by linux.local (Postfix, from userid 0)
id F3EE722974; Tue, 26 Mar 2013 19:00:01 -0400 (EDT)
From: root@linux.local (Cron Daemon)
To: root@linux.local
Subject: Cron <root@Vici-Dial1> /usr/share/astguiclient/AST_conf_update.pl
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20130326230001.F3EE722974@linux.local>
Date: Tue, 26 Mar 2013 19:00:01 -0400 (EDT)

problem connecting to "localhost", port 5038: Connection refused at /usr/share/astguiclient/AST_conf_update.pl line 258[/quote]

I've re-run the installation for both the SQL and the Telephony server and tinkered quite a bit, quite a few times but to no avail.

The errors point to an attempt to telnet into the Asterisk manager. Is the request suppose to be sent to the localhost on the Telephony server or to the manager on the DB?

[quote] ### connect to asterisk manager through telnet
$t = new Net::Telnet (Port => $telnet_port,
Prompt => '/.*[\$%#>] $/',
Output_record_separator => '',);
#$fh = $t->dump_log("$telnetlog"); # uncomment for telnet log
if (length($ASTmgrUSERNAMEsend) > 3) {$telnet_login = $ASTmgrUSERNAMEsend;}
else {$telnet_login = $ASTmgrUSERNAME;}

[u] $t->open("$telnet_host");[/u]
$t->waitfor('/[01]\n$/'); # print login
$t->print("Action: Login\nUsername: $telnet_login\nSecret: $ASTmgrSECRET\n\n");
$t->waitfor('/Authentication accepted/'); [/quote]

Here are the config files that would be related to the connection between both servers:

DB server:

astguiclient.conf
[quote]# Paths used by astGUIclient
PATHhome => /usr/share/astguiclient
PATHlogs => /var/log/astguiclient
PATHagi => /var/lib/asterisk/agi-bin
PATHweb => /srv/www/htdocs
PATHsounds => /var/lib/asterisk/sounds
PATHmonitor => /var/spool/asterisk/monitor
PATHDONEmonitor => /var/spool/asterisk/monitorDONE

# The IP address of this machine
VARserver_ip => 172.16.1.46

# Database connection information
VARDB_server => localhost
VARDB_database => asterisk
VARDB_user => cron
VARDB_pass => 1234
VARDB_custom_user => custom
VARDB_custom_pass => custom1234
VARDB_port => 3306[/quote]

manager.conf
[quote][general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0

[cron]
secret = 1234
read = system,call,log,verbose,command,agent,user
write = system,call,log,verbose,command,agent,user

[updatecron]
secret = 1234
read = command
write = command

[listencron]
secret = 1234
read = system,call,log,verbose,command,agent,user
write = command

[sendcron]
secret = 1234
read = command
write = system,call,log,verbose,command,agent,user[/quote]

Telephony Server:

astguiclient.conf
[quote]# Paths used by astGUIclient
PATHhome => /usr/share/astguiclient
PATHlogs => /var/log/astguiclient
PATHagi => /var/lib/asterisk/agi-bin
PATHweb => /srv/www/htdocs
PATHsounds => /var/lib/asterisk/sounds
PATHmonitor => /var/spool/asterisk/monitor
PATHDONEmonitor => /var/spool/asterisk/monitorDONE

# The IP address of this machine
VARserver_ip => 172.16.1.44

# Database connection information
VARDB_server => 172.16.1.46
VARDB_database => asterisk
VARDB_user => cron
VARDB_pass => 1234
VARDB_custom_user => custom
VARDB_custom_pass => custom1234
VARDB_port => 3306[/quote]

manager.conf
[quote][general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0

[cron]
secret = 1234
read = system,call,log,verbose,command,agent,user
write = system,call,log,verbose,command,agent,user

[updatecron]
secret = 1234
read = command
write = command

[listencron]
secret = 1234
read = system,call,log,verbose,command,agent,user
write = command

[sendcron]
secret = 1234
read = command
write = system,call,log,verbose,command,agent,user[/quote]

I am at my wits end, the servers are located at a COLO location so I only have remote access. I have another ViciBox installation locally that has the Preloaded iso on it. I am going to try to connect to the DB using that server and see if I can compare the configuration between the local Telephony and the remote Telephony server. But I am not sure what that would accomplish since the configuration files look correct.

Can anyone point me in the right direction as to what the issue could be?

Thank you

[williamconley]

problem connecting to "localhost", port 5038: Connection refused at /usr/share/astguiclient/AST_conf_update.pl line 258

Turn off the firewall on the machine and see if that allows a connection. This is your "error", so you'll have to attack it directly to see why the connection is being refused.

You are not having a problem with clustering, your server is simply non-functional at this point. You may want to consider a different OS, however, as this particular distro has never had Vicidial installed as far as I know. Gardo has good instructions for CentOS, Ubuntu is nice, and OpenSuSE has been used for 11.1,11.3 and I think is now in 12.1. So you may want to try an OS that is already in use, which may save a few headaches. Not saying it "won't" work, just that using an OS that's already tested may save some headaches (and may, in fact, be related ...).

Have you considered a colo that will install Vicidial for you?

[inthegenes]

The firewall is off on both servers via the install script. And there is no sign of apparmor running. And yes this is the error causing my system to be non-functional.

I went with OpenSUSE because that's what ViciBox uses and because I didn't want to have a OpenSUSE Ubuntu Vici cluster. I successfully built a Ubuntu vicibox from scratch locally before trying the OpenSUSE. Guess I should have stayed with it instead of opting for the OpenSUSE OS.

The colo will install but it is at a cost...

Is there anything else that I could do to troubleshoot the issue. It seems fairly simple on the surface but I have run out of ideas.

[williamconley]

First build the server as a standalone, and you will likely find that the challenge is not related to clustering. A dialer that cannot communicate with itself on the asterisk manager interface port cannot be used in a cluster.

And I wasn't knocking OpenSuSE, just stating that the version you chose is not a known compatible one ... so you may have some challenges in underlying package interference with "unpredictable" results (like ... no communications on the asterisk manager port? LOL).

If asterisk does not start, for instance, there will be no communication on that port. In which case, you need to find the error when asterisk fails (unless you just forgot to start it ...) in an asterisk log or perhaps by "asterisk -vvvvc" and see what "dies" during the attempted startup.

On the other hand, if you DO have a good Ubuntu install, I'd jump back to that if I were you. No reason to reinvent the wheel if you already reinvented it before ... LOL.

[inthegenes]

The asterisk start only fails when the start_asterisk_boot.pl script is used. Asterisk can start on its own, "asterisk -vvvvc" does not show any errors. But if started via "asterisk" the configuration files are not being written.

The Ubuntu install was a standalone, the clustering was not attempted. And the Ubuntu install was local not at the colo.

Based on the limited capacity of a standalone we are opting for a cluster.

[williamconley]

Ok, one point at a time ... LOL

Obviously it is time to disassemble the asterisk boot pl script and execute the commands one at a time to find where it dies.

Ubuntu being standalone does not mean it cannot be clustered after being certified functional. http://www.poundteam.com/downloads/Vici ... v1%201.pdf

If you are installing a single server in the colo, it will also be a "standalone" as you cannot cluster across physical distances. A cluster must be in a single location.

Of course, the only real reason for using a Colo is because you do not have enough bandwidth ... with the minor exception of those who simply do not want their own IT department at all. We have a few of those as well. We actually also have a few that simply want to know that WE will be there if there is a problem with the hardware/software/OS to make it work ASAP. No worries is worth money to a solid, long-running call center.

Happy Hunting!

PS: When we lease a Vicidial server to a client, we install Any version of Vicidial (any SVN revision level or Vicibox/Goautodial/GnuDial release). We don't charge for the install of each server, but we do charge to cluster them. And we have no setup fee. Purely month-to-month. Root access is even available if you are prepared to accept responsibility for the OS/software health of the box. But if you leave us in charge of the OS/software ... you are left with pure Vicidial "ready-to-go" with no worries.

I say this because we are actively looking for call centers to test GnuDial (Vicidial on Ubuntu 12.04 LTS) at present. Perhaps even a serious discount on Monthly Lease ...

[inthegenes]

I am upgrading the OS from OpenSUSE 11.4 12.1, hopefully it will work after that. I opted for 11.4 because the only scratch install scripts I could find where for Ubuntu 8 and OpenSUSE 11.1

Plus, as mentioned before the DB server (which is located at the colo) is an OpenSUSE.

Our reasons for using a colo are a bit different but can be categorized as a bandwidth reason.

[williamconley]

Yep, SuSE 11.1,11.3 and 12.1 are known to work with Vicidial. But if you experience "issues" with 12.1, you can install Vicibox 4.0.3 in a Virtual machine and compare it to your hosted server's OS since that will also be 12.1. Comparison may make life a bit easier. You could also consider trying to talk the Colo into using the Vicibox 4.0.3 .iso, since it is a SuSEStudio install .iso ... pretty plain OpenSuSE install ...

[inthegenes]

Ok William,

I took your advice and upgraded the server to OpenSUSE 12.1, the only thing is that its the desktop version and not the server version (didn't upgrade when I used the yast software manager? so I ran the install script with the desktop kernel).


uname -a
Linux Vici-Dial1 3.1.10-106-desktop #1 SMP PREEMPT Mon Mar 25 15:26:10 UTC 2013 (83a27d3) x86_64 x86_64 x86_64 GNU/Linux

As before Asterisk starts ok, but not when using the start_asterisk_boot.pl script. Telnet error again. I got this error message previously and installed the Telnet application, I am guessing if I install it again I will be in the same boat. Perhaps all I need to do is configure telnet correctly.

From root@linux.local Wed Mar 27 19:48:01 2013
Return-Path: <root@linux.local>
X-Original-To: root
Delivered-To: root@linux.local
Received: by linux.local (Postfix, from userid 0)
id A9ECD23DC3; Wed, 27 Mar 2013 19:48:01 -0400 (EDT)
From: root@linux.local (Cron Daemon)
To: root@linux.local
Subject: Cron <root@Vici-Dial1> /usr/share/astguiclient/AST_conf_update.pl
Content-Type: text/plain; charset=UTF-8
Auto-Submitted: auto-generated
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20130327234801.A9ECD23DC3@linux.local>
Date: Wed, 27 Mar 2013 19:48:01 -0400 (EDT)

Can't locate Net/Telnet.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl .) at /usr/share/astguiclient/AST_conf_update.pl line 117.
BEGIN failed--compilation aborted at /usr/share/astguiclient/AST_conf_update.pl line 117.

I am still working on getting a ViciBox installed to compare.

When we attempted to install the ViciBox iso at the Colo it didn't work. The Kiwi bootloader had some form of error, the Vicibox preload iso wouldn't work off a flash drive, but the Kiwi bootloader from a OpenSuse iso did work from the flash. Hence the current quandary...

[williamconley]

you have your cart before your horse. if asterisk is running, it is possible the telnet error will go away. But without asterisk running, it is impossible, since the port is not being listened to by the asteriskmanager interface.

so you'll have to disassemble the start asterisk boot and run it line by line to find the error so you can get asterisk to start in it's "screen" with everything else. that screen is an essential part of the asterisk management of Vicidial.

I'd probably just switch back to ubuntu, though, if I were you ... or convince the colo to use a USB CD drive for the .iso installation.

[inthegenes]

Ok,

It works when you run through the script step by step. To use the script I had to manually close/quit all the screens that were open using, "screen -S 23536.aster2323525 -X quit" and then run the start_asterisk_boot script. When I did that the script worked without any issues.

Only two items remain to be rid of this headache;

For some reason the script is starting twice the screens necessary. Perhaps the if statement in the script is working?
There are screens on:
9771.ASTVDremote (Detached)
9767.ASTVDremote (Detached)
9763.ASTVDauto (Detached)
9761.ASTVDauto (Detached)
9755.ASTlisten (Detached)
9752.ASTsend (Detached)
9748.ASTsend (Detached)
9746.ASTupdate (Detached)
9743.ASTupdate (Detached)
9607.asterisk (Detached)
9588.astshell20130328234843 (Detached)
11 Sockets in /var/run/screens/S-root.

Two, what is the proper procedure for starting and stopping Asterisk/VICIdial? Do I have to manually quit every screen if I need to restart Asterisk?

Thanks for your help so far William. You have brought sanity to a month's worth of testing.

[inthegenes]

Not out of the woods as yet.

I have single scripts now:
Vici-Dial1:/etc/asterisk # screen -ls
There are screens on:
4909.ASTVDremote (Detached)
4906.ASTVDauto (Detached)
4903.ASTlisten (Detached)
4900.ASTsend (Detached)
4897.ASTupdate (Detached)
4659.asterisk (Detached)
4580.astshell20130329162131 (Detached)
4560.astershell20130329162131 (Detached)
8 Sockets in /var/run/screens/S-root.

However if I try to log into a conference and or agent session, or even after a test call to the moh class I get the following message;

Vici-Dial1*CLI> originate SIP/2990 extension 8302@default
[Mar 29 16:52:28] -- Executing [8302@default:1] Answer("SIP/2990-74000fb0", "") in new stack
[Mar 29 16:52:28] -- Executing [8302@default:2] Playback("SIP/2990-74000fb0", "conf") in new stack
[Mar 29 16:52:28] -- <SIP/2990-74000fb0> Playing 'conf' (language 'en')
[Mar 29 16:52:50] == Spawn extension (default, 8302, 2) exited non-zero on 'SIP/2990-74000fb0'
[Mar 29 16:52:50] -- Executing [h@default:1] DeadAGI("SIP/2990-74000fb0", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Mar 29 16:52:50] WARNING[4982]: res_agi.c:241 launch_netscript: Connect to 'agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------' failed: Connection refused
[Mar 29 16:53:01] == Parsing '/etc/asterisk/manager.conf': [Mar 29 16:53:01] Found
[Mar 29 16:53:01] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 29 16:53:01] == Parsing '/etc/asterisk/manager.conf': [Mar 29 16:53:01] Found
[Mar 29 16:53:01] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 29 16:53:01] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 29 16:53:02] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 29 16:53:06] == Parsing '/etc/asterisk/manager.conf': [Mar 29 16:53:06] Found
[Mar 29 16:53:06] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 29 16:53:06] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 29 16:53:15] == Parsing '/etc/asterisk/manager.conf': [Mar 29 16:53:15] Found
[Mar 29 16:53:15] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 29 16:53:17] > Channel SIP/2990-880021b0 was answered.
[Mar 29 16:53:17] == Starting SIP/2990-880021b0 at default,,1 failed so falling back to exten 's'
[Mar 29 16:53:17] == Starting SIP/2990-880021b0 at default,s,1 still failed so falling back to context 'default'
[Mar 29 16:53:17] -- Sent into invalid extension 's' in context 'default' on SIP/2990-880021b0
[Mar 29 16:53:17] -- Executing [i@default:1] Playback("SIP/2990-880021b0", "invalid") in new stack
[Mar 29 16:53:17] -- <SIP/2990-880021b0> Playing 'invalid' (language 'en')
[Mar 29 16:53:19] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 29 16:53:21] == Auto fallthrough, channel 'SIP/2990-880021b0' status is 'UNKNOWN'
[Mar 29 16:53:21] -- Executing [h@default:1] DeadAGI("SIP/2990-880021b0", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Mar 29 16:53:21] WARNING[5114]: res_agi.c:241 launch_netscript: Connect to 'agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------' failed: Connection refused

The agent login fails with the following message; "Sorry, there are no available sessions" and the audio response from the extension is "I am sorry that is not a valid extension."

[williamconley]

is dahdi loaded? do meetme rooms work? is the script listening on port 4577 operational? if meetme rooms do work, are the meetme rooms built?

you are in scratch install mode. one piece at a time you have to go through and fix every single cotton pickin item. LOL

[inthegenes]

Dahdi is installed dahdi_test works. But it's not installed as a module in Asterisk...

I will check the other points and get back to you.

Really appreciate the help!

[inthegenes]

Ok William,

I found another post on the forum that you made in regards to reinstalling libpri, dahdi and asterisk to resolve the Dahdi issue. I did that and now Dahdi appears as a module in Asterisk.

My meetme rooms are not working. I have two boxes connected to the DB. The ViciBox built with the preload iso for testing has somehow grabbed all of the meetme rooms. They all bear it's IP address on the web GUI (Admin -> Conference). If I try to modify a conference and change the IP address it only duplicates the conference room, both still bear the preload's IP address. If I try to modify a VICIdial conference it doesn't duplicate it but it doesn't change the IP address. If I manually create a conference or a VICIdial conference, they are automatically loaded into the box (after a minute) but they are not recognized as an extension.

CLI for dialing a VICIdial conference:
[Apr 1 07:45:45] -- <SIP/2991-00000002> Playing 'conf' (language 'en')
[Apr 1 07:45:50] == Spawn extension (default, 8302, 2) exited non-zero on 'SIP/2991-00000002'
[Apr 1 07:45:50] -- Executing [h@default:1] DeadAGI("SIP/2991-00000002", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Apr 1 07:45:50] ERROR[589]: utils.c:968 ast_carefulwrite: write() returned error: Connection refused
[Apr 1 07:45:50] WARNING[589]: res_agi.c:238 launch_netscript: Connect to 'agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------' failed: Connection refused
[Apr 1 07:45:58] -- Executing [8600051@default:1] MeetMe("SIP/2991-00000003", "8600051|F") in new stack
[Apr 1 07:45:58] == Parsing '/etc/asterisk/meetme.conf': [Apr 1 07:45:58] Found
[Apr 1 07:45:58] == Parsing '/etc/asterisk/meetme-vicidial.conf': [Apr 1 07:45:58] Found
[Apr 1 07:45:58] -- <SIP/2991-00000003> Playing 'conf-invalid' (language 'en')
[Apr 1 07:46:02] == Parsing '/etc/asterisk/manager.conf': [Apr 1 07:46:02] Found
[Apr 1 07:46:02] == Manager 'sendcron' logged on from 127.0.0.1
[Apr 1 07:46:02] == Parsing '/etc/asterisk/manager.conf': [Apr 1 07:46:02] Found
[Apr 1 07:46:02] == Manager 'sendcron' logged on from 127.0.0.1
[Apr 1 07:46:02] == Manager 'sendcron' logged off from 127.0.0.1
[Apr 1 07:46:02] == Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/2991-00000003'
[Apr 1 07:46:02] -- Executing [h@default:1] DeadAGI("SIP/2991-00000003", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Apr 1 07:46:02] ERROR[617]: utils.c:968 ast_carefulwrite: write() returned error: Connection refused
[Apr 1 07:46:02] WARNING[617]: res_agi.c:238 launch_netscript: Connect to 'agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------' failed: Connection refused


Conference that I created:
[Apr 1 07:47:41] NOTICE[28961]: chan_sip.c:15765 handle_request_invite: Call from '2991' to extension '9688000' rejected because extension not found.

Admin -> Conferences -> Show VICIdial Conferences
8600298 172.18.0.250 MODIFY
8600299 172.18.0.250 MODIFY
9687000 172.16.1.44 MODIFY

scratch install box - meetme-vicidial.conf
; ViciDial Conferences:
conf => 9687000

; Conferences:
conf => 9688000

The standard conferences (86XXXXX ) can be found in the meetme-vicidial.conf file of the test box.

I am still combing the forum posts. What do you suggest I do to resolve the meetme rooms? And how do I test if the script listening on 4577 is operational?

Thanks in advance.

[williamconley]

best advice: install a cluster on a virtual server pair via vicibox 4.0.X .iso. Then you can compare your settings to see your flaw.

for dahdi installation, you are restricted to direct interaction with the OS, but for vicidial configuration you could literally steal it from a virtual server configuration file and/or database to make it work. so let Kumba's installer do all the work for your cluster, and then steal the database and .conf files to transplant them into your hosted server. just remember that the IP addresses must match OR you must run the ip update script to make them match after the transplant.

as long as you install the same revision level as the one you have, the files and database can just be copied over top of the old ones (for the DB, you drop database asterisk, then create database asterisk, then load the transplanted data in from a mysqldump on the donating server). the beauty of "device independent software" such as php/perl/asterisk.

you can use tools to check for ports with listeners on both installs, plus checking for how many screens and what is in each one. compare crontab entries. virtual servers are excellent tools for this. just remember: virtual servers are only good for one or two calls at a time. perfect for testing. not good for production at all.

[inthegenes]

Wasn't the response and or answer I was looking for

The problem seems to be related to FastAGI_log.pl, it won't execute:
Can't locate Net/Server.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl .) at ./FastAGI_log.pl line 160.
BEGIN failed--compilation aborted at ./FastAGI_log.pl line 160.

Seeing as though I received a similar error with telnet I am figuring the AGI is not being run correctly in the necessary screen. The ASTfastlog screen is not running.

I was hoping to not have to start over again... I have a test machine and a production server. So I may take your advice and copy the configs from the test server, pull it from the DB and then use those files with the production server But it seems a bit iffy to me, sounds like a move one would make in desperation. I not quite there as yet, I still believe the issue(s) can be resolved.

[inthegenes]

I am getting there!

I resolved the AGI issue by following some pointers on a scratch installation post online;
http://shirker.blog.com/2011/09/19/180/

It seems as if the previous error with Net::Telnet [b]was[/b] solved by installing the CPAN module. I went ahead, followed the instructions and installed a slew of CPAN modules including the one that was causing the FastAGI error, Net::Server. Reboot, no more FastAGI error. The ASTfastlog screen now presents itself when I hit the screen -ls.

I then followed the instructions on a VICIbox cluster installation pdf by PoundTeam (http://www.poundteam.com/downloads/Vici ... Latest.pdf) to try and smooth out any other rough edges. Namely the missing MeetMe room configuration on the box. Copied them over from the test box using mysql as per PoundTeam instruction, and I can now successfully call a MeetMe room!

-- Executing [8600051@default:1] MeetMe("SIP/2991-00000003", "8600051|F") in new stack
[Apr 2 17:52:26] == Parsing '/etc/asterisk/meetme.conf': [Apr 2 17:52:26] Found
[Apr 2 17:52:26] == Parsing '/etc/asterisk/meetme-vicidial.conf': [Apr 2 17:52:26] Found
[Apr 2 17:52:26] -- Created MeetMe conference 1023 for conference '8600051'
[Apr 2 17:52:26] -- <SIP/2991-00000003> Playing 'conf-onlyperson' (language 'en')
[Apr 2 17:52:36] -- Hungup 'DAHDI/pseudo-1790583063'
[Apr 2 17:52:36] == Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/2991-00000003'
[Apr 2 17:52:36] -- Executing [h@default:1] DeadAGI("SIP/2991-00000003", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0---------------") in new stack
[Apr 2 17:52:36] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0

Logged into agent interface, made successful manual ratio calls. Only inbound calls left to test.


I did notice one error however that I am sure is not atypical. When my carrier was configured incorrectly and the call would not terminate (could not identify global string, working config - dial via IP address) I got a string of these warnings:

[Apr 2 17:41:40] WARNING[14970]: app_meetme.c:2474 conf_run: Unable to write frame to channel Local/8600051@default-97dc,2
[Apr 2 17:41:40] WARNING[14970]: app_meetme.c:2474 conf_run: Unable to write frame to channel Local/8600051@default-97dc,2
[Apr 2 17:41:40] WARNING[14970]: app_meetme.c:2474 conf_run: Unable to write frame to channel Local/8600051@default-97dc,2
[Apr 2 17:41:40] WARNING[14970]: app_meetme.c:2474 conf_run: Unable to write frame to channel Local/8600051@default-97dc,2
[Apr 2 17:41:40] WARNING[14970]: app_meetme.c:2474 conf_run: Unable to write frame to channel Local/8600051@default-97dc,2

Then when I log out of the agent session it suddenly didn'tt know the MeetMe conference number;
[Apr 2 17:52:09] -- Executing [55558600051@default:1] MeetMeAdmin("Local/55558600051@default-0660,2", "8600051|K") in new stack
[Apr 2 17:52:09] WARNING[17270]: app_meetme.c:3145 admin_exec: Conference number '8600051' not found!
[Apr 2 17:52:09] -- Executing [55558600051@default:2] Hangup("Local/55558600051@default-0660,2", "") in new stack
[Apr 2 17:52:09] == Spawn extension (default, 55558600051, 2) exited non-zero on 'Local/55558600051@default-0660,2'
[Apr 2 17:52:09] -- Executing [h@default:1] DeadAGI("Local/55558600051@default-0660,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Apr 2 17:52:09] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0

This will be a production box so I will need to have it as clean as possible. Any pointers?

[williamconley]

one of your biggest problems with an installation like this is what happens if you have a "fail" on a Hard drive during a workday. If you are afraid of the "reinstall", you could well have the worst day of your life in the event of a drive failure while trying to re-install so you can restore the DB on a running system ... only you can't reinstall because your install was "unusual" and in the end not well documented.

you should reinstall several times.

preaching session over.

when perl claims it cannot find a file or module to execute, you must install that module/file. you'll need to go over your perl and CPAN installation and be sure you have installed all the necessary modules.

by this i do NOT mean "executed the lines that install them", but rather "INSTALL" them. ie: check for errors! don't fire it off and look away. if you simply go back and reinstall perl and all cpan modules, you should find which one refuses to install. and then find out why ... and Make it install (somehow ... find the dependency that is missing or whatever the problem is). if you are not sure where to begin, try starting at line 160 of fastagi and see what is trying to happen ... and perform that task manually with debugging a full.

i will say that this is still OS based stuff. your "install" is not complete and as such a copy from another machine will not likely work. without all the perl/php/etc modules in place, the system won't run or at least won't run properly.

[inthegenes]

Looks like you didn't see my reply, 5:11pm versus 5:13pm.

I resolved the errors prohibiting the box from logging in and dialing out.

I did glean something from the post however, I will have to duplicate the installation or make the necessary preparations to have the box rebuilt when we are next scheduled to visit the COLO. That way I avoid any 'worst day' scenarios, I haven't had one this year I would like to get through the year without one

So I will re-install several times in a test environment and document the installation, just in case the worst happens sooner than our next scheduled visit.

As my previous post indicates I went through and installed every perl/CPAN module, resolving any errors that came up during each installation.

Please see my previous post however in regards to a MeetMe room error that surfaced when my carrier was configured incorrectly.

Cheers and many thanks