🥇RHEL 8 बीटा कार्यशाळा: कार्यरत वेब अॅप्लिकेशन्स एकत्र करणे

RHEL 8 बीटा विकासकांना अनेक नवीन वैशिष्ट्ये ऑफर करतो, ज्याची सूची पृष्ठे घेऊ शकते, तथापि, नवीन गोष्टी शिकणे नेहमीच चांगले असते, म्हणून खाली आम्ही Red Hat Enterprise Linux 8 Beta वर आधारित अनुप्रयोग पायाभूत सुविधा तयार करण्यावर कार्यशाळा देऊ करतो.

Django आणि PostgreSQL चे संयोजन, अॅप्लिकेशन्स तयार करण्यासाठी एक सामान्य कॉम्बिनेशन, आणि RHEL 8 बीटा त्यांच्यासोबत काम करण्यासाठी कॉन्फिगर करू या, विकासकांमध्ये एक लोकप्रिय प्रोग्रामिंग भाषा पायथॉन घेऊ. मग आम्ही आणखी काही (अवर्गीकृत) घटक जोडू.

चाचणी वातावरण बदलेल, कारण ऑटोमेशनच्या शक्यतांचा शोध घेणे, कंटेनरसह कार्य करणे आणि एकाधिक सर्व्हरसह वातावरणाचा प्रयत्न करणे मनोरंजक आहे. नवीन प्रकल्पासह प्रारंभ करण्यासाठी, आपण हाताने एक लहान, साधा प्रोटोटाइप तयार करून प्रारंभ करू शकता जेणेकरुन आपण नेमके काय घडणे आवश्यक आहे आणि ते कसे संवाद साधते ते पाहू शकता आणि नंतर स्वयंचलित आणि अधिक जटिल कॉन्फिगरेशन तयार करण्यासाठी पुढे जा. आज आपण अशा प्रोटोटाइपच्या निर्मितीबद्दल बोलत आहोत.

चला RHEL 8 बीटा VM प्रतिमा तैनात करून सुरुवात करूया. तुम्ही सुरवातीपासून व्हर्च्युअल मशीन स्थापित करू शकता, किंवा तुमच्या बीटा सबस्क्रिप्शनसह उपलब्ध KVM अतिथी प्रतिमा वापरू शकता. अतिथी प्रतिमा वापरताना, तुम्हाला व्हर्च्युअल सीडी कॉन्फिगर करावी लागेल ज्यामध्ये मेटाडेटा आणि क्लाउड इनिटलायझेशन (क्लाउड-इनिट) साठी वापरकर्ता डेटा असेल. तुम्हाला डिस्क स्ट्रक्चर किंवा उपलब्ध पॅकेजेससह विशेष काही करण्याची आवश्यकता नाही; कोणतीही कॉन्फिगरेशन करेल.

चला संपूर्ण प्रक्रियेवर बारकाईने नजर टाकूया.

Django स्थापित करत आहे

Django च्या नवीनतम आवृत्तीसह, तुम्हाला Python 3.5 किंवा नंतरचे आभासी वातावरण (virtualenv) आवश्यक असेल. बीटा नोट्समध्ये तुम्ही पाहू शकता की पायथन 3.6 उपलब्ध आहे, हे खरंच आहे का ते तपासूया:

[cloud-user@8beta1 ~]$ python
-bash: python: command not found
[cloud-user@8beta1 ~]$ python3
-bash: python3: command not found

Red Hat सक्रियपणे RHEL मध्ये Python ला सिस्टीम टूलकिट म्हणून वापरते, मग याचा परिणाम का होतो?

वस्तुस्थिती अशी आहे की अनेक पायथन विकसक अजूनही पायथन 2 वरून पायथन 2 मध्ये संक्रमणाचा विचार करत आहेत, तर पायथन 3 स्वतः सक्रिय विकासाधीन आहे आणि अधिकाधिक नवीन आवृत्त्या सतत दिसत आहेत. म्हणून, पायथनच्या विविध नवीन आवृत्त्यांमध्ये वापरकर्त्यांना प्रवेश प्रदान करताना स्थिर प्रणाली साधनांची आवश्यकता पूर्ण करण्यासाठी, सिस्टम पायथनला नवीन पॅकेजमध्ये हलविण्यात आले आणि Python 2.7 आणि 3.6 दोन्ही स्थापित करण्याची क्षमता प्रदान केली. बदल आणि ते का केले गेले याबद्दल अधिक माहिती मधील प्रकाशनात आढळू शकते लँगडन व्हाईटचा ब्लॉग (लॅंगडन व्हाइट).

तर, पायथनवर काम करण्यासाठी, तुम्हाला फक्त दोन पॅकेजेस स्थापित करणे आवश्यक आहे, ज्यामध्ये python3-pip अवलंबित्व म्हणून समाविष्ट आहे.

sudo yum install python36 python3-virtualenv

लॅंगडनच्या सूचनेनुसार डायरेक्ट मॉड्यूल कॉल्स का वापरू नयेत आणि pip3 इंस्टॉल का करू नये? आगामी ऑटोमेशन लक्षात घेऊन, हे ज्ञात आहे की Ansible ला चालण्यासाठी pip स्थापित करणे आवश्यक आहे, कारण pip मॉड्यूल कस्टम pip एक्झिक्युटेबलसह virtualenvs ला समर्थन देत नाही.

तुमच्या विल्हेवाटीवर कार्यरत python3 इंटरप्रिटरसह, तुम्ही Django इंस्टॉलेशन प्रक्रिया सुरू ठेवू शकता आणि आमच्या इतर घटकांसह एक कार्यरत प्रणाली देखील ठेवू शकता. इंटरनेटवर अनेक अंमलबजावणी पर्याय उपलब्ध आहेत. येथे एक आवृत्ती सादर केली आहे, परंतु वापरकर्ते त्यांच्या स्वतःच्या प्रक्रिया वापरू शकतात.

आम्ही Yum वापरून RHEL 8 मध्ये उपलब्ध PostgreSQL आणि Nginx आवृत्त्या बाय डीफॉल्ट स्थापित करू.

sudo yum install nginx postgresql-server

PostgreSQL ला psycopg2 ची आवश्यकता असेल, परंतु ते फक्त virtualenv वातावरणात उपलब्ध असणे आवश्यक आहे, म्हणून आम्ही ते Django आणि Gunicorn सोबत pip3 वापरून स्थापित करू. परंतु प्रथम आपल्याला virtualenv सेट करणे आवश्यक आहे.

जॅंगो प्रोजेक्ट्स स्थापित करण्यासाठी योग्य जागा निवडण्याच्या विषयावर नेहमीच बरेच वादविवाद होतात, परंतु जेव्हा शंका असेल तेव्हा आपण नेहमी लिनक्स फाइलसिस्टम हायरार्की स्टँडर्डकडे वळू शकता. विशेषत:, FHS म्हणते की /srv चा वापर यासाठी केला जातो: "होस्ट-विशिष्ट डेटा संग्रहित करणे—सिस्टम तयार करत असलेला डेटा, जसे की वेब सर्व्हर डेटा आणि स्क्रिप्ट्स, FTP सर्व्हरवर संग्रहित डेटा आणि सिस्टम रेपॉजिटरीज नियंत्रित करणे." आवृत्त्या (FHS मध्ये दिसतात. -2.3 2004)."

हे आमचे प्रकरण आहे, म्हणून आम्ही आम्हाला आवश्यक असलेली प्रत्येक गोष्ट /srv मध्ये ठेवतो, जी आमच्या अनुप्रयोग वापरकर्त्याच्या मालकीची आहे (क्लाउड-वापरकर्ता).

sudo mkdir /srv/djangoapp
sudo chown cloud-user:cloud-user /srv/djangoapp
cd /srv/djangoapp
virtualenv django
source django/bin/activate
pip3 install django gunicorn psycopg2
./django-admin startproject djangoapp /srv/djangoapp

