vicidial.org

It's released and can be downloaded here:

https://download.vicidial.com/iso/vicib ... 12.0.2.iso
https://download.vicidial.com/iso/vicib ... 0.2-md.iso

Here's the short list of things:
- OpenSuSE 15.6 with Kernel 6.4.0
- PHP 8.2
- Asterisk 18 with PJSIP support
- MariaDB 10.11.9
- Python 3.11 now included
- vicibox-mdraid1 supports NVMe drives as well as adding/replacing drives
- configs are statically copied, so future package updates won't affect production
- On first login downloading updates and setting up RAID arrays is now included

good shit, lets goooo

I've updated the docs site to include the new installation options in ViciBox v.12.0. You can see it here:

https://docs.vicibox.com/en/latest/inst ... hase1.html

There's also now a bugfix for Vicibox v.12.0.0 from the vicibox-mdraid1 script. Long story short if you apply updates before running the RAID setup you will be fine. If not, you will potentially have to setup the swap array manually. Read about that here:

https://docs.vicibox.com/en/latest/bugf ... 200-1.html

And there's now a dark mode on docs.vicibox.com. yay!

Looks like I forgot to enable the firewall by default in 12.0.0. So that's a security policy issue and will necessitate a 12.0.1 release. By default we should assume the network is hostile to us and firewall it until told otherwise.

You can turn it on in 'yast firewall' or by running 'systemctl enable firewalld.service' and then rebooting. This will cleanly load the firewall and all the IP blocking stuff. I guess as a bonus 12.0.1 will also get the new and improved vicibox-mdraid1. So far the seems like the bulk of the issues.

I'll probably do the firewall section of the vicibox manual next. That really has been long overdue.

I enabled the edit on github links in the docs.vicibox.com site. So feel free to update screenshots or instructions in any section. It'd be nice to turn this into a sort of Vicibox Admin knowledge base.

Doh, let me try to spread the word on this, good catch

carpenox wrote:Doh, let me try to spread the word on this, good catch

here's the bugfix note
https://docs.vicibox.com/en/latest/bugf ... 200-2.html

bad news kumba, one of the community members showed me this in my discord



this is on 12.0.1 when trying to go into yast firewall

carpenox wrote:bad news kumba, one of the community members showed me this in my discord



this is on 12.0.1 when trying to go into yast firewall

There's a second 'ssh' listed in /etc/firewalld/external.xml. Remove the second SSH and you should be fine.

Firewalld just silently ignores it and gets on about it's business. YaST, meanwhile, has a collective meltdown somewhere in the middleware that connects it to DBus. But that's far enough down the food chain that I'm not going to chase it.

You can do a zypper up and pull in the new vicibox-firewall. You'll see it say something like creating /etc/firewalld/zones/external.xml.rpmnew and might have to copy them over the bare XML files. This .rpmnew is a standard behavior with config files. When you change the defaults it just plops an .rpmnew on the filesystem and you have to back in the changes.

Here's the bugfix info on the docs site: https://docs.vicibox.com/en/latest/bugf ... 201-1.html

I'll probably let 12.0.1 marinate for a week or so in case more issues are found. Then I'll probably push out 12.0.2

yea good deal, ill continue to collect feedback from the community and report back

found an error in the docs

when you go to click the link for iso download in installation area:





The link is for https://download.vicidial.com/iso/vicib ... 12.0.1.iso

when it should be https://download.vicidial.com/iso/vicib ... 12.0.1.iso

Just the capital V throws it off

Fixed. Also, if anyone wants to make changes and submit it through a PR on github go for it. No need to check in here first.

On a side note, a ViciDial SVN issue was found. Long story short the server_updater table needs a fix. You can read about it here:

https://docs.vicibox.com/en/latest/bugf ... 201-2.html

Well major issue found in all ViciBox v.12.0 releases so far. Apparently MariaDB finally deprecated a TIMESTAMP behvaior. The long story short is that before this was deprecated when you added a TIMESTAMP type in MariaDB it would implicitly apply certain clauses like 'ON UPDATE CURRENT_TIMESTAMP'. Given that parts of ViciDial are old enough that they predate the TIMESTAMP field even being a type this behavior was assumed in all sorts of schema across the codebase.

Now the default behavior is to be explicit with the clauses. Otherwise none are added. The result is you end up with tables like server_updater and it's db_time TIMESTAMP field which should have an ON UPDATE CURRENT_TIMESTAMP but doesn't.

Here's the ViciBox bugfix on it: https://docs.vicibox.com/en/latest/bugf ... 01-2.html#
And the MariaDB explanation of the bevhavior: https://mariadb.com/docs/server/ref/mdb ... timestamp/

