sudo, &, -b или --daemon: как да оставим OpenVPN клиент във фонов режим

Във фразата „пусни го във фонов режим“ се крият два въпроса. Първият е дали този потребител изобщо може да стартира привилегирован процес; вторият е дали сесията може да продължи, без някой да пише в терминал. Амперсандът в шела не отговаря на нито един от тях, а скрипт, който пази парола за sudo в променлива, отговаря лошо на първия и оставя втория незасегнат. Разделете ги и опциите стават лесни за сравнение.

Сравнете трите кандидата по собственост, а не по удобство.

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

Добавянето на амперсанд към команда кара шела да я пусне като фонова задача, а задачата продължава да принадлежи на този шел. sudo може да попита още преди програмата да стартира, а OpenVPN може да попита след това за парола за ключ или вход. Стартирането на команда, която очаква вход, във фонов режим създава процес, който чака терминал, който никой не наблюдава. Терминалът се освобождава; взаимодействието — не.

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

sudo -b не е обработчик на удостоверения

sudo -b изпълнява командата във фонов режим от гледна точка на самия sudo, което звучи като липсващата функция, но не е. Според ръководството на sudo интерактивните команди обикновено се държат неправилно в този режим, а управлението на задачите в шела не може да управлява процесите, които той създава. Той премества процеса, без да му дава начин да отговаря на въпроси. Нищо в него не доставя парола за частен ключ или вход в шлюз.

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

--daemon променя програмата, не входа

--daemon кара самия OpenVPN да се отдели след инициализацията. Ръководството за 2.6 отбелязва, че пренасочването на syslog се случва при разбора на опцията, въпреки че отделянето става по-късно, така че съобщенията могат да спрат да се показват в терминала по-рано от очакваното. Тишината след този момент не доказва нищо за тунела. Добавете явна --log или --log-append така че изходът да попадне някъде, където можете да го прочетете.

Режимът на демон също премахва конзолата за постоянно. Защитен частен ключ изисква askpass в този режим, а въведените от конзолата удостоверения, съчетани с опции за кеширане, могат да оставят по-късно повторно удостоверяване без място, където да попита. Проверете модела за удостоверяване спрямо инсталираната версия, преди да приемете, че фоновото стартиране ще преживее първото обновяване на ключа.

Какво дава и какво не дава проверката със sudo

sudo -v валидира или обновява кешираните локални удостоверения, като удостоверява, ако политиката го изисква. Той не стартира OpenVPN, не се удостоверява пред шлюза и не гарантира, че по-късна команда в скрипта е разрешена. sudo -n означава обратното: не питай, а се провали. Това прави локалния отказ за оторизация явен, което е полезно, и не казва нищо за това какво ще поиска OpenVPN по-късно.

Нито една от опциите не е причина да се дадат безусловни команди без парола или да се подаде администраторска парола в скрипт.

Предпочитайте собственик, който може да бъде наблюдаван

За тунел, притежаван от машина, използвайте услугата, която дистрибуцията поддържа. Такъв собственик предоставя старт, стоп, статус и журнали и оцелява след края на сесията ви. Събирането на фонов режим на шела, демонизация и цикъл за рестартиране един около друг създава три собственика за един тунел и не дава ясен отговор кой работи.

Каквото и да изберете, проверете ресурса, за който съществува тунелът. Успешната заявка за стартиране е събитие на процеса, а не доказателство за работеща връзка.