The Open Sourcerer

How to install OpenERP 6.1 on Ubuntu 10.04 LTS

The new release of OpenERP 6.1 heralds a great many incremental improvements in the product plus a complete re-write of the web interface; which is a massive improvement and much more an integral part of OpenERP than it’s predecessor.

UPDATE: By popular request here is a subsequent post describing how to set up a reverse proxy and ssl using nginx.

As my previous howto for 6.0 was a such roaring success I thought I’d better do something for the new 6.1 release too.

Before continuing, I should mention that you can simply download a “.deb” package of OpenERP 6.1 and install that on Ubuntu. But that doesn’t provide me with enough fine grained control over what and where things get installed and it restricts our flexibility to modify & customise hence I prefer to do it a slightly more manual way… (It should be said though, that this install process should only take about 10-15 minutes once the host machine has been built)

So without further ado here we go:

Step 1. Build your server

I install just the bare minimum from the install routine (you can install the openssh-server during the install procedure or install subsequently depending on your preference).

After the server has restarted for the first time I install the openssh-server package (so we can connect to it remotely) and denyhosts to add a degree of brute-force attack protection. There are other protection applications available: I’m not saying this one is the best, but it’s one that works and is easy to configure and manage. If you don’t already, it’s also worth looking at setting up key-based ssh access, rather than relying on passwords. This can also help to limit the potential of brute-force attacks. [NB: This isn’t a How To on securing your server…]

sudo apt-get install openssh-server denyhosts

Now make sure you are running all the latest patches by doing an update:

sudo apt-get update
sudo apt-get dist-upgrade

Although not always essential it’s probably a good idea to reboot your server now and make sure it all comes back up and you can login via ssh.

Now we’re ready to start the OpenERP install.

Step 2. Create the OpenERP user that will own and run the application

sudo adduser --system --home=/opt/openerp --group openerp

This is a “system” user. It is there to own and run the application, it isn’t supposed to be a person type user with a login etc. In Ubuntu, a system user gets a UID below 1000, has no shell (it’s actually /bin/false) and has logins disabled. Note that I’ve specified a “home” of /opt/openerp, this is where the OpenERP server code will reside and is created automatically by the command above. The location of the server code is your choice of course, but be aware that some of the instructions and configuration files below may need to be altered if you decide to install to a different location.

A question I was asked a few times in the previous how to for 6.0 was how to run the OpenERP server as the openerp system user from the command line if it has no shell. This can be done quite easily:

sudo su - openerp -s /bin/bash

This will su your current terminal login to the openerp user (the “-” between su and openerp is correct) and use the shell /bin/bash. When this command is run you will be in openerp’s home directory: /opt/openerp.

When you have done what you need you can leave the openerp user’s shell by typing exit.

Step 3. Install and configure the database server, PostgreSQL

sudo apt-get install postgresql

Then configure the OpenERP user on postgres:

First change to the postgres user so we have the necessary privileges to configure the database.

sudo su - postgres

Now create a new database user. This is so OpenERP has access rights to connect to PostgreSQL and to create and drop databases. Remember what your choice of password is here; you will need it later on:

createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt openerp
Enter password for new role: ********
Enter it again: ********

Finally exit from the postgres user account:

exit

Step 4. Install the necessary Python libraries for the server

Update 27/02/2012: Many thanks to Gavin for reporting. Have added python-simplejson to the package list.

sudo apt-get install python-dateutil python-feedparser python-gdata \
python-ldap python-libxslt1 python-lxml python-mako python-openid python-psycopg2 \
python-pybabel python-pychart python-pydot python-pyparsing python-reportlab \
python-simplejson python-tz python-vatnumber python-vobject python-webdav \
python-werkzeug python-xlwt python-yaml python-zsi

From what I can tell, on Ubuntu 10.04 the package python-werkzeug is too old and this will cause the server to not start properly. If you are trying this on a later version of Ubuntu then you might be OK, but just in-case you can also do the following.

I found it necessary to install a more recent version of Werkzeug using Python’s own package management library PIP. The python pip tool can be installed like this:

sudo apt-get install python-pip

Then remove Ubuntu’s packaged version of werkzeug:

sudo apt-get remove python-werkzeug

Then install the up-to-date version of werkzeug:

sudo pip install werkzeug

With that done, all the dependencies for installing OpenERP 6.1 are now satisfied, including for the new integral web interface.

