Dúas configuracións resolven o mesmo problema e fallan en direccións opostas. Montar o recurso compartido no arranque dá a cada servizo un sistema de ficheiros que ou está aí ou explica por que se detivo o arranque. Unha automontaxe baixo demanda dá á máquina un arranque rápido e pasa a espera a quen toque a ruta primeiro. Detrás dunha VPN a segunda adoita ser o mellor intercambio, e a razón é que o túnel impón unha orde que a secuencia de arranque non pode ver.

Montaxe no arranque fronte a automontaxe

Unha montaxe no arranque é doada de razoar. O destino do sistema de ficheiros espera a montaxe, os servizos que declaran unha dependencia dela arrancan despois, e se o servidor non é accesible a máquina ou espera ou falla segundo as opcións. Todo o que vén detrás herda esa única decisión.

Unha automontaxe invírteo. A ruta existe de inmediato, a montaxe real ocorre cando algo a abre, e os servizos que arrancan cedo non se bloquean nun túnel que aínda non subiu.

A comparación redúcese a quen debe absorber o atraso. Unha estación de traballo que necesita o recurso antes de que o usuario poida traballar probablemente debería esperar. Un portátil que arranca dentro dunha bolsa, ou un servidor cuxo recurso é opcional, non.

Ningunha das dúas opcións arranxa unha ruta que falta. Ambas só deciden cando se observa o fallo.

A liña de fstab, opción por opción

Supoña que unha instancia de cliente OpenVPN existente é [email protected], o servidor é files.corp.example e o punto de montaxe é /mnt/work. Substitua os tres polos valores autorizados do seu propio sitio. Unha liña que funciona vese así:

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

_netdev marca a montaxe como necesitada de rede, e non nomea ningún túnel. nofail mantén o recurso opcional para o destino normal do sistema de ficheiros. x-systemd.automount crea o disparador baixo demanda en lugar de montar de inmediato.

x-systemd.requires= é a parte que ata o intento de montaxe á unidade de VPN, e pertence á operación de montaxe, non ao disparador. Poñer unha orde ampla na propia unidade de automontaxe é como a xente crea ciclos dos que logo systemd se queixa nunha lingua que ninguén le dúas veces.

x-systemd.mount-timeout=30s limita o comando de montaxe inicial. Non limita nada do que ocorre despois, e ese é o malentendido máis común sobre esta opción.

Que non significa «iniciado»

Comprobe que significa estar activo para a unidade de VPN que nomeou. Un servizo de túnel pode informar de que se iniciou antes de que exista a ruta ao servidor de ficheiros ou antes de que se resolva o nome privado, e ordenar despois del entón non lle compra nada. Nese oco vive case todo intento fallido. Tamén é invisible a menos que mire a ruta e o resolvedor en lugar do estado da unidade.

Use o propio sinal de preparación do dono da conexión como requisito previo adicional onde exista. Unha espera fixa é unha suposición que funciona no seu escritorio e falla nunha rede máis lenta ou tras unha reconexión.

Inspeccione as unidades xeradas para a ruta do exemplo: mnt-work.automount e mnt-work.mount. Tras un cambio de fstab revisado, recargue systemd e xestione esas unidades directamente en lugar de executar un comando de montaxe xeral que exercita entradas non relacionadas.

Aquí cabe unha advertencia máis. Un servizo que toca /mnt/work no arranque segue disparando a montaxe e segue esperándoa, así que marcar o recurso como opcional non fai paciente a todas as aplicacións.

Despois da montaxe o fallo é outro

Unha vez montado NFS, o comportamento de reintento e recuperación do sistema de ficheiros goberna que lle fai unha caída posterior a unha lectura ou unha escritura. O tempo de espera de montaxe que puxo non inflúe niso.

Unha montaxe suave acurta algunhas esperas e cambia a semántica dos erros, con consecuencias para a integridade dos datos fáciles de pasar por alto cando o obxectivo é un arranque máis rápido. Elixilo para gañar dous segundos de arranque raramente é un bo intercambio. Se o requisito é de verdade unha operación limitada durante unha caída, iso é unha decisión a nivel de aplicación, non un indicador de fstab.

Decida que debe pasar cun proceso que está a medio escribir cando cae o túnel, e anóteo. Esa resposta é máis útil que calquera cadea de opcións.

Probe catro estados, non un

Un arranque normal co túnel dispoñible é o caso doado e non demostra case nada. Confirma que a cadea está ben escrita e nada máis. Probe o primeiro acceso sen a VPN, logo a recuperación cando sobe, logo unha caída controlada tras unha montaxe correcta.

Catro estados, catro observacións, e as notas van xunto á entrada de fstab. A seguinte persoa herda comportamento en lugar dunha configuración que ten que reconstruír.

Artigos relacionados