Workshop RHEL 8 Beta: სამუშაო ვებ აპლიკაციების შექმნა

RHEL 8 Beta სთავაზობს დეველოპერებს ბევრ ახალ ფუნქციას, რომელთა ჩამონათვალს შეიძლება დასჭირდეს გვერდები, თუმცა ახლის სწავლა ყოველთვის უკეთესია პრაქტიკაში, ამიტომ ქვემოთ გთავაზობთ სემინარს Red Hat Enterprise Linux 8 Beta-ზე დაფუძნებული აპლიკაციის ინფრასტრუქტურის რეალურად შექმნის შესახებ.

მოდით ავიღოთ Python, პოპულარული პროგრამირების ენა დეველოპერებს შორის, როგორც საფუძველი, Django-სა და PostgreSQL-ის კომბინაცია, საკმაოდ გავრცელებული კომბინაცია აპლიკაციების შესაქმნელად, და დავაკონფიგურიროთ RHEL 8 Beta მათთან მუშაობისთვის. შემდეგ ჩვენ დავამატებთ კიდევ რამდენიმე (არაკლასიფიცირებულ) ინგრედიენტს.

სატესტო გარემო შეიცვლება, რადგან საინტერესოა ავტომატიზაციის შესაძლებლობების შესწავლა, კონტეინერებთან მუშაობისა და მრავალი სერვერის მქონე გარემოს ცდის შესახებ. ახალი პროექტის დასაწყებად, შეგიძლიათ დაიწყოთ პატარა, მარტივი პროტოტიპის ხელით შექმნით, რათა ნახოთ ზუსტად რა უნდა მოხდეს და როგორ ურთიერთქმედებს ის, შემდეგ კი გადახვიდეთ ავტომატიზაციაზე და შექმნათ უფრო რთული კონფიგურაციები. დღეს ჩვენ ვსაუბრობთ ასეთი პროტოტიპის შექმნაზე.

დავიწყოთ RHEL 8 Beta VM სურათის განლაგებით. თქვენ შეგიძლიათ დააინსტალიროთ ვირტუალური მანქანა ნულიდან, ან გამოიყენოთ KVM სტუმრის სურათი, რომელიც ხელმისაწვდომია თქვენი Beta გამოწერით. სტუმრის გამოსახულების გამოყენებისას, თქვენ უნდა დააკონფიგურიროთ ვირტუალური CD, რომელიც შეიცავს მეტამონაცემებს და მომხმარებლის მონაცემებს ღრუბლის ინიციალიზაციისთვის (cloud-init). თქვენ არ გჭირდებათ რაიმე განსაკუთრებულის გაკეთება დისკის სტრუქტურასთან ან ხელმისაწვდომ პაკეტებთან; ნებისმიერი კონფიგურაცია ასე იქნება.

მოდით უფრო ახლოს მივხედოთ მთელ პროცესს.

ჯანგოს ინსტალაცია

Django-ს უახლესი ვერსიით, დაგჭირდებათ ვირტუალური გარემო (virtualenv) Python 3.5 ან უფრო ახალი ვერსიით. ბეტა შენიშვნებში ხედავთ, რომ Python 3.6 ხელმისაწვდომია, მოდით შევამოწმოთ, ეს მართლაც ასეა:

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

Red Hat აქტიურად იყენებს Python-ს, როგორც სისტემის ხელსაწყოების კომპლექტს RHEL-ში, რატომ არის ეს შედეგი?

ფაქტია, რომ Python-ის ბევრი დეველოპერი ჯერ კიდევ განიხილავს Python 2-დან Python 2-ზე გადასვლას, ხოლო თავად Python 3 აქტიური განვითარების პროცესშია და მუდმივად ჩნდება უფრო მეტი ახალი ვერსია. ამიტომ, სტაბილური სისტემის ინსტრუმენტების საჭიროების დასაკმაყოფილებლად, ხოლო მომხმარებლებს Python-ის სხვადასხვა ახალ ვერსიებზე წვდომის შეთავაზებისას, Python სისტემა გადავიდა ახალ პაკეტში და უზრუნველყო პითონის 2.7 და 3.6 ინსტალაციის შესაძლებლობა. დამატებითი ინფორმაცია ცვლილებებისა და მათი განხორციელების მიზეზების შესახებ შეგიძლიათ იხილოთ პუბლიკაციაში ლენგდონ უაიტის ბლოგი (ლენგდონ უაიტი).

