rsync ignora --chown / - usermap

Question

Estou correndo ansible com o módulo synchronize , que executa o rsync. Meu problema não é ansible-related, como tomei o comando rsync da saída de depuração e executou-o manualmente - ainda o mesmo problema.

O comando que eu executei é:

/usr/bin/rsync --delay-updates -F --rsync-path="sudo rsync" --compress --delete-after --archive "/local/path" "[email protected]:/remote/path" --chown=myuser:myuser

Qualquer coisa que eu tente - acabo com o diretório pertencente a root:root .

Portanto, agora o rsync é executado com êxito como root, por isso deve ter todas as permissões necessárias. Eu também tentei usar --usermap=*:myuser --groupmap=*:myuser - nada.

Eu adicionei --chmod=750 - não sendo aplicado.

Na saída de depuração ( -vvvv ), posso ver meus parâmetros novamente, mas é isso.

Nenhum aviso, nenhum erro, mas também nenhuma menção posterior de qualquer coisa que contenha "user", "group", "chown" etc ... rsync é 3.1.1 no Debian 8.

Qualquer ajuda seria apreciada ...

    

Answer 1

sudo não foi o infrator ... foi parcialmente eu, e talvez seja também um bug / recurso funcionando de forma diferente do esperado.

Minha tarefa ansiosa adicionou o nome da pasta de origem ao caminho de destino, o que resultou na criação do caminho e na criação da pasta de origem dentro dessa pasta, duplicando efetivamente a estrutura de pastas para /destination/path/source/source/...

--chmod está sendo aplicado à segunda pasta source , mas não àquela criada como parte da estrutura de destino. Portanto, o top source pertence ao root, mas o segundo source pertence ao usuário e também deve pertencer.

Corrigida minha tarefa ansible para usar o caminho correto e, portanto, também esse problema.

Será que alguém deve esperar que rsync também chown / chmod pastas sejam criadas como parte do caminho de destino?

    

Answer 2

A chamada do sistema chown (e, por extensão, os comandos chown e rsync --chown ) só pode ser usada por root . Você está se conectando ao sistema remoto como o usuário ansible , portanto, o sistema remoto não permitirá a operação. O comando rsync reconhece que ele não está sendo executado como root no sistema remoto, portanto, ele silenciosamente ignora a opção --chown e outros como ele (por exemplo, --mapuser ).

O manual do rsync não é realmente explícito sobre esse comportamento, mas se você especificar o --super opção também, fará com que rsync no sistema remoto assuma que está sendo executado como root , mesmo que não seja. Isso permitirá que ele tente a operação chown e produza um erro se ou quando falhar.

EDITAR:

Se você conseguir executar rsync no sistema remoto como root (por exemplo, usando --rsync-path="sudo rsync" ), ainda precisará adicionar algumas opções para que --chown possa ser usado. O manual indica:

--chown=USER:GROUP
    This option forces all files to be owned by USER with group GROUP.
    This is a simpler interface than using --usermap and --groupmap
    directly, but it is implemented using those options internally, so
    you cannot mix them.

E aqui está o que o manual diz para --usermap e --groupmap :

--usermap=STRING, --groupmap=STRING
    ...
    For the --usermap option to have any effect, the -o (--owner)
    option must be used (or implied), and the receiver will need to
    be running as a super-user (see also the --fake-super option).
    For the --groupmap option to have any effect, the -g (--groups)
    option must be used (or implied), and the receiver will need to
    have permissions to set that group. 

Além de usar --rsync-path para executá-lo em sudo , tente adicionar as opções -o e -g também.