Jump to content
johnodon

[DOCKER] Container Webui context menu IP/Port not updating when changes are made

26 posts in this topic Last Reply

Recommended Posts

unRAID OS Version: v6 Final (but v6 RCs and betas are probably also impacted)

 

Description:  If you edit a container in advanced view and change the Webui field under Additional Fields, the changes are not reflected in the Webui context menu item you use to launch the application webpage.

 

How to reproduce:  Add a new container and let it complete building.  Then edit the container and change the Webui field (I tried changing the port #) and save the container.  Once the container restarts, the Webui context menu icon will attempt to launch the container's webui using the old value.

 

Expected results:  The Webui context menu should be updated to reflect the changes and launch the application's webui with the new values.

 

Actual results:  The application is launched with the old webui value.

 

Other information:  From original post...

 

I am having an issue with some docker containers that I want to run in Host mode.  I'll use Binhex's SabNZBd as an example...

 

I changed the webui port in SAB to 8085 so it does not conflict with other containers.  I also changed the port in the webui for the container:

 

Ny9SgTY.png

 

However, if I try an open the SAB via right clicking and selecting WebUI, it still tries to open SAB via port 8080 which naturally fails:

 

D46ZqZI.png

 

If I open my browser and go directly to http://192.168.1.10:8085, I am able to reach SAB without issue.

 

Why is the WebUI context menu not updating?

 

John

Share this post


Link to post

I've seen this a couple of times already.  But never had anyone actually document it and open a defect report.  dockerMan isn't picking up the changes in the template file of a container that's already running.  Here's another example: http://lime-technology.com/forum/index.php?topic=40262.msg380740#msg380740

 

You want to open a defect report.

 

In the meantime, you can solve this by deleting ALL references to the container in /boot/config/plugins/dockerMan/templates and templates-user and remove the container and image and re-add it with the appropriate changes.

Share this post


Link to post

I've seen this a couple of times already.  But never had anyone actually document it and open a defect report.  dockerMan isn't picking up the changes in the template file of a container that's already running.  Here's another example: http://lime-technology.com/forum/index.php?topic=40262.msg380740#msg380740

 

You want to open a defect report.

 

In the meantime, you can solve this by deleting ALL references to the container in /boot/config/plugins/dockerMan/templates and templates-user and remove the container and image and re-add it with the appropriate changes.

 

I'll open a defect report.  Nice to know I'm not nuts.  :)

 

Ahhh...I tried deleting the template but only the user one.

 

Thx Squid!

 

John

Share this post


Link to post

I've seen this a couple of times already.  But never had anyone actually document it and open a defect report.  dockerMan isn't picking up the changes in the template file of a container that's already running.  Here's another example: http://lime-technology.com/forum/index.php?topic=40262.msg380740#msg380740

 

You want to open a defect report.

 

In the meantime, you can solve this by deleting ALL references to the container in /boot/config/plugins/dockerMan/templates and templates-user and remove the container and image and re-add it with the appropriate changes.

 

I'll open a defect report.  Nice to know I'm not nuts.  :)

 

Ahhh...I tried deleting the template but only the user one.

 

Thx Squid!

 

John

Anything for a Rush fan

Share this post


Link to post

 

Anything for a Rush fan

 

I'm actually surprised that is the first Rush comment I have received on this forum (especially considering I am surrounded by fellow dorks).  :D

Share this post


Link to post

 

Anything for a Rush fan

 

I'm actually surprised that is the first Rush comment I have received on this forum (especially considering I am surrounded by fellow dorks).  :D

I saw the show last night, (and changed my avatar), so it was still on my mind  ;)

Share this post


Link to post

Nope... Still exists in 6.2 Beta 19  Drives me nuts sometimes, but I got used to it

Share this post


Link to post

 

Anything for a Rush fan

 

I'm actually surprised that is the first Rush comment I have received on this forum (especially considering I am surrounded by fellow dorks).  :D

I assumed we all were Rush fans. Certainly not the first mention of Rush on the forum. I know I have been involved in a few.

Share this post


Link to post

I think I can easy fix this for the next beta.

 

It seems like the expectation here is [iP]:[PORT:1234] will take you to http://ip_address:1234  but that's not how the PORT:<port> variable works.  For example:

 

binhex-sabnzbd Docker defaults:

  WebUI: http://[iP]:[PORT:8080]/

  Container Port 8080  <---->  Host port 8080

 

Now if you want to change the host port to 8085:

  Container Port 8080  <---->  Host port 8085

 

At this point the WebUI won't need to change and the WebUI link on the context menu will take you to 8085.  That's because the WebUI's [PORT:8080] will look for the Container port 8080 and then use port number mapped the Host (8085) for the final link.  Essentially "[PORT:8080]" is replaced with "8085".

 

As a workaround today, you can click 'Check for Updates' to make those WebUI links to refresh.

 

After I fix this bug you may never need to modify the default WebUI url again. 

Share this post


Link to post

I think I can easy fix this for the next beta.

 

It seems like the expectation here is [iP]:[PORT:1234] will take you to http://ip_address:1234  but that's not how the PORT:<port> variable works.  For example:

 

