MultiServer issue
- Thread starter AlexJ
- Start date
Richard G
Verified User
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.
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.
I thought tickets were blocked when expired?
Richard G
Verified User
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:
So to me it looks like an SSL issue, and should be fixed when setting up SSL correctly on the servers hostnames.
@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:
So to me it looks like an SSL issue, and should be fixed when setting up SSL correctly on the servers hostnames.
Richard G
Verified User
Maybe you can fix it with the results of my test?
Richard G
Verified User
Oke I hope that will give a better result.
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 :
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 :
Richard G
Verified User
Look at post 17 and 18. Maybe same solution can be used as this looks as almost the same error notice.
forum.directadmin.com
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
- Joined
- Feb 27, 2003
- Messages
- 9,158
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
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
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 %sThis 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
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...
I've increased the handshake_timeout but that didn't help.
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.