pppd ಬೈನರಿ ಸಿಗಲಿಲ್ಲ: ರನ್ಟೈಮ್ ಸರಿಪಡಿಸಿ, ದೃಢೀಕರಣವಲ್ಲ

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

ಮೆನು ಮತ್ತು ಡೀಮನ್ ಬೇರೆ ಬೇರೆ

ಡೆಸ್ಕ್ಟಾಪ್ ಸಂಪಾದಕವು ಪ್ರೊಫೈಲ್ ಉಳಿಸಬಲ್ಲದು, ಅದನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾದ ಸಹಾಯಕ ಇಲ್ಲದಿದ್ದರೂ, ಏಕೆಂದರೆ ಉಳಿಸುವಿಕೆ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಸಾಮರ್ಥ್ಯಗಳನ್ನಲ್ಲ. ಎರಡು ಘಟಕಗಳು ಬೇರೆ ಬೇರೆ ಪ್ಯಾಕೇಜ್ಗಳಲ್ಲಿ ಬರುತ್ತವೆ ಮತ್ತು ಬೇರೆ ಬೇರೆ ಕ್ಷಣಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಶುದ್ಧವಾಗಿ ಉಳಿಯುವ ಪ್ರೊಫೈಲ್ ಮತ್ತು ತಕ್ಷಣ ವಿಫಲವಾಗುವ ಸಂಪರ್ಕ ಸಂಪೂರ್ಣವಾಗಿ ಸುಸಂಗತ.

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

ಫೈಲ್ ಅಲ್ಲ, ಪ್ಯಾಕೇಜ್ ಓದಿ

ಏನನ್ನೂ ಮುಟ್ಟುವ ಮೊದಲು ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜ್ನ ಸ್ಥಿತಿ, ಅದರ ಘೋಷಿತ ಅವಲಂಬನೆಗಳು ಮತ್ತು ನಿರೀಕ್ಷಿತ ಫೈಲ್ ಪಟ್ಟಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ವಿತರಣೆಗಳ ಪ್ಯಾಕೇಜಿಂಗ್ ಇದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು Debian ನ NetworkManager PPTP ಪ್ಯಾಕೇಜ್ ಉಪಯುಕ್ತ ಉದಾಹರಣೆ, ಏಕೆಂದರೆ ಅದು PPP ಡೀಮನ್ ಪ್ಯಾಕೇಜ್ ಮತ್ತು PPTP ಕ್ಲೈಂಟ್ ಮೇಲೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಅವಲಂಬಿತವಾಗಿದೆ. ಇದು ಇಂದು PPTP ನಿಯೋಜಿಸಲು ಶಿಫಾರಸಲ್ಲ, ಹಳೆಯ ಏಕೀಕರಣ. ಸಹಾಯಕವು ಕ್ಲೈಂಟ್ನ ಒಳಗೆ ಅಲ್ಲ, ತನ್ನದೇ ಅವಲಂಬನೆಯಾಗಿ ಹೇಗೆ ಬರುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ತೋರಿಸುತ್ತದೆ.

ವಿಫಲತೆಯ ಮೂರು ವಿಧಾನಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ: ಸ್ಥಾಪನೆಯಾಗದ ಪ್ಯಾಕೇಜ್, ಯಾವುದೇ ಅಭ್ಯರ್ಥಿ ನೀಡದ ರೆಪೊಸಿಟರಿ, ಮತ್ತು ಪ್ಯಾಕೇಜ್ನ ಮಾಲೀಕತ್ವದ ಹೊರಗೆ ಕೈಯಿಂದ ಸ್ಥಾಪಿಸಿದ ಬೈನರಿ. ಇವು ಬೇರೆ ಬೇರೆ ರಿಪೇರಿ ಬೇಕು, ಮತ್ತು ಮೊದಲನೆಯದು ಮಾತ್ರ ಅದೇ ಪ್ಯಾಕೇಜ್ ಮರುಸ್ಥಾಪಿಸುವುದರಿಂದ ಸರಿಯಾಗುತ್ತದೆ.

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

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

ಉಳಿದವನ್ನು ಮುರಿಯದೆ ರನ್ಟೈಮ್ ಸರಿಪಡಿಸಿ

