Interoperability Between automount Implementations?

vinay asks: "We are trying to integrate our Sun Solaris machines with new Linux servers. One major issue we currently have is to have a single set of automount files that will work for both environments. After going through all of the HOWTOs and the FAQs for Linux automount, we were troubled to see that Linux automount has a very basic feature set, and isn't very compatible with Solaris automount." Might it be possible for Linux to emulate the missing features offered in Solaris automount via expert use of short scripts?

"We are primarily interested in how to take care of '/-' key and variable substitution. Currently, one can call a map like:

 /-  auto.direct mount-options

and in auto.direct can have entry like

 /project1  -some_options FileServer:/projects/project1

Now this map will not work for Linux. The best one can do is mount the projects tree as /linux/projects and make some softlinks. However, this becomes very messy as the number of machines grows (and this is only for one directory path).

It's the same thing with all of the software we have installed, we can mount the Linux software in a different tree, but in that case all startup files (.cshrc, .bash_profile, etc) will have to different for each OS (or some other messy workarounds). The way I would prefer to handle this is to install Solaris software in /software/SunOS, and Linux in /software/Linux and mount them via variable substitution in the automount file:

 /software -options  FileServer:/software/$OSNAME

This way users will have a single startup file and they will only mount the binaries of their current OS in exactly same path.

Also, Linux automount recommends that you avoid mounting in the root directory area, but the automount from other vendors don't seem to have this limitation, and make use of the '/-' key."

While, I'm all for compatibility, it's not unreasonable to expect programs like "automount" to vary between implementations. Has anyone figured out a work around for this situation that isn't so "messy"? Would preprocessing the automount options file right before invocation be possible, in this case? And are there plans to make Linux automount more compatible with some of the options available to the Solaris version?

Use amd

[joekrahn]

Linux autofs is missing many, many features, such as being able to specify multiple redundant servers for one mount point. I use amd, packaged in am-utils. It has almost everything you need, but no direct maps (I think it's a Linux limitation: the automounter has to take the whole directory, not just entries in it).

You can simulate this by having a real mount point, like /nfs, then putting symbolic links in root, such as /shares -> /nfs/shares. Of course, you then have to maintain those links.

You still may need different map formats. For total compatibility, you might have to make executable maps that read and reformat the real maps. I gave in and just keep two sets of maps, one for Linux and one for IRIX.

Home directory mounts have not been a problem, and I still use autofs for those, becuase it's a bit faster.

The /pack method

[Styx]

I use the /pack way [sunsite.dk], both at home and at work.
For the full-featured automounters (Solaris, IRIX), I then use a map looking like this:
make vortex:/sda7/pack-$OSNAME-$OSREL-$CPU/make-3.74 make-3.74 vortex:/sda7/pack-$OSNAME-$OSREL-$CPU/& binutils vortex:/sda7/pack-$OSNAME-$OSREL-$CPU/binutils-2.1 1.2 binutils-2.11.2 vortex:/sda7/pack-$OSNAME-$OSREL-$CPU/& /sda7 on the server looks like this: pack pack-IRIX64-6.2-mips pack-Linux-2.4-Alpha pack-SunOS-5.8-sparc

The plain pack is for linux x86, the rest should be self-explanatory.

Because of the /pack system, I know that apache on a box, can always be restarted by doing /pack/apache/bin/apachectl restart, or even apachectl restart when I use /coll, and have /coll/local/bin and /coll/local/sbin first in my path.

Other than that, I set PATH and MANPATH (and some other stuff), differently with a case structure based on $OSNAME in .bashrc

It works pretty well.

Here's how we do it:

[O]

At work, we have an NIS server which contains all of our data. In our case, we mount the /home directory. Here are our relevants files:

/etc/auto.master:
# Master map for automounter
#
+auto.master
/home auto.home -nobrowse

Relevants entries in /etc/nsswitch.conf:
netgroup: nis
auto.home: nis
auto.master: nis


And we start it as "/sbin/automount /home yp auto.home"

See, all of the info is just an NIS field:
[tux-6] ~$ ypcat auto.master
auto.home
-hosts -nosuid

auto.home is also an NIS field that has all the rest of the stuff

We are using whatever automounter that comes with Solaris (I'm assuming. I never looked at it too hard) and Autofs 4.0.0pre10 or something like that on linux, and they both work. The config files are almost the same too.

Not to be a nimrod but

[pauldy]

What about the uname command wouldn't it be fairly easy to put something like

CUR_OS=`uname`
if test "$CUR_OS" == "Linux"
then
<paste linux parms here>
else
<paste solaris parms here>
fi

It seems to me this would be fairly easy if you already have two working implimentations of each to just make a file like this for mast all the files you currently have that run as shell scripts. You could even create them with a nice shell script by mounting the two dirs then running something like.

filelist=".bashrc .cshrc .tcshrc etc..."
for file in filelist
do
echo "CUR_OS=\`uname\`" > ./newfiles/$file
echo "if test \"\$CUR_OS\" == \"Linux\" >> ./newfiles/$file
echo " then" >> ./newfiles/$file
cat ./linux/$file >> ./newfiles/$file
echo " else" >> ./newfiles/$file
cat ./solaris/$file >> ./newfiles/$file
echo " fi" >> ./newfiles/$file
done

Seems like it wouldn't be that hard or complicated. You could even use something like this to set MOUNT_PARMS for linux as well as one for linux then call automount $MOUNT_PARMS and have it run just like you want.