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으로 설정하여 이 문제를 우회할 수는 있지만, 자산은 예전처럼 사전 컴파일됩니다. 다만, 향후 이 방향으로 전환할 계획이라면 현재의 사전 컴파일 프로세스가 폐기될 경우 랜덤 사용자 ID를 사용하는 컨테이너화 솔루션에 실질적인 문제가 될 수 있습니다.

따라서 몇 가지 질문을 드리고자 합니다:

  • 예전 방식의 자산 사전 컴파일링을 폐기할 계획이라면(그렇다면) 예상 시점은 언제인가요?
  • os 모듈에 다른 방식으로 접근하거나, 다른 접근 방식을 고려하여 랜덤 사용자 ID를 사용하는 컨테이너화 솔루션이 계속 작동할 수 있는 방법이 있나요?

이 문제에 관심을 가져주셔서 감사합니다. 정말 감사드립니다.

인사드립니다,
Ismael