សិក្ខាសាលា RHEL 8 Beta៖ ការកសាងកម្មវិធីគេហទំព័រដែលកំពុងដំណើរការ

RHEL 8 Beta ផ្តល់ជូនអ្នកអភិវឌ្ឍន៍នូវមុខងារថ្មីៗជាច្រើន ការចុះបញ្ជីដែលអាចយកទំព័របាន ទោះជាយ៉ាងណាក៏ដោយ ការរៀនអ្វីដែលថ្មីគឺតែងតែប្រសើរជាងក្នុងការអនុវត្ត ដូច្នេះខាងក្រោមនេះ យើងផ្តល់ជូននូវសិក្ខាសាលាស្តីពីការបង្កើតហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីដោយផ្អែកលើ Red Hat Enterprise Linux 8 Beta ។

ចូរយក Python ដែលជាភាសាសរសេរកម្មវិធីដ៏ពេញនិយមក្នុងចំណោមអ្នកអភិវឌ្ឍន៍ ជាមូលដ្ឋាន ការរួមបញ្ចូលគ្នានៃ Django និង PostgreSQL ដែលជាការរួមបញ្ចូលគ្នាដ៏សាមញ្ញមួយសម្រាប់បង្កើតកម្មវិធី និងកំណត់រចនាសម្ព័ន្ធ RHEL 8 Beta ដើម្បីធ្វើការជាមួយពួកគេ។ បន្ទាប់មក យើង​នឹង​បន្ថែម​គ្រឿងផ្សំ​ពីរ​បី​ទៀត (មិន​បាន​ចាត់ថ្នាក់)។

បរិយាកាសសាកល្បងនឹងផ្លាស់ប្តូរ ព្រោះវាគួរឱ្យចាប់អារម្មណ៍ក្នុងការស្វែងយល់ពីលទ្ធភាពនៃស្វ័យប្រវត្តិកម្ម ធ្វើការជាមួយកុងតឺន័រ និងសាកល្បងបរិស្ថានជាមួយម៉ាស៊ីនមេច្រើន។ ដើម្បីចាប់ផ្តើមជាមួយគម្រោងថ្មី អ្នកអាចចាប់ផ្តើមដោយបង្កើតគំរូតូចមួយដោយដៃផ្ទាល់ ដូច្នេះអ្នកអាចឃើញច្បាស់នូវអ្វីដែលត្រូវកើតឡើង និងរបៀបដែលវាមានអន្តរកម្ម ហើយបន្ទាប់មកបន្តទៅស្វ័យប្រវត្តិ និងបង្កើតការកំណត់រចនាសម្ព័ន្ធស្មុគស្មាញបន្ថែមទៀត។ សព្វថ្ងៃនេះយើងកំពុងនិយាយអំពីការបង្កើតគំរូបែបនេះ។

ចូរចាប់ផ្តើមដោយការដាក់ឱ្យប្រើប្រាស់រូបភាព RHEL 8 Beta VM ។ អ្នកអាចដំឡើងម៉ាស៊ីននិម្មិតពីទទេ ឬប្រើរូបភាពភ្ញៀវ KVM ដែលមានជាមួយការជាវបេតារបស់អ្នក។ នៅពេលប្រើរូបភាពភ្ញៀវ អ្នកនឹងត្រូវកំណត់រចនាសម្ព័ន្ធស៊ីឌីនិម្មិតដែលនឹងមានទិន្នន័យមេតា និងទិន្នន័យអ្នកប្រើប្រាស់សម្រាប់ការចាប់ផ្តើមពពក (cloud-init) ។ អ្នកមិនចាំបាច់ធ្វើអ្វីពិសេសជាមួយរចនាសម្ព័ន្ធថាស ឬកញ្ចប់ដែលមានទេ ការកំណត់រចនាសម្ព័ន្ធណាមួយនឹងធ្វើ។

ចូរយើងពិនិត្យមើលកាន់តែដិតដល់នូវដំណើរការទាំងមូល។

ការដំឡើង Django

ជាមួយនឹងកំណែថ្មីបំផុតរបស់ 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 ត្រូវបានផ្លាស់ប្តូរទៅក្នុងកញ្ចប់ថ្មី និងផ្តល់លទ្ធភាពក្នុងការដំឡើងទាំង Python 2.7 និង 3.6 ។ ព័ត៌មាន​បន្ថែម​អំពី​ការ​ផ្លាស់​ប្តូរ និង​មូល​ហេតុ​ដែល​ពួក​គេ​ត្រូវ​បាន​គេ​ធ្វើ​ឡើង​អាច​រក​ឃើញ​នៅ​ក្នុង​ការ​បោះពុម្ព​ផ្សាយ​នៅ​ក្នុង ប្លុករបស់ Langdon White (Langdon White) ។

