The Open Sourcerer

Asterisk, Zaptel, Oslec and Ubuntu Server [Updated]

I have recently migrated my server at home from a custom Linux build to Ubuntu Server (8.10 Intrepid). The main migration went very smoothly and I learned a few new tricks on the way too.

One function the server performs is as my telephone system for work and home. It runs Asterisk. I have a couple of IAX2 trunks from our VOIP provider for mine and my wife’s businesses and I also have a cheap x100p clone analogue card for PSTN backup purposes. On my old system software, I had compiled the device drivers (zaptel) and kernel modules for the card manually and used a, frankly fantastic, echo canceller called Oslec (the Open Source Line Echo Canceller). You can read the couple of posts I made about when I first tried it out here.

On my new server OS, I installed the Asterisk server via Ubuntu’s package management system sudo apt-get install asterisk. After some digging around on the ‘net (and it wasn’t obvious) I discovered that the zaptel drivers (for the PSTN hardware) need to be installed slightly differently:

sudo m-a -t build zaptel Which retrieves the zaptel package and builds it for your running kernel. You might have to run m-a prepare in advance of this to retrieve your Linux kernel headers.

The m-a (Module Assistant) command will compile and create a .deb package in the /usr/src directory. On my system the package was called zaptel-modules-2.6.27-11-server_1.4.11~dfsg-2+2.6.27-11.27_i386.deb.

It can then be installed using dpkg: sudo dpkg -i zaptel-modules-2.6.27-11-server_1.4.11~dfsg-2+2.6.27-11.27_i386.deb.

This went fine and I had read on launchpad that as of an earlier version of the zaptel package the Oslec echo canceller was now the default. Unfortunately this didn’t quite work as I expected. The zaptel module was in fact using the standard MG2 EC which is not very good with my x100p card at all.

After a bit more digging around in the source code, there is a file in the zaptel package called zconfig.h which is where the chosen EC is defined. It is specified as MG2 in the package. What I did to fix it was as follows.

• Unpack the zaptel.tar.bz2 package that was in /usr/src.
• Edit the kernel/zconfig.h file so the line #define ECHO_CAN_MG2 is commented out
• and added in a line that reads #define ECHO_CAN_OSLEC instead.
• Re-assemble the zaptel package: sudo tar jcvf zaptel.tar.bz2 modules (“modules” is the directory name where the zaptel package extracts to).
• Delete the existing zaptel-blah-blah.deb file and the modules directory too.
• Re-run the m-a -t build zaptel command.

Thanks to Tzafir Cohen on the asterisk mailing list for this. There is a far simpler method to use for the time being although this is a known bug and is now fixed in the development tree so I guess it will be unnecessary once the package has been updated. Do please check first if you are following this in the months to come. Anyway, instead of the commands above, these commands work for me and are far simpler:

sudo m-a -f get zaptel-source This simply gets the source package and saves it in /usr/src.
sudo ECHO_CAN_NAME=OSLEC m-a -t a-i zaptel And this builds and installs the modules and tells the build scripts to choose the Oslec EC by default. The -t switch puts the command into text mode so you actually see what is going on. I find the process rather opaque and uninformative without this switch.

After rebuilding, the zaptel module now requires, and loads the Oslec EC by default. The command modinfo zaptel is a good test. The output of it should be something like this:

filename: /lib/modules/2.6.27-11-server/misc/zaptel.ko
version: 1.4.11
license: GPL
description: Zapata Telephony Interface
author: Mark Spencer <markster@digium.com>
srcversion: 4433ADDE0493C798A455677
depends: oslec,crc-ccitt
vermagic: 2.6.27-11-server SMP mod_unload modversions 686
parm: debug:int
parm: deftaps:int

Note the “depends” line.

You could also type lsmod | grep 'zaptel' once you have reloaded your server:

zaptel 199844 5 wcfxo
oslec 16668 1 zaptel
crc_ccitt 10112 1 zaptel

This command shows the oslec ec module installed along with the the zaptel and wcfxo drivers.

One final point to note. If you just want to load a particular telephony hardware driver and not all of them, I think you need a file /etc/default/zaptel like this with the relevant driver(s) uncommented:

TELEPHONY=yes
DEBUG=yes

#MODULES="$MODULES wctdm" # TDM400P - Modular FXS/FXO interface (1-4 ports)

