Pauls Blog

Asterisk is an open source PABX. Thats right, it is a fully featured scalable PABX that supports both voip, pstn, isdn and voicemail that can be used anywhere from a home office to a multi site corporation.

And whats more, it is open source. Which essentially means you can choose your level of financial investment. If you are a small business owner, this can be an ideal solution, particularly if you have or are willing to develop the skills to manage it, your costs can be zero beyond your time and hardware costs.

This isn’t about asterisk itself however, so more details can be found here: http://www.asterisk.org

This post is about FreePBX (http://www.freepbx.org), which is a web based front end to manage asterisk. Asterisk is amazingly flexible, and the options you have of defining how it behaves when it recieves a call are infinite. It is also relatively easy to learn how to develop dial plans for asterisk, but ultimately, building and managing a complex asterisk configuration can be a time consuming process.

This is where freepbx comes in. It dramatically simplies the management of asterisk, and has a large number of modules that you can add in to bring in all the functionality you could wish for, providing features for nothing that would only ever be available on the highest end commercial closed box PABX solutions.

Freepbx needs to interact directly with asterisk, and modify its configuration files. In terms of compartmentalising access rights, this can be problematic, as freepbx needs to run its web server as the asterisk user. But if you are already running apache, your webserver will already have a user id that it runs under – probably “apache”, and you don’t want to give either this user access to your asterisk configuration files, and nor do you want to run your web services as “asterisk” and have to change the permissions of anything it might need to access.

Apache has some modules in developement that will allow a single web site to run under a specific user id. This will be great when it finally is ready to use, particularly in the web hosting arena, where having a common user for all web sites presents problems. However, it isn’t ready.

One solution is to run a separate web server instance for asterisk. As this article is aimed at someone who is sharing the funtionality of their server between asterisk and other tasks, this may seem a resource heavy solution. However, consider using “lighttpd”. This is as the name suggests, a lightweight web server. It has a good set of features, but isn’t as hungry as apache. You can just run it on a different port – 81 for example, and have it run as the “asterisk” user.

You can also leave it running as the “lighttpd” group, which will enable the daemon to retain the permissions on the files it needs to access, such as its log files.

This means that all of the freepbx files can be owned by asterisk and still be updatable from the web frontend. This is one of the primary reason why the “Warning: Cannot connect to online repository (mirror.freepbx.org). Online modules are not available.” is received when trying to update the FreePBX modules. It is almost always a permissions issue.

I say “almost always”. Recently there has been a drive with php installations to have “allow_url_fopen” option set to “off”. What this means is that any functions that are “file” related – such as reading a file from a disk, cannot also be used to open a URL. If a url needs to be opened, the curl library is the recommended solution. The reason for this is that many recent exploits have taken advantage of insecure code along with having this setting enabled to completely take over a site.

FreePBX at the time of writing (2.4beta2) expects to be able to open urls as files. To change this setting, edit your php.ini file and change the “allow_url_fopen” option to On. Do not do this unless you understand the implications and risks.

This file can reside in a number of places depending on your distribution. Often it is at /etc/php.ini.

Gentoo has a different php.ini depending on what is happening. For the apache server, the php.ini is at:

/etc/php/apache2-php5/php.ini

For lighttpd, it uses the cgi version:

/etc/php/cgi-php5/php.ini

Incidentally, the command line option is: /etc/php/cli-php5/php.ini

Drop us a query if you need further information on this…

Paul

This article is a follow on from my previous go at putting together a technique for encouraging Sabayon to move away from using packages that are masked for testing, and to use stable packages instead. I posted a link to the original at http://www.sabayonlinux.org forums, and voxiac pointed out the obvious: If you want to get to a stable environment, then the goal should be to change the ACCEPT_KEYWORDS from accepting all test masked packages to using stables. The rest can follow from there. So this is how do to it.

Note: All references to ~amd64 should be changed to reflect your architecture – probably x86 if not amd64

First things first, edit /etc/make.conf and either comment out, remove, or change the ACCEPT_KEYWORDS line to:

ACCEPT_KEYWORDS=amd64

If you do this, you must do the rest, otherwise you could be in trouble next time you get to emerge something. This line tells emerge that all packages must be stable, unless explicitly stated in /etc/portage/package.keywords

Next we need to get the list of packages that are currently masked as test packages, and create a file that we can use to add to the package.keywords to let emerge know that they can remain as test packages.

We use three commands piped together to do this. You can try these out stage by stage so that you can see exactly what is going on. The first part is:

equery -i -N list

This shows a list of installed packages, such as:

[I--] [ ~] x11-wm/twm-1.0.3 (0)

The second column will contain a tilde ‘~’ if the package is masked. These are the packages we need, so we will pipe the output into grep to pull out only those lines that contain a tilde:

equery -i -N list | grep \~

The output will now only contain the masked packages. We need to manipulate each line a little to pull out just the package name, and then add the prefix and suffix we need ready for the package.keywords file:

equery -i -N list | grep \~ | sed 's/.* \(.*\) (.*/=\1 ~amd64/'

This transforms the above line:

[I--] [ ~] x11-wm/twm-1.0.3 (0)

into:

=x11-wm/twm-1.0.3 ~amd64

This means “permit use of a masked package for x11-wm/twm, for version 1.0.3 only.”

We just need to output the results of that to a file, and append it to /etc/portage/package.keywords

Output to a file:

equery -i -N list | grep \~ | sed 's/.* \(.*\) (.*/<=\1 ~amd64/' > testpackages

Append to the end of /etc/portage/package.keywords (take a backup first):

cp /etc/portage/package.keywords /etc/portage/package.keywords.back

cat testpackages >> /etc/portage/package.keywords

This last command will need to be done with root privileges. If you followed the previous article’s approach, you will have a bunch of old entries in their from the previous method. These will need to be removed first.

Once you have done this, you can effectively leave it alone. As new packages are released into the stable tree, they will supercede the ones you have installed, and the package.keywords entries will be ignored. voxiac suggested a cron job that would clean up the package.keywords file over time. I’ll have a go at putting something together down the line, depending on what level of hassle the cleanup is.

By the way, this command will give you a count of the current test packages you have installed:

equery -i -N list | grep \~ | wc -l

Versus total installed:

equery -i -N list | grep \/ | wc -l

My count is:

Total: 1347, of which are unstable: 852.

Quite a way to go….

The following talks about how you can gradually move Sabayon from the testing tree to the stable tree of portage.

Sabayon. Very cool. However, it is a bit disturbing that it bases everything on the testing tree of portage.

In make.conf, there is a line:

ACCEPT_KEYWORDS=~amd64

That last part may read ~x86 if you are on a 32bit platform. In gentoo speak a package is “masked” in the portage tree (the software repository) until it has completed testing. The ~x86 or ~amd64 keyword identifies a packages as being in testing. Once testing is complete, the keyword changes to “x86″. Ie, without the tilda.

The line above is essentially saying that whenever you install a package, it should install the latest testing version.

This can lead to problems, as the packages in testing haven’t been tested to see if they are ready for release – that they haven’t been QAed to work with everything else you may have installed.

So just remove the line from make.conf right? Wrong. The dependencies that packages have on each other are far too complex for this to work. Another strategy would be to work out groups of packages that work together, and roll them back to stable using /etc/portage/package.keywords and /etc/portage/package.mask

Forget it. Portage is the tangled web we weave.

The following approach works on this principle: You accept that you currently have a bunch of testing packages installed,but everything seems to be working. Then take advantage of the fact that lots of people are volunteering their time to ensure that these packages are suitable for release, or fixing them so that they are. So if you could say “Ok, no package can be upgraded from now on until they are in the release tree”.

So look at this:

equery -i list | sed 's/(.*)/\>\=$1 -~amd64 amd64/' > packages

This command will get a list all of your currently installed packages, add a “>” to the beginning of each line, and add ” -~amd64 amd64″ to the end of each line, and output them all to a file called “packages”

So if the package was this:

media-video/vlc-0.8.6-r1

Now it looks like this:

>media-video/vlc-0.8.6-r1 -~amd64 amd64


If this line were put into /etc/portage/package.keywords, it would be saying “remove the “~amd64″ mask from this package, and add the release mask, if the version number is greater than the one shown. In other words, don’t install any more test versions for this package.

So if the file you generated is added to the end of /etc/portage/keywords then any updates to these packages will not be installed unless they are in the release tree. So now, all you need to do is wait until enough packages are in release that you feel confident you can remove the ACCEPT_KEYWORDS line from make.conf.

Note that for the above file, the first line of the “packages” file will not be valid. Remove the first line. You can append the file to package.keywords with (as root):

cat packages >> /etc/portage/package.keywords

Note that this is not a fire and forget solution. There are likely to be dependency tweaks you need to make as you go along, and you will have to enter a line in package.keywords for any new packages you install, but this at least will stop “emerge world” from ensuring your system is never stable.

Yeah, Windows sucks. It is truly awful. But a necessary evil for myself and many others.

One of the suckiest things is how it refuses to accept that there can be in existence any other operating systems in the world but itself.

So I have a PC, and had a Windows and Linux install for some time running together, with grub in the MBR handling the booting both Linix and Windows. Or at least passing booting off to ntldr to bring windows up. No problem.

But then I wanted to reinstall Windows in another partition. It is always good to do a reinstall of Windows into a fresh partition so that you can copy over bits and pieces of the old install as you need them (notably stuff in the Application Data folder in your profile). So it was time. My Windows installation had gotten slow and bloated after only six months, as I randomly install software to make the experience more palatable. My new strategy was to run everything from Linux primarily, and do Windows stuff from a windows VM on my server, and just use native Windows for games.

I did try and use VM Server as a way of reinstalling Windows into the partition without having to leave Linux, by creating a partition based disk for the vm. VM Server reports that the partition table is invalid if you do this on my install. There are a few people who have experienced this before, but none seemed quite the same as mine, and I didn’t get to the bottom of it.

So it was time for a native install. So a PC fairly useless while Windows gets on with copying itself. Except it didn’t work. This was new – most of the problems you get with Windows I have encountered one time or another but this one I hadn’t seen.

The CD would boot, and do the “Checking Hardware configuration” message that precedes the blue install screen, but it never got to the blue. It just cleared the screen and hung.

So.. a bit of a googling (sorry Google for using your name as a verb, but seriously, it is one now) and I discover that Windows XP install will not work if there is a boot sector that it doesn’t know. Ie, if there is one present, and it isn’t a Windows one. Either that or the partition tables aren’t aligned the way it expects.

So a bit of monkeying around later – reorganising the partitions in a way that I did not want, and having to boot the disk with no hard drives connected, I finally got Windows installed. Of course my boot sector is now trashed with the Windows one instead of grub.

But clearly putting grub back is only going to give me problems next time I want to wipe windows.

The good news is that you can boot Linux – essentially chain grub – from NTLDR – the windows boot manager. There are a stack of articles about it around, and from my experience GRLDR doesn’t work – this is the grub4dos boot manager that should be able to read and process a standard menu.lst file. The documentation is erratic, and says that it must on the boot drive, but cannot be on ntfs. Not sure how you resolve that if your boot drive is ntfs.

So the other way is to get a copy of the grubbed boot sector, make a file out of it, put it in the root of your boot drive, and just add it to boot.ini.

You need to understand which is your boot drive. In my case grub was installed in the MBR of the primary disk /dev/hda. After all this stuffing around, that had been wiped, so I reinstalled it into another drive:


# grub
grub> root (hd0,7)
grub> setup (hd0,7)


This will install grub into /dev/hda8 (the eighth partition of the first ide drive – grub itself numbers partitions from zero). If your first drive is SATA, then this may refer to /dev/sda

Now make a copy of the first 512 sectors:


dd if=/dev/hda8 of=linux.boot bs=512 count=1


Copy this to your primary Windows partition – wherever boot.ini resides (usually c:\). Then edit boot.ini and put in the line:


c:\linux.boot="Linux"


Reboot, and this will appear in the standard boot menu for Windows.