This only affects databases. Web servers and Dialers are unaffected.

This is a 10/10 on the broke scale so I'll be pushing out a ViciBox v.12.0.2 later tonight once the schemas have been updated. In the meantime, you can follow the bugfix above if you want to apply the fix yourself.

The VICIdial codebase has also been updated to use the TIMESTAMP "default" and "on update" field definitions as of svn/trunk revision 3898.

This affected 40 database tables, and the update includes changes to both the "MySQL_AST_CREATE_tables.sql" and "upgrade_2.14.sql" files.

good deal, this only effects Vicibox 12 it seems, I have most my clients servers on alma 9.5 and about 30% of them are on 3896 with no issues

carpenox wrote:good deal, this only effects Vicibox 12 it seems, I have most my clients servers on alma 9.5 and about 30% of them are on 3896 with no issues

And only when setting up a new database. If you imported a database from an older ViciBox v.11 install the on update was explicitly set in the export.

ah ok that makes sense, these were all exisitng systems on alma that were upgraded to latest SVN's. i wonder if i was to do a fresh install with SVN 3896 if the error would happen on a scratch...., now i wanna try lol

carpenox wrote:ah ok that makes sense, these were all exisitng systems on alma that were upgraded to latest SVN's. i wonder if i was to do a fresh install with SVN 3896 if the error would happen on a scratch...., now i wanna try lol

Just import the create tables SQL and do a describe on server_updater. If you don't see current_timestamp then you got the same problem. Fix is the same as what I documented.

ok so i created a new database and imported the create sql file from 3896 and this was the results of desc

MariaDB [asterisk2]> describe server_updater;

Code: Select all

+-------------+-------------+------+-----+---------------------+-------------------------------+
| Field       | Type        | Null | Key | Default             | Extra                         |
+-------------+-------------+------+-----+---------------------+-------------------------------+
| server_ip   | varchar(15) | NO   | PRI | NULL                |                               |
| last_update | datetime    | YES  |     | NULL                |                               |
| db_time     | timestamp   | NO   |     | current_timestamp() | on update current_timestamp() |
+-------------+-------------+------+-----+---------------------+-------------------------------+

3 rows in set (0.000 sec)


what svn should i try it on?

carpenox wrote:ok so i created a new database and imported the create sql file from 3896 and this was the results of desc

MariaDB [asterisk2]> describe server_updater;

Code: Select all

+-------------+-------------+------+-----+---------------------+-------------------------------+
| Field       | Type        | Null | Key | Default             | Extra                         |
+-------------+-------------+------+-----+---------------------+-------------------------------+
| server_ip   | varchar(15) | NO   | PRI | NULL                |                               |
| last_update | datetime    | YES  |     | NULL                |                               |
| db_time     | timestamp   | NO   |     | current_timestamp() | on update current_timestamp() |
+-------------+-------------+------+-----+---------------------+-------------------------------+

3 rows in set (0.000 sec)


what svn should i try it on?

Any version before 3898 as that's when Matt committed the schema changes. Looks like your version or configuration of MariaDB doesn't have the deprecated behavior changed yet.

Also just released 12.0.2. So that should hopefully be a pretty solid release.

the links dont work at the top of the post, they have the lowercase V again instead of https://download.vicidial.com/iso/vicib ... 12.0.2.iso

carpenox wrote:the links dont work at the top of the post, they have the lowercase V again instead of https://download.vicidial.com/iso/vicib ... 12.0.2.iso

Just looked at https://docs.vicibox.com/en/latest/inst ... a-std.html and https://docs.vicibox.com/en/latest/inst ... ia-md.html and the links are downloading just fine. Has the upper case V and everything.

Not sure what issue the issue is.

Added an installation video to docs.vicibox.com. No audio, just a 6-minute video on doing Phase1 install for the MD RAID arrays. There's a link on the main page to the video in the Phase 1 section.

Also updated the maintenance section with new screenshots and set the width of images to 640 pixels instead of 664. It scales better for the 1024x768 screenshots I'm doing.

That pretty much just leaves the networking section left. I think I'll save that for a day I feel like playing CCNE.

Reports coming in for 12.0.2 still with yast firewall issue

I found this patch which seems to fix it:

zypper in -t patch openSUSE-SLE-15.6-2024-4321=1 SUSE-2024-4321=1


Full doc here: https://www.suse.com/support/update/ann ... orm=MG0AV3

Hmmm, that seems different then the issue I fixed, which was more YaST then firewalld. The external.xml was definitely wrong and causing an issue in YaST.

