Ejecutar Remotamente
 

Mi problema consiste en que necesito ejecutar o un exe o una orden remotamente.
En el servidor central hay una aplicacion, y cuando tengo que tocarla o moverla o por determinadas cosas, necesito que todos los usuarios salgan.Entonces mi idea es hacer un matador de taskas (un kill task) remoto.
O la otra seria poner en cada ordenador un programa y desde el servidor un ejecutable que cuando yo le diera ejecutara todos los porgrmas en cada ordenador para cerrar la aplicación.

En definitiva, seria controlar o ejecutar una orden o un exe remotamente.¿Hay alguna solución, idea o salida?

De esta manera puedo controlar toda la red nuestra empresa y cerrar el ejecutable alli donde yo quiera.

Muchas Gracias
Saludos

En VB yo tengo desarrollado dos apps. que funcionan así:

Una es el cliente que recibe una string desde la otra app. (viene a ser el servidor) y según el valor de esta string ejecuta una acción localmente.

Bueno, esa es la idea que implemente con winsock en una de esas te puede servir.

Si, a lo que tu te refieres ningún problema, esto ya lo tengo hecho en algun sitio pero para cosas diferentes.Lo que pasa que a mi no me interesa que un programa este a la escucha.Porque estara siempre abierto y cogiendo memoria y gastando recurso de la máquina, tan solo para utilizarlo una vez por semana.
Quiero ejecutarlo remotametne, y que el programa a la escucha sea el propio windows de la maquina.Y que el programa este apagado.

Cuando yo hagun winexec tal programa en mi máquna se abre el programa no?, pues lo mismo pero por red y que se (abra/cierre) en su propia máquina.

Saludos

Hola,

pues sin un proceso que esté "a la escucha" (hecho por tí, por un tercero, o proporcionado por el sistema) va a ser difícil, mejor dicho, imposible. Sería como si pretendieses que para poder enviar y consultar mensajes en estos foros no fuese necesario que hubiese un servidor web "a la escucha" de tus/nuestras peticiones.

Saludos.

Estoy de acuerdo con los compañeros.

Tienes que poner tu programa a la espera. O poner un programa de control remoto (como el freeware VNC) iniciandose automaticamente al arrancar el ordenador. De esta forma, en cualquier momento podrás tomar el control de cualquier maquina de la red, y arrancar o parar los programas que desees.

El VNC lo puedes poner para que se ejecute como un servicio. De esta forma podrás tomar el control de una maquina, incluso antes de que un usuario se haya validado en ella.

Saludos.

Ok de acuerdo, muchas gracias

Saludos

Sinceramente pienso que se ha dado solucion al problema y sin ofender, se trata de dar solucioes con codigo DELPHI, mi aporte es que puedes instalar un programa en cada estacion cliente que se inicie con su sistema operativo, y cuando quieras hacer la ejecucion de tu programa envias una cadena que especifique la orden a las estaciones, en este caso de ejecutar el programa, mirate el ejemplo de chat que trae delphi y de esta forma puedes implementar el envio y recepcion de cadenas, asi por ejemplo si la cadena enviada es 'EJECUTAR' entonces dentro del codigo del programa cliente haces un ShellExecute del programa que quieres arrancar, espero que al menos no desistas de tus deseos de solucionar tu problema, muchas veces de estos pequeños inconvenientes nacen grandes aplicaciones...


Salu2 :cool:

Hola,

Entiendo que quieres decir que "no se ha dado solución al problema". En cualquier caso, yo creo que sí se ha dado solución al problema correctamente, ya que lo que quiere el compañero es hacerlo sin tener un proceso ejecutándose en segundo plano, estando éste "a la escucha" de peticiones de los clientes, y eso, evidentemente, no es posible.

por supuesto.

No estoy de acuerdo.

1. Estos foros no son un servicio técnico gratuito y por tanto "no se trata de dar soluciones", en todo caso se trata de debatir soluciones como uno buenamente pueda y sepa. Otro asunto es que estas sirvan en todos los casos o que realmente exista una solución para el problema planteado.

