Eu preciso copiar dados programaticamente de um servidor FTP com rclone. A configuração é tão simples quanto:

[exampleftp]
type = ftp
host = ftp.example.com
user = myuser
pass = mypass

Se eu tentar copiar qualquer coisa, recebo:

Failed to create file system for "exampleftp:/": NewFs: failed to make FTP connection to "ftp.example.com:21": UTF8 support on

Despejar a troca de protocolo mostra:

$ rclone --config=rclone.conf ls exampleftp: -vv --dump bodies

DEBUG : Using config file from "rclone.conf"
DEBUG : rclone: Version "v1.55.1-DEV" starting with parameters ["rclone" "--config=rclone.conf" "ls" "exampleftp:" "-vv" "--dump" "bodies"]
DEBUG : Creating backend with remote "exampleftp:"
DEBUG : ftp://ftp.example.com:21: Connecting to FTP server
DEBUG : FTP Rx: "220 Welcome to the example FTP Server."
DEBUG : FTP Tx: "USER myuser"
DEBUG : FTP Rx: "331 User myuser, password please"
DEBUG : FTP Tx: PASS *****
DEBUG : FTP Rx: "230 Password Ok, User logged in"
DEBUG : FTP Tx: "FEAT"
DEBUG : FTP Rx: "211- Additional features supported include:"
DEBUG : FTP Rx: " MDTM"
DEBUG : FTP Rx: " MFCT"
DEBUG : FTP Rx: " MFMT"
DEBUG : FTP Rx: " SIZE"
DEBUG : FTP Rx: " REST STREAM"
DEBUG : FTP Rx: " AUTH TLS"
DEBUG : FTP Rx: " AUTH SSL"
DEBUG : FTP Rx: " PBSZ"
DEBUG : FTP Rx: " EPRT"
DEBUG : FTP Rx: " EPSV"
DEBUG : FTP Rx: " XCRC"
DEBUG : FTP Rx: " XSHA1"
DEBUG : FTP Rx: " XSHA256"
DEBUG : FTP Rx: " XSHA512"
DEBUG : FTP Rx: " XMD5"
DEBUG : FTP Rx: " HASH SHA-256;SHA-512;SHA-1*;MD5"
DEBUG : FTP Rx: " PROT"
DEBUG : FTP Rx: " LANG EN*"
DEBUG : FTP Rx: " SITE PSWD"
DEBUG : FTP Rx: " SITE ZONE"
DEBUG : FTP Rx: " SITE UTIME"
DEBUG : FTP Rx: " MODE Z ZLIB(LEVEL)"
DEBUG : FTP Rx: " MLST Type*;Size*;Modify*;Create*;"
DEBUG : FTP Rx: " CLNT"
DEBUG : FTP Rx: " CSID"
DEBUG : FTP Rx: " RMDA"
DEBUG : FTP Rx: " UTF8"
DEBUG : FTP Rx: "211 End"
DEBUG : FTP Tx: "TYPE I"
DEBUG : FTP Rx: "200 Type Binary"
DEBUG : FTP Tx: "OPTS UTF8 ON"
DEBUG : FTP Rx: "220 UTF8 support on"
DEBUG : FTP Tx: "QUIT"
Failed to create file system for "exampleftp:": NewFs: failed to make FTP connection to "ftp.example.com:21": UTF8 support on

Para mim, isso parece dizer:

• Servidor: "Eu apoio UTF8"
• Cliente: "Ótimo, então use UTF8"
• Servidor: "Claro, aqui está"
• Cliente: "Err, eu preciso ir. Tchau."

Tudo funciona bem com outro cliente, como lftp. No entanto, preferiria usar rclone, pois isso faria parte de uma estrutura pré-configurada para rclone.

Alguém sabe o que está acontecendo e alguma solução alternativa?

Eu tenho diretórios iniciais NFS (v4). O servidor NFS é um Synology (DSM 5.2), o cliente é um FC 23.

O cliente obtém as configurações autofs de um servidor freeIPA:

ipa automountmap-add default auto.home
ipa automountkey-add default --key "/home" --info auto.home auto.master
ipa automountkey-add default --key "*" --info "-fstype=nfs4,rw,sec=sys,hard,intr,rsize=8192,wsize=8192 nfsserver.hq.example.com:/volume1/shared_homes/&" auto.home

Ao investigar um problema com direitos de acesso a arquivos, verifiquei os rótulos do SElinux nos diretórios iniciais montados:

$ matchpathcon -V /home
/home has context system_u:object_r:autofs_t:s0, should be system_u:object_r:home_root_t:s0

e