ដូច្នេះ ដើម្បីទទួលបាន Python ដំណើរការ អ្នកគ្រាន់តែដំឡើងកញ្ចប់ពីរប៉ុណ្ណោះ ដោយរួមបញ្ចូល python3-pip ជាការពឹងផ្អែក។

sudo yum install python36 python3-virtualenv

ហេតុអ្វីមិនប្រើការហៅម៉ូឌុលដោយផ្ទាល់ដូចដែល Langdon ណែនាំ និងដំឡើង pip3? ដោយចងចាំអំពីស្វ័យប្រវត្តិកម្មនាពេលខាងមុខ វាត្រូវបានគេដឹងថា Ansible នឹងតម្រូវឱ្យដំឡើង pip ដើម្បីដំណើរការ ចាប់តាំងពីម៉ូឌុល pip មិនគាំទ្រ virtualenvs ជាមួយនឹង pip ផ្ទាល់ខ្លួនដែលអាចប្រតិបត្តិបាន។

ជាមួយនឹងអ្នកបកប្រែ python3 ដែលកំពុងធ្វើការនៅការចោលរបស់អ្នក អ្នកអាចបន្តជាមួយនឹងដំណើរការដំឡើង Django និងមានប្រព័ន្ធការងាររួមជាមួយនឹងសមាសធាតុផ្សេងទៀតរបស់យើង។ មានជម្រើសអនុវត្តជាច្រើនដែលមាននៅលើអ៊ីនធឺណិត។ មានកំណែមួយបង្ហាញនៅទីនេះ ប៉ុន្តែអ្នកប្រើប្រាស់អាចប្រើដំណើរការផ្ទាល់ខ្លួនរបស់ពួកគេ។

យើងនឹងដំឡើងកំណែ PostgreSQL និង Nginx ដែលមាននៅក្នុង RHEL 8 តាមលំនាំដើមដោយប្រើ Yum ។

sudo yum install nginx postgresql-server

PostgreSQL នឹងតម្រូវឱ្យមាន psycopg2 ប៉ុន្តែវាត្រូវតែមាននៅក្នុងបរិស្ថាននិម្មិតតែប៉ុណ្ណោះ ដូច្នេះយើងនឹងដំឡើងវាដោយប្រើ pip3 រួមជាមួយ Django និង Gunicorn ។ ប៉ុន្តែដំបូងយើងត្រូវរៀបចំ virtualenv ។

វាតែងតែមានការជជែកវែកញែកជាច្រើនលើប្រធានបទនៃការជ្រើសរើសកន្លែងដែលត្រឹមត្រូវក្នុងការដំឡើងគម្រោង Django ប៉ុន្តែនៅពេលមានការសង្ស័យ អ្នកអាចងាកទៅរកស្តង់ដារឋានានុក្រមប្រព័ន្ធឯកសារលីនុច។ ជាពិសេស 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-server ។ ស្គ្រីបនេះជួយអ្នកធ្វើកិច្ចការមូលដ្ឋានដែលទាក់ទងនឹងការគ្រប់គ្រងចង្កោមមូលដ្ឋានទិន្នន័យ ដូចជាការចាប់ផ្តើមចង្កោម ឬដំណើរការធ្វើឱ្យប្រសើរឡើង។ ដើម្បីកំណត់រចនាសម្ព័ន្ធ 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? វ៉ៃ?

ម៉ាស៊ីនមេអភិវឌ្ឍន៍មានប្រយោជន៍សម្រាប់ការធ្វើតេស្ត ប៉ុន្តែដើម្បីដំណើរការកម្មវិធី អ្នកត្រូវតែកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ និងប្រូកស៊ីសមរម្យសម្រាប់ចំណុចប្រទាក់ Web Server Gateway Interface (WSGI) ។ មានបន្សំទូទៅជាច្រើនឧទាហរណ៍ Apache HTTPD ជាមួយ uWSGI ឬ Nginx ជាមួយ Gunicorn ។

ការងាររបស់ Web Server Gateway Interface គឺបញ្ជូនសំណើពី web server ទៅកាន់ web framework Python។ WSGI គឺជាវត្ថុបុរាណនៃអតីតកាលដ៏អាក្រក់នៅពេលដែលម៉ាស៊ីន CGI នៅជុំវិញ ហើយសព្វថ្ងៃនេះ WSGI គឺជាស្តង់ដារជាក់ស្តែង ដោយមិនគិតពី web server ឬ Python framework ដែលត្រូវបានប្រើប្រាស់។ ប៉ុន្តែទោះបីជាការប្រើប្រាស់យ៉ាងទូលំទូលាយក៏ដោយ ក៏នៅតែមានភាពខុសប្លែកគ្នាជាច្រើននៅពេលធ្វើការជាមួយក្របខ័ណ្ឌទាំងនេះ និងមានជម្រើសជាច្រើន។ ក្នុងករណីនេះ យើងនឹងព្យាយាមបង្កើតអន្តរកម្មរវាង Gunicorn និង Nginx តាមរយៈរន្ធមួយ។

