Update 3 Final: Wake Up with PUSH for the Web Client & PWA

[NickD_3CX]

Thanks. I get the point.
So basically at the moment, the primary intention of overwriting sources.list is to treat 3CX installation as an appliance as much as possible (regardless if it is installed from ISO, installed in a supported cloud provider or self-hosted).

When the rest API which has been spoken about for some time gets released, would it support triggering updates? Going via management console for 150+ setups is bit tedious (about the only time when we are not happy about the fast phase of feature additions )

Correct, that is the primary reason.

Now regarding the REST API, that we will have to see when that time comes.

 

[SKDamon]

Critical Security Update​

Update 3 contains some critical security updates and we recommend customers upgrade to update 3 as soon as possible.

Update 3 unavailable on Raspberry Pi PBX​

Raspberry is undergoing some changes which will bring future builds of its operating system in line with Debian. When 3CX supports Debian 11 (bullseye) we will look at supporting Raspberry once again. For the moment update 3 will not be available for Raspberry Pi.

Bold move... Yikes.
Any plans to keep RPi users secure? Or are we left for dead?

 

[N_G]

No there will be no more special support for PBX on Raspberry PI. So you can move to hosted or debian. Probably when 3CX supports the latest debian running on Raspberry Pi it will install but we cant give a time frame or guarantuee that it will.

 

[paurus]

No there will be no more special support for PBX on Raspberry PI. So you can move to hosted or debian. Probably when 3CX supports the latest debian running on Raspberry Pi it will install but we cant give a time frame or guarantuee that it will.

it's very sad. I bought a Pi 4 specifically for 3CX 6 months ago. now is it in the trash?

 

[Evolute IT]

No there will be no more special support for PBX on Raspberry PI. So you can move to hosted or debian. Probably when 3CX supports the latest debian running on Raspberry Pi it will install but we cant give a time frame or guarantuee that it will.

Does the SBC continues to work and be supported on Raspberry tho?

 

[SteveITS]

SBC continues to work and be supported on Raspberry

They mentioned that in the blog post: "3CX SBC will remain supported on Raspberry Pi devices. As a solution to stay on the latest update, move to Hosted by 3CX and use the Pi device as a 3CX SBC."

We had deployed a few Pis late on v16 so they are on Debian 9, and the upgrade path there is to reinstall. Which means either a site visit, or they buy another we ship to them, or we install on a VM that is easily replaced down the road. So hopefully the SBC will keep updating/working on 9 for a while longer.

 

[Anaphylaxis]

It would be nice if we could enable or disable automatic updates via Instance Manager.

I agree, there are far too few features that 3CX provides for configuration management to be stripping our instances of anything non-3CX.

 

[SyncWave]

They mentioned that in the blog post: "3CX SBC will remain supported on Raspberry Pi devices. As a solution to stay on the latest update, move to Hosted by 3CX and use the Pi device as a 3CX SBC."

We had deployed a few Pis late on v16 so they are on Debian 9, and the upgrade path there is to reinstall. Which means either a site visit, or they buy another we ship to them, or we install on a VM that is easily replaced down the road. So hopefully the SBC will keep updating/working on 9 for a while longer.

So they are fully supporting 3CX SBC on PI moving forward but not the core PBX?

Any clarification here, @Nick Galea

 

[ChrisC_3CX]

So they are fully supporting 3CX SBC on PI moving forward but not the core PBX?

That is exactly right. This of course is not to say that running the whole 3CX PBX on the Raspberry Pi won't be supported again in the future at some point.

 

[eska]

I have a question(maybe a dumb one) unrelated to the discussion above, but regarding the update. Can the update potentially lead to an incompatibility within the different 3CX apps? If one user does not get the update for the Windows client, can he or she still use it without issues?

 

[NickD_3CX]

I have a question(maybe a dumb one) unrelated to the discussion above, but regarding the update. Can the update potentially lead to an incompatibility within the different 3CX apps? If one user does not get the update for the Windows client, can he or she still use it without issues?

