One of the hidden gems in Open Enterprise Server, be it running on NetWare or on top of SLES, is NetStorage. This provides web access to your files via a web interface, or via WebDAV. As a web interface, you get to see your drive mappings from your login script parsed, to show in the web interface, as well as your home directory (from the Home Directory attribute in eDirectory). What is nice to see is that Kanaka is using the same infrastructure, so that your Macs, when they login can get their drive mappings as well. Both share the same libraries, which is always nice to see. Reuse is good!

An almost side thing it offers is access to your files via WebDAV. This allows you to map a drive (on Windows) or via a client on Mac OS, or whatever else you need that has a WebDAV client that works. (I quibble since some WebDAV clients work, and some do not).

These are great ways to get access to files from the server, when out of the office, from pretty much anywhere, secure over an SSL connection. I know at the university I used to work at, we had a two node NetWare cluster for thousands of lab users, and we clustered the NetStorage interface, and in fact found a huge number of folk were actually using the NetStorage logins instead of an actual lab. That was only 10 years ago.

The underlying technology used, to parse the logins scripts and act as a client to access files to present via a web interface is called XTier. This was actually part of a cross platform client effort from many years back that never quite got completed. But enough of it was completed to allow it to run on NetWare or Linux to offer the NetStorage service. Amusingly, the only part of the revamped Novell client from that effort that made it, was in fact a server side client, for NetWare, which was then ported over to Linux for OES Linux.

One of the strange decisions (I make no value judgement, only note its existence) is that XTeir stores its configuration in something it calls the Registry. Yes, there is a NetWare Registry and on OES Linux there is one too. There was one thing other than NetStore that used it on NetWare though I am totally drawing a blank on what it was. It has been many years since I last looked at this on NetWare.

On NetWare there is even a tool to browse the Registry (Command line tool is CDBEEDIT, and NoRM (Novell Remote Manager) has a GUI for it). OES Linux calls it much more simply, regedit, and it resides in /opt/novell/xtier/bin and the commands are things like cd to change paths, and ls to list the contents of a path.

The reason for explaining this odd stuff is that the settings for NetStorage (well technically for XTier) are stored in the registry and issues there can leave you stuck.

I recently ran into a NetStorage issue and kept some pretty good notes, so I figured I would share where my issues were as an example of troubleshooting in the hopes at least one of my issues will be something someone else runs across and finds via a web search. I like articles with error codes that explain how to fix them, I assume others do as well.

I was trying to get to NetStorage on an OES2 SP3 server with no luck. I figured, let me check the config in iManager first. I know this is a shortcut to https://myServer/oneNet/nsadmin but I was getting an error.

iManager, File Access (NetStorage). and select Authentication Domains:

###netstorageError-iMan.jpg###

What to do next? Well check the logs. Where are they? In this case, looking at the iManager logs, which is a Tomcat web application, so needs to be here:

/var/opt/novell/tomcat5/logs/catalina.out

