వర్క్‌షాప్ RHEL 8 బీటా: పని చేసే వెబ్ అప్లికేషన్‌లను రూపొందించడం

RHEL 8 బీటా డెవలపర్‌లకు అనేక కొత్త ఫీచర్‌లను అందిస్తుంది, వాటి జాబితా పేజీలను తీసుకోవచ్చు, అయితే, కొత్త విషయాలను నేర్చుకోవడం ఆచరణలో ఎల్లప్పుడూ మెరుగ్గా ఉంటుంది, కాబట్టి మేము Red Hat Enterprise Linux 8 బీటా ఆధారంగా వాస్తవానికి అప్లికేషన్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను రూపొందించడంపై వర్క్‌షాప్‌ను అందిస్తున్నాము.

డెవలపర్‌లలో ప్రసిద్ధ ప్రోగ్రామింగ్ భాష అయిన పైథాన్‌ని ప్రాతిపదికగా తీసుకుందాం, అప్లికేషన్‌లను రూపొందించడానికి చాలా సాధారణ కలయిక అయిన జంగో మరియు పోస్ట్‌గ్రెస్‌ఎస్‌క్యూఎల్ కలయిక మరియు వాటితో పని చేయడానికి RHEL 8 బీటాను కాన్ఫిగర్ చేయండి. అప్పుడు మేము మరికొన్ని (వర్గీకరించని) పదార్థాలను జోడిస్తాము.

పరీక్ష వాతావరణం మారుతుంది, ఎందుకంటే ఆటోమేషన్ యొక్క అవకాశాలను అన్వేషించడం, కంటైనర్‌లతో పని చేయడం మరియు బహుళ సర్వర్‌లతో పరిసరాలను ప్రయత్నించడం ఆసక్తికరంగా ఉంటుంది. కొత్త ప్రాజెక్ట్‌తో ప్రారంభించడానికి, మీరు చేతితో ఒక చిన్న, సరళమైన నమూనాను సృష్టించడం ద్వారా ప్రారంభించవచ్చు, తద్వారా మీరు ఖచ్చితంగా ఏమి జరగాలి మరియు అది ఎలా సంకర్షణ చెందుతుందో చూడవచ్చు, ఆపై ఆటోమేట్ చేయడానికి మరియు మరింత సంక్లిష్టమైన కాన్ఫిగరేషన్‌లను రూపొందించడానికి కొనసాగండి. ఈ రోజు మనం అటువంటి నమూనా యొక్క సృష్టి గురించి మాట్లాడుతున్నాము.

RHEL 8 బీటా VM ఇమేజ్‌ని అమలు చేయడం ద్వారా ప్రారంభిద్దాం. మీరు మొదటి నుండి వర్చువల్ మిషన్‌ను ఇన్‌స్టాల్ చేయవచ్చు లేదా మీ బీటా సబ్‌స్క్రిప్షన్‌తో అందుబాటులో ఉన్న KVM అతిథి చిత్రాన్ని ఉపయోగించవచ్చు. అతిథి చిత్రాన్ని ఉపయోగిస్తున్నప్పుడు, మీరు క్లౌడ్ ఇనిషియలైజేషన్ (క్లౌడ్-ఇనిట్) కోసం మెటాడేటా మరియు యూజర్ డేటాను కలిగి ఉండే వర్చువల్ CDని కాన్ఫిగర్ చేయాలి. మీరు డిస్క్ నిర్మాణం లేదా అందుబాటులో ఉన్న ప్యాకేజీలతో ప్రత్యేకంగా ఏమీ చేయనవసరం లేదు; ఏదైనా కాన్ఫిగరేషన్ చేస్తుంది.

మొత్తం ప్రక్రియను నిశితంగా పరిశీలిద్దాం.

జాంగోను ఇన్‌స్టాల్ చేస్తోంది

