કયો openvpn બાઇનરી ચાલી રહ્યો છે? લોન્ચ પાથ તપાસો

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

સેવા જે પાથ શરૂ કરે તેનાથી શરૂ કરો

ટર્મિનલ અને systemd યુનિટ એક્ઝિક્યુટેબલને એક જ રીતે ઉકેલતા નથી. shell PATH માં શોધે છે; યુનિટ પાથનું નામ આપે છે, અને drop-in ઓવરરાઇડ તેને તમે વાંચી રહ્યા છો તે ફાઇલને અડ્યા વગર બદલી શકે છે. એ જ તફાવત આ કામની મોટાભાગની ગૂંચવણ સમજાવે છે. તે એ પણ નક્કી કરે છે કે તમારા સમારણે કઈ ફાઇલને નિશાન બનાવવી છે.

યુનિટને પૂછો કે તે શું ચલાવે છે, તેને બદલતા drop-in સહિત, અને તમે અધિકૃત માનો છો તે ટુકડાને બદલે પરિણામી ExecStart લાઇન વાંચો. પછી એ પાથને કોઈપણ પ્રતીકાત્મક લિંક દ્વારા અંતિમ ફાઇલ સુધી અનુસરો. છુપાયેલી ડિરેક્ટરીમાં exec સાથે પૂરો થતો રેપર આ જૂના ઉપાયોની સામાન્ય ગોઠવણ છે.

કંઈપણ બદલતા પહેલાં ઉકેલાયેલો પાથ લખી લો.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

આદેશના નામની સેવાના પાથ સાથે સરખામણી કરો

બંને જવાબો ઘણી વાર અલગ હોય છે, અને એ તફાવત આપોઆપ ખામી નથી. NetworkManager પ્લગઇન પોતાનો પાથ શરૂ કરી શકે છે, અને કન્ટેનર બીજો માઉન્ટ કરી શકે છે.

મહત્વનું એ જાણવું છે કે ટ્રાફિક પરિચર્યા કરતી પ્રક્રિયા કયો માલિક શરૂ કરે છે. જો યુનિટ /usr/local/sbin/openvpn-wrapper ચલાવે છે જ્યારે તમારો shell /usr/sbin/openvpn ઉકેલે છે, તો બીજી ફાઇલ સમારવાથી સેવામાં કંઈ બદલાતું નથી.

દરેક ઉમેદવાર કયા પેકેજની માલિકીનો છે તે પૂછો, પછી નક્કી કરો કે ફાઇલ પેકેજ-સંચાલિત છે કે સ્થાનિક રીતે મૂકેલી છે. માલિકીના પેકેજ વગરની ફાઇલ એ કોઈએ જાણી જોઈને ત્યાં મૂકેલી ફાઇલ છે, અને તે ભૂંસાય તે પહેલાં નામ, માલિક અને કારણને પાત્ર છે. ઊલટી ભૂલ પણ સામાન્ય છે: જૂની સાચવેલી બાઇનરીથી પેકેજ ફાઇલ ઉપર લખવી, કારણ કે ફોરમની પોસ્ટે એ જ ડિરેક્ટરી વાપરી હતી.

પેકેજ ફાઇલો વિશે પેકેજ ડેટાબેઝને બોલવા દો

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

ચકાસણી ચલાવો અને ખાલી પરિણામને કંઈપણનો પુરાવો ગણવાને બદલે આઉટપુટ વાંચો.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

સમારતા પહેલાં સ્થિતિ નોંધો

ઉકેલાયેલો લોન્ચ પાથ, ફાઇલનો પેકેજ સંબંધ, રેપરનું સ્થાન અને તેને દાખલ કરનાર રેકોર્ડ એકઠા કરો. જો રેપરમાં પછી જરૂરી થતું એકીકરણ કામ હોય તો તેને સુરક્ષિત જગ્યાએ નકલ કરો.

વાંચ્યા પહેલાં રેપરની સામગ્રી સહાય થ્રેડમાં પેસ્ટ ન કરો, કારણ કે આ સ્ક્રિપ્ટો ક્યારેક ઓળખપત્રો કે ગેટવેની વિગતો ધરાવે છે.

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

લોન્ચ ચકાસો, પછી રેપર દૂર કરો

સમારણ પછી સેવા શરૂ કરો અને ખાતરી કરો કે પ્રક્રિયા તમે ઇચ્છેલા પાથ પર ચાલી રહી છે. હાથે ચલાવેલી આવૃત્તિ ક્વેરી સાબિત કરે છે કે ફાઇલ કામ કરે છે; તે સાબિત કરતી નથી કે યુનિટ તેનો ઉપયોગ કરે છે.

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

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