ui_content_path option doesn't seem to work

[hanshasselberg]

Overview of the Issue

When providing ui_content_path in a json config, it doesn't seem to work in contrast to the cli flag -ui-content-path

Reproduction Steps

Steps to reproduce this issue, eg:

1. Create test config: cat '{"ui_content_path":"consul"}' > test.json
2. Start dev agent: consul agent -dev -config-file test.json
3. Open in browser: `http://localhost:8500/consul/', which doesn't work

OS, Architecture, and any other information you can provide about the environment.

Log Fragments

Include appropriate Client or Server log fragments. If the log is longer than a few dozen lines, please include the URL to the gist of the log instead of posting it in the issue. Use -log-level=TRACE on the client and server to capture the maximum log detail.

[pvandervelde]

@s-christoff Any idea on the timeline for this. We prefer to use the config over the command line because we put consul in our VM images. Given that consul is in our base image (which should be general for use with all our VMS), it's much easier to add another config file on the VMs where we want the UI to turn on rather than having to change the consul command line :)

[schristoff]

@pvandervelde Hey, thanks for the follow up. It's incoming :)

[pvandervelde]

Awesome thanks!

[pvandervelde]

@s-christoff Did this make it to Consul 1.6.2. The merge date on that PR suggests it does but I have a 1.6.2 version of Consul running with the the following config for the UI

{
    "ui": true,
    "ui_content_path": "/dashboards/consul"
}

But the consul UI shows on http://<NODE_IP_ADDRESS>:8500/ui which isn't what I expected. Did I get the wrong configuration option? Is the correct one in the documentation somewhere because I can't find it :(

[schristoff]

Hey @pvandervelde , I'm sorry to hear this is still causing trouble for you. I went ahead and tried to replicate this locally by creating a test.json with the ui-content-path set to "/dashboards/consul" and when I went to localhost:8500 or localhost:8500/dashboards/consul it was loading at the proper path.
Are you able to provide me with a little more information (perhaps a curl, or more replication steps?) I would love to dig into this and get this resolved. :)

[pvandervelde]

@s-christoff I suspect I got the configuration option wrong. Is it ui-content-path or ui_content_path (dashes vs underscores). I assumed it would be underscores because all the JSON elements use those but looking at your comment it might be dashes?

[schristoff]

That was my bad in the above comment, I am really used to typing ui-content-path, but my test.json locally for testing looks like

{
    "ui": true,
    "ui_content_path": "/dashboards/consul",
    "data_dir": "/usr/local/consul.d"
}

I added the data_dir option because I wasn't sure if you were running Consul in dev mode or not. I tried both though.

[pvandervelde]

I'll try your config file with the version of Consul I have installed when I get near my machine tonight

[pvandervelde]

Ok on my local machine now. I have the following running in a VM:

OS: Ubuntu 18.04.3
Consul version 1.6.2

Consul is running as a client. A different VM has the server instance, that also runs on Ubuntu 18.04.3 with Consul 1.6.2.

Consul service status:

Consul config (/etc/consul/consul.json)

{
"addresses": {
    "http": "0.0.0.0"
},
"client_addr": "127.0.0.1",
"data_dir": "/var/lib/consul",
"disable_host_node_id": true,
"disable_remote_exec": true,
"disable_update_check": true,
"dns_config": {
    "allow_stale": true,
    "max_stale": "87600h",
    "node_ttl": "30s",
    "service_ttl": {
    "*": "30s"
    }
},
"domain": "consulverse",
"enable_syslog": true,
"log_level": "DEBUG",
"ports": {
    "dns": 8600,
    "http": 8500,
    "serf_lan": 8301,
    "serf_wan": 8302,
    "server": 8300
},
"server": false,
"skip_leave_on_interrupt": true,
"verify_incoming": false,
"verify_outgoing": false
}

Consul UI config (/etc/consul/conf.d/consul_ui.json)

{
    "ui": true,
    "ui_content_path": "/dashboards/consul"
}

Consul log

• doing a curl on the VM to http://127.0.0.1:8500/ui/ gets the HTML for the UI page
• doing a curl on the VM to http://127.0.0.1:8500/dashboards/ui/ gets nothing

Other things I've tried

• I have deleted the consul data directory and restarted consul but that doesn't seem to matter
• I have moved the UI config lines to the /etc/consul/consul.json file but that didn't matter either

Setting the command line flag works without issue.

Is there anymore information you would need to debug this? If necessary I can zip up the VM and drop it somewhere but it'll be about 800Mb so that might be a bit much (also you need hyper-v which is probably a bigger issue)

[schristoff]

Hey - apologies again on all the clarifying questions. How many agents are you setting up at a time, and are you setting one of them specifically to be a server? I am asking this due to the manager: No servers available error in your logs, which I can replicate when I am standing up one single agent. Only servers can serve up the UI. I'll continue to dig into this in the meantime.

[pvandervelde]

More clarification is always good :) Ask as many questions as you need to help me figure out where things are broken. I'm pretty sure I stuffed up a configuration somewhere :(

I've got about 6 machines running in my test environment. There is one server (which is a different machine than the one that is serving the UI). Because it's a test setup I haven't configured it so that it auto-joins (all machines are on DHCP with machine names not being pushed to a DNS, so join is done via IP addresses)

When I grabbed a snapshot of the log I hadn't done a consul join from either the server or the UI machine, so hence why it displayed the no servers available message in the log. I made sure to join to the server before testing the UI part though.

When you say only servers can serve up the UI what do you mean with that? Because the machine I'm serving the UI from isn't a server machine (and it won't serve the UI when it's not connected to a server) but it definitely serves the UI from that machine when I use the command line argument (it probably gets all the internal information from the server instance though, but the HTML pages originate from the UI machine).

If it's helpful I can grab the output of consul members with some useful notes of which machine is what.

[schristoff]

Okay - so I've found that in 1.7.0-beta we made some changes to some of the primary code around how we load the index (you can check it out here). Can you perhaps try using the 1.7.0-beta and see if the issue is still happening?
I ran the following command:

 ✘ schristoff  ~  docker run -it -e CONSUL_LOCAL_CONFIG='{"ui": true,"ui_content_path": "/dashboards/consul","data_dir": "./consul","datacenter": "dc2"}' -p 8500:8500 consul:1.6.2

and was able to recreate your issue, however I think I was running 1.7.0 locally (accidentally) and wasn't able to recreate previously. When I reran the following command with 1.7.0, it worked!

 ✘ schristoff  ~  docker run -it -e CONSUL_LOCAL_CONFIG='{"ui": true,"ui_content_path": "/dashboards/consul","data_dir": "./consul","datacenter": "dc2"}' -p 8500:8500 consul:1.7.0-beta2

Let me know! :)

[pvandervelde]

@s-christoff, just as an FYI I haven't been able to run a test yet, work has been silly busy. When I come up for a breath I'll try to run a test but I currently don't know when that is :(

[ghost]

Hey there,

This issue has been automatically locked because it is closed and there hasn't been any activity for at least 30 days.

If you are still experiencing problems, or still have questions, feel free to open a new one 👍.

[gauravkohli]

@s-christoff .. We are having the same issue as @pvandervelde.

And after testing as you mentioned last, I do see that it works for 1.7.0-beta4, but not for any of the stable version 1.6.2, 1.6.3. Is it possible to have this fix in any stable release ? or by when can we expect 1.7.0 stable release to be available?

[schristoff]

Howdy @gauravkohli, I'm sorry you're having this issue too. :(
I don't think we will be putting this in previous stable versions (1.6.2, 1.6.3) - however 1.7.0 stable release should be coming within the next week or so.
Thank you for your patience with this!