I'm in the middle of upgrading my 8.1.2 Solaris 10 and 11 Sparc clients to v8.3, but because some/most of the clients are behind firewalls or in the DMZ, I can't seem to run the nbcertcmd on them to get a certificate. So now I'm trying to do the dance of:
nbcertcmd -createCertRequest -requestFile /tmp/cert-req -server nbu-server
then I copy the /tmp/cert-req file to my "nbu-server" and run on the "nbu-server" (which is running: Solaris 11.2 sun4v sparc) the nbcertcmd to sign the request, but the **bleep** thing fails.
# /usr/openv/netbackup/bin/nbcertcmd -signCertificate -validFor 2D -requestFile /tmp/cert-req -certificateFile /tmp/cert-signed
Option '-noPrompt' is not valid when used with operation '-signCertificate'.
Option '-file' or '-validFor' is mandatory to complete operation '-signCertificate'.
Usage: nbcertcmd -signCertificate
-validFor | -file <authorization_token_file>
Reads the certificate signing request from the specified request file and sends
it to the master server to get a NetBackup CA-signed certificate. The signed
certificate is stored in the specified certificate file. The command must be
executed on the NetBackup host that has connectivity with the master server.
Specifies the path of the certificate file.
Path of the file containing authorization token on the first line.
Specifies the path of the certificate request file.
Indicates that an authorization token is used for the request. Prompts the user
to securely specify a token.
EXIT STATUS 20: invalid command parameter
I don't use the "-noPrompt" flag anywhere. And I can't figure out how to make this work. Do I really need to also regenerate a token for this client? I have to say that this entire move to security has been a total pain in the ass, because it's makes things so fragile. I wish I could just turn this off for internal only hosts.
Solved! Go to Solution.
I've been trying to use both the GUI upgrade process, then the CLI with install_client_files ssh <client>, and now I'm just copying the **bleep** packages over and doing 'pkgadd -a .pkg_defaults -d VRTSnbpck.pkg VRTSnbpck; ...' to try and get this to go forward.
The VRTSnbpck package never installs properly because of the nbcertcmd failures, so I just skip it and do a force install of the VRTSnbclt, VRTSnbjre, etc as given in this document (typo corrected of course).
So I'm not really screwing this up I don't think, it's that it's really just too **bleep** fragile. And of course there's the lovely gem that says you need to login as root to the GUI otherwise you can't do any of the Certificate management, even though my user account has full Admin access.
No, I'm not frustrated on a friday afternoon. :)
@jstoffel-tosh out of curiousity - why do you need new certificates? You say you are upgrading 8.1.2 clients and these would have required certificates to operate.
How does/did NetBackup operate for these clients prior to your attempt to upgrade?
Have you checked the usage of the WEB_SERVER_TUNNEL and WEB_SERVER_TUNNEL_USE options for the clients to use a HTTP tunnel via the media server?
Both the GUI method and the CLI with install_client_files are for new installations only, not upgrades.
Plus I would never even think of using any of those methods with new installations in a DMZ. ssh is normally not allowed and one needs to jump through a number of hoops to get it allowed.
update_clients command is used for upgrades where regular NBU ports are used to push new software, but there is a newer, better option : vxupdate.
Details in chapter 7 of NBU 8.3 Upgrade Guide.
As per @davidmoline , there should be no reason to re-add or re-register security certificates (already added with 8.1.2).