Aws-cli: Windows AWSCLI64PY3 MSI não envia aws.exe mais quebra scripts

@DanielLaberge - Obrigado por

aws-cli / 1.16.37 Python / 3.6.0 Windows / 10 botocore / 1.12.27

Instalado a partir deste pacote: AWSCLI64PY3.msi com link desta página

Observei que o nome do pacote mudou, costumava ser 'AWSCLI64.msi' até muito recentemente.

tivemos o mesmo problema também. Existe alguma razão para o exe ser removido?

Estamos executando aws-cli/1.16.40 Python/3.6.0 Windows/10 botocore/1.12.30 e nossos scripts de construção do Cake não são mais executados como resultado dessa mudança.

Implantar as ferramentas CLI deste link resolveu nosso problema no momento:
https://s3.amazonaws.com/aws-cli/AWSCLI64.msi

Curiosamente, --version dá:
aws-cli/1.16.40 Python/2.7.15 Windows/10 botocore/1.12.30

Isso também é o que fiz para contornar o problema, algumas das páginas de documentação da AWS ainda estão vinculadas ao pacote AWSCLI64.msi, que inclui aws.exe.

Obrigado bazwilliams, eu deveria ter mencionado essa solução alternativa no OP, meu mal.

@DanielLaberge , @angelaman e @bazwilliams - Obrigado por seus comentários. Estou curioso se você já conhece esta página ? Ele tem um link para um download dos arquivos de configuração do AWS CLI que incluem os instaladores MSI de 32 e 64 bits e instalará automaticamente a versão correta. Os links de download para https://s3.amazonaws.com/aws-cli/AWSCLISetup.exe.

Tentei a instalação automatizada que você sugeriu, mas ainda instala uma versão das ferramentas cli sem o binário aws.exe .

Este problema foi encerrado automaticamente porque não houve resposta ao nosso pedido de mais informações do autor original. Com apenas as informações que estão atualmente no problema, não temos informações suficientes para tomar medidas. Entre em contato se tiver ou encontre as respostas de que precisamos para que possamos investigar mais a fundo.

@justnance Como @bazwilliams respondeu, sua solução não parece funcionar. Não sei por que este tíquete está fechando. Você poderia reabri-lo novamente?

Acho que precisamos que @DanielLaberge responda para que o bot abra novamente.

Outra pessoa pode assumir a responsabilidade por este problema para que eu não tenha que responder a cada dois dias?

A natureza do problema não requer este bot ...

após realizar essa atualização, nossos scripts param de ser executados após a primeira chamada para aws. como aws agora é um arquivo .cmd, ele requer o prefixo "call" ao ser chamado de arquivos em lote ou cmd, sem ele o script de chamada para de executar.

isso também interromperá os aplicativos do Windows usando o processo de inicialização sem a execução do shell para enviar para o aws.exe - quaisquer que sejam os benefícios de eliminar o aws.exe, considere-os contra a introdução dessa alteração significativa nos ambientes do Windows. meu voto seria para restaurar aws.exe

Todos - confirmamos que é um bug. O comportamento é esperado, mas não intencional. A solução neste momento é usar a CLI com Python / 2.7.15 em vez de Python / 3.6.0.

Para ser claro, a versão CLI MSI com o problema é a nossa mais nova versão MSI construída em relação ao python 3.6 . Ainda publicamos as versões mais antigas do

A solução neste momento é usar a CLI com Python / 2.7.15 em vez de Python / 3.6.0.

Essa solução alternativa não é válida, pois a versão 2.x apresenta outros defeitos .

Eu recomendo soltar os nomes de arquivo aws na pasta bin com o seguinte conteúdo:

#!/usr/bin/env bash

self=`readlink -f "$0"`
basedir=`dirname "$self"`

"$basedir/../runtime/python.exe" -m awscli "$@"

Eu entendi e parece estar funcionando bem

$vi .bashrc

adicione o abaixo
alias aws = 'aws.cmd'

Trabalho foi feito para resolver este problema. Instale a versão mais recente do CLI e nos informe se está funcionando conforme o esperado agora. Obrigado pela sua paciência.

Isso é bastante inespecífico. Também este:

Interessante. Qual versão do Windows e qual instalador você está usando?

@JordonPhillips Windows 10 17763.134. Para o MSI, tenho apenas um número de revisão {94E88177-499F-4DF5-8D96-25FDD46EA1C6} , criado em 12/02/2019 às 01:00

