Ho cambiato il nome perché non posso spegnere il server originale per ore, finché non avrò verificato che tutto funzioni correttamente e non avrò scambiato i server.
Non è necessario. Se disponi di un certificato wildcard, puoi semplicemente apportare modifiche DNS locali tramite il file Hosts per configurare tutto e ripristinare il backup stesso.
Successivamente, basta attivare il DNS pubblicamente.
Non capisco cosa intendi.
Devo tenere a.domain.com attivo mentre eseguo i test.
E ho bisogno di accedere all’interfaccia di Discourse della copia che sto ripristinando per verificare che tutto sia a posto.
Quindi mi serve un altro URL per accedere alla copia, sull’altro server.
Quindi semplicemente cambio il nome host in Discourse e in Nginx dopo il ripristino.
Quando tutto è a posto, cambio il nome nel nuovo server in a.domain.com, spengo il vecchio server e punto il DNS di a.domain.com al nuovo server.
Quanto sopra non è corretto. Puoi forzare il tuo computer locale a connettersi al nuovo server utilizzando lo stesso nome DNS, modificando il file HOSTS sul tuo computer locale o inserendo manualmente una voce nel tuo DNS locale.
Non ho un computer locale.
Entrambi i server sono su Internet, ovvero server cloud.
Uso ssh da una macchina Windows.
Forse potrei prendere l’hostname locale per impostare l’indirizzo IP della macchina, ma è più complesso che cambiare il nome sui server.
Pensi che una modifica all’hostname possa essere il problema?
Non dovrebbe essere un problema…
Sì, abbiamo ricominciato a vedere questo problema con gli avatar personalizzati molto tempo dopo che il processo sidekiq aveva avuto il tempo di ricostruire qualsiasi immagine ausiliaria di avatar e profilo, ma solo nella configurazione con nginx come reverse proxy verso un socket Unix.
Le piccole icone degli avatar sono corrette; tuttavia, non funzionano nella scheda del profilo o nelle pagine del profilo (a meno che non fossero già state memorizzate nella cache prima e la cache non sia ancora scaduta).
Non appena eseguiamo:
nginx -s stop; ./launcher start web-only
Il problema con le immagini degli avatar personalizzati scompare (per le immagini non visualizzate precedentemente / memorizzate nella cache del browser).
E subito dopo aver eseguito:
./launcher stop web-only; nginx
Il problema con le immagini degli avatar personalizzati ricompare per le immagini non ancora visualizzate / memorizzate nella cache.
Non ci sono errori relativi a HTTPS e questo non è assolutamente dovuto a force_https (completamente irrilevante):
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
Abbiamo confermato questo problema su mobile (iOS, versione più recente), su desktop, su Chrome (versione più recente), su Safari (versione più recente), ecc.
C’è qualcosa di strano che si verifica quando si utilizza nginx come reverse proxy verso un socket Unix, il quale influisce sulle immagini degli avatar personalizzati.
Finora, scusa per l’informazione @ariznaf, non siamo riusciti a isolare il problema e non abbiamo una soluzione.
“Sembra” che nella configurazione nginx reverse proxy verso un socket Unix, l’applicazione discourse (il contenitore) non stia ricostruendo queste immagini degli avatar personalizzati come fa nella configurazione senza nginx come reverse proxy verso un socket di dominio Unix.
Forse sidekiq non gradisce la configurazione nginx reverse proxy verso socket Unix e si rifiuta di pianificare o eseguire questo processo di ricostruzione, LOL? @riking?
Strano.
Ecco un aggiornamento:
Nella configurazione del reverse proxy che utilizza socket Unix di cui stiamo discutendo:
Tuttavia, quando verifichiamo force_https:
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
E naturalmente, come previsto, non ci sono errori nel certificato del browser (Chrome è soddisfatto):
Quindi, la mia ipotesi non esperta è che in questa configurazione l’impostazione/metodo force_http manchi di queste immagini; poiché tutto il resto è impeccabile, tranne queste avatar personalizzate (e l’immagine della pagina del profilo).
Questa è la mia ipotesi al di sopra della mia competenza con Discourse.
Aggiornamento:
Dopo ulteriori ricerche, risulta che tutte le nostre configurazioni di nginx reverse proxy verso socket Unix mancavano della maggior parte dei file in /shared/uploads. Questo passaggio mancava nei vari tutorial e documenti howto consultati su questo argomento, quindi la prossima volta che vedrò una wiki su questo tema su Meta, aggiornerò il tutorial/wiki/howto per includere questo passaggio.
L’unica piccola complicazione rimasta è un problema con il favicon:
Se qualcuno ha un metodo consigliato per risolvere questo problema, sarebbe ottimo. Grazie!
Ricaricalo di nuovo. È la soluzione più rapida.
Le persone dimenticano, quando usano un socket, di aver disabilitato il template HTTPS, quindi Discourse non sa di essere dietro SSL a meno che force_https non venga abilitato manualmente, da qui il mio suggerimento di ieri.
Una volta abilitato force_https, puoi ricaricare le risorse per correggere i loro percorsi.
Non ho risposto a nulla di tutto ciò perché ho presunto che qualche trasferimento di dati del server andato storto (non utilizzando la funzione di backup integrata) avesse omesso completamente la cartella /uploads/ e non sapevo come spiegarlo in modo che tu potessi capire.
Sì… abbiamo seguito questa guida per configurare il reverse proxy nginx, ma era pensata per un’installazione standalone e non menzionava gli upload perché non era necessario trasferirli in modalità standalone:
Abbiamo seguito anche questa guida per due container, che anch’essa non menzionava il ripristino del DB o il trasferimento di alcuna cartella di upload:
Credo che possiamo capire le cose facilmente. Ecco il pezzo mancante che ti serviva per spiegare, a titolo di riferimento:
I principali tutorial su questa configurazione omettono il fatto che dovresti eseguire un ripristino del DB o trasferire manualmente gli upload nel nuovo container, poiché non l’hanno incluso.
Ovviamente, ora ha senso dopo averlo capito al 100% da soli (di nuovo!) perché non è nei tutorial. LOL
Tutto è facile una volta che conosci qual è il problema.
PS: Per chiudere. Grazie a tutti coloro che hanno scritto i vari tutorial. Sono stati di grande aiuto! Molto apprezzato. Da parte nostra, questa configurazione è completa e non useremo più alcuna configurazione standalone su alcun sito Discourse in futuro. Il nostro “default” normale sarà due container con un reverse proxy verso un socket Unix. Questo funziona meglio per gli aggiornamenti e lo scambio di container in tempo reale con quasi zero tempi di inattività. Ottimo lavoro!!
Discourse è GRANDE!!
Bravo Jeff @codinghorror e Sam @sam! BRAVO!
È abbastanza semplice farlo funzionare, ma come ho già detto prima, non usiamo S3 e altri servizi di archiviazione cloud; preferiamo mantenere le cose “semplici” e quindi i nostri backup vengono semplicemente rsyncati su archiviazione esterna. Preferiamo così… è una cosa in meno da debuggare e possiamo “farne a meno” senza S3,
Non so se questo sia utile o meno. Tuttavia, l’ottimizzazione delle immagini tende a fallire se il processo che esegue l’ottimizzazione non riesce a raggiungere il tuo server tramite il suo nome di dominio internet.
Ciò potrebbe spiegare perché questa funzionalità non funziona come previsto in un’architettura più complessa con reverse proxy.
Grazie, Kane.
Stavo provando (come probabilmente sai) altre alternative al metodo di backup standard tramite l’interfaccia utente di Discourse. Lo stavo facendo perché ho avuto problemi ogni volta che ho tentato un ripristino con il metodo di backup standard, seguendo sempre le istruzioni fornite nei tutorial ufficiali di questo sito.
In ogni caso, ho precisato all’inizio che stavo eseguendo il ripristino da un backup creato tramite l’interfaccia utente, seguendo la procedura di backup e quella di ripristino standard e raccomandate.
L’unica differenza rispetto a un’installazione standard di Discourse standalone è che stiamo utilizzando nginx come reverse proxy, collegato a Discourse tramite un socket.
Il problema principale che abbiamo riscontrato riguarda gli avatar, che sembravano essere persi e sostituiti dall’immagine profilo predefinita.
Mi hai detto che dovevano essere ricostruiti dal job di Sidekiq. Tuttavia, quel job sembra terminare immediatamente con successo (stato OK) quando viene avviato, ma gli avatar rimangono invariati.
Dato che i backup sono molto importanti per noi (chi potrebbe ignorarli?), eseguirò ulteriori test, facendo molta attenzione a seguire le istruzioni e provando altre idee suggerite qui.
Siamo soddisfatti di Discourse, ci piace molto. Stiamo solo cercando di assicurarci di avere una procedura di ripristino robusta, nel caso in cui subissimo qualche tipo di attacco (ne abbiamo subito uno di recente) o un guasto del server.
Se desideri che eseguiamo alcuni test per cercare di risolvere questo problema o fornire ulteriori informazioni, sarò felice di fare del mio meglio e fornirti quei dati.
Sembra che il sistema non possa accedere alle miniature degli avatar, questo è certo.
Ma il resto del forum viene servito correttamente: le rotte, SSL e tutto è configurato correttamente, per quanto riesco a vedere.
Se ci fosse qualche tipo di errata configurazione, non potresti accedere al forum Discourse e vedere il resto dei contenuti; riceveresti errori 502 o qualcosa di simile.
@neounix
Usiamo S3 perché è il metodo più semplice dall’interfaccia per avere i backup offsite.
Forse S3 non è l’opzione migliore, non lo so; comunque, dove sono salvati i backup non è correlato al problema, dato che non si tratta di un’impossibilità di raggiungerli ed eseguire il ripristino.
Il ripristino viene eseguito correttamente.
@stephan
Nel file app.yml ho commentato il template SSL e il template Let’s Encrypt, nonché la sezione expose con le porte.
La parte SSL è gestita da nginx, quindi non ho bisogno che il socket sia cifrato, giusto?
È sbagliato? Dovrei usare comunque il template SSL?
Immagino che, se questo fosse il problema, non potrei vedere nessuna parte del forum dopo il ripristino, non solo gli avatar, ma chissà…
Effettuerò ulteriori test. Grazie a tutti per il vostro aiuto.
@ariznaf … ciao!
Il modo in cui ho risolto questo problema su due server diversi è stato copiare manualmente la directory /shared/uploads dalla configurazione originale alle configurazioni socket-only, e dopo di ciò il problema è scomparso.
Il metodo che ho usato per verificare rapidamente è stato confrontare le dimensioni della directory uploads, semplicemente in questo modo (supponendo che tu sia nella directory condivisa):
du -sh uploads
Quando li ho confrontati, è allora che ho scoperto qual era il problema
Forse puoi verificare anche tu? Spero che questo possa aiutarti a isolare il tuo problema.
PS: Non sono negativo verso S3. Come si dice, ognuno fa come preferisce…
Fammi vedere se ho capito correttamente.
Quando eseguo i backup, ho verificato di salvare anche gli upload (non le miniature, ma ho testato anche il salvataggio delle miniature; ora sto salvando le miniature, quindi non dovrai attendere una nuova generazione).
Dopo il ripristino, anche gli upload vengono ripristinati.
Vuoi dire che il ripristino degli upload non funziona correttamente e devi farlo manualmente?
Come ripristini gli upload manualmente?
Hai scaricato il backup ed estratto la cartella shared/standalone/uploads?
Se è così (proverò a mia volta), mi sembra chiaro che ci sia qualche tipo di bug nel processo di ripristino.
Grazie.
Sto cercando alternative per eseguire i backup e archiviarli, ma il team di Discourse insiste sul fatto che l’unico modo corretto per farlo è utilizzare il backup standard.
Ciao @ariznaf,
Non ripristiniamo tramite l’interfaccia di amministrazione (effettuiamo solo backup dall’interfaccia web, non ripristini). Trasferiamo il file nel container tramite sftp (inclusi gli upload) e procediamo al ripristino in questo modo:
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
Tuttavia, quando ho configurato un nuovo nginx reverse proxy per socket Unix l’altro giorno, non ho ripristinato dal database perché il database era già presente nel container data (come menzionato nei topic delle guide).
Per questo motivo ho dovuto copiare manualmente gli upload sul nuovo container.
La tua situazione sembra diversa dalla nostra.
Spero che questo ti sia d’aiuto.
Grazie.
Sembra che tu stia eseguendo da riga di comando la stessa procedura che effettuiamo tramite l’interfaccia: abilitando i ripristini e ripristinando dai file tgz che contengono il database e i file caricati.
Ma poi dici che, per far funzionare gli avatar (utilizzando socket e un reverse proxy nginx), è necessario un secondo ripristino contenente solo i file caricati. È corretto?
Ciao @ariznaf… non esattamente…
All’inizio avevamo un’app standalone. Ho separato quell’app in due container diversi (uno per i dati e uno solo per il web) e poi ho eseguito un ripristino dal file di backup grande che conteneva gli upload.
Tutto è andato bene…
Poi ho creato un nuovo container, socket-only, e l’ho configurato per usare un reverse proxy.
Non ho eseguito un ripristino nel nuovo container socket-only (perché il container dei dati aveva già i dati del DB intatti), ma ho dimenticato di copiare manualmente gli upload (questo è stato il mio errore). Se avessi seguito la procedura normale di ripristino, non sarebbe stato necessario.
Ma non c’è motivo di eseguire di nuovo un ripristino manuale del DB nel nuovo container, perché proprio per questo i dati sono nel loro proprio container carino e separato. Quindi, in questa situazione, gli upload devono essere copiati nel nuovo container. È fatto in modo davvero elegante.
Ti è d’aiuto?
Non è quello che ho detto. Ho detto che il backend non riesce a raggiungere se stesso attraverso il front nginx. Quello che stai dicendo è il contrario.
Per ottimizzare un caricamento, il job Sidekiq lo recupera tramite http(s).
No, puoi disabilitare il template SSL, ma dovrai abilitare manualmente l’opzione force_https.