New idea

[SamMousa]

Hi, I'm new to OMV but have experience in docker. I was thinking about creating a generic plugin that would allow all docker containers to be used as plugins.

1. Install docker
2. Install portainer.io (basically this is a docker manager that would do the same as OMV-docker-gui currently does)
3. Configure it so that OMV is a reverse proxy that handles the authentication.

In my opinion this would have several advantages:

1. Run any container as an OMV plugin
2. No need for OMV-docker-gui to reinvent the wheel (or keep reinventing it)

What do you guys think of this approach?

[ryecoaaron]

I'm always open to new ideas. As for running a container as an OMV plugin, how would you do that?

[SamMousa]

http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

Combine that with an OMV plugin that returns the sign in status. Then add a generic rule to nginx for routing. Like host/container/ABC forwards requests to port 80 of container ABC after auth

[SamMousa]

I've got it working like this at the moment:

1. Container tutum/hello-world (simple http server on container port 80)
2. No container port forwarding
3. Following config in /etc/nginx/openmediavault-webgui.d/hello.conf:

   location /hello {
   auth_request /auth.php;
   proxy_pass http://172.17.0.2;
   }

4. Then I created /var/www/openmediavault.php/auth.php by ripping some lines from rrd.php:

   require_once("openmediavault/autoloader.inc");
   require_once("openmediavault/functions.inc");
   try {
   $session = &\OMV\Session::getInstance();
   $session->start();
   $session->validate();
   } catch(\Exception $e) {
   http_response_code(401);
   die($e->getMessage());;
   }

This works correctly; when I'm not logged into OMV I get 401, otherwise I get the hello world page.

Todo:

• Discover IP / port of container.
• Create path alias based on container labels, that way you just add a label like OMVpath:hello.
• Optionally add support for alternative ports to remove the need for path rewriting, like OMVport:12345.
• Regenerate nginx config when container changes are detected.

I think this is a viable and scalable approach that will:

• Reduce the plugin maintenance workload (plex is already released as a container, no need to release / package it as an OMV plugin)
• Increase the number of plugins, since any container can simply be used as an OMV plugin.

[ryecoaaron]

Sounds cool. Do you plan to have anything in the OMV web interface to support each container or would everything be done from portainer?

[SamMousa]

Well the idea is that containers provide their own interface (as many of these kinds of tools do, think: transmission, portainer, plex). The minimum UI should be links to open their pages in new windows. We could also load them in iframes but that might not always work optimally. Of course since we are on the same origin we can do some nifty resizing stuff with JS.

[SamMousa]

Side note, it would make sense to add configuration to OMV for changing the directory docker uses, since I can imagine that many OMV users have their OS on a small partition / USB stick.

[ryecoaaron]

That is fine. I just wouldn't say it is creating "plugins" for each docker since there is really nothing in the OMV web interface for the docker. It is definitely adding services which reducing the need for making plugins and that is fine in my book :)

Just to warn you, due to the OMV nginx config itself (which is difficult to change), iframes can be a pain.

[ryecoaaron]

The directory option would be very good because there are a lot of people who fill their OS partition.

[SamMousa]

I agree, plugin might not be the right term, integration might be better. :) I have no clue how to build OMV plugins though, they seem to be packaged. Do you have any links to tutorials for OMV 4? Or do you recommend just copying a small existing addon and editing that where needed? Why is OMV nginx difficult to change? I can just write my own files to /etc/nginx/openmediavault-webgui.d/ and OMV won't touch them, right?

[ryecoaaron]

Here is the guide: https://github.com/skyajal/diypluginguide3.x I would definitely look at other plugins as well.

As for the nginx config, it is only difficult to change OMV's web interface to allow iframe due to the security model of the web interface's site. There is a environment variable that helps but it doesn't fix all iframe proxy sites. See this code - https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/usr/share/openmediavault/mkconf/nginx.d/10webgui#L156 If you are creating your own site, then it is easy but that doesn't help put an iframe in the web interface.

[SamMousa]

I don't think there will be a problem regarding iframes. X-Frame-Options only applies to the client page. So you're not able to load OMV inside an iframe. But since it is set to SAMEORIGIN by default (or one of my plugins changed it), it should be fine.

[ryecoaaron]

We have a few plugins that put their web interface in the plugin and they have issues. calibre, virtualbox, etc are examples. That is why I started removing the iframe component from the plugins I maintain.

[etique57]

I'm just transitionning to OMV from my current ubuntu server, and that is an approach that I would like to see go through!

[SamMousa]

@etique57, for now i've worked around it like so:

1. install docker
2. install portainer

then i run all things docker via their own port and use it's own security or none at all.

This is less than ideal but at least it gives me more control.

[etique57]

ok then I'm at the same level :) the integrated auth was appealing though.

I don't want to hijack this thread, but it's more or less related... How do you make the data persist in the portainer container?

[SamMousa]

I don't want to hijack this thread, but it's more or less related... How do you make the data persist in the portainer container?

http://portainer.readthedocs.io/en/stable/deployment.html

Specifically note the -v ... argument which creates a volume and thus persistence.

[etique57]

Works like a charm (and I should RTFM). Thanks.