"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, [email protected]
Starshine Technical Services, http://www.starshine.org/

Remote Backups: GNU 'tar' through 'rsh'

From Ken Plumbly on 18 Jul 1998 in the comp.unix.questions newsgroup

Hi :

I'm sure this one will probably drive you crazy, I read your answer in LG issue 29 for remote backups, and did what the article said, but I get the response back from the server with the tape drive:

Getting things like this working for the first time have driven me crazy in the past. So, it's certainly possible for them to do so again.

(Some friends might say that "crazy" is a state they've come to expect of me).

Can you just run a command like:

rsh -l operator tapehost "id; pwd; ls -l /dev/st0"

... and get the desired results?

In my example I make some assumptions:

I'd run this command from root on the client and use the "-l operator" switch and argument to specify that I want rsh to access the "operator" account on the tapehost.

I'd create an account named "operator" on the tapehost machine. It would have no special privileges except that it would be a member of the "tape" group.

My copy of /dev/st0 on the tapehost would be owned by root.tape (the "tape" group) and would be mode 770 (writable by group).

This should allow what you want. Until you can use stock 'rsh' commands through this context --- your 'tar' commands are doomed. (Since GNU tar actually calls 'rsh' for that part of this work).

For more security you can use 'ssh' instead of 'rsh'

Next I would not use the command as you described it.

Tape drives are very sensitive to inconsistent latency (caused by transport of the data over a network and by any compression you attempt to do). If the data is not fed to the interface fast enough and at an even rate then the drive will have to stop, rewind a bit, and restart to get back to the right speed and tape position to continue writing.

This is called "shoeshining."

To prevent shoeshining we run a program called 'buffer' (Lee McLoughlin) on the "tapehost" (the machine that recieves the data over the network and writes it to the tape drive).

So that command would look like:

# tar czSf - .... | rsh -l operator tapehost "buffer -o /dev/st0"

Note the -S switch that we use to preserve "sparsity" in files --- that is to detect cases where the data blocks have not be continously allocated to the file --- where there are "holes" in the allocation map for the "empty" parts of the file's data. These sorts of files are commonly created with dbm libraries and other "hashing" algorithms that use file seek offsets as "indexes" into a file --- your /etc/aliases.pag file might be one of them. If you don't understand "holes" and "sparse" files (which are features of the Unix filesystem that aren't supported in some others --- though I know that Netware had them) --- don't worry about it. Just add the -S and it won't hurt anything even if there are no such files in the data set that you're working with.

Note that I use the c (create), z (compress) and f (file target) flags, and that the file target I specify is "-" (a dash). In Unix this usually indicates that the "standard output" device should be used. In other words, "-" (dash) is an idiom in a number of Unix/Linux commands. So, this command will write all of the tar file into the pipe.

On the recieving side of the pipe we have a local copy of 'rsh' that will try to connect to the "tapehost" as the user named "operator" and thereon try to run a command named "buffer" with the -o (output) of that pointed to the tape device.

How much difference does 'buffer' make? About an order of magnitude. Yes. You read that right --- on my network (which was completely idle at the time) I ran experiements with and without buffer (and with and without compression) and it would take 10 times longer to write the tape without 'buffer'. On top of all of that the tapes created without 'buffer' are much less reliable. So, failing to use that can be harmful to your data, and add immense amounts of wear and tear to the drive (shortening its useful life).

The 'buffer' command came with my copies of S.u.S.E. and might come with your copy of RH 5.x (although I don't think 4.2 had it). You can find that at:

http://src.doc.ic.ac.uk/public/public/packages/buffer

Imperial College, U.K./Great Britain where Lee McLoughlin is a a system manager, and programmer.

Lee McLoughlin is also known for an FTP mirror package he wrote and maintained in PERL a few years ago. He maintains a web page (http://www.doc.ic.ac.uk/~lmjm/) which doesn't mention this or the 'buffer' program but highlights some of his other work.

With RH 4.2 you might also be suffering from some confusion with your PAM configuration. You might have to change that around a bit or upgrade it to a new version.

If you were trying to access the root or any "root equivalent" account -- that is anyone with a UID of 0 (zero) you might have been bumping into the "/etc/securettys" problem. This is one of the other reasons why I configure my systems with an "operator" account and give that account access to the 'buffer' program and to the /dev/st0 node.

If you did tests with 'rlogin' that seemed successful (you were able to 'rlogin' to the account but not to run 'rsh' commands, keep in mind that these are separately configurable services in PAM.

Another constraint that is a bit more subtle: you cannot access 'rsh' and 'rlogin' commands through IP Masquerading. This is because the source IP port for an rsh or rlogin connection must be set to specific values

It's a very weak form of "authentication" on the part of the protocol, it was intended to ensure that the process on the client side of the machine was running with 'root's authority --- that it wasn't a random user's process just claiming to be anybody. That was almost reasonably 20 years ago before people had TCP/IP capable workstation on their desktops --- back when all of the "computers" were locking in server rooms and you wanted to create loosely coupled computing clusters within your domain. It is wholly inadequate and inappropriate on today's networks. That's why we have 'issh' and why I spend all night last night playing with the "Linux Free S/WAN" project (just search Yahoo! on that phrase).

(Free S/WAN is a project to implement secure, network level IP --- so that we can use transparent cryptography to protect applications layer protocols like rsh, and so many others. It's being developed internationally --- so that it will have to be imported into the U.S. --- this is because we're a "free nation" except when it comes to the practical application of advanced mathematics as a medium of expression).

In any event --- I really doubt that you're trying to access your tapehost through a masquerading router --- but if you are, you can expect that to fail.

From the error messages you show it looks like you do have the appropriate /etc/services entry and the appropriate entries in the /etc/inetd.conf. It also looks like you are not having a TCP wrappers problem in this case (since that would have given a different error message in the tapehost's syslog).

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 31 August 1998

	backup	uidgid	connect	95slow	badblock	trident	sound
	kernel	solprint	idescsi	distrib	modem	NDS	rpm
	guy	maildns	memleak	multihead	cdr