PostgreSQL आणि Django सेट करणे सोपे आहे: डेटाबेस तयार करा, वापरकर्ता तयार करा, परवानग्या कॉन्फिगर करा. सुरुवातीला PostgreSQL स्थापित करताना एक गोष्ट लक्षात ठेवली पाहिजे ती म्हणजे postgresql-setup स्क्रिप्ट जी postgresql-server पॅकेजसह स्थापित केली जाते. ही स्क्रिप्ट तुम्हाला डेटाबेस क्लस्टर अॅडमिनिस्ट्रेशनशी संबंधित मूलभूत कार्ये करण्यास मदत करते, जसे की क्लस्टर इनिशिएलायझेशन किंवा अपग्रेड प्रक्रिया. RHEL प्रणालीवर नवीन PostgreSQL उदाहरण कॉन्फिगर करण्यासाठी, आम्हाला कमांड चालवावी लागेल:

sudo /usr/bin/postgresql-setup -initdb

त्यानंतर तुम्ही systemd वापरून PostgreSQL सुरू करू शकता, डेटाबेस तयार करू शकता आणि Django मध्ये प्रोजेक्ट सेट करू शकता. अॅप्लिकेशन वापरकर्त्यासाठी पासवर्ड स्टोरेज कॉन्फिगर करण्यासाठी क्लायंट ऑथेंटिकेशन कॉन्फिगरेशन फाइलमध्ये (सामान्यत: pg_hba.conf) बदल केल्यानंतर PostgreSQL रीस्टार्ट करण्याचे लक्षात ठेवा. तुम्हाला इतर अडचणी आल्यास, pg_hba.conf फाइलमधील IPv4 आणि IPv6 सेटिंग्ज बदलण्याची खात्री करा.

systemctl enable -now postgresql

sudo -u postgres psql
postgres=# create database djangoapp;
postgres=# create user djangouser with password 'qwer4321';
postgres=# alter role djangouser set client_encoding to 'utf8';
postgres=# alter role djangouser set default_transaction_isolation to 'read committed';
postgres=# alter role djangouser set timezone to 'utc';
postgres=# grant all on DATABASE djangoapp to djangouser;
postgres=# q

फाइल /var/lib/pgsql/data/pg_hba.conf मध्ये:

# IPv4 local connections:
host    all        all 0.0.0.0/0                md5
# IPv6 local connections:
host    all        all ::1/128                 md5

फाइल /srv/djangoapp/settings.py मध्ये:

# Database
DATABASES = {
   'default': {
       'ENGINE': 'django.db.backends.postgresql_psycopg2',
       'NAME': '{{ db_name }}',
       'USER': '{{ db_user }}',
       'PASSWORD': '{{ db_password }}',
       'HOST': '{{ db_host }}',
   }
}

प्रकल्पातील settings.py फाइल कॉन्फिगर केल्यानंतर आणि डेटाबेस कॉन्फिगरेशन सेट केल्यानंतर, सर्वकाही कार्य करत असल्याची खात्री करण्यासाठी तुम्ही डेव्हलपमेंट सर्व्हर सुरू करू शकता. डेव्हलपमेंट सर्व्हर सुरू केल्यानंतर, डेटाबेसशी कनेक्शन तपासण्यासाठी प्रशासक वापरकर्ता तयार करणे चांगली कल्पना आहे.

./manage.py runserver 0.0.0.0:8000
./manage.py createsuperuser

WSGI? वाई?

डेव्हलपमेंट सर्व्हर चाचणीसाठी उपयुक्त आहे, परंतु अनुप्रयोग चालविण्यासाठी तुम्हाला वेब सर्व्हर गेटवे इंटरफेस (WSGI) साठी योग्य सर्व्हर आणि प्रॉक्सी कॉन्फिगर करणे आवश्यक आहे. अनेक सामान्य संयोजने आहेत, उदाहरणार्थ, uWSGI सह Apache HTTPD किंवा Gunicorn सह Nginx.