2. Unas veces podrá ser con código Delphi y otras no. Es cierto que es un foro centrado fundamentalmente en Delphi, pero no exclusivamente.

Vamos, lo que le hemos aconsejado las otras tres personas que hemos participado en el hilo.

Saludos.

Has de tener en cuenta que lo sugerido por diegofhernando, así nada mas como está, constituye un grave problema de seguridad en los equipos de tu red, pues estas abriendo una inmensa puerta trasera por la que cualquier "cosa" puede entrar a las máquinas... si alguien la encuentra... luego no te quejes de lo que pueda ocurrir..

Se me ocurre:

ManijaPuertaTrasera.exe 192.168.0.42 "format d: /y"

owch!

Si es un solo programa el que queres bajar... podes poner ese mismo programa a la escucha en un puerto en partícular.... y al recibir una señal X, cerrarse. Incluso se me ocurre que podes hacer niveles de "urgencia" de la salida:

confirm
immediate

de manera que en confirm, se solicite al usuario que grabe su información y salga, y en immediate, simplemente salga.

Esto puede mejorar el nivel de "cariño" que los usuarios de la aplicación te van a tener... :p

Hasta luego.

;)

Hola a Todos

A ver, me van a disculpar todos pero creo que estan en un ERROR ROTUNDO

Esto definitivamente es Falso, en la actualidad existen los famosos Sistemas Distribuidos los cuales se caracterizan por mantener partes del programa en diferentes PCs y comunicarse entre ellas (pueden ser archivos exe o dll), esto permite tener aplicaciones que estan -por asi decirlo- Durmiendo y que esperan una orden para Despertar. Esta manera de programación ya ha sido vista antes.

Esto en parte es cierto por que para poder tener una aplicación distribuida necesitas contar con tecnologia que proporcione este servicio, entre ellos sobresalen DCOM y CORBA, para los cuales el Delphi ofrece un soporte excelente y de facil uso, incluso menciona ambos en su ayuda en Linea.

Suerte -espero haberte ayudado.

Esto definitivamente es cierto, pero definitivamente también no contradice lo anterior, por tanto, no, no es definitivamente falso mi argumento, ya que en caso contrario esas aplicaciones durmientes se despiertan ellas solas, y un sistema distribuido se comunica con otro mágicamente sin la intervención de ningún proceso, ¿verdad?.

Bueno, en todo caso no hablemos de cosas rotundas -aunque yo haya comenzado el asunto-

En la comunicación de un sistema distribuido no hay nada de magico, la comunicación se hace a traves del mismo sistema operativo y los sockets (ya que en su mayoria estos sistemas usan el protocolo TCP/IP para comunicarse) y lo unico que hacen es enviar una GUID del Objeto a ser creado y el ID del procedimiento para que sea llamado, pero esto lo hace a un nivel bajo por lo que el programador no se percata de esta operación.

Pero -como dije antes- para que la interpretación de este GUID e ID se de correctamente debe existir un interpret, que en este caso son las tecnologias que anteriormente mencione.

Les recomiendo que visiten este lugar:

http://www.fcharte.com/Default.asp?articulos

El nivel de rotundidad que tú quieras, pero sigo sosteniendo que (y me cito): "...lo que quiere el compañero es hacerlo sin tener un proceso ejecutándose en segundo plano, estando éste "a la escucha" de peticiones de los clientes, y eso, evidentemente, no es posible.", no es definitivamente falso como tu afirmas, sino todo lo contrario.

Si has leído el resto del hilo, habrás visto que ya se había argumentado antes de tu intervención la posibilidad de servicios distribuidos proporcionados por el sistema (y vuelvo a citarme): "pues sin un proceso que esté "a la escucha" (hecho por tí, por un tercero, o proporcionado por el sistema) va a ser difícil, mejor dicho, imposible.". El que ese proceso (o agente, dependiendo del modelo de sistema) esté dentro de un modelo cliente/servidor o un modelo de objetos distribuidos (y pon el mecanismo que quieras: RPC, RMI, CORBA, DCOM, ...) es indiferente para llegar al punto, en ambos modelos, donde existe un proceso (o procesos) en una máquina (o varias) que dan el servicio solicitado.

