Yikes d/cleanup es peligroso. Esa es una buena manera de perder mucho trabajo de Docker que no tiene nada que ver con Discourse…
Empecé a hacer algunos hacks manuales como los siguientes que funcionaban, pero cada vez había más y más problemas de permisos, así que decidí dejar de intentar apagar incendios.
mkdir app/assets/javascripts/plugins
mkdir tmp
sudo chown 1000:1000 tmp
sudo chown 1000:1000 app/assets/javascripts/plugins
Voy a usar el usuario host con un uid de 1000 y apuesto a que ahora simplemente funcionará, pero esto realmente expone una deficiencia en cómo se realiza el desarrollo de Discourse, parece.
…y sí, eso solucionó el problema.
En el caso de ese “tmp”, podría estar en un volumen de Docker con nombre o anónimo. Con los plugins, podría ser útil tener ese volumen montado, pero los permisos del sistema de archivos host tendrían que modificarse para admitir escrituras.
No creo que sea seguro asumir que todos los desarrolladores usarán un uid de 1000.
Hola chicos, ¿saben cómo ejecutar el desarrollo usando la versión antigua de Discourse? Sé que en Discourse en producción podemos establecer la versión en app.yml. Pero no sé cómo hacerlo en desarrollo usando Docker. Quiero ejecutar el desarrollo en la última versión estable v2.7.10. Gracias por su ayuda.
Simplemente haz checkout de esa rama o commit en git. (La forma en que lo hago es buscar en Google
Necesitarás eliminar, crear y migrar la base de datos después de degradarla.
Hola, gracias @pfaffman,
Hice un git pull fresco de Discourse y cambié a la rama de versión “stable”. (que usa la etiqueta de Discourse v2.7.10)
Ejecuté dev init y establecí el correo electrónico y la contraseña del usuario administrador
d/boot_dev --init
y ejecuté rails server, escuchará en el puerto 3000
d/rails s
luego ejecuté ember-cli
cd app/assets/javascripts/discourse
yarn
yarn run ember serve --proxy "http://localhost:3000"
El desarrollo de Discourse se puede abrir en “http://localhost:4200”
Sin embargo, tengo un problema al iniciar sesión como usuario administrador (el que creé al ejecutar “d/boot_dev --init”)
Aparece un mensaje de “Error desconocido” en la pantalla, con el siguiente error en /logs
ActiveRecord::StatementInvalid (PG::UndefinedFunction: ERROR: function max(boolean) does not exist
LINE 1: ..._rank, MAX(user_badges.created_at) AS created_at, MAX(user_b...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
)
lib/freedom_patches/ams_include_without_root.rb:49:in `include!'
app/controllers/application_controller.rb:495:in `serialize_data'
app/controllers/application_controller.rb:504:in `render_serialized'
app/controllers/session_controller.rb:611:in `login'
app/controllers/session_controller.rb:337:in `create'
app/controllers/application_controller.rb:395:in `block in with_resolved_locale'
app/controllers/application_controller.rb:395:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:71:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/missing_avatars.rb:23:in `call'
lib/middleware/turbo_dev.rb:34:in `call'
¿Tienes alguna experiencia con ese error? ¿O tal vez mi paso para ejecutar el desarrollo en la versión anterior fue incorrecto?
Creo que necesitas rm -r la base de datos. No estoy seguro de dónde está, pero probablemente esté en el OP.
Hola a todos,
Volví a empezar de cero. Todo va bien, obtengo un entorno de desarrollo impecable al que puedo acceder.
Luego, instalo un par de plugins para que coincidan con mi entorno de producción y descargo la copia de seguridad más reciente.
La subo, intento restaurarla en el entorno de desarrollo y vuelvo a recibir el error de autenticación Peer. He presentado un error, pero hasta ahora no hay respuesta. ¿Alguien puede intentar reproducirlo? He visto problemas similares más arriba en los comentarios de esta publicación, así que supongo que no soy el único en esto.
[2021-11-29 19:43:39] 'koen' ha iniciado la restauración!
[2021-11-29 19:43:39] Marcando la restauración como en curso...
[2021-11-29 19:43:39] Asegurándose de que /src/tmp/restores/default/2021-11-29-194339 existe...
[2021-11-29 19:43:39] Copiando el archivo de copia de seguridad al directorio tmp...
[2021-11-29 19:43:39] Extrayendo el archivo de volcado...
[2021-11-29 19:43:40] Validando metadatos...
[2021-11-29 19:43:40] Versión actual: 20211124161346
[2021-11-29 19:43:40] Versión restaurada: 20211123033311
[2021-11-29 19:43:40] Habilitando el modo de solo lectura...
[2021-11-29 19:43:40] Pausando sidekiq...
[2021-11-29 19:43:40] Esperando hasta 60 segundos para que Sidekiq termine de ejecutar trabajos...
[2021-11-29 19:43:46] Creando funciones faltantes en el esquema discourse_functions...
[2021-11-29 19:43:46] Restaurando el archivo de volcado... (esto puede tardar un tiempo)
[2021-11-29 19:43:47] psql: error: la conexión al servidor en el socket \"/var/run/postgresql/.s.PGSQL.5432\" falló: FATAL: La autenticación Peer falló para el usuario \"postgres\"
[2021-11-29 19:43:47] EXCEPCIÓN: psql falló: psql: error: la conexión al servidor en el socket \"/var/run/postgresql/.s.PGSQL.5432\" falló: FATAL: La autenticación Peer falló para el usuario \"postgres\"
[2021-11-29 19:43:47] /src/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/src/lib/backup_restore/database_restorer.rb:26:in `restore'
/src/lib/backup_restore/restorer.rb:51:in `run'
/src/script/spawn_backup_restore.rb:23:in `restore'
/src/script/spawn_backup_restore.rb:36:in `block in <main>'
/src/script/spawn_backup_restore.rb:4:in `fork'
/src/script/spawn_backup_restore.rb:4:in `<main>'
[2021-11-29 19:43:47] Intentando revertir...
[2021-11-29 19:43:47] No fue necesario revertir
[2021-11-29 19:43:47] Limpiando...
[2021-11-29 19:43:47] Eliminando funciones del esquema discourse_functions...
[2021-11-29 19:43:47] Eliminando el directorio tmp '/src/tmp/restores/default/2021-11-29-194339'...
[2021-11-29 19:43:47] Reanudando sidekiq...
[2021-11-29 19:43:47] Marcando la restauración como finalizada...
[2021-11-29 19:43:47] Notificando a 'koen' el fin de la restauración...
[2021-11-29 19:43:51] ¡Finalizado!
Hola,
Tengo un problema que parece derivar de la división entre los puertos 3000 y 4200. No estoy completamente seguro de cómo se relacionan entre sí, pero entiendo que 3000 es el servidor y 4200 un proxy hacia él desde el CLI de Ember. El puerto 4200 funciona bien, excepto que a veces, y específicamente al responder con un 302, las cabeceras de respuesta tienen URIs que usan el puerto 3000 en lugar del 4200. Estaba intentando específicamente que OAuth2 funcionara con un proveedor personalizado como se describe aquí, y la presencia del puerto 3000 en algunas de las respuestas rompe el flujo de trabajo de OAuth2. No hay ningún puerto 3000 en ninguna de mis configuraciones de OAuth2, debe provenir internamente del servidor.
¿Alguien ha encontrado este tipo de problema antes? ¿Saben cómo configurar un entorno que imite más de cerca la versión de producción?
Por si sirve de algo, también intenté configurar la versión de producción localmente, pero eso requiere un registro completo de dominio y correo electrónico y no parece muy amigable para entornos locales.
Gracias.
Actualización, volví a intentar tomar la ruta de borrón y cuenta nueva y esta vez usando otra máquina. Ahora me quedo atascado porque no tengo el UID 1000 que se mencionó más arriba en este hilo, publicación 100 de @dcook. Estaría de acuerdo en que asumir que UID=1000 es incorrecto y constituiría un error. ¿Lo informaste como tal?
En mi máquina principal persiste el error de permisos del usuario de Postgress que planteé aquí: Backup restore failing on clean dev docker env: FATAL: Peer authentication failed for user “postgres”.
@rishabh, ¿cuál es tu opinión sobre ambos puntos? Me encantó cambiar al método basado en docker, rápido y limpio. Pero ahora en dos máquinas diferentes se siente un poco como un camino sin salida y me pregunto qué más puedo aportar para que se resuelva. También me pregunto un poco sobre el ciclo de vida de los errores. ¿Se reciben, revisan, rechazan o aceptan, aparcan, resuelven, etc.?
Por ahora, iré a intentar configurar el entorno de desarrollo nativo y ver si puedo hacerlo funcionar.
Hola. Es la primera vez que instalo Discourse usando Docker en Mac.
Primero, lamento mi inglés… ![]()
Ya he ejecutado
d/boot_dev --init
Luego obtuve un error de que el puerto: 3000 ya estaba en uso. Así que cambié el puerto 30030: 3000 (archivo: bin/docker/boot_dev)
Después de eso, inicié este código
d/boot_dev --init
# En una terminal:
d/rails s
# Y en una terminal separada
d/ember-cli
Mis preguntas son:
-
Cuando ejecuto el código
d/rails s, puedo abrir la página de inicio de Discourse en ‘localhost: 30030’. Si solo quiero abrir Discourse y usar el puerto 30030 (reenvío de puertos), ¿puedo finalizar el proceso de instalación? No sé qué sond/rails s,d/ember-cli. … -
Y el proceso
d/rail ses muy largo. Me preocupa qué está mal… ¿es correcto? ¿Od/rails syd/ember-clison procesos en segundo plano mientras alojan Discourse?
Gracias. ![]()
Hola,
En el entorno de desarrollo, ¿es posible editar la configuración que debería estar en app.yml?
La pregunta trata principalmente sobre la edición de DISCOURSE_ENABLE_CORS; simplemente agregar orígenes CORS en la interfaz de administración no ayudó a resolver el error CORS.
Gracias.
Parece que la creación de un archivo discourse.conf en /config resolvió el problema:
enable_cors = true
Información tomada del archivo de configuración predeterminado: discourse/config/discourse_defaults.conf at main · discourse/discourse · GitHub
Hola chicos, tengo un problema al iniciar el desarrollo de Discourse con Docker.
Mi Discourse de producción usa la versión de etiqueta v2.8.0. así que necesito ejecutar el desarrollo local usando v2.8.0.
Uso Docker que se ejecuta en Mac OS para mi configuración de desarrollo.
lo que hice en el comando es
git clone https://github.com/discourse/discourse.git
cd discourse
git checkout v2.8.0
d/boot_dev --init
Tengo este error después de que el código de inicialización llega a la sección de migración de la base de datos.
Migrating database...
== 20220104053343 AddBookmarkPolymorphicColumns: migrating ====================
-- add_column(:bookmarks, :bookmarkable_id, :integer)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::DuplicateColumn: ERROR: column "bookmarkable_id" of relation "bookmarks" already exists
/src/lib/migration/safe_migrate.rb:92:in `async_exec'
/src/db/migrate/20220104053343_add_bookmark_polymorphic_columns.rb:5:in `change'
/src/lib/freedom_patches/schema_migration_details.rb:9:in `block in exec_migration'
/src/lib/freedom_patches/schema_migration_details.rb:8:in `exec_migration'
/src/lib/migration/safe_migrate.rb:28:in `migrate'
/src/lib/migration/safe_migrate.rb:55:in `migrate'
/src/lib/tasks/db.rake:218:in `block (2 levels) in <main>'
/src/lib/distributed_mutex.rb:33:in `block in synchronize'
/src/lib/distributed_mutex.rb:29:in `synchronize'
/src/lib/distributed_mutex.rb:29:in `synchronize'
/src/lib/distributed_mutex.rb:14:in `synchronize'
/src/lib/tasks/db.rake:210:in `block in <main>'
Caused by:
ActiveRecord::StatementInvalid: PG::DuplicateColumn: ERROR: column "bookmarkable_id" of relation "bookmarks" already exists
/src/lib/migration/safe_migrate.rb:92:in `async_exec'
/src/db/migrate/20220104053343_add_bookmark_polymorphic_columns.rb:5:in `change'
/src/lib/freedom_patches/schema_migration_details.rb:9:in `block in exec_migration'
/src/lib/freedom_patches/schema_migration_details.rb:8:in `exec_migration'
/src/lib/migration/safe_migrate.rb:28:in `migrate'
/src/lib/migration/safe_migrate.rb:55:in `migrate'
/src/lib/tasks/db.rake:218:in `block (2 levels) in <main>'
/src/lib/distributed_mutex.rb:33:in `block in synchronize'
/src/lib/distributed_mutex.rb:29:in `synchronize'
/src/lib/distributed_mutex.rb:29:in `synchronize'
/src/lib/distributed_mutex.rb:14:in `synchronize'
/src/lib/tasks/db.rake:210:in `block in <main>'
Hace 2 meses ejecuté el desarrollo usando la versión 2.8.0 y no tuve problemas, pero hace un par de días empecé a tener este problema.
¿Chicos, tienen el mismo problema?
Si migraste la base de datos con una versión posterior de Discourse, deberás eliminar y crear una nueva base de datos para obtener la migración anterior.
Hice una nueva clonación limpia e inicié el desarrollo con la versión 2.8.0. Aún no debería haber datos.
Met un erroro durante la instalación, ¿hay alguna forma de desinstalar todo y volver a empezar?
Hola, encontré este error extraño. ¿Alguien tiene experiencia resolviendo este problema? ¡Gracias de antemano!
Aparece cuando estaba ejecutando d/boot_dev --init.
Migrating database...
rake aborted!
LoadError: cannot load such file -- /usr/local/lib/ruby/gems/2.7.0/gems/mail-2.8.0.rc1/lib/mail/indifferent_hash.rb
/src/lib/email.rb:3:in `<main>'
/src/app/jobs/scheduled/poll_mailbox.rb:10:in `<class:PollMailbox>'
/src/app/jobs/scheduled/poll_mailbox.rb:6:in `<module:Jobs>'
/src/app/jobs/scheduled/poll_mailbox.rb:5:in `<main>'
/src/config/initializers/100-sidekiq.rb:74:in `block (2 levels) in <main>'
/src/config/initializers/100-sidekiq.rb:73:in `glob'
/src/config/initializers/100-sidekiq.rb:73:in `block in <main>'
/src/config/environment.rb:7:in `<main>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
He recibido el mismo mensaje de error al ejecutar d/boot_dev --init, intenté d/rake db:migrate RAILS_ENV=development, y el mismo error de nuevo:
rake aborted!
LoadError: cannot load such file -- /usr/local/lib/ruby/gems/2.7.0/gems/mail-2.8.0.rc1/lib/mail/indifferent_hash.rb
/src/lib/email.rb:3:in `<main>'
/src/app/jobs/scheduled/poll_mailbox.rb:10:in `<class:PollMailbox>'
/src/app/jobs/scheduled/poll_mailbox.rb:6:in `<module:Jobs>'
/src/app/jobs/scheduled/poll_mailbox.rb:5:in `<main>'
/src/config/initializers/100-sidekiq.rb:74:in `block (2 levels) in <main>'
/src/config/initializers/100-sidekiq.rb:73:in `glob'
/src/config/initializers/100-sidekiq.rb:73:in `block in <main>'
/src/config/environment.rb:7:in `<main>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
Yo también me encontré con este problema. Y lo solucioné revirtiendo este commit
Funciona perfectamente para mí. Gracias.