ಕಾರ್ಯಾಗಾರ RHEL 8 ಬೀಟಾ: ವರ್ಕಿಂಗ್ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು

RHEL 8 ಬೀಟಾ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನೇಕ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನೀಡುತ್ತದೆ, ಅದರ ಪಟ್ಟಿಯು ಪುಟಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದಾಗ್ಯೂ, ಹೊಸ ವಿಷಯಗಳನ್ನು ಕಲಿಯುವುದು ಯಾವಾಗಲೂ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಉತ್ತಮವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು Red Hat Enterprise Linux 8 ಬೀಟಾವನ್ನು ಆಧರಿಸಿ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ವಾಸ್ತವವಾಗಿ ರಚಿಸುವ ಕಾರ್ಯಾಗಾರವನ್ನು ಕೆಳಗೆ ನೀಡುತ್ತೇವೆ.

ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಜನಪ್ರಿಯ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಾದ ಪೈಥಾನ್ ಅನ್ನು ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ, ಜಾಂಗೊ ಮತ್ತು ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್ ಸಂಯೋಜನೆ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸಲು ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯ ಸಂಯೋಜನೆ, ಮತ್ತು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು RHEL 8 ಬೀಟಾವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ನಂತರ ನಾವು ಒಂದೆರಡು ಹೆಚ್ಚು (ವರ್ಗೀಕರಿಸದ) ಪದಾರ್ಥಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ.

ಪರೀಕ್ಷಾ ಪರಿಸರವು ಬದಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸಾಧ್ಯತೆಗಳನ್ನು ಅನ್ವೇಷಿಸಲು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಕಂಟೇನರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಮತ್ತು ಬಹು ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಪರಿಸರವನ್ನು ಪ್ರಯತ್ನಿಸುವುದು. ಹೊಸ ಯೋಜನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು, ನೀವು ಕೈಯಿಂದ ಸಣ್ಣ, ಸರಳವಾದ ಮೂಲಮಾದರಿಯನ್ನು ರಚಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಬಹುದು ಇದರಿಂದ ನೀವು ನಿಖರವಾಗಿ ಏನಾಗಬೇಕು ಮತ್ತು ಅದು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು, ತದನಂತರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಸಂರಚನೆಗಳನ್ನು ರಚಿಸಲು ಮುಂದುವರಿಯಿರಿ. ಇಂದು ನಾವು ಅಂತಹ ಮೂಲಮಾದರಿಯ ರಚನೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ.

RHEL 8 ಬೀಟಾ VM ಇಮೇಜ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸೋಣ. ನೀವು ಮೊದಲಿನಿಂದಲೂ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಸ್ಥಾಪಿಸಬಹುದು ಅಥವಾ ನಿಮ್ಮ ಬೀಟಾ ಚಂದಾದಾರಿಕೆಯೊಂದಿಗೆ ಲಭ್ಯವಿರುವ KVM ಅತಿಥಿ ಚಿತ್ರವನ್ನು ಬಳಸಬಹುದು. ಅತಿಥಿ ಚಿತ್ರವನ್ನು ಬಳಸುವಾಗ, ಕ್ಲೌಡ್ ಆರಂಭಕ್ಕಾಗಿ (ಕ್ಲೌಡ್-ಇನಿಟ್) ಮೆಟಾಡೇಟಾ ಮತ್ತು ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರುವ ವರ್ಚುವಲ್ ಸಿಡಿಯನ್ನು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಡಿಸ್ಕ್ ರಚನೆ ಅಥವಾ ಲಭ್ಯವಿರುವ ಪ್ಯಾಕೇಜುಗಳೊಂದಿಗೆ ನೀವು ವಿಶೇಷವಾದ ಏನನ್ನೂ ಮಾಡಬೇಕಾಗಿಲ್ಲ; ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾಡುತ್ತದೆ.

ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ.

ಜಾಂಗೊವನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತಿದೆ

ಜಾಂಗೊದ ಹೊಸ ಆವೃತ್ತಿಯೊಂದಿಗೆ, ಪೈಥಾನ್ 3.5 ಅಥವಾ ನಂತರದ ಜೊತೆಗೆ ನಿಮಗೆ ವರ್ಚುವಲ್ ಪರಿಸರದ (ವರ್ಚುವಲ್ನ್ವ್) ಅಗತ್ಯವಿರುತ್ತದೆ. ಬೀಟಾ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಪೈಥಾನ್ 3.6 ಲಭ್ಯವಿದೆ ಎಂದು ನೀವು ನೋಡಬಹುದು, ಇದು ನಿಜವೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:

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

Red Hat RHEL ನಲ್ಲಿ ಪೈಥಾನ್ ಅನ್ನು ಸಿಸ್ಟಮ್ ಟೂಲ್ಕಿಟ್ ಆಗಿ ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ಏಕೆ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ?

ಸತ್ಯವೆಂದರೆ ಅನೇಕ ಪೈಥಾನ್ ಡೆವಲಪರ್‌ಗಳು ಇನ್ನೂ ಪೈಥಾನ್ 2 ರಿಂದ ಪೈಥಾನ್ 2 ಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಆಲೋಚಿಸುತ್ತಿದ್ದಾರೆ, ಆದರೆ ಪೈಥಾನ್ 3 ಸ್ವತಃ ಸಕ್ರಿಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿದೆ ಮತ್ತು ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೊಸ ಆವೃತ್ತಿಗಳು ನಿರಂತರವಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿವೆ. ಆದ್ದರಿಂದ, ಪೈಥಾನ್‌ನ ವಿವಿಧ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ಬಳಕೆದಾರರಿಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡುವಾಗ ಸ್ಥಿರವಾದ ಸಿಸ್ಟಮ್ ಪರಿಕರಗಳ ಅಗತ್ಯವನ್ನು ಪೂರೈಸಲು, ಸಿಸ್ಟಮ್ ಪೈಥಾನ್ ಅನ್ನು ಹೊಸ ಪ್ಯಾಕೇಜ್‌ಗೆ ಸರಿಸಲಾಗಿದೆ ಮತ್ತು ಪೈಥಾನ್ 2.7 ಮತ್ತು 3.6 ಎರಡನ್ನೂ ಸ್ಥಾಪಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸಿದೆ. ಬದಲಾವಣೆಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಏಕೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಪ್ರಕಟಣೆಯಲ್ಲಿ ಕಾಣಬಹುದು ಲ್ಯಾಂಗ್ಡನ್ ವೈಟ್ ಅವರ ಬ್ಲಾಗ್ (ಲ್ಯಾಂಗ್ಡನ್ ವೈಟ್).

ಆದ್ದರಿಂದ, ಕೆಲಸ ಮಾಡುವ ಪೈಥಾನ್ ಅನ್ನು ಪಡೆಯಲು, ನೀವು ಕೇವಲ ಎರಡು ಪ್ಯಾಕೇಜುಗಳನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗಿದೆ, ಜೊತೆಗೆ python3-pip ಅನ್ನು ಅವಲಂಬನೆಯಾಗಿ ಸೇರಿಸಲಾಗಿದೆ.

sudo yum install python36 python3-virtualenv

ಲ್ಯಾಂಗ್ಡನ್ ಸೂಚಿಸಿದಂತೆ ನೇರ ಮಾಡ್ಯೂಲ್ ಕರೆಗಳನ್ನು ಏಕೆ ಬಳಸಬಾರದು ಮತ್ತು pip3 ಅನ್ನು ಸ್ಥಾಪಿಸಬಾರದು? ಮುಂಬರುವ ಯಾಂತ್ರೀಕರಣವನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು, Ansible ಅನ್ನು ಚಲಾಯಿಸಲು ಪಿಪ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ ಎಂದು ತಿಳಿದಿದೆ, ಏಕೆಂದರೆ ಪಿಪ್ ಮಾಡ್ಯೂಲ್ ಕಸ್ಟಮ್ ಪಿಪ್ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ವರ್ಚುವಲ್ನೆವ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

ನಿಮ್ಮ ವಿಲೇವಾರಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪೈಥಾನ್3 ಇಂಟರ್ಪ್ರಿಟರ್ನೊಂದಿಗೆ, ನೀವು ಜಾಂಗೊ ಅನುಸ್ಥಾಪನಾ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಮುಂದುವರಿಯಬಹುದು ಮತ್ತು ನಮ್ಮ ಇತರ ಘಟಕಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಬಹುದು. ಅಂತರ್ಜಾಲದಲ್ಲಿ ಹಲವಾರು ಅನುಷ್ಠಾನ ಆಯ್ಕೆಗಳು ಲಭ್ಯವಿದೆ. ಇಲ್ಲಿ ಒಂದು ಆವೃತ್ತಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಬಳಕೆದಾರರು ತಮ್ಮದೇ ಆದ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಬಹುದು.

