If you are using the password option for the tentacle protocol then you must also add the password to the TENTACLE_EXT_OPTS in the /etc/init.d/tentacle_serverd file e.g.
TENTACLE_EXT_OPTS=”-x YOURAGENTPASSWORD …
If you do not do this then if you are using the agent password option then no agent data will be logged.
This is not a very secure way of data logging.
This was a painless upgrade but I found two quirks,
1) when you edit your config.php then you must set the chmod permissions to 600. If you try 400 then the Pandora Console still thinks that the file is readable by others. Obviously a bug but nothing to worry about. Note that to edit the ./include/config.php you must copy the new version 5 ./include/config.inc.php to ./include/config.php and then edit that new config.php and copy and paste in your custom settings from your old version 4 config.php file.
2) The ./extras/pandoradb_migrate_4.0.x_to_5.0.mysql.sql (and actually any of those migration files) is missing a schema change to the tagente_estado table. It has,
ALTER TABLE `tagente_estado` ADD COLUMN `last_known_status` tinyint(4) NOT NULL DEFAULT 0;
but ALSO needs to have,
ALTER TABLE `tagente_estado` ADD COLUMN `last_error` tinyint(4) NOT NULL DEFAULT 0;
else the pandora_server won’t start.
I was converting my Asterisk commands to the closest equivalent FreeSWITCH command so I could display the data in the FMS Pandora Console. Nothing fancy here – just totals of registrations and current call counts (and channels – a subtle difference as a channel is one leg of a call). I was after numbers of registrations but the FreeSWITCH command line interface (fs_cli) didn’t list this as an option when you did a help on the show command.
But it really does have a show registrations with a switch for the totals i.e. show registrations count only the module source code didn’t have this in its help text. I’ll log it as a trivial bug.
Here is my Pandora FMS pandora_agent.conf snippet,
module_begin
module_name FSRegnsCount
module_type generic_data
module_exec /usr/local/freeswitch/bin/fs_cli -x "show registrations count" | awk '{if (match($0,"total")) { printf("%d",$1);}}'
module_description FreeSWITCH registrations
module_end
I will be adding more of thee snippets of Pandora agent configs to a special page on our web site here – http://www.openmutual.org/resources/pandora-fms-agent/
The “show” command help syntax is just a #define in /usr/local/src/freeswitch/src/mod/applications/mod_commands/mod_commands.c so easy to fix.
During the Pandora FMS console upgrade the database schema may not have been upgraded correctly. If this happens then the Pandora server will be unable to start, i.e. when you try /etc/init.d/pandora_server start then it fails and logs its error messages in the /var/log/pandora/pandora_server.error file. If there are Unknown column errors then this is a clear giveaway that the database that you are connecting to doesn’t have the expected schema,
DBD::mysql::db do failed: Unknown column 'extended_info' in 'field list' at /usr/lib/perl5/PandoraFMS/DB.pm line 567. DBD::mysql::st execute failed: Unknown column 'disabled' in 'where clause' at /usr/lib/perl5/PandoraFMS/DB.pm line 399. DBD::mysql::db do failed: Unknown column 'tags' in 'field list' at /usr/lib/perl5/PandoraFMS/DB.pm line 567.
The fix is easy to do (assuming you don’t want to fall back to the previous version). Ideally first make a backup of your database using whatever tools you have available (your cpanel Mysql tools or command line mysqldump or phpmyadmin).
Then run the following command line commands,
cd /path/to/pandora_console cat extras/pandoradb_migrate_v3.1_to_v3.2.sql | mysql -u pandora -p -D pandora
and then at the Enter password: prompt enter the password of the mysql user pandora. Note that the -u is the user i.e. pandora and the -D pandora is the database of pandora. This is the default convention used on the Pandora FMS system though you can use any database username and database name. Yes that is the 3.1 to 3.2 schema upgrade file. There is no harm in repeating that command.
Then repeat that with the 3.2 -> 4.0 schema changes..
cat extras/pandoradb_migrate_v3.2_to_v4.0.sql | mysql -u pandora -p -D pandora
At the end of this then you can start the Pandora server and it should startup correctly.
This is one of those silly gotchas that works on some servers but not on others. On servers you’ve probably gotten used to common server processes like mysql and ssh and so on listening on all IP addresses (0.0.0.0).
Doesn’t work that way on virtual (e.g. venet0) interfaces used with virtual servers. Few things get to have bindings like 0.0.0.0:port.
You probably know the answer now – If your tentacle server is bound to a specific IP then if the Pandora Agent (client) on the actual Pandora Server itself tries a default of “localhost” i.e. connect to itself then that isn’t going to work at all if the tentacle server is not listening on 127.0.0.1/0.0.0.0 but is listening on a specific IP address.
Fix is easy – do a netstat -an | grep 41121 and you’ll see something like…
tcp 0 0 X.X.X.X:41121 0.0.0.0:* LISTEN
where X.X.X.X is an actual IP address and not 0.0.0.0.
In the /etc/pandora/pandora_agent.conf then set the server_ip to that IP address or, better, set it to the domain name that resolves to that IP.
This is a first-day-of-use error message that will appear as a warning triangle at the top of your PandoraFMS v4 Administration Console. The fix is easy. Go into the menu option,
Administration -> Setup -> Visual Styles
and set the Fontpath option (it will be set but not saved into the new
database schema) and then do an Update on that page just the once.
That clears that warning triangle message. If you didn’t notice then the warning triangle appears at the top near your username and logout icon.
Sometimes you need to patch the Pandora FMS. To do this download the patch file (it’ll come from Sourceforge).
Untar it in a suitable location e.g.
cd sources
wget <the patchfile URL>
tar xvfz pandora_console_3.2.1_March_Patch.tar.gz
cp -i -R pandora_console/* /path/to/httpdocs/pandora_console/
and then confirm each change if it makes sense. Repeat for the pandora_server though that is at a different location e.g.,
cp -i -R pandora_server/* /usr/share/pandora_server/
The console changes will have an effect immediately as that is just PHP scripts but the server needs to have the following,
/etc/init.d/pandora_server restart
When you are initially creating the Pandora FMS 3.2.1 on a hosting system then you may hit two problems,
Open_basedir restrictions stop the install script (version 3.2.1) from seeing if the Graphviz binary exists (/usr/bin/twopi ) which is probably there because to get the Pandora FMS installed then Graphviz is a dependency. This shows up as an error on the list of dependencies for the FMS installer web page but if you know that you have the file (/usr/bin/twopi ) then you can click the skip to next step button.
When Pandora FMS creates/updates the pandora MySQL username then it changes the password but unless the RELOAD privilege is on the administration MySQL account then this script fails but it has created the config file. If you are creating the MySQL users via Plesk then this RELOAD privilege is not set. The install fails and you have an empty database. All is not lost – in the pandora_console directory there are two SQL files pandoradb.sql and pandoradb_data.sql. FTP these to your local PC, then use Plesk to create the pandora database and pandora user. Then use the mysqladmin (from within Plesk) to import these two files (it picks them from your local PC). Import both files in turn.
Now edit the /etc/pandora/pandora_server.conf file and set the password that the install created for the pandora MySQL account. Restart the Pandora FMS server ( sudo /etc/init.d/pandora_server restart )
Pandora FMS should now work (the default account is admin and the password is pandora). Obviously on internet-facing Pandora FMS consoles then that is the first thing you change !