ಯಾವುದೇ ವಿತರಣೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬ್ಯಾಕಪ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಚಿಸುವುದು ಸುಲಭದ ಕೆಲಸವಲ್ಲ. Linux ಗಾಗಿ Veeam ಏಜೆಂಟ್ Red Hat 6 ಮತ್ತು Debian 6 ರಿಂದ OpenSUSE 15.1 ಮತ್ತು Ubuntu 19.04 ವರೆಗಿನ ವಿತರಣೆಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನೀವು ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನವು ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸಿ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕು.
ಸಮ್ಮೇಳನದಲ್ಲಿ ಮಾಡಿದ ಭಾಷಣದ ವಸ್ತುಗಳನ್ನು ಆಧರಿಸಿ ಲೇಖನವನ್ನು ರಚಿಸಲಾಗಿದೆ .
ಲಿನಕ್ಸ್ ಕೇವಲ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಒಂದಲ್ಲ. ಮೂಲಭೂತವಾಗಿ, ಇದು ಒಂದು ವೇದಿಕೆಯಾಗಿದ್ದು, ಅದರ ಆಧಾರದ ಮೇಲೆ ನೀವು ಏನನ್ನಾದರೂ ಅನನ್ಯವಾಗಿ, ನಿಮ್ಮದೇ ಆದದನ್ನು ಮಾಡಬಹುದು. ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಲಿನಕ್ಸ್ ತಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಘಟಕಗಳ ಸೆಟ್‌ನಲ್ಲಿ ಭಿನ್ನವಾಗಿರುವ ಅನೇಕ ವಿತರಣೆಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನವು ಯಾವುದೇ ವಿತರಣೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ನೀವು ಪ್ರತಿಯೊಂದರ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕರು. .deb vs .rpm
ವಿಭಿನ್ನ ವಿತರಣೆಗಳಲ್ಲಿ ಉತ್ಪನ್ನವನ್ನು ವಿತರಿಸುವ ಸ್ಪಷ್ಟ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ.
ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನಗಳನ್ನು ವಿತರಿಸಲು ಅತ್ಯಂತ ವಿಶಿಷ್ಟವಾದ ಮಾರ್ಗವೆಂದರೆ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಇರಿಸುವುದು ಇದರಿಂದ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಅದನ್ನು ಅಲ್ಲಿಂದ ಸ್ಥಾಪಿಸಬಹುದು.
ಆದಾಗ್ಯೂ, ನಾವು ಎರಡು ಜನಪ್ರಿಯ ಪ್ಯಾಕೇಜ್ ಸ್ವರೂಪಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಆರ್ಪಿಎಮ್ и ದೇಬ್. ಇದರರ್ಥ ಎಲ್ಲರೂ ಬೆಂಬಲಿಸಬೇಕು.
ಡೆಬ್ ಪ್ಯಾಕೇಜ್‌ಗಳ ಜಗತ್ತಿನಲ್ಲಿ, ಹೊಂದಾಣಿಕೆಯ ಮಟ್ಟವು ಅದ್ಭುತವಾಗಿದೆ. ಅದೇ ಪ್ಯಾಕೇಜ್ ಡೆಬಿಯನ್ 6 ಮತ್ತು ಉಬುಂಟು 19.04 ಎರಡರಲ್ಲೂ ಸಮಾನವಾಗಿ ಸ್ಥಾಪಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ಯಾಕೇಜುಗಳನ್ನು ನಿರ್ಮಿಸುವ ಮತ್ತು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯ ಮಾನದಂಡಗಳು, ಹಳೆಯ ಡೆಬಿಯನ್ ವಿತರಣೆಗಳಲ್ಲಿ ಇಡಲಾಗಿದೆ, ಹೊಸ ಲಿನಕ್ಸ್ ಮಿಂಟ್ ಮತ್ತು ಪ್ರಾಥಮಿಕ OS ನಲ್ಲಿ ಪ್ರಸ್ತುತವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಲಿನಕ್ಸ್‌ಗಾಗಿ ವೀಮ್ ಏಜೆಂಟ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿ ಹಾರ್ಡ್‌ವೇರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಒಂದು ಡೆಬ್ ಪ್ಯಾಕೇಜ್ ಸಾಕಾಗುತ್ತದೆ.
ಆದರೆ rpm ಪ್ಯಾಕೇಜುಗಳ ಜಗತ್ತಿನಲ್ಲಿ, ವ್ಯತ್ಯಾಸಗಳು ಉತ್ತಮವಾಗಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಎರಡು ಸಂಪೂರ್ಣ ಸ್ವತಂತ್ರ ವಿತರಕರು, Red Hat ಮತ್ತು SUSE ಇವೆ, ಇದಕ್ಕೆ ಹೊಂದಾಣಿಕೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಅನಗತ್ಯವಾಗಿದೆ. ಎರಡನೆಯದಾಗಿ, ಈ ವಿತರಕರು ವಿತರಣಾ ಕಿಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಬೆಂಬಲ ಮತ್ತು ಪ್ರಾಯೋಗಿಕ. ಅವರ ನಡುವೆ ಹೊಂದಾಣಿಕೆಯ ಅವಶ್ಯಕತೆಯೂ ಇಲ್ಲ. el6, el7 ಮತ್ತು el8 ತಮ್ಮದೇ ಆದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಹೊಂದಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. Fedora ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್. SLES11 ಮತ್ತು 12 ಗಾಗಿ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು openSUSE ಗಾಗಿ ಪ್ರತ್ಯೇಕ. ಮುಖ್ಯ ಸಮಸ್ಯೆ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಹೆಸರುಗಳು.
ಅವಲಂಬನೆಯ ಸಮಸ್ಯೆ
ದುರದೃಷ್ಟವಶಾತ್, ಒಂದೇ ಪ್ಯಾಕೇಜುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ವಿಭಿನ್ನ ವಿತರಣೆಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಹೆಸರುಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ವೀಮ್ ಪ್ಯಾಕೇಜ್ ಅವಲಂಬನೆಗಳ ಭಾಗಶಃ ಪಟ್ಟಿಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.
EL7 ಗಾಗಿ:
SLES 12 ಗಾಗಿ:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- ಫ್ಯೂಸ್-ಲಿಬ್ಸ್
- ಫೈಲ್-ಲಿಬ್ಸ್
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- ಲಿಬ್ಮ್ಯಾಜಿಕ್1
- ಲಿಬ್ಫ್ಯೂಸ್2
- veeamsnap-kmp=3.0.2.1185
ಪರಿಣಾಮವಾಗಿ, ವಿತರಣೆಗಾಗಿ ಅವಲಂಬನೆಗಳ ಪಟ್ಟಿ ಅನನ್ಯವಾಗಿದೆ.
ನವೀಕರಿಸಿದ ಆವೃತ್ತಿಯು ಹಳೆಯ ಪ್ಯಾಕೇಜ್ ಹೆಸರಿನಲ್ಲಿ ಮರೆಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಕೆಟ್ಟದಾಗಿದೆ.
ಉದಾಹರಣೆ:
ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಫೆಡೋರಾ 24 ರಲ್ಲಿ ನವೀಕರಿಸಲಾಗಿದೆ ಶಾಪ ಹಾಕುತ್ತಾನೆ ಆವೃತ್ತಿ 5 ರಿಂದ ಆವೃತ್ತಿ 6 ರವರೆಗೆ. ಹಳೆಯ ವಿತರಣೆಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಆವೃತ್ತಿ 5 ನೊಂದಿಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ. Fedora 5 ನಲ್ಲಿ ಲೈಬ್ರರಿಯ ಹಳೆಯ 24 ನೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲು, ನಾನು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಬಳಸಬೇಕಾಗಿತ್ತು ncurses-compat-libs.
ಪರಿಣಾಮವಾಗಿ, ವಿವಿಧ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಫೆಡೋರಾಗೆ ಎರಡು ಪ್ಯಾಕೇಜುಗಳಿವೆ.
ಮತ್ತಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಮುಂದಿನ ವಿತರಣಾ ನವೀಕರಣದ ನಂತರ, ಪ್ಯಾಕೇಜ್ ncurses-compat-libs ಲೈಬ್ರರಿಯ ಆವೃತ್ತಿ 5 ರೊಂದಿಗೆ ಅದು ಲಭ್ಯವಿಲ್ಲ ಎಂದು ತಿರುಗುತ್ತದೆ. ಹಳೆಯ ಲೈಬ್ರರಿಗಳನ್ನು ವಿತರಣೆಯ ಹೊಸ ಆವೃತ್ತಿಗೆ ಎಳೆಯಲು ವಿತರಕರಿಗೆ ಇದು ದುಬಾರಿಯಾಗಿದೆ. ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಸಮಸ್ಯೆಯು SUSE ವಿತರಣೆಗಳಲ್ಲಿ ಪುನರಾವರ್ತನೆಯಾಯಿತು.
ಪರಿಣಾಮವಾಗಿ, ಕೆಲವು ವಿತರಣೆಗಳು ತಮ್ಮ ಸ್ಪಷ್ಟ ಅವಲಂಬನೆಯನ್ನು ಕೈಬಿಡಬೇಕಾಯಿತು ncurses-libs, ಮತ್ತು ಉತ್ಪನ್ನವನ್ನು ಸರಿಪಡಿಸಿ ಇದರಿಂದ ಅದು ಲೈಬ್ರರಿಯ ಯಾವುದೇ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು.
ಮೂಲಕ, Red Hat ನ ಆವೃತ್ತಿ 8 ರಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಮೆಟಾ ಪ್ಯಾಕೇಜ್ ಇರುವುದಿಲ್ಲ ಪೈಥಾನ್, ಇದು ಉತ್ತಮ ಹಳೆಯದನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ ಪೈಥಾನ್ 2.7. ಇದೆ ಪೈಥಾನ್ಎಕ್ಸ್ಎನ್ಎಕ್ಸ್ и ಪೈಥಾನ್3.
ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳಿಗೆ ಪರ್ಯಾಯ
ಅವಲಂಬನೆಗಳೊಂದಿಗಿನ ಸಮಸ್ಯೆ ಹಳೆಯದಾಗಿದೆ ಮತ್ತು ಬಹಳ ಹಿಂದೆಯೇ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಅವಲಂಬನೆ ನರಕವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಿ.
ವಿವಿಧ ಲೈಬ್ರರಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಅವು ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಸಂಘರ್ಷಕ್ಕೆ ಒಳಗಾಗುವುದಿಲ್ಲ - ವಾಸ್ತವವಾಗಿ, ಇದು ಯಾವುದೇ ಲಿನಕ್ಸ್ ವಿತರಕರು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಕಾರ್ಯವಾಗಿದೆ.
ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಈ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಸಿಡುಕಿನ ಕ್ಯಾನೊನಿಕಲ್ ನಿಂದ. ಮುಖ್ಯ ಆಲೋಚನೆ: ಅಪ್ಲಿಕೇಶನ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಮುಖ್ಯ ವ್ಯವಸ್ಥೆಯಿಂದ ರಕ್ಷಿಸಲಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಲೈಬ್ರರಿಗಳು ಅಗತ್ಯವಿದ್ದರೆ, ಅವುಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸರಬರಾಜು ಮಾಡಲಾಗುತ್ತದೆ.
ಫ್ಲಾಟ್ಪ್ಯಾಕ್ ಲಿನಕ್ಸ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಸಹ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಕಲ್ಪನೆಯನ್ನು ಸಹ ಬಳಸಲಾಗುತ್ತದೆ ಆಪ್ಐಮೇಜ್.
ಈ ಪರಿಹಾರಗಳು ಯಾವುದೇ ವಿತರಣೆಗಾಗಿ ಒಂದು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಸಂದರ್ಭದಲ್ಲಿ ಫ್ಲಾಟ್ಪ್ಯಾಕ್ ನಿರ್ವಾಹಕರ ಜ್ಞಾನವಿಲ್ಲದೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ಥಾಪನೆ ಮತ್ತು ಉಡಾವಣೆ ಸಾಧ್ಯ.
ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ರನ್ ಆಗುವುದಿಲ್ಲ. ಕೆಲವು ಜನರಿಗೆ ವೇದಿಕೆಗೆ ನೇರ ಪ್ರವೇಶದ ಅಗತ್ಯವಿದೆ. ನಾನು ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ, ಅದು ಕರ್ನಲ್ ಮೇಲೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅವಲಂಬಿತವಾಗಿದೆ ಮತ್ತು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಪರಿಕಲ್ಪನೆಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಎರಡನೆಯ ಸಮಸ್ಯೆಯೆಂದರೆ, Red Hat ಮತ್ತು SUSE ನಿಂದ ಎಂಟರ್ಪ್ರೈಸ್ ಪರಿಸರದಲ್ಲಿ ಜನಪ್ರಿಯವಾಗಿರುವ ವಿತರಣೆಗಳು ಇನ್ನೂ Snappy ಮತ್ತು Flatpak ಗೆ ಬೆಂಬಲವನ್ನು ಹೊಂದಿಲ್ಲ.
ಈ ನಿಟ್ಟಿನಲ್ಲಿ, Linux ಗಾಗಿ Veeam ಏಜೆಂಟ್ ಲಭ್ಯವಿಲ್ಲ ಮೇಲೆ ಅಲ್ಲ .
ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳ ಕುರಿತಾದ ಪ್ರಶ್ನೆಯನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸಲು, ಬೈನರಿ ಫೈಲ್‌ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದು ಪ್ಯಾಕೇಜ್‌ಗೆ ಸ್ಥಾಪಿಸಲು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತ್ಯಜಿಸುವ ಆಯ್ಕೆ ಇದೆ ಎಂದು ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಅಂತಹ ಬಂಡಲ್ ವಿಭಿನ್ನ ವಿತರಣೆಗಳು ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಸಂವಾದಾತ್ಮಕ ಅನುಸ್ಥಾಪನಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೈಗೊಳ್ಳಿ, ಅಗತ್ಯ ಗ್ರಾಹಕೀಕರಣವನ್ನು ಕೈಗೊಳ್ಳುತ್ತದೆ. VMware ನಿಂದ Linux ಗಾಗಿ ನಾನು ಅಂತಹ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಮಾತ್ರ ಎದುರಿಸಿದ್ದೇನೆ.
ನವೀಕರಣ ಸಮಸ್ಯೆ
ಎಲ್ಲಾ ಅವಲಂಬನೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದರೂ ಸಹ, ಪ್ರೋಗ್ರಾಂ ಒಂದೇ ವಿತರಣೆಯಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ಚಲಿಸಬಹುದು. ಇದು ನವೀಕರಣಗಳ ವಿಷಯವಾಗಿದೆ.
3 ನವೀಕರಣ ತಂತ್ರಗಳಿವೆ:
- ಸರಳವಾದದ್ದು ಎಂದಿಗೂ ನವೀಕರಿಸದಿರುವುದು. ನಾನು ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದೇನೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಮರೆತುಬಿಟ್ಟೆ. ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದರೆ ಏಕೆ ನವೀಕರಿಸಬೇಕು? ನೀವು ಮೊದಲ ಬಾರಿಗೆ ಬೆಂಬಲವನ್ನು ಸಂಪರ್ಕಿಸಿದಾಗ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ವಿತರಣೆಯ ರಚನೆಕಾರರು ನವೀಕರಿಸಿದ ಬಿಡುಗಡೆಯನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತಾರೆ.
- ನೀವು ವಿತರಕರನ್ನು ನಂಬಬಹುದು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ನವೀಕರಣಗಳನ್ನು ಹೊಂದಿಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಫಲವಾದ ನವೀಕರಣದ ನಂತರ ತಕ್ಷಣವೇ ಬೆಂಬಲಕ್ಕೆ ಕರೆ ಮಾಡುವ ಸಾಧ್ಯತೆಯಿದೆ.
- ಪರೀಕ್ಷಾ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಅದನ್ನು ಚಲಾಯಿಸಿದ ನಂತರವೇ ಹಸ್ತಚಾಲಿತ ನವೀಕರಣದ ಆಯ್ಕೆಯು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹ, ಆದರೆ ದುಬಾರಿ ಮತ್ತು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎಲ್ಲರೂ ಅದನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ.
ವಿಭಿನ್ನ ಬಳಕೆದಾರರು ವಿಭಿನ್ನ ನವೀಕರಣ ತಂತ್ರಗಳನ್ನು ಬಳಸುವುದರಿಂದ, ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆಗಳು ಮತ್ತು ಹಿಂದೆ ಬಿಡುಗಡೆಯಾದ ಎಲ್ಲವುಗಳನ್ನು ಬೆಂಬಲಿಸುವುದು ಅವಶ್ಯಕ. ಇದು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆ ಎರಡನ್ನೂ ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಬೆಂಬಲ ತಂಡಕ್ಕೆ ತಲೆನೋವು ಸೇರಿಸುತ್ತದೆ.
ಹಾರ್ಡ್‌ವೇರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ವೈವಿಧ್ಯ
ವಿಭಿನ್ನ ಹಾರ್ಡ್‌ವೇರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಸ್ಥಳೀಯ ಕೋಡ್‌ಗೆ ಹೆಚ್ಚಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿರುವ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಕನಿಷ್ಠ, ನೀವು ಪ್ರತಿ ಬೆಂಬಲಿತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಾಗಿ ಬೈನರಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು.
Linux ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ Veeam ಏಜೆಂಟ್‌ನಲ್ಲಿ, ಈ RISC ನಂತಹ ಯಾವುದನ್ನೂ ನಾವು ಇನ್ನೂ ಬೆಂಬಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಾನು ಈ ವಿಷಯದ ಬಗ್ಗೆ ವಿವರವಾಗಿ ವಾಸಿಸುವುದಿಲ್ಲ. ನಾನು ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಮಾತ್ರ ವಿವರಿಸುತ್ತೇನೆ: ವೇದಿಕೆ-ಅವಲಂಬಿತ ಪ್ರಕಾರಗಳು, ಉದಾಹರಣೆಗೆ size_t, ರಚನೆ ಜೋಡಣೆ ಮತ್ತು ಬೈಟ್ ಕ್ರಮ.
ಸ್ಥಿರ ಮತ್ತು/ಅಥವಾ ಡೈನಾಮಿಕ್ ಲಿಂಕ್ ಮಾಡುವಿಕೆ
ಆದರೆ ಪ್ರಶ್ನೆ "ಲೈಬ್ರರಿಗಳೊಂದಿಗೆ ಹೇಗೆ ಲಿಂಕ್ ಮಾಡುವುದು - ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಅಥವಾ ಸ್ಥಿರವಾಗಿ?" ಚರ್ಚಿಸಲು ಯೋಗ್ಯವಾಗಿದೆ.
ನಿಯಮದಂತೆ, ಲಿನಕ್ಸ್ ಅಡಿಯಲ್ಲಿ C/C++ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಡೈನಾಮಿಕ್ ಲಿಂಕ್ ಅನ್ನು ಬಳಸುತ್ತವೆ. ನಿರ್ದಿಷ್ಟ ವಿತರಣೆಗಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದರೆ ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಒಂದು ಬೈನರಿ ಫೈಲ್‌ನೊಂದಿಗೆ ವಿವಿಧ ವಿತರಣೆಗಳನ್ನು ಕವರ್ ಮಾಡುವುದು ಕಾರ್ಯವಾಗಿದ್ದರೆ, ನೀವು ಹಳೆಯ ಬೆಂಬಲಿತ ವಿತರಣೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕು. ನಮಗೆ, ಇದು Red Hat 6. ಇದು gcc 4.4 ಅನ್ನು ಒಳಗೊಂಡಿದೆ, ಇದು C++11 ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಸಹ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. .
C++6.3 ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೆಂಬಲಿಸುವ gcc 14 ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ನಮ್ಮ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, Red Hat 6 ನಲ್ಲಿ ನೀವು libstdc++ ಅನ್ನು ಒಯ್ಯಬೇಕು ಮತ್ತು ನಿಮ್ಮೊಂದಿಗೆ ಲೈಬ್ರರಿಗಳನ್ನು ಹೆಚ್ಚಿಸಬೇಕು. ಅವುಗಳನ್ನು ಸ್ಥಿರವಾಗಿ ಲಿಂಕ್ ಮಾಡುವುದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ.
ಆದರೆ ಅಯ್ಯೋ, ಎಲ್ಲಾ ಲೈಬ್ರರಿಗಳನ್ನು ಸ್ಥಿರವಾಗಿ ಲಿಂಕ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ.
ಮೊದಲನೆಯದಾಗಿ, ಸಿಸ್ಟಮ್ ಲೈಬ್ರರಿಗಳು ಲಿಬ್ಫ್ಯೂಸ್, libblkid ಕರ್ನಲ್ ಮತ್ತು ಅದರ ಮಾಡ್ಯೂಲ್‌ಗಳೊಂದಿಗೆ ಅವುಗಳ ಹೊಂದಾಣಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಲಿಂಕ್ ಮಾಡುವುದು ಅವಶ್ಯಕ.
ಎರಡನೆಯದಾಗಿ, ಪರವಾನಗಿಗಳೊಂದಿಗೆ ಒಂದು ಸೂಕ್ಷ್ಮತೆ ಇದೆ.
ಜಿಪಿಎಲ್ ಪರವಾನಗಿಯು ಮೂಲತಃ ಲೈಬ್ರರಿಗಳನ್ನು ಓಪನ್ ಸೋರ್ಸ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಮಾತ್ರ ಲಿಂಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. MIT ಮತ್ತು BSD ಗಳು ಸ್ಥಾಯೀ ಲಿಂಕಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತವೆ ಮತ್ತು ಲೈಬ್ರರಿಗಳನ್ನು ಯೋಜನೆಯಲ್ಲಿ ಸೇರಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. ಆದರೆ LGPL ಸ್ಥಿರ ಲಿಂಕ್ ಮಾಡುವುದನ್ನು ವಿರೋಧಿಸುವಂತೆ ತೋರುತ್ತಿಲ್ಲ, ಆದರೆ ಲಿಂಕ್ ಮಾಡಲು ಅಗತ್ಯವಾದ ಫೈಲ್‌ಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಅಗತ್ಯವಿದೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ಡೈನಾಮಿಕ್ ಲಿಂಕ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ನೀವು ಏನನ್ನೂ ಒದಗಿಸದಂತೆ ತಡೆಯುತ್ತದೆ.
C/C++ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು
ವಿಭಿನ್ನ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಮತ್ತು ವಿತರಣೆಗಳಿಗಾಗಿ C/C++ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು, gcc ಯ ಸೂಕ್ತವಾದ ಆವೃತ್ತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅಥವಾ ನಿರ್ಮಿಸಲು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಿಗಾಗಿ ಕ್ರಾಸ್-ಕಂಪೈಲರ್‌ಗಳನ್ನು ಬಳಸಲು ಮತ್ತು ಲೈಬ್ರರಿಗಳ ಸಂಪೂರ್ಣ ಸೆಟ್ ಅನ್ನು ಜೋಡಿಸಲು ಸಾಕು. ಈ ಕೆಲಸವು ಸಾಕಷ್ಟು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿದೆ, ಆದರೆ ಸಾಕಷ್ಟು ತೊಂದರೆದಾಯಕವಾಗಿದೆ. ಮತ್ತು ಆಯ್ದ ಕಂಪೈಲರ್ ಮತ್ತು ಲೈಬ್ರರಿಗಳು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಆವೃತ್ತಿಯನ್ನು ಒದಗಿಸುತ್ತವೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ.
ಒಂದು ಸ್ಪಷ್ಟ ಪ್ರಯೋಜನ: ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ಸಂಪೂರ್ಣ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಒಂದು ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ ಒಂದು ಸೆಟ್ ಬೈನರಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಕು ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ವಿವಿಧ ವಿತರಣೆಗಳಿಗಾಗಿ ಪ್ಯಾಕೇಜ್‌ಗಳಾಗಿ ಪ್ಯಾಕೇಜ್ ಮಾಡಬಹುದು. ಲಿನಕ್ಸ್‌ಗಾಗಿ ವೀಮ್ ಏಜೆಂಟ್‌ಗಾಗಿ ವೀಮ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗಿದೆ.
ಈ ಆಯ್ಕೆಗೆ ವಿರುದ್ಧವಾಗಿ, ನೀವು ಸರಳವಾಗಿ ನಿರ್ಮಾಣ ಫಾರ್ಮ್ ಅನ್ನು ತಯಾರಿಸಬಹುದು, ಅಂದರೆ, ಜೋಡಣೆಗಾಗಿ ಹಲವಾರು ಯಂತ್ರಗಳು. ಅಂತಹ ಪ್ರತಿಯೊಂದು ಯಂತ್ರವು ನಿರ್ದಿಷ್ಟ ವಿತರಣೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಸಂಕಲನ ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಜೋಡಣೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿತರಕರು ಸಿದ್ಧಪಡಿಸಿದ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಕಲನವನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ. ಅಂದರೆ, ಕಂಪೈಲರ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಮತ್ತು ಲೈಬ್ರರಿಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಹಂತವನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಲಭವಾಗಿ ಸಮಾನಾಂತರಗೊಳಿಸಬಹುದು.
ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನಕ್ಕೆ ಒಂದು ತೊಂದರೆಯೂ ಇದೆ: ಒಂದೇ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಪ್ರತಿ ವಿತರಣೆಗೆ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಬೈನರಿ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ. ಮತ್ತೊಂದು ಅನನುಕೂಲವೆಂದರೆ ಇಷ್ಟು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಯಂತ್ರಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡಿಸ್ಕ್ ಸ್ಥಳ ಮತ್ತು RAM ಅನ್ನು ನಿಯೋಜಿಸಬೇಕು.
veemsnap ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ನ KMOD ಪ್ಯಾಕೇಜುಗಳನ್ನು Red Hat ವಿತರಣೆಗಳಿಗಾಗಿ ಸಂಕಲಿಸಲಾಗಿದೆ.
ಬಿಲ್ಡ್ ಸೇವೆಯನ್ನು ತೆರೆಯಿರಿ
SUSE ಯ ಸಹೋದ್ಯೋಗಿಗಳು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕಂಪೈಲ್ ಮಾಡಲು ಮತ್ತು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಜೋಡಿಸಲು ವಿಶೇಷ ಸೇವೆಯ ರೂಪದಲ್ಲಿ ಕೆಲವು ಮಧ್ಯಮ ನೆಲವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು - .
ಮೂಲಭೂತವಾಗಿ, ಇದು ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸುವ ಹೈಪರ್ವೈಸರ್ ಆಗಿದ್ದು, ಅದರಲ್ಲಿ ಎಲ್ಲಾ ಅಗತ್ಯ ಪ್ಯಾಕೇಜುಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಈ ಪ್ರತ್ಯೇಕ ಪರಿಸರದಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ, ಅದರ ನಂತರ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ.
OpenBuildService ನಲ್ಲಿ ಅಳವಡಿಸಲಾದ ಶೆಡ್ಯೂಲರ್ ಸೂಕ್ತ ಪ್ಯಾಕೇಜ್ ಬಿಲ್ಡಿಂಗ್ ವೇಗಕ್ಕಾಗಿ ಎಷ್ಟು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಅಂತರ್ನಿರ್ಮಿತ ಸಹಿ ಕಾರ್ಯವಿಧಾನವು ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಸಹಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅಂತರ್ನಿರ್ಮಿತ ರೆಪೊಸಿಟರಿಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಅಂತರ್ನಿರ್ಮಿತ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯು ಬದಲಾವಣೆಗಳು ಮತ್ತು ನಿರ್ಮಾಣಗಳ ಇತಿಹಾಸವನ್ನು ಉಳಿಸುತ್ತದೆ. ಈ ವ್ಯವಸ್ಥೆಗೆ ನಿಮ್ಮ ಮೂಲಗಳನ್ನು ಸೇರಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. ನೀವೇ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿಲ್ಲ; ನೀವು ತೆರೆದ ಒಂದನ್ನು ಬಳಸಬಹುದು.
ಆದಾಗ್ಯೂ, ಒಂದು ಸಮಸ್ಯೆ ಇದೆ: ಅಂತಹ ಕೊಯ್ಲುಗಾರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವುದು ಕಷ್ಟ. ಉದಾಹರಣೆಗೆ, ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ಅಗತ್ಯವಿಲ್ಲ; ನಾವು ಈಗಾಗಲೇ ಮೂಲ ಕೋಡ್‌ಗಳಿಗಾಗಿ ನಮ್ಮದೇ ಆದದ್ದನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಮ್ಮ ಸಹಿ ಕಾರ್ಯವಿಧಾನವು ವಿಭಿನ್ನವಾಗಿದೆ: ನಾವು ವಿಶೇಷ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಭಂಡಾರವೂ ಬೇಕಾಗಿಲ್ಲ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇತರ ವಿತರಣೆಗಳಿಗೆ ಬೆಂಬಲ - ಉದಾಹರಣೆಗೆ, Red Hat - ಕಳಪೆಯಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ, ಇದು ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ.
ಅಂತಹ ಸೇವೆಯ ಪ್ರಯೋಜನವೆಂದರೆ SUSE ವಿತರಣೆಯ ಮುಂದಿನ ಆವೃತ್ತಿಗೆ ವೇಗದ ಬೆಂಬಲ. ಬಿಡುಗಡೆಯ ಅಧಿಕೃತ ಪ್ರಕಟಣೆಯ ಮೊದಲು, ಜೋಡಣೆಗೆ ಅಗತ್ಯವಾದ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಸಾರ್ವಜನಿಕ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗುತ್ತದೆ. OpenBuildService ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ವಿತರಣೆಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಹೊಸದು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಾವು ಬಾಕ್ಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ನಿರ್ಮಾಣ ಯೋಜನೆಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಹೀಗಾಗಿ, ವಿತರಣೆಯ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸೇರಿಸುವುದು ಬಹುತೇಕ ಒಂದೇ ಕ್ಲಿಕ್‌ನಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ.
ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ, OpenBuildService ಅನ್ನು ಬಳಸಿಕೊಂಡು, SUSE ವಿತರಣೆಗಳಿಗಾಗಿ veemsnap ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ನ ಸಂಪೂರ್ಣ ವೈವಿಧ್ಯಮಯ KMP ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಜೋಡಿಸಲಾಗಿದೆ.
ಮುಂದೆ, ನಾನು ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಸಮಸ್ಯೆಗಳ ಮೇಲೆ ವಾಸಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಕರ್ನಲ್ ABI
ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಐತಿಹಾಸಿಕವಾಗಿ ಮೂಲ ರೂಪದಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ. ವಾಸ್ತವವೆಂದರೆ ಕರ್ನಲ್ನ ರಚನೆಕಾರರು ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಸ್ಥಿರವಾದ API ಅನ್ನು ಬೆಂಬಲಿಸುವ ಕಾಳಜಿಯೊಂದಿಗೆ ತಮ್ಮನ್ನು ತಾವು ಹೊರೆ ಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ವಿಶೇಷವಾಗಿ ಬೈನರಿ ಮಟ್ಟದಲ್ಲಿ ಇದನ್ನು kABI ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ವೆನಿಲ್ಲಾ ಕರ್ನಲ್‌ಗಾಗಿ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸಲು, ನಿಮಗೆ ಖಂಡಿತವಾಗಿಯೂ ಈ ನಿರ್ದಿಷ್ಟ ಕರ್ನಲ್ನ ಹೆಡರ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಮತ್ತು ಇದು ಈ ಕರ್ನಲ್ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಕರ್ನಲ್ ಅನ್ನು ನವೀಕರಿಸುವಾಗ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು DKMS ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಡೆಬಿಯನ್ ರೆಪೊಸಿಟರಿಯ ಬಳಕೆದಾರರು (ಮತ್ತು ಅದರ ಅನೇಕ ಸಂಬಂಧಿಗಳು) ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ವಿತರಕರ ಭಂಡಾರದಿಂದ ಬಳಸುತ್ತಾರೆ ಅಥವಾ DKMS ಬಳಸಿ ಮೂಲದಿಂದ ಸಂಕಲಿಸುತ್ತಾರೆ.
ಆದಾಗ್ಯೂ, ಈ ಪರಿಸ್ಥಿತಿಯು ನಿರ್ದಿಷ್ಟವಾಗಿ ಎಂಟರ್ಪ್ರೈಸ್ ವಿಭಾಗಕ್ಕೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಸ್ವಾಮ್ಯದ ಕೋಡ್ ವಿತರಕರು ಉತ್ಪನ್ನವನ್ನು ಸಂಕಲಿಸಿದ ಬೈನರಿಗಳಾಗಿ ವಿತರಿಸಲು ಬಯಸುತ್ತಾರೆ.
ಭದ್ರತಾ ಕಾರಣಗಳಿಗಾಗಿ ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ಸಾಧನಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಲು ನಿರ್ವಾಹಕರು ಬಯಸುವುದಿಲ್ಲ. ಎಂಟರ್ಪ್ರೈಸ್ ಲಿನಕ್ಸ್ ವಿತರಕರಾದ Red Hat ಮತ್ತು SUSE ಗಳು ತಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಸ್ಥಿರವಾದ kABI ಅನ್ನು ಬೆಂಬಲಿಸಬಹುದು ಎಂದು ನಿರ್ಧರಿಸಿದರು. ಫಲಿತಾಂಶವು Red Hat ಗಾಗಿ KMOD ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು SUSE ಗಾಗಿ KMP ಪ್ಯಾಕೇಜುಗಳು.
ಈ ಪರಿಹಾರದ ಮೂಲತತ್ವವು ತುಂಬಾ ಸರಳವಾಗಿದೆ. ವಿತರಣೆಯ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಗಾಗಿ, ಕರ್ನಲ್ API ಅನ್ನು ಫ್ರೀಜ್ ಮಾಡಲಾಗಿದೆ. ವಿತರಕರು ಅವರು ಕರ್ನಲ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, 3.10, ಮತ್ತು ಕರ್ನಲ್ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದ ತಿದ್ದುಪಡಿಗಳು ಮತ್ತು ಸುಧಾರಣೆಗಳನ್ನು ಮಾತ್ರ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಮೊದಲ ಕರ್ನಲ್‌ಗಾಗಿ ಸಂಗ್ರಹಿಸಲಾದ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಮರುಸಂಕಲನವಿಲ್ಲದೆ ಎಲ್ಲಾ ನಂತರದವುಗಳಿಗೆ ಬಳಸಬಹುದು.
Red Hat ತನ್ನ ಸಂಪೂರ್ಣ ಜೀವನಚಕ್ರದ ಉದ್ದಕ್ಕೂ ವಿತರಣೆಗಾಗಿ kABI ಹೊಂದಾಣಿಕೆಯನ್ನು ಹೇಳುತ್ತದೆ. ಅಂದರೆ, rhel 6.0 (ನವೆಂಬರ್ 2010 ರ ಬಿಡುಗಡೆ) ಗಾಗಿ ಜೋಡಿಸಲಾದ ಮಾಡ್ಯೂಲ್ ಆವೃತ್ತಿ 6.10 (ಬಿಡುಗಡೆ ಜೂನ್ 2018) ನಲ್ಲಿ ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು. ಮತ್ತು ಇದು ಸುಮಾರು 8 ವರ್ಷಗಳು. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಈ ಕಾರ್ಯವು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ.
kABI ಹೊಂದಾಣಿಕೆ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ veamsnap ಮಾಡ್ಯೂಲ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಹಲವಾರು ಪ್ರಕರಣಗಳನ್ನು ನಾವು ದಾಖಲಿಸಿದ್ದೇವೆ.
RHEL 7.0 ಗಾಗಿ ಸಂಕಲಿಸಲಾದ veeamsnap ಮಾಡ್ಯೂಲ್, RHEL 7.5 ರಿಂದ ಕರ್ನಲ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂದು ಹೊರಹೊಮ್ಮಿದ ನಂತರ, ಆದರೆ ಅದು ಲೋಡ್ ಆಗಿದೆ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಲು ಖಾತರಿಯಾಯಿತು, ನಾವು RHEL 7 ಗಾಗಿ kABI ಹೊಂದಾಣಿಕೆಯ ಬಳಕೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತ್ಯಜಿಸಿದ್ದೇವೆ.
ಪ್ರಸ್ತುತ, RHEL 7 ಗಾಗಿ KMOD ಪ್ಯಾಕೇಜ್ ಪ್ರತಿ ಬಿಡುಗಡೆ ಆವೃತ್ತಿಗೆ ಅಸೆಂಬ್ಲಿ ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ.
SUSE ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ kABI ಹೊಂದಾಣಿಕೆಯ ಕಾರ್ಯವನ್ನು ಸಮೀಪಿಸಿದೆ. ಅವರು ಒಂದು ಸೇವಾ ಪ್ಯಾಕ್‌ನಲ್ಲಿ ಮಾತ್ರ kABI ಹೊಂದಾಣಿಕೆಯನ್ನು ಒದಗಿಸುತ್ತಾರೆ.
ಉದಾಹರಣೆಗೆ, SLES 12 ರ ಬಿಡುಗಡೆಯು ಸೆಪ್ಟೆಂಬರ್ 2014 ರಲ್ಲಿ ನಡೆಯಿತು. ಮತ್ತು SLES 12 SP1 ಈಗಾಗಲೇ ಡಿಸೆಂಬರ್ 2015 ರಲ್ಲಿತ್ತು, ಅಂದರೆ, ಒಂದು ವರ್ಷಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಕಳೆದಿದೆ. ಎರಡೂ ಬಿಡುಗಡೆಗಳು 3.12 ಕರ್ನಲ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೂ ಸಹ, ಅವು kABI ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಕೇವಲ ಒಂದು ವರ್ಷಕ್ಕೆ kABI ಹೊಂದಾಣಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ವಾರ್ಷಿಕ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ನವೀಕರಣ ಚಕ್ರವು ಮಾಡ್ಯೂಲ್ ರಚನೆಕಾರರಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಾರದು.
ಈ SUSE ನೀತಿಯ ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ veeamsnap ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ನಾವು kABI ಹೊಂದಾಣಿಕೆಯೊಂದಿಗೆ ಒಂದೇ ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ದಾಖಲಿಸಿಲ್ಲ. ನಿಜ, SUSE ಗಾಗಿನ ಪ್ಯಾಕೇಜುಗಳ ಸಂಖ್ಯೆಯು ಬಹುತೇಕ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಕ್ರಮವಾಗಿದೆ.
ಪ್ಯಾಚ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಕ್‌ಪೋರ್ಟ್‌ಗಳು
ವಿತರಕರು kABI ಹೊಂದಾಣಿಕೆ ಮತ್ತು ಕರ್ನಲ್ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸಿದರೂ, ಅವರು ಈ ಸ್ಥಿರ ಕರ್ನಲ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು ದೋಷಗಳನ್ನು ನಿವಾರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ತಮ್ಮದೇ ಆದ "ದೋಷಗಳ ಮೇಲೆ ಕೆಲಸ" ಜೊತೆಗೆ, ಎಂಟರ್ಪ್ರೈಸ್ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ನ ಡೆವಲಪರ್ಗಳು ವೆನಿಲ್ಲಾ ಕರ್ನಲ್ನಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ತಮ್ಮ "ಸ್ಥಿರ" ಒಂದಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ.
ಕೆಲವೊಮ್ಮೆ ಇದು ಹೊಸದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ .
Red Hat 6 ರ ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆಯಲ್ಲಿ, ಚಿಕ್ಕ ನವೀಕರಣಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ತಪ್ಪಾಗಿದೆ. ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಬಿಡುಗಡೆಯಾದಾಗ ವೀಮ್‌ಸ್ನ್ಯಾಪ್ ಮಾಡ್ಯೂಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಲು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಕಾರಣವಾಯಿತು. ನವೀಕರಣದ ಮೊದಲು ಮತ್ತು ನಂತರ ಕರ್ನಲ್ ಮೂಲಗಳನ್ನು ಹೋಲಿಸಿದ ನಂತರ, ಬ್ಯಾಕ್‌ಪೋರ್ಟ್ ಕಾರಣವೆಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ವೆನಿಲ್ಲಾ ಕರ್ನಲ್ ಆವೃತ್ತಿ 4.19 ರಲ್ಲಿ ಇದೇ ರೀತಿಯ ಪರಿಹಾರವನ್ನು ಮಾಡಲಾಗಿದೆ. ಈ ಪರಿಹಾರವು ವೆನಿಲ್ಲಾ ಕರ್ನಲ್ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಅದನ್ನು "ಸ್ಥಿರ" 2.6.32 ಗೆ ವರ್ಗಾಯಿಸುವಾಗ, ಸ್ಪಿನ್‌ಲಾಕ್‌ನೊಂದಿಗೆ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸಿದೆ.
ಸಹಜವಾಗಿ, ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾವಾಗಲೂ ದೋಷಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ, ಆದರೆ ಕೋಡ್ ಅನ್ನು 4.19 ರಿಂದ 2.6.32 ಕ್ಕೆ ಎಳೆಯುವುದು ಯೋಗ್ಯವಾಗಿದೆಯೇ? ಸ್ಥಿರತೆಗೆ ಅಪಾಯವಿದೆಯೇ?.. ನನಗೆ ಖಚಿತವಿಲ್ಲ...
"ಸ್ಥಿರತೆ" ಮತ್ತು "ಆಧುನೀಕರಣ" ನಡುವಿನ ಹಗ್ಗಜಗ್ಗಾಟದಲ್ಲಿ ಮಾರ್ಕೆಟಿಂಗ್ ತೊಡಗಿಸಿಕೊಂಡಾಗ ಕೆಟ್ಟ ವಿಷಯ. ಮಾರ್ಕೆಟಿಂಗ್ ವಿಭಾಗಕ್ಕೆ ಒಂದು ಕಡೆ ಸ್ಥಿರವಾಗಿರಲು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಉತ್ತಮವಾಗಲು ಮತ್ತು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಲು ನವೀಕರಿಸಿದ ವಿತರಣೆಯ ತಿರುಳು ಅಗತ್ಯವಿದೆ. ಇದು ವಿಚಿತ್ರ ರಾಜಿಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನಾನು SLES 4.4 SP12 ನಿಂದ ಕರ್ನಲ್ 3 ನಲ್ಲಿ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಅದರಲ್ಲಿ ವೆನಿಲ್ಲಾ 4.8 ನಿಂದ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಕಂಡು ನನಗೆ ಆಶ್ಚರ್ಯವಾಯಿತು. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, SLES 4.4 SP12 ನಿಂದ 3 ಕರ್ನಲ್ನ ಬ್ಲಾಕ್ I/O ಅನುಷ್ಠಾನವು SLES4.8 SP4.4 ನಿಂದ ಸ್ಥಿರವಾದ 12 ಕರ್ನಲ್ನ ಹಿಂದಿನ ಬಿಡುಗಡೆಗಿಂತ 2 ಕರ್ನಲ್‌ಗೆ ಹೋಲುತ್ತದೆ. SP4.8 ಗಾಗಿ ಕರ್ನಲ್ 4.4 ರಿಂದ SLES 3 ಗೆ ಎಷ್ಟು ಶೇಕಡಾ ಕೋಡ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ನಿರ್ಣಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ನಾನು ಕರ್ನಲ್ ಅನ್ನು ಅದೇ ಸ್ಥಿರ 4.4 ಎಂದು ಕರೆಯಲು ಸಹ ಸಾಧ್ಯವಿಲ್ಲ.
ಇದರ ಬಗ್ಗೆ ಅತ್ಯಂತ ಅಹಿತಕರ ವಿಷಯವೆಂದರೆ ವಿಭಿನ್ನ ಕರ್ನಲ್‌ಗಳಲ್ಲಿ ಸಮಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬರೆಯುವಾಗ, ನೀವು ಇನ್ನು ಮುಂದೆ ಕರ್ನಲ್ ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಲಾಗುವುದಿಲ್ಲ. ನೀವು ವಿತರಣೆಯನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಕೆಲವೊಮ್ಮೆ ನೀವು ಹೊಸ ಕ್ರಿಯಾತ್ಮಕತೆಯೊಂದಿಗೆ ಗೋಚರಿಸುವ ವ್ಯಾಖ್ಯಾನದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು, ಆದರೆ ಈ ಅವಕಾಶವು ಯಾವಾಗಲೂ ಗೋಚರಿಸುವುದಿಲ್ಲ.
ಪರಿಣಾಮವಾಗಿ, ಕೋಡ್ ವಿಲಕ್ಷಣವಾದ ಷರತ್ತುಬದ್ಧ ಸಂಕಲನ ನಿರ್ದೇಶನಗಳೊಂದಿಗೆ ಮಿತಿಮೀರಿ ಬೆಳೆದಿದೆ.
ದಾಖಲಿತ ಕರ್ನಲ್ API ಅನ್ನು ಬದಲಾಯಿಸುವ ಪ್ಯಾಚ್‌ಗಳು ಸಹ ಇವೆ.
ನಾನು ವಿತರಣೆಯನ್ನು ನೋಡಿದೆ 5.16 ಮತ್ತು ಈ ಕರ್ನಲ್ ಆವೃತ್ತಿಯಲ್ಲಿನ lookup_bdev ಕರೆಯು ಇನ್‌ಪುಟ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಬದಲಾಯಿಸಿರುವುದನ್ನು ನೋಡಿ ಬಹಳ ಆಶ್ಚರ್ಯವಾಯಿತು.
ಅದನ್ನು ಒಟ್ಟುಗೂಡಿಸಲು, lookup_bdev ಕಾರ್ಯವು ಮಾಸ್ಕ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಮೇಕ್‌ಫೈಲ್‌ಗೆ ನಾನು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸೇರಿಸಬೇಕಾಗಿತ್ತು.
ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಸಹಿ ಮಾಡಲಾಗುತ್ತಿದೆ
ಆದರೆ ಪ್ಯಾಕೇಜ್ ವಿತರಣೆಯ ವಿಷಯಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ.
ಸ್ಥಿರವಾದ kABI ಯ ಒಂದು ಪ್ರಯೋಜನವೆಂದರೆ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬೈನರಿ ಫೈಲ್‌ನಂತೆ ಸಹಿ ಮಾಡಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮಾಡ್ಯೂಲ್ ಆಕಸ್ಮಿಕವಾಗಿ ಹಾನಿಗೊಳಗಾಗಿಲ್ಲ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾರ್ಪಡಿಸಲಾಗಿಲ್ಲ ಎಂದು ಡೆವಲಪರ್ ಖಚಿತವಾಗಿ ಹೇಳಬಹುದು. ನೀವು ಇದನ್ನು modinfo ಆಜ್ಞೆಯೊಂದಿಗೆ ಪರಿಶೀಲಿಸಬಹುದು.
Red Hat ಮತ್ತು SUSE ವಿತರಣೆಗಳು ಮಾಡ್ಯೂಲ್‌ನ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅನುಗುಣವಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೋಂದಾಯಿಸಿದರೆ ಮಾತ್ರ ಅದನ್ನು ಲೋಡ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರವು ಮಾಡ್ಯೂಲ್ ಸಹಿ ಮಾಡಲಾದ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯಾಗಿದೆ. ನಾವು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೇಜ್ ಆಗಿ ವಿತರಿಸುತ್ತೇವೆ.
ಇಲ್ಲಿರುವ ಸಮಸ್ಯೆಯೆಂದರೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಕರ್ನಲ್ನಲ್ಲಿ ನಿರ್ಮಿಸಬಹುದು (ವಿತರಕರು ಅವುಗಳನ್ನು ಬಳಸುತ್ತಾರೆ) ಅಥವಾ ಉಪಯುಕ್ತತೆಯನ್ನು ಬಳಸಿಕೊಂಡು EFI ಅಸ್ಥಿರವಲ್ಲದ ಮೆಮೊರಿಗೆ ಬರೆಯಬೇಕು ಮೊಕುಟಿಲ್. ಉಪಯುಕ್ತತೆ ಮೊಕುಟಿಲ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ಥಾಪಿಸುವಾಗ, ನೀವು ಸಿಸ್ಟಮ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುವ ಮೊದಲು, ಹೊಸ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಲೋಡ್ ಮಾಡಲು ಅನುಮತಿಸಲು ನಿರ್ವಾಹಕರನ್ನು ಕೇಳುತ್ತದೆ.
ಹೀಗಾಗಿ, ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸೇರಿಸಲು ಸಿಸ್ಟಮ್‌ಗೆ ಭೌತಿಕ ನಿರ್ವಾಹಕರ ಪ್ರವೇಶದ ಅಗತ್ಯವಿದೆ. ಯಂತ್ರವು ಎಲ್ಲೋ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಅಥವಾ ಸರಳವಾಗಿ ರಿಮೋಟ್ ಸರ್ವರ್ ಕೋಣೆಯಲ್ಲಿದ್ದರೆ ಮತ್ತು ಪ್ರವೇಶವು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಮಾತ್ರ (ಉದಾಹರಣೆಗೆ, ssh ಮೂಲಕ), ನಂತರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸೇರಿಸುವುದು ಅಸಾಧ್ಯ.
ವರ್ಚುವಲ್ ಗಣಕಗಳಲ್ಲಿ EFI
ಬಹುತೇಕ ಎಲ್ಲಾ ಮದರ್ಬೋರ್ಡ್ ತಯಾರಕರು EFI ಅನ್ನು ದೀರ್ಘಕಾಲ ಬೆಂಬಲಿಸಿದ್ದಾರೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಸಿಸ್ಟಮ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವಾಗ, ನಿರ್ವಾಹಕರು EFI ಯ ಅಗತ್ಯತೆಯ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು.
ಎಲ್ಲಾ ಹೈಪರ್ವೈಸರ್ಗಳು EFI ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. VMWare vSphere ಆವೃತ್ತಿ 5 ರಿಂದ EFI ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
ಮೈಕ್ರೋಸಾಫ್ಟ್ ಹೈಪರ್-ವಿ ವಿಂಡೋಸ್ ಸರ್ವರ್ 2012 ಆರ್ 2 ಗಾಗಿ ಹೈಪರ್-ವಿ ಯಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಇಎಫ್‌ಐ ಬೆಂಬಲವನ್ನು ಸಹ ಪಡೆದುಕೊಂಡಿತು.
ಆದಾಗ್ಯೂ, ಡೀಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಈ ಕಾರ್ಯವನ್ನು Linux ಯಂತ್ರಗಳಿಗೆ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ಅಂದರೆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ಥಾಪಿಸಲಾಗುವುದಿಲ್ಲ.
vSphere 6.5 ರಲ್ಲಿ, ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿಸಿ ಸುರಕ್ಷಿತ ಬೂಟ್ ವೆಬ್ ಇಂಟರ್‌ಫೇಸ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಯಲ್ಲಿ ಮಾತ್ರ ಸಾಧ್ಯ, ಅದು ಫ್ಲ್ಯಾಶ್ ಮೂಲಕ ಚಲಿಸುತ್ತದೆ. HTML-5 ನಲ್ಲಿ ವೆಬ್ UI ಇನ್ನೂ ತುಂಬಾ ಹಿಂದುಳಿದಿದೆ.
ಪ್ರಾಯೋಗಿಕ ವಿತರಣೆಗಳು
ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಅಧಿಕೃತ ಬೆಂಬಲವಿಲ್ಲದೆ ಪ್ರಾಯೋಗಿಕ ವಿತರಣೆಗಳು ಮತ್ತು ವಿತರಣೆಗಳ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಗಣಿಸೋಣ. ಒಂದೆಡೆ, ಅಂತಹ ವಿತರಣೆಗಳು ಗಂಭೀರ ಸಂಸ್ಥೆಗಳ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಂಡುಬರುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ. ಅಂತಹ ವಿತರಣೆಗಳಿಗೆ ಯಾವುದೇ ಅಧಿಕೃತ ಬೆಂಬಲವಿಲ್ಲ. ಆದ್ದರಿಂದ, ಅವುಗಳನ್ನು ಒದಗಿಸಿ. ಅಂತಹ ವಿತರಣೆಯಲ್ಲಿ ಉತ್ಪನ್ನವನ್ನು ಬೆಂಬಲಿಸಲಾಗುವುದಿಲ್ಲ.
ಆದಾಗ್ಯೂ, ಅಂತಹ ವಿತರಣೆಗಳು ಹೊಸ ಪ್ರಾಯೋಗಿಕ ಪರಿಹಾರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಲು ಅನುಕೂಲಕರ ವೇದಿಕೆಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, Fedora, OpenSUSE Tumbleweed ಅಥವಾ Debian ನ ಅಸ್ಥಿರ ಆವೃತ್ತಿಗಳು. ಅವು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿವೆ. ಅವರು ಯಾವಾಗಲೂ ಪ್ರೋಗ್ರಾಂಗಳ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಯಾವಾಗಲೂ ಹೊಸ ಕರ್ನಲ್ ಅನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಒಂದು ವರ್ಷದಲ್ಲಿ, ಈ ಪ್ರಾಯೋಗಿಕ ಕಾರ್ಯವು ನವೀಕರಿಸಿದ RHEL, SLES ಅಥವಾ ಉಬುಂಟುನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬಹುದು.
ಆದ್ದರಿಂದ ಪ್ರಾಯೋಗಿಕ ವಿತರಣೆಯಲ್ಲಿ ಏನಾದರೂ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ಮತ್ತು ಅದನ್ನು ಪರಿಹರಿಸಲು ಇದು ಒಂದು ಕಾರಣವಾಗಿದೆ. ಈ ಕಾರ್ಯವು ಶೀಘ್ರದಲ್ಲೇ ಬಳಕೆದಾರರ ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ನೀವು ಸಿದ್ಧರಾಗಿರಬೇಕು.
ಆವೃತ್ತಿ 3.0 ಗಾಗಿ ಅಧಿಕೃತವಾಗಿ ಬೆಂಬಲಿತ ವಿತರಣೆಗಳ ಪ್ರಸ್ತುತ ಪಟ್ಟಿಯನ್ನು ನೀವು ಅಧ್ಯಯನ ಮಾಡಬಹುದು . ಆದರೆ ನಮ್ಮ ಉತ್ಪನ್ನವು ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದಾದ ವಿತರಣೆಗಳ ನೈಜ ಪಟ್ಟಿ ಹೆಚ್ಚು ವಿಸ್ತಾರವಾಗಿದೆ.
ವೈಯಕ್ತಿಕವಾಗಿ, ನಾನು ಎಲ್ಬ್ರಸ್ ಓಎಸ್ನ ಪ್ರಯೋಗದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೆ. ವೀಮ್ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಅಂತಿಮಗೊಳಿಸಿದ ನಂತರ, ನಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ನಾನು ಈ ಪ್ರಯೋಗದ ಬಗ್ಗೆ Habé ನಲ್ಲಿ ಬರೆದಿದ್ದೇನೆ .
ಸರಿ, ಹೊಸ ವಿತರಣೆಗಳಿಗೆ ಬೆಂಬಲ ಮುಂದುವರಿಯುತ್ತದೆ. ನಾವು ಆವೃತ್ತಿ 4.0 ಬಿಡುಗಡೆಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೇವೆ. ಬೀಟಾ ಕಾಣಿಸಿಕೊಳ್ಳಲಿದೆ, ಆದ್ದರಿಂದ ಗಮನವಿರಲಿ !
ಮೂಲ: www.habr.com