ដោយសារសមាសធាតុទាំងពីរនេះត្រូវបានដំឡើងនៅលើម៉ាស៊ីនមេតែមួយ សូមសាកល្បងប្រើរន្ធ UNIX ជំនួសឱ្យរន្ធបណ្តាញ។ ដោយសារការប្រាស្រ័យទាក់ទងគ្នាទាមទាររន្ធក្នុងករណីណាក៏ដោយ តោះព្យាយាមបោះជំហានមួយជំហានទៀត ហើយកំណត់រចនាសម្ព័ន្ធការធ្វើឱ្យសកម្មរន្ធសម្រាប់ Gunicorn តាមរយៈប្រព័ន្ធ។

ដំណើរការនៃការបង្កើត socket activated services គឺសាមញ្ញណាស់។ ដំបូង ឯកសារឯកតាត្រូវបានបង្កើតដែលមានការណែនាំ ListenStream ចង្អុលទៅចំណុចដែលរន្ធ UNIX នឹងត្រូវបានបង្កើត បន្ទាប់មកឯកសារឯកតាសម្រាប់សេវាកម្មដែលសេចក្តីណែនាំតម្រូវនឹងចង្អុលទៅឯកសារឯកតារន្ធ។ បន្ទាប់មក នៅក្នុងឯកសារឯកតាសេវាកម្ម អ្វីដែលនៅសេសសល់គឺត្រូវហៅ 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 ។ វាអាចបណ្តាលមកពីការអនុញ្ញាតរន្ធយូនីកដែលបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ ឬវាអាចបណ្តាលមកពីបញ្ហាស្មុគស្មាញបន្ថែមទៀតទាក់ទងនឹងការគ្រប់គ្រងការចូលប្រើនៅក្នុង 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 នោះទេ ប៉ុន្តែពួកគេមិនមានអ្វីថ្មីនោះទេ។ មនុស្សជាច្រើនថែមទាំងបានធ្វើការជាមួយពួកគេដោយមិនដឹងខ្លួន។ នៅពេលដែលគោលការណ៍ត្រូវបានបង្កើតដោយផ្អែកលើសារសវនកម្ម គោលការណ៍ដែលបានបង្កើតតំណាងឱ្យដែនដែលបានដោះស្រាយ។ ចូរយើងព្យាយាមបង្កើតគោលការណ៍អនុញ្ញាតដ៏សាមញ្ញមួយ។

ដើម្បីបង្កើតដែនដែលបានអនុញ្ញាតជាក់លាក់សម្រាប់ហ្គីនខន អ្នកត្រូវការគោលការណ៍មួយចំនួន ហើយអ្នកក៏ត្រូវសម្គាល់ឯកសារដែលសមរម្យផងដែរ។ លើសពីនេះ ឧបករណ៍គឺត្រូវការជាចាំបាច់ដើម្បីប្រមូលផ្តុំគោលនយោបាយថ្មី។

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 អ្នកនឹងមិនឃើញដំណើរការដែលកំពុងដំណើរការទេ។ វាហាក់ដូចជា gunicorn កំពុងព្យាយាមចូលប្រើកម្មវិធីបកប្រែ Python នៅក្នុងបរិស្ថាន virtualenv របស់យើង ដែលអាចដំណើរការស្គ្រីបកម្មករ។ ដូច្នេះឥឡូវនេះ ចូរយើងសម្គាល់ឯកសារដែលអាចប្រតិបត្តិបានទាំងពីរនេះហើយពិនិត្យមើលថាតើយើងអាចបើកទំព័រសាកល្បង 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 ។ យើងបានកំណត់រចនាសម្ព័ន្ធ Python 3 និង PostgreSQL 10 ពីឃ្លាំង RHEL 8 Beta ។ ឥឡូវនេះ អ្នកអាចឆ្ពោះទៅមុខ និងបង្កើត (ឬគ្រាន់តែដាក់ពង្រាយ) កម្មវិធី Django ឬស្វែងរកឧបករណ៍ដែលមានផ្សេងទៀតនៅក្នុង RHEL 8 Beta ដើម្បីធ្វើស្វ័យប្រវត្តិកម្មដំណើរការកំណត់រចនាសម្ព័ន្ធ កែលម្អការអនុវត្ត ឬសូម្បីតែផ្ទុកការកំណត់រចនាសម្ព័ន្ធនេះ។

ប្រភព: www.habr.com