Disk Enclosures
1752290 Members
5200 Online
108786 Solutions
New Discussion юеВ

XP config change auditing

 
Jon Hill_3
Advisor

XP config change auditing

We experienced a pretty major problem a few days ago with a development server. /stand (the boot volume) disappeared on us, though some other volumes in vg00 survived. vg00 resided on our XP-512 array.

Anyway, we were doing some work on the XP at the time and I wanted to confirm that this work was not responsible for the disaster. We did everything we could to trace our steps, and even got the RC to analyze a log dump from the SVP.

I was astonished when the RC told me that the XP does not audit config changes. Shortly before we booted up the development server, I performed several BC paircreates, deleted LUNs, added new LUNs, freed up a couple of LUSEs and made changes to Secure Manager. None of these changes were noted in the SVP dump. How is it possible for a storage frame targeted at the top-tier enterprise customers could ignore auditing?

I check my work religiously and am quite confident that none of my actions touched the dev server's vg00, but I'd have a stronger leg to stand on if I had a change log to back me up. I don't.

How do other XP users handle config auditing?
3 REPLIES 3
Sanjay Kumar Suri
Honored Contributor

Re: XP config change auditing

Our experience are as under:

1. vg00 is created on the internal disk of the system and not on XP.

2. Any change at XP level is done only by Customer Engineer. Noone is allowed to make changes in the configuration at XP.

3. Any change at XP level is preceded by Ignite/Full FS backup.

sks
A rigid mind is very sure, but often wrong. A flexible mind is generally unsure, but often right.
MBNA SAN Team
Occasional Advisor

Re: XP config change auditing

Hi,

Just curiuos to know how the boot process from XP512 to the server is setup..
Jon Hill_3
Advisor

Re: XP config change auditing

The boot from SAN process is pretty straightforward. We use Emulex LP8000 HBAs and have configured them in boot-from-SAN mode, which basically just means we enabled the boot BIOS.

During the initial Win2K install, we popped in the Win2K CD, hit a key very early in the setup screen to indicate that we'd install additional drivers, fed the Windows setup the HBA drivers (from a floppy) about five minutes later, and then just installed normally. With the HBA drivers installed, the LUNs on the SAN were visible and we specified one of those LUNs as our boot device.

During the server POST, an Emulex prompt appears that tells you to hit alt-E in order to configure the Emulex cards. We hit Alt-E during the first boot, pointed to the LUN we wanted to boot from, and then let it fly.

The only caveat is that if your server has two HBAs and you're using AutoPath or other DMP software, be sure to unplug one HBA during the Win2K install. You can plug it in once you've installed your DMP software.