PAM મોડ્યુલ અજાણ્યું છે: ખરેખર કઈ પ્રક્રિયા નિષ્ફળ ગઈ

એ વાક્યને પાસવર્ડ વિશે નહીં, પરંતુ શેર થયેલ ઑબ્જેક્ટ અને ફંક્શન પોઇન્ટર વિશેનું નિવેદન તરીકે વાંચો. એ જ શબ્દો એક OpenVPN પ્લગઇનમાંથી, એક સેવા માટે લોડ કરાયેલા PAM સ્ટેકમાંથી, અથવા RADIUS ડીમનની અંદરથી આવી શકે છે, અને એ ત્રણ અલગ તપાસ છે. પહેલા પ્રક્રિયા નક્કી કરો.

નીચેની તપાસ ધારે છે કે સંદેશો VPN લોગિન પર Linux-PAM એકીકરણ દ્વારા આવ્યો છે. જો તે RADIUS સર્વરની પોતાની રૂપરેખાંકનમાંથી આવ્યો હોય, તો તે ડીમનના પુરાવાથી શરૂ કરો.

પેકેજનું નામ આપતા પહેલા પ્રક્રિયાનું નામ આપો

ત્રણ ઘટકોને મોડ્યુલ કહેવાય છે અને તેમાંથી કોઈ પણ એકબીજાના બદલે વાપરી શકાય તેવું નથી. OpenVPN પ્રમાણીકરણ પ્લગઇન VPN ડીમન દ્વારા લોડ થાય છે અને તે ડીમનનું કૉલબેક ઇન્ટરફેસ અમલમાં મૂકે છે. PAM મોડ્યુલ એ શેર થયેલ ઑબ્જેક્ટ છે જેને libpam નામવાળી સેવા માટે લોડ કરે છે, અને જે આ પ્રકારના પ્રવેશ બિંદુઓ અમલમાં મૂકે છે: pam_sm_authenticate. FreeRADIUS મોડ્યુલ તે ડીમનની પોતાની રૂપરેખાંકનનો એક ભાગ છે. એ જ શબ્દોવાળો સંદેશો ત્રણમાંથી કોઈ પણ એકમાંથી આવી શકે છે, તેથી પહેલો પ્રશ્ન એ છે કે કઈ લોગ લાઇને તેને ઉત્પન્ન કરી.

એક નિષ્ફળ પ્રયાસનો સમયસ્ટેમ્પ VPN લોગ અને સિસ્ટમ પ્રમાણીકરણ લોગ વચ્ચે સાંકળો, પછી સારાંશ પહેલાની લાઇનો વાંચો. ચોક્કસ લોડર સંદેશો સામાન્ય રીતે ત્યાં પહેલેથી હોય છે.

લોડિંગ ભૂલ વાંચો, પછી પ્રવેશ બિંદુ

PAM અજાણ્યા મોડ્યુલની જાણ કરે છે જ્યારે તે પસંદ કરેલ શેર થયેલ ઑબ્જેક્ટ લોડ કરી શકતું નથી, અથવા જ્યારે લોડ કરેલ ઑબ્જેક્ટ તે સ્ટેક એન્ટ્રીને જરૂરી કાર્ય પૂરું પાડતું નથી. આ અલગ સુધારા છે: પહેલો પાથ, પેકેજિંગ કે ABI ની સમસ્યા છે, અને બીજો મેળ ન ખાતું પ્રવેશ બિંદુ છે. પ્રમાણીકરણ લાઇને જરૂર છે pam_sm_authenticate જ્યારે ખાતા લાઇને જરૂર છે pam_sm_acct_mgmt, અને જે લાઇબ્રેરી તેમાંથી માત્ર એક જ અમલમાં મૂકે છે તે બીજામાં નિષ્ફળ જશે, જેમ ડિસ્પેચર કોડ બતાવે છે. ડિસ્ક પર ફાઇલ મળવી એ બેમાંથી એક પણ સાબિત કરતું નથી.

બીજા ડિસ્ટ્રિબ્યુશન કે CPU આર્કિટેક્ચરમાંથી સમાન નામની લાઇબ્રેરી લેવી એ સુધારો નથી, અને તે પ્રક્રિયાને એવું મોડ્યુલ લોડ કરતી મૂકી શકે છે જે તેના libpam સામે ક્યારેય પરીક્ષણ ન કરાયું હોય. કંઈપણ બદલતા પહેલા ઇચ્છિત પાથનું માલિક પેકેજ અને ફાઇલની વાસ્તવિક આર્કિટેક્ચર તપાસો.

સ્ટેક આપતી બાંયધરીઓ જાળવી રાખો

આ ભૂલ ચૂપ કરવાનો સૌથી ઝડપી રસ્તો સૌથી ખરાબ પણ છે: જરૂરી મોડ્યુલને વૈકલ્પિક તરીકે ચિહ્નિત કરવું, ખાતા તબક્કો ડિલીટ કરવો, અથવા બિનશરતી પરવાનગી દાખલ કરવી. તેમાંથી દરેક નિષ્ફળ તપાસને ગેરહાજર તપાસમાં ફેરવે છે, અને પછી લોગિન એવા કારણોસર સફળ થાય છે જે કોઈએ ઇચ્છ્યા ન હતા. પાસવર્ડ રીસેટ અને શેર કરેલ રહસ્યમાં ફેરફાર પણ ખૂટતું કાર્ય પૂરું પાડતા નથી, કારણ કે નિષ્ફળતા કોઈ પણ ઓળખપત્ર બેકએન્ડ સુધી પહોંચે તે પહેલા જ થાય છે.

બહુ-મોડ્યુલ સ્ટેકે નિષ્ફળ એન્ટ્રી પહેલા બીજું બેકએન્ડ ચલાવ્યું હોઈ શકે, તેથી આ ભૂલ સાબિત કરતી નથી કે કોઈ RADIUS વિનંતી મોકલાઈ નથી.

મોડ્યુલ નહીં, લોગિન ચકાસો

વિસંગતિ સુધારાયા પછી વાસ્તવિક પ્રવેશ માર્ગનું પરીક્ષણ કરો. માન્ય ખાતું સફળ થવું જોઈએ, અમાન્ય ઓળખપત્રો હજી પણ નિષ્ફળ થવા જોઈએ, અને પ્રતિબંધિત ખાતું હજી પણ નકારવું જોઈએ. એ પણ ખાતરી કરો કે પ્રમાણપત્ર કે વધારાના પરિબળની કોઈ પણ આવશ્યકતા હજી લાગુ છે, કારણ કે તબક્કો છોડી દેતું સુધારેલું સ્ટેક ક્લાયન્ટની બાજુથી સફળતા જેવું દેખાય છે.

મોડ્યુલ સ્વચ્છ રીતે લોડ થવું એ પ્રગતિ છે, પૂર્ણ થયેલી કસોટી નહીં.

કયું સેવા નામ, કઈ નીતિ ફાઇલો અને કયા પ્રવેશ બિંદુઓ સંકળાયેલા હતા તે નોંધો, સાથે પુરાવા તરીકે વાપરેલા એક જ પ્રયાસ સાથે. એ નોંધ જ આગલી ઘટનાને પુરાતત્ત્વીય કસરતને બદલે શોધમાં ફેરવે છે.