Simple Zope Clustering with Squid and Pound

Finally got a simple Squid/Pound/Zope setup running. There are so many howtos out there on how this is supposed to be setup, but each seem to be missing one part or adds in some extra complexities that aren't really needed.

1. Pound is super simple to setup
2. ZEO is a little more difficult
3. Squid is the most complex

In this setup no redirector script is needed for squid since we can handle the mappings in the VirtualHostMonster mappings tab. We have to run pound and squid on the same port, but different interfaces so the url rewriting does the right thing. VirtualHostMonster itself won't rewrite the ports without some kind of rewriting done beforehand. This is ok since we can just bind Pound to the loopback interface and the squid to the external interface.
For reference I took the stock stock squid settings did the following:

changed :
http_access deny all
to:
http_access allow all

added:
http_port [external_ip]:80
httpd_accel_host 127.0.0.1
httpd_accel_port 80
httpd_accel_single_host on
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Pound's config is simple also:

ListenHTTP 127.0.0.1,80
User zope
Group zope
LogLevel 1
UrlGroup ".*"
BackEnd 127.0.0.1,51003,1
BackEnd 127.0.0.1,51004,1
EndGroup

All that is left is to configure 2 ZEO Clients and a ZEO Storage Server to answer the requests. In one of the ZEO Clients go into the root VirtualHostMonster and on the mappings tab add one entry per domain name and site you want to serve.

Technorati Tags: deployment, python, zope

Multiple BroadVoice lines again, guess I didn't learn it all the other night

So I found today that calls coming into our asterisk from BroadVoice
were only being picked up by the last BroadVoice peer that I had
listed in my sip.conf. So I tried a few things here and there and
ended up making another entry in sip.conf for all incoming BroadVoice
calls to use and then direct them to a special [from-broadvoice]
context in extensions. From there I direct calls to the correct
contexts.

So the basic setup I have is like this:

1 peer for each BV account with their credentials so they each make
outgoing calls on their own BV account
1 register for each BV account with their credentials so incoming
calls come to our asterisk server
1 general BV peer for incoming BV calls with a context in extensions
to direct calls correctly

Seems to work so far. If anyone knows of a better way leave a
comment and I'll update the voip-info.org page once this has road
tested for a bit.

Technorati Tags: voip

Setting up multiple BroadVoice accounts, or I learned a lot last night, Part 4

So now the office building is growing and we have multiple tenants who I have gotten to signup for a BroadVoice account. Now the challenge of setting them all up in one Asterisk server. I have been running one line on there for the last couple month very easily by following a combination of the instructions on the BroadVoice website and some instructions I have found on voip-info.org.

The problem with these instructions are that they only describe setting up one line and the configurations are a bit cryptic. To help any others out there here are my example instructions for multiple sip registrations using BraodVoice and Asterisk.

You will need a register line for each BroadVoice line:

register => 5555551234@sip.broadvoice.com:mysecret:5555551234@line1-broadvoice/5555551234
register => 5555551235@sip.broadvoice.com:mysecret:5555551235@line2-broadvoice/5555551235

Then you need an entry for each peer:

[line1-broadvoice]
authname=5555551234
canreinvite=no
context=line1
dtmf=inband
dtmfmode=inband
fromdomain=sip.broadvoice.com
fromuser=5555551234
host=sip.broadvoice.com
insecure=very
qualify=yes
secret=mysecret
type=peer
user=phone
username=5555551234

[line2-broadvoice]
authname=5555551235
canreinvite=no
context=line2
dtmf=inband
dtmfmode=inband
fromdomain=sip.broadvoice.com
fromuser=5555551235
host=sip.broadvoice.com
insecure=very
qualify=yes
secret=mysecret
type=peer
user=phone
username=5555551235

Once you have that setup you can now need to setup the contexts in extensions.conf:

[line1]
include => line1out
exten => 5555551234,1,Macro(stdexten,${EXTEN},SIP/${EXTEN})

[line1out]
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}}@line1-broadvoice,30)
exten => _1NXXNXXXXXX,2,Congestion()
exten => _1NXXNXXXXXX,102,Busy()
exten => _011.,1,Dial(SIP/${EXTEN}@line1-broadvoice,30)
exten => _011.,2,Congestion()
exten => _011.,102,Busy()

