RHEL 8 Beta ڊولپرز کي ڪيتريون ئي نيون خاصيتون پيش ڪري ٿو، جن جي لسٽنگ ڪري سگھي ٿي صفحا، جيتوڻيڪ، نئين شين کي سکڻ هميشه عملي طور تي بهتر آهي، تنهنڪري هيٺ اسين هڪ ورڪشاپ پيش ڪريون ٿا اصل ۾ هڪ ايپليڪيشن انفراسٽرڪچر ٺاهڻ تي جيڪو Red Hat Enterprise Linux 8 Beta تي ٻڌل آهي.
اچو ته وٺون Python، ڊولپرز جي وچ ۾ هڪ مشهور پروگرامنگ ٻولي، بنياد جي طور تي، Django ۽ PostgreSQL جو هڪ ميلاپ، ايپليڪيشن ٺاهڻ لاءِ ڪافي عام ميلاپ، ۽ انهن سان ڪم ڪرڻ لاءِ RHEL 8 بيٽا کي ترتيب ڏيو. ان کان پوء اسان ڪجھ وڌيڪ شامل ڪنداسين (غير ترتيب ڏنل) اجزاء.
ٽيسٽ ماحول تبديل ٿي ويندو، ڇاڪاڻ ته اهو دلچسپ آهي آٽوميشن جي امڪانن کي ڳولڻ، ڪنٽينرز سان ڪم ڪرڻ ۽ ڪيترن ئي سرورن سان ماحول جي ڪوشش ڪرڻ. هڪ نئين پروجيڪٽ سان شروع ڪرڻ لاءِ، توهان هٿ سان هڪ ننڍڙو، سادو پروٽوٽائپ ٺاهي شروع ڪري سگهو ٿا ته جيئن توهان ڏسي سگهو ٿا ته ڇا ٿيڻ جي ضرورت آهي ۽ اهو ڪيئن لهي ٿو، ۽ پوءِ اڳتي وڌو خودڪار ڏانهن ۽ وڌيڪ پيچيده ترتيبون ٺاهي. اڄ اسان کي اهڙي prototype جي پيدائش جي باري ۾ ڳالهائي رهيا آهن.
اچو ته RHEL 8 بيٽا VM تصوير کي ترتيب ڏيڻ سان شروع ڪريون. توهان شروع کان هڪ ورچوئل مشين انسٽال ڪري سگهو ٿا، يا استعمال ڪري سگهو ٿا KVM مهمان تصوير موجود آهي توهان جي بيٽا سبسڪرپشن سان. جڏهن مهمان جي تصوير استعمال ڪندي، توهان کي هڪ مجازي سي ڊي ترتيب ڏيڻ جي ضرورت پوندي جنهن ۾ ڪلائوڊ شروعاتي (ڪلائوڊ-انٽ) لاءِ ميٽا ڊيٽا ۽ صارف ڊيٽا شامل هوندي. توهان کي ڊسڪ جي جوڙجڪ يا دستياب پيڪيجز سان ڪجهه خاص ڪرڻ جي ضرورت ناهي؛ ڪا به ترتيب ڏيندو.
اچو ته سڄي عمل تي هڪ ويجهي نظر رکون.
Django انسٽال ڪرڻ
جيانگو جي جديد ترين ورزن سان، توهان کي پٿون 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 فعال طور تي Python کي RHEL ۾ سسٽم ٽول ڪٽ طور استعمال ڪري ٿو، پوء اھو نتيجو ڇو ٿو؟
حقيقت اها آهي ته ڪيترائي پٿون ڊولپر اڃا تائين پٿون 2 کان پٿون 2 تائين منتقلي تي غور ڪري رهيا آهن، جڏهن ته پٿون 3 پاڻ فعال ترقي هيٺ آهي، ۽ وڌيڪ ۽ وڌيڪ نوان ورزن مسلسل ظاهر ٿي رهيا آهن. تنهن ڪري، مستحڪم سسٽم اوزار جي ضرورت کي پورو ڪرڻ لاءِ جڏهن صارفين کي پٿون جي مختلف نون ورزن تائين رسائي فراهم ڪندي، سسٽم پٿون کي نئين پيڪيج ۾ منتقل ڪيو ويو ۽ پٿون 2.7 ۽ 3.6 ٻنهي کي انسٽال ڪرڻ جي صلاحيت ڏني وئي. تبديلين جي باري ۾ وڌيڪ معلومات ۽ اهي ڇو ڪيون ويون آهن جي اشاعت ۾ ڳولهي سگهجن ٿا (Langdon White).
تنهن ڪري، پٿون ڪم ڪرڻ لاءِ، توهان کي صرف ٻه پيڪيجز انسٽال ڪرڻ جي ضرورت آهي، جنهن ۾ python3-pip هڪ انحصار طور شامل آهي.
sudo yum install python36 python3-virtualenv
ڇو نه سڌو ماڊل ڪالون استعمال ڪريو جيئن Langdon تجويز ڪيو ۽ انسٽال ڪريو pip3؟ ايندڙ آٽوميشن کي ذهن ۾ رکندي، اهو معلوم ٿئي ٿو ته Ansible کي هلائڻ لاءِ پِپ انسٽال ڪرڻ جي ضرورت پوندي، ڇو ته پِپ ماڊل virtualenvs کي ڪسٽم پائپ ايگزيڪيوٽيبل سان سپورٽ نٿو ڪري.
توهان جي اختيار ۾ ڪم ڪندڙ python3 مترجم سان، توهان جاري ڪري سگهو ٿا Django جي انسٽاليشن جي عمل سان ۽ اسان جي ٻين حصن سان گڏ هڪ ڪم ڪندڙ نظام پڻ آهي. انٽرنيٽ تي ڪيترائي عمل درآمد جا اختيار موجود آھن. هتي ھڪڙو نسخو پيش ڪيو ويو آھي، پر صارف پنھنجي عمل کي استعمال ڪري سگھن ٿا.
اسان انسٽال ڪنداسين PostgreSQL ۽ Nginx ورزن موجود RHEL 8 ۾ ڊفالٽ طور Yum استعمال ڪندي.
sudo yum install nginx postgresql-server
PostgreSQL کي psycopg2 جي ضرورت پوندي، پر ان کي صرف هڪ مجازي ماحول ۾ موجود هجڻ جي ضرورت آهي، تنهنڪري اسان ان کي انسٽال ڪنداسين pip3 سان گڏ Django ۽ Gunicorn. پر پهرين اسان کي virtualenv قائم ڪرڻ جي ضرورت آهي.
جيانگو پروجيڪٽس کي انسٽال ڪرڻ لاءِ صحيح جڳھ چونڊڻ جي موضوع تي هميشه تمام گهڻو بحث مباحثو هوندو آهي، پر جڏهن شڪ هجي ته، توهان هميشه ڏانهن رخ ڪري سگهو ٿا لينڪس فائل سسٽم هيرارڪي معيار. خاص طور تي، FHS چوي ٿو ته /srv استعمال ڪيو ويندو آهي: "اسٽور ميزبان مخصوص ڊيٽا- ڊيٽا جيڪو سسٽم پيدا ڪري ٿو، جهڙوڪ ويب سرور ڊيٽا ۽ اسڪرپٽ، ايف ٽي پي سرورز تي ذخيرو ٿيل ڊيٽا، ۽ ڪنٽرول سسٽم ريپوزٽريز." ورزن (ايف ايڇ ايس ۾ ظاهر ٿئي ٿو. -2.3 ۾ 2004).
اهو بلڪل اسان جو معاملو آهي، تنهنڪري اسان هر شي کي / srv ۾ رکون ٿا، جيڪو اسان جي ايپليڪيشن استعمال ڪندڙ (Cloud-user) جي ملڪيت آهي.
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-setup اسڪرپٽ جيڪو نصب ٿيل آھي postgresql-server package. هي اسڪرپٽ توهان کي ڊيٽابيس ڪلستر انتظاميه سان لاڳاپيل بنيادي ڪم انجام ڏيڻ ۾ مدد ڪري ٿي، جهڙوڪ ڪلستر جي شروعات يا اپ گريڊ جو عمل. RHEL سسٽم تي نئين PostgreSQL مثال کي ترتيب ڏيڻ لاء، اسان کي حڪم هلائڻ جي ضرورت آهي:
sudo /usr/bin/postgresql-setup -initdb
توھان وري شروع ڪري سگھوٿا PostgreSQL استعمال ڪندي systemd، ڊيٽابيس ٺاھيو، ۽ Django ۾ ھڪڙو منصوبو سيٽ ڪريو. پوسٽگري ايس ايس ايل کي ٻيهر شروع ڪرڻ لاءِ ياد رکو ڪلائنٽ جي تصديق ڪنفيگريشن فائل ۾ تبديليون ڪرڻ کان پوءِ (عام طور تي pg_hba.conf) ايپليڪيشن استعمال ڪندڙ لاءِ پاسورڊ اسٽوريج ترتيب ڏيڻ لاءِ. جيڪڏھن توھان ٻين مشڪلاتن کي منهن ڏيو، پڪ ڪريو ته IPv4 ۽ IPv6 سيٽنگون pg_hba.conf فائل ۾ تبديل ڪريو.
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). هتي ڪيترائي عام مجموعا آهن، مثال طور، Apache HTTPD سان uWSGI يا Nginx سان Gunicorn.
ويب سرور گيٽ وي انٽرفيس جو ڪم ويب سرور کان درخواستن کي پٿون ويب فريم ورڪ ڏانهن منتقل ڪرڻ آهي. WSGI خوفناڪ ماضي جو هڪ رشتو آهي جڏهن CGI انجڻ جي چوڌاري هئا، ۽ اڄ WSGI حقيقي معيار آهي، بغير ويب سرور يا پٿون فريم ورڪ استعمال ڪيو ويو آهي. پر ان جي وسيع استعمال جي باوجود، انهن فريم ورڪ سان ڪم ڪرڻ وقت اڃا تائين ڪيترائي nuances آهن، ۽ ڪيتريون ئي چونڊون. انهي صورت ۾، اسان هڪ ساکٽ ذريعي Gunicorn ۽ Nginx جي وچ ۾ رابطي کي قائم ڪرڻ جي ڪوشش ڪنداسين.
جيئن ته اهي ٻئي حصا هڪ ئي سرور تي نصب ٿيل آهن، اچو ته نيٽ ورڪ ساکٽ جي بدران UNIX ساڪٽ استعمال ڪرڻ جي ڪوشش ڪريو. جيئن ته رابطي کي ڪنهن به صورت ۾ ساکٽ جي ضرورت آهي، اچو ته هڪ وڌيڪ قدم کڻڻ جي ڪوشش ڪريون ۽ سسٽم ڊي ذريعي Gunicorn لاءِ ساکٽ ايڪٽيويشن کي ترتيب ڏيو.
ساکٽ چالو ڪيل خدمتون ٺاهڻ جو عمل بلڪل سادو آهي. پهرين، هڪ يونٽ فائل ٺاهي وئي آهي جنهن ۾ هڪ ListenStream هدايتون شامل آهن انهي نقطي ڏانهن اشارو ڪندي جنهن تي UNIX ساکٽ ٺاهي ويندي، پوء خدمت لاء هڪ يونٽ فائل جنهن ۾ گهربل هدايت ساکٽ يونٽ فائل ڏانهن اشارو ڪندي. ان کان پوء، سروس يونٽ فائل ۾، اهو سڀ ڪجهه باقي رهي ٿو Gunicorn کي ورچوئل ماحول مان ڪال ڪرڻ ۽ UNIX ساکٽ ۽ جيانگو ايپليڪيشن لاءِ WSGI بائنڊنگ ٺاهڻ.
هتي يونٽ فائلن جا ڪجهه مثال آهن جيڪي توهان هڪ بنياد طور استعمال ڪري سگهو ٿا. پهرين اسان ساکٽ قائم ڪيو.
[Unit]
Description=Gunicorn WSGI socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
ھاڻي توھان کي ترتيب ڏيڻ جي ضرورت آھي Gunicorn daemon.
[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;
}
}
سسٽم ڊي استعمال ڪندي Gunicorn ساکٽ ۽ نينڪس شروع ڪريو ۽ توهان جاچ شروع ڪرڻ لاءِ تيار آهيو.
خراب گيٽ وي غلطي؟
جيڪڏهن توهان پنهنجي برائوزر ۾ ايڊريس داخل ڪريو ٿا، توهان کي گهڻو ڪري هڪ 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
اهو سڀ ڪجهه تنقيد ۽ رت جا ڳوڙها ٿي سگهي ٿو، پر اهو صرف پروٽوٽائپ کي ڊيب ڪرڻ آهي. اچو ته چيڪ کي غير فعال ڪريون بس پڪ ڪرڻ لاءِ ته اهو مسئلو آهي، جنهن کان پوءِ اسان هر شيءِ کي ان جي جاءِ تي واپس آڻينداسين.
برائوزر ۾ صفحي کي ريفريش ڪندي يا اسان جي ڪرل ڪمانڊ کي ٻيهر هلائڻ سان، توھان ڏسي سگھو ٿا 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 کي ڊيٽا لکڻ کان روڪي ٿو UNIX ساکٽ ۾ جيڪو Gunicorn پاران استعمال ڪيو ويو آهي. عام طور تي، اهڙين حالتن ۾، پاليسيون تبديل ٿيڻ شروع ٿينديون آهن، پر اڳتي هلي ٻيا چئلينج آهن. توھان پڻ ڊومين سيٽنگون تبديل ڪري سگھو ٿا پابندي واري ڊومين کان اجازت واري ڊومين ۾. ھاڻي اچو httpd_t کي اجازتن واري ڊومين ڏانھن. هي نينگڪس کي لازمي رسائي ڏيندو ۽ اسان اڳتي وڌڻ جي ڪم سان جاري رکي سگهون ٿا.
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
جيڪڏهن توهان گني ڪارن سروس جي حيثيت کي ڏسو يا پي ايس ڪمانڊ کي هلائيندا، توهان ڪنهن به هلندڙ عمل کي نه ڏسندا. اهو ڏسڻ ۾ اچي ٿو ته gunicorn ڪوشش ڪري رهيو آهي 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 باقي سسٽم لاءِ. جيڪڏھن توھان سمجھو ٿا ته ڪھڙي قسم جي رسائي جي حقيقي ايپليڪيشن جي ضرورت آھي، توھان تڪڙو ڳولي سگھوٿا انھن مسئلن کي حل ڪرڻ جو بھترين طريقو. پر ان وقت تائين، سسٽم کي محفوظ رکڻ ۽ جيانگو پروجيڪٽ جو واضح، قابل استعمال آڊٽ حاصل ڪرڻ بهتر آهي.
sudo ausearch -m AVC
ٿيو!
هڪ ڪم ڪندڙ جيانگو پروجيڪٽ ظاهر ٿيو آهي فرنٽ اينڊ تي ٻڌل آهي Nginx ۽ Gunicorn WSGI. اسان ترتيب ڏنو Python 3 ۽ PostgreSQL 10 RHEL 8 بيٽا مخزن مان. ھاڻي توھان اڳتي وڌي سگھوٿا ۽ Django ايپليڪيشنون ٺاھي سگھوٿا (يا صرف ترتيب ڏيو) يا RHEL 8 بيٽا ۾ موجود ٻيا اوزار ڳولي سگھوٿا ڪنفيگريشن جي عمل کي پاڻمرادو ڪرڻ لاءِ، ڪارڪردگي کي بھتر ڪرڻ، يا ھن ترتيب کي ڪنٽينرائيز ڪرڻ لاءِ.
جو ذريعو: www.habr.com