Mount function |
-
Option to mount/remount all entries of an history
-
Option to unmount all mounted folders
-
Boot-surviving disk file mounting:
|
|
MEDIUM individually, HIGH in all
|
List function |
-
Option for displaying less columns option. Note: When used on command line,
the size of the terminal is not resized. it would be useful to have an option
(which may be the default one), to only display a restricted set of columns
like 'label', 'mount source', 'mountpoint'
-
To list incoming ssh connections (see 'who' command). To evaluate if really relevant
|
|
|
Inter-operability |
Propose alternate output for the list of mounts: e.g. JSON, YAML, XML.
This could be useful when output is used as input by other tools.
|
|
LOW individually, MEDIUM in all
|
Benchmarking function |
-
add a command to perform basic benchmarking on a mounted folder (transfer/copy speed rate)
-
Benchmarking from one mounted folder to another (bridged data flows)
-
Basic network performance measurement (maybe progressbar as alternate display to label?)
|
|
|
Log function |
-
--log could allow to filter the logs according to their log level.
-
timestamping of log entries
-
circular log with a max size configuration parameter
|
|
|
Dashboard |
-
upon a broken link, mountpilot may still hang. Broken/hanging link may be detected only when launching or after relaunch. A dynamic supervision of broken link may be useful
-
Positive selective filters: provide a solution to manage complex filters, define behavior, allowed actions, how history is managed then
-
Filter selection: it should be possible to change filter list while the dashboard is running.
-
Allow to force a lazy unmount in interactive mode too, e.g. via a new command key
|
-
MEDIUM for new feat.
-
LOW for improvs.
|
-
LOW for new feat.
-
HIGH for improvs.
|
Command line |
Changing directory to the mountpoint of a labelled device : e.g. sumo --cd BACKUP_ALL
|
|
|
Security function |
-
IP detection services to search for "mountable" devices on the network
-
configure auto unmount after a certain timeout or at a given time for data sources
-
to be able to send an alerts (e.g. email) if a specific mount gets lost , specify counter actions (auto-remount attempt?)
-
to be able to send an alerts (e.g. email) if any or an unallowed mount is done, specify counter actions (auto-unmount attempt?)
-
Provide support for active security rules enforcement (client-side), e.g. forbid the mounting of certain data sources, forbid outgoing SSH sessions, supervise data quotas.
On server-side, fine tuning is already possible (e.g. ssh config and allowed IPs), check if some basic common support could be added (e.g. forbid access to the calling client)
|
|
|
Diagnostic function |
|
|
|
Platforms |
|
|
|
Extended and New functionalities (high workload) |
-
Multi-host dashboard: Enable MountPilot to inspect other hosts and make it possible to display the dashboard for a selectable host
-
Integration with docker: make an extension DockerPilot to manage docker containers the same way
-
Integration with virtual machines: make an extension VMPilot to manage running VMs the same way
-
Integration with network: make an extension NetPilot to manage reachable hosts and devices, open ports, type of systems
|
|
|
Internal Architecture |
|
|
|
Swiss-knife extension |
Define an architecture for pluggable extensions, whereby new functionality can be added while keeping base functions untouched.
For example, a vault can be easily implemented as extension based on VERA volume.
|
|
|
Packaging & updating |
Basically, there would be a file for each one, mappping the original package names with the target ones and the relevant packaging tool.
The file selection would base on the output of a tool or a mix of different tools like lsb_release, uname etc.
|
|
|
Test |
-
Create a separate package 'sumo-test' gathering all test-related tools, files and input data used for the tests. Purpose is to make test replayable by anyone with no missing deps and questions left. For next release?
-
Formalize the test running sumo from a blank host within docker.
-
Think about a test in a blank env inside a VM. Docker is not well suited, because of the system limitations within a container.
|
|
|