වැඩමුළුව RHEL 8 බීටා: වැඩ කරන වෙබ් යෙදුම් ගොඩනැගීම

RHEL 8 බීටා සංවර්ධකයින්ට නව විශේෂාංග රැසක් ලබා දෙයි, ඒවා ලැයිස්තුගත කිරීම පිටු ගත හැක, කෙසේ වෙතත්, ප්‍රායෝගිකව අලුත් දේවල් ඉගෙන ගැනීම සැමවිටම වඩා හොඳය, එබැවින් පහතින් අපි Red Hat Enterprise Linux 8 Beta මත පදනම් වූ යෙදුම් යටිතල පහසුකම් සැදීම පිළිබඳ වැඩමුළුවක් ඉදිරිපත් කරමු.

සංවර්ධකයින් අතර ජනප්‍රිය ක්‍රමලේඛන භාෂාවක් වන Python පදනමක් ලෙස, යෙදුම් නිර්මාණය කිරීම සඳහා තරමක් පොදු සංයෝජනයක් වන Django සහ PostgreSQL සංයෝජනයක් ලෙස ගෙන ඒවා සමඟ වැඩ කිරීමට RHEL 8 Beta වින්‍යාස කරමු. එවිට අපි තවත් (වර්ගීකරණය නොකළ) අමුද්රව්ය කිහිපයක් එකතු කරන්නෙමු.

පරීක්ෂණ පරිසරය වෙනස් වනු ඇත, මන්ද එය ස්වයංක්‍රීයකරණයේ හැකියාවන් ගවේෂණය කිරීම, බහාලුම් සමඟ වැඩ කිරීම සහ බහු සේවාදායකයන් සමඟ පරිසරය උත්සාහ කිරීම සිත්ගන්නා කරුණකි. නව ව්‍යාපෘතියක් සමඟ ආරම්භ කිරීම සඳහා, ඔබට කුඩා, සරල මූලාකෘතියක් අතින් නිර්මාණය කිරීමෙන් ආරම්භ කළ හැකිය, එවිට ඔබට සිදුවිය යුතු දේ සහ එය අන්තර්ක්‍රියා කරන ආකාරය හරියටම දැක ගත හැකිය, ඉන්පසු ස්වයංක්‍රීය කිරීමට සහ වඩාත් සංකීර්ණ වින්‍යාස කිරීමට ඉදිරියට යන්න. අද අපි කතා කරන්නේ එවැනි මූලාකෘතියක් නිර්මාණය කිරීම ගැන ය.

RHEL 8 Beta VM රූපය යෙදවීමෙන් ආරම්භ කරමු. ඔබට මුල සිටම අතථ්‍ය යන්ත්‍රයක් ස්ථාපනය කළ හැකිය, නැතහොත් ඔබේ බීටා දායකත්වය සමඟ ඇති KVM ආගන්තුක රූපය භාවිතා කරන්න. ආගන්තුක රූපයක් භාවිතා කරන විට, ඔබට වලාකුළු ආරම්භ කිරීම සඳහා පාර-දත්ත සහ පරිශීලක දත්ත අඩංගු අතථ්‍ය සංයුක්ත තැටියක් වින්‍යාස කිරීමට අවශ්‍ය වනු ඇත (Cloud-init). තැටි ව්‍යුහය හෝ පවතින පැකේජ සමඟ ඔබට විශේෂ කිසිවක් කිරීමට අවශ්‍ය නැත; ඕනෑම වින්‍යාසයක් සිදු කරනු ඇත.

සමස්ත ක්රියාවලිය දෙස සමීපව බලමු.

Django ස්ථාපනය කිරීම

Django හි නවතම අනුවාදය සමඟ, ඔබට Python 3.5 හෝ ඊට පසු අථත්‍ය පරිසරයක් (virtualenv) අවශ්‍ය වේ. බීටා සටහන් වල Python 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 හි විවිධ නව අනුවාද සඳහා පරිශීලකයින්ට ප්‍රවේශය ලබා දෙන අතරම ස්ථාවර පද්ධති මෙවලම්වල අවශ්‍යතාවය සපුරාලීම සඳහා, පද්ධති Python නව පැකේජයක් වෙත ගෙන ගොස් Python 2.7 සහ 3.6 යන දෙකම ස්ථාපනය කිරීමේ හැකියාව ලබා දෙන ලදී. වෙනස්කම් සහ ඒවා සිදු කළේ ඇයිද යන්න පිළිබඳ වැඩි විස්තර ප්‍රකාශනයෙන් සොයාගත හැකිය Langdon White ගේ බ්ලොග් අඩවිය (ලැන්ග්ඩන් වයිට්).

එබැවින්, වැඩ කරන Python ලබා ගැනීම සඳහා, ඔබට පැකේජ දෙකක් ස්ථාපනය කිරීමට අවශ්‍ය වේ, python3-pip පරායත්තතාවයක් ලෙස ඇතුළත් කර ඇත.

sudo yum install python36 python3-virtualenv

