Configurarea sistemului¶

This document describes basic steps to set up Odoo in production or on an internet-facing server. It follows installation, and is not generally necessary for a development systems that is not exposed on the internet.

Atenționare

Dacă configurați un server public, asigurați-vă că verificați recomandările noastre de Securitate!

dbfilter¶

Odoo este un sistem multi-tenant: un singur sistem Odoo poate rula și servi un număr de instanțe de baze de date. Este de asemenea foarte personalizabil, cu personalizări (începând de la modulele care sunt încărcate) în funcție de „baza de date curentă”.

Acesta nu este un problemă când lucrați cu backend-ul (clientul web) ca un utilizator înregistrat în companie: baza de date poate fi selectată la logare și personalizările încărcate ulterior.

Cu toate acestea, este o problemă pentru utilizatorii neînregistrați (portal, website) care nu sunt legați de o bază de date: Odoo trebuie să știe care ar trebui să fie baza de date utilizată pentru a încărca pagina website sau pentru a efectua operația. Dacă nu se utilizează multi-tenancy, nu este o problemă, există doar o bază de date de utilizat, dar dacă există mai multe baze de date accesibile, Odoo are nevoie de o regulă pentru a ști care ar trebui să fie utilizată.

Acesta este unul dintre scopurile --db-filter: specifică cum ar trebui să fie selectată baza de date în funcție de hostname (domeniu) care este solicitat. Valoarea este o expresie regulată, posibil includând hostname-ul injectat dinamic (%h) sau primul subdomeniu (%d) prin care sistemul este accesat.

Pentru serverele care găzduiesc mai multe baze de date în producție, în special dacă website este utilizat, dbfilter trebuie să fie setat, altfel un număr de caracteristici nu vor funcționa corect.

Exemple de configurare¶

Afișează doar bazele de date cu nume care încep cu «mycompany»

in the configuration file set:

[options]
dbfilter = ^mycompany.*$

Afișează doar bazele de date care se potrivesc cu primul subdomeniu după www: de exemplu, baza de date „mycompany” va fi afișată dacă cererea de intrare a fost trimisă la www.mycompany.com sau mycompany.co.uk, dar nu pentru www2.mycompany.com sau helpdesk.mycompany.com.

in the configuration file set:

[options]
dbfilter = ^%d$

Notă

Setarea unei --db-filter corecte este o parte importantă a securizării instalării. Odată ce funcționează corect și se potrivește cu o singură bază de date pentru fiecare hostname, este recomandat să se blocheze accesul la ecranele managerului bazei de date și să se utilize --no-database-list ca parametru de pornire pentru a preveni listarea bazelor de date și pentru a bloca accesul la ecranele de administrare a bazei de date. Vedeți și securitate.

PostgreSQL¶

În mod implicit, PostgreSQL permite conexiunea doar prin socket-uri UNIX și conexiuni de loopback (de la „localhost”, aceeași mașină pe care este instalat serverul PostgreSQL).

Socket-ul UNIX este ok dacă doriți ca Odoo și PostgreSQL să execute pe aceeași mașină, și este implicit atunci când nu este furnizat niciun host, dar dacă doriți ca Odoo și PostgreSQL să execute pe mașini diferite 1 va avea nevoie să asculte interfețele de rețea 2, fie:

Acceptați doar conexiuni de loopback și utilizați un tunel SSH între mașina pe care rulează Odoo și cea pe care rulează PostgreSQL, apoi configurați Odoo pentru a se conecta la capătul tunelului său
Acceptați conexiunile la mașina pe care este instalat Odoo, posibil prin ssl (vedeți Setările de conexiune PostgreSQL pentru detalii), apoi configurați Odoo pentru a se conecta prin rețea

Exemplu de configurare¶

Permite conexiunea tcp pe localhost
Permite conexiunea tcp de pe rețeaua 192.168.1.x

in /etc/postgresql/9.5/main/pg_hba.conf set:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

