Две конфигурации го решаваат истиот проблем и паѓаат во спротивни насоки. Монтирањето на споделениот ресурс при подигнување ѝ дава на секоја служба датотечен систем што или го има или објаснува зошто подигнувањето запре. Автоматското монтирање по барање му дава на машината брзо подигнување и го предава чекањето на тој што прв ќе ја допре патеката. Зад VPN второто обично е подобрата размена, а причината е што тунелот наметнува ред што секвенцата на подигнување не може да го види.

Монтирање при подигнување наспроти автоматско монтирање

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

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

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

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

Редот во fstab, опција по опција

Да претпоставиме дека постоечката клиентска инстанца OpenVPN е [email protected], серверот е files.corp.example, а точката на монтирање е /mnt/work. Заменете ги сите три со овластените вредности од вашата локација. Еден употреблив ред изгледа вака:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev го означува монтирањето како такво на кое му е потребна мрежа и не именува никаков тунел. nofail го држи споделениот ресурс изборен за вообичаената цел на датотечниот систем. x-systemd.automount го создава активаторот по барање наместо веднаш да монтира.

x-systemd.requires= е делот што го врзува обидот за монтирање за единицата на VPN, и тој припаѓа на операцијата за монтирање, а не на активаторот. Ставањето широка наредба на самата единица за автоматско монтирање е начинот на кој луѓето создаваат циклуси за кои systemd потоа се жали на јазик што никој не го чита двапати.

x-systemd.mount-timeout=30s ја ограничува почетната команда за монтирање. Тоа не ограничува ништо што се случува потоа, и ова е најчестата заблуда за оваа опција.

Што не значи „стартувано“

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

Користете го сопствениот сигнал за подготвеност на сопственикот на врската како дополнителен предуслов каде што постои. Фиксното спиење е претпоставка што работи на вашата маса и паѓа на побавна мрежа или по повторно поврзување.

Прегледајте ги генерираните единици за патеката од примерот: mnt-work.automount и mnt-work.mount. По прегледана промена во fstab, вчитајте systemd повторно и управувајте со тие единици директно наместо да пуштате сеопфатна команда за монтирање што вежба неповрзани записи.

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

По монтирањето, дефектот е друг

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

Мекото монтирање скратува некои чекања и ја менува семантиката на грешките, со последици за интегритетот на податоците што лесно се превидуваат кога целта е побрзо подигнување. Избирањето за да се добијат две секунди стартување ретко е добра размена. Ако барањето навистина е ограничена операција за време на прекин, тоа е одлука на ниво на апликација, не знаменце во fstab.

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

Тестирајте четири состојби, не една

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

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

Поврзани статии