2013-07-29 14:08:48,498 [main] INFO  org.apache.jk.common.ChannelSocket - JK: ajp13 listening on /0.0.0.0:9009
2013-07-29 14:08:49,887 [main] INFO  org.apache.jk.server.JkMain - Jk running ID=0 time=0/1540  config=null
2013-07-29 14:08:49,933 [main] INFO  org.apache.catalina.startup.Catalina - Server startup in 25066 ms
input to ShellCommand: rpm -q oes-release
Novell JClient 1.6.1402-1.6.1402.  Copyright 1999 Novell Inc. All Rights Reserved.
count -->0
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
        java.security.cert.CertPathValidatorException: The certificate issued by OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US is not trusted; internal cause is: 
        java.security.cert.CertPathValidatorException: Certificate chaining error
        at com.ibm.jsse2.n.a(n.java:3)
        at com.ibm.jsse2.jc.a(jc.java:501)
        at com.ibm.jsse2.db.a(db.java:144)
        at com.ibm.jsse2.db.a(db.java:416)
        at com.ibm.jsse2.eb.a(eb.java:89)
        at com.ibm.jsse2.eb.a(eb.java:291)
        at com.ibm.jsse2.db.m(db.java:192)
        at com.ibm.jsse2.db.a(db.java:79)
        at com.ibm.jsse2.jc.a(jc.java:184)
        at com.ibm.jsse2.jc.g(jc.java:257)
        at com.ibm.jsse2.jc.a(jc.java:361)
        at com.ibm.jsse2.jc.startHandshake(jc.java:304)
        at com.ibm.net.ssl.www2.protocol.https.b.afterConnect(b.java:125)
        at com.ibm.net.ssl.www2.protocol.https.c.connect(c.java:28)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:959)
        at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
        at com.ibm.net.ssl.www2.protocol.https.a.getResponseCode(a.java:47)
        at com.novell.emframe.netstorage.NetStorage.authenticate(NetStorage.java:1777)
        at com.novell.emframe.netstorage.NetStorage.getXML(NetStorage.java:1664)
        at com.novell.emframe.netstorage.NetStorage.getXML(NetStorage.java:1646)
        at com.novell.emframe.netstorage.NetStorage.getAuthDomainsMainPageData(NetStorage.java:385)
        at com.novell.emframe.netstorage.NetStorage.execute(NetStorage.java:196)
        at com.novell.emframe.dev.Task.execute(Task.java:505)
        at com.novell.nps.gadgetManager.BaseGadgetInstance.processRequest(BaseGadgetInstance.java:858)
        at com.novell.nps.gadgetManager.GadgetManager.delegateToGadget(GadgetManager.java:4253)
        at com.novell.nps.gadgetManager.LaunchService.onDelegateAction(LaunchService.java:86)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:618)
        at com.novell.nps.gadgetManager.BaseGadgetInstance.handleAction(BaseGadgetInstance.java:2371)
        at com.novell.nps.gadgetManager.GadgetManager.processInstanceRequest(GadgetManager.java:1606)
        at com.novell.nps.gadgetManager.GadgetManager.processServiceRequest(GadgetManager.java:1062)
        at com.novell.nps.PortalServlet.handleFrameService(PortalServlet.java:505)
        at com.novell.nps.PortalServlet.processRequest(PortalServlet.java:373)
        at com.novell.nps.PortalServlet.doPost(PortalServlet.java:279)
        at com.novell.nps.PortalServlet.doGet(PortalServlet.java:262)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
        at com.novell.emframe.fw.servlet.AuthenticatorServlet.service(AuthenticatorServlet.java:332)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
        at java.lang.Thread.run(Thread.java:811)
Caused by: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
        java.security.cert.CertPathValidatorException: The certificate issued by OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US is not trusted; internal cause is: 
        java.security.cert.CertPathValidatorException: Certificate chaining error
        at com.ibm.jsse2.util.f.b(f.java:49)
        at com.ibm.jsse2.util.f.b(f.java:16)
        at com.ibm.jsse2.util.e.a(e.java:2)
        at com.ibm.jsse2.yb.checkServerTrusted(yb.java:46)
        at com.ibm.jsse2.hb.checkServerTrusted(hb.java:22)
        at com.ibm.jsse2.eb.a(eb.java:8)
        ... 51 more
Caused by: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
        java.security.cert.CertPathValidatorException: The certificate issued by OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US is not trusted; internal cause is: 
        java.security.cert.CertPathValidatorException: Certificate chaining error
        at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:249)
        at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:215)
        at com.ibm.jsse2.util.f.b(f.java:82)
        ... 56 more
Caused by: java.security.cert.CertPathValidatorException: The certificate issued by OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US is not trusted; internal cause is: 
        java.security.cert.CertPathValidatorException: Certificate chaining error
        at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.java:111)
        at com.ibm.security.cert.PKIXCertPathValidatorImpl.engineValidate(PKIXCertPathValidatorImpl.java:176)
        at com.ibm.security.cert.PKIXCertPathBuilderImpl.myValidator(PKIXCertPathBuilderImpl.java:474)
        at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:386)
        at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:332)
        at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:332)
        at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:195)
        ... 58 more