in /etc/postgresql/9.5/main/postgresql.conf set:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Configurarea Odoo¶

În mod implicit, Odoo se conectează la un postgres local prin socket-ul UNIX prin portul 5432. Acest lucru poate fi suprascris folosind opțiunile bazei de date atunci când instalarea Postgres nu este locală și/sau nu utilizează valorile implicite de instalare.

The packaged installers will automatically create a new user (odoo) and set it as the database user.

Ecranele de administrare a bazei de date sunt protejate de setarea admin_passwd. Această setare poate fi setată doar folosind fișierele de configurare, și este verificată simplu înainte de a efectua modificări la baza de date. Ar trebui să fie setată la o valoare generată aleatoriu pentru a asigura că terțe părți nu pot folosi această interfață.
Toate operațiunile bazei de date folosesc opțiunile bazei de date, inclusiv ecranul de administrare a bazei de date. Pentru ca ecranul de administrare a bazei de date să funcționeze, este necesar ca utilizatorul PostgreSQL să aibă dreptul createdb.
Utilizatorii pot întotdeauna să șteargă bazele de date pe care le dețin. Pentru ca ecranul de administrare a bazei de date să fie complet nefuncțional, utilizatorul PostgreSQL trebuie creat cu no-createdb și baza de date trebuie să fie deținută de un alt utilizator PostgreSQL.

Atenționare
utilizatorul PostgreSQL nu trebuie să fie un superutilizator

Exemplu de configurare¶

conectează-te la un server PostgreSQL p
portul 5432
folosind un cont de utilizator «odoo»,
cu «pwd» ca parolă
filtrarea doar a bazelor de date cu un nume care începe cu «mycompany»

in the configuration file set:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL între Odoo și PostgreSQL¶

De la Odoo 11.0, puteți forța conexiunea ssl între Odoo și PostgreSQL. În Odoo, controlul db_sslmode controlează securitatea ssl a conexiunii cu valoarea aleasă din «disable», «allow», «prefer», «require», «verify-ca» sau «verify-full»

PostgreSQL Doc

Server integrat¶

Odoo includes built-in HTTP, cron, and live-chat servers, using either multi-threading or multi-processing.

The multi-threaded server is a simpler server primarily used for development, demonstrations, and its compatibility with various operating systems (including Windows). A new thread is spawned for every new HTTP request, even for long-running requests such as long polling. Extra daemonic cron threads are spawned too. Due to a Python limitation (GIL), it doesn’t make the best use of the hardware.

The multi-threaded server is the default server, also for docker containers. It is selected by leaving the --workers option out or setting it to 0.

The multi-processing server is a full-blown server primarily used for production. It is not liable to the same Python limitation (GIL) on resource usage and hence makes the best use of the hardware. A pool of workers is created upon server startup. New HTTP requests are queued by the OS until there are workers ready to process them. An extra event-driven HTTP worker for the live chat is spawned on an alternative port. Extra cron workers are spawned too. A configurable process reaper monitors resource usage and can kill/restart failed workers.

The multi-processing server is opt-in. It is selected by setting the --workers option to a non-null integer.

Notă

Because it is highly customized for Linux servers, the multi-processing server is not available on Windows.

Calculul numărului de procese worker¶

