• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About 1activegeek

  • Rank
  1. 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.
  2. 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!
  3. 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)
  4. 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 -> 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
  5. 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
  6. 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:
  7. Aha! Thank you jonathanm! That helps. Wasn't aware I had to do it that way. All set now.
  8. Thanks ken-ji, that's what I'm doing right now, though I just leave it for bridge. The --net=bridge2 setting I use will override it anyway on creation. I just wish these additional networks could be saved. It shouldn't happen often, but I'd imagine things like OS updates in the future and possible upgrades to the docker core system could possibly wipe these out. Additionally if there is a loss then I would need to re-create them. It's not extremely difficult, just would be a nice to have. I'll mark this as resolved. Whoops, I guess that's not an option here. Oh well.
  9. Got it, I was thinking more about understanding the code that was used for presenting the data inside of unRAID. I figured weeding out individual bridge networks would be more difficult. Unfortunately, my use case wouldn't work as well using macvlan based networking. I'm using the bridge network to let docker do its normal networking for containers, but provide name resolution which the default network does not. If I switch to macvlan, I expose the containers to the local network which I do not want to do at all.
  10. Ahhh, ok that would explain it then. Anywhere you can point me to the code that looks for macvlan, so I can look at possible adaptation for bridge networks as well? Thankfully I only have the one, but would be nice to be able to have it save these custom networks as well.
  11. Thanks @bonienl for the followup. Perhaps this has something to do with the way the "custom" networks are being discovered then? Here is my Docker settings in UR: But you will notice here, that I have another customer network named "bridge2": But this custom network is not showing up: Perhaps I needed to elaborate on the custom network not being picked up here. ;o)
  12. Coming to bump this topic from about a month ago. Haven't seen any responses. I'm hoping someone can help shed some light. I recently had to go through a cache upgrade, and in doing so I lost the configured docker networks. I was expecting this would have saved them, but to no avail as well. Happy to test and help resolve as this is an important feature that I do in fact utilize.
  13. Where does disk encryption stand?

    I hear you there! We've gradually lost the basic things that enabled SOOO MUCH! I think if there would at least be an option similar to that (and I think there is via script) I should be in good shape for my desired workflow. Hopefully this weekend I can finally get into testing it out. I'll be sure to report back/share my findings.
  14. Where does disk encryption stand?

    I'll just add, I wasn't meaning to bring into question a debate around the utility of the function. As mentioned, different levels of risk are acceptable for different folks. So apologies if this has derailed some of the conversations around the purpose or intended use. For me, flexibility in this capability is key because of it's inherent risks/reward setups. The infrequency of use could also be problematic if you use a long phrase and forget it, vs a file being supplied locally. For key strength - yes this is my main point. The encryption is only as strong as the key used. In this case my key is a 4k keyfile - stronger than any long password you're likely to remember or even want to enter to start an array. It also has the advantage of using random data vs strict alphanumeric characters. Keyfiles also remove the ability of any type of MITM attack on a browser locally or malware on a device monitoring keystrokes. Because it can be supplied directly on the system, the only attack vector is direct attachment to the host.
  15. Where does disk encryption stand?

    Not sure I understand. You mean if I had a disk that I wanted to format, the keyfile needs to be supplied first? I think that would be fine, I'd only want that in rare instances. And in this case, I just want to ensure the key doesn't reside on the server itself to allow for mounting if I was to unmount the array. The idea here is if I need to set the drives encrypted - I can stop the array and destroy the USB keyfile. Or just reboot and pull the drive, pull the plug pull the drive, etc. As I say this, also makes me think there is a further level of plausible deniability here. I don't believe you can tell by analyzing the LUKS headers if there is a physical file vs a passphrase present in the slots. I believe it will only indicate that x/8 slots are used/available. So theoretically, assuming nobody can prove the disk exists, it could just be a password.

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