أعدادات النظام¶

يصف هذا المستند الخطوات الأساسية لإعداد Odoo في مرحلة الإنتاج أو على خادم متصل بالإنترنت. ويتبع installation، وهو ليس ضروريًا بشكل عام لأنظمة التطوير غير المكشوفة على الإنترنت.

تحذير

إذا كنت تقوم بإعداد خادم عام، فتأكد من مراجعة توصياتنا :المرجع:`الأمن`!

com.dbfilter¶

Odoo هو نظام متعدد المستأجرين: قد يعمل نظام Odoo واحد ويخدم عددًا من مثيلات قاعدة البيانات. كما أنه قابل للتخصيص بشكل كبير، مع التخصيصات (بدءًا من الوحدات التي يتم تحميلها) اعتمادًا على "قاعدة البيانات الحالية".

هذه ليست مشكلة عند العمل مع الواجهة الخلفية (عميل الويب) كمستخدم شركة مسجل الدخول: يمكن تحديد قاعدة البيانات عند تسجيل الدخول، وتحميل التخصيصات بعد ذلك.

ومع ذلك، فهذه مشكلة بالنسبة للمستخدمين غير المسجلين (البوابة، موقع الويب) وغير المرتبطين بقاعدة بيانات: يحتاج Odoo إلى معرفة قاعدة البيانات التي يجب استخدامها لتحميل صفحة موقع الويب أو إجراء العملية. إذا لم يتم استخدام الإيجار المتعدد، فهذه ليست مشكلة، فهناك قاعدة بيانات واحدة فقط يمكن استخدامها، ولكن إذا كانت هناك قواعد بيانات متعددة يمكن الوصول إليها، يحتاج Odoo إلى قاعدة لمعرفة القاعدة التي يجب أن يستخدمها.

هذا هو أحد أغراض db-filter فهو يحدد كيفية اختيار قاعدة البيانات بناءً على اسم المضيف (المجال) المطلوب. القيمة عبارة عن تعبير عادي، ومن المحتمل أن تتضمن اسم المضيف الذي تم إدخاله ديناميكيًا (%h) أو المجال الفرعي الأول (%d) الذي يتم من خلاله الوصول إلى النظام.

بالنسبة للخوادم التي تستضيف قواعد بيانات متعددة في الإنتاج، خاصة إذا تم استخدام موقع الويب، يجب تعيين dbfilter، وإلا فلن يعمل عدد من الميزات بشكل صحيح.

عينات التكوين¶

إظهار قواعد البيانات ذات الأسماء التي تبدأ بـ "mycompany" فقط

[options]
dbfilter = ^mycompany.*$

إظهار قواعد البيانات المطابقة للنطاق الفرعي الأول بعد www فقط: على سبيل المثال، سيتم عرض قاعدة البيانات "mycompany" إذا تم إرسال الطلب الوارد إلى www.mycompany.com أو mycompany.co.uk ``، ولكن ليس لـ ``www2.mycompany.com أو helpdesk.mycompany.com.

[options]
dbfilter = ^%d$

ملاحظة

يعد إعداد عامل تصفية قاعدة البيانات المناسب جزءًا مهمًا من تأمين عملية النشر الخاصة بك. بمجرد أن تعمل بشكل صحيح وتتطابق فقط مع قاعدة بيانات واحدة لكل اسم مضيف، يوصى بشدة بحظر الوصول إلى شاشات مدير قاعدة البيانات، واستخدام معلمة بدء التشغيل --no-database-list لمنع إدراج قواعد البيانات الخاصة بك، ومنع الوصول إلى شاشات إدارة قاعدة البيانات. انظر أيضًا الأمان.

PostgreSQL¶

افتراضيًا، يسمح PostgreSQL فقط بالاتصال عبر مآخذ توصيل UNIX واتصالات الاسترجاع (من "localhost"، وهو نفس الجهاز الذي تم تثبيت خادم PostgreSQL عليه).

