Tim Lytle's questions

I've seen this behavior twice in the past week or so, where mail takes a very long time to send (60 seconds). In troubleshooting one case, I found that cause is setting a custom 'From' header.

I can work around this using a SMTP connection instead of mail() (which is better all around) - just wondering if anyone could shed some light on why setting the header would cause this delay.

I have some guesses, but nothing I know for sure.

Update: Running in Linux. I have to check on the MX records, I'm pretty sure one is correctly pointing to the server (for the domain, although the address isn't really a valid user/alias), the other it's probably not, since this is one of many servers for that domain/company.

Update (2): Actually, the hosting for the one recently changed, so I'm pretty sure neither case has a MX record pointing to the server sending the email. That's likely the issue - although, I'd love to know why the mail is still sent, but with a delay. Looks like this will be moved to ServerFault and perhaps find an answer there.

Log output (actual domain name redacted):

Oct  3 12:28:18 server sendmail[29795]: p93CSI3t029795: from=tjlytle, size=129, class=0, nrcpts=1, msgid=<[email protected]>, relay=tjlytle@localhost
Oct  3 12:29:30 server sm-mta[29796]: p93CSIs6029796: from=<[email protected]>, size=355, class=0, nrcpts=1, msgid=<[email protected]>, proto=ESMTP, daemon=MTA-v4, relay=localhost.localdomain [127.0.0.1]
Oct  3 12:29:30 server sendmail[29795]: p93CSI3t029795: [email protected], ctladdr=tjlytle (1001/1001), delay=00:01:12, xdelay=00:01:12, mailer=relay, pri=30129, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (p93CSIs6029796 Message accepted for delivery)
Oct  3 12:29:30 server sm-mta[30649]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128

I'm trying to work up a backup strategy for some clients, and am leaning towards duplicity for remote backup (already use rdiff-backup for internal/on location backups).

Is it reasonable to want a full backup every so often? Since duplicity increments forward, each incremental backup is relying on the previous increment, and all are relying heavily on the last full backup. Should that become corrupt, bad things happen. A related question: Does Duplicity test the incremental backups for consistency?

Assuming I do want a full backup every so often, how efficiently does duplicity create that full backup? Can/does it check file signatures and copy unchanged data from previous full backups/increments? Basically creating a new 'full' archive transferring new/changed data and merging existing unchanged data?

Right now my concern is that running a full backup is needed, but the consistent large bandwidth use of full backups will make this unreasonable for some clients.

I have a long standing problem with mod_rewrite and 1and1 shared hosting (hope that being shared hosting does't get this migrated to 'sharedserverfault'). Everything about the rewrite rules work fine - except when 'index' is in the path. Then I get an Apache 404 error.

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]

Pretty standard so far, works fine on most server. On 1and1's server I get a 404 error if index is the top 'directory'. Anything starting with 'http://example.com/index' will give a 404.

• http://example.com/index
• http://example.com/index/action
• http://example.com/index/what/ever.anything

If I copy index.php to bootstrap.php and change the .htaccess file to point there and delete index.php, it will work.

However, that makes it a pain to update the server - any ideas what apache settings are causing this? Obviously I can't change the main configuration file, but I can override settings with the .htaccess file.

A friend couldn't seem to get Norton Ghost to clone a disk usably. I suggested using GParted, and (after running chkdsk /f on the NTFS partition - possibly the cause of Norton's problem) took the following steps:

• Copied the recovery partition (at the end of the original drive) to the end of the new drive.
• Copied the system partition to the start of the new drive, and 'stretched' it to fill the empty space.

After the clone was finished (and I had left), he tried to boot, got an error and did the fixmbr/fixboot process. After that Windows XP would start to boot, but give a 'missing hal.dll' error.

What happened?