Technically speaking, yes, the latest 3CX Server version is tested and compatible with the latest 3CX App versions.
We do of course try to keep a certain level of backwards compatibility, but it is expected that all users must update to the latest version of the 3CX apps they are using.

 

[SKDamon]

If one user does not get the update for the Windows client, can he or she still use it without issues?

From my experience, outdated App version does not really matter. After all, the V16 client still works with V18 PBX.
But the great thing with the new V18 App is that it does not require Admin permissions to update, the only time you need Admin permissions is the Firewall dialog from Windows upon first install.

 

[Benedikt Machens]

Hi!

Yes, this is correct, on every update this will be replaced.
We have done this to avoid all the issues that have happened over the years where Debian releases a package update that might "break" your 3CX installation (like what happened with IOS PUSH last year...) and to avoid issues for package versions not existing after some time, if you have old systems and you try to upgrade them.

This aside, remember that the 3CX Instance is supposed to have ONLY the 3CX software, nothing extra. I understand the point you make on monitoring software, but we have found that a lot of times 3rd-party software, sometimes even including monitoring software, can affect the installation as a whole.

I would highly suggest you don't add additional repositories.

At the very minimum, if you add a repository for whatever reason, e.g. to install a package, immediately remove it afterwards so that 3CX does not view packages from there. This would likely still render your system "unsupported", but at least reduces the chances of breaking something.

Sorry NickD, but just no!

i know 3CX is just trying to keep things simple and easy, but you are the manufacturer of the PBX and not the Admin of the system. We (the 3CX Partners) are responsible to ensure are reliable system for the PBX and a solution for our customers. Things like overwritting soures.list (or nftables) is something you should not do! Make a suggestion on installation, but if an admin chooses to use official repositorys for faster security updates and better nftables is this our choice. In most cases it has a reason to do so and in more than 100 installations we had no problems with additional packages. And we have installed a lot to make wishes happen for our customers that the PBX could not do.


Regards

 

[NickD_3CX]

Sorry NickD, but just no!

i know 3CX is just trying to keep things simple and easy, but you are the manufacturer of the PBX and not the Admin of the system. We (the 3CX Partners) are responsible to ensure are reliable system for the PBX and a solution for our customers. Things like overwritting soures.list (or nftables) is something you should not do! Make a suggestion on installation, but if an admin chooses to use official repositorys for faster security updates and better nftables is this our choice. In most cases it has a reason to do so and in more than 100 installations we had no problems with additional packages. And we have installed a lot to make wishes happen for our customers that the PBX could not do.


Regards

I understand your point but I don't agree 100%. We need to ensure that the software, if untouched and neglected by either a Partner or Customer, remains secure and up-to-date via automatic updates, without though "breaking" because a debian repository was decided to be removed, or because the XYZ monitoring software that a Partner installed 3 years ago and has since "left" that customer who decided to do an update and break the system.

All these are real cases.

Installing any other software on a 3CX Server always rendered it "unsupported", this is commonly known and we have made it clear in the past.
All we did now is make it more difficult to do this.

From your reply, it sounds like this is what you were doing, making 3CX systems "unsupported".
I get it it though, because you're on top of things with your customers, you have made it work for you.

As you seem quite familiar with Debian, what is stopping you from writing a 3-line script adding the repo back and running it in a hourly cronjob?
Your system will still be unsupported, but that was always the case with installing 3rd-party software.

I think people are making this bigger than what it really is.

What we did is:

• Protect the users that are not so knowledgeable so there system never has dependency issues and will remain protected as long as they keep 3CX up-to-date (auto updates enabled in Management Console)
  
  
• Those who did things not recommended/supported can still do so, with one extra step

 

[Benedikt Machens]

As you seems quite familiar with Debian, what is stopping you from writing a 3-line script adding the repo back and running it in a hourly cronjob?
Your system will still be unsupported, but that was always the case with installing 3rd-party software.

Thats right and already done. But everytime this things happen during an update i feel like that someone is working against me.
Yes we have installation monitoring on our systems, because we have to SLA's to inform our customers if telephony is unavailable, and yes we rely on the default debian repositorys to keep things up to date to not have an 3 year old software package

I fully get your point that make 3CX supportable as much as you can, but why those forcing stuff on every update and not just one time on installation? Doing this that way only forces people like to me write scripts to revert this to ensure that the customer has the same solution as yesterday after an Update



Edit: Just as an anecdote "Package 'sngrep' has no installation candidate". Not every package someone wants to install from the default repo will break the phonesystem. But tools like sngrep make it fast to analyse SIP traffic when a customer has issues....

 

[Digital-Stewards]

DO people need to login to the webinterface again and manually re-install the desktop app again?
This should better be made automatically, or pushed via a button in the desktop app that there is a update. Lots of my clients don't use the webinterface.

 

[NickD_3CX]

DO people need to login to the webinterface again and manually re-install the desktop app again?
This should better be made automatically, or pushed via a button in the desktop app that there is a update. Lots of my clients don't use the webinterface.

No, After the 3CX Server Update is installed, along with it there is the new version of Desktop App. Once each user logs into their Desktop App, as soon as it detects the newer version, it will prompt the user to install it.
Even if they don't press the update button, which is prominently placed at the top of the Desktop App, so you can't miss it, when they relaunch the app it will auto install it.

 

[NickD_3CX]

Thats right and already done. But everytime this things happen during an update i feel like that someone is working against me.
Yes we have installation monitoring on our systems, because we have to SLA's to inform our customers if telephony is unavailable, and yes we rely on the default debian repositorys to keep things up to date to not have an 3 year old software package

I fully get your point that make 3CX supportable as much as you can, but why those forcing stuff on every update and not just one time on installation? Doing this that way only forces people like to me write scripts to revert this to ensure that the customer has the same solution as yesterday after an Update

Because this helps "reset" things that someone may have done in the past and had forgotten it's there and comes back to bite them much later. You'd be surprised how often this happens.

 

[Benedikt Machens]

You'd be surprised how often this happens.

Not really, thats why we sell "Managed service" and customers have no admin access

 

[GoranC]

Hello NickD_3CX,

You need to understand that you are selling telephony system, hence you can't make changes like this in order to "boost" security of customers because we (MSPs) are bound by contracts to provide certain services to the customers, which includes 3cx PBX + additional things on top of that.

I understand that our PBX will be unsupported if we modify the system, but we need to make those changes to meet our contractual obligations that were made prior to these changes...

Furthermore, you can always give an option to the customer without much knowledge to use your recommended best practice approach, but you have to allow others to use 3rd party software at their own risk.

Now you'll probably repeat the above "As you seem quite familiar with Debian, what is stopping you from writing a 3-line script adding the repo back and running it in a hourly cronjob?". We are not here to fight with 3cx about ownership of the virtual machine, I don't want to develop/run scripts on 50-100 PBXs after every update because you think it's fine to make changes like this. We where just developing ansible playbook for automatic welcome email update on all our PBXs, when we suddenly realized that we can't use certain packages anymore...

As someone already said, SNGREP as a MUST have software on any VOIP system is not available anymore because of these changes, which is ridiculous considering how powerful the tool is, especially compared to activity log which can't be tracked live compared to SNGREP.

Instead of giving us a quick solutions for things like:
1. Show if PBX operates in IN or OUT of office hours mode (Solution: additional field in PBX status on dashboard???)
2. SNMP/Rest API for basic monitoring, so we can see problems before our customer report them to us.
3. Provide us with a way to mass update welcome email on all PBXs. (Solution: allow us to do this on customer portal?)

You're applying updates which only further complicate things for all of us, and we again have to waste time to meet our obligations, only because you think it should be nice to enforce security policies which are "recommended" by you.

Regards
Goran