Charles's questions

tl;dr: I fat-fingered grub-install, then "correctly" re-issued it targeting the /boot filesystem on /dev/sda1 but it isn't reading grub/grub.conf unless I expressly tell it where to look using the grub prompt tools. How do I fix that?

I have a critical CentOS 5 system with multiple hard drives that aren't hot-swappable. That's a bad idea, by the way.

The first drive contains /boot, then two mirror mdraid partitions for the OS and data. The second drive contains just the two mdraid partitions.

The first drive is very slowly dying, so I added a third drive to prepare for the inevitable. I copied the partition layout of the first drive, added it to the mdraid mirror, then used dd to clone sda1 to sdc1.

I had a hardware maintenance window last night and needed to reboot the machine anyway, so I figured I'd take the chance to switch sdc to the boot drive. As I only copied the partition layout and the first partition, not the entire drive, I figured that sdc wasn't bootable. So after adjusting fstab, I made sdc1 bootable and used grub-install to ensure that grub could take care of things.

Only I fat-fingered the command and typed grub-install /dev/sda.

It gave me a warning about not finding the drive in the BIOS drive list, so I assumed that it didn't do anything harmful. I re-issued the command targetting /dev/sda1 instead, but got the same error. Hmm. Oh well, it probably didn't do anything, right? Yeah. No.

When the system didn't come back up after reboot (printing GRUB GRUB GRUB over and over on the console), I knew I was screwed. Apparently what I did is irritatingly common.

I booted the machine into a live CD, used dd to nuke the MBRs on both sda and sdc, mounted sda1's copy of /boot, issued the correct command (which involves asking it to probe the drive list and giving an actual filesystem location), and rebooted. What came up was the grub shell. I was able to issue root (hd0,0) and configfile grub/grub.conf to get into the boot menu, but I would have assumed that if I'd issued the command correctly to begin with then it would have seen the menu immediately.

So, my critical system is running fine. I'm only going to be able to reboot it once in the near future, so I'd like to get this taken care of correctly.

So, my questions:

1. Is the current booting-into-grub-but-not-seeing-any-configuration fixable without re-running grub-install? I'm terrified of the thing now.
2. If I have to invoke grub-install again, what should be the correct way? I used grub-install --recheck --root-directory=/path/to/sda1/boot /dev/sda1 to get it into its current state.

We occasionally have customer-provided servers in our technical support and engineering departments. They're isolated on their own VLAN, with strict firewall rules in place to minimize possible bad behavior.

We've found ourselves needing to capture (instead of block) outgoing mail by these machines. Redirecting ports and feeding machines fake MX records is easy. Creating a fake open relay doesn't seem to be. My goal is:

• Mail to [email protected] gets relayed upstream (relay_domain = $mydomain and relayhost = $mydomain)
• Mail to [email protected] gets captured and forwarded to an email address @ourdomain.com

Things that probably won't work, as answered in other similar questions:

• BCC maps: I don't want the original mail delivered to the original recipients at all.
• virtual_alias_maps: The outgoing mails could be to any domain, not just one or two domains.
• canonical rewriting /^.*$/: Modifies all mail, which isn't what I want. I only want non-relayable mail to be forwarded.

If this isn't possible in postfix, can other MTAs handle the task? It looks like my other obvious choices are sendmail and exim.

Workstations on the office VLAN are assigned IP addresses in the 10.10.0.0/16 range. It's defined as a "Work" network and is using the "Private" firewall rule set. We use a central firewall / router to pass traffic between the VLANs and different IP ranges.

One of those IP ranges is assigned to our VPN solution, 10.100.0.0/16. For some reason, Windows Firewall (at least in Windows 7) is blocking all incoming traffic from 10.100 addresses, including pings and SMB traffic.

Why is this traffic being blocked? I thought the rules on "Private" connections were more relaxed. Is it because the traffic is coming from outside of the LAN's netmask/subnet? The wording on some of the "Private" rules suggests this, but I'm not 100% sure.

Can the traffic be permitted without creating new firewall rules? Rather, if it really is the netmask/subnet causing the problem, is there a way to make either the network configuration or Windows Firewall see it as sane? Creating new rules works, I'd just rather not have to go to each workstation and apply it manually. We don't yet have a domain, so no group policy pushing.

I've found myself needing redundant storage at a block level. File-level replication (Gluster, GFS, etc) does not work for my use case.

It looks like DRBD is the go-to solution for block replication. There don't seem to be too many other sane options. Have I failed in my research, or is DRBD the only game in town?

I have two physical machines that I wish to virtualize.

I can not (physically) plug the hard drives from either machine into the new machine that will act as their VM host, so I think that copying the entire structure of the system over using dd is out of the question.

How can I best go about migrating these machines from their hardware to the KVM environment? I've set up empty, unformatted LVM logical volumes to host their filesystems, with the understanding that giving the VMs a real partition to work with achieves higher performance than sticking an image on the filesystem.

Would I be better off creating new OS installs and rsyncing the differences over?

FWIW, the two machines to be VM'd are running CentOS 5, and the host machine is running Ubuntu Server 10.04 for no particularly important reason. I doubt this matters too much, as it's still going to be KVM and libvert that matter.