Langdon යෝජනා කරන පරිදි සෘජු මොඩියුල ඇමතුම් භාවිතා කර pip3 ස්ථාපනය නොකරන්නේ මන්ද? ඉදිරියට එන ස්වයංක්‍රීයකරණය සිහියේ තබා ගනිමින්, ඇන්සිබල්ට ක්‍රියාත්මක වීමට පයිප්ප ස්ථාපනය කිරීම අවශ්‍ය වනු ඇති බව දන්නා කරුණකි, මන්ද යත්, පිප් මොඩියුලය අභිරුචි පයිප්ප ක්‍රියාත්මක කළ හැකි virtualenvs සඳහා සහය නොදක්වයි.

ඔබ සතුව වැඩ කරන python3 පරිවර්තකයක් සමඟින්, ඔබට Django ස්ථාපන ක්‍රියාවලිය දිගටම කරගෙන යා හැකි අතර අපගේ අනෙකුත් සංරචක සමඟ වැඩ කරන පද්ධතියක් ද ඇත. අන්තර්ජාලයේ බොහෝ ක්‍රියාත්මක කිරීමේ විකල්ප තිබේ. මෙහි එක් අනුවාදයක් ඉදිරිපත් කර ඇත, නමුත් පරිශීලකයින්ට ඔවුන්ගේම ක්‍රියාවලි භාවිතා කළ හැකිය.

අපි RHEL 8 හි ඇති PostgreSQL සහ Nginx අනුවාද පෙරනිමියෙන් Yum භාවිතයෙන් ස්ථාපනය කරන්නෙමු.

sudo yum install nginx postgresql-server

PostgreSQL සඳහා psycopg2 අවශ්‍ය වනු ඇත, නමුත් එය ලබා ගත හැක්කේ virtualenv පරිසරයක පමණි, එබැවින් අපි එය Django සහ Gunicorn සමඟ pip3 භාවිතයෙන් ස්ථාපනය කරන්නෙමු. නමුත් මුලින්ම අපි virtualenv සැකසිය යුතුයි.

Django ව්‍යාපෘති ස්ථාපනය කිරීම සඳහා සුදුසු ස්ථානය තෝරා ගැනීමේ මාතෘකාව පිළිබඳව සෑම විටම විවාදයක් පවතී, නමුත් සැක සහිත විට, ඔබට සැමවිටම Linux ගොනු පද්ධති ධුරාවලියේ ප්‍රමිතිය වෙත හැරිය හැක. නිශ්චිතවම, FHS පවසන්නේ / srv භාවිතා කරන්නේ: "වෙබ් සර්වර් දත්ත සහ ස්ක්‍රිප්ට් වැනි පද්ධතිය නිපදවන ධාරක-විශේෂිත දත්ත ගබඩා කිරීම, FTP සේවාදායකයන් මත ගබඩා කර ඇති දත්ත සහ පද්ධති ගබඩාවන් පාලනය කිරීම" අනුවාද (FHS හි දිස්වේ. -2.3 දී 2004)."

මෙය හරියටම අපගේ නඩුවයි, එබැවින් අපි අපගේ යෙදුම් පරිශීලකයාට (Cloud-user) අයත් වන / 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-server පැකේජය සමඟ ස්ථාපනය කර ඇති postgresql-setup script එකයි. පොකුරු ආරම්භ කිරීම හෝ උත්ශ්‍රේණි කිරීමේ ක්‍රියාවලිය වැනි දත්ත සමුදා පොකුරු පරිපාලනය හා සම්බන්ධ මූලික කාර්යයන් කිරීමට මෙම ස්ක්‍රිප්ට් ඔබට උපකාර කරයි. 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? Wai?

සංවර්ධන සේවාදායකය පරීක්ෂා කිරීම සඳහා ප්‍රයෝජනවත් වේ, නමුත් යෙදුම ක්‍රියාත්මක කිරීම සඳහා ඔබ වෙබ් සේවාදායක ද්වාර අතුරුමුහුණත (WSGI) සඳහා සුදුසු සේවාදායකය සහ ප්‍රොක්සිය වින්‍යාසගත කළ යුතුය. පොදු සංයෝජන කිහිපයක් තිබේ, උදාහරණයක් ලෙස, uWSGI සමඟ Apache HTTPD හෝ Gunicorn සමඟ Nginx.

Web Server Gateway Interface හි කාර්යය වන්නේ වෙබ් සේවාදායකයෙන් ඉල්ලීම් Python වෙබ් රාමුව වෙත යොමු කිරීමයි. WSGI යනු CGI එන්ජින් තිබූ කාලයේ බිහිසුණු අතීතයේ ධාතුවක් වන අතර අද WSGI යනු වෙබ් සේවාදායකය හෝ Python රාමුව කුමක් වුවත් තථ්‍ය ප්‍රමිතියයි. නමුත් එහි පුළුල් භාවිතය තිබියදීත්, මෙම රාමු සමඟ වැඩ කිරීමේදී බොහෝ සූක්ෂ්මතා සහ බොහෝ තේරීම් තිබේ. මෙම අවස්ථාවේදී, අපි සොකට් එකක් හරහා Gunicorn සහ Nginx අතර අන්තර්ක්‍රියා ඇති කිරීමට උත්සාහ කරමු.

