After looking for a couple of hours, I decided it's time to ask for some help.
I have a local server of an online game, which has its own command line where the admin can execute different commands, like /kickuid x (which kicks the user with the useruid = x) and many other commands. Here's a screenshot of how it looks like:
I am interested in automatically executed commands, but the problem is that I have no idea of how I could pass a command to the game service through cmd.
I would be very grateful if somebody knows how to(assuming that it's possible) send commands to a running process through cmd or maybe in another way.
No, there is no generic mechanism to "send commands from outside the program".
Possible approaches to look at:
sending keystrokes is one ultimate fallback to automating programs with any UI
some programs expose COM automation interfaces (like Office/IE), or even COM remoting.
some program expose REST remote management API (usually if the rest of program uses some form of HTTP server)
some read configuration/other files
some have custom API to execute commands remotely (i.e. most DB servers)
Related
I have two separate programs. One is a winform that hosts a running process with output/input being redirected through the form. The process is a canned product with little chance of being able to modify it myself.
The second program is a service that can pole data from the running process but it doesn't interact with the winform directly.
My goal is to send a string from the service to the winform to then interact with the running process. OR, I wouldn't mind being able to send commands directly to the process but I'm betting that can't happen without modifying the running process source.
I've look at Named Pipes but I'm not sure that that is the best means. Both programs are hosted on the same machine. I'm just not sure what my options are. Any ideas? =)
The full range if IPC (Inter-Process Communication) options available in Windows is outlined on MSDN.
Clipboard
COM
Data Copy
DDE
File Mapping
Mailslots
Pipes
RPC
Windows Sockets
Then there are mechanisms outside of Windows
MSMQ or similar queue systems
Record commands/state in a database or file
Of all these, Named Pipes is probably the best fit for your particular application. I have used them for similar things in the past. They are easy to setup and use.
There are multiple options to achieve this communication. Mainly you can use Named pipes (WCF), MSMQ
What i want: I want to read the Output of the PuttY Window with C#
What I've got: Our company has several hundreds of servers with at least 2-3 technical users (which are running applications). We got a database of all the users and passwords. So it's basically search, copy and paste to login.
What i want to do: Write a piece of software that does this automatically.
How far i am: Wrote a tool, that reads the logfile of a single PuTTY instance and looks for the password prompt. Determinates target user and server (based on current server and su - [username]). Retrieves the password and sends it via PostMessage to a selected PuTTY.
The Problem or what i want to change:
I want to be able to read the PuTTY output directly from the PuTTY window, because the logfile is kind of unreliable (TAB, ESCAPE, etc which scrambles the output).
I have used UISpy and other tools to get a control, but no luck.
I don't want to use a keylogger mechanism or something like that.
Maybe a hook or something, but have never done that before.
Additonal Info:
Connection is made over a JumpServer, only ssh connections from there to the target servers are allowed.
Direct login with the tech. user is disabled.
The PuTTY window is already opened and used to work on the server.
Writing a whole new Connection Manager is no option. Coworkers are familar with PuTTY and this solution should be some sort of standalone background worker.
Additonal Info 2:
The goal is to write a strict 3rd party software. Not to use other SSH libs, modify PuTTY source or other approaches. The question is: how to read text from the PuTTY window, beside the logfiles.
I don't know why this hasn't been suggested yet, but plink (which is part of the PuTTY suite) is the command-line version of PuTTY, you'll just need to redirect stdin and stdout to get a relatively powerful (as in features, you'll still need to interpret telnet stuff yourself) SSH client.
Have you considered using OCR?
Sketch of solution would be:
1 - Agent runs waiting to notice a Putty Window (either register a callback with OS for new processes or periodically check the list of running processes)
2 - When a putty is noticed, agent takes screenshot and extracts portion of screen occupied by putty. You would need to extract window location, but can be done via OS calls assuming you have a handle from step 1
3 - Pump this image data into tesseract or something, and get text output back. check to see if the password prompt is there
4 - If prompt is there, it sounds like you had the rest done after this (send info needed via PostMessage)
You should take a look at This Link (Putty StdIn / StdOut. Shows how to open putty from a c# app and how to handle Standard In, Out and Error Output to communicate with your putty instance.
If you are using putty as an SSH tool, use http://www.routrek.co.jp/en/product/varaterm/granados.html C# SSH library
If you are using putty as a serial tool use the inbuilt IO classes
Telnet also has C# libraries, none that I can give any knowledgabel input into what is good.
If you can purpose a modified version of putty, you should modify putty sources and including some pipes (or socket) that communicates with your c# application. Like that, your coworker keep the same software.
I have done plenty of C# shell command calls, apps, batch files etc. The other day I was asked if it would be a problem if an executable that I currently run from my web site app, would move to another server on our intranet.
In other words the web site app and the executable that I am running through Process.Start(...) are located on the same box currently - all good there. Now there is a wish to separate the two on two different servers.
I done a few futile attempts to execute an app (located on server B) from server A (where the web site resides).
Is there a way that I have not run cross yet to do this ?
Thanks
PsExec is one way with minimal coding. Using System.Diagnostic.Process, you can call this command:
psexec \\ServerB (path)\myapp.exe arg0 arg1 ...
To control the processes of server A by running an application on server B, you would need an application running on server B that would get controlled remotely somehow.
As an example, let's say server A runs unix, so you could write a application that would connect to server A using ssh, authenticate and then control the processes and whatnot like you do in a shell. If server A does not allow ssh connection, you could write your own application that would be running on server A listening to some connection and commands that would come from an application in server B.
It's quite hard to understand what are your current settings and why would you even want to switch the application from server A to server B, so a little more information would wield you a better answer.
Austin's PSExec approach is probably the easiest approach to executing an EXE on a remote machine, but you may want to consider a potentially more robust solution:
You could modify your command-line app to run as a service and to respond to requests for work and/or data via a WCF (binaryXML/TCP or XML/HTTP) call.
I'm not sure where to get started with simply executing a remote script and returning the output to a web form. In this case we have an application server that executes some 3rd party tools. We'd like to write an interface for our power users that allow them to check the status of various processes and also execute some of the 3rd party admin tools that support has available. The issue is that we only connect to this Linux (RedHat) machine via Putty over SSH. I looked into PsExec but it doesn't seem to handle SSH. I'd like to avoid any large security holes, if possible, but this is intended to be a limited number of users in a closed network.
Thanks for any assistance getting started!
There are several options to do SSH in .NET - although you need a library for that since nothing is built-in:
http://www.codeproject.com/KB/IP/sharpssh.aspx
http://www.rebex.net/ssh-shell.net/ (commercial)
https://www.eldos.com/sbb/net-ssh.php (commercial)
http://sshnet.codeplex.com/
http://granados.sourceforge.net/
I just wanted some input on a project that I'm working on. Basically, I'm creating a service that monitors and processes new files in a directory specified by a configuration file and other parameters through the command line. It should also output text via the command line, i.e. when a user types in '-help' it will display it's usage. A goal is to also make it so that the user can change the configuration file on the fly, so the service will constantly monitor the config file for changes and adjust accordingly.
The challenge I'm seeing is trying to consolidate the ability to enter commands through the command line, display output, as if it were a console app, and have the service be able process these commands while it is running in the Service Control Manager. So far in my research, the solutions I've stumbled upon seem to show how to create a Windows Service App that can also run as a console app, but it either operates as one or the other, not both. Any suggestions or input is appreciated.
UPDATE:
Thank you all for your suggestions, I did some reading on various Windows supported IPC mechanisms. I boiled my options down to File Mapping, Named Pipes and RPC. I'm assuming for now that the Windows Service app and Helper Console app will be on the same computer and will not need to communicate over a network. I'll be looking at Named Pipes first.
The service needs to offer a possibility to communicate with it, but this can't be done directly, it has to be done by some sort of IPC (inter process communication), this could be .net Remoting, WCF, tcp/ip. You will have to write a helper program that parses the command line and uses this IPC to send the commands to the service, which can act appropiately on receiving it.
I would write a console app that sends requests to the service and displays its responses. If you wanted to be clever, you could include both parts in the same executable. I can't think of any way to make the service write to and read from the console while it's running as a service.