Caused by: java.security.cert.CertPathValidatorException: Certificate chaining error
        at com.ibm.security.cert.CertPathUtil.findIssuer(CertPathUtil.java:298)
        at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.java:108)
        ... 64 more
java.lang.NullPointerException
        at com.novell.emframe.netstorage.NetStorage.getXML(NetStorage.java:1667)
        at com.novell.emframe.netstorage.NetStorage.getXML(NetStorage.java:1646)
        at com.novell.emframe.netstorage.NetStorage.getAuthDomainsMainPageData(NetStorage.java:385)
        at com.novell.emframe.netstorage.NetStorage.execute(NetStorage.java:196)
        at com.novell.emframe.dev.Task.execute(Task.java:505)
        at com.novell.nps.gadgetManager.BaseGadgetInstance.processRequest(BaseGadgetInstance.java:858)
        at com.novell.nps.gadgetManager.GadgetManager.delegateToGadget(GadgetManager.java:4253)
        at com.novell.nps.gadgetManager.LaunchService.onDelegateAction(LaunchService.java:86)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:618)
        at com.novell.nps.gadgetManager.BaseGadgetInstance.handleAction(BaseGadgetInstance.java:2371)
        at com.novell.nps.gadgetManager.GadgetManager.processInstanceRequest(GadgetManager.java:1606)
        at com.novell.nps.gadgetManager.GadgetManager.processServiceRequest(GadgetManager.java:1062)
        at com.novell.nps.PortalServlet.handleFrameService(PortalServlet.java:505)
        at com.novell.nps.PortalServlet.processRequest(PortalServlet.java:373)
        at com.novell.nps.PortalServlet.doPost(PortalServlet.java:279)
        at com.novell.nps.PortalServlet.doGet(PortalServlet.java:262)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
        at com.novell.emframe.fw.servlet.AuthenticatorServlet.service(AuthenticatorServlet.java:332)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
        at java.lang.Thread.run(Thread.java:811)

The take away from all that trace is probably this segment, occurring multiple times:

javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 

        java.security.cert.CertPathValidatorException: The certificate issued by OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US is not trusted; internal cause is: 
        java.security.cert.CertPathValidatorException: Certificate chaining error

Well that looks like an obvious error. My SSL certificate's signing CA (Certificate Authority) is not trusted. (If it is not obvious to you, then you do not handle SSL stuff enough! Sadly, if you do handle SSL enough, you are very familiar with this stuff). I have a commercial cert, signed by Go Daddy, and this is saying my JVM (which Tomcat runs in) does not trust the signing CA from Go Daddy.

The issue is one very common to SSL. In order to start an SSL conversation, you need to exchange key for encrypting (symmetrically) the conversation. But if someone watches you do that exchange, they just use the key to decrypt it, so that is no help. Thus you need some way to securely decide on the shared secret. For this, SSL uses an asymmetrical key exchange, where a private and public key pair are used. But you need to trust the guy sending you the info. Normally the keystore (in your browser, your Java instance, your .NET instance) trusts most of the well known signing authorities. But if you minted your own certificate from a CA of your own (Can you say eDirectory, with its own CA, and all the certs used internally?) then you need to get the Public Key of the CA into the keystore as a trusted root certificate.

I noticed that Aaron B posted a new tool and explanation that does a great job of explaining this, as well as making it easy to get the trusted root CA from an application:
certfetcher – The easy way to grab public key certificates from available HTTPS, LDAPS, and other services

So which keystore to use? Well, Tomcat is a Java app, so you would expect the instance of Java being used would be the one. I started with:

echo $JAVA_HOME 

which returns

/usr/lib/jvm/java

That means I need to find the cacerts, which holds the default certs that come with the JVM and should be in the lib/security directory in the JAVA_HOME, thus:

/usr/lib/jvm/java/jre/lib/security/cacerts

I checked this keystore, to see its contents, with the command:

keytool -list -v -keystore cacerts  -keypass changeit | less

(Of course, probably need the full path /usr/lib/jvm/java/jre/bin/keytool but you know what I mean. And of course the default password for the cacerts keystore file is usually 'default' or 'changeit'.)

Looks like I have 59 trusted root certificates in there, and my Go Daddy one looks to be good.

Now sometimes, I find that seeing is believing so I tried changing in a GUI tool from IBM I like called KeyMan. Imported the Go Daddy CA public key again, but now, when I start Tomcat I get this error:

java.net.SocketException: Default SSL context init failed: IBMKeyManager: Problem accessing key store java.io.IOException: Keystore was tampered 
with, or password was incorrect
        at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:8)
		

Well that clearly did not work. Lets NOT use that tool again. Besides, the Go Daddy cert was in there. (I just thought this was an interesting error to include).

Turns out the real cacerts file was in:

/var/opt/novell/tomcat5/conf 

Once I added the Go Daddy CA Public Key as a trusted CA then it started to work. Well work better, sort of. It just peeled back a layer on the onion to show the next error.

Now I see a different error when I try to get to the oneNet/nsadmin page to manage NetStorage configurations.

java.io.IOException: Server returned HTTP response code: 401 for URL: https://myserver.mydomain.com/oneNet/nsadmin?label=[authdomains]
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1196)
        at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
        at com.ibm.net.ssl.www2.protocol.https.a.getResponseCode(a.java:47)
        at com.novell.emframe.netstorage.NetStorage.authenticate(NetStorage.java:1836)
        at com.novell.emframe.netstorage.NetStorage.getXML(NetStorage.java:1664)
        at com.novell.emframe.netstorage.NetStorage.getXML(NetStorage.java:1646)
        at com.novell.emframe.netstorage.NetStorage.getAuthDomainsMainPageData(NetStorage.java:385)
        at com.novell.emframe.netstorage.NetStorage.execute(NetStorage.java:196)
        at com.novell.emframe.dev.Task.execute(Task.java:505)
        at com.novell.nps.gadgetManager.BaseGadgetInstance.processRequest(BaseGadgetInstance.java:858)
        at com.novell.nps.gadgetManager.GadgetManager.delegateToGadget(GadgetManager.java:4253)
        at com.novell.nps.gadgetManager.LaunchService.onDelegateAction(LaunchService.java:86)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:618)
        at com.novell.nps.gadgetManager.BaseGadgetInstance.handleAction(BaseGadgetInstance.java:2371)
        at com.novell.nps.gadgetManager.GadgetManager.processInstanceRequest(GadgetManager.java:1606)
        at com.novell.nps.gadgetManager.GadgetManager.processServiceRequest(GadgetManager.java:1062)
        at com.novell.nps.PortalServlet.handleFrameService(PortalServlet.java:505)
        at com.novell.nps.PortalServlet.processRequest(PortalServlet.java:373)
        at com.novell.nps.PortalServlet.doPost(PortalServlet.java:279)
        at com.novell.nps.PortalServlet.doGet(PortalServlet.java:262)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
        at com.novell.emframe.fw.servlet.AuthenticatorServlet.service(AuthenticatorServlet.java:332)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704)
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
        at java.lang.Thread.run(Thread.java:811)

At first I thought it was a possible issue, from TID: NetStorage NSadmin tool does not work in Mozilla Firefox


Which suggests changing the XML name space in this file:

 /opt/novell/netstorage/webapp/admin.xsl

But it turned out not to be the case.

My next thought was, lets check the registry. A good TID on this is: Possible NetStorage Login Latency after Applying OES2 Updates

You will find the regedit tool by:

cd /opt/novell/xtier/bin
./regedit
cd /local_machine/Software/Novell/XTier/Configuration/XSrv/Authentication Domains
ls                   
	NOTE:  the ls command should return an entry that has either the IP address or DNS Name of the authentication server, this will be referred to as <IP or DNS> in the next command
cd <IP or DNS>
ls

What this showed me, is that when I first installed this server (Goodness it was several years ago now) it was with one IP address, but have since moved it, and the old address is still there for LDAP lookups. It was unclear to me how to fix this with regedit command lines, since a rename would have solved it but that did not seem to be an option.

As far I knew, I had not really made any configuration changes on this box, so resetting the registry seemed like the fastest way to proceed.

The good news is there is a good TID on how to recreate XTier keys: How to recreate missing Xtier registry keys

Make sure your LD_LIBRARY path has the right lib directory included. It should out of the box on OES already.

LD_LIBRARY_PATH=/opt/novell/xtier/lib 

Then you can use the xsrvcfg tool to do this with a command like:

/opt/novell/xtier/bin/xsrvcfg -D \-n admin.novell -p adminpass -d auth.server.novell.com -c o=novell

Replacing the following with appropriate values :

    admin.novell with the tree admin user
    adminpass with the password for the tree admin user
    auth.server.novell.com with the IP address or DNS name of the authentication server
    o=novell with the context for context-less authentication

So my example looked a bit more like:

/opt/novell/xtier/bin/xsrvcfg -D \-n admin.mydomain.com -p MyP@ssw0rd -d myserver.mydomain.com -c dc=com

Then, restart the XTier services:

Stop them first:

rcnovell-xsrvd stop
rcnovell-xregd stop

Then start them back up:

rcnovell-xregd start
rcnovell-xsrvd start

Probably good to restart Apache2 and maybe Tomcat with

rcapache2 restart
rcnovell-tomcat6 restart (or tomcat5 if older iManager)

Then you should test the authentication of NetStorage one of many ways.


Results:

myserver:/usr/lib/jvm/java/jre/lib/security # /opt/novell/xtier/bin/xsrvcfg -D \-n admin.mydomain.com -p password -d myserver.mydomain.com -c dc=com
Debug: Server GUID exists. Do nothing.
Setting ProxyUserName
Setting ProxyUserPassword
Clearing AuthenticationDomain
Setting AuthenticationDomain to myserver.mydomain.com
Setting AuthenticationContext[priority] to dc=com

After that, I was able to get to the Authentication Domains page of the https://myServer/oneNet/nsadmin and set up the proper LDAP contexts to look for users and NetStorage was working again.

I know in the past, I have added multiple Authentication Domains on multiple servers, to handle load balancing and cluster support. In this case I was just using the basic out of the box authentication, so resetting the defaults did the trick.

But as you can see it progresses logically from one error to the next, and the logs are kind of obvious. Starting with iManager, look in the iManager log. Where is that? Well iManager is a Tomcat web application, so look at the Tomcat log.

Once you get an error you can work with, work through it, in our case an SSL trusted CA was missing, look at the obvious keystore. But the missing CA public key is in there, so maybe it is in another keystore. Where could that be? Well lets see if there is an iManager specific keystore. Look in the /var/opt file system, since /opt is more for binaries, and /var/opt is more for things that change like logs, etc. /etc/opt is more for configuration files. Then the nsadmin stuff, you need to know about the registry and its possible usages. Look at the settings, and there was the incorrect value. Too bad it is too hard to actually fix, so throw it away and recreate and all done. In hindsight that was all pretty easy, it is more about knowing what to do next, where to look, and how to figure out hints. Which I suppose defines most IT troubleshooting.

Anyway my hope is that this article will get indexed and the next guy with a similar problem will find it and hopefully it will help them. If this does help, add a comment with your particular error case. Or better yet, write some issue you ran into, just like this one, showing the logs, what hints you took from it, where you went next, and how you resolved it.

I personally take notes like this so I remember what I did, and for the next time. Then it is pretty easy to turn the notes into an article like this. Everybody wins!