How could I get MariaDB 10.1 to listen only on IPv4? Strange but true the very first time I installed MariaDB and started it, I saw that it was correctly listening on IPv4 as shown in the example picture below
But strangely after reinstalling MariaDB for some reasons and rebooting my Centos 7 installation, it seems to have started listening only on IPv6 and I hence I cannot get the Galera Cluster to work (which was working fine when it was listening on IPv4). So how do I get this MariaDB to listen only on IPv4. The below is a screenshot from my machine
[root#dataqry-0001 ~]# netstat -ntpl | grep sql
tcp6 0 0 :::3306 :::* LISTEN 14323/mysqld
Contents of /etc/my.cnf.d/server.cnf (Pls note that I also tried uncommenting out the bind address, it is still the same strangely)
#
# These groups are read by MariaDB server.
# Use it for options that only the server (but not clients) should see
#
# See the examples of server my.cnf files in /usr/share/mysql/
#
# this is read by the standalone daemon and embedded servers
[server]
# this is only for the mysqld standalone daemon
[mysqld]
#
# * Galera-related settings
#
[galera]
# Mandatory settings
#wsrep_on=ON
#wsrep_provider=
#wsrep_cluster_address=
#binlog_format=row
#default_storage_engine=InnoDB
#innodb_autoinc_lock_mode=2
#
# Allow server to accept connections on all interfaces.
#
#bind-address=0.0.0.0
#
# Optional setting
#wsrep_slave_threads=1
#innodb_flush_log_at_trx_commit=0
# this is only for embedded server
[embedded]
# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]
# This group is only read by MariaDB-10.1 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don't understand
[mariadb-10.1]
I should add that I am quite confused with MariaDB / MySQL settings littered all over the place. The above bind-address is for Galera I guess. It's my first time with MariaDB on Centos 7, so apologies - I even tried disabling IPv6 earlier but doesn't show it listening on IPv4
Thanks
M.M
Preface
Although the information in the official MariaDB bug-tracker seems to suggest that this is not possible, unless the mysql software is used instead; I can confirm that setting the following configuration option in e.g. /etc/my.cnf, at least while using version 10.1.21-MariaDB, does work as expected and as outlined in #Hackerman's comment.
bind-address=0.0.0.0
The misunderstood/misleading/irrelevant official bug-trackers I eluded to:
MDEV-6536 (Open)
MDEV-4379 (Closed)
Answer
To answer the question as it pertains to your specific scenario, however, you should pay attention to the "section" under which that setting is set; namely, you have it written under the [galera] section, rather than the server-wide [mysqld] section.
[mysqld]
#
# * Galera-related settings
#
[galera]
# Mandatory settings
#wsrep_on=ON
#wsrep_provider=
#wsrep_cluster_address=
#binlog_format=row
#default_storage_engine=InnoDB
#innodb_autoinc_lock_mode=2
#
# Allow server to accept connections on all interfaces.
#
#bind-address=0.0.0.0
Make sure bind-address is specified in the [mysqld] section.
Related
Last week I decided to upgrade the mac to the latest version Monterey. Well. Most things works, except for Vagrant. Well.. it works, except there is almost no connection to the server.
vagrant ssh works.
I have been able to launch virtualbox, but access to http or mysql is not happening.
I know the mysql-server is running. The same goes with the apache server.
Logs have been checked and I cannot see that any traffic going to the server.
Ping is not working.
I have updated virtualbox. I have destroyed the box and upgraded vagrant / homestead. still no luck.
MORE INFO:
When I run traceroute I see that the first hit is the correct IP I have set in hosts file. Then it goes to 192.168.0.1 which isn't going anywhere.
I guess the 192.168.0.1 comes from the mac virtualbox / vagrant is running on.
Any pointers on what to do next are welcome.
Probably the same problem as mine (I couldn't use any longer IP 192.168.10.10). VirtualBox did some changes lately (from VirtualBox 6.1.28 I think) and a new configuration is needed to use your preferred (192.168.0.1) IP address:
On Linux, macOS and Solaris Oracle VM VirtualBox will only allow IP
addresses in 192.168.56.0/21 range to be assigned to host-only
adapters. For IPv6 only link-local addresses are allowed. If other
ranges are desired, they can be enabled by creating
/etc/vbox/networks.conf and specifying allowed ranges there. For
example, to allow 10.0.0.0/8 and 192.168.0.0/16 IPv4 ranges as well as
2001::/64 range put the following lines into /etc/vbox/networks.conf:
* 10.0.0.0/8 192.168.0.0/16
* 2001::/64
You can check the whole information here.
Alternatively (skipping the networks.conf configuration) you can use any IP from the initially supported range like for instance: 192.168.56.10
I followed the official guide at:
https://mariadb.com/kb/en/installing-and-using-mariadb-via-docker/
However, I haven't found any entry with bind-address in my my.cnf file, it looks like this:
# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 0. "/etc/mysql/my.cnf" symlinks to this file, reason why all the rest is read.
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# If you are new to MariaDB, check out https://mariadb.com/kb/en/basic-mariadb-articles/
#
# This group is read both by the client and the server
# use it for options that affect everything
#
[client-server]
# Port or socket location where to connect
# port = 3306
socket = /run/mysqld/mysqld.sock
# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/
when I try to connect to it from outside, that is from the host computer, I get the following:
Creating a session to 'root#172.17.0.2'
MySQL Error 2003 (HY000): Can't connect to MySQL server on '172.17.0.2' (60)
What should I do to be able to connect to the server from outside? It does run as I can connect from within the docker container.
I'm using macOS.
You can't do this trick mysql -h 172.17.0.2 -u root -p on Mac.
There is no docker0 bridge on macOS🔗
Because of the way networking is implemented in Docker Desktop for Mac, you cannot see a docker0 interface on the host. This interface is actually within the virtual machine.
I cannot ping my containers
Docker Desktop for Mac can’t route traffic to containers.
Please see the official docker documentation for Mac.
I suggest you expose the container port to the host -p 127.0.0.1:3306:3306 and then connect to your DB as to the localhost mysql -h 127.0.0.1 -p -uroot.
docker run --name mariadbtest \
-p 127.0.0.1:3306:3306\
-e MYSQL_ROOT_PASSWORD=mypass \
-d mariadb/server:10.3 \
--log-bin \
--binlog-format=MIXED
Your configuration uses a socket for connections, as you have commented out port:
# port = 3306
socket = /run/mysqld/mysqld.sock
So you should uncomment port above (and remove / comment out the socket configuration). This will cause the database to listen on port 3306.
For local usage you'll want to port-map that port to localhost afterward, for example running your container with -p so you can connect via localhost:3306:
docker -d -p 127.0.0.1:3306:3306 [..] example/mariadb
I've setup debug configuration for PhpStorm and it is successfully validated by PhpStorm:
Xdebug helper for Chrome is also installed.
The problem is that nothing happens when I start listening for debug connections and reload the required page with Xdebug helper switched on. Also tried this bookmarklets with no luck.
No errors or something, just nothing.
Also tried to set different IPs as dockerhost: from 192.168.. range (from network settings), from 172.* range (from nginx), from 10.* range (10.0.75.1 is default). Also tried docker.for.mac.internal.host which failed when containers were starting.
Docker 17.02, macOS Sierra, PhpStorm 2017.3
If you're on linux, be sure to create corresponding rules in your firewall.
But to troubleshoot this more effectively you need to gather more info.
Enable xdebug logging xdebug.remote_log=/var/www/xdebug.log in you
xdebug.ini or you can append that in the "Cli Interpreters > Configuration Options" in PHPStorm (xdebug.remote_log, /path/inside/workspace/container/xdebug.log)
Another step you could take is to monitor the incoming connections to your machine. (run this on where you installed docker). It will start listening to all incoming connection attempts on port 9000.
sudo tcpdump -i any port 9000
Now run the debugger once, check the logs inside the container (workspace by default) and see if any incoming connection attempts have gone through from the container.
If you see something like Time-out connecting to client (Waited: 200 ms). :-(, chances are that your firewall is blocking the incoming connections.
To open them up you could add a rule using ufw
sudo ufw allow in from 172.22.0.0/24 to any port 9000 (or write down a specific ip) Be sure to double check that this is the ip trying to connect
this will allow all connections on port 9000 from 172.22.0.* (which is what laradock uses for its virtual networks). Be sure to double check the logs maybe your setup uses different ip range)
My working xdebug.ini (both in php-fpm and workspace containers are the same)
xdebug.remote_host=dockerhost
xdebug.remote_connect_back=0
xdebug.remote_port=9000
xdebug.idekey=PHPSTORM
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.remote_log=/var/www/xdebug.log
xdebug.cli_color=1
xdebug.profiler_enable=0
xdebug.profiler_output_dir="~/path/to/profiler.log"
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.var_display_max_children=-1
xdebug.var_display_max_data=-1
xdebug.var_display_max_depth=-1
If none of the above works, another step would be to also check if you have any containers running on port 9000 already. If so, then you'll need to use another, port, just don't forget to expose it from docker.
(Explanation: docker binds (exposes) ports to the host machine so that any incoming connections get directed to the right container, if 9000 is taken, xdebug won't be able to connect to any IDE on your machine, even if the IDE says it is running the listener)
Hope this helps.
I appreciate if someone can help me out with this issuse.
I am starting a development for kibana plugin and installed all necessary packages.
My environment is below.
kibana 5.0.0 alpha5 (Used git clone from the git repository)
I want to start the devlopment server other than 127.0.0.1:5601
so I have created config/kibana.dev.yml as below
# Kibana is served by a back end server. This setting specifies the port to use.
server.port: 5601
# This setting specifies the IP address of the back end server.
server.host: "0.0.0.0"
However, this seems not to be applied when I start the kibana server from npm start. It keeps starting at 127.0.0.1:5601
Do I need any other setting to read config/kibana.dev.yml?
Thanks,
Yu Watanabe
When started in dev mode, SSL is on be default. In that configuration and if no custom certificates have been specified, the server.host setting has no effect and is forced to localhost (to match the host name in the default provided certificates) as can be seen in the cli/serve/serve.js file:
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'));
}
}
You can start Kibana by specifying the --no-ssl switch in order for the server.host setting to be taken into account:
sh ./bin/kibana --dev --no-ssl
I've installed Sonarqube 4.1.1 on a windows 64 bit system. I have no problems connecting to the web client on the same machine where I installed it. But I have no remote access - even in the same network (so I don't need ip forwarding and so on).
As I thought the port might be the problem, I switched my other tomcat installation to this port and it worked remotely. Only if I try to access sonar remotely it doesn't work.
#--------------------------------------------------------------------------------------------------
# WEB SERVER
# Binding IP address. For servers with more than one IP address, this property specifies which
# address will be used for listening on the specified ports.
# By default, ports will be used on all IP addresses associated with the server.
sonar.web.host=0.0.0.0
# Web context. When set, it must start with forward slash (for example /sonarqube).
# The default value is root context (empty value).
#sonar.web.context=
# TCP port for incoming HTTP connections. Disabled when value is -1.
sonar.web.port=8082
# TCP port for incoming HTTPS connections. Disabled when value is -1 (default).
#sonar.web.https.port=-1
# HTTPS - the alias used to for the server certificate in the keystore.
# If not specified the first key read in the keystore is used.
#sonar.web.https.keyAlias=
# HTTPS - the password used to access the server certificate from the
# specified keystore file. The default value is "changeit".
#sonar.web.https.keyPass=changeit
# HTTPS - the pathname of the keystore file where is stored the server certificate.
# By default, the pathname is the file ".keystore" in the user home.
# If keystoreType doesn't need a file use empty value.
#sonar.web.https.keystoreFile=
# HTTPS - the password used to access the specified keystore file. The default
# value is the value of sonar.web.https.keyPass.
#sonar.web.https.keystorePass=
# HTTPS - the type of keystore file to be used for the server certificate.
# The default value is JKS (Java KeyStore).
#sonar.web.https.keystoreType=JKS
# HTTPS - the name of the keystore provider to be used for the server certificate.
# If not specified, the list of registered providers is traversed in preference order
# and the first provider that supports the keystore type is used (see sonar.web.https.keystoreType).
#sonar.web.https.keystoreProvider=
# The maximum number of connections that the server will accept and process at any given time.
# When this number has been reached, the server will not accept any more connections until
# the number of connections falls below this value. The operating system may still accept connections
# based on the sonar.web.connections.acceptCount property. The default value is 50 for each
# enabled connector.
#sonar.web.http.maxThreads=50
#sonar.web.https.maxThreads=50
# The minimum number of threads always kept running. The default value is 5 for each
# enabled connector.
#sonar.web.http.minThreads=5
#sonar.web.https.minThreads=5
# The maximum queue length for incoming connection requests when all possible request processing
# threads are in use. Any requests received when the queue is full will be refused.
# The default value is 25 for each enabled connector.
#sonar.web.http.acceptCount=25
#sonar.web.https.acceptCount=25
# Access logs are generated in the file logs/access.log. This file is rolled over when it's 5Mb.
# An archive of 3 files is kept in the same directory.
# Access logs are enabled by default.
#sonar.web.accessLogs.enable=true
This is my sonar.properties file (the relevant part).
You should change sonar.web.host from 0.0.0.0 to your server ip in sonar.properties file. Then restart sonarqube.
I might be late on this post. I am using Sonarqube Community Edition 8.8 and I was facing same issue, was able to access on localhost and not using IP. In sonar.properties I changed sonar.web.host from 0.0.0.0 to sonar.web.host = "*" and restarted sonarqube. This worked for me.