SymmetricDS Sample - client node refused to connect to server node - database-connection

I am working on the example from the SymmetricDS tutorial. I am using the configuration files corp-000.properties and store-001.properties found in the samples directory of the download zip. I have placed them in the engine directory and edited them so that corp-000 is using a Postgresql DB as master-000 and store-001 is using an MySQL DB as slave-001, both on separate machine.
Here are the config from corp-000.properties:
engine.name=master-000
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://127.0.0.1/master?stringtype=unspecified
I've also enable the firewall (8080/tcp and 5432/tcp) and changed port from 31415 to 8080: However when the same error still came out and the url returns this result:
This site can’t be reached
<Master-node-IP> refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
What should I do to solve thise problem?

Add to corp configuration
auto.registration=true
Can’t hurt to add
auto.reload=true
Solution by #swm is
The solution is need to set bind ip in symmetricDS

Below are some example configs.
What is happening here is that the main or master cannot see the sync / registration urls and ports not the database.
Make sure the following are setup correctly.
MAIN
registration.url=
sync.url=ttp://<IP>:<PORT>/sync/<SDS_MAIN>
CHILD
registration.url=http://<IP>:<PORT>/sync/<SDS_MAIN>
sync.url=http://<IP>:<PORT>/sync/<SDS_CHILD>
FULL EXAMPLE CONFIGS BELOW
MAIN
engine.name=<SDS_MAIN>
db.driver=net.sourceforge.jtds.jdbc.Driver
db.url=jdbc:jtds:sqlserver://<IP>:1433/<DB>;useCursors=true;bufferMaxMemory=10240;lobBuffer=5242880
db.user=***********
db.password=***********
registration.url=
sync.url=ttp://<IP>:<PORT>/sync/<SDS_MAIN>
group.id=<GID>
external.id=000
auto.registration=true
initial.load.create.first=true
sync.table.prefix=sym
#start.initial.load.extract.job=false
compression.level=-1
compression.strategy=0
CHILD
engine.name=<SDS_CHILD>
db.driver=net.sourceforge.jtds.jdbc.Driver
db.url=jdbc:jtds:sqlserver://<IP>:1433/<DB>;useCursors=true;bufferMaxMemory=10240;lobBuffer=5242880
db.user=***********
db.password=***********
registration.url=http://<IP>:<PORT>/sync/<SDS_MAIN>
sync.url=http://<IP>:<PORT>/sync/<SDS_CHILD>
group.id=<GID>
external.id=100
auto.registration=true
initial.load.create.first=true
sync.table.prefix=sym
start.initial.load.extract.job=false
compression.level=-1
compression.strategy=0

Related

How can I tell what options are in use on a running Mosquitto Service

How can I tell if the settings files associated with a Mosquitto instance, have been properly applied?
I want to add a configuration file to the conf.d folder to override some settings in the default file, but I do not know how to check they have been applied correctly once the Broker is running.
i.e. change persistence to false (without editing the standard file).
Test it.
You can run mosquitto with verbose output enabled, which will generally give you feedback on what options were set, but don't just believe that.
To do that, stop running Mosquitto as a service (how you do this depends on you setup) and manually run it from the shell with the -v option. Be sure to point it at the correct configuration file with the -c option.
That's not enough to be sure that it's actually working properly. To do that you need to test it.
Options have consequences or we wouldn't use them.
If you configure Mosquitto to listen on a specific port, test it by trying to connect to that port.
If you configure Mosquitto to require secure connections on a port, test it by trying to connect to the port unsecured (this shouldn't work) and secured (this should work).
You should be able to devise relatively simple tests for any options you can set in the configuration file. If you care if it's actually working, don't just take it on faith; test it.
For extra credit you can bundle the tests up into a script so that you can run an entire test suite easily in the future and test your Mosquitto installation anytime you make changes to it.
Having duplicate configuration options with different values is a REALLY bad idea.
The behaviour of mosquitto is not defined in this case, which value should be honoured, the first found, the last? When using the conf.d directory, what order will the files be loaded in?
Also will you always remember that you have changed the value in a conf.d file in the future when you go looking?
If you want to change one of the defaults in the /etc/mosquitto/mosquitto.conf file then edit that file. (Any sensible package management system will notice the file has been changed and ask what to do at the point of upgrade)
The conf.d/ directory is intended for adding extra listeners.
Also be aware that there really isn't a default configuration file, you must always specify a configuration file with the -c command line option. The file at /etc/mosquitto/mosquitto.conf just happens to be the config file that is passed when mosquitto is started as a service when installed using most Linux package managers. (The default Fedora install doesn't even setup the /etc/mosquitto/conf.d directory)