वेब सर्व्हर गेटवे इंटरफेसचे काम वेब सर्व्हरकडून पायथन वेब फ्रेमवर्कवर विनंत्या अग्रेषित करणे आहे. डब्ल्यूएसजीआय हे भयंकर भूतकाळातील एक अवशेष आहे जेव्हा सीजीआय इंजिन आजूबाजूला होते आणि आज डब्ल्यूएसजीआय हे डी फॅक्टो मानक आहे, वेब सर्व्हर किंवा पायथन फ्रेमवर्क वापरल्याशिवाय. परंतु त्याचा व्यापक वापर असूनही, या फ्रेमवर्कसह कार्य करताना अजूनही अनेक बारकावे आणि अनेक पर्याय आहेत. या प्रकरणात, आम्ही सॉकेटद्वारे गुनिकॉर्न आणि एनजीनक्स यांच्यात परस्परसंवाद स्थापित करण्याचा प्रयत्न करू.

हे दोन्ही घटक एकाच सर्व्हरवर स्थापित केलेले असल्याने, नेटवर्क सॉकेटऐवजी UNIX सॉकेट वापरण्याचा प्रयत्न करूया. संप्रेषणासाठी कोणत्याही परिस्थितीत सॉकेटची आवश्यकता असल्याने, चला आणखी एक पाऊल टाकण्याचा प्रयत्न करूया आणि सिस्टमड द्वारे गुनिकॉर्नसाठी सॉकेट सक्रियकरण कॉन्फिगर करूया.

सॉकेट सक्रिय सेवा तयार करण्याची प्रक्रिया अगदी सोपी आहे. प्रथम, एक युनिट फाइल तयार केली जाते ज्यामध्ये UNIX सॉकेट ज्या बिंदूवर तयार केले जाईल त्या बिंदूकडे निर्देश करणारे ListenStream निर्देश असतात, त्यानंतर सेवेसाठी एक युनिट फाइल ज्यामध्ये आवश्यक निर्देश सॉकेट युनिट फाइलकडे निर्देशित करेल. त्यानंतर, सर्व्हिस युनिट फाइलमध्ये, व्हर्च्युअल वातावरणातून गुनिकॉर्नला कॉल करणे आणि UNIX सॉकेट आणि जॅंगो ऍप्लिकेशनसाठी WSGI बंधनकारक तयार करणे बाकी आहे.

येथे युनिट फाइल्सची काही उदाहरणे आहेत जी तुम्ही आधार म्हणून वापरू शकता. प्रथम आम्ही सॉकेट सेट करतो.

[Unit]
Description=Gunicorn WSGI socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

आता तुम्हाला गुनिकॉर्न डिमन कॉन्फिगर करणे आवश्यक आहे.

[Unit]
Description=Gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=cloud-user
Group=cloud-user
WorkingDirectory=/srv/djangoapp

ExecStart=/srv/djangoapp/django/bin/gunicorn 
         —access-logfile - 
         —workers 3 
         —bind unix:gunicorn.sock djangoapp.wsgi

[Install]
WantedBy=multi-user.target

Nginx साठी, प्रॉक्सी कॉन्फिगरेशन फायली तयार करणे आणि आपण वापरत असल्यास स्थिर सामग्री संचयित करण्यासाठी निर्देशिका सेट करणे ही एक साधी बाब आहे. RHEL मध्ये, Nginx कॉन्फिगरेशन फाइल्स /etc/nginx/conf.d मध्ये स्थित आहेत. तुम्ही खालील उदाहरण /etc/nginx/conf.d/default.conf फाइलमध्ये कॉपी करू शकता आणि सेवा सुरू करू शकता. तुमच्या होस्ट नावाशी जुळण्यासाठी सर्व्हर_नाव सेट केल्याचे सुनिश्चित करा.

server {
   listen 80;
   server_name 8beta1.example.com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /srv/djangoapp;
   }

   location / {
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_pass http://unix:/run/gunicorn.sock;
   }
}

