We met at a pub in central London, and talked for around 3hrs. Everyone seemed to get on really well and most of us took the opportunity to share our experiences and promote our individual areas of expertise.

Four of us ended up going for the obligatory curry after the event which was also fun and very enjoyable – especially when the waiter brought me a fresh Naga Chilli to tantalise my taste-buds – hats off to Alan Bell and Chris from Credativ for having a taste of raw Naga. They are definitely NOT for the feint hearted…

The UK partners present at our inaugural meeting yesterday were (in no particular order)

Value Decision
Credativ
Publicus Solutions
Seath Solutions
The Open Learning Centre

A business-minded community of partners represents a much more compelling proposition to our existing and prospective customer-base than do standalone partners.

And here’s a very dodgy picture taken by yours truly:

UK OpenERP Partner Meeting

Installing OpenERP isn’t really that hard, but having seen several other “How Tos” on-line describing various methods where none seemed to do the whole thing in what I consider to be “the right way”, I thought I’d explain how we do it. There are a few forum posts that I’ve come across where the advice is just plain wrong too, so do be careful.

As we tend to host OpenERP on servers that are connected to the big wide Internet, our objective is to end up with a system that is:

A: Accessible only via encrypted (SSL) services from the GTK client, Web browser, WebDAV and CalDAV
B: Readily upgradeable and customisable

One of my friends said to me recently, “surely it’s just sudo apt-get install openerp-server isn’t it?” Fair enough; this would actually work. But there are several problems I have with using a packaged implementation in this instance:

• Out-of-date. The latest packaged version I could see, in either the Ubuntu or Debian repositories, was 5.0.15. OpenERP is now at 6.0.3 and is a major upgrade from the 5.x series.
• Lack of control. Being a business application, with many configuration choices, it can be harder to tweak your way when the packager determined that one particular way was the “true path”.
• Upgrades and patches. Knowing how, where and why your OpenERP instance is installed the way it is, means you can decide when and how to update it and patch it, or add custom modifications.

So although the way I’m installing OpenERP below is manual, it gives us a much more fine-grained level of control. Without further ado then here is my way as it stands currently (“currently” because you can almost always improve things. HINT: suggestions for improvement gratefully accepted).

