I did a bit of research on using Maven to execute commands on a remote server using some ssh exec plugin.
The thing that gets me though is I need to run a command which launches some menu driven program to stop a server and then start it up again.
I would basically have to perform the following tasks in sequence:
Connect to the remote server using SSH
Login with username/pass
Change directory to a particular location
Run a command at that location to launch a command line menu driven program (i.e. "./control")
Enter two commands to that menu driven program
Disconnect
The two commands are just numbers which represent choices from a menu it prints on the console, like:
Enter the number of the server you wish to stop:
[1] server1
[2] server2
[3] server3
I would enter "2" for example. Is this possible?
One possible solution would be to write a Perl script on the remote server that accepts the server number as an argument.
You could then use Perl's Expect.pm library to supply this argument to your control program when it prompts for input.
This then simplifies your Maven task to executing a script on a remote server, which presumably you are now happy with thanks to your research.
(If you've not used it before, Perl's Expect library is designed for exactly this use case - automatically supplying input to interactive command line programs.)
Related
I need to run some commands on some remote Solaris/Linux servers and collect their output in a log file on my local server.
Currently, I'm using a simple Expect script, residing on the local server to fire the commands on the target system. I then redirect the output of the expect script to a log file, like this,
/usr/local/bin/expect script.exp >> logfile.txt
However, this is proving to be very unreliable as the connection to the server fluctuates a lot, leading to incomplete logs and hung scripts.
Is there a better and more reliable way to go about this task?
I have implemented fedorqui's answer,
Created a (shell) script that runs the required commands on the target servers.
Deployed this script to all servers.
Executed this script via expect, from my local (central) server.
Finally collected logs individually from each server after successful completion, and processed them.
The solution has been working fine without a glitch till now.
I wanna write a remote console, working like a telnet server. User is able to use telnet to log into the server, then write some commands to do some works.
A good example for this is the console of router os. What I'm confusing right now is, I can accept user's input, do someting then print some texts back, but I wanna use ncurses to make the console has more features(such as "cmd auto-complete", syntax color...), so how can I do that? Because the console is in user side, if the server calls ncurses APIs it'll just change stuffs on server...
Maybe this is a stupid question but I'm really newbie on this. Any suggestions are appreciated.
This is more difficult than you might think.
You need to understand how terminals work - they use special control sequences for e.g. moving the cursor or color output. This is described by a terminfo file which is terminal-specific. Ncurses translates API calls (e.g. move cursor to a certain position) to such control sequences using terminfo.
Since the terminal (nowadays xterm, gnome-terminal, screen, tmux, etc) is on the client side, you have to pass the type of terminal from the client to the server. That's why e.g. ssh passes this information from the ssh client to the server (try echo $TERM in your ssh session - it might be 'linux' if you are logged in via the console, or 'xterm', if you are using X and an xterm). Also, you better have the respective terminfo available on the server.
Another piece of the puzzle is pseudo terminals. As nowadays relatively few people use serial terminals, their semantics are emulated so that applications and libraries (e.g. curses and its friends) originally developed for serial consoles keep working. This is achieved via pseudo terminals - these are like pipes, a master and a slave device communicates, anything written on one side comes out on the other side. For a login process, getty, for example, can just use one side of a pty device and think it's a serial line - your server program must handle the other side of the pty, sending everything it gets from the pty to your client via the network.
Terminal emulators also use ptys, type tty into your terminal, and you'll get something like /dev/pts/9 if you're using a terminal emulator. On the other side of the pty it's usually your shell, communicating with your terminal emulator via the pty.
Your client program can more or less just use standard input and standard output. If your terminal information is correct, the rest will be handled by your terminal emulator, just pass anything you receive from your server program to stdout, and send anything you read from stdin to your server program.
Hopefully I haven't left out any important detail. Good luck!
It is possible to have ncurses operate on streams other than stdin and stdout. Call newterm() before initscr() to set the input and output file handles for ncurses.
But you will need to know what sort of terminal is on the remote end of the connection (ssh and telnet both have mechanisms for communicating this to the server) and you will also want a fall back to a non-ncurses interface in case the remote end is not a supported terminal type (or if you can't determine the terminal type).
I have always used the os:cmd/1 method to call operating system routines. Now, i know that erlang has an ssh application. I would like to know how i can use this module to ssh into a SOLARIS server, run a command and collect the reply. I believe that such an operation would be handled asynchronously. I need an example using the ssh application built into Erlang doing this:
Now, at times we setup SSH KEYS between servers to prevent password prompt especially if one is using a script to execute tasks on remote servers. i am intending to write many Erlang programs or escripts that will interact with many remote servers within our environment. i need a complete example and explanation on how ssh with and/or without password prompt can be handled using erlang ssh application. NOTE: In the screen shot above, the two servers had SSH KEYS set up and so there is no password prompt when ssh is initiated from any of the two.
The correct erlang native API to achieve this is not ssh, which only implements a user-interactive shell for ssh, but instead use ssh_connection. Take a look at ssh_connection:exec/4
To be more complete, use ssh:connect to establish a connection and then using the handler returned from it to connect with ssh_connection:exec/4
I didn't try it myself and can't provide a complete example but the documentation seems to be a good starting point.
Every month we send reports to a server using FTP. We run a query on a database to create the files then use the ftp functionality in LabVIEW to do the transfer. This runs on a Windows system.
This works fine but now we have to switch to using SFTP and the CopSSH package has been recommended. As LabVIEW has no native SFTP functionality we are looking at how we can use the sftp.exe application from CopSSH.
From the command prompt we have set up the encryption and made the initial connection using sftp username#host and entered the password. This has been confirmed by the team on the server side so connection to the server is set up. Now we just use sftp username#host and no password is required.
Where we are struggling is how to initiate the transfer from our LabVIEW code. We are able to call system commands using the System Exec VI but is there a way to pass a list of functions to the SFTP executable?
The commands used to transfer the files when we type it at the command prompt are:
sftp username#host
put c:/Data/File1.txt remoteFile1
put c:/Data/File2.txt remoteFile2
put c:/Data/File3.txt remoteFile3
quit
This works from the command prompt but I am looking to just call the sftp executable with a list of files to transfer. I don't think this would be specific to LabVIEW as you could use a batch file to run from a scheduled job.
LabVIEW can call ActiveX and .net but we really need to use this specific application.
I have been using WinSCP which has a command line version, winscp.com. It supports sftp and allows synchronize, keepuptodate, get, put and delete on folders and files. One word of warning, keepuptodate depends on an unbroken connection. Although WinSCP can remake a connection automatically, keepuptodate cannot. I suspect it is based on Microsoft's .NET SystemIO FileSystemWatcher. I therefore do a regular synchronize to keep a mirror of my source folder tree on the remote target.
If copssh's sftp.exe is a command line utility, and System Exec in your version of LabVIEW has the 'standard input' terminal (present at least since 8.5), you should be able to simply wire the commands you want sftp.exe to run into the standard input terminal.
If that doesn't work for some reason, could you use PuTTY instead of copssh? The documentation for PuTTY's PSFTP component says that it can execute a sequence of commands in a script file using the -b command line switch, e.g.
psftp user#hostname -b myscript.scr
so you could have your LabVIEW program create the script file then run it with System Exec.
You are mixing SSH and SFTP. SSH opens a secure connection, but SFTP is a separate protocol which is run over SSH connection and requires a separate tunnel. In OpenSSH (and it's Windows Port, copSSH) it's sftp.exe application that does SFTP.
Now about FTP vs SFTP. Please check an article that explains the difference between SFTP and FTP(S). If LabView supports FTP, this doesn't help you when you need to perform SFTP transfers.
I don't know whether you can use external ActiveX controls in LabView. If you can, you are welcome to check our SFTP ActiveX control, that will let you do the transfer. If all you can do is call external application, then you'd have to use copSSH's sftp.exe.
How can we trigger a shell script on an unix server through an email with particular subject?
procmail allows you to act on incoming mails, including filtering and starting external commands.
Some useful links:
general procmail documentation: http://pm-doc.sourceforge.net/doc/
start a shell command as a procmail rule: http://porkmail.org/era/procmail/mini-faq.html#rtfm
Just in case the link goes down, this is the link from the second point from above:
Q: How can I run an arbitrary Perl or shell script on all or selected
incoming mail?
A: Install Procmail. Read the manual pages (there are several). Thank
you.
:0 * conditions, if any | your-script-here
The conditions, in their simplest form, are regular expressions to
match against the header of each incoming mail message. Correction:
Even simpler, you can leave out the condition lines completely if you
want to do your action (in this case, run a shell script)
unconditionally.
More-complicated conditions can also be exit codes of other shell
scripts or programs, or tests against the full body of the message, or
against Procmail variables (Procmail's variables are also exported to
the environment of subprocesses, so they are essentially environment
variables. There are details about this later in this FAQ.)
Actions can also be to save the message to a folder (appended to a
Unix mailbox file, or written to a new file in a directory) or to
forward the message to one or more other addresses. Finally, the
action can be a nested block of more "recipes," as these
condition-action mappings are called in Procmail jargon, to try if the
outer condition is met. The procmailrc(5) manual page has the full
scoop.
Obviously, you are not restricted to Perl or shell scripts. Anything
you can run from a Unix command prompt can be run from Procmail, in
principle, although running interactive programs doesn't usually make
much sense.
More general, but to my mind less useful than Wim's procmail suggestion: You can even just point your .forward at an executable with "|scrip.sh".
You could in theory, by writing a program to monitor/poll the incoming email server and check the subject line using standard POP3 protocol, if the subject line has a particular trigger keywords, invoke the shell script... This is the order of approach that would suit... there may be an open source solution already out there...
Using sockets, connect to the incoming email server by IP and port (usually 25), non-blocking that is not to seize up and chew up CPU time, within a thread looping forever
List the emails using the POP3 protocol
Pull down the headers via POP3 protocol and do a regexp on the subject line
If the regexp matches the subject line, issue a trigger perhaps a system call to invoke the shell script