RHEL 8 Beta ڈویلپرز کو بہت سی نئی خصوصیات پیش کرتا ہے، جن کی فہرست میں صفحات لگ سکتے ہیں، تاہم، نئی چیزیں سیکھنا عملی طور پر ہمیشہ بہتر ہوتا ہے، اس لیے ذیل میں ہم Red Hat Enterprise Linux 8 Beta پر مبنی ایپلیکیشن انفراسٹرکچر بنانے کے لیے ایک ورکشاپ پیش کرتے ہیں۔
آئیے ڈیولپرز کے درمیان ایک مقبول پروگرامنگ لینگویج Python کو بنیاد کے طور پر، Django اور PostgreSQL کا مجموعہ، ایپلی کیشنز بنانے کے لیے کافی عام مجموعہ، اور ان کے ساتھ کام کرنے کے لیے RHEL 8 Beta کو ترتیب دیں۔ پھر ہم کچھ اور (غیر درجہ بند) اجزاء شامل کریں گے۔
ٹیسٹ کا ماحول بدل جائے گا، کیونکہ آٹومیشن کے امکانات کو تلاش کرنا، کنٹینرز کے ساتھ کام کرنا اور متعدد سرورز کے ساتھ ماحول آزمانا دلچسپ ہے۔ ایک نئے پروجیکٹ کے ساتھ شروع کرنے کے لیے، آپ ہاتھ سے ایک چھوٹا، سادہ پروٹو ٹائپ بنا کر شروع کر سکتے ہیں تاکہ آپ بالکل دیکھ سکیں کہ کیا ہونے کی ضرورت ہے اور یہ کیسے تعامل کرتا ہے، اور پھر خودکار اور مزید پیچیدہ کنفیگریشنز بنانے کی طرف بڑھیں۔ آج ہم اس طرح کے ایک پروٹوٹائپ کی تخلیق کے بارے میں بات کر رہے ہیں.
آئیے RHEL 8 Beta VM امیج کو تعینات کرکے شروع کریں۔ آپ شروع سے ایک ورچوئل مشین انسٹال کر سکتے ہیں، یا اپنے بیٹا سبسکرپشن کے ساتھ دستیاب KVM گیسٹ امیج استعمال کر سکتے ہیں۔ مہمان کی تصویر کا استعمال کرتے وقت، آپ کو ایک ورچوئل سی ڈی کنفیگر کرنے کی ضرورت ہوگی جس میں کلاؤڈ انیشیلائزیشن (کلاؤڈ انیٹ) کے لیے میٹا ڈیٹا اور صارف کا ڈیٹا ہوگا۔ آپ کو ڈسک کے ڈھانچے یا دستیاب پیکجوں کے ساتھ کچھ خاص کرنے کی ضرورت نہیں ہے؛ کوئی بھی کنفیگریشن کرے گی۔
آئیے پورے عمل کو قریب سے دیکھتے ہیں۔
جینگو انسٹال کرنا
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 دونوں کو انسٹال کرنے کی صلاحیت فراہم کی گئی۔ تبدیلیوں کے بارے میں مزید معلومات اور انہیں کیوں کیا گیا تھا اس میں اشاعت میں پایا جا سکتا ہے۔ (لینگڈن وائٹ)۔
لہذا، Python کو کام کرنے کے لیے، آپ کو صرف دو پیکجز انسٹال کرنے کی ضرورت ہے، جس میں python3-pip بطور انحصار شامل ہے۔
sudo yum install python36 python3-virtualenv
کیوں نہ براہ راست ماڈیول کالز کا استعمال کریں جیسا کہ لینگڈن تجویز کرتا ہے اور پائپ 3 انسٹال کرتا ہے؟ آنے والی آٹومیشن کو ذہن میں رکھتے ہوئے، یہ معلوم ہے کہ Ansible کو چلانے کے لیے pip انسٹال کرنے کی ضرورت ہوگی، کیونکہ pip ماڈیول اپنی مرضی کے مطابق pip executable کے ساتھ virtualenvs کو سپورٹ نہیں کرتا ہے۔
آپ کے اختیار میں کام کرنے والے python3 ترجمان کے ساتھ، آپ Django کی تنصیب کے عمل کو جاری رکھ سکتے ہیں اور ہمارے دوسرے اجزاء کے ساتھ ایک کام کرنے والا نظام رکھ سکتے ہیں۔ انٹرنیٹ پر نفاذ کے بہت سے اختیارات دستیاب ہیں۔ یہاں ایک ورژن پیش کیا گیا ہے، لیکن صارف اپنے عمل کو استعمال کر سکتے ہیں۔
ہم RHEL 8 میں دستیاب PostgreSQL اور Nginx ورژن کو بطور ڈیفالٹ Yum کا استعمال کرتے ہوئے انسٹال کریں گے۔
sudo yum install nginx postgresql-server
PostgreSQL کو psycopg2 کی ضرورت ہوگی، لیکن اسے صرف ایک ورچوئل این وی ماحول میں دستیاب ہونا ضروری ہے، لہذا ہم اسے 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) کے لیے مناسب سرور اور پراکسی کو ترتیب دینا ہوگا۔ کئی عام امتزاج ہیں، مثال کے طور پر، UWSGI کے ساتھ Apache HTTPD یا Gunicorn کے ساتھ Nginx۔
ویب سرور گیٹ وے انٹرفیس کا کام ویب سرور سے درخواستوں کو Python ویب فریم ورک پر بھیجنا ہے۔ WSGI خوفناک ماضی کی یادگار ہے جب CGI انجن آس پاس تھے، اور آج WSGI ڈی فیکٹو معیار ہے، قطع نظر اس کے کہ ویب سرور یا Python فریم ورک استعمال کیا جائے۔ لیکن اس کے وسیع پیمانے پر استعمال کے باوجود، ان فریم ورک کے ساتھ کام کرتے وقت بہت سی باریکیاں اور بہت سے انتخاب موجود ہیں۔ اس صورت میں، ہم ایک ساکٹ کے ذریعے Gunicorn اور Nginx کے درمیان تعامل قائم کرنے کی کوشش کریں گے۔
چونکہ یہ دونوں اجزاء ایک ہی سرور پر انسٹال ہیں، آئیے نیٹ ورک ساکٹ کے بجائے UNIX ساکٹ استعمال کرنے کی کوشش کریں۔ چونکہ کمیونیکیشن کے لیے کسی بھی صورت میں ساکٹ کی ضرورت ہوتی ہے، آئیے ایک اور قدم اٹھانے کی کوشش کریں اور سسٹم ڈی کے ذریعے Gunicorn کے لیے ساکٹ ایکٹیویشن کو ترتیب دیں۔
ساکٹ ایکٹیویٹڈ سروسز بنانے کا عمل کافی آسان ہے۔ سب سے پہلے، ایک یونٹ فائل بنائی جاتی ہے جس میں ایک ListenStream ڈائریکٹیو ہوتا ہے جس میں اس پوائنٹ کی طرف اشارہ کیا جاتا ہے جس پر UNIX ساکٹ بنایا جائے گا، پھر اس سروس کے لیے ایک یونٹ فائل جس میں Requires Directive ساکٹ یونٹ فائل کی طرف اشارہ کرے گا۔ پھر، سروس یونٹ فائل میں، جو کچھ باقی ہے وہ ہے ورچوئل ماحول سے گنی کارن کو کال کرنا اور UNIX ساکٹ اور Django ایپلیکیشن کے لیے 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"
اگر ہم Gunicorn کو براہ راست جانچتے ہیں، تو ہمیں خالی جواب ملے گا۔
curl —unix-socket /run/gunicorn.sock 8beta1.example.com
آئیے معلوم کریں کہ ایسا کیوں ہوتا ہے۔ اگر آپ لاگ کو کھولتے ہیں، تو آپ کو زیادہ امکان نظر آئے گا کہ مسئلہ SELinux سے متعلق ہے۔ چونکہ ہم ایک ڈیمون چلا رہے ہیں جس کے لیے کوئی پالیسی نہیں بنائی گئی ہے، اس لیے اسے init_t کے بطور نشان زد کیا گیا ہے۔ آئیے اس نظریہ کو عملی طور پر جانچتے ہیں۔
sudo setenforce 0
یہ سب کچھ تنقید اور خون کے آنسوؤں کا سبب بن سکتا ہے، لیکن یہ صرف پروٹو ٹائپ کو ڈیبگ کر رہا ہے۔ آئیے صرف اس بات کو یقینی بنانے کے لیے چیک کو غیر فعال کر دیں کہ یہ مسئلہ ہے، جس کے بعد ہم ہر چیز کو اس کی جگہ پر واپس کر دیں گے۔
براؤزر میں صفحہ کو تازہ کر کے یا ہماری curl کمانڈ کو دوبارہ چلا کر، آپ Django ٹیسٹ صفحہ دیکھ سکتے ہیں۔
لہذا، اس بات کو یقینی بنانے کے بعد کہ سب کچھ کام کرتا ہے اور اجازت کے مزید مسائل نہیں ہیں، ہم 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
اگر آپ گنی کارن سروس کی حیثیت کو دیکھتے ہیں یا پی ایس کمانڈ چلاتے ہیں، تو آپ کو کوئی چلنے والا عمل نظر نہیں آئے گا۔ ایسا لگتا ہے کہ گنی کارن ہمارے 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
ہوا!
ایک کام کرنے والا Django پروجیکٹ Nginx اور Gunicorn WSGI پر مبنی فرنٹ اینڈ کے ساتھ ظاہر ہوا ہے۔ ہم نے RHEL 3 Beta repositories سے Python 10 اور PostgreSQL 8 کو ترتیب دیا۔ اب آپ آگے بڑھ سکتے ہیں اور Django ایپلی کیشنز بنا سکتے ہیں (یا صرف تعینات کر سکتے ہیں) یا RHEL 8 Beta میں دیگر دستیاب ٹولز کو دریافت کر سکتے ہیں تاکہ کنفیگریشن کے عمل کو خودکار بنایا جا سکے، کارکردگی کو بہتر بنایا جا سکے، یا اس کنفیگریشن کو کنٹینرائز کیا جا سکے۔
ماخذ: www.habr.com