SAIL Community Supported PBX

I'll look at it.   You're right, it should burp.

I've been playing around with a 64bit arm .img install for RaspberryPi.   You've always been able to install sark on the 64 bit Pi 4 but, to make it easier, we've put up a ready-to-run image here:-

http://www.sailpbx.com/sail/raspi-arm-64-img/

Download it and burn it onto a microSD card with the RaspberryPi imager and it should just run on any Pi 4. 
N.B.  The image inflates to about 7.6Gb so you'll need a micro SDcard of at least 8Gb.

SSH login creds are

UID sark
PWD sarkadmin

The front-end browser is just the same as always.

UID admin
PWD sarkadmin

No, I don't think we'll drop it.   It's difficult to know for now what will happen with Debian 12 and Asterisk.  I suspect it will come back in 13 and someone will do a backport to fetch it into 12 but that's just a guess so we'll have to see.

I've just tidied up the 6.2 installer for Ubu 22.04 and Deb11 and it looks OK.  You will see this appear as 6.2.0-34 or 35.   These will be the last few releases for 6.2 and it will move into maintenance as we begin to roll out 6.5 over the next few months. 

I've also been playing around with a 64bit arm install for RaspberryPi.   You've always been able to install sark on the 64 bit Pi but we've put up a ready-to-run image here:-

http://www.sailpbx.com/sail/raspi-arm-64-img/

Download it and burn it onto a microSD card with the RaspberryPi imager and it should just run on any Pi 4. 
N.B.  The image inflates to about 7.6Gb do you'll need a micro SDcard of at least 8Gb.

SSH creds are

UID sark
PWD sarkadmin

The front-end browser is just the same as always.

UID admin 
PWD sarkadmin
 

Here's some further information and observation on the latest SARK/SAIL packages

Ubuntu users only

The latest SARK 6.2 will install on Ubuntu 20.04LTS (Focal Fossa) or Ubuntu 22.04LTS (Jammy Jellyfish). It may install on other releases but these are the two which we currently test with and have packages for.

Debian users only

Debian has been a little bit of a rollercoaster ride for SARK and Asterisk over the last few years.-

Debian 10 (Buster) did not include the package for our preferred mail agent (ssmtp). As far as we know this was because ssmtp was unmaintained at that time. It was later re-included in Debian 11. Also, in Buster, Debian changed from using iptables to nftables. The problem for SARK is that we use the shorewall firewall which only runs with iptables. Furthermore, iptables can do packet searching whereas nftables can not. In spite of these changes, SARK/SAIL will install fine on Buster but you will need to use an alternative mail agent if you wish to do things like voicemail-to-email and you will need to set iptables as your preferred filter (see below).

Debian 11 (Bullseye) installs without issue but you still need to select iptables as your filter.