يعد مقبس UNIX جيدًا إذا كنت تريد تنفيذ Odoo وPostgreSQL على نفس الجهاز، وهو الافتراضي عند عدم توفير مضيف، ولكن إذا كنت تريد تنفيذ Odoo وPostgreSQL على أجهزة مختلفة [#different-machines] _ فسوف تحتاج إلى الاستماع إلى واجهات الشبكة 2، إما:

اقبل فقط اتصالات الاسترجاع و"استخدم نفق SSH"_ بين الجهاز الذي يعمل عليه Odoo والجهاز الذي يعمل عليه PostgreSQL، ثم قم بتكوين Odoo للاتصال بنهاية النفق الخاص به
اقبل الاتصالات بالجهاز الذي تم تثبيت Odoo عليه، ربما عبر SSL (راجع إعدادات اتصال PostgreSQL للحصول على التفاصيل)، ثم قم بتكوين Odoo للاتصال عبر الشبكة

عينة التكوين¶

السماح باتصال TCP على المضيف المحلي
السماح باتصال TCP من شبكة 192.168.1.x

في /etc/postgresql/<إصدار POSTGRESQL الخاص بك>/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/<إصدار POSTGRESQL>/main/postgresql.conf:

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

تكوين أودو¶

يتصل Odoo تلقائيًا بـ postgres محلي عبر مقبس UNIX عبر المنفذ 5432. ويمكن تجاوز ذلك باستخدام قاعدة البيانات عندما لا يكون نشر Postgres محليًا و/أو لا يستخدم إعدادات التثبيت الافتراضية.

سيقوم المثبتات المعبأة تلقائيًا بإنشاء مستخدم جديد (odoo) وتعيينه كمستخدم لقاعدة البيانات.

شاشات إدارة قاعدة البيانات محمية بواسطة الإعداد admin_passwd. لا يمكن ضبط هذا الإعداد إلا باستخدام ملفات التكوين، ويتم فحصه ببساطة قبل إجراء تعديلات على قاعدة البيانات. ويجب ضبطها على قيمة يتم إنشاؤها عشوائيًا لضمان عدم تمكن الجهات الخارجية من استخدام هذه الواجهة.
تستخدم جميع عمليات قاعدة البيانات قاعدة البيانات، بما في ذلك شاشة إدارة قاعدة البيانات. لكي تعمل شاشة إدارة قاعدة البيانات، يتطلب الأمر أن يكون لدى مستخدم PostgreSQL الحق في إنشاء قاعدة بيانات.
يمكن للمستخدمين دائمًا إسقاط قواعد البيانات التي يمتلكونها. لكي تصبح شاشة إدارة قاعدة البيانات غير فعالة تمامًا، يجب إنشاء مستخدم PostgreSQL باستخدام no-createdb ويجب أن تكون قاعدة البيانات مملوكة لمستخدم PostgreSQL مختلف.

تحذير
يجب ألا يكون مستخدم PostgreSQL مستخدمًا متميزًا

عينة التكوين¶

اتصل بخادم PostgreSQL على 192.168.1.2
المنفذ 5432
باستخدام حساب مستخدم "odoo"،
مع "pwd" ككلمة مرور
تصفية قاعدة بيانات فقط باسم يبدأ بـ "mycompany"

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

SSL بين Odoo وPostgreSQL¶

منذ الإصدار 11.0 من Odoo، يمكنك فرض اتصال SSL بين Odoo وPostgreSQL. في Odoo، يتحكم db_sslmode في أمان SSL للاتصال مع القيمة المختارة من "disable" أو "allow" أو "prefer" أو "require" أو "verify-ca" أو "verify-full".

PostgreSQL Doc

خادم مدمج¶

يتضمن Odoo خوادم HTTP مدمجة، تستخدم إما تعدد العمليات أو المعالجة المتعددة.

بالنسبة للاستخدام الإنتاجي، يوصى باستخدام خادم المعالجة المتعددة لأنه يزيد من الاستقرار، ويستخدم موارد الحوسبة بشكل أفضل إلى حد ما ويمكن مراقبته بشكل أفضل وتقييد الموارد.

Multiprocessing is enabled by configuring :option: a non-zero number of worker processes odoo-bin --workers, the number of workers should be based on the number of cores in the machine (possibly with some room for cron workers depending on how much cron work is predicted)
يمكن تكوين حدود العمال بناءً على تكوين الأجهزة لتجنب استنفاد الموارد

تحذير

وضع المعالجة المتعددة غير متوفر حاليًا على نظام التشغيل Windows

حساب عدد العمال¶

القاعدة الأساسية : (#CPU*2)+1
يحتاج عمال Cron إلى وحدة المعالجة المركزية
عامل واحد ~= 6 مستخدمين متزامنين

حساب حجم الذاكرة¶

نحن نعتبر أن 20% من الطلبات هي طلبات ثقيلة، في حين أن 80% هي طلبات أبسط
عامل ثقيل، عندما تكون جميع الحقول المحسوبة مصممة بشكل جيد، تكون طلبات SQL مصممة بشكل جيد، ... من المقدر أن تستهلك حوالي 1 جيجابايت من ذاكرة الوصول العشوائي
من المقدر أن يستهلك العامل الأخف، في نفس السيناريو، حوالي 150 ميجابايت من ذاكرة الوصول العشوائي

ذاكرة الوصول العشوائي المطلوبة = #العامل * ( (نسبة_العامل_الخفيف * تقدير_رام_العامل_الخفيف) + (نسبة_العامل_الثقيل * تقدير_رام_العامل_الثقيل))

دردشة مباشرة¶

في المعالجة المتعددة، يتم تشغيل عامل LiveChat مخصص تلقائيًا والاستماع إليه على odoo-bin --gevent-port لكن العميل لن يتصل به.

بدلاً من ذلك، يجب أن يكون لديك وكيل يعيد توجيه طلباته التي يبدأ عنوان URL الخاص بها بـ /websocket/ إلى منفذ gevent. يجب إرسال الطلب الآخر إلى odoo-bin --http-port.

ولتحقيق هذا الأمر، ستحتاج إلى نشر وكيل عكسي أمام Odoo، مثل nginx أو apache. عند القيام بذلك، ستحتاج إلى إعادة توجيه المزيد من رؤوس http إلى Odoo، وتنشيط proxy_mode في تكوين Odoo ليقوم Odoo بقراءة تلك الرؤوس.

عينة التكوين¶

خادم مع 4 وحدة المعالجة المركزية، 8 الموضوع
60 مستخدمًا متزامنًا
60 مستخدمًا / 6 = 10 <- العدد النظري للعامل المطلوب
(4 * 2) + 1 = 9 <- الحد الأقصى النظري لعدد العمال
سوف نستخدم 8 عمال + 1 لكرون. سنستخدم أيضًا نظام مراقبة لقياس حمل وحدة المعالجة المركزية والتحقق مما إذا كان يتراوح بين 7 و7.5.
ذاكرة الوصول العشوائي = 9 * ((0.8*150) + (0.2*1024)) ~= ذاكرة الوصول العشوائي 3Go لـ Odoo

[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 خلف وكيل عكسي
قم بإعداد مثال إنهاء Nginx لوكيل إنهاء SSL.
قم بإعداد البروكسي نفسه كمثال Nginx للبروكسي.
يجب أيضًا على وكيل إنهاء 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 $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;
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $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;
  }

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

Odoo كتطبيق WSGI¶

من الممكن أيضًا تثبيت Odoo كتطبيق WSGI قياسي. يوفر Odoo الأساس للبرنامج النصي لمشغل WSGI باسم odoo-wsgi.example.py. يجب تخصيص هذا البرنامج النصي (ربما بعد نسخه من دليل الإعداد) لتعيين التكوين بشكل صحيح مباشرةً في odoo.tools.config بدلاً من سطر الأوامر أو ملف التكوين.

ومع ذلك، سيكشف خادم WSGI فقط عن نقطة نهاية HTTP الرئيسية لعميل الويب وموقع الويب وواجهة برمجة تطبيقات خدمة الويب. نظرًا لأن Odoo لم يعد يتحكم في إنشاء العمال، فلا يمكنه إعداد عمال cron أو Livechat

عمال كرون¶

لتشغيل مهام cron لنشر Odoo كما يتطلب تطبيق WSGI

Odoo الكلاسيكي (يتم تشغيله عبر odoo-bin)
متصل بقاعدة البيانات حيث يجب تشغيل وظائف cron عبر odoo-bin
والتي لا ينبغي أن تتعرض للشبكة. للتأكد من عدم إمكانية الوصول إلى مشغلي cron عبر الشبكة، فمن الممكن تعطيل خادم HTTP المدمج بالكامل باستخدام odoo-bin --no-http` أو الإعداد http_enable = False في ملف التكوين

دردشة مباشرة¶

النظام الفرعي الثاني الإشكالي لعمليات نشر WSGI هو LiveChat: حيث تكون معظم اتصالات HTTP قصيرة نسبيًا وتحرر عملية العامل الخاصة بها بسرعة للطلب التالي، يتطلب LiveChat اتصالاً طويل الأمد لكل عميل من أجل تنفيذ إشعارات في الوقت الفعلي تقريبًا .

وهذا يتعارض مع نموذج العامل القائم على العملية، لأنه سيربط العمليات العاملة ويمنع المستخدمين الجدد من الوصول إلى النظام. ومع ذلك، فإن هذه الاتصالات طويلة الأمد لا تفعل سوى القليل جدًا وتظل في الغالب متوقفة في انتظار الإشعارات.

الحلول لدعم الدردشة المباشرة/الزخارف في تطبيق WSGI هي:

انشر إصدارًا مترابطة من Odoo (بدلاً من إصدار مسبق قائم على العملية) وأعد توجيه الطلبات فقط إلى عناوين URL التي تبدأ بـ /websocket/ إلى Odoo، هذا هو الأبسط ويمكن أن يتضاعف عنوان URL لـ websocket كمثيل cron .
انشر Odoo الذي حدث عبر odoo-gevent وطلبات الوكيل التي تبدأ بـ /websocket/ إلى منفذ gevent.

خدمة الملفات والمرفقات الثابتة¶

لتسهيل التطوير، يخدم Odoo مباشرة جميع الملفات الثابتة والمرفقات في وحداته. قد لا يكون هذا مثاليًا عندما يتعلق الأمر بالعروض، ويجب عمومًا تقديم الملفات الثابتة بواسطة خادم HTTP ثابت.

خدمة الملفات الثابتة¶

توجد ملفات Odoo الثابتة في مجلد static/ الخاص بكل وحدة، لذلك يمكن تقديم الملفات الثابتة عن طريق اعتراض جميع الطلبات إلى /MODULE/static/FILE، والبحث عن الوحدة الصحيحة (والملف) في مسارات الوظائف الإضافية المختلفة.

Example

لنفترض أنه تم تثبيت Odoo عبر حزم debian للمجتمع والمؤسسات و--addons-path <odoo-bin --addons-path>` هو ``'/usr/lib/python3/dist-packages/ أودو/الإضافات'''.

باستخدام تكوين NGINX (https) أعلاه، يجب إضافة كتلة الموقع التالية لخدمة الملفات الثابتة عبر NGINX.

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

# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
    root /usr/lib/python3/dist-packages/odoo/addons;
    try_files $uri @odoo;
    expires 24h;
}

Example

Say Odoo has been installed via the source. The two git repositories for Community and Enterprise have been cloned in /opt/odoo/community and /opt/odoo/enterprise respectively and '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

باستخدام تكوين NGINX (https) أعلاه، يجب إضافة كتلة الموقع التالية لخدمة الملفات الثابتة عبر NGINX.

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

# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
    root /opt/odoo;
    try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;
    expires 24h;
}