I'll check this out. I'll have to see how I can install a patch into ViciBox.

Just installed a fresh system from ViciDial 12.0.2 without updates. This means it's only what's packaged on the ISO.

Here's the output of 'zypper se -t patch 2024-4321':

Code: Select all

vicibox12:~ # zypper se -t patch 2024-4321
Loading repository data...
Reading installed packages...

S  | Name                        | Summary                          | Type
---+-----------------------------+----------------------------------+------
i  | openSUSE-SLE-15.6-2024-4321 | Recommended update for firewalld | patch


This seems to indicate by the 'i' that it's already installed in the base image.

What is the firewall problem you are seeing?

check out the image on this article:

https://dialer.one/index.php/how-to-fix ... 12-errors/

It's happening on the ISO once you type "yast firewall"

That doesn't happen for me, and I have installed on two different machines so far.

I am going off what people in the community have reported to me in my discord and skype groups, and its been multiple people, about half a dozen or so. But I believe the latgest SVN may have fixed it.

carpenox wrote:check out the image on this article:

https://dialer.one/index.php/how-to-fix ... 12-errors/

It's happening on the ISO once you type "yast firewall"

I can't reproduce it on 12.0.2.

yea i just put the iso on a virtualbox and i didnt get the error either, shrug

So we have run into an issue, but not sure if its with vicibox 12 or asterisk 18 but I figured I post it here anyways.

We have run into an issue on two different vicibox 12 installs where after a call, the agent presses hangup customer, the call gets hung up, but the agent remains in dead call.

Tried both on meetme and CONFBRIDGE.

both on svn 3899 (We also tried 3899 on an older vicibox and it works fine so I don't think its the SVN)

What we have noticed is when the agent interface sends agc/vdc_db_query.php, its not liking the start_epoch and it gives us an http error 500. if we remove start epoch it gives us a correct response. also, we noticed its sending the actual channel name, which it seems to also do on other systems, so I don't think thats the issue, but if we change start epoch value to some numbers instead of the channel name it also seems to respond.

I have seen that old firewalld issue where it doesn't like dealing with 50K+ entries in an IPSet. That's indicative of firewalld running at 100% CPU load.

Only real fix for that is to turn off the voipbl part of VB-Firewall in the crontab.

I tested this with several manual dial calls on a brand-new VICIbox 12.0.2 install last night and I couldn't replicate the issue. Could you share more details on what kind of calls these were and any other settings that you think may trigger it?

These were normal outbound calls from a campaign using ratio dial method and with routing extension 8369.
Any time an agent pressed hangup it was trying to post vdc_db_query.php

We think the issue is with php not setting NULL value for start _epoch

As a duck tape fix, I believe we modified line 9677 on vicidial.php

"&exten=" + recording_exten + "&channel=" + lastcustchannel + "&start_epoch=" + MDlogEPOCH + "&auto_dial_level=" + auto_dial_level
to
"&exten=" + recording_exten + "&channel=" + lastcustchannel + "&start_epoch=0" + "&auto_dial_level=" + auto_dial_level
remove + MDlogEPOCH and set &start_epoch=0

We switched and its working perfectly, but we aren't sure what logging or other features we might have broken doing this as a work around.
As a note, we re-inported the DB from vicibox11 so not sure if there was some setting that needs to be changed for the new PHP version. I didn't see anything in system settings.

great postback alo, i will add this to the article for fixes and give you the credit for the post, do you have any website or email you want as a link for people to reach out to you or visit?

This has been fixed in svn/trunk revision 3900. The fix is in the vdc_db_query.php script, and it will overwrite the start_epoch only if it hasn't been populated or it has non-digits in it. Your posted workaround can result in inaccurate logging.

Please upgrade to the latest code and test.

Thank you very much for reporting!

awesome - good shit

anyone else having issues with FastAGI not starting with the new install?


/usr/share/astguiclient/FastAGI_log.pl --debugX
SERVER LOGGING ON: LEVEL-4 FILE-/var/log/astguiclient/FastAGIchildLOG.2025-02-06
2025/02/06-09:36:24 VDfastAGI (type Net::Server::PreFork) starting! pid(3241)
Resolved [*]:4577 to [::]:4577, IPv6
Not including resolved host [0.0.0.0] IPv4 because it will be handled by [::] IPv6
Binding to TCP port 4577 on host :: with IPv6
2025/02/06-09:36:24 Can't connect to TCP port 4577 on :: [Invalid argument]
at line 66 in file /usr/lib/perl5/vendor_perl/5.26.1/Net/Server/Proto/TCP.pm
2025/02/06-09:36:24 Server closing!