Je suis à l’origine de la création d’OpenAguila, je suis donc assez mal placé pour juger de ses qualités et défauts, cependant d’après les retours des utilisateurs, le logiciel est apprécié pour sa simplicité ainsi que son pragmatisme concernant son utilisation. Une fois la philosophie de fonctionnement acquise, on est rapidement opérationnel. Ces qualités proviennent du fait qu’OpenAguila a été créé en partenariat étroit avec un chef d’entreprise, ce n’est donc pas un logiciel fait par des informaticiens pour des informaticiens.

OpenAguila a cependant aussi certains défauts criants comme la lourdeur d’utilisation de certains modules (approvisionnement, intervention), l’impossibilité de paramétrer facilement des éditions PDF (il faut rentrer dans le code XSL), le manque d’interfaces vers l’extérieur (import / export). De plus, sa réalisation a débuté à la fin des années 90, sa conception technique est vieillissante, ce qui rend la maintenance / les évolutions délicates.

Pour toutes ces raisons j’ai décidé une refonte complète de l’application. Cette refonte sera essentiellement technique (passage du langage JAVA à Python), la philosophie dont je parlais plus haut sera bien évidemment conservée, tout en essayant de gommer les défauts fonctionnels.

Pourquoi ce changement radical ?

• Le framework utilisé par OpenAguila est spécifique (fin des années 90, il n’y avait pas les outils web actuels), il faut entièrement le revoir pour pouvoir effectuer par la suite facilement des évolutions.
• Je me suis lassé de l’utilisation de Java que je trouve trop lourd / rigide. Lors de ma participation à un autre projet j’ai eu l’occasion de découvrir le langage Python ainsi que le framework web Django. J’en suis tombé amoureux…

Dis, OpenAguila2 va être livré quand ?

La réponse habituelle dans le monde des logiciels libres : « quand on aura fini ». Le travail est en effet gigantesque, le nombre de participants va être primordial. Pour l’instant quelques personnes se sont manifestées pour apporter de l’aide au projet (développement, tests, documentation), mais plus on est de fous, plus on rit. La compétence qui nous manque est un designer web, qui nous fasse des jolies pages (qui a dit comme pour tous les projets ?).

Si vous avez envie de participer à un projet libre, quelque soit vos compétences, vous êtes le bienvenu .

L’installation de Conky est très simple, elle se fait par votre gestionnaire de paquets favori. Pour le mettre au démarrage de votre gestionnaire de fenêtres, il faut éditer votre fichier $HOME/.xinitrc et placer tout au début par exemple :

(sleep 10 && conky) &

On ordonne par là de lancer conky en tâche de fond au bout de 10 secondes.
Pourquoi en tâche de fond ? Si vous ne le faites pas, la suite de votre .xinitrc ne va pas s’exécuter, donc autant dire que votre gestionnaire de fenêtre n’apparaîtra pas.
Pourquoi un délai de 10 secondes ? Ce délai dépend de votre configuration, mais il est nécessaire d’en mettre un sinon l’affichage de votre conky risque d’être écrasé par celui de votre gestionnaire de fenêtres.

vi ~/.gtkrc-2.0
style "xfdesktop-icon-view" {
XfdesktopIconView::label-alpha = 0
fg[NORMAL] = "#ffffff"
fg[SELECTED] = "#17B2FF"
fg[ACTIVE] = "#17B2FF"
}
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view


Voilà

Avec ArchLinux le procédé est très simple, il suffit d’éditer le fichier /etc/pacman.conf et d’ajouter le paquet à la ligne :

IgnorePkg = mon_paquet_a_ignorer

En fait cela ne fonctionnait pas avec Enlightenment alors qu’il n’y avait aucun problème avec Openbox. Bon c’était déjà ça, cela signifiait que ce n’était pas dû à Archlinux lui-même… En regardant dans les logs, je voyais que le périphérique était bien détecté. J’arrivais d’ailleurs à le faire manuellement en utilisant le compte super-utilisateur. Mais lorsque je cliquais sur l’icône de mon périphérique, j’avais invariablement une erreur du type PermissionDeniedByPolicy mount-removable no.
En cherchant sur Internet j’ai constaté que le problème venait de HAL (Hardware Abstraction Layer). Finalement je suis tombé sur cet article.
En observant mon fichier ~/.xinitrc, je me suis rendu compte que Enlightenment était lancé simplement comme cela :

exec enlightenment_start

D’après l’article cité précédemment, il faut le lancer de cette manière :

exec ck-launch-session enlightenment_start

La raison est (je cite) : « La dernière mise à jour de HAL a le support de PolicyKit et ConsoleKit activé, plus concrètement, les droits de montage/démontage, arrêt/redémarrage, mise en veille/hibernation sont donnés par défaut au propriétaire de la session (celui qui est connecté) mais il faut pour cela démarrer ConsoleKit avec votre session graphique. »

Prérequis :

• Slim est installé et opérationnel.
• Vous disposez de plusieurs gestionnaires de fenêtre installés (OpenBox, Enlightenment [e17]).

On va commencer par éditer le fichier /etc/slim.conf. Repérons ensuite la ligne commençant par sessions et ajoutons par exemple :

sessions e17,openbox

Ensuite dans votre répertoire $HOME, éditer le fichier .xinitrc. Faisons alors la correspondance avec les entrées du fichier /etc/slim.conf.

case $1 in
e17)
exec ck-launch-session enlightenment_start
;;
openbox)
exec ck-launch-session openbox-session
;;
*)
exec ck-launch-session enlightenment_start
;;
esac