Debian 12 (Bookworm) does not include the Asterisk PBX package at all (you're kidding me, right? - Nope) Again, this appears to be due to a lack of resource to maintain it within the Debian group. If you want to know more then you can look at this thread..
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031046

It may be that the next release - Debian 13 (Trixie) will have the necessary work done to include Asterisk but for now, if you want to run Asterisk under Debian12, then you'll likely need to install it from sources or from a third party package.

Summary

We ourselves have pretty much exclusively moved to Ubuntu for our own development and deployment.  Almost all of our customer systems are Ubuntu/AWS/ARM based instances.   Right now, it's just less of a hassle to deal with.   

Ubunru 18.04 is the last stable release

Ubuntu 20.04 is just about ready and we use it in production but it still has a few glitches which we're currently ironing out

Ubuntu 22.04 is pretty much in the same place as 20.04.

We're doing some further testing this week and I'll publish an update once we've finished.

The problems we've seen have been minor permissions issues and so forth but frustrating if you're doing a first time install.

OK, I think we have a fix for this.  We're testing it in source at the moment but you can try it too if you wish.  There are two modules you need to change. 

The first module is /opt/sark/scripts/getmaclist.  Take a copy of it and save it somewhere safe.  Now open the module in your favorite editor and completely replace the existing code with this new code:-

#!/bin/sh
# get a list of macs amd manufacturers from IEEE
#

[ ! -e /opt/sark/www/sark-common/manuf.txt ]  && touch /opt/sark/www/sark-common/manuf.txt
chown www-data:www-data /opt/sark/www/sark-common/manuf.txt
curl -L -s "http://www.sailpbx.com/sail/public/manuf.txt" > /tmp/manuf.txt
ret=$?
if test "$ret" != "0"; then
     logger SARKgetmaclist - **** Link fail - Could not fetch new manufacturer MAC DB ****
     exit 4
fi   

if [ -s /tmp/manuf.txt ]; then
        diff /opt/sark/www/sark-common/manuf.txt /tmp/manuf.txt
        if [  "$?" -ne "0" ] ; then
                mv /tmp/manuf.txt /opt/sark/www/sark-common/manuf.txt
                logger SARKgetmaclist - updated manufacturer MAC DB
        else
                logger SARKgetmaclist - manufacturer MAC DB up to date
        fi
else
        logger SARKgetmaclist - **** Could not fetch new manufacturer MAC DB ****
fi

Next you must make a small change to /opt/sark/php/sarkextensions/view.php

At, or around, line 1956 you should find the following line

$short_vendor_cols = explode($delim,$vendorline,3);

You should replace this line with...

$short_vendor_cols = preg_split('/\s+/',$vendorline,3);

That's the changes done.  Now you can run the maclist...

sudo rm /opt/sark/www/sark-common/manuf.txt
sudo sh /opt/sark/scripts/getmaclist.sh

You should now have a new file in /opt/sark/www/sark-common/manuf.txt.  It will look a little different to the MAC list you used to have.

Now go ahead and add your new Yealink.  It should be picked up OK.

Let me know how this works for you.

Apologies for the late reply.  We've been moving offices and it took longer than we planned.  Anyhow, we're settled now.  I just did a from scratch install of Ubuntu 22.04 on a VM here.  It appears that our MAC/Manufacturer source is giving problems.   I'll address it with some haste and come back to you.  Thanks for calling this in to us.

Usually if it is "LAN=/" then something went wrong in the IP discovery.   I haven't used Proxmox for quite some time and my memory is hazy.  The example I showed you above was from a live AWS Debian instance.  We also use Parallels for local testing and it behaves the same as AWS.

I'd be interested to see what "ip a" gives on your Proxmox instance. That may give some clues.



   

Hi there,

All good here.  The local.lan file should show the subnet CIDR.  Like this

root@ip-10-0-1-34:~# cat /etc/shorewall/local.lan
LAN=10.0.1.0/24

A routine called setip (/opt/sark/generator/setip.php) runs as a systemd task (called setlan) each time you reboot the box.  Among other things, it attempts to figure out the local network CIDR and set it into local.lan

Things which can sometimes confuse it are multiple NICs on the box with the second (or higher) NIC attached to the LAN and NIC 0 empty.

The easiest way to see what it's doing is to simply run it inline and then look at syslog.

php /opt/sark/generator/setip.php
Syslog should look something like this

May  8 15:31:51 ip-10-0-1-34 php: SRK setip Interface name on this node: eth0
May  8 15:31:51 ip-10-0-1-34 php: SRK setip IPV4: 10.0.1.34
May  8 15:31:51 ip-10-0-1-34 php: SRK setip staticIPV4:
May  8 15:31:51 ip-10-0-1-34 php: SRK setip Network address: 10.0.1.0
May  8 15:31:51 ip-10-0-1-34 php: SRK setip netmask: 255.255.255.0
May  8 15:31:51 ip-10-0-1-34 php: SRK setip CIDR: 24
Hope this helps

Hi there

Good question.   6.1 optionally allows different MOH files for each tenant.  You can load the individual tenant MOH files in the tenant edit panel.  The sound files for each tenant are saved in /usr/share/asterisk/moh-{tenant name} and a reference is generated in sark_moh.conf

As you know, in Asterisk the sound directories are abstracted in that they are defined in /etc/asterisk/musiconhold.conf and, in the Digium sample file, there is a [default] entry which points to the sample moh files in the directory /usr/share/asterisk/moh

It is also the case that Asterisk will ignore empty MOH directories.

The confusion arises due to Asterisk defining an MOH class "default" (in the sample musiconhold.conf) and SARK having a "default" tenant (so it also has a class "default" in sark_moh.conf).  However, as long as the SARK entry is an empty directory then it gets ignored and Asterisk uses the Digium supplied sample music.  If, on the other hand, you save a music file into moh-default then that will be used instead.

It is, however, confusing so thanks for the question and I hope this above helps.




 

Yes, they will always differ.   GitHub has what we are working on right now.  Packagecloud has what we regard as a current release.   So GitHub will always be ahead of packagecloud.

You can of course download a later version from GitHub and install it but it may not be what we would call a release.   It also may have bugs that we didn't fix yet.   

Packagecloud releases will tend to go in jumps.   The next packagecloud release may, as an example, be -30.   Whenever we get to a point in GitHub where we think we have a stable release then that's when we upload it to packagecloud and it becomes the current release.

Hope this helps.
 

Further to my last post, you will find new dpkgs on sailpbx.com at

http://www.sailpbx.com/sail/sail-6.0/debs/

There are both amd64 and arm64 packages for sailhpe_6.0.0-8.

Please download and install the correct one for your architecture and let me know if it works for you.  We've tested it here and it works for both preselect and transformation mask.

Before you begin, ensure you have backed up the existing image, just in case of accidents or further issues.

Regards

Answering your first reply:-

QuoteThe description says
"Optional: 1 or 2 digit pre-select code which you can use to seize a specific trunk (must be systemwide unique)"
And I see you have a ":" after the number but that also did not work.
The pre-select and the dial plan in the phone worked fine on earlier versions of Sark. Doing a snGrep during a call it does not select the correct trunk. Why pre-select? To get the right DiD associated to the call for the called party to ring back on the correct line. Unless there is another way to do it?

Either method should work, however, it looks as tho' a bug crept in in -6 and we missed it.   I'm looking at it now and will get back with you as soon as I know more.   Hopefully, we should be able to squash it fairly quickly.

Thank you for your help with this, it's much appreciated.

SARK won't automatically strip a preselect or prefix that isn't recognised by the upstream carrier, you have to tell it to do so. 

You do this in the Trunk definition of the trunk which will carry the call (WD_House) in the Transformation Mask.  To strip 91 you would enter the following in the field:-

91:
I also wonder why you are using a preselect at all.  Such cases are quite rare. you can usually delineate just by using a suitable dialplan in the route.

Finally, regarding your question about the failed installation of the -24 release.  -24 is not yet on our repos, our last stable release is -19 so I assume you are install a downloaded version.  If this is the case then you need to tell dpkg where the package is locally e.g.

dpkg -i /home/{someuser}/sail_6.2.0-24+deb10u1_all.deb
Hope this helps

Cool, thankyou and sorry for the long wait.