Disabling directory links HPUX?

[cbozlagan]

Disabling directory links HPUX?

How can I disable directory links?

Thanks

[Pete Randall]

rm /usr/bin/ln


Pete

[Dennis Handly]

What do you mean by directory links? As in hard or soft links, as Pete suggests?

[James R. Ferguson]

Hi:

Since hard links to directories are not permitted, you must mean soft (symbolic) links.

Perhaphs you don't want to traverse links when finding a file. The '-follow' option of 'find' controls this behavior. See the manpages for 'find(1)'.

Regards!

...JRF...

[cbozlagan]

Hi dennis,

I mean softlink

Thanks

[Steven Schweda]

> I mean softlink

Great. Now, what do you mean by "disable"?

Is there some actual problem which you are
trying to solve?

[cbozlagan]

Hi,

I do more explenation below
---------------------------
1- I had 2 HPUX system clustered. Running SAP R/3 on them.

2- I migrated SAP R/3 to faster platform.

3- I decided to use my HPUX s seperately (non clustered)
one HPUX for SAP NW XI
one HPUX for SAP NW EP

4- In order to use my HP system seperately I stopped cluster mechanism(MC/Masterguard)

5- I deleted SAP R/3 directories but one of them can not be deleted.

This directory is /usr/sap/trans

I know that this directory was exported and softlinked to other HP system.

I must delete trans directory to begin SAP NW installation.

Problem mentioned above is about both of HPUX system there once clustered each other.

Thanks.

[Steven Schweda]

> 5- I deleted SAP R/3 directories but one
> of them can not be deleted.

What, exactly, did you do, and what, exactly,
happened whan you did it?

> I know that this directory was exported
> and softlinked to other HP system.

What does this mean? Exported how? NFS?
Linked how?

It might help if you showed the actual
commands you used, and their actual output.
Seeing only what you concluded is less
helpful than seeing what actually happened.

[cbozlagan]

Hi steven, thanks for your interest

I give some knowledge below mean of export and link. This is from SAP document that mentions about cluster systems.

YOU CAN SEE soft link and export terms near <=== sign


===========
DOCUMENT
===========

3.1.3 Configuring Network File System

If required, you configure Network File System (NFS), which is a system-wide Single Point-of-Failure
(SPOF), for a high-availability (HA) installation. For more information consult your HA partner.
We regard NFS as an extension to the operating system. The switchover product protects NFS and
makes it transparently available to the SAP system in switchover situations.

You need to decide:

- How to protect NFS

- Which switchover cluster nodes NFS is to run on
The NFS configuration might depend on your database system. The directories need to be available
for the SAP system before and after a switchover.

Procedure
---------

1. Check the NFS directories, several of which need to be shared between all instances of a system.
These directories are:

- /sapmnt//profile
Contains the different profiles to simplify maintenance

- /sapmnt//global
Contains log files of batch jobs and central SysLog

- /usr/sap/trans
Contains data and log files for objects transported between different SAP Web AS systems (for
example, development integration). This transport directory ought to be accessible by at least
one AS instance of each system, but preferably by all.

- /sapmnt//exe
Contains the kernel executables. These executables ought to be accessible on all AS instances
locally without having to use NFS. The best solution is to store them locally on all AS instance
hosts.



2. Since you can protect NFS by a switchover product, it makes sense to install it on a cluster node.
The requirements of your database system might dictate how NFS has to be set up. If required, you
can configure the NFS server on the cluster node of the CI or the DB.
In both cases the NFS clients use the virtual IP address to mount NFS. If the second node is used as
an additional SAP instance during normal operation (for example, as a dialog instance), it also
needs to mount the directories listed above from the primary node.
When exporting the directories with their original names, you might encounter the problem of
a â busy NFS mountâ on the standby node. You can use the following workaround to solve this
problem:

a) On the primary server, mount the disks containing the directories:
/export/usr/sap/trans
/export/sapmnt/

b) The primary server creates soft links to the directories with the original SAP names: <===
/usr/sap/trans â > /export/usr/sap/trans
/sapmnt/ â > /export/sapmnt/

Alternatively the primary server can also mount the directories:
/export/usr/sap/trans â > /usr/sap/trans
/export/sapmnt/SID â > /sapmnt/

c) The primary server exports: <===
/export/usr/sap/trans
/export/sapmnt/

d) The standby NFS mounts: <===
from virt.IP:/export/usr/sap/trans to /usr/sap/trans
from virt.IP:/export/sapmnt/ to /sapmnt/
If the primary node goes down and a switchover occurs, the following happens:

- These directories on the standby node become busy:
/usr/sap/trans
/sapmnt/

- The standby node mounts disks to:
/export/usr/sap/trans
/export/sapmnt/

- The standby node configures the virtual IP address virt.IP

- The standby node exports: <===
/export/usr/sap/trans
/export/sapmnt/

- These directories on the standby node are accessible again:
/usr/sap/trans
/sapmnt/

[Steven Schweda]

Ok, but:

> It might help if you showed the actual
> commands you used, and their actual output.

This is still true.

"rm" should be able to remove a soft link.

"umount" should be able to unmount an
NFS-mounted file system, unless it's busy.

What, exactly, are you trying to do? How,
exactly, are you trying to do it? What,
exactly, happens when you try?

[cbozlagan]

steven,


dr x r x r x trans

chmod u+w trans

it gives message below:
chmod:can't change trans: Operation not supported

[Dennis Handly]

>I do more explanation below

(This is more useful than your original question.)

dr x r x r x trans
$ chmod u+w trans
>it gives message below:
chmod:can't change trans: Operation not supported

Do a "bdf trans" to find the mount point.
Then search in /etc/mnttab.

This may be a read only filesystem. And if you are on the client, you have no business fidding with it there. Work on the server.

But you should at least be able to umount it.

[cbozlagan]

Hi,

I deleted the lines below from /etc/mnttab

/etc/auto.direct /usr/sap/trans autofs ignore,direct 0 0 1181284472

/etc/auto.direct /sapmnt/BRP autofs ignore,direct 0 0 1181284473

I rebooted both systems.

After rebooting, I checked /etc/mnttab. I saw lines above exist there.System reconstructed lines above after rebooting.

[Steven Schweda]

> I deleted the lines below from /etc/mnttab

"man mnttab":

[...]
WARNINGS
The table is provided only as a means for programs to return
information about mounted file systems.

/etc/mnttab should never be manually edited. Any manual changes made
to /etc/mnttab are overwritten without warning by syncer, mount, and
umount.
[...]

"man fstab"?

If you're using the automounter ("man
automount", "man automountd"), NFS-remote
file systems can be mounted without explicit
"mount" commands.

[Dennis Handly]

>I deleted the lines below from /etc/mnttab

Ack!!!
As Steven says, you should just umount those, ordinarily you don't need to reboot. But if you did, those should not be mounted, especially if you did exportfs -u.

[M.S. BALAJI]

Hi,

From this thread and other threads you have created, I understand that you are running MC service guard cluster with High availability NFS.

1. For SAP installation, normally
/usr/sap/trans will be mounted as /export/usr/sap/trans and /sapmnt/SID as /export/sapmnt/SID. This is handled by HA-NFS

2. The VG's will be under the control of Service guard

Please follow the procedures.

Hope you have the list of VG's under the control service guard and FS details.

If you don't please take a output of #bdf.
(or) you can gather the current configuration of cluster and package by running
#cmgetconf -v -c clustername filename.ascii
#cmgetconf -v -p pkg.name filename.ascii

All the VG and FS information will be available there.

1) #cmhaltcl -v (This will halt the cluster service and unmount all FS and deactivate VG's)
2) #modify the /etc/rc.config.d/cmcluster file (AUTOSTART_CMCLD=0)
3) See the cluster config files
4) Add the mount points in /etc/fstab
5) If possible take a reboot else activate vg's using
vgchagne -a y -c n -S n /dev/vgXX
6) mountall

7) Delete the files in /usr/sap/trans

With thanks & regards,
BALAJI M.S

[Yogeeraj_1]

hi,

I don't think you should have manually edited the /etc/mnttab.

This is an extract from man mnttab:

mount and umount update the mnttab file whenever a file system is mounted or unmounted. syncer rewrites the mnttab file if it is out of date with the mounted file system table maintained internally by the HP-UX kernel,

...
/etc/mnttab should never be manually edited. Any manual changes made to /etc/mnttab are overwritten without warning by syncer, mount, and umount.



You should review your /etc/fstab instead.

hope this helps!

kind regards
yogeeraj