Data Backup and Recovery

SnapCreatorAgent 4.1.0 won't start

SVOLLRAT1
8,196 Views

Hi Guys

We are currently trying to Upgrade to SCA 4.1.0 from previous 4.0 and 3.6 Installations.

We backed up the Configs and Logs and deinstalled the old Agent as described in the Install-Guide.

Installing the new Agent also works fine but it never starts it afterwards.

According to the ServiceLog it fails with java.

[2014-02-17 17:29:17] [info]  [ 8060] Commons Daemon procrun (1.0.15.0 64-bit) started

[2014-02-17 17:29:17] [info]  [ 8060] Running 'SnapCreatorAgentService' Service...

[2014-02-17 17:29:17] [info]  [ 7708] Starting service...

[2014-02-17 17:29:17] [error] [ 7708] Failed creating java

[2014-02-17 17:29:17] [error] [ 7708] ServiceStart returned 1

[2014-02-17 17:29:17] [info]  [ 8060] Run service finished.

[2014-02-17 17:29:17] [info]  [ 8060] Commons Daemon procrun finished

I'd expect that the Installer contains everything it needs including a standalone java client.

Installing a general use Java Client on a productive Server is strictly forbidden with most of our customers due to the massive security concerns this brings.

Even after installing a JRE (tried 7u51) on a Test-System it won't work. What am I doing wrong?

BR Stefan

10 REPLIES 10

SVOLLRAT1
7,736 Views

Finally got the Agent working, had to get a x64 Java Version, wouldn't work with a 32bit one.

Now I have the issue that 4.1 and 4.0 won't communicate with each other.

Last time in discussion I was ensured that Agent-Communication would be kept fixed from Version 4 on so that no immediate update of every System is required.

ktenzer
7,736 Views

Hi Stefan,

Yeah the java bit version must match between OS and SC.

As for 4.0 agents, they are supported using a 4.1 SC server. Can you share the error message and server / agent logs?

Regards,

Keith

SVOLLRAT1
7,736 Views

HI Keith

Right now the productive Server still runs 4.0p1, for good reasons.

If you try to contact a 4.1 client the response is like the client is not online although it is.

I’d expect something like a “to new client, not supported” message if that is the case at all.

With other Software we know that Server always should be the highest version but it usually works normal with newer clients, then restricted to the abilities of the oldest Version.

Freundliche Grüsse / Kind Regards

Stefan Vollrath

T-Systems Schweiz AG

Storage & Backup Operations

Stefan Vollrath

Storage Engineer

Murgenthalstrasse 12, CH-4901 Langenthal

+41 (0) 78 645 1076 (phone)

E-Mail: stefan.vollrath@t-systems.com

http://www.t-systems.ch<http://www.t-systems.ch/>

Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

Von: Keith Tenzer

Gesendet: Dienstag, 18. Februar 2014 16:30

An: Vollrath, Stefan

Betreff: - Re: SnapCreatorAgent 4.1.0 won't start

<https://communities.netapp.com/index.jspa>

Re: SnapCreatorAgent 4.1.0 won't start

created by Keith Tenzer<https://communities.netapp.com/people/ktenzer> in Snap Creator - View the full discussion<https://communities.netapp.com/message/125773#125773>

Hi Stefan,

Yeah the java bit version must match between OS and SC.

As for 4.0 agents, they are supported using a 4.1 SC server. Can you share the error message and server / agent logs?

Regards,

Keith

Reply to this message by replying to this email -or- go to the message on NetApp Community<https://communities.netapp.com/message/125773#125773>

Start a new discussion in Snap Creator by email<mailto:discussions-community-products_and_solutions-databases_and_enterprise_apps-snapcreator@communities.netapp.com> or at NetApp Community<https://communities.netapp.com/choose-container.jspa?contentType=1&containerType=14&container=2481>

ktenzer
7,736 Views

Hi Stefan,

The Server always must be at same version or one higher than agent, we never supported a lower verison server talking to higher verison agent. What is the use case for this?

In 4.1 we re-wrote the agent, it has REST API endpoints whereas in 4.0 this agent has SOAP endpoints. The 4.0 SC server has no idea how to even talk to a 4.1 agent.

Regards,

Keith

SVOLLRAT1
7,736 Views

So the same stuff as with 3.x and 4.0 all over again.

With those major Versions I somehow understood but with minor Versions they should be able to talk in each configuration within a version family.

The main issue for me: why isn’t everything needed for the agent included in that Package?

Why deliberately creating a security hole on a System by requiring one of the most bug proven Software to be additionally installed and maintained?

Freundliche Grüsse / Kind Regards

Stefan Vollrath

T-Systems Schweiz AG

Storage & Backup Operations

Stefan Vollrath

Storage Engineer

Murgenthalstrasse 12, CH-4901 Langenthal

+41 (0) 78 645 1076 (phone)

E-Mail: stefan.vollrath@t-systems.com

http://www.t-systems.ch<http://www.t-systems.ch/>

Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

Von: Keith Tenzer

Gesendet: Mittwoch, 19. Februar 2014 09:41

An: Vollrath, Stefan

Betreff: - Re: SnapCreatorAgent 4.1.0 won't start

<https://communities.netapp.com/index.jspa>

Re: SnapCreatorAgent 4.1.0 won't start

created by Keith Tenzer<https://communities.netapp.com/people/ktenzer> in Snap Creator - View the full discussion<https://communities.netapp.com/message/125822#125822>

Hi Stefan,

The Server always must be at same version or one higher than agent, we never supported a lower verison server talking to higher verison agent. What is the use case for this?

In 4.1 we re-wrote the agent, it has REST API endpoints whereas in 4.0 this agent has SOAP endpoints. The 4.0 SC server has no idea how to even talk to a 4.1 agent.

Regards,

Keith

Reply to this message by replying to this email -or- go to the message on NetApp Community<https://communities.netapp.com/message/125822#125822>

Start a new discussion in Snap Creator by email<mailto:discussions-community-products_and_solutions-databases_and_enterprise_apps-snapcreator@communities.netapp.com> or at NetApp Community<https://communities.netapp.com/choose-container.jspa?contentType=1&containerType=14&container=2481>

ktenzer
7,736 Views

Well we re-wrote the SC Agent 4.1 from scratch and we only communicate now using HTTPS. In addition plugins use a token and it has a token based authentication so there are a lot of security enhancements in 4.1. In addition from stability perspective it is much more stable and we have tested it in fairly large environments.

I agree the SC 3.x and 4.0 agent (which is same code base) was not to the level it needed to be which is what drove us to do a complete re-write.

We definitely would like to start supporting more versions from SC server, I am not sure about a newer agent and older server, but certainly we can look at this. Now that the server and agent code base is the same this could be a possibility.

Keith

SVOLLRAT1
7,736 Views

Hi Again

Security Enhancements within is nice but what about the Security Risks it causes for everything else?

Wouldn’t it be a better idea to include the required Java, possibly stripped down to the bare minimum within the Agent/Server itself?

Dependencies on OS-Patches and Modules is fine for me but requiring 3rd Party Software to get basic functionality working is something we rarely come across in Enterprise Enviroments (requiring those for extended functions like OpenStorage, SMI-S, VSS-HardwareProviders or SSEA is legitimate).

I can almost count the hours until the Audit-Reporter will sound the red alarm caused by an outdated Java-Runtime on a Productive Server.

Freundliche Grüsse / Kind Regards

Stefan Vollrath

Von: Keith Tenzer

Gesendet: Mittwoch, 19. Februar 2014 09:51

An: Vollrath, Stefan

Betreff: - Re: SnapCreatorAgent 4.1.0 won't start

<https://communities.netapp.com/index.jspa>

Re: SnapCreatorAgent 4.1.0 won't start

created by Keith Tenzer<https://communities.netapp.com/people/ktenzer> in Snap Creator - View the full discussion<https://communities.netapp.com/message/125823#125823>

Well we re-wrote the SC Agent 4.1 from scratch and we only communicate now using HTTPS. In addition plugins use a token and it has a token based authentication so there are a lot of security enhancements in 4.1. In addition from stability perspective it is much more stable and we have tested it in fairly large environments.

I agree the SC 3.x and 4.0 agent (which is same code base) was not to the level it needed to be which is what drove us to do a complete re-write.

We definitely would like to start supporting more versions from SC server, I am not sure about a newer agent and older server, but certainly we can look at this. Now that the server and agent code base is the same this could be a possibility.

Keith

Reply to this message by replying to this email -or- go to the message on NetApp Community<https://communities.netapp.com/message/125823#125823>

Start a new discussion in Snap Creator by email<mailto:discussions-community-products_and_solutions-databases_and_enterprise_apps-snapcreator@communities.netapp.com> or at NetApp Community<https://communities.netapp.com/choose-container.jspa?contentType=1&containerType=14&container=2481>

ktenzer
7,736 Views

Including Java is something we discussed and may do but it has major downsides and security risks. If there is a security patch for example to Java, today you just upgrade Java, but if we bundle or package Java we may lose this capability. There may be a middle ground where we can install Java and it could be upgraded by customers, depends on how tightly we bundle.

The other major issue is usually there is some other Java version installed and this can create conflicts and cause a lot of issues with other applications.

