Posts by anderbytes

    Thank you for your efforts... and let's hope someone steps forward to maintaining this.

    If I had some spare time, I would, because it really seems as simple as understanding the WebGUI framework, and about all the commands and parameters of docker command line.

    About commands IMPORT/EXPORT, I can see a very fair use related to backup and restoring containers... for that, a TARBALL is just perfect.

    1. Export whole container as a Tarball (uncompressed)
    docker export -o test.tar CONTAINER_NAME

    2. Import tarball file as a new container
    docker import test.tar

    3. Rename a container's name

    4. List the processes runnings (runs PS inside container)
    docker top CONTAINER_NAME [optional ps parameters]

    --- VOLUMES ---
    I also understand from command line that each volume created with VOLUME CREATE could can be assigned a NAME and LABELS. Why are the labels all NULL and names so random? Isn't it possible to determine their name during creation based on the CONTAINER name and added "_" and then something at the end? this way you could see in DOCKER VOLUME LS which volume is from which container, and then use comands as DOCKER VOLUME CREATE and DOCKER VOLUME RM to allow some future editing (inserting, removing...) of volumes without the need of recreating everything.

    --- NETWORKING ---
    About networking, I understand that each time a new container is added into a network (example: a bridge), you have to recreate the whole network... that's what I understood from the command line. OK for now... but if that's how it works... why can't you make possible to edit existing networks? What if we forget a port in a container?

    Right... every time any little change will be made in a existing network (inserting or removing ports, for example), the whole network is remade, but there's no actual downside in doing that. Am I wrong?

    About upgrading the image and distributing it to related containers, I understand that docker doesn't natively supports a command to do that. But that doesn't mean it can't be done.

    But...think with me... plugin knows all the containers configurations... we know it has today to be done manually... Nobody blocks you from scripting the existing manual process of:
    - Checking if the image's version is newer than the container's.
    - If YES, continue, if NO, stop right here and warn the user.
    - Stop the container
    - Save it's configurations (volume mapping, environment variables, ports, parameters, name, everything!!) in memory
    - Delete this old container
    - Recreate a new container with the new image, PLUS all the configuration saved above, exactly all of them
    - Start the new container

    Thanks for your attention!

    Not being able to edit containers was a limitation of docker itself when the plug-in was developed. I'm not sure if it's possible with later versions of docker.

    I promise that one of these days I'll stop to take a look and compare:
    - What commands/subcommands exists in Docker command line that is installed
    - Which of them are implemented
    - Which of them are not

    I'm loving Docker so I want to help.
    My next post here will be with those info (and whether there are things to implement or not)

    It doesn't work here, don't know why.
    I Guess the auto-update feature works OK in Windows version... but never saw it working in Linux.

    There's even a message in Dashboard telling that there's a update available, but that it has to be done manually. :-/

    Also, when a container is stopped. can't be made possible to edit it's details? To add more volumes, add a environment path... ?

    There's one important feature missing in Docker plugin, and I guess it's fairly easy to implement.

    We have to be able to choose if the mount of the container path will be READ-ONLY (inside the container) or not...

    The command below shows how to do it:

    docker run -v /path/on/host:/path/on/container:ro my/image

    the ":ro" tells it to mount as read only. Simple, right?

    No, you should not lose any meta data. This plugin is getting things from 4 places. The plugin is from one of the OMV Extras repos. Mono is coming from a Xmarin repo. Emby is coming from a Emby's github. And there are some libraries I built, for various cpus, coming from my Github.

    GOD I'm dumb.

    I confused thinking that "FORCE UPDATE" would appear next to "Restart Server" but no... Now I rememebered that it is in WebGUI of OMV in Emby Server part.

    That worked. I Forced the update, restarted the server, the page, and I'm in 3.0.5821.0.


    The plugin has a force upgrade button. You click on that. Then a box pops up and you have to click on start. After it is done upgrading you will need to click on the plugins restart button. Then you will see the new version in the Emby UI.

    The FORCE UPDATE button is gone. I even forgot that it existed.
    My situation is similar to the seen in this screenshot I found in internet:…b3c2_2015112609_32_42.jpg
    from topic…ic/12906-freebsd-package/

    This is VERY important!

    Last January 20th Lets Encrypt put in prodution the long expected ACME DNS Challenge, where people like me that CANT (Damn ISP) open ports 80 or 443 , now are eligible to validate the domain via DNS server TXT record. It's actually MUCH easier than opening ports in my server.

    Official Let's Encrypt announe:

    Example of a shell-script client that supports it :….sh/blob/master/
    Others: https://community.letsencrypt.…ient-implementations/2103
    Example of a hook (auxiliary script used by above):

    External Content
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    PLEASE look into this!
    I've generated mine manually today, but having it as a plugin would be MUCH better, because Let'sEncrypt expires every 90 days.

    Thanks a lot!