SMVI Automation from .NET Based Service

[#1]

Hello All,

I'm trying to solve the following issue when using SMVI. The system is a .NET based Windows service running as the "localservice" account that picks up SMVI work tasks from a database. The service then instantiates a .NET Process object and runs the SMVI command. The Process object has access to the StandardInput, StandardOutput and StandardError elements of the process. When the process executes the SMVI command, SMVI launches just fine and asks for the UserName. We are able to send the UserName to StandardInput and the SMVI executable accepts this just fine. The SMVI Executable then prompts for the password. However when we send the password to the SMVI executable via the same method it is not accepted.

We've tried various other methods to get this to work (runinng the service as a named account, piping the password to the smvi executable) all without success.

Is anyone else out there automating SMVI in this manner or some other method?

Thanks!

Jim F.

[#2]

I cannot speak for doing this in .NET as I rarely use it. I'm a UNIX guy. To test this, I did write up a small Java app that you can look through (see attached file). I used Java 1.6 for testing, but the code should run in Java 1.5 as well.

When running this, I see that the wrapper class actually functions correctly, but I think there is a regression in the SMVI server that is resulting in the -user argument no supplying the password properly to the server. I'm going to start debugging this today and will use burt 335095 for any comments on what I find.

Currently, if I run this wrapper class, I see output similar to:

josh@joshb-desktop:~/workspace/SMVIRunner$ java -cp bin/ SmviCliCaller /mnt/joshb/p4/aladdin/client/cli/ ./bin/smvi myuser somepassword 123 backup-test
Started process
Wrote username
Wrote password
SMVI exited with value 1
Security processing failed.

Along with entries like the following in the server log:

2009-01-05 12:53:03,832 [::] ERROR - Incorrect password
2009-01-05 12:53:03,832 [::] WARN -
org.apache.ws.security.WSSecurityException: General security error (WSSecurityEngine: Callback supplied no password for: myuser)

SmviCliCaller.java ‏3 KB

[#3]

I ran my 'smvi servercredential set' from the wrong SMVI directory which caused the authentication problems. Once I corrected it and stored my custom user in the proper location for my SMVI server, everything worked just fine.

If the Java wrapper that I attached is not enough to get you moving, please let me know.

[#4]

Hi Josh,

We also having working code now with .NET. Basically we have a domain user called smvi-runner and an SMVI user named smvi-runner. As long as I log into the server as 'smvi-runner' and manually run a SMVI command to get the credentials cached up, then start the service which is running as the named account smvi-runner then I can get results back.

I have a concern with this method, does the creditional caching ever timeout?

Also, a real issue with this method is that if some one stops the service as a user other than smvi-runner then starts it again, the service will no longer work until someone relogs into the server as smvi-runner, manually runs a smvi command and then starts the service up.

-Jim F.

[#5]

Once you type in a valid password and successfully complete an SMVI command, SMVI will cache that password indefinately. You can remove the cache file (<current users application data>\NetApp\smvi\1.0\client\*) by hand which will force the CLI to prompt for the password again.

If you want to work around your current issue, you can create a SMVI specific user accout (smvi servercredential set) and then use the -user argument like you were attempting to do originally. Otherwise, yes, you will likely have an issue if someone stopped and reconfigured your service to run as a different user.

[#6]

Josh,

Have you tested this on the Windows version of SMVI?

-Jim F.

[#7]

Josh,

We figured out a solution. It turns out when our process was starting, and environment variable was not being set that points to the application data folder. We added that to the code and now it seems to be running alright.

Thanks!

-Jim F.

[#8]

Oh, the APPDATA environment variable? Cool. Glad to hear the original code is now working.

The following is just in case someone else views this thread.

I just ran that Java file under Windows. I had to do two things.

1. Created a cmd file to call Java. Just be careful passing arguments with spaces in the name.

2. Specifiy the path to smvi.exe as the working directory and the full path to smvi.exe as the file/script to run.

For some reason, on Windows, it would not pick up just 'smvi.exe' in the working directory. One I did these, the same Java code ran without issues.