OpenVPN 3 Python ದೋಷ: ವ್ಯವಸ್ಥೆಯ Python ಅಲ್ಲ, ಸಾಧನವನ್ನೇ ಸರಿಪಡಿಸಿ
Traceback ಫ್ರಂಟೆಂಡ್ ಅನ್ನು ಓಡಿಸಿದ ಇಂಟರ್ಪ್ರಿಟರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಟನೆಲ್ ಅನ್ನು ಹೊಂದಿರುವ ಸೇವೆಯನ್ನಲ್ಲ. ಎಲ್ಲವನ್ನೂ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಮರುನಿರ್ದೇಶಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಹೋಲಿಸಿ.
VPN ನಿರ್ವಹಣಾ ಆಜ್ಞೆ ಪ್ರಾರಂಭವಾದಾಗ Traceback ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಪ್ರವೃತ್ತಿ ಬೇರೆ Python ಅನ್ನು ಸ್ಥಾಪಿಸುವುದಕ್ಕೆ ಅಥವಾ ಸಿಸ್ಟಮ್ನ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬೇರೆಡೆಗೆ ತಿರುಗಿಸುವುದಕ್ಕೆ ಓಡುತ್ತದೆ. ಆ ಪ್ರವೃತ್ತಿ ಪರಸ್ಪರ ಸಂಬಂಧವಿಲ್ಲದ ಎರಡು ರನ್ಟೈಮ್ಗಳನ್ನು ಬೆರೆಸುತ್ತದೆ. ಒಂದು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮತ್ತು ಅದರ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಸಾಧನಗಳಿಗೆ ಸೇರಿದೆ; ಇನ್ನೊಂದು ನೀವು ನಿರ್ಮಿಸುತ್ತಿರುವ ಯಾವುದೇ ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಸೇರಿದೆ. ಎರಡನೆಯದನ್ನು ತೃಪ್ತಿಪಡಿಸಲು ಮೊದಲನೆಯದನ್ನು ಬದಲಿಸುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಡೆಸ್ಕ್ಟಾಪ್ ತನ್ನ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ದಾರಿ.
ಮಾಡಲು ಯೋಗ್ಯವಾದ ಹೋಲಿಕೆ ಎಂದರೆ ವಾಸ್ತವವಾಗಿ ವಿಫಲವಾದ ಘಟಕ ಮತ್ತು ನೀವು ಬದಲಿಸಲು ಅರ್ಹರಾಗಿರುವ ರನ್ಟೈಮ್ ನಡುವಿನದು. ಅವು ಬಹುತೇಕ ಎಂದಿಗೂ ಒಂದೇ ವಸ್ತುವಲ್ಲ.
ಒಂದೇ ತರ ಕಾಣುವ ಎರಡು Python ಪ್ರಶ್ನೆಗಳು
ಮೊದಲ ಪ್ರಶ್ನೆ: Traceback ಮುದ್ರಿಸಿದ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಯಾವ ಇಂಟರ್ಪ್ರಿಟರ್ ಓಡಿಸಿತು? ಎರಡನೆಯದು: ನನ್ನ ಪ್ರಾಜೆಕ್ಟ್ ಯಾವ ಇಂಟರ್ಪ್ರಿಟರ್ ಬಳಸಬೇಕು? ಟರ್ಮಿನಲ್ನಲ್ಲಿ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಏಕೆಂದರೆ ಎರಡಕ್ಕೂ python3 ಟೈಪ್ ಮಾಡಿ ಉತ್ತರಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವುಗಳಿಗೆ ಬೇರೆ ಮಾಲೀಕರು, ಬೇರೆ ಅಪ್ಗ್ರೇಡ್ ಮಾರ್ಗಗಳು ಮತ್ತು ಬೇರೆ ಪ್ರಭಾವದ ವ್ಯಾಪ್ತಿ ಇದೆ.
ಸಿಸ್ಟಮ್ ಸಾಧನವು ತನ್ನ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಜೊತೆಗೆ ಬಂದ ಇಂಟರ್ಪ್ರಿಟರ್ಗೆ ಮತ್ತು ಆ ಇಂಟರ್ಪ್ರಿಟರ್ನ ABI ವಿರುದ್ಧ ನಿರ್ಮಿಸಲಾದ ಸಂಕಲಿತ ಮಾಡ್ಯೂಲ್ಗಳಿಗೆ ಬದ್ಧವಾಗಿದೆ. ಪ್ರಾಜೆಕ್ಟ್ ನೀವು ಅದಕ್ಕಾಗಿ ರಚಿಸುವ ಯಾವುದೇ ಪರಿಸರಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ. ಸಿಸ್ಟಮ್ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಸರಿಸುವುದು ಮೊದಲನೆಯದನ್ನು ಯಂತ್ರದ ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ಒಂದೇ ಬಾರಿಗೆ ಬದಲಿಸುತ್ತದೆ; ಪರಿಸರವನ್ನು ರಚಿಸುವುದು ಎರಡನೆಯದನ್ನು ಒಂದೇ ಡೈರೆಕ್ಟರಿಗೆ ಬದಲಿಸುತ್ತದೆ.
ಆ ಕ್ರಿಯೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಹಿಂತಿರುಗಿಸಬಹುದು. ಅದು ಮೊದಲನೆಯದಲ್ಲ.
ದೋಷವನ್ನು ಯಾವ ಘಟಕ ಉಂಟುಮಾಡಿತು
ಬೇರೆ ಏನನ್ನೂ ಓದುವ ಮೊದಲು Tracebackನ ಮೊದಲ ಸಾಲು ಮತ್ತು ಅದನ್ನು ಉತ್ಪಾದಿಸಿದ ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ಅನ್ನು ಓದಿ. ಕಮಾಂಡ್ ಲೈನ್ ಫ್ರಂಟೆಂಡ್, ವಿಶೇಷ ಸೇವೆ ಮತ್ತು API ಬೈಂಡಿಂಗ್ಗಳು ಪ್ರತ್ಯೇಕ ಭಾಗಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಮಾತ್ರ Python.
command -v openvpn3
head -n 1 "$(command -v openvpn3)"
dpkg -S "$(command -v openvpn3)" 2>/dev/null
systemctl status openvpn3-service-client --no-pagerಸ್ಕ್ರಿಪ್ಟ್ನ ಮೊದಲ ಸಾಲು ಅದು ಬಳಸುವ ಇಂಟರ್ಪ್ರಿಟರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು Traceback ಬಂದದ್ದು ಅದೇ ಇಂಟರ್ಪ್ರಿಟರ್ನಿಂದ. ಪ್ಯಾಕೇಜ್ ಪ್ರಶ್ನೆ ಫೈಲ್ ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಅದು ಅದನ್ನು ಯಾರು ಬದಲಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸೇವೆಯ ಸ್ಥಿತಿ ಸಂಪೂರ್ಣ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಸೆಷನ್ಗಳನ್ನು ನಿಜವಾಗಿ ತೆರೆಯುವ ವಿಶೇಷ ಬ್ಯಾಕೆಂಡ್ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಎಂಬುದು.
ಮಾಡ್ಯೂಲ್ ಆಮದು ದೋಷ, D-Bus ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯ ನಿರಾಕರಣೆ ಮತ್ತು ತಿರಸ್ಕರಿಸಿದ ರುಜುವಾತುಗಳು ಮೂರು ಬೇರೆ ಹಂತಗಳು. ಆಮದು ದೋಷ ಯಾವುದೇ ಸೆಷನ್ ಇರುವ ಮೊದಲೇ ಸಂಭವಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ಸಂರಚನೆಯ ಎಷ್ಟೇ ಪ್ರಮಾಣ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೇವೆಯೂ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಸಂದೇಶವನ್ನು ಆ ಮೂರು ಹಂತಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಸೇರಿಸುವುದೇ ನಿಜವಾದ ಮೊದಲ ಹೆಜ್ಜೆ.
ಪ್ರಾಜೆಕ್ಟ್ ಪರಿಸರ ಏನನ್ನು ಸರಿಪಡಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ
ಪ್ರಾಜೆಕ್ಟ್ ಪರಿಸರವು ಪ್ರಾಜೆಕ್ಟ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಒಂದು ಅಪ್ಲಿಕೇಶನ್ಗೆ ಬೇಕಾದ ನಿಖರ ಗ್ರಂಥಾಲಯ ಆವೃತ್ತಿಗಳನ್ನು ಉಳಿದ ಎಲ್ಲದರಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ ನೀಡುತ್ತದೆ. ಅದು ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತ, ಮತ್ತು ವಿಫಲವಾಗುತ್ತಿರುವ ಪ್ರೋಗ್ರಾಂ ನಿಮ್ಮದೇ ಸ್ಕ್ರಿಪ್ಟ್ ಆದಾಗ ಅದು ಸರಿಯಾದ ಸಾಧನ.
uv run --python 3.11 app.py
python3 -c 'import openvpn3; print(openvpn3.__file__)'ಎರಡನೇ ಆಜ್ಞೆ ನಿರ್ದಿಷ್ಟ ಇಂಟರ್ಪ್ರಿಟರ್ ಬೈಂಡಿಂಗ್ಗಳ ಯಾವ ಪ್ರತಿಯನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಕಾಣೆಯಾದ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಮರೆಯಾಗಿಸಿದ ಪ್ಯಾಕೇಜ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ ಅದೇ. ಅದನ್ನು ವಿಫಲವಾಗುತ್ತಿರುವ ಸ್ಕ್ರಿಪ್ಟ್ ಬಳಸುವ ಇಂಟರ್ಪ್ರಿಟರ್ನೊಂದಿಗೆ ಓಡಿಸಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಬೇರೊಂದರೊಂದಿಗೆ ಅಲ್ಲ.
ಪ್ರಾಜೆಕ್ಟ್ ಪರಿಸರವು ಮಾಡಲಾಗದ್ದು ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಫ್ರಂಟೆಂಡ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು. ಆ ಪ್ರೋಗ್ರಾಂನ ಅವಲಂಬನೆಗಳು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಆಯ್ಕೆ ಮಾಡಿದ ಇಂಟರ್ಪ್ರಿಟರ್ಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಪರಿಸರದೊಳಗೆ ಓಡಿಸುವುದು ಒಂದೋ ವಿಫಲವಾಗುತ್ತದೆ ಅಥವಾ ಯಾರೂ ಬೆಂಬಲಿಸದ ಮಿಶ್ರಣವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಪರಿಸರ ಚರಣಾಂಶದಿಂದ ಅದರೊಳಗೆ ಮಾರ್ಗಗಳನ್ನು ಚುಚ್ಚುವುದು ಹೆಚ್ಚುವರಿ ಹಂತಗಳೊಂದಿಗೆ ಅದೇ ತಪ್ಪು: ಸಾಧನ ಏನನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಿದ್ದೀರಿ, ಆದರೆ ಅದನ್ನು ಯಾವುದರ ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಿಲ್ಲ. ಆ ವಿನಿಮಯವು ಮುಂದಿನ ಆಮದು ಎದುರಾಗುವವರೆಗೆ ಮಾತ್ರ ಸರಿಪಡಿಸಿದಂತೆ ಕಾಣುತ್ತದೆ.
ಸಿಸ್ಟಮ್ ಇಂಟರ್ಪ್ರಿಟರ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವುದು ಏಕೆ ಬಲೆ
ಡೀಫಾಲ್ಟ್ ಇಂಟರ್ಪ್ರಿಟರ್ ಬದಲಿಸುವುದು ಆಕರ್ಷಕ, ಏಕೆಂದರೆ ಅದು ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ Traceback ಅನ್ನು ಸರಿಪಡಿಸಿದಂತೆ ಕಾಣುತ್ತದೆ. ಅದು ಹೋಸ್ಟ್ನ ಪ್ರತಿ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ Python ಸಾಧನವೂ ನೆಲೆಗೊಂಡಿರುವ ಊಹೆಯನ್ನೂ ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯಗಳು ನಂತರ, ಸಂಬಂಧವಿಲ್ಲದ ಸ್ಥಳಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.
ಪರ್ಯಾಯ ಆಯ್ಕೆಯ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸಮಾನ ಅನುಷ್ಠಾನಗಳ ನಡುವೆ ಬದಲಾಯಿಸಲು ವಿನ್ಯಾಸ ಮಾಡಲಾಗಿದೆ, ಹಳೆಯ ಸಂಕಲಿತ ಮಾಡ್ಯೂಲ್ಗಳ ಅಡಿಯಲ್ಲಿ ಹೊಸ ಭಾಷೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಅಲ್ಲ. ಸಂಕಲಿತ ವಿಸ್ತರಣೆಗಳು ನಿರ್ದಿಷ್ಟ ABI ಗಾಗಿ ನಿರ್ಮಿಸಲ್ಪಡುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿನ್ನೆ ಆಮದಾಗಿದ್ದ ಮಾಡ್ಯೂಲ್ ಒಂದೂ ಪ್ಯಾಕೇಜ್ ತೆಗೆಯದೆಯೇ ಇಂದು ಲೋಡ್ ಆಗದಿರಬಹುದು.
ಜನರು ಕಂಡುಕೊಳ್ಳುವ ಸಲಹೆಗಳಲ್ಲಿ ಹೆಸರಿನ ಬಲೆ ಕೂಡ ಇದೆ. ಆವೃತ್ತಿ ಇಲ್ಲದ python ಆಜ್ಞೆಗೆ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ಗಳು ಮತ್ತು ಪರಿಸರಗಳ ನಡುವೆ ಒಂದೇ ಸಾರ್ವತ್ರಿಕ ಅರ್ಥವಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ನಿರ್ದಿಷ್ಟ ಪ್ರಮುಖ ಆವೃತ್ತಿಯ ಸ್ಥಿರ ಸಮಾನಾರ್ಥಕ ಎಂದು ಪರಿಗಣಿಸುವುದು ಅದನ್ನು ಬರೆದ ಯಂತ್ರದಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ತಿದ್ದುಪಡಿಗಳನ್ನು ನೀಡುತ್ತದೆ. ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ನಲ್ಲಿರುವ ನೀತಿಯಲ್ಲ, ನಿಮ್ಮ ಮುಂದಿರುವ ಸಿಸ್ಟಮ್ನ ನೀತಿಯನ್ನು ಓದಿ.
ಪ್ರತ್ಯೇಕ ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆಗಳು
ಕೊನೆಯಲ್ಲಿ ಎರಡು ಪರೀಕ್ಷೆಗಳಿರಬೇಕು, ಮತ್ತು ಒಂದನ್ನು ಗೆಲ್ಲುವುದು ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಮೊದಲನೆಯದು ಬೆಂಬಲಿತ ಕ್ಲೈಂಟ್ ಆಜ್ಞೆ ಅದನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಇಂಟರ್ಪ್ರಿಟರ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದು. ಎರಡನೆಯದು ವಿಶೇಷ ಸೇವೆ ಸೆಷನ್ ಸ್ಥಾಪಿಸುತ್ತದೆ ಮತ್ತು ಟನೆಲ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂಬುದು.
openvpn3 sessions-list
openvpn3-service-client --help 2>/dev/null | head -n 3
ip -4 addr show tun0ಕೆಲಸ ಮಾಡುವಾಗ ಯಂತ್ರಕ್ಕೆ ಪ್ರವೇಶಿಸುವ ಸ್ವತಂತ್ರ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ವಿಶೇಷವಾಗಿ VPN ನಿಮ್ಮ ಏಕೈಕ ಆಡಳಿತ ಪ್ರವೇಶವನ್ನು ಹೊತ್ತಿದ್ದರೆ. ಸಿಸ್ಟಮ್ ಇಂಟರ್ಪ್ರಿಟರ್ಗೆ ಮಾಡುವ ಬದಲಾವಣೆ ಅದೇ ರೀತಿಯ ಸಂಪಾದನೆ, ಅದು ಆ ಪ್ರವೇಶವನ್ನು ಅರ್ಧದಾರಿಯಲ್ಲಿ ಕಸಿದುಕೊಳ್ಳಬಹುದು.
ವೈಫಲ್ಯವು ಸಿಸ್ಟಮ್ ಸಾಧನಕ್ಕೆ ಕಾಣೆಯಾದ ಮಾಡ್ಯೂಲ್ ಆಗಿದ್ದರೆ, ತಿದ್ದುಪಡಿ ಬೆಂಬಲಿತ ಕಾರ್ಯಪ್ರವಾಹದ ಮೂಲಕ ಪ್ಯಾಕೇಜ್ ಕಾರ್ಯಾಚರಣೆ. ವೈಫಲ್ಯವು ನಿಮ್ಮದೇ ಪ್ರಾಜೆಕ್ಟ್ನಲ್ಲಿ ಆವೃತ್ತಿ ಸಂಘರ್ಷವಾಗಿದ್ದರೆ, ತಿದ್ದುಪಡಿ ಪರಿಸರ. ಆ ಎರಡರ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವುದೇ ಇಡೀ ನಿರ್ಧಾರ, ಮತ್ತು ಅದನ್ನು Traceback ಮುದ್ರಿಸಿದ ಪ್ರೋಗ್ರಾಂ ನಿರ್ಧರಿಸುತ್ತದೆ.