Parece que no final da instalação, um aplicativo externo é iniciado (vejo rapidamente uma janela de console aberta) e, em seguida, recebo a mensagem acima. Posso criar um novo tíquete se isso ajudar.

Para fazer o exe funcionar, contamos com um arquivo que precisa de um caminho absoluto para o python empacotado, já que os caminhos relativos são interpretados como relativos ao diretório de trabalho atual. (O CMD tem uma solução alternativa sintática, que é usada em aws.cmd , mas não está disponível aqui.) Portanto, o que está acontecendo no final da instalação é que estamos executando comandos shell para atualizar esse caminho.

Isso é o que estamos fazendo:

cmd.exe /c echo "[AWSCLI64PY3_RUNTIME]python.exe" > .\bin\tmp.txt
cmd.exe /c type .\bin\aws-script.py >> .\bin\tmp.txt
cmd.exe /c move /y .\bin\tmp.txt .\bin\aws-script.py

Com o bit [AWSCLI64PY3_RUNTIME] sendo um modelo que apenas retorna o caminho absoluto para a pasta runtime . Eu sei que parece um pouco hacky, mas na verdade é o que o setuptools faz e mais ou menos o que o pip faz (no entanto, o pip anexa o script ao final do exe).

Executamos testes nesses MSIs como parte do lançamento, então estou um pouco surpreso que haja uma falha no momento da instalação. Eu me pergunto se há alguma diferença material entre o Windows Server e o Windows que esteja causando o problema. Meu outro palpite é que é algum tipo de problema de permissão que faz com que um desses comandos falhe.

Recebi exatamente o mesmo erro acima ao instalar o pacote no Windows. Algo deve ter mudado esta semana porque na semana passada estava funcionando muito bem. Eu contornei o erro não usando o pacote .msi e, em vez disso, baixando a versão .exe. Quando executei a versão .exe, vi a instalação de algumas dependências dotnet e estou supondo que essas mesmas dependências podem estar faltando no instalador MSI.

Pode ser um problema de atualização com as alterações do exe. Tente desinstalar / reinstalar se você vir isso.

@JordonPhillips Na verdade, vi .\bin\aws-script.py durante a instalação. Eu tinha investigado um pouco, porque presumi que meu próprio aws.sh no diretório bin estava causando um conflito. Eu o removi e também tentei mais algumas coisas para tentar fazer a instalação passar, mas sem sucesso.

Portanto, o arquivo foi realmente criado no diretório de destino. Não tenho certeza do que poderia ter dado errado depois disso.

O arquivo existe como parte da instalação normal - nós apenas acrescentamos o caminho para ele. Se você quebrá-lo, deverá ter um caminho absoluto para o interpretador python no início. Se os comandos falharem, ele não estará lá.

No momento em que recebo a mensagem de erro, o conteúdo de .\bin\aws-script.py é:

# -*- coding: utf-8 -*-
import sys
from awscli.clidriver import main
if __name__ == '__main__':
    sys.argv[0] = 'aws'
    sys.exit(main())

Vou investigar um pouco mais ...

Sim, conseguimos alguns logs de outro usuário e parece que está falhando na primeira linha do script que colei acima. Estou mais inclinado para uma questão de permissão. É sua conta de usuário e conta de administrador?

Eu sou um administrador

O que acontece se você executar cmd.exe /c echo "foo" > .\bin\tmp.txt no diretório de instalação?

Esquisito. Quando estou verificando a guia Segurança da pasta bin , recebo a seguinte mensagem:

---------------------------
Windows Security
---------------------------
The permissions on bin are incorrectly ordered, which may cause some entries to be ineffective.
---------------------------
OK   
---------------------------

Quando executo o comando que você sugeriu, a partir de um PowerShell elevado, ele funciona bem. Ainda está no estado em que vejo a mensagem de erro durante a instalação.

De uma instância não elevada do PowerShell, ele falha com um UnauthorizedAccessException . Mas acho que isso era esperado.

Eu me pergunto se o problema é chamar cmd /c para executar o comando? Talvez isso não mantenha o administrador.

Acho que o próprio processo cmd.exe não é gerado de forma elevada:

O msiexec.exe também não é.

Mas isso não pedir elevação durante a instalação para fazer alterações para o Program Files pasta. Eu esperaria que o processo cmd.exe não fosse criado com os mesmos privilégios.

Sim, parece que é onde ele muda do contexto do usuário do Sistema Local para o meu próprio. Espero que ajude.

Remover e reinstalar realmente funciona? Parece que isso também seria um problema em novas instalações. Eu não quero ficar sem um CLI

