FreePBX 16 - Housekeeping and Security


#10

Please provide (and update) an installer tarball at the normal location (http://mirror.freepbx.org/modules/packages/freepbx/freepbx-16.0-latest.tgz) as has been the norm for past beta’s so those of us maintaining alternate distributions can get to work on necessary changes also.


(TheJames) #11

There is no magic to the tarball… note 16.0.10.6 was the latest tag on github

wget https://github.com/FreePBX/framework/archive/refs/tags/release/16.0.10.6.tar.gz
tar -xzvf 16.0.10.6.tar.gz
mv framework-release-16.0.10.6 freepbx
tar -czvf freepbx-16.0-latest.tgz freepbx

With those commands…
image tarfile :slight_smile:


#12

You‘re still staying with CentOS? I had hoped the recent chaos with RHEL/CentOS would be the final nail in the coffin and the (overdue) switch to something predictable and reliable like Ubuntu LTS would finally be announced :frowning:

CentOS with its aging PHP components and constantly shifting release timeframes has been troublesome for the FreePBX distro multiple times if I recall correctly…


(TheJames) split this topic #13

8 posts were split to a new topic: Discussion: Open ports and asterisk


Discussion: Open ports and asterisk
(TheJames) split this topic #16

A post was merged into an existing topic: Discussion: Open ports and asterisk


#21

Is there a way to remotely (from a script) determine what the latest release available is in?:

https://github.com/FreePBX/framework/archive/refs/tags/release/


(Matthew Fredrickson) #22

Hey,

Sorry I missed this question.

For now, We’re still sticking with CentOS 7.x as the release base for FreePBX. It was not without much thought and concern that that decision was made.

We originally wanted to target CentOS 8.x but the whole Streams thing messed around with that goal and so until one of the CentOS 8.x based forks gets a little more stable we’re going to stick with CentOS 7.x but add updated versions of PHP and other necessary packages for the PHP 7.x upgrade.

Matthew Fredrickson


#23

Are you also updating the mariadb version?

For us non-distro users, we have to dumb-down the db defaults of “modern” mariadb installs to match the distro’s MariaDB v5.5 default settings.


#24

Thx for this heads-up. Good to know.
We also wish there was better support for postgres, since thats the standard database in our realm.


(Tom Ray) #25

How about some actual QA? I know there is supposed to be QA but too many simple things are being either ignored or not checked. From Advanced Recovery and the Warm Spare a few months back to now.

The Chan_SIP to Chan_PJSIP mass convertor has a pretty big bug. It is generating the outbound_proxy setting wrong. Per the Asterisk WIKI and the PJSIP configuration the outbound proxy should be a FULL SIP URI with the ;lr tag at the end (\ is needed to escape ; ) instead it is just the IP:port.

Things like this should not be something QA is missing, at all. It seems to happen way too much.


(Lorne Gaetz) #26

I don’t remember seeing this reported, what is the ticket number?


(Tom Ray) #27

I just found it. I haven’t had a chance to open a ticket yet but then again, I’ve got tickets from 4 years ago I was assured would be handled by the CFO. Still open. I’ll report it when I have the chance.


(Jared Busch) #28

Yeah, I have zero confidence that things are ever going to be handled in any kind of reasonable timeframe.

Example: @lgaetz suddenly hit a year old ticket of mine and now it will be closed in 5 days because I do not have time to respond immediately? I mean I would have to recreate the entire scenario at this point.
https://issues.freepbx.org/browse/FREEPBX-21590


(Jared Busch) #29

Supposed to be, Corportate stated “there is”, and reality are 3 completely unrelated realities, when it comes to this project.


(TheJames) #30

He didn’t ask you to reproduce it… He asked basically why can’t you.

Based on the other replies it looks like the ticket is basically a won’t fix…


(Tom Ray) #31

I agree, that is looking how this is going. However, why wasn’t this handled that way back in June 2020? The fact that the ticket system is poorly managed is not helpful for anyone. Not the users, contributors or the developers that need to do the work.

If this ticket is truly a Won’t Fix, then comment on that and mark it Won’t Fix so it’s closed out. The current ticketing system looks like a mess of unattended and ignored bugs and feature requests. It really makes it look like no one is paying attention and there’s no real structure.


(TheJames) #32

Just before I left I closed out anything over 2 years old. That seemed to be the consensus that anything within the last two years is probably workable but anything older may have already been taken care of. That said I know we did triage calls every Tuesday where we would go through all of the open bugs and build out what needed to be done. I don’t know what the current engineering plan is obviously. I have noticed in watching commits and pull requests which I still do that many tickets are done under FREEI which are internal tickets so you can’t necessarily see the relation or reasoning behind it. One of the things I saw recently made zero sense to me but it was an internal ticket so any explanation to why can’t be publicly seen. I hate to say this but one of my reasons for leaving was the project being controlled by project management which is 100% business case focused. This means all engineering decisions had to have a business case related to the bottom line. Some things that made it into 15 were forgiveness over permission.


(Jared Busch) #33

That was obvious from the start.

You don’t show why/how things cause a problem with having a scenario in place to (re)produce it. Also, somehow I didn’t have a thread here first. I usually do. Annoying.


(Jared Busch) #34

Would this be like the conversation from certain Sangoma members in the Open Source Lounge meetings 100% commenting on how things can be sold?


(Jared Busch) #35

Seem to match what I see. My still open tickets.

image