APRENDER. PRATICAR. EVOLUIR.Valida a versão antes de validar o transporte
Um transporte correto pode entregar o ficheiro errado para o período de negócio. relativeWrongSource arranca numa pasta stale que contém delivery.csv de uma versão anterior. O put usa um nome relativo e termina com zero, com hash remoto igual à origem selecionada. O erro acontece antes do transporte: o contrato esperava o ficheiro da pasta expected. explicitSource usa um caminho explícito a partir do mesmo diretório de arranque e envia a versão pretendida. Esta comparação mostra porque o teste no terminal do operador não basta para o scheduler. Regista caminho resolvido, período, identidade da entrega e hash esperado. Um caminho estável pode conter outro conteúdo; a confirmação precisa de ligar o artefacto selecionado ao ciclo de negócio.
Publica um estado que o consumidor compreende
No roundtrip, o upload escreve stage.part e deixa o ficheiro final anterior intacto. Outra sessão pede rename e descarrega o resultado; a comparação integral confirma os bytes observados. O teste cobre estados antes e depois, não leitores concorrentes, transações de negócio ou persistência perante falhas. renameDenied demonstra um estado intermédio importante: o staging está completo, mas o nome final não existe. O scheduler não deve converter essa falha em sucesso se o contrato usa o nome final como sinal de disponibilidade. Preserva identificador, hash e artefactos úteis enquanto reconcilias a recuperação. Não apagues o staging nem cries outro identificador de entrega por impulso; a segurança do reenvio depende do contrato com o consumidor.
Separa capacidades, pedidos e garantias
O cliente pode anunciar extensões suportadas pelo servidor, mas disponibilidade de uma extensão não prova autorização de uma operação. O controlo de rename aplica uma política que pode recusar publicação depois de um upload válido. flushRequest usa put -f e o diagnóstico regista Sending SSH2_FXP_EXTENDED(fsync@openssh.com). O ficheiro lido coincide com a origem e a transferência termina normalmente. Isso demonstra o pedido e o conteúdo observado, sem ensaio de perda de energia, recuperação de storage ou confirmação do consumidor. A opção de flush depende do suporte da extensão no upload. Documenta a capacidade concreta do endpoint e a evidência necessária para a promessa de durabilidade. Não transformes um resultado local sem falhas numa garantia universal de perda zero.
Prepara um exercício de decisão e passagem para RUN
O guião abaixo propõe quarenta minutos de prática: oito para identificar a entrega, doze para localizar a falha, doze para decidir recuperação e oito para preparar aceitação. Usa Ria para comparar ficheiros com o mesmo nome e versões diferentes; Farol para distinguir permissões do filesystem e read-only do subsistema; Duna para decidir sobre staging completo sem publicação. Um participante representa APS, outro o proprietário da integração e outro o gestor da mudança. A decisão final deve incluir responsável, operação permitida, prova esperada, prazo e condição de reversão. Estes casos são fictícios e não representam políticas BNP Paribas. O guião ainda não foi executado com participantes. O laboratório ensina mecanismos locais; a aceitação real exige contexto do job, endpoint e consumidor autorizados. O relatório deve preservar separadamente os critérios demonstrados e os critérios ainda dependentes de observação no ambiente autorizado.
GUIÃO DE 40 MINUTOS: SFTP E ACEITAÇÃO
Casos fictícios, sem políticas de um banco real.
Copiar run.py da aula anterior. Python 3, POSIX e conta local não-root utilizável.
Sete binários OpenSSH 10.5p1 correspondentes; build executado sem PAM.
Substituir /path/to por caminhos autorizados. Não usa o serviço SSH do sistema.
python3 run.py \
--ssh /path/to/openssh-10.5p1/ssh \
--sshd /path/to/openssh-10.5p1/sshd \
--sshd-session /path/to/openssh-10.5p1/sshd-session \
--sshd-auth /path/to/openssh-10.5p1/sshd-auth \
--keygen /path/to/openssh-10.5p1/ssh-keygen \
--sftp /path/to/openssh-10.5p1/sftp \
--sftp-server /path/to/openssh-10.5p1/sftp-server \
--output evidence.json
0–8: identificar versão, caminho resolvido, destinatário e identidade da entrega.
8–20: Ria envia versão antiga; Farol rejeita escrita; Duna conserva staging.
Para cada caso: fase, evidência, hipótese e confirmação em falta.
20–32: decidir recuperação, responsável, limite de acesso e risco de repetição.
32–40: definir operação de aceitação, resultado esperado e condição de reversão.
Entregar uma tabela com origem, transferência, publicação e consumo.
Distinguir pedido fsync de evidência de sobrevivência a falha de energia.
Não foram ensaiados parceiro externo, chroot, rede interrompida ou consumidor real.
Guia ainda não executado com participantes.
Ria prova que os bytes recebidos correspondem à origem, mas deteta que essa origem é do dia anterior. Corrige a seleção e reconcilia o consumidor antes de reenviar.
Armadilhas comuns
Tratar código zero como versão correta, usar hash sem referência esperada, confundir pedido fsync com ensaio de falha física ou publicar sucesso após rename recusado.
Tópicos relacionados: Gestão de incidentes e mudanças · Integrações e idempotência
Aceitação de entrega combina versão pretendida, integridade, publicação e contrato do consumidor. Cada conclusão deve corresponder à evidência que foi realmente recolhida.
Referência: OpenSSH SFTP client · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior