L'application étant programmée en Python (Django), il n'y a pas d'étape de compilation, les fichiers doivent juste être placés aux bons endroits et quelques répertoires créés avec les bonnes permissions. L'arborescence conseillée pour les fichiers est la suivante, c'est celle qui est prévue dans les scripts livrés et la configuration par défaut :
/opt/polynum |
répertoire de l'application |
/opt/polynum/polynum |
code de l'application Polynum (Django) |
/opt/polynum/bin |
scripts associés au projet |
/opt/polynum/virtualenv |
environnement virtuel contenant les modules Python spécifiques |
/opt/polynum/static |
fichiers statiques (images, scripts javascript, feuille de style CSS) |
/etc/polynum |
répertoire des fichiers de configuration |
/var/lib/polynum |
répertoire des données (dont les fichiers PDF) |
/var/run/polynum |
données d'exécution (PID du processus, sockets, etc) |
En outre, on doit disposer de :
Une base de données PostgreSQL est nécessaire. Elle peut être locale ou distante. Polynum devra disposer des droits suffisants sur cette base, y compris pour créer ou modifier des tables.
Pour les tests uniquement, une petite base locale en SQLite peut être utilisée. La configuration par défaut utilise une base /tmp/polynum.sqlite. En production, les performances de SQLite ne sont pas suffisantes.
Afin de sécuriser le fonctionnement de l'application, elle tournera avec un utilisateur dédié. Il sera le seul à disposer des accès nécessaires sur le système (lecture du fichier de configuration contenant des mots de passe, écriture sur le répertoire des fichiers téléchargés, etc).
Dans la configuration par défaut, l'utilisateur se nomme polynum associé à un groupe polynum.
L'application peut se lancer en tant que serveur web, mais pour des raisons de performance et de sécurité, il est fortement recommandé de la faire fonctionner derrière un serveur web classique (tel que nginx ou apache) qui gérera entre autre la diffusion des fichiers statiques de façon performante.