☰

mount e umount se comportam de maneira diferente quando executados no cron

tag-icon • tag-icon mount cron centos-6 fuse umount
mount e umount se comportam de maneira diferente quando executados no cron

Executando o CentOS 6 na AWS, e o que estou vendo está me deixando perplexo.

Há uma s3fsmontagem /etc/fstabque às vezes perde a capacidade de ler e escrever. Eu tenho um cron job que funcionou muito bem por meses, que simplesmente testava se a montagem estava boa a cada minuto e, se alguma vez perdesse a conexão, seria apenas umounto mountcompartilhamento. A montagem tendia a desaparecer com mais frequência sem carga do que sob carga real, então essa foi uma ótima solução.

Por alguma razão, isso parou de funcionar e agora as máquinas não conseguem ler/gravar no compartilhamento, pois a primeira coisa que as máquinas fazem na inicialização após o provisionamento é umounto mountcompartilhamento.

Agora, o erro que recebo ao tentar ler é este:

cp: cannot open `/app/canary.txt' for reading: Input/output error

No /var/log/messageseu vejo isso:

kernel: s3fs[3077]: segfault at e66000 ip 00007f833663d94e sp 00007ffc849c5b18
error 4 in libc-2.12.so[7f83365b4000+18a000]

Agora, quando executo exatamente o mesmo script no console que o root, ele simplesmente funciona perfeitamente. Desmontar e montar a unidade e deixá-la funcionando.

Meu primeiro palpite foi que algo no ambiente estava causando a diferença, então adicionei um source /root/.bash_profileao meu script, sem sucesso.

A linha em /etc/fstab é um monstro, mas descobrimos que funciona melhor depois de muitas tentativas de ajuste fino:

ourbucket /app fuse.s3fs _netdev,allow_other,endpoint=us-west-2,url=https://s3-us-west-2.amazonaws.com,use_path_request_style,use_sse,gid=1001,umask=0007,use_cache=/srv/s3fs,retries=20,parallel_count=30,connect_timeout=30,readwrite_timeout=60,stat_cache_expire=86400,max_stat_cache_size=100000 0 0

Esta é a aparência do arquivo cron:

* * * * * root /usr/bin/sudo /root/check_mount.sh

Tentei com e sem o sudo, pois achei que poderia afetar o meio ambiente.

Tentei muitas variações do script, mas a maioria desses comandos foi usada em um ponto ou outro. O mesmo problema surge independentemente do tipo de coisa que umounteu faço.

\cp /app/canary.txt /tmp/canary.txt
retVal=$?
sleep 1
if [ ${retVal} -ne 0 ]; then
    echo "Copy failed, trying to umount"
    umount /app
    echo "umount returned $?"
    sleep 1
    echo "Trying umount -f"
    umount -f /app
    echo "umount -f returned $?"
    sleep 1
    echo "Trying fusermount -u"
    /usr/local/bin/fusermount -u /app
    echo "fusermount returned $?"
    sleep 1
    echo "Trying to mount"
    mount /app
    echo "mount returned $?"
    sleep 1
    echo "Trying copy after mount"
    \cp /app/canary.txt /tmp/canary.txt
fi

Este script estava inicialmente em python, com as peças-chave sendo destinadas apenas a os.system, mas eu queria remover isso da equação. Estava dando os mesmos problemas.

Responder1

Aqui está minha solução completa:

Primeiro, auditei visualmente o audit.log. Para capturar as coisas certas e apenas as coisas certas, eu costumava audit2allowcriar uma política e digitar uma regra de aplicação.

grep mount /var/log/audit/audit.log | audit2allow -R -M mounts3fs

Eu grep para mount então só consigo as coisas certas.

Isso criou ummounts3fs.ppemounts3fs.tearquivo. Omounts3fs.tese parece com isso:

policy_module(mounts3fs, 1.0)

require {
    type file_t;
    type var_t;
    type mount_t;
    type cert_t;
    class dir { write remove_name add_name };
    class file { create unlink link setattr };
}

#============= mount_t ==============
#!!!! The source type 'mount_t' can write to a 'dir' of the following types:
# user_home_t, etc_runtime_t, var_run_t, mount_var_run_t, mount_tmp_t, user_home_dir_t, etc_t, nfs_t, tmpfs_t, tmp_t, var_t

allow mount_t cert_t:dir { write remove_name add_name };
allow mount_t cert_t:file { create unlink };
allow mount_t file_t:dir { remove_name add_name };
allow mount_t file_t:file { unlink link setattr };
allow mount_t var_t:file link;

Para instalar a política, executo isto:

semodule -i mounts3fs.pp

Descobri que isso não era suficiente para determinadas operações, então criei uma política adicional como esta:

module s3fs 1.0;

require {
    type file_t;
    type mount_t;
    class dir create;
    class file create;
}

#============= mount_t ==============

#!!!! This avc is allowed in the current policy
allow mount_t file_t:dir create;
allow mount_t file_t:file create;

selinuxainda pode ir direto para o inferno.

informação relacionada