Regulă de bază: (#CPU * 2) + 1
Procesele cron au nevoie de CPU
1 proces worker ~= 6 utilizatori concurenți

calculul dimensiunii memoriei¶

Considerăm că 20% din cererile sunt cereri grele, în timp ce 80% sunt mai simplu
Un proces worker greu, când toate câmpurile calculate sunt bine proiectate, cererile SQL sunt bine proiectate, … este estimat să consume aproximativ 1GB de RAM
Un proces worker mai ușor, în același scenariu, este estimat să consume aproximativ 150MB de RAM

RAM necesară = #worker * ( (rata_worker_ușor * estimarea_ram_worker_ușor) + (rata_worker_greu * estimarea_ram_worker_greu) )

LiveChat¶

In multi-processing, a dedicated LiveChat worker is automatically started and listens on the --longpolling-port. By default, the HTTP requests will keep accessing the normal HTTP workers instead of the LiveChat one. You must deploy a proxy in front of Odoo and redirect incoming requests whose path starts with /longpolling to the LiveChat worker. You must also start Odoo in --proxy-mode so it uses the real client headers (such as hostname, scheme, and IP) instead of the proxy ones.

Exemplu de configurare¶

Server cu 4 CPU, 8 Thread
60 de utilizatori concurenți
60 de utilizatori / 6 = 10 <- numărul teoretic de procese worker necesare
(4 * 2) + 1 = 9 <- numărul maxim teoretic de procese worker
Vom folosi 8 procese worker + 1 pentru cron. Vom folosi de asemenea un sistem de monitorizare pentru a măsura încărcarea CPU, și pentru a verifica dacă este între 7 și 7.5 .
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM pentru Odoo

in the configuration file:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

Indiferent dacă este accesat prin intermediul website/web client sau web service, Odoo transmite informații de autentificare în text clar. Acest lucru înseamnă că o implementare sigură a Odoo trebuie să folosească HTTPS3. Terminarea SSL poate fi implementată prin intermediul aproape oricărui proxy de terminare SSL, dar necesită următoarea configurare:

Activați modulul proxy al Odoo. Acest lucru ar trebui să fie activat numai atunci când Odoo este în spatele unui proxy invers
Configurați proxy-ul de terminare SSL (Exemplu de terminare Nginx)
Configurați proxy-ul în sine (Exemplu de proxy Nginx)
Proxy-ul dvs. de terminare SSL ar trebui de asemenea să redirecționeze la conexiunile ne securizate către port

Exemplu de configurare¶

Redirecționați cererile http către https
Proxy requests to odoo

in the configuration file set:

proxy_mode = True

în /etc/nginx/sites-enabled/odoo.conf setați:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # Add Headers for odoo proxy mode
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Real-IP $remote_addr;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect longpoll requests to odoo longpolling port
  location /longpolling {
    proxy_pass http://odoochat;
  }

  # Redirect requests to odoo backend server
  location / {
    proxy_redirect off;
    proxy_pass http://odoo;
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

Odoo ca o aplicație WSGI¶

Este de asemenea posibil să montați Odoo ca o aplicație standard WSGI . Odoo oferă baza pentru un script de lansare WSGI ca odoo-wsgi.example.py. Acest script ar trebui să fie personalizat (posibil după copierea din directorul de instalare) pentru a seta corect configurarea direct în odoo.tools.config în loc de prin linia de comandă sau un fișier de configurare.

Cu toate acestea, serverul WSGI va expune doar punctul final principal HTTP pentru web client, website și webservice API. Deoarece Odoo nu controlează crearea mai multor procese worker, nu poate configura cron sau procese worker livechat

Procese worker Cron¶

Starting one of the built-in Odoo servers next to the WSGI server is required to process cron jobs. That server must be configured to only process crons and not HTTP requests using the --no-http cli option or the http_enable = False configuration file setting.

On Linux-like systems, using the multi-processing server over the multi-threading one is recommended to benefit from better hardware usage and increased stability, i.e., using the --workers=-1 and --max-cron-threads=n cli options.

LiveChat¶

Using a gevent-compatible WSGI server is required for the correct operation of the live chat feature. That server should be able to handle many simultaneous long-lived HTTP requests but doesn’t need a lot of processing power. All requests whose path starts with /longpolling should be directed to that server. A regular (thread/process-based) WSGI server should be used for all other requests.

The Odoo cron server can also be used to serve the live chat requests. Just drop the --no-http cli option from the cron server and make sure requests whose path starts with /longpolling are directed to this server, either on the --http-port (multi-threading server) or on the --longpolling-port (multi-processing server).

Serving Static Files¶

For development convenience, Odoo directly serves all static files in its modules. This may not be ideal when it comes to performances, and static files should generally be served by a static HTTP server.

Odoo static files live in each module’s static/ folder, so static files can be served by intercepting all requests to /MODULE/static/FILE, and looking up the right module (and file) in the various addons paths.

Securitate¶

Pentru început, rețineți că securizarea unui sistem de informații este un proces continuu, nu o operațiune unică. În orice moment, veți fi doar atât de sigur cât cel mai slab link din mediul dvs.

Așa că vă rugăm să nu luați această secțiune ca fiind lista ultimă de măsuri care vor preveni toate problemele de securitate. Este doar destinat ca un rezumat al primelor lucruri importante pe care ar trebui să le fiți sigur că le includeți în planul dvs. de acțiune de securitate. Restul va veni din cele mai bune practici de securitate pentru sistemul dvs. de operare și distribuția, cele mai bune practici din punct de vedere al utilizatorilor, parolelor și managementului controlului accesului, etc.

Când implementați un server orientat către internet, vă rugăm să luați în considerare următoarele subiecte legate de securitate:

Setați întotdeauna o parolă puternică pentru super-admin și restrângeți accesul la paginile de administrare a bazei de date imediat ce sistemul este configurat. Vedeți Securitatea managerului de bază de date.
Alegeți logins unice și parole puternice pentru toate conturile de administrator pe toate bazele de date. Nu utilizați «admin» ca login. Nu utilizați aceste logins pentru operațiuni zilnice, doar pentru controlul/administrarea instalării. Niciodată nu utilizați parolele implicit ca admin/admin, chiar și pentru bazele de date de test/staging.
Nu instalați date de demonstrație pe servere orientate către internet. Bazele de date cu date de demonstrație conțin logins și parole implicite care pot fi utilizate pentru a intra în sistemele dvs. și pot cauza probleme semnificative, chiar și pe sistemele de testare/dezvoltare.
Folosiți filtrele de bază de date adecvate ( --db-filter) pentru a restrânge vizibilitatea bazelor de date în funcție de numele de gazdă. Vedeți dbfilter. De asemenea, puteți utiliza -d pentru a furniza propriul dvs. (separate prin virgulă) lista de baze de date disponibile pentru a filtra, în loc să lăsați sistemul să le aducă toate din backend-ul bazei de date.
Odată ce db_name și db_filter sunt configurate și se potrivesc cu o singură bază de date pe nume de gazdă, ar trebui să setați opțiunea de configurare list_db la False, pentru a preveni listarea completă a bazelor de date și pentru a bloca accesul la ecranele de administrare a bazelor de date (aceasta este expusă și ca opțiunea de linie de comandă --no-database-list)
Folosiți PostgreSQL user (--db_user) nu este un super-user, și că bazele de date sunt deținute de un alt utilizator. De exemplu, acestea ar putea fi deținute de super-user-ul postgres dacă folosiți un db_user non-privilegiat dedicat. Vedeți și Configurarea Odoo.
Păstrați instalările actualizate prin instalarea regulată a celor mai recente versiuni, fie prin intermediul GitHub sau prin descărcarea celei mai recente versiuni de la https://www.odoo.com/page/download sau http://nightly.odoo.com
Configurați serverul dvs. în modul multi-proces cu limite adecvate care se potrivesc cu utilizarea tipică (memorie/CPU/timeout-uri). Vedeți și :ref:
Porniți Odoo în spatele unui server web care oferă terminarea HTTPS cu un certificat SSL valid, pentru a preveni interceptarea comunicărilor în limba engleză. Certificările SSL sunt ieftine, și există multe opțiuni gratuite. Configurați proxy-ul web pentru a limita dimensiunea cererilor, setați timeout-uri adecvate, apoi activați opțiunea proxy mode. Vedeți și HTTPS.
Dacă aveți nevoie să permiteți accesul SSH la distanță la serverele dvs., asigurați-vă că setați o parolă puternică pentru toate conturile, nu doar root. Se recomandă în mod ferm să dezactivați complet autentificarea bazată pe parolă și să permiteți doar autentificarea cheii publice. De asemenea, luați în considerare restricționarea accesului prin VPN, permiteți doar IP-uri de încredere în firewall și / sau rulați un sistem de detectare a forței brute precum fail2ban sau echivalentul său.
Luați în considerare instalarea limitării adecvate a rate-ului pe proxy-ul dvs. sau firewall, pentru a preveni atacurile brute-force și atacurile de tip denial of service. Vedeți și Blocarea atacurilor brute force pentru măsuri specifice.

Mai mulți furnizori de rețea oferă automat mitigarea pentru atacurile de tip Distributed Denial of Service (DDOS), dar aceasta este adesea un serviciu opțional, așa că ar trebui să vă consultați cu ei.
De când posibil, găzduiți instanțele demo/test/staging care se confruntă cu publicul pe mașini diferite de cele de producție. Și aplicați aceleași precauții de securitate ca și pentru producție.
Dacă serverul dvs. Odoo care se confruntă cu publicul are acces la resurse interne sensibile sau servicii (de exemplu, prin intermediul unei VLAN private), implementați reguli de firewall adecvate pentru a proteja aceste resurse interne. Acest lucru va asigura că serverul Odoo nu poate fi utilizat accidental (sau ca rezultat al acțiunilor de utilizator malicioase) pentru a accesa sau perturba aceste resurse interne. De obicei, acest lucru se poate face prin aplicarea unei reguli de DENY implicită pe firewall, apoi numai autorizând explicit accesul la resursele interne pe care serverul Odoo le are nevoie să le acceseze. Systemd IP traffic access control poate fi de asemenea util pentru a implementa controlul de acces la rețea per-proces.
Dacă serverul dvs. Odoo care se confruntă cu publicul este în spatele unui firewall de aplicații web, un load-balancer, un serviciu de protecție DDoS transparent (precum CloudFlare) sau un dispozitiv de nivel de rețea similar, puteți dori să evitați accesul direct la sistemul Odoo. Este de obicei greu de păstrat adresele IP de capăt ale serverelor dvs. Odoo secrete. De exemplu, acestea pot apărea în jurnalele serverului web atunci când se interoghează sisteme publice, sau în antetele e-mailurilor postate din Odoo. Într-o astfel de situație, puteți dori să configurați firewall-ul astfel încât capetele să nu fie accesibile public, cu excepția adreselor IP specifice ale serviciului dvs. WAF, load-balancer sau proxy. Furnizorii de servicii precum CloudFlare de obicei mențin o listă publică a gamelor lor de adrese IP pentru acest scop.
Dacă găzduiți mai mulți clienți, izolați datele și fișierele clienților unul de celălalt utilizând containere sau tehnici adecvate de „jail”.
Configurați copii de rezervă zilnice ale bazelor de date și a datelor de magazin de fișiere, și copiați-le pe un server de arhivare la distanță care nu este accesibil de la serverul în sine.
Deploying Odoo on Linux is strongly recommended over Windows. Should you choose nevertheless to deploy on a Windows platform, a thorough security hardening review of the server should be conducted and is outside of the scope of this guide.

Blocarea atacurilor brute force¶

Pentru implementări care se confruntă cu publicul, atacurile brute force asupra parolelor de utilizator sunt foarte comune, și această amenințare nu trebuie să fie neglijată pentru serverele Odoo. Odoo emite o intrare în jurnal când este efectuată o încercare de conectare, și raportează rezultatul: reușit sau eșuat, împreună cu numele de utilizator țintă și adresa IP sursă.

Intrările în jurnal vor avea următorul format.

Conectare eșuată:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Conectare reușită:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Aceste jurnale pot fi analizate ușor de către un sistem de prevenire a incursiunilor precum fail2ban.

De exemplu, următoarea definiție de filtru fail2ban ar trebui să se potrivească cu o conectare eșuată:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Acest lucru ar putea fi utilizat cu o definiție de închisoare pentru a bloca IP-ul atacatorului pe HTTP(S).

Aici este cum ar putea arăta pentru blocarea IP-ului pentru 15 minute când 10 încercări de conectare eșuate sunt detectate de la același IP într-un minut:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Securitatea managerului de bază de date¶

Configurarea Odoo a menționat admin_passwd în trecere.

Această setare este utilizată pe toate ecranele de administrare a bazei de date (pentru a crea, șterge, crea o copie de rezervă sau restaura baze de date).

Dacă ecranele de administrare nu trebuie să fie accesibile deloc, ar trebui să setați opțiunea de configurare list_db la False, pentru a bloca accesul la toate ecranele de selecție și administrare a bazei de date.

Atenționare

Este recomandat puternic să dezactivați Database Manager pentru orice sistem care se confruntă cu publicul! Este destinat ca un instrument de dezvoltare/demonstrație, pentru a face ușor crearea și administrarea bazelor de date. Nu este conceput pentru utilizare în producție, și poate expune chiar și caracteristici periculoase atacatorilor. De asemenea, nu este conceput pentru a gestiona baze de date mari, și poate declanșa limitele de memorie.

Pe sistemele de producție, operațiunile de administrare a bazei de date trebuie efectuate întotdeauna de către administratorul de sistem, inclusiv provisionarea de noi baze de date și copii de rezervă automate.

Asigurați-vă că ați configurat un parametru db_name corespunzător (și opțional, și db_filter) astfel încât sistemul să poată determina baza de date țintă pentru fiecare solicitare, altfel utilizatorii vor fi blocați deoarece nu vor fi autorizați să aleagă baza de date singuri.

Dacă ecranele de administrare trebuie să fie accesibile numai dintr-un set selectat de mașini, utilizați funcțiile serverului proxy pentru a bloca accesul la toate rutele care încep cu /web/database cu excepția (posibil) /web/database/selector care afișează ecranul de selecție a bazei de date.

Dacă ecranul de administrare a bazei de date trebuie să rămână accesibil, setarea admin_passwd trebuie să fie schimbată de la admin la implicit: această parolă este verificată înainte de a permite operațiunile de modificare a bazei de date.

Trebuie stocată în siguranță, și ar trebui să fie generată aleatoriu, de exemplu

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

ce va genera un sir de 32 de caractere pseudo-aleatorii imprimabile.

Browsere suportate¶

Odoo suportă toate browserele majore de desktop și mobile disponibile pe piață, atâta timp cât sunt suportate de către editori.

Iată browserele suportate:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

Atenționare

Vă rugăm să vă asigurați că browserul este actualizat și încă suportat de editorul înainte de a depune un raport de eroare.

Notă

De la Odoo 13.0, ES6 este suportat. Prin urmare, suportul pentru IE este abandonat.

1: pentru a avea mai multe instalări Odoo care folosesc aceeași bază de date PostgreSQL, sau pentru a oferi mai multe resurse de calculare atât software-ului.
2: tehnologic, un instrument precum socat poate fi folosit pentru a proxy socket-uri UNIX prin rețele, dar acest lucru este mai mult pentru software
3: sau sa fie accesibil numai prin rețele interne de pachete, dar acest lucru necesită comutatoare securizate, protecții împotriva ARP spoofing și preclude folosirea WiFi. Chiar și peste rețele de pachete securizate, implementarea peste HTTPS este recomandată, și costurile posibile sunt scăzute deoarece certificatele „self-signed” sunt mai ușor de implementat într-o mediu controlat decât peste internet.

Edit on GitHub