Дали up скриптата на OpenVPN се изврши премногу рано или никогаш не беше подготвена?

up скриптата се извршува, излегува со нула, а задачата внатре во неа не може да стигне до приватен сервис што од терминал работи совршено две секунди подоцна. Инстинктот вели дека е работа за тајмингот, а вообичаената поправка е сон, што ја крие трката без да ја разбере. Поупатно читање е дека „up“ означува кука, а не гаранција за подготвеност. Таа се активира кога уредот за тунел е конфигуриран, што е порано од рутите, DNS и сигурно порано од која било апликација зад тунелот.

Тестот во школка успеа бидејќи се изврши откако сето се смири. Куката се изврши во еден конкретен момент.

Каде стои up во редоследот на стартување

OpenVPN го конфигурира уредот за тунел и потоа ја извршува up куката. Инсталирањето на рутите е подоцнежна фаза и има своја кука, поради што задача зависна од рути сместена во up може да види уред без корисна патека. Сместете ја работата со рути во route-up и проблемот со тајмингот обично исчезнува.

Прирачникот го документира овој редослед и околината што ја добива секоја кука. Овој редослед е целото објаснување за класичниот извештај „работи од мојата школка“, а тоа е и причината зошто истата скрипта може да помине на една машина, а да не помине на друга со поспора фаза на рутирање. Ниту еден резултат не кажува ништо за квалитетот на скриптата.

DNS и подготвеноста на апликацијата доаѓаат уште подоцна. Дури и инсталираните рути не се доказ дека далечниот крај слуша, дека името се решава или дека постои десктоп сесија за задача поврзана со корисник.

Што всушност наследува куката

Куката се извршува под сметката и околината на OpenVPN процесот, што не е исто како вашата интерактивна школка. Може да ѝ недостасува сесиска магистрала на корисникот, десктоп околина или креденцијал што се отклучува само при најава. Запишете кое од тие навистина ѝ е потребно на задачата.

Тоа е важно за задачи што изгледаат како мрежни, но зависат од кориснички контекст: монтирање споделување со кориснички креденцијал, поставување прокси по корисник или конфигурирање печатач. Привилегирана тунелска кука е погрешно место за нив, и никакво чекање не поправа сесија што недостасува.

Кога задачата ќе падне во кука, запишете ја сметката, околината и првата операција што паднала. Тоа го одвојува прераното време од проблем со дозвола или контекст, а двете имаат сосема различни поправки. Погодувањето меѓу нив е начинот на кој поправка од пет минути станува цело попладне.

Зошто додавањето сон не е проверка за подготвеност

Сонот ја одложува скриптата и го поместува прозорецот на трката. На брз ден задачата успева; на бавен ден повторно паѓа, а дефектот станува потежок за репродукција зашто изгледа дека одложувањето работи. Одложување што работи само при лесен товар е случајност, не поправка.

Ако зависноста е рута, користете ја куката што одговара на инсталирањето на рутите. Ако зависноста е сервис зад тунелот, користете ограничена проверка што го чека тој конкретен услов и јасно паѓа кога никогаш не доаѓа.

Држете го дефектот експлицитен. Кука што излегува со нула додека нејзината вистинска работа паднала е полоша од кука што паѓа, бидејќи сервисниот менаџер запишува успех и никој повеќе не гледа. Една лог-линија од самата скрипта е најевтиниот начин тоа да остане чесно.

Чистењето и повторното поврзување заслужуваат исто внимание

Скрипта што менува споделено состојба бара соодветен пат за враќање. Рутите, записите на резолверот и огнените ознаки што ги додава кука треба да бидат идемпотентни и вратливи, инаку повторното поврзување ќе натрупа втора копија врз првата.

Повторните поврзувања можат да ги извршуваат куките почесто од целосно стартување на сервисот. Постојано мрежно поврзување што ја воспоставува сесијата повторно може да го активира циклусот up и route-up, па скрипта што претпоставува едно извршување по стартување на крајот ќе работи погрешно. Избројте ги извршувањата во логот во текот на еден ден на треперење за да видите колку често навистина се извршува. Потоа направете ја скриптата безбедна да се изврши толку пати.

Тестирајте го животниот циклус што паднал, а не подоцнежна команда. Репродуцирајте го стартувањето или повторното поврзување, гледајте како се извршува куката и потврдете дека задачата успеала во моментот кога навистина се извршува. Успех од интерактивна школка потоа е доказ за зависноста, не доказ дека патот за стартување работи.

Именувајте го настанот од кој зависи секоја задача, а потоа врзете ја за тој настан. Сето друго е одложување што се преправа дека е проверка.