Systemd वापरून Gunicorn सॉकेट आणि Nginx सुरू करा आणि तुम्ही चाचणी सुरू करण्यासाठी तयार आहात.

खराब गेटवे त्रुटी?

आपण आपल्या ब्राउझरमध्ये पत्ता प्रविष्ट केल्यास, आपल्याला बहुधा 502 खराब गेटवे त्रुटी प्राप्त होईल. हे चुकीच्या पद्धतीने कॉन्फिगर केलेल्या UNIX सॉकेट परवानग्यांमुळे होऊ शकते, किंवा ते SELinux मधील प्रवेश नियंत्रणाशी संबंधित अधिक जटिल समस्यांमुळे असू शकते.

nginx त्रुटी लॉगमध्ये आपण यासारखी एक ओळ पाहू शकता:

2018/12/18 15:38:03 [crit] 12734#0: *3 connect() to unix:/run/gunicorn.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.122.1, server: 8beta1.example.com, request: "GET / HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/", host: "8beta1.example.com"

जर आपण गनिकॉर्नची थेट चाचणी केली तर आपल्याला रिकामे उत्तर मिळेल.

curl —unix-socket /run/gunicorn.sock 8beta1.example.com

हे का घडते ते शोधूया. तुम्ही लॉग उघडल्यास, तुम्हाला बहुधा समस्या SELinux शी संबंधित असल्याचे दिसेल. आम्ही एक डिमन चालवत आहोत ज्यासाठी कोणतेही धोरण तयार केलेले नाही, ते init_t म्हणून चिन्हांकित केले आहे. चला या सिद्धांताची प्रत्यक्ष व्यवहारात चाचणी करूया.

sudo setenforce 0

या सर्वांमुळे टीका आणि रक्ताचे अश्रू होऊ शकतात, परंतु हे फक्त प्रोटोटाइप डीबग करत आहे. ही समस्या आहे याची खात्री करण्यासाठी चेक अक्षम करूया, त्यानंतर आम्ही सर्वकाही त्याच्या जागी परत करू.

ब्राउझरमध्ये पृष्ठ रीफ्रेश करून किंवा आमची कर्ल कमांड पुन्हा चालवून, तुम्ही जॅंगो चाचणी पृष्ठ पाहू शकता.

म्हणून, सर्वकाही कार्य करते याची खात्री करून घेतल्यानंतर आणि परवानगीच्या समस्या नाहीत, आम्ही SELinux पुन्हा सक्षम करतो.

sudo setenforce 1

मी येथे sepolgen सह audit2allow किंवा अलर्ट-आधारित धोरणे तयार करण्याबद्दल बोलणार नाही, कारण याक्षणी कोणतेही वास्तविक Django अनुप्रयोग नाही, त्यामुळे Gunicorn ला काय ऍक्सेस करायचे आहे आणि त्याला काय ऍक्सेस नाकारायचा आहे याचा पूर्ण नकाशा नाही. म्हणून, सिस्टीमचे संरक्षण करण्यासाठी SELinux चालू ठेवणे आवश्यक आहे, त्याचवेळी ऍप्लिकेशनला चालवण्यास आणि ऑडिट लॉगमध्ये संदेश सोडण्याची परवानगी देणे आवश्यक आहे जेणेकरुन वास्तविक धोरण त्यांच्यापासून तयार केले जाऊ शकेल.

परवानगी देणारी डोमेन निर्दिष्ट करत आहे

प्रत्येकाने SELinux मधील अनुमत डोमेनबद्दल ऐकले नाही, परंतु ते काही नवीन नाहीत. अनेकांनी नकळतही त्यांच्यासोबत काम केले. ऑडिट मेसेजवर आधारित पॉलिसी तयार केली जाते, तेव्हा तयार केलेली पॉलिसी निराकरण केलेल्या डोमेनचे प्रतिनिधित्व करते. चला एक साधी परवानगी धोरण तयार करण्याचा प्रयत्न करूया.