Ensuite lors de l’apparition de la fenêtre de login de Slim, il vous suffit d’appuyer sur F1 pour choisir la session et ensuite rentrer votre nom d’utilisateur puis mot de passe.
Le *) du case permet de choisir enlightenment par défaut.

1) Dans votre settings.py, le processeur de contexte de template django.core.context_processors.request doit être présent en plus de ceux définis par défaut, ce qui donne :

TEMPLATE_CONTEXT_PROCESSORS = (
'django.core.context_processors.auth',
'django.core.context_processors.debug',
'django.core.context_processors.i18n',
'django.core.context_processors.request',
)


2) Dans la vue (views.py), il faudra passer un objet de type RequestContext si vous utilisez la méthode render_to_response, ce qui donne par exemple :

...
request.session['hello'] = 'world !!!'
return render_to_response('index.html', context_instance=RequestContext
(request))


3) Vous accédez à votre variable de session, dans votre template de cette façon :

value : {{ request.session.hello }}


En fait il y a 2 fichiers à modifier dans la configuration de PostgreSQL :

1) pg_hba.conf
host all postgres 192.168.0.0/24 trust

Vous autorisez ici n’importe quelle machine du réseau local 192.68.0.x à vous connecter à votre serveur en tant que postgres et sans fournir de mot de passe.

On peut être plus restrictif et autoriser une seule machine, par exemple :
host all postgres 192.168.0.10/32 trust

2) postgresql.conf

Ici il faut changer le paramètre listen_addresses (par défaut il est sur localhost).

listen_addresses = '*'

Cela signifie que si mon serveur à une adresse IP publique 88.89.90.91, je pourrais me connecter avec par exemple la commande :
psql -U postgres -h 88.89.90.91

On peut aussi être plus restrictif et indiquer quelle adresse pourra être spécifiée par le client appelant :
listen_addresses = 'localhost, 192.168.0.100'

Ici si j’essaye de me connecter par :
psql -U postgres -h 88.89.90.91
cela ne fonctionnera pas, je serais obligé d’utiliser, depuis ma machine distante :
psql -U postgres -h 192.168.0.100

Ne pas oublier de recharger la configuration de PostgreSQL :
/etc/init.d/postgresql reload.

Pour la rédaction de cet article, je me suis basé sur la documentation de Django. L’installation a été réalisée sur un serveur fonctionnant avec Debian Lenny.

Installation de WSGI

aptitude install libapache2-mod-wsgi

Paramétrage de l’application pour l’utilisation d’Apache

Pour ce faire créez par exemple un répertoire apache à la racine de votre site et ajouter un fichier nommé django.wsgi. Ajoutez les lignes suivantes :
import os
import sys
sys.path.append('/usr/local/src/django_apps/app/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'monprojet.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Adaptez les lignes 3 et 4 à votre projet. Attention la ligne sys.path.append contient le chemin vers votre projet, nom du projet NON compris.

Il faut ensuite ajouter à Apache le site développé avec Django. Ajoutez par exemple à votre virtualhost les lignes suivantes :

Alias /media/ /usr/local/src/django_apps/app/monprojet/media/

<Directory /usr/local/src/django_apps/app/monprojet/media>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias /monprojet /usr/local/src/django_apps/app/monprojet/apache/django.wsgi

<Directory /usr/local/src/django_apps/app/monprojet/apache>
Order deny,allow
Allow from all
</Directory>

• La ligne avec Alias permet de définir un chemin pour indiquer à Apache où aller chercher les fichiers statiques (images, css…).
• La ligne avec WSGIScriptAlias définit l’URL pour l’appel de votre site.
• Les directives avec Directory donnent l’accès aux répertoires à Apache

Voilà, ne pas oublier de recharger la configuration d’Apache.

/etc/init.d/apache2 reload

Stopper Apache

/etc/init.d/apache2 stop

Activer le module SSL

a2enmod ssl

Créer un hôte virtuel pour le site en https

Il faut pour ce faire créer un fichier dans le répertoire /etc/apache2/sites-available nommé avec par exemple votre nom de domaine : mondomaine.https

NameVirtualHost *:443
<VirtualHost *:443>
...
...
# add ssl protocol
SSLEngine On
SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
SSLCertificateFile /etc/ssl/certs/mondomaine.crt
SSLCertificateKeyFile /etc/ssl/private/mondomaine.key
</VirtualHost>


Ajouter l’hôte virtuel nouvellement créé

a2ensite mondomaine.https

Vérifier que le port 443 est bien autorisé

• Vérifier qu’il y a bien Listen 443 dans le fichier /etc/apache2/ports.conf
• Vérifier que ce port est bien autorisé par votre parefeu

Générer la clé et le certificat

Attention je fais ici la supposition que l’on génère soit-même le certificat sans passer par un organisme officiel. Un message de mise en garde sur l’authenticité du certificat sera affiché aux visiteurs de votre site.

Génération de la clé privée

openssl genrsa -out mondomaine.key 1024

Il n’y a ici pas de mot de passe associé (sinon il faut rajouter l’option -des3 à cette ligne de commande). Si on met un mot de passe, il sera demandé à chaque démarrage d’Apache.

Etablissement d’une demande de certificat

openssl req -new -key mondomaine.key -out mondomaine.csr

Création du certificat

openssl x509 -req -days 30000 -in mondomaine.csr -signkey mondomaine.key -out mondomaine.crt

Installation du certificat

mv mondomaine.crt /etc/ssl/certs
mv mondomaine.key /etc/ssl/private

Démarrage d’Apache

/etc/init.d/apache2 start