Step 5. Install the OpenERP server

I tend to use wget for this sort of thing and I download the files to my home directory.

Make sure you get the latest version of the application. At the time of writing this it’s 6.1-1; I got the download links from their download page.

wget http://nightly.openerp.com/6.1/releases/openerp-6.1-1.tar.gz

Now install the code where we need it: cd to the /opt/openerp/ directory and extract the tarball there.

cd /opt/openerp
sudo tar xvf ~/openerp-6.1-1.tar.gz

Next we need to change the ownership of all the the files to the OpenERP user and group.

sudo chown -R openerp: *

And finally, the way I have done this is to copy the server directory to something with a simpler name so that the configuration files and boot scripts don’t need constant editing (I called it, rather unimaginatively, server). I started out using a symlink solution, but I found that when it comes to upgrading, it seems to make more sense to me to just keep a copy of the files in place and then overwrite them with the new code. This way you keep any custom or user-installed modules and reports etc. all in the right place.

sudo cp -a openerp-6.1-1 server

As an example, should OpenERP 6.1-2 come out soon, I can extract the tarballs into /opt/openerp/ as above. I can do any testing I need, then repeat the copy command so that the modified files will overwrite as needed and any custom modules, report templates and such will be retained. Once satisfied the upgrade is stable, the older 6.1-1 directories can be removed if wanted.

That’s the OpenERP server software installed. The last steps to a working system is to set up the configuration file and associated boot script so OpenERP starts and stops automatically when the server itself stops and starts.

Step 6. Configuring the OpenERP application

The default configuration file for the server (in /opt/openerp/server/install/) is actually very minimal and will, with only one small change work fine so we’ll simply copy that file to where we need it and change it’s ownership and permissions:

sudo cp /opt/openerp/server/install/openerp-server.conf /etc/
sudo chown openerp: /etc/openerp-server.conf
sudo chmod 640 /etc/openerp-server.conf

The above commands make the file owned and writeable only by the openerp user and group and only readable by openerp and root.

To allow the OpenERP server to run initially, you should only need to change one line in this file. Toward to the top of the file change the line db_password = False to the same password you used back in step 3. Use your favourite text editor here. I tend to use nano, e.g.

sudo nano /etc/openerp-server.conf

One other line we might as well add to the configuration file now, is to tell OpenERP where to write its log file. To complement my suggested location below add the following line to the openerp-server.conf file:

logfile = /var/log/openerp/openerp-server.log

Once the configuration file is edited and saved, you can start the server just to check if it actually runs.

sudo su - openerp -s /bin/bash
/opt/openerp/server/openerp-server

If you end up with a few lines eventually saying OpenERP is running and waiting for connections then you are all set. Just type CTL+C to stop the server then exit to leave the openerp user’s shell.

If there are errors, you’ll need to go back and check where the problem is.

Step 7. Installing the boot script

For the final step we need to install a script which will be used to start-up and shut down the server automatically and also run the application as the correct user. There is a script you can use in /opt/openerp/server/install/openerp-server.init but this will need a few small modifications to work with the system installed the way I have described above. Here’s a link to the one I’ve already modified for 6.1-1.

Similar to the configuration file, you need to either copy it or paste the contents of this script to a file in /etc/init.d/ and call it openerp-server. Once it is in the right place you will need to make it executable and owned by root:

sudo chmod 755 /etc/init.d/openerp-server
sudo chown root: /etc/init.d/openerp-server

In the configuration file there’s an entry for the server’s log file. We need to create that directory first so that the server has somewhere to log to and also we must make it writeable by the openerp user:

sudo mkdir /var/log/openerp
sudo chown openerp:root /var/log/openerp

Step 8. Testing the server

To start the OpenERP server type:

sudo /etc/init.d/openerp-server start

You should now be able to view the logfile and see that the server has started.

less /var/log/openerp/openerp-server.log

If there are any problems starting the server you need to go back and check. There’s really no point ploughing on if the server doesn’t start…

If the log file looks OK, now point your web browser at the domain or IP address of your OpenERP server (or localhost if you are on the same machine) and use port 8069. The url will look something like this:

http://IP_or_domain.com:8069

What you should see is a screen like this one:

