Betas após os testes eventualmente são lançados como uma versão estável. Dependendo do tamanho das alterações no núcleo, pode ser necessário executar etapas especiais pela linha de comando.
Um VPS (Servidor Virtual Privado) é o que você pagou para sua instalação do Discourse rodar. A menos que você esteja rodando em seu PC doméstico; que normalmente será uma instalação não suportada.
Eu estava usando o Upcloud como meu provedor de VPS. Agora estou usando o Cobtabo.
Todas as versões beta, após testes suficientes, tornam-se o que as pessoas chamam de lançamentos Estáveis.
No link que Moin forneceu, você tem:
Planos hospedados do Discourse geralmente usam a ramificação Testes-Aprovados para garantir a melhor segurança e boa estabilidade.
Não leve isso a mal. Mas com você não estando familiarizado com termos como VPS. Sugere que você é muito novo nisso. Você instalou o Discourse sozinho ou talvez herdou um fórum Discourse? Todos nós já fomos novos em algum momento na configuração/manutenção do Discourse.
Não é uma opinião. É um fato se o software que você escolhe usar. O que está no mesmo nível da maioria dos softwares de código aberto e até mesmo de código fechado que você usa. Eu escrevi vps. O Android capitalizou o V e o P.
No entanto, tudo bem, imagino que você terá que descobrir as coisas por si mesmo; se você realmente não quer ajuda para aprender.
Boa sorte! 
Notei que @anon55243134 excluiu quase todas as suas postagens. Eu realmente acho que há lições a serem aprendidas aqui para a equipe e para a manutenção dos scripts de atualização e a comunicação em torno da atualização.
@anon55243134 é alguém que tem executado um discourse auto-hospedado por anos e agora tem uma instalação danificada e não funcional - apenas seguindo as instruções para atualizar.
Se isso acontecesse comigo, eu ficaria muito irritado e angustiado com a possibilidade de perder o conteúdo do meu fórum. Tendo optado pela auto-hospedagem, eu poderia não estar pronto ou ser capaz de pagar muito dinheiro para consertá-lo, se é que isso é possível.
Acho que há avisos e verificações insuficientes
Ainda mais preocupante, em uma das postagens excluídas, vejo algumas falhas bastante drásticas que não foram capturadas e o script continuou:
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
Eu não verifiquei os scripts, mas esperaria que a ausência de coisas fosse uma indicação de que problemas estão por vir, e é hora de parar.
Desculpe abrir uma caixa de Pandora existente! No meu caso, atualizei o Ubuntu e o Postgres e depois executei novamente o comando sudo ./luancher rebuild app no diretório /var/discourse e tudo parece ter sido reconstruído corretamente e o site está de volta.
Obrigado a todos que me auxiliaram com esse esforço. Agradeço a ajuda e não sei onde estaria sem esta comunidade.
Obrigado!
Existem definitivamente oportunidades aqui para melhorar o Discourse. Tendo uma instância estável rodando há 7 a 8 anos, sempre houve momentos em que precisei atualizar pela linha de comando do servidor. Isso é até coberto na documentação com uma frequência recomendada.
No entanto, a documentação não é tão fácil de acessar quanto poderia ser. O plugin Document Categories é definitivamente uma melhoria. Mas, na minha opinião, ainda não é tão bom quanto poderia ser.
Minhas recomendações para melhorar isso seriam links diretos na interface web de administração. Talvez com um link de (?) para abrir um pop-up com algumas informações e um link para um Tópico aqui no Meta com informações mais detalhadas.
Com o painel de Atualização, seria útil ter informações extras de forma semelhante, até mesmo com Core e Docker, para desativar o botão com uma mensagem necessária para fazer pela linha de comando do servidor com um link para as notas de lançamento específicas, com a primeira seção detalhando os requisitos. Por exemplo, Versão X do Docker e versão X do Ubuntu LTS (ou distribuições Linux suportadas oficialmente equivalentes). O tópico vinculado também deveria, na minha opinião, incluir alguns itens de copiar e colar da linha de comando do servidor.
Com os scripts, não tenho certeza de quão fácil isso pode ser. Mas que o script inicial faça uma verificação de alguns requisitos básicos. Se a dependência necessária não estiver presente, saia com uma mensagem e talvez um link para as informações básicas necessárias sobre como fazer.
A mensagem de atualização falha precisa ser mais intuitiva. Embora diga para rolar para cima para ver erros anteriores. Descobri que existem alguns erros que parecem comuns e não afetam a reconstrução. Portanto, exportar erros-chave para um arquivo de log que causou a falha da reconstrução seria muito melhor. No entanto, essas mudanças propostas provavelmente levarão um bom tempo e trabalho.
Com Documentation > Self-Hosting, realmente precisamos de um guia de início mais completo, com uma introdução sobre o que se deve saber antes de auto-hospedar. Como um bom conhecimento do sistema operacional, como o Ubuntu LTS, com algumas informações básicas sobre manutenção e atualização da distribuição. Melhores práticas de backup e guias diretos. Esses guias poderiam talvez até ser adicionados como um tópico com tags na categoria Staff, com links para o Meta.
Bloomberg, se não me engano, criou um bom tópico sobre o que aconteceu neste tópico. Pelo meu lado, peço desculpas a @anon55243134. No entanto, eles também precisam assumir sua parte. Se você está buscando suporte, precisa estar disposto a ouvir o que é dito e fornecer as informações solicitadas para que todos que puderem ajudem a guiá-lo para possíveis soluções.
Todos nós podemos ter ideias em nossas opiniões sobre como o design, etc., poderia ser melhor. Mas, na ausência de mudanças que gostaríamos de ter. Temos que aceitar como está no momento.
Eu sei o quão angustiante é ter tempo de inatividade prejudicial. Há um tempo, tive um problema com o cliente para o qual sou administrador voluntário. Pedi a eles por mais de um mês quando não consegui reconstruir o aplicativo devido ao servidor ser muito pequeno e os guias de liberação de espaço aqui não conseguiram resolver, eles ignoraram meu conselho e, finalmente, como eu avisei, o servidor sofreu uma grande falha. Eles acabaram pagando um membro aqui para consertar o problema, que acabou envolvendo a implantação de um novo servidor com espaço suficiente. O site ficou fora do ar por mais de 2 semanas devido à negligência deles. Mais tarde, eles não estavam mantendo o servidor de e-mail e, embora o site não estivesse fora do ar, a falta de e-mails de notificação causou muitos danos. Eu poderia entrar em mais detalhes. Mas não é um problema do Discourse. Isso é um problema de auto-hospedagem.
Há muito, muito tempo, tive um problema de reconstrução que foi causado por um arquivo de template. O log me deu o suficiente para explorar um palpite se comentando o arquivo de template. Funcionou para resolver meu problema. Quando surgiu aqui, postei o que fiz, o que ajudou a identificar o problema para a equipe.
De todos os lados, precisamos nos esforçar para melhorar. Reserve um tempo para ler e ouvir aqueles com a experiência e as habilidades para ajudar a resolver problemas. É assim que ganhei minha consciência sobre as coisas que sou capaz de fazer. Para coisas (que especialmente com a complexidade do Discourse) com as quais não tenho experiência, pesquiso o melhor que posso e peço ajuda e aceito o conselho de todos aqui que são de fato mais avançados na compreensão deste software fantástico.
@anon55243134, se você estiver disposto a dar uma chance, talvez todos nós possamos ajudar a colocá-lo de volta online. Só precisamos evitar, durante este processo, desviar para “como achamos que deveria ser” e aceitar por enquanto “como é”. Depois de consertado, podemos aprender com as lições e iniciar uma boa discussão com recomendações sobre como potencialmente melhorar as coisas e aceitar que, se a equipe for receptiva (geralmente é), isso levará um tempo considerável com outros projetos em andamento. Do nosso lado, podemos trabalhar em ideias e aqueles que têm o conhecimento real podem, se tiverem tempo, trabalhar em algumas das informações necessárias para guias, melhores práticas, etc.
United Together Everyone Achieves More. Decidi que realizamos muito pouco ou nada.