सिस्टम कॉन्फ़िगरेशन¶

यह दस्तावेज़ Odoo को प्रॉडक्शन में या इंटरनेट-फ़ेसिंग सर्वर पर सेट अप करने के बुनियादी स्टेप्स का वर्णन करता है। यह इंस्टॉलेशन के बाद आता है, और आम तौर पर ऐसे डेवलपमेंट सिस्टम के लिए आवश्यक नहीं है जो इंटरनेट पर एक्सपोज़ नहीं है।

चेतावनी

अगर आप पब्लिक सर्वर सेट अप कर रहे हैं, तो हमारी सुरक्षा सिफ़ारिशों को ज़रूर चेक करें!

dbfilter¶

Odoo एक मल्टी-टेनेंट सिस्टम है: एक सिंगल Odoo सिस्टम कई डेटाबेस इंस्टेंसेस को रन और सर्व कर सकता है। यह अत्यधिक कस्टमाइज़ेबल भी है, जिसमें कस्टमाइज़ेशन (लोड किए जा रहे मॉड्यूल से शुरू होकर) "करंट डेटाबेस" पर निर्भर करते हैं।

बैकएंड (वेब क्लाइंट) के साथ लॉग-इन कंपनी यूज़र के रूप में काम करते समय यह कोई समस्या नहीं है: लॉग इन करते समय डेटाबेस को सेलेक्ट किया जा सकता है, और बाद में कस्टमाइज़ेशन लोड किए जा सकते हैं।

हालाँकि यह नॉन-लॉग्ड यूज़र्स (पोर्टल, वेबसाइट) के लिए एक समस्या है जो किसी डेटाबेस से बाउंड नहीं हैं: Odoo को यह जानने की आवश्यकता है कि वेबसाइट पेज लोड करने या ऑपरेशन करने के लिए किस डेटाबेस का इस्तेमाल किया जाना चाहिए। अगर मल्टी-टेनेंसी का इस्तेमाल नहीं किया जाता है तो यह कोई समस्या नहीं है, इस्तेमाल करने के लिए केवल एक डेटाबेस है, लेकिन अगर कई डेटाबेस एक्सेसिबल हैं तो Odoo को यह जानने के लिए एक नियम की आवश्यकता है कि उसे किसका इस्तेमाल करना चाहिए।

यह --db-filter के उद्देश्यों में से एक है: यह निर्दिष्ट करता है कि रिक्वेस्ट किए जा रहे होस्टनाम (डोमेन) के आधार पर डेटाबेस को कैसे सेलेक्ट किया जाना चाहिए। वैल्यू एक रेगुलर एक्सप्रेशन है, जिसमें संभवतः डायनामिक रूप से इंजेक्ट किया गया होस्टनाम (%h) या पहला सबडोमेन (%d) शामिल है जिसके माध्यम से सिस्टम को एक्सेस किया जा रहा है।

प्रॉडक्शन में कई डेटाबेस होस्ट करने वाले सर्वर के लिए, खासकर अगर website का इस्तेमाल किया जाता है, तो dbfilter सेट होना चाहिए, अन्यथा कई फ़ीचर्स सही ढंग से काम नहीं करेंगे।

कॉन्फ़िगरेशन सैंपल¶

सिर्फ़ 'mycompany' से शुरू होने वाले नामों वाले डेटाबेस दिखाएं

कॉन्फ़िगरेशन फ़ाइल में सेट करें:

[options]
dbfilter = ^mycompany.*$

सिर्फ़ www के बाद पहले सबडोमेन से मैच करने वाले डेटाबेस दिखाएं: उदाहरण के लिए, "mycompany" डेटाबेस दिखाया जाएगा अगर आने वाला अनुरोध www.mycompany.com या mycompany.co.uk पर भेजा गया था, लेकिन www2.mycompany.com या helpdesk.mycompany.com के लिए नहीं।

कॉन्फ़िगरेशन फ़ाइल में सेट करें:

[options]
dbfilter = ^%d$

टिप्पणी

सही --db-filter सेट करना आपकी डिप्लॉयमेंट को सुरक्षित करने का एक ज़रूरी हिस्सा है। एक बार जब यह सही तरीके से काम कर रहा हो और प्रति होस्टनेम केवल एक डेटाबेस से मैच हो रहा हो, तो डेटाबेस मैनेजर स्क्रीन तक ऐक्सेस ब्लॉक करना और --no-database-list स्टार्टअप पैरामीटर का इस्तेमाल करके अपने डेटाबेस की लिस्टिंग रोकना और डेटाबेस मैनेजमेंट स्क्रीन तक ऐक्सेस ब्लॉक करना बेहद ज़रूरी है। security भी देखें।

PostgreSQL¶

डिफ़ॉल्ट रूप से, PostgreSQL सिर्फ़ UNIX सॉकेट और लूपबैक कनेक्शन ("localhost" से, वही मशीन जिस पर PostgreSQL सर्वर इंस्टॉल है) की अनुमति देता है।

UNIX सॉकेट ठीक है अगर आप Odoo और PostgreSQL को एक ही मशीन पर चलाना चाहते हैं, और यह डिफ़ॉल्ट है जब कोई होस्ट प्रदान नहीं किया जाता, लेकिन अगर आप Odoo और PostgreSQL को अलग-अलग मशीनों पर चलाना चाहते हैं 1 तो इसे listen to network interfaces 2 की ज़रूरत होगी, या तो:

केवल लूपबैक कनेक्शन स्वीकार करें और उस मशीन के बीच use an SSH tunnel का इस्तेमाल करें जिस पर Odoo चलता है और जिस पर PostgreSQL चलता है, फिर Odoo को अपने टनल के अंत से कनेक्ट करने के लिए कॉन्फ़िगर करें
उस मशीन से कनेक्शन स्वीकार करें जिस पर Odoo इंस्टॉल है, संभवतः ssl के माध्यम से (विवरण के लिए PostgreSQL connection settings देखें), फिर Odoo को नेटवर्क के माध्यम से कनेक्ट करने के लिए कॉन्फ़िगर करें

कॉन्फ़िगरेशन सैंपल¶

localhost पर tcp कनेक्शन की अनुमति दें
192.168.1.x नेटवर्क से tcp कनेक्शन की अनुमति दें

/etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf में सेट करें:

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

/etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf में सेट करें:

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