Finally there are potential legal issues with shipping Java, so this is something we would also need to investigate.

It isnt quite a simple problem but I agree we definitely need to make things work out-of-box without forcing customer to install additional software (java).

SC btw doesnt have problems with newer versions of Java but rather older versions. I think you need to be at 1.6.24 or higher but I understand your issue. You cant install software on the host like java or update host often so this is something we need to solve. I think our current approach works for some customer profiles where updating software isnt as big a deal but for your profile I do see it creates problems.

One thought is you could create a package with SC Agent and Java and create an install script. This could be certified by security team and as such then you could standardise and make things easier. Obviously just a workaround that we arent providing this but a thought at least.

Are you looking for us to ship java with SC agent or tightly couple our code with java JVM into a binary and thus completely hide Java?

Keith

SVOLLRAT1
7,736 Views

Hi Keith

How you ship and package Java with the Agent and Server is up to you.

My Problem is just requiring Customers to install and manage additional Software that they don’t need or don’t want at all.

NetBackup and DataProtector for example ship a minimal Java-Runtime included in there Lib-Directories (DP also includes its own Perl).

Since that Software doesn’t need its Directories included in PATH-Variable it is almost impossible that another Software gets to those JREs, also they only include Functions used by their own Software, almost nothing more than that.

Yes it could be a Security risk if a attacker knows a vulnerable Version of that Software is installed, knowing the usually non-Default install path and which Functions are available to exploit. With a general JRE that simply can be queried using the Search-Path with a know Functionset this is very more likely to succeed.

Patching of those REs is done with the regular General Release Patches, again adjusted to the specific need.

Biggest Advantage on that Approach is its Independence.

We have Management Servers with old SAP-GUIs using 1.4 Java Versions (or even older), a DP-GUI with Java 1.5 and four NetBackup-Consoles ranging from Java 1.4 to 1.7.

All working perfectly well without interference.

Freundliche Grüsse / Kind Regards

Stefan Vollrath

T-Systems Schweiz AG

Storage & Backup Operations

Stefan Vollrath

Storage Engineer

Murgenthalstrasse 12, CH-4901 Langenthal

+41 (0) 78 645 1076 (phone)

E-Mail: stefan.vollrath@t-systems.com

http://www.t-systems.ch<http://www.t-systems.ch/>

Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

Von: Keith Tenzer

Gesendet: Mittwoch, 19. Februar 2014 10:15

An: Vollrath, Stefan

Betreff: - Re: SnapCreatorAgent 4.1.0 won't start

<https://communities.netapp.com/index.jspa>

Re: SnapCreatorAgent 4.1.0 won't start

created by Keith Tenzer<https://communities.netapp.com/people/ktenzer> in Snap Creator - View the full discussion<https://communities.netapp.com/message/125824#125824>

Including Java is something we discussed and may do but it has major downsides and security risks. If there is a security patch for example to Java, today you just upgrade Java, but if we bundle or package Java we may lose this capability. There may be a middle ground where we can install Java and it could be upgraded by customers, depends on how tightly we bundle.

The other major issue is usually there is some other Java version installed and this can create conflicts and cause a lot of issues with other applications.

Finally there are potential legal issues with shipping Java, so this is something we would also need to investigate.

It isnt quite a simple problem but I agree we definitely need to make things work out-of-box without forcing customer to install additional software (java).

SC btw doesnt have problems with newer versions of Java but rather older versions. I think you need to be at 1.6.24 or higher but I understand your issue. You cant install software on the host like java or update host often so this is something we need to solve. I think our current approach works for some customer profiles where updating software isnt as big a deal but for your profile I do see it creates problems.

One thought is you could create a package with SC Agent and Java and create an install script. This could be certified by security team and as such then you could standardise and make things easier. Obviously just a workaround that we arent providing this but a thought at least.

Are you looking for us to ship java with SC agent or tightly couple our code with java JVM into a binary and thus completely hide Java?

Keith

Reply to this message by replying to this email -or- go to the message on NetApp Community<https://communities.netapp.com/message/125824#125824>

Start a new discussion in Snap Creator by email<mailto:discussions-community-products_and_solutions-databases_and_enterprise_apps-snapcreator@communities.netapp.com> or at NetApp Community<https://communities.netapp.com/choose-container.jspa?contentType=1&containerType=14&container=2481>

ktenzer
6,856 Views

Hi Stefan,

Thank you for taking the time to give examples, this does sound very interesting and we have certainly been discussing some of these options. I will take this back to the team and I am hopeful we can provide a solution that doesnt require customer to manage additional software such as Java.

Regards,

Keith

Public