No subject

> Without the "SMARTHOST" lines, I get:
> Diagnostic-Code: SMTP; 550 Dialups/open relays blocked. Contact
> <openrelay at abuse.earthlink.net>
>
> With it, I get:
> Diagnostic-Code: SMTP; 550 rejected: cannot route to sender
> <snyderd at Popeye.SnydersWeb.com>
>

Read the error - cannot route to sender.  IIRC, that means that sendmail wasn't able
to resolve Popeye.SnydersWeb.com to an MX record (IP address for delivering mail).
nslookup tells me that there isn't an MX record for Popeye.SnydersWeb.com, but there
is for SnydersWeb.com.  So, if you get the to address fixed it should work.

I didn't read the original message very carefully because I don't do sendmail.  If
you continue to have trouble, you might try exim or qmail.  Both have reputations
for being reliable and easier to configure than sendmail.

HTH,
Dave



Received: from tummy.com (IDENT:qmailr at secure.tummy.com [198.49.126.3])
	by clue.denver.co.us (8.9.3/8.9.3) with SMTP id OAA12750
	for <clue-tech at clue.denver.co.us>; Tue, 12 Feb 2002 14:41:19 -0700
Received: (qmail 23854 invoked by uid 10); 12 Feb 2002 21:46:19 -0000
Received: (qmail 18808 invoked by uid 500); 12 Feb 2002 21:46:13 -0000
Date: Tue, 12 Feb 2002 14:46:13 -0700
From: Sean Reifschneider <jafo at tummy.com>
To: clue-tech at clue.denver.co.us
Subject: Re: [CLUE-Tech] Synching time shell script, where to put it to autosynch?
Message-ID: <20020212144613.D17987 at tummy.com>
References: <3C66025E.9BA4A22 at orci.com> <200202101616.g1AGGh2v095115 at deimos.frii.net> <3C66A869.AD6F54A8 at orci.com> <20020210233159.C1159 at tummy.com> <3C687725.26881312 at orci.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3C687725.26881312 at orci.com>; from kevincu at orci.com on Mon, Feb 11, 2002 at 07:00:05PM -0700
Sender: clue-tech-admin at clue.denver.co.us
Errors-To: clue-tech-admin at clue.denver.co.us
X-BeenThere: clue-tech at clue.denver.co.us
X-Mailman-Version: 2.0beta2
Precedence: bulk
Reply-To: clue-tech at clue.denver.co.us
List-Id: CLUE technical discussions, questions and answers. <clue-tech.clue.denver.co.us>

On Mon, Feb 11, 2002 at 07:00:05PM -0700, Kevin Cullis wrote:
>So, what would you recommend instead?  Putting it in the bin directory
>under root and then linking it?

Any root-protected directory should do.  I'd probably put it in
/usr/local/sbin

Sean
-- 
 Q:  What kind of dog goes "BOFH!  BOFH!"?
 A:  A rootweiler
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

Received: from rocky.us.pason.com (rocky.us.pason.com [63.251.183.29])
	by clue.denver.co.us (8.9.3/8.9.3) with ESMTP id TAA15331
	for <clue-tech at clue.denver.co.us>; Wed, 13 Feb 2002 19:03:19 -0700
Received: from goure (firewall.pason.com [216.18.39.158]) by rocky.us.pason.com (8.8.4/8.8.5) with SMTP id TAA16283; Wed, 13 Feb 2002 19:05:40 -0700
From: "Jim Ockers" <ockers at pason.com>
To: <ed at eh3.com>
Cc: <clue-tech at clue.denver.co.us>
Date: Wed, 13 Feb 2002 19:04:02 -0700
Message-ID: <003001c1b4fb$dfa9c240$2e0aa8c0 at goure.int.ca.pason.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <1009406784.2774.2.camel at eddy>
Subject: [CLUE-Tech] RE: [CLUE-Talk] swapping tapes in a jukebox with GNU tar
Sender: clue-tech-admin at clue.denver.co.us
Errors-To: clue-tech-admin at clue.denver.co.us
X-BeenThere: clue-tech at clue.denver.co.us
X-Mailman-Version: 2.0beta2
Precedence: bulk
Reply-To: clue-tech at clue.denver.co.us
List-Id: CLUE technical discussions, questions and answers. <clue-tech.clue.denver.co.us>

Dear Ed:

Thanks again for sending me this information and the backup scripts (in
December).  I finally got them up & running on our production server today.
I was uncomfortable with the tar multi-tape archival process and wasn't sure
how to do it so I appreciate your help.

mtx works pretty well for our tape autoloader/library hardware.

> You don't need the 2.4 kernel.  All you need is GNU tar and a copy of
> Leonard Zubkoff's mtx or a similar program.  Included are cut-down
> versions of the scripts that I just wrote for a Solaris box connected to
> a SCSI DDS-3 jukebox.  The backup script is kicked off by cron on a
> weekly basis and it does a monthly rotation between the first-three and
> second-three tapes.

I have another couple of questions, though.  Our tape drive hardware (DLT)
has hardware compression in it.  The native capacity is 35GB and the
compressed "capacity" is 70GB.  You know how the tape drive marketing
business goes.  So, with our 35/70 drives, I've been fitting 200GB of data
on one 35GB tape using lots of gzip and the hardware compression of course.
(Our database index files are inefficient and therefore have very good
compression.  There's actually about 100GB of actual data in there, which
compresses to less than 70GB I'm sure, due to the inefficient indexes.)

I had to switch to using the tape changer because the gzip was taking too
long and chewing on the CPU while our customers were trying to use the
system.

Anyway, do you have any idea what the -L medium size option is that I should
give tar for the hardware-compressed device?  I am not aware of a way to
make tar motor along until it fills up the device and then (and only then)
switch the tape.  I told it that the tape was 60GB in size since I'd rather
err on the side of caution.

Also, would you please have a look at this web page?  I think you'll find it
interesting.  He is talking about a way of using dd and pipes to buffer tape
backup data to speed up the write to the tape.  He is using gzip which
evidently caused things to really slow down:

http://dmst.aueb.gr/dds/pubs/trade/1999-login-dd/html/dd.html

It was published in USENIX.  I messed with this today and it seems that his
method is mutually exclusive with the use of an autochanger.  Following his
method, basically what I was doing was (without the gzip of course):

tar -cvf - / | dd obs=512k | dd obs=512k of=/dev/st0

where dd actually writes to the tape.  I also found that to read back from
the tape you have to use dd, as in "dd ibs=512k if=/dev/st0 | tar -tvf -"
otherwise tar doesn't understand the large blocksizes or the modifications
dd makes to the data stream.

Using Mr. Spinellis' method, dd actually owns the write-data-to-tape
process.  When I was messing with this today I had two dd's running and I
killed tar.  The first dd died (SIGPIPE), but the second dd (which was
holding /dev/st0 open for writing) did not die (it must have ignored
SIGPIPE).  I couldn't kill it (SIGTERM, SIGKILL).  I finally used mtx to
have the robotics unload the tape drive, and only then did that last dd
process go away (and I could access the tape drive again).

My question is: I think that if tar is writing to standard output you can't
use the -M option because tar does not own the write-data-to-tape process,
so it would have no way of releasing the tape drive to change tapes and
re-attaching itself to the tape drive so that we could continue writing data
to the next tape.

Do you agree?  Can you think of some way that I could use the
double-buffering method to speed up the write-to-tape but still use my tape
library with changer?

Thanks in advance for your thoughts.

Regards,
JimO

--
Jim Ockers (ockers at pason.com)
Contact information: http://www.pason.com/ockers.html