Odoo को कॉन्फ़िगर करना¶

शुरुआत में, Odoo पोर्ट 5432 के माध्यम से UNIX सॉकेट पर लोकल postgres से कनेक्ट होता है। इसे डेटाबेस ऑप्शन का इस्तेमाल करके ओवरराइड किया जा सकता है जब आपकी Postgres डिप्लॉयमेंट लोकल नहीं है और/या इंस्टॉलेशन डिफ़ॉल्ट का इस्तेमाल नहीं करती है।

पैकेज्ड इंस्टॉलर ऑटोमैटिकली एक नया उपयोगकर्ता (odoo) बनाएंगे और इसे डेटाबेस उपयोगकर्ता के रूप में सेट करेंगे।

डेटाबेस मैनेजमेंट स्क्रीन admin_passwd सेटिंग द्वारा सुरक्षित हैं। यह सेटिंग केवल कॉन्फ़िगरेशन फ़ाइलों का इस्तेमाल करके सेट की जा सकती है, और डेटाबेस में बदलाव करने से पहले बस इसे चेक किया जाता है। इसे एक रैंडमली जेनेरेट की गई वैल्यू पर सेट किया जाना चाहिए ताकि थर्ड पार्टी इस इंटरफ़ेस का इस्तेमाल न कर सकें।
सभी डेटाबेस ऑपरेशन डेटाबेस ऑप्शन का इस्तेमाल करते हैं, जिसमें डेटाबेस मैनेजमेंट स्क्रीन भी शामिल है। डेटाबेस मैनेजमेंट स्क्रीन के काम करने के लिए ज़रूरी है कि PostgreSQL उपयोगकर्ता के पास createdb राइट हो।
उपयोगकर्ता हमेशा उन डेटाबेस को ड्रॉप कर सकते हैं जिनके वे मालिक हैं। डेटाबेस मैनेजमेंट स्क्रीन को पूरी तरह से गैर-कार्यात्मक बनाने के लिए, PostgreSQL उपयोगकर्ता को no-createdb के साथ बनाया जाना चाहिए और डेटाबेस किसी अन्य PostgreSQL उपयोगकर्ता के स्वामित्व में होना चाहिए।

चेतावनी
PostgreSQL उपयोगकर्ता superuser नहीं होना चाहिए

कॉन्फ़िगरेशन सैंपल¶

192.168.1.2 पर PostgreSQL सर्वर से कनेक्ट करें
पोर्ट 5432
'odoo' उपयोगकर्ता अकाउंट का इस्तेमाल करते हुए,
पासवर्ड के रूप में 'pwd' के साथ
केवल उन db को फ़िल्टर करना जिनका नाम 'mycompany' से शुरू होता है

कॉन्फ़िगरेशन फ़ाइल में सेट करें:

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

Odoo और PostgreSQL के बीच SSL¶

Odoo 11.0 के बाद से, आप Odoo और PostgreSQL के बीच ssl कनेक्शन को लागू कर सकते हैं। Odoo में db_sslmode कनेक्शन की ssl सुरक्षा को कंट्रोल करता है जिसमें 'disable', 'allow', 'prefer', 'require', 'verify-ca' या 'verify-full' में से चुने गए वैल्यू होते हैं

PostgreSQL Doc

बिल्ट-इन सर्वर¶

Odoo में बिल्ट-इन HTTP, cron, और लाइव-चैट सर्वर शामिल हैं, जो मल्टी-थ्रेडिंग या मल्टी-प्रोसेसिंग का इस्तेमाल करते हैं।

मल्टी-थ्रेडेड सर्वर एक सरल सर्वर है जो मुख्य रूप से डेवलपमेंट, प्रदर्शन और विभिन्न ऑपरेटिंग सिस्टम (Windows सहित) के साथ इसकी संगतता के लिए इस्तेमाल किया जाता है। हर नए HTTP अनुरोध के लिए एक नया थ्रेड बनाया जाता है, यहां तक कि websocket जैसे लंबे समय तक चलने वाले कनेक्शन के लिए भी। अतिरिक्त डेमॉनिक cron थ्रेड भी बनाए जाते हैं। Python की एक सीमा (GIL) के कारण, यह हार्डवेयर का सबसे अच्छा उपयोग नहीं करता है।

मल्टी-थ्रेडेड सर्वर डिफ़ॉल्ट सर्वर है, docker कंटेनर के लिए भी। इसे --workers ऑप्शन को छोड़कर या 0 पर सेट करके चुना जाता है।

मल्टी-प्रोसेसिंग सर्वर एक पूर्ण विकसित सर्वर है जो मुख्य रूप से प्रॉडक्शन के लिए इस्तेमाल किया जाता है। यह रिसोर्स उपयोग पर Python की समान सीमा (GIL) के अधीन नहीं है और इसलिए हार्डवेयर का सबसे अच्छा उपयोग करता है। सर्वर स्टार्टअप पर workers का एक pool बनाया जाता है। नए HTTP अनुरोध OS द्वारा तब तक कतारबद्ध किए जाते हैं जब तक कि उन्हें प्रोसेस करने के लिए workers तैयार न हों। लाइव चैट के लिए एक अतिरिक्त event-driven HTTP worker एक वैकल्पिक पोर्ट पर बनाया जाता है। अतिरिक्त cron workers भी बनाए जाते हैं। एक कॉन्फ़िगर करने योग्य प्रोसेस reaper रिसोर्स उपयोग की निगरानी करता है और विफल workers को kill/restart कर सकता है।

मल्टी-प्रोसेसिंग सर्वर opt-in है। इसे --workers ऑप्शन को एक नॉन-नल इंटीजर पर सेट करके चुना जाता है।

टिप्पणी

क्योंकि यह Linux सर्वर के लिए अत्यधिक अनुकूलित है, मल्टी-प्रोसेसिंग सर्वर Windows पर उपलब्ध नहीं है।

Worker संख्या की गणना¶

