R.I.P. Kazoo

Yes, you can run them on VPS. My current cluster run this kind of install. You should upload the ISO to the VPS, open the console and run the Text-installer on it. during the first boot, all PBX services will start up. The step required here is to change the SIP-Proxy listen ip other than 127.0.0.1 and als oun some startup 'sup' commands (I am working to create a startup script to ease the post-configuration).

The goal of these ISO's is to ease the Kazoo installation and configuration.
Thank you for the answer @fmateo05 ... I’m not so technically minded so I will wait until I know that you have a start-up script to help me out.

How many VPS’s should I have for cluster setup if that is the route I want to go oppose to installing it all on one VPS?

thank you
 
I have done the install with the embedded iso what is the root password, i tried kazoo & Kazzo ?
 
Thank you for the answer @fmateo05 ... I’m not so technically minded so I will wait until I know that you have a start-up script to help me out.

How many VPS’s should I have for cluster setup if that is the route I want to go oppose to installing it all on one VPS?

thank you

Hello @fmateo05 ,

I followed the instructions here:


and installed your Kazoo image on a VPS at hotlineservers.com... the install completed but when you do step 6, you get a error message that that kazoo-first-boot does not exist.

then I did step 7, then rebooted

steps above all the VPS console

however, you cannot access anything via the web... ie. the web portal does not even load... the browser times out.

So, while the ISO installed on the VPS etc, can't do anything thereafter other than login as root user at the VPS console.

Thanks!
 
check the iptables rules just in case. Root password is root/root (or root/password).
for the web page load, restart apache and check if port 80 is running
 
check the iptables rules just in case. Root password is root/root (or root/password).
for the web page load, restart apache and check if port 80 is running

@fmateo05 , thank you, would you be so kind to provide me the commands to execute at the console to check all these?

Because even when I type ifconfig at the command line using the console returns 'command not found'

Thank you
 
Last edited:
Which kind of commands? kazoo sup commands or bash?
For apache: systemctl restart apache2


I'm sorry, I am loosing something in translation:

1. I installed your Kazoo image from https://ekpbx.com
2. Can only login using the console terminal on the VPS
3. Followed your post installation edit instructions from https://ekpbx.com/?page_id=49
4. Step 5 never appeared from https://ekpbx.com/?page_id=49
5. Step 6 kazoo-first-boot does not exist when I ran that from https://ekpbx.com/?page_id=49
6. Step 7 was followed from https://ekpbx.com/?page_id=49
7. Posted my result to you for help in the above thread
8. You asked me to check for iptables and apache
9. I asked how do I do that from the console, what should I type for iptables and apache?
10. Web browser still does not load
11. No access to console via SSH port 22

Sorry, that's all I know :)

Thank you
 
Kazoo 5 isn't officially released and I question if it ever will be released publicly. It was there, then it was ripped back. When I spoke to folks at 2600hz, their answer is about getting the apps store working well with it and then that supposedly will be a good source of revenue from them. However, I think they only really want to release things that are hosted by them (and some of their pricing isn't shy). I'm actively working on getting my own geo-redundant setup working, but for sure there is no "5 minute" install and up and running like PBXinaFlash.

I do believe they answered that already some time back.



No, it's not closed source. But we have paused on the public stuff to try and finish our app exchange. We are 10 years into this company and the entire point of the company was the app exchange, and it's still not done, so we're finishing that before we finalize and release 5.x




It sounds like they want to monetize the application exchange.
 
It sounds like they want to monetize the application exchange.

Correct, and agreed. I just hope things do go that way. Because they make a LOT of money from their "rented" portal option - or if you house it yourself and have them manage it. I'd be happy to pay for some of the apps (might even add one to it). That being said, I sure hope they allow one to purchase things from app exchange on my own hardware instead of being forced to rent theirs.
 
If you are a service provider, its a lot easier to have multiple cloud instances or rent space in a data center and create VPS's of your own. IncrediblePBX is a known quantity with good support via the forums. It is easily mass-produced to multiple instances of VPS. At $3-$5/month for reliable cloud instances, I wouldn't waste my time on multi-tenant unless you're like a Ring Central or Avaya or Cisco.

I started with a similar approach when I started offering Hosted PBX 7-8 years ago. It is a complete nightmare to maintain, and having a fixed price per instance is a huge downside when a single true multi-tenant solution can scale to millions of handsets, with $0 fixed cost per account. Of course as you scale up with more nodes, your infrastructure costs go up, but you are not stuck paying fixed cost per account.

Have you tried maintaining 100s of VMs? Then want to implement a change on all of them? There are automation tools that would facilitate this, but the whole concept is backwards when multi-tenant solutions will do the job better in every way.

Use the tool that fits the job, not the one that was built to be an on-prem DIY PBX.
 
Have you tried maintaining 100s of VMs? Then want to implement a change on all of them? There are automation tools that would facilitate this, but the whole concept is backwards when multi-tenant solutions will do the job better in every way.

Use the tool that fits the job, not the one that was built to be an on-prem DIY PBX.

The counterpoint to this is if you implement a bad change, or just otherwise have some outage on your multitenant system, you have 100 tenants down.

I agree with your reasoning but would not say "better in every way."
 
The counterpoint to this is if you implement a bad change, or just otherwise have some outage on your multitenant system, you have 100 tenants down.

I agree with your reasoning but would not say "better in every way."

Thats what sandbox environments are for. You test things before you implement on production.

In addition, having numerous instances of each component for redundancy further prevents some one off issue from taking down your entire platform.

Edit: not to mention multiple zones that can operate independently from one another, to handle an entire datacenter going down. instructions on how to set this up with kazoo are openly available and work
 
Last edited:
Thats what sandbox environments are for. You test things before you implement on production.

In addition, having numerous instances of each component for redundancy further prevents some one off issue from taking down your entire platform.

Edit: not to mention multiple zones that can operate independently from one another, to handle an entire datacenter going down. instructions on how to set this up with kazoo are openly available and work

How is your deployment going? I see that you are offering services with Kazoo. Is the entire process automated or you need to add the new company and then let them manage it afterwards?
 
How is your deployment going? I see that you are offering services with Kazoo. Is the entire process automated or you need to add the new company and then let them manage it afterwards?

Entire process is automated. Another amazing aspect of Kazoo is it being entirely API driven, you can fully control/provision any aspect of it via your own logic.

It is as easy as just watching your browser network API requests while doing anything in the web portal. Check the API calls it makes, the data it sends, the responses it gets, and replicate that in your own code. Adding a new customer, creating a user, linking their payment method, setting what apps they have access to, etc, etc, all automated...

My deployment is going great, no issues whatsoever. Parent company 1pbx has entered into a partnership with one of the largest telcos in Canada, so we have been busy working with them. pbxHQ will likely not see any major changes for a few months, but we now have all the resources we need to further develop integrations and remove any existing pain points (bad UI experience for onboarding, among others)
 
Coming from a guy who loves Kazoo, the definite downside involves writing custom logic to interact with it, that a future Kazoo update could break. I can think of a few examples in the past, and this typically only happens on major version updates where API endpoints are added/removed/changed.

Depending how much custom logic you build, it will often be better to stick with the major version you are running, and implement any new features yourself if you require them. Unless the update doesn't break anything vital that you have already built.
 

Members online

Forum statistics

Threads
26,761
Messages
174,868
Members
20,320
Latest member
united0147
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