1activegeek

Members
  • Content count

    32
  • Joined

  • Last visited

Community Reputation

1 Neutral

About 1activegeek

  • Rank
    Advanced Member
  1. 1activegeek

    unRAID OS version 6.5.2 available

    @bonienl - its fixed!! Just wanted to report that this has successfully been wiped out as a bug now. The proper view is being seen, the correct port mappings are listed where applicable, and all is great in the world. THANK YOU THANK YOU for fixing this. Really appreciate the effort to the small details like this. Keep up the great work!
  2. 1activegeek

    unRAID OS version 6.5.1 Stable Release Available

    @bonienl - agreed, and it should also NOT be showing the mapped ports as like I said those ports are NOT actually mapped to the host. So it's 2 things not showing correctly. I sent you a PM with the details you asked for here so as not to clog it up.
  3. 1activegeek

    unRAID OS version 6.5.1 Stable Release Available

    Sure thing. That's what I had thought from what you mentioned in that thread. Here is a screenshot, showing the same thing as last time - these are all showing ports that are not mapped locally, but are showing as such in the interface. Again, the actual ports are not open, so functionality is working correct and as expected. Let me know if you need any other details.
  4. 1activegeek

    unRAID OS version 6.5.1 Stable Release Available

    @bonienl was that fix for displaying the mapping on custom networks included? I linked the relevant convo below from the 6.5.0 release. I saw in these 6.5.1 notes it mentions the regression of Docker CE version, not sure if that affected the fix? In my case, still seeing the same incorrect output.
  5. 1activegeek

    Where does disk encryption stand?

    Excellent! So no further setup needed. This is great. Thanks again for the help. This gives me that warm and fuzzy accomplished feeling for today!
  6. 1activegeek

    Where does disk encryption stand?

    Just wanted to followup as I said I would. Took a little longer to get back to this as I had a few more things going on that took precedence. I did setup the basics of what you outlined here, I'm glad it was this simple! It did work out perfectly fine. So now I've validated that with the array set to automatically start on boot, the USB inserted, the array will start up perfectly without issue. I've not validated startup without the USB, but I'm fairly confident the result will be a failure to boot as it has been before creating this Go file entry. Thanks for the help! I was going to look into options for removing the key after startup now as a secondary effort. But as I thought about the method described here, there is a symbolic link created for the keyfile, vs copying over the keyfile. So outside of a reboot, the key should persist for subsequent mounts. But as soon as the USB device backing the link is gone, the file should/would be gone correct? So in this fashion, simply removing the USB should nullify the valid key's existence, correct?
  7. 1activegeek

    [Plugin] CA Appdata Backup / Restore

    Ok so to be sure I have no issue, I'll want to just re-create those scripts ensuring only LF endings. So I don't want to link to this directly. Thanks for the direction, and the great plugins!
  8. 1activegeek

    [Plugin] CA Appdata Backup / Restore

    Aha, ok cool. Glad I asked. I was thinking it was like an override. I would assume this means I should be able to easily link to scripts setup in the UserScripts plugin, just pointing to /boot/config/plugins/user.scripts/scripts/pause_statuscake/script for example?
  9. 1activegeek

    [Plugin] CA Appdata Backup / Restore

    So forgive me if this is mentioned somewhere, but my searches on this forum don't always seem to come up properly. Aka sometimes I see no hits when something exists. I wanted to see if there could be any clarity provided on the "custom start script" and "custom stop script" options. I'm trying to understand 2 things about these: Are these for custom scripts that run the backups? Like to override the scripts that are actually being used? Or are these intended to allow a user running a custom script at start/stop. Are the start/stop referencing the start/stop of the backup? Or the start/stop of the docker containers to process the backups?
  10. 1activegeek

    unRAID OS version 6.5.0 Stable Release Available

    Correct, that's what I was trying to illustrate earlier. It's all FUNCTIONING as expected, thankfully - but it's just utterly useless from a WebUI viewpoint. I can no longer tell what's mapped, what isn't type scenario. And it just threw me for a loop seeing ALL that data after I upgraded. Thanks for the help and for the quick update. I'll keep an eye out for the next update for sure.
  11. 1activegeek

    unRAID OS version 6.5.0 Stable Release Available

    Sooo ... is there somewhere I can go to get said update?! Or would it need to come in next version update? PS - damn that was quick!
  12. 1activegeek

    unRAID OS version 6.5.0 Stable Release Available

    Ok, but the "type" would equal the driver no? username@unraid:~$ docker network ls NETWORK ID NAME DRIVER SCOPE e862a38c5fe1 bridge bridge local 075df9b08ac4 bridge2 bridge local 0dfca2d1d148 host host local a09a118a7922 localnet macvlan local d5e104f60e1b none null local So why wouldn't it see bridge2 as a bridge? And the backstory to explain WHY I'm using this customer bridge - is for DNS name resolution of containers. Using link and other mentions of containers in descriptors is said to be deprecated, so I don't want to use deprecated mechanisms to connect my containers. I run about 30 containers. 24 or so, are run though nginx to expose their services. Using the non-default bridge, has DNS naming of containers enabled. So I can resolve the name of guacamole, cadvisor, etc from the nginx container. Traffic then no longer needs to flow out the docker network then back in through the host networking. It removes extra hops in transmission, removes an issue with macvlan connectivity on the SAME port, and reduces attack footprint on the system. So I'm EXTREMELY hesitant to move back to having to use the default bridge network - unless someone knows a way to enable dns name resolution! (I've not found a way)
  13. 1activegeek

    unRAID OS version 6.5.0 Stable Release Available

    Running this command shows nothing for containers that are not mapping their ports, as expected. Tried a container that IS mapping ports, and it shows properly. I think we're really digging into semantics that are not of importance. These have their own IP, because they are on the bridge. By default, docker will assign each container it's own IP. That has no bearing on MAPPING of ports. If I'm mapping a port on my host (which is what the mapped host ports sections shows) then I am trying to tie 443 for example on my HOST IP to 443 in my CONTAINER IP. So I don't think talking about the IP of containers is important here as they SHOULD have an IP. What I would expect to see differently with the IP info though, is that I should see something like 172.18.0.12:443 -> 10.0.10.22:443 for a port that is ACTUALLY mapped per the container config to the HOST. But I don't see this either. Some more details of 2 containers in particular one mapped, one not. Guacamole here IS NOT mapped to the host, is part of the bridge network and SHOULD get a 172.18.x.x IP. You can see the details screen has no Port mapping. cAdvisor here IS MAPPED to a host port of 8080 as can be seen in the settings/config as well, but it does also still have it's own IP as expected
  14. 1activegeek

    unRAID OS version 6.5.0 Stable Release Available

    Sorry I did not mention that, but these are all on Bridged network, so yes they are all attempting to run on the host IP. Either way, you can see from the command line, that they are not mapped. The docker service is clearly showing something different than the unRAID interface. I can tell you for a fact that unRAID is the one with incorrect information being shown in the interface. The command line docker service is correct. Edit: Adding network in view of first screen image for further validation
  15. 1activegeek

    unRAID OS version 6.5.0 Stable Release Available

    Not sure if I should post this here or post as an issue somewhere else? I've found what may be a bug in the display of the docker details. It seems the port mappings are for the most part incorrectly mapped. As in, the ports are actually NOT mapped to the host, but they are showing as mapped. I've tried re-building the container, but it still shows this way. I'm sharing screenshots here to show a list from the port maps screen, a sample from the main docker screen, and a view from the command line using `docker ps -a` to show the actual mapped ports. While it doesn't appear to be doing any real harm that I've found yet ... it is very difficult to understand what I'm viewing and see ports used for different containers. Docker tab main view: Docker container Edit screen showing mapped host ports: Command line view from terminal of docker ps -a output:

Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.