안녕하세요,
FAQ에 있는 내용인 것 같고, 그렇다면 미리 사과드립니다. 제가 충분히 찾아보지 못한 것 같습니다 
웹 인터페이스를 통해 실행하는 대신, 마법사와 동일한 작업을 수행하는 스크립트를 작성하려면 어떻게 해야 하나요?
스펙 테스트의 Fabricate(admin) 픽스처와 유사한 것으로 시작할 것입니다. 그리고 아마도 컨테이너의 커스텀 섹션에서 호출하게 될 것입니다.
도움 주시면 감사하겠습니다!
Wizard는 사이트 설정과 API 호출의 중간쯤에 해당합니다.
API 호출에 대해서는 Discourse API를 역공학하는 방법을 참고하고, 사이트 설정은 다음 예시를 따르세요:
하지만 … 아마도 제가 막막한 부분이 바로 이것일 겁니다: API를 호출하려면 API 키가 필요합니다. 그리고 이를 위해 관리자 사용자가 필요하지만, 저는 아직 그런 사용자가 없습니다. API 키 없이 API를 호출할 수 있을까요? 아니면 사용자 계정과 분리되어 관리자 권한을 가진 API 키를 발급받을 수 있을까요?
관리자 사용자를 생성하려면 rake:admin을 사용해야 하는 것 같습니다. 하지만 제 생각에는 관리자 사용자가 이미 생성되어 있고 승인만 되지 않은 상태일 수 있으며, 따라서 승인되도록 변경해야 할 것 같습니다.
아니면 api_key:create_master를 사용하여 API 키를 생성하고, 그 키를 이용해 관리자 사용자를 생성할 수도 있을까요?
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'api_key:create_master[MASTERKEY]'
ad676e7413778aaaaa5d315c35f188591ef0edb4a4d4b2d644b9247a88421cfa
하지만 이 마스터 키를 어떻게 사용해야 하는지 정확히 이해하지 못해 다음 명령이 작동하지 않습니다:
# curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c35f91ef0edb4a4d4b2d644b924b7a88421cfa"
{"errors":["You are not permitted to view the requested resource. The API username or key is invalid."],"error_type":"invalid_access"}
그러나 관리자 사용자를 생성한 후:
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'admin:create'
Email: loic@dachary.org
Password:
Repeat password:
Ensuring account is active!
Account created successfully with username loic
Do you want to grant Admin privileges to this account? (Y/n) Y
Your account now has Admin privileges!
그리고 방금 생성된 사용자를 지정하여 동일한 마스터 키를 사용하면 작동합니다:
curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c358591ef0edb4a4d4b2d644b924b7a88421cfa" -H "Api-Username: loic"
{"category_list":{"can...
/admin/site_settings/category/branding에도 접근할 수 있으므로 관리자 권한이 있는 상태입니다.
정확히 무엇을 하려 하시는 건가요? 관리자 사용자를 자동 생성하고 일부 설정을 적용하는 것을 원하시는 건가요?
네, 정확합니다. 저는 브라우저 상호작용이 필요 없는 스크립트를 통해 사용자와 카테고리, 주제 등을 채워 넣는 방식으로 새 포럼을 처음부터 만들어 보고 싶습니다.
아마도 먼저 해당 데이터베이스를 생성하고 설치 과정의 일부로 복원하는 것이 좋을까요?
데이터베이스가 없습니다. 사용자, 카테고리 및 토픽은 mailman2에서 가져온 데이터를 사용하여 생성됩니다.
데이터를 가져오려면 별도의 프로세스로 실행하면 됩니다.
그것이 일회성 작업이었다면 괜찮았을 겁니다. 하지만 저는 가져오기 스크립트를 테스트할 수 있어야 합니다. 그리고 테스트가 실행되려면 중간에 수동 개입 없이 처음부터 discourse를 생성해야 합니다. 
참고로, 이는 mailman2를 discourse로 가져오기 위해 진행 중인 작업의 일부입니다. 테스트는 tox에서 실행되며, tox는 다음과 같은 작업을 수행합니다:
- 새로운 discourse 인스턴스 생성
- 다양한 테스트 실행
- discourse 인스턴스 삭제
멀티사이트 설치 환경이라고 가정하면, 승인된 관리자 사용자와 관리자 API 키를 생성하려면 다음을 사용할 수 있습니다:
docker exec app env RAILS_DB=secondsite rake 'api_key:create_master[MYKEY]'( echo user1@example.com ; echo $pass ; echo $pass ; echo ) | docker exec -i app env RAILS_DB=secondsite rake 'admin:create'
참고: 멀티사이트 설치 환경이 아니라면, env RAILS_DB=secondsite 부분을 제거하면 됩니다.
그 후, 다음과 같이 작동하는지 확인합니다.
curl -X GET https://forum2/admin/backups -H "Accept: application/json" -H "Api-Key: 886171a73dd12759b5d6c1915b0f0d4475e8b3fff3d97954b95171200b6" -H "Api-Username: user1"
[]
(영감을 주신 Jay Pfaffman에게 특별한 감사를 드립니다)
이 작업이 완료되면 더 이상 마법사를 실행할 필요가 없으나, 화면에는 여전히 실행해야 한다는 메시지가 표시됩니다.
저는 수입(imports) 업무를 통해 생계의 상당 부분을 꾸려가고 있습니다. 아래에서 설명하는 내용은 정기적으로 수입을 수행하는 거의 모든 사람들이 사용하는 방식과 매우 유사할 것이라고 확신합니다.
제가 권장하는 방법은 다음과 같습니다.
- 임포터(importer)를 구성하고 실행합니다.
- 임포터가 원하는 대로 작동하는지 테스트합니다.
- 첫 실행 이후에 수집된 데이터를 가져오도록 임포터를 다시 실행하는 스크립트를 작성합니다.
- 해당 스크립트를 테스트합니다.
- 위 모든 단계가 정상적으로 작동하는 것을 확인한 후, 최종 임포트를 실행합니다.
- 해당 데이터를 프로덕션 서버에 복원합니다.
마이그레이션 작업과 프로덕션 서버 설정 작업은 완전히 별개의 작업이며, 요구 사항도 다릅니다. 일반적으로 마이그레이션 작업에는 프로덕션 서버에서 필요하지 않은 것들이 요구되지만(다만 mailmain 임포터는 예외라고 생각합니다).
멀티사이트(multisite) 서버에서 마이그레이션을 실행하는 것은 특히 무모해 보입니다.
조언 감사합니다. 이 과정을 따르겠습니다. mbox 아카이브가 100GB가 넘기 때문에 몇 번의 테스트는 필수적일 것 같습니다.
이 부분에 대해… mbox 임포터가 항상 새로운 카테고리를 생성하고 기존 카테고리를 사용할 수 없는 것 같습니다. 이 문제에 대해 아시는 점이 있으신가요?
foolhardy라는 단어의 의미를 몰랐습니다. 이 표현이 마음에 들어 다시 사용하겠습니다 
그래서 처음부터 가져오기를 다시 실행하는 것은 매우 나쁜 아이디어입니다. 그렇게 하면 몇 주가 걸릴 가능성이 높습니다. 가져오기를 다시 실행하면 새로운 데이터만 가져오게 됩니다(저는 기존 데이터를 완전히 건너뛰도록 스크립트를 수정하는 경우가 많습니다).
CategoryCustomField를 만들어 기존 카테고리를 사용하도록 스크립트를 수정할 수 있습니다. 빈 데이터베이스로 시작하고 스크립트가 카테고리를 생성하도록 두는 것을 권장합니다. 이후 원하는 대로 커스터마이징할 수 있으며, 스크립트를 다시 실행하면 기존 카테고리를 계속 사용하게 됩니다.
수입 데이터의 진정한 위험은 연도에 따라 데이터에 차이가 있을 가능성이 크다는 점입니다. 따라서 10년 전 데이터에는 적용되던 방식이 5년 전 데이터에는 적용되지 않을 수 있고, 이런 식으로 이어집니다. 하지만 운이 좋으면 다를 수도 있겠죠.
칭찬으로 들리는지 모르겠네요
저는 항상 가져오기(Import) 작업에 멀티사이트를 사용합니다. 이렇게 하면 여러 포럼이 공존할 수 있습니다: 제가 수정 작업을 진행하는 동안 클라이언트는 옆에 있는 포럼에서 가져온 결과를 검토할 수 있거든요. 또한 특정 시점으로 되돌아가기 위해 데이터베이스를 복사하는 것도 쉽습니다.
잠깐… 뭐라고!?
역시 놀랍네요! CDCK에서 일하지 않는 사람들 중, 가져오기(Import)에 대해 저보다 더 잘 아는 사람은 당신 정도인 것 같은데, 만약 당신이 가져오기에 멀티사이트를 사용한다면, 나도 그렇게 해볼까 생각하게 됩니다. 저는 보통 트래픽(Traefik)을 앞에 두고 같은 호스트에서 별도의 컨테이너를 구동하곤 하는데, 그래서 엄밀히 말하면 같은 방식은 아니지만, 어쨌든 비슷하다고 볼 수 있겠네요.