RAM-ನಲ್ಲಿ ಚಾಲನೆಯಾಗುವ VPN ರನ್ಟೈಮ್ ಲಾಗ್ಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ

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

ಸ್ಥಿತಿಯನ್ನು ಬರೆಯಬಲ್ಲ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ: ಡೀಮನ್, ದೃಢೀಕರಣ ಸೇವೆ, ಜರ್ನಲ್, ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣಾ ಏಜೆಂಟ್ ಮತ್ತು ನಿರ್ವಹಣಾ ಸಾಧನಗಳು.

ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಂಗ್ರಹ ಎರಡು ಬೇರೆ ಪ್ರಶ್ನೆಗಳು

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

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

tmpfs ಒಂದು ಖಾತರಿ ಅಲ್ಲ

Linux tmpfs ಭೌತಿಕ RAM ಡಿಸ್ಕ್ ಅಲ್ಲ. ಮೌಂಟ್ ಅನುಮತಿಸಿದಾಗ ಪುಟಗಳನ್ನು swap ಗೆ ಬರೆಯಬಹುದು ಎಂದು ಕರ್ನಲ್ ದಾಖಲೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ tmpfs ಫೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಎಂದೂ ಅಲ್ಲಿಗೆ ನಕಲಿಸದಿದ್ದರೂ ಡಿಸ್ಕ್ ತಲುಪಬಹುದು. mount swap-ಆಧಾರಿತ tmpfs ಕೆಲಸದಲ್ಲಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಇತರ ಮೆಮೊರಿ ಫೈಲ್ಸಿಸ್ಟಮ್ಗಳು ಇನ್ನೂ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ. /run ಅಡಿಯಲ್ಲಿನ ಮಾರ್ಗ ಅಸ್ಥಿರತೆ ಎಂದರ್ಥ ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿಜವಾದ ಮೌಂಟ್ ಆಯ್ಕೆಗಳನ್ನು ಓದಿ.

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

Journald ಗೆ ಎರಡು ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಒಂದು ಫಾರ್ವರ್ಡರ್ ಇದೆ

Journald ಈ ವಿಭಜನೆಯನ್ನು ಸ್ವಚ್ಛವಾಗಿ ತೋರಿಸುತ್ತದೆ. ಅಸ್ಥಿರ ಸಂಗ್ರಹಣೆ ನಮೂದುಗಳನ್ನು /run/log/journal ಅಡಿಯಲ್ಲಿ ಇಡುತ್ತದೆ, ಶಾಶ್ವತ ಸಂಗ್ರಹಣೆ /var/log/journal ಅಡಿಯಲ್ಲಿ, ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಮೋಡ್ ಎರಡರ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ; ಜಾರಿಯಲ್ಲಿರುವ ಮೋಡ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಿಸ್ಟಮ್ನಿಂದ ಬರುತ್ತದೆ, ಇಮೇಜ್ ವಿವರಣೆಯಿಂದ ಅಲ್ಲ. ಅಸ್ಥಿರಕ್ಕೆ ಬದಲಾಯಿಸುವುದು ಈಗಾಗಲೇ ಶಾಶ್ವತವಾಗಿ ಬರೆದದ್ದನ್ನು ಅಳಿಸುವುದಿಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ಕೂಡ ಪ್ರತ್ಯೇಕ ಚಾನಲ್: ಸ್ಥಳೀಯವಾಗಿ ಏನನ್ನೂ ಇಡದ ಸಂಗ್ರಹ ಸೆಟ್ಟಿಂಗ್ ಕೂಡ ಸಂದೇಶಗಳನ್ನು ಇನ್ನೊಂದು ಗುರಿಗೆ ಒಪ್ಪಿಸಬಹುದು.

ಜಾರಿಯಲ್ಲಿರುವ ಮೋಡ್ ಅನ್ನು ಜರ್ನಲ್ನಿಂದಲೇ ಅಥವಾ ಅದರ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ನಿಂದ ಓದಿ, ನಂತರ ಫಾರ್ವರ್ಡಿಂಗ್ ಗುರಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಇನ್ನೊಂದನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ.

ಮರುಬೂಟ್ನಿಂದ ಏನು ಉಳಿಯಬೇಕು

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

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

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