Gunicorn साठी एक विशिष्ट अनुमत डोमेन तयार करण्यासाठी, तुम्हाला काही प्रकारचे धोरण आवश्यक आहे आणि तुम्हाला योग्य फायली चिन्हांकित करणे देखील आवश्यक आहे. याव्यतिरिक्त, नवीन धोरणे तयार करण्यासाठी साधने आवश्यक आहेत.

sudo yum install selinux-policy-devel

अनुमत डोमेन यंत्रणा समस्या ओळखण्यासाठी एक उत्तम साधन आहे, विशेषत: जेव्हा सानुकूल ऍप्लिकेशन किंवा ऍप्लिकेशन्स जे आधीपासून तयार केलेल्या धोरणांशिवाय पाठवले जातात तेव्हा. या प्रकरणात, Gunicorn साठी अनुमत डोमेन धोरण शक्य तितके सोपे असेल - एक मुख्य प्रकार घोषित करा (gunicorn_t), एक प्रकार घोषित करा जो आम्ही एकाधिक एक्झिक्युटेबल्स (gunicorn_exec_t) चिन्हांकित करण्यासाठी वापरणार आहोत, आणि नंतर योग्यरित्या चिन्हांकित करण्यासाठी सिस्टमसाठी संक्रमण सेट करा. चालू प्रक्रिया शेवटची ओळ पॉलिसी लोड करतेवेळी डीफॉल्टनुसार सक्षम केलेली सेट करते.

gunicorn.te:

policy_module(gunicorn, 1.0)

type gunicorn_t;
type gunicorn_exec_t;
init_daemon_domain(gunicorn_t, gunicorn_exec_t)
permissive gunicorn_t;

तुम्ही ही पॉलिसी फाइल संकलित करून तुमच्या सिस्टममध्ये जोडू शकता.

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i gunicorn.pp

sudo semanage permissive -a gunicorn_t
sudo semodule -l | grep permissive

SELinux आपला अज्ञात डिमन जे ऍक्सेस करत आहे त्या व्यतिरिक्त काहीतरी ब्लॉक करत आहे का ते तपासूया.

sudo ausearch -m AVC

type=AVC msg=audit(1545315977.237:1273): avc:  denied { write } for pid=19400 comm="nginx" name="gunicorn.sock" dev="tmpfs" ino=52977 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0

SELinux Nginx ला Gunicorn द्वारे वापरलेल्या UNIX सॉकेटवर डेटा लिहिण्यापासून प्रतिबंधित करते. सामान्यतः, अशा प्रकरणांमध्ये, धोरणे बदलू लागतात, परंतु पुढे इतर आव्हाने असतात. तुम्ही डोमेन सेटिंग्ज निर्बंध डोमेनवरून परवानगी डोमेनमध्ये बदलू शकता. आता httpd_t परवानगी डोमेनवर हलवू. हे Nginx ला आवश्यक प्रवेश देईल आणि आम्ही पुढील डीबगिंग कार्य सुरू ठेवू शकतो.

sudo semanage permissive -a httpd_t

त्यामुळे, एकदा तुम्ही SELinux संरक्षित ठेवण्यात व्यवस्थापित केले (तुम्ही खरोखर SELinux प्रकल्प प्रतिबंधित मोडमध्ये सोडू नये) आणि परवानगी डोमेन लोड झाल्यानंतर, सर्वकाही योग्यरित्या कार्य करण्यासाठी gunicorn_exec_t म्हणून नेमके काय चिन्हांकित करणे आवश्यक आहे हे शोधणे आवश्यक आहे. पुन्हा प्रवेश निर्बंधांबद्दल नवीन संदेश पाहण्यासाठी वेबसाइटला भेट देण्याचा प्रयत्न करूया.

sudo ausearch -m AVC -c gunicorn