Acho que não, mas você pode usar o python 2 msis ou versões anteriores do python 3 msis.

Python 2: https://s3.amazonaws.com/aws-cli/AWSCLI64.msi
Python 3 mais antigo: https://s3.amazonaws.com/aws-cli/AWSCLI64PY3-1.16.101.msi

Ainda estamos trabalhando em uma correção, mas enquanto isso, parece que se você executar cmd / powershell como administrador e depois executar msiexec a partir daí, funcionará.

Temos uma correção em vigor, que será lançada no próximo lançamento. Essas coisas tendem a acontecer diariamente, então provavelmente será amanhã.

O problema era que, por padrão, o wix (o conjunto de ferramentas usado para construir instaladores msi) executará comandos cmd usando os privilégios de usuário do usuário que executou o instalador, em vez da função de administrador que é assumida para executar o resto da instalação. Então, nós apenas tivemos que dizer a ele para usar as mesmas permissões do resto da instalação.

Impressionante. Parece bom :)

A versão que está disponível para download no momento, ainda não continha a correção, aparentemente. Vou verificar novamente mais tarde para uma revisão mais recente.

@oliversalzburg Um lançamento acabou de sair com a correção.

Também para dar algum contexto sobre o problema original (a falta de um exe), uma vez que não parece estar aqui:

Para o python 2 msis, usamos uma ferramenta chamada py2exe para gerar executáveis. Basicamente, o que isso faz é compilar (quase) tudo até o código de bytes do Python e, em seguida, agrupar o suficiente para fazer um exe funcionar. Funciona mais ou menos, mas o projeto não vê atualizações há muito tempo e não funciona com o Python 3.

Para Python 3.6+, o PSF vende uma versão zip autocontida do python para ser agrupada em aplicativos. Então, quando começamos o trabalho de mudar os instaladores para o python 3, decidimos usar isso, pois é muito mais simples, pois não precisamos depender de uma dependência de terceiros.

O efeito colateral de fazer isso foi que não tínhamos mais um exe para apontar porque a CLI não usa entry_points . Mesmo se usássemos entry_points em geral, ainda não teríamos um exe funcionando porque o exe gerado pelo pip tem um caminho absoluto para o executável python incorporado. Instalamos todos os pacotes no python agrupado no momento da compilação , de modo que seja qualquer que seja o caminho em nossa caixa de construção. A menos que você tivesse exatamente a mesma configuração, incluindo nome de usuário, não funcionaria.

Então, o que fizemos foi colocar um script cmd em uma pasta que usa um caminho relativo ao arquivo para chamar o cli com o python empacotado. Presumimos que isso seria bom, pois geralmente o Windows irá procurar por itens no caminho sem olhar para a extensão, se você não a forneceu enquanto trabalhava no terminal. Obviamente, essa não era uma suposição correta a se fazer.

Então, para corrigir isso, vimos o que as ferramentas de configuração e o pip fazem por entry_points . Basicamente, eles criaram exe's que chamarão a atenção de um script python especial. O topo do script é um shebang com um caminho absoluto para o python a ser usado. O problema é que o shebang nesse arquivo não é capaz de tirar proveito da sintaxe do script cmd que permite especificar um caminho relativo ao arquivo no disco.

Como não sabemos em qual caminho estaremos instalando até o momento da instalação, precisamos definir isso durante a instalação. Uma vez que só rodamos as instalações reais do pip quando o msi é compilado, não quando é executado (porque para um msi funcionar bem, ele precisa saber todos os arquivos que serão criados), tivemos que acrescentar o shebang ao arquivo especial tempo de instalação. Então, fazemos isso e incluímos a versão setuptools do exe wrapper (a versão pip depende do arquivo sendo compactado e anexado ao exe, que não nos sentimos confortáveis ​​em modificar).

É aqui que encontramos os problemas de permissão. Os arquivos instalados com MSIs concedem permissões de leitura / execução apenas a não administradores. Nossos comandos para preceder o shebang não tinham essas permissões (consulte o comentário anterior), então eles falharam. Não detectamos isso em nossos testes automatizados porque o usuário é apenas um administrador, portanto, não foi possível instalar nenhum problema.

Posso confirmar que o problema do instalador foi resolvido agora. E o problema original também foi corrigido :)

Este problema foi encerrado automaticamente porque não houve resposta ao nosso pedido de mais informações do autor original. Com apenas as informações que estão atualmente no problema, não temos informações suficientes para tomar medidas. Entre em contato se tiver ou encontre as respostas de que precisamos para que possamos investigar mais a fundo.