Migrazione di Discourse da una droplet DigitalOcean a un'altra senza interruzioni

Stiamo migrando a un nuovo droplet DigitalOcean e abbiamo provato a utilizzare l’immagine del marketplace. Durante l’esecuzione dello script di configurazione, il processo si interrompe prematuramente perché il nostro nome di dominio punta ancora all’istanza corrente in produzione.

Devo mettere in funzione questa nuova installazione per poter ripristinarne il backup e, successivamente, aggiornare le record DNS.

L’errore è il seguente:

Verifica del nome di dominio . . .
ATTENZIONE: La porta 443 del computer non sembra essere accessibile tramite il nome host:  x
ATTENZIONE: Anche la connessione a x (porta 80) fallisce.

Ciò suggerisce che x risolve a un indirizzo IP che non raggiunge questa
macchina su cui state installando Discourse.

La prima cosa da fare è verificare che x risolva all'indirizzo IP di questo server.
Di solito si fa questo nello stesso luogo in cui è stato acquistato il dominio.

Se siete certi che l'indirizzo IP risolva correttamente, potrebbe trattarsi di un problema di firewall.
Una ricerca sul web per "apri porte IL TUO SERVIZIO CLOUD" potrebbe essere d'aiuto.

Il nome di dominio risponde effettivamente sulle porte 80 e 443, quindi anche questo messaggio di errore sembra errato.

Ciao Matt,

Noi (il team di Discourse) non gestiamo l’immagine del marketplace di DO, quindi temo che possiamo essere di aiuto limitato per risolvere quel problema specifico.

Ma gestisci questo, vero?

Anche le istruzioni di installazione manuale includono questo passaggio.

Di sicuro non posso essere la prima persona a farlo. Come fanno gli altri?

Sì, gestiamo questo. Non ho esaminato il codice; ho dato per scontato che il controllo provenisse dall’immagine del marketplace.

./discourse-setup è pensato come un modo semplice per configurare Discourse, evitando la necessità di modificare manualmente un file di testo quando si avvia un nuovo sito Discourse. Il tuo caso d’uso non è “tipico” e non è gestito dallo script di configurazione.

Nel tuo caso, la soluzione migliore sarebbe probabilmente copiare il file containers/app.yml dal tuo server attuale a quello nuovo. In alternativa, puoi modificare manualmente il file tu stesso, come suggerito alle righe 75/76:

1 Mi Piace

Dove posso trovare il file app.yml predefinito? Voglio iniziare con una nuova installazione predefinita.

Inoltre, come posso avviare il server senza lo script di configurazione? L’accesso all’indirizzo IP rimane non responsivo poiché non riesco ad eseguire lo script di configurazione.

Il file predefinito si trova in samples/standalone.yml. Disponibile anche su GitHub.

Se stai seguendo la guida ufficiale di installazione, dopo aver eseguito i comandi in “Installa Discourse”, dovrai procedere come segue:

Copia il file YAML predefinito da samples a containers:

cp samples/standalone.yml containers/app.yml

Modifica il file manualmente:

nano containers/app.yml

Avvia il bootstrap e avvia Discourse:

./launcher rebuild app

Grazie, questo mi avvicina alla soluzione.

Ma ora non riesco a importare il backup perché non posso attivare il mio account amministratore temporaneo:

(6) Il caricamento dello script ‘’ è stato rifiutato perché viola la seguente direttiva Content Security Policy: “script-src ”. Si noti che ‘script-src-elem’ non è stato impostato esplicitamente, quindi viene utilizzato ‘script-src’ come fallback.

Esiste un modo diretto per ripristinare da un backup o disabilitare il CSP fino ad allora?

Connettiti via SSH al tuo server, poi:

cd /var/discourse
sudo ./launcher enter app
rails c
SiteSetting.content_security_policy = false
exit
exit

Nota che ti consiglio di provare prima il ripristino del backup da riga di comando: risolve il problema reale che hai (ripristinare un backup) rispetto all’ostacolo attuale (CSP).

1 Mi Piace

Grazie per i suggerimenti.

Durante l’esecuzione del restore, ottengo:

ERROR:  could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
DETAIL:  Key (path, incoming_domain_id)=(/s/free+proxy+hideip.me, 1009) is duplicated.
EXCEPTION: psql failed: DETAIL:  Key (path, incoming_domain_id)=(/s/free+proxy+hideip.me, 1009) is duplicated.
/var/www/discourse/lib/backup_restore/database_restorer.rb:87:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:497:in `exec'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:37:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tentativo di rollback...
Rollback in corso...
Pulizia dei file...
Rimozione delle funzioni dallo schema discourse_functions...
Rimozione della directory tmp '/var/www/discourse/tmp/restores/default/2020-12-29-214249'...
Riattivazione di sidekiq...
Segnalazione del completamento del restore...
Notifica al 'system' della fine del restore...
Completato!
[FAILED]
Restore terminato.

Sembra che tu abbia un indice danneggiato. Hai eseguito un aggiornamento sull’istanza esistente? C’è la possibilità che questo possa aiutare.

C’è un argomento da qualche parte con le istruzioni per copiare i file del database grezzo (e di Let’s Encrypt) dalla vecchia istanza. Probabilmente è quello che farei.

1 Mi Piace

Cos’è “rub run”?

Gli aggiornamenti sull’istanza esistente continuano a generare errori (diversi da questo), ecco perché sto passando a una nuova istanza.

Hai un link a questo?

Trasferimento dei backup tramite rsync e cron forse

1 Mi Piace