Remote Network Commands
Normally, being connected to some kind of network does not mean that you are able to directly access all resources provided by that network. Some devices, like tape drives and printers, are connected to special computers and are only accessible on these machines. Others, such as disk drives, can be accessed easily, when the system administrators allow it.
Gaining direct access to resources becomes more complicated the larger the network gets. This is partly due to security reasons, and partly due to the simple fact that the more people that have to be convinced you need to mount a disk, the less your chance of success. From this follows the rule that the more resources available, the harder it will usually be to connect to them.
A nice and easy way around this dilemma is using the remote commands rlogin, rcp and rsh. These commands allow access to any account that is owned by you on any computer in the network without the use of a password. rcp and rlogin can be compared with ftp and telnet, whereas rsh offers the possibility to combine commands on different machines in one shell pipeline.
Configuration is extremely easy—in fact, your host network is probably configured correctly already—and you have instant access to these capabilities. In this article, I present these commands, explain the local setup, give some examples to give you a start, show some options, and demonstrate the complexity that can be reached. Most of my examples can easily be replicated on your networked machine.
Under normal conditions (your network is up, you can telnet into other machines, and you can be reached by other machines), the only thing you need to do is create a file called .rhosts in your home directory which is readable and writable only by you (mode 600). This file should contain the full hostnames of each of the machines you want to log in from, and the user name on that machine, like this:
apple.groucho.edu fred orange.groucho.edu sam
The .rhosts file specifies the machines and users that are allowed to login to the user on the machine where the .rhosts file resides. If I am logged in as sam on the machine banana.groucho.edu and I have the above .rhosts file in my home directory, then the user sam from orange.groucho.edu and the user fred from the machine apple.groucho.edu have remote access to my account.
Now, I log into apple.groucho.edu (username fred) from my account on banana.groucho.edu. From apple.groucho.edu I run the following command: rlogin banana.groucho.edu -l sam. Once you are logged in, shell commands will work as normal.
If you are asked to enter your password, do not enter a password, but instead quickly switch back to your original login on banana.groucho.edu and type ps -a. In the process list your rlogin request should appear with the name of the machine it came from as an argument. When this is different from the name you entered in the .rhosts file, you will need to enter the new name. Sometimes a machine uses different lines or a common server for such communication, although its name doesn't change. If there is still no connection, you should ask the system administrator. Some machines simply don't allow any rlogin commands.
In order to respond to any rlogin request, your Linux machine's inetd.conf should have the following two lines:
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
When you are a member of a domain and share usernames, you might want to include the hosts you frequently connect to in /etc/hosts.equiv. In this case your .rhosts file may contain only the nickname (which is commonly just the machine name without the domain information) together with the username. The above example .rhosts file on the machine named banana.groucho.edu would then look like:
apple.groucho.edu fred orange sam
The rcp command copies files or directories from one machine to another. It is used like the cp command. For instance, I can copy a file named test.dat from the remote machine banana to my local machine orange. (For this example to work the two machines must share usernames.)
rcp banana:test.dat .
rcp banana.groucho.edu:test.dat .
The file test.dat is situated in my home directory on banana and is copied to my current directory on orange.
If I want to copy my Mail directory and its contents to orange into the directory Mail.banana (again, from orange):
rcp -r banana:Mail Mail.banana
To preserve the time stamp I would type:
rcp -r -p banana:Mail Mail.banana
Making a remote copy from the machine apple where I have a different account, apple:
rcp fred@apple:test.dat test
Of course, things also work the other way around. Here is a remote copy to apple:
rcp test.dat fred@apple:test.dat
The last interesting thing would be a copy from apple to banana, while you're logged into banana. Unfortunately, this works on every other machine except my Linux machines:
rcp fred@apple:test.dat banana:test.dat
You see that rcp is a bit handier than ftp.
With rlogin you perform a remote login to another machine. It can be used instead of telnet:
rlogin -l fred apple
rlogin apple -l fred
(for some versions of Unix)
I integrate every machine in my window-menu with an rlogin. This makes login very efficient. As an example, here are two descriptions—one for windows manager fvwm and one for olvwm--to add a menu and a shortcut key for rlogin to orange. The xhost can be omitted, but it is useful for other things. For fvwm:
Popup "Rlogin" Title "Rlogin" Exec "banana F1" xhost +banana;\ exec xterm -fn fixed -T banana -sb -e rlogin banana & EndPopup Key F1 A N Exec "banana" xhost +banana;\ exec xterm -fn fixed -T banana -sb -e rlogin banana &
"Login" MENU "Rlogin" TITLE PIN "banana" xhost +banana; exec xterm -T banana\ -sb -e rlogin banana "Login" END
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Senior Perl Developer
- Technical Support Rep
- Symbolic Math with Python
- UX Designer
- Network Monitoring with Ethereal
- I once had a better way I
53 sec ago
- Not only you I too assumed
18 min 16 sec ago
- another very interesting
2 hours 11 min ago
- Reply to comment | Linux Journal
4 hours 4 min ago
- Reply to comment | Linux Journal
10 hours 58 min ago
- Reply to comment | Linux Journal
11 hours 14 min ago
- Favorite (and easily brute-forced) pw's
13 hours 6 min ago
- Have you tried Boxen? It's a
18 hours 58 min ago
- seo services in india
23 hours 29 min ago
- For KDE install kio-mtp
23 hours 30 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?