Cannot access changes and create projects

Tried gerrit 2.15 and 2.16.6.
I'm trying to migrate an existing gerrit instance to another hardware.
There is an AOSP mirror with old changes and database.
I've moved everything to the new hardware and can see a list of changes and a list of projects, but I can't access any changes themselves. When I click to access some change, I receive 404 not found and a message "Server error: Not found: root-dir".
When I try to create a new project with the name "root-dir/project_path/project_name", I receive the same message.
Cgroups configurations are correct.
Reindexing doesn't help, neither does reinitializing.
Using ssh I can create a project and pull any change I want.
The only difference between configurations is that now we use nginx in front of a gerrit instance.
Why is this happening?
The issue was actually in an nginx configuration.
server {
...
location / {
proxy_pass http://[ipv6_address]:8443/;
...
}
}
The slash at the end caused the issue: should be proxy_pass http://[ipv6_address]:8443;
Issue 1999: creating project with a / will cause an error (404 not found)
Troubleshooting

Cassandra fails to initialize with error "Cannot add table 'role_members' to non existing keyspace 'system_auth'"

I am running a Cassandra cluster in Docker containers using fleet for management. I am able to get the cluster up and running, but if I bring the units down with fleet and then back up again, the containers fail. The Cassandra logs has this entry on the second start.
Cannot add table 'role_members' to non existing keyspace 'system_auth'.
Fatal configuration error; unable to start server. See log for stacktrace.
INFO 20:59:34 InetAddress /172.17.8.102 is now DOWN
ERROR 20:59:34 Fatal configuration error
org.apache.cassandra.exceptions.ConfigurationException: Cannot add table 'role_members' to non existing keyspace 'system_auth'.
at org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:284) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:275) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.StorageService.maybeAddTable(StorageService.java:1046) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.StorageService.doAuthSetup(StorageService.java:1034) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:967) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:698) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:581) ~[apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:291) [apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:481) [apache-cassandra-2.2.0.jar:2.2.0]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:588) [apache-cassandra-2.2.0.jar:2.2.0]
I can't find any information on this particular error, and I really have no idea why it's happening. The closest information I can find is that the system_auth table needs to be configured specially if you are not using the default AllowAllAuthenticator, but I am using this. I haven't changed it in the cassandra.yaml file.
Does anyone know why this might be happening?
Is it possible that you are using CassandraAuthorizer without using PasswordAuthenticator? I think that might not work and cause this particular error.
system_auth is not applicable to AllowAllAuthenticator, you need to use PasswordAuthenticator instead. If you configure cassandra.yaml in the following way:
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
And then restart cassandra, it should create the system_auth keyspace for you. If you don't want to set up authorization, you can always use AllowAllAuthorizer instead. More information can be found here.
This turned out to be a rather unique configuration issue I had. I was mapping /var/lib/cassandra on the host to /var/lib/cassandra inside my docker container. But I was also inadvertently mapping /var/lib/cassandra/data to an auto-generated Docker directory on the host. As such when I stopped and restarted the containers, the data directory would disappear and Cassandra would fail as it tried to recreate data from the commitlog directory.
I got the problem just following the Datastax "Initializing a multiple node cluster (single data center)" tutorial.
I solved the same problem deleting the whole content of /var/lib/cassandra and not only the content of /var/lib/cassandra/system/
Why?
I think Kris got the real problem source: when restarting, the C* service found the commitLog full and recovered by trying to reconstruct the commits found there, failing due to a different configuration and a different table structure...

Configuring Sonar plugin for Jenkins

