Hi all! This ‘b’ does not mean Beta at all. The Asterisk version schema can be a little confusing in places, but I assure you, we (TheWebMachine Networks) do not employ beta builds. We use the same Sangoma repos and the same core build of the FreePBX distro as you’d get with an ISO install, spare the cloud-init utilities and drivers necessary for the AWS environment, plus our SmartUpgrade utility, which aids in common tasks. In this case we are using the same asterisk-version-switch command as any other FreePBX system from the same Sangoma yum repo. We wrap around this command primarily to deal with a LONG time bug in the asterisk-version-switch utility that fails to reinstall the correct IMAP drivers if a system is using IMAP VM storage. We also bother to tell the user which version they are currently on before letting asterisk-version-switch blindly prompt for a selection.
To be clear, AWS FreePBX from TheWebMachine Networks is a “true to Distro” build and we are a Sangoma Software Partner. All AWS FreePBX customers are welcome to contact our support staff via our website at any time. Sorry for any confusion this caused anyone!
We’ve taken a deeper look into this. We lookup the actively running version by asking asterisk itself:
asterisk -rx "core show version"
By default, this captures an entire line of data…
asterisk -rx "core show version"
Asterisk 16.9.0 built by mockbuild @ jenkins7 on a x86_64 running Linux on 2020-03-21 00:51:54 UTC
So, our code does a cut from chars 10-17:
currentasterisk=`asterisk -rx "core show version" | cut -c 10-17`
…this would grab “16.9.0 b” by mistake because the versioning can reach numbers like “16.10.0” or “16.10.10”, which would require that many chars (up to 8) to capture entirely. As you can see, this means it is merely cosmetic how SmartUpgrade is showing this accidental start of the word “built.” We’ll look to fix that moving forward.
# asterisk -x "core show version"
Asterisk 17.3.0 built by mockbuild @ jenkins7 on a x86_64 running Linux on 2020-03-21 01:37:45 UTC
# asterisk -x "core show version" | cut -d ' ' -f 2
17.3.0
Oh, yeah…for sure that’s how we’ll fix it. That particular line has been around, literally, since day one of the code; one of those “write it and forget it” bits. Most of the checking on asterisk versions take just the major version into account, anyway. There had never been a known cause to address it, specifically, until this cosmetic bit was pointed out.
Pissy? No, I wasn’t pissy. I initially took your comment as sarcastic and was replying in kind. However, would I really be in the wrong if I had been even just a little disappointed that you decided to randomly step into a thread to contribute little more than the P.C. equivalent of “how can we be sure your code isn’t shit?” Was that comment really helpful to anyone? In a forum that is supposed to be focused on the community helping each other out, posting such things serves no one. At best, it contributes nothing of real value to the discussion. Is it safe to assume then, based on your comment, you’ve never make a mistake in anything you’ve ever written? I’d be more suspect of someone who suggests - especially by ‘virtue’ of shaming others - that they never make mistakes or they’re immune to simple human clumsiness, regardless of the context. You’re usually so helpful around here. I find it disheartening to see such a disparaging comment out of you.
The bug was entirely cosmetic. The line/variable in question isn’t used beyond the display of version information to the user in a centralized location…there was nothing to “bite” anyone, programmatically speaking. If there had been, that most likely would have been found in testing prior to release. We use a similar tiered strategy (release, edge, etc) as Sangoma…but that doesn’t mean things don’t occasionally slip through. A quick browse of any project’s issue tracker is plenty evidence of that. Was the cosmetic flaw in displaying shorter version numbers confusing? Yes, without a doubt. Would it have brought down a server? Not a chance! Let’s not conflate the matter.
And, while we’re at it, “three weeks response time” implies that this is, specifically, our support forum or that this is the preferred method for our customers to receive support on our release. We do not intensely monitor this forum for every new post, as we support our release via our own channels. We posted an explanation here after the customer contacted us a couple days ago via the normal support channels and we addressed the inquiry there…we were simply unaware of this post prior to that time. For the sake of completeness, and in case someone else stumbles upon this thread via random search, we wanted to provide the answer here, as well. We’ve done this in the past - ensuring that an answer is provided here, even if the customer does reach out to us directly - as a matter of practice. “Better late than never.” It can save the next person a lot of headache if they end up here instead of our own direct support channels.
Of course, there’s nothing wrong with someone seeking guidance here for general FreePBX matters (for obvious reasons), but this one just happened to be specific to our release and a utility included within it. This is why all customers are advised in the AWS launch instructions and all other documentation we provide to reach out to us directly with any questions or concerns. We typically respond within minutes via those methods. We do skim through this forum as time allows, in case this type of post pops up, but it isn’t at the top of our priority list and we’ve had a lot of customers scrambling with all the changes the pandemic brought about…that has kept us quite busy, and a little more absent from this forum, as a result. It is unfortunate that the customer had to wait so long for a definitive answer, but all we can do now is try to monitor this forum better moving forward to catch these posts sooner. On 5/19, billsimon suggested (twice) that the customer reach out to us for assistance. They finally contacted us directly for the first time on 6/17…nearly a month later.
That particular line has been around, literally, since day one of the code; one of those “write it and forget it” bits. Most of the checking on asterisk versions take just the major version into account, anyway. There had never been a known cause to address it, specifically, until this cosmetic bit was pointed out.
You’re usually so helpful around here. I find it disheartening to see such a disparaging comment out of you.