I'm not sure about installing it side-by-side with WordPress (or using the LAMP base in general) but it installs pretty nicely on the LAPP appliance (which has PostgreSQL already installed and configured). Here's what got it working for me:

wget -O - https://nightly.odoo.com/odoo.key | apt-key add -
echo "deb http://nightly.odoo.com/8.0/nightly/deb/ ./" >> /etc/apt/sources.list.d/odoo.list
apt-get update && apt-get install -y odoo sudo

sudo su - postgres -c "createuser -s odoo"
service postgresql restart

From my reading of the Deb install it seems that there is one dependency (wkhtmltopdf - which allows exporting of reports to PDF) that can't be automatically resolved and needs to be manually installed:

#adjust these as suits your setup. They work as is for 64bit v13.0 TKL
ARCH=amd64
REL=wheezy
VER=0.12.2.1

wget http://downloads.sourceforge.net/project/wkhtmltopdf/${VER}/wkhtmltox-${VER}_linux-${REL}-${ARCH}.deb
deb -i --force-depends wkhtmltox-*.deb

apt-get -y -f install

If you want you can also set up an Apache proxy (so you don't need to use port 8069). This also forces it to only work via https (so more secure). Note though that if you do this then it will break your WordPress site so for you I wouldn't recommend it!:

#set the domain name of your appliance here first!
DOMAIN_NAME="www.example.com"

cat > /etc/apache2/sites-available/odoo.conf <<EOF
NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	Redirect permanent / https://$DOMAIN_NAME/
</VirtualHost>

<VirtualHost *:443>
	SSLProxyEngine on
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/cert.pem
        ServerAdmin webmaster@localhost
	RequestHeader set "X-Forwarded-Proto" "https"
	SetEnv proxy-nokeepalive 1
        	ProxyPass / http://127.0.0.1:8069/
        	ProxyPassReverse / http://127.0.0.1:8069/
	ProxyErrorOverride off
	SetEnv proxy-nokeepalive 1
</VirtualHost>
EOF

a2dissite default
a2ensite odoo

a2enmod proxy_http headers rewrite

service apache2 reload

If you do that then you should also adjust some setting for Odoo:

cat >> /etc/odoo/openerp-server.conf <<EOF
proxy_mode = True
xmlrpc_interface = 127.0.0.1
EOF

service odoo restart

You could also have Odoo running in a subdirectory e.g. www.example.com/odoo but that will be a trickier config if you still intend to host WordPress in your webroot (i.e www.example.com); not so much if you are happy with WP in a sub dir too (e.g. www.example.com/wordpress or www.example.com/blog). Obviously that would then require some sort of landing page in your webroot (www.example.com).

Sorry if I scared you or made you think that it wasn't possible to have them operate side-by-side (i.e. proxying Apache and keeping your current WP site). I just didn't want you (or someone else) to blindly follow my instructions and break your (working) website!

As a Odoo user would you recommend that some apps be installed by default? I.e. if there was a TurnKey Odoo appliance should it have some apps already installed or just be a blank canvas (like it is when you manually install it)? If so which ones and why? I'd be really interested in your opinion.

As to your final point re install scripts for servers; yes there would be advantages to going in that direction. But there are also potential issues... The way that we currently do it means that we are installing to a known system with a sane, usable and probably most importantly known default. It means that we can control the base environment (and even then we still have the odd bug slip through).

If we provided install scripts then we would have no control over the system that it is being installed to so the potential for issues beyond our control are greatly increased (and the potential points of friction are almost infinite). We already have plenty of support issues to take care of. My strong suspicion is that providing a 'base' appliance and then install scripts for installing other functionality would massively increase our support overhead. As a small team; every time I post here; means that there is something else that I'm not doing... Don't get me wrong I enjoy the interactions I have in the forums, it's just that I have lots of other stuff to do too! :)

Another issue with that direction is that these theoretical install scripts would need to be more intelligent (than the current install logic) and therefore complex (and therefore more likely to have bugs and harder to debug). E.g. Are the correct version of dependencies for the software being installed satisfied? If not will installing them cause issues with other software already installed? What if there is a conflict between software (and it's dependencies) installed already and what we are trying to install (and it's dependencies)? Does software being installed (and it's dependencies) make already installed software (and it's dependencies) redundant or should they still run side-by-side?

And there are a myriad of potential issues and/or questions relating to config too that would need to be resolved or decided. Even if we excluded vastly different appliances and focused on LAMP based appliances (so that they all have a common base and less likelihood for conflicting software and dependencies), there are still config questions that need to be resolved. Like in your instance with Odoo alongside WordPress; should we configure by default for subdomains or subdirectories? Whichever way we go, which will have precedence? I.e. do we want WordPress on blog.example.com or www.example.com? Or do we want them both as subdomains/subdirectories and a landing page? You can guarantee that which ever way we make it default to then there will people who want it set up different and IMO there is no real sane default (all choices are arbitrary). If we made the install scripts allow users to choose, then again we add complexity and therefore greater opportunity for issues to creep in...

FWIW this isn't just theoretical; Bitnami (probably TKL's main competitor) have install scripts like you suggest. If you have a look at their support forums they are chock full of people having issues and/or questions like I am discussing here. Plus they also still have the same sort of issues we have (as they also provide pre-built appliances like we do). I've never really used Bitnami so I'm not saying what they do is bad; just that IMO it's not a good path for us to go down... In fairness they also have install scripts for Windows so they have a broader market. Also they have a much bigger budget for marketing etc so have many more users... Still IMO my point stands.

