Add DB filter in configuration script

[Yenthe666]

trafficstars

The /etc/conf script should contain the database filter? Something along the lines of:

sudo su root -c "echo 'dbfilter = ^%d$' >> /etc/${OE_CONFIG}.conf"

[Yenthe666]

@sebastian-code and @tvibliani do you guys see any negative points in adding in the dbfilter parameter? Does this code look good too?

[sebastian-code]

Shouldn't the dbfilterparameter be injected from the nginx proxy?

[Yenthe666]

@sebastian-code to be honest my knowledge about Nginx is so limited that I have barely any idea. What I do understand is that in the Nginx you specify the database, which is in essence some sort of dbfilter too. This will map a specific database to a specific URL. But I'd like to offer this ability for the default installation script too, for if you wouldn't use the Nginx installation script.

[lukebranch]

@Yenthe666 ,

Just a quick note, I think it may be worthwhile to assign a unique path for:

data_dir = (eg. data_dir = /opt/odoo/.local/share/Odoo)

for multi-tenant setups.

My setup was a bit oddball I admit, I had:

PostgreSQL 9.3 = 5422 PostgreSQL 9.5 = 5433

both running using the system user 'odoo', and running database users.

I was testing duplicate databases between the two PostgreSQL versions and made the mistake of leaving the database names identical and letting them share the same data_dir.

Strange things started to happen with images, and when I dumped the 9.5 database it dumped the images for the 9.3 counterpart with the same database name.

Stupid error on my part, however I just thought I would note this here, as it may be worthwhile in multi-tenant, multi-db type setups to make sure this data_dir is a unique value.

[Yenthe666]

@lukebranch,

Thanks for letting me know. I didn't know that two different PostgreSQL version would interfere with eachother if they had the same user running it. Sounds like a flaw to me.. You're talking about the variable data_dir in the .conf file, right?

[lukebranch]

@Yenthe666 ,

Yes, that's the variable i'm referring to.

Steps to reproduce would be:

1. Install Odoo using your installation script without any changes
2. Install Aeroo Reports using your installation script
3. Install PostgreSQL 9.5 (http://raonyguimaraes.com/installing-postgresql-9-5-on-linux/)
4. PostgreSQL 9.5 will then be by default running on 5433
5. Create a seperate startup script using odoo123-server instead of odoo-server and point this to a different configuration file (eg. /etc/odoo123-server.conf)
6. keep data_dir the same default value and modify: db_port = 5433 xmlrpc_port = 8079 longpolling_port = 8082 ogfile = /var/log/odoo/odoo123-server.log
7. Create postgreSQL 'odoo' user on 9.5 like follows: sudo su - postgres -c "createuser -p 5433 -s odoo" 2> /dev/null || true
8. restart postgreSQL and Odoo (or just reboot the server if you haven't already in step 1 or 2.
9. create TEST123 database in the 9.3 instance, add some products, photos, etc. and backup (with zip filestore) and restore to the 9.5 instance.
10. play around in the 9.5 instance for a bit and then dump it from /web/database/manager
11. go back to 9.3 instance and your photos will likely be blanked out but still in cache which means they'll show up on the kanban, but not on the individual product profile pages in the backend.

I guess if more than one instance of a duplicated database is sharing the data_dir it would make sense that the data would overwrite, but it definitely caught me off guard.

[sebastian-code]

That's why I said before than the script has to control the whole process, creating a different user, but I also has to confess than I haven't give a though about dealing with a situation were even a different user creates a database with the same name. And well, perhaps for testing purposes you will have different PostgreSQL engines, but in production I don't see that happening.

[lukebranch]

@sebastian-code ,

I agree that this situation is incredibly unlikely to occur in a production environment, however if the script is to include multi-tenant type situations it may be worthwhile assigning a sequential or random two to three digit code to additional instances to be used in the odoo-server.conf file name, data_dir, and log file path among other things.

[sebastian-code]

The truth be said, I don't see how. A multi-tenant deployment is (if I understand correctly) one Odoo instance, one DB engine instance, one Odoo system user, and over that, at the DB management page you create multiple databases. If that's the right concept (which I do think so) how are you going to detect and interfere the DB creation with a script made only to install Odoo?

The other possibility is than you're talking about one DB engine (or one alone for every tenant) with different Odoo instances. If that's the case you're referring to, the script already solves that, because what you do is to run the script every single time for each tenant, providing a different system username (odoo, odoo_testing, odoo_production...), that would create a different folder structure, system user, port and process for every single tenant (the only thing left out would be the installation of different PostgreSQL instances, something I think is not wise because you can handle everything with just one well handled engine); in this case, the only thing to configure would be the port routing through Nginx for the different deployments.

Am I correct?

[lukebranch]

@sebastian-code ,

Yes, you may be right. I'll take a look at the script in more detail this afternoon to confirm, however for a standard multi-tenant setup I agree, it's should not be possible to run into the issue i've described.