Unsolved
1 Rookie
•
4 Posts
0
96
November 26th, 2024 18:36
networker datadomain device failure
I am trying to configure devices a networker 8.2.4.10 backup server with nmc server 8.2.4.10 to a Datadomain (7.13.1.10-1136647) but it is failing with error ( cant upgrade this backup server to version 19) at the username, and password configuration.
user and password are correct
1732026726 1 5 0 1423943424 26236 0 "nmc server" gstd NSR notice 5 %s %s 2 0 24 11/19/24 15:32:06.852233 0 252 ddsm: failed to connect ddcl
: Connecting to 'Datadomain"' failed [5341] ([26236] [140605768312576] Tue Nov 19 15:32:06 2024 ddpi_connect_with_user_pwd() failed,
Hostname: "Datadomain", Err: 5341-SSL_connect returned 1).
On the datadomain side we see the following
11/26 11:48:58.786744 [7fd324ceef70] nfs_rpc_svc_idx0 accepted 80000065a 715 from 10.78.161.102:50978
11/26 11:48:58.787739 [7fefc2469810] ddboost: <nmcserver-50978>, cipher_info: 0, cipher_strength: 1, auth_mode: 3
11/26 11:48:58.788688 [7fd327a15030] SSL_read get error 1 [s3_srvr.c:1427 0 error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:]
11/26 11:48:58.788742 [7fd327a15030] nfs_rpc_svc_idx0 destroyed tcp 80000065a
The backup server has device configured to another datadomain (7.13.1.0-1107703).
I can ssh with user and password from nmc to DataDomain.
I can telnet DD ports from BS and NMC.
I tried configuring from another networker 8 server and same error.
I tried manually creating the DD.
Tried messing with httpd.conf file,
/opt/lgtonmc/apache/conf
# Secure (SSL/TLS) connections
Include conf/extra/httpd-ssl.conf
created a httpd-ssl.conf in /conf/extra
SSLSessionCache shmcb:/opt/lgtonmc/apache/logs/ssl_scache(512000)
<VirtualHost _default_:443>
SSLEngine on
#SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLProtocol all -SSLv3
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5
SSLCertificateFile /etc/ssl/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>
Dell wont support because of old version of networker.
Brahmaiah E
1 Rookie
•
73 Posts
0
November 27th, 2024 21:06
If possible reach me out on <Private data removed from public view. DELL Admin> we can connect over zoom or teams and try to resolve the issue
(edited)
networker19
1 Rookie
•
4 Posts
0
November 28th, 2024 11:39
@Brahmaiah E for obvious security i cannot do that, but if you have ideas, share in this forum
bbeckers1
2 Intern
•
191 Posts
0
December 5th, 2024 20:59
NW8.2 SP4 is not being supported for a very long time now (EOSS June 30th 2018!). Also it uses a ddboost lib version that is way too old compared to what the latest DDOS7.13 is running.
"NetWorker 8.2.x Compatibility All Reports March 11, 2020" states:
"NetWorker 8.2.x includes DD Boost library 3.0.x, supports DDOS 5.3.x, 5,4.x, 5.5.x,,5.6.x and 5.7.x".
While a similar document for nw9 stated :
"Networker 8.2.4 & 9.x.x supports DDOS 6.0 & DDVE 3.0. DD Cloud Tier feature of DDOS 6.0 is not supported with NW8.2.4 and 9.0.x." and:
"NetWorker 9.0.1 includes DD Boost library 3.2.1.2 and supports DDHA"
Of course at the time ddos7.13 did not exist yet, but as the ddboost libraries required for NW clients was always developed further, at a certain point the ddboost lib will no longer be able to talk to a DD anymore. nw19.11 has ddboost lib 8.0.0.0, while nw18.1 has ddboost lib 3.4.2.0 supporting only "Dell DD OS: 6.0.1, 6.0.2, 6.1.1, 6.1.2, 5.7.x".
Also nowadays running ddos7.x, we know that certain older clients will no longer be able to perform any ddboost actions as their ddboost lib is simply too low, hence Client Direct will not work and they will fall back to using the legacy method and that is sending data full blown to their configured NW storage node which will have to perform all the dedupe activities dealing with the dd system.
So it will simply stop working at a certain point, albeit at times not supported doesn't mean it doesn't work, as the legacy method via the NW SN (or backup server) makes it still work for very old NW clients...
What is the impossibility of upgrading the nw8.2.4 backup server? An unsooprted OS version that nw9 and up no longer support like Sun Solaris or HPUX if not possible to upgrade, deploy another nw server next to it and migrate any clients over? Even if those clients themselves might be running too low a NW client version, at least they would be using a nw server (and if used NW storage nodes) that would be able to talk to a DD with a current ddboost lib version and be able to perform Client Direct.
So what is the issue of not being able to upgrade?
BTW I also expect at a certain point also that it will no longer work to backup old nw client versions with the latest and greatest nw server version. Still one can backup a nw8 client on a nw19.9 backup server for example, but as soon as a nw server might no longer accept such old clients, it is all over...
If not via ddboost, worse case you can still create an AFTD device and use a NFS or CIFS share on the DD to backup towards. But no longer any of that Client Direct dedupe occurring, so dedupe would be done after the fact (so once it was written to the DD) and not on already occurring on client end... so way more backup traffic to be expected.
I can't recall that any nw8 client worked with a ddos7.x version, let alone that it would work for a nw8 backup server and NW SN with that old a version. The last nw8 nw server we had was still using ddos 6.2 or so, but not ddos7.x, so don't have any hands-on experience with that...
networker19
1 Rookie
•
4 Posts
0
December 5th, 2024 21:33
I don't make the rules, I am fully aware the issues with having a networker server on version 8.
Issue is resolved now anyway. Data domain is configured now and backups running successfully.
The issue related to a setting on datadomain, once the setting was to none I was able to configure the DD.
bbeckers1
2 Intern
•
191 Posts
0
December 6th, 2024 09:42
@networker19 setting to "none"? So for the ddboost user being used? What was the setting before?
So you might be lucky that it even still works.
Presumably it is not using Client Direct but rather writing to the defined ddboost device. I reckon that clients also might not be able to write directly to the data domain but rather would use the NW storage node (or backup server if there are no storage nodes used)?
The daemon logs would show that I guess stating using the legacy method to backup and not stating it established a direct connection with the data domain in question? Then again I can't recall the exact wording from nw8 at the time compared to more current nw server and storage versions and the way that this fallback mechanism from Client Direct was actually logged on a nw8.2.4 backupserver as it was called Direct File Access (DFA) before?