Pauls Blog

The latest release of OpenSuse 11.2 ships with the new 190 drivers from nVidia, which are not compatible with Xen. Well that may be but here is how to get it working with the 185 drivers. The main problem is you get a modpost GPL infringment, which prevents the kernel module being linked, but you can get around it:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'xen_features'

Here are the steps:

1) Download NVIDIA-Linux-x86_64-185.18.36-pkg2.run from nvidia
2) execute


chmod +x NVIDIA-Linux-x86_64-185.18.36-pkg2.run
./NVIDIA-Linux-x86_64-185.18.36-pkg2.run --extract-only
cd NVIDIA-Linux-x86_64-185.18.36-pkg2/usr/src/nv

3) edit Makefile.kbuild, and after

EXTRA_CFLAGS += -Wall -Wimplicit -Wreturn-type -Wswitch -Wformat -Wchar-subscripts -Wparentheses -Wpointer-arith -Wno-multichar -Werror -mcmodel=kernel -mno-red-zone -fno-defer-pop -MD $(DEFINES) $(INCLUDES) -Wsign-compare -Wno-cast-qual -Wno-error


Insert:


XEN_FEATURES := $(shell grep "D xen_features" /boot/System.map-$(shell uname -r) | colrm 17)
EXTRA_LDFLAGS := --defsym xen_features=0x$(XEN_FEATURES)


Note: the colrm 17 is applicable to 64bit only. For 32bit, use colrm 9.

4) The usual:


export IGNORE_XEN_PRESENCE=1
export SYSSRC=/lib/modules/$(uname -r)/source
export SYSOUT=/lib/modules/$(uname -r)/build
make module


Then copy nvidia.ko to /lib/modules/2.6.31.5-0.1-xen/updates/
and ../../X11R6/lib/modules/drivers/nvidia_drv.so to /usr/lib64/xorg/modules/updates/drivers/

(adjust these for your install).

6) Either modprobe nvidia or reboot and startx

It is relocation time – the ServWise Australian operations centre is moving, from Albury NSW to Melbourne VIC.

What does this mean to our customers? Actually, there should be no impact at all to service. Both sites will be operational concurrently for a small overlap period and we have our northern hemisphere op centre of course, but zero-impact is achieved in the main by keeping op centre dependencies to a minimum. As the critical ServWise infrastructure is housed in data-centres seperately frop ops, it can be conceivably managed and monitored from anywhere at any time.

The impact behind the scenes is clear and present though, but just the usual stuff. The new site needs cabling and other fit-out work done, and in an attempt to streamline things and hopefully get some coordination going between parties, we are having a single day for surveys for the cabling guys, internet provision, flooring, painting etc and utilities. Hopefully getting them all together we can get an agreement on how to proceed, so as to avoid cable guys carving holes in newly painted walls and painters not spilling paint on new carpet. Of course, they all say that they should do their part first

Furniture will be relocated to the new site from the old pretty quickly, but will need some basics there to get it all up and running so we can operate from both. And duplication of routing/switching and some server infrastructure. All fairly basic, but it still needs to be done, tested and solid.

All in all it will be great to be back in Melbourne. I was based out of there prior to the incarnation of ServWise and I am looking forward to being back amongst it all.

Forgetting to add an attachment to an email is a common enough mistake.  One of the things I like about Thunderbird is it’s simple extensibility.

So if you find yourself wishing that there was a way to fix the way you do something, or a tool of some kind that that will help with a process, then someone else has almost always had the same problem and created an add-on that alters or adds to Thunderbird in such a way that it solves your problem.

Forgetting attachments is one of those things, and the link goes to a module that will scan any email that you send, looking for an indication that you intended to send an attachment, but didn’t.  In my case, this is as simple as saying, “if I have the word ‘attach’ in my email, and there is no attachment, then just check with me before you send the email”.

This has saved me more times than I like to consider

https://addons.mozilla.org/en-US/thunderbird/addon/5759

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