Status of the project

[smn]

I want to completely move away from using FreePBX for various reasons. I have not been very active with FusionPBX for awhile so not in tune with what has been happening as of late. The last time I used it (and still do) was for v4.4. I have not tried v5 yet.

I am also looking at other projects such as ASTPP, which compliments Fusion nicely. If anyone cares to share their opinion about that I would also be interested. I am pretty good at coding and debugging PHP so I prefer projects that welcome my contributions.

 

[hfoster]

I can say confidently, that Mark and the rest of the FusionPBX team are more than welcome to accept pull requests for things that make a lot of sense.

 

[smn]

I can say confidently, that Mark and the rest of the FusionPBX team are more than welcome to accept pull requests for things that make a lot of sense.

Maybe it was just a coincidence but almost every time I submitted pull requests his reaction was to remove the related features. I know how to get rid of features I don't like on FusionPBX now. I just need to submit pull requests on them.

 

[Dan]

What features did Mark nix? Mind linking to the pull requests?

 

[hfoster]

Adminer and that Text Editor (can't remember the name) were removed because they just kept on being sources of exploitation and vulnerabilities, especially when people can just use SSH and psql/vim/emacs and do the same thing

 

[Dan]

Yeah, those are 3rd party modules and defending them from security issues is hard and a bit out of scope IMO, especially when they are causing FusionPBX instances to turn into bots :c

Mark has been great about accepting my pull requests, but if I add a feature and they decide to refactor that code I have had the feature I add disappear without warning before, then I get to rush to rewrite it and pull request it.

 

[smn]

What features did Mark nix? Mind linking to the pull requests?

CentOS, MySQL, Adminer. There may have been some other ones as well. Once or twice could be a coincidence but he did that to me at least 3 times. To be fair, I think those features were on life support at the time I submitted my pull requests so I think they probably just sped up his decision.

The CentOS one was understandable and I'm ok with using Debian. I'm still not much of a fan of PostgreSQL. This is the only project I deal with that still uses it. I have tried to love it but just about everyone seems to be using MariaDB now a days. I think this project would be more active if it used MariaDB but that's just my opinion.

 

[hfoster]

Kinda hamstrung by FreeSWITCH there. Your choices are PostgreSQL core, or use an ODBC module to connect to MariaDB, though I'm pretty sure a mod_mariadb now exists but it's very new.

Same with CentOS/Debian for a while. They stopped targetting CentOS so building it was becoming a pain, SignalWire rejuvenated the CentOS repo a bit....but then Red Hat came along and pretty much axed CentOS anyway.

 

[smn]

Kinda hamstrung by FreeSWITCH there. Your choices are PostgreSQL core, or use an ODBC module to connect to MariaDB, though I'm pretty sure a mod_mariadb now exists but it's very new.

Same with CentOS/Debian for a while. They stopped targetting CentOS so building it was becoming a pain, SignalWire rejuvenated the CentOS repo a bit....but then Red Hat came along and pretty much axed CentOS anyway.

Freeswitch fully supports both. Not hamstrung at all. I don't think PostgreSQL is part of core anymore. It's a separate module now just like mariaDB. Setting up ODBC is not difficult.

 

[hfoster]

PostgreSQL *for* the core. As in your session tables, etc, for Master/Master BDR replication and seamless failover, etc. For a long time there was only ODBC and mod_pgsql.

Regardless, they're both SQL servers so it's not really a massive barrier to entry.

 

[smn]

PostgreSQL *for* the core. As in your session tables, etc, for Master/Master BDR replication and seamless failover, etc. For a long time there was only ODBC and mod_pgsql.

Regardless, they're both SQL servers so it's not really a massive barrier to entry.

There are replication options for MariaDB/MySQL as well and those are also probably more commonly used than anything PostgreSQL has.

 

[hfoster]

Eitherway, it's such an insignificant part. SQL is SQL for the most part, and the only obvious difference is that PostgreSQL usually forces unix auth, MySQL/MariaDB with it's own auth. Changing the installer to suddenly use MariaDB would just result in a ton of people heading here wondering why the docs and 10 years of snippets are not correct anymore wqhen it comes to resetting a password or using the numerous scripts people have created.

What probably puts more people off is that it's a mature product, with active commercial and individual users. There's very little scope for innovation here, simply boring box ticking commits. We have many many clients using FusionPBX, and we urge them to submit features they desire and we have practically nothing left to include from the customer perspective.

(I would like to see 2FA, but that's another drama for another day).

Also, it's in a very old fashioned style procedural PHP format which I doubt you'll find many programmers wanting to work on these days. I don't even think about PHP without using Symfony now, and I know people are the same with Laravel.

 

[Dan]

Freeswitch Core db should be in SQLite in ramdrive for best performance IIRC, and each profile should be on its own separate SQLite db, especially if your putting different tenants on different profiles to scale Freeswitch.

We did try Postgres for Core and profile databases, but it was writing 1 to 3MB/s to SSD at all times (with an order of magnitude less read activity, 10KB/s to 200KB/s) and performed much slower than SQLite.

MySQL in FusionPBX is just Daniel Lucio with Okay.com.mx keeping MySQL and CentOS/Red Hat Enterprise Linux support tested and functional I believe, but it's not a recommended configuration from FusionPBX iirc.

I've been happy in the Debian realm for a decade now, most of what I support is on Postgres or SQLite with the exception of InvoiceNinja and the Ubiquiti UniFi controller (shout out to MongoDB for making me use backups to get things working again, ugh ).

 

[smn]

Freeswitch Core db should be in SQLite in ramdrive for best performance IIRC, and each profile should be on its own separate SQLite db, especially if your putting different tenants on different profiles to scale Freeswitch.

We did try Postgres for Core and profile databases, but it was writing 1 to 3MB/s to SSD at all times (with an order of magnitude less read activity, 10KB/s to 200KB/s) and performed much slower than SQLite.

MySQL in FusionPBX is just Daniel Lucio with Okay.com.mx keeping MySQL and CentOS/Red Hat Enterprise Linux support tested and functional I believe, but it's not a recommended configuration from FusionPBX iirc.

I've been happy in the Debian realm for a decade now, most of what I support is on Postgres or SQLite with the exception of InvoiceNinja and the Ubiquiti UniFi controller (shout out to MongoDB for making me use backups to get things working again, ugh ).

The Freeswitch SQLite files are easily corrupted, like when the server hard reboots for whatever reason. That can happen even in datacenters with redundant power. Server hardware fails sometimes too. That is reason enough for me to not want to use SQLite even though the fix is easy. Just delete all the files in the /db directory and restart.

 

[smn]

Eitherway, it's such an insignificant part. SQL is SQL for the most part, and the only obvious difference is that PostgreSQL usually forces unix auth, MySQL/MariaDB with it's own auth. Changing the installer to suddenly use MariaDB would just result in a ton of people heading here wondering why the docs and 10 years of snippets are not correct anymore wqhen it comes to resetting a password or using the numerous scripts people have created.

What probably puts more people off is that it's a mature product, with active commercial and individual users. There's very little scope for innovation here, simply boring box ticking commits. We have many many clients using FusionPBX, and we urge them to submit features they desire and we have practically nothing left to include from the customer perspective.

(I would like to see 2FA, but that's another drama for another day).

Also, it's in a very old fashioned style procedural PHP format which I doubt you'll find many programmers wanting to work on these days. I don't even think about PHP without using Symfony now, and I know people are the same with Laravel.

It would be a total non-issue if Fusion abstracted the DB entirely by using Eloquent or Doctrine, but there is probably zero chance of that happening.

 

[hfoster]

At that point, it wouldn't really be FusionPBX. It would be it's successor. There's probably a whole load more changes I would recommend than an ORM too!
I would love to work on a more modern approach if I had the time.

 

[DigitalDaz]

The Freeswitch SQLite files are easily corrupted, like when the server hard reboots for whatever reason. That can happen even in datacenters with redundant power. Server hardware fails sometimes too. That is reason enough for me to not want to use SQLite even though the fix is easy. Just delete all the files in the /db directory and restart.

If you are running it in tmpfs there is no need to delete anything, it went when the reboot happened

 

[Dan]

@DigitalDaz is on point, @smn if you put the core db in ramdrive (eg: /dev/shm with some tweaking) or /tmp it will not exist when you reboot, and Freeswitch will create the file.

I haven't had SQLite corrupt itself in quite a while, whether its being used by Freeswitch with tons of writes per second, Synapse (Matrix homeserver) with many writes, or on client devices like Signal Desktop, Teams Desktop, Element or another electron based app. When this has happened in the past, its usually indicative of the underlying SSD or hard drive failing!

 

[smn]

If you are running it in tmpfs there is no need to delete anything, it went when the reboot happened

Is there any downside to that? There must be some reason that is not done by default.

 

[smn]

@DigitalDaz is on point, @smn if you put the core db in ramdrive (eg: /dev/shm with some tweaking) or /tmp it will not exist when you reboot, and Freeswitch will create the file.

I haven't had SQLite corrupt itself in quite a while, whether its being used by Freeswitch with tons of writes per second, Synapse (Matrix homeserver) with many writes, or on client devices like Signal Desktop, Teams Desktop, Element or another electron based app. When this has happened in the past, its usually indicative of the underlying SSD or hard drive failing!

There is nothing wrong with the drives. Not using SSD. Happens almost every time there is a hard reboot/reset. If it's not happening to you it may be because your server is not very active or doesn't have a lot of stuff configured. Just guessing. The server it always happens on for me has a bunch of domains and lots of stuff going on. I think that putting the files in /tmp would fix it as long as there are no major downsides.