జంగో యొక్క సరికొత్త వెర్షన్‌తో, మీకు పైథాన్ 3.5 లేదా తర్వాతి వెర్షన్‌తో వర్చువల్ ఎన్విరాన్‌మెంట్ (వర్చువల్ ఎన్విరాన్‌మెంట్) అవసరం. బీటా నోట్స్‌లో మీరు పైథాన్ 3.6 అందుబాటులో ఉందని చూడవచ్చు, ఇది నిజంగా జరిగిందో లేదో చూద్దాం:

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

Red Hat RHELలో పైథాన్‌ని సిస్టమ్ టూల్‌కిట్‌గా యాక్టివ్‌గా ఉపయోగిస్తుంది, కాబట్టి దీని ఫలితం ఎందుకు వస్తుంది?

వాస్తవం ఏమిటంటే, చాలా మంది పైథాన్ డెవలపర్‌లు ఇప్పటికీ పైథాన్ 2 నుండి పైథాన్ 2కి మారడం గురించి ఆలోచిస్తున్నారు, అయితే పైథాన్ 3 యాక్టివ్ డెవలప్‌మెంట్‌లో ఉంది మరియు మరిన్ని కొత్త వెర్షన్‌లు నిరంతరం కనిపిస్తాయి. అందువల్ల, పైథాన్ యొక్క వివిధ కొత్త వెర్షన్‌లకు వినియోగదారులకు ప్రాప్యతను అందిస్తున్నప్పుడు స్థిరమైన సిస్టమ్ సాధనాల అవసరాన్ని తీర్చడానికి, సిస్టమ్ పైథాన్ కొత్త ప్యాకేజీకి తరలించబడింది మరియు పైథాన్ 2.7 మరియు 3.6 రెండింటినీ ఇన్‌స్టాల్ చేయగల సామర్థ్యాన్ని అందించింది. మార్పులు మరియు అవి ఎందుకు చేయబడ్డాయి అనే దాని గురించి మరింత సమాచారం ప్రచురణలో చూడవచ్చు లాంగ్డన్ వైట్ బ్లాగ్ (లాంగ్డన్ వైట్).

కాబట్టి, పని చేసే పైథాన్ పొందడానికి, మీరు రెండు ప్యాకేజీలను ఇన్‌స్టాల్ చేయాలి, python3-pip డిపెండెన్సీగా చేర్చబడుతుంది.

sudo yum install python36 python3-virtualenv

లాంగ్‌డన్ సూచించినట్లుగా డైరెక్ట్ మాడ్యూల్ కాల్‌లను ఎందుకు ఉపయోగించకూడదు మరియు pip3ని ఇన్‌స్టాల్ చేయకూడదు? రాబోయే ఆటోమేషన్‌ను దృష్టిలో ఉంచుకుని, పిప్ మాడ్యూల్ కస్టమ్ పిప్ ఎక్జిక్యూటబుల్‌తో virtualenvsకి మద్దతు ఇవ్వదు కాబట్టి, అమలు చేయడానికి Ansibleకి పిప్ ఇన్‌స్టాల్ చేయవలసి ఉంటుందని తెలిసింది.

మీ వద్ద పని చేస్తున్న python3 ఇంటర్‌ప్రెటర్‌తో, మీరు జంగో ఇన్‌స్టాలేషన్ ప్రాసెస్‌ను కొనసాగించవచ్చు మరియు మా ఇతర భాగాలతో పాటు వర్కింగ్ సిస్టమ్‌ను కలిగి ఉండవచ్చు. ఇంటర్నెట్‌లో అనేక అమలు ఎంపికలు అందుబాటులో ఉన్నాయి. ఇక్కడ ఒక సంస్కరణ అందించబడింది, కానీ వినియోగదారులు వారి స్వంత ప్రక్రియలను ఉపయోగించవచ్చు.

మేము యమ్ ఉపయోగించి డిఫాల్ట్‌గా RHEL 8లో అందుబాటులో ఉన్న PostgreSQL మరియు Nginx సంస్కరణలను ఇన్‌స్టాల్ చేస్తాము.