ასე რომ, სამუშაო Python-ის მისაღებად საჭიროა მხოლოდ ორი პაკეტის ინსტალაცია, python3-pip-ით დამოკიდებულების სახით.

sudo yum install python36 python3-virtualenv

რატომ არ გამოიყენოთ პირდაპირი მოდულის ზარები, როგორც ლენგდონი გვთავაზობს და დააინსტალიროთ pip3? მომავალი ავტომატიზაციის გათვალისწინებით, ცნობილია, რომ Ansible-ს დასჭირდება პიპის დაყენება გასაშვებად, რადგან პიპ მოდული არ უჭერს მხარს virtualenv-ებს პერსონალური პიპ-შემსრულებელი ფაილით.

თქვენს განკარგულებაში მოქმედი python3 თარჯიმანით, შეგიძლიათ გააგრძელოთ Django-ს ინსტალაციის პროცესი და გქონდეთ სამუშაო სისტემა ჩვენს სხვა კომპონენტებთან ერთად. განხორციელების მრავალი ვარიანტი არსებობს ინტერნეტში. აქ არის ერთი ვერსია წარმოდგენილი, მაგრამ მომხმარებლებს შეუძლიათ გამოიყენონ საკუთარი პროცესები.

ჩვენ დავაინსტალირებთ PostgreSQL და Nginx ვერსიებს, რომლებიც ხელმისაწვდომია RHEL 8-ში ნაგულისხმევად Yum-ის გამოყენებით.

sudo yum install nginx postgresql-server

PostgreSQL დასჭირდება psycopg2, მაგრამ ის ხელმისაწვდომი უნდა იყოს მხოლოდ virtualenv გარემოში, ამიტომ ჩვენ დავაინსტალირებთ pip3-ის გამოყენებით Django-სა და Gunicorn-თან ერთად. მაგრამ ჯერ ჩვენ უნდა დავაყენოთ virtualenv.

