మీరు డిస్క్‌లో సవరించిన 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 ఇంటర్‌ఫేస్ మరియు దాని మద్దతు ఇచ్చే ఫీల్డ్‌లను కవర్ చేస్తాయి.