Si è verificato un errore durante l’aggiornamento
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
Per favore, aiutami a risolverlo.
Se i backup vanno lì, ne hai accesso. E sì, anche chiunque possieda quel bucket ne ha accesso.
Sentiti libero di aprire un argomento su Marketplace se desideri esplorare servizi a pagamento di terze parti.
Questa è una posizione difficile in cui trovarsi: hai la mia comprensione.
Personalmente, vorrei molto fare un backup prima di provare una ricostruzione. Se il normale processo di backup non ti è utile (perché invia i backup in un luogo inaccessibile), allora proverei in qualche modo a ottenere un backup del database utilizzando la riga di comando, ma non sono sicuro esattamente di come. Forse pg_dump all’interno di Docker?
O forse puoi usare il tuo accesso alla riga di comando per reindirizzare i backup al disco locale invece che a S3.
Ma in entrambi i casi avrai bisogno di spazio su disco locale sufficiente.
Modifica: incrociato nel post con Jay.
Grazie: la mia idea generale, se potessimo fare un backup, sarebbe quella di reindirizzare effettivamente il backup su un disco locale invece che su S3 e avremmo spazio per esso.
È colpa mia se non ho capito il backup locale ieri sera invece di fare la ricostruzione: il senno di poi è chiaro su questo. Ho sottovalutato l’impatto di una ricostruzione.
Puoi aiutarmi a capire questo? Stai dicendo che le credenziali devono essere presenti se i backup vengono indirizzati lì? (abbiamo confermato che ne è apparso uno nuovo nel pannello di amministrazione del nostro Discourse)
Il problema è che, se abbiamo bisogno delle credenziali per accedere al backup, non credo che nessuno le abbia tranne il tizio che è sparito.
Potrebbe literatecomputing ottenere un backup locale e ripristinare il nostro sito esistente su un nuovo server mantenuto se si assumessero il lavoro?
Se il bucket S3 contiene backup recenti come la settimana scorsa, allora Discourse ha le credenziali per il bucket. Probabilmente si trovano in app.yml o nelle impostazioni del sito.
Ma non hai bisogno di accedere tu stesso al bucket S3, dovresti essere in grado di scaricare il backup tramite Discourse.
Vedi i backup in /admin/backups?
Se sì, cosa succede quando provi a scaricarli?
Potresti anche cambiare le Impostazioni del sito - Backup - Posizione di backup in “archiviazione locale”.
Sì. Se stai eseguendo il backup su S3, le credenziali si trovano nel tuo database o nel file yml.
Sì. Sia in SiteSettings che nel file yml è presente l’impostazione backup_location. Se si trova in SiteSettings e non nel database, è più difficile, ma non impossibile da cambiare.
Sono solo un principiante ma potrei
provenire da un recente argomento segnalato problema di proprietà con un file durante la ricostruzione
se hai accesso alla riga di comando perché non fare un backup dalla riga di comando?
Ho accesso root. Ho eseguito un backup da riga di comando, ma è stato inviato su S3. Grazie ai commenti di @pfaffman mi rendo conto che posso provare a scaricare il backup da S3 in locale: ho solo bisogno del tempo per tentare.
Vedi l’impostazione backup_location nelle impostazioni dell’UX (o il server è inattivo quindi non puoi vederlo?)
Intendi questo avviso?
ATTENZIONE: il file containers/app.yml è leggibile da tutti. Puoi proteggere questo file eseguendo: chmod o-rwx containers/app.yml
È un avviso. Per molti anni, l’impostazione predefinita era che quel file fosse leggibile da tutti (supponendo che la maggior parte degli auto-ospitanti si connetta semplicemente come root e non abbia altri utenti), ma a un certo punto si è deciso che avere i segreti in quel file leggibili da chiunque non è una best practice. Dato che stai eseguendo il launcher come root, root sarà sempre in grado di leggere il file.
Non vedo un admin/backups dove si trova? L’unico posto in cui ho visto backups è /var/discourse/shared/standalone/backups/default, ma questi sono tutti vecchi backup locali.
Ne darò seguito alla situazione delle impostazioni del sito più tardi, quando la persona che vi ha accesso sarà sveglia (sono nel fuso orario del Regno Unito). Presumo che non abbiano accesso poiché il sito è inattivo.
Non vedo un’impostazione specifica backup_location nel file app.yml.
Anche la barra laterale, ma ho visto nella sezione Informazioni della tua azienda che sei un ex insegnante di scuola superiore. Quello è il mio lavoro principale al momento 
Non quello. Quando avrò la possibilità, pubblicherò l’errore specifico, ma proveniva dal tentativo di aggiornare node, come ho detto, non durante la ricostruzione.
Aggiungi questo all’URL dei tuoi forum. Dovresti essere in grado di vedere i tuoi backup nell’interfaccia utente.
Ah, capito. Lo stavo cercando sul server stesso. Il sito è completamente inattivo, quindi non ho accesso alla pagina.
Solo una domanda generale. Quali sono le specifiche del server? Inclusa la versione del sistema operativo.
Siamo riusciti a risolvere oggi un nuovo backup locale, quindi lo sto scaricando localmente ora.
Quindi farò semplicemente pull in /var/discourse e poi proverò una ricostruzione per aggiornare?
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 è, in effetti, un eufemismo 
Immagino che tu stia salvando le configurazioni del tuo container, quindi git pull o git pull --rebase potrebbero portarti dove devi essere, tanto vale provare 
Amico mio, non ho idea di cosa sia successo, ma vedrò cosa otteniamo con un pull o un rebase, se necessario. Creerò una nuova finestra di manutenzione poiché, per qualche motivo, il sito è tornato online con la vecchia versione. Vi aggiornerò tutti con i risultati. Apprezzo molto tutta la saggezza!