EMBER_CLI_PROD_ASSETS a 1 causa il crash della precompilazione degli asset

Viene da New installs will default to Ember CLI builds in Production - #36 by david

Ciao Team,

Provando a impostare EMBER_CLI_PROD_ASSETS su 1, ottengo quanto segue al momento della precompilazione degli asset (versione 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.

Qualche suggerimento sul perché sta succedendo?

Saluti,
Ismael

1 Mi Piace

È un’installazione di produzione che utilizza la guida all’installazione?

Puoi provare una ricompilazione?

1 Mi Piace

Nessun successo dopo la ricostruzione dell’istanza. Sto cercando di capire cosa causa la chiamata uv_os_get_passwd, o più in generale cosa causa questo errore, si aspetta che venga impostato un utente specifico nel sistema/impostazione?

Saluti,
Ismael

Come stai eseguendo esattamente l’immagine Discourse? Ci sono flag aggiuntivi per la sicurezza?

Seguendo questa traccia, il problema è che la build di Ember-CLI sta fallendo e, mentre si tenta di stampare l’errore, viene generata un’altra eccezione che maschera quella reale.

Puoi entrare nell’immagine Discourse e provare:

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

?

1 Mi Piace

Interessante, questo è quello che ottengo quando eseguo il tuo suggerimento (e ha perfettamente senso se l’intenzione è accedere a qualsiasi sistema di libreria interna con un utente casuale diverso da root):

node
Welcome to Node.js v16.13.2.
Type ".help" for more information.

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

> os.userInfo().shell
Uncaught:
SystemError [ERR_SYSTEM_ERROR]: A system error occurred: 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']
}

>

Come stai eseguendo esattamente l’immagine Discourse? Ci sono flag aggiuntivi per la sicurezza?

Abbiamo utilizzato una soluzione containerizzata basata su OpenShift, in cui Discourse viene eseguito con un ID utente casuale. Nessun problema finora, approccio molto simile alla guida di installazione ufficiale.
È certamente possibile aggirare questo problema impostando EMBER_CLI_PROD_ASSETS su 0, gli asset vengono precompilati come ai vecchi tempi, ma prima o poi, se i tuoi piani sono di muoverti in questa direzione, potrebbe rappresentare un vero problema per questo tipo di soluzioni se l’attuale processo di precompilazione viene abbandonato.

Quindi un paio di domande qui:

  • Avete una stima di quando abbandonerete (se è il caso) la precompilazione degli asset nel vecchio modo?
  • C’è un modo per accedere alla macchina os in un modo diverso, o considerare un approccio diverso, in modo che le soluzioni containerizzate con ID utente casuali possano ancora funzionare?

Molte grazie per aver esaminato questo problema, molto apprezzato.

Saluti,
Ismael

1 Mi Piace

Rimuoveremo EMBER_CLI_PROD_ASSETS nelle prossime settimane.

Non lo stiamo utilizzando direttamente, ma una dipendenza, di una dipendenza, di una dipendenza… Penso che sia una chiamata strana anche per noi, ma non è qualcosa su cui abbiamo molto controllo.

1 Mi Piace

Nota che l’errore che stai vedendo non è l’errore effettivo.
È un errore che si verifica quando si tenta di mostrarti il vero errore…

3 Mi Piace

È esattamente lo stesso problema di 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

Utilizzando un ID utente casuale, node si lamenta al momento del caricamento dei metodi e delle proprietà di utilità relativi al sistema os.

Solo per confermare, il vecchio modo sarà totalmente deprecato/rimosso, giusto?

Saluti,
Ismael

1 Mi Piace

Sì, capito dopo il post qui sopra. A meno che il Team non intraprenda azioni/controlli speciali per consentirlo, l’era dell’uso di ID utente casuali è finita, secondo me.

Saluti,
Ismael

1 Mi Piace

Sí, exactamente. Hemos estado lanzando gradualmente este nuevo pipeline de activos durante años, para que podamos seguir lo que recomienda el proyecto EmberJS y ser menos un caso aislado. Ya estamos en la fase final del despliegue.

2 Mi Piace

Ottimo, tutto chiaro.

Come al solito, grazie mille per le tue informazioni dettagliate, molto apprezzate.

Saluti,
Ismael

1 Mi Piace

Per completezza, e se può essere utile a qualcuno. Esiste almeno un modo per far funzionare ember cli come previsto con un uid casuale, ed è assicurarsi che l’uid casuale assegnato abbia una voce in /etc/passwd al momento dell’esecuzione dell’operazione rake assets:precompile.

Qualcosa come:

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

Quindi, il comando app/assets/javascripts/discourse run ember build -prod (da discourse/assets.rake at tests-passed · discourse/discourse · GitHub) lo farà.

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)
...

Ho anche notato che questa operazione è piuttosto costosa, consumando quasi 2 GB di RAM solo per la precompilazione :scream:

Saluti,
Ismael

2 Mi Piace

La settimana scorsa utilizzava oltre 4 GB, ma siamo riusciti a farlo funzionare di recente su server con 1 GB di RAM/2 GB di swap.

4 Mi Piace

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