EMBER_CLI_PROD_ASSETS 设置为 1 会在预编译资源时崩溃

支持
5

有趣的是，当我执行你的建议时，我得到了这个（如果目的是以 root 以外的随机用户访问任何内部库系统，这是完全有道理的）：

node
欢迎使用 Node.js v16.13.2。
输入“ .help”以获取更多信息。

> 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 来绕过此问题，资产会像以前一样预编译，但迟早，如果你打算朝这个方向发展，如果当前预编译过程被放弃，这可能会给这类解决方案带来真正的问题。

所以这里有几个问题：

  • 你是否有一个关于放弃（如果确实如此）旧式资产预编译的 ETA？
  • 是否有办法以不同的方式访问 os 机制，或者考虑不同的方法，以便使用随机用户 ID 的容器化解决方案仍然可以工作？

非常感谢你的关注，非常感激。

祝好，
Ismael

1 个赞