binhex-sabnzbd Docker defaults:

  WebUI: http://[iP]:[PORT:8080]/

  Container Port 8080  <---->  Host port 8080

 

Now if you want to change the host port to 8085:

  Container Port 8080  <---->  Host port 8085

 

At this point the WebUI won't need to change and the WebUI link on the context menu will take you to 8085.  That's because the WebUI's [PORT:8080] will look for the Container port 8080 and then use port number mapped the Host (8085) for the final link.  Essentially "[PORT:8080]" is replaced with "8085".

 

As a workaround today, you can click 'Check for Updates' to make those WebUI links to refresh.

 

After I fix this bug you may never need to modify the default WebUI url again.

While your description may be correct for some of the users due to that misunderstanding, it is not mine.  I've always understood that the port listed in the WebUI entry refers to the container port.  What I'm referring to is an actual change to the entry

 

Take for instance, cAdvisor (smdion's repository).  cAdvisor DOES have a webUI, but the template does not have that element filled out.

 

So, install cAdvisor with ALL of the defaults.  Don't change a thing (except its host port if you have to)

 

Now go back and edit the container and ADD the appropriate WebUI entry in there ie: http://[iP]:[PORT:8080]/

 

No amount of checking for Updates, etc will get dockerMan to show the WebUI in the drop down, even though if you re-edit the container, it shows that's its there.

 

A somewhat related issue is where dockerMan on checking for updates (at least on 6.0/6.1 - haven't checked on 6.2) doesn't bring down any changed environment variables.

 

The problem here is that cAdvisor's *default* settings are to have no webUI, and that is the setting that dockerMan seems to be always picking up.

 

Sorry for being long winded and terse, but this issue and variations of it have been kicking around since 6.0 in various threads and this is the first response by LT or gfjardim on it.

 

(And if you follow the link earlier for another example http://lime-technology.com/forum/index.php?topic=40262.msg380740#msg380740), you'll see that a virgin install of a container worked properly, but aptalca could not get a changed value to work on his own container, without jumping through some hoops)

 

 

EDIT: I just toasted my docker.img file, rebooted, and installed cAdvisor and before clicking create added the WebUI entry.  No WebUI appeared on the dropdown.

Share this post


Link to post

I think I can easy fix this for the next beta.

 

It seems like the expectation here is [iP]:[PORT:1234] will take you to http://ip_address:1234  but that's not how the PORT:<port> variable works.  For example:

 

binhex-sabnzbd Docker defaults:

  WebUI: http://[iP]:[PORT:8080]/

  Container Port 8080  <---->  Host port 8080

 

Now if you want to change the host port to 8085:

  Container Port 8080  <---->  Host port 8085

 

At this point the WebUI won't need to change and the WebUI link on the context menu will take you to 8085.  That's because the WebUI's [PORT:8080] will look for the Container port 8080 and then use port number mapped the Host (8085) for the final link.  Essentially "[PORT:8080]" is replaced with "8085".

 

As a workaround today, you can click 'Check for Updates' to make those WebUI links to refresh.

 

After I fix this bug you may never need to modify the default WebUI url again.

While your description may be correct for some of the users due to that misunderstanding, it is not mine.  I've always understood that the port listed in the WebUI entry refers to the container port.  What I'm referring to is an actual change to the entry

 

Take for instance, cAdvisor (smdion's repository).  cAdvisor DOES have a webUI, but the template does not have that element filled out.

 

So, install cAdvisor with ALL of the defaults.  Don't change a thing (except its host port if you have to)

 

Now go back and edit the container and ADD the appropriate WebUI entry in there ie: http://[iP]:[PORT:8080]/

 

No amount of checking for Updates, etc will get dockerMan to show the WebUI in the drop down, even though if you re-edit the container, it shows that's its there.

 

A somewhat related issue is where dockerMan on checking for updates (at least on 6.0/6.1 - haven't checked on 6.2) doesn't bring down any changed environment variables.

 

The problem here is that cAdvisor's *default* settings are to have no webUI, and that is the setting that dockerMan seems to be always picking up.

 

Sorry for being long winded and terse, but this issue and variations of it have been kicking around since 6.0 in various threads and this is the first response by LT or gfjardim on it.

 

(And if you follow the link earlier for another example http://lime-technology.com/forum/index.php?topic=40262.msg380740#msg380740), you'll see that a virgin install of a container worked properly, but aptalca could not get a changed value to work on his own container, without jumping through some hoops)

 

 

EDIT: I just toasted my docker.img file, rebooted, and installed cAdvisor and before clicking create added the WebUI entry.  No WebUI appeared on the dropdown.

 

Squid, thanks for the details.  Confirmed the issue with the cAdvisor template never providing a WebUI link after editing the container details.  I fixed the underlying issue in the web gui code. 

 

The issue with the cAdvisor template never providing a WebUI link after editing and, in general, editing the WebUI and saving keeps the old link value in the context menu are actually two separate issues.  They're surprisingly similar but in totally unrelated sections of code.  Both will be patched in the next Beta.  8)

Share this post


Link to post

Squid, thanks for the details.  Confirmed the issue with the cAdvisor template never providing a WebUI link after editing the container details.  I fixed the underlying issue in the web gui code. 

 

The issue with the cAdvisor template never providing a WebUI link after editing and, in general, editing the WebUI and saving keeps the old link value in the context menu are actually two separate issues.  They're surprisingly similar but in totally unrelated sections of code.  Both will be patched in the next Beta.  8)

My next rant / defect report is more interesting.

Share this post


Link to post

Both will be patched in the next Beta.

 

Sorry, I lied.  :'(  Beta20 only contains the fix for the "cAdvisor template never providing a WebUI link after editing the container details" type issues.

 

I know what is causing the other, still open, issue regarding the "context menus using old cached values after editing the webUI link" but I need a little bit more time to implement a proper fix for it.

Share this post


Link to post

Both will be patched in the next Beta.

 

Sorry, I lied.  :'(  Beta20 only contains the fix for the "cAdvisor template never providing a WebUI link after editing the container details" type issues.

 

I know what is causing the other, still open, issue regarding the "context menus using old cached values after editing the webUI link" but I need a little bit more time to implement a proper fix for it.

I think the Icon also have this issue, I am trying to change Icon on a docker, but it is not changing.

 

Would be great if someone can confirm this.

Share this post


Link to post

Both will be patched in the next Beta.

 

Sorry, I lied.  :'(  Beta20 only contains the fix for the "cAdvisor template never providing a WebUI link after editing the container details" type issues.

 

I know what is causing the other, still open, issue regarding the "context menus using old cached values after editing the webUI link" but I need a little bit more time to implement a proper fix for it.

I think the Icon also have this issue, I am trying to change Icon on a docker, but it is not changing.

 

Would be great if someone can confirm this.

Try clearing your browser cache for that one.  DockerMan actually doesn't display the remote version of the icon but rather downloads a local version, and your browser may not be picking up the change.  (or it may also be a valid bug)

 

Sent from my LG-D852 using Tapatalk

 

 

Share this post


Link to post

Both will be patched in the next Beta.

 

Sorry, I lied.  :'(  Beta20 only contains the fix for the "cAdvisor template never providing a WebUI link after editing the container details" type issues.

 

I know what is causing the other, still open, issue regarding the "context menus using old cached values after editing the webUI link" but I need a little bit more time to implement a proper fix for it.

I think the Icon also have this issue, I am trying to change Icon on a docker, but it is not changing.

 

Would be great if someone can confirm this.

Try clearing your browser cache for that one.  DockerMan actually doesn't display the remote version of the icon but rather downloads a local version, and your browser may not be picking up the change.  (or it may also be a valid bug)

 

Sent from my LG-D852 using Tapatalk

Still shows the same Icon :/

Share this post


Link to post

Both will be patched in the next Beta.

 

Sorry, I lied.  :'(  Beta20 only contains the fix for the "cAdvisor template never providing a WebUI link after editing the container details" type issues.

 

I know what is causing the other, still open, issue regarding the "context menus using old cached values after editing the webUI link" but I need a little bit more time to implement a proper fix for it.

I think the Icon also have this issue, I am trying to change Icon on a docker, but it is not changing.

 

Would be great if someone can confirm this.

Try clearing your browser cache for that one.  DockerMan actually doesn't display the remote version of the icon but rather downloads a local version, and your browser may not be picking up the change.  (or it may also be a valid bug)

 

Sent from my LG-D852 using Tapatalk

Still shows the same Icon :/

Bug then

 

Sent from my LG-D852 using Tapatalk

 

 

Share this post


Link to post

Both will be patched in the next Beta.

 

Sorry, I lied.  :'(  Beta20 only contains the fix for the "cAdvisor template never providing a WebUI link after editing the container details" type issues.

 

I know what is causing the other, still open, issue regarding the "context menus using old cached values after editing the webUI link" but I need a little bit more time to implement a proper fix for it.

I think the Icon also have this issue, I am trying to change Icon on a docker, but it is not changing.

 

Would be great if someone can confirm this.

Try clearing your browser cache for that one.  DockerMan actually doesn't display the remote version of the icon but rather downloads a local version, and your browser may not be picking up the change.  (or it may also be a valid bug)

 

Sent from my LG-D852 using Tapatalk

Still shows the same Icon :/

Bug then

 

Sent from my LG-D852 using Tapatalk

Yeah... :/

 

 

If you see this Eric, is this something you can fix for 6.2b22? :)

Share this post


Link to post

All related issues in this thread should be solved in RC1.

 

Here is the announcement and release thread: http://lime-technology.com/forum/index.php?topic=50240.0

Same Icon is still showing if I edit the Icon URL line, tested on RC2.

 

I was able to reproduce in RC2 and was working on a fix.  RC3 (released yesterday) still has this bug but should be patched in RC4.

Share this post


Link to post

Can anyone confirm it's fixed now?

Confirmed fixed  8)

Thank you!

Share this post


Link to post

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.