Vicidial - Asterisk table missing after running non_agent.ap

[wjohnson133]

Hello everybody,

Today I was looking to delete an item from a list and I used the non-agent.api to do it. I left the agent screen on pause for an hour or three and I came back and there was an error message saying that asterisk database is no longer present. I did a show tables query and all of the other databases are present except for Asterisk. I am open to suggestions on what to do here. I have no knowledge of whether I have backups, whether I should reboot my VPS server. Rather than doing guesswork I was wondering if I could get some advice here on where to start. Any help would be appreciated.

Vicidial Version

VERSION: 2.14-605a
BUILD: 170327-1655

Linux Distribution
CentOS Linux release 7.3.1611 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.3.1611 (Core)
CentOS Linux release 7.3.1611 (Core)

Kernel

3.10.0-514.10.2.el7.x86_64

MySQL Version

mysql Ver 15.1 Distrib 5.5.52-MariaDB, for Linux (x86_64) using readline 5.1

Perl Version

This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
(with 34 registered patches, see perl -V for more detail)

Asterisk Version

Asterisk 1.8.23.0-1_centos7.go RPM by demian@goautodial.com built by root @ centos7.goautodial.com on a x86_64 running Linux on 2014-08-01 00:18:09 UTC

PHP Version

PHP 5.4.16 (cli) (built: Nov 6 2016 00:29:02)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with XCache v3.1.1, Copyright (c) 2005-2014, by mOo
with XCache Optimizer v3.1.1, Copyright (c) 2005-2014, by mOo
with XCache Cacher v3.1.1, Copyright (c) 2005-2014, by mOo
with XCache Coverager v3.1.1, Copyright (c) 2005-2014, by mOo

[mflorell]

Well, that's not really uncommon if you are using a VPS. The only suggestion I would have is to not virtualize your database or asterisk servers.

[wjohnson133]

Well, that's not really uncommon if you are using a VPS. The only suggestion I would have is to not virtualize your database or asterisk servers.

I used the wrong term, when I said a VPS I mean an online server, specifically www.ovh.com/ca/en/

[mflorell]

I don't see the specs for "online server" on their website.

We don't recommend using any kind of virtual server for Vicidial use. There can be several causes for the database connection going away, from a locked database query, to hardware issues to improper configurations.

[williamconley]

Plus: If your system was not whitelist firewalled, and you have enemies ... well, someone could certainly have deleted the DB after breaking into your system.

[mflorell]

Doesn't require enemies William, just a basic bored teenager can go and do that if the system is vulnerable

[williamconley]

Dunno, I've had a *lot* of clients who were unsecured, and none have actually lost data unless they pissed off either a previous employee or a previous IT person.

The bored hackers have always turned out to be china or russia trying to use the PBX to connect calls for free so far. They don't damage the system or make detectable changes: they have a monetary reason for it to keep working and "not be noticed"! lol

[mflorell]

I remember years ago I had a client that was hacked and had his server turned into an open FTP server. The hacker deleted his database, presumably so he'd have more room for files. Of course that's what alerted my client to the hack

[williamconley]

lol: And now there are thousands of "free file share" sites. No need to configure an open FTP through hacking. Time marches on. lol

[wjohnson133]

I remember years ago I had a client that was hacked and had his server turned into an open FTP server. The hacker deleted his database, presumably so he'd have more room for files. Of course that's what alerted my client to the hack

I think I may have deleted the database while attempting to use the non_agent api. I deleted a record on a list by putting the information in the web link but then I tried to see if I could do the same thing using the wget and curl commands from the linux command line. The system was working on something for awhile. These are some very amusing anecdotes that you guys are sharing though. Hard won experience.

Somebody told me that open source software is only free if my time is worth nothing...truer words...

[williamconley]

Executing sql commands directly requires a knowledge of sql. If you try to delete a single record, but don't understand sql, your learning experience may well include deletion of an entire table's records. The structure remains, but the table is now empty or "truncated".

This is also a Very Good Reason to both understand and invoke the admin backup perl script for Vicidial. It's quite useful at providing the ability to restore your data from last night. We put this into every server during buildout with auto-activation at 11:45PM for a full backup (DB/Web/Config file).

Technically speaking, the mysql-binary logs could be used to retrieve your data on a stock installed system, but it's not a simplistic process (and not a Vicidial question/answer: It's pure mysql).

[wjohnson133]

Thank you for the information William, I added it to Cron but it doesn't seem to be doing it as part of the batch process