Has the 3CX SBC started rewriting /etc/3cxsbc.conf?

[JustinSubertETS]

Looking at my /etc/3cxsbc.conf files I have recently noticed that some of them are being rewritten, being denoted by the lines:

# Automatically generated SBC config file at 23/08/2019 2:05:09 AM.
# This file is rewritten on every restart so don't try to edit it.

This is a major headache to me as I manage this config via Ansible.

Is this an intended change and, if so, does anyone have any suggestions how I deal with config management in future?

Thanks

 

[cobaltit]

Looks pretty intentional based off the comments . This is part of the v16 SBC upgrade.


As far as change management, that's what the 'Push Config' button on the SBC trunk is for.

 

[JohnS_3CX]

Hi Justin, the SBC is controlled by your PBX so the settings get rewritten and updated to maintain the SBC in the intended state.

 

[JustinSubertETS]

Thanks for the replies guys.

Here is my challenge.

I believe that I need to provide a valid /etc/3cxsbc.conf in order to initially connect a new SBC to the PBX. With this in mind I elected to manage this file using Ansible, which is now in competition with 3CX over who owns the file.

I can understand the motivation for making settings configurable from the PBX but the chosen implementation has significantly complicated my setup for at least the following reasons:

1. Where I was able to increase the SBC log levels from "ERR" to "NOTICE" in one place for all SBCs, now it appears that I need to individually configure my 20 SBCs across my 4 PBXs to achieve the same result.
2. I have, hopefully temporarily, lost the ability to manage the SBCs via Ansible, effectively blocking the management of existing SBCs or deployment of new SBCs

I wonder if it would have made more sense to separate out the PBX owned configuration into an alternate file, removing the conflict between local administrator configuration PBX managed configuration.

I think that it's worth noting that all my SBCs are running v16, but it's only the ones connected to v16 PBXs that are exhibiting this issue, the ones connecting to v15 PBXs are not yet affected. This means that I will need to hold these PBXs back at v15 until I have found a solution.

Do I just change the permissions on /etc/3cxsbc.conf to prevent the SBC from overwriting the Ansible configuration?

Is anyone else out there using Ansible and have found a solution to this issue?

Thanks

 

[cobaltit]

I'm not really sure what you are looking for. Clearly 3CX has one way and one way only they want SBC's to be managed. You need to decide if you want to do it the 3CX way or your own way, at the risk of creating a potentially unsupported configuration.

I wonder if it would have made more sense to separate out the PBX owned configuration into an alternate file, removing the conflict between local administrator configuration PBX managed configuration.

I don't see this happening. The goal is to provide a simple and standardized method of managing the SBCs. The extra effort it takes YOU to manage your 20 SBCs pales in the big picture. Besides, in your example, why would you want to increase the log levels across all SBCs? I doubt you are having issues at all sites at once, and if you are, you can still increase logging at one or two sites should suffice if you imagine them being the same issue. I think your only feasible option (short of coming up with your own hack) is to post in the ideas section to enable bulk editing of the SBC trunks. Then you would have the same ability as you have currently with Ansible.

 

[ivank]

Do I just change the permissions on /etc/3cxsbc.conf to prevent the SBC from overwriting the Ansible configuration?

Hi.
Use /etc/3cxsbc.conf.local to store your personal settings. This file has higher priority than standard config.

 

[cobaltit]

Oh nice. Problem solved!

 

[JustinSubertETS]

Awesome, /etc/3cxsbc.conf.local sounds like the solution to my woes. I will test using this with Ansible and report back.

Many thanks

 

[JustinSubertETS]

It transpires that /etc/3cxsbc.conf.local solves the universal log level challenge but not the initial seeding of the other settings.
The three seeding settings I set via Ansible are Password, TunnelAddr and PbxSipIP in the section [Bridge/123456]. This allows me to provision new SBCs with zero touches.
It would appear that Password is legitimately changed once the SBC is adopted to a connection specific password, so I should not overwrite it in /etc/3cxsbc.conf.local.
What I have done is to create /etc/3cxsbc.conf once and then touch /etc/3cxsbc.ansible to prevent future modifications. I also now manage /etc/3cxsbc.conf.local with Ansible to get consistent log levels.

It's a little messy but is better than nothing!

Thanks for your input guys.