java - programas - programacion shell linux ejemplos

Llamar a un script de shell utilizando el canal de ejecución SSH, pero ignora las llamadas a otros scripts de shell

Question

Estoy logrando ejecutar un script de shell en un servidor remoto usando JSch exec usando los útiles ejemplos proporcionados aquí. Puedo ver los ecos que se devuelven desde el script y el estado de salida al final es 0, por lo que todo se ve bien a primera vista.

Sin embargo, el problema es que la secuencia de comandos llama a otras secuencias de comandos, y estas parecen ser completamente ignoradas, simplemente omitidas.

El script llama a otros scripts directamente. es decir, la primera línea del script es algo así como:

script_two.sh

¿Alguien podría aconsejar alguna forma de superar esto? Empecé a buscar en el canal "shell" en lugar de "exec", pero esto puede ser complicado en mi caso porque antes de dar acceso al usuario al sistema, el servidor presenta un formulario para completar (nombre, número, por qué iniciando sesión, etc.) - Todavía no he podido rellenar y enviar este formulario de forma programática, por lo que me gustaría seguir con el ejecutivo si es posible.

Soy nuevo en todo esto, ¡cualquier ayuda / consejo sería bienvenido!

Fragmento de código a continuación. Como dije, esto parece funcionar, pero el script sh representado por "scriptFileName" en el código llama a otros shcripts, y estos no se ejecutan.

Muchas gracias de antemano por cualquier ayuda, J

JSch jsch = new JSch();
JSch.setConfig(FileTransferConstants.STRICT_HOST_KEY_CHECKING, "no");

Session session = jsch.getSession(username, hostIPAddress, port);
session.setPassword(password);
session.connect();

//create the execution channel over the session
ChannelExec channelExec = (ChannelExec)session.openChannel("exec");

channelExec.setCommand(scriptFileName);
channelExec.connect();

Answer 1

Supongo que el script se ve así:

script_one.sh
script_two.sh

Es decir, el guión se basa en . (la ruta actual) está en la PATH entorno PATH , lo que no es un valor predeterminado.

Entonces, para que el guión funcione, el . tiene que ser agregado a la PATH en alguna secuencia de comandos de inicio. Es bastante probable que la adición ocurra (probablemente de forma involuntariamente incorrecta) solo para sesiones interactivas. Probablemente porque la adición se realiza en un script de inicio que se ejecuta (de origen) solo para las sesiones interactivas.

El canal "exec" en el JSch (con razón) no asigna un pseudo terminal (PTY) para la sesión. Como consecuencia, un conjunto diferente de scripts de inicio es (podría ser) de origen, cuando inicias sesión con un cliente SSH. Y / o se toman diferentes ramas en los scripts, en función de la ausencia / presencia de la variable de entorno TERM . Por lo tanto, el entorno puede diferir de la sesión interactiva que usa con su cliente SSH.

Las soluciones son (en orden de preferencia):

• Corrija la secuencia de comandos para no confiar en la configuración no predeterminada de tener el . en PATH . Llame a los sub-scripts con una ruta explícita:

  ./script_one.sh
  ./script_two.sh

• Corrija los scripts de inicio para agregar el . al PATH incondicionalmente (incluso para sesiones no interactivas).

• (no recomendado) .setPty la asignación de pseudo-terminal para el canal "exec" usando el método .setPty :

  Channel channel=session.openChannel("exec");
  ((ChannelExec)channel).setPty(true);

  Usar el pseudo terminal para automatizar la ejecución de un comando puede traerle desagradables efectos secundarios. Ver, por ejemplo, ¿hay una forma simple de deshacerse de los valores basura que vienen cuando SSH usa la biblioteca Paramiko de Python y obtiene la salida de la CLI de una máquina remota?

Consulte también una pregunta relacionada. El comando Shell ping con la opción fuente está fallando cuando se ejecuta utilizando JSch setCommand .