É possível que o mount (8) substitua o systemd MountFlags?

1

Estou trabalhando em Debian stretch/4.14.75 e tenho sido usando meu próprio automounter ( udev-hook + shell-script ) por anos.

Como ele quebra recentemente devido ao problema de namespace que o diretório montado não é visível em outro lugar, exceto esse terminal aberto pelo automounter-script .

Embora

# sed -i "/^MountFlags/s/=.*$/=shared/" \
    /lib/systemd/system/systemd-udevd.service

tornou bom novamente, eu me pergunto se é possível mount(8) ou alguma outra manipulação para fazer um one-shot-propagação do namespace de volta para o root (?) namespace.

Eu acho que eles devem ter uma boa razão para fazer com que MountFlags=slave seja o padrão ou?

    
por Rudi 18.10.2018 / 11:08

2 respostas

2

Não, você não pode realmente propagar as montagens de volta ao namespace raiz quando estiver executando em um namespace de montagem desanexado.

Além de desativar o sandbox de namespace de montagem, você pode usar systemd-mount para corrija o problema.

Justificativa para sandboxing

O systemd prefere que as regras do udev não montem sistemas de arquivos diretamente, mas sim que ele inicie unidades (como unidades de montagem) a partir das regras do udev. É por isso que o udevd é executado em um namespace de montagem separado (com MountFlags=slave ), para evitar erros nas regras ou regras que desejam montar temporariamente um sistema de arquivos para poluir as montagens do host.

Mas, claro, no seu caso, é isso que você quer fazer, através do seu roteiro automontador.

systemd-mount

Você pode adaptar seu script automounter para trabalhar dentro do namespace de montagem separado do udevd, simplesmente substituindo as chamadas para mount por systemd-mount , que é uma ferramenta que usa os mesmos argumentos que mount (na medida do possível), mas monta os sistemas de arquivos pedindo ao systemd para fazê-lo (mais especificamente, criando uma unidade de montagem e um unidade de montagem automática para ela, ambas as unidades criadas sob o diretório transitório /run/systemd/system que não é preservado na reinicialização.)

Desativando o sandbox de montagem com uma substituição

Se você realmente quiser desabilitar o sandbox dos namespaces de montagem do udevd, use um arquivo de configuração de substituição para fazê-lo, em vez de modificar o fornecido em /lib com o pacote systemd (que provavelmente será danificado na próxima vez que pacote é atualizado pelo apt.)

Você pode abrir um arquivo de substituição no seu editor com:

$ sudo systemctl edit systemd-udevd

Onde é possível redefinir MountFlags para seu padrão ("compartilhado") com as duas linhas a seguir:

[Service]
MountFlags=

Configurar uma variável para uma string vazia geralmente a redefine para o padrão no systemd.

Por favor, note que em versões recentes do systemd isto está configurado usando PrivateMounts= , por exemplo, veja o commit que converte o arquivo de serviço do udevd para usá-lo.

O que destaca um dos problemas com a substituição: você está se desviando da configuração padrão do systemd, portanto pode acabar tendo que se adaptar de tempos em tempos, já que precisa de configuração adicional ou alternativa para manter esse funcionamento à medida que for atualizado systemd.

Além disso, você perde os benefícios do sandboxing do udevd para seu próprio namespace de montagem em primeiro lugar.

Portanto, se a solução que usa systemd-mount funcionar para você, recomendo-a durante a substituição.

    
por 18.10.2018 / 16:14
1

unidades systemd são armazenadas nestes locais:

   /etc/systemd/system/* - local configuration
   /run/systemd/system/* - runtime units
   /usr/lib/systemd/system/* - units of installed packages

Quando você deseja modificar algo, não deve modificar o arquivo no diretório /usr/lib/systemd/system/ , mas deve criar um novo arquivo de unidade com o mesmo nome no diretório /etc/systemd/system/ .

De man systemd.unit :

There are two methods of overriding vendor settings in unit files: copying the unit file from /usr/lib/systemd/system to /etc/systemd/system and modifying the chosen settings. Alternatively, one can create a directory named unit.d/ within /etc/systemd/system and place a drop-in file name.conf there that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present.

The advantage of the first method is that one easily overrides the complete unit, the vendor unit is not parsed at all anymore. It has the disadvantage that improvements to the unit file by the vendor are not automatically incorporated on updates.

The advantage of the second method is that one only overrides the settings one specifically wants, where updates to the unit by the vendor automatically apply. This has the disadvantage that some future updates by the vendor might be incompatible with the local changes.

systemd tem seu próprio mecanismo para montar volumes conforme descrito aqui :

systemd is in charge of mounting the partitions and filesystems specified in /etc/fstab. The systemd-fstab-generator(8) translates all the entries in /etc/fstab into systemd units, this is performed at boot time and whenever the configuration of the system manager is reloaded.

Eu acho que usar o seu próprio automontador com o systemd lhe dará mais problemas do que o necessário.

    
por 18.10.2018 / 11:42