RHEL 8 ቤታ አውደ ጥናት፡ የሚሰሩ የድር መተግበሪያዎችን መገንባት

RHEL 8 ቤታ ለገንቢዎች ብዙ አዳዲስ ባህሪያትን ያቀርባል, ዝርዝሩ ገጾችን ሊወስድ ይችላል, ነገር ግን አዳዲስ ነገሮችን መማር ሁልጊዜ በተግባር የተሻለ ነው, ስለዚህ ከዚህ በታች በ Red Hat Enterprise Linux 8 Beta ላይ የተመሰረተ የመተግበሪያ መሠረተ ልማትን በትክክል ስለመፍጠር አውደ ጥናት አቅርበናል.

RHEL 8 ቤታ አውደ ጥናት፡ የሚሰሩ የድር መተግበሪያዎችን መገንባት

በገንቢዎች ዘንድ ታዋቂ የሆነውን የፕሮግራም አወጣጥ ቋንቋ ፓይዘንን እንደ መሰረት አድርገን የDjango እና PostgreSQL ጥምር፣ አፕሊኬሽኖችን ለመፍጠር በጣም የተለመደ ጥምረት እና RHEL 8 Beta ን ከነሱ ጋር እናዋቅር። ከዚያም ሁለት ተጨማሪ (ያልተመደቡ) ንጥረ ነገሮችን እንጨምራለን.

የሙከራ አካባቢው ይለወጣል፣ ምክንያቱም አውቶሜሽን፣ ከእቃ መያዣዎች ጋር አብሮ መስራት እና አካባቢዎችን ከበርካታ አገልጋዮች ጋር መሞከር አስደሳች ስለሆነ። በአዲስ ፕሮጀክት ለመጀመር፣ ምን መሆን እንዳለበት እና እንዴት እንደሚገናኝ በትክክል ማየት እንዲችሉ ትንሽ እና ቀላል ፕሮቶታይፕ በእጅ በመፍጠር መጀመር ይችላሉ እና ከዚያ ወደ አውቶማቲክ እና የበለጠ ውስብስብ ውቅሮችን መፍጠር ይችላሉ። ዛሬ ስለ እንደዚህ ዓይነት ፕሮቶታይፕ መፈጠር እየተነጋገርን ነው.

የ RHEL 8 ቤታ ቪኤም ምስልን በማሰማራት እንጀምር። ምናባዊ ማሽንን ከባዶ መጫን ወይም ከቅድመ-ይሁንታ ምዝገባዎ ጋር የሚገኘውን የKVM እንግዳ ምስል መጠቀም ይችላሉ። የእንግዳ ምስል ሲጠቀሙ ሜታዳታ እና የተጠቃሚ ውሂብ ለCloud ማስጀመሪያ (cloud-init) የያዘ ምናባዊ ሲዲ ማዋቀር ያስፈልግዎታል። በዲስክ መዋቅር ወይም በሚገኙ ጥቅሎች ልዩ ነገር ማድረግ አያስፈልግዎትም፤ ማንኛውም ውቅር ይሰራል።

አጠቃላይ ሂደቱን በጥልቀት እንመልከተው።

ጃንጎን በመጫን ላይ

በአዲሱ የጃንጎ ስሪት፣ ከፓይዘን 3.5 ወይም ከዚያ በላይ ያለው ምናባዊ አካባቢ (virtualenv) ያስፈልግዎታል። በቅድመ-ይሁንታ ማስታወሻዎች ውስጥ Python 3.6 እንዳለ ማየት ይችላሉ፣ ይህ በእርግጥ ይህ መሆኑን እንፈትሽ፡

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

ቀይ ኮፍያ Pythonን በRHEL ውስጥ እንደ የሥርዓት መሣሪያ ስብስብ በንቃት ይጠቀማል፣ ታዲያ ይህ ለምን ያስገኛል?

