EMBER_CLI_PROD_ASSETS を 1 にするとアセットのプリコンパイルがクラッシュする

サポート
5

興味深いことに、あなたの提案を実行したところ、これが出力されました（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']
}

>

Discourseイメージはどのように実行していますか？セキュリティのために追加のフラグはありますか？

OpenShiftをベースにしたコンテナソリューションを使用しており、DiscourseはランダムなユーザーIDで実行されています。今のところ問題はありません。アプローチは公式のインストールガイドと非常によく似ています。
EMBER_CLI_PROD_ASSETS を 0 に設定することでこの問題を回避できます。アセットは以前のようにプリコンパイルされますが、遅かれ早かれ、この方向に進む計画がある場合、現在のプリコンパイルプロセスが放棄された場合、このようなソリューションにとって深刻な問題となる可能性があります。

そこで、いくつか質問があります。

  • 以前の方法でのアセットのプリコンパイルを放棄する予定はありますか？（もしそうなら）その時期はいつ頃ですか？
  • os マシンに別の方法でアクセスする方法はありますか、または別の方法を検討していただけますか？これにより、ランダムなユーザーIDを持つコンテナソリューションでも引き続き機能しますか？

この件についてご検討いただき、誠にありがとうございます。

よろしくお願いいたします。
Ismael

「いいね！」 1