$ matchpathcon -V /home/roberto
/home/roberto has context system_u:object_r:nfs_t:s0, should be unconfined_u:object_r:user_home_dir_t:s0

Admito que o SELinux ainda dá trabalho, estou pensando se os contextos acima devem ser corrigidos.

Pelo que entendi (por favor, corrija-me caso contrário), isso tem a ver com o suporte SELinux Labeled NFS , que permitiria dar rótulos como se os arquivos estivessem em um sistema de arquivos local, em vez de um nfs_trótulo genérico. Para que isso funcione, é necessário o NVS v4.2. Sendo meu servidor NFS no DSM, duvido que já suporte v4.2.

Minha pergunta é: meu cliente está simplesmente me dizendo "atualize seu servidor e faça esse novo recurso legal funcionar", caso em que não devo me preocupar muito ou isso é realmente algo para consertar? E se sim, como?

Tenho um servidor frontend.example.comcom IP público. É o Apache (2.4) que deve fazer proxy do tráfego vindo de service1.example.com(DNS alias to frontend.example.com).

service1.example.comé uma VM em uma LAN privada ( 192.168.56.0) entre as duas.

Agora, isso é fácil para HTTP:

<VirtualHost *:80>
        ServerName service1.example.com

        ProxyPass / http://192.168.56.2/
        ProxyPassReverse / http://192.168.56.2/

        <Location "/">
                Require all granted
        </Location>
</VirtualHost>

Estou tentando fazer o mesmo para HTTPS:

<VirtualHost *:443>
        ServerName service1.example.com

        SSLEngine On
        SSLProxyEngine On
        ProxyRequests Off
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerExpire off
        SSLInsecureRenegotiation on
        SSLProxyVerify none
        SSLVerifyClient none
        SSLCertificateFile /etc/ssl/certs/example_com.crt
        SSLCertificateKeyFile /etc/ssl/certs/example_com.key

        ProxyPass / https://192.168.56.2/
        ProxyPassReverse / https://192.168.56.2/

        <Location "/">
                Require all granted
        </Location>
</VirtualHost>

Tentar acessar service1.example.comvia HTTPS retorna: Erro durante o handshake SSL com o servidor remoto

Segurança não é minha preocupação aqui. service1 requer uma conexão HTTPS para alguns de seus serviços, é por isso que não estou simplesmente fazendo proxy de HTTPS para HTTP. Não quero frontend.example.comme envolver com SSL. O que eu gostaria é que falasse "ei, estou com conexão no 443, não estou lidando com isso, estou apenas encaminhando para esse IP interno, que vai cuidar disso". Eu só quero que ele passe o pedido adiante. Isso pode ser feito?

Como você pode ver na configuração do HTTPS acima, tentei relaxar a segurança o máximo possível (por exemplo SSLInsecureRenegotiation on, para diminuir as barreiras contra um ataque man-in-the-middle, não é?). Mas nada funcionou até agora.

Breve descrição do problema

Esta questão é sobre o mapeamento de id no NFSv4 dando errado.

Servidor NFS: um Synology DS, com DSM 5.2.

Cliente: Uma máquina FC22 normal, que monta automaticamente como /home uma das pastas exportadas acima.

Ambas as máquinas são clientes inscritos de um domínio freeIPA, portanto, usando o servidor freeIPA como servidor DNS e LDAP.

Quando um usuário LDAP efetua login no cliente, ele encontra a pasta montada. Então a montaria funciona. No entanto, as propriedades dos arquivos são mapeadas como nobody:nobody. Sei que esse "problema de ninguém" não é novo, mas nenhuma das soluções que encontrei até agora resolve o problema.

Login do usuário LDAP e toque no arquivo

$ ssh ldapuser1@client1
ldapuser1@client1's password: 