अंगूठे का नियम : (#CPU * 2) + 1
Cron workers को CPU की आवश्यकता होती है
1 वर्कर ~= 6 समवर्ती यूज़र

मेमोरी साइज़ की गणना¶

हम मानते हैं कि 20% अनुरोध हेवी अनुरोध होते हैं, जबकि 80% सरल होते हैं
एक हेवी वर्कर, जब सभी कम्प्यूटेड फ़ील्ड अच्छी तरह से डिज़ाइन किए गए हों, SQL अनुरोध अच्छी तरह से डिज़ाइन किए गए हों, ... लगभग 1GB RAM उपयोग करने का अनुमान है
एक लाइटर वर्कर, उसी परिदृश्य में, लगभग 150MB RAM उपयोग करने का अनुमान है

आवश्यक RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

लाइवचैट¶

मल्टी-प्रोसेसिंग में, एक समर्पित लाइवचैट वर्कर ऑटोमैटिकली शुरू होता है और --gevent-port पर सुनता है। डिफ़ॉल्ट रूप से, HTTP अनुरोध लाइवचैट वर्कर के बजाय सामान्य HTTP वर्कर्स तक पहुँचते रहेंगे। आपको Odoo के सामने एक प्रॉक्सी डिप्लॉय करनी होगी और आने वाले अनुरोधों को जिनका पाथ /websocket/ से शुरू होता है, लाइवचैट वर्कर पर रीडायरेक्ट करना होगा। आपको Odoo को --proxy-mode में भी शुरू करना होगा ताकि यह प्रॉक्सी के बजाय वास्तविक क्लाइंट हेडर्स (जैसे होस्टनेम, स्कीम, और आईपी) का इस्तेमाल करे।

कॉन्फ़िगरेशन सैंपल¶

4 CPU, 8 थ्रेड वाला सर्वर
60 समवर्ती यूज़र
60 यूज़र / 6 = 10 <- आवश्यक वर्कर्स की सैद्धांतिक संख्या
(4 * 2) + 1 = 9 <- वर्कर्स की सैद्धांतिक अधिकतम संख्या
हम 8 वर्कर्स + 1 cron के लिए इस्तेमाल करेंगे। हम CPU लोड को मापने के लिए एक मॉनिटरिंग सिस्टम का भी इस्तेमाल करेंगे, और जाँचेंगे कि यह 7 और 7.5 के बीच है।
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= Odoo के लिए 3GB RAM

कॉन्फ़िगरेशन फ़ाइल में:

[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¶

चाहे इसे वेबसाइट/वेब क्लाइंट या वेब सर्विस के ज़रिए एक्सेस किया जाए, Odoo प्रमाणीकरण जानकारी को क्लियरटेक्स्ट में ट्रांसमिट करता है। इसका मतलब है कि Odoo की एक सुरक्षित डिप्लॉयमेंट को HTTPS3 का इस्तेमाल करना चाहिए। SSL टर्मिनेशन को लगभग किसी भी SSL टर्मिनेशन प्रॉक्सी के ज़रिए लागू किया जा सकता है, लेकिन निम्नलिखित सेटअप की आवश्यकता होती है:

Odoo का प्रॉक्सी मोड सक्षम करें। इसे सिर्फ़ तभी सक्षम किया जाना चाहिए जब Odoo एक रिवर्स प्रॉक्सी के पीछे हो
SSL टर्मिनेशन प्रॉक्सी सेट करें (Nginx termination example)
प्रॉक्सीइंग को सेट करें (Nginx proxying example)
आपके SSL टर्मिनेशन प्रॉक्सी को नॉन-सिक्योर कनेक्शन को ऑटोमैटिकली सिक्योर पोर्ट पर रीडायरेक्ट करना चाहिए

कॉन्फ़िगरेशन सैंपल¶

http अनुरोध को https पर रीडायरेक्ट करें
Odoo के लिए प्रॉक्सी अनुरोध

कॉन्फ़िगरेशन फ़ाइल में सेट करें:

proxy_mode = True

/etc/nginx/sites-enabled/odoo.conf में सेट करें:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# 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;

  # 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 websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    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;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # 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;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

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

HTTPS हार्डनिंग¶

सभी अनुरोध में Strict-Transport-Security हेडर जोड़ें, ताकि ब्राउज़र इस डोमेन पर कभी भी प्लेन HTTP अनुरोध न भेज सकें। आपको हमेशा इस डोमेन पर वैलिड सर्टिफ़िकेट के साथ काम करने वाली HTTPS सर्विस बनाए रखनी होगी, अन्यथा आपके यूज़र को सिक्योरिटी अलर्ट दिखाई देंगे या वे इसे ऐक्सेस करने में पूरी तरह असमर्थ होंगे।

NGINX में हर विज़िटर के लिए एक साल तक HTTPS कनेक्शन फ़ोर्स करें इस लाइन के साथ:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

session_id कुकी के लिए अतिरिक्त कॉन्फ़िगरेशन डिफ़ाइन किया जा सकता है। Secure फ़्लैग जोड़ा जा सकता है ताकि यह सुनिश्चित हो सके कि यह कभी भी HTTP पर ट्रांसमिट न हो और SameSite=Lax ताकि ऑथेंटिकेटेड CSRF को रोका जा सके।

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

WSGI ऐप्लिकेशन के रूप में Odoo¶

Odoo को स्टैंडर्ड WSGI ऐप्लिकेशन के रूप में माउंट करना भी संभव है। Odoo odoo-wsgi.example.py के रूप में WSGI लॉन्चर स्क्रिप्ट के लिए बेस प्रदान करता है। उस स्क्रिप्ट को कस्टमाइज़ किया जाना चाहिए (संभवतः सेटअप डायरेक्टरी से कॉपी करने के बाद) ताकि कमांड-लाइन या कॉन्फ़िगरेशन फ़ाइल के बजाय odoo.tools.config में सीधे कॉन्फ़िगरेशन सही तरीके से सेट हो सके।

हालांकि WSGI सर्वर केवल वेब क्लाइंट, वेबसाइट और वेबसर्विस एपीआई के लिए मुख्य HTTP एंडपॉइंट को एक्सपोज़ करेगा। क्योंकि Odoo अब वर्कर के क्रिएशन को कंट्रोल नहीं करता है इसलिए यह cron या लाइवचैट वर्कर को सेटअप नहीं कर सकता

Cron वर्कर¶

Cron जॉब को प्रोसेस करने के लिए WSGI सर्वर के साथ बिल्ट-इन Odoo सर्वर में से एक को स्टार्ट करना आवश्यक है। उस सर्वर को --no-http CLI ऑप्शन या http_enable = False कॉन्फ़िगरेशन फ़ाइल सेटिंग का उपयोग करके केवल cron को प्रोसेस करने और HTTP अनुरोध नहीं करने के लिए कॉन्फ़िगर किया जाना चाहिए।

Linux जैसे सिस्टम पर, बेहतर हार्डवेयर उपयोग और बढ़ी हुई स्थिरता से लाभ उठाने के लिए मल्टी-थ्रेडिंग सर्वर की तुलना में मल्टी-प्रोसेसिंग सर्वर का उपयोग करने की सिफ़ारिश की जाती है, यानी --workers=-1 और --max-cron-threads=n CLI ऑप्शन का उपयोग करना।

लाइवचैट¶

लाइव चैट फ़ीचर के सही ऑपरेशन के लिए gevent-कंपैटिबल WSGI सर्वर का उपयोग करना आवश्यक है। उस सर्वर को कई एक साथ लंबे समय तक चलने वाले कनेक्शन को हैंडल करने में सक्षम होना चाहिए लेकिन इसे बहुत अधिक प्रोसेसिंग पावर की आवश्यकता नहीं होती। सभी अनुरोध जिनका पाथ /websocket/ से शुरू होता है, उन्हें उस सर्वर पर डायरेक्ट किया जाना चाहिए। अन्य सभी अनुरोध के लिए एक रेगुलर (thread/process-आधारित) WSGI सर्वर का उपयोग किया जाना चाहिए।

Odoo cron सर्वर का उपयोग लाइव चैट अनुरोध को सर्व करने के लिए भी किया जा सकता है। बस cron सर्वर से --no-http CLI ऑप्शन हटा दें और सुनिश्चित करें कि जिन अनुरोध का पाथ /websocket/ से शुरू होता है वे इस सर्वर पर डायरेक्ट हों, या तो --http-port (मल्टी-थ्रेडिंग सर्वर) पर या --gevent-port (मल्टी-प्रोसेसिंग सर्वर) पर।

स्टैटिक फ़ाइल और अटैचमेंट सर्व करना¶

डेवलपमेंट सुविधा के लिए, Odoo अपने मॉड्यूल में सभी स्टैटिक फ़ाइल और अटैचमेंट को सीधे सर्व करता है। परफ़ॉर्मेंस की बात आने पर यह आदर्श नहीं हो सकता है, और स्टैटिक फ़ाइल को आम तौर पर स्टैटिक HTTP सर्वर द्वारा सर्व किया जाना चाहिए।

स्टैटिक फ़ाइल सर्व करना¶

Odoo स्टैटिक फ़ाइल प्रत्येक मॉड्यूल के static/ फ़ोल्डर में स्थित होती हैं, इसलिए स्टैटिक फ़ाइल को /MODULE/static/FILE के सभी अनुरोध को इंटरसेप्ट करके और विभिन्न addons पाथ में सही मॉड्यूल (और फ़ाइल) को देखकर सर्व किया जा सकता है।

यह अनुशंसित है कि वेब सर्वर द्वारा डिलीवर की गई सभी इमेज पर Content-Security-Policy: default-src 'none' हेडर सेट किया जाए। यह पूरी तरह से ज़रूरी नहीं है क्योंकि उपयोगकर्ता मॉड्यूल के static/ फ़ोल्डर के अंदर कॉन्टेंट को मॉडिफ़ाई/इंजेक्ट नहीं कर सकते और मौजूदा इमेज फ़ाइनल हैं (वे खुद नए रिसोर्स फ़ेच नहीं करती)। हालांकि, यह अच्छी प्रैक्टिस है।

ऊपर दिए गए NGINX (https) कॉन्फ़िगरेशन का इस्तेमाल करते हुए, NGINX के ज़रिए स्टैटिक फ़ाइल सर्व करने के लिए निम्नलिखित map और location ब्लॉक जोड़े जाने चाहिए।

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

वास्तविक root और try_files डायरेक्टिव आपके इंस्टॉलेशन पर निर्भर हैं, खासकर आपके --addons-path पर।

Example

मान लीजिए कि Odoo को कम्युनिटी और एंटरप्राइज़ के लिए डेबियन पैकेज के ज़रिए इंस्टॉल किया गया है, और --addons-path '/usr/lib/python3/dist-packages/odoo/addons' है।

root और try_files ये होने चाहिए:

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

मान लीजिए कि Odoo को सोर्स के ज़रिए इंस्टॉल किया गया है, कि कम्युनिटी और एंटरप्राइज़ दोनों git रिपॉज़िटरी क्रमशः /opt/odoo/community और /opt/odoo/enterprise में क्लोन की गई थीं, और --addons-path '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise' है।

root और try_files ये होने चाहिए:

root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;

अटैचमेंट सर्व करना¶

अटैचमेंट फ़ाइलस्टोर में स्टोर की गई फ़ाइल हैं जिनका ऐक्सेस Odoo द्वारा नियंत्रित होता है। उन्हें सीधे स्टैटिक वेब सर्वर के ज़रिए ऐक्सेस नहीं किया जा सकता क्योंकि उन्हें ऐक्सेस करने के लिए डेटाबेस में कई लुकअप की ज़रूरत होती है ताकि यह निर्धारित किया जा सके कि फ़ाइल कहाँ स्टोर हैं और वर्तमान उपयोगकर्ता उन्हें ऐक्सेस कर सकता है या नहीं।

फिर भी, एक बार फ़ाइल का पता लगने और Odoo द्वारा ऐक्सेस अधिकारों की पुष्टि हो जाने के बाद, Odoo के बजाय स्टैटिक वेब सर्वर का उपयोग करके फ़ाइल को सर्व करना एक अच्छा विचार है। Odoo के लिए फ़ाइलों को सर्व करने का काम स्टैटिक वेब सर्वर को सौंपने के लिए, स्टैटिक वेब सर्वर पर X-Sendfile (apache) या X-Accel (nginx) एक्सटेंशन को सक्षम और कॉन्फ़िगर किया जाना चाहिए। एक बार इसे सेट अप कर लेने के बाद, Odoo को --x-sendfile CLI फ़्लैग के साथ शुरू करें (यह एकल फ़्लैग X-Sendfile और X-Accel दोनों के लिए उपयोग किया जाता है)।

टिप्पणी

Apache (और संगत वेब सर्वर) के लिए X-Sendfile एक्सटेंशन को किसी अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत नहीं है।
NGINX के लिए X-Accel एक्सटेंशन को निम्नलिखित अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत है:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
    add_header Content-Security-Policy $upstream_http_content_security_policy;
    add_header X-Content-Type-Options nosniff;
}
```
अगर आपको नहीं पता कि आपके फ़ाइलस्टोर का पाथ क्या है, तो Odoo को --x-sendfile ऑप्शन के साथ स्टार्ट करें और सीधे Odoo के ज़रिए /web/filestore URL पर नेविगेट करें (NGINX के ज़रिए URL पर नेविगेट न करें)। यह एक चेतावनी लॉग करता है, मैसेज में वह कॉन्फ़िगरेशन होता है जो आपको चाहिए।

सुरक्षा¶

शुरुआत के लिए, यह ध्यान रखें कि इन्फ़ॉर्मेशन सिस्टम को सुरक्षित करना एक निरंतर प्रक्रिया है, एक बार का ऑपरेशन नहीं। किसी भी समय, आप केवल अपने एनवायरमेंट की सबसे कमज़ोर कड़ी जितने ही सुरक्षित होंगे।

इसलिए कृपया इस सेक्शन को उन उपायों की अंतिम सूची के रूप में न लें जो सभी सुरक्षा समस्याओं को रोक देंगे। यह केवल उन पहली ज़रूरी चीज़ों के सारांश के रूप में है जिन्हें आपको अपनी सुरक्षा ऐक्शन प्लान में शामिल करना सुनिश्चित करना चाहिए। बाकी आपके ऑपरेटिंग सिस्टम और डिस्ट्रिब्यूशन के लिए बेस्ट सिक्योरिटी प्रैक्टिस, उपयोगकर्ताओं, पासवर्ड और ऐक्सेस कंट्रोल मैनेजमेंट के मामले में बेस्ट प्रैक्टिस आदि से आएगा।

इंटरनेट-फ़ेसिंग सर्वर डिप्लॉय करते समय, कृपया निम्नलिखित सुरक्षा-संबंधित विषयों पर विचार करना सुनिश्चित करें:

हमेशा एक मज़बूत सुपर-एडमिन पासवर्ड सेट करें, और सिस्टम सेटअप होते ही डेटाबेस मैनेजमेंट पेज का ऐक्सेस प्रतिबंधित करें। डेटाबेस मैनेजर सुरक्षा देखें।
सभी डेटाबेस पर सभी एडमिन अकाउंट के लिए यूनीक लॉगिन और मज़बूत पासवर्ड चुनें। लॉगिन के रूप में 'admin' का इस्तेमाल न करें। इंस्टॉलेशन को कंट्रोल/मैनेज करने के लिए ही इन लॉगिन का इस्तेमाल करें, दिन-प्रतिदिन के ऑपरेशन के लिए नहीं। कभी भी admin/admin जैसे किसी भी डिफ़ॉल्ट पासवर्ड का इस्तेमाल न करें, यहाँ तक कि टेस्ट/स्टेजिंग डेटाबेस के लिए भी।
इंटरनेट-फ़ेसिंग सर्वर पर डेमो डेटा इंस्टॉल न करें। डेमो डेटा वाले डेटाबेस में डिफ़ॉल्ट लॉगिन और पासवर्ड होते हैं जिनका इस्तेमाल आपके सिस्टम में घुसने और महत्वपूर्ण परेशानी पैदा करने के लिए किया जा सकता है, यहाँ तक कि स्टेजिंग/डेव सिस्टम पर भी।
होस्टनेम के अनुसार अपने डेटाबेस की विज़िबिलिटी को प्रतिबंधित करने के लिए उपयुक्त डेटाबेस फ़िल्टर (--db-filter) का इस्तेमाल करें। dbfilter देखें। आप डेटाबेस बैकएंड से सभी को फ़ेच करने देने के बजाय, फ़िल्टर करने के लिए उपलब्ध डेटाबेस की अपनी (कॉमा-सेपरेटेड) सूची प्रदान करने के लिए -d का भी इस्तेमाल कर सकते हैं।
जब आपका db_name और dbfilter कॉन्फ़िगर हो जाए और प्रति होस्टनेम सिर्फ़ एक डेटाबेस से मैच करे, तो आपको list_db कॉन्फ़िगरेशन ऑप्शन को False पर सेट करना चाहिए, ताकि डेटाबेस की लिस्टिंग पूरी तरह से रोकी जा सके और डेटाबेस मैनेजमेंट स्क्रीन तक ऐक्सेस ब्लॉक हो सके (यह --no-database-list कमांड-लाइन ऑप्शन के रूप में भी उपलब्ध है)
सुनिश्चित करें कि PostgreSQL उपयोगकर्ता (--db_user) सुपर-यूज़र नहीं है, और आपके डेटाबेस किसी अलग उपयोगकर्ता के स्वामित्व में हैं। उदाहरण के लिए अगर आप डेडिकेटेड नॉन-प्रिविलेज्ड db_user का उपयोग कर रहे हैं तो वे postgres सुपर-यूज़र के स्वामित्व में हो सकते हैं। यह भी देखें Odoo को कॉन्फ़िगर करना।
GitHub के जरिए या https://www.odoo.com/page/download या http://nightly.odoo.com से नवीनतम वर्शन डाउनलोड करके नियमित रूप से नवीनतम बिल्ड इंस्टॉल करके इंस्टॉलेशन को अपडेट रखें
अपने सर्वर को मल्टी-प्रोसेस मोड में अपने सामान्य उपयोग (मेमोरी/सीपीयू/टाइमआउट) से मेल खाने वाली उचित लिमिट के साथ कॉन्फ़िगर करें। यह भी देखें बिल्ट-इन सर्वर।
ईव्सड्रॉपिंग को रोकने के लिए क्लियरटेक्स्ट कम्युनिकेशन पर, वैध SSL सर्टिफ़िकेट के साथ HTTPS टर्मिनेशन प्रदान करने वाले वेब सर्वर के पीछे Odoo चलाएं। SSL सर्टिफ़िकेट सस्ते हैं, और कई मुफ़्त ऑप्शन मौजूद हैं। अनुरोधों के साइज़ को सीमित करने के लिए वेब प्रॉक्सी कॉन्फ़िगर करें, उचित टाइमआउट सेट करें, और फिर proxy mode ऑप्शन सक्षम करें। यह भी देखें HTTPS।
अगर आपको अपने सर्वर पर रिमोट SSH ऐक्सेस की अनुमति देनी है, तो सुनिश्चित करें कि सिर्फ़ root ही नहीं बल्कि सभी अकाउंट के लिए मजबूत पासवर्ड सेट करें। यह अत्यधिक अनुशंसित है कि पासवर्ड-आधारित प्रमाणीकरण को पूरी तरह से अक्षम करें, और केवल पब्लिक की प्रमाणीकरण की अनुमति दें। VPN के जरिए ऐक्सेस को प्रतिबंधित करना, फ़ायरवॉल में सिर्फ़ विश्वसनीय IP की अनुमति देना, और/या fail2ban या समकक्ष जैसे ब्रूट-फ़ोर्स डिटेक्शन सिस्टम चलाना भी विचार करें।
ब्रूट-फ़ोर्स अटैक और डिनायल ऑफ़ सर्विस अटैक को रोकने के लिए अपने प्रॉक्सी या फ़ायरवॉल पर उपयुक्त रेट-लिमिटिंग इंस्टॉल करने पर विचार करें। विशिष्ट उपायों के लिए ब्रूट फ़ोर्स अटैक को ब्लॉक करना भी देखें।

कई नेटवर्क प्रोवाइडर डिस्ट्रिब्यूटेड डिनायल ऑफ़ सर्विस अटैक (DDOS) के लिए स्वचालित शमन प्रदान करते हैं, लेकिन यह अक्सर एक वैकल्पिक सर्विस होती है, इसलिए आपको उनसे परामर्श करना चाहिए।
जब भी संभव हो, अपने पब्लिक-फ़ेसिंग डेमो/टेस्ट/स्टेजिंग इंस्टेंस को प्रॉडक्शन वाली मशीनों से अलग मशीनों पर होस्ट करें। और प्रॉडक्शन की तरह ही सुरक्षा सावधानियां लागू करें।
अगर आपके पब्लिक-फ़ेसिंग Odoo सर्वर की संवेदनशील इंटरनल नेटवर्क रिसोर्स या सर्विस (जैसे प्राइवेट VLAN के जरिए) तक ऐक्सेस है, तो उन इंटरनल रिसोर्स को सुरक्षित करने के लिए उपयुक्त फ़ायरवॉल नियम लागू करें। यह सुनिश्चित करेगा कि Odoo सर्वर का उपयोग आकस्मिक रूप से (या दुर्भावनापूर्ण उपयोगकर्ता कार्यों के परिणामस्वरूप) उन इंटरनल रिसोर्स तक ऐक्सेस करने या उन्हें बाधित करने के लिए नहीं किया जा सकता। आमतौर पर यह फ़ायरवॉल पर आउटबाउंड डिफ़ॉल्ट DENY नियम लागू करके किया जा सकता है, फिर केवल उन इंटरनल रिसोर्स तक ऐक्सेस को स्पष्ट रूप से अधिकृत करें जिन तक Odoo सर्वर को ऐक्सेस करने की आवश्यकता है। Systemd IP traffic access control भी प्रति-प्रोसेस नेटवर्क ऐक्सेस कंट्रोल लागू करने के लिए उपयोगी हो सकता है।
अगर आपका पब्लिक-फ़ेसिंग Odoo सर्वर वेब ऐप्लिकेशन फ़ायरवॉल, लोड-बैलेंसर, पारदर्शी DDoS प्रोटेक्शन सर्विस (जैसे CloudFlare) या इसी तरह के नेटवर्क-लेवल डिवाइस के पीछे है, तो आप Odoo सिस्टम तक डायरेक्ट ऐक्सेस से बचना चाह सकते हैं। आमतौर पर अपने Odoo सर्वर के एंडपॉइंट IP एड्रेस को गुप्त रखना मुश्किल होता है। उदाहरण के लिए वे पब्लिक सिस्टम को क्वेरी करते समय वेब सर्वर लॉग में दिखाई दे सकते हैं, या Odoo से पोस्ट किए गए ईमेल के हेडर में। ऐसी स्थिति में आप अपने फ़ायरवॉल को इस तरह कॉन्फ़िगर करना चाह सकते हैं कि एंडपॉइंट आपके WAF, लोड-बैलेंसर या प्रॉक्सी सर्विस के विशिष्ट IP एड्रेस के अलावा सार्वजनिक रूप से सुलभ न हों। CloudFlare जैसे सर्विस प्रोवाइडर आमतौर पर इस उद्देश्य के लिए अपनी IP एड्रेस रेंज की पब्लिक लिस्ट बनाए रखते हैं।
अगर आप कई ग्राहकों को होस्ट कर रहे हैं, तो कंटेनर या उपयुक्त "jail" तकनीकों का उपयोग करके ग्राहक डेटा और फ़ाइल को एक-दूसरे से अलग करें।
अपने डेटाबेस और फ़ाइलस्टोर डेटा का दैनिक बैकअप सेट करें, और उन्हें ऐसे रिमोट आर्काइविंग सर्वर पर कॉपी करें जो सर्वर से ही सुलभ न हो।
Windows की तुलना में Linux पर Odoo डिप्लॉय करने की अत्यधिक अनुशंसा की जाती है। यदि आप फिर भी Windows प्लेटफ़ॉर्म पर डिप्लॉय करना चुनते हैं, तो सर्वर की संपूर्ण सुरक्षा हार्डनिंग समीक्षा की जानी चाहिए और यह इस गाइड के दायरे से बाहर है।

ब्रूट फ़ोर्स अटैक को ब्लॉक करना¶

इंटरनेट-फ़ेसिंग डिप्लॉयमेंट के लिए, उपयोगकर्ता पासवर्ड पर ब्रूट फ़ोर्स अटैक बहुत आम हैं, और Odoo सर्वर के लिए इस खतरे की उपेक्षा नहीं की जानी चाहिए। Odoo जब भी लॉगिन प्रयास किया जाता है तो एक लॉग एंट्री जारी करता है, और परिणाम रिपोर्ट करता है: सफलता या विफलता, टारगेट लॉगिन और सोर्स IP के साथ।

लॉग एंट्री निम्नलिखित फ़ॉर्म में होंगी।

विफल लॉगिन:

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

सफल लॉगिन:

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

इन लॉग का fail2ban जैसे इंट्रूज़न प्रिवेंशन सिस्टम द्वारा आसानी से विश्लेषण किया जा सकता है।

उदाहरण के लिए, निम्नलिखित fail2ban फ़िल्टर परिभाषा असफल लॉगिन से मेल खानी चाहिए:

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

इसका उपयोग HTTP(S) पर हमला करने वाले आईपी को ब्लॉक करने के लिए jail परिभाषा के साथ किया जा सकता है।

यह इस तरह दिख सकता है कि जब 1 मिनट के भीतर एक ही आईपी से 10 असफल लॉगिन प्रयास का पता चलता है तो 15 मिनट के लिए आईपी को ब्लॉक किया जाए:

[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

डेटाबेस मैनेजर सुरक्षा¶

Odoo को कॉन्फ़िगर करना ने admin_passwd का उल्लेख किया।

यह सेटिंग सभी डेटाबेस मैनेजमेंट स्क्रीन पर उपयोग की जाती है (डेटाबेस बनाने, मिटाने, डंप करने या रिस्टोर करने के लिए)।

अगर मैनेजमेंट स्क्रीन बिल्कुल भी एक्सेसिबल नहीं होनी चाहिए, तो आपको list_db कॉन्फ़िगरेशन ऑप्शन को False पर सेट करना चाहिए, ताकि सभी डेटाबेस चयन और मैनेजमेंट स्क्रीन तक एक्सेस ब्लॉक हो जाए।

चेतावनी

किसी भी इंटरनेट-फेसिंग सिस्टम के लिए डेटाबेस मैनेजर को अक्षम करने की दृढ़ता से सिफारिश की जाती है! यह एक डेवलपमेंट/डेमो टूल है, जो डेटाबेस को जल्दी से बनाना और मैनेज करना आसान बनाता है। यह प्रॉडक्शन में उपयोग के लिए डिज़ाइन नहीं किया गया है, और यह हमलावरों के लिए खतरनाक फीचर्स को भी उजागर कर सकता है। यह बड़े डेटाबेस को संभालने के लिए भी डिज़ाइन नहीं किया गया है, और मेमोरी लिमिट को ट्रिगर कर सकता है।

प्रॉडक्शन सिस्टम पर, डेटाबेस मैनेजमेंट ऑपरेशन हमेशा सिस्टम एडमिन द्वारा किए जाने चाहिए, जिसमें नए डेटाबेस का प्रावधान और स्वचालित बैकअप शामिल हैं।

एक उपयुक्त db_name पैरामीटर सेट करना सुनिश्चित करें (और वैकल्पिक रूप से, dbfilter भी) ताकि सिस्टम प्रत्येक अनुरोध के लिए टारगेट डेटाबेस निर्धारित कर सके, अन्यथा उपयोगकर्ता ब्लॉक हो जाएंगे क्योंकि उन्हें खुद डेटाबेस चुनने की अनुमति नहीं होगी।

अगर मैनेजमेंट स्क्रीन केवल मशीनों के चयनित सेट से एक्सेसिबल होनी चाहिए, तो प्रॉक्सी सर्वर की सुविधाओं का उपयोग करके /web/database से शुरू होने वाले सभी रूट तक एक्सेस को ब्लॉक करें, सिवाय (शायद) /web/database/selector के, जो डेटाबेस-चयन स्क्रीन प्रदर्शित करता है।

अगर डेटाबेस-मैनेजमेंट स्क्रीन एक्सेसिबल रहनी चाहिए, तो admin_passwd सेटिंग को इसके admin डिफ़ॉल्ट से बदला जाना चाहिए: डेटाबेस-परिवर्तन ऑपरेशन की अनुमति देने से पहले इस पासवर्ड को चेक किया जाता है।

इसे सुरक्षित रूप से संग्रहीत किया जाना चाहिए, और यादृच्छिक रूप से जेनरेट किया जाना चाहिए जैसे।

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

जो 32-कैरेक्टर का स्यूडोरैंडम प्रिंटेबल स्ट्रिंग जेनरेट करता है।

मास्टर पासवर्ड रीसेट करें¶

ऐसे उदाहरण हो सकते हैं जहां मास्टर पासवर्ड गुम हो गया हो, या कंप्रोमाइज हो गया हो, और उसे रीसेट करने की आवश्यकता हो। निम्नलिखित प्रक्रिया Odoo ऑन-प्रिमाइस डेटाबेस के सिस्टम एडमिन के लिए है, जो यह बताती है कि मास्टर पासवर्ड को मैन्युअल रूप से कैसे रीसेट और फिर से एन्क्रिप्ट करें।

यह भी देखें

Odoo.com अकाउंट

नया ऑन-प्रिमाइस डेटाबेस बनाते समय, एक यादृच्छिक मास्टर पासवर्ड जेनरेट होता है। Odoo डेटाबेस को सुरक्षित करने के लिए इस पासवर्ड का उपयोग करने की सिफारिश करता है। यह पासवर्ड डिफ़ॉल्ट रूप से लागू होता है, इसलिए किसी भी Odoo ऑन-प्रिमाइस डिप्लॉयमेंट के लिए एक सुरक्षित मास्टर पासवर्ड होता है।

चेतावनी

Odoo ऑन-प्रिमाइस डेटाबेस बनाते समय इंस्टॉलेशन इंटरनेट पर किसी के लिए भी एक्सेसिबल होता है, जब तक कि डेटाबेस को सुरक्षित करने के लिए यह पासवर्ड सेट नहीं किया जाता।

मास्टर पासवर्ड Odoo कॉन्फ़िगरेशन फ़ाइल (odoo.conf या odoorc (हिडन फ़ाइल)) में निर्दिष्ट होता है। ग्राफिकल यूजर इंटरफ़ेस (GUI) के माध्यम से डेटाबेस को संशोधित करने, बनाने या मिटाने के लिए Odoo मास्टर पासवर्ड की आवश्यकता होती है।

कॉन्फ़िगरेशन फ़ाइल का पता लगाएँ¶

सबसे पहले, Odoo कॉन्फ़िगरेशन फ़ाइल (odoo.conf या odoorc (छिपी हुई फ़ाइल)) खोलें।

कॉन्फ़िगरेशन फ़ाइल यहाँ स्थित है: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Linux मशीन पर Odoo कैसे इंस्टॉल किया गया है, इसके आधार पर कॉन्फ़िगरेशन फ़ाइल दो अलग-अलग स्थानों में से एक पर स्थित होती है:

पैकेज इंस्टॉलेशन: /etc/odoo.conf
सोर्स इंस्टॉलेशन: ~/.odoorc

पुराना पासवर्ड बदलें¶

उपयुक्त फ़ाइल खोलने के बाद, कॉन्फ़िगरेशन फ़ाइल में पुराने पासवर्ड को एक अस्थायी पासवर्ड में बदलें।

कॉन्फ़िगरेशन फ़ाइल का पता लगाने के बाद, इसे GUI का उपयोग करके खोलें। यह फ़ाइल पर डबल क्लिक करके किया जा सकता है। फिर, डिवाइस में फ़ाइल खोलने के लिए डिफ़ॉल्ट GUI होना चाहिए।

अगला, मास्टर पासवर्ड लाइन admin_passwd = $pbkdf2-sha… को admin_passwd = newpassword1234 में बदलें, उदाहरण के लिए। यह पासवर्ड कुछ भी हो सकता है, जब तक इसे अस्थायी रूप से सेव किया जाए। = के बाद के सभी अक्षरों को बदलना सुनिश्चित करें।

Example

लाइन इस तरह दिखाई देती है: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

संशोधित लाइन इस तरह दिखाई देती है: admin_passwd = newpassword1234

नीचे दिए गए Unix कमांड का उपयोग करके मास्टर पासवर्ड लाइन को संशोधित करें।

Secure Shell (SSH) प्रोटोकॉल के ज़रिए Odoo सर्वर के टर्मिनल से कनेक्ट करें और कॉन्फ़िगरेशन फ़ाइल में बदलाव करें। कॉन्फ़िगरेशन फ़ाइल को संशोधित करने के लिए, निम्नलिखित कमांड दर्ज करें: sudo nano /etc/odoo.conf

कॉन्फ़िगरेशन फ़ाइल खोलने के बाद, मास्टर पासवर्ड लाइन admin_passwd = $pbkdf2-sha… को admin_passwd = newpassword1234 में बदलें। यह पासवर्ड कुछ भी हो सकता है, जब तक इसे अस्थायी रूप से सेव किया जाए। = के बाद के सभी अक्षरों को बदलना सुनिश्चित करें।

Example

संशोधित लाइन इस तरह दिखाई देती है: admin_passwd = newpassword1234

महत्त्वपूर्ण

यह आवश्यक है कि पासवर्ड को कुछ और में बदला जाए, बजाय लाइन की शुरुआत में सेमीकोलन ; जोड़कर नया पासवर्ड रीसेट ट्रिगर करने के। यह सुनिश्चित करता है कि पूरी पासवर्ड रीसेट प्रक्रिया के दौरान डेटाबेस सुरक्षित रहे।

Odoo सर्वर को रीसेट करें¶

Odoo सर्वर को रीस्टार्ट करने के लिए अस्थायी पासवर्ड सेट करने के बाद आवश्यक है।

Odoo सर्वर को रीस्टार्ट करने के लिए, पहले Windows खोजें बार में services टाइप करें। फिर, सर्विस ऐप्लिकेशन को सेलेक्ट करें, और Odoo सर्विस तक स्क्रॉल करें।

अगला, Odoo पर राइट क्लिक करें, और Start या Restart सेलेक्ट करें। यह ऐक्शन Odoo सर्वर को मैन्युअली रीस्टार्ट करता है।

यह कमांड टाइप करके Odoo सर्वर को रीस्टार्ट करें: sudo service odoo15 restart

टिप्पणी

सर्वर पर चल रहे विशिष्ट वर्शन के अनुसार odoo के बाद नंबर बदलें।

पासवर्ड को फिर से एन्क्रिप्ट करने के लिए वेब इंटरफ़ेस का इस्तेमाल करें¶

पहले, ब्राउज़र में /web/database/manager या http://server_ip:port/web/database/manager पर जाएं।

टिप्पणी

server_ip को डेटाबेस के आईपी पते से बदलें। port को उस नंबर पोर्ट से बदलें जहां से डेटाबेस एक्सेसिबल है।

अगला, Set Master Password पर क्लिक करें, और मास्टर पासवर्ड फ़ील्ड में पहले से चुना गया अस्थायी पासवर्ड टाइप करें। इस स्टेप के बाद, New Master Password टाइप करें। जब Continue बटन पर क्लिक किया जाता है तो New Master Password हैश (या एन्क्रिप्ट) हो जाता है।

इस पॉइंट पर, पासवर्ड सफलतापूर्वक रीसेट हो गया है, और नए पासवर्ड का हैश वर्शन अब कॉन्फ़िगरेशन फ़ाइल में दिखाई देता है।

यह भी देखें

Odoo डेटाबेस सुरक्षा के बारे में ज़्यादा जानकारी के लिए, यह दस्तावेज़ देखें: डेटाबेस मैनेजर सुरक्षा।

समर्थित ब्राउज़र¶

Odoo निम्नलिखित ब्राउज़रों के नवीनतम वर्शन को सपोर्ट करता है।

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: एक ही PostgreSQL डेटाबेस का इस्तेमाल करने के लिए कई Odoo इंस्टॉलेशन होना, या दोनों सॉफ़्टवेयर को ज़्यादा कंप्यूटिंग रिसोर्स प्रदान करना।
2: तकनीकी रूप से socat जैसे टूल का इस्तेमाल नेटवर्क में UNIX सॉकेट्स को प्रॉक्सी करने के लिए किया जा सकता है, लेकिन यह ज़्यादातर उस सॉफ़्टवेयर के लिए है जिसका इस्तेमाल सिर्फ़ UNIX सॉकेट्स पर किया जा सकता है
3: या सिर्फ़ इंटरनल पैकेट-स्विच्ड नेटवर्क पर एक्सेसिबल हो, लेकिन इसके लिए सुरक्षित स्विच, ARP स्पूफ़िंग के खिलाफ़ सुरक्षा की आवश्यकता होती है और WiFi का उपयोग रोकता है। सुरक्षित पैकेट-स्विच्ड नेटवर्क पर भी, HTTPS पर डिप्लॉयमेंट की सिफ़ारिश की जाती है, और संभावित लागत कम होती है क्योंकि "सेल्फ़-साइन" सर्टिफ़िकेट को नियंत्रित एनवायरमेंट पर इंटरनेट की तुलना में डिप्लॉय करना आसान होता है।