EMBER_CLI_PROD_ASSETS naar 1 crasht bij het precompileren van assets

Ondersteuning
5

Intersting, this is what I’m getting when executing your suggestion (and makes total sense if the intention is to access any internal library system with a random user other than 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']
}
>

How exactly are you running the Discourse image? Are there any extra flags for security?

We’ve been using a containerized solution based in OpenShift, in which Discourse is running with a random user id. No issues so far, approach very similar to the official install guide.
It’s certainly that we can bypass this issue by setting EMBER_CLI_PROD_ASSETS to 0, assets are precompiled as in the old days, but sooner than later, if your plans are to move into this direction, can pose a real problem for this kind of solutions if the current precompiling process is abandoned.

So a couple of questions here:

  • Do you have an ETA about abandoning (if that’s the case) precompiling assets the old way?
  • Is there any way to access the os machinery on a different way, or consider a different approach, so that containerized solutions with random user id’s can still work?

Many thanks for looking into this, much appreciated.

Cheers,
Ismael

1 like