Come scriptare la procedura guidata di installazione?

Buongiorno,

Sembra una domanda frequente e mi scuso in anticipo se lo è: apparentemente non ho cercato abbastanza :blush: Come potrei scrivere uno script per fare la stessa cosa della procedura guidata invece di farlo tramite l’interfaccia web?

Inizierebbe con qualcosa di simile a il fixture Fabricate(admin) dai test di specifica. E forse chiamato dalla sezione personalizzata del container.

Grazie in anticipo per il vostro aiuto!

Wizard è per metà impostazioni del sito e per metà chiamate API.

Per le chiamate API, puoi leggere Come fare reverse engineering dell’API di Discourse e per le impostazioni del sito segui l’esempio qui:

2 Mi Piace

Ma… forse è qui che mi perdo: per chiamare l’API ho bisogno di una chiave API. E quindi di un utente amministratore… che non ho (ancora). È possibile chiamare l’API senza una chiave API? Oppure ottenere una chiave API che sia scollegata da un utente e abbia credenziali di amministratore?

Sembra che dovrei usare rake:admin per creare l’utente amministratore. In realtà, penso che l’utente amministratore sia già stato creato ma non approvato, quindi dovrei modificarlo affinché venga approvato.

Oppure potrei creare una chiave API con api_key:create_master e utilizzarla per creare l’utente amministratore?

root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'api_key:create_master[MASTERKEY]'
ad676e7413778aaaaa5d315c35f188591ef0edb4a4d4b2d644b9247a88421cfa

Ma sembra che non abbia ben capito come utilizzare questa chiave master, perché questo non funziona:

# curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c35f91ef0edb4a4d4b2d644b924b7a88421cfa"
{"errors":["You are not permitted to view the requested resource. The API username or key is invalid."],"error_type":"invalid_access"}

Tuttavia, se creo un utente amministratore:

root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'admin:create' 
Email:  loic@dachary.org
Password:  
Repeat password:  

Ensuring account is active!

Account created successfully with username loic
Do you want to grant Admin privileges to this account? (Y/n)  Y

Your account now has Admin privileges!

e poi uso la stessa chiave master specificando l’utente appena creato, funziona:

curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c358591ef0edb4a4d4b2d644b924b7a88421cfa" -H "Api-Username: loic"
{"category_list":{"can...

e ha i privilegi di amministratore, poiché può anche accedere a /admin/site_settings/category/branding

Cosa stai cercando di fare esattamente? Vuoi automatizzare la creazione di un utente amministratore e l’impostazione di alcune configurazioni?

1 Mi Piace

Sì, esattamente. Voglio creare un nuovo forum da zero e popolarlo con utenti, categorie e argomenti tramite uno script che non richieda alcuna interazione con il browser.

Forse è meglio creare prima quel database e ripristinarlo come parte del processo di installazione?

Non ho alcun database: gli utenti, le categorie e gli argomenti verranno creati utilizzando i dati provenienti da mailman2.

Se vuoi importare i dati, fallo semplicemente come processo separato.

Se fosse un singolo tentativo, andrebbe bene. Ma voglio poter testare lo script di importazione. E affinché il test venga eseguito, deve prima creare un Discourse da zero, senza richiedere alcun intervento manuale a metà del test automatizzato :wink:

Per contesto, questa è parte del lavoro che sto svolgendo per importare mailman2 in Discourse. Il test verrebbe eseguito tramite tox, il quale:

  • creerebbe una nuova istanza di Discourse
  • eseguirebbe vari test
  • distruggerebbe l’istanza di Discourse

Assumendo un’installazione multisito, la creazione di un utente amministratore approvato e di una chiave API amministrativa può essere eseguita con:

  • docker exec app env RAILS_DB=secondsite rake 'api_key:create_master[MYKEY]'
  • ( echo user1@example.com ; echo $pass ; echo $pass ; echo ) | docker exec -i app env RAILS_DB=secondsite rake 'admin:create'

Nota: se non si tratta di un’installazione multisito, basta rimuovere env RAILS_DB=secondsite.

Quindi verificare che funzioni con:

curl -X GET https://forum2/admin/backups -H "Accept: application/json" -H "Api-Key: 886171a73dd12759b5d6c1915b0f0d4475e8b3fff3d97954b95171200b6" -H "Api-Username: user1"
[]

(grazie speciali a Jay Pfaffman per l’ispirazione)

Una volta completata questa operazione, Discourse non richiede più l’esecuzione della procedura guidata, anche se continua a indicare che dovrebbe essere eseguita.

Guadagno una parte significativa del mio lavoro facendo importazioni. Sono abbastanza certo che quanto descrivo di seguito sia più o meno come opera chiunque faccia importazioni regolarmente.

Ciò che consiglierei è:

  • configurare ed eseguire l’importatore
  • verificare che faccia ciò che desideri
  • creare uno script per rieseguire l’importatore e importare i dati acquisiti dal primo avvio
  • verificare che funzioni
  • eseguire l’importazione finale quando tutto quanto sopra funziona
  • ripristinare quei dati sul tuo server di produzione

L’attività di migrazione e quella di configurazione del server di produzione sono completamente diverse e hanno requisiti differenti. Di solito l’attività di migrazione richiede cose che il server di produzione non necessita (ma credo che l’importatore mailman sia un’eccezione).

Eseguire una migrazione su un server multisito sembra particolarmente avventato.

3 Mi Piace

Grazie per il consiglio, seguirò questa procedura. Ci sono oltre 100 GB di archivi mbox, saranno necessari almeno alcuni test.

Riguardo a questo… sembra che l’importatore mbox crei sempre una nuova categoria e non sia in grado di utilizzarne una esistente. Sai qualcosa a riguardo?

Non conoscevo il significato di avventato: mi piace e lo userò di nuovo :slight_smile:

È un motivo in più per cui rieseguire l’importazione da zero è una cattiva idea. Probabilmente richiederebbe settimane. Quando riesegui l’importatore, vengono importati solo i nuovi dati (e spesso lo modifico per saltare completamente i dati vecchi).

Puoi probabilmente modificare lo script per utilizzare una categoria esistente creando un CategoryCustomField. Ti consiglio di iniziare semplicemente con un database vuoto e lasciare che lo script lo crei; potrai poi personalizzarlo come preferisci e, quando riesegui lo script, continuerà a utilizzarlo.

2 Mi Piace

Il vero pericolo del tuo import è che è probabile ci siano differenze nei dati nel corso degli anni, quindi ciò che funziona per dati vecchi di 10 anni non funzionerà per quelli di 5 anni e così via. Ma forse avrai fortuna.

3 Mi Piace

Mi ha fatto riflettere…

1 Mi Piace

Non so se sia un complimento :wink:
Utilizzo sempre il multisite per le importazioni. Permette a più forum di coesistere: uno su cui sto lavorando mentre il cliente può revisionare l’importazione nel forum adiacente. Inoltre, è facile copiare un database per ripartire da un certo punto.

2 Mi Piace

Aspetta… cosa!?

Beh, lasciami cadere dalle nuvole! Sei praticamente l’unica persona al mondo che non lavora per CDCK di cui penso che sappia più di me sulle importazioni, e se usi il multisito per le importazioni, beh, allora prenderò in considerazione di fare lo stesso. Di solito avvio container separati sullo stesso host con traefik davanti, quindi immagino sia in qualche modo la stessa cosa, ma non proprio.

3 Mi Piace

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.