Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client_addr not included in configuration file #73

Closed
dpetzel opened this issue Oct 30, 2014 · 7 comments
Closed

client_addr not included in configuration file #73

dpetzel opened this issue Oct 30, 2014 · 7 comments

Comments

@dpetzel
Copy link
Contributor

dpetzel commented Oct 30, 2014

This is related to #72, but is a slightly different issue so want to treated it as such.

Based on the documentation the client_addr configuration element is what controls what IP's the service will bind to. When not set this defaults to 127.0.0.1. manually adding this element to the json configuration and restarting the service shows this to be the case.

I think the client_addr attribute needs to get added to the copy param in order to have the service listening on all available interfaces. Setting the bind_addr doesn't result in the service listening on anything except 127.0.0.1

@dpetzel
Copy link
Contributor Author

dpetzel commented Nov 1, 2014

After looking at this with a fresh pair of eyes, the client_addr attribute works. The problem I had was I didn't have the UI enabled. Is it reasonable that someone might want to run the HTTP API without the UI, and thus client_addr shouldn't be tied to the UI?

@ericfode
Copy link
Contributor

ericfode commented Nov 6, 2014

@dpetzel I believe #78 should fix this, would you mind validating?

@dpetzel
Copy link
Contributor Author

dpetzel commented Nov 6, 2014

I'm not actually sure that's going to help in my case. If I'm reading it correctly your PR would result me in having to redefine client_addr into the extra params? While I could certainly do that it feels unnecessarily redundant. I think the fix is to remove the conditional around adding client_addr:

if node['consul']['serve_ui']
  service_config['ui_dir'] = node['consul']['ui_dir']
  service_config['client_addr'] = node['consul']['client_addr']
end

becomes something more like

service_config['client_addr'] = node['consul']['client_addr']
if node['consul']['serve_ui']
  service_config['ui_dir'] = node['consul']['ui_dir']
end

@ericfode
Copy link
Contributor

ericfode commented Nov 6, 2014

@dpetzel sorry about that I misunderstood your issue. :P

On Thu, Nov 6, 2014 at 3:43 PM, dpetzel [email protected] wrote:

I'm not actually sure that's going to help in my case. If I'm reading it
correctly your PR would result me in having to redefine client_addr into
the extra params? While I could certainly do that it feels unnecessarily
redundant. I think the fix is to remove the conditional around adding
client_addr:

if node['consul']['serve_ui']
service_config['ui_dir'] = node['consul']['ui_dir']
service_config['client_addr'] = node['consul']['client_addr']
end

becomes something more like

service_config['client_addr'] = node['consul']['client_addr']
if node['consul']['serve_ui']
service_config['ui_dir'] = node['consul']['ui_dir']
end


Reply to this email directly or view it on GitHub
#73 (comment)
.

@johnbellone johnbellone added this to the 0.9.0 release milestone Mar 14, 2015
logankoester added a commit to logankoester/consul-cookbook that referenced this issue Apr 9, 2015
This does not match the code. Possibly relevant to sous-chefs#73.
@johnbellone johnbellone removed this from the 0.9.0 release milestone May 1, 2015
@dontrebootme
Copy link

Running into this same issue. I vote for having the conditional for the ui removed from accepting client_addr or being reworked as well.

@johnbellone
Copy link
Contributor

I am closing this out because of impeding #126 landing on master.

@lock
Copy link

lock bot commented Apr 25, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants