Contents |
As part of the EasyNeuf project, we want to make extension keys (dongle) embarking appliactions to extend gate functionalities.
This is a commercial approach and the following constraints must be respected :
The main idea is to put a easykey.cfg (this file can be renamed) file in the dongle filesystem root, this file will allows :
The system integration is mainly done by minihal and the used environment. Two cases are possible:
A simple system of keys/values is preferred. The idea is to seperate the different applications to facilitating the update can be found on this file structure:
[easykey] id = games1 name[fr] = Games extension icon = games.svg version = 1 [application1] id = tremulous file = applications/tremulous.desktop version = 1 [application2] ...
.desktop files will be used to integrate the software to the system. Notably, we can modify 9panel and add one more argument to find the .desktop files in the directory of the USB key.
No need for games but for future applications, the /usr/bin/mime-handle program will take into account the .desktop files of the key and if possible remember to ask the user to insert the key if it is not present.
Dongles have to be doivent être auto-containers and must not use system ressources. So we propose that all applications of a dongle have to be executed in an auto-contained chroot. To allow system integration of backup and highscores or configuration files, we propose to mount the directory */home/$USER* and the directory */var/games* (for example) containing gate global hi-scores or others...
We propose the following organisation for each dongle:
o--+-- easykey.cfg
|
+-- icons/
|
+--+ applications/
| |
| +-- *.desktop
|
+--+ system/
| |
| +-- lib/
| |
| +-- bin/
|
+--+ components/
|
+--+ tremulous/
| |
| +-- bin/
| |
| +-- usr/share/...
| |
| +-- ...
|
+--+ wesnoth/
|
+-- bin/
|
+-- usr/share/...
|
+-- ...
Execution of each application will be done by invocate a script placed on the *system*. So it will be necessary to have an updated gate to execute applications from the dongle (the update must be planned before the dongle commercialisation). Execution configuration for each application will be done by .desktop files present on the dongle.
Example of .desktop fiule
[application] id=tremulous name=Tremulous program=/bin/tremulous description[fr]=Fight game between marines and aliens
Then, we will use a script nearly like this one (disclaimer: not tested yet) on which we will put the .desktop file as an argument. For example: /usr/bin/run-app.sh /path/to/dongle/applications/tremulous.desktop.
#!/bin/sh application_program=`grep -i '^Exec=' $1 | sed -e 's/^.*= *//g'` application_id=`grep -i '^id=' $1 | sed -e 's/^.*= *//g'` mount --bind /home/$USER /path/to/dongle/home/$USER mount --bind /path/to/dongle/$application_id /path/to/dongle/system/$application_id chroot /path/to/dongle/system $application_program [...] # Verifying that the program is well executed umount /path/to/dongle/home/$USER umount /path/to/dongle/system/$application_id
The idea is to have a dongle update utility directly in the gate which one will be executed manually by the user. Idealy, we download a set of .tar files, we uncompress it in the directories of key components.
Openssl signature (a certificate must be present on the system for verification). This certificate will have a long lifetime to allow a rotation by updating the gate on the day it expires.