What I do recommend you do at this point is to change the super admin password to something nice and strong (Click the “Manage Databases” link below the main Login box). By default this password is just “admin” and knowing that, a user can create, backup, restore and drop databases! This password is stored in plain text in the /etc/openerp-server.conf file; hence why we restricted access to just openerp and root. When you change and save the new password the /etc/openerp-server.conf file will be re-written and will have a lot more options in it.

Now it’s time to make sure the server stops properly too:

sudo /etc/init.d/openerp-server stop

Check the logfile again to make sure it has stopped and/or look at your server’s process list.

Step 9. Automating OpenERP startup and shutdown

If everything above seems to be working OK, the final step is make the script start and stop automatically with the Ubuntu Server. To do this type:

sudo update-rc.d openerp-server defaults

You can now try rebooting you server if you like. OpenERP should be running by the time you log back in.

If you type ps aux | grep openerp you should see a line similar to this:

openerp 1491 0.1 10.6 207132 53596 ? Sl 22:23 0:02 python /opt/openerp/server/openerp-server -c /etc/openerp-server.conf

Which shows that the server is running. And of course you can check the logfile or visit the server from your web browser too.

That’s it!

OpenERP 6.1 really is a major step up in terms of improvements from 6.0 and the new integrated web interface (with a Point of Sale and a Mobile interface built-in) are really very cool. Performance has improved considerably and the way the new web service interfaces to OpenERP is very different. So, if I get the time, the next instalment of these posts will go into a bit of detail about how this works and some alternative ways to provide more secure access, such as reverse proxy.

C# Is just “SO Last Year”

Most readers of this humble blog will be very aware of my personal opinion about Mono and specifically with regards to where it should belong in Ubuntu.

Free and Open Source Software projects are built using a wide variety of programming languages. Blackduck who study this kind of thing have released some interesting data regarding the use of various languages to develop FOSS applications.

C# (the language of choice for Mono advocates) is languishing in 10th place behind Perl, Python, PHP, Java and many not insignificant others.

And is doesn’t appear to be growing by anything other than what looks like a statistical anomaly.

If one were to listen to some proponents of Mono/C# you might have been led to think that (to be read in a really deep voice like the old Carlsberg ads):

Yeah right.

My other foot has bells on it…

Book Review: Asterisk AGI Programming with Packt

[Please Note: If you follow the book links from this site to Packt’s and decide to buy *any* book from their site, we will get a small commission that we’ll use towards the upkeep of our servers etc.]

As you may have read previously, I was approached by Packt Publishing to see if I would like to review their new book on AGI Programming by Nir Simionovich. Time has conspired against me to actually use it for a real project so instead I resorted to choosing it as my bedtime reading for a few days.

I’ve now read the book and first off I’d like to thank Packt for asking me. I have enjoyed it far more than I thought I would. As for how to review it, I thought I’d give my overall impression and then just go through it chapter by chapter.

It isn’t a long book – about 190 pages – which to my mind is no bad thing. It managed to concentrate on the subject and had little in the way of superfluous text and language (Apart from chapter 1 that is). The author knows his subject well and writes in a fairly informal and easy-to-read style which I personally quite liked. The meat of the book concentrates on – as you would probably guess – programming with AGI and focusses almost exclusively on using PHP. As much as I am happy around PHP, I would have liked to see some examples with alternative languages such as Python perhaps. The subtitle of the book is “Design and Develop Asterisk-based VoIP telephony platforms and services using PHP and PHPAGI” so I guess that’s why other languages don’t get much of a look in. They are mentioned here and there and there are some good links to various other libraries and open source projects. I did like the fact that he mentioned throughout the book – where necessary – the functional difference between the main versions of Asterisk (1.2, 1.4 and 1.6) and ways to deal with those differences when you come up against them.

OK – so here is my chapter-by-chapter review:

Sorry, but I didn’t really get the first chapter at all. This is a book aimed at programmers and developers and yet the first chapter was a repetitive cut-and-paste of how to build the various asterisk components from source, including lots of screen shots showing the output of things like ./configure which personally I found a bit trivial and uninteresting. I was a bit concerned that the rest of the book was going to follow suit but thankfully I was mistaken.

Chapter 2 is really good. It explains the workings of Asterisk’s dialplan and applications – the infamous extension.conf – in a very clear and understandable way. I recall when I first started to look at Asterisk and was delving into as much information on-line as I could get, the Asterisk TFOT book [pdf download] and whatever else I could find, that it was several days before the penny finally dropped. It isn’t difficult really but it isn’t quite the same as “normal” programming or scripting concepts and the language itself is far from obvious (e.g. an extension is not the phone on your desk in Asterisk’s configuration files). But then this is telephony we are talking about. Using the example of a basic IVR or AA the author examines the diaplan syntax and construction.

