Se ha producido un error en mi actualización
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Por favor, ayúdame a solucionarlo.
Se ha producido un error en mi actualización
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Por favor, ayúdame a solucionarlo.
Si las copias de seguridad van allí, usted tiene acceso a él. Y sí, también lo tiene quien sea que posea ese bucket.
Siéntase libre de abrir un tema en Marketplace si desea explorar servicios de terceros de pago.
Esa es una posición difícil, te ofrezco mis condolencias.
Personalmente, querría mucho hacer una copia de seguridad antes de intentar una reconstrucción. Si el proceso de copia de seguridad habitual no te es útil (porque envía las copias de seguridad a un lugar inaccesible), entonces intentaría de alguna manera obtener una copia de seguridad de la base de datos usando la línea de comandos, pero no estoy seguro exactamente de cómo. ¿Quizás pg_dump dentro de Docker?
O tal vez puedas usar tu acceso a la línea de comandos para redirigir las copias de seguridad al disco local en lugar de a S3.
Pero en ambos casos necesitarás suficiente espacio en disco local.
Editar: me crucé en la publicación con Jay.
Gracias. Mi idea general, si pudiéramos hacer una copia de seguridad, sería de hecho redirigir la copia de seguridad a un disco local en lugar de S3 y tendríamos espacio para ello.
Es mi culpa que no haya descubierto la copia de seguridad local anoche en lugar de hacer la reconstrucción; la retrospectiva es 20/20 en eso. Subestimé el impacto de una reconstrucción.
¿Puedes ayudarme a entender esto? ¿Estás diciendo que las credenciales deben estar presentes si las copias de seguridad se enrutan allí? (confirmamos que apareció una nueva en el panel de administración de nuestro Discourse)
El problema es que, si necesitamos las credenciales para acceder a la copia de seguridad, no creo que nadie las tenga, excepto el tipo que desapareció.
¿Podría literatecomputing obtener una copia de seguridad local y restaurar nuestro sitio existente en un nuevo servidor mantenido si asumieran el trabajo?
Si el bucket de S3 tiene copias de seguridad tan recientes como la semana pasada, entonces Discourse tiene las credenciales para el bucket. Probablemente estén en app.yml o en la configuración del sitio.
Pero no necesitas acceso al bucket de S3 tú mismo, deberías poder descargar la copia de seguridad a través de Discourse.
¿Ves las copias de seguridad en /admin/backups?
Si es así, ¿qué sucede cuando intentas descargarlas?
También podrías cambiar la configuración del sitio - Copias de seguridad - Ubicación de la copia de seguridad a “almacenamiento local”.
¿Está diciendo que las credenciales deben estar presentes si las copias de seguridad se envían allí?
Sí. Si está haciendo una copia de seguridad en S3, las credenciales están en su base de datos o en el archivo yml.
¿Podría literatecomputing hacer una copia de seguridad local y restaurar nuestro sitio existente en un nuevo servidor mantenido si asumieran el trabajo?
Sí. Ya sea en SiteSettings o en el archivo yml, está la configuración backup_location. Si está en SiteSettings y no en la base de datos, es más difícil, pero no imposible de cambiar.
Soy solo un novato, pero podría
Intenté actualizar node y recibí un error de que un archivo en particular requería acceso administrativo durante la instalación, y necesitaba ejecutar un comando
chownpara cambiar los privilegios. Lo hice, pero no marcó ninguna diferencia.
ser del tema reciente que informó un problema de propiedad con un archivo en la reconstrucción
Which is why I posted the question. This has never happened before with numerous rebuilds.
si tienes acceso a la línea de comandos, ¿por qué no hacer una copia de seguridad desde la línea de comandos?
Tengo acceso root. Hice una copia de seguridad por línea de comandos, pero se envió a S3. Gracias a los comentarios de @pfaffman, ahora me doy cuenta de que puedo intentar descargar la copia de seguridad de S3 a local; solo necesito tiempo para intentarlo.
¿Ves la configuración backup_location en la configuración de la UX (¿o el servidor está caído y no puedes ver?)?
recibí un error de que un archivo en particular requería acceso administrativo durante la instalación,
¿Te refieres a esta advertencia?
ADVERTENCIA: El archivo containers/app.yml es legible por todos. Puedes proteger este archivo ejecutando: chmod o-rwx containers/app.yml
Es una advertencia. Durante muchos años, el valor predeterminado fue que ese archivo fuera legible por todos (asumiendo que la mayoría de los autoalojadores simplemente iniciarían sesión como root y no tendrían otros usuarios), pero en algún momento se decidió que tener los secretos en ese archivo legibles para todos no es una buena práctica. Dado que estás ejecutando el lanzador como root, root siempre podrá leer el archivo.
No veo un admin/backups, ¿dónde está eso? El único lugar donde he visto backups es en /var/discourse/shared/standalone/backups/default, pero estas son todas copias de seguridad locales antiguas.
Tendré más información sobre la situación de la configuración del sitio más tarde, cuando la persona que puede acceder a ella esté despierta (están en horario del Reino Unido). Supongo que no tienen acceso ya que el sitio está caído.
No veo una configuración específica de backup_location en el archivo app.yml.
También, barra lateral, pero vi en el “Acerca de” de tu empresa que eres un ex profesor de CS. Ese es mi trabajo actual ![]()
¿Te refieres a esta advertencia?
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
No esa. Cuando tenga la oportunidad, publicaré el error específico, pero fue al intentar actualizar node, como dije, no durante la reconstrucción.
Añade esto a la URL de tus foros. Deberías poder ver tus copias de seguridad en la interfaz de usuario.
Ah, entendido. Estaba buscando esto en el propio servidor. El sitio está completamente caído, así que no tengo acceso a la página.
Solo una pregunta general. ¿Cuáles son las especificaciones del servidor? Incluyendo la versión del sistema operativo.
2.0.20230313-1023: Pulling from discourse/base
esta es una imagen antigua [1] y probablemente la fuente de estos errores:
error discourse@: The engine "node" is incompatible with this module. Expected version ">= 20". Got "18.15.0" error discourse@: The engine "yarn" is incompatible with this module. Expected version "please-use-pnpm". Got "1.22.19" warning discourse@: The engine "pnpm" appears to be invalid.
Probablemente necesites hacer git pull del directorio discourse_docker (el directorio desde donde ejecutas launcher).
Como siempre, haz una copia de seguridad del servidor primero ya que te encuentras en un estado degradado.
en tiempo de Internet ↩︎
Hoy pudimos organizar una nueva copia de seguridad local, así que la estoy descargando localmente ahora.
Entonces, ¿simplemente haré pull en /var/discourse y luego intentaré reconstruir para actualizar?
Your branch and 'origin/main' have diverged,
and have 15 and 201 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
diverged es, de hecho, un eufemismo ![]()
Supongo que has estado guardando tus configuraciones de contenedor, así que git pull o git pull --rebase podrían llevarte a donde necesitas estar, más vale que lo intentes ![]()
Amigo, no tengo ni idea de lo que ha estado pasando, pero veré qué conseguimos con un pull o un rebase si es necesario. Voy a crear una nueva ventana de mantenimiento ya que, por alguna razón, el sitio volvió a estar en la versión antigua. Les actualizaré con los resultados.
¡Agradezco mucho toda la sabiduría!