ನಾವು Yum ಬಳಸಿಕೊಂಡು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ RHEL 8 ನಲ್ಲಿ ಲಭ್ಯವಿರುವ PostgreSQL ಮತ್ತು Nginx ಆವೃತ್ತಿಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ.

sudo yum install nginx postgresql-server

PostgreSQL ಗೆ psycopg2 ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಇದು ಕೇವಲ virtualenv ಪರಿಸರದಲ್ಲಿ ಲಭ್ಯವಿರಬೇಕು, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಜಾಂಗೊ ಮತ್ತು Gunicorn ಜೊತೆಗೆ pip3 ಬಳಸಿ ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ಆದರೆ ಮೊದಲು ನಾವು virtualenv ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ.

ಜಾಂಗೊ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಸರಿಯಾದ ಸ್ಥಳವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ವಿಷಯದ ಕುರಿತು ಯಾವಾಗಲೂ ಸಾಕಷ್ಟು ಚರ್ಚೆಗಳು ನಡೆಯುತ್ತವೆ, ಆದರೆ ಸಂದೇಹವಿದ್ದಲ್ಲಿ, ನೀವು ಯಾವಾಗಲೂ ಲಿನಕ್ಸ್ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಹೈರಾರ್ಕಿ ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ಗೆ ತಿರುಗಬಹುದು. ನಿರ್ದಿಷ್ಟವಾಗಿ, FHS ಹೇಳುತ್ತದೆ: "ಹೋಸ್ಟ್-ನಿರ್ದಿಷ್ಟ ದತ್ತಾಂಶವನ್ನು ಶೇಖರಿಸಿಡಲು-ವ್ಯವಸ್ಥೆಯು ಉತ್ಪಾದಿಸುವ ಡೇಟಾ, ಉದಾಹರಣೆಗೆ ವೆಬ್ ಸರ್ವರ್ ಡೇಟಾ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, FTP ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಡೇಟಾ, ಮತ್ತು ಸಿಸ್ಟಮ್ ರೆಪೊಸಿಟರಿಗಳನ್ನು ನಿಯಂತ್ರಿಸಿ." ಆವೃತ್ತಿಗಳು (FHS ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. -2.3 ರಲ್ಲಿ 2004)."

ಇದು ನಿಖರವಾಗಿ ನಮ್ಮ ಪ್ರಕರಣವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ನಾವು / srv ಗೆ ಹಾಕುತ್ತೇವೆ, ಅದು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರ (ಕ್ಲೌಡ್-ಬಳಕೆದಾರ) ಮಾಲೀಕತ್ವದಲ್ಲಿದೆ.

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 ಮತ್ತು ಜಾಂಗೊವನ್ನು ಹೊಂದಿಸುವುದು ಸುಲಭ: ಡೇಟಾಬೇಸ್ ರಚಿಸಿ, ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿ, ಅನುಮತಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಆರಂಭದಲ್ಲಿ PostgreSQL ಅನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ಒಂದು ವಿಷಯವೆಂದರೆ postgresql-ಸೆಟಪ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು postgresql-server ಪ್ಯಾಕೇಜ್‌ನೊಂದಿಗೆ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಕ್ಲಸ್ಟರ್ ಪ್ರಾರಂಭ ಅಥವಾ ಅಪ್‌ಗ್ರೇಡ್ ಪ್ರಕ್ರಿಯೆಯಂತಹ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಆಡಳಿತದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಮೂಲಭೂತ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಈ ಸ್ಕ್ರಿಪ್ಟ್ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. RHEL ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಹೊಸ PostgreSQL ನಿದರ್ಶನವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು, ನಾವು ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕಾಗಿದೆ:

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) ಗಾಗಿ ಸೂಕ್ತವಾದ ಸರ್ವರ್ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ಹಲವಾರು ಸಾಮಾನ್ಯ ಸಂಯೋಜನೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, uWSGI ಜೊತೆಗೆ Apache HTTPD ಅಥವಾ Gunicorn ಜೊತೆ Nginx.