So I got quite a lot out of chapter 2. I thought it was well written and clear and useful. Chapter 3 develops the IVR theme further, introduces other features of the Asterisk application pool and covers the scripting language in more detail examining branching, expressions, operators and flow control. It’s a fairly short chapter but covers a good deal of ground if you are unfamiliar with Asterisk programming.

Your level of knowledge and familiarity with Asterisk will dictate what you get from this first section (Chapters 1-3). Although I have used Asterisk for a couple of years now and have felt quite comfortable with the platform’s configuration and use, I got quite a lot of new information and ideas from this early part of the book. For me, this initial part has been very useful and will be a good reference for the future. I think, though, if you are very familiar with Asterisk then you might find it a bit slow going. The book hasn’t examined AGI whatsoever up to this point and we are about a third of the way through already! The author does suggest that a coffee is a good before starting on Chapter 4 as “the journey becomes more and more complicated”…

Chapter 4 introduces the reader to AGI in a fairly gentle way and also offers 10 “rules” to help make your AGI programming more successful – they all make sense to me and will I’m sure prove to be a very useful monitoring/checking tool. Packt sent me an extract from this chapter which you are free to read here if you want to get a flavour of it.

The following chapter introduces us to some real code (PHP) and we build our first, simple AGI application. Nothing to hard, but a useful introduction into how to actually get the conversation happening between Asterisk and your script. There are couple of nice flow charts which are helpful for visualising the traffic flow back and forth between Asterisk and your script too. Again not too complicated but helpful in getting the novice AGI programmer, i.e. me, thinking about things the right way.

In chapter 6 Nir examines and recommends the use of a set of PHP classes (library) called PHPAGI. Being completely new to AGI programming I am in no position to contradict the author’s recommendation, but looking on the Sourceforge site for this library, it is quite old and has not been updated for 3 years or more. Of course that may be because it is perfect and needs no further development, or there might be other reasons but I would have really liked to have had some more discussion regarding this choice of library before continuing – just for my own piece of mind more than anything else. Perhaps if Nir reads this he could leave a comment about this? My own assumptions after reading the rest of the chapter are that the AGI interface itself is fairly simple and so – perhaps – the need for a more dynamic or complex library is just not there and this one does the job just fine. Anyway, the rest of the chapter we look at a new AGI application using the class library above and also we discover the main – and what seems to me to be a first-class – concept for building AGI applications: Atomic AGI or Particle Programming. Sounds great doesn’t it? It really does make a lot of sense. Basically it’s a bit like the traditional ideals behind Unix/Linux command line applications; write small applications that do one thing and do it well. To summarise then, in chapter 6 we are shown the author’s recommended path to AGI Nirvana through adopting some rules, and practices. It is hard for me to draw any solid conclusions from his approach as I am a novice with AGI and so have nothing by way of comparison, but it certainly seems to make a great deal of sense and is clear and well explained. Good stuff.

The remainder of the book goes a bit wider than just pure AGI. Chapters 7 and 8, examine some of the closely related applications and facilities of Asterisk. We get an overview of FastAGI (AGI over TCP) and Nir shows us some further PHP libraries that are available to assist with producing FastAGI applications. Chapter 8 offers an overview of the AMI (Asterisk Manager Interface) and some example code to get you started.

In the penultimate chapter, the reader is given a challenge: to create an application that is used in the real world – an Asterisk Call Recording Gateway. There is no code in this chapter – that’s for you to do. But Nir provides some useful guidance about the way to think about the development and plan the project itself.

And finally, chapter 10 discusses how to make sure your Asterisk applications can scale and offers several ideas and techniques to improve performance such as database query caching and using web services.

As I said at the beginning – I enjoyed reading this book much more than I thought I would. It is not overly technical and Nir has an engaging style of writing. The book is a great introduction into Asterisk programming. It is not “The Bible of Asterisk Programming” and does not set out to be. It is clearly aimed at developers who have not had much to do with Asterisk before but are familiar with traditional programming methods. I really liked the fact that it is quite short. You can read the whole book in a couple of evenings and being laid out the way it is it will become a very useful reference document for me in the future.

Nir Simionovich has a blog.