تحذير

يعتمد تكوين NGINX الفعلي الذي تحتاجه بشكل كبير على التثبيت الخاص بك. يسلط المقتطفان أعلاه الضوء على تكوينين محتملين فقط ولا يجوز استخدامهما كما هو.

مرفقات التقديم¶

المرفقات هي ملفات مخزنة في مخزن الملفات والتي يتم تنظيم الوصول إليها بواسطة Odoo. لا يمكن الوصول إليها مباشرة عبر خادم ويب ثابت لأن الوصول إليها يتطلب عمليات بحث متعددة في قاعدة البيانات لتحديد مكان تخزين الملفات وما إذا كان المستخدم الحالي يمكنه الوصول إليها أم لا.

Nevertheless, once the file has been located and the access rights verified by Odoo, it is a good idea to serve the file using the static web server instead of Odoo. For Odoo to delegate serving files to the static web server, the X-Sendfile (apache) or X-Accel (nginx) extensions must be enabled and configured on the static web server. Once it is set up, start Odoo with the CLI flag (this unique flag is used for both X-Sendfile and X-Accel).

ملاحظة

لا يتطلب ملحق X-Sendfile لـ Apache (وخوادم الويب المتوافقة) أي تكوين إضافي.
يتطلب ملحق X-Accel لـ NGINX **** التكوين الإضافي التالي:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
In case you don't know what is the path to your filestore, start Odoo with the option and navigate to the /web/filestore URL directly via Odoo (don't navigate to the URL via NGINX). This logs a warnings, the message contains the configuration you need.

