If you do this once, you may be asked to do it again. If it becomes known that you have done some minor Unix sysadmin tasks in the past, you may be asked to do more and different things in the future. Eventually, in baby steps, you may be pushed into becoming the de facto sysadmin of that system.
I guess you would not like that, and I don't blame you: it's a matter of personal preferences after all.
If this seems like a possible future in your situation, I recommend that you grow yourself a backbone *now* and politely but firmly refuse to do anything with that system.
If you need reasons, you have plenty:
- you don't have the necessary skills for the job
- you're unfamiliar with that system in particular
- you're afraid that if you make a mistake, it would cause damage to the company and be considered your fault
If your boss won't listen to you, explain your situation to a higher-level boss.
It might be important to express your refusal in writing (e.g. email), so that you'll get a permanent record of who-said-what, just in case it eventually escalates to a legal issue.
Based on your question, it seems you have an external storage system, perhaps a SAN of some complexity. If multipathing is used, you would need to find out how it was configured in the past, and make sure the new disk has a proper multipath configuration. It's not very difficult, but the details will depend on your current system configuration.
There are plenty of details that must be known (or found out) to successfully perform your task:
What's your HP-UX version?
(the command "uname -a" will indicate that)
Is this a stand-alone system, or a member of a cluster? If a cluster, what's the name of the clustering solution? HP Serviceguard, or perhaps something different and maybe application-specific?
Which multipath solution you're using; the old built-in LVM alternate pathing, or some load-balancing solution like HP's SecurePath, EMC's PowerPath or the built-in features of the latest-and-greatest HP-UX 11.31?
(a "vgscan -v" listing of one of your existing volume groups that uses external storage; "swlist" listing may also reveal the name of an optional multipath solution, if one has been installed)
What's the rough size of the new LUN?
What I'm trying to find out is, is it "average size" for the OS version so that the default settings will be adequate, or "relatively large" so some configuration planning is required to ensure that the new filesystem can be painlessly maintained/expanded/migrated to another storage device in the future?
Is your system using the basic LVM or the optional VxVM for disk management? (The output of "mount" or "bdf" should reveal that: if the devices that hold the filesystems are named like /dev/vg*/*, you're using LVM; if they are named like /dev/vx/dsk/*/*, you have VxVM.)
What kind of volume group naming scheme have you been using in the past? Would the old scheme be appropriate for your new LUN/filesystem, or should you create custom name(s) to make the configuration more self-documenting?
What are the requirements of the application that will be using the new filesystem?
In which directory should the new filesystem be mounted?
What kind of permissions should it have?
Is it a legacy application that cannot handle files larger than 2 GB, so a "nolargefiles" filesystem option might be required to protect it?
Or is the OS version so old that "largefiles" would have to be explicitly specified at filesystem creation time?
MK
MK
