SUGGESTIONS Lets Encrypt?

I originally started using Kazoo as an alternative to a farm of VMs running FreePBX. If you are running numerous FreePBX, then I advise exploring something easier to maintain and scale.

Edit: Something else to keep in mind, is that everything about Kazoo was designed so that it can be redundant, scale horizontally, and handle massive amounts of volume. I can't think of any examples off the top of my head, but I remember when I first started using Kazoo, that some things that were simple in FreePBX were either very difficult or impossible in Kazoo.

Yeah, I have about 100 instances on VM's now and as you know, it can be a bear to manage and I want to look to the future (while not ignoring the past). Do you have any reference materials or what did you use to start to learn how to do stuff that you did in FPBX in Kazoo? Any advice is appreciated.
 
Yeah, I have about 100 instances on VM's now and as you know, it can be a bear to manage and I want to look to the future (while not ignoring the past). Do you have any reference materials or what did you use to start to learn how to do stuff that you did in FPBX in Kazoo? Any advice is appreciated.

Seems Kazoo would be a great fit for you.

For the most part, this guide does have a lot of great info and is accurate: https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/

Any file that it mentions to change something in, just look around inside, get familiar.

For setting up a cluster, this guide is also quite good: https://docs.2600hz.com/sysadmin/doc/kazoo/cluster-guide/

Pretty decent starting point for your firewall: https://docs.2600hz.com/sysadmin/doc/security/iptables/

Also for securing API: https://docs.2600hz.com/sysadmin/doc/config/ssl/easy_setup/

And don't use bigcouch, it is very dated. CouchDB 2.3.1 is much preferred now, I have an install script that I made for myself and decided to share: https://github.com/1pbx/kazoo-couchdb

I am no scripting expert, it could probably use some minor improvements, but it does get the job done, and ensures that future yum updates don't accidentally upgrade CouchDB higher than 2.3.1. Certain aspects of Kazoo (largely, the tasks app, maybe others) will fail on CouchDB 3+

It is a big learning curve but rewarding and fun experience if you are into that sort of thing. For learning the platform, single server with 1 database will work just fine. If you get stuck I don't mind answering some questions, or my company offers paid Kazoo support if you need bigger assistance. https://1pbx.io/kazoo/support
 
Also depending on how existing phones are configured, you may be able to migrate users from FreePBX to Kazoo without them even knowing. This can be done by changing DNS records and setting up account realms to existing VM hostnames.

Ability to do this is largely dependent on how phones are currently configured though. If they are configured in a very simple manor with just their current FreePBX VM hostname, username, and password, you should be able to do it. Just make the new account on Kazoo have a realm that matches the FreePBX hostname, then make the device username and password match what is already set in the phone. And of course, point the VM hostname to Kazoo SBCs (Kamailio).

Kazoo is truly multi-tenant, every single account can have a SIP device with the exact same username. Authentication of SIP devices is done with username + realm, along with password.
 
I realize this thread went on a bit of a tangent, but I have a question back on topic. Has anyone gotten Let's Encrypt to work on IncrediblePBX 2021 for Debian 10?

I've managed to install certbot (though to get the current version, I had to install snap and use the snap package).

Code:
apt install snapd
snap install core
snap refresh core
snap install --classic certbot

In order to obtain a certificate, however, I have to bring down the firewall. Seems there is no easy way to do that in Debian. It seems one has to copy the firewall rules, flush and delete all the firewall rules, then add accept rules.
Source: https://kerneltalks.com/howto/how-to-disable-iptables-firewall-temporarily/

For one, as I am not completely clear what traveling man is doing in the background, I'm concerned that saving the rules and then restoring them may break the TM script. More importantly, however, I cannot even take the firewall down. Typing the first command "iptables -F" crashes the system permanently. I've had to restore from a snapshot twice.

Any suggestions?

Can I not do this over SSH? Have to use console?
 
FWIW, I prefer acme.sh over certbot.

But... for FreePBX I use the certificate manager module along with my lewatch script. Once lewatch is installed the certman module GUI and command line should "just work" without any fuss.

If you don't want to use lewatch, you can still do all you need with the certman module, just not from the GUI.

Generate the initial cert:
Code:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
fwconsole cert --generate --type letsencrypt --hostname admin.yourfqdn.com --country-code US --state Iowa --email [email protected] --san sip.yourfqdn.com --san ucp.yourfqdn.com
iptables -D INPUT -p tcp --dport 80 -j ACCEPT

Then schedule a cron job:
Code:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
fwconsole cert --updateall
iptables -D INPUT -p tcp --dport 80 -j ACCEPT


You should be able to divine the answer to your iptables question from the above. Completely disabling and restarting the firewall is crazy and not necessary.
 
Sorry, I checked my test IPBX instance module admin, saw the current certman, and thought @wardmundy had removed the certman module version lock. I forgot I had manually installed the current version.

Lewatch works fine with the older IPBX version of certman, but if you want CLI functionality you need a current version of certman. For now:
Code:
fwconsole ma downloadinstall https://github.com/FreePBX/certman/archive/release/15.0.39.zip


@wardmundy unpin certman! The firewall module dependency issue was fixed over seven months ago.
 
FWIW, I prefer acme.sh over certbot.

But... for FreePBX I use the certificate manager module along with my lewatch script. Once lewatch is installed the certman module GUI and command line should "just work" without any fuss.

If you don't want to use lewatch, you can still do all you need with the certman module, just not from the GUI.

Generate the initial cert:
Code:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
fwconsole cert --generate --type letsencrypt --hostname admin.yourfqdn.com --country-code US --state Iowa --email [email protected] --san sip.yourfqdn.com --san ucp.yourfqdn.com
iptables -D INPUT -p tcp --dport 80 -j ACCEPT

Then schedule a cron job:
Code:
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
fwconsole cert --updateall
iptables -D INPUT -p tcp --dport 80 -j ACCEPT


You should be able to divine the answer to your iptables question from the above. Completely disabling and restarting the firewall is crazy and not necessary.

Will deleting the port 80 accept at the end of the script remove my ability to access the web GUI from whitelisted addresses? I suspect not as this rule would be added at the end?
 
Sorry, I checked my test IPBX instance module admin, saw the current certman, and thought @wardmundy had removed the certman module version lock. I forgot I had manually installed the current version.

Lewatch works fine with the older IPBX version of certman, but if you want CLI functionality you need a current version of certman. For now:
Code:
fwconsole ma downloadinstall https://github.com/FreePBX/certman/archive/release/15.0.39.zip


@wardmundy unpin certman! The firewall module dependency issue was fixed over seven months ago.

I upgraded my certman module and installed your script but it didn't seem to allow the initial certificate creation:

Ignore the above. A reboot of my pbx fixed it.
 
Last edited:
it errored out with...
That's a new one.

Was this from the GUI or command line?

The lewatch process is working, or it would have failed much earlier.

The only direct call to stream_get_meta_data() is in the Lescript.php library. If that is the call that is failing (and it likely is based on the log above), then the immediate prior call to the php tmpfile() function failed:
Code:
 $tmpConf = tmpfile();
 $tmpConfMeta = stream_get_meta_data($tmpConf);

tmpfile() is a core php function and returns a file handle on success, or FALSE (a boolean) on failure.

Based on your other recent posts, it looks like something is hosed with the tmp folder.

I''m going to stick my neck out and declare now this is not a certman or lewatch issue.
 
That's a new one.

Was this from the GUI or command line?

The lewatch process is working, or it would have failed much earlier.

The only direct call to stream_get_meta_data() is in the Lescript.php library. If that is the call that is failing (and it likely is based on the log above), then the immediate prior call to the php tmpfile() function failed:
Code:
$tmpConf = tmpfile();
$tmpConfMeta = stream_get_meta_data($tmpConf);

tmpfile() is a core php function and returns a file handle on success, or FALSE (a boolean) on failure.

Based on your other recent posts, it looks like something is hosed with the tmp folder.

I''m going to stick my neck out and declare now this is not a certman or lewatch issue.
It was the GUI. Though rebooting the box resolved it. It looks like the tmpfile issues that Ubuntu and Debian IPBX beta users (including me) are affecting other parts of FreePBX. Its definitely nothing to do with your script.
 
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Back
Top