I am having some confusion over configuring Sonar plugin on Jenkins. I went to Manage Jenkins -> Configure System and added Sonar.I am confused about what to put in the Database URL in the Sonar section.
I put
jdbc:mysql://10.4.1.206/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true
10.4.1.206 is the node I am connecting to.
However, the port is 3306.
Should I put
jdbc:mysql://10.4.1.206:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true or just leave it like before?
Also, since I am using MySQL, do I need to put com.mysql.jdbc.Driver in the Driver section? It says to leave it blank if I am using embedded default driver.
Please forgive me; this is my first time tampering with both Jenkins and Sonar.
In case you have configured your Sonar to use MySQL, you need to provide both the URL and the driver. The default, embedded database for Sonar is Derby - below you will find a sample of a default sonar configuration:
# Comment the 3 following lines to deactivate the default embedded database
sonar.jdbc.url: jdbc:derby://localhost:1527/sonar;create=true
sonar.jdbc.driverClassName: org.apache.derby.jdbc.ClientDriver
sonar.jdbc.validationQuery: values(1)
So, if you have configured your Sonar to use MySQL, and I can only assume that you had, let's analyze the configuration itself:
The driver that you need to explicitly declare is com.mysql.jdbc.Driver.
Yours URL string looks good to me. According to the MySQL Connect specification:
The JDBC URL format for MySQL Connector/J is as follows, with items in square brackets ([, ]) being optional:
jdbc:mysql://[host][,failoverhost...][:port]/[database] »
[?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
If the host name is not specified, it defaults to 127.0.0.1. If the port is not specified, it defaults to 3306, the default port number for MySQL servers.
jdbc:mysql://[host:port],[host:port].../[database] »
[?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
In my current setup the connection is as follows:
jdbc:mysql://localhost:3306/radical_sonar?useUnicode=true&characterEncoding=utf8
I tend to use the port number explicitly in order to avoid confusion rather than anything else - we do have a test MariaDB install running on a different port...
In Manage Jenkins > Configure System, your Sonar-Settings should be as follows:
Database URL should be:
jdbc:mysql://10.4.1.206:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true
Driver should be:
com.mysql.jdbc.Driver
If you need more information, you might also want to have a look at your "sonarqube/conf/sonar.properties" File and the following documentation link
http://docs.codehaus.org/display/SONAR/Configuring+SonarQube+Jenkins+Plugin
Good Luck with your configuration!

How to run Grails Wrapper (grailsw) behind a proxy?

I tried to run grailsw, but the wrapper cannot connect to download grails-2.2.1-download.zip (creates a 0 byte file instead).
I need to use a proxy server to connect to the internet, where do I configure proxy settings for the Grails Wrapper?
After running grails wrapper, your project directory has a new subdirectory called wrapper, with a file grails-wrapper.properties. You can configure your proxy settings in there, with the following properties:
systemProp.http.proxyHost=
systemProp.http.proxyPort=
systemProp.http.proxyUser=
systemProp.http.proxyPassword=
systemProp.http.nonProxyHosts=
I solved this problem for myself.
It is a two step process
1.a) Back up your JRE_HOME\lib\security folder. This is essential because the below steps might corrupt cacerts file under jre.
1.b) You need to install the ssl public key of Github.com to your local file system. To do that you have to use the InstallCert.java program( Link to InstallCert.java )
It is supposed to be run as java InstallCert github.com
and when it asks to enter cert number you need to enter 1
It will create a file with name "jssecacerts" in the current directory
1.c) But this program will not work because it does not know about how to authenticate with proxy. For this you need the code from SSLSocketClientWithTunneling page
Use the above two and create a program that tunnels through the proxy retrieves the ssl key and writes a file called jssecerts
2) Update your grails.bat with addtional options. Add these options to the %JAVA_EXE% command line. Paste them after %DEFAULT_JVM_OPTS%
-Dhttp.proxyHost=YourproxyURL -Dhttp.proxyPort=YourproxyPort -Dhttps.proxyHost=YourproxyURL -Dhttps.proxyPort=YourproxyPort -Dhttp.proxyUser=YourProxyUserID -Dhttp.proxyPassword=YourProxyPassword -Dhttps.proxyUser=YourProxyUserID -Dhttps.proxyPassword=YourProxyPassword -Djavax.net.ssl.trustStore=path-to-your-jssecacerts-created-in-step-1

Resources