[Support] omada-controller


Recommended Posts

I'm currently running v5.9 which so far has been working well. I'm also using SWAG to run it behind a proxy.

 

If I try to upgrade to 5.12 or 5.13, the proxy no longer works. It is still possible to login directly after the upgrade though.

 

What seems to happen is that the container is seen by the proxy and it tries to load but it just constantly spins (with the Omada logo). It seems like it's getting stuck somewhere. I tried to go through the access logs but nothing obvious comes up in there between v5.9 and the alter versions. It jsut seems like something is no longer passing through but no error gets thrown.

 

Does anyone have any suggestion on what to do? Many thanks in advance.

 

Edit:

 

Here's the proxy config (excuse the mess):

 

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name webaddressofserver.xyz;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {

        proxy_set_header Host $http_host:18043;
        proxy_set_header Cookie $http_cookie;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Referer $http_referer;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass https:/UNRAIDLOCALIPADDRESS:18043;
        proxy_redirect ~https://(.+):18043/(.+)/login$ https://$http_host/$2/login;
        proxy_buffering off;

    }

    location /js {
	proxy_pass https://UNRAIDLOCALIPADDRESS:18043/js;
    }

    location /api {
	proxy_pass http://UNRAIDLOCALIPADDRESS:18043/api;
    }

}

 

Edited by srappy
Link to comment
  • 4 weeks later...
On 11/23/2020 at 5:34 PM, hedrinbc said:

Hi there couple questions.

 

  1. Were you able to create paths on your system for the three paths required?
  2. Were those paths on your array or in a cache or unassigned drive?

 

My 3 paths are on an unassigned drive versus in the array and I have heard there could be permission issues if on the array. Reading those logs it appears to me it can't write into the paths.

 

Happy to continue to help, I do have it running over here so we can get there!

-Ben

 

Hi Ben,

 

First of all, thanks very much for voluntarily maintaining an UnRAID compatible docker for mbentley's TP-Link Omada SDN controller.  I wanted to make a quick suggestion from a software usability standpoint that I think is a low-effort way to avoid a lot of future headaches for users of your docker. 

 

As you probably know, many, if not most UnRAID dockers are preconfigured with host file paths that do not require careful manual entry, so UnRAID users have been "trained" to expect this behavior when installing a new docker.  Your defaults on host paths, if left unchanged, produce behavior that is sort of the worst of both worlds - it appears to work normally, but in fact UnRAID creates a temporary path based on your hard-coded personal server settings with "extrassd" that does not persist after reboot, causing in some cases hours and days of confusion for users of this docker.

 

To resolve this situation, I would recommend one of the following minor adjustments to the docker:

 

1) Set the default host paths to the following:

 

/mnt/user/appdata/omada-controller/data/

/mnt/user/appdata/omada-controller/work/

/mnt/user/appdata/omada-controller/logs/

 

This solution would I believe clear up a lot of user frustration and confusion after they just accepted your default (personal) host paths of your "extrassd."  Many / most UnRAID users opt to use a Cache drive and map the /appdata share exclusively to that drive, so it would not be stored on spinning drives with parity.  If for some reason you believe this solution might create an issue (I believe you referenced file permissions "on the array"), please let me know.  I assume UnRAID would create these directories if they do not yet exist in the appdata share.  This could also be hard-coded into mnt/cache/appdata/ I suppose, but I'm not certain why that would be a more optimal solution.

 

2) Another solution could be to make a much more prominent note in the Docker Template settings themselves (via instructional text below the host paths and/or in the blue description text], the Community Apps description and/or this support thread that explicitly states that it is MANDATORY for the user to reset these host paths to fit their own system needs.  However, I believe that if you make the changes in my suggestion above, these instructions may be unnecessary.

 

Finally, someone (not me) has produced a YouTube video walking users through installation of your Docker, and you may wish to link to this video in the first posts of this support thread for future reference [note that this person manually creates folders in /mnt/cache/appdata (which I did not think was necessary) and then edits the default host paths]:

 

 

I believe these changes could cut down on demands on your time as well as a lot of user frustration in this thread, on Reddit, and elsewhere.

 

I hope these suggestions may be helpful and again, huge thanks to you @hedrinbc and @mbentley for supporting this useful docker.

 

Cheers.

 

Edited by AnotherITGuy
Link to comment

@AnotherITGuy Thank you so much for your detailed post.

 

There was an attempt some time ago to change the paths and they were updated in part of the XML. Due to your post looking further at the bottom of the XML I realized the non-standard paths were still in a couple variables at the bottom of the file.

 

I believe I pushed this update just now.

 

I will look into your second idea as soon as possible.

 

Again, thank you much and thank you for the actionable input that will make this docker run better for others.

 

Have a good day,

-Ben

Link to comment

@hedrinbc You are most welcome, I'm glad you found my suggestions helpful. 

 

I'm not as familiar with the mechanics of how CA repositories update after code pushes, but just FYI it seems the template is still defaulting to your old personal host paths when I attempt to install as of this post time (11:43am EST).

 

Cheers

 

 

Link to comment
5 minutes ago, AnotherITGuy said:

@hedrinbc Just checked again and it's now working with the correct updated host paths!  Thanks again for the quick work, I hope this helps users out going forward.

 

Cheers

 

 

Ok, great! Thanks again.

 

Unfortunately I tried to fix this quite some time ago but only changed the paths in the middle of the XML and not the ones at the bottom!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.