Those two are not a problem. You can presume that both addons are working. If you encounter any issues we can help you solve them then
Docker GUI plugin now stable
-
- OMV 2.x
- nicjo814
-
-
Add a video, check the library, remove the video, check the library again.
ill correct the screenshot.
-
I've tested a little.
Adding a video to a source folder - watchdog recognize the new file and add an entry to the library.
Removing a video - no reaction by watchdog, the film is still in the library.
The forum post says: "Optionally, the library can be automatically cleaned when files are deleted." Where can I enable this option?
There is a removalmethod option in the /addons/service.watchdog/resources/settings.xml - this could be the right option to change.And I still have a little internet access problem.
When I powered on my OMV server today, the kodi container starts automatic but had no internet access. The /etc/resolv.conf was empty. I had to restart the container in the OMV/Docker web-gui to get the dns entry back in /etc/resolv.conf and then internet was working. -
-
The internet issue is really strange... Could test to fire up a new container in bridged mode instead of host mode and forward some unused ports to it?
-
Network mode: Host
Run image - internet access
Server restart - no access (empty resolv.conf)
Restart container - internet accessNetwork mode: Bridge
(0.0.0.0:8080->8080/tcp, 0.0.0.0:9777->9777/udp)
Run image - internet access
Server restart - internet access
Restart container - internet accessSo, it looks like there is a problem with the DNS when restarting the server in host mode.
-
Does eneybody test owncloud in docker? With MySQL and fail2ban?
-
-
-
That's intentional. Do you think it's the wrong behaviour? I haven't really considered what "should" happen when you disable the plugin....
-
I think the most logical way to a user is when all services have a nearly equal behaviour. I don't use many plugins or services, but I think most of them stopping the daemon and disabling the automatic start on booting the server, when disabling the service in the webgui.
So, to my it’s logical when:
- installing plugin - installs docker
- removing plugin - uninstalls docker
- disabling plugin - disables the docker daemon
But, it's only my opinion - would be better to hear some other (more important) ones. -
-
removing plugin - uninstalls docker
No, every time you uninstall a plugin the binary stays, imagine people on zfs or mysql having their servers or modules vanish because they removed the plugin.
disabling plugin - disables the docker daemon
The plugin all it does is communicate through the API, to interpret results and parse them into the webUI. Also to pipe commands and run containers. Again removing the plugin should only disable the API socket not stop the containers. Again imagine someone prefers to use docker CLI, removes the plugin, all containers down, nginx, sql servers, etc down because of the plugin? For me is correctly implemented
This is open discussion, another people might contribute also.
-
Actually, the way a debian package works is if you manually install the dependency (docker in this case) before the plugin is installed, the plugin will not uninstall it. If the dependency is installed by the plugin, it will be uninstalled by the plugin. There probably are some exceptions but this is generally how it works.
-
OMV targets home users, right? So, this way sounds right to me. The more professional users can install docker first and so they are protected against removing all containers by removing the plugin.
For me, the possibility to activate/disable the docker demon within the GUI would be nice.
In the moment no container is running and I don't need docker running, but will keep my containers. Disabling docker by using the CLI to looking for the settings the plugin made and change them is very sophisticated to an home user. -
-
-
It's in /etc/crontab . I'll add /dev/null redirection when I have some free time.
-
OMV targets home users, right? So, this way sounds right to me. The more professional users can install docker first and so they are protected against removing all containers by removing the plugin.
In general I agree with you, but I know that a lot of users have installed Docker manually before there was a plugin and I would not categorize them (or me) as professional users. Thus the change you're suggesting might cause issues for those users.OMV targets home users, right? So, this way sounds right to me. The more professional users can install docker first and so they are protected against removing all containers by removing the plugin.
For me, the possibility to activate/disable the docker demon within the GUI would be nice.
In the moment no container is running and I don't need docker running, but will keep my containers. Disabling docker by using the CLI to looking for the settings the plugin made and change them is very sophisticated to an home user.
I might have a look at this in a while, but for now my dev time is very limited. Also the Docker service is a real pain so I'm not very keen on messing with it again -
-
If this is for home users than I feel it's even *more* important that users are protected from screwing themselves over.
"What do you mean the Docker container I was using for my PhD dissertation is gone?"
In later news: divorce caused by clicking button in home server.
-
I've updated the stable release with some features from the testing release:
openmediavault-docker-gui (0.2.17) stable
* Add tooltips to the Run Container dialogue
* Add extra parameters field -
Just recently i trashed my 3 year install. I was carrying it since OMV 0.2, it was a "frankendebian" the last few weeks it wouldn't shutdown.
So i picked a btrfs root subvolume, debootstrap and i a had a clean omv running with shutdown and working suspend. I decided to move everything now to Docker, here is a list of currently running containers
forked-daap (by sparkyballs)
Flexget
Jackett
Nzbget
mysql (I gave up with the plugin finally)
Sonarr
plexmediaserver
fileBOT
kodi-watchdog
emby (sometimes to test it)So come and use the containers and create one, test another one, delete it, etc.... this what i think it could be useful in the webui.
1) Toggle status button, like a click to change in between docker ps; docker ps -a and docker ps --filter 'status=exited'
2) a search filter box in images and probably the containers also.
3) a copy to clipboard command button. Sometimes you still need to go to cli to run an container interactively. So it would be nice to have the command ready to paste. Of this i am not sure if the current framework supports this
-
-
May i ask why you want it to move it in docker, what is the advantage?
-
Move what?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!