run exe on different computer

[Sean DiZazzo]

On Sep 13, 4:57 pm, Dave Angel <da... at ieee.org> wrote:
> daved170 wrote:
> > On Sep 13, 2:17 pm, Dave Angel <da... at ieee.org> wrote:
>
> >> daved170 wrote:
>
> >>> Hi everybody,
> >>> I'm building a small python program that run a service (exe file) on
> >>> my servers.
> >>> I don't want to use remote desktop and it's siblings.
>
> >>> I would like to have some information on how to run an exe on a
> >>> different computer and if there a way to check if that exe is still
> >>> alive.
>
> >>> Thanks
> >>> Dave
>
> >> On a question like this, you really need to supply much more information
> >> on your constraints.  You could start by saying these servers are
> >> running Windows Server 2003.  And that they're on a domain (rather than
> >> a workgroup).  And that you're trying to access them from another
> >> machine within the same local domain, not over the internet.  And that
> >> your local machine is on the same domain, and has an account with admin
> >> privileges for all the desired servers.  And that you are allowed to do
> >> a one-time install (of something) on each server prior to this
> >> particular need.  And that each server already has Python version 2.5
> >> installed, and the IT department won't allow you to install any later
> >> version.
>
> >> Then once you have an environment, you need to specify just what kind of
> >> program you want to run on those servers.  Is it an EXE program?  Or is
> >> it Python, with a particular script?  Does it really need to be a
> >> *service*, which has a particular set of constraints, and should be
> >> installed, and started/stopped using the service manager.  Do you want
> >> this program to restart whenever the servers are restarted?
>
> >> One solution that should work for nearly every Windows topology might be
> >> to go to each server, run the scheduler task, and specify a new batch
> >> file to be run upon boot.  This batch file can check a specified
> >> (shared) directory for a python script, and if found, run it.  If not
> >> found, sleep for 60 seconds or so, then repeat.  Note that it's a good
> >> idea to put a five minute delay at the very beginning, in case the
> >> script needs to be deleted at the next boot.  Sometimes a bug requires
> >> surgery, and it's good to have enough time to do it.
>
> >> Now, to control those servers from another machine, copy an appropriate
> >> script into the prearranged directory.  Within a minute, it'll be
> >> running, and it can post whatever results it likes in another accessible
> >> directory.
>
> >> Whether this is a "safe" thing to do is a separate question.  Generally
> >> an IT department likes to have some control over just what programs run
> >> on their servers, and for good reason.
>
> >> DaveA
>
> > Hi DaveA
> > Thanks for your answer. I'll try to clearify myself.
> > For now I'm trying to do that on client & server that are win XP. They
> > both on the same domain (maybe in the future they'll be runinig on the
> > web). I have admin user on both my computers.
> > I have both an exe and a python app that I'd like to control from my
> > client.
> > Insted of logging to my Server I would like to write a python app at
> > my client that allows me to control both that exe and my Server-python-
> > app. I don't want to use the schedualer because I would like to
> > control it from my client.
> > I can install whatever I'll like on both of the computers. they are
> > mine and I have full access for them.
> > I hope I clearify myself and if there are more solutions I'll be happy
> > to be noted.
> > Thans
> > DaveD :)
>
> If you only have those two machines, you aren't on a NT domain, you've
> got a workgroup.  A Windows domain is hosted by a server OS, and XP can
> only be a client on a domain.  Without being on an NT domain, security
> is much sloppier.  In some ways that makes things easier, but you may
> hit a brick wall if you need more than one kind of simultaneous access
> to another machine.
>
> Is this EXE file you want to run on the server something out of your
> control, or could you customize that as well?  Because if you can, then
> the distinction between that and your server-python program is probably
> unimportant.  Call the programs you might want to run:   X1, X2, X3.
>
> In order to run X1 on that server without opening a console (or remote
> desktop, or whatever) on it, you will have to have something else
> already running which is willing to be a proxy on your behalf.  You then
> communicate with that program to tell it what to run, and when.  I
> suggested a batch file for that program, call it S.  It could just as
> easily have been a python script, but there's no advantage that I can
> see.  The idea is to make sure that S is always running (which is why
> you put it into the scheduler;  it'll be restarted whenever the machine
> is booted).
>
> Anyway, the idea is that S is a very lightweight program, and it can
> launch any possible Xn.  And the only question is how you want the
> client to talk to S.  If S is a fancier program, you might use sockets,
> or whatever, but on a local system, the file system works pretty well.  
> And a batch file is about as lightweight as you can get;  the only
> external program it needs is "sleep.exe".
>
> It's quite possible that DCOM (for example) includes something that acts
> like S, but when I was working in that field 15 years ago, it was very
> messy, and fragile.  I favor simpler systems when they're possible.  If
> you want to pursue this route, check out the Win32 extensions  http://sourceforge.net/projects/pywin32/(or just get ActivePython,
> which includes them with the usual stuff).  See function
> CoCreateInstance <pythoncom__CoCreateInstance_meth.html>, which can
> launch an OLE Automation Server remotely.
>
> Or you could run SimpleXMLRPCServer on your server (again, from the
> scheduler).  Once started, it watches for requests over the internet.
>
> Once X1 is running, you probably want to use sockets or something like
> that to communicate between your client and X1.  At that point, the
> overhead isn't as important.
>
> HTH
> DaveA

+1 to XMLRPC

I guess that is assuming you can just fire it off and let it work.  It
would be much more difficult to set up a gui on a remote machine that
controls a server program.

Here's a link to code I use for a windoze xmlrpc server that runs as a
service on several server machines.  http://www.mail-archive.com/python-list@python.org/msg150695.html

You can define a class on the xmlrpc server with any methods you want
to execute on the client.  Then just connect to the server machine
from the client, and execute whatever methods you choose.  (These can
execute subprocesses that call external programs.)  The return values
(when available) are sent back to the client.

I think that the call to the xmlrpc from the client blocks until the
remote call is finished.  (Not positive)  So, if you need, you can set
up the server class with a "poll()" method, call the xmlrpc method in
a separate thread, and poll it until you know its done.

Another idea...

I use heartbeats to tell if a daemon/service is still running.  Check:
http://code.activestate.com/recipes/52302/

Set up a heartbeat server somewhere, and then set up the client
portion in your windoze service.  I have the server write it's up/down
status to a database, and then I can read the status of lots of
daemons from anywhere I want.

If you are looking to monitor alot of daemons/services that are
installed on several machines, heartbeats are the way to go.

~Sean