[Update 18/08/2011: I've updated this post for the new 6.0.3 release of OpenERP]

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 still 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 (well 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, and optional web client, 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.

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: ********

[Update 18/08/2011: I have added the --no-superuser switch. There is no need for the openerp database user to have superuser privileges.]

Finally exit from the postgres user account:

exit

Step 4. Install the necessary Python libraries for the server

sudo apt-get install python python-psycopg2 python-reportlab \
python-egenix-mxdatetime python-tz python-pychart python-mako \
python-pydot python-lxml python-vobject python-yaml python-dateutil \
python-pychart python-webdav

And if you plan to use the Web client install the following:

sudo apt-get install python-cherrypy3 python-formencode python-pybabel \
python-simplejson python-pyparsing

Step 5. Install the OpenERP server, and optional web client, code

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 files. At the time of writing this it’s 6.0.2 6.0.3; I got the download links from their download page.

wget http://www.openerp.com/download/stable/source/openerp-server-6.0.3.tar.gz

And if you want the web client:

wget http://www.openerp.com/download/stable/source/openerp-web-6.0.3.tar.gz

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

cd /opt/openerp
sudo tar xvf ~/openerp-server-6.0.3.tar.gz
sudo tar xvf ~/openerp-web-6.0.3.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 and web client directories to something with a simpler name so that the configuration files and boot scripts don’t need constant editing (I call them, rather unimaginatively, server and web). 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-server-6.0.3 server
sudo cp -a openerp-web-6.0.3 web

As an example, should OpenERP 6.0.4 come out next, I can extract the tarballs into /opt/openerp/ as above. I can do any testing I need, then repeat the copy command (replacing 6.0.3 obviously) 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.0.3 directories can be removed if wanted.

That’s the OpenERP server and web client software installed. The last steps to a working system are to set up the two (server and web client) configuration files and associated init scripts so it all starts and stops automatically when the server boots and shuts down.

Step 6. Configuring the OpenERP application

The default configuration file for the server (in /opt/openerp/server/doc/) could really do with laying out a little better and a few more comments in my opinion. I’ve started to tidy up this config file a bit and here is a link to the one I’m using at the moment (with the obvious bits changed). You need to copy or paste the contents of this file into /etc/ and call the file openerp-server.conf. Then you should secure it by changing ownership and access as follows:

sudo chown openerp:root /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 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 = ******** to have the same password you used way back in step 3. Use your favourite text editor here. I tend to use nano, e.g. sudo nano /etc/openerp-server.conf

Once the config file is edited, you can start the server if you like just to check if it actually runs.

/opt/openerp/server/bin/openerp-server.py --config=/etc/openerp-server.conf

It won’t really work just yet as it isn’t running as the openerp user. It’s running as your normal user so it won’t be able to talk to the PostgreSQL database. Just type CTL+C to stop the server.

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. Here’s a link to the one I’m using currently.

Similar to the config 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 config 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 now you need to go back and check. There’s really no point ploughing on if the server doesn’t start…

OpenERP - First Login

If you now start up the GTK client and point it at your new server you should see a message like this:

Which is a good thing. It means the server is accepting connections and you do not have a database configured yet. I will leave configuring and setting up OpenERP as an exercise for the reader. This is a how to for installing the server. Not a how to on using and configuring OpenERP itself…

What I do recommend you do at this point is to change the super admin password to something nice and strong. By default it is “admin” and with that a user can create, backup, restore and drop databases (in the GTK client, go to the file menu and choose the Databases -> Administrator Password option to change it). This password is written as plain text into the /etc/openerp-server.conf file. Hence why we restricted access to just openerp and root.

One rather strange thing I’ve just realised is that when you change the super admin password and save it, OpenERP completely re-writes the config file. It removes all comments and scatters the configuration entries randomly throughout the file. I’m not sure as of now if this is by design or not.

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 708 3.8 5.8 181716 29668 ? Sl 21:05 0:00 python /opt/openerp/server/bin/openerp-server.py -c /etc/openerp-server.conf

Which shows that the server is running. And of course you can check the logfile or use the GTK client too.

Step 10. Configure and automate the Web Client

Although it’s called the web client, it’s really another server-type application which [ahem] serves OpenERP to users via a web browser instead of the GTK desktop client.

If you want to use the web client too, it’s basically just a repeat of steps 6, 7, 8 and 9.

The default configuration file for the web client (can also be found in /opt/openerp/web/doc/openerp-web.cfg) is laid out more nicely than the server one and should work as is when both the server and web client are installed on the same machine as we are doing here. I have changed one line to turn on error logging and point the file at our /var/log/openerp/ directory. For our installation, the file should reside in /etc/, be called openerp-web.conf and have it’s owner and access rights set as with the server configuration file:

sudo chown openerp:root /etc/openerp-web.conf
sudo chmod 640 /etc/openerp-web.conf

Here is a web client boot script. This needs to go into /etc/init.d/, be called openerp-web and be owned by root and executable.

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

You should now be able to start the web server by entering the following command:

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

Check the web client is running by looking in the log file, looking at the process log and, of course, connecting to your OpenERP server with a web browser. The web client by default runs on port 8080 so the URL to use is something like this: http://my-ip-or-domain:8080

Make sure the web client stops properly:

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

And then configure it to start and stop automatically.

sudo update-rc.d openerp-web defaults

You should now be able to reboot your server and have the OpenERP server and web client start and stop automatically.

I think that will do for this post. It’s long enough as it is!

I’ll do a part 2 in a little while where I’ll cover using apache, ssl and mod_proxy to provide encrypted access to all services.

[UPDATE: Part 2 is here]

• Propose a hack session on an application you are working on and need some help
• Talk about Debian packaging and lets actually package something together
• Run though some Natty installation testing together
• Write some documentation together

The common theme is that this is a collaborative exercise in real time and to support that we will be using the #ubuntu-uk IRC channel that we use for general support and chat, plus we will also be using a voice over IP conferencing server that uses the Mumble client. This client is in Ubuntu so just find it in the software centre or “sudo apt-get install mumble” from a terminal. Once you have it installed and running you need to connect to the server at mumble.libertus.co.uk and then start talking away. Please use a headset microphone to avoid feedback or you will have to use the push to talk feature which is a bit unnatural. The server is up and running already, feel free to give it a try in advance.

I look forward to hearing lots of people on Saturday!

BSA SPAM

This spam marketing literature however, is actually a very compelling call to action for those businesses that aren’t already protecting themselves by using Free and Open Source Software. If the image isn’t terribly legible, here are a few of the juicy bits just SCREAMING at you to think very carefully about the software choices you make in your business.

Your boss wouldn’t ask you to steal or commit fraud, would they? So why do they ask you to use unlicensed software?

Note the phrasing: “unlicensed software”. Of course Free software is licensed, so that’s OK then. There are lots of great Free Software licenses.

Here’s the bit where the BSA really start to suggest you should be using Free Software.

Here’s how easy it is to get caught up using illegal software:

• One or more software licenses are bought, but the software is installed on more PCs than the licenses permit
• Software is purchased for an employee’s home PC and is also installed on to a work PC

These activities are perfectly OK and in-fact encouraged with licensed Free software. A Free Software License gives a user the freedom to do these things; It’s called freedom 2: The freedom to redistribute copies so you can help your neighbor.

• Font designs and software are downloaded illegally from the internet

You can download legally lots of font designs from places such as the Open Font Library and Google’s WebFont Library online.

The recently released Ubuntu font is an excellent example of a high quality, freely available font.. You can read about it here, get it from here and even get the font source from here. You may also choose to use the Google Font API to use it freely on your website from here.

And as for downloading “software” well, there’s probably more Free software available for download than the BSA could shake a stick at.

So please, consider carefully what our friends at the BSA have to say and talk your bosses or employees about the choices they make. Using properly licensed software is not hard. You don’t have to be at risk from even making a simple mistake. Using licensed Free software protects you.

If you are in a business and want advice on the choices available there are companies such as our own that can help. The BSA would rather your employees take you to the cleaners…

So, if you know of a company that is using unlicensed software, please let us know now. You could receive a reward of up to £10,000.

The format of the evening was a panel debate with Mark Elkins of the BSC chairing and Tariq Rashid of the Home Office proposing the topics for discussion. On the panel were representatives from a number of large system integrators (SIs) who work on large scale government projects. The panel was:

• Darren Austin, UK Chief Engineer, Atos Origin.
• Adam Jollans, Program Director – Open Source and Linux Strategy, IBM Systems & Technology Group.
• Mike Robertson, Head of Public Sector Business, Savvis.
• Gurpritpal Singh, CTO, UK Technology Consulting, Hewlett Packard.

The format of the evening was that Tariq would pose a question and the panel members gave their responses before it was opened to the floor for questions and comments from the audience. This format worked quite well – although some members of the audience were clearly unused to requesting, and then waiting to be called to speak, and rather disrespectfully interrupted the proceedings on a number of occasions to spout their opinion during the panel responses – please, if you go to an event with a set format, don’t disrupt it, that just makes the community seem unprofessional.

I won’t break down the responses question by question (there will be audio published at some point I believe and I didn’t take good notes) but some of the key points raised were:

The System Integrators are perfectly happy to work with Open Source. The customer just has to ask for it. All the SIs on the panel said this. They already provide Open Source solutions to other countries, they already use Open Source software where they are providing just a service (cuts their costs and gives them more control). They just pitch proprietary stuff at procurement contracts because that is what wins them here.

When the customer asks for a service to be performed to open standards (yes there was a discussion of the definition of an open standard, the problems of FRAND and the need for Free standards) then the integrator will generally use Open Source software because it reduces their costs (a little) but much more importantly allows them the freedom to commercialise the overall solution in the way that they want to, without complicated negotiations with a third party supplier. The implication of this seemed to me to be that the government still gets screwed over, but only by the SI, and possibly not so badly.

Purchasers of smaller solutions rather than multi-million pound services projects buy from a catalogue, the  G-Cat or something like that. This is a list of approved, vetted, commercial off the shelf (COTS) solutions that are safe to use (“safe” in this context meaning you won’t get fired if the thing you bought was on the catalogue). This catalogue is hard to get on to. Suppliers of proprietary software have to jump through hoops to prove that they are good enough as a company to supply the licenses and there may be some technical appraisal, I don’t really know the details. The point is that the process is hard, it takes time, and probably money. Suppliers go through that process and write it all off as cost of sales, because they know that if they get on the list then the gravy train is on it’s way into town. Open Source projects, with great code, a solid and active community, but no real concept of “financial stability” (and equally no concept of “financial instability”) often have no budget to jump through hoops and fill out documents as a presales exercise because they get, and want, no financial reward at the end of the process when someone in local government downloads and uses the software for free. If the government wants Free Software in the catalogue, they are going to have to pick up the tab in the short term for the presales activity and engage with some knowledgeable consultants (yes, we will do that kind of thing) on a project to go through the evaluation process and fill out all the forms to enable, in the longer term, better value selections to be made from the catalogue.

There was quite a discussion about the ownership of risk, this is important to government purchasers, but more as a concept, than as a reality. Large projects have big penalty clauses, which means that the government likes to work with suppliers who have the financial wherewithal to live up to these clauses. I don’t think I am revealing that much about my company finances to say that we would struggle to demonstrate that we could pay up on a penalty clause running into tens of millions of pounds. Does the government exercise these penalties on a regular basis? No. As one of the pannelists mentioned they would swiftly end up owning all the SIs if they did, and whilst the UK government nationalising IBM is a fun thing to contemplate, it really isn’t going to happen. I made the point at this stage that the government seems to get a lot of comfort from knowing “who to sue”, if things break. What they need to do is learn how to gain comfort from knowing “how to fix it”, and knowing that they can engage with any other supplier to fix broken things. Having open code and the legal right to modify it to your requirements and to have other people modify it to your requirements actually reduces risk. Having financial penalties does not in fact reduce risk at all, it just mitigates your liability when things go wrong.

Next week there will be another debate covering slightly different topics, I believe the format and panel will stay the same which I think works very well (subject to a well behaved audience of course). The topics are listed below, feel free to discuss them in the comments and I will try and pass on some of the most insightful at the event.

Evening Debate 2 – Tuesday 1st March

1. Security. OSS is insecure compared to commercial software?

• By what criteria can we select software to minimise security risks?
• Does OSS need a different approach to patching?
• Can we simply use empirical evidence when comparing OSS with closed software? Statistics for internet browsers are common – published vulnerabilities, known exploits, time to fix
• Key question for HMG is – all things being equal, open code means vulnerabilities can be discovered and exploited before there is time to fix

2. Buy-not-Build. Can OSS actually benefit HMG because HMG doesn’t want custom or re-engineered software?

• HMG generally asks IT suppliers to build systems from COTS components and minimise customisation and re-engineering – it doesn’t want to maintain special code because of cost and risk. So does a significant benefit of OSS not apply to HMG?

3. Legal advice for OSS

• OSS has some unique legal aspects compared with commercial software – where to get advice? Myths around legal obstacles and obligations are going unchallenged.
• Patents and liability issues are often raised – resolved by major OSS suppliers who will shield customers?

4. Long Term Strategy

• OSS won’t happen overnight.
• Should we work backwards from insisting on open information formats for HMG interactions with the public and other sectors? This way the use of open standards compliant software filters back into HMG organisations.

5. Other Ideas

Database / Server

Modules / Databases

Model and Form View / Form

_defaults / Field default values

_constraints and _sql_constraints / Validation formulas

Records / Documents

Functional fields / Computed and Computed for display fields

Read only fields / Computed when composed fields

Tree Views / Views

Calendar Views / Calendar Views

Gantt views / n/a

Diagram Views / n/a

Graph Views / n/a

Domain / Selection formula

Python / Lotusscript

Access Controls List / Access Control Lists

n/a / Replication

n/a / What You See Is What You Get

n/a / Public Key Authentication

Internationalisation / Domino Global Workbench

Workflow / Lotus Workflow,formally known as Domino.Workflow

Reporting and Printing / n/a

Text & HTML / Rich Text

AGPL / Proprietary

In Conclusion

Notes is OK, but proprietary and closed and quirky and carrying over 20 years of baggage with it. OpenERP has more of a rigorous and correct feel to it with standards compliance, a modern framework, nice APIs and a real grown up relational back end with transactions and atomicity and so on. The NoSQL engine at the core of Notes is a great idea, and new implementations of the architecture such as CouchDB are dead handy, especially for distributed applications.

All these detail comparisons are rather academic, the bottom line is that having poked about at the application development layer of OpenObject and looking back at all the Notes applications I have written over the last 15 years or so I am left thinking that most of them I could rebuild now in OpenObject, but slightly better.

As many others do I’m sure, I use ssh terminal sessions a lot. I’ve often got half a dozen open at once either in separate terminals or in Terminator for example. Sometimes if I don’t update them for a reasonable length of time they simply lock up so that I have no response at all. I’ve not actually timed this issue but I expect it is happening somewhere between 10 and 30 minutes of inactivity.

After getting annoyed for the umpteenth time today I finally did some serious searching… I concluded that this lock-up is probably due to my broadband router. It wasn’t happening across the local LAN or when I was connecting from other locations so I already suspected my broadband service. I suspect that it’s a NAT cache timeout or something but that’s not really important.

Several howtos I found discussing various timeout problems suggested editing the ssh config file on the server. This is fine if you know which server(s) you will be connecting too all the time and of course if there don’t happen to be hundreds of them that you need to re-configure. But if you don’t know or do use many machines then that’s not an ideal solution at all.

I think this is though

If you haven’t already got one, make a file in your home ssh directory (on Ubuntu it is normally found in ~/.ssh):

touch ~/.ssh/config

Open it with your favourite editor and enter a line something like this:

ServerAliveInterval 120

Then save and close it. From my initial tests this seems to do the trick nicely.

According to the manual it:

Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server, or 300 if the BatchMode option is set. This option applies to protocol version 2 only. ProtocolKeepAlives and SetupTimeOut are Debian-specific compatibility aliases for this option.

This is one of those things I should have done ages ago. I hope this help others who find their ssh sessions mysteriously hanging.

The White Hart, Sherington

Earlier this week, we had a bit of a road trip on our hands… A day discussing OpenERP in Cambridge and the next day vtiger CRM consulting in Milton Keynes which is not too far away, so we needed somewhere to stay to avoid driving a 200+ mile round trip.

We found a real gem of place! A very attractive country pub with extremely pleasant rooms, very friendly service, fantastic food (the Mixed Grill was really, really excellent), good beer and entertaining and congenial locals too.

If you happen to be working around the Bedford, Milton Keynes, Newport Pagnell area and want somewhere to stay, I whole-heartedly recommend you check out The White Hart in Sherington.