sudo yum install nginx postgresql-server

PostgreSQLకి psycopg2 అవసరమవుతుంది, కానీ అది కేవలం virtualenv వాతావరణంలో మాత్రమే అందుబాటులో ఉండాలి, కాబట్టి మేము దీనిని జంగో మరియు Gunicornతో పాటు pip3ని ఉపయోగించి ఇన్‌స్టాల్ చేస్తాము. అయితే ముందుగా మనం virtualenvని సెటప్ చేయాలి.

జంగో ప్రాజెక్ట్‌లను ఇన్‌స్టాల్ చేయడానికి సరైన స్థలాన్ని ఎంచుకోవడం అనే అంశంపై ఎల్లప్పుడూ చాలా చర్చలు జరుగుతూనే ఉంటాయి, కానీ సందేహం ఉంటే, మీరు ఎల్లప్పుడూ Linux ఫైల్‌సిస్టమ్ హైరార్కీ స్టాండర్డ్‌ని ఆశ్రయించవచ్చు. ప్రత్యేకించి, FHS ఇలా చెబుతోంది: "హోస్ట్-నిర్దిష్ట డేటాను నిల్వ చేయడానికి-నిర్దిష్ట డేటా-సిస్టమ్ ఉత్పత్తి చేసే డేటా, వెబ్ సర్వర్ డేటా మరియు స్క్రిప్ట్‌లు, 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 మరియు జంగోను సెటప్ చేయడం సులభం: డేటాబేస్ను సృష్టించండి, వినియోగదారుని సృష్టించండి, అనుమతులను కాన్ఫిగర్ చేయండి. పోస్ట్‌గ్రెస్‌క్యూల్‌ను ఇన్‌స్టాల్ చేస్తున్నప్పుడు ముందుగా గుర్తుంచుకోవలసిన విషయం ఏమిటంటే పోస్ట్‌గ్రెస్‌క్యూల్-సర్వర్ ప్యాకేజీతో ఇన్‌స్టాల్ చేయబడిన పోస్ట్‌గ్రెస్‌క్యూల్-సెటప్ స్క్రిప్ట్. క్లస్టర్ ప్రారంభించడం లేదా అప్‌గ్రేడ్ ప్రాసెస్ వంటి డేటాబేస్ క్లస్టర్ అడ్మినిస్ట్రేషన్‌తో అనుబంధించబడిన ప్రాథమిక విధులను నిర్వహించడానికి ఈ స్క్రిప్ట్ మీకు సహాయపడుతుంది. RHEL సిస్టమ్‌పై కొత్త PostgreSQL ఉదాహరణను కాన్ఫిగర్ చేయడానికి, మనం ఆదేశాన్ని అమలు చేయాలి:

sudo /usr/bin/postgresql-setup -initdb

మీరు systemdని ఉపయోగించి PostgreSQLని ప్రారంభించవచ్చు, డేటాబేస్‌ని సృష్టించవచ్చు మరియు జంగోలో ప్రాజెక్ట్‌ను సెటప్ చేయవచ్చు. అప్లికేషన్ వినియోగదారు కోసం పాస్‌వర్డ్ నిల్వను కాన్ఫిగర్ చేయడానికి క్లయింట్ ప్రామాణీకరణ కాన్ఫిగరేషన్ ఫైల్‌కు (సాధారణంగా 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.

వెబ్ సర్వర్ గేట్‌వే ఇంటర్‌ఫేస్ యొక్క పని వెబ్ సర్వర్ నుండి పైథాన్ వెబ్ ఫ్రేమ్‌వర్క్‌కు అభ్యర్థనలను ఫార్వార్డ్ చేయడం. WSGI అనేది CGI ఇంజిన్‌లు ఉన్నప్పటి భయంకరమైన గతం యొక్క అవశేషాలు మరియు నేడు WSGI అనేది వెబ్ సర్వర్ లేదా పైథాన్ ఫ్రేమ్‌వర్క్‌తో సంబంధం లేకుండా వాస్తవ ప్రమాణంగా ఉంది. కానీ దాని విస్తృత ఉపయోగం ఉన్నప్పటికీ, ఈ ఫ్రేమ్‌వర్క్‌లతో పనిచేసేటప్పుడు ఇంకా చాలా సూక్ష్మ నైపుణ్యాలు మరియు అనేక ఎంపికలు ఉన్నాయి. ఈ సందర్భంలో, మేము Gunicorn మరియు Nginx మధ్య పరస్పర చర్యను సాకెట్ ద్వారా ఏర్పాటు చేయడానికి ప్రయత్నిస్తాము.

ఈ రెండు భాగాలు ఒకే సర్వర్‌లో ఇన్‌స్టాల్ చేయబడినందున, నెట్‌వర్క్ సాకెట్‌కు బదులుగా UNIX సాకెట్‌ని ఉపయోగించి ప్రయత్నిద్దాం. ఏ సందర్భంలోనైనా కమ్యూనికేషన్‌కు సాకెట్ అవసరం కాబట్టి, సిస్టమ్‌డి ద్వారా గునికార్న్ కోసం సాకెట్ యాక్టివేషన్‌ని కాన్ఫిగర్ చేసి మరో అడుగు వేయడానికి ప్రయత్నిద్దాం.

సాకెట్ యాక్టివేటెడ్ సేవలను సృష్టించే ప్రక్రియ చాలా సులభం. మొదట, UNIX సాకెట్ సృష్టించబడే పాయింట్‌ను సూచించే ListenStream డైరెక్టివ్‌ను కలిగి ఉన్న యూనిట్ ఫైల్ సృష్టించబడుతుంది, ఆపై సర్వీస్ కోసం ఒక యూనిట్ ఫైల్, దీనిలో నిర్దేశకం అవసరమయ్యే సాకెట్ యూనిట్ ఫైల్‌కు సూచించబడుతుంది. అప్పుడు, సర్వీస్ యూనిట్ ఫైల్‌లో, వర్చువల్ ఎన్విరాన్‌మెంట్ నుండి గునికార్న్‌కి కాల్ చేయడం మరియు UNIX సాకెట్ మరియు జంగో అప్లికేషన్ కోసం WSGI బైండింగ్‌ను సృష్టించడం మాత్రమే మిగిలి ఉంది.

మీరు ప్రాతిపదికగా ఉపయోగించగల యూనిట్ ఫైల్‌ల యొక్క కొన్ని ఉదాహరణలు ఇక్కడ ఉన్నాయి. మొదటి మేము సాకెట్ ఏర్పాటు.

[Unit]
Description=Gunicorn WSGI socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

ఇప్పుడు మీరు Gunicorn డెమోన్‌ను కాన్ఫిగర్ చేయాలి.

[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

ఇక్కడ audit2allow లేదా సెపోల్జెన్‌తో అలర్ట్-ఆధారిత విధానాలను రూపొందించడం గురించి మాట్లాడటం లేదు, ప్రస్తుతం జంగో అప్లికేషన్ ఏదీ లేదు, కాబట్టి 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

Gunicorn ఉపయోగించే UNIX సాకెట్‌కు డేటా రాయకుండా SELinux Nginxని నిరోధిస్తుంది. సాధారణంగా, అటువంటి సందర్భాలలో, విధానాలు మారడం ప్రారంభిస్తాయి, కానీ ముందు ఇతర సవాళ్లు ఉన్నాయి. మీరు డొమైన్ సెట్టింగ్‌లను పరిమితి డొమైన్ నుండి అనుమతి డొమైన్‌కి కూడా మార్చవచ్చు. ఇప్పుడు httpd_tని అనుమతుల డొమైన్‌కి తరలిద్దాం. ఇది Nginxకి అవసరమైన యాక్సెస్‌ని ఇస్తుంది మరియు మేము తదుపరి డీబగ్గింగ్ పనిని కొనసాగించవచ్చు.

sudo semanage permissive -a httpd_t

కాబట్టి, మీరు SELinuxని సురక్షితంగా ఉంచుకోగలిగిన తర్వాత (మీరు నిజంగా SELinux ప్రాజెక్ట్‌ను నిరోధిత మోడ్‌లో వదిలివేయకూడదు) మరియు అనుమతి డొమైన్‌లు లోడ్ అయిన తర్వాత, ప్రతిదీ సరిగ్గా పని చేయడానికి ఖచ్చితంగా ఏమి గుర్తించాలో gunicorn_exec_t అని మీరు గుర్తించాలి. మళ్ళీ. యాక్సెస్ పరిమితుల గురించి కొత్త సందేశాలను చూడటానికి వెబ్‌సైట్‌ని సందర్శించి ప్రయత్నిద్దాం.

sudo ausearch -m AVC -c gunicorn

మీరు /srv/djangoappలోని ఫైల్‌లపై వివిధ పనులను చేసే 'comm="gunicorn"'ని కలిగి ఉన్న చాలా సందేశాలను చూస్తారు, కాబట్టి ఇది స్పష్టంగా ఫ్లాగ్ చేయడానికి విలువైన ఆదేశాలలో ఒకటి.

కానీ అదనంగా, ఇలాంటి సందేశం కనిపిస్తుంది:

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

మీరు gunicorn సేవ యొక్క స్థితిని చూస్తే లేదా ps ఆదేశాన్ని అమలు చేస్తే, మీరు ఏ రన్నింగ్ ప్రాసెస్‌లను చూడలేరు. Gunicorn మా virtualenv వాతావరణంలో పైథాన్ ఇంటర్‌ప్రెటర్‌ని యాక్సెస్ చేయడానికి ప్రయత్నిస్తున్నట్లు కనిపిస్తోంది, బహుశా వర్కర్ స్క్రిప్ట్‌లను అమలు చేయడానికి. కాబట్టి ఇప్పుడు ఈ రెండు ఎక్జిక్యూటబుల్ ఫైల్‌లను గుర్తించి, మన జంగో పరీక్ష పేజీని తెరవగలమో లేదో తనిఖీ చేద్దాం.

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 ఉంటుంది. నిజమైన అప్లికేషన్‌కు ఎలాంటి యాక్సెస్ అవసరమో మీరు అర్థం చేసుకుంటే, అటువంటి సమస్యలను పరిష్కరించడానికి మీరు ఉత్తమమైన మార్గాన్ని త్వరగా కనుగొనవచ్చు. కానీ అప్పటి వరకు, సిస్టమ్‌ను సురక్షితంగా ఉంచడం మరియు జంగో ప్రాజెక్ట్ యొక్క స్పష్టమైన, ఉపయోగించగల ఆడిట్‌ను పొందడం ఉత్తమం.

sudo ausearch -m AVC

జరిగింది!

పని చేసే జంగో ప్రాజెక్ట్ Nginx మరియు Gunicorn WSGI ఆధారిత ఫ్రంటెండ్‌తో కనిపించింది. మేము RHEL 3 బీటా రిపోజిటరీల నుండి పైథాన్ 10 మరియు PostgreSQL 8 కాన్ఫిగర్ చేసాము. ఇప్పుడు మీరు కాన్ఫిగరేషన్ ప్రాసెస్‌ను ఆటోమేట్ చేయడానికి, పనితీరును మెరుగుపరచడానికి లేదా ఈ కాన్ఫిగరేషన్‌ను కంటెయినరైజ్ చేయడానికి RHEL 8 బీటాలో జాంగో అప్లికేషన్‌లను రూపొందించవచ్చు లేదా సృష్టించవచ్చు (లేదా కేవలం అమలు చేయవచ్చు) లేదా అందుబాటులో ఉన్న ఇతర సాధనాలను అన్వేషించవచ్చు.

మూలం: www.habr.com