Το RHEL 8 Beta προσφέρει στους προγραμματιστές πολλές νέες δυνατότητες, η καταχώριση των οποίων μπορεί να πάρει σελίδες, ωστόσο, η εκμάθηση νέων πραγμάτων είναι πάντα καλύτερη στην πράξη, επομένως παρακάτω προσφέρουμε ένα εργαστήριο για τη δημιουργία ουσιαστικής υποδομής εφαρμογών με βάση το Red Hat Enterprise Linux 8 Beta.
Ας πάρουμε ως βάση την Python, μια δημοφιλή γλώσσα προγραμματισμού μεταξύ των προγραμματιστών, έναν συνδυασμό Django και PostgreSQL, έναν αρκετά κοινό συνδυασμό για τη δημιουργία εφαρμογών, και διαμορφώνουμε τη RHEL 8 Beta για να λειτουργεί με αυτές. Στη συνέχεια θα προσθέσουμε μερικά ακόμη (μη ταξινομημένα) υλικά.
Το περιβάλλον δοκιμής θα αλλάξει, γιατί είναι ενδιαφέρον να εξερευνήσουμε τις δυνατότητες αυτοματισμού, την εργασία με κοντέινερ και τη δοκιμή περιβαλλόντων με πολλούς διακομιστές. Για να ξεκινήσετε με ένα νέο έργο, μπορείτε να ξεκινήσετε δημιουργώντας ένα μικρό, απλό πρωτότυπο με το χέρι, ώστε να μπορείτε να δείτε ακριβώς τι πρέπει να συμβεί και πώς αλληλεπιδρά, και στη συνέχεια να προχωρήσετε στην αυτοματοποίηση και στη δημιουργία πιο περίπλοκων διαμορφώσεων. Σήμερα μιλάμε για τη δημιουργία ενός τέτοιου πρωτοτύπου.
Ας ξεκινήσουμε με την ανάπτυξη της εικόνας RHEL 8 Beta VM. Μπορείτε να εγκαταστήσετε μια εικονική μηχανή από την αρχή ή να χρησιμοποιήσετε την εικόνα επισκέπτη KVM που είναι διαθέσιμη με τη συνδρομή σας Beta. Όταν χρησιμοποιείτε μια εικόνα επισκέπτη, θα πρέπει να διαμορφώσετε ένα εικονικό CD που θα περιέχει μεταδεδομένα και δεδομένα χρήστη για προετοιμασία στο cloud (cloud-init). Δεν χρειάζεται να κάνετε κάτι ιδιαίτερο με τη δομή του δίσκου ή τα διαθέσιμα πακέτα, οποιαδήποτε διαμόρφωση θα κάνει.
Ας ρίξουμε μια πιο προσεκτική ματιά στην όλη διαδικασία.
Εγκατάσταση του Django
Με την πιο πρόσφατη έκδοση του Django, θα χρειαστείτε ένα εικονικό περιβάλλον (virtualenv) με Python 3.5 ή νεότερη έκδοση. Στις σημειώσεις Beta μπορείτε να δείτε ότι η 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. Περισσότερες πληροφορίες για τις αλλαγές και γιατί έγιναν μπορείτε να βρείτε στη δημοσίευση στο (Λάνγκντον Γουάιτ).
Έτσι, για να λειτουργήσει η 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, αλλά πρέπει να είναι διαθέσιμο μόνο σε περιβάλλον 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 που εγκαθίσταται με το πακέτο 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 (WSGI). Υπάρχουν αρκετοί κοινοί συνδυασμοί, για παράδειγμα, Apache HTTPD με uWSGI ή Nginx με Gunicorn.
Η δουλειά της διεπαφής πύλης διακομιστή Web είναι να προωθήσει αιτήματα από τον διακομιστή ιστού στο πλαίσιο ιστού της Python. Το WSGI είναι ένα κατάλοιπο του τρομερού παρελθόντος όταν υπήρχαν οι μηχανές CGI και σήμερα το WSGI είναι το de facto πρότυπο, ανεξάρτητα από τον διακομιστή ιστού ή το πλαίσιο 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 {
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 και είστε έτοιμοι να ξεκινήσετε τις δοκιμές.
Σφάλμα Bad Gateway;
Εάν εισαγάγετε τη διεύθυνση στο πρόγραμμα περιήγησής σας, πιθανότατα θα λάβετε ένα σφάλμα 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, δεν θα δείτε διεργασίες που εκτελούνται. Φαίνεται ότι ο Gunicorn προσπαθεί να αποκτήσει πρόσβαση στον διερμηνέα Python στο περιβάλλον μας 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 εμφανίστηκε με ένα frontend που βασίζεται στο Nginx και το Gunicorn WSGI. Διαμορφώσαμε τα Python 3 και PostgreSQL 10 από τα αποθετήρια RHEL 8 Beta. Τώρα μπορείτε να προχωρήσετε και να δημιουργήσετε (ή απλά να αναπτύξετε) εφαρμογές Django ή να εξερευνήσετε άλλα διαθέσιμα εργαλεία στο RHEL 8 Beta για να αυτοματοποιήσετε τη διαδικασία διαμόρφωσης, να βελτιώσετε την απόδοση ή ακόμα και να διαμορφώσετε σε κοντέινερ αυτή τη διαμόρφωση.
Πηγή: www.habr.com