I can’t recall the exact origins of this file and whether or not it is really necessary, but I had it on my old system and the Ubuntu provided zaptel init script checks for it’s presence; although it doesn’t look like it does much with its contents though…

Hopefully this will help others and also act as a bit of an aide memoir for me when I next build an Ubuntu server with Asterisk.

Tell Someone Else!

A shared “drop-box” using Samba [Updated]

Here’s a neat thing I managed to sort out the other day.

If you have read any of the “Untangle, Asterisk and File Server; All-in-One” series of posts before, then you will know that I’ve got a neat little VIA CN700 server for our home that is running all sorts of good stuff.

One of the things I have wanted to do for a while was to create a shared directory on the server so any family member can put stuff in there (like music files etc) but not be able to delete anything so as to prevent accidentally removing thousands of MP3s or irreplaceable digital pictures for example. This facility is apparently called a “drop-box”.

Hmmmm. Now let me think… Linux file permissions are rwx: Read Write eXecute. So, if you have write access, you can delete too. How can I fix this?

After some Googling and reading the Samba documentation it is actually pretty straightforward. Here’s how to make a drop-box on a Linux file server using Samba (CIFS) as the file sharing protocol and access mechanism.

• Create a directory somewhere on your server and give it a sensible name: I called it “shared” and put it under the /home tree.
• Create a Linux group for all users who you want to access the drop-box: I called the group “shared”. Then add your users to that group.
• Using sudo or running as root, change the the directory settings as follows:
  • chmod 770 shared. This prevents access to the directory by anyone other than root, and the owner and group members.
  • chown nobody:shared shared. This changes the directory ownership to a user “nobody” and the group “shared”. It is important that you use a user who is NOT a member of the shared group. Any user will do, but it must be defined in/etc/passwd. I chose “nobody” as it has very minimal permissions and is unlikely to pose any sort of security hazard. On my server, the user nobody is configured thus:nobody:x:99:99:Unprivileged User:/dev/null:/bin/false
  • chmod g+s shared/. This sets the directory’s SGID bit so that any new files or directories created in our shared directory will have their group id set to that of the of the shared directory. This ensures all members of the shared group can read the contents.
  • chmod +t shared This sets the “sticky bit” of our shared directory. On Linux, setting the sticky bit, means items inside the directory can be renamed or deleted only by the item’s owner, the directory’s owner, or the superuser; without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of owner.
  • Here’s a listing of the directory showing how it should look now:drwxrws--T 3 nobody shared 62 2008-04-15 21:48 shared

Now we can set-up our share in Samba as follows:

[shared]
comment = Our Shared Data/Media
path = /home/shared/
read only = no
valid users = @shared
browseable = yes
inherit owner = yes

The valid users @shared line tells samba that only members of the “shared” group can access this share. And the line inherit owner = yes is what makes it all work. This tells samba to set the owner of any files created to the owner of the directory we are in. In this case the owner is “nobody”. As the sticky bit is set on this directory, only the user “nobody” or the superuser can remove files as their ownership is instantly changed by Samba when first created from the actual user to the user “nobody”.

After dropping a file into the shared directory over a samba connection the listing looks like this:

-rwxr--r-- 1 nobody shared 1272366 2008-04-17 14:17 14_-_Jubilee.mp3.

See how the file is owned by “nobody:shared” and only has group and other read set.

It might sound like a bit of a palaver, but it doesn’t take very long to set up. This is a very useful way of creating drop-boxes for many kinds of applications.

I hope someone finds this useful, and please leave a comment if you do!

[UPDATE]

A big thanks to Simbul who noted the obvious flaw in my suggestion. Although you could safely drop files into this folder, you couldn’t create directories which was a bit of a PITA to be honest. However Simbul made a simple addition to the [shared] section that fixes this issue (See the comments at the bottom of this post for details):

[shared]
comment = Our Shared Data/Media
path = /home/shared/
read only = no
valid users = @shared
browseable = yes
inherit owner = yes
Add the following two lines:
directory mode = 3770
force directory mode = 3770

And that’s it. Thanks Simbul. It works a treat.

Tell Someone Else!

Pet Project

I’ve been meaning to write about this for a while now. But what with the flu, Microshaft’s ongoing corruption of the ISO and some other stuff cropping up, I just kept finding reasons to put it off. Finally however, after jotting some notes and so forth for a few days I’ve managed to get my act together.

A Pet [Open Source] Project I want to give some airtime to, and get some assistance for, is Linux From Scratch.

History

Going back into the dark ages, I had been “playing” with one Linux distribution or other from the cover of PC magazines for sometime (I think it was a very early Mandrake or Suse product that first grabbed me), and found the whole system quite fascinating. The fact it was all free, and you could “LOOK” into it and see how it all worked together was a real eye opener. I was used to PCs and other computer platforms so it wasn’t all new… I grew up with VT100 terminals, DEC VAX VMS and then DOS so command line interpreters and such were nothing new in themselves but to get a complete OS, that did stuff, was free, and actually encouraged you to examine it, I remember it making me sit up and take notice even then.

One of the very first Open Source communities I came into active contact with was the Linux From Scratch (LFS for short) community. I cannot remember how I stumbled across the project or quite how long ago either, but it was quite a few years certainly. They have a feature which encourages newcomers to register their first LFS build when it is up and running. Checking on their website today, they have 19570 users registered so far. My LFS ID is 216 and the version of “the book” I recorded as having followed was 2.4.x when I registered. Although I certainly built (tried to build) a few before getting brave enough to register Anyway, I’m guessing this would have been around 1999/2000 some time.

LFS is still a project I follow closely and have a very warm opinion of. It has taught me a great deal over the years.

What is it then?

The project – if you can’t guess from the name – is all about building a functional Linux based operating system from scratch. That is, from nothing. You start with a spare partition on your hard disk and, by following the book, you learn what makes up a GNU/Linux operating system, how that operating system works and why bits of it behave the way they do. It is an educational project and it is a brilliant educational project. You gain knowledge of not just Linux itself but, Bash, compiling, device management and much, much more too. And what you also learn is what makes it all tick together… It is quite hard to explain but it’s a bit like the whole being worth more than just a simple sum of the individual parts.

LFS was started by a chap called Gerard Beekmans. The LFS project’s homepage explains the project thus:

What is Linux From Scratch?

Linux From Scratch (LFS) is a project that provides you with step-by-step instructions for building your own customized Linux system entirely from source.

Why would I want an LFS system?

Many wonder why they should go through the hassle of building a Linux system from scratch when they could just download an existing Linux distribution. However, there are several benefits of building LFS. Consider the following:

LFS teaches people how a Linux system works internally
Building LFS teaches you about all that makes Linux tick, how things work together and depend on each other. And most importantly, how to customize it to your own tastes and needs.

Building LFS produces a very compact Linux system
When you install a regular distribution, you often end up installing a lot of programs that you would probably never use. They’re just sitting there taking up (precious) disk space. It’s not hard to get an LFS system installed under 100 MB. Does that still sound like a lot? A few of us have been working on creating a very small embedded LFS system. We installed a system that was just enough to run the Apache web server; total disk space usage was approximately 8 MB. With further stripping, that can be brought down to 5 MB or less. Try that with a regular distribution.

LFS is extremely flexible
Building LFS could be compared to a finished house. LFS will give you the skeleton of a house, but it’s up to you to install plumbing, electrical outlets, kitchen, bath, wallpaper, etc. You have the ability to turn it into whatever type of system you need it to be, customized completely for you.

LFS offers you added security
You will compile the entire system from source, thus allowing you to audit everything, if you wish to do so, and apply all the security patches you want or need to apply. You don’t have to wait for someone else to provide a new binary package that (hopefully) fixes a security hole. Often, you never truly know whether a security hole is fixed or not unless you do it yourself.

Why LFS is a great platform

[When I discuss LFS I also imply the use of BLFS (Beyond Linux From Scratch) which is a fantastic resource for how to build and install the stuff that goes to make up a "useful" and "complete" Operating System.]

As some of the readers here will know, the little server I’ve built for home use is running LFS. It also runs, Apache, Tomcat, MySQL, PHP, Postgresql, is a Mail server, a Samba (Windows Networking) server, is our telephone exchange (running Asterisk) and a few other things too.