तुम्हाला 'comm="gunicorn"' असलेले बरेच संदेश दिसतील जे /srv/djangoapp मधील फाइल्सवर विविध गोष्टी करतात, त्यामुळे हे स्पष्टपणे ध्वजांकित करण्यायोग्य आदेशांपैकी एक आहे.

परंतु या व्यतिरिक्त, यासारखा संदेश दिसेल:

type=AVC msg=audit(1545320700.070:1542): avc:  denied { execute } for pid=20704 comm="(gunicorn)" name="python3.6" dev="vda3" ino=8515706 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0

तुम्ही गनिकॉर्न सेवेची स्थिती पाहिल्यास किंवा ps कमांड चालवल्यास, तुम्हाला कोणतीही चालू असलेली प्रक्रिया दिसणार नाही. असे दिसते की gunicorn आमच्या virtualenv वातावरणात Python इंटरप्रिटरमध्ये प्रवेश करण्याचा प्रयत्न करत आहे, शक्यतो वर्कर स्क्रिप्ट चालवण्यासाठी. तर आता या दोन एक्झिक्युटेबल फाईल्स चिन्हांकित करू आणि आपण आमचे Django चाचणी पृष्ठ उघडू शकतो का ते तपासू.

chcon -t gunicorn_exec_t /srv/djangoapp/django/bin/gunicorn /srv/djangoapp/django/bin/python3.6

नवीन टॅग निवडण्यापूर्वी गनीकॉर्न सेवा पुन्हा सुरू करणे आवश्यक आहे. तुम्ही ते ताबडतोब रीस्टार्ट करू शकता किंवा सेवा थांबवू शकता आणि जेव्हा तुम्ही ब्राउझरमध्ये साइट उघडता तेव्हा सॉकेट सुरू करू शकता. ps वापरून प्रक्रियांना योग्य लेबले प्राप्त झाली आहेत याची पडताळणी करा.

ps -efZ | grep gunicorn

नंतर एक सामान्य SELinux पॉलिसी तयार करण्यास विसरू नका!

तुम्ही आता AVC मेसेज पाहिल्यास, शेवटच्या मेसेजमध्ये ऍप्लिकेशनशी संबंधित प्रत्येक गोष्टीसाठी permissive=1 आणि उर्वरित सिस्टीमसाठी permissive=0 आहे. वास्तविक अनुप्रयोगास कोणत्या प्रकारच्या प्रवेशाची आवश्यकता आहे हे आपल्याला समजल्यास, आपण अशा समस्यांचे निराकरण करण्याचा सर्वोत्तम मार्ग पटकन शोधू शकता. परंतु तोपर्यंत, सिस्टम सुरक्षित ठेवणे आणि Django प्रकल्पाचे स्पष्ट, वापरण्यायोग्य ऑडिट करणे सर्वोत्तम आहे.

sudo ausearch -m AVC

झाले!

Nginx आणि Gunicorn WSGI वर आधारित फ्रंटएंडसह कार्यरत Django प्रकल्प दिसला आहे. आम्ही RHEL 3 बीटा रेपॉजिटरीजमधून Python 10 आणि PostgreSQL 8 कॉन्फिगर केले. आता तुम्ही पुढे जाऊ शकता आणि Django अॅप्लिकेशन्स तयार करू शकता (किंवा फक्त उपयोजित करू शकता) किंवा RHEL 8 बीटामध्ये कॉन्फिगरेशन प्रक्रिया स्वयंचलित करण्यासाठी, कार्यप्रदर्शन सुधारण्यासाठी किंवा हे कॉन्फिगरेशन कंटेनरीकृत करण्यासाठी इतर उपलब्ध साधने एक्सप्लोर करू शकता.

स्त्रोत: www.habr.com

कार्यशाळा RHEL 8 बीटा: कार्यरत वेब अनुप्रयोग तयार करणे

Django स्थापित करत आहे

WSGI? वाई?

खराब गेटवे त्रुटी?

परवानगी देणारी डोमेन निर्दिष्ट करत आहे

झाले!

एक टिप्पणी जोडा Отменить ответ