How To – Fix the Perl repo for ViciBox 10(Leap 15.3)

If you’ve tried to update your ViciBox 10 system you’ll see that the Perl repo gives an error and you can’t update from that repo any longer. The reason for this is because Leap 15.3 has gone end of life(EOL) and will no longer be getting updates. The other repos will begin to die as well and your system will remain vulnerable to hackers as dialer system are high priority targets right now for ransomware groups, denialof service attackers and crypto miners. So how do you fix this issue? You upgrade to leap 15.4 following this article: How to – Upgrade OpenSuSE Leap 15.3 to 15.4.

Hopefully this helps those of you running into this problem and you’ll now be able to keep your systems secure.

Chris aka carpenox

How to – Upgrade OpenSuSE Leap 15.3 to 15.4

This article will go over how to upgrade Leap 15.3 to 15.4 since 15.3 is end of life

Step 1. Preparations – Backup everything

Keep verified backups: Do not skip this step. Before typing the following commands, you must back up all data and config files. Also, ensure your system backup is up-to-date and restorable in an emergency. The author or nixCraft is not liable for damages due to failed upgrades.

Step 2. Update OpenSUSE 15.3 packages

The openSUSE Leap version 15.3 is only available as the 64-bit release. Next, type the following zypper command to update all existing packages. To refresh a repo, enter:
$ sudo zypper ref
Outputs:

Repository 'openSUSE-Leap-15.3' is up to date.                                                     
Repository 'openSUSE-Leap-15.3-Update' is up to date.                                              
Repository 'openSUSE-Leap-15.3-Update-Non-Oss' is up to date.                                      
Repository 'Update repository of openSUSE Backports' is up to date.                                
Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15' metadata[done]
Building repository 'Update repository with updates from SUSE Linux Enterprise 15' cache ....[done]
All repositories have been refreshed.

Update ALL installed packages with newer versions and patches

Before the upgrade procedure can begin, apply all pending upgrades or security patches. For example:
$ sudo zypper up
Outputs:

Loading repository data...
Warning: Repository 'openSUSE-Leap-15.3-Update' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...

The following 10 packages are going to be upgraded:
  cups cups-client cups-config libcups2 libcupscgi1 libcupsimage2 libcupsmime1 libcupsppdc1
  libfreetype6 libqpdf26

10 packages to upgrade.
Overall download size: 8.4 MiB. Already cached: 0 B. After the operation, additional 79.8 KiB will
be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving package cups-config-2.2.7-150000.3.35.1.x86_64    (1/10), 239.1 KiB (  3.1 MiB unpacked)
Retrieving: cups-config-2.2.7-150000.3.35.1.x86_64.rpm ......................................[done]
Retrieving package libfreetype6-2.10.4-150000.4.12.1.x86_64  (2/10), 447.3 KiB (  1.1 MiB unpacked)
Retrieving: libfreetype6-2.10.4-150000.4.12.1.x86_64.rpm ....................................[done]
....
..
Checking for file conflicts: ................................................................[done]
( 1/10) Installing: cups-config-2.2.7-150000.3.35.1.x86_64 ..................................[done]
( 2/10) Installing: libfreetype6-2.10.4-150000.4.12.1.x86_64 ................................[done]
( 3/10) Installing: libqpdf26-9.0.2-150200.3.3.1.x86_64 .....................................[done]
....
( 9/10) Installing: cups-client-2.2.7-150000.3.35.1.x86_64 ..................................[done]
Failed to try-restart cups-lpd@.service: Unit name cups-lpd@.service is missing the instance name.
See system logs and 'systemctl status cups-lpd@.service' for details.
(10/10) Installing: cups-2.2.7-150000.3.35.1.x86_64 .........................................[done]
Executing %posttrans scripts ................................................................[done]

Step 3. Reboot the server

Now note down the current Linux kernel version, type:
$ uptime
$ uname -mrs
You must reboot the Linux cloud box, using the shutdown command or reboot command:
$ sudo systemctl reboot
## OR ##
$ sudo shutdown -r now
Log in using the ssh command once system comes back online:
$ ssh ec2-user@your-aws-ec2-dns-ip-here
## OR ##
$ ssh root@your-Linode-dnsname-OR-ip-here
Then verify Linux kernel version:
$ uname -mrs
Also note down the OpenSUSE Linux version using the cat command:
$ cat /etc/os-release