حماية¶

بالنسبة للمبتدئين، ضع في اعتبارك أن تأمين نظام المعلومات هو عملية مستمرة، وليست عملية لمرة واحدة. في أي لحظة، ستكون آمنًا بقدر أضعف حلقة في بيئتك.

لذا يرجى عدم اعتبار هذا القسم بمثابة القائمة النهائية للإجراءات التي من شأنها منع جميع المشكلات الأمنية. الغرض منه فقط هو أن يكون ملخصًا للأشياء المهمة الأولى التي يجب عليك التأكد من تضمينها في خطة العمل الأمنية الخاصة بك. سيأتي الباقي من أفضل الممارسات الأمنية لنظام التشغيل والتوزيع الخاص بك، وأفضل الممارسات فيما يتعلق بالمستخدمين وكلمات المرور وإدارة التحكم في الوصول وما إلى ذلك.

عند نشر خادم متصل بالإنترنت، يرجى التأكد من مراعاة المواضيع التالية المتعلقة بالأمان:

قم دائمًا بتعيين كلمة مرور قوية للمسؤول المتميز، وتقييد الوصول إلى صفحات إدارة قاعدة البيانات بمجرد إعداد النظام. راجع :المرجع:`db_manager_security`.
اختر تسجيلات دخول فريدة وكلمات مرور قوية لجميع حسابات المسؤولين في جميع قواعد البيانات. لا تستخدم "المسؤول" لتسجيل الدخول. لا تستخدم عمليات تسجيل الدخول هذه للعمليات اليومية، فقط للتحكم/إدارة التثبيت. لا تستخدم أبدًا أي كلمات مرور افتراضية مثل admin/admin، حتى بالنسبة لقواعد بيانات الاختبار/التدريج.
لا لا تثبت البيانات التجريبية على الخوادم التي تواجه الإنترنت. تحتوي قواعد البيانات التي تحتوي على بيانات تجريبية على معلومات تسجيل الدخول وكلمات المرور الافتراضية التي يمكن استخدامها للدخول إلى أنظمتك والتسبب في مشاكل كبيرة، حتى في أنظمة التدريج/التطوير.
Use appropriate database filters to restrict the visibility of your databases according to the hostname. See com.dbfilter.You may also use to provide your own (comma-separated) list of available databases to filter from, instead of letting the system fetch them all from the database backend.
Once your db_name and db_filter are configured and only match a single database per hostname, you should set list_db configuration option to False, to prevent listing databases entirely, and to block access to the database management screens (this is also exposed as the command-line option)
Make sure the PostgreSQL user is not a super-user, and that your databases are owned by a different user. For example they could be owned by the postgres super-user if you are using a dedicated non-privileged db_user. See also تكوين أودو.
حافظ على تحديث عمليات التثبيت عن طريق تثبيت أحدث الإصدارات بانتظام، إما عبر GitHub أو عن طريق تنزيل أحدث إصدار من https://www.odoo.com/page/download أو http://nightly.odoo.com
قم بتكوين الخادم الخاص بك في وضع العمليات المتعددة مع الحدود المناسبة التي تتوافق مع استخدامك النموذجي (الذاكرة/وحدة المعالجة المركزية/المهلات). راجع أيضًا :المرجع:`builtin_server`.
Run Odoo behind a web server providing HTTPS termination with a valid SSL certificate, in order to prevent eavesdropping on cleartext communications. SSL certificates are cheap, and many free options exist. Configure the web proxy to limit the size of requests, set appropriate timeouts, and then enable the option. See also HTTPS.
إذا كنت بحاجة إلى السماح بوصول SSH عن بعد إلى خوادمك، فتأكد من تعيين كلمة مرور قوية لكل الحسابات **، وليس فقط الجذر. يوصى بشدة بتعطيل المصادقة المستندة إلى كلمة المرور بالكامل، والسماح فقط بمصادقة المفتاح العام. ضع في اعتبارك أيضًا تقييد الوصول عبر شبكة VPN، والسماح فقط بعناوين IP الموثوقة في جدار الحماية، و/أو تشغيل نظام كشف القوة الغاشمة مثل "fail2ban" أو ما يعادله.
فكر في تثبيت معدل مناسب لتحديد السعر على الخادم الوكيل أو جدار الحماية الخاص بك، لمنع هجمات القوة الغاشمة وهجمات رفض الخدمة. راجع أيضًا:المرجع:login_brute_force للتعرف على التدابير المحددة.

