Closed Bramblefoot closed 2 years ago
Thanks for the comments - much appreciated.
There shouldn't be any references to the 172.X
"docker network" IPs.
The project is meant to use the host machine IP for all references.
What individual container's or settings are you using the 172.x
IPs for/in?
I have had to use the 172 docker network in all my containers. A specific example is: I will sometimes go into overseerr to make a media request and the radarr/sonarr connection is down and I'm unable to make the request. The quality profile and root folder will not be available because it can't connect. This is caused by the container getting a new IP. This can happen to radarr/sonarr because they point to nzbget and deluge. Basically any connection can experience this. My way to deal with it before was, I created a script to shut down all containers and restart them in a specific order. That way they get the same IP all the time. And that script ran daily.
If I try using the host:port the connections fail. See attachments.
Maybe I've messed up something in my host's networking?
Any help is appreciated.
Thanks, Bill
"Try not. Do, or do not. There is no try." - Yoda
On Sun, Mar 20, 2022, 5:01 PM Tom Morgan @.***> wrote:
Thanks for the comments - There shouldn't be any references to the 172.X "docker network" IPs. The project is meant to use the host machine IP for all references. What individual container's or settings are you using the 172. IPs for/in?
— Reply to this email directly, view it on GitHub https://github.com/tom472/mediabox/issues/129#issuecomment-1073357182, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4VDLJJ3ISRAZESQV5XF53VA6N4FANCNFSM5REJZB6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
So when you try to open anything from the Homer start page they all go to host IP:port
are you saying that none of those ever open or load for you?
What about if you go into Portainer and then into the stack info for the Medaibox stack.
At the far right there will be a column that says "Published Ports" and those will be links to the applications again via host IP:port
-- do those open for you?
If neither of those are working / opening for you something is for sure wrong - there should be no need for and no use of the Docker 172.x
net IPs necessary at all when using Mediabox.
Is your host PC IP address being detected correctly?
At the bottom of the "Getting Started" page there is a "Troubleshooting" section that shows the details being used.
Can you verify that the IP_AADRESS
line is correct for the IP address of your host PC?
Interestingly enough, that all works. Portainer links using host:port open. Homer works using the same host:port links . Muximux works using the same host:port links. The 1 container that is exposed to the internet via nginx, the nginx sites-available file points to the host:port. But, when setting up containers, using the host:port doesn't work. But using the 172 network does. This is the getting started section, which looks correct to me:
LOCALUSER=bill HOSTNAME=server01 IP_ADDRESS=192.168.1.177 PUID=1000 PGID=1000 DOCKERGRP=998 PWD=/home/bill/mediabox DLDIR=/home/bill/mediabox/content TVDIR=/home/bill/mediabox/content/tv MISCDIR=/home/bill/mediabox/content/misc MOVIEDIR=/home/bill/mediabox/content/movies MUSICDIR=/home/bill/mediabox/content/music CIDR_ADDRESS=192.168.1.0/24 TZ=America/Chicago PMSTAG=public PMSTOKEN= VPN_REMOTE=ca-montreal.privacy.network CPDAEMONUN= removed for privacy CPDAEMONPASS= removed for privacy NZBGETUN= removed for privacy NZBGETPASS= removed for privacy
thanks,
Bill
On Sun, Mar 20, 2022 at 7:05 PM Tom Morgan @.***> wrote:
So when you try to open anything from the Homer start page they all go to host IP:port are you saying that none of those ever open or load for you?
What about if you go into Portainer and then into the stack info for the Medaibox stack. At the far right there will be a column that says "Published Ports" and those will be links to the applications again via host IP:port -- do those open for you?
If neither of those are working / opening for you something is for sure wrong - there should be no need for and no use of the Docker 172.x net IPs necessary at all when using Mediabox.
Is your host PC IP address being detected correctly? At the bottom of the "Getting Started" page there is a " Troubleshooting" section that shows the details being used. Can you verify that the IP_AADRESS line is correct for the IP address of your host PC?
— Reply to this email directly, view it on GitHub https://github.com/tom472/mediabox/issues/129#issuecomment-1073378521, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4VDLIRE2VBZWTINZPCBWLVA64LDANCNFSM5REJZB6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
-- "Try not. Do, or do not. There is no try." - Yoda
OK so I am not really following:
The 1 container that is exposed to the internet via nginx, the nginx sites-available file points to the
host:port
. But, when setting up containers, using thehost:port
doesn't work. But using the 172 network does.
What container is exposed to the internet?
Mediabox does not expose anything to the internet in its config.
And what do you mean by "when stetting up containers using the host:port
doesn't work."
Setting up what exactly?
You just mentioned that via Homer, Portainer, Muximux it all works - so that is host IP:port
working.
Using that same info in the containers should work exactly the same.
For example:
In Overseerr - my settings for Radarr and Sonarr are set for the host IP:port
Same with copying a Torznab Feed Link from Jackett - it creates a link with host IP:port/feed/etc..
and using those in Sonarr and Radarr works totally fine.
Additionally - no one has had this issue before or asked about this here or needed a fix. If this were an issue and the behavior of Mediabox there would be more talk about it I'd think.
I know, it doesn't make sense to me either. You asked if the links in portainer worked. They do. All those are pointing to the hosts ip and container ports. (192.168.1.177: XXXX) Those same links work in muximux, and homer. However when I am setting up any of the containers to use like Overseerr, and pointing to my Radarr container, and use the host ip and container port (192.168.1.177:7878) that does not work. And setting up Radarr, when pointing it to NZBGet, using the host:port does not work. But in both of those examples, if I use the docker container ip ( 172.17.0.35:7878) that will connect and work.
thanks, Bill
On Sun, Mar 20, 2022 at 8:53 PM Tom Morgan @.***> wrote:
OK so I am not really following:
The 1 container that is exposed to the internet via nginx, the nginx sites-available file points to the host:port. But, when setting up containers, using the host:port doesn't work. But using the 172 network does.
What container is exposed to the internet? Mediabox does not expose anything to the internet in its config. And what do you mean by "when stetting up containers using the host:port doesn't work." Setting up what exactly? You just mentioned that via Homer, Portainer, Muximux it all works - so that is host IP:port working. Using that same info in the containers should work exactly the same.
For example: In Overseerr - my settings for Radarr and Sonarr are set for the host IP:port Same with copying a Torznab Feed Link from Jackett - it creates a link with host IP:port/feed/etc.. and using those in Sonarr and Radarr works totally fine.
Additionally - no one has had this issue before or asked about this here or needed a fix. If this were an issue and the behavior of Mediabox there would be more talk about it I'd think.
— Reply to this email directly, view it on GitHub https://github.com/tom472/mediabox/issues/129#issuecomment-1073412643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4VDLL4F3WECEOCFMSSVTDVA7JBTANCNFSM5REJZB6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
-- "Try not. Do, or do not. There is no try." - Yoda
Well, I think I figured it out. The simplest solution was just overlooked by myself. I have Ubuntu's UFW running on the host with very few open ports. If I turn that off, or add ports to it that are being used by mediabox I can point containers to the host ip! This revelation leads me to a couple questions... Is there doc somewhere that said to have UFW turned off? I don't recall seeing it. Is that how you intended it to be? No firewall running? Is it safe? I suppose as long as those pets aren't forwarded on the router it should be fine. I think I will just be adding these ports to the firewall and leaving it turned on.
Thanks for the help in finding my problem! Bill
"Try not. Do, or do not. There is no try." - Yoda
On Sun, Mar 20, 2022, 9:17 PM William Thomas @.***> wrote:
I know, it doesn't make sense to me either. You asked if the links in portainer worked. They do. All those are pointing to the hosts ip and container ports. (192.168.1.177:XXXX) Those same links work in muximux, and homer. However when I am setting up any of the containers to use like Overseerr, and pointing to my Radarr container, and use the host ip and container port (192.168.1.177:7878) that does not work. And setting up Radarr, when pointing it to NZBGet, using the host:port does not work. But in both of those examples, if I use the docker container ip ( 172.17.0.35:7878) that will connect and work.
thanks, Bill
On Sun, Mar 20, 2022 at 8:53 PM Tom Morgan @.***> wrote:
OK so I am not really following:
The 1 container that is exposed to the internet via nginx, the nginx sites-available file points to the host:port. But, when setting up containers, using the host:port doesn't work. But using the 172 network does.
What container is exposed to the internet? Mediabox does not expose anything to the internet in its config. And what do you mean by "when stetting up containers using the host:port doesn't work." Setting up what exactly? You just mentioned that via Homer, Portainer, Muximux it all works - so that is host IP:port working. Using that same info in the containers should work exactly the same.
For example: In Overseerr - my settings for Radarr and Sonarr are set for the host IP:port Same with copying a Torznab Feed Link from Jackett - it creates a link with host IP:port/feed/etc.. and using those in Sonarr and Radarr works totally fine.
Additionally - no one has had this issue before or asked about this here or needed a fix. If this were an issue and the behavior of Mediabox there would be more talk about it I'd think.
— Reply to this email directly, view it on GitHub https://github.com/tom472/mediabox/issues/129#issuecomment-1073412643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN4VDLL4F3WECEOCFMSSVTDVA7JBTANCNFSM5REJZB6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID: @.***>
-- "Try not. Do, or do not. There is no try." - Yoda
Glad you got it figured out --
I don't think I have specific instructions for the UFW to be off - so that might be something I'll add to the docs. However per the Ubuntu docs turning it on would be a user selected action.
ufw by default is initially disabled.
So while I don't specifically mention that it should be off - the default setting on an Ubuntu install is off. And thus if it is turned on then yes it would be on the user to open/add/allow any necessary ports.
Yes this the intended design and config of Mediabox. Nothing is exposed inbound from the internet except for Plex which already has built-in security. The rest of the applications and configuration are meant to be open to your internal network, as that should be secured by other means.
First off, thanks for making this project. It makes running/managing these containers easy. I would like to offer a suggestion for a problem I have. The problem is ip addressing. When using the system provided bridge network, you cannot assign ip addresses. And occasionally during updates or some other activities where containers get restarted or stopped and started, they come back up with different ip addresses. This can cause havoc when containers point to other containers' docker IP address. (ie. 172.17.0.x) A container get it's ip based on first come first served order in the systems bridge network, so ips can change for a specific container. Some might suggest using the hosts ip and containers associated port, but that has never worked for me. That would be a great solution since the hosts ip never changes and neither do the ports. But alas I have to use docker network's ip. Solution 1: I'd be willing to change over to using the host ip, provided I could actually get it working. Solution 2: If we created a new Mediabox bridge network, you can assign ips to containers. Then no matter what order they start in, they will have the same IP.