[Novalug] Re: [Ma-linux] backup/mirror script

[Mark Smith]

On Tue, Apr 17, 2007 at 11:29:11AM -0400, Angelo Bertolli wrote:
> >why are you testing the connection with nc when rsync will
> >do that as a matter of course anyway?  it complicate things
> >unnecessarily and doesn't help.
> 
> I don't like the way rsync fails.  Especially since I have a firewall 
> rule that I use that drops packets if someone connects to ssh too 
> frequently.  Rsync ends up taking forever to find out it can't connect.

if you're connecting to the ssh port, your firewall will see it as
a ssh connection.  besides, my version of rsync (2.6.3) has a timeout
option.

> >don't exit -1 as that's "weird".  the desired range is 0-255.
> >if you want 255, use 255, but i would suggest 'exit 1' for
> >"normal failure" or 2 if you want differentiate that between
> >a usage statement, or pick your exit code.
> 
> Are there any standard numbers I should use?  Like 5 means missing 
> arguments or something?

i've never seen anyone use them, but many operating systems include
a /usr/include/*exit*.h which defines common exit codes.  of course,
it's used from a c-program, there's no reason why you can't use the
values for your shell script.  having said that, the only thing that
should really matter is zero and non-zero.

i use 0 for success, 1 for general error, and 2 for a usage request,
but everything is up for grabs.  i would suggest doing it the same
way all the time.

> >make sure it's running as ssh (if applicable) to protect privacy
> >enroute.
> 
> I think this is the default for rsync.

yes, it is now, but older versions don't.  it's probably safe to
assume ssh.  you know your own systems better than i do.

> >if this is a script that will run in an unattended mode you'll
> >need to open ssh for root w/o a password from the remote side.
> >you'll need to take necessary precautions and accept certain
> >risk with that.
> 
> Thanks for the comments.  I actually do use this at the command line, 
> and not unattended.  Call me crazy, but I'm not too keen on using ssh 
> keys with root.

it's all a matter of risk acceptance.  sometimes it makes more sense
to accept that particular risk depending upon the situation.  it makes
your root access only as strong as the weakest host, but sometimes
that's okay.  you just have to understand and accept the risk.

for instance, if you wanted to backup a dozen or more hosts on a regular
basis, it'd probably be stupid to depend upon a human being to do the
right thing.  you also probably want to grab the filesystems when the
file system is fairly quiescent which will probably translate to early
in the morning times.

-- 
Mark Smith
mark at winksmith.com
mark at tux dot org
nova-instructor at tux dot org