After rethinking the plugin functionality i realized that the current implementation does not reflect my requirements. It should be possible to upload plugins via WebUI (which are added to a local APT archive then) and the WebUI should also display plugins that are in the OMV package web archive. So i refactored the WebUI and backend to meet these requirements. It is only possible to install OMV plugins via WebUI (no other *.deb packages), so the packages must meet a naming convention, otherwise the backend denies uploading and installation.

Note, OMV plugins only contain the files required by the framework, e.g. the scripts, WebUI javascript and backend PHP files. The package(s) the plugin requires additionally are defined as package dependencies (get more informations here and here), this means the NAS box must have I-Net access to download these additional packages during installation.

Source: openmediavault-transmissionbt
Section: net
Priority: optional
Maintainer: Volker Theile <votdev@gmx.de>
Build-Depends: debhelper (>> 7)
Standards-Version: 3.6.10
Homepage: http://www.openmediavault.org

Package: openmediavault-transmissionbt
Architecture: all
Depends: openmediavault, transmission-daemon (>= 1.77)
Description: OpenMediaVault TransmissionBT (BitTorrent) plugin
 Transmission is a simple BitTorrent client that features a very simple and
 intuitive interface.

I do not plan to implement a special plugin package management that does not need network access to get these additional packages (which means the additional packages are included in one big file).

Today i finished the implementation of the plugin administration WebUI. Now it is possible to install and delete OpenMediaVault plugins via WebUI. The plugins itself a generic Debian packages. This makes it easy to handle package dependencies and the whole install/remove process.

The (really important) ‘About’ page has been already design 🙂

After becoming familar to Inkscape i created the new OpenMediaVault logo. Note, i’m not a gfx artist, so I hope you will like it anyway.

This weekend i finished to implement the Rsync service. OpenMediaVault will act as Rsync server if this is enabled. Also scheduled Rsync jobs are supported which can be local or remote, where remote also support the push and pull modes. The user permission thing is a little bit tricky for Rsync modules when acting as a server, but i think i’ve found a good solution where everybody will be happy. If a rsync server module is read/write enabled only users with read/write and read-only permissions are allowed to contact the module if this is not public/anonymous. If the module is write-only then only users with read/write permissions are allowed to use this module.

Thanks to the ability to execute commands asynchronously it is also possible to run a job from within the WebUI. For those of you that are interested how it works: There are several RPC methods (start/stop/content) to manage the async command execution and displaying the command output in the WebUI. It was a little bit difficult to find the best implementation because i did not want to give away sensible informations about the command from the backend to the WebUI, on the other hand is should be easy and clear to understand and use. At the end a token (currently the pid of the command) is used to identify the async running command in a RPC call. But stop, there are some additional security checks in the backend that ensure that a RPC can not be used to stop any running command on the server. The pid is used as key to access a structure with all necessary informations which is stored in session. So it is not possible to use this feature to attack the system.

The last days i implemented the feature to execute cron jobs or any other command from within the WebUI. This may be also used for file system checks for example.