Having said (ranted!? :D ) all that, ultimately we would love to provide some way to easily combine appliances and run them on a single server (physical or VPS). We just don't think that install scripts that install to a monolithic base appliance is the way to do it. For those running on hardware the obvious answer IMO is to use a hypervisor for each separate server (personally I use and love ProxmoxVE). For those that don't mind a bit of tweaking then our LXC appliance is probably a good way to go (somewhat like a TKL only hypervisor where different appliances run as containers within the host appliance). Both of these have redundancy but personally I prefer it that way. If one server crashes or needs maintenance then it doesn't affect the others (e.g. in your case a DDOS attack on your WP site won't also bring down you Odoo server). We have other ideas for how we might make this work nicely and be more newb friendly but unfortunately have not yet had the time or resources to investigate how we might successfully do that... It's on our radar though! :)

I agree that it looks like a Odoo appliance would be a good addition to the TurnKey library although TBH unless someone builds it soon it probably won't make it into the next release. I think that in theory with the info I discovered (and shared above) that building an appliance should be relatively easy; however the devil is in the detail and it's often that last mile that is the hardest...

If you have any further ideas and/or feedback re your experiences with Odoo etc I'd love to hear them...

And as for scripted installs and multi-purpose appliances; we'll continue to ponder the pros and cons and consider how best to do it. Hopefully at some point come up with something that is workable...

IIRC there is a (couple?) of Odoo settings that need tweaking to stop 8069 being publicly available. You can bind Odoo to localhost - so Apache can proxy it but it's not available publicly. Actually while writing this email I came across a comment here that may be of use?

TBH I don't recall exactly now (I don't use Odoo I was just playing) but I think that there was a setting that related to proxying the authentication too. Maybe that is why you are getting validation errors? I don't think that I even tested installing a module though so that's pure speculation. I would suggest that you look into the Odoo config file and go through all the possible settings. Maybe something will present itself? IIRC there was documentation about all the possible config setting in the online Odoo docs?

Also there is a TKL community member (L. Arnold) who is working on building a TurnKey Linux Odoo appliance (to hopefully add to our library of pre-installed, pre-configured appliances for the v14.0 release). As a Odoo user perhaps you might have some constructive input?

Landis has been working on a v14.0 TurnKey appliance which looks like it's progressing really well. Perhaps you could help him testing that out an d see how it compares to what you are experiencing now...?

Tryiing with a GEN call as well

GEN=0.12  which is a GENERATIONAL folder holding all the 0.12 releases releases

Working on the Proper Mod.  How does this look?  (trying to not Link it)

LOOKS like it built after several tries.  

wget http://download.gna.org/wkhtmltopdf/0.12/0.12.2.1/wkhtmltox-0.12.2.1_linux-jessie-amd64.deb
wget http://download.gna.org/wkhtmltopdf/${GEN}/${VER}/wkhtmltox-${VER}_linux-${REL}-${ARCH}.deb

* wget http://download.gna.org/wkhtmltopdf/0.12/0.12.2.1/wkhtmltox-0.12.2.1_linux-jessie-amd64.deb
* wget http://download.gna.org/wkhtmltopdf/${GEN}/${VER}/wkhtmltox-${VER}_linux-${REL}-${ARCH}.deb