ನೀವು ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಸಂಪಾದಿಸಿದ post_auth ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು Access Server ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ

ಏನನ್ನೂ ಬದಲಿಸದ ಸಂಪಾದಿತ mac.py ಸಾಮಾನ್ಯ ಮೊದಲ ಲಕ್ಷಣ. ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್ Access Server ಚಲಾಯಿಸುವುದಲ್ಲ; ದೃಢೀಕರಣ ಸೇವೆ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸರ್ವರ್‌ನ ಕಾನ್ಫಿಗ್ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಆ ಸಂಗ್ರಹಿತ ಪ್ರತಿಯೇ ಲಾಗಿನ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸಂಗ್ರಹಿತ ಮೌಲ್ಯ ಬದಲಾಗುವವರೆಗೆ, ಪ್ರತಿ ಪರೀಕ್ಷೆಯೂ ಹಳೆಯ ಸ್ಕ್ರಿಪ್ಟ್ ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದಷ್ಟೇ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

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

ಫೈಲ್ ಮೂಲವೇ ಹೊರತು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿಯಲ್ಲ

Access Server post-auth ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು auth.module.post_auth_script ಕೀಲಿಯ ಅಡಿಯಲ್ಲಿ ಇರಿಸುತ್ತದೆ. ಫೈಲ್ ಸಂಪಾದಿಸುವುದು ನಿಮ್ಮ ಕಾರ್ಯ ಪ್ರತಿಯನ್ನು ಮಾತ್ರ ನವೀಕರಿಸುತ್ತದೆ. ಡೀಮನ್ ಸಂಗ್ರಹಿತ ಮೌಲ್ಯವನ್ನು ಓದುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ ನಮೂದನ್ನು ಅಳಿಸಿ ಹೊಸ ಫೈಲ್ ಅನ್ನು ಅದರ ಜಾಗದಲ್ಲಿ ಇಡುವವರೆಗೆ ಬದಲಾವಣೆ ಕಾಣುವುದಿಲ್ಲ. ಆ ಸಂಗ್ರಹಿತ ಮೌಲ್ಯವೇ ದೃಢೀಕರಣ ಸೇವೆ ನೋಡುವ ಏಕೈಕ ಪ್ರತಿ.

ಬದಲಿಸುವ ಮೊದಲು ಅದನ್ನು ಓದಿ. ಅದು ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್‌ಗೆ ಈಗಾಗಲೇ ಹೊಂದಿಕೆಯಾದರೆ, ಸಮಸ್ಯೆ ಸಂಗ್ರಹಣೆಯಲ್ಲಿಲ್ಲ ಮತ್ತು ವ್ಯಾಪ್ತಿಯ ಪ್ರಶ್ನೆಗೆ ಹೋಗಿ. ಅದು ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ತೋರಿಸಿದರೆ, ಬದಲಾವಣೆ ಸೇವೆಗೆ ತಲುಪಲಿಲ್ಲ.

./sacli -k auth.module.post_auth_script ConfigGet

ಸಂಗ್ರಹಿತ ಪ್ರತಿಯನ್ನು ಬದಲಿಸಿ, ನಂತರ ಅದನ್ನು ಅನ್ವಯಿಸಿ

ಬರೆಯುವ ಮೊದಲು ಅಳಿಸುವುದು ಅಲಂಕಾರವಲ್ಲ. ConfigPut ಜೊತೆಗೆ --value_file ಒಂದೇ ಹಂತದಲ್ಲಿ ಮೌಲ್ಯವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಮೊದಲು ConfigDel ಮಾಡುವುದು ಹಳೆಯ ಅಥವಾ ಹಾಳಾದ ನಮೂದು ಉಳಿಯುವುದನ್ನು ಅಸಾಧ್ಯ ಮಾಡುತ್ತದೆ. ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಕೆಲಸ ಮಾಡುವ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪ್ರತಿಯನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಕಡತಕೋಶದ ಹೊರಗೆ ಇರಿಸಿ.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

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

ಮೌಲ್ಯ ಫೈಲ್‌ಗೆ ಸಂಪೂರ್ಣ ಮಾರ್ಗ ಬಳಸಿ ಮತ್ತು root ಅದನ್ನು ಓದಬಲ್ಲದು ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಿಮ್ಮ ಶೆಲ್‌ನಿಂದ ಪರಿಹಾರವಾಗುವ ಆದರೆ ಸೇವಾ ಖಾತೆಯಿಂದ ಆಗದ ಮಾರ್ಗವು ConfigGet ನಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾಣುವ ಮತ್ತು ಮೊದಲ ಲಾಗಿನ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುವ ಸಂಗ್ರಹಿತ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ. sacli start ನಂತರ ಸಂಗ್ರಹಿತ ಫಲಿತಾಂಶವನ್ನು ಇನ್ನೊಮ್ಮೆ ಪರಿಶೀಲಿಸಿ, ಮೊದಲು ಅಲ್ಲ.

ಮಾಡ್ಯೂಲ್ ವ್ಯಾಪ್ತಿ ಅಥವಾ ಪ್ರತಿ ಸಂಪರ್ಕ: ಪ್ರಶ್ನೆ ಎಲ್ಲಿರಬೇಕು

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

