Profaili ya OpenVPN katika Git: nini cha kuondoa kabla ya commit

Profaili hutumikia madhumuni mawili kwa wakati mmoja: hurekodi mipangilio ya muunganisho, na hubeba kifurushi cha vitambulisho vinavyofanya kazi. Kiendelezi cha faili hakikwambii chochote kuhusu kipi kati ya hivyo viwili ulicho nacho mkononi. Soma maudhui kabla ya kuamua kuwa ni mali ya hifadhi.

Hatua zifuatazo zinadhani kwamba kiolezo cha mteja kinazingatiwa kwa udhibiti wa matoleo. Zitekeleze kwa mpangilio, na usimame kabla ya commit kitu ambacho huwezi kukibatilisha.

Soma faili unayokaribia kuiweka kwenye index

Anza na baiti halisi, kwa sababu profaili inayorejelea faili tofauti inaonekana tofauti kabisa na ile inayozipachika. Tafuta alama za block ya PEM na lebo za ndani zinazoitwa ca, cert, key, tls-auth na tls-crypt, na ukaguzi huo huo utakuonyesha hali zote mbili. Ufunguo wa faragha uliosimbwa bado unahesabika kama nyenzo nyeti, na ufunguo wa pamoja wa tls-auth au tls-crypt ni kitambulisho hata kama si utambulisho wa mtumiaji. Tumia ukaguzi huo huo kwa kila kitu kinachowekwa kwenye index pamoja na profaili, ikiwa ni pamoja na kumbukumbu na skripti za usanidi zinazorejelea faili ya vitambulisho.

Kisha angalia seti iliyowekwa kwenye index na si mti wa kazi. git diff --cached unaonyesha kile ambacho commit itakuwa nacho kweli, na hicho ndicho toleo pekee lenye maana kwa uamuzi huu.

Amua kile ambacho hifadhi inaweza kusambaza

Kiolezo kinaweza kubeba mipangilio ya pamoja iliyokaguliwa na nafasi zilizo na majina kwa kila kitu ambacho mtu hupokea wakati wa kujiandikisha. Kile ambacho hakiwezi kubeba ni utambulisho unaoweza kutumika, kwa sababu hifadhi husambazwa kwa wote wanaoweza kuisoma, ikiwa ni pamoja na uendeshaji wa kiotomatiki. Hifadhi ya faragha hupunguza hadhira bila kubadilisha swali la kama kila msomaji ameidhinishwa kwa kitambulisho hicho.

Kanuni ya kupuuza huzuia nyongeza za baadaye na haifanyi chochote kuhusu kile kilichorekodiwa tayari. Ukosefu huu wa usawa unafaa kufahamika kabla ya commit ya kwanza na si baada ya ya kumi. Majina na anwani za miundombinu ni uamuzi tofauti: si siri za uthibitishaji, lakini zinaweza kufichua zaidi ya kile timu inakusudia kuchapisha. Fanya uamuzi huo kwa uwazi badala ya kuainisha kila mstari kuwa nenosiri au wa umma.

Ikiwa nyenzo tayari ziko kwenye historia

Kuondoa mstari katika commit mpya kunaacha toleo la zamani salama kwa yeyote anayeipakua. Chukulia ufichuzi kama halisi: tambua aina ya kitambulisho, kisha tafuta mamlaka inayoweza kukibatilisha. Cheti cha mteja kinabatilishwa na orodha ya ubatilishaji huzalishwa upya; ufunguo wa pamoja wa kituo cha udhibiti hubadilishwa kwenye seva na kwa kila mteja anayeutumia.

Vyote viwili vina eneo tofauti sana la athari, na mpango unapaswa kueleza ni kipi unachotekeleza kabla ya kuanza. Tafuta commit iliyoleta nyenzo kwa utafutaji wa aina ya git log --all -S 'BEGIN PRIVATE KEY', ili wigo wa usafishaji ujulikane badala ya kukisiwa. Nakala ya mwenzako au fork inaweza kuwa tayari inashikilia kitu cha zamani, ndiyo sababu ubatilishaji huja kwanza na usafishaji baadaye.

Safisha tu baada ya kuzidhibiti

Kuandika upya historia hubadilisha kila commit baada ya ile unayohariri, kwa hivyo kwanza kunahitaji ridhaa ya mmiliki wa hifadhi na watu wanaofanya kazi ndani yake. Push ya kulazimishwa si ukarabati; ni tukio la uratibu lenye hatari yake ya kurudisha nyuma. Panga tarehe, chukua nakala rudufu, na uwaambie timu lini litatokea.

Baada ya hapo, thibitisha mti wa sasa na historia iliyobaki badala ya kuamini muhtasari wa zana.

Hifadhi matokeo kama vitu viwili: kiolezo ambacho ni salama kushirikiwa, na orodha ya vitambulisho vilivyotolewa katika mchakato wa kujiandikisha. Hakuna kati yao kinachohitaji utambulisho unaoweza kutumika uishi ndani ya hifadhi.

Mgawanyo huo ndio ukarabati halisi, na unaendelea kuishi baada ya mtu anayefuata atakaye taka commit profaili.