Задатак се покреће при пријави, лог показује да клијент стартује, али тунел се никада не подиже. Или се подигне и нестане неколико секунди касније. У оба случаја листа својстава је вероватно била у реду. launchd је дао два обећања када је прихватио задатак: надзираће процес и тај процес ће наставити да ради. VPN-у треба оба, а исправна XML датотека не даје ниједно.

Исправна листа својстава није услуга која ради

plutil -lint проверава структуру. Не може да вам каже да ли бинарна датотека постоји, да ли ова верзија клијента подржава аргументе или да ли задатак стартује у контексту у коме су акредитиви доступни. То су семантичка питања и она објашњавају већину неуспеха који изгледају као проблеми са launchd-ом.

plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn

Прочитајте излаз друге команде уместо да претпоставите да је задатак учитан. Она пријављује последњи излазни статус и да ли услуга ради, што пре него што дирнете профил разликује „никад није стартовао” од „стартовао и умро”.

Агенти наслеђују корисничку сесију, демони не

Apple документација за launchd раздваја агенте по кориснику од системских демона. Агент ради у контексту пријављеног корисника, са његовим привеском кључева и окружењем. Демон ради без те сесије, а премештање задатка у системски директоријум не поново ствара интерактивне акредитиве корисника.

Та разлика одлучује дизајн. Ако веза захтева да се особа пријави или одобри MFA упит, подржани распоред је задатак у корисничкој сесији који се покреће после пријаве. Ако мора да ради без икога пријављеног, клијенту треба одобрени ненадгледани идентитет са сопственим процесом обнове и опозива. Избор погрешног реда даје задатак који чисто стартује и пада на првом кораку аутентификације.

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

Надзор функционише само ако процес остане напред

Клијент који сам себе претвори у демона одмах враћа контролу launchd-у, а надзорник тада гледа процес који је већ завршен. Тунел може бити подигнут, али launchd сматра да је задатак неуспешан и његова политика рестарта ће урадити нешто што нисте намеравали.

Користите документовани режим првог плана или услуге који клијент нуди. Ако производ има сопствену подржану функцију стартовања, она већ зна како да остане напред и како да преда мрежном стеку; прилагођени задатак је засебан дизајн, а не његово побољшање.

Дајте задатку јединствену ознаку, намењену извршну датотеку и промишљен низ аргумената. Низ није shell командна линија, па цеви и преусмеравања тамо не раде, а наводници се понашају другачије. Команда која успе у терминалу администратора је у најбољем случају прелиминарна провера.

Акредитиви морају да раде без упита

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

Држите тајне ван аргумената и ван стандардног излаза задатка. Ако клијент подржава читање акредитива из заштићеног складишта, користите тај пут и проверите да ли контекст извршавања задатка може да дође до складишта. Демон који ради као root обично не може да прочита ставку у привеску кључева за пријаву, а то је врста детаља која се појављује само у системском контексту.

Дефинишите шта значи спремно и тестирајте тамо

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

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

Прихватите задатак у контексту у коме ће заиста радити: без мреже при покретању, уз нормалну пријаву, буђење из сна и контролисано заустављање. Затим запишите ознаку задатка, верзију клијента и ревизију профила заједно, да следећа особа наследи услугу која се може приписати, а не датотеку која је некад радила.

Повезани чланци