Como desmontar / var / usr com segurança no systemd sem reinicializar

Question

Eu tenho um servidor Linux em uma VM que a reinicialização funciona como desligamento devido à configuração incorreta de um provedor de terceiros. Eu não tenho acesso à configuração da VM.

A pessoa que instalou o sistema fez uma bagunça com o armazenamento e montou irresponsavelmente um ponto para cada diretório ( /var , /home , /usr , etc ...) levando-os a ficarem facilmente carentes de alguns e vazios para os outros.

Para corrigir essa confusão, estou reorganizando os pontos de montagem, consegui gerenciar a maioria deles, fazendo mount --bind / /mnt seguido de rsync e, em seguida, relançando o processo que os usa depois de umount .

O problema é o /var e /usr que é usado pelo próprio processo init do systemd. Será que systemd-remount-fs faz o truque? Como eu poderia permear isso? Seria um simples fstab edit seguido por rsync ser suficiente? Irá reiniciar todos os serviços?

Eu sei quais pontos realmente precisam de partições separadas para o meu caso, e este não é o caso de /var e /usr .

A premissa é que eu não posso usar umount -l pois eu terei que destruir a partição depois de remontar aquela, e eu gostaria de evitar kexec devido a não saber se ela terá o mesmo efeito de bugs nessa configuração incorreta VM de ser incapaz de trazer isso de novo.

Estou planejando ter uma partição btrfs compactada para /var/log e outra btrfs ou xfs para /var/lib/docker e coloque todos os outros juntos com o espaço mínimo necessário possível, uma vez que eles estarão quase estáticos . E no futuro eu posso colocá-los como squashfs junto com o root e montar um overlayfs para facilitar a detecção de erros de configuração. Eu gostaria de poder fazer tudo isso sem reiniciar, embora eu não saiba que poderei.

    

Answer 1

ATENÇÃO: estas operações são extremamente arriscadas, não dou nenhuma garantia sobre isso, é recomendável que você entenda cada passo e aplique-o a seu próprio risco, se você provavelmente não vai quebrar o seu sistema e eu não sou responsável por quaisquer danos decorrentes do seu uso.

Eu clonei todos os discos do servidor em uma máquina virtual local em minha estação de trabalho para tentar os comandos sem afetar meu servidor original, se você não tiver certeza de que pode fazer o mesmo. Depois de uma extensa pesquisa e vários experimentos, finalmente encontrei uma solução.

Alguns sistemas usam systemd no initrd , após a montagem da raiz de destino, ele alterna o ambiente systemd da mesma forma que você faria com o chroot, todos os serviços são encerrados e, em seguida, reiniciados no novo ambiente.

Poderíamos aproveitar esse recurso para alterar a raiz novamente, fazendo isso em um ambiente clonado em outro disco que libera os bloqueios que o sistema mantém no ambiente mais antigo, para que você possa desmontar esses pontos com segurança. nem mesmo ser montado. Mas esse ambiente clonado deve garantir a configuração correta para reativar a rede e fornecer acesso ssh. Se isso não acontecer, considere-se condenado.

É importante que você tenha uma partição separada, uma vez se você chroot para um diretório dentro de outra partição em vez de um dispositivo em si, o sistema ainda pode conter o dispositivo da partição pai, para este caso de uso devemos considerar que se destina não bloqueie nenhum.

Se você tiver espaço livre não alocado ou for capaz de reduzir algumas partições para ter espaço para o ambiente clonado, isso é recomendado. No entanto, se você não tiver espaço de armazenamento gratuito, poderá criar um ponto de montagem tmpfs da memória, se tiver memória suficiente. Uma partição de rede não é recomendada, uma vez que a conexão pode se perder durante o procedimento.

Mesmo que você não tenha espaço de armazenamento gratuito nem memória suficiente, ainda é possível criar uma imagem de disco com partição btrfs compactada dentro de um ponto de montagem tmpfs de memória que permitiria gravar mais dados do que você normalmente tem de memória. Nesse caso, tenha cuidado quando a partição se tornar somente de leitura, se acontecer, provavelmente ela morrerá de fome.

É importante notar que fazer o chroot dentro de uma partição de memória pode fazer com que esta memória seja bloqueada no ambiente antigo de tal forma que você não seja capaz de liberá-la sem o reboot ou kexec .

Depois de ter provisionado as partições necessárias para o ambiente clonado, veja como isso funcionará:

$ sudo mount /dev/clone_environment_device /mnt
# mount other separate partitions if required
$ sudo mkdir -p /mnt/mnt /mnt/dev /mnt/proc /mnt/sys /mnt/tmp /mnt/var/tmp /mnt/run
$ sudo chmod 1777 /mnt/tmp /mnt/var/tmp
$ sudo ln -s ../run /mnt/var/run
$ sudo rsync -aAHXSv \
    --exclude 'mnt' \
    --exclude 'dev' \
    --exclude 'run' \
    --exclude 'sys' \
    --exclude 'proc' \
    --exclude 'tmp' \
    --exclude 'var/tmp' \
    / \
    /mnt

É importante ajustar o caminho dos dispositivos e o uuid ( blkid ) para corresponder aos novos.

$ sudo vi /mnt/etc/fstab
$ sudo vi /mnt/etc/default/grub

Então, para executar o chroot:

$ sudo mkdir /sysroot
$ sudo mount --rbind /mnt /sysroot
$ sudo touch /etc/initrd-release
$ sudo systemctl --no-block isolate initrd-switch-root
# it will stop all other services (isolate) and call systemctl switch-root /sysroot

Note que não é necessário vincular proc e dev como você faz normalmente ao executar um chroot, o systemd fará isso por você. Você pode perder a conexão, se você esperar algum tempo e ainda não conseguir se conectar você tem minhas condolências, você foi desperdiçado.

No entanto, se você tiver sorte e conseguir se conectar, não esqueça de instalar o gerenciador de inicialização para o novo ambiente, a fim de recuperá-lo novamente no caso de um desligamento:

$ sudo grub2-install /dev/intended_bootable_disk
$ sudo grub2-mkconfig -o /etc/grub2.cfg

Claro, faça isso apenas se você não estiver no ponto de montagem da memória, se estiver, agora você deve apagar as outras partições e fazer tudo novamente com o armazenamento real.

Lembre-se, faça por sua conta e risco.