-bash-4.3$ id
uid=1172000004(ldapuser1) gid=1172000004(ldapuser1) groups=1172000004(ldapuser1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

ldapuser1pode logar corretamente e tem uid 1172000004.

-bash-4.3$ pwd
/home/ldapuser1

-bash-4.3$ ls -lan
total 8
drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 17:34 .
drwxr-xr-x. 3          0          0    0 18 aug 18:33 ..

O usuário LDAP aterrissa corretamente em seu diretório home, previamente criado e atribuído a ele. Mas qualquer novo arquivo recebe a propriedade errada:

-bash-4.3$ touch a

-bash-4.3$ ls -lan
total 8
drwxrwxrwx. 2 1172000004 1172000004 4096 18 aug 18:41 .
drwxr-xr-x. 3          0          0    0 18 aug 18:33 ..
-rwxrwxrwx. 1         99        100    0 18 aug 18:42 a

Observe que 99:100 está guest:usersno servidor. O arquivo idmapd.confno servidor diz para mapear nobody:nobodypara guest:users.

Configuração do servidor

$ exportfs -v   
/volume1/shared_homes xxx.xxx.0.0/24(rw,async,no_root_squash,no_subtree_check,insecure_locks,anonuid=1025,anongid=100,sec=krb5,rw,no_root_squash,no_all_squash)


$ klist -k /etc/nfs/krb5.keytab 
Keytab name: FILE:/etc/nfs/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   5 nfs/[email protected]
   5 nfs/[email protected]
   5 nfs/[email protected]
   5 nfs/[email protected]

$ cat /etc/idmapd.conf 
[General]
Domain=hq.example.com
Verbosity=10
[Mapping]
Nobody-User=guest
Nobody-Group=users
[Translation]
Method=nsswitch
GSS-Methods=static,synomap
[Static]

$ cat /etc/nsswitch.conf
passwd:     files ldap winbind
shadow:     files ldap winbind
group:      files ldap winbind
osts:      files dns wins
bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   files
publickey:  nisplus
automount:  files
aliases:    files

Configuração do cliente

$ automount -s
Mount point: /home
source(s):
  instance type(s): sss 
  map: auto.home
  * | -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 nfs-server.hq.example.com:/volume1/shared_homes/&

$ df
nfs-server.hq.example.com:/volume1/shared_homes/ldapuser1 11609721368 2208608120 9400994464  20% /home/ldapuser1

$ cat /etc/idmapd.conf
[General]
Domain=hq.example.com


$ cat /etc/nsswitch.conf
passwd:     files sss
shadow:     files sss
group:      files sss
hosts:      files dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files sss
aliases:    files nisplus
sudoers: files sss

$ cat /etc/sysconfig/nfs | egrep -v "^#"
RPCNFSDARGS=""
RPCMOUNTDOPTS=""
STATDARG=""
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
RPCGSSDARGS="-vvv"
GSS_USE_PROXY="yes"
RPCSVCGSSDARGS="-vvv"
BLKMAPDARGS=""
SECURE_NFS=yes

Servidor de LOGS

Aug 18 18:50:59 nfs-server idmapd[14622]: nfsdcb: authbuf=gss/krb5 authtype=user
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_uid_to_name: final return value is 0
Aug 18 18:50:59 nfs-server idmapd[14622]: Server : (user) id "1173000004" -> name "[email protected]"
Aug 18 18:50:59 nfs-server idmapd[14622]: nfsdcb: authbuf=gss/krb5 authtype=group
Aug 18 18:50:59 nfs-server idmapd[14622]: nfs4_gid_to_name: calling nsswitch->gid_to_name
Aug 18 18:51:00 nfs-server idmapd[14622]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
Aug 18 18:51:00 nfs-server idmapd[14622]: nfs4_gid_to_name: final return value is 0
Aug 18 18:51:00 nfs-server idmapd[14622]: Server : (group) id "1173000004" -> name "[email protected]"

Observe que os mapeamentos parecem ser solicitados para o usuário/domínio correto. No log, no entanto, também encontrei muitas referências a mapeamentos de [email protected]e [email protected].

Cliente LOGS

aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: key: 0x274d13a5 type: uid value: [email protected] timeout 600
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: calling nsswitch->name_to_uid
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nss_getpwnam: name '[email protected]' domain 'hq.example.com': resulting localname 'ldapuser1'
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2118]: nfs4_name_to_uid: final return value is 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: key: 0x3e28949 type: gid value: [email protected] timeout 600
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: calling nsswitch->name_to_gid
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
aug 18 18:50:59 client1.hq.example.com nfsidmap[2120]: nfs4_name_to_gid: final return value is 0

Observações e perguntas

• A causa mais comum de mapeamento incorreto nesses casos parece ser a Domainconfiguração ausente ou não consistente em idmapd.confambos os lados. Aqui está corretamente definido em ambos os lados
• Funciona se eu usar mapeamentos estáticos, ou seja, 1) criar local ldapuser1no servidor 2) adicionar uma entrada em [Static] em idmapd.conf, que diz [email protected]=ldapuser1. No entanto, este não é o objetivo.
• O servidor Synology obviamente não é Fedora/RedHat, então não é o companheiro freeIPA perfeito. Em particular, sente falta SSSD. Ainda assim, acho que deve funcionar.

Estou completamente preso neste ponto. Não sei nem onde pedir ajuda. O suporte da Synology afirma que isso deve funcionar. De acordo com os desenvolvedores do freeIPA, isso está fora do tópico, porque não é específico do freeIPA, mas "apenas" problemas de NFS & co. Isso é discutível, pois a maneira como todas essas tecnologias são conectadas e usadas é específica do freeIPA.

De qualquer forma, não sei mais o que olhar. É por isso que pergunto aqui esperando que alguém possa me fazer dar pelo menos mais um passo à frente. Qualquer palpite é mais do que bem-vindo!

O que estou tentando fazer

Tenho um domínio freeIPA, com alguns clientes e um Synology NAS (também inscrito no freeIPA).

Criei uma pasta compartilhada no NAS, com suporte a NFSv4 + krb5. Do cliente, obtenho um ticket para usuário LDAP [email protected]e monto esta pasta.

Inicialmente, os arquivos criados nesta pasta seriam de propriedade do nobodyusuário.

Finalmente consegui fazer funcionar, alterando /etc/idmapd.confo NAS para

• ter o domínio definido corretamente
• ter um mapeamento estático entre [email protected]e um usuário local

Pergunta

Eu entendo o papel do idmapdfore NFS em geral.

Neste caso porém:

• por que preciso de mapeamentos explícitos? Não pode descobrir por si mesmo?
• por que preciso de um mapeamento? O NAS também está no mesmo domínio freeIPA, é um cliente LDAP e possui os princípios kerberos corretos [email protected]. do utilizador? Posso evitar a criação de usuários locais?

Minha corrente idmapd.confestá assim:

[General]
Domain=hq.example.com

[Mapping]
Nobody-User=guest
Nobody-Group=users

[Translation]
Method=nsswitch
GSS-Methods=static,synomap

[Static]
[email protected]=user1

O que eu gostaria de conseguir é não precisar desse mapeamento estático [email protected]=user1e, se possível, nem precisar criar um usuário local user1no NAS.

Estou ciente de que questões sobre migração para LDAP não são novidade. Pesquisei bastante informações agora, mas o problema que encontrei é que as informações parecem bastante fragmentadas sobre o assunto. Portanto, espero que alguém experiente possa me indicar a direção certa.

A situação atual:

• Pequena empresa, crescendo em usuários e desktops
• Cerca de 10 desktops Fedora-20 / 3 servidores Fedora-20
• 1 Synology NAS DS1813+
• Cerca de 10 usuários
• Todos os logins são locais nos desktops
• Os usuários NÃO têm os mesmos UIDs e GIDs na rede de máquinas.

Obviamente, torna-se cada vez mais atraente usar um diretório de usuário centralizado, como o LDAP.

O problema :

Infelizmente, não consegui encontrar guias confiáveis ​​e completos que cobrem todo o processo para um cenário da vida real.

• Configurando o servidor e configurando os clientes: OK, pelo que li, não é o processo mais simplificado, mas mesmo que seja um pouco complicado, acredito que seja possível.
• Migrar todos os usuários, de todas as máquinas: eis a parte "delicada". Obviamente, não quero arriscar nenhuma perda de informação. Novamente, encontrei alguns guias sobre migração e sobre o MigrationTools , mas nenhuma dessas fontes me dá a sensação de um guia confiável. Cenário típico: há uma página wiki ou algo assim com instruções e uma pilha enorme de comentários reclamando que o procedimento falhou em algum momento. As questões levantadas são muitas vezes muito mais do que as respostas dadas. Como isso pode me fazer sentir que posso iniciar esse processo com segurança?

Algumas perguntas específicas:

• Existe um conjunto atualizado de melhores práticas/ferramentas recomendadas que certamente devem ser consideradas para esse processo de migração? Em particular com atenção aos cenários da vida real? Qual sequência de ações seguir, no que prestar atenção, como minimizar os riscos de perda de dados, como minimizar o tempo de inatividade dos usuários etc.?
• Suponha que o usuário 'roberto' esteja presente (com IDs diferentes) em duas máquinas. Ao migrar as informações de /etc/passwd de ambas as máquinas para o LDAP, elas são "mescladas" durante o processo? Se não, o que deve ser feito?
• A migração pode ser feita em etapas, apenas para um usuário começar? É aconselhável?
• Outra abordagem (talvez ingênua?) Em que pude pensar é: crie novos usuários LDAP, altere a propriedade de todos os arquivos dos usuários locais antigos para esses novos usuários e remova os usuários locais antigos. Isso faz sentido? Alguma experiência anterior?
• Como o LDAP se relaciona com o ACL? Eles vão bem juntos?
• A próxima etapa desejada é centralizar os diretórios pessoais dos usuários em um espaço compartilhado no NFS. Qualquer indicação para esta próxima etapa também seria bem-vinda, especialmente se vinculada à migração para o LDAP.