Clayton,
I hope you don't mind me posting your email to the newsgroup, I
think others may also find your detailed explaination useful.
Thanks very much, most appreciated.
Scott Spence
Noggon Limited
---------- Forwarded message ----------
Date: Sun, 14 Feb 1999 05:05:43 -0800 (PST)
From: Clayton Weaver <[EMAIL PROTECTED]>
To: Scott Spence <[EMAIL PROTECTED]>
Subject: Re: FTP backup utility..
Try backupd. It installs as a server, it has a config file where
you specify allow/deny connections globally to the server and
allow/deny connections per resource. A resource can be a local
device like a tape drive or pretty much anything else. You
specify a write command and a read command for each resource,
which can be anything.
So to backup from a client on a different box, one would use
the included client:
tar -c / | backupc -w tape0 -h "[hostip or hostname where server is]"
The write command for the [tape0] resource on the host that is the
argument to the -h option could do any kind of filtering that you want.
Ditto for the read command on the remote host for reading back from
that same resource.
Two gotchas, one trivial, one maybe not:
* You have to double quote the values in the various fields of
a resource in /etc/backupd.conf, or they get parsed as
empty strings. I.e.,
[tape0]
# ok
user = "backup"
#lose, everything runs as whatever you started backupd as in inetd.conf
user = backup
The " and " are his delimiters for the string value of a resource field.
(primitive, but the point was "fast and simple".)
I hacked the readwrite() function so that it checks uid and exits if
getuid() returns 0 after calling changeuser() (no fork()/exec()ing
shell scripts as root allowed), and hacked it to chdir() into a
hardcoded directory owned by an admin uid.gid with 0711 permissions
at startup (that probably does nothing, since someone could go
wherever they wanted in their shell script; but if it dumps core
from the daemon, only core dumps with that uid-gid can be saved
into that directory, since it can't be running as root).
* The other gotcha, and this is one is a little more serious, is
that communications between the daemon and its read or write
commands is via a pipe, opened in the daemon before fork()ing
and execing() whatever the read or write command is. That could
be a bottleneck for really big throughput. The parent is sitting
there with an open socket connection to a backupc client and
the child is getting that through a pipe and then doing whatever
the script does it with. So everything comes to a backupd "write"
command for a resource on stdin, and everything comes from a "read"
command back to the daemon on the read command's stdout. You'd
just have to test whether this problem is a real problem given the
load you pour through that pipe.
He has binary (and source) OS/2 and Win32 clients as well as source for
a linux client. I haven't tried it from my OS/2 machine but it works fine
connecting to the local server via local host (it's still an AF_INET
socket, he doesn't switch to unix domain sockets if the user is local
or anything like that).
How you handle the actual archive data management is totally in your own
hands with backupd. It doesn't have any built-in limitations in *what*
to do with the data, only in throughput (which might be no big deal
since it has to pass through network sockets anyway; depends on how fast
your system is). But he is exec()ing the commands with execl() and
executing them with "sh -c command", ie as #!/bin/sh scripts, so whatever
/bin/sh is on a system is what's handling the pipe between the backupd
daemon and the read or write command for a specific resource in
/etc/backupd.conf.
It's a fairly simple, gpl program, you could hack anything you want into
it in terms of functionality.
ftp://ftp.gwdg.de/pub/linux/misc/backupd/
Additional caveat: you need a shell that can do real pipes for the
win95 client port (dos tmpfile pipes won't do for some reason), like tcsh
or bash.
Regards,
Clayton Weaver
<mailto:[EMAIL PROTECTED]>
(Seattle)
"Everbody's ignorant, just in different subjects." Will Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
