rsync, Part II
Lest I forget, I haven't explained how to connect to an rsync server as a client. This is a simple matter of syntax; when specifying the remote host, use a double colon rather than a single colon and use a path relative to the desired module, not an absolute path.
For instance, to revisit the scenario in last month's example, in which the client system is called near and the remote system is called far, suppose you wish to retrieve the file newstuff.tgz and far is running rsync in dæmon mode. Suppose further that you can't remember the name of the module on far in which new files are stored. First, you can query far for a list of its available modules, as shown below:
[root@near darthelm ]# rsync far:: public Nobody home but us tarballs incoming You can put, but you can't take
(Not coincidentally, these are the same modules we set up in this month's examples; as I predicted in the previous section, the module Audiofreakz is omitted.) The directory you need is named public. Assuming you're right, the command to copy newstuff.tgz to your current working directory would look like this:
[yodeldiva@near ~]# rsync far::public/newstuff.tgz .Both the double colon and the path format differ from SSH mode. Whereas SSH expects an absolute path after the colon, the rsync dæmon expects a module name, which acts as the “root” of the file's path. To illustrate, let's look at the same command using SSH mode:
[yodeldiva@near ~]# rsync -e ssh \ far:/home/public_rsync/newstuff.tgz .These two aren't exactly equivalent, of course; whereas the rsync dæmon process on far is configured to serve files in this directory to anonymous users (i.e., without authentication), SSH always requires authentication (although this can be automated using null-passphrase RSA or DSA keys, described in Chapter 4 of Building Secure Servers with Linux). But it does show the difference between how paths are handled.
The last rsync usage I'll mention is the combination of rsync, running in dæmon mode, with Stunnel. Stunnel is a general-purpose TLS or SSL wrapper that can be used to encapsulate any simple TCP transaction in an encrypted and optionally X.509-certificate-authenticated session. Although rsync gains encryption when you run it in SSH mode, it loses its dæmon features, most notably anonymous rsync. Using Stunnel gives you encryption as good as SSH's, while still supporting anonymous transactions.
Stunnel is covered in-depth in Chapter 5 of Building Secure Servers with Linux, using rsync in most examples. Suffice it to say that this method involves the following steps on the server side:
Configure rsyncd.conf as you normally would.
Invoke rsync with the --port option, specifying some port other than 873 (e.g., rsync --daemon --port=8730).
Set up a Stunnel listener on TCP port 873 to forward all incoming connections on TCP 873 to the local TCP port specified in the previous step.
If you don't want anybody to connect “in the clear”, configure hosts.allow to block nonlocal connections to the port specified in Step 2. In addition, or instead, you can configure iptables to do the same thing.
On the client side, the procedure is as follows:
As root, set up a Stunnel listener on TCP port 873 (assuming you don't have an rsync server on the local system already using it), which forwards all incoming connections on TCP 873 to TCP port 873 on the remote server.
When you wish to connect to the remote server, specify localhost as the remote server's name. The local Stunnel process now opens a connection to the server and forwards your rsync packets to the remote Stunnel process. The remote Stunnel process decrypts your rsync packets and delivers them to the remote rsync dæmon. Reply packets, naturally, are sent back through the same encrypted connection.
Mick Bauer (firstname.lastname@example.org) is a network security consultant for Upstream Solutions, Inc., based in Minneapolis, Minnesota. He is the author of the O'Reilly book Building Secure Servers with Linux, composer of the “Network Engineering Polka” and a proud parent (of children).
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released