바로 이 주제에 대해 논의해야 하는 이유가 이것입니다. 원래 게시물에는 비교적 자주 업데이트되는 목록이 포함되어 있습니다. 수정 이력을 살펴보면 어떤 플러그인이 언제 추가되었는지 알 수 있습니다.
이제 끝났습니다! 남은 것은 케이크데이(cakeday) 하나뿐이며, 몇 달 안에 완료될 것입니다.
얼마 전에 이 문제에 부딪혔습니다. 최근 Discourse 개발을 시작해 보고 있어서, 업데이트 워크플로우를 연습해 보고자 했습니다:
# git pull
# bundle install
# pnpm install
# ./bin/rails db:migrate
하지만 제 추측으로는, Discourse AI 플러그인이 PostgreSQL의 Pgvector 플러그인을 요구하는 것 같습니다(이 플러그인의 존재를 이전에는 몰랐습니다):
== 20230710171141 EnablePgVectorExtension: migrating ==========================
-- enable_extension(:vector)
bin/rails aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)
ERROR: current transaction is aborted, commands ignored until end of transaction block
/home/john/development/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:8:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block (PG::InFailedSqlTransaction)
/home/john/development/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:8:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
ActiveRecord::StatementInvalid: PG::FeatureNotSupported: ERROR: extension "vector" is not available (ActiveRecord::StatementInvalid)
DETAIL: Could not open extension control file "/usr/share/postgresql/extension/vector.control": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:6:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Caused by:
PG::FeatureNotSupported: ERROR: extension "vector" is not available (PG::FeatureNotSupported)
DETAIL: Could not open extension control file "/usr/share/postgresql/extension/vector.control": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
/home/john/development/discourse/plugins/discourse-ai/db/migrate/20230710171141_enable_pg_vector_extension.rb:6:in 'EnablePgVectorExtension#change'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'block in FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/freedom_patches/schema_migration_details.rb:8:in 'FreedomPatches::SchemaMigrationDetails#exec_migration'
/home/john/development/discourse/lib/migration/safe_migrate.rb:28:in 'Migration::SafeMigrate::SafeMigration#migrate'
/home/john/development/discourse/lib/migration/safe_migrate.rb:53:in 'Migration::SafeMigrate::NiceErrors#migrate'
/home/john/development/discourse/lib/tasks/db.rake:267:in 'block (2 levels) in <main>'
/home/john/development/discourse/lib/distributed_mutex.rb:53:in 'block in DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'Thread::Mutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:49:in 'DistributedMutex#synchronize'
/home/john/development/discourse/lib/distributed_mutex.rb:34:in 'DistributedMutex.synchronize'
/home/john/development/discourse/lib/tasks/db.rake:242:in 'block in <main>'
Tasks: TOP => db:migrate
설치하러 갈 수는 있지만, 이 수준에서 플러그인을 비활성화하여 해당 마이그레이션이 단순히 건너뛰어지는 방법이 있는지 궁금합니다. (개발 목적으로 탐구하고 싶지 않은 "플러그인"의 경우, 추가 소프트웨어를 설치하는 것을 원하지 않습니다.)
오늘早些时候我也遇到了同样的问题。在 ChatGPT 的帮助下,我通过 sudo 安装了该包。我也在想,也许从 /plugins 目录中删除插件文件夹会有帮助
… 但之后运行 git pull 可能会将其重新安装回来。
이 변경 사항에 반대합니다. 일반적으로 소프트웨어 개발에서 핵심 코드를 가볍게 유지하면 메인 배포판의 크기를 줄이고, 속도를 높이며, 공격 표면(attack surface)을 축소할 수 있습니다. 제가 마지막으로 플러그인을 사용해 본 경험에 따르면, 플러그인 코드는 비활성화 상태여도 실행될 수 있는 것으로 보입니다. 이는 플러그인 작성자가 이를 확인해야 할 사항으로 보였기 때문입니다. 따라서 이러한 변경은 위험과 부풀림(bloat)을 상당히 증가시킨다고 생각합니다.
가장 즉각적인 문제는 설치 가이드에서 지침이 업데이트되지 않은 것 같습니다(제가 놓친 것일까요?). 다시 정상적으로 작동시키기 위해 무엇을 설치해야 하는지 명확하지 않습니다. postgresql-16-pgvector 우분투 패키지를 설치하여 일부 오류를 해결했지만, db:migrate 실행 시 여전히 일부 벡터 관련 오류가 발생했습니다. 로컬에서 AI 플러그인을 삭제하는 방식으로 우회했습니다.
어쨌든, 이는 상당한 양의 추가 코드이며, 이 중 많은 플러그인은 대부분의 디스커스 커뮤니티의 사용 사례와 전혀 관련이 없습니다. (이 플러그인들이 나쁘다는 뜻은 아닙니다! 필요한 커뮤니티에는 매우 유용할 것입니다. 다만, 모든 커뮤니티 포럼이 Zendesk 연동 등을 기본으로 포함해야 한다는 점을 이해하기 어렵습니다.) 특히 추가 요구 사항으로 인해 문제를 일으키고 있는 AI 플러그인은 제 생각에는 반드시 제거되어야 합니다.
개인적인 차원에서, 관리자 패널에 로그인했는데 갑자기 광고 플러그인 일색이 보이면, 코드가 비활성 상태여야 한다고 해도 매우 걱정됩니다. 가능한 한 강한 표현으로, 제 설치 환경에 빅테크 광고 플러그인이 기본으로 포함되어 있지 않기를, 비활성화 상태라도 원하지 않는다고 분명히 말씀드립니다. 광고 산업은 역사적으로 사용자 프라이버시 측면에서 매우 악용해 왔으며, 디스커스가 이러한 통합을 기본으로 포함하는 것은 스스로를 돕는 일이 아닙니다. 광고를 원하는 사람들은 필요한 플러그인을 찾는 데 아무런 어려움이 없으므로, 모든 설치에 이를 포함할 필요는 없습니다.
요약: 이 변경 사항을 재고해 주시기 바랍니다. ![]()
Discourse는 공식 호스팅에서 항상 제공되던 플러그인을 코어에 통합하고 있습니다
관리자 인터페이스에 불필요한 부피가 증가하고, 내 뇌에는 _광고_로 인식되는 수많은 브랜드 이름이 포함되는 데 동의합니다. 이건 별로 좋지 않아요. 대형 브랜드를 피하려는 자유 소프트웨어 옹호자로서, 이것은 몇 년 전 완전히 아마존, 구글 및 그 공범들에게 식민화되기 전의 우분투가 밟았던 발자취를 따르는 것이라 생각합니다. 그들을 눈앞에 들이대기만 하면, 결국 그들에게 삼켜질 거예요.
플러그인을 코어에 번들링하는 것은 개발자가 실수로 플러그인 기능을 시간이 지나면서 필수 요구 사항으로 전환할 수 있는 기회를 제공하지만, 플러그인으로 유지하는 것은 그런 실수를 방지할 수 있습니다.
@team 이 변경 사항의 근거를 명확히 설명해 주실 수 있을까요?
디스코urs 인프라에서 설치 속도를 높이는 것이 목적이라면, CI에서 자동으로 생성되는 discourse-hosting-bundle 패키지를 만드는 것으로도 동일한 결과를 달성할 수 있지 않을까요?
@david, 영향받는 플러그인 목록에서 알파벳 순서를 유지해 주시겠습니까?
여기서 의도는 Discourse를 처음 사용하는 사용자에게 더 매끄러운 경험을 제공하여, 처음부터 "완전한 기능"을 갖춘 Discourse 환경을 경험하게 하는 것입니다.
또 다른 의도는 저희 팀과 커뮤니티 기여자들의 개발 경험을 개선하는 것입니다. 이러한 모든 플러그인이 코어에 번들로 포함됨으로써, 서로 다른 코어 버전과의 호환성을 고려할 필요가 없어집니다. 이는 현재 관련 코어 변경 사항과 함께 매우 활발하게 개발되고 있는 discourse-ai와 같은 플러그인에서 특히 유용합니다.
브랜드가 있는 인증(Auth) 플러그인은 Google/Facebook과 같은 기존 코어 인증 방식처럼 코어에 흡수될 가능성이 가장 높습니다. 따라서 머지않아 목록에서 제거될 가능성이 큽니다.
이 변경 사항은 저희 호스팅 환경의 성능과는 무관합니다. 말씀하신 대로 이미 이러한 플러그인들을 모두 포함하고 더 많은 것이 들어간 사전 구축된 배포판이 이미 존재했기 때문입니다. ![]()
순서를 수정했습니다 ![]()
이미 원문에서 답변이 제시되었습니다:
그에 대한 몇 가지 예시:
- 플러그인을 위해 코어에 무언가를 추가할 때 버전 관리에 대해 걱정할 필요가 없습니다. 두 가지가 동일한 버전을 유지하고 있다는 것을 알기 때문입니다.
- 두 플러그인의 코드가 모두 존재할 경우, 다른 플러그인에 의존하는 플러그인을 테스트하는 것이 더 쉬워집니다.
- 코어에서 무언가를 변경할 때 플러그인의 스펙을 수정하기 위해 여러 개의 PR을 해야 하는 경우가 많았는데, 이제는 독립적인 PR 하나만 있으면 됩니다.
최종 결과는 이 같은 문제를 처리하는 대신 제품을 개선하고 유지보수하는 데 더 많은 시간을 할애할 수 있게 된다는 것입니다. 궁극적으로 여러분도 이로 인해 이득을 보게 됩니다.
저는 이러한 것들이 제 UI에서 사라지기를 매우 원합니다. 하지만 이들은 선택적이지도, 숨겨져 있지도 않아서 단순히 공간을 차지하고 있을 뿐입니다: 이들은 코어(core)의 일부이기 때문입니다. 바로 이것이 우리가 우려하는 이유입니다.
첫 사용자의 경험에 관해서는, 공식 번들(bundel)을 포함하고 문서화하도록 컨테이너 템플릿을 변경하는 것이 효과적일 수 있습니다:
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
# docker_manager 플러그인은 자동화된 웹 기반 업데이트에 필수적입니다
- git clone https://github.com/discourse/docker_manager.git
# 다음 플러그인은 모든 Discourse 호스팅 인스턴스에 설치됩니다.
# 활성화하려면 `- git clone` 줄 앞의 `#`을 제거해 주석을 해제하세요.
# https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/ 참조
# Discourse Advertising 플러그인 (Ads): https://meta.discourse.org/t/discourse-advertising-plugin-ads/33734
#- git clone https://github.com/discourse/discourse-adplugin
# Discourse Affiliate
#- git clone https://github.com/discourse/discourse-affiliate
# ...
# ...
# 다른 플러그인은 아래에 추가하세요. 공식 플러그인 목록은 다음을 참조하세요:
# https://meta.discourse.org/tag/official
# 사용 가능한 모든 플러그인은 다음을 참조하세요:
# https://meta.discourse.org/c/plugin/22
개발자 경험에 관해서는, 확실히 덜 침습적인 방식으로 플러그인 버전 전달을 자동화할 수 있을 것입니다. 예를 들어, 위 문서화 전략을 사용하여 플러그인의 주석을 해제하는 pups 규칙을 사용할 수 있습니다.
사용자를 대신해 이를 수행하는 컨테이너 템플릿을 가질 수도 있습니다:
templates:
- "templates/discourse.hosting.yml"
- "templates/discourse.core-bundle.yml"
제 첫인상은 좋았습니다: 아직 제 레이더에 없던 몇 가지 흥미로운 플러그인을 발견할 수 있었기 때문입니다. 하지만 네, 지난 10년간 최적화와 최소 공통 분모를 찾는 것에 집중해 오신 것을 보았기에, 이러한 제안을 이렇게 처리하실 줄은 몰랐습니다.
보통 git clone 명령이 있는 위치에 rm - rf discourse-ai를 추가할 수 있다고 생각합니다. 제가 직접 해본 적은 없습니다.
네, 기술적으로는 플러그인 디렉터리의 모든 폴더를 삭제해도 코어 Discourse는 계속 작동합니다.
디스코र्स 팀이 개발한 이러한 플러그인들은 규칙을 따르고 최소한의 오버헤드만 추가할 가능성이 높습니다. 모두 포함되어 있으면 이들이 함께 작동하고 동일한 요구 사항을 공유하는지 확인하기가 더 쉽습니다.
내장된 PostgreSQL이 아닌 외부 PostgreSQL을 실행 중인가요? 오랜 기간 업데이트되지 않은 2컨테이너 구성을 사용하고 있나요?
제거하도록 설정할 수는 있지만, 악의적인 회사에서 계정을 만들고 트래킹을 시작할 수 있는 키를 가져오지 않는 한 아무것도 할 수 없습니다.
답변 주셔서 감사합니다.
그랬으면 좋겠지만, 이 플러그인들을 사용하지 않는 커뮤니티(대부분의 커뮤니티가 해당될 것입니다)에게는 아무런 이점이 없으면서 버그와 공격의 표면적만 넓혀주는 셈입니다.
디스코urses가 여기서 실제 문제를 파악했지만 잘못된 해결책을 내놓았다고 느낍니다.
디스코urses 개발/플러그인 생태계의 취약성이라는 근본적인 문제가 실제로 존재한다는 점에는 전적으로 동의합니다. 움직이는 대상(moving target)에 맞춰 개발하는 것은 분명히 어렵고, 코어의 API 변경은 이를 더욱 힘들게 합니다. 일정한 정도까지 이는 엣지(bleeding edge) 업스트림에 맞춰 개발하는 것의 일부이지만, 바로 그렇기 때문에 이것이 기본 동작이어서는 안 됩니다. 제가 단순히 몇 가지 간단한 플러그인을 사용하는 입장에서, 여러분의 문제(제 문제보다 훨씬 큰 범위를 가지는)에 공감할 수 있습니다.
그러나 디스코urses가 여기서 하고 있는 것은 단순히 문제를 미루는 것에 불과합니다. 이는 디스코urses 자체의 문제는 해결할지 모르지만, 나머지 플러그인 개발자들의 문제는 해결하지 못합니다. 다른 모든 사람들도 동일한 고통을 겪고 있으며, 단지 규모가 작을 뿐입니다.
더 나은 해결책은 개발할 수 있는 더 견고한 LTS(장기 지원) 시리즈를 갖추는 것입니다. 이 부분은 다른 곳에서 이미 논의되었으므로 반복하지 않겠지만, 커뮤니티, 플러그인 개발자, 심지어 디스코urses 직원들조차 직면하는 가장 큰 도전 중 하나는 LTS가 없다는 점입니다. 안정판(stable branch) 사용은 적극적으로 비추천되고 있습니다. 더 전통적인 개발 파이프라인이 사용된다면 플러그인 개발이 훨씬 쉬워질 것입니다. 시스템이 깨지는 시점(메이저 버전 업그레이드)을 알고 계획을 세울 수 있으며, 그렇지 않은 경우에도 작은 업그레이드가 포럼을 무작정 깨뜨리지 않을 것이라는 확신을 가질 수 있습니다. (이는 제 생각에 디스코urses의 가장 큰 문제 중 하나이며, 포럼 옵션을 논의할 때 다른 곳에서 여러 번 언급된 바 있습니다. 이러한 변동성은 실제 단점입니다.)
네 – 링크에 언급된 대로, 이는 컨테이너 기반이 아닌 개발 환경에서 이 문제를 겪었습니다. (아직 프로덕션 컨테이너에서는 시도해 보지 않았습니다.)
제가 우려하는 것 중 하나는, ‘표준’ 경로가 이 플러그인들이 존재한다고 가정하는 경우입니다. 그러면 다른 모든 사람이 광고 플러그인을 허용하고 있기 때문에 버그에 직면할 수 있습니다. 예상치 못한 버그가 발생하는 위험을 감수하거나, 추가적인 플러그인 로드를 처리해야 합니다. 제 목표는 배포 환경에서 최대한의 안정성을 유지하는 것입니다.
또한 다른 포럼과 비교했을 때 디스코urses 코어조차도 리소스 사용량 측면에서 상당히 무겁다는 점을 지적할 가치가 있습니다. 성능 문제를 더 악화시키지 않도록 코어를 가볍게 유지하는 것이 중요하다고 생각합니다.
아직 비활성화 상태에서도 추적/폰홈(phone-home) JS를 가져오지 않는지 확인하기 위해 이를 감사(audit)하지는 않았지만, 그때까지 저는 말씀이 맞다고 가정하겠습니다. 누군가 이를 재확인해 주었으면 합니다. 만약 이것이 사실이 아니라면 큰 스캔들이 될 테니까요.
헬레킨(Hellekin)의 혼란(clutter)에 대한 지적은 타당하다고 생각하며, 또한 빅테크 광고 플러그인에 대해 그들이 시사하는 바가 오픈소스 커뮤니티의 일부(오픈소스 포럼을 처음부터 더 많이 사용할 가능성이 있는 유형)에게는 잘 받아들여지지 않을 것이라고 생각합니다.
어쨌든, 제 피드백을 들어주셔서 감사합니다. 비록 그것이 쉽지 않겠지만요 ![]()
어떤 문자열이 이전에 검수되었고 어떤 것은 그렇지 않았는지를 파악하기가 어렵다고 생각합니다.
Crowdin의 모든 데이터가 아니라 텍스트만 추가되었기 때문에, 이전에 존재했던 오픈된 코멘트가 이제 사라진 건 아닌지 미리 확인해 보셨는지 잠시 궁금해했습니다. 하지만 그 답을 알고 싶지도 않은 것 같습니다. 결국 몇 달 동안 아무도 반응하지 않는 것과 번역가들의 질문과 코멘트가 단순히 사라지는 것 사이에 큰 차이는 없으니까요.
새 번들에서 플러그인 디렉터리를 제거했을 때 부작용이 없는지, 그리고 플러그인이 의도치 않게 필수 요구 사항이 되지 않는지를 확인하는 테스트가 있나요?
우리의 핵심 테스트 스위트는 어떤 플러그인도 로드하지 않은 상태에서 실행되므로, 네이티브 코드에서 플러그인으로의 모든 의존성은 CI에 의해 감지되어야 합니다.
플러그인을 클론하는 줄들을 주석 처리했는데, 다시 "launcher rebuild app"을 실행해도 동일한 메시지가 나타납니다:
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 546 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
---
HINT: The plugin 'discourse-reactions' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-reactions' from your containers/app.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
---
HINT: The plugin 'discourse-data-explorer' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-data-explorer' from your containers/app.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
---
HINT: The plugin 'discourse-solved' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-solved' from your containers/app.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
실패 원인은 FAILED 줄 위에 있습니다.