업데이트 중 오류가 발생했습니다
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
수정하는 데 도움을 주실 수 있나요?
백업이 그곳으로 전송되고 있다면, 당신은 이미 접근 권한이 있는 것입니다. 그리고 네, 그 버킷의 소유자도 마찬가지입니다.
제3자 유료 서비스를 고려해 보시려면 Marketplace 채널에 주제를 개설하셔도 됩니다.
그런 입장이면 정말 난감하시겠네요. 공감합니다.
개인적으로는 재구축을 시도하기 전에 반드시 백업부터 확보하고 싶습니다. 만약 정기적인 백업 프로세스가 도움이 되지 않는다면(백업이 접근할 수 없는 곳에 전송되기 때문일 수 있으니), 명령줄을 통해 데이터베이스 백업을 받는 방법을 시도해 보겠습니다. 다만 정확히 어떻게 해야 하는지는 잘 모르겠습니다. 아마 도커 안에서 pg_dump를 사용하는 건가요?
아니면 명령줄 접근 권한을 이용해 S3 대신 로컬 디스크로 백업을 리다이렉트하는 것도 방법일 수 있습니다.
하지만 어떤 경우든 충분한 로컬 디스크 공간이 필요합니다.
수정: 제이와 동시에 글을 올렸네요.
감사합니다 - 백업을 수행할 수 있다면 S3 대신 로컬 디스크로 백업을 리다이렉트하는 것이 제 일반적인 생각입니다. 그렇게 하면 필요한 공간을 확보할 수 있을 것입니다.
재건축을 수행하기 전에 지난밤에 로컬 백업을 진행하지 못한 것은 제 실수입니다. 사후적으로 보면 그 부분은 20/20(사후의 지혜)인 셈이죠. 재건축이 미치는 영향을 과소평가했습니다.
이 내용을 이해하는 데 도움이 될 수 있을까요? 백업이 해당 위치로 라우팅되고 있다면 인증 정보가 존재해야 한다는 뜻인가요? (우리 Discourse의 관리자 패널에 새로운 항목이 나타나는 것을 확인했습니다.)
문제는, 백업에 접근하려면 인증 정보가 필요한데, 그 정보를 실제로 가지고 있는 사람은 연락이 두절된 그 사람뿐인 것 같다는 점입니다.
literatecomputing이 이 작업을 맡게 된다면, 로컬 백업을 가져와 기존 사이트를 새로 관리되는 서버에 복원할 수 있을까요?
S3 버킷에 지난 주와 같이 최근 날짜의 백업이 있다면, Discourse가 해당 버킷에 대한 자격 증명을 보유하고 있을 것입니다. 이 자격 증명은 app.yml 또는 사이트 설정에 저장되어 있을 가능성이 높습니다.
다만, S3 버킷에 직접 접근할 필요는 없습니다. Discourse를 통해 백업을 다운로드할 수 있어야 합니다.
/admin/backups에서 백업이 보이나요?
보인다면, 다운로드를 시도할 때 어떤 일이 발생하나요?
또는 사이트 설정 - 백업 - 백업 위치를 "로컬 저장소(local storage)"로 변경할 수도 있습니다.
네. S3로 백업하는 경우 자격 증명은 데이터베이스나 yml 파일에 있습니다.
네. SiteSettings 또는 yml 파일에 backup_location 설정이 있습니다. 데이터베이스가 아닌 SiteSettings에 있는 경우 변경이 더 어렵지만 불가능한 것은 아닙니다.
저는 그냥 초보이지만
최근 토픽에서 재빌드 시 파일 소유권 문제와 관련된 보고가 있었습니다.
명령줄 접근 권한이 있다면 왜 명령줄로 백업을 하지 않나요?
저는 루트 접근 권한이 있습니다. 커맨드라인으로 백업을 수행했지만, S3로 업로드되었습니다. @pfaffman님의 코멘트를 통해 이제 S3에서 백업을 로컬로 가져와볼 수 있겠다는 생각이 들었습니다. 시도할 시간이만 있으면 됩니다.
UX의 설정에서 backup_location 설정 항목을 확인하나요? (아니면 서버가 꺼져서 확인이 불가능한 건가요?)
말씀하신 것이 이 경고인가요?
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
이것은 경고입니다. 수년간 해당 파일은 기본적으로 모든 사용자가 읽을 수 있도록(world-readable) 설정되어 있었습니다(대부분의 셀프 호스터는 루트 계정으로 로그인하고 다른 사용자가 없다고 가정했기 때문이죠). 하지만 어느 시점부터는 해당 파일에 포함된 시크릿(비밀 정보)이 모든 사람에게 읽힐 수 있는 상태는 최선의 관행이 아니라는 판단이 내려졌습니다. 현재 런서를 루트 계정으로 실행하고 있으므로, 루트 사용자는 항상 해당 파일을 읽을 수 있습니다.
admin/backups를 찾을 수 없습니다. 어디에 있나요? backups를 본 유일한 위치는 /var/discourse/shared/standalone/backups/default인데, 여기 있는 것들은 모두 오래된 로컬 백업입니다.
사이트 설정 관련 상황은 나중에 해당 사이트에 접근할 수 있는 사람이 깨어 있을 때(영국 시간대입니다) 후속 조치를 취하겠습니다. 사이트가 다운되어 있어서 그 사람이 접근할 수 없는 것으로 추정됩니다.
app.yml 파일에서 backup_location 설정을 구체적으로 확인하지 못하고 있습니다.
그리고 부수적인 이야기인데, 귀사 소개 페이지에서 전직 CS 교사셨다는 것을 보았습니다. 저 역시 현재 본업이 CS 교사입니다 
아니요, 그 경고가 아닙니다. 기회가 되면 구체적인 오류 메시지를 올리겠습니다. 말씀드린 것처럼 노드 업그레이드를 시도할 때 발생한 오류였지, 재빌드 중에 발생한 것이 아닙니다.
포럼 URL에 이 항목을 추가하세요. 그러면 사용자 인터페이스에서 백업을 확인할 수 있습니다.
아, 알겠습니다. 서버 자체에서 이 내용을 찾고 있었어요. 사이트가 완전히 중단되어 해당 페이지에 접근할 수 없었습니다.
일반적인 질문입니다. 서버의 사양은 무엇인가요? OS 버전도 포함해 주세요.
오늘 로컬에서 새 백업 설정을 마쳤으니, 이제 로컬로 다운로드하고 있습니다.
/var/discourse에서 pull을 실행한 뒤, 업데이트를 위해 리빌드를 시도하면 될까요?
Your branch and 'origin/main' have diverged,
and have 15 and 201 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
diverged(분기)라고 표현한 것은 사실 과소평가입니다 
컨테이너 구성을 커밋하고 있는 것 같은데, git pull 또는 git pull --rebase를 실행하면 원하는 위치에 도달할 수 있을지도 모르니, 한 번 시도해 보는 것도 좋을 것 같습니다 
친구들, 지금 무슨 일이 일어나고 있는지 전혀 감이 잡히지 않지만, 필요하면 pull이나 rebase를 시도해서 어떤 결과가 나올지 확인해 보겠습니다. 어쨌든 사이트가 이전 버전으로 다시 올라왔기 때문에, 새로운 유지보수 윈도우를 만들 예정입니다. 결과가 나오면 모두에게 업데이트해 드리겠습니다.
모두의 조언에 진심으로 감사드립니다!