RAM-આધારિત VPN રનટાઇમ લોગ વિશે કંઈ કહેતું નથી

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

સ્થિતિ લખી શકે તેવી દરેક પ્રક્રિયાની યાદી બનાવીને શરૂ કરો: ડેમન, પ્રમાણીકરણ સેવા, જર્નલ, કોઈપણ મોનિટરિંગ એજન્ટ અને સંચાલન સાધનો.

સંગ્રહ અને એકત્રીકરણ અલગ પ્રશ્નો છે

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

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

tmpfs એ બાંયધરી નથી

Linux tmpfs ભૌતિક RAM ડિસ્ક નથી. કર્નલ દસ્તાવેજીકરણ સ્પષ્ટ છે કે જ્યારે માઉન્ટ પરવાનગી આપે ત્યારે પૃષ્ઠો swap માં લખી શકાય છે, તેથી tmpfs ફાઇલ ડિસ્ક સુધી પહોંચી શકે છે જ્યારે એપ્લિકેશને તેને ક્યારેય ત્યાં નકલ ન કરી હોય. mount દર્શાવે છે કે swap-આધારિત tmpfs કાર્યરત છે કે નહીં, અને અન્ય મેમરી ફાઇલસિસ્ટમો ફરી અલગ રીતે વર્તે છે. /run હેઠળનો માર્ગ અસ્થિરતા સૂચવે છે એમ ધારવાને બદલે વાસ્તવિક માઉન્ટ વિકલ્પો વાંચો.

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

Journald પાસે બે ગંતવ્ય અને એક ફોરવર્ડર છે

Journald વિભાજનને સુઘડ રીતે દર્શાવે છે. અસ્થિર સંગ્રહ એન્ટ્રીઓ /run/log/journal હેઠળ રાખે છે, સ્થાયી સંગ્રહ /var/log/journal હેઠળ, અને સ્વયંસંચાલિત મોડ બંને વચ્ચે પસંદ કરે છે; અમલમાં રહેલો મોડ ચાલતી સિસ્ટમમાંથી આવે છે, ઇમેજના વર્ણનમાંથી નહીં. અસ્થિરમાં બદલવાથી પહેલેથી સ્થાયી રીતે લખાયેલું ભૂંસાતું નથી. ફોરવર્ડિંગ પણ અલગ ચેનલ છે: સ્થાનિક રીતે કંઈ ન રાખતું સંગ્રહ સેટિંગ પણ સંદેશા બીજા લક્ષ્યને સોંપી શકે છે.

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

રીબૂટ પછી શું ટકવું જોઈએ

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

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

અમલમાં રહેલી સંગ્રહ અને ફોરવર્ડિંગ ગોઠવણીની કેટલીક નિરુપદ્રવી ઘટનાઓ સાથે સરખામણી કરો, પછી મશીન રીબૂટ અથવા બદલો અને ફરી ચકાસો કે શું બચ્યું અને સેવાએ તેની સ્થિતિ ક્યાંથી પુનઃપ્રાપ્ત કરી.