Les Mikesell (lesmik...@gmail.com)

Are you leading by example here?

My solution for semi-critical stuff (i.e. a few minutes of downtime
won't cost the 6 figures it would take to prevent it) has been to use
RAID1 in a chassis with hot-swap carriers and keep a spare chassis
handy.  That way the common case of a disk failure doesn't even cause a 
slowdown and you can rebuild at an off-peak time without shutting down
and in the much less likely case of a motherboard failure you yank the
drives, put them in the other box and reboot.  But, that means you are 
probably limited to 6 disks total with half used as mirrors and you
still need backups for software or site disasters.

The next step up from this would be DRBD to keep hot copies on the spare
machine but I've always gotten away with one spare chassis for several
active servers (and sometime using it for testing other things too...).

You do need to know about the NIC hardware address in
/etc/sysconfig/ifcfg-eth? when swapping disks around, though.

It's the same connector except keyed so you can plug a SATA device into
a SAS backplane but not the reverse.   SAS controllers are required to 
support SATA devices.

But, I think the OP's real problem is that everything is tied to one
single large drive (i.e. the software mirroring is mostly irrelevant as
well as the controller type).  These would get you a queue of 
outstanding commands compared to a SATA, but if you want a big
difference in throughput or less latency when multitasking you really
have to split things over a bunch of drives, either with some other type
of raid or explicitly mounting different filesystems so you can control
which things compete for the disk head position.

I'm using apache with mod_proxy to make the server appear at a different
location and port and need to tweak some absolute references in the
content as it goes by.  mod_proxy_html looked promising - and appears to 
work - but seems to be making the httpd process consume a lot of CPU on
occasion.  mod_substitute as included in more recent apache versions 
should work and mod_sed is another possibility.   Has anyone solved this 
problem with the version of httpd in RHEL/Centos?

On the other hand, given bandwidth suitable for keeping up with changes
via rsync, backuppc is perfectly capable of maintaining offsite backups
over a vpn without transporting anything.  And for life span you can use 
raid mirrors and replace a drive every couple of years.  Also, backuppc 
can generate a tar imaage that you can write to other media for archival
storage and the ability to restore without the application running - it
isn't particularly handy but it is possible.

That's generally not a problem, but you'll get a snapshot of changing
files, like growing logfiles, and if a file is deleted while still open
it will still consume space on the source as seen by 'df' until the
application closes it or exits but it won't be copied.

I think it is the wrong answer to any possible problem (compared to
changing DNS or whatever it takes to make the connection request go to
the right place on its own).  Your iptables DNAT line would work to get 
the packet to the other host - and you should be able to see that with
tcpdump.  However, when host B responds back to the original source 
address it won't complete a connection to the socket waiting for
something from host A.

_And_ keep in mind that you are going to get replies and probably spam
to this address.  So you'll probably want to turn on the moderation 
feature of the list.

Is that peculiar to bash?  I thought the `command` construct was 
expanded by shells into the command line before being evaluated.

These shouldn't make any difference.  The limit is on the size of the 
expanded shell command line.  The original example won't cause it.  The 
ones that expand a list with a * or the output of ls may.  The right 
solution is to let rm recurse with -r or to potentially long list to xargs.

Anything that is installed via RPM is already databased and tracked.  if 
you edit something you have to track it yourself.  I don't know of a 
good tool for this.  For the things I edit frequently and the changes 
aren't obvious (like DNS zone files), I commit the changes to a CVS
server that has viewcvs for easy browsing and diff-ing against earlier
versions.

> I've used tripwire in the past - do you have any other recommendations
> for this type of project?

Tripwire doesn't help when you need to put things back the way they were
a version or two back.  Backups are always a good thing and a 
brute-force approach would be to rsync your /etc directories off to some
other machine, perhaps using the backup-dir option to keep some old
versions around.  Running rsync with the -v and -n options will tell you 
if anything changed compared to the last copy. I'm surprised that there
isn't a good tool built on top of one of the version control systems
that could treat similar machines as branches, though.  What needs to be 
done is very similar to other version control concepts and everyone
needs it.

How can a forum possibly be the right place to discuss what people care
about in mailing lists?  At least until someone sets up a gateway...