EMBER_CLI_PROD_ASSETS para 1 falha na pré-compilação de assets

Vem de New installs will default to Ember CLI builds in Production - #36 by david

Olá Equipe,

Ao tentar definir EMBER_CLI_PROD_ASSETS como 1, estou recebendo o seguinte no momento da pré-compilação de assets (versão 2.9.0.beta2 commit: d2de058ff51f204fcf85c86a00750a59505af3bb):

yarn run v1.22.17
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build -prod
WARNING: Node v16.13.2 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js. See https://git.io/v7S5n for details.
DEPRECATION: The integration of jQuery into Ember has been deprecated and will be removed with Ember 4.0. You can either opt-out of using jQuery, or install the `@ember/jquery` addon to provide the jQuery integration. Please consult the deprecation guide for further details: https://emberjs.com/deprecations/v3.x#toc_jquery-apis
A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)

node:internal/errors:464
    ErrorCaptureStackTrace(err);
    ^

SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)
    at new SystemError (node:internal/errors:233:5)
    at new NodeError (node:internal/errors:336:7)
    at Object.userInfo (node:os:347:11)
    at summarizeProcess (/var/www/discourse/app/assets/javascripts/node_modules/console-ui/lib/summarize-process.js:17:15)
    at writeError (/var/www/discourse/app/assets/javascripts/node_modules/console-ui/lib/write-error.js:114:3)
    at UI.writeError (/var/www/discourse/app/assets/javascripts/node_modules/console-ui/lib/index.js:167:20)
    at CLI.logError (/var/www/discourse/app/assets/javascripts/node_modules/ember-cli/lib/cli/cli.js:318:13)
    at CLI.run (/var/www/discourse/app/assets/javascripts/node_modules/ember-cli/lib/cli/cli.js:253:12)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async module.exports (/var/www/discourse/app/assets/javascripts/node_modules/ember-cli/lib/cli/index.js:145:12) {
  code: 'ERR_SYSTEM_ERROR',
  info: {
    errno: -2,
    code: 'ENOENT',
    message: 'no such file or directory',
    syscall: 'uv_os_get_passwd'
  },
  errno: [Getter/Setter],
  syscall: [Getter/Setter]
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Alguma dica sobre por que isso está acontecendo?

Abraços,
Ismael

1 curtida

Essa é uma instalação de produção usando o guia de instalação?

Você pode tentar uma reconstrução?

1 curtida

Sem sucesso após a reconstrução da instância. Estou procurando mais o que está causando a chamada uv_os_get_passwd, ou mais geralmente sobre o que está causando esse erro, isso espera que algum usuário específico no sistema/configuração seja definido?

Abraços,
Ismael

Como exatamente você está executando a imagem do Discourse? Existem sinalizadores extras para segurança?

Seguindo este rastreamento, o problema é que a compilação do Ember-CLI está falhando e, ao tentar imprimir o erro, ele está lançando outra exceção e mascarando a real.

Você pode entrar na imagem do Discourse e tentar:

node
const os = require('os');
os.userInfo().shell

?

1 curtida

Interessante, é isso que estou recebendo ao executar sua sugestão (e faz todo o sentido se a intenção é acessar qualquer sistema de biblioteca interna com um usuário aleatório que não seja o root):

node
Bem-vindo ao Node.js v16.13.2.
Digite ".help" para mais informações.

> const os = require('os');
undefined

> os.userInfo().shell
Uncaught:
SystemError [ERR_SYSTEM_ERROR]: Ocorreu um erro de sistema: uv_os_get_passwd returned ENOENT (no such file or directory)
    at __node_internal_captureLargerStackTrace (node:internal/errors:464:5)
    at new SystemError (node:internal/errors:233:5)
    at new NodeError (node:internal/errors:336:7)
    at Object.userInfo (node:os:347:11) {
  code: 'ERR_SYSTEM_ERROR',
  info: {
    errno: -2,
    code: 'ENOENT',
    message: 'no such file or directory',
    syscall: 'uv_os_get_passwd'
  },
  errno: [Getter/Setter: -2],
  syscall: [Getter/Setter: 'uv_os_get_passwd']
}

>

Como exatamente você está executando a imagem do Discourse? Existem sinalizadores adicionais para segurança?

Temos usado uma solução conteinerizada baseada em OpenShift, na qual o Discourse está sendo executado com um ID de usuário aleatório. Nenhum problema até agora, abordagem muito semelhante ao guia de instalação oficial.
É certamente que podemos contornar esse problema definindo EMBER_CLI_PROD_ASSETS como 0, os ativos são pré-compilados como antigamente, mas mais cedo ou mais tarde, se seus planos são seguir nessa direção, isso pode representar um problema real para esse tipo de solução se o processo de pré-compilação atual for abandonado.

Então, algumas perguntas aqui:

  • Você tem uma ETA sobre o abandono (se for o caso) da pré-compilação de ativos da maneira antiga?
  • Existe alguma maneira de acessar a maquinaria os de outra forma, ou considerar uma abordagem diferente, para que as soluções conteinerizadas com IDs de usuário aleatórios ainda possam funcionar?

Muito obrigado por analisar isso, muito apreciado.

Abraços,
Ismael

1 curtida

Estamos removendo o EMBER_CLI_PROD_ASSETS nas próximas semanas.

Não estamos usando isso diretamente, mas sim uma dependência, de uma dependência, de uma dependência… Acho que é uma chamada estranha também, mas não é algo sobre o qual tenhamos muito controle.

1 curtida

Note que o erro que você está vendo não é o erro real.
É um erro que acontece ao tentar mostrar o erro real para você…

3 curtidas

É exatamente o mesmo problema que em Issue with non 'username' defined · Issue #2373 · nodejs/node-gyp · GitHub e os.userInfo throws if no username in docker container · Issue #25714 · nodejs/node · GitHub

Ao usar um ID de usuário aleatório, o node reclama no momento de carregar os métodos e propriedades do utilitário os relacionados ao sistema.

Apenas para confirmar, a forma antiga será totalmente descontinuada/removida, certo?

Abraços,
Ismael

1 curtida

Sim, entendi após a postagem acima. A menos que a equipe tome alguma ação/verificação especial para permitir isso, a era de usar IDs de usuário aleatórios acabou, na minha opinião.

Abraços,
Ismael

1 curtida

Sim, exatamente. Temos lançado gradualmente este novo pipeline de ativos ao longo dos anos, para que possamos acompanhar o que o projeto EmberJS recomenda e ser menos um “floco de neve”. Já estamos na fase final de implementação.

2 curtidas

Excelente, tudo claro.

Como sempre, muito obrigado pelas suas informações detalhadas, muito apreciado.

Abraços,
Ismael

1 curtida

Apenas para constar, e se for útil para alguém. Existe pelo menos uma maneira de fazer o ember cli funcionar como esperado com um uid aleatório, e isso é garantir que o uid aleatório atribuído tenha uma entrada em /etc/passwd no momento de executar a operação rake assets:precompile.

Algo como:

if [ `id -u` -ge 10000 ]; then
  cat /etc/passwd | sed -e "s/^discourse:/builder:/" > /tmp/passwd
  echo "discourse:x:`id -u`:`id -g`:,,,:/home/discourse:/bin/bash" >> /tmp/passwd
  cat /tmp/passwd > /etc/passwd
  rm /tmp/passwd
fi

Assim, o comando app/assets/javascripts/discourse run ember build -prod (de discourse/assets.rake at tests-passed · discourse/discourse · GitHub) funcionará.

yarn run v1.22.17
$ /discourse/app/assets/javascripts/node_modules/.bin/ember build -prod
WARNING: Node v16.13.2 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js. See https://git.io/v7S5n  for details.
DEPRECATION: The integration of jQuery into Ember has been deprecated and will be removed with Ember 4.0. You can either opt-out of using jQuery, or install the `@ember/jquery` addon to provide the jQuery integration. Please consult the deprecation guide for further details: https://emberjs.com/deprecations/v3.x#toc_jquery-apis 
- Building
Environment: production
- Building
- building... 
[WARN] (broccoli-terser-sourcemap) Minifying "assets/chunk.529.6ee9018498e97f872147.js" took: 24288ms (more than 20,000ms)
...

Também notei que essa operação é bastante custosa, consumindo quase 2GB de RAM apenas para pré-compilar :scream:

Abraços,
Ismael

2 curtidas

Estava usando mais de 4GB na semana passada, mas conseguimos fazer funcionar em servidores com 1GB de RAM/2GB de swap recentemente.

4 curtidas

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.