For SC 3.3.0 to SC 3.4.0 both Agent and Server must be upgraded.
The only thing maybe missing is the GUI scheduler. I am going to check with some of the other devs if there is a way to copy the DB tables it uses over otherwise you need to re-create all the schedules in the GUI. If you aren't using them ignore this. We are going to improve this in the future.
I am currenlty not using the GUI schedular in 3.3 but was thinking about it for 3.4. For now, everything is scheduled via cron.
For the GUI schedular, is the GUI required to be running via '/usr/bin/java -jar snapcreator.jar -gui_port 6060'; in order for the jobs to run? Just curious as cron is running as a deamon, I would imagine the java process must be running to manage the GUI schedular jobs.
We did the upgrade in the same way, added the variables to our existing configs, copied the schedule-database, changed the startup scripts, upgraded the agents (and also changed them to run multithreaded). Everything seems to be running fine, but we have a big problem: scServer cannot reach any scAgent...
Can you telnet to agent:port "telnet rs24.asp.local 9089" from scServer?
Also a java error is very strange? The snapcreator binary meaning the agent and the backend server is not written in Java. Please try things from CLI to rule out Java.
The only place I could imagine you seeing a java error is if you do an agent ping from GUI since that java client in that case talks to agent. But snapcreator server binary to snapcreator agent binary = NO JAVA CODE.
Another thing check the /scAgent3.4.0/config/agent.conf? Make sure if you had any security things there from 3.3.0 that you update that, the agent.conf changed so please read about it. Here is what you should have:
Yes, telnet from the server works fine. I checked the agent.conf: it was the original from the tar-file, but there were ^M charaters in the AIX version, so I removed them and restarted the agent, but it is still not reachable.
I need to clarify the java error: that shows up if I do a "test agent connection" from the web gui.
Running a profile from the command line gives this error:
Ok so this is consistent, it means the agent is not reachable which means there is some Network communication issues. Neither the GUI nor the CLI can talk to the agent. This can happen due to following:
1. Firewall (thought if you can telnet the port should be open)
2. Using the wrong agent port
3. Other Network issues
I am thinking maybe option 2? Are you sure you started agent on correct port? You are not using default port wich is 9090. Also are you sure the SC_AGENT setting is correct?
You can send us command you are using to start agent, the SC_AGENT setting in config file, and the output from your telnet command?
Oh another thing if you have ^M in agent.conf that means you probably edited it in windows and copied to unix, is that possible? If you didn't that means they were there wich would be a build issue on our edb. Let us know?
Double check and make sure there are no ^M in your config file. This would explain this issue since SC_AGENT would have ^M and that would mess things up.
If in doubt do this, vi config file, edit select all. Create new file in vi, and paste config there. Then use the new config file.
Yes, we explicitly configured port 9089 for all agents, because 9090 is in use on AIX by the Web System Management daemon. I did find another thing: using telnet, I get a normal (open) connection if I use the single-threaded agent, but the connection is opended and closed immediately if I start the multithreaded agent.
As for the ^M: they are in the .tar.gz package on the NOW site, I did not change anything to the agent.conf file. Oh, and also, the files on NOW are not .tar.gz files, just plain .tar files. gunzip told me they were not in gz format, and tar would not unpack them if I used the -z option. And yes, I removed the ^M from the files.
By the way, besides AIX agents we also have some Linux (x64) agents, and they show the same behaviour. I did not find any ^Ms in the linux files (so that package seems to be more ok than the AIX one), but the errors are the same. To be more specific, both on AIX and Linux, I get:
- scServer Unauthorized when I run the single-threaded agent
- Unexpected end of file when I run the multithreaded agent.
On the agent machine, the multi-threaded agent also shows this warning when I do a telnet or "test connection" from the GUI:
Use of uninitialized value in numeric lt (<) at
/</opt/netapp/scServer3.4.0/snapcreator>HTTP/Daemon.pm line 380 (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.
To help you figure out what was undefined, perl will try to tell you the
name of the variable (if any) that was undefined. In some cases it cannot
do this, so it also tells you what operation you used the undefined value
in. Note, however, that perl optimizes your program and the operation
displayed in the warning may not necessarily appear literally in your
program. For example, "that $foo" is usually optimized into "that "
. $foo, and the warning will refer to the concatenation (.) operator,
We have double checked and the AIX build does have ^Ms in the agent.conf (it appears to be only build with ^Ms anywhere), the wsdl.conf isnt used that is for creating your own APIs so that can be ignored. However we verified this was QA'ed and ^Ms didn't have any effect. Also I just tested downloaded from NOW AIX and Linux package. Installed Linux scServer and AIX scAgent. I am not testing DB just APP_QUIESCE_CMDs and APP_UNQUIESCE_CMDs to agent. Everything works with and without control ^Ms.
With Linux x64 I have a DB2 database and I tested that and everything works as expected, again using packages on NOW
Here is my agent.conf. I did notice if you delete ^M and then add your own ^M then it will break but otherwise they seem to be safely ignored. I would recommend removing them though since you have issue:
You had us all running around like chickens without a head ;D
Still you did uncover the ^M issue, that wasn't expected...we are looking into it but it sounds like no big deal since the ^Ms went through our full QA process so we would have seen an issue if there was one. Still it is something we will want to fix, having ^Ms is not necessary and we will probably BURT it since it is unexpected (well at least from a user perspective).
Thank you so much!
Good luck with SC 3.4.0 I hope you enjoy the improvements we made one of them being much better security controls on agent side
Perhaps it would be nice to warn the user when starting the agent in normal mode, that agent.conf is missing. Now I saw the message when I started the agent in debug-mode, thanks to your example. Otherwise I would probably still be searching...
One of the biggest improvements for us in 3.4.0 is support for HP-UX and the multithreaded agent. We have machine with lots of Oracle instances, in which SMO is a pita to use. I'm glad 3.4 was released on the scheduled date, we will be deploying several hp-ux machines with snapcreator.