මෙම සංරචක දෙකම එකම සේවාදායකයේ ස්ථාපනය කර ඇති බැවින්, ජාල සොකට් වෙනුවට UNIX සොකට් එකක් භාවිතා කිරීමට උත්සාහ කරමු. ඕනෑම අවස්ථාවක සන්නිවේදනය සඳහා සොකට් එකක් අවශ්‍ය වන බැවින්, අපි තවත් එක් පියවරක් ගෙන systemd හරහා Gunicorn සඳහා සොකට් සක්‍රිය කිරීම වින්‍යාස කිරීමට උත්සාහ කරමු.

සොකට් සක්රිය කළ සේවාවන් නිර්මාණය කිරීමේ ක්රියාවලිය බෙහෙවින් සරල ය. පළමුව, UNIX සොකට් එක සාදනු ලබන ලක්ෂ්‍යය වෙත යොමු කරන ListenStream විධානයක් අඩංගු ඒකක ගොනුවක් සාදනු ලැබේ, පසුව අවශ්‍ය විධානය ඇති සේවාව සඳහා ඒකක ගොනුවක් සොකට් ඒකක ගොනුව වෙත යොමු කරනු ඇත. එවිට, සේවා ඒකක ගොනුවේ, ඉතිරිව ඇත්තේ අතථ්‍ය පරිසරයෙන් Gunicorn ඇමතීමට සහ UNIX සොකට් සහ Django යෙදුම සඳහා 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_name සැකසීමට වග බලා ගන්න.

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 socket සහ Nginx ආරම්භ කරන්න, ඔබ පරීක්ෂණ ආරම්භ කිරීමට සූදානම්.

නරක ද්වාර දෝෂයක්ද?

ඔබ ඔබේ බ්‍රවුසරයට ලිපිනය ඇතුළත් කළහොත්, ඔබට බොහෝ විට 502 Bad Gateway දෝෂයක් ලැබෙනු ඇත. එය වැරදි ලෙස වින්‍යාස කර ඇති 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"

Gunicorn එක කෙලින්ම test කලොත් අපිට ලැබෙන්නේ හිස් උත්තරයක්.

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

මෙය සිදුවන්නේ මන්දැයි අපි සොයා බලමු. ඔබ ලොගය විවෘත කළහොත්, ගැටලුව SELinux හා සම්බන්ධ බව ඔබට බොහෝ විට පෙනෙනු ඇත. අපි ප්‍රතිපත්තියක් නිර්මාණය කර නොමැති ඩීමන් එකක් ධාවනය කරන බැවින්, එය init_t ලෙස සලකුණු කර ඇත. අපි මෙම න්යාය ප්රායෝගිකව පරීක්ෂා කරමු.

sudo setenforce 0

මේ සියල්ල විවේචනයට සහ ලේ කඳුළුවලට හේතු විය හැක, නමුත් මෙය මූලාකෘතිය නිදොස් කිරීම පමණි. මෙය ගැටළුව බව තහවුරු කර ගැනීම සඳහා චෙක්පත අක්‍රිය කරමු, ඉන්පසු අපි සියල්ල නැවත එහි ස්ථානයට යමු.

බ්‍රවුසරයේ පිටුව නැවුම් කිරීමෙන් හෝ අපගේ curl විධානය නැවත ක්‍රියාත්මක කිරීමෙන්, ඔබට Django පරීක්ෂණ පිටුව දැකිය හැක.

එබැවින්, සියල්ල ක්‍රියාත්මක වන බවටත්, තවත් අවසර ගැටළු නොමැති බවටත් වග බලා ගැනීමෙන්, අපි නැවත SELinux සක්‍රීය කරමු.

sudo setenforce 1

මම මෙහි audit2allow හෝ sepolgen සමඟ අනතුරු ඇඟවීම් පදනම් කරගත් ප්‍රතිපත්ති නිර්මාණය කිරීම ගැන කතා නොකරමි, මේ මොහොතේ සැබෑ 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

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 පරිසරය තුළ Python පරිවර්තකය වෙත ප්‍රවේශ වීමට උත්සාහ කරන බව පෙනේ, සමහර විට සේවක ස්ක්‍රිප්ට් ධාවනය කිරීමට. දැන් අපි මෙම ක්‍රියාත්මක කළ හැකි ගොනු දෙක සලකුණු කර අපගේ Django පරීක්ෂණ පිටුව විවෘත කළ හැකිදැයි පරීක්ෂා කරමු.

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

නව ටැගය තෝරා ගැනීමට පෙර gunicorn සේවාව නැවත ආරම්භ කිරීමට අවශ්‍ය වනු ඇත. ඔබට එය වහාම නැවත ආරම්භ කිරීමට හෝ සේවාව නැවැත්වීමට සහ ඔබ බ්‍රව්සරයේ වෙබ් අඩවිය විවෘත කරන විට සොකට් එය ආරම්භ කිරීමට ඉඩ දෙන්න. 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 Beta හි ඇති වෙනත් මෙවලම් ගවේෂණය කිරීමට හැකිය.

මූලාශ්රය: www.habr.com