While I am always willing to accept feedback and corrections to articles I publish, including this one, I do not have the time to provide Odoo installation support of any kind so please do not ask for it. Read the article in its entirety and you'll know everything I do about the subject.
If it is against your company's policy to host financial data in the cloud (as it is my own) then installing locally is your only choice, and you should include the cost of hardware and consultants needed to install and maintain the system, and optionally the cost of an Enterprise License ($250/user/yr) if required.
Do not make the error in judgment that many businesses are inclined to make in their quest to save money and assume that getting the application source code for free will significantly reduce the expenses associated with the installation, routine maintenance, and training required to deploy the application.
I'm sure you're wondering why I chose FreeBSD rather than Linux, particularly given that most people seem to install it on Linux, the Odoo developers provide documentation for Linux, and I have over 20 years of development experience on Linux and Unix.
I originally installed the latest postgres available on FreeBSD (9.4) but through the course of installing the various python dependencies required by Odoo I learned that python 2.7 (required by Odoo) has more than a few hard references to postgres 9.3...at least in the FreeBSD package ecosystem.
While I ultimately worked around those issues by using pip to install the python dependencies I wound up keeping 9.3 rather than reinstalling 9.4. Odoo does not mention a specific Postgres version requirement for their application but based on my experience in other projects anything 9.1 or later is probably good enough.
Incidentally when installing any package on FreeBSD via pkg the specific package version number, i.e. \"-9.3.9_1\", may be eliminated but my convention in documents of this type is to show the specific version installed for traceability purposes.
The database configuration defaults to listening to requests only on the local server. This is a security feature and is compatible with installations that run both postgres and the Odoo application on the same system. If the server and application are on different systems the database configuration file will need to be tweaked to listen for connections on hosts other than localhost (127.0.0.1). Search the postgres documentation for instructions on this topic.
According to the Odoo documentation the application will refuse to login to the postgres database using the default database user (called \"postgres\" on Linux and \"pgsql\" on FreeBSD) that is created during the installation of the postgres server. That's a good thing, but it does necessitate the creation of another postgres user that can \"own\" the database used by the Odoo application.
In PHP, composer is used to install prepared PHP packages from a variety of sources. Python has a similar package tool called \"pip\". This can and should be used to install any required python packages, including those required by Odoo.
On my initial installation I obtained a list of required python packages from a script someone built for ubuntu. I translated those package names to FreeBSD and attempted to install them via the 'pkg' command. That ultimately did not work as several packages on the list conflicted with one another and even forcefully removed the version of postgres I had installed at the time (9.4).
The second time around I did it the way Odoo recommends and used pip to install the packages listed in the requirements.txt file located at the top of the source tree. I had one problem with this method as well: python-ldap refused to build due to missing header files that I ultimately traced to openldap2. I found at least one of the headers in /usr/local/include, so I knew the problem was not the result of a missing package. I ultimately fixed the problem by removing the python-ldap package from the requirements.txt file, fed pip that file again to get all packages OTHER than python-ldap installed, and then manually used pip to install python-ldap, which then worked. Not sure why. However irrelevant to the context I'll just throw in a \"Python Sucks\" comment here because I can.
I know everyone trusts the node devs and thousands install node by executing the node install.sh script every day but I'm not a fan of executing unknown / unsigned code directly from the net, especially as root, which explains why the above curl command doesn't do anything but download the file. If you choose to download the script rather than install the FreeBSD package equivalent I strongly advise you examine the script for malware before you execute it. If you don't know how to do that, you should probably install the FreeBSD package.
After filling out that initial display Odoo should open the standard Odoo desktop with the application modules page displayed. From here required application modules can be installed. For example, my primary reason for using Odoo was their MRP (Manufacturing) module, which would allow me to track the raw materials and other parts used to build my products. Note that some modules will install other modules as dependencies. For example, the MRP module requires the Inventory module, so it will be installed automatically.
Once the application is known to start and stop without errors, the startup and shutdown sequence can be automated by creating an init script. Unfortunately at the time of writing no one had documented a compatible FreeBSD install script so I had to build my own init script based on the scripts built for Linux, the Odoo documentation, and a lot of testing.
The file was installed in /usr/local/etc rather than /etc because of the age-old Unix convention (unfortunately long since abandoned in Linux) of installing applications and related stuff in /usr/local, which wisely separates user applications from the OS core.
By default the Odoo application provides its own HTTP service and responds to connection attempts on a specific port. This is useful only if you intend to access Odoo strictly from a web browser installed and running on that same host. This is too limiting for most installations as it would preclude purchasing, warehousing, etc. from accessing the system over the network, so the solution is to use a traditional webserver to proxy requests from other hosts and send them to the Odoo application server.
I advise going through the effort of installing Odoo from source as opposed to packages because a source control system (git) makes it a lot easier to control and monitor the state of the Odoo application code to prevent unauthorized changes, move forward to new releases, revert to old releases if necessary, and apply simple patches that may be internally developed or provided by the community outside or in advance of a formal release by the Odoo developers.
First, the routines do not play nicely when the name of the process contains dashes (openerp-server for example). This is because whoever wrote those routines used a rather arcane syntax for variable assignment I almost never use because I learned long ago it causes problems like this.
I fixed all of these issues by growing my own start/stop/status functions. This was not ideal but I wasn't about to rewrite rc.subr or change the name of the openerp server process as that would have made future testing and contributions to the project annoying.
This may be obvious but I'll mention it anyway -- uninstalling a module will delete all the data and relationships associated with that module from the database. The only way to restore the deleted data would be via a backup. Fortunately the application will warn about this very fact prior to removing the module. I don't think many people will be removing modules from production servers, but it is possible if Odoo doesn't impress in certain areas and that capability is moved to other systems.
While the transition from openerp to Odoo branding has had a positive impact on the overall state of the application and its GUI, which I find surprisingly slick if not a bit slow, there is a dark side to all of this: monetization.
And yes, I know about web.url.base. I was able to change that by logging in as admin, activating developer mode, and then going to Settings->Parameters but ultimately the value did not survive a restart of the openerp-server application. I have no idea why as that value has to be stored in the database. What are they doing with the new value when I click \"Save\"
You will be prompted for your OpenERP user id and password (free to register) to start, and for any required configurations as each application is installed. Applications often have dependency applications, which will be automatically installed.
Odoo is now installed and running on your server. Open a web browser and point it to :8069 (Where SERVER is either the IP address or domain of the hosting server). You will be prompted to fill out information for the creation of a new database (Figure A).
Python command is not available but the 3.9.2 version we just installed is present. If you can't see the newly installed python you should check the pyenv documentation here to make it available in your path via a different method than what we did earlier.
We directly typed the DB name, user, and password and initialized it with the i flag. --without-demo=all is used because we are installing a production-ready environment. If you want demo data, omit that flag.With the -c flag we told Odoo where the config file will be /home/odoo/.odoorc_codingdodo_demoThe --save flag is used to save everything we just typed into the newly created config file.
Let's Encrypt needs to do its acme-challenge to validate our domain name and creating the certificate with Certbot. If we plan to install multiple instances / different domain names pointing to this server, it is a good habit to isolate the let's encrypt acme-challenge location to its custom snippet. 153554b96e