O resultado do processo não descreve todo o workflow
O laboratório compara duas sequências que tentam obter um ficheiro inexistente antes de enviar outro. Sem prefixo, o get falha, o cliente sai com um e o upload seguinte não cria ficheiro. Com -get, o erro é ignorado para continuidade, o put seguinte executa e o processo termina com zero. O requisito fictício declara a leitura obrigatória, por isso o segundo workflow continua inválido. Regista resultados por etapa e faz o estado do scheduler representar as dependências reais, em vez de depender apenas do último comando concluído.
Reconhecer uma falha de publicação
O servidor de outro teste é iniciado com uma política que recusa rename e posix-rename. O put cria policy.part e o seu hash coincide com a origem. A publicação falha, o processo termina com um e policy.bin não aparece. O resultado não exige assumir corrupção ou voltar a enviar todos os bytes. Existe staging completo que precisa de reconciliação e uma operação recusada a investigar. Mantém a fronteira do consumidor: fazê-lo ler qualquer parcial para contornar a falha pode expor outras transferências ainda incompletas.
Distinguir política do subsistema e permissões
Num diretório que o processo local pode escrever, sftp-server -R permite get e recusa put. A comparação mantém o filesystem e mostra uma restrição adicional do subsistema. Alterar permissões indiscriminadamente não resolve essa política. Confirma também qual executável interpreta cada argumento: -R no servidor significa leitura apenas, enquanto -R no cliente configura o número de pedidos pendentes e recebe um valor numérico. Num ticket, guarda a invocação completa com os argumentos associados ao componente correto. Uma letra isolada não identifica o controlo que causou o erro.
A máscara não é sempre o último controlo
A origem do ensaio tem modo 0644 e o servidor usa umask 0077. Um put normal deixa o novo ficheiro em 0600. Com put -p, a preservação de atributos termina com 0644. A criação e a alteração posterior são momentos distintos. Se o contrato exige leitura apenas pela conta de serviço, verifica o estado final e revê preservação, modo da origem e política autorizada do destino. O ensaio usa ficheiros do próprio utilizador: não demonstra ACL, propriedade entre contas, isolamento de parceiros ou requisitos de chroot.
Delimitar versões e reprodução
Os comandos executados são /usr/bin/sftp e /usr/libexec/sftp-server, identificados por hashes na evidência. ssh -V da mesma máquina indica OpenSSH 10.3p1; os dois executáveis SFTP não forneceram uma versão de produto separada. As notas oficiais consultadas apresentam 10.5p1, que não foi executado nesta revisão. O protocolo local anuncia versão três e extensões observadas nos logs. O runner usa apenas ficheiros sintéticos temporários e remove-os no fim. A ligação direta não valida chaves, credenciais, encriptação ou características de uma rede internacional.
Entregar um estado recuperável a RUN
Substitui o rótulo vago “SFTP OK” por etapas e evidência: leitura do manifesto, transferência, validação, publicação e aceitação conforme o contrato. Regista nomes, versão, identificador, resultado, parcial restante e procedimento de recuperação. Se uma operação obrigatória falhou, impede o avanço dependente e comunica o prazo em risco. Para autorizar a mudança, testa o cliente real do scheduler e os controlos do destino. O resumo é que uma transferência tecnicamente concluída pode coexistir com publicação negada, permissões inadequadas ou falta de validação funcional.
# From the project root; macOS bundled client/server paths are explicit
python3 content/labs/sftp-delivery/run.py
# -D executes the local SFTP subsystem directly, without SSH
# criticalAbort / ignoredError: inspect stage outcome and side effects
# renameDenied: complete partial remains; final name absent
# preservedPermissions: put 0600; put -p 0644 with server umask 0077Caso fictício: o manifesto obrigatório falha com -get, mas o upload posterior torna o processo verde. RUN corrige a condição de avanço e trata a entrega como pendente.
Armadilhas comuns
Usar saída zero como cumprimento de todos os pré-requisitos, reenviar bytes para corrigir rename negado, ou assumir que umask impõe o modo final após put -p.
Tópicos relacionados: Batch e falhas observáveis · Publicação e retoma de ficheiros · Diagnóstico e passagem para RUN
A recuperação deve partir da etapa que falhou e do estado realmente existente, preservando publicação controlada, permissões e referências da entrega.
Referência: OpenSSH SFTP subsystem · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior