doc: multi-domain installation example on Debian

[bbmt-bbmt]

Documentation pour une installation avancée de pytition. Cette installation permet de mutualiser le code sur plusieurs domaine. Ainsi la mise à jour du code se fait de manière plus simple. La configuration de chaque domaine est mise dans /etc/pytition. Un script bash de mise à jour globale est donné à la fin de la doc.

[bbmt-bbmt]

J'aurais besoin d'aide pour finir cette pull-request.

• [ ] Traduction complète en anglais
• [ ] amélioration du style pour être en adéquation avec le reste de la doc

[fallen]

Merci pour la documentation, c'est une excellente idée de documenter cet usage de Pytition. Je vais faire les propositions de traduction dans les commentaires de revue de code :) Si tu penses qu'il vaut mieux qu'on s'y prenne autrement (pad ?) n'hésite pas à me le dire ! Merci !

[fallen]

Some notes:

• Don't forget to add advance_install in doc/index.rst
• You need an empty blank line after each .. code-block:: bash line
• You can test that your RST/sphinx syntax is correct and check the result by sourcing your virtualenv, and doing:

  cd doc
  make html
  firefox _build/html/index.html

Also, I'm curious, what is the purpose of the "admin" install? I understand that the admin unix user is there in order to run the update commands for all installed instances of the organizations. But why having a specific Pytition instance run by the admin user?

Thanks so much for all your help, it's very appreciated :)

[bbmt-bbmt]

Si on veut utiliser la commande manage.py update, il faut être dans un contexte django "valide" et donc il nous faut une instance valide mais pas forcément en ligne. On peut utiliser une base sqlite3 pour ne pas dépendre du réseau avec une base mariadb. On aurait pu (je pense) utiliser le user admin avec l'instance pytition.orga1.org mais je préférais séparer les rôles. Ça me permet aussi de me connecter à l'instance admin pour vérifier que tout se passe bien ou pour investiguer sur un problème si je n'ai pas les mots de passe des autres instances.

De plus imaginons que mon script d'update utilise pytition.orga1.org et que cette orga me demande un jour de supprimer son instance, il faut que je pense à modifier le script d'update. Même si ce n'est pas grand chose, pas sur que j'y pense sur le moment (si c'est moi qui suis encore là, je trouverais vite le problème mais on peut penser que ça risque d'incomber à une autre personne que moi). Ça rend le trout un peu plus résilient.

Disons que ce n'est pas forcément obligatoire mais je trouvais ça plus propre de séparer les rôles et les instances et je trouve ça utile en cas de problème.(vision d'adminsys :-) )

A toi de me dire si c'est quelque chose à mettre ou pas dans la doc.

Je vais intégrer toutes les modifs en fin de semaine prochaine. Merci pour la traduction.

Amicalement, Olivier

[bbmt-bbmt]

Désolé mais il reste encore des parties en français que tu n'avais pas traduites.

[bbmt-bbmt]

Je pense que tout est bon. Merci pour l'aide.

[fallen]

J'aimerai bien rendre plus clair le fait que cette méthode d'installation est une méthode alternative pour fournir la fonction multi-user/orga de Pytition qui est déjà inclue dans l'installation classique (cloisonnement avec gestion des droits et pages de liste de pétitions, mais en effet ça ne donne pas la possibilité d'avoir une configuration différente par compte, il n'y a qu'une config globale). Que ce soit clair que ce n'est pas forcément LA seule façon de faire si on veut pouvoir héberger plusieurs utilisateur-ices / organisations. J'avoue que je ne sais pas trop comment organiser la doc (niveau découpage en pages, et en titres) pour que ce soit clair. Si tu as une idée @bbmt-bbmt ^^ :) Ça me gêne un peu de merger tel quel. Désolé d'avoir pris tant de temps avant de formuler le retour.

[bbmt-bbmt]

Pas de souci. En fait mon objectif n'était pas de faire d'une autre manière la partie multi-organisation de pytition mais de pouvoir gérer du multi-domaine avec donc une base de donnée bien séparé par domaine. Chez nous chaque organisation ayant son propre domaine peut vouloir héberger son logiciel de pétition dans un sous domaine qui lui appartient. Plutôt que faire une installation par domaine et donc de gérer chaque mise à jour par domaine, j'ai mutualisé tout ce qui est possible pour facilité le travail.

Peut-être qu'un titre du style "Multi-domain installation example " serait plus approprié?

Amicalement, Olivier

[fallen]

Peut-être qu'un titre du style "Multi-domain installation example " serait plus approprié?

Oui je pense que c'est plus clair en effet :) Merci pour les précisions !

[fallen]

Je te laisse faire la modif avant que je puisse merger ?

[bbmt-bbmt]

Normalement, ça devrait être bon Amicalement, Olivier

[fallen]

Super ! Merci et encore désolé pour le temps de revue !