يوفر العديد من موفري الشبكات تخفيفًا تلقائيًا لهجمات رفض الخدمة الموزعة (DDOS)، ولكن غالبًا ما تكون هذه خدمة اختيارية، لذا يجب عليك التشاور معهم.
كلما أمكن، قم باستضافة مثيلاتك التجريبية/الاختبارية/التدريجية العامة على أجهزة مختلفة عن تلك الخاصة بالإنتاج. وتطبيق نفس الاحتياطات الأمنية المتبعة في الإنتاج.
إذا كان خادم Odoo العام لديك يتمتع بإمكانية الوصول إلى موارد أو خدمات الشبكة الداخلية الحساسة (على سبيل المثال عبر شبكة محلية ظاهرية خاصة)، فقم بتنفيذ قواعد جدار الحماية المناسبة لحماية تلك الموارد الداخلية. سيضمن ذلك عدم إمكانية استخدام خادم Odoo عن طريق الخطأ (أو نتيجة لإجراءات المستخدم الضارة) للوصول إلى تلك الموارد الداخلية أو تعطيلها. عادةً ما يمكن القيام بذلك عن طريق تطبيق قاعدة DENY الافتراضية الصادرة على جدار الحماية، وبعد ذلك فقط يتم السماح بشكل صريح بالوصول إلى الموارد الداخلية التي يحتاج خادم Odoo للوصول إليها. التحكم في الوصول إلى حركة مرور IP للنظام قد يكون مفيدًا أيضًا في تنفيذ التحكم في الوصول إلى الشبكة لكل عملية.
إذا كان خادم Odoo الخاص بك موجودًا خلف جدار حماية لتطبيق الويب، أو موازن التحميل، أو خدمة حماية DDoS شفافة (مثل CloudFlare) أو جهاز مشابه على مستوى الشبكة، فقد ترغب في تجنب الوصول المباشر إلى نظام Odoo. من الصعب عمومًا الحفاظ على سرية عناوين IP لنقطة النهاية لخوادم Odoo الخاصة بك. على سبيل المثال، يمكن أن تظهر في سجلات خادم الويب عند الاستعلام عن الأنظمة العامة، أو في رؤوس رسائل البريد الإلكتروني المرسلة من Odoo. في مثل هذه الحالة، قد ترغب في تكوين جدار الحماية الخاص بك بحيث لا يمكن الوصول إلى نقاط النهاية بشكل عام إلا من خلال عناوين IP المحددة لخدمة WAF أو موازن التحميل أو الوكيل. عادةً ما يحتفظ مقدمو الخدمات مثل CloudFlare بقائمة عامة بنطاقات عناوين IP الخاصة بهم لهذا الغرض.
إذا كنت تستضيف عدة عملاء، فاعزل بيانات وملفات العملاء عن بعضها البعض باستخدام الحاويات أو تقنيات "السجن" المناسبة.
قم بإعداد نسخ احتياطية يومية لقواعد البيانات وبيانات مخزن الملفات، وانسخها إلى خادم أرشفة عن بعد لا يمكن الوصول إليه من الخادم نفسه.

