Yikes d/cleanup è pericoloso. È un buon modo per perdere molto lavoro di Docker non correlato affatto a Discourse…
Ho iniziato a fare alcuni hack manuali come i seguenti che funzionavano, ma continuavano a esserci sempre più problemi di permessi, quindi ho deciso di smettere di cercare di spegnere incendi.
mkdir app/assets/javascripts/plugins
mkdir tmp
sudo chown 1000:1000 tmp
sudo chown 1000:1000 app/assets/javascripts/plugins
Userò l’utente host con un uid di 1000 e scommetto che ora funzionerà, ma questo espone davvero una lacuna in come viene fatto lo sviluppo di Discourse, a quanto pare.
…e sì, ha funzionato.
Nel caso di quel “tmp” potrebbe trovarsi in un volume Docker nominato o anonimo. Con i plugin, potrebbe essere utile avere quel volume montato, ma i permessi del file system host dovrebbero essere modificati per supportare le scritture.
Non credo sia sicuro presumere che ogni sviluppatore utilizzerà un uid di 1000.
3 Mi Piace
Ciao ragazzi, sapete come eseguire lo sviluppo utilizzando una vecchia versione di Discourse? So che in Discourse live possiamo impostare la versione in app.yml. Ma non so come farlo in sviluppo usando Docker. Voglio eseguire lo sviluppo sull’ultima versione stabile v2.7.10. Grazie per il vostro aiuto.
Controlla quel branch o commit in git. (Il modo in cui lo faccio è cercare su Google
Dovrai eliminare, creare ed eseguire la migrazione del database dopo il downgrade.
Ciao grazie @pfaffman,
Ho fatto un git pull pulito di discourse e ho effettuato il checkout della versione “stable”. (che utilizza il tag della versione discourse v2.7.10)
Ho eseguito dev init e impostato l’email e la password dell’utente amministratore
d/boot_dev --init
e ho eseguito rails server che ascolterà sulla porta 3000
d/rails s
quindi ho eseguito ember-cli
cd app/assets/javascripts/discourse
yarn
yarn run ember serve --proxy "http://localhost:3000"
il discourse di sviluppo può essere aperto su “http://localhost:4200”
tuttavia ho riscontrato un problema durante l’accesso come utente amministratore (quello che ho creato durante l’esecuzione di “d/boot_dev --init”)
“Errore sconosciuto” appare sullo schermo, con il seguente errore su /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'
Hai qualche esperienza con quell’errore? o forse i miei passaggi per eseguire lo sviluppo su una versione precedente erano sbagliati?
Penso che tu debba rm -r il database. Non sono sicuro di dove si trovi, ma è probabile che sia nell’OP.
1 Mi Piace
Ciao a tutti,
Sono ripartito da zero. Tutto va bene, ottengo un ambiente di sviluppo incontaminato in cui posso accedere.
Poi aggiungo un paio di plugin per eguagliare il mio ambiente di produzione e scarico il backup più recente.
Lo carico, provo a ripristinarlo nell’ambiente di sviluppo e ricevo di nuovo l’errore di autenticazione Peer. Ho segnalato un bug, ma finora non c’è stata risposta. Qualcuno può provare a riprodurre il problema? Ho visto problemi simili più avanti nei commenti di questo post, quindi immagino di non essere l’unico in questa situazione?
[2021-11-29 19:43:39] 'koen' has started the restore!
[2021-11-29 19:43:39] Marking restore as running...
[2021-11-29 19:43:39] Making sure /src/tmp/restores/default/2021-11-29-194339 exists...
[2021-11-29 19:43:39] Copying archive to tmp directory...
[2021-11-29 19:43:39] Extracting dump file...
[2021-11-29 19:43:40] Validating metadata...
[2021-11-29 19:43:40] Current version: 20211124161346
[2021-11-29 19:43:40] Restored version: 20211123033311
[2021-11-29 19:43:40] Enabling readonly mode...
[2021-11-29 19:43:40] Pausing sidekiq...
[2021-11-29 19:43:40] Waiting up to 60 seconds for Sidekiq to finish running jobs...
[2021-11-29 19:43:46] Creating missing functions in the discourse_functions schema...
[2021-11-29 19:43:46] Restoring dump file... (this may take a while)
[2021-11-29 19:43:47] psql: error: connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: FATAL: Peer authentication failed for user \"postgres\"
[2021-11-29 19:43:47] EXCEPTION: psql failed: psql: error: connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: FATAL: Peer authentication failed for user \"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] Trying to rollback...
[2021-11-29 19:43:47] There was no need to rollback
[2021-11-29 19:43:47] Cleaning stuff up...
[2021-11-29 19:43:47] Dropping functions from the discourse_functions schema...
[2021-11-29 19:43:47] Removing tmp '/src/tmp/restores/default/2021-11-29-194339' directory...
[2021-11-29 19:43:47] Unpausing sidekiq...
[2021-11-29 19:43:47] Marking restore as finished...
[2021-11-29 19:43:47] Notifying 'koen' of the end of the restore...
[2021-11-29 19:43:51] Finished!
Ciao,
Ho un problema che sembra derivare dalla scissione tra le porte 3000 e 4200. Non sono del tutto sicuro di come si relazionino tra loro, ma la mia comprensione è che 3000 sia il server e 4200 un proxy ad esso dalla CLI di Ember. La porta 4200 funziona bene, tranne per il fatto che a volte, e specificamente quando si risponde con un 302, gli header di risposta hanno URI che utilizzano la porta 3000 invece della 4200. Stavo specificamente cercando di far funzionare OAuth2 con un provider personalizzato come descritto qui, e la presenza della porta 3000 in alcune delle risposte interrompe il flusso di lavoro di OAuth2. Non c’è nessuna porta 3000 in nessuna delle mie configurazioni OAuth2, deve provenire internamente dal server.
Qualcuno ha riscontrato questo tipo di problema prima? Sapete come impostare un ambiente che imiti più da vicino il rilascio di produzione?
Per quello che vale, ho anche provato a configurare il rilascio di produzione localmente, ma ciò richiede la registrazione di un dominio e di un’email a tutti gli effetti e non sembra molto amichevole per gli ambienti locali.
Grazie.
1 Mi Piace
Aggiornamento, ho riprovato a percorrere la strada della “tabula rasa” e questa volta utilizzando un’altra macchina. Ora mi blocco perché non ho l’UID 1000 che è stato menzionato più sopra in questo thread, post 100 da @dcook. Concorderei sul fatto che presumere UID=1000 sia sbagliato e costituirebbe un bug. L’hai segnalato come tale?
Sulla mia macchina principale persiste il bug dei permessi dell’utente Postgress che ho sollevato qui: Backup restore failing on clean dev docker env: FATAL: Peer authentication failed for user “postgres”.
@rishabh qual è la tua opinione su entrambi questi punti? Mi è piaciuto passare al metodo basato su docker, veloce e pulito. Ma ora su due macchine diverse sembra un po’ un vicolo cieco e mi chiedo cos’altro posso fare per contribuire a risolverlo. Mi chiedo anche un po’ sul ciclo di vita dei bug. Vengono ricevuti, revisionati, rifiutati o accettati, messi da parte, risolti, ecc.?
Per ora andrò a provare a configurare l’ambiente di sviluppo nativo per vedere se riesco a farlo funzionare.
2 Mi Piace
Ciao. È la prima volta che installo Discourse usando Docker su Mac.
Prima mi scuso per il mio inglese 
Ho già eseguito
d/boot_dev --init
Poi ho ricevuto un errore che la porta:3000 è già in uso. Quindi ho cambiato la porta 30030:3000 (file: bin/docker/boot_dev)
Dopo di che, ho avviato questo codice
d/boot_dev --init
# In un terminale:
d/rails s
# E in un terminale separato
d/ember-cli
Le mie domande sono:
-
Quando eseguo il codice
d/rails s, posso aprire la pagina di avvio di Discourse su ‘localhost:30030’. Se voglio solo aprire Discourse e usare la porta 30030 (port forwarding), allora posso completare il processo di installazione?? Non so cosa sianod/rails s,d/ember-cli. … -
E il processo
d/rail sè così lungo. Sono preoccupato di cosa c’è di sbagliato.. è giusto? od/rails sed/ember-clisono processi in background mentre ospitano Discourse?
Grazie. 
Ciao,
Nell’ambiente di sviluppo, è possibile modificare le impostazioni di configurazione che dovrebbero essere inserite in app.yml?
La domanda riguarda principalmente la modifica di DISCOURSE_ENABLE_CORS; la semplice aggiunta di origini cors nell’interfaccia di amministrazione non ha aiutato a risolvere l’errore cors.
Grazie.
Sembra che la creazione di un file discourse.conf sotto /config abbia risolto il problema:
enable_cors = true
Informazioni tratte dal file di configurazione predefinito: discourse/config/discourse_defaults.conf at main · discourse/discourse · GitHub
2 Mi Piace
Ciao ragazzi, ho riscontrato un problema durante l’inizializzazione dello sviluppo di discourse con docker.
La mia discourse di produzione utilizza la versione tag v2.8.0, quindi ho bisogno di eseguire lo sviluppo locale utilizzando la v2.8.0.
Utilizzo docker in esecuzione su Mac OS per la mia configurazione di sviluppo.
Quello che ho fatto da riga di comando è:
git clone https://github.com/discourse/discourse.git
cd discourse
git checkout v2.8.0
d/boot_dev --init
Ho ottenuto questo errore dopo che il codice di inizializzazione ha raggiunto la sezione di migrazione del database:
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>'
2 mesi fa ho eseguito lo sviluppo utilizzando la versione 2.8.0 e non ho avuto problemi, ma qualche giorno fa ho iniziato ad avere questo problema.
Avete lo stesso problema?
Se hai migrato il database con una versione successiva di Discourse, dovrai eliminare e creare un nuovo database per ottenere la migrazione precedente.
1 Mi Piace
Ho clonato da zero e inizializzato lo sviluppo utilizzando la versione 2.8.0. Non dovrebbero esserci ancora dati.
1 Mi Piace
Ho commesso un errore durante l’installazione, c’è un modo possibile per disinstallare tutto e poi ricominciare da capo?
Ciao, ho trovato questo errore strano. Qualcuno ha esperienza nella risoluzione di questo problema? Grazie in anticipo!
Si presenta quando stavo eseguendo 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)
1 Mi Piace
Ho ricevuto lo stesso messaggio di errore durante l’esecuzione di d/boot_dev --init, ho provato d/rake db:migrate RAILS_ENV=development, stesso errore di nuovo:
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)
Ho riscontrato anch’io questo problema. L’ho risolto ripristinando questo commit:
2 Mi Piace
Funziona perfettamente per me. Grazie.