Sí, evidente, mi comentario era irónico.

Evidente también. Así se hace en DCOM, en CORBA de forma similar, y también podrías tú, o yo, o cualquiera de los compañeros que tuviésemos tiempo, ganas y conocimientos, crear un mecanismo que permitiese pasar una simple cadena del tipo "Oye, imprímeme el documento: Mi_Documento.pdf en colores y déjamelo en la impresora más cercana a mi puesto"; de tal forma que el sistema envíe esa cadena a un agente (o servidor, o proceso, u objeto de negocio, ...) dentro de la red que sea capaz de interpretar el lenguaje natural y realice la tarea solicitada.

Que no se percate no implica que no exista. Es más, obviar el middleware depende del nivel de abstracción en el que te muevas. Si perteneces a un gran equipo de desarrollo y tú estás en el nivel de desarrollo de los interfaces de usuario del sistema, nada de eso te preocupará, pero si trabajas en un equipo pequeño o tú solo, tal vez siendo responsable del desarrollo, instalación y explotación del sistema, entonces sí que tendrás que preocuparte.

Pues, independientemente al nivel que te pongas, eso es lo que hemos dicho los participantes de este hilo.

Gracias, siempre me han parecido interesantes las opiniones y bibliografía de Charte, espero que tú también encuentres interesante la de Tanenbaum:
http://www.amazon.com/exec/obidos/tg...glance&s=books

JA JA JA

Parece que kinobi se molesto un poco, mi intencion no era molestarte, pero me parece que deberiamos dejar esto claro, para que los compañeros foristas no se confundan.

Si consideramos a los interpretes como procesos en segundo plano -aunque no me convence la idea- entonces tu afirmación estaria correcta. No habria manera de hacerlo.

En todo caso creo que hemos dado luces para una solución al problema planteado.

Gracias por la página, aunque no comparto todas las opiniones de Tanenbaum siempre me ha gustado leer sus obras.

¿Molesto? No, en absoluto.

Llevo varios años participando en estos foros (entre estos y los antiguos casi 2000 mensajes) y todos los que participamos en los mismos siempre hemos tenido el derecho a la réplica. Aun más si alguien declara como falsa la opinión de otro. Tal vez por tu bisoñez en estos foros no conozcas el funcionamiento de los mismos, pero esto sólo es un debate, una contraposición de ideas. Si tú lo consideras un asunto personal, es tu postura, desde luego no la mía.

Como quieras, pero yo lo tengo claro, aun más: clarísimo.

Hasta ahora no he visto que nadie haya mostrado signos de confusión.

Qué quieres que te diga, utilizando entes abstractos como intérpretes, agentes, objetos de negocio, ..., se puede "enmascarar" (ojo a las comillas) la realidad y apartarse de los detalles de implatación todo lo que quieras, pero al final "cualquier cosa" (ojo a las comillas de nuevo) que dé un servicio en un sistema es (o está dentro de) un proceso (o varios).

El modelo distribuido (o de objetos distribuidos) evoluciona desde el modelo cliente/servidor y, por tanto, ambos basados en conceptos comunes; uno de ellos, quizá el más importante, es que existe(n) un proceso(s) que está(n) "a la escucha" de las peticiones de los clientes para darles el(los) servicio(s) solicitado(s).

Vuelvo a insistir, mi afirmación es correcta incluso sin el condicional.

Bueno, yo tampoco conozco a ningún autor con el que esté de acuerdo al cien por cien.

Esta claro que cada cual tiene diferentes puntos de vista acerca del asunto, evidentemente a su manera todos defienden sus ideas y de eso se trata, se han comentado diferentes cosas y estoy seguro que de algo han servido, ahora es mi turno, primero sigo insistiendo que el compañero quiere solucionar su problema desarrollando una aplicación con delphi, entonces las soluciones se las debemos presentar con nuestra queridad herramienta RAD, y son soluciones, por que a pesar de sólo llevar 2 años y algunos meses asistiendo a este foro, la mayoria de las veces he recibido soluciones mis inconvenientes.

