현재 데이터베이스에 있는 포스트와 사용자(두 개의 다른 구식 포럼에서 가져온 것)를 전역적으로 정리할 수 있는, 사용자 친화적인 유틸리티를 찾고 있습니다. 예를 들어, 주제를 삭제하거나, 제목에 특정 문자열이 포함된 모든 포스트에 특정 태그를 추가하거나, 사용자 프로필이 특정 기준을 충족하지 않는 경우 사용자를 삭제하거나 접근 권한을 변경하는 등의 작업이 가능한 도구입니다.
phpMyAdmin처럼 Discourse 관리자의 SQL 백업 파일을 편집할 수 있는 도구가 있을까요? 아니면 라이브 Discourse 인스턴스에서도 작동할 수 있을까요?
Discourse 내에서 쿼리를 실행할 수 있는 플러그인이 있다는 것은 알지만, 데이터 변경은 허용하지 않는 것 같습니다.
업로드 없이 백업을 다운로드하여 로컬 PostgreSQL 인스턴스에 복원한 후, pgAdmin3로 쿼리를 실행하는 것이 가장 좋은 방법입니다.
네, Data Explorer 플러그인은 변경 사항을 적용할 수 없도록 되어 있습니다. 하지만 일단 이 플러그인부터 시작하는 것을 권장합니다. 쿼리를 실행하여 문제가 실제로 존재하는지 확인한 후, 변경이 필요한 레코드를 선택하는 쿼리를 실행할 수 있습니다. 이렇게 하면 실수로 데이터베이스를 망가뜨리는 것에서 보호받을 수 있습니다.
이미 프로덕션 환경에서 운영 중인 것으로 추정됩니다. 따라서 Discourse 팀의某种 승인 없이 데이터베이스를 수정하는 것은 매우 신중해야 합니다.
Discourse 데이터베이스에 익숙해지고 문제의 규모를 파악한 후에는 변경 사항을 적용할 방법을 고려해 볼 수 있습니다. 모든 작업을 Discourse 내에서 처리할 수 있을 수도 있고, 변경 사항이 매우 적어 커맨드라인으로 처리해도 충분할 수도 있습니다.
Falco 씨, 감사합니다!
나는 클릭과 포인터를 사용하는 것 외에는 아무것도 잘 모르는 초보입니다.
하지만 공식 가이드를 따라(아무것도 크게 이해하지 못했지만) Windows 10에서 Discourse의 로컬 인스턴스를 설정하는 데 성공했습니다. 그렇다면 pgAdmin3를 같은 위치에 설치하는 방법에 대한 안내도 어딘가에 있을까요?
어리석은 질문일 수 있지만, 이 오프라인 Discourse 인스턴스가 내보낸 SQL 파일을 복원해야 하는 대상인가요? (아니면 PostgreSQL로 Discourse 데이터베이스 백업 파일을 '복원’하는 다른 방법이 있나요?)
그리고 복원 후에 어떻게 쿼리를 실행하나요? 즉, 실행 중인 Discourse 인스턴스의 데이터베이스로 pgAdmin3를 어떻게 연결하나요? 실행 중인 discourse 데이터베이스는 물리적으로 어디에 위치하나요? Discourse 인스턴스가 실행 중이라는 사실이 데이터베이스를 어떤 방식으로 잠그나요?
로컬 서버의 ~ /var/discourse 디렉터리 안에 있는 파일들 중에서 데이터베이스에 해당한다고 명확히 보이는 파일을 찾지 못하겠습니다.
Remah, 감사합니다.
저는 Discourse를 자체 호스팅하고 있어서 Discourse 팀에 직접 접근할 수 없습니다.
작은 커뮤니티를 위해 순수히 자원봉사 기반으로(즉, 예산 없이) 포럼을 구축하고 운영 중이며, MyBB와 Yahoo Groups 포럼의 데이터를 모두 가져오고 있습니다. 후자의 경우, 예를 들어 오래된 관리용 자동 생성 이메일 알림들이 Discourse에서 주제(topic)로 대량으로 생성되어 이 맥락에서는 거의 관련이 없는 상태입니다.
새로운 문제를 발견할 때마다 임시로 테스트하고 전역 설정을 변경해야 할 가능성이 높으므로, 학습 곡선을 최소화하고 CLI 기반 도구를 피하고 싶습니다.
도메인 이름을 보고 처음부터 확인해 보니, 당신의 상황을 어느 정도 이해할 수 있습니다. 참고로 저는 웰링턴에 있으며, 자선 단체를 위한 비공개 포럼 두 개를 설정하고 적극적으로 사용 중입니다.
시간과 경험이 제한적이므로, 가장 단순하고 사용하기 쉬운 도구부터 시작하고, 상황이 요구할 때만 다음 단계로 넘어가는 것을 제안합니다. Discourse 자체를 사용하는 첫 번째 수준 이상의 도구를 마스터하는 데는 상당한 비용이 듭니다. Discourse는 설계된 대로 사용할 때 놀라운 힘을 발휘할 수 있습니다.
어쨌든 마스터해야 할 기능들이 포함된 Discourse GUI.
Discourse에서 필요한 기능에 익숙해지세요. 더 이상 진행하지 않아도 필요한 작업의 99%를 수행할 수 있을地发现할 수 있습니다. 따라서 더 이상 진행하지 않을 수도 있습니다.
실제로 보이는 문제들을 우선시하세요.
예를 들어, 이전의 이메일 알림은 큰 문제가 아닐 수 있습니다. 관련성이 없다면, 더 관련성 있는 주제들이 생성됨에 따라 Discourse에서 설계된 대로 그 중요도가 자연스럽게 낮아집니다. 모든 데이터 오류를 해결하는 것보다 포럼을 제대로 가동하는 것이 더 중요합니다.
따라서 이러한 자동화 이메일 알림 중 몇 개가 주제로 변환되었나요?
데이터 탐색기(Data Explorer) 플러그인은 당신에게 유용할 것이므로, 데이터베이스를 더 잘 이해하고 어떤 조치가 필요한지 식별하기 위한 다음 단계입니다. 나중에 보고에 도움이 되지만, 절대적으로 필수적인 것은 아닙니다.
변경 사항을 만들 수 없는 것은 안전장치입니다. 몇 년 전에는 성급한 업데이트로 인해 데이터가 손상되는 사용자가 많았기 때문입니다.
문제 기록을 식별하기 위해 생성하는 쿼리는 데이터베이스를 수정하는 SQL 쿼리에서 한 단계만 떨어져 있습니다.
최종 옵션은 데이터베이스를 수정하기 위한 명령줄과 스크립트일 가능성이 높습니다.
데이터베이스를 수동으로 수정함으로써 손상될 위험을 감수하기보다는, 화면에 표시되는 데이터에 오류가 있는 위험을 감수하는 편이 낫습니다. 이는 시간 폭탄을 만들 수 있습니다. 일부 데이터 손상 사항은 적시에 식별되지 않을 수 있기 때문입니다.
데이터 탐색기를 사용하면 실제 데이터 예시와 정량화된 기록 수를 포함한 쿼리 결과를 얻을 수 있습니다. 팀과 다른 전문가들이 당신의 데이터와 달성하려는 목표를 이해할 수 있다면, 올바른 답변을 얻을 가능성이 더 높습니다. 그들은 데이터베이스를 업데이트하는 가장 쉽고 안전한 방법에 대해 조언해 줄 수 있습니다.
당신이 필요한 것의 대부분은 이미 주제에 포함되어 있을 가능성이 높습니다. 다른 사이트들도 비슷한 유형의 문제에 직면하기 때문입니다. 따라서 다른 사람이 어렵게 얻은 지식을 그대로 복사하는 셈이 됩니다.
전적으로 동의합니다. 데이터베이스를 직접 수정하지 마세요. 언젠가 후회하게 될 것입니다.
Remah, 감사합니다.
모든 조언이 합리적으로 들립니다.
일부 사용자들이 수동으로 삭제할 주제를 스캔하고 표시하도록 설득할 수 있다면, 부분적인 해결책을 크라우드소싱으로 마련할 수 있을지도 모릅니다.
현재 해당 도메인의 사이트는 본질적으로 빈 상태의 플레이스홀더이며, 프리랜서가 기존 포럼에서 데이터를 가져오는 과정을 세밀하게 조정하고 있습니다. 특히 MyBB에 대한 가져오기 스크립트를 조정하여, 이전에 설정해 두었던 사용자 프로필의 사용자 지정 필드가 사용자와 게시글과 함께 정상적으로 가져와지기를 바랍니다. 또한 MyBB 게시글 중 일부에 포함된 MyCode를 올바르게 파싱하여, 현재는 보이는 상태인 서식 코드가 제대로 처리되기를 기대합니다.
저는 이 가져오기 작업을 직접 시도하면서 한 주를 헛되이 보냈습니다. MyBB 가져오기 스크립트 사용에 대한 공식 가이드에 따라, Windows 10의 Ubuntu 인스턴스든 DigitalOcean 기반 인스턴스든, 모든 선행 조건이 갖춰진 개발 환경을 구축하는 데 실패했기 때문입니다.
고통스럽게 여기저기 헤매며, 하나의 오류 메시지를 해결하면 또 다른 오류가 쏟아지는 상황을 반복하다가, 결국 가져오기를 시작하는 최종 Ruby on Rails 명령을 실행할 때 SQL 데이터베이스에 접근하는 부분에서 어느 쪽 환경에서든 완전히 막혀버렸습니다.
Linux와 Ruby는 모두 자학 성향의 사람들을 위해 잔인한 사람들이 작성한 것 같습니다. 둘 다 놀라울 정도로 취약하고 난해하니까요. 그런 환경에서는 데이터베이스를 조작할 때 치명적인 문제가 발생할 가능성이 높다고 느껴집니다!
동감입니다.
포럼 관리자로 남아주세요. 
그 환경에서는 항상 사용자 친화성이 부족했습니다. 20년 전보다도 커맨드 라인이 더 왕이라고 생각합니다.
그래서 저는 디스커스를 좋아하는 겁니다. 팀이 코어 디스커스를 훨씬 더 친근하게 만들려고 노력하고 있습니다. 불행히도, 마이그레이션은 고도의 기술이 필요한 선택지입니다.
그 작업은 거의 확실하게 Rails 콘솔에서 수행하는 것이 더 좋습니다.
‘더 좋다’의 기준에 따라 달라질 수도 있겠네요.
제 경우처럼 초보자의 경우, 평소 개발 환경을 설정해 본 적 없고 Ruby(물론 Linux도)에 대해 전혀 모르는 사람에게 가장 낮은 학습 곡선과 최소한의 접근 복잡성이 높은 우선순위가 될 것입니다. 이러한 것들에 익숙해질 다른 이유(그리고 시간)가 있다면 상황이 달라질 수도 있겠지만요… 이상적인 세상이라면, Digital Ocean에서 호스팅 중인 Discourse 설정을 직접 조회할 수 있는某种의 GUI 기반 로컬 윈도우 앱이 있었으면 좋겠습니다…
데이터베이스에 직접 변경 사항을 적용하지 않기로 결정했다면, 이 주제에서 설명하는 일부 명령이 도움이 될 수 있습니다: Administrative Bulk Operations. 예를 들어, 레일스 콘솔에서 주제를 태그하는 방법에 대한 자세한 내용이 포함되어 있습니다. 가장 중요한 점은 명령을 실행하기 전에 사이트 데이터베이스를 백업하는 것입니다.
저에게 ‘더 낫다’는 기준은 “데이터베이스가 손상된 상태, 특히 완전히 망가진 상태로 남을 가능성이 훨씬 낮은 것”입니다. 당신이 ‘초보자’라서, 당신이 . . . 무언가를 수행할 때 어떤 테이블을 업데이트해야 하는지 모릅니다.
어떤 방식으로 하든, 자주 백업을 꼭 하세요.
좋은 지적입니다. 일단 다른 방법들을 찾아보도록 하겠습니다.
두 시나리오 모두에서 제 무지가 큰 리스크이지만, Ruby를 통해 데이터베이스 변경을 수행하는 것이 pgAdmin4를 사용하여 동일한 변경을 시도하는 것보다 더 안전하다고 볼 수 있을까요?
즉각적으로 인지되지 않는 손상의 위험성에 대해 언급이 있었는데요 - 한 가지 접근 방식과 다른 접근 방식 중 이 위험성에 영향을 미칠 수 있는 요인이 있을까요?
머릿속으로는, 적절한 백업을 마친 후에도 감행하기로 결정한다면, Digital Ocean 드롭렛에서 pgAdmin4의 복사본을 실행하여 CLI 콘솔 창을 거치지 않고 브라우저에서 URL을 통해 직접 접근할 수 있도록 하는 방안을 구상했습니다. 이렇게 하면 복잡성의 계층을 몇 단계 줄일 수 있을 것 같습니다(여기서 이것이 실제로 가능한지 가정하고 있습니다).
대체로 그렇습니다. Ruby는 올바른 일이 일어나도록 보장하기 위해 다양한 마법 같은 작업을 수행합니다. 예를 들어 모델에서 무언가를 destroy(삭제)하면, 언제 어떤 다른 항목들이 삭제되어야 하는지 알고 있습니다. 원시 SQL을 사용하여 수행할 수 있는 “안전한” 작업도 많지만, 가능할 경우 거의 항상 Rails를 통해 수행합니다.
아, 그거 알아서 좋습니다. 감사합니다!
꽤 유용해 보이네요. 감사합니다!
저는 GUI에서 Discourse 데이터베이스를 직접 편집하는 방법?에 대한 답변이 제가 원하던 내용과 달라서, 스스로 해결한 방법을 공유합니다.
프로덕션 환경에서는 절대 이렇게 하지 마세요.
이 방법은 PostgreSQL에서 권장하는 관리 도구인 pgAdmin 4를 사용합니다.
이 작업은 Discourse에 대해 더 알아보기 위해(예: 설치, 구성, 튜닝, 플러그인 개발, API 사용, 웹훅 설정 등) 제 로컬 머신에서 수행되었습니다.
참고: Discourse는 Windows 10에서 개발용 Discourse 설치 입문 가이드에 따라 Windows 10의 WSL 2에 설치된 Ubuntu 18.04 환경에서 실행되었습니다.
참고: WSL 2에는 systemd가 기본적으로 포함되어 있지 않습니다. Issue 457
Ubuntu 20.04/18.04/16.04에 pgAdmin 4 설치하기를 템플릿으로 참고했습니다.
BASH 사용
$ echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" |sudo tee /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
$ sudo apt update
$ sudo apt install pgadmin4 pgadmin4-apache2
pgAdmin4 사용자 이메일: postgres@localhost
pgAdmin4 비밀번호: <password 1>
$ sudo /etc/init.d/apache2 restart
$ sudo ufw allow http
$ sudo ufw allow https
$ hostname -I
<address> 기록하기
$ whoami
<user name> 기록하기
PostgreSQL 전문가가 아니어서 Postgres DB 사용자 비밀번호를 가져오는 방법을 몰랐거나, pgadmin4에 필요한 DB 로그인을 설정하는 다른 방법이 있었을 수도 있으므로, 다음 단계는 필요하지 않을 수 있습니다.
$ psql postgres
PSQL 사용
postgres=# ALTER ROLE <user name> '<password 2>';
인터넷 브라우저 사용
http://<address>/pgadmin4
사용자: postgres@localhost
비밀번호: <password 1>
pgAdmin4가 시작되면
pgAdmin4 사용
서버 연결 생성
탭: General(일반)
Name(이름): Discourse Development
Server group(서버 그룹): Servers(서버)
탭: Connection(연결)
Host(호스트): localhost
Port(포트): 5432
Maintenance database(유지보수 데이터베이스): postgres
Username(사용자 이름): <user name>
Password(비밀번호): <password 2>
완벽하지는 않지만 작동하며, 아무것도 없는 것보다는 낫습니다. 피드백과 제안 환영합니다.
보너스 라운드
PostgreSQL
소프트웨어 카탈로그 - 관리/개발 도구
대부분의 작업에서는 데이터베이스에 직접 접근하는 것보다 Rails 콘솔을 사용하는 것이 더 쉽고 약간 더 안전하다고 생각합니다.
혹시 하려는 것이 사용자 비밀번호 변경이라면(그게 아니라도 괜찮습니다. 여전히 좋은 예시이므로), 다음을 실행하세요.
cd /var/discourse
./launcher enter app
rake admin:create
이름과는 달리, 이 rake 태스크를 사용하면 다음 작업을 수행할 수 있습니다.
다른 예시들은 Administrative Bulk Operations을 참고하세요.
다음은 몇 가지 예시입니다:
users=User.all
me=User.find_by_username ('pfaffman')
me=User.find_by_email('jay@literatecomputing.com')
UserEmail.create!(user: me, email: myotheraddress@somewhereelse.com')
posts_with_uploads=Post.where("raw like '%upload%' ")
Group.create(
name: "mygreatgroup",
automatic_membership_email_domains: 'literatecomputing.com',
primary_group: true,
title: "Literate Computing Staff",
grant_trust_level: 4,
flair_url: 'https://example.com/path.icon.png'
)
피드백 감사합니다. 배울 점이 하나 더 늘었네요.
개발 경력은 수십 년에 이르지만, Ruby나 Rails는 사용해 본 적이 없습니다. 실제로 대학 시절 펀치 카드로 프로그래밍을 시작했고, 개인적으로는 Atari 800으로 시작했습니다.