/opt linked to /export/opt; am I in trouble? - SUN

This is a discussion on /opt linked to /export/opt; am I in trouble? - SUN ; Hi all; I have a Solaris 8 system, running an Oracle DB and Veritas Volume Manager. Veritas is used as the boot-disk mirroring scheme; /, /usr, etc. are all UFS mounts of Veritas volumes. Specific revs I don't think matter ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: /opt linked to /export/opt; am I in trouble?

  1. /opt linked to /export/opt; am I in trouble?

    Hi all;

    I have a Solaris 8 system, running an Oracle DB and Veritas Volume
    Manager. Veritas is used as the boot-disk mirroring scheme; /, /usr,
    etc. are all UFS mounts of Veritas volumes. Specific revs I don't
    think matter for this question. I am concerned that I've inadvertently
    screwed something up, especially with Veritas, and would like som
    reassurance and/or corrective action from the group members Here's the
    background:

    - Vendor loaded the OS, installed supplemental packages (Veritas, some
    vendor specific stuff, etc.) back in 2003. Before my time and I wasn't
    involved, so I don't know the exact sequence of events.

    - this system had /opt as a soft link to /export/opt, a Veritas volume
    on the encapsulated boot disks. Contents of /export/opt are:

    $ ls -l /opt
    lrwxrwxrwx 1 root other 11 Apr 15 2004 /opt -> /export/opt

    $ cd /opt
    $ ls
    answerbooks rsc SUNWebnfs SUNWrtvc TSIgfxdrv VRTSfsdoc VRTSvxfs
    MITRAjre SUNWabhdw SUNWexplo SUNWsmtv TSIgfxOW VRTSlic VRTSvxvm
    MITRAssh SUNWconn SUNWits SUNWvts VRTS VRTSvmsa

    - I recently installed the SUNWsan package, using the SUN supplied
    'install-it' script, which contains all requisite patches, etc.. I
    installed the backage in single-user mode, expecting it to follow the
    link to /export/opt. Like a fool, I didn't think to verify this link,
    and as it was a Veritas mount, I don't think it was available in
    single-user. Shame on me! Apparently I missed a prompt, or the script
    did it automatically, but upon script completion, the /opt LINK was
    gone, instead replaced with a directory containing the SUNWsan
    package, and nothing else.

    - The reboot following the install was uneventful, all Veritas file
    systems came back online as expected, the SAN SW working as expected
    and turned over to the users. Later in the day, I get a call
    indicating that one of the vendor supplied package tools requiring
    Java isn't working. It is then I discovered the link to /export/opt
    missing.

    My resolution was to simply create a link in /opt to /export/home/
    {vendor tool}, which contains the Java path required, and they're OK
    again. I then created similar links to all the other packages listed
    above (SUNW*, VRTS*, etc.).

    I have the following questions, that speak to my lack of true
    understanding about SUN packaging, and how they inter-relate with the
    actual kernel. Please bear with my ignorance:

    1) Is my resolution above 'safe'? ie; does the system have access to
    all the package and package contents needed in the above scenario? I
    know during package install, binaries, etc. will be moved to /bin, or /
    sbin, or wherever they are needed. My system obviously booted OK
    following the removal of the link to these package locations, so the
    Veritas binaries are intact and working as expected.

    2) What is the purpose of having the package directory in /opt
    directory (link or not) if the binaries are moved to where the system
    needs them? If the system critical packages (esp. Veritas and SUNW*)
    located in the /export/opt directory were not available at boot time,
    then the system would not boot properly (or at least the Veritas
    mounts would not mount.

    Any insight into this would be appreciated; I have to schedule a
    reboot of this system shortly, and would like to be assured that it
    will indeed return to me safe and sound. I am reassured by the fact
    that it booted fine after the SUNWsan install, but am concerned that I
    have an issue that will bit me later.

    Thanks as usual to all who respond...

    Joe D.


  2. Re: /opt linked to /export/opt; am I in trouble?

    In article <1180022515.877358.141180@g4g2000hsf.googlegroups.c om>,
    Joe D. wrote:
    >Hi all;
    >
    > [...]
    >
    >My resolution was to simply create a link in /opt to /export/home/
    >{vendor tool}, which contains the Java path required, and they're OK
    >again. I then created similar links to all the other packages listed
    >above (SUNW*, VRTS*, etc.).
    >
    >I have the following questions, that speak to my lack of true
    >understanding about SUN packaging, and how they inter-relate with the
    >actual kernel. Please bear with my ignorance:


    Assuming you had the space to afford it, a better solution might have
    been to simply move the contents of the original symlinked location
    in /opt. Failing that, should maybe have moved the contents of the new
    /opt to the originally linked location and restored the link.

    Overall, littering the filesystem with tons of symlinks is kind of
    sloppy/bad form.

    -tom
    --

    "You can only be -so- accurate with a claw-hammer." --me

  3. Re: /opt linked to /export/opt; am I in trouble?

    On May 24, 4:55 pm, fer...@xanthia.com (Thomas H Jones II) wrote:
    > In article <1180022515.877358.141...@g4g2000hsf.googlegroups.c om>,
    >
    > Joe D. wrote:
    > >Hi all;

    >
    > > [...]

    >
    > >My resolution was to simply create a link in /opt to /export/home/
    > >{vendor tool}, which contains the Java path required, and they're OK
    > >again. I then created similar links to all the other packages listed
    > >above (SUNW*, VRTS*, etc.).

    >
    > >I have the following questions, that speak to my lack of true
    > >understanding about SUN packaging, and how they inter-relate with the
    > >actual kernel. Please bear with my ignorance:

    >
    > Assuming you had the space to afford it, a better solution might have
    > been to simply move the contents of the original symlinked location
    > in /opt. Failing that, should maybe have moved the contents of the new
    > /opt to the originally linked location and restored the link.
    >
    > Overall, littering the filesystem with tons of symlinks is kind of
    > sloppy/bad form.
    >
    > -tom
    > --
    >
    > "You can only be -so- accurate with a claw-hammer." --me


    Thanks.

    I can indeed move the contents of /opt to the 'original' location in /
    export/opt, and restore the original sym-link.

    But what about ny other questions? Is the contents of the package
    directory important, in light of the fact that the server booted OK?
    Just trying to understand how it works.


  4. Re: /opt linked to /export/opt; am I in trouble?

    In article <1180114998.549402.165180@g4g2000hsf.googlegroups.c om>,
    Joe D. wrote:
    >I can indeed move the contents of /opt to the 'original' location in /
    >export/opt, and restore the original sym-link.
    >
    >But what about ny other questions? Is the contents of the package
    >directory important, in light of the fact that the server booted OK?
    >Just trying to understand how it works.


    Each /opt/PACKAGE directory will have a different level of importance
    depending on what functionality is provided by it. Beyond that, can't
    really comment on the importance of them (which is why I did not
    previously do so).

    -tom
    --

    "You can only be -so- accurate with a claw-hammer." --me

+ Reply to Thread