Fallo en la actualización 2.7.0.beta2

¿Podría ser que se esté quedando sin RAM y que el OOM Killer esté terminando procesos aleatorios como sshd, desconectándolo y causando problemas?

Debería haber algo en la salida de dmesg, /var/log/messages o la salida de journalctl si el OOM Killer está activo.

Dudo que el problema sea que se me acabe la RAM; más bien es que me niego a dejar de usar la consola de PuTTY en lugar de la consola de DO.

Así que voy a seguir la sugerencia de @pfaffman mencionada arriba, especialmente ahora que he descubierto que la consola de PuTTY se desconecta incluso cuando la uso para algo completamente diferente a la gestión de Discourse.

Podría ser la RAM. ¿Tienes swap?

¿Has probado a ajustar la configuración de keep-alive, algo como esto?

@pfaffman No especificé nada; estoy utilizando todos los valores predeterminados de los droplets, confiando en que el equipo de DO garantice un comportamiento razonable.

Primero, voy a intentar establecer el keep-alive como sugirió @omarfilip arriba, luego revisaré la situación del espacio de intercambio (swap), y finalmente consideraré la sugerencia de @pfaffman de usar la consola original de DO (si la configuración de keep-alive me permite seguir usando la consola de PuTTY, la usaré ya que es mucho más amigable para el usuario que la equivalente de DO.

Tener a tantas personas amables ayudándome me lleva a reiterar mis razones para intentar unir Ghost y Discourse: en mi opinión, es la herramienta ideal para que alguien redacte documentación técnica y ofrezca el mejor soporte para debatir sobre estos documentos. Mi plan es abordar la Gestión de Identidad y Cuentas (IAM) utilizando varios proveedores de IAM de PaaS interesantes; este tema no está suficientemente documentado (al menos en mi opinión, basada en años de uso de estos servicios).

Para “hacer pruebas beta” de mi herramienta integrada Ghost/Discourse, decidí describir todos los detalles del proceso de creación y prueba de esta herramienta. Así, todas las personas que me ayudan deben saber que este esfuerzo tiene como objetivo ayudar a las comunidades de Discourse, Ghost y Digital Ocean.

Si utilizaste la instalación de un solo clic de Digital Ocean y no la Instalación Estándar Oficial de Discourse, es probable que no tengas la memoria de intercambio (swap) configurada. Por lo tanto, al reconstruir, se te agotará la memoria RAM a menos que tengas más de 2 GB.

Puedes intentar ejecutar:

cd /var/discourse
./discourse-setup

Esto creará la memoria de intercambio si es necesario.

Si necesitas ayuda con la instalación de un solo clic de Digital Ocean y quieres “confiar en que el personal de DO asegure un comportamiento razonable”, entonces debes confiar en ellos para que te brinden soporte.

Pero, ya que estoy escribiendo, una forma más fácil de confirmar que el problema no es PuTTY (lo cual podría ahorrarte mucho tiempo ajustando los parámetros de PuTTY en vano) es probar la consola. Si no has ejecutado discourse-setup, estoy bastante seguro de que el problema es el espacio de memoria de intercambio.

@pfaffman Seguí al pie de la letra el proceso oficial de instalación de Discourse, incluyendo el uso de PuTTY mencionado en dicho documento oficial de instalación.

Es posible que hayas deducido que utilicé la instalación de un clic de Digital Ocean (DO) y que pienses que debería depender de DO:

Si quieres ayuda con la instalación de un clic de Digital Ocean y deseas “confiar en que el equipo de DO garantice un comportamiento razonable”, entonces debes confiar en ellos para que te brinden soporte.

Mi referencia a la instalación de un clic proviene del correo electrónico reciente de Discourse:

¡Genial, ya está disponible una nueva versión de Discourse!

Tu versión: 2.7.0.beta1
Nueva versión: 2.7.0.beta2

Por lo tanto, la situación actual es la siguiente:

  • Agradezco sinceramente tu ayuda, Jay :revolving_hearts:, sabiendo que te ganas la vida ayudando a personas con Discourse. A pesar de que no parezco un cliente potencial, dedicaste tiempo a sacarme del aprieto.
  • Logré instalar la actualización 2.7.0.beta2 sin problemas, una vez que descubrí que PuTTY se comportaba mal independientemente de la configuración de keep-alive que apliqué. Así que cambié de autenticación basada en SSH a un par de usuario/contraseña, inicié sesión en el host del droplet y ejecuté con éxito el comando ./launcher rebuild app.

Muchas gracias a todos los que aportaron partes de la solución.

¡Oh! ¡Mea culpa! ¡Lo siento mucho!

Entonces sí tienes swap y mi suposición era incorrecta. Qué lástima, porque iba a ser una solución sencilla. :wink:

¡Qué alivio después de acusarte falsamente!

Y es terrible saber que PuTTY es tan malo. No entiendo cómo sigue siendo el cliente SSH recomendado para Windows.

Creo que ahora hay algún cliente que forma parte de esa cosa del subsistema de Linux, pero la versión de Windows que usaba regularmente era Windows 98.

¡Me alegro de que lo hayas solucionado!

Todos los sistemas operativos modernos incluyen clientes SSH de forma nativa, por lo que no debería ser necesario utilizar clientes de terceros. Incluso en Windows Terminal, simplemente puedes escribir SSH. Debería funcionar siempre que tu sistema Windows esté actualizado.

¡Vaya! ¿De verdad? La última vez que (creí) mirar, requería una instalación que parecía complicada.

¿Y puede usar una clave SSH normal y no ese disparate de PEM?

Esta larga historia tiene un final feliz y podría clasificarse como un alboroto en una taza de té. Aprendí mucho sobre Discourse y, en consecuencia, planeo quedarme aquí indefinidamente. Aquí está la descripción detallada del final feliz:

  1. Mi problema al actualizar de Beta1 a Beta2 se manifestó por la expiración del tiempo de espera de la consola de PuTTY. Lo interpreté como un colapso colossal en la tarea de actualización de Discourse y dediqué mucho tiempo a aprender los “interiores” de Discourse: un callejón sin salida por el que me alegro de haber seguido innecesariamente.

  2. La solución a mi problema es extremadamente simple (una vez que sabes dónde “empujar”): tan simple como 1, 2, 3 a continuación.


    (el hecho de que comenzara con un intervalo de “keep-alive” demasiado grande me llevó a creer que PuTTY es realmente un software terrible y dediqué mucho tiempo a cambiar del acceso al droplet basado en SSH a la autenticación basada en [id, contraseña] necesaria para la propia consola de Digital Ocean (que es realmente mala). Nota: este experimento rehabilita completamente la herramienta PuTTY.

  3. @Falco abrió nuestros “ojos colectivos” al señalar que simplemente usáramos OpenSSH integrado en Windows 10 (gracias a Scott Hanselman).


Dado que ya le prometí a @codinghorror escribir el mejor documento posible que presente Discourse al mundo como agradecimiento por su ayuda (y la de su equipo) para que entendiera Discourse, @pfaffman me permitió hacer de la sugerencia de @Falco la primera parte de mi documento.

Recomiendo usar tmux; de esta manera, puedes reconectar a la sesión que está ejecutando rebuild incluso si tu cliente se agota el tiempo de espera.

@md-misko gracias por el consejo:

Lo genial de tmux es que te permite tener múltiples paneles abiertos al mismo tiempo, cada uno con su propia shell ejecutándose, pero utilizando la misma conexión SSH única. Además, también puedes tener varias “ventanas” abiertas al mismo tiempo, algo así como pestañas con más paneles dentro.

Hola @sunjam, parece que el problema se puede solucionar con la nueva versión de la gema omniauth-vkontakte 1.7.0.

He creado una solicitud de extracción para el mantenedor del plugin. Como solución temporal, puedes cambiar el enlace de GitHub en tu app.yml a

- git clone https://github.com/rapekas/discourse-vk-auth

y reconstruir.