SUMMARY: automount question

From: raina eckhardt (raina@doc.plh.af.mil)
Date: Fri Jun 10 1994 - 20:16:08 CDT


        
                SUMMARY OF AUTOMOUNT QUESTION

I would like to thank all of the people who replied to my question
about automount. I underestimated the number of answers that I would
receive. The current count is 27 replies. There are several different
ways to solve the automount problem that I was experiencing. I will
start by including the automount question, then by outlining the solution
that I choose to implement. Finally, I will list some of the other
possible solutions that were sent to me.

QUESTION:

Here is a summary of the problem that we are having:

We currently have seven sun workstations on a network (Each named after one
of the Seven Dwarfs). All are running OS V4.1.2 and using NIS for sharing
system information. We are using only one NIS server, doc. It is our master
server. We have several file systems that are being exported from doc and
automounted on the other six systems. Our automount files are being shared
via NIS as NIS maps. The problem occurs if we try to have doc use the NIS
automount map files. When we do this, then doc tries to automount it's own
locally mounted files system and they become unavailable. When we try to access these file system on doc we get an error message "too may symbolic links".
Our current solution is to have doc use its own automount files in /etc.
This has been working for us. However we are now starting to export file
systems from some of the other six systems to be automounted by the remaining
systems. This is causing the same problem. For example:

        o I added a new disk to sleepy, file system name /yes
        o exported /yes on sleepy
        o modified /var/yp/etc/auto.direct on doc to include /yes as an
          automount file system
        o created and pushed this new auto.direct map to the NIS clients
        o rebooted all of the system

All of the systems automounted /yes correctly until sleepy was rebooted. Then
sleepy tried to automount it's own local file system, /yes, and I got the error
message "too many symbolic links".

My current set-up is:

        o remove /yes from /var/yp/etc/auto.direct on doc
        o create and push new auto.direct map to NIS clients
        o reboot sleepy
        o insert /yes back into /var/yp/etc/auto.direct on doc
        o create and push new auto.direct map to NIS client

This is VERY temporary. If sleepy reboots then we will loose the /yes file
system. I need a permanent solution to this problem. Please respond as soon
as you can.

Our current automount set-up is as follows:

        auto.master - has only one line directing automount to use auto.direct:
                      /- auto.direct -rw,intr,soft

        auto.direct - contains a line for each file system that should be
                      automounted.

        auto.home - is empty

After combing through the man pages on automount I found the -NULL option. I have tried using the -NULL option when starting automount in /etc/rc.local.
This worked for all of my systems except my NIS server which seems to ignore
it.

MY FINAL SOLUTION: <--- This is also the solution that the Sun Support people
                         gave me.

Create a directory, /export, on the file server. Mount the local file
system to be exported on a mount point in /export. i.e. If the file system
is called /home, then it would be mounted locally as /export/home. Then
include an entry in the NIS auto.direct file as follows:

/home options file_server:/export/home

Also, export the file system, /export/home, on the system, file_server.
When the file server starts automount using the NIS automount maps it will
identify that /export/home is a local file system. It will then create a
symbolic link from /home to /export/home. When each NIS client starts
automount it will automount file_server:/export/home as /tmp_mnt/home and
create a symbolic link from /home to /tmp_mnt/home.

Now all of the exported file systems will be located in /export on the file
server. This also helps to quickly identify the exported file systems.

OTHER POSSIBLE SOLUTIONS:

o Use indirect automounts and create soft links to the file systems. The
  advantage is that no reboots will be needed when an automount NIS map is
  updated and pushed to the clients.

o Use different names for the exported file system and the automount point.
  i.e. If the local file system is called /home1 on the file server, then
  call it /dsk1 on the NIS automount clients. Include the following line
  in the auto.direct file:

  /dsk1 options file_server:/home1

o Use the -null option when invoking the automount command from /etc/rc.local.
  Issue the automount command, then list each file system that is mounted
  locally followed by the -null option. i.e.

  if [ -f /usr/etc/automount ]; then
        automount /home1 -null /home2 -null && echo -n ' automount '
  fi

o Change the name of the local file system to end with "_". Then specify
  this name in the auto.direct file. i.e. if the local file system is
  called /home1_ on system named file_server include the following line
  in auto.direct:

  /home1 file_server:&_

  Where "&_" = /home1_. This will automount the file system as /home1 on
  the clients and create a symbolic link /home1 to /home1_ on the file
  server.

Thanks again to all the people who replied!

Regards,
Raina Eckhardt
Systems Administrator
Seismology Division
Phillips Lab
Hanscom, MA
raina@doc.plh.af.mil



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:03 CDT