ყოველთვის არის ბევრი კამათი Django პროექტების დასაყენებლად შესაფერისი ადგილის არჩევის თემაზე, მაგრამ როდესაც ეჭვი გეპარებათ, ყოველთვის შეგიძლიათ მიმართოთ Linux ფაილური სისტემის იერარქიის სტანდარტს. კონკრეტულად, FHS ამბობს, რომ /srv გამოიყენება: "ჰოსტის სპეციფიკური მონაცემების შესანახად - მონაცემები, რომლებსაც სისტემა აწარმოებს, როგორიცაა ვებ სერვერის მონაცემები და სკრიპტები, FTP სერვერებზე შენახული მონაცემები და სისტემის საცავების კონტროლი." ვერსიები (ჩნდება FHS-ში. -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-ის საწყისი ინსტალაციისას არის postgresql-setup სკრიპტი, რომელიც დაინსტალირებულია postgresql-სერვერის პაკეტთან ერთად. ეს სკრიპტი დაგეხმარებათ შეასრულოთ ძირითადი ამოცანები, რომლებიც დაკავშირებულია მონაცემთა ბაზის კლასტერის ადმინისტრირებასთან, როგორიცაა კლასტერის ინიციალიზაცია ან განახლების პროცესი. ახალი PostgreSQL ინსტანციის კონფიგურაციისთვის RHEL სისტემაზე, ჩვენ უნდა შევასრულოთ ბრძანება:

sudo /usr/bin/postgresql-setup -initdb

ამის შემდეგ შეგიძლიათ დაიწყოთ PostgreSQL systemd-ის გამოყენებით, შექმნათ მონაცემთა ბაზა და დააყენოთ პროექტი Django-ში. დაიმახსოვრეთ, გადატვირთოთ PostgreSQL კლიენტის ავტორიზაციის კონფიგურაციის ფაილში (ჩვეულებრივ 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-ით.

ვებ სერვერის კარიბჭის ინტერფეისის ამოცანაა ვებ სერვერიდან მოთხოვნების გადაგზავნა Python ვებ ჩარჩოში. WSGI არის საშინელი წარსულის რელიქვია, როდესაც CGI ძრავები არსებობდა და დღეს WSGI არის დე ფაქტო სტანდარტი, მიუხედავად გამოყენებული ვებ სერვერისა თუ Python ჩარჩოსა. მაგრამ მიუხედავად მისი ფართო გამოყენებისა, ჯერ კიდევ ბევრი ნიუანსია ამ ჩარჩოებთან მუშაობისას და ბევრი არჩევანი. ამ შემთხვევაში, ჩვენ შევეცდებით დავამყაროთ ურთიერთქმედება Gunicorn-სა და Nginx-ს შორის სოკეტის საშუალებით.

ვინაიდან ორივე კომპონენტი დაინსტალირებულია ერთ სერვერზე, მოდით ვცადოთ UNIX სოკეტის გამოყენება ქსელის სოკეტის ნაცვლად. ვინაიდან კომუნიკაცია ნებისმიერ შემთხვევაში მოითხოვს სოკეტს, მოდით ვცადოთ კიდევ ერთი ნაბიჯის გადადგმა და Gunicorn-ისთვის სოკეტის აქტივაციის კონფიგურაცია systemd-ის საშუალებით.

სოკეტის გააქტიურებული სერვისების შექმნის პროცესი საკმაოდ მარტივია. ჯერ იქმნება ერთეული ფაილი, რომელიც შეიცავს ListenStream დირექტივას, რომელიც მიუთითებს იმ წერტილზე, სადაც შეიქმნება UNIX სოკეტი, შემდეგ ერთეული ფაილი სერვისისთვის, რომელშიც Requires დირექტივა მიუთითებს სოკეტის ერთეულის ფაილზე. შემდეგ, სერვისის ერთეულის ფაილში, რჩება მხოლოდ Gunicorn-ის გამოძახება ვირტუალური გარემოდან და შექმნათ WSGI სავალდებულო UNIX სოკეტისთვის და Django აპლიკაციისთვის.

აქ მოცემულია ერთეული ფაილების მაგალითები, რომლებიც შეგიძლიათ გამოიყენოთ როგორც საფუძველი. პირველი ჩვენ დავაყენეთ სოკეტი.

[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;
   }
}

გაუშვით Gunicorn სოკეტი და Nginx systemd-ის გამოყენებით და მზად ხართ ტესტირების დასაწყებად.

ცუდი კარიბჭის შეცდომა?

თუ თქვენ შეიყვანთ მისამართს თქვენს ბრაუზერში, დიდი ალბათობით მიიღებთ 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-ს გავტესტავთ, ცარიელ პასუხს მივიღებთ.

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

SELinux ხელს უშლის Nginx-ს მონაცემების ჩაწერაში UNIX სოკეტში, რომელსაც იყენებს Gunicorn. როგორც წესი, ასეთ შემთხვევებში პოლიტიკის შეცვლა იწყება, მაგრამ წინ სხვა გამოწვევებია. თქვენ ასევე შეგიძლიათ შეცვალოთ დომენის პარამეტრები შეზღუდვის დომენიდან ნებართვის დომენზე. ახლა გადავიტანოთ 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

თუ შეხედავთ Gunicorn სერვისის სტატუსს ან გაუშვით ps ბრძანება, ვერ ნახავთ რაიმე გაშვებულ პროცესს. როგორც ჩანს, გუნიკორნი ცდილობს პითონის თარჯიმანზე წვდომას ჩვენს virtualenv გარემოში, შესაძლოა მუშა სკრიპტების გასაშვებად. ახლა მოდით აღვნიშნოთ ეს ორი შესრულებადი ფაილი და შევამოწმოთ, შეგვიძლია თუ არა ჩვენი 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

მოხდა!

გამოჩნდა სამუშაო Django პროექტი ფრონტენტით, რომელიც დაფუძნებულია Nginx-სა და Gunicorn WSGI-ზე. ჩვენ დავაკონფიგურირეთ Python 3 და PostgreSQL 10 RHEL 8 ბეტა საცავებიდან. ახლა თქვენ შეგიძლიათ წინ წახვიდეთ და შექმნათ (ან უბრალოდ განათავსოთ) Django აპლიკაციები ან შეისწავლოთ სხვა ხელმისაწვდომი ინსტრუმენტები RHEL 8 Beta-ში კონფიგურაციის პროცესის ავტომატიზაციისთვის, მუშაობის გასაუმჯობესებლად ან თუნდაც ამ კონფიგურაციის კონტეინერზე.

წყარო: www.habr.com