Remote Network Commands
The rsh command is the most powerful remote command, as it can be integrated into a pipe. This enables you to execute complex command sequences between different machines. Without any command, rsh rlogins to the other machine. When I am logged into orange:
rsh banana logs me remotely to banana, while: rsh -l fred apple
does the same on apple, where the username is different from the one for my current shell on orange.
Both stdout and stderr from the remote machine are piped to the local machine. After establishing the connection, neither /etc/profile nor .bash_profile (for bash) nor .login (for csh and tcsh) are scanned. This can be confusing in the beginning, as not everything you defined as variables and aliases for a login shell are present. This is different from rlogin, which gives you a real “login shell”. The most common problem is that you use a command that cannot be found because the path variable has not been set correctly. In these cases, you could set your path in your shell initialization file, such as .bashrc or .cshrc (there is no such file for /bin/sh, however). A more general solution is to simply use fully qualified pathnames for commands.
The easiest use of rsh is a simple command like:
rsh banana ls
You should get a listing from your home directory on banana. If you want to use options that start with “-”, the syntax would be:
rsh banana `ls -al'
Everything in between the quotes is executed on banana.
The listing was sent to your local stdout, your screen, just as if ls had been executed locally (on orange). Below are some examples of creating a tar archive on banana from a directory called bin, with the output going to stdout and the archive file being placed on orange:
rsh banana `tar cf - bin' | dd of=archive.tar
rsh banana `tar cf - bin' > archive.tar
Of course this will work for different usernames or in the other direction too:
rsh -l fred apple `tar cf - bin' > archive.tar tar cf - bin | rsh -l fred apple dd of=archive.tar
The dd command is very handy here, because it copies stdin to the file specified by of. If I were to use > to redirect the output, I would end up on orange again, but I want the file to be written to apple instead, which dd does correctly.
Now for some examples of what happens on which machine. Start with something simple:
ps -aux | grep root
This shows all processes root owns on your local machine. The next command will show all processes on banana which are owned by root.
rsh banana `ps -aux' | grep root
In this case, the ps command is executed on banana, but grep is executed locally (on orange).
The next command does the same thing, except that the grep command is executed on banana, as is the ps command.
rsh banana `ps -aux | grep root'
rsh banana `ps -aux' | rsh banana `grep root'
The next example shows how to split stderr and stdout (this works only for sh or bash, not for csh or tcsh!):
rsh banana `dd if=bin.tar 2>fehler' > test.dat
Here we have dd that writes its error output to the file fehler on banana, but which transmits its standard output to orange into the file test.dat. The secret here is the use of quotes. Because 2>fehler is inside the quotes it is executed on banana. Things can get very tricky. Not only can you make full use of shell commands, you also can run them on different machines:
rsh banana `tar xf bin.tar `rsh banana `tar tf \ bin.tar' | grep gj2.c`'
Here I have a tar archive bin.tar on banana. In it there is a file called usr/local/src/gj2.c. First, there is a command expansion in between ` ... `. This expansion returns all the filenames from the archive which contain the string “gj2.c”. First, tar tf returns the list of files in the archive and then grep (running on orange) performs the pattern match. This yields usr/local/src/gj2.c and usr/local/src/gj2.c~. Now the first tar (tar xf bin.tar) extracts these files on banana.
Imagine that you have a tape drive attached to banana and another to orange. You want to make a copy of a tape. Dumping the contents of the tape to the disk drive and copying it back to another tape would be a solution, but would require enough free disk space to hold the entire contents of the tape. Another solution would look like:
rsh banana dd if=/dev/rst0 ibs=1024 | dd \ of=/dev/rmt0 obs=1024
Here /dev/rst0 is a SCSI tape drive on banana and /dev/rmt0a SCSI tape drive on orange. Now you want to process your data with a special program called demux. After processing, your data has shrunk considerably to about 200 megabytes. As we operate on binary data, porting our program to banana would be very time consuming (orange is still my Linux machine). On the other hand, orange doesn't have 200 megabytes of free space. We do the following:
rsh banana dd if=/dev/rst0 ibs=1024 | demux | \ rsh banana dd of=file.dat
Now we read from banana, process on orange and write back to banana.
In the next illustration you want to access a printer connected to banana. We have a PostScript file, test.ps, that we want to send on a printer called p_a4:
dd if=test.ps | rsh banana `lpr -Pp_a4'
You might want to have a look at the file before you print it:
dd if=test.ps | rsh banana `xv - -display orange:0'
This will only work under X-windows. On orange, you would have given a command like xhost +banana first.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide