Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Verified Answer
  • Replies replies
    9
  • Subscribers subscribers
    13
  • Views views
    236
  • Users 0 members are here
  • +1 person also asked this people also asked this
Related
Options

Mysterious " [110:101] Client import failed!" for SLES15 SP6

Ulrich Windl

On a freshly installed SLES15 SP6 x86_64 client, I can install the software, but it always fails with " [110:101] Client import failed!".

Unfortunately the error details do not help.

I see that at the end there was no system unit for "omni" installed, so the communication test from CM to client fails (while the test from client to CM succeeds).

Messages are like this:

[Normal] Starting installation session on Dienstag, 12. November 2024, 12:24:01...

[Normal] Getting list of clients for installation...

[Normal] Connecting to client client-host.domain.org...

[Normal] <client-host.domain.org> Checking for response from system client-host.domain.org.

[Normal] <client-host.domain.org> Using secure shell protocol to connect to clients ...

[Normal] <client-host.domain.org> Valid username and password must be specified...

[Normal] Connecting to client client-host.domain.org...

[Normal] <client-host.domain.org> Checking for response from system client-host.domain.org.

[Normal] <client-host.domain.org> Configuring SSH with provided credentials.

[Normal] <client-host.domain.org> SSH configuration completed successfully.

[Normal] Client client-host.domain.org (Linux 6.4.0-150600.23.25-default) OK.

[Normal] <client-host.domain.org> Starting installation/update for client system client-host.domain.org at Dienstag, 12. November 2024, 12:24:14.

[Normal] <client-host.domain.org> Installing Core Component

[Normal] <client-host.domain.org> Installation of Core Component succeeded.

[Normal] <client-host.domain.org> Installing Core Technology Stack

[Normal] <client-host.domain.org> Installation of Core Technology Stack succeeded.

[Normal] <client-host.domain.org> Installing Common Utilities

[Normal] <client-host.domain.org> Installation of Common Utilities succeeded.

[Normal] <client-host.domain.org> Installing Disk Agent

[Normal] <client-host.domain.org> Installation of Disk Agent succeeded.

[Normal] <client-host.domain.org> Installing Automatic Disaster Recovery

[Normal] <client-host.domain.org> Installation of Automatic Disaster Recovery succeeded.

[Normal] <client-host.domain.org> Copying and configuring certificates

[Normal] <client-host.domain.org> Update of client system client-host.domain.org completed.

[Critical] <client-host.domain.org> [110:101] Client import failed!


[Normal] Installation session finished on Dienstag, 12. November 2024, 12:25:47.

[Normal] <client-host.domain.org> Reverting SSH configuration.


============================================================================
 Session completed with errors!
============================================================================

Are there any useful logs to be found to diagnose the problem?

The help I get is like this:

Description:

The successfully installed client could not be imported to the cell.
Possible causes are: improper installation, network inaccessibility
of the client, or Cell Manager malfunction.

Actions:

* Check if Data Protector software works locally on installed client.
* Try to contact the Data Protector client using the command, "telnet <client> <Data Protector port>"
* Check network accessibility of the Cell Manager.
* If necessary, restart Data Protector daemons.
* Try to import the client again, using the GUI.

When I try to connect from a SLES15 SP5 machine I get this error message:

openssl s_client -host client-host.domain.org -port 5565
139745201380352:error:02002071:system library:connect:No route to host:crypto/bio/b_sock2.c:110:
139745201380352:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:111:
connect:errno=113

(it succeeds for another client, and I can ping the client in question without a problem)

I wonder whether https://www.suse.com/releasenotes/aarch64/SUSE-SLES/15-SP6/index.html#security might be relevant

(I had to lower the policies on the client to make a TLS connection succeed)

  • 0

    The version of Data Protector is 23.4...

  • 0

    hello,

    check file allow_hosts, if is empty add CM name.

    Also check certificates from client to CM.

    regards

  • 0 in reply to 

    "allow_hosts" of what product? I cannot see any "allowed_hosts". Can you be  more specific?

    Also, CM *can* contact the client using SSH; otherwise " SSH configuration completed successfully." wouldn't be possible, I guess.

    Likewise for "check certificates from client to CM": It's not actually clear what you are suggesting.

    I'm afraid you cannot edit you message any more to provide useful details.

  • 0 in reply to 

    Hello,

    search on the client etc/opt/omni/client cell_host

    /etc/opt/omni/client/cat cell_server

    should show you CM name

    did you run certificates between client and CM?run in client :

    opt/omni/bin/omnicc -secure_comm -configure_peer CM_name

    regards

  • 0 in reply to 

    There is no such file in /etc/opt/omni/client/.

    Before I had tried a "secure comm": From Client to server it works, but not from server to client.

    The error message is "Error getting certificate from the peer '...'."

  • 0  

    What if you telnet to port 5565 of the client. I'm assuming that is failing too. On the client you could check the status of the inet service:

    systemctl status omni.socket

    You could also look for the omni* config files in /usr/lib/systemd/system (assuming that's the correct path on SLES15 SP6).

    Are any of the systems (client or server) multi homed?

  • Verified Answer

    +2 in reply to   

    Welcome back ;-)

    Using "telnet" is increasingly difficult these days, as standard installations don't have it; probably "netcat" ist the tool to use today.

    netcat -v 172.20.2.24 5565
    netcat: connect to 172.20.2.24 port 5565 (tcp) failed: No route to host

    "systemctl status omni.socket" reports an " active (listening)" status for a week or so, but that statistics look strange:

     Accepted: 0; Connected: 0;
     Tasks: 0

    So no incoming connection? Maybe our sophisticated pranoidly "safe" network infrastructure is blocking the traffic apart from the hosts's firewall configuration. I'l have to check it out (ping of the IP works, however, so it cannot be a routing issue IMHO).

    I also checked the target host's firewall configuration, and even if it's running, and the omni port is allowed, "iptables -L" does not display a single rule, just as if nothing had been set up.

    However on a second glance I saw that the port was 5555

    After changing the port to 5565 netcat reported: "Connection to 172.20.2.24 5565 port [tcp/omni] succeeded!"

    What is new to me is that the error is "no route to host", while I would expect either the packets to be swallowed silently, or getting "connection refused" or "connection reset" or similar.

    In the next step a "/opt/omni/bin/omnicc -secure_comm -configure_peer ..." suceeded, too.

    After that I was able to import the client.

    I completed the verification with a "check installation" and an "Upgrade" (even not necessary). It succeeded as well, and the socket stats for omni socket showed:

    Accepted: 91; Connected: 0;

  • 0   in reply to   

    So glad it is resolved. So if I understood you correctly the port was blocked indeed and so this explains the "No route to host". Thanks for providing the feedback here. This may help others in the future.

  • 0 in reply to   

    The major problem was the poor error message, not much better than "something went wrong".

    The other confusing message was that from the network stack (see also https://unix.stackexchange.com/q/786991/320598).

    Both made it harder for me to find out the true cause of the problem.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.