Le versioni beta, dopo i test, vengono infine distribuite come versione stabile. A seconda di quanto siano grandi le modifiche al core, potrebbero essere necessari passaggi speciali da eseguire tramite la riga di comando.
Un VPS (Virtual Private Server) è ciò per cui hai pagato per eseguire la tua installazione di Discourse. A meno che tu non stia eseguendo su un PC di casa; che in genere sarà un’installazione non supportata.
Stavo usando Upcloud come mio provider VPS. Ora sto usando Contabo.
Tutte le beta, dopo sufficienti test, diventano quelle che la gente chiama release Stabili.
Nel link fornito da Moin, hai:
I piani di Discourse ospitati utilizzano tipicamente il branch Tests-Passed per garantire la migliore sicurezza e una buona stabilità.
Non prenderla male. Ma dato che non hai familiarità con termini come VPS, suggerisce che sei molto nuovo a questo. Hai installato Discourse da solo o forse hai ereditato un forum Discourse? Tutti siamo stati nuovi una volta alla configurazione/manutenzione di Discourse.
Non è un’opinione. È un dato di fatto se il software che scegli di utilizzare. Che è alla pari con la maggior parte del software open-source e persino closed-source che utilizzi. Ho scritto vps. Android ha capitalizzato la V e la P.
Tuttavia, capisco che dovrai semplicemente capire le cose da solo; se non vuoi davvero aiuto per imparare.
Buona fortuna! 
Noto che @anon55243134 ha cancellato quasi tutti i suoi post. Penso davvero che ci siano lezioni da imparare qui per il team e per la manutenzione degli script di aggiornamento e della comunicazione relativa all’aggiornamento.
@anon55243134 è qualcuno che gestisce un discourse self-hosted da anni e ora ha un’installazione danneggiata e non funzionante, semplicemente seguendo le istruzioni per l’aggiornamento.
Se succedesse a me, sarei molto infastidito e angosciato dalla potenziale perdita dei contenuti del mio forum. Avendo optato per l’auto-hosting, potrei non essere pronto o in grado di pagare ingenti somme per farlo riparare, se ciò fosse anche solo possibile.
Penso che ci siano avvisi e controlli insufficienti
Ancora più preoccupante, in uno dei post cancellati vedo alcuni fallimenti piuttosto drammatici che non sono stati intercettati e lo script è continuato:
cat: /shared/postgres_data/PG_VERSION: No such file or directory
...
E: Unable to locate package postgresql--pgvector
cp: cannot stat '/etc/postgresql//main/*': No such file or directory
sh: 1: /usr/lib/postgresql/bin/postgres: not found
...
Finding the real data directory for the source cluster
could not get data directory using "/usr/lib/postgresql/bin/postgres" -D "/shared/postgres_data" -C data_directory: No such file or directory
Failure, exiting
Non ho controllato gli script, ma mi aspetterei che l’inesistenza di qualcosa sia un’indicazione che ci sono problemi in arrivo, e che sia ora di fermarsi.
Scusate per aver aperto un vecchio vaso di Pandora! Nel mio caso ho aggiornato Ubuntu e Postgres e poi ho eseguito di nuovo sudo ./launcher rebuild app nella directory /var/discourse e tutto sembra essere ricostruito correttamente e il sito è tornato operativo.
Grazie a tutti coloro che mi hanno aiutato con questo servizio. Apprezzo l’aiuto e non so dove sarei senza questa comunità.
Grazie!
C’è sicuramente spazio qui per migliorare Discourse. Avendo una istanza Stable funzionante ormai da 7 o 8 anni, ci sono sempre stati momenti in cui ho dovuto eseguire l’Upgrade tramite la riga di comando del server. Questo è anche coperto nella documentazione con una frequenza consigliata.
Tuttavia, la documentazione non è così facile da consultare come potrebbe essere. Il plugin Document Categories è sicuramente un miglioramento. Ma ancora, a mio avviso, non è così buono come potrebbe.
Le mie raccomandazioni per migliorare questo sarebbero dei link direttamente nell’interfaccia web di amministrazione. Magari con un link (?) per far apparire un popup con alcune informazioni e un link a un argomento qui in Meta con dettagli più approfonditi.
Con il pannello di aggiornamento, sarebbe utile avere anche alcune informazioni extra in modo simile, con magari una versione in grigia del pulsante con un messaggio necessario per eseguire l’upgrade dalla riga di comando del server, con un link alle note di rilascio di quella versione con la prima sezione che dettaglia i requisiti. Per esempio, Versione Docker X e versione Ubuntu LTS X (o distros Linux ufficialmente supportate equivalenti). L’argomento collegato dovrebbe, a mio parere, includere anche alcuni comandi da riga di comando da copiare e incollare.
Per gli script, non sono sicuro di quanto sia facile farlo. Ma si potrebbe far sì che lo script iniziale esegua un controllo per alcuni requisiti di base. Se una dipendenza richiesta non è presente, terminare con un messaggio e magari un link alle informazioni di base su come fare.
Il messaggio di errore di aggiornamento fallito deve essere più intuitivo. Anche se dice di scorrere verso l’alto per errori precedenti, ho trovato che ci sono alcuni errori che sembrano comuni e non influenzano il processo di ricostruzione. Quindi esportare gli errori chiave nel file di log che ha causato il fallimento della ricostruzione sarebbe molto meglio. Tuttavia, questi cambiamenti proposti probabilmente richiederanno un notevole lavoro e tempo.
Con Documentation > Self-Hosting, è davvero necessario un guida più approfondita su come iniziare, con un’introduzione su cosa bisogna sapere prima di self-hosting. Come una conoscenza decente del sistema operativo, come Ubuntu LTS, con alcune info di base su manutenzione e aggiornamenti della distribuzione. Le migliori pratiche sui backup e istruzioni dirette. Questi argomenti potrebbero anche essere aggiunti come una categoria di argomenti con tag in Staff, con link in Meta.
Bloomberg, se ricordo bene, ha fatto un buon argomento su cosa è successo in questa discussione. Per quanto mi riguarda, mi scuso con @anon55243134. Tuttavia, anche loro devono assumersi le proprie responsabilità. Se si cerca supporto, bisogna essere disposti ad ascoltare quanto si dice e fornire le informazioni richieste, così tutti coloro che possono aiutare possano guidarli verso possibili soluzioni.
Tutti noi possiamo avere idee o opinioni su come il design possa essere migliorato. Ma, in mancanza di modifiche che vorremmo, dobbiamo accettare come stanno le cose attualmente.So che quanto può essere frustrante avere tempi di inattività dannosi. Qualche tempo fa ho avuto un problema con il client per il quale faccio volontariamente l’amministratore. Ho presentato una petizione per oltre un mese perché non riuscivo a ricostruire l’app a causa di un server troppo piccolo e i tutorial per liberare spazio qui non potevano risolvere. Hanno ignorato il mio consiglio e alla fine, come avevo previsto, il server ha subito un crash importante. Alla fine hanno pagato un membro qui per risolvere il problema, che ha comportato il dispiegamento di un nuovo server con spazio sufficiente. Il sito è stato offline per oltre 2 settimane a causa della loro negligenza. Più tardi non hanno mantenuto il server di posta e, anche se il sito non era inattivo, la mancanza di email di notifica ha causato molti danni. Potrei aggiungere altro, ma non riguarda Discourse, che si tratta di un problema di self hosting.
Tanto tempo fa ho avuto un problema di ricostruzione causato da un file modello. Il log mi ha fornito abbastanza informazioni per fare una supposizione commentando il file modello. Ha funzionato per risolvere il mio problema. Quando sono venuto qui, ho condiviso cosa avevo fatto, il che ha aiutato a identificare il problema per il team.
In tutti i casi dobbiamo cercare di migliorare. Prenditi il tempo di leggere e ascoltare chi ha esperienza e competenza per aiutare a risolvere i problemi. È così che ho acquisito consapevolezza sulle cose che posso fare. Per le cose (che, soprattutto con la complessità di Discourse, non conosco bene), cerco di informarmi il più possibile, chiedere aiuto e seguire i consigli di tutti coloro che qui sono più esperti di questa fantastica applicazione.
@anon55243134, se sei disposto a dare una possibilità, forse possiamo aiutarci a riportarti online. Dobbiamo semplicemente evitare, durante questo processo, di deviare su “come pensiamo che dovrebbe essere” e accettare per il momento “come è”. Una volta risolto il problema, possiamo imparare dalle lezioni apprese e avviare una buona discussione con raccomandazioni su come migliorare le cose e, se il team è ricettivo (cosa che di solito sono), riconoscere che ci vorrà del tempo, con altri progetti in corso. Da parte nostra, possiamo lavorare sulle idee e coloro che hanno realmente competenza possono, se hanno tempo, lavorare su alcune delle informazioni necessarie per tutorial, migliori pratiche, ecc.