ಪ್ರಶ್ನೆಯನ್ನು post_auth ನಿರ್ವಾಹಕದ ಒಳಗೆ ಇರಿಸಿ, ಪ್ರತಿ ದೃಢೀಕರಣಕ್ಕೂ ಚಲಿಸುವಂತೆ. ದಾಖಲಿತ ಸಹಿ ಉಳಿಸಿ, ನಿರ್ವಾಹಕ ಪಡೆಯುವ ದೃಢೀಕರಣ ಫಲಿತಾಂಶವನ್ನು ಸರಿಹೊಂದಿಸಿ, ಮತ್ತು ಬರೀ ಸಂಖ್ಯೆಯ ಬದಲು ಅದೇ ವಸ್ತುವನ್ನು ಹಿಂತಿರುಗಿಸಿ.

ಸಂಪರ್ಕ ನಿರ್ವಹಣೆಯನ್ನೂ ನಿರ್ವಾಹಕದ ಒಳಗೆ ಇರಿಸಿ. ಆಮದಿನಲ್ಲಿ ತೆರೆದ ಸಂಪರ್ಕವನ್ನು ಮೊದಲ ಬಳಕೆದಾರ ಲಾಗಿನ್ ಆಗುವ ಮೊದಲು ಸರ್ವರ್ ಮುಚ್ಚಬಹುದು, ಮತ್ತು ಉಂಟಾಗುವ ದೋಷ ಮುರಿದ ಸ್ಕ್ರಿಪ್ಟ್‌ನಂತೆ ಅಲ್ಲ, ತಿರಸ್ಕರಿಸಿದ ರುಜುವಾತಿನಂತೆ ಕಾಣುತ್ತದೆ.

ತಿರಸ್ಕಾರದ ಎರಡು ಮಾರ್ಗ, ಒಬ್ಬ ಮಾಲೀಕ

ನಿರ್ಧಾರ ಸ್ಥಳೀಯ ಪ್ರಶ್ನೆಯಾದರೆ, ಫಲಿತಾಂಶದ ಮಾಲೀಕ Python ನಿರ್ವಾಹಕ. ಅದು ಬಾಹ್ಯ HTTP ಪರಿಶೀಲನೆಯಾದರೆ, ಆದೇಶದ ನಿರ್ಗಮನ ಸ್ಥಿತಿಯೇ ಉತ್ತರವನ್ನು ಹೊತ್ತುಕೊಳ್ಳಲಿ: ಶೂನ್ಯವಲ್ಲದ ಕೋಡ್‌ನೊಂದಿಗೆ ಹೊರಡುವ ಸುತ್ತು ಲಾಗಿನ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯ ಆದೇಶದ ಸ್ಥಿತಿಯೇ ಸ್ಪಷ್ಟ exit ಇಲ್ಲದೆ ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಸ್ಥಿತಿಯಾಗುತ್ತದೆ.

ರಹಸ್ಯವನ್ನು ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿಯ ಹೊರಗೆ ಇರಿಸಿ. root ಓದಬಲ್ಲ ಫೈಲ್ ಅಥವಾ ಸೇವೆ ರವಾನಿಸುವ ಪರಿಸರ ಮೌಲ್ಯ, ಯಾವುದೇ ಸ್ಥಳೀಯ ಬಳಕೆದಾರ ps ನಿಂದ ಓದಬಲ್ಲ ವಾದಕ್ಕಿಂತ ಸುರಕ್ಷಿತ. ಕರೆಗಿಂತ ಮೊದಲು ತುದಿಯನ್ನು ಚರದಲ್ಲಿ ಸ್ಥಿರಗೊಳಿಸಿ, ಟೈಪೊ ಸಂರಚನೆಯ ಸಮಯದಲ್ಲಿ ವಿಫಲವಾಗಲಿ, ಯಾರೋ ಲಾಗಿನ್ ಆಗುವಾಗ ಅಲ್ಲ. ಆ ರಹಸ್ಯವನ್ನು ಬೇರೆ ಯಾವುದೇ ರುಜುವಾತಿನಂತೆ ಬದಲಿಸುತ್ತಿರಿ.

ಪ್ರತಿ ಪರಿಶೀಲನೆಗೆ ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ಆರಿಸಿ. ಡೇಟಾಬೇಸ್ ಕೇಳುವ ಮತ್ತು HTTP ಸೇವೆಯನ್ನು ಕರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಎರಡೂ ಭಿನ್ನವಾದಾಗಿನ ಸಂದರ್ಭಕ್ಕೆ ಘೋಷಿತ ಆದ್ಯತಾ ನಿಯಮ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಲಾಗ್‌ನಲ್ಲಿನ ತಿರಸ್ಕಾರ ಕಾರಣ ಬಳಕೆದಾರರಿಗೆ ಹೇಳಿದ್ದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ನಿರ್ವಾಹಕನನ್ನು ಲಾಕ್ ಔಟ್ ಮಾಡದೆ ಅನ್ವಯಿಸಿ

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

ಎರಡು ಷರತ್ತುಗಳು ಕಾಯಿರಿ ಎನ್ನುತ್ತವೆ: ನೀವು root ಆಗಿ ಮೌಲ್ಯ ಫೈಲ್ ಓದಲಾಗದಿದ್ದರೆ, ಅಥವಾ ನಿರ್ವಾಹಕ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಎರಡನೇ ದಾರಿ ಇಲ್ಲದಿದ್ದರೆ. ಎರಡೂ ಸಣ್ಣ ಬದಲಾವಣೆಯನ್ನು ಲಾಕ್ ಔಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ, ಮತ್ತು ದಿನದ ಕೊನೆಯಲ್ಲಿ ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಲು ಯೋಗ್ಯವಾದುದು ಒಂದೂ ಇಲ್ಲ. Access Server ದಾಖಲೆಗಳು post-auth ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಅದರ ಬೆಂಬಲಿತ ಕ್ಷೇತ್ರಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ.