when starting kibana with --dev option it doesnt use server.host setting

[ppisljar]

Kibana version: 5.0alpha

Server OS version: linux ubuntu 16.04 64bit

Browser version: /

Browser OS version: /

Original install method (e.g. download page, yum, from source, etc.): from source

Description of the problem including expected versus actual behavior:

when starting kibana with -dev option `bin/kibana --dev' it doesnt bind to the ip address specified in the config file

Steps to reproduce:

1. update kibana.dev.yml with
   server.host: "0.0.0.0"

2. start kibana with ---dev option
   bin/kibana --dev

   3.kibana will not bind to 0.0.0.0

Provide logs and/or server output (if relevant):

when starting without --dev option:

~/elastic/kibana_fork$ bin/kibana 
  log   [15:45:48.489] [info][optimize] Optimizing and caching bundles for console, kibana, sense-tests and status_page. This may take a few minutes
  log   [15:47:09.113] [info][optimize] Optimization of bundles for console, kibana, sense-tests and status_page complete in 80.62 seconds
  log   [15:47:09.146] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.179] [info][status][plugin:[email protected]] Status changed from uninitialized to yellow - Waiting for Elasticsearch
  log   [15:47:09.200] [error][elasticsearch] Request error, retrying
HEAD http://localhost:9200/ => connect ECONNREFUSED 127.0.0.1:9200
  log   [15:47:09.203] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.207] [warning][elasticsearch] Unable to revive connection: http://localhost:9200/
  log   [15:47:09.207] [warning][elasticsearch] No living connections
  log   [15:47:09.210] [error][status][plugin:[email protected]] Status changed from yellow to red - Unable to connect to Elasticsearch at http://localhost:9200.
  log   [15:47:09.211] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.213] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.215] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.218] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.220] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.224] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.233] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.235] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
  log   [15:47:09.238] [info][listening] Server running at http://0.0.0.0:5601

when starting with --dev option:

~/elastic/kibana_fork$ bin/kibana --dev 
 watching for changes  (235 files)
  log   [15:45:35.488] [info][listening] basePath Proxy running at https://localhost:5601/aje
server    log   [15:45:37.576] [info][optimize] Waiting for optimizer completion
optmzr    log   [15:45:37.591] [info][optimize] Lazy optimization of bundles for console, kibana, sense-tests and status_page ready
optmzr    log   [15:45:37.612] [info][optimize] Lazy optimization started
optmzr    log   [15:45:37.634] [info] Plugin initialization disabled.
server    log   [15:45:37.660] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.695] [info][status][plugin:[email protected]] Status changed from uninitialized to yellow - Waiting for Elasticsearch
server    log   [15:45:37.717] [error][elasticsearch] Request error, retrying
HEAD http://localhost:9200/ => connect ECONNREFUSED 127.0.0.1:9200
server    log   [15:45:37.721] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.733] [warning][elasticsearch] Unable to revive connection: http://localhost:9200/
server    log   [15:45:37.734] [warning][elasticsearch] No living connections
server    log   [15:45:37.742] [error][status][plugin:[email protected]] Status changed from yellow to red - Unable to connect to Elasticsearch at http://localhost:9200.
server    log   [15:45:37.744] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.747] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.753] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.757] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.760] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.763] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.769] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.779] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.784] [info][status][plugin:[email protected]] Status changed from uninitialized to green - Ready
server    log   [15:45:37.790] [info][listening] Server running at https://localhost:5603

[tsullivan]

I wonder if this has to do with HTTPS. Is it possible to connect to an HTTPS URL using just an IP address? My understanding is the server.host setting should match the domain name bound in the SSL certificate.

My understanding is based on my experience creating a custom certificate for running in dev mode, in order to connect to my local Kibana server via https://tsullivan.local:5601

[ppisljar]

yes, it has to do with https

src/cli/serve.js:

if (opts.dev) {
    set('env', 'development');
    set('optimize.lazy', true);
    if (opts.ssl && !has('server.ssl.cert') && !has('server.ssl.key')) {
      set('server.host', 'localhost');
      set('server.ssl.cert', fromRoot('test/dev_certs/server.crt'));
      set('server.ssl.key', fromRoot('test/dev_certs/server.key'));
    }
  }

so i guess this is expected behaviour.

[LeeDr]

Lowering to P2 since this is a dev problem and wouldn't (I think) impact production users.

[timroes]

I think this is no longer true. I use this in my configuration to access from VMs, etc and it works without issues.