Forum Discussion

randes2000's avatar
randes2000
Level 4
7 years ago

Java Admin console fails to start/run on RHEL7 server

I cannot start/launch the Java Admin console (jnbSA) on a RHEL7 client as a non-root user.   As root, the Admin console starts correctly and I can then authenticate with non-root credentials.  I don't want to have to use root.   The Admin console starts correctly on the master server and my four media servers as a non-root user.  I don't wish to use the master or media servers to admin Netbackup any longer.  I also can't install the Windows Remote Admin console as I don't have admin on any Windows system.
 
Issue: As non-root user, run jnbSA. Authentication screen comes up and I enter master server, user and password.  Authentication fails with "The Netbackup Admin Console failed to establish a secure connection with the host '<master server>'.  The request was terminated with error code VRTS-24579."  
As root user, run jnbSA.  Authentication screen comes up and I enter master server, user and password.   Admin console comes up and all is well.
 
Master server - Netbackup version 7.7.2 - Solaris 10 SPARC (no recent configuration changes...really)
Client - Netbackup version 7.7.2 - RHEL 7 virtual machine (new install) Netbackup installation from NetBackup_7.7.2_CLIENTS2.tar.gz download.  This RHEL7 server is backed up via VMWare APIs not Netbackup client.
Master server/client connectivity has been tested and looks good.
 
Java Admin console has never been attempted from a client in this environment.  We have always used the master server, but I wish to change this.  Please don't ask why I just don't use the master server (STIGs and other reasons).
 
This seems to be a permissions issue on the RHEL7 client, but I can't determine what it is.  Veritas support has also been unable to solve this issue and I have submitted a lot of logs and answered a lot of questions.

7.7
Linux
  • randes2000's avatar
    randes2000
    6 years ago

    An update on this issue.  The solution was found by my fellow Netbackup administrator  troubleshooting a new RHEL7 master server install in our DR site. The VRTS-24579 error.  The problem was that our user VRTSatlocal.conf file listed the wrong home directory.   Each user file was originally created on our Solaris master server where /home/<username> is our auto-mounted home directory.   This stems from Solaris using /export/home as the default home directory structure and (a long time ago) us choosing /home for auto-mounting.  Along comes RHEL and it uses /home as the default home directory.  We chose /export/home for auto-mounting home directories.   So my original problem involved attempting to run the Admin Console directly from the RHEL client.  The VRTSatlocal.conf file listed my home directory as /home/<username>, when on the RHEL client it is actually /export/home/<username>.  Changing the lines in the VRTSatlocal.conf file from “/home/<username>” to “${HOME}” solved the problem.  Now, no matter where I attempt to launch the Admin Console, the proper home directory is found in VRTSatlocal.conf file.   Probably a unique situation at our site, so it was hard for Veritas to resolve.

16 Replies

Sort By
  • Thiago_Ribeiro's avatar
    Thiago_Ribeiro
    Moderator
    7 years ago

    Hi,

    From what I understood reading this document maybe you need to deploy a nbu certificate for this client. Take a look

    About security certificates for NetBackup hosts

    NetBackup uses security certificates for authentication of NetBackup hosts. TheNetBackup security certificates conform to the X.509 Public Key Infrastructure (PKI) standard. A master server acts as the Certificate Authority (CA) and issues security certificates to hosts.

    NetBackup provides two types of NetBackup host security certificates: Host ID-based certificates and host name-based certificates. Host ID-based certificates are based on Universally Unique Identifiers (UUID) that are assigned to each NetBackup host. The NetBackup master server assigns these identifiers to the hosts.

    Any security certificates that were generated before NetBackup 8.0 are now referred to as host name-based certificates. NetBackup is in the process of replacing these older certificates with newer host ID-based certificates. The transition will be completed in future releases and the use of host name-based certificates will be  eliminated. However, the transition is ongoing and NetBackup 8.0 continues to require the older host name-based certificates for certain operations.

    For more information about deployment, management, and usage of security certificates, see the NetBackup Security and Encryption Guide.

    Depending on the NetBackup host type and the certificate type, deployment of certificates varies. Consider the following scenarios:

    NetBackup master server
    Host ID-based certificates and host name-based certificates are automatically deployed during NetBackup installation and upgrade.

    Clustered NetBackup master server
    Host ID-based certificates and host name-based certificates may not be automatically deployed on all nodes.

    NetBackup media servers and clients
    Depending on the settings on the master server, host ID-based certificates may be automatically deployed on media servers and clients.Host name-based certificates are manually deployed using the command-line interface.

     

    Thiago

    • randes2000's avatar
      randes2000
      Level 4
      7 years ago

      The RHEL7 system accepted a certificate from the master server on first connection.  I was root when I first made the connection and I wonder if this may have set permissions that are preventing non-root users from using the Java Console.

      The user is not using Active Directory, but LDAP is used for authentication on the RHEL7 system.  How do I view this Etrack Number?

  • Amol_Nair's avatar
    Amol_Nair
    Level 6
    7 years ago

    Do you still have the case open or was it closed?

    Probably enabling EAT logs for the java console may help in identifying if there is a permission related issue reported when any of the paths are being accessed in the background when the console is launched and you attempt to login using a non-root user