Installing macOS Catalina 10.15 on Proxmox 6.1 or 6.2 using OpenCore

This tutorial for installing macOS Catalina using OpenCore has been adapted for Proxmox from Kholia’s OSX-KVM project and Leoyzen’s OpenCore configuration for KVM. You can get the full sourcecode on my GitHub here.

If you’d like to use Clover instead, use my older tutorial, but OpenCore works better!

Source: Installing macOS Catalina 10.15 on Proxmox 6.1 or 6.2 using OpenCore – Nicholas Sherlock

How to keep one group of extensions from being able to call another group of extensions in FreePBX

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

FreePBX is NOT designed for multi-tenant use. Yet a lot of people will still try to, for example, run two small companies off the same FreePBX server. The question then invariably arises “How do I keep one company’s users from calling the other company’s extensions?”

Just yesterday in the FreePBX forum, someone asked:

Imagine I have extensions 100-110 and I name those CustomContext “GroupA” and I name 200-210 as “GroupB”. Can anyone tell me how I’d eliminate GroupA and GroupB from dialing each other?

And I replied as follows:

Create two new contexts in /etc/asterisk/extensions_custom.conf (just add these to the bottom of the file):

[from-group-a] exten => _2XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

[from-group-b] exten => _1XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

After you do that:

Go to the extension configuration page for each extension in Group A and change the context from from-internal to from-group-a.

Go to the extension configuration page for each extension in Group B and change the context from from-internal to from-group-b.

The way this works is if someone in Group A attempts to call an extension in the 200-299 range, OR if someone in Group B attempts to call an extension in the 100-199 range, the call is diverted to “congestion” (a fast busy signal). Otherwise, the call goes to the from-internal context and is processed in the normal way.

No nice way to do this from a GUI page, unfortunately. But, this is pretty simple, I think.

EDIT: There may be a slightly more elegant way to do this, that only involves adding ONE additional context to /etc/asterisk/extensions_custom.conf:

[from-restricted-exts] exten => _2XX/_1XX,1,Goto(app-blackhole,congestion,1)
exten => _1XX/_2XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

Then you would change the context for all “restricted” extensions from from-internal to from-restricted-exts — this should have the exact same effect as the above contexts (if you don’t understand why, see Asterisk hiding a useful feature in plain sight by giving it a “cute” name).

What I did not really go into in that reply is that this does NOT provide 100% separation.  Although it prevents a user in one group from calling a user on the other directly, it does not address a host of other issues that could arise.  Just as one example, there is nothing that would stop a user in “Group A” from transferring a call to a user in “Group B”.  Did I mention that FreePBX is NOT designed to be a multi-tenant system?

Probably the best solution for multi-tenant use is to run separate installations of Asterisk and FreePBX for each tenant.  You can run them on separate servers, or on separate Virtual Machines on the same server, but be careful if you do the latter, because some VM’s work better than others for the purpose.  The PBX in a Flash folks would tell you, for example, that they’ve never had a problem running PBX in a Flash under Proxmox, but always seem to have issues if trying to run it under VMware.  But others will say that with the right tweaks (and by installing VMware Tools) they’ve made it work under VMware.  But I think that if you only have one server available, running two installs of Asterisk and FreePBX in Virtual Machines is better than trying to make FreePBX (and perhaps Asterisk itself) do something it is clearly not designed to do.