Hola,
Parece que es una pregunta frecuente y me disculpo de antemano si lo es: aparentemente no busqué lo suficiente 
¿Cómo podría escribir un script para hacer lo mismo que el asistente en lugar de hacerlo a través de la interfaz web?
Comenzaría con algo que se asemeje a el fixture de Fabricate(admin) de las pruebas de especificación. Y quizás se llame desde la sección personalizada del contenedor.
¡Gracias de antemano por su ayuda!
Wizard es la mitad configuraciones del sitio y la mitad llamadas a la API.
Para las llamadas a la API, puedes leer Cómo ingeniería inversa de la API de Discourse y para las configuraciones del sitio, sigue el ejemplo aquí:
Pero… tal vez ahí es donde me pierdo: para que yo pueda llamar a la API necesito una clave de API. Y por lo tanto, un usuario administrador… que no tengo (aún). ¿Es posible llamar a la API sin una clave de API? ¿O obtener una clave de API que esté desvinculada de un usuario y tenga credenciales de administrador?
Parece que debería usar rake:admin para crear el usuario administrador. Más bien, creo que el usuario administrador ya está creado pero no aprobado, por lo que necesitaría cambiarlo para que quede aprobado.
¿O tal vez puedo crear una clave API con api_key:create_master y usarla para crear el usuario administrador?
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'api_key:create_master[MASTERKEY]'
ad676e7413778aaaaa5d315c35f188591ef0edb4a4d4b2d644b9247a88421cfa
Pero parece que no termino de entender cómo se debe usar esta clave maestra, porque esto no funciona:
# 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"}
Sin embargo, si creo un usuario administrador:
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!
y luego uso la misma clave maestra especificando el usuario recién creado, sí funciona:
curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c358591ef0edb4a4d4b2d644b924b7a88421cfa" -H "Api-Username: loic"
{"category_list":{"can...
y tiene privilegios de administrador, ya que también puede acceder a /admin/site_settings/category/branding.
¿Qué estás intentando lograr exactamente? ¿Quieres automatizar la creación de un usuario administrador y configurar algunos ajustes?
Sí, exactamente. Quiero crear un nuevo foro desde cero y poblarlo con usuarios, categorías y temas, mediante un script que no requiera ninguna interacción con el navegador.
¿Quizás solo crear esa base de datos primero y restaurarla como parte del proceso de instalación?
No tengo ninguna base de datos: los usuarios, categorías y temas se crearán utilizando datos de mailman2.
Si deseas importar los datos, hazlo simplemente como un proceso separado.
Si hubiera sido un solo intento, estaría bien. Pero quiero poder probar el script de importación. Y para que la prueba se ejecute, primero debe crear un Discourse desde cero, sin requerir ningún tipo de intervención manual en medio de la prueba automatizada 
Para dar contexto, esto es parte del trabajo que estoy realizando para importar mailman2 a discourse. La prueba se ejecutaría desde tox, lo cual:
Suponiendo una instalación multisitio, se puede crear un usuario administrador aprobado y una clave de API de administrador con:
docker exec app env RAILS_DB=secondsite rake 'api_key:create_master[MI_CLAVE]'( echo usuario1@ejemplo.com ; echo $pass ; echo $pass ; echo ) | docker exec -i app env RAILS_DB=secondsite rake 'admin:create'Nota: si no estás en una instalación multisitio, simplemente elimina env RAILS_DB=secondsite.
Luego, verifica que funcione con:
curl -X GET https://forum2/admin/backups -H "Accept: application/json" -H "Api-Key: 886171a73dd12759b5d6c1915b0f0d4475e8b3fff3d97954b95171200b6" -H "Api-Username: usuario1"
[]
(agradecimiento especial a Jay Pfaffman por la inspiración)
Una vez completado esto, Discourse ya no requiere ejecutar el asistente, aunque siga mostrando que debería ejecutarse.
Gano una parte significativa de mi sustento trabajando con importaciones. Estoy bastante seguro de que lo que describo a continuación es prácticamente cómo lo hacen todos los que realizan importaciones de forma regular.
Lo que recomendaría es:
La tarea de migración y la tarea de configurar un servidor de producción son completamente diferentes y tienen requisitos distintos. Por lo general, la tarea de migración requiere cosas que el servidor de producción no necesita (aunque creo que el importador de Mailman es una excepción).
Ejecutar una migración en un servidor multisitio parece especialmente imprudente.
Gracias por el consejo, seguiré este proceso. Hay más de 100 GB de archivos mbox, así que se requerirán al menos algunas pruebas.
Respecto a eso… parece que el importador de mbox siempre crea una nueva categoría y no puede utilizar una existente. ¿Sabes algo al respecto?
No conocía el significado de foolhardy: me gusta y lo volveré a usar 
Esa es aún más razón para que volver a ejecutar la importación desde cero sea una mala idea. Probablemente tomaría semanas. Cuando vuelves a ejecutar el importador, solo se importan los datos nuevos (y a menudo lo modifico para que omita por completo los datos antiguos).
Es probable que puedas modificar el script para usar una categoría existente creando un CategoryCustomField. Recomiendo empezar con una base de datos vacía y dejar que el script la cree; luego puedes personalizarla como quieras y, al volver a ejecutar el script, seguirá usándola.
El verdadero peligro de tu importación es que probablemente haya diferencias en los datos a lo largo de los años, por lo que lo que funciona para datos de hace 10 años no funcionará para datos de hace 5 años y así sucesivamente. Pero quizás tengas suerte.
No estoy seguro de si eso es un cumplido
Siempre utilizo multisitio para las importaciones. Permite que múltiples foros coexistan: uno que estoy modificando mientras el cliente puede revisar la importación en su vecino. Además, es fácil copiar una base de datos para reiniciar desde un punto determinado.
Espera… ¿qué!?
¡Vaya, me dejo caer con una pluma! Eres casi la única persona en el planeta que no trabaja para CDCK de la que creo que sabe más sobre importaciones que yo, y si usas multisitio para las importaciones, bueno, consideraré hacer lo mismo. Por lo general, activo contenedores separados en el mismo host con traefik al frente, así que supongo que es algo parecido, pero no del todo.