እውነታው ግን ብዙ የፓይዘን አዘጋጆች ከፓይዘን 2 ወደ ፓይዘን 2 የሚደረገውን ሽግግር እያሰላሰሉ ነው ፣ እሱ ራሱ ፓይዘን 3 በንቃት ልማት ላይ ነው ፣ እና ብዙ እና ተጨማሪ አዳዲስ ስሪቶች በየጊዜው እየታዩ ነው። ስለዚህ፣ ለተጠቃሚዎች የተለያዩ አዲስ የፓይዘን ስሪቶችን ሲያገኙ የተረጋጋ የስርዓት መሳሪያዎችን ፍላጎት ለማሟላት፣ ሲስተም Python ወደ አዲስ ጥቅል ተወስዶ ሁለቱንም Python 2.7 እና 3.6 የመጫን ችሎታ አቅርቧል። ስለ ለውጦቹ እና ለምን እንደተደረጉ ተጨማሪ መረጃ በህትመት ውስጥ ይገኛል። የላንግዶን ኋይት ብሎግ (ላንግዶን ነጭ)

ስለዚህ፣ Pythonን ለመስራት ሁለት ፓኬጆችን ብቻ መጫን ያስፈልግዎታል፣ python3-pip እንደ ጥገኝነት ተካቷል።

sudo yum install python36 python3-virtualenv

ለምን እንደ ላንግዶን እንደሚጠቁመው የቀጥታ ሞጁል ጥሪዎችን አይጠቀሙ እና pip3 ን አይጫኑም? የመጪውን አውቶሜትሽን ከግምት ውስጥ በማስገባት፣ የፓይፕ ሞጁሉ ብጁ ፒፕ ፈጻሚውን ቨርቹዋልንቭስ ስለማይደግፍ Ansible ፓይፕ እንዲሰራ እንደሚያስፈልግ ይታወቃል።

በሚሰራ python3 አስተርጓሚ አማካኝነት በጃንጎ የመጫን ሂደት መቀጠል እና ከሌሎች ክፍሎቻችን ጋር የአሰራር ስርዓት እንዲኖርዎት ማድረግ ይችላሉ። በይነመረብ ላይ ብዙ የማስፈጸሚያ አማራጮች አሉ። እዚህ የቀረበው አንድ ስሪት አለ, ነገር ግን ተጠቃሚዎች የራሳቸውን ሂደቶች መጠቀም ይችላሉ.

Yumን በመጠቀም በ RHEL 8 የሚገኙትን PostgreSQL እና Nginx ስሪቶችን በነባሪ እንጭነዋለን።

sudo yum install nginx postgresql-server

PostgreSQL psycopg2 ያስፈልገዋል፣ነገር ግን መገኘት ያለበት በቨርችዋልኤንቭ አካባቢ ብቻ ነው፣ስለዚህ ፒፕ3ን በመጠቀም ከጃንጎ እና ጉኒኮርን ጋር እንጭነዋለን። ግን መጀመሪያ ቨርቹሪኔቭን ማዘጋጀት አለብን።

የጃንጎ ፕሮጄክቶችን ለመትከል ትክክለኛውን ቦታ በመምረጥ ርዕስ ላይ ሁል ጊዜ ብዙ ክርክሮች አሉ ፣ ግን ጥርጣሬ ሲኖርዎት ሁል ጊዜ ወደ ሊኑክስ ፋይል ስርዓት ተዋረድ ደረጃ መዞር ይችላሉ። በተለይም FHS እንዲህ ይላል /srv ለ: "አስተናጋጅ-ተኮር ውሂብ - ስርዓቱ የሚያመነጨውን እንደ የድር አገልጋይ ውሂብ እና ስክሪፕቶች, በኤፍቲፒ አገልጋዮች ላይ የተከማቸ ውሂብ እና የስርዓት ማከማቻዎችን ለመቆጣጠር" ስሪቶች (በ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 ን ሲጭን አንድ ነገር ማስታወስ ያለብዎት ነገር ቢኖር በፖስትግሬስql-አገልጋይ ፓኬጅ የተጫነው የፖስትግሬስql ማዋቀር ስክሪፕት ነው። ይህ ስክሪፕት ከዳታቤዝ ክላስተር አስተዳደር ጋር የተያያዙ እንደ ክላስተር ማስጀመሪያ ወይም የማሻሻያ ሂደት ያሉ መሰረታዊ ተግባራትን እንዲያከናውኑ ያግዝዎታል። አዲስ የ PostgreSQL ምሳሌን በRHEL ስርዓት ላይ ለማዋቀር ትዕዛዙን ማስኬድ አለብን፡-

sudo /usr/bin/postgresql-setup -initdb

ከዚያ systemd ን በመጠቀም PostgreSQL ን መጀመር፣ ዳታቤዝ መፍጠር እና በጃንጎ ውስጥ ፕሮጀክት ማዘጋጀት ይችላሉ። ለመተግበሪያው ተጠቃሚ የይለፍ ቃል ማከማቻን ለማዋቀር በደንበኛው የማረጋገጫ ውቅር ፋይል (በተለምዶ 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? ዋይ?

የልማት አገልጋዩ ለሙከራ ይጠቅማል፣ ነገር ግን አፕሊኬሽኑን ለማስኬድ ተገቢውን አገልጋይ እና ፕሮክሲ ለድር አገልጋይ ጌትዌይ በይነገጽ (WSGI) ማዋቀር አለብዎት። ብዙ የተለመዱ ጥምረቶች አሉ፣ ለምሳሌ Apache HTTPD ከ uWSGI ወይም Nginx ከGunicorn ጋር።

የዌብ ሰርቨር ጌትዌይ በይነገጽ ስራ ከድር አገልጋይ ጥያቄዎችን ወደ ፓይዘን ድር ማዕቀፍ ማስተላለፍ ነው። WSGI የሲጂአይ ሞተሮች በነበሩበት ጊዜ ያለፈው አስከፊ ታሪክ ቅርስ ነው፣ እና ዛሬ WSGI የዌብ አገልጋይ ወይም የፓይዘን ማዕቀፍ ምንም ይሁን ምን የእውነተኛ ደረጃ ነው። ግን በሰፊው ጥቅም ላይ ቢውልም ፣ ከእነዚህ ማዕቀፎች ጋር ሲሰሩ አሁንም ብዙ ልዩነቶች እና ብዙ ምርጫዎች አሉ። በዚህ አጋጣሚ በGunicorn እና Nginx መካከል በሶኬት በኩል መስተጋብር ለመፍጠር እንሞክራለን።

እነዚህ ሁለቱም ክፍሎች በአንድ አገልጋይ ላይ ስለተጫኑ፣ ከኔትወርክ ሶኬት ይልቅ UNIX ሶኬት ለመጠቀም እንሞክር። በማንኛውም ሁኔታ ግንኙነቱ ሶኬት ስለሚያስፈልገው አንድ ተጨማሪ እርምጃ ለመውሰድ እንሞክር እና ለGunicorn በ systemd የሶኬት ማግበርን እናዋቅር።

የሶኬት ገቢር አገልግሎቶችን የመፍጠር ሂደት በጣም ቀላል ነው። በመጀመሪያ፣ የዩኒክስ ሶኬት የሚፈጠርበትን ነጥብ የሚያመለክተው የ ListenStream መመሪያን የያዘ የዩኒት ፋይል ይፈጠራል፣ ከዚያም የሚያስፈልገው የአገልግሎት ክፍል ፋይል ወደ ሶኬት ክፍል ፋይል ይጠቁማል። ከዚያም በአገልግሎት ክፍል ፋይል ውስጥ የቀረው ጉኒኮርን ከምናባዊው አካባቢ መደወል እና ለ 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 {
   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ን በቀጥታ ከሞከርን ባዶ መልስ እናገኛለን።

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

ይህ የሚሆነው ለምን እንደሆነ እንወቅ። መዝገቡን ከከፈቱ ችግሩ ከ SELinux ጋር የተዛመደ መሆኑን ያያሉ። እኛ ምንም ፖሊሲ ያልተፈጠረለትን ዲሞን እየሰራን ስለሆነ እንደ init_t ምልክት ተደርጎበታል። ይህንን ንድፈ ሐሳብ በተግባር እንፈትነው።

sudo setenforce 0

ይህ ሁሉ ትችት እና የደም እንባ ሊያስከትል ይችላል, ነገር ግን ይህ ፕሮቶታይፕን ማረም ብቻ ነው. ችግሩ ይህ መሆኑን ለማረጋገጥ ብቻ ቼኩን እናሰናክለው ከዚያ በኋላ ሁሉንም ነገር ወደ ቦታው እንመልሰዋለን።

ገጹን በአሳሹ ውስጥ በማደስ ወይም የኛን ከርል ትዕዛዙን እንደገና በማስጀመር የጃንጎን የሙከራ ገጽ ማየት ይችላሉ።

ስለዚህ ፣ ሁሉም ነገር እንደሚሰራ እና ምንም ተጨማሪ የፍቃድ ችግሮች እንደሌሉ ካረጋገጥን በኋላ SELinuxን እንደገና እናነቃለን።

sudo setenforce 1

በአሁኑ ጊዜ ትክክለኛው የጃንጎ መተግበሪያ ስለሌለ ጉኒኮርን ምን ማግኘት እንደሚፈልግ እና ምን መድረስ እንዳለበት የሚገልጽ ሙሉ ካርታ ስለሌለ እዚህ ከሴፖልገን ጋር ስለ ኦዲት2allow ወይም ማንቂያ ላይ የተመሰረቱ ፖሊሲዎችን ለመፍጠር አልናገርም። ስለዚህ, ስርዓቱን ለመጠበቅ 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

በ/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 ትዕዛዙን ካስኬዱ ምንም አሂድ ሂደቶችን አያዩም። ጉኒኮርን የፓይዘን አስተርጓሚውን በእኛ ቨርችዋልኤንቭ አካባቢ ለማግኘት እየሞከረ ያለ ይመስላል፣ ምናልባትም የሰራተኛ ስክሪፕቶችን ለማስኬድ። ስለዚህ አሁን እነዚህን ሁለት ሊተገበሩ የሚችሉ ፋይሎችን ምልክት እናድርግ እና የጃንጎን የሙከራ ገጻችንን መክፈት እንደምንችል እንፈትሽ።

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

አዲሱ መለያ ከመመረጡ በፊት የጉኒኮርን አገልግሎት እንደገና መጀመር አለበት። ወዲያውኑ እንደገና ማስጀመር ወይም አገልግሎቱን ማቆም እና በአሳሹ ውስጥ ጣቢያውን ሲከፍቱ ሶኬቱ እንዲጀምር ማድረግ ይችላሉ. ps በመጠቀም ሂደቶች ትክክለኛ መለያዎችን መቀበላቸውን ያረጋግጡ።

ps -efZ | grep gunicorn

በኋላ መደበኛ የSELinux ፖሊሲ መፍጠርን አይርሱ!

የAVC መልዕክቶችን አሁን ከተመለከቱ፣ የመጨረሻው መልእክት ከመተግበሪያው ጋር ለተያያዙት ነገሮች ሁሉ ፍቃደኛ=1 እና ለቀሪው ስርዓት ፍቀድ=0 ይዟል። አንድ እውነተኛ መተግበሪያ ምን ዓይነት መዳረሻ እንደሚያስፈልገው ከተረዱ, እንደዚህ ያሉ ችግሮችን ለመፍታት ምርጡን መንገድ በፍጥነት ማግኘት ይችላሉ. ግን እስከዚያ ድረስ የስርዓቱን ደህንነት መጠበቅ እና የጃንጎ ፕሮጀክት ግልጽ የሆነ ጥቅም ላይ ሊውል የሚችል ኦዲት ማግኘት ጥሩ ነው።

sudo ausearch -m AVC

ተከሰተ!

የሚሰራ የጃንጎ ፕሮጀክት በNginx እና Gunicorn WSGI ላይ የተመሰረተ የፊት ለፊት ገፅታ ታይቷል። Python 3 ን እና PostgreSQL 10ን ከRHEL 8 ቤታ ማከማቻዎች አዋቅረናል። አሁን ወደፊት መሄድ እና የDjango አፕሊኬሽኖችን መፍጠር (ወይም በቀላሉ ማሰማራት) ወይም ሌሎች የሚገኙ መሳሪያዎችን በRHEL 8 Beta ማሰስ የማዋቀር ሂደቱን በራስ ሰር ለመስራት፣ አፈፃፀሙን ለማሻሻል ወይም ይህን ውቅር በይዘት ለመያዝ ይችላሉ።

ምንጭ: hab.com

አስተያየት ያክሉ