Стартира ли твърде рано up скриптът на OpenVPN или никога не е бил готов?

up скриптът се изпълнява, завършва с нула и задачата в него не успява да достигне частна услуга, която две секунди по-късно работи безупречно от терминал. Инстинктът подсказва проблем с времето, а обичайното решение е изчакване, което скрива надпреварата, без да я разбира. По-полезното тълкуване е, че “up” е име на кука, а не гаранция за готовност. Тя се задейства, когато тунелното устройство бъде конфигурирано, което е по-рано от маршрутите, DNS и със сигурност по-рано от всяко приложение зад тунела.

Тестът в обвивката успя, защото се изпълни, след като всичко се успокои. Куката се изпълни в един конкретен момент.

Къде стои up в реда на стартиране

OpenVPN конфигурира тунелното устройство и след това изпълнява куката up. Инсталирането на маршрути е по-късен етап и има своя собствена кука, поради което задача, зависеща от маршрут и поставена в up, може да види устройство без полезен път. Поставете работата с маршрути в route-up и проблемът с времето обикновено изчезва.

Ръководството документира този ред и средата, която получава всяка кука. Този ред е цялото обяснение на класическия доклад “работи от моята обвивка” и е също причината един и същ скрипт да минава на една машина и да се проваля на друга с по-бавен етап на маршрутите. Нито един от двата резултата не казва нищо за качеството на скрипта.

Готовността на DNS и приложенията идва още по-късно. Дори инсталираните маршрути не са доказателство, че далечният край слуша, че име се разрешава или че съществува сесия на работния плот за задача, обвързана с потребител.

Какво всъщност наследява куката

Куката се изпълнява под акаунта и средата на процеса OpenVPN, което не е същото като вашата интерактивна обвивка. Може да липсва шина за сесии на потребителя, среда на работния плот или идентификационни данни, които се отключват само при вход. Запишете кое от тези неща задачата всъщност изисква.

Това е важно за задачи, които изглеждат мрежови, но зависят от потребителски контекст: монтиране на споделен ресурс с потребителски идентификационни данни, настройване на прокси за отделен потребител или конфигуриране на принтер. Привилегированата тунелна кука е грешното място за тях и никакво чакане не поправя липсваща сесия.

Когато задача се провали в кука, запишете акаунта, средата и първата операция, която се е провалила. Това отделя преждевременното време от проблем с разрешения или контекст, а двете имат напълно различни решения. Гадаенето между тях е начинът, по който петминутно решение се превръща в цял следобед.

Защо добавянето на изчакване не е проверка за готовност

Изчакването забавя скрипта и измества прозореца на надпреварата. В бърз ден задачата успява; в бавен ден тя отново се проваля и провалът става по-труден за възпроизвеждане, защото забавянето изглежда, че работи. Забавяне, което работи само при леко натоварване, е съвпадение, а не решение.

Ако зависимостта е маршрут, използвайте куката, съответстваща на инсталирането на маршрути. Ако зависимостта е услуга зад тунела, използвайте ограничена проверка, която чака точно това условие и се проваля ясно, когато то никога не настъпи.

Пазете провала явен. Кука, която завършва с нула, докато действителната ѝ работа се е провалила, е по-лоша от кука, която се проваля, защото мениджърът на услуги записва успех и никой повече не поглежда. Ред в журнала от самия скрипт е най-евтиният начин да запазите това честно.

Почистването и повторното свързване заслужават същото внимание

Скрипт, който променя споделено състояние, се нуждае от съответстващ път за отмяна. Маршрутите, записите на резолвера и маркировките на защитната стена, добавени от кука, трябва да бъдат идемпотентни и обратими, иначе повторното свързване ще натрупа второ копие върху първото.

Повторните свързвания могат също да изпълняват куки по-често от пълно стартиране на услуга. Постоянен интерфейс, който възстановява сесия, може да задейства отново цикъла up и route-up, така че скрипт, който предполага едно изпълнение на всяко зареждане, в крайна сметка ще се държи неправилно. Пребройте изпълненията в журнала за един ден на трептене, за да видите колко често наистина се изпълнява. След това направете скрипта безопасен за толкова изпълнения.

Тествайте жизнения цикъл, който се е провалил, а не по-късна команда. Възпроизведете зареждането или повторното свързване, наблюдавайте изпълнението на куката и потвърдете, че задачата е успяла в момента, в който тя наистина се изпълнява. Успех от интерактивна обвивка след това е доказателство за зависимостта, а не доказателство, че пътят на стартиране работи.

Назовайте събитието, от което зависи всяка задача, след което я привържете към това събитие. Всичко останало е забавяне, което се представя за проверка.