Menu
▾
▴
#128 windows: add remote access to commandline interface
he wrapper commands relating to the windows service (http://wrapper.tanukisoftware.com/doc/german/launch-win.html#exe) are of restricted use because the service is usually at a (remote) server and to issue service related commands you have to login at the remote server or use other tools.
I would like that the wrapper is able to connect to a remote service manager to issue service related commands
all commands use the parameters found in the wrapper.conf. To access a remote service its not really required to enhance this logic.
e.g. wrapper -p N:\path\wrapper.conf if wrapper.exe detects that the effective path to wrapper.conf is at a network drive (i.e. detects that N is a network drive) then the remote servername could be determined using the properties of the network drive and the command could be issued remote.
This could be used for following commands:
-t --start starT an NT service
-a --pause pAuse a started NT service
-e --resume rEsume a paused NT service
-p --stop stoP a running NT service
-r --remove Uninstall/Remove as an NT service
-l=<code> --controlcode=<code> send a user controL Code to a running NT service
-q --query Query the current status of the service
-qs --querysilent Silently Query the current status of the service
(is this a service related command??) -d --dump request a thread Dump
under additional conditions even -install commands could be done remote
if there are concerns about security and/or backwards compatibility this feature could be only enabled if a additional environment property is set:
e.g.: wrapper.ntservice.enable_remote_access
thinkable values could be
0 do not enable remote operate as before
1 enable, if remote access is detected: allow detection of server name and access remote
2:<server name> do not detect server name, access <server name> always if remote ( this if detection of the server name maybe error prone)
with the above semantics the command line interface does not need to be enhanced (exception maybe -install of remote service) and operates remote in the same manner as locally. Even the existing scripts may be used remote without modification
What do you think about it?
Charly
charly,
thanks for your post.
I checked on connecting to a remote Service Manager and think it could be done.
The thing with the auto-detect is IMAHO quite dangerous cos as you also mentioned error prone, so I think it shouldn't be done this way.
But the option to set the remote host with wrapper.ntservice.remote.host for the target sounds good. also maybe sth. like wrapper.ntservice.remote.user, wrapper.ntservice.remote.domain, wrapper.ntservice.remote.password etc. for impersonating, which would work basically like the other account properties.
Would that be acceptable for you?
Christian,
I do not assume that detection of the remote server name is always error prone. I would only have the option to deal with such a case. for example if the share is a DFS share the real server is difficult to detect.
The wrapper.conf file could also used locally (at the rmote server) so there must/should be difference between local access and remote access even if the remote host is configured.
I.e. the service should accessed locally if the caller is locally logged on even if there is a remote servername configured in wrapper.conf.
Such properties like wrapper.ntservice.remote.user, wrapper.ntservice.remote.password sound handy but they are not useful if one is able/allowed to store a (administrator) password into a textfile. If one does not do that, the ability to specify credentials is useless.
But such properties are not really necessary because if you use that way I suggested (with the network drive) then you have access to the wrapper.conf. If you presume that the same access rights which enable you to access the remote file also enable you to access the remote service you will have always access even without the parameters.
So for me it seems necessary that there is a difference between local and remote access with the same file and
properties to specify credentials for administrator access are unnecessary. (I would never use them)
I hope I made it clear what I think.
Charly
I have reconsidered this.
If you will not implement any autodetect this would be no problem for me because I would then implement an autodetection outside of the wrapper.exe within the script. The result of the autodetect would then be used to provide the property wrapper.ntservice.remote.host with the (autodetected or fixed) value of the servername at the commandline of wrapper.exe if remote access is detected. So it is not mandatory for me to have an autodetection implemented in the wrapper binary.
The remote access must be usable without the need to specify a password.
Charly
To simplify matters:
For me it would already be useful to simply have an option that would show:
What commandline parameters provided to "sc.exe" (see http://support.microsoft.com/kb/251192 ) would do the service related command of wrapper.exe locally.
Especially the sc.exe commandline for the wrapper --install command would be helpful.
The sc.exe commandline could then easily manually modified by the user to do actually a remote access.
So no remote access with its difficulties need to be implemented. Simply outputting a sc.exe commandline (based on wrapper.conf) at the console (or logfile) would already be helpful.
For this maybe the wrapper --help command could be extended:
e.g.: wrapper --help -i --> show appropriate "sc.exe Create" commandline
What do you think about it?
Charly