ವೆಬ್ ಸರ್ವರ್ ಗೇಟ್‌ವೇ ಇಂಟರ್‌ಫೇಸ್‌ನ ಕೆಲಸವೆಂದರೆ ವೆಬ್ ಸರ್ವರ್‌ನಿಂದ ಪೈಥಾನ್ ವೆಬ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು. CGI ಇಂಜಿನ್‌ಗಳು ಇದ್ದಾಗ WSGI ಭಯಾನಕ ಭೂತಕಾಲದ ಅವಶೇಷವಾಗಿದೆ ಮತ್ತು ಇಂದು WSGI ಎಂಬುದು ವೆಬ್ ಸರ್ವರ್ ಅಥವಾ ಪೈಥಾನ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಲೆಕ್ಕಿಸದೆ ವಾಸ್ತವಿಕ ಮಾನದಂಡವಾಗಿದೆ. ಆದರೆ ಅದರ ವ್ಯಾಪಕ ಬಳಕೆಯ ಹೊರತಾಗಿಯೂ, ಈ ಚೌಕಟ್ಟುಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಇನ್ನೂ ಅನೇಕ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಮತ್ತು ಹಲವು ಆಯ್ಕೆಗಳಿವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು Gunicorn ಮತ್ತು Nginx ನಡುವೆ ಸಾಕೆಟ್ ಮೂಲಕ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.

ಈ ಎರಡೂ ಘಟಕಗಳನ್ನು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿರುವುದರಿಂದ, ನೆಟ್‌ವರ್ಕ್ ಸಾಕೆಟ್ ಬದಲಿಗೆ UNIX ಸಾಕೆಟ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸೋಣ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಸಂವಹನಕ್ಕೆ ಸಾಕೆಟ್ ಅಗತ್ಯವಿರುವುದರಿಂದ, ಇನ್ನೂ ಒಂದು ಹಂತವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸೋಣ ಮತ್ತು systemd ಮೂಲಕ Gunicorn ಗಾಗಿ ಸಾಕೆಟ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡೋಣ.

ಸಾಕೆಟ್ ಸಕ್ರಿಯ ಸೇವೆಗಳನ್ನು ರಚಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ತುಂಬಾ ಸರಳವಾಗಿದೆ. ಮೊದಲಿಗೆ, UNIX ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸುವ ಬಿಂದುವನ್ನು ಸೂಚಿಸುವ ListenStream ನಿರ್ದೇಶನವನ್ನು ಒಳಗೊಂಡಿರುವ ಯುನಿಟ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ, ನಂತರ ಅಗತ್ಯವಿರುವ ನಿರ್ದೇಶನವು ಸಾಕೆಟ್ ಯೂನಿಟ್ ಫೈಲ್‌ಗೆ ಸೂಚಿಸುವ ಸೇವೆಗಾಗಿ ಯೂನಿಟ್ ಫೈಲ್. ನಂತರ, ಸೇವಾ ಘಟಕ ಫೈಲ್‌ನಲ್ಲಿ, ವರ್ಚುವಲ್ ಪರಿಸರದಿಂದ ಗುನಿಕಾರ್ನ್ ಅನ್ನು ಕರೆಯುವುದು ಮತ್ತು UNIX ಸಾಕೆಟ್ ಮತ್ತು ಜಾಂಗೊ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ WSGI ಬೈಂಡಿಂಗ್ ಅನ್ನು ರಚಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ.

ನೀವು ಆಧಾರವಾಗಿ ಬಳಸಬಹುದಾದ ಯುನಿಟ್ ಫೈಲ್‌ಗಳ ಕೆಲವು ಉದಾಹರಣೆಗಳು ಇಲ್ಲಿವೆ. ಮೊದಲು ನಾವು ಸಾಕೆಟ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ.

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

systemd ಅನ್ನು ಬಳಸಿಕೊಂಡು Gunicorn ಸಾಕೆಟ್ ಮತ್ತು Nginx ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ನೀವು ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಿದ್ಧರಾಗಿರುವಿರಿ.

ಕೆಟ್ಟ ಗೇಟ್‌ವೇ ದೋಷವೇ?

ನಿಮ್ಮ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ನೀವು ವಿಳಾಸವನ್ನು ನಮೂದಿಸಿದರೆ, ನೀವು ಹೆಚ್ಚಾಗಿ 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"

ನಾವು ನೇರವಾಗಿ ಗುನಿಕಾರ್ನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿದರೆ, ನಮಗೆ ಖಾಲಿ ಉತ್ತರ ಸಿಗುತ್ತದೆ.

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

ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ. ನೀವು ಲಾಗ್ ಅನ್ನು ತೆರೆದರೆ, ಸಮಸ್ಯೆಯು SELinux ಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ನೀವು ಹೆಚ್ಚಾಗಿ ನೋಡುತ್ತೀರಿ. ನಾವು ಯಾವುದೇ ನೀತಿಯನ್ನು ರಚಿಸದ ಡೀಮನ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿರುವುದರಿಂದ, ಅದನ್ನು init_t ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ. ಈ ಸಿದ್ಧಾಂತವನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪರೀಕ್ಷಿಸೋಣ.

sudo setenforce 0

ಇದೆಲ್ಲವೂ ಟೀಕೆ ಮತ್ತು ರಕ್ತದ ಕಣ್ಣೀರಿಗೆ ಕಾರಣವಾಗಬಹುದು, ಆದರೆ ಇದು ಕೇವಲ ಮೂಲಮಾದರಿಯನ್ನು ಡೀಬಗ್ ಮಾಡುತ್ತಿದೆ. ಇದು ಸಮಸ್ಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಚೆಕ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸೋಣ, ಅದರ ನಂತರ ನಾವು ಎಲ್ಲವನ್ನೂ ಅದರ ಸ್ಥಳಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ.

ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಪುಟವನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ನಮ್ಮ ಕರ್ಲ್ ಆಜ್ಞೆಯನ್ನು ಮರುಚಾಲಿಸುವ ಮೂಲಕ, ನೀವು ಜಾಂಗೊ ಪರೀಕ್ಷಾ ಪುಟವನ್ನು ನೋಡಬಹುದು.

ಆದ್ದರಿಂದ, ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಅನುಮತಿ ಸಮಸ್ಯೆಗಳಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ, ನಾವು SELinux ಅನ್ನು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ.

sudo setenforce 1

ನಾನು ಇಲ್ಲಿ audit2allow ಅಥವಾ ಸೆಪೋಲ್ಜೆನ್‌ನೊಂದಿಗೆ ಎಚ್ಚರಿಕೆ-ಆಧಾರಿತ ನೀತಿಗಳನ್ನು ರಚಿಸುವ ಕುರಿತು ಮಾತನಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸದ್ಯಕ್ಕೆ ಯಾವುದೇ ನಿಜವಾದ ಜಾಂಗೊ ಅಪ್ಲಿಕೇಶನ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ 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 ಗುನಿಕಾರ್ನ್ ಬಳಸುವ UNIX ಸಾಕೆಟ್‌ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುವುದರಿಂದ Nginx ಅನ್ನು ತಡೆಯುತ್ತದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನೀತಿಗಳು ಬದಲಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ, ಆದರೆ ಮುಂದೆ ಇತರ ಸವಾಲುಗಳಿವೆ. ನೀವು ಡೊಮೇನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನಿರ್ಬಂಧ ಡೊಮೇನ್‌ನಿಂದ ಅನುಮತಿ ಡೊಮೇನ್‌ಗೆ ಬದಲಾಯಿಸಬಹುದು. ಈಗ ನಾವು ಅನುಮತಿಗಳ ಡೊಮೇನ್‌ಗೆ 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

ನೀವು ಗುನಿಕಾರ್ನ್ ಸೇವೆಯ ಸ್ಥಿತಿಯನ್ನು ನೋಡಿದರೆ ಅಥವಾ ps ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿದರೆ, ನೀವು ಯಾವುದೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ. Gunicorn ನಮ್ಮ virtualenv ಪರಿಸರದಲ್ಲಿ ಪೈಥಾನ್ ಇಂಟರ್ಪ್ರಿಟರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಂತೆ ತೋರುತ್ತಿದೆ, ಬಹುಶಃ ವರ್ಕರ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡಲು. ಆದ್ದರಿಂದ ಈಗ ಈ ಎರಡು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳನ್ನು ಗುರುತಿಸೋಣ ಮತ್ತು ನಾವು ನಮ್ಮ ಜಾಂಗೊ ಪರೀಕ್ಷಾ ಪುಟವನ್ನು ತೆರೆಯಬಹುದೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ.

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 ಆಧಾರಿತ ಮುಂಭಾಗದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಜಾಂಗೊ ಯೋಜನೆಯು ಕಾಣಿಸಿಕೊಂಡಿದೆ. RHEL 3 ಬೀಟಾ ರೆಪೊಸಿಟರಿಗಳಿಂದ ನಾವು ಪೈಥಾನ್ 10 ಮತ್ತು PostgreSQL 8 ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ. ಈಗ ನೀವು ಮುಂದುವರಿಯಬಹುದು ಮತ್ತು ಜಾಂಗೊ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು (ಅಥವಾ ಸರಳವಾಗಿ ನಿಯೋಜಿಸಬಹುದು) ಅಥವಾ ಸಂರಚನಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಅಥವಾ ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕಂಟೈನರ್ ಮಾಡಲು RHEL 8 ಬೀಟಾದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಇತರ ಪರಿಕರಗಳನ್ನು ಅನ್ವೇಷಿಸಬಹುದು.

ಮೂಲ: www.habr.com