[line2]
include => line2out
exten => 5555551235,1,Macro(stdexten,${EXTEN},SIP/${EXTEN})

[line2out]
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}}@line1-broadvoice,30)
exten => _1NXXNXXXXXX,2,Congestion()
exten => _1NXXNXXXXXX,102,Busy()
exten => _011.,1,Dial(SIP/${EXTEN}@line1-broadvoice,30)
exten => _011.,2,Congestion()
exten => _011.,102,Busy()


These are greatly simplified, but they should help anyone else wanting to use multiple lines and wasn't sure of the syntax. These are all working on an Asterisk 1.2.1 system running on my favorite OS FreeBSD!

Technorati Tags: voip

Vonage doesn't react well to round robin NAT, or I learned a lot last night, part 3

So now we have our nice shiney network up and running. I go to test the phones that are hooked up to our asterisk box and I can't call out on any of our external lines. This is for another posting, but we basically have to have our Vonage Cisco ATA-186's plugged into our network and then the RJ-11 from those go into a Digium TDM400 card with 4 FXO ports on it. Crazy hack, but vonage won't let you connect directly to thier service.

Hope that this isn't a problem with the network internally I take a regular phone down and conenct it directly to the vonage box and I get the same problem. At least that is one relief. Now I get on the phone with Vonage tech support (using our BroadVoice account) and spend over an hour and they can't figure it out. The boxes connect and register. You can dial and it rings. They can call in and they ring, but when you pick up there is no audio. So after the call dropped for the second time I found something interesting in my NAT tables. Connections were being given different external IP addresses for each connection.

Here is something I did not know and only happened upon it by accident. Setting up round-robin NAT is super easy with PF. I had put all of our external IP addresses on the one exteral interface and PF just started using them all as a pool. Instantly scalable, but not very SIP happy. More later on why BroadVoice was working and vonage was not.

So using PF we can keep this new found functionality, but we can tell the devices to be sticky. So once they go out on one interface stay there. That should look like this now:

nat on $ext_if from $sfu_net to any -> $ext_if round-robin sticky-address

Flushed the NAT table and rebooted the ATAs and viola I had calls working again! The reason BroadVoice was working was the fact we are using bi-directional NAT for the boxes in our DMZ so it was using a dedicated IP on the external interface for all of its traffic. For the record that is done like this:

binat on $ext_if from $asterisk_int to any -> $asterisk_ext

So we now have VoIP working again internally and externally.

Technorati Tags: networking, voip

FreeBSD is an amazing OS, or I learned a lot last night, Part 2

One thing I have learned for sure is something I always thought was true. FreeBSD is an amazing operating system. It is clean, lean and powerful. We just turned an old Dell Precision 410 into a network router/firewall with 4 NICs and many many vlans. That part was easy except for the cheap NICs I have been using.

The onboard NIC had to be disabled because it was conflicting with the PCI ones. I had purchased 2 identical Linksys cards at Fry's only to get back to the server room to find they are completely different cards. One was a v2 and the other was a v5.1. The v5.1 works great, but the v2 was timing out under any network load.

So out it came and in went another NIC I had rescued from an old machine. Bingo! except that the driver wasn't compiled into the kernel. FreeBSD to the rescue. I just kldload'd the driver up and then added it to loader.conf like so:

if_sis_load="YES"

and we are back on the road again. After a little testing all is well and the cards are all playing happily along. One thing I would change about this would be to get a good brand name server grade multi-port NIC. The box has one already and it works flawlessly. Next time I won't even start this without one.

Technorati Tags: networking, voip

I learned a lot last night, part 1

We have been reconfiguring the office networks here at the Six Feet Up HQ. We now have other tenants in the building so I wanted to partition them into seperate vlans. This is not a task for the weak at heart or those with out professional training :-)

To try to capture some of my wrong turns and put some tips out there for others to take advantage of I wanted to start blogging them here. There will be many more parts to come as this was a long process.

Technorati Tags: networking, voip