Weavus

Members
  • Posts

    21
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Weavus's Achievements

Noob

Noob (1/14)

0

Reputation

  1. Did this ever get resolved? I also see the same behaviour on viewing Docker logs and consoles.
  2. Anyone able to run this behind nginx and actually get the Alexa skill to communicate with it? I’m getting SSL errors as it seems AWS does not like letsencrypt certs and even uploading the full pem as a self cert certificate still prevents the skill from successfully being able to connect.
  3. I have the VLAN listed in my Docker settings as shown above and br0.5 is listed on the Docker settings page. However Docker network ls or the 'Network Type' dropdown on container templates is not showing it.
  4. Having trouble getting br0.5 showing up in the Docker 'Network Type' dropdown. I only see br0. Network Settings Enable VLANs: Yes VLAN number: 5 Interface description: Docker VLAN Network protocol: IPV4 Only IPv4 address assignment: Static IPv4 address: 192.168.5.0 IPv4 default gateway: 192.168.5.1 Routing Table IPv4 default 192.168.1.1 via br0 1 IPv4 default 192.168.5.1 via br0.5 2 IPv4 172.17.0.0/16 docker0 1 IPv4 192.168.1.0/24 br0 1 IPv4 192.168.5.0/24 br0.5 1 IPv6 ::1 lo 256 IPv6 fd00:0:0:1::/64 br0 256 Docker Settings Docker version: 18.09.6 Docker vDisk location: /mnt/cache/docker.img Default appdata storage location: /mnt/user/appdata/ Docker LOG rotation: Enabled Preserve user defined networks: No IPv4 custom network on interface br0: Subnet: 192.168.1.0/24 Gateway: 192.168.1.1 DHCP pool: 192.168.1.128/26 (64 hosts) IPv4 custom network on interface br0.5: Subnet: 192.168.5.0/24 Gateway: 192.168.5.1 DHCP pool: 192.168.5.128/26 (64 hosts) Docker Network LS NETWORK ID NAME DRIVER SCOPE 92afbb695547 br0 macvlan local 37e5ee6e805d bridge bridge local ea7a550c1b45 host host local bd960ef7eb26 none null local Any ideas why I can't see br0.5 in Docker network ls or the dropdown? I've tried running 'rm /var/lib/docker/network/files/local-kv.db; /etc/rc.d/rc.docker restart' but that didnt help. Any ideas?
  5. Speed. https://nzbget.net/choosing-cipher recommends using RC4-MD5
  6. It stopped working because RC4 is not included in the container. openssl ciphers -v doesn't show any RC4 Thanks for the info. Any advice on which cipher I should be using going forward or best to leave it blank until RC4-MD5 is restored?
  7. Overnight my container was updated to "25.02.19: - Rebasing to alpine 3.9" and I'm now getting the following error for all of my newsservers: TLS handshake failed for nl.newsgroupdirect.com: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure TLS handshake failed for news.tweaknews.eu: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure TLS handshake failed for sslreader.eweka.nl: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure If I leave the cipher empty in the newsservers configuration of nzbget then everything works fine. Why has RC4-MD5 stopped working all of the sudden with the rebasing to alpine 3.9 and no change the the nzbget code?
  8. Thanks bonienl, I'll give that workaround a go and see if that works for me until a proper way of handling this advanced use/edge case is provided in a future release. EDIT: Can confirm, commenting out those 3 lines and adding the file to flash and copying it via the go file means my custom docker network was preserved and my containers auto started as expected using the old custom network after a reboot. Thanks again for a speedy workaround idea.
  9. Could we have a Docker GUI setting to skip the removal of any manually created macvlan?
  10. Sorry, I was mistaken, when rebooting Unraid/Docker recreated br0 which is using the gateway 192.168.1.1 which means I cant recreate my localnetwork network as it can't use the gateway while br0 has it until I manually delete br0 and recreate my localnetwork network. My eth1 interface does not have an IP address assigned so nothing is automatically created on startup for br1. How is 6.4 supposed to work with two network interfaces to achieve what I want, i.e. my containers having their own assigned IP in my 192.168.1.x range? Am I missing something as to how its supposed to work in 6.4 to do this automagically? Right now I can't see how the automatic wipe existing/create new is helping me so is their a way to tell Unraid/Docker not to blow my self-created network away when it restarts? Thanks
  11. Excellent write up, thanks! I've followed this (using the same network layout as I was already using 192.168.1.x) and its working great for my containers however when I stop / start docker the localnetwork is deleted and I have to manually recreate it and then manually start the containers. Also, the last time I rebooted unraid (6.4.0_rc20a) it also recreated br1 which I had to delete from docker before I could recreate localnetwork. Is it supposed to save this network in the docker.img? If yes, any idea why mine isn't being saved and I'm having to recreate it each time? If not, is there a best practice way of automating the recreation of the network and starting of the containers?
  12. Add the following to Extra Parameters in the docker template to get it working: --dns 127.0.0.1 --dns 8.8.8.8
  13. Having the same issue with single NIC, bonding = no, bridging = yes