منع هجمات القوة الغاشمة¶

بالنسبة لعمليات النشر التي تواجه الإنترنت، تعد هجمات القوة الغاشمة على كلمات مرور المستخدم شائعة جدًا، ويجب عدم إهمال هذا التهديد بالنسبة لخوادم 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 =

يمكن استخدام هذا مع تعريف السجن لمنع عنوان IP المهاجم على HTTP(S).

إليك ما يمكن أن يبدو عليه حظر عنوان IP لمدة 15 دقيقة عند اكتشاف 10 محاولات تسجيل دخول فاشلة من نفس عنوان IP خلال دقيقة واحدة:

[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

أمن مدير قاعدة البيانات¶

تكوين أودو ذكر admin_passwd بشكل عابر.

يُستخدم هذا الإعداد على جميع شاشات إدارة قواعد البيانات (لإنشاء قواعد البيانات أو حذفها أو تفريغها أو استعادتها).

إذا كان لا بد من عدم إمكانية الوصول إلى شاشات الإدارة على الإطلاق، فيجب عليك تعيين خيار التكوين list_db على خطأ، لمنع الوصول إلى جميع شاشات اختيار قاعدة البيانات وإدارتها.

تحذير

يوصى بشدة بتعطيل مدير قاعدة البيانات لأي نظام متصل بالإنترنت! والمقصود منها هو أن تكون أداة تطوير/عرض توضيحي، لتسهيل إنشاء قواعد البيانات وإدارتها بسرعة. إنه غير مصمم للاستخدام في الإنتاج، وقد يعرض ميزات خطيرة للمهاجمين. كما أنه غير مصمم للتعامل مع قواعد البيانات الكبيرة، وقد يؤدي إلى حدود للذاكرة.

في أنظمة الإنتاج، يجب دائمًا تنفيذ عمليات إدارة قاعدة البيانات بواسطة مسؤول النظام، بما في ذلك توفير قواعد بيانات جديدة ونسخ احتياطية آلية.

تأكد من إعداد معلمة db_name مناسبة (واختياريًا، db_filter أيضًا) حتى يتمكن النظام من تحديد قاعدة البيانات الهدف لكل طلب، وإلا فسيتم حظر المستخدمين لأنه لن يُسمح لهم بالاختيار قاعدة البيانات نفسها.

إذا كان يجب الوصول إلى شاشات الإدارة فقط من مجموعة محددة من الأجهزة، فاستخدم ميزات الخادم الوكيل لمنع الوصول إلى جميع المسارات التي تبدأ بـ /web/database باستثناء (ربما) /web/database/selector الذي يعرض شاشة اختيار قاعدة البيانات.

إذا كان يجب ترك شاشة إدارة قاعدة البيانات قابلة للوصول، فيجب تغيير الإعداد admin_passwd من الإعداد الافتراضي admin: يتم التحقق من كلمة المرور هذه قبل السماح بعمليات تغيير قاعدة البيانات.

يجب أن يتم تخزينها بشكل آمن، ويجب أن يتم إنشاؤها بشكل عشوائي على سبيل المثال.

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

والتي ستنشئ سلسلة قابلة للطباعة مكونة من 32 حرفًا.

المتصفحات المدعومة¶

يدعم Odoo جميع متصفحات سطح المكتب والجوال الرئيسية المتوفرة في السوق، طالما أنها مدعومة من قبل ناشريها.

فيما يلي المتصفحات المدعومة:

جوجل كروم
موزيلا فايرفوكس
مايكروسوفت ايدج
أبل سفاري

تحذير

يرجى التأكد من تحديث متصفحك وما زال مدعومًا من قبل ناشره قبل تقديم تقرير بالأخطاء.

ملاحظة

منذ الإصدار 13.0 من Odoo، أصبح ES6 مدعومًا. ولذلك، تم إسقاط دعم IE.

1: لإجراء عمليات تثبيت متعددة لـ Odoo، استخدم نفس قاعدة بيانات PostgreSQL، أو لتوفير المزيد من موارد الحوسبة لكلا البرنامجين.
2: من الناحية الفنية، يمكن استخدام أداة مثل socat لتوكيل مآخذ توصيل UNIX عبر الشبكات، ولكن هذا مخصص في الغالب للبرامج التي لا يمكن استخدامها إلا عبر مآخذ توصيل UNIX
3: أو يمكن الوصول إليها فقط عبر شبكة داخلية لتبديل الحزم، ولكن ذلك يتطلب محولات آمنة وحماية ضد ``انتحال ARP`_ ويمنع استخدام WiFi. وحتى عبر شبكات تبديل الحزم الآمنة، يوصى بالنشر عبر HTTPS، ويتم خفض التكاليف المحتملة حيث يسهل نشر الشهادات "الموقعة ذاتيًا" في بيئة خاضعة للتحكم مقارنةً عبر الإنترنت.