Active IQ Unified Manager Discussions
Active IQ Unified Manager Discussions
Good day, i am running OnCommand System Manager ver 3.1.1 on Windows.
Today, for the very first time, i have seen this issue: i can connect to my 3210 running DataONTAP 8.0.3P2 7-mode, but when i try to reach my new 2240 running DataONTAP 8.1.3P3 7-mode i recieve an error 500 "connection refused".
I have found this workaround: on the 2240s i have issued the command >options httpd.admin.enable on ;
after this the OnCommand System Manager probably still tries a secure connection, on the console i see errors like
[hostname: HTTPPool03:warning]: HTTP XML Authentication failed from MyClientIP .
But now i guess OnCommand System Manager falls back to a non secure connection, i see the question "do you want to set up a secure connection or continue without...", i answer "continue without" and i'm able to manage my filers again.
What's happened? Maybe something java updates related? Thanks in advance.
Alessandro
I created another post realted to this.
Did you happen to install java 8 client(s)?
Good Morning everyone!
Im struggling with the same issue.
Is there a workaround or a fix to this problem?
My java-client version is 7.45 due to the fact, that we need this exact version for some other applications here.
But if the only way to get the OnCommandSystemmanager working again is to update java, surely i will do the update.
Thanks in advance!
Hello everyone!
I just updated Java to the latest version and this issue is solved.
It seems to be java related.
This is working for OnCommandSystemmanager version 3.1.1 and 3.1.2
BR
Stefan
I have written 2 KB's related to this issue:
KB ID: 2021850
OnCommand System Manager is unable to authenticate clustered Data ONTAP using secure protocols when Java 8u25 is installed on the host
KB ID: 2021507
OnCommand System Manager 3.1 and 3.1.1 do not function when using Java 8.x
I am using OCSM 3.1.1RC1 as well and got upgraded to Java 8 update 31 and am having the same issues with SSL. I also change the .exe with the .jar version and still have the same issues. I uninstalled Java 8 and reverted back to Java 7u75 but that didn't seem to work either. I'm stumped.
Exact same thing here...Removed all traces of Java 8, installed 7u75, got the System Manager to install but cannot connect to anything. Just error 500. Another user here is able to connect without any problems.
I ended up installing Java 8 U 31. Reinstalled OnCommand System Manager 3.1.1RC1 which kept all my filers. But when I try to run the Network Config Checker I get the enclosed errors. When I try to login to the filer themselves I get the other enclosed screenshot. The only thing that changed was the Java upgrade.
I can't seem to find anyone else with this exact type of issue though.
I have had the same issue. If you are experiencing error 500 and are using Windows 7 Enterprise x64 try uninstalling all versions of Java and then install J7 U45 x86 and then J7 U71 x64 then install OCSM 3.1.1.
I had later versions of Java (x86/x64) and OCSM wouldn't launch.
I experienced similar issues when I inadvertently updated my to a Java 8 version.
As previously suggested I did the following to resolve the issue.
- uninstalled OCSM
- uninstalled all Java versions
- reinstalled Java 7 u51
- reinstalled OCSM
It seems to be the case that later versions of Java 7 and especially version 8 are incompatible.
Try following command on all nodes. i had this issue and this fixed it straight away.
options tls.enable on
Thanks cmcn_2015! I had the same isssue , solved it by following above steps. Java 8 does not work with OCSM 3.1.2! But Netapp document say s, it works with Java 8.
I am having a customer with the same security warning prompts as SCOTTY's last screenshot
When I click "Set up a secure connection" it refreshes the page with the same Security Warning
When I click "Continue wihtout secure connection" I get a 500 Connectino Refused error.
We rolled back to Java 7u71 and are still having the issue.
@Scotty wrote:I ended up installing Java 8 U 31. Reinstalled OnCommand System Manager 3.1.1RC1 which kept all my filers. But when I try to run the Network Config Checker I get the enclosed errors. When I try to login to the filer themselves I get the other enclosed screenshot. The only thing that changed was the Java upgrade.
I can't seem to find anyone else with this exact type of issue though.
Hi everybody,
at least I am not alone with that problem...
I tried different versions of the OCSM (3.0 and 3.1.1) on different platforms (2k3 and 7-64) with different java versions 7.74 (? - latest) , 8.25 and 8.31
as FKL said before I first get the
netapp is not configured for secure management -error
and then it divides:
my old netapp 2040 then accepts the insecure connection
but my new 2240 doesnt and return error 500 "connection refused"
i reinstalled the SSH / SSL certificates with no success (at least on my 2240)
i created a new admin-user with a simple password - again with no success
guess i have to create a new VM and start with java 6 (halleluja and java forever )
btw: the solution Chuck offers doesnt work for me
til then
Hilmar
OK, heres my version of a solution:
- a clean Windows-7 64 bit
- Java 7u25 64 bit version
- Firefox 32 (as default browser)
- OnCommand version 3.0
the changes proposed by Chuck are still active - will check if they are needed / helpful :
options httpd.admin.enable off
secureadmin disable all
secureadmin setup ssl
secureadmin enable ssl
secureadmin enable ssh2
options tls.enable on
a simple password only with characters - will check if needed
with that version i successfully connect to my old FAS 2040 and my new FAS 2240 without any error - puah
hope that helps
Hilmar
While removing newer version of Java and installing older versions probably fixes this in most cases, do you really want to run version of software that have known vulnerabilities in them?
I think that companies like NETAPP, EMC, DELL, HP, etc, etc., need to be accountable for staying current. They need to upgrade the applications regularly to stay compatible with the platforms they develop in. The days of write it once and forget it are long gone. The threat vectors have changed and continue to change on a daily basis.
If I had machine that was dedicated to doing nothing other managing storage, network and servers, that never saw any portion of the production network and was isolated 100% from the internet, perhaps leaving archaic versions of depreciated software out there would be an option. The days of doing business this way are also long gone.
Cannot speak for everyone of course, but I don’t have the real-estate on my desk and have no desire to run up down the hall to my MDF every time I want to manage something in the environment.
To clarify, I am 100% in agreement with Chuck. There is no excuse for NetApp not supporting Java 8 when it has been out for this long. In our organization, running outdated versions of Java is unacceptable. Following the steps above, I was able to install the System Manager, then install Java 8, and remove 7--and the entire thing works fine. The big key I believe is that our filers did not have TLS enabled. We removed SSL support from our environment when the Poodle vulnerability was made known. Unfortunately, we did not realize this until going through these steps. We couldn't get it to work no matter what version of Java was installed.
Also--our complex password works just fine 🙂 No reason to use a simple password.
Chuck,
you are absolutely right !
That java chaos is unproductive and annoying.
But let us see my thread not as a political but as a technical thing that helps me (and hopefully one or another) gaining back access to my NetApp again.
Lets see this as a base and maybe theres someone out there who will improve my solution working with actual versions of java.
Cheers
Hilmar
regarding my last version:
------------------------------------------------------------------------
- a clean Windows-7 64 bit
- Java 7u25 64 bit version
- Firefox 32 (as default browser)
- OnCommand version 3.0
options httpd.admin.enable off
secureadmin disable all
secureadmin setup ssl
secureadmin enable ssl
secureadmin enable ssh2
options tls.enable on
a simple password only with characters
with that version i successfully connect to my old FAS 2040 and my new FAS 2240 without any error - puah
----------------------------------------------------------------------------
i did some additional testing:
a) Firefox version 35 is fine
b) an non-complex password is not needed
c) OCSM 3.0 or 3.1.1. does not make a difference
BUT:
d) JAVA does
i tried different versions (thanks to ESX and SNAPSHOTs) in which i upgraded java step by step
6u45 is fine
7u25 is fine
even 7u75 32 bit and 7u25 64 is fine,
but 7u75 32 AND 64 bit installed causes the well known problem
and just to complete: 8u31 32bit uninstalls 7u25 64 bit and therefore is does NOT work
=> my best guess: 7u25 64 bit (in 64 bit environment) iss essential
maybe there are some versions between 7u25 and 7u75 that will work as well
but i do know that 7u25 DOES work, whereas 7u75 DOES NOT
and to complete my research i re-installed 7u25 64 bit after 8u31 de-installed it - and - guess - YEPP , everything is fine
=> install whatever version you prefer, but have 7u25 64 bit installed as well
that directly points me to a question to you Chuck: did you have different versions installed ?
something like : the 32bit version is java 8 but the 64 bit version is an elder java 7 ?
Cheers
Hilmar
I can confirm that java 8 64bit is the problem.
I approved the java updater lately and it updated to java 8u31 32bit and 64bit
The behaviour then was the following when I tried to login to our filers
7.3.7P3 FAS3020 => security question => OK (I know the system is out of support)
8.1.3P1 FAS3210 => security question => OK
8.1.3P1 FAS3220 => error 500
8.1.3P1 FAS3270 => error 500
After struggling a while with different solutions from this thread I uninstalled the 64bit version and reverted to java 7u55 64bit which I had been running before the update.
Now on all filers there is no security question anymore and all logins work OK
I am running 8.31 64-bit and using the steps I provided in my earlier post, I have everything work with SSL/TLS.
Now, granted, there is no 100% garuntee that it works for 100% of everyone. There are other considerations such as individula security settings in the JAVA. I have all of my filers (both by IP address and by host name) as trusted sites in my browser and in JAVA.