I got a few replies which answered the immediately obvious, that is to use the $CPU and/or $HOST Map Variables. This is not what I was looking for. The real issue is that in my environment X64 and SPARC binaries locations are going to be read-only, to take care of failover of these partitions, I simply cannot put them in a single location on a file server. I will not be able to mount it on a particular platform and install the binaries directly (they are automounted read-only file systems). Thanks to Richard Skelton who provided the right solution to this problem. His solution is given below: ==Richard Skelton says: What we do is to modify /etc/rc2.d/S74autofs on each client:- 'start') umask 0 Server="filer01" Platform="SunOS_5.9_sparc_all" echo "Starting automountd5.6 (Server: $Server, Platform: $Platform)" # # Start daemon here # /usr/lib/autofs/automountd -D SERVER=$Server -D PLATFORM=$Platform </de v/null >/dev/msglog 2>&1 echo "." echo "Do mounts" /usr/sbin/automount -t 300 # do mounts echo "." ;; 'stop') This is for a Sparc client. For an X86 client we would replace SunOS_5.9_sparc_all with SunOS_5.10_intel_all The the auto_direct map cab have for example:- /opt/studio11 -rw,hard,intr $SERVER:/vol/vol1/studio11/$PLATFORM On the filer the /vol/vol1/studio11 directory contains:- rskelton: ls Linux_2.2_i586_all/ SunOS_5.10_sparc_all@ SunOS_5.9_sparc_all@ Linux_2.4_i686_all@ SunOS_5.8_sparc_all/ SunOS_5.10_intel_all/ == It works like a charm :-) I never knew we could set our own Variables into automountd. Learnt something new. Much thanks to all who cared to reply. My original post is shown below: --SF On 2/15/07, Sun Manager <sunfired@gmail.com> wrote: > > Hello fellow managers, > > I am trapped in a kind of hole trying to figure out how best to accomplish > the task of sharing different binaries across different OS platforms from a > single location and at the same time provide for a fail-over of this shared > space using autofs in a NIS environment. I am afraid this post is going to > be long trying to best explain my situation. I searched high and low for an > answer but could not find any that had my particular situation. > > All our servers, so far have been SPARC machines running Solaris 9. So > there has been no need think about cross platform so far. However we will > soon be procuring X64 Servers that run Solaris 10 and I plan to put them in > the same domain as the other SPARC machines. Currently we have a shared > partition containing public domain tools (binaries) that are compiled and > hosted from a SPARC server in the network. This partition is mounted using a > direct map under the name /netopt and this is a read-only file system > because it is maintained as a fail-over partition. Its clone resides on > another nfs server, another SPARC. Whenever a new tool is compiled, I login > locally on the nfs server and compile and install the tool. The clone > machine copies everthing over in a minute and the tool become available in > the NIS domain. The problem with this arrangement will surface when the X64 > servers are added to the network. Then, even though there is a way in NIS to > use Map Variables to access platform specific binaries in /netopt, there > seems to be no way I can compile and install platform specific binaries into > /netopt because of the read-only filesystem requirement for fail-over. I > don't want to use the cross-compiling features of gcc. What I thought > instead was to have one of the X64 servers to serve X64 binaries under the > same /netopt mountpoint. This way I can login to the X64 host to compile and > install new tools but I can't see a way to make the auto_direct map to > conditionally serve up the tools from either platform in accordance to where > the requests originates from. To clarify: > > For example: > if > binaries in sparc resides in <sparc host>:/usr2/netopt > and binaries in x64 resides in <x64 host>:/usr2/netopt > are mapped directly to /netopt > > and if a user on x64 types the command: > cd /netopt > > is there a way to configure auto_direct maps to see that the request is > coming from a X64 client and hence to mount /netopt from the <X64 host> > > I hope my problem is clearly stated. I appreciate your response and > insight into solving this issue once and for all. > > Thanks > SF _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Feb 15 21:29:26 2007
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:04 EST