primeval_god

Members
  • Posts

    439
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by primeval_god

  1. Autostart works just fine. The scripts in the event directory are triggered by unRAID system events. This is not the case. The compose.manager plugin stores stack names in a file called "Name" in each stack directory. "$(cat $dir/Name)" reads the stack name.
  2. @OFark @bergi9 @spychodelics A new version is available that fixes the terminal style output for 6.10.0. A big thanks to @bergi9 for helping me track down the issue.
  3. This is already planned but not yet implemented.
  4. This plugin has a settings page, there should be a listing for compose.manager under the unraid setting tab.
  5. @OFark @spychodelics This plugin has not yet been updated to work correctly with 6.10. Until it is, set the terminal output style to "Basic" in the settings page that should restore functionality. I hope to have an update made in the next couple of days.
  6. Does /root/.docker/config.json exist on your system? From what i can see compose should grab credentials from that file, which is where docker login caches them.
  7. Thanks good to know, i havent yet tested against 6.10 as I still run 6.9. I cant find a good reason that this should be the case. Are any errors reported in the compose log?
  8. It just issues compose pull for now. At the moment this plugin doesn't really have any considerations for the build aspect of compose.
  9. I am aware of that option, though there is still the matter of the display discrepancy in the port listing. Overall this is not a major issue, but I still would like to see it as an improvement to dockerman.
  10. This is not necessarily true. If a host has more than 1 ethernet ports with separate IP addresses for each the docker port publishing syntax can be used to expose a port on a specific ip address. If no IP address is specified in the port mapping then the port is exposed on all interfaces. In a new setup i am trying i have the 2 ethernet ports with separate IP addresses. eth0 the primary host port on which the unRAID webui is exposed 192.168.0.44. And eth1 192.168.0.55 which the unRAID webui is not accessible on. Custom bridge networks are setup for each interface. If I spin up a container with a port mapping of 8080:8080 and connect it to either bridge network, the container is accessible from both 192.168.0.44:8080 and 192.168.0.55:8080. If I use a port mapping of 192.168.0.55:8080:8080 then the container is only accessible via 192.168.0.55:8080 and not 192.168.0.44:8080. Additionally specifying 2 containers with 192.168.0.55:8080:8080 and 192.168.0.44:8080:8080 respectively is possible with each being accessible from the specified IP address through the matching ethernet interface. I am not sure if this is a newer docker feature or if it has always been this way but it is definitely in the current version https://docs.docker.com/config/containers/container-networking/
  11. I am not sure if this qualifies as a bug report or an enhancement because this is the first time i am attempting to use this feature. Docker supports publishing a port to a specific interface by specifying the IP address of the interface along with the port in the docker run command (docker run -p 192.168.0.55:9090:8080/tcp). Dockerman allows adding the IP in the port specification of the template and correctly translates it to the docker run command, however the dockerman gui is not fully on board. On the docker page the containers port listing still shows the port mapped to the IP address of the primary host interface. Additionally (and more importantly) if the container has a webui address specified with a template 'https://[IP]:[PORT:8080]' dockerman populates the IP field with the primary host IP address rather than the one specified for the port mapping.
  12. Containers sharing layers should not be an issue. What kind of problems do you run into exactly? Does one just fail to start?
  13. Support for specifying WebUI and Icons via docker labels is coming i believe in unRAID 6.10. Likewise i plan on adding some functionality to this plugin to support automatically inserting the necessary labels into compose files.
  14. Probably because the plugin system is used to deliver updates to the OS, likely without any special cases to differentiate from updating any other plugin. As your screenshot shows there is actually an unRAUDServer.plg plugin file being used in the update process.
  15. No a USB drive is still required to boot unRAID. As far as i know the recommendations have not changed. USB 2.0 is still preferred. The reasons that i am aware of are that some (possibly older now) motherboards did not like to boot correctly from their USB3 controllers whereas USB2 worked fine. Additionally the controllers in USB3 tend to run hotter than USB2, and there is some concern as to how that effects life longterm especially for physically small thumbdrives. There is a PSA posted in the Announcements forum about Sandisk usb drives purchased from various vendors in recent months. The USB drive i have has been running very reliably for 5+ years now. That said my personal opinion, which has nothing to do with the flash aspect of unRAID, is that unRAID should not be used for business purposes, due primarily to the robustness of its security, slow patch cycles, and limited support options. For a home NAS its a Rockstar. Edit: Looks like Squid got here while i was still typing.
  16. Interesting, this should not be the case. Using compose pulls images into the local docker repo just like using docker directly. When restarting your system the image should exist locally and compose up should work just fine. What does your compose file look like?
  17. My guess would be that since the alpine repo you link to is a base image it doesnt have a useful entry point. Docker containers are not really designed to be full system containers, docker focuses on running a single main process within a containerized environment. The ENTRYPOINT and COMMAND fields in a dockerfile work together to specify what that process should be, without them a container wont start because there is in effect nothing for it to do. You can override the entrypoint at runtime (lookup docker documentation on specific flag then put it in the extra arguments field in the template) which would let you play around with the base image. The intended usage however would be to use the alpine image as a base for creating your own docker image. You would write a dockerfile with the alpine image in the FROM statement, add the dependencies for your desired application, then an ENTRYPOINT and CMD to specify how that application should be launched in the container when the container starts.
  18. It doesnt. What they are talking about is out of the scope of unRAID's web gui. They are not talking about things you do when running a docker container. "add RUN <commands> to my dockerfile" is something you do when creating a docker image. You would have to write your own Dockerfile using their image as a base image, add the suggested RUN commands, and then use the docker build command to build an image from that docker file. Then in the unRAID web ui you would run a container and in repository field specify the name of the custom image you built.
  19. Sorry to say, but i kind of doubt you will find the answers you are looking for on this forum. This sounds to me like a fairly complicated issue with docker networking rather than anything specific to unRAID. My guess is that the vast majority of unRAID users, even many of our guru types, have rarely if ever delved to the level of mucking around in iptables in docker (or in the unRAID os for that matter). What little i know on the subject amounts to the fact that docker uses iptables (somehow) in the construction of its container networks and the rules it creates dont always play nice with custom rules.
  20. Not sure, you might be able to disable "automatically protect new and modified files" after your initial build then modify a file and attempt a validation. Since the file is modified but its hash is not updated it should trigger an alert. Just be sure to reenable the setting afterword and rebuild the disk you modified a file on. Also word of advice since validation tasks run in parallel, with a lot of disks it is best to space validation out into several tasks that run at different times. For my 5 disks i run verification on one disk every friday (each disk is only verified every 5 weeks). Also a quick fyi for you and anyone who reads this post. Dont forget to check the help text for this plugin. Many people, myself included, forget that the help button in unRAID often reveals useful information, and many of our great plugin authors make use of it.
  21. After the initial build the plugin will watch your file system for any writes made your files. When a write happens it will refresh the hash of the changed file. Then every time the verification task runs it will recalculate all of the hashes and compare them to the hashes saved with the file. If it finds any that dont match it will send a notification (through unraids notification system) alerting you of the file with the mismatched hash. Additionally you can trigger a verification run with the buttons in the plugin.
  22. At this time I have no plans to support such a thing. Some of the core features of the plugin are currently based on the folder structure it creates in the plugin config directory on the flash drive.
  23. I dont use vlans myself so i could be wrong, but i dont believe that real networks are by default available as interfaces for a docker container. I think you would need to use the docker network create command to create a custom macvlan network that is attached to br0.10 for your containers to connect to.
  24. Actually such a network configuration is very common when it comes to microservice containers. The reason it may not seem to be as common with docker is that much of the containerization community has "moved on" from docker when it comes to managing multicontainer apps to more feature rich container orchestration tools like kubernetes (note moved on is a bit over the top as docker still underpins many of the orchestrators). So to the heart the issue, the unRAID platform integrated docker as a means to gain easily installable and sandboxed applications. The unRAID webui is focused primarily on supporting single container applications. Thusly there has been little need to support more complex networking schemes in the interface. That said, under the hood it is just docker and additional networks can be attached to a docker container with the docker cli. If you are determined to step beyond unRAIDs single container paradigm i suggest looking into the docker compose plugin for unRAID (full disclosure I maintain it).