MultiServer issue

Just to be on the safe side I ran #/usr/local/directadmin/directadmin set cluster 1 on both servers but no luck...
 
Yes oke but have you verified as I set? So opened the directadmin.conf file and checked the line was in there?
And restarted DA afterwards?

If yes and still no luck, I think best is to send in a ticket with DA. Since the support is expired, it might take a while until somebody answers, or maybe get lucky here on the forums.

If you want I would be prepared to have a look for you, however, since it's not that difficult, I don't think you did anything wrong.
I could be able to test with one of my servers, use the test connection to see how that works.
 
Seems I've found some part of the issue.
@AlexJ gave me some login info.
When testing on our own server, I also got a timeout using the ip address.
However, when ticking the SSL connection, the test works flawlessly.

I have SSL enabled for my hostname and use:
servername=my.hostname.com
and
ssl_redirect_host=my.hostname.com
in directadmin.conf.

So it seems that probably the SSL redirect is in effect and you have to use the SSL connection to get it to work.

Now I tested with SSL ticked in muti server setup on your server, and then the timeout disappeared but some other error occured:
149.xxx.xx.xx : : Unable to connect to secure socket
Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).
openssl error queue:
empty error queue. ret=-1
errno: Success
Click to expand...

So to me it looks like an SSL issue, and should be fixed when setting up SSL correctly on the servers hostnames.
 
Yes, I cannot send a ticket. Instead, I've sent a message via the contact page.
I hope somebody would answer.
 
Okay, I've enabled LetsEncrypt on both servers but still no connection.

Here is the error on server A:

server.domain.com : Unable to connect to secure socket
Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).
openssl error queue:
empty error queue. ret=-1
errno: Success


And on server B I get the following message in the error.log file:

Timeout (handshake_timeout=12) from 1.2.3.4 : last flagged: Sockets::handshake :
 
Look at post 17 and 18. Maybe same solution can be used as this looks as almost the same error notice.

DirectAdmin 1.47.0 - RC

Hello, We're please to announce the Release Candidate of DirectAdmin 1.47.0. Update: RC 3 - Jan 8, 2015. You can see all changes here: directadmin.com/versions.php?version=1.470000 This is a major release with many new features, and many bug-fixes. New Features...
forum.directadmin.com forum.directadmin.com
 
I'd recommend running debug on the B end to confirm the request is coming in as expected.

1) If B is doing some redirect, then on box A, ensure all settings match 100% what the final redirect ends up as.
Eg, use hostb.domain.com instead of an IP address so that the "Host" is being passed (If I did it correctly), so no redirect happens (and ensure SSL matches correctly too).

2) On B, try shutting removing these from your directadmin.conf, if they exists:
ssl_redirect_host
force_hostname
just to confirm or rule them out.

3) If the connection was able to get out with the SSL checkbox, then this next check *probably* doesn't affect anything, but I'd recommend running DA box A in debug level 153, which is specific to the clustering and will give you more info. I'm most curious about the local IP that DA is trying to bind to.
If you have the latest pre-release binaries, with ./directadmin b153 on box A, issue a test and we'd be looking for
Code: 
Cluster::set_bind setting bind IP to %s
which will only show up if indeeded, a local value is being bound to.
This can be affected by the "lan_ip" directadmin.conf setting. If you're not on a LAN, then clear it from the directadmin.conf and restart DA.

Hope that helps with the hunt!

John
 
Richard G said:
Look at post 17 and 18. Maybe same solution can be used as this looks as almost the same error notice.

DirectAdmin 1.47.0 - RC

Hello, We're please to announce the Release Candidate of DirectAdmin 1.47.0. Update: RC 3 - Jan 8, 2015. You can see all changes here: directadmin.com/versions.php?version=1.470000 This is a major release with many new features, and many bug-fixes. New Features...
forum.directadmin.com forum.directadmin.com
Click to expand...

I've increased the handshake_timeout but that didn't help.
 
DirectAdmin Support said:
I'd recommend running debug on the B end to confirm the request is coming in as expected.

1) If B is doing some redirect, then on box A, ensure all settings match 100% what the final redirect ends up as.
Eg, use hostb.domain.com instead of an IP address so that the "Host" is being passed (If I did it correctly), so no redirect happens (and ensure SSL matches correctly too).

2) On B, try shutting removing these from your directadmin.conf, if they exists:
ssl_redirect_host
force_hostname
just to confirm or rule them out.

3) If the connection was able to get out with the SSL checkbox, then this next check *probably* doesn't affect anything, but I'd recommend running DA box A in debug level 153, which is specific to the clustering and will give you more info. I'm most curious about the local IP that DA is trying to bind to.
If you have the latest pre-release binaries, with ./directadmin b153 on box A, issue a test and we'd be looking for
Code: 
Cluster::set_bind setting bind IP to %s
which will only show up if indeeded, a local value is being bound to.
This can be affected by the "lan_ip" directadmin.conf setting. If you're not on a LAN, then clear it from the directadmin.conf and restart DA.

Hope that helps with the hunt!

John
Click to expand...

I've disabled/commented out ssl_redirect_host on Server B and the connection setting on Server A uses a correct domain name which is in the SSL certificate's subject.

I've attached the log file for Debug Level 153 on Server A.

Server A is behind NAT.
 

Attachments

Could be firewall. But also looks like the other server has some deny.commands enabled.

What is in your allowed list? Also maybe check if the server user who is connecting has correct permissions for the requests.

And did you do a:

Code: 
cd /usr/local/directadmin/scripts
./set_permissions.sh all

Could be a permission error also
 
LoL guys, his last answer (post #35) was from 4 years ago, I think he already fixed it in those years. :)
 
You must log in or register to reply here.
Back
Top