One of the main reasons for choosing LFS as the platform for this server is this: as it is built entirely from scratch there is no bloat, or unnecessary applications, the system is about as lean as you can get. The hardware I chose (very deliberately) is not the most powerful in the world; a mere 7Watts power consumption. But the applications running on the server currently seem very happy and there are plenty of system resources spare. This would be very hard to achieve using a mainstream distribution as they have to cater for as generic a host platform as possible and include a huge amount of features and supporting applications that are largely superfluous for a custom-built and tailored system.

Why LFS is not a great platform

LFS is not perfect however. The hurdle that causes most LFS users eventually to fall down and revert to a mainstream distribution is that of long-term maintenance of the LFS system. There is, by default, no concept of a package management system. When you install an application, you download the source code, and build the executable binaries and libraries and install them on your system. If there is a “dependency” issue like a missing library or something, this must be installed first before you can continue. In most respects this isn’t such a bad thing, but if you want to try some new app out it can involve building a great deal of software that you may realise, afterwards you don’t really want. Removing the unwanted can be a PITA.

My Desktop OS is Ubuntu. It works, and is very easy to upgrade and manage.

What happens next then?

In a few recent weeks, there has been a great flood of discussion and debate on the LFS mailing lists. The original thread for this debate, started by a long term LFS editor called Jeremy Huntwork, has sown the seed for a process to review what LFS is all about and how it could be taken forward whilst still maintaining the core principle of being an Educational Project first and foremost.

One area where I feel the project’s new direction and strategy could really benefit is from some “new blood” with few pre-conceived ideas or historical baggage.

If you use Linux, don’t really know what is going under the hood but want to, then please visit the LFS website, download or read on-line the current book and start working your way through it. Join the mailing lists (either directly or go through gmane and your favourite newsreader), and please contribute your views and experiences.

We really want to give LFS a new lease of life and that, IMHO, needs some fresh ideas and thinking too.

Tell Someone Else!

Open Source Cars and More

I love this article on zdnet from David Greenfield. It’s a round-up of what’s happening in the up and coming area of Open Source Hardware. According to David,

A burgeoning trend in open source hardware is putting up some devices on the Web — from machines that make anything (including themselves) to cars — with the specs to make them yourself (See our list below). While still in its infancy, the trend could redefine hardware cost models much as its done for software.

And there are some neat really ideas like this one which I have been following myself for a while:

Now that you’ve got Asterisk, what hardware platform will you run the software on? Usually folk settle on a Intel or AMD based-server of one kind or another. You can build your own PBX hardware with the Astfin Project or buy one for just $450 from the Free Telephony Project store.

This Asterisk appliance project has the chap who wrote the brilliant Open Source Echo Canceller I mentioned before in it.

But how about your own, Open Source Car…

Open Source isn’t just for your office. The OScar aims to be the first open source automobile. The goal is to create a utilitarian car that aims to move people from place-to-place sans a lot of the high-tech gadgetry that runs in today cards. Initial concepts call for a four-door, four meter length vehicle weighing about 1000 Kilo capable of reaching 145 KM/hour.

Cool – just the thing to keep a man happy and content in his shed for months.

Tell Someone Else!

Remote Firefox over X/SSH

Here’s a quick tip…

I was trying to get a Firefox session running over an SSH connection between my desktop PC (Ubuntu 7.10) and the little server I’m building. The strange thing was, every time I typed firefox & at the command line prompt, it started Firefox all right; but it started a local (Ubuntu) instance of it with my local profile settings! One of the reasons I wanted to run a remote browser was so I could download files directly to that machine and so I could access some html docs on that box; as it is now headless.

A bit of Googling led me here, where the author used this command ( export MOZ_NO_REMOTE=1; firefox -profilemanager ) &. After a bit of experimentation, and more Googling, for my purposes it can be simplified to this:

firefox -no-remote &

This assumes Firefox version 2 and that your SSH connection was made using ssh -X uname@host

Hope this helps someone else. It got me foxed for ages initially…

Tell Someone Else!

Untangle, Asterisk PBX and File Server; All-in-One. Part 8

If you’ve been following the story so far you’ll now where I am. If you haven’t, please go back to Part 1 and read from there. Alternatively if you click on the Untangle tag in the tag cloud then you should get all of the posts so far.

Hi all,

I’ve not yet got any further with the Untangle portion, but pretty much everything else is now in place and working

Last night I built and installed the few remaining applications that are necessary to support my objectives:

• MySQL (I need this for Joomla! and vtiger)
• Postgresql (I need this for untangle)
• Apache
• PHP (and some associated libraries for added functionality, i.e. HTML-Tidy, mm, libmcrypt, mhash…)

I have also been thinking about what it is actually I am trying to achieve. I find a picture really helps so here’s a block diagram of the applications I want and how they should interface to the outside world…

This was a good exercise that helped me to understand the flow of traffic and what needs to be prevented from passing through the server. The dotted line from Apache to the Internet is because I’m not sure yet whether I’ll actually provide any sort of public web presence from this box or not. I doubt it somehow but you never know…

If anyone has any comments or suggestions for improvements I’d be happy to hear them. I made the original diagram in OOo draw. Here’s the original file if you want to use it or alter it. As with all other stuff on here, its CC licensed.

Tell Someone Else!

Untangle, Asterisk PBX and File Server; All-in-One. Part 7.1 (OSLEC)

O.K. I said I’d write a bit about an excellent new echo canceller which happens to work with Asterisk. Here it is it’s called OSLEC the Open Source Line Echo Canceller and it’s written by a chap called David Rowe.

As readers may recall, I’ve built a small home server (VIA CN700) on which I plan to run Asterisk, Samba and Untangle. Samba is up and running and Asterisk is too. I have a single port, very cheap (about £15 inc postage from the USA) x100p card providing an interface to a normal analogue PSTN telephone line.

When we got everything working, we noticed a great deal of echo on voice calls over the x100p. Lots of playing with gains and various settings in the zaptel configuration failed to make any noticeable difference.

I came across this site whilst looking for something completely different and started to read… It sounded like just the thing. A bit of jiggery and a quick patch to the zaptel-1.4.5.1 sources – thanks to the asterisk mailing list – and I got the OSLEC canceller working.

Basically here’s what to do:

1. Build the OSLEC module (it will need to find your kernel sources – just like zaptel) according to the instructions on the website. Once built and you’ve checked that you can install it by inserting the module into your running kernel, copy it (oslec.ko) to your kernel’s loadable module directory: on my system the zaptel modules reside in /lib/modules/2.6.23/misc/ so that’s where I put the oslec module too.
2. Patch your zaptel source tree (if you have version 1.4.5.1 you will need to patch Makefile.kernel26 or OSLEC will never get loaded) and rebuild and re-install as described. (Caution: Backup your /etc/zaptel.conf, /etc/asterisk/zapata.conf and your modified SysV init scripts so you can simply overwrite the default files installed when you rerun make install on the zaptel sources.)
3. Edit your zapata.conf so the following are as below:
   echocancel=yes
echocancelwhenbridged=no
;echotraining=400
4. Reload everything (if in doubt, stop asterisk and zaptel using your SysV init scripts, e.g # /etc/rc.d/init.d/{asterisk,zaptel} stop. Then start them again. When zaptel starts you should see a message saying Echo canceller OSLEC or something like that; if it says MG2 then it isn’t working so you need to go back and recheck your build and patching and module loading.

That’s it.

Now make or receive a call through your cheap x100p card and marvel at the clear echo free sound! It worked brilliantly for me. Of course YMMV but it is definitely worth a try. Most of the reports on the ‘net are incredibly positive about this.

Tell Someone Else!

Untangle, Asterisk PBX and File Server; All-in-One. Part 7

There’s no Untangle in this installment – I’m awaiting a new kernel from the developers before I can get any further; it should be here shortly however.

In the previous article of this series I mentioned that I’d explain how to get Asterisk built and running as a non-root user. It wasn’t too hard to be honest but I’ll document it anyway.

The problem: Asterisk by default, when compiled from source, expects to be run as root. For userspace applications, this is NEVER a good idea in my opinion. After all we’re running on a multi user system that can support non-root processes – unlike Windows – so we really should…

The solution for Asterisk-1.4.13 on my LFS based system, is as follows:

Build any hardware add-ons and codecs you need before building Asterisk. I built the Zaptel module for my x100p card and the Speex Open Source VBR codec. The zaptel module needs to find your kernel source tree (usually in /usr/src/linux-2.6.x.x). To build the zaptel source:

./configure --prefix=/usr
make menuselect (to select/deselect the modules you wish to build)
make

then as root:

make install

and optionally:

make config This will install the SysV init scripts and some default configuration files. You may need to modify the init scripts depending on your system.

Simply follow a similar process for the Speex codec…

For Asterisk, start off by creating a group and user that will run and own the asterisk process and files (select {G,U}IDs and names that are appropriate for your system).

groupadd -g 75 asterisk
useradd -c "Asterisk PBX" -d /var/lib/asterisk -g asterisk -s /bin/false -u 75 asterisk

Edit the Makefile in the top of the asterisk source tree so that the line:

ASTVARRUNDIR=${localstatedir}/run becomes ASTVARRUNDIR=${localstatedir}/run/asterisk

Then build as normal

./configure --prefix=/usr
make menuselect (Turn on/off various modules and options. Select sound files/language/format and extra sounds. Type “s” to save and exit)
make

Then as root:

make install

Asterisk is now installed. But because we will run the process as non-root it needs write permissions for these directories and their contents:

/var/lib/asterisk, /var/log/asterisk, /var/run/asterisk, /var/spool/asterisk, /dev/zap/*.

If you installed the zaptel modules and used the ‘make config’ command, a udev rules file (zaptel.rules) will be written to /etc/udev/rules.d. This enables, by default, udev to create the zaptel device files as user:group asterisk. If you chose another name above you will need to edit this file accordingly.

O.K., lets sort out the ownership and access to the files Asterisk needs. First change the owner:

chown -R asterisk:asterisk /var/{lib/asterisk,log/asterisk,run/asterisk,spool/asterisk}

Now set read/write only by owner, read only by group and no access by other:

chmod 750 /var/{lib/asterisk,log/asterisk,run/asterisk,spool/asterisk}
chmod -R o= /var/{lib/asterisk,log/asterisk,run/asterisk,spool/asterisk}

This switch (chmod -R o=) is pretty cool by the way. It removes all access to all files and directories for the “other” classification, effectively setting them to “0″ but does not change or overwrite any of the permissions for owner and/or group access.

The asterisk process itself only needs read permission for the configuration directory (/etc/asterisk) and its contents (almost¹):

chown -R root:asterisk /etc/asterisk
chmod 750 /etc/asterisk
chmod 640 /etc/asterisk/*

Some of Asterisk’s ‘.conf’ files contain cleartext passwords and other potentially sensitive information. Setting the files as above permits read/write only by the user root and read only by members of the group asterisk.

That’s it basically. When you start asterisk from the SysV init scripts, pass the following arguments to have it run, safely, as your new user:

asterisk ${DEBUG} ${ZAP_TIMING} -U ${USER} -G ${GROUP}

In my startup script, I’ve set those constants above to be:
# If you want debug messages to the console and the logs switch the
# comments below
DEBUG=""
#DEBUG="-d"
# The user and group we created earlier
GROUP="asterisk"
USER="asterisk"
# Use this if you want to limit the maximum number of simultaneous calls
# to prevent system failure for example
MAXCALLS=""
#MAXCALLS="-m 20"
# If you have a Zaptel card/timing source, enable it here
#ZAP_TIMING=""
ZAP_TIMING="-I"

That’s it.

When asterisk starts, it will run as the user and group defined above. In the next installment, I will write a bit about a fantastic new echo canceler which sorts out cheap x100p cards and makes them work properly… It’s really excellent.

1. Except for voicemail.conf. When a user changes their pin asterisk writes these changes to the voicemail.conf file.

Tell Someone Else!

Untangle, Asterisk PBX and File Server; All-in-One. Part 6

If you’ve been following the story so far you’ll now where I am. If you haven’t, please go back to Part 1 and read from there. Alternatively if you do a search for Untangle in the little search box top-left then you should get all of the posts so far.

I have stalled on Untangle due to kernel issues already well documented on here before. The good news is the guys from Untangle are in contact with me and are working on a new kernel for the upcoming 5.1 release. I am hoping to get something to play with in the next few weeks. And it will most likely be based on a 2.6.22 release which is excellent news as that has direct support for my hardware.

So in the meantime I have been installing Samba – which is fairly straightforward – and Asterisk which is a bit more involved.

As you will know, I am using the Linux From Scratch (LFS) project for this server’s operating system. From the same stable, comes the Beyond Linux From Scratch (BLFS) book that contains many (i.e. hundreds) excellent resources and instructions for installing various applications; including Samba. So I will not go into detail about how to build Samba here. The configuration of Samba for my home network is another subject and I will discuss this further once I’m happy with the set up.

Asterisk, the Open Source PBX, is another ballgame entirely. To build asterisk itself from source is not too hard. From an LFS core, there were no dependencies to satisfy first. If you are on a major distro however, you will certainly need to add quite a few -dev packages to your system first. With Ubuntu they have a meta package called build-essentials which will certainly help. Here is a good starting point for information: http://www.voip-info.org/wiki/index.php?page=Asterisk+installation+tips.

To build asterisk for testing purposes, build and install as root*. As I have an x100p analogue FXO card I need to install the zaptel driver first like this (after extracting the source tarball and cd‘ing into it):

./configure --prefix=/usr &&
make menuselect &&
make &&
make install &&
make config

Both this and the Asterisk build expect your kernel source tree (the headers) to be in /usr/src/linux-`uname -r` by default. The make menuselect command will enable you to select which hardware drivers you need and to disable the building of those you do not. make config will install a rc.d script for init so the card is properly initialised during boot-up. Although I had to hack this a bit to work with the LFS/BLFS boot scripts. Even if you do not have any analogue cards, you are recommended to install the zaptel drivers as they can provide timing a source for Inter-Asterisk Trunks (IAX) and conferencing via the ztdummy module.

Once the zaptel modules are installed, repeat a similar process for the Asterisk source:

./configure --prefix=/usr &&
make menuselect &&
make &&
make install

This should build and install the Asterisk server into the /usr hierarchy with the configuration files in /etc/asterisk and the runtime information and sound files under /var. When you run make menuselect pay attention, you can choose whether to install various language files, codecs, add-on sounds (I installed the extra sound files) and other goodies. Here’s a page that should help you get going once again: http://www.voip-info.org/wiki/index.php?page=Asterisk+Compile.

You can elect to install sample configuration files, by typing make samples. This will basically give you a working PBX out of the box for testing purposes. This is sort-of-useful but the files are very complicated and hard to follow, although they are well commented so they make a good reference. I quickly removed the whole /etc/asterisk directory to somewhere else (to keep for reference) and started from scratch with a clean directory.

Learning how to setup asterisk is time consuming. Then comes that moment when, after reading for hours and looking into lots of text files and learning about channels, priorities, applications and contexts, suddenly the penny drops! It will become clear. But don’t rush it and I would strongly recommend NOT going for one of the packaged appliance builds that come with a GUI front end to start with. Why? Because you will never learn what’s under the hood and you will be limited by the GUI designer’s ideas of what you need to configure. Once you ‘get it’, by all means use a GUI, but not before…

For testing you will need a phone I know. Obvious but it had to be said. There are plenty of SIP phones on the market that are inexpensive, and there are several “soft phones” that you can run on your PC and use a headset, or mic & speakers. I chose to go the soft phone route for now and tried the following three soft phones for Linux.

• Ekiga: Formerly Gnome Meeting. Initially I thought this was great but I have had several weird issues with DTMF and sound quality, so this is on the back-burner for now.
• Wengo Phone: Looks nice, seems to work O.K. but I preferred the User Interface and overall experience of the final one in my list.
• Twinkle: This just works. Has a simple and easy to use interface and is a cinch to setup. My personal favourite of the three (apart from the name, that is.)

These soft phones I used purely for SIP connectivity on my local LAN to the Asterisk server. There are others that can connect to Asterisk using IAX or H.323 but I didn’t try those, nor see a need to.

Here are a couple of resources I found very helpful along the way:

• The voip-info.org wiki for Asterisk
• This excellent short slide presentation (They say a picture paints a thousand words don’t they…)
• This e-book: The “TFOT” Book (If this site is down, google for it. It’s available from lots of other sources)
• And google. There is loads of information out there if you are prepared to look for it.

Along with my business partner who has installed Asterisk on his similarly small and low-powered server, we now have fully networked digital PBX functionality (IAX trunking between our servers), Voicemail (with email notification and forwarding), and Dial-in & Dial-out via the PSTN (through the x100p card on my box). Next is to try conferencing and call parking.

With this little server (shown here with the x100p card installed), I now have Samba, providing a home network file server for all the family, Asterisk running happily and providing advanced digital telephony throughout the house. And all using free and Open Source software. Once I’d bought the hardware, the software costs were zero, and will be zero. How much is Windows Home Server? And more to the point, why do you need it? Oh yes, does it also have a fully fledged enterprise grade digital PBX? And is it secure? (Just like the rest of Windows… lol)

Once I’ve nailed the configuration down and got asterisk running securely*, I’ll post some more on this including configuration details.

* The usual way to install Asterisk from source is by, and as, root. For a test-bed that’s no problem but for a production environment with direct internet connectivity (as this device will have) this is not a good idea. I will spend a little time developing an installation procedure that will install it as a non-root user and with limited privilages. The suggested mechanisms I have found on-line are not quite as I would like them. I try and keep to the FHS where possible and maintain a “tight” ship. This process I will also document once it’s nailed…

Tell Someone Else!

Untangle, Asterisk PBX and File Server; All-in-One. Part 5

If you’ve been following the story so far you’ll now where I am. If you haven’t, please go back to Part 1 and read from there.

I’ve been a bit busy recently so haven’t had as much time as I’d like to crack on with this. However, I’ve actually come to a bit of a halt regarding Untangle due to the kernel…

I managed to get the initial Rake (Ruby’s Make) build scripts to run to completion on my LFS-6.3 system . For those who are interested, after editing some of the Rake files for hard-coded environment variables, I had to drop down to the last version 5 release of the JDK. Version 6 is not supported due to the issues mentioned in part 4 of this series.

After the build completed, trying to run Untangle caused it to barf badly. But I wasn’t surprised by this. I hadn’t installed Postgresql, and I discovered I was missing a setting in my kernel config (IP Userspace queueing via NETLINK (OBSOLETE)) which caused this file ip_queue_maxlen to be created in /proc. There was another file in /proc missing too: icmp_frag_accept. It was searching for this, that led me to get to the bottom of the kernel issues.

After some dialogue on their mailing lists, it became clear that the build process was not going to be as simple as I’d first thought. The current version of Untangle (5.0.2) uses a very heavily patched Debian kernel (2.6.16-ck11). The method they use for patching relies on some debian tools which, seeing as I am building on LFS, I don’t have – nor do I really want.

A little side note: In the Untangle kernel, they are using the now infamous CK scheduler from Con Kolivas, that is no longer being developed for, or ported to, the main kernel tree (Google for Con Kolivas to read about the saga). I’m not sure how this will affect the UT project in the long run but it is quite an interesting area of kernel development and fuelled some big arguments.

When I have some more time to concentrate, I’ll try and work out what is really needed and see if I can patch my recent 2.6.22.5 kernel. They are developing a new release of Untangle (5.1) which may well give me what I need anyway; the ability to run other apps on the same platform and a more modern kernel version. Watch this space…

In the meantime, I have managed to get Asterisk installed. It’s a fairly straightforward CMMI (configure, make, make install) install for the needed packages (in build order): zaptel-1.4.5.1 drivers for the x100p card, asterisk-1.4.11 and asterisk-addons-1.4.2.

Configuring asterisk however is another ball game entirely. It is fairly complicated and involves a steep learning curve. Although thankfully, there are plenty of resources available on-line. I strongly recommend to get the Creative Commons Licensed O’Reilly book from 2005: Asterisk – The Future of Telephony which is widely available on-line and is an excellent resource. Also, there are lots of good blogs and other online resources to help you get started.

In addition, you will almost certainly need a SIP phone of some description. I’m currently using the Ekiga softphone as it is open source and happily runs on Ubuntu (it’s gnome based). It was originally called GnomeMeeting.

I can now make and receive calls locally between the Asterisk server and my PSTN line. Next is to try and get it work over a NAT’ed firewall to Alan Bell’s (my business partner) Asterisk server. Using IAX2 (Inter-Asterisk Exchange protocol) seems the way to ge here as it was specifically designed to use a single IP port, as opposed to SIP that uses independent ports (and potentially many of them) for connection management (UDP) and actual call data (RDP). Using SIP requires you to open up hundreds, if not thousands, of ports on your firewall. More reading and learning to follow.

Laterz…

Tell Someone Else!