ఏదైనా పంపిణీపై పనిచేసే బ్యాకప్ అప్లికేషన్‌ను సృష్టించడం అంత తేలికైన పని కాదు. Linux కోసం Veeam ఏజెంట్ Red Hat 6 మరియు Debian 6 నుండి OpenSUSE 15.1 మరియు Ubuntu 19.04 వరకు పంపిణీలపై పని చేస్తుందని నిర్ధారించుకోవడానికి, మీరు సాఫ్ట్‌వేర్ ఉత్పత్తి కెర్నల్ మాడ్యూల్‌ని కలిగి ఉన్నందున అనేక సమస్యలను పరిష్కరించాలి.
సమావేశంలో ప్రసంగం నుండి వచ్చిన అంశాల ఆధారంగా వ్యాసం సృష్టించబడింది .
Linux కేవలం అత్యంత ప్రజాదరణ పొందిన ఆపరేటింగ్ సిస్టమ్‌లలో ఒకటి కాదు. ముఖ్యంగా, ఇది ఒక ప్లాట్‌ఫారమ్, దీని ఆధారంగా మీరు ఏదైనా ప్రత్యేకమైనది, మీ స్వంతం చేసుకోవచ్చు. దీనికి ధన్యవాదాలు, Linux వారి సాఫ్ట్‌వేర్ భాగాల సెట్‌లో విభిన్నమైన అనేక పంపిణీలను కలిగి ఉంది. మరియు ఇక్కడ ఒక సమస్య తలెత్తుతుంది: ఏదైనా పంపిణీలో సాఫ్ట్‌వేర్ ఉత్పత్తి పని చేయడానికి, మీరు ప్రతి దాని లక్షణాలను పరిగణనలోకి తీసుకోవాలి.
ప్యాకేజీ నిర్వాహకులు. .deb vs .rpm
వివిధ పంపిణీలలో ఉత్పత్తిని పంపిణీ చేయడంలో స్పష్టమైన సమస్యతో ప్రారంభిద్దాం.
సాఫ్ట్‌వేర్ ఉత్పత్తులను పంపిణీ చేయడానికి అత్యంత సాధారణ మార్గం ప్యాకేజీని రిపోజిటరీలో ఉంచడం, తద్వారా సిస్టమ్‌లో నిర్మించిన ప్యాకేజీ నిర్వాహకుడు దానిని అక్కడ నుండి ఇన్‌స్టాల్ చేయవచ్చు.
అయితే, మాకు రెండు ప్రసిద్ధ ప్యాకేజీ ఫార్మాట్‌లు ఉన్నాయి: rpm и deb. అంటే అందరూ సపోర్ట్ చేయాలి.
డెబ్ ప్యాకేజీల ప్రపంచంలో, అనుకూలత స్థాయి అద్భుతమైనది. అదే ప్యాకేజీ డెబియన్ 6 మరియు ఉబుంటు 19.04 రెండింటిలోనూ సమానంగా ఇన్‌స్టాల్ చేస్తుంది మరియు పని చేస్తుంది. పాత డెబియన్ డిస్ట్రిబ్యూషన్‌లలో నిర్దేశించబడిన ప్యాకేజీలను నిర్మించడం మరియు వాటితో పని చేసే ప్రక్రియ యొక్క ప్రమాణాలు కొత్త వింతైన Linux Mint మరియు ఎలిమెంటరీ OSలో సంబంధితంగా ఉంటాయి. కాబట్టి, Linux కోసం Veeam ఏజెంట్ విషయంలో, ప్రతి హార్డ్‌వేర్ ప్లాట్‌ఫారమ్‌కు ఒక deb ప్యాకేజీ సరిపోతుంది.
కానీ 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
- libmagic1
- libfuse2
- veamsnap-kmp=3.0.2.1185
ఫలితంగా, డిపెండెన్సీల జాబితా పంపిణీకి ప్రత్యేకంగా ఉంటుంది.
అప్‌డేట్ చేయబడిన సంస్కరణ పాత ప్యాకేజీ పేరుతో దాచడం ప్రారంభించినప్పుడు అధ్వాన్నంగా ఉంటుంది.
ఉదాహరణకు:
ప్యాకేజీ ఫెడోరా 24లో నవీకరించబడింది ఎన్కర్సెస్ వెర్షన్ 5 నుండి వెర్షన్ 6 వరకు. పాత పంపిణీలతో అనుకూలతను నిర్ధారించడానికి మా ఉత్పత్తి వెర్షన్ 5తో నిర్మించబడింది. Fedora 5లో లైబ్రరీ యొక్క పాత 24వ వెర్షన్‌ని ఉపయోగించడానికి, నేను ప్యాకేజీని ఉపయోగించాల్సి వచ్చింది ncurses-compat-libs.
ఫలితంగా, వివిధ డిపెండెన్సీలతో Fedora కోసం రెండు ప్యాకేజీలు ఉన్నాయి.
మరింత ఆసక్తికరంగా. తదుపరి పంపిణీ నవీకరణ తర్వాత, ప్యాకేజీ ncurses-compat-libs లైబ్రరీ వెర్షన్ 5తో అది అందుబాటులో లేదని తేలింది. పంపిణీదారు పాత లైబ్రరీలను కొత్త పంపిణీ సంస్కరణలోకి లాగడం ఖరీదైనది. కొంత సమయం తర్వాత, సమస్య SUSE పంపిణీలలో పునరావృతమైంది.
ఫలితంగా, కొన్ని పంపిణీలు వాటిపై స్పష్టమైన ఆధారపడటాన్ని వదులుకోవలసి వచ్చింది ncurses-libs, మరియు ఉత్పత్తిని పరిష్కరించండి, తద్వారా ఇది లైబ్రరీ యొక్క ఏదైనా సంస్కరణతో పని చేయగలదు.
మార్గం ద్వారా, Red Hat వెర్షన్ 8లో ఇకపై మెటా ప్యాకేజీ లేదు పైథాన్, ఇది పాత మంచిని సూచిస్తుంది పైథాన్ 2.7. ఉంది python2 и పైథాన్3.
ప్యాకేజీ నిర్వాహకులకు ప్రత్యామ్నాయం
డిపెండెన్సీల సమస్య పాతది మరియు చాలా కాలంగా స్పష్టంగా ఉంది. డిపెండెన్సీ నరకాన్ని గుర్తుంచుకోండి.
వివిధ లైబ్రరీలు మరియు అప్లికేషన్‌లను కలపడం వలన అవన్నీ స్థిరంగా పని చేస్తాయి మరియు వైరుధ్యం లేకుండా ఉంటాయి - వాస్తవానికి, ఏదైనా Linux పంపిణీదారుడు పరిష్కరించడానికి ప్రయత్నించే పని ఇది.
ప్యాకేజీ నిర్వాహకుడు ఈ సమస్యను పూర్తిగా భిన్నమైన రీతిలో పరిష్కరించడానికి ప్రయత్నిస్తాడు. క్లిష్టమైన కానానికల్ నుండి. ప్రధాన ఆలోచన: అప్లికేషన్ ప్రధాన సిస్టమ్ నుండి వేరుచేయబడిన మరియు రక్షించబడిన శాండ్‌బాక్స్‌లో నడుస్తుంది. ఒక అప్లికేషన్‌కు లైబ్రరీలు అవసరమైతే, అవి అప్లికేషన్‌తో పాటు సరఫరా చేయబడతాయి.
Flatpak Linux కంటైనర్‌లను ఉపయోగించి శాండ్‌బాక్స్‌లో అప్లికేషన్‌లను అమలు చేయడానికి కూడా మిమ్మల్ని అనుమతిస్తుంది. శాండ్‌బాక్స్ ఆలోచన కూడా ఉపయోగించబడుతుంది AppImage.
ఈ పరిష్కారాలు ఏదైనా పంపిణీ కోసం ఒక ప్యాకేజీని సృష్టించడానికి మిమ్మల్ని అనుమతిస్తాయి. విషయంలో Flatpak అడ్మినిస్ట్రేటర్‌కు తెలియకుండానే అప్లికేషన్‌ను ఇన్‌స్టాల్ చేయడం మరియు ప్రారంభించడం సాధ్యమవుతుంది.
ప్రధాన సమస్య ఏమిటంటే అన్ని అప్లికేషన్లు శాండ్‌బాక్స్‌లో అమలు చేయబడవు. కొంతమందికి ప్లాట్‌ఫారమ్‌కి నేరుగా యాక్సెస్ అవసరం. నేను కెర్నల్ మాడ్యూల్స్ గురించి కూడా మాట్లాడటం లేదు, ఇవి ఖచ్చితంగా కెర్నల్‌పై ఆధారపడి ఉంటాయి మరియు శాండ్‌బాక్స్ కాన్సెప్ట్‌కి సరిపోవు.
రెండవ సమస్య ఏమిటంటే, Red Hat మరియు SUSE నుండి ఎంటర్‌ప్రైజ్ వాతావరణంలో జనాదరణ పొందిన పంపిణీలు ఇంకా Snappy మరియు Flatpak కోసం మద్దతును కలిగి లేవు.
ఈ విషయంలో, Linux కోసం Veeam ఏజెంట్ అందుబాటులో లేదు న కాదు .
ప్యాకేజీ నిర్వాహకుల గురించిన ప్రశ్నను ముగించడానికి, బైనరీ ఫైల్‌లను మరియు వాటిని ఒక ప్యాకేజీలో ఇన్‌స్టాల్ చేయడానికి స్క్రిప్ట్‌ను కలపడం ద్వారా ప్యాకేజీ మేనేజర్‌లను పూర్తిగా వదిలివేయడానికి ఒక ఎంపిక ఉందని నేను గమనించాలనుకుంటున్నాను.
అటువంటి బండిల్ వివిధ పంపిణీలు మరియు ప్లాట్‌ఫారమ్‌ల కోసం ఒక సాధారణ ప్యాకేజీని సృష్టించడానికి, ఇంటరాక్టివ్ ఇన్‌స్టాలేషన్ ప్రాసెస్‌ను నిర్వహించడానికి, అవసరమైన అనుకూలీకరణను నిర్వహించడానికి మిమ్మల్ని అనుమతిస్తుంది. నేను VMware నుండి Linux కోసం అటువంటి ప్యాకేజీలను మాత్రమే ఎదుర్కొన్నాను.
నవీకరణ సమస్య
అన్ని డిపెండెన్సీ సమస్యలు పరిష్కరించబడినప్పటికీ, ప్రోగ్రామ్ ఒకే పంపిణీలో భిన్నంగా అమలు కావచ్చు. ఇది నవీకరణల గురించి.
3 నవీకరణ వ్యూహాలు ఉన్నాయి:
- ఎప్పటికీ అప్‌డేట్ చేయకూడదనేది సరళమైనది. నేను సర్వర్‌ని సెటప్ చేసాను మరియు దాని గురించి మరచిపోయాను. ప్రతిదీ పని చేస్తే ఎందుకు అప్‌డేట్ చేయాలి? మీరు మద్దతును మొదటిసారి సంప్రదించినప్పుడు సమస్యలు ప్రారంభమవుతాయి. పంపిణీ సృష్టికర్త నవీకరించబడిన విడుదలకు మాత్రమే మద్దతు ఇస్తారు.
- మీరు పంపిణీదారుని విశ్వసించవచ్చు మరియు ఆటోమేటిక్ అప్‌డేట్‌లను సెటప్ చేయవచ్చు. ఈ సందర్భంలో, అప్‌డేట్ విఫలమైన వెంటనే మద్దతుకు కాల్ వచ్చే అవకాశం ఉంది.
- టెస్ట్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో అమలు చేసిన తర్వాత మాత్రమే మాన్యువల్ అప్‌డేట్ చేసే ఎంపిక అత్యంత విశ్వసనీయమైనది, కానీ ఖరీదైనది మరియు సమయం తీసుకుంటుంది. అందరూ భరించలేరు.
వేర్వేరు వినియోగదారులు వేర్వేరు నవీకరణ వ్యూహాలను ఉపయోగిస్తున్నందున, తాజా విడుదల మరియు గతంలో విడుదల చేసిన అన్నింటికి మద్దతు ఇవ్వడం అవసరం. ఇది అభివృద్ధి మరియు పరీక్ష ప్రక్రియ రెండింటినీ క్లిష్టతరం చేస్తుంది మరియు మద్దతు బృందానికి తలనొప్పిని జోడిస్తుంది.
హార్డ్‌వేర్ ప్లాట్‌ఫారమ్‌ల వెరైటీ
విభిన్న హార్డ్‌వేర్ ప్లాట్‌ఫారమ్‌లు స్థానిక కోడ్‌కు ఎక్కువగా ఉండే సమస్య. కనీసం, మీరు ప్రతి మద్దతు ఉన్న ప్లాట్‌ఫారమ్ కోసం బైనరీలను సేకరించాలి.
Linux ప్రాజెక్ట్ కోసం Veeam ఏజెంట్‌లో, మేము ఇప్పటికీ ఈ RISC వంటి వాటికి మద్దతు ఇవ్వలేము.
నేను ఈ సమస్యపై వివరంగా నివసించను. నేను ప్రధాన సమస్యలను మాత్రమే వివరిస్తాను: ప్లాట్‌ఫారమ్-ఆధారిత రకాలు, వంటివి size_t, నిర్మాణం అమరిక మరియు బైట్ క్రమం.
స్టాటిక్ మరియు/లేదా డైనమిక్ లింకింగ్
కానీ ప్రశ్న ఏమిటంటే “లైబ్రరీలతో ఎలా లింక్ చేయాలి - డైనమిక్‌గా లేదా స్టాటిక్‌గా?” చర్చించదగినది.
నియమం ప్రకారం, Linux క్రింద C/C++ అప్లికేషన్లు డైనమిక్ లింకింగ్‌ని ఉపయోగిస్తాయి. అప్లికేషన్ నిర్దిష్ట పంపిణీ కోసం ప్రత్యేకంగా రూపొందించబడితే ఇది గొప్పగా పనిచేస్తుంది.
ఒక బైనరీ ఫైల్‌తో వివిధ పంపిణీలను కవర్ చేయడం పని అయితే, మీరు పాత మద్దతు ఉన్న పంపిణీపై దృష్టి పెట్టాలి. మాకు, ఇది Red Hat 6. ఇది gcc 4.4ని కలిగి ఉంది, దీనికి C++11 ప్రమాణం కూడా మద్దతు ఇవ్వదు. .
మేము మా ప్రాజెక్ట్‌ను gcc 6.3 ఉపయోగించి నిర్మిస్తాము, ఇది C++14కి పూర్తిగా మద్దతు ఇస్తుంది. సహజంగానే, ఈ సందర్భంలో, Red Hat 6లో మీరు libstdc++ని తీసుకువెళ్లాలి మరియు మీతో లైబ్రరీలను పెంచాలి. వాటిని స్థిరంగా లింక్ చేయడం సులభమయిన మార్గం.
కానీ అయ్యో, అన్ని లైబ్రరీలు స్థిరంగా లింక్ చేయబడవు.
ముందుగా, సిస్టమ్ లైబ్రరీలు వంటివి లిబ్ఫ్యూజ్, libblkid కెర్నల్ మరియు దాని మాడ్యూల్‌లతో వాటి అనుకూలతను నిర్ధారించడానికి డైనమిక్‌గా లింక్ చేయడం అవసరం.
రెండవది, లైసెన్స్‌లతో ఒక సూక్ష్మభేదం ఉంది.
GPL లైసెన్స్ ప్రాథమికంగా లైబ్రరీలను ఓపెన్‌సోర్స్ కోడ్‌తో మాత్రమే లింక్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. MIT మరియు BSD స్టాటిక్ లింక్‌ను అనుమతిస్తాయి మరియు లైబ్రరీలను ప్రాజెక్ట్‌లో చేర్చడానికి అనుమతిస్తాయి. కానీ LGPL స్టాటిక్ లింకింగ్‌కు విరుద్ధంగా కనిపించడం లేదు, కానీ లింక్ చేయడానికి అవసరమైన ఫైల్‌లను భాగస్వామ్యం చేయడం అవసరం.
సాధారణంగా, డైనమిక్ లింకింగ్‌ని ఉపయోగించడం వలన మీరు ఏదైనా అందించకుండా నిరోధిస్తుంది.
C/C++ అప్లికేషన్‌లను రూపొందించడం
విభిన్న ప్లాట్‌ఫారమ్‌లు మరియు డిస్ట్రిబ్యూషన్‌ల కోసం C/C++ అప్లికేషన్‌లను రూపొందించడానికి, gcc యొక్క తగిన వెర్షన్‌ను ఎంచుకుని లేదా నిర్మించడానికి మరియు నిర్దిష్ట ఆర్కిటెక్చర్‌ల కోసం క్రాస్-కంపైలర్‌లను ఉపయోగించడం మరియు మొత్తం లైబ్రరీలను సమీకరించడం సరిపోతుంది. ఈ పని చాలా ఆచరణీయమైనది, కానీ చాలా సమస్యాత్మకమైనది. మరియు ఎంచుకున్న కంపైలర్ మరియు లైబ్రరీలు పని చేయదగిన సంస్కరణను అందిస్తాయనే హామీ లేదు.
స్పష్టమైన ప్రయోజనం: అవస్థాపన చాలా సరళీకృతం చేయబడింది, ఎందుకంటే మొత్తం నిర్మాణ ప్రక్రియను ఒక యంత్రంలో పూర్తి చేయవచ్చు. అదనంగా, ఒక ఆర్కిటెక్చర్ కోసం ఒక సెట్ బైనరీలను సేకరించడం సరిపోతుంది మరియు మీరు వాటిని వివిధ పంపిణీల కోసం ప్యాకేజీలుగా ప్యాక్ చేయవచ్చు. Linux కోసం Veeam ఏజెంట్ కోసం వీమ్ ప్యాకేజీలు ఈ విధంగా నిర్మించబడ్డాయి.
ఈ ఎంపికకు విరుద్ధంగా, మీరు కేవలం బిల్డ్ ఫారమ్‌ను సిద్ధం చేయవచ్చు, అంటే అసెంబ్లీ కోసం అనేక యంత్రాలు. అటువంటి ప్రతి యంత్రం నిర్దిష్ట పంపిణీ మరియు నిర్దిష్ట నిర్మాణం కోసం అప్లికేషన్ కంపైలేషన్ మరియు ప్యాకేజీ అసెంబ్లీని అందిస్తుంది. ఈ సందర్భంలో, డిస్ట్రిబ్యూటర్ తయారుచేసిన మార్గాలను ఉపయోగించి సంకలనం నిర్వహించబడుతుంది. అంటే, కంపైలర్‌ను సిద్ధం చేయడం మరియు లైబ్రరీలను ఎంచుకునే దశ తొలగించబడుతుంది. అదనంగా, నిర్మాణ ప్రక్రియను సులభంగా సమాంతరంగా చేయవచ్చు.
అయితే, ఈ విధానానికి ఒక ప్రతికూలత ఉంది: ఒకే ఆర్కిటెక్చర్‌లోని ప్రతి పంపిణీకి, మీరు మీ స్వంత బైనరీ ఫైల్‌లను సేకరించాలి. మరొక ప్రతికూలత ఏమిటంటే, ఇంత పెద్ద సంఖ్యలో యంత్రాలు నిర్వహించబడాలి మరియు పెద్ద మొత్తంలో డిస్క్ స్థలం మరియు RAM కేటాయించబడాలి.
ఈ విధంగా veamsnap కెర్నల్ మాడ్యూల్ యొక్క KMOD ప్యాకేజీలు Red Hat పంపిణీల కోసం కంపైల్ చేయబడతాయి.
బిల్డ్ సేవను తెరవండి
SUSE నుండి సహోద్యోగులు అప్లికేషన్‌లను కంపైల్ చేయడానికి మరియు ప్యాకేజీలను అసెంబ్లింగ్ చేయడానికి ప్రత్యేక సేవ రూపంలో కొంత మధ్యస్థాన్ని అమలు చేయడానికి ప్రయత్నించారు - .
ముఖ్యంగా, ఇది వర్చువల్ మెషీన్‌ను సృష్టించే హైపర్‌వైజర్, దానిలో అవసరమైన అన్ని ప్యాకేజీలను ఇన్‌స్టాల్ చేస్తుంది, అప్లికేషన్‌ను కంపైల్ చేస్తుంది మరియు ఈ వివిక్త వాతావరణంలో ప్యాకేజీని నిర్మిస్తుంది, ఆ తర్వాత వర్చువల్ మిషన్ విడుదల చేయబడుతుంది.
OpenBuildServiceలో అమలు చేయబడిన షెడ్యూలర్ సరైన ప్యాకేజీ నిర్మాణ వేగం కోసం ఎన్ని వర్చువల్ మిషన్‌లను ప్రారంభించవచ్చో నిర్ణయిస్తుంది. అంతర్నిర్మిత సంతకం మెకానిజం ప్యాకేజీలపై సంతకం చేస్తుంది మరియు వాటిని అంతర్నిర్మిత రిపోజిటరీకి అప్‌లోడ్ చేస్తుంది. అంతర్నిర్మిత సంస్కరణ నియంత్రణ వ్యవస్థ మార్పులు మరియు నిర్మాణాల చరిత్రను సేవ్ చేస్తుంది. ఈ సిస్టమ్‌కు మీ మూలాలను జోడించడం మాత్రమే మిగిలి ఉంది. మీరు సర్వర్‌ను మీరే సెటప్ చేయవలసిన అవసరం లేదు; మీరు ఓపెన్‌ను ఉపయోగించవచ్చు.
అయితే, ఒక సమస్య ఉంది: అటువంటి హార్వెస్టర్ ఇప్పటికే ఉన్న మౌలిక సదుపాయాలకు సరిపోవడం కష్టం. ఉదాహరణకు, సంస్కరణ నియంత్రణ అవసరం లేదు; మేము ఇప్పటికే సోర్స్ కోడ్‌ల కోసం మా స్వంతంగా కలిగి ఉన్నాము. మా సంతకం విధానం భిన్నంగా ఉంటుంది: మేము ప్రత్యేక సర్వర్‌ని ఉపయోగిస్తాము. రిపోజిటరీ కూడా అవసరం లేదు.
అదనంగా, ఇతర పంపిణీలకు మద్దతు - ఉదాహరణకు, Red Hat - చాలా తక్కువగా అమలు చేయబడింది, ఇది అర్థం చేసుకోదగినది.
అటువంటి సేవ యొక్క ప్రయోజనం SUSE పంపిణీ యొక్క తదుపరి సంస్కరణకు వేగవంతమైన మద్దతు. విడుదల అధికారిక ప్రకటనకు ముందు, అసెంబ్లీకి అవసరమైన ప్యాకేజీలు పబ్లిక్ రిపోజిటరీలో పోస్ట్ చేయబడతాయి. OpenBuildServiceలో అందుబాటులో ఉన్న పంపిణీల జాబితాలో కొత్తది కనిపిస్తుంది. మేము పెట్టెను తనిఖీ చేస్తాము మరియు అది నిర్మాణ ప్రణాళికకు జోడించబడుతుంది. అందువల్ల, పంపిణీ యొక్క కొత్త సంస్కరణను జోడించడం దాదాపు ఒక క్లిక్‌లో చేయబడుతుంది.
మా ఇన్‌ఫ్రాస్ట్రక్చర్‌లో, OpenBuildServiceని ఉపయోగించి, SUSE పంపిణీల కోసం వీమ్స్‌నాప్ కెర్నల్ మాడ్యూల్ యొక్క మొత్తం రకాల KMP ప్యాకేజీలు అసెంబుల్ చేయబడతాయి.
తరువాత, నేను కెర్నల్ మాడ్యూల్స్‌కు సంబంధించిన సమస్యలపై దృష్టి పెట్టాలనుకుంటున్నాను.
కెర్నల్ ABI
Linux కెర్నల్ మాడ్యూల్స్ చారిత్రాత్మకంగా మూలం రూపంలో పంపిణీ చేయబడ్డాయి. నిజానికి కెర్నల్ సృష్టికర్తలు కెర్నల్ మాడ్యూల్స్ కోసం స్థిరమైన APIకి మద్దతివ్వాలనే ఆందోళనతో భారం పడరు మరియు ముఖ్యంగా బైనరీ స్థాయిలో, దీనిని kABI అని పిలుస్తారు.
వనిల్లా కెర్నల్ కోసం మాడ్యూల్‌ను రూపొందించడానికి, మీకు ఖచ్చితంగా ఈ నిర్దిష్ట కెర్నల్ యొక్క హెడర్‌లు అవసరం మరియు ఇది ఈ కెర్నల్‌లో మాత్రమే పని చేస్తుంది.
కెర్నల్‌ను నవీకరిస్తున్నప్పుడు మాడ్యూల్‌లను నిర్మించే ప్రక్రియను ఆటోమేట్ చేయడానికి DKMS మిమ్మల్ని అనుమతిస్తుంది. ఫలితంగా, డెబియన్ రిపోజిటరీ యొక్క వినియోగదారులు (మరియు దాని చాలా మంది బంధువులు) పంపిణీదారు యొక్క రిపోజిటరీ నుండి లేదా DKMS ఉపయోగించి మూలం నుండి సంకలనం చేయబడిన కెర్నల్ మాడ్యూళ్ళను ఉపయోగిస్తారు.
అయితే, ఈ పరిస్థితి ముఖ్యంగా ఎంటర్‌ప్రైజ్ విభాగానికి సరిపోదు. ప్రొప్రైటరీ కోడ్ డిస్ట్రిబ్యూటర్‌లు ఉత్పత్తిని కంపైల్డ్ బైనరీలుగా పంపిణీ చేయాలనుకుంటున్నారు.
భద్రతా కారణాల దృష్ట్యా డెవలప్‌మెంట్ టూల్స్‌ను ప్రొడక్షన్ సర్వర్‌లలో ఉంచాలని నిర్వాహకులు కోరుకోరు. Red Hat మరియు SUSE వంటి Enterprise Linux పంపిణీదారులు తమ వినియోగదారుల కోసం స్థిరమైన kABIకి మద్దతు ఇవ్వవచ్చని నిర్ణయించుకున్నారు. ఫలితంగా Red Hat కోసం KMOD ప్యాకేజీలు మరియు SUSE కోసం KMP ప్యాకేజీలు ఉన్నాయి.
ఈ పరిష్కారం యొక్క సారాంశం చాలా సులభం. పంపిణీ యొక్క నిర్దిష్ట సంస్కరణ కోసం, కెర్నల్ API స్తంభింపజేయబడింది. పంపిణీదారు అతను కెర్నల్‌ను ఉపయోగిస్తాడని పేర్కొన్నాడు, ఉదాహరణకు, 3.10, మరియు కెర్నల్ ఇంటర్‌ఫేస్‌లను ప్రభావితం చేయని దిద్దుబాట్లు మరియు మెరుగుదలలను మాత్రమే చేస్తాడు మరియు మొదటి కెర్నల్ కోసం సేకరించిన మాడ్యూల్స్‌ను తిరిగి కంపైలేషన్ లేకుండా అన్ని తదుపరి వాటి కోసం ఉపయోగించవచ్చు.
Red Hat దాని మొత్తం జీవితచక్రం అంతటా పంపిణీకి kABI అనుకూలతను క్లెయిమ్ చేస్తుంది. అంటే, rhel 6.0 (నవంబర్ 2010 విడుదల) కోసం సమీకరించబడిన మాడ్యూల్ వెర్షన్ 6.10 (విడుదల జూన్ 2018)లో కూడా పని చేయాలి. మరియు ఇది దాదాపు 8 సంవత్సరాలు. సహజంగానే, ఈ పని చాలా కష్టం.
kABI అనుకూలత సమస్యల కారణంగా వీమ్స్‌నాప్ మాడ్యూల్ పని చేయడం ఆగిపోయిన అనేక కేసులను మేము నమోదు చేసాము.
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 విధానం ఫలితంగా, మేము మా వీమ్స్‌నాప్ మాడ్యూల్‌లో kABI అనుకూలతతో ఒక్క సమస్యను కూడా రికార్డ్ చేయలేదు. నిజమే, SUSE కోసం ప్యాకేజీల సంఖ్య దాదాపుగా ఎక్కువ పరిమాణంలో ఉంటుంది.
పాచెస్ మరియు బ్యాక్‌పోర్ట్‌లు
పంపిణీదారులు kABI అనుకూలత మరియు కెర్నల్ స్థిరత్వాన్ని నిర్ధారించడానికి ప్రయత్నించినప్పటికీ, వారు ఈ స్థిరమైన కెర్నల్ యొక్క పనితీరును మెరుగుపరచడానికి మరియు లోపాలను తొలగించడానికి కూడా ప్రయత్నిస్తారు.
అదే సమయంలో, వారి స్వంత "లోపాలపై పని"తో పాటు, Enterprise Linux కెర్నల్ యొక్క డెవలపర్లు వనిల్లా కెర్నల్‌లో మార్పులను పర్యవేక్షిస్తారు మరియు వాటిని వారి "స్థిరమైన" ఒకదానికి బదిలీ చేస్తారు.
కొన్నిసార్లు ఇది కొత్త వాటికి దారితీస్తుంది .
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 కెర్నల్ యొక్క మునుపటి విడుదల కంటే SLES 4.8 SP4.4 నుండి 12 కెర్నల్ యొక్క బ్లాక్ I/O అమలు 2 కెర్నల్‌తో సమానంగా ఉంటుంది. SP4.8 కోసం కెర్నల్ 4.4 నుండి SLES 3కి ఎంత శాతం కోడ్ బదిలీ చేయబడిందో నేను నిర్ధారించలేను, కానీ నేను కెర్నల్‌ను అదే స్థిరమైన 4.4 అని కూడా పిలవలేను.
దీని గురించి చాలా అసహ్యకరమైన విషయం ఏమిటంటే, వివిధ కెర్నల్‌లపై సమానంగా పని చేసే మాడ్యూల్‌ను వ్రాసేటప్పుడు, మీరు ఇకపై కెర్నల్ వెర్షన్‌పై ఆధారపడలేరు. మీరు పంపిణీని కూడా పరిగణనలోకి తీసుకోవాలి. కొన్నిసార్లు మీరు కొత్త కార్యాచరణతో పాటు కనిపించే నిర్వచనంలో పాల్గొనడం మంచిది, కానీ ఈ అవకాశం ఎల్లప్పుడూ కనిపించదు.
ఫలితంగా, కోడ్ విచిత్రమైన షరతులతో కూడిన సంకలన ఆదేశాలతో నిండిపోయింది.
డాక్యుమెంట్ చేయబడిన కెర్నల్ APIని మార్చే ప్యాచ్‌లు కూడా ఉన్నాయి.
నేను పంపిణీని చూశాను 5.16 మరియు ఈ కెర్నల్ వెర్షన్‌లోని lookup_bdev కాల్ ఇన్‌పుట్ పారామితుల జాబితాను మార్చడం చూసి చాలా ఆశ్చర్యపోయాను.
దీన్ని కలపడానికి, లుక్‌అప్_బిడివ్ ఫంక్షన్‌లో మాస్క్ పరామితి ఉందో లేదో తనిఖీ చేసే మేక్‌ఫైల్‌కి నేను స్క్రిప్ట్‌ను జోడించాల్సి వచ్చింది.
కెర్నల్ మాడ్యూల్స్‌పై సంతకం చేస్తోంది
అయితే ప్యాకేజీ పంపిణీ విషయానికి వద్దాం.
స్థిరమైన kABI యొక్క ప్రయోజనాల్లో ఒకటి ఏమిటంటే, కెర్నల్ మాడ్యూల్‌లను బైనరీ ఫైల్‌గా సంతకం చేయవచ్చు. ఈ సందర్భంలో, డెవలపర్ అనుకోకుండా మాడ్యూల్ దెబ్బతినలేదని లేదా ఉద్దేశపూర్వకంగా సవరించబడలేదని నిర్ధారించుకోవచ్చు. మీరు దీన్ని modinfo కమాండ్‌తో తనిఖీ చేయవచ్చు.
Red Hat మరియు SUSE డిస్ట్రిబ్యూషన్‌లు మాడ్యూల్ యొక్క సంతకాన్ని తనిఖీ చేయడానికి మిమ్మల్ని అనుమతిస్తాయి మరియు సంబంధిత సర్టిఫికేట్ సిస్టమ్‌లో నమోదు చేయబడితే మాత్రమే దానిని లోడ్ చేస్తుంది. సర్టిఫికేట్ అనేది మాడ్యూల్ సంతకం చేయబడిన పబ్లిక్ కీ. మేము దానిని ప్రత్యేక ప్యాకేజీగా పంపిణీ చేస్తాము.
ఇక్కడ సమస్య ఏమిటంటే, సర్టిఫికేట్‌లు కెర్నల్‌లో నిర్మించబడవచ్చు (పంపిణీదారులు వాటిని ఉపయోగిస్తారు) లేదా యుటిలిటీని ఉపయోగించి EFI నాన్-వోలటైల్ మెమరీకి వ్రాయబడాలి మొకుటిల్. వినియోగ మొకుటిల్ సర్టిఫికేట్‌ను ఇన్‌స్టాల్ చేస్తున్నప్పుడు, మీరు సిస్టమ్‌ను రీబూట్ చేయవలసి ఉంటుంది మరియు ఆపరేటింగ్ సిస్టమ్ కెర్నల్‌ను లోడ్ చేయడానికి ముందు కూడా, కొత్త సర్టిఫికేట్‌ను లోడ్ చేయడాన్ని అనుమతించమని నిర్వాహకుడిని అడుగుతుంది.
అందువలన, సర్టిఫికేట్‌ను జోడించడానికి సిస్టమ్‌కు భౌతిక నిర్వాహకుని యాక్సెస్ అవసరం. యంత్రం ఎక్కడో క్లౌడ్‌లో లేదా రిమోట్ సర్వర్ గదిలో ఉన్నట్లయితే మరియు యాక్సెస్ నెట్‌వర్క్ ద్వారా మాత్రమే ఉంటే (ఉదాహరణకు, ssh ద్వారా), అప్పుడు ప్రమాణపత్రాన్ని జోడించడం అసాధ్యం.
వర్చువల్ మిషన్లపై EFI
దాదాపు అన్ని మదర్‌బోర్డు తయారీదారులచే EFIకి చాలా కాలంగా మద్దతు ఉన్నప్పటికీ, సిస్టమ్‌ను ఇన్‌స్టాల్ చేసేటప్పుడు, నిర్వాహకుడు EFI అవసరం గురించి ఆలోచించకపోవచ్చు మరియు అది నిలిపివేయబడవచ్చు.
అన్ని హైపర్‌వైజర్లు EFIకి మద్దతు ఇవ్వవు. VMWare vSphere వెర్షన్ 5 నుండి EFIకి మద్దతు ఇస్తుంది.
విండోస్ సర్వర్ 2012ఆర్2 కోసం హైపర్-వితో ప్రారంభించి మైక్రోసాఫ్ట్ హైపర్-వి కూడా EFI మద్దతును పొందింది.
అయినప్పటికీ, డిఫాల్ట్ కాన్ఫిగరేషన్‌లో ఈ కార్యాచరణ Linux మెషీన్‌ల కోసం నిలిపివేయబడింది, అంటే ప్రమాణపత్రం ఇన్‌స్టాల్ చేయబడదు.
vSphere 6.5లో, ఎంపికను సెట్ చేయండి సురక్షిత బూట్ వెబ్ ఇంటర్‌ఫేస్ యొక్క పాత వెర్షన్‌లో మాత్రమే సాధ్యమవుతుంది, ఇది ఫ్లాష్ ద్వారా నడుస్తుంది. HTML-5లో వెబ్ UI ఇప్పటికీ చాలా వెనుకబడి ఉంది.
ప్రయోగాత్మక పంపిణీలు
చివరకు, అధికారిక మద్దతు లేకుండా ప్రయోగాత్మక పంపిణీలు మరియు పంపిణీల సమస్యను పరిశీలిద్దాం. ఒక వైపు, అటువంటి పంపిణీలు తీవ్రమైన సంస్థల సర్వర్‌లలో కనిపించే అవకాశం లేదు. అటువంటి పంపిణీలకు అధికారిక మద్దతు లేదు. కాబట్టి, వాటిని అందించండి. అటువంటి పంపిణీలో ఉత్పత్తికి మద్దతు ఉండదు.
అయినప్పటికీ, ఇటువంటి పంపిణీలు కొత్త ప్రయోగాత్మక పరిష్కారాలను ప్రయత్నించడానికి అనుకూలమైన వేదికగా మారతాయి. ఉదాహరణకు, Fedora, OpenSUSE Tumbleweed లేదా Debian యొక్క అస్థిర సంస్కరణలు. అవి చాలా స్థిరంగా ఉన్నాయి. వారు ఎల్లప్పుడూ ప్రోగ్రామ్‌ల యొక్క కొత్త వెర్షన్‌లను కలిగి ఉంటారు మరియు ఎల్లప్పుడూ కొత్త కెర్నల్‌ను కలిగి ఉంటారు. ఒక సంవత్సరంలో, ఈ ప్రయోగాత్మక కార్యాచరణ నవీకరించబడిన RHEL, SLES లేదా ఉబుంటులో ముగుస్తుంది.
కాబట్టి ప్రయోగాత్మక పంపిణీలో ఏదైనా పని చేయకపోతే, సమస్యను గుర్తించడానికి మరియు దాన్ని పరిష్కరించడానికి ఇది ఒక కారణం. ఈ కార్యాచరణ త్వరలో వినియోగదారుల ఉత్పత్తి సర్వర్‌లలో కనిపిస్తుంది అనే వాస్తవం కోసం మీరు సిద్ధంగా ఉండాలి.
మీరు వెర్షన్ 3.0 కోసం అధికారికంగా మద్దతు ఉన్న పంపిణీల ప్రస్తుత జాబితాను అధ్యయనం చేయవచ్చు . కానీ మా ఉత్పత్తి పని చేయగల పంపిణీల యొక్క నిజమైన జాబితా చాలా విస్తృతమైనది.
వ్యక్తిగతంగా, నేను Elbrus OS తో ప్రయోగంలో ఆసక్తి కలిగి ఉన్నాను. వీమ్ ప్యాకేజీని ఖరారు చేసిన తర్వాత, మా ఉత్పత్తి ఇన్‌స్టాల్ చేయబడింది మరియు పని చేస్తుంది. నేను హబ్రేలో ఈ ప్రయోగం గురించి వ్రాసాను .
సరే, కొత్త పంపిణీలకు మద్దతు కొనసాగుతోంది. మేము వెర్షన్ 4.0 విడుదల కోసం ఎదురు చూస్తున్నాము. బీటా కనిపించబోతోంది, కాబట్టి గమనించండి !
మూలం: www.habr.com