Step 4. Upgrading OpenSUSE 15.3 to 15.4

Now my cloud server is fully patched. It is time to update the server to OpenSUSE version 15.4.

List the repositories

The update repository must exist and is enabled and update before upgrading to 15.3. Verify it using the zypper command as follows:
$ sudo zypper repos --uri
## OR type ##
$ sudo zypper lr -u
Output indicating that there are no 3rd party repos and Update repos are enabled on my OpenSUSE 15.3 server:

Repository priorities are without effect. All enabled repositories share the same priority.
 
# | Alias                             | Name                                                                                        | Enabled | GPG Check | Refresh | URI
--+-----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+---------+---------------------------------------------------------------
1 | openSUSE-Leap-15.3                | openSUSE-Leap-15.3                                                                          | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/distribution/leap/15.3/repo/oss/
2 | openSUSE-Leap-15.3-Update         | openSUSE-Leap-15.3-Update                                                                   | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.3/oss/
3 | openSUSE-Leap-15.3-Update-Non-Oss | openSUSE-Leap-15.3-Update-Non-Oss                                                           | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.3/non-oss/
4 | repo-backports-debug-update       | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No      | ----      | ----    | http://download.opensuse.org/update/leap/15.3/backports_debug/
5 | repo-backports-update             | Update repository of openSUSE Backports                                                     | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.3/backports/
6 | repo-sle-debug-update             | Update repository with debuginfo for updates from SUSE Linux Enterprise 15                  | No      | ----      | ----    | http://download.opensuse.org/debug/update/leap/15.3/sle/
7 | repo-sle-update                   | Update repository with updates from SUSE Linux Enterprise 15                                | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.3/sle/

Verify that we can get latest OpenSUSE 15.4 version, run:
$ sudo zypper --releasever=15.4 lr -u
Here is what I see

Warning: Enforced setting: $releasever=15.4
Repository priorities are without effect. All enabled repositories share the same priority.
 
# | Alias                             | Name                                                                                        | Enabled | GPG Check | Refresh | URI
--+-----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+---------+---------------------------------------------------------------
1 | openSUSE-Leap-15.3                | openSUSE-Leap-15.3                                                                          | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/distribution/leap/15.4/repo/oss/
2 | openSUSE-Leap-15.3-Update         | openSUSE-Leap-15.3-Update                                                                   | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.4/oss/
3 | openSUSE-Leap-15.3-Update-Non-Oss | openSUSE-Leap-15.3-Update-Non-Oss                                                           | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.4/non-oss/
4 | repo-backports-debug-update       | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No      | ----      | ----    | http://download.opensuse.org/update/leap/15.4/backports_debug/
5 | repo-backports-update             | Update repository of openSUSE Backports                                                     | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.4/backports/
6 | repo-sle-debug-update             | Update repository with debuginfo for updates from SUSE Linux Enterprise 15                  | No      | ----      | ----    | http://download.opensuse.org/debug/update/leap/15.4/sle/
7 | repo-sle-update                   | Update repository with updates from SUSE Linux Enterprise 15                                | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/leap/15.4/sle/

In the above output results, check the last URI column). All repository links should contain 15.4 or openSUSE_Leap_15.4 as a version number. If not check if your Leap repos defined in /etc/zypp/repos.d/ are using the $releasever variable already in the URIs. For example, try the grep command:
$ sudo grep baseurl /etc/zypp/repos.d/*.repo
If you see hard-coded version 15.3 Leap version number, then you need to modify them first. This can be done using the sed command to find and replace with sed:
$ sudo sed -i 's/15.3/${releasever}/g' /etc/zypp/repos.d/*.repo
Now verify again:
$ sudo zypper --releasever=15.4 lr -u

Running the upgrade for 15.4

It is time to switch and refresh all repositories to 15.4 using the following syntax and grab the repository metadata:
$ sudo zypper --releasever=15.4 ref
For slower

Warning: Enforced setting: $releasever=15.4
Retrieving repository 'openSUSE-Leap-15.3' metadata ................................................................................................................................................................................................................................[done]
Building repository 'openSUSE-Leap-15.3' cache .....................................................................................................................................................................................................................................[done]
Retrieving repository 'openSUSE-Leap-15.3-Update' metadata .........................................................................................................................................................................................................................[done]
Building repository 'openSUSE-Leap-15.3-Update' cache ..............................................................................................................................................................................................................................[done]
Retrieving repository 'openSUSE-Leap-15.3-Update-Non-Oss' metadata .................................................................................................................................................................................................................[done]
Building repository 'openSUSE-Leap-15.3-Update-Non-Oss' cache ......................................................................................................................................................................................................................[done]
Retrieving repository 'Update repository of openSUSE Backports' metadata ...........................................................................................................................................................................................................[done]
Building repository 'Update repository of openSUSE Backports' cache ................................................................................................................................................................................................................[done]
Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15' metadata ......................................................................................................................................................................................[done]
Building repository 'Update repository with updates from SUSE Linux Enterprise 15' cache ...........................................................................................................................................................................................[done]
All repositories have been refreshed.

Next, execute the following command for full distribution upgrade to 15.4 from 15.3. Please note that command must be typed from non-GUI (KDE/GNOME) mode. Hence, it is recommended you run the command from either runlevel 3 (text + network), or a virtual console (see how to switch boot target to text or GUI in systemd Linux for more info.). You can press Ctrl-Alt-F2 (all at the same time) to switch to virtual terminal 2. One can also issue the following command:
$ sudo systemctl set-default multi-user.target
Let us start the distribution upgrade that will get your system to the new version:
$ sudo zypper --releasever=15.4 dup
OR first download everything on slower internet connection to avoid any problem with upgrades:
$ sudo zypper --releasever=15.4 dup --download-in-advance
Once the dup is finished, openSUSE sets the releasever variable to the new version 15.4:

Final confirmation

At the following prompt type y and hit the [Enter] key to start upgrade procedure:

The following 11 packages are going to be REMOVED:
  kernel-default-5.3.18-150300.59.87.1 kernel-default-5.3.18-150300.59.90.1 kernel-default-extra-5.3.18-150300.59.87.1
  kernel-default-extra-5.3.18-150300.59.90.1 kernel-default-optional-5.3.18-150300.59.87.1
  kernel-default-optional-5.3.18-150300.59.90.1 librsvg-lang libusbguard0 libwebkit2gtk3-lang libyui-ncurses-pkg15
  systemd-icon-branding-openSUSE
 
The following package requires a system reboot:
  kernel-default-5.14.21-150400.24.18.1
 
486 packages to upgrade, 4 to downgrade, 55 new, 11 to remove.
Overall download size: 688.7 MiB. Already cached: 0 B. After the operation, additional 51.0 MiB will be used.
 
    Note: System reboot required.
Continue? [y/n/v/...? shows all options] (y): y

The zypper command will download, install, or upgrade a total of 486 packages on my cloud server. The procedure to download and install packages takes its own sweet time. So, naturally, your Internet and cloud server speed plays a significant role. In the end, you should see an output as follows showing you must reboot the OpenSUSE server or desktop:

....
..
dracut: *** Stripping files done ***
dracut: *** Creating image file '/boot/initrd-5.14.21-150400.24.18-default' ***
dracut: *** Creating initramfs image file '/boot/initrd-5.14.21-150400.24.18-default' done ***
(403/552) Installing: kernel-default-5.14.21-150400.24.18.1.x86_64 ......................................................[done]
(404/552) Removing kernel-default-5.3.18-150300.59.87.1.x86_64 ..........................................................[done]
(405/552) Removing kernel-default-5.3.18-150300.59.90.1.x86_64 ..........................................................[done]
(406/552) Installing: util-linux-lang-2.37.2-150400.8.3.1.noarch ........................................................[done]
(407/552) Installing: systemd-network-249.12-150400.8.10.1.x86_64 .......................................................[done]
(408/552) Installing: kernel-default-extra-5.14.21-150400.24.18.1.x86_64 ................................................[done]
(409/552) Installing: grub2-systemd-sleep-plugin-2.06-150400.11.5.2.noarch ..............................................[done]
.....
..
Executing %posttrans scripts ............................................................................................[done]
There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs.
 
Since the last system boot core libraries or services have been updated.
Reboot is suggested to ensure that your system benefits from these updates.

Therefore, reboot the Linode or AWS cloud server using the shutdown command or reboot command as follows:
$ sudo reboot

Step 5: Verification

Make sure everything is working. First, find OpenSuse Linux Version and other info:
$ uname -mrs
$ cat /etc/os-release
$ hostnamectl

Then check your Linux server log file. For instance, use the journalctl command/tail command/dmesg command command and others:
$ sudo tail -f /var/log/nginx/www.nixcraft_com_access.log
$ dmesg | more
$ journalctl -xe

Step 6: Apply any newly released updates

Finally, again use the zypper command to apply security patches, software updates and Linux kernel:
$ sudo zypper refresh
$ sudo zypper patch
$ sudo zypper update
# if a new Linux kernel installed, reboot the box
$ sudo reboot

Hopefully this will help a lot of you keep up to date and secure

Chris aka carpenox

What does – The statuses at the bottom of each list mean?

List Statuses Breakdown

In this article, I will go over what the list statuses mean in relation to reporting. What I’m talking about is at the bottom of each list as shown in the picture below:

All of these different statuses can become pretty confusing, especially because they are not all on the agent screen and some are not even on the system statuses either which becomes really challenging. Ok so let’s stay from the to, I’ll outline them all on a simple “List” layout.

• A – Answering machine disposition marked by an agent
• AA – Answering machine disposition automatically detected by the AMD(Answering Machine Detection) system
• AB – Busy signal automatically detected by the carrier
• ADC – Disconnected number detected by carrier
• ADCT – Congested number reported by carrier
• B – Busy disposition marked by agent
• CallBK – Agent setup a callback which can be done in there agent interface and a calendar down to them
• CBHold – Scheduled ANYONE callback that has not hit it’s trigger, or an AGENTONLY callback
• DAIR – Dead air dispo marked by an agent, usually because they hear nothing when they get the call
• DC – Disconnected number marked by an agent
• Dec – Declined sale dispo marked by agent because customer denied ever purchasing anything from your business
• DNC – Do Not Call dispo marked by agent, usually requested by customer
• DNCL – Do Not Call dispo automatically marked by system because a number already marked DNC was in there Hopper
• ERI – Agent error – usually closes browser accidentally or logs out accidentally, or similar

The next 5 dispos are related to KHOMP AMD also used with a 3rd party service called AI AMD(Artificially Intelligent Answering Machine Detection) If interested in this message me via Skype -:- live:carpenox_3 | Back to the list statuses

• N – No Answer dispo marked by the agent, usually because no one answered the phone
• NA – No Answer dispo automatically detected, Any outbound call that does not receive an Answer signal(or other signal) from the carrier. This can include ring-no-answer, disconnected, carrier congestion and other errors
• New – New Lead, never called
• NI – Not Interested dispo marked by agent
• NP – No Pitch No Price dispo marked by agent, didn’t get a chance to read the pitch and/or give the price
• Sale – Agent closed the call and made the sale

The last thing I want to go over is the other columns, “called”, “not called”, “dialable” and”penetration”.

• Called – The number of leads dialed since the lists last reset
• Not Called – The amount of leads not called since last reset
• Dialable – How many of the “Not Called” leads are dialable at that time, in my example you’ll see 0 because when I took that screen shot I was outside of allowed call times for that campaign or list. So it shows you dialable leads within time zone parameters
• Penetration – Some dispos get the lead marked as “completed”, such as Sale, DNC, Not interested, etc. So as leads with a completed status get marked, it takes those out of rotation and calculated what percent along with all the rest of the dispositions and puts it as penetrated

Campaign List Statuses

The other place you’ll see a similar layout of statuses is at the bottom of any campaign. I’ll go over what this means as well. Below is a picture to help you follow along:

As you can see above it looks very similar to the results on the bottom of each list, except this combines all active lists on the campaign and shows you only called and not called results. What this means is the numbers next to each dispo for the called campaign have all been dialed since the last reset of the lists attached and active, and the same for the not called except those numbers are how many leads have not been dialed since the last lists reset.

I hope this article has helped some of you that may have been confused about this past of the system, comment below or join our chat: https://join.skype.com/ujkQ7i5lV78O of you have any questions.

Chris aka carpenox

How to – Integrate Queuemetrics with Vicidial

This article will go over how to integrate Queuemetrics with ViciDial

ViciDial integration

ViciDial is an enterprise class, open source call center suite in use by many large call centers around the world.

VICIdial has a full featured predictive dialer. It can also function as an ACD for inbound calls, or closer calls coming from VICIdial outbound frontiers. It is capable of inbound, outbound, and blended call handling.

It can also be easily integrated with QueueMetrics.

For more information, see http://www.vicidial.com

ViciDial is a registered trademark.

Prerequisites

• A working ViciDial instance, version 2.0.4 or later

It is very important that all servers involved (be they for QueueMetrics or ViciDial or general Asterisk usage) are on the same time zone and time, aligned with sub-second precision by an NTP daemon. If this is not so, the setting may lead to data corruption and inaccurate reports.

In order to translate ViciDial data to QueueMetrics, the following conventions are used:

• The campaign_id in ViciDial is seen as the queue in QueueMetrics
• The user ID in ViciDial is prepended by “agent/” and translated to the agent code in QueueMetrics (e.g. user 123 appears as agent/123)
• The UniqueID for the call appears as Asterisk’s unique id prepended with server_id field (e.g. 1-1170345123.1234)

In this example, we imagine that:

• The QueueMetrics server has IP 1.2.3.4
• The QueueMetrics database server has IP 1.2.3.5 and the QM database is called “queuemetrics”
• The ViciDial server has IP 1.2.3.6

Changes to QueueMetrics database

ViciDial and QueueMetrics work together by sharing the database.

You must log on to the QueueMetrics database and create a user for ViciDial to connect to it. We use a different username from the one QM uses so it is easy to monitor who is doing what.

GRANT ALL PRIVILEGES ON queuemetrics.* TO vicidial@'1.2.3.6' IDENTIFIED BY 'qm';

ViciDial will also need special indexing on the ‘queue_log’ table to work efficiently:

CREATE INDEX vici_time_id on queue_log(time_id);
CREATE INDEX vici_call_id on queue_log(call_id);

Changes to ViciDial

The system configuration can easily be set from the ViciDial Admin / System Settings page:

• Enable QueueMetrics logging: set to 1
• QueueMetrics server IP: this is the IP for the MySQL DB server, in our example “1.2.3.5”
• QueueMetrics DB name: the database name, in our example “queuemetrics”
• QueueMetrics DB login: the database login, in our example “vicidial”
• QueueMetrics DB password: the database password, in our example “qm”
• QueueMetrics URL: the login URL for QM, e.g. “http://1.2.3.4:8080/queuemetrics”
• QueueMetrics LogID: leave it to VIC (this in an ID for the server)
• QueueMetrics EnterQueue Prepend: This field is used to allow for prepending of one of the vicidial_list data fields in front of the phone number of the customer for customized QueueMetrics reports. Default is NONE to avoid populating anything.

A set of cron jobs is expected to run to keep the logs updated; check that they are present by issuing a ‘crontab -e’:

### fix the vicidial_agent_log once every hour and the full day run at night
33 * * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl
50 0 * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl --last-24hours
*/5 * * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl --only-qm-live-call-check
1 1 * * * /usr/share/astguiclient/Vtiger_optimize_all_tables.pl --quiet

Also, you will need to install the PHP XML-RPC library in order to have audio data accessible from the QueueMetrics server:

pear install XML_RPC-1.5.1

Changes to QueueMetrics

Edit the ‘configuration.properties’ file in order to set the following properties:

# This is the default queue log file.
default.queue_log_file=sql:P01

By default, ViciDial logs all data to partition “P01”.

audio.server=it.loway.app.queuemetrics.callListen.listeners.ClassicXmlRpcRecordings

audio.liveserver=it.loway.app.queuemetrics.callListen.RTlisteners.ClassicXmlRpcListenerRT

default.audioRpcServer=http://1.2.3.6/vicidial/xml_rpc_audio_server_vicidial.php

Change ‘1.2.3.6’ to your ViciDial server address.

After this, you need to define each ViciDial campaign as a QueueMetrics queue, and set it properly as an inbound or outbound one. After that, you can freely create composite queues to report on all or some activity at once.

The live monitoring asks for an extension to send the call to, this is an extension dialed on the active voicemail server as defined in the system settings. If there is no active voicemail defined then the live monitor will place the call to the extension on the server that the agent is on.

As far as I know, no one uses this anymore, but I wanted to give those of you that are interested the ability to give it a try if you wanted, so here it is

Chris aka carpenox