-
Controller Versionv5.9.31 Describe the BugOmada appears to startup with no errors, but when I access http://ip:8088 it redirects to https://10.168.3.59:8043/0f5f794c76c2c95f05b8cd5ac6a1e0e3/login, but then the page times out Expected BehaviorThe page loads Steps to ReproduceRun container How You're Launching the ContainerContainer LogsAdditional ContextSorry if this isn't the place to come for support, I didn't see a Discord / Forum link anywhere |
Beta Was this translation helpful? Give feedback.
Answered by
mbentley
Jun 3, 2023
Replies: 9 comments
-
|
Yup, this is the right place to come for help. I don't see anything from the logs that would specifically indicate any issues, looks like the controller is up and running and nothing error wise indicated from the logs. Have you tried a different browser, incognito session, or a hard refresh of the login page? Another quick way to test would be to try to use a curl command, assuming you have linux terminal access somewhere: This should do a verbose curl to the http port, ignoring certificate errors, showing errors in the output and following redirects. If it works, it should output the page's html after the verbose connection logs. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I have tried other browsers / other machines / phones, they all get to the redirect address and then fail. Here's the output of the curl command: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
also:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I also am getting the infinite redirect loop after seemingly doing nothing, except assumably the 5.9.31 update when I rolled my Kubernetes deployment. Oddly enough, it seems to be redirecting to itself, not even a protocol change. As with @bobbywaz , there's nothing useful in the logs either. I should note that I'm fully set up with TLS. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
What are you getting if you do a similar curl command? I am not 100% sure why @bobbywaz is getting an error about not supporting https libcurl but it looks like it has something to do with quotes: https://stackoverflow.com/a/24232441. In @bobbywaz 's case, try to do |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
50 redirects to the same page. curl output |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hm, I'm trying to figure out in what scenario it would end up in a redirect loop that never completes. How are you exposing the service if it is deploy to k8s? Ingress? Load balancer? Odd that it would just suddenly stop working but I doubt it has anything to do with the packaging of the software in the container. You're not trying to terminal SSL on your ingress and have traffic go over the http port are you? That's the only scenario where I can think of that it would just redirect non-stop right off hand. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I'm just using docker, no K8's, no load balancing, nothing fance. I just deleted it and restarted it with the newest version and now it's booting fine, but when I access the URL through my reverse proxy (omada.bobbyw.name) it's redirecting to the internal port... (omada.bobbyw.name:8043). Is there a way to use it without the redirect at all? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Sorry, I forgot to reply on this. There is a similar discussion about using Traefik to reverse proxy that might be helpful seeing as ingress would be a similar issue of doing a reverse proxy no matter what ingress is being used. The software always wants to use the internal port that the service is listening on and from my experience, doesn't handle that well otherwise without the same port internally and externally being the same. |
Beta Was this translation helpful? Give feedback.
0 replies
Answer selected by
mbentley
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry, I forgot to reply on this. There is a similar discussion about using Traefik to reverse proxy that might be helpful seeing as ingress would be a similar issue of doing a reverse proxy no matter what ingress is being used. The software always wants to use the internal port that the service is listening on and from my experience, doesn't handle that well otherwise without the same port internally and externally being the same.