status=200/CHDIR: systemd никогаш не го стартуваше OpenVPN

Услугата паѓа, дневниците споменуваат spawn и директориум, а првиот инстинкт е да се провери конфигурацијата на VPN. Од таа датотека уште ништо не е прочитано. systemd падна додека го подготвуваше процесот, пред извршната датотека да стартува, така што ниту еден парсер, ниту еден сертификат и ниту еден оддалечен домаќин не биле прашани. Читањето на кодот на состојбата како изјава за systemd, а не за OpenVPN, е она што го прави ова кратко истражување.

Прочитајте го кодот на состојбата пред апликацијата

Бројниот код по името на услугата го именува етапата што не успеала. Грешка во директориум се пријавува како состојба CHDIR, додека извршна датотека што не можела да се изврши е сосема друг код. Двете изгледаат слично во ред за резиме и немаат ништо заедничко во причините.

Таа разлика е важна зашто поправките се во различни датотеки. Грешката CHDIR се однесува на патека и на тоа како услугата ја гледа. Грешката exec се однесува на бинарната датотека, нејзиниот интерпретатор или неа поврзан mount. Менувањето на оддалечената точка на VPN, списокот на шифри или патеката до сертификатот не може да реши ниту една од двете.

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

Прашајте го unit-от каде сака да биде

Читајте го ефективниот unit, а не датотеката што мислите дека е инсталирана, зашто drop-in датотеките можат да ја заменат работната директорија без некогаш да го уредите главниот unit. Излезот на show директно одговара на прашањето:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

За шаблонот на upstream сервер работната директорија е директориумот со конфигурацијата на серверот и името на инстанцата го избира профилот внатре во неа. Затоа инстанца со име branch очекува своја датотека во истиот директориум, а профил поставен на друго место воопшто не го исполнува барањето за работна директорија.

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

Проверете ја патеката како што ја гледа услугата

Вашиот shell и услугата не делат ист поглед на датотечниот систем. Поставен коренски директориум или root image го менува значењето на апсолутната патека внатре во unit-от, а патека што очигледно постои на домаќинот може да недостасува во тој простор од имиња. Прочитајте ги поставките на unit-от пред да верувате на рачен тест.

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

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

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

Поправете го сопственикот, потоа очекувајте друга грешка

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

Спротивставете се на кратенката да ги проширите дозволите на конфигурациското дрво или да го отстраните sandbox-от. Двете го отстрануваат симптомот, а истовремено ги отстрануваат заштитите што биле намерно поставени таму, и следната грешка ќе биде потешка за толкување.

Рестартирајте ја инстанцата и прочитајте го следниот настан наместо да претпоставите успех. Веројатната следна грешка е што OpenVPN не може да ја отвори својата конфигурациска датотека, што е напредок: влезено е во работната директорија и парсерот сега работи. Оттаму следете го вистинското мапирање на датотеките на unit-от наместо да се враќате на мрежно решавање проблеми.

Референцата за извршување на systemd определува како работната директорија се толкува заедно со коренските директориуми и sandbox-от. Моделот што треба да се запомни е едноставен: секој код на состојба именува различна етапа, и само сопствените грешки на апликацијата ја опишуваат апликацијата.