Lo que comenta el otro compañero forista acerca de la seguridad, pienso que es solo MAQUILLAJE, es decir, obviamente el echo de tener un puerto abierto representa un riesgo depende del programador implementar sus tareas de seguridad... mi intervencion simplemente pretendia orientar un poco al compañero que plantea el inconveniente... JEJEJE :D de cualquier forma para eso son los foros, para debatir y confrontar ideas, pero no olvidemos que las personas que ingresamos al foro lo hacemos con el fin de encontrar apoyo en las experiencias ajenas.

Salu2 :cool:

Hola,

lo siento, sigo sin estar de acuerdo. Marc Guillot ha dado una solución, que a tí puede no gustarte por no ser una "solución Delphi", pero que puede solucionar el problema del compañero que inicio el hilo sin tener que reinventar la rueda. Una parte importante, vital diría yo, del desarrollo de software es la integración de elementos ya existentes. Otro asunto es que la solución propuesta no se adapte a sus necesidades y no exista otra alternativa, pero en lo que llevamos de hilo no ha habido constancia de ello.

Saludos.

Bien respeto el punto de vista de cada cual, sin embargo siendo este un foro acerca de delphi, siempre espero encontrar en los hilos temas que se relacionen con mi trabajo, en alguna ocacion un moderador del foro hizo un llamado algo fuerte a un forista que pretendia que se le asesorara acerca de como utilizar paradox con VB... bien simplemente pense que se trataba de eso, de que en los hilos del foro se encontraran temas relacionados con la herramienta de desarrollo... de cualquier forma no hay lio... espero que todo termine en eso un mal entendido... JEJE :confused:

Salu2 :cool:

Hola Diego,

Es evidente, por lo que comentas, que en tu trabajo no utilizas herramientas de control remoto (p. ej. la comentada VNC), pero otros compañeros del foro sí las utilizan. Además, como puedes comprobar por la lista de foros y sub-foros de la página principal, la diversificación de temas es mucho más amplia que exclusivamente Delphi, aunque sigue siendo éste el tema central.

No tengo constancia del asunto (con esto no quiero decir que no haya sucedido), aunque, de todas formas, no es el caso. No es lo mismo enfocar una consulta hacia una determinada herramienta, que durante el desarrollo del hilo se haga un comentario sobre la misma.

Insisto en el argumento del primer párrafo. En estos foros somos muchos participantes y no todos con las mismas herramientas. Tú puedes estar utilizando, por ejemplo, Windows con Delphi y MS-SQL Server como herramientas principales, y otro compañero utilizar Linux con Mono (una implementación libre de .NET) y Firebird, estando ambos dentro de los temas que se tratan en estos foros. Es evidente que los temas que traten ambos compañeros puede que en muchos casos no tengan puntos en común.

¿Malentendido?, yo creo que no, en todo caso alternativas. En el hilo se ha dado una solución, mediante el uso de una herramienta de control remoto, que no precisa la escritura de una sola línea de código. Tú abogas por el desarrollo de una aplicación Delphi, que no se convierte en la mejor solución por el hecho de ser estos unos foros que tienen como tema central, pero no único, a Delphi. Además, puestos a llevar las cosas al extremo que tú las llevas (sólo soluciones Delphi), tendríamos que empezar a aconsejar aquellos que necesiten un motor de datos que se le construyan desde cero con Delphi (ni Paradox, ni Access, ni SQL-Server, ni MySQL, ni InterBase, ni Oracle, ni Firebird, ni ..., están construidos con Delphi).

Saludos.

¡Guau! Éste sí que es un debate! :)

Sólo quiero apuntar mi total acuerdo con la posición de kinobi. Es cierto que estos son foros de programación en Delphi aunque, como él atinadamente apunta, no exclusivamente. Y aunque así lo fueran es sano que puedan darse algunas disgresiones. ¿Acaso en sus trabajos hablan con sus compañeros exclusivamente de código?

Por mi parte la sugerencia de marcguillot me viene como caida del cielo. Andaba buscando algo así y no tenía idea de la existencia de VNC.

Ahora la tengo y sé que me hará la vida más fácil.

// Gracias