가이드를 작성해 주셔서 감사합니다.
하지만 관리자 섹션에서 백업을 생성할 때 문제가 발생하고 있습니다.
다음과 같은 오류가 표시됩니다:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".
pg_hba.conf 파일을 확인했는데, 모든 옵션이 trust로 설정되어 있습니다.
이 문제를 해결하는 방법에 대한 도움을 주시면 감사하겠습니다.
Ubuntu와 MacOSX 모두에서 시도해 보았습니다. 두 환경 모두에서 게시글 생성, API 등 모든 기능이 정상적으로 작동하지만 백업 기능만 작동하지 않습니다.
훌륭한 Docker 솔루션을 공유해 주셔서 감사합니다.
플러그인 스펙을 실행하는 데 이 방법이 잘 작동합니다:
d/rake plugin:spec["discourse-follow"]
Docker를 사용하지 않는 개발 환경처럼 특정 플러그인 테스트를 대상으로 할 수 있는 방법이 있을까요? 예를 들어:
LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32
다음과 같이 시도해 보았지만:
d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10 LOAD_PLUGINS=1 RAILS_ENV=test
에러가 발생합니다.
LOAD_PLUGINS와 RAILS_ENV는 환경 변수를 지정하기 위해 커맨드 앞에 위치해야 합니다. 커맨드 뒤에 위치할 경우, rspec가 이해하지 못하는 rspec의 인자로 취급됩니다.
LOAD_PLUGINS=1 RAILS_ENV=test d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10
아니요, 그게 효과가 있다고는 생각하지 않습니다 - 실제로 시도해 보셨나요?
아래와 같은 오류가 발생합니다:
NameError:
uninitialized constant Follow
환경 변수가 docker 프로세스로 전달되지 않고 있기 때문이라고 추측합니다.
그래서 제가 그것들을 인자로 전달하려고 했던 것입니다.
죄송합니다. 두 명령을 "첫 번째는 다른 스펙에서는 작동하지만, 두 번째는 이 스펙에서는 작동하지 않는다"고 오해했습니다. 테스트를 위해 개발 환경을 설정해 두지 않았습니다.
GitHub의 rspec 파일을 확인해 보면, 환경 변수를 전달하지 않는 것 같다는 말씀이 맞는 것 같습니다. 다만 d/shell을 실행하면 컨테이너 내부에서 셸을 열 수 있으므로, 거기서 rspec 명령을 실행해 보실 수 있을 것입니다.
Simon, 정말 훌륭한 해결책이네요. 감사합니다!
방금 테스트해 봤는데 잘 작동합니다. 예를 들면:
my-blah-machine:~/discourse$ d/shell
discourse@discourse:/src$ LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37
이 내용을 위키에 추가했습니다.
d/shell과 d/rspec 모두 사용하는 d/exec를 좀 더 자세히 살펴보면, 이렇게 줄일 수도 있을 것 같다:
RAILS_ENV=test d/exec LOAD_PLUGINS=1 rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37
d/exec는 RAILS_ENV는 전달하지만 LOAD_PLUGINS는 전달하지 않기 때문에, 이 두 변수가 d/exec의 양쪽에 배치되어 있다.
그렇게 하면 다음과 같은 오류가 발생합니다:
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "LOAD_PLUGINS=1": executable file not found in $PATH: unknown
아, 환경 변수를 docker exec에서 그렇게 사용할 수 없구나. 뭐, 어쨌든 먼저 셸을 여는 방식은 작동하니까 다행이야.
저는 Max와 정확히 같은 문제를 겪고 있습니다. 로컬 개발용 Docker 설치 환경에서 백업이나 복구를 시도할 때마다 동일한 오류가 발생합니다: Peer authentication failed for user "postgres"
조사를 해본 결과, 개발 환경에서 데이터베이스 설정이 다음과 같이 표시됩니다:
BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration host=nil, port=nil, username="postgres", password=nil, database="discourse_development">
어떤 이유로 개발 환경이 환경 변수에 사용자 이름을 설정하지 않아 BackupRestore 모듈이 사용자 이름 값을 기본적으로 postgres로 설정하는 것 같습니다.
# lib/backup_restore.rb:122
DatabaseConfiguration.new(
config["backup_host"] || config["host"],
config["backup_port"] || config["port"],
config["username"] || username || ENV["USER"] || "postgres",
config["password"] || password,
config["database"]
)
올바른 데이터베이스 사용자 이름을 어디에서 설정할 수 있을까요?
Install the Discourse Theme CLI console app to help you build themes 을(를) 어떻게 사용하나요?
gem을 성공적으로 설치했습니다: d/exec sudo gem install discourse_theme … 이제 로컬 테마로 심볼릭 링크를 만드는 것이 과제입니다 …
@Simon_Manning 권한 문제를 우회하기 위해 sudo를 사용했음을 참고해 주세요 (리마인드해 주셔서 감사합니다 @fzngagan)
docker 설정으로 플러그인을 테스트하고 있습니다. 랜덤하게 앱 로딩이 멈추고, 데이터 폴더를 삭제하고 모든 것을 다시 빌드하기 전까지는 빈 화면만 표시됩니다. 이 문제를 디버깅하는 데 도움이 되는 팁이 있을까요?
그 문제에 대해 어떤 발견이 있었나요? 여전히 문제가 있는 것 같습니다.
저의 “지저분한” 우회 방법은 다음 코드 블록에서 사용자 이름 postgres를 discourse로 대체하는 것이었습니다:
# lib/backup_restore.rb:122
DatabaseConfiguration.new(
config["backup_host"] || config["host"],
config["backup_port"] || config["port"],
config["username"] || username || ENV["USER"] || "postgres",
config["password"] || password,
config["database"]
)
로컬 Mac에서 Ubuntu VM으로 전환했는데, 이렇게 하면 실행이 더 쉬워질 줄 알았지만 불행히도 아직까지는 그렇지 않습니다.
초기 단계에서 이미 기이한 권한 문제와 씨름하고 있습니다. d/bundle install은 일부 패키지를 설치하려면 sudo 권한이 필요하다고 보고하고, d/rails s도 권한 문제로 인해 실행되지 않습니다.
Traceback (most recent call last):
8: from /src/bin/unicorn:70:in `<main>'
7: from /src/bin/unicorn:38:in `ensure_cache_clean!'
6: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'
5: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'
4: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'
3: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'
2: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'
1: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
/usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permission denied @ dir_s_mkdir - /src/tmp (Errno::EACCES)
무엇이 잘못되었는지 아이디어가 있을까요? 이 머신은 이전에 프로덕션 discourse를 문제없이 실행했습니다. 저는 단순히 해당 컨테이너를 중지하고 제거한 후, dev git 저장소를 다른 디렉터리로 클론했습니다. 서로 다른 셸 인스턴스를 처리하기 위해 tmux를 통해 모든 것을 실행하고 있습니다.
아직 M1을 사용하지는 않지만, 곧 전환할 예정이며 Docker 환경 설정의 편리함을 훨씬 선호합니다.
해당 PR 링크는 https://github.com/docker/for-mac/issues/5321로 연결되며, 거기서 이렇게 언급하고 있습니다:
유일한 해결책은 arm64를 지원하는 멀티 아키텍처 이미지로 전환하는 것입니다. 이러한 이미지는 훨씬 빠르고 일반적으로 더 안정적입니다. 사용 중인 기본 이미지를 확인하고 가능한 경우 멀티 아키텍처 이미지로 전환하는 것을 권장합니다. 각 이미지가 지원하는 아키텍처는 Docker Hub에서 확인할 수 있습니다: […]
멀티 아키텍처 이미지를 직접 빌드하려면
docker buildx사용을 권장하며, 이 블로그 포스트를 확인해 보세요: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/
Discourse 팀이 멀티 아키텍처 이미지 지원을 고려하고 있을까요? Discourse 기본 이미지는 debian:buster-slim 기반으로 되어 있으며, 이는 멀티 아키텍처를 지원하므로 Discourse 기본 이미지를 멀티 아키텍처로 만드는 것이 불가능할 정도로 어려운 작업은 아닐 것 같습니다. 하지만 그렇게 하면 ARM(프로덕션 환경에서!)을 지원해야 하는 입장에 처할 수 있습니다. 누군가(Discourse 팀?)가 x86_64 및 ARM 양쪽에서 Discourse 테스트를 실행하고, 실패 시 문제를 수정하는 등의 작업을 수행해야 합니다.
여기서 PR이 환영받을까요?
(개인적으로 ARM은 클라우드 호스팅 환경에서도 미래의 아키텍처라고 생각합니다.)
WSL2에서 이걸 설정하려고 합니다.
ember_cli 시작까지 진행했는데, Chrome에서 다음과 같은 오류가 표시됩니다:
터미널이나 개발 로그에서 오류가 보이지 않습니다. 조언 주시면 감사하겠습니다.
정말 유용합니다.
여러분 안녕하세요,
같은 문제를 겪고 있어서 버그로 보고하려고 합니다. 아래 내용을 확인해 주세요.
추가 정보를 제공하거나 도움이 될 수 있는 부분이 있는지 알려 주세요.
Koen
openSUSE Leap 15에서 이 문제를 해결하지 못하겠습니다. 이는 지원되지 않는 OS일 것 같지만, Docker를 사용하고 있으므로 실제로는 문제가 되지 않아야 할 것 같은데…
Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/app/assets/javascripts/plugins
/src/lib/plugin/instance.rb:441:in `ensure_directory'
/src/lib/plugin/instance.rb:713:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)
"app/assets/javascripts/plugins"를 수동으로 생성해 보았더니, 그 결과 다음과 같은 오류가 발생했습니다.
Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/tmp
lib/discourse.rb:94:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)
그래서 소스 폴더에 tmp를 mkdir로 생성해 보았습니다…
하지만 그 다음에는 여기까지 오게 됩니다:
Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /src/tmp/5ad4443faf817dc922116f8df65ae5c3
lib/discourse.rb:97:in `initialize'
lib/discourse.rb:97:in `open'
lib/discourse.rb:97:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)
boot_dev가 discourse 사용자로 docker exec를 실행하는 것처럼 보입니다… 하지만 디렉터리는 uid가 1016인 사용자(제 호스트 사용자의 uid)가 소유하고 있습니다.
대부분의 개발자들은 개인 노트북에서 uid가 1000인 사용자로 실행하여 우연히 uid가 일치하기 때문에 이 문제에 직면하지 않을 것이라고 생각합니다…