ರನ್ಟೈಮ್ ಸ್ಪಷ್ಟವಾಗಿ ಅಪೂರ್ಣವಾದಾಗ, ವಿತರಣೆಯ ಪರಿಶೀಲಿತ ಪ್ಯಾಕೇಜ್ ವಹಿವಾಟನ್ನು ಬಳಸಿ ಮತ್ತು ಅದು ಏನನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಎಂದು ಮೊದಲು ಓದಿ. PPP ಅನ್ನು ಹಲವು ಪ್ರವೇಶ ಜಾಲ ಏಕೀಕರಣಗಳು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ತೆಗೆಯುವುದು ಅಥವಾ ಮರುಸ್ಥಾಪಿಸುವುದು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಬಳಕೆದಾರರನ್ನು ಜೊತೆಗೆ ಕರೆದೊಯ್ಯಬಹುದು. ಒಂದು ಮುರಿದದನ್ನು ಸರಿಪಡಿಸಲು ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದು ಲ್ಯಾಪ್ಟಾಪ್ ಎರಡು ಕೆಲಸ ಮಾಡುವ ಸಂಪರ್ಕಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ದಾರಿ.

ಬೇರೆ VPN ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸುವುದೂ ರಿಪೇರಿ ಅಲ್ಲ. ಅದು ಹೊಸ ಹೊಂದಾಣಿಕೆಯ ಅಗತ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ಮೂಲ ಪ್ರೊಫೈಲ್ ಅನ್ನು ವಿವರಣೆಯಿಲ್ಲದೆ ಬಿಡುತ್ತದೆ.

ಸಂಸ್ಥೆಯು ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಃ ಹೋಗಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿದ್ದರೆ, ಅದು ಮಾಲೀಕರಿರುವ ಸ್ಥಳಾಂತರ ನಿರ್ಧಾರ. ಅದು ದೋಷನಿವಾರಣೆಯ ಹಂತವಲ್ಲ, ಮತ್ತು ಸಂಪರ್ಕ ವಿಫಲವಾದ ಕ್ಷಣದಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಬಾರದು.

ಮುಂದಿನ ದೋಷವನ್ನು ಹೊಸ ಹಂತವಾಗಿ ಪರಿಗಣಿಸಿ

ಸಹಾಯಕ ಪ್ರಾರಂಭವಾದ ನಂತರ ಮುಂದಿನ ವೈಫಲ್ಯ ಬೇರೆಯಾಗಿರುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿ. PPP ಕೊಂಡಿ ಮಾತುಕತೆ, ಬಳಕೆದಾರ ದೃಢೀಕರಣ, ವಿಳಾಸ ಹಂಚಿಕೆ, ಮಾರ್ಗಗಳು ಮತ್ತು ಹೆಸರು ಪರಿಹಾರ ಪ್ರತಿಯೊಂದೂ ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಸಾಕ್ಷ್ಯವಿದೆ.

ನಂತರದ ನಿರಾಕರಣೆಗೆ ಅವಲಂಬನಾ ರಿಪೇರಿಯನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ ಅಥವಾ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಎಲ್ಲಾ ಹಳೆಯ ದೃಢೀಕರಣ ಮತ್ತು ಸಂಕೋಚನ ಆಯ್ಕೆಗಳನ್ನು ಆನ್ ಮಾಡುವ ಮೂಲಕ ಉತ್ತರಿಸಬೇಡಿ. ಅದು ಒಂದು ನಿರ್ಣಯಿಸಬಹುದಾದ ಸಮಸ್ಯೆಯನ್ನು ಹಲವು ಪರಸ್ಪರ ಕ್ರಿಯಾಶೀಲ ಸಮಸ್ಯೆಗಳಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಬದಲಾಯಿಸಿ ಮತ್ತು ಅದು ಏನನ್ನು ಬದಲಾಯಿಸಿತು ಎಂದು ದಾಖಲಿಸಿ.

ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಗಳು ಮತ್ತು ನೀವು ನೋಡಿದ ನಿಖರ ಸಂದೇಶವನ್ನು ದಾಖಲಿಸಿ. ಕಾಣೆಯಾದ ಬೈನರಿ ಮತ್ತು ಅದನ್ನು ಒದಗಿಸಬೇಕಾದ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಹೆಸರಿಸುವ ವರದಿ VPN ಬಗ್ಗೆ ಸಾಮಾನ್ಯ ದೂರು ಇಲ್ಲದ ರೀತಿಯಲ್ಲಿ ಕ್ರಿಯಾತ್ಮಕವಾಗಿದೆ.