Even better is the integration of NIS services with the Automounter, adding flexibility and central administration with the elimination of client-by-client local files administration. That's exceptional for medium-to-large networks.
The integration is extremely simple and straightforward, just requiring to enable the corresponding (automount) Name Service Switch (NSS) database and crafting appropriate built-in (auto.master and auto.home) NIS maps alongside additional auto_* custom NIS maps for extended flexibility.
It's critical to avoid as much as possible any hard-coded dependencies in the /etc/auto_master of each client in order to avoid expensive post-installation management in case locations must be substituted. It's enough to consider the importance of this on a network of hundreds or thousands of computers. As a consequence, it's important to carefully choose stable names for the topmost mounting points for the data at rest, such as /data, /public, /download, /business.corp, and so on.
Once all the requirements have been fulfilled, typical usages are:
- The in-line (a.k.a. the no absolute paths prefixes) syntax.
The referenced NIS map contents are considered in relation to: i) a mountpoint prefix (to the left) of the map's name in the current Automounter configuration file or else ii) a nested map (multiple indirection) into another referenced NIS map.
- The inclusion (+map_name) syntax.
The map_name NIS map contents are inserted at the current Automounter configuration file (a.k.a. local map) referenced line position. This has the main disadvantage of not integrating with variable substitution as previously described. So except for special cases I won't consider this option due to its inherent limitation.
Again, a couple of examples should help clarify matters.
I'll start by the simplest and progress to the more elaborated examples.
Example 1:
Requirement: Standards based centrally management of on-demand mounting of assorted NFS shares by several hosts under /data.
Solution: Configure the automounter of each host to use a specific NIS map describing what's to be mounted as needed. Assuming a host called app-server-1, this is as simple as modifying its /etc/auto_master as follows:
app-server-1:~# cat /etc/auto_master
...
/data auto_data_${HOST} -nobrowse
Note:
I can make use of variable substitution as long as it happens on the value (not the key) field of NIS maps themselves. In addition, it can't be used in included NIS maps. This last limitation is precisely what prevents me from taking advantage of the auto.master NIS map (which is referenced in the standard /etc/auto_master as simply +auto_master at the position where I inserted the ellipses).app-server-1:~# ypcat -k auto_data_app-server-1
area-4 file-server-1:/export/data/tank-4
area-3 file-server-1:/export/data/tank-3
area-2 file-server-1:/export/data/tank-2
area-1 file-server-1:/export/data/tank-1
In this example, areas area-1 through area-4 are to be on-demand mapped to app-server-1 under /data. Later, if any modifications are needed, it's just a matter of updating the corresponding (auto_data_app-server-1) NIS map. Given the normal automounter timeouts (for indirect NIS maps — direct ones require automounter restart), nothing else is necessary to get the updates reflected to app-server-1.
I'd like to show the corresponding NIS server side changes in order to support the new custom map. But at the same time, I'd like to show the include directive, which is a more manageable approach then simply ever adding stuff to /var/yp/Makefile to the point it can turn cumbersome or virtually unmanageable. As such, in /var/yp/Makefile just add the 2 following changes for each new custom NIS map:
# cat /var/yp/Makefile
...
all: passwd ageing group netid \
project netgroup aliases publickey \
hosts ipnodes ethers networks netmasks \
rpc services protocols \
auto.master auto.home \
auth.attr exec.attr prof.attr user.attr \
auto_data_app-server-1
...
include target.auto_data_app-server-1
...
The file now being included is as follows:
# cat /var/yp/target.auto_data_app-server-1
auto_data_app-server-1.time: $(DIR)/auto_data_app-server-1
-@if [ -f $(DIR)/auto_data_app-server-1 ]; then\
# Join any continuation lines.;\
(\
while read L;\
do;\
echo "$$L";\
done\
< $(DIR)/auto_data_app-server-1\
$(CHKPIPE)) |\
#;\
# Normalize the input to makedbm.;\
# Stripe-out comments,;\
# then delete blank lines.;\
(sed -e "s/[`echo '\t'` ]*#.*$$//" -e "/^ *$$/d"\
$(CHKPIPE)) |\
#;\
# Build the updated map.;\
$(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto_data_app-server-1;\
#;\
# Finishing house-keeping.;\
touch auto_data_app-server-1.time;\
echo "updated auto_data_app-server-1";\
#;\
# Push the updated map to slaves?;\
if [ ! $(NOPUSH) ]; then\
$(YPPUSH) auto_data_app-server-1;\
echo "pushed auto_data_app-server-1";\
fi\
else\
echo "couldn't find $(DIR)/auto_data_app-server-1";\
fi
auto_data_app-server-1: auto_data_app-server-1.time
But repeating all this stuff for every time is boring, inefficient and error-prone. A more intelligent approach is required. I can say I know the basics of the make utility but until know I haven't faced the need to go beyond. Well that's one of those moments. After a couple of days thinking over the problem I've been finally inspired to the following solution:
Instead of the aforementioned auto_data_app-server-1 include file, use the following alternative include file, call it target.template-1 if you will, which adds more 2 maps — not shown on the original all make target — just to illustrate the better scalability and manageability of the new approach:
BUILD_TEMPLATE_1 = -@if [ -f $(DIR)/$(CUSTOM_MAP) ];\
then\
(\
while read L;\
do\
echo "$$L";\
done\
< $(DIR)/$(CUSTOM_MAP)\
$(CHKPIPE)\
)\
|\
(\
sed -e "s/[`echo '\t'` ]*\#.*$$//" -e "/^ *$$/d"\
$(CHKPIPE)\
)\
|\
$(MAKEDBM) - $(YPDBDIR)/$(DOM)/$(CUSTOM_MAP);\
:;\
touch $(CUSTOM_MAP).time;\
echo "updated $(CUSTOM_MAP)";\
:;\
if [ ! $(NOPUSH) ];\
then\
$(YPPUSH) $(CUSTOM_MAP);\
echo "pushed $(CUSTOM_MAP)";\
fi\
else\
echo "couldn't find $(DIR)\$(CUSTOM_MAP)";\
fi
#---------------------------------------------------------
auto_data_app-server-1.time := CUSTOM_MAP = $(@:%.time=%)
auto_data_app-server-1.time : $(DIR)/auto_data_app-server-1
$(BUILD_TEMPLATE_1)
auto_data_app-server-1: auto_data_app-server-1.time
#---------------------------------------------------------
auto_data_group-1.time := CUSTOM_MAP = $(@:%.time=%)
auto_data_group-1.time : $(DIR)/auto_data_group-1
$(BUILD_TEMPLATE_1)
auto_data_group-1: auto_data_group-1.time
#---------------------------------------------------------
auto_data_group-2.time := CUSTOM_MAP = $(@:%.time=%)
auto_data_group-2.time : $(DIR)/auto_data_group-2
$(BUILD_TEMPLATE_1)
auto_data_group-2: auto_data_group-2.time
As seen, I make use of the following new knowledge:
- macros ( = );
- conditional macros ( := );
- pattern replacement macro reference ( : %=% ).
I also had to adjust what's passed to BUILD_TEMPLATE_1 taking into consideration that now I putting it all into a make macro.
Example 2:
Consider a slightly more complex variation of example 1, where multiple indirection is used to factor out commonalities. This greatly improves manageability and flexibility. Note that the reference in /etc/auto_master doesn't change, but the contents of the auto_data_${HOST} map, change as follows:
app-server-1:~# ypcat -k auto_data_app-server-1
group-2 -fstype=autofs,nobrowse auto_data_&
group-1 -fstype=autofs,nobrowse auto_data_&
And the 2 NIS maps being referenced with the aid of key substitution are as follows:
app-server-1:~# ypcat -k auto_data_group-1
area-2 -fstype=autofs,nobrowse file-server-1:/export/data/tank2
area-1 -fstype=autofs,nobrowse file-server-1:/export/data/tank1
app-server-1:~# ypcat -k auto_data_group-2
area-4 -fstype=autofs,nobrowse file-server-1:/export/data/tank4
area-3 -fstype=autofs,nobrowse file-server-1:/export/data/tank3
In this example, areas area-1 and area-2 were grouped into group-1 and areas area-3 and area-4 were grouped into group-2. In order to prevent spurious directories under /data (note that /etc/auto_master is the same from example 1), I had to explicitly declare group-1 and group-2 in auto_data_app-server-1 where I used key substitution to somewhat enhance manageability.
Example 3:
This example demonstrates the extremely flexible automounter's executable maps. Executable maps are local files that are run whenever indirect mounting requests take place. Perhaps its greatest advantage is precisely the freedom to dynamically correlate several pieces of information in building the mounting string. For instance, in can query and correlate multiple NIS maps. Whatever it performs it must be efficient. If the executable map happens to be a shell script, an obvious requirement is setting the execution bit. In addition it may be advisable to set the file mode to 0550. Furthermore, the expected behavior is to accept a lookup key as its $1 parameter and, case successful, to return the contents of a respective automounter map entry to standard output, otherwise nothing.
The local file that is run can be of any type as long it exhibits the expected aforementioned behavior. So, for instance, let me present a source code boilerplate for a binary implementation based on previous NIS programming examples:
#include <cstdlib>
#include <iostream>
#include <rpcsvc/ypclnt.h>
#include "pointer.hxx"
inline void std_c_free( void * p ) throw()
{
::free( p );
}
int main( int argc, char * argv[] )
{
// No input, treat as invalid key.
// No output to the standard output.
if ( argc != 2 )
::exit( YPERR_KEY );
// The lookup logic could be rather involved.
// It could:
// - Query systems
// - Query databases
// - Trigger special actions
//
// For better startup performance,
// a companion custom multi-threaded SMF service
// to which most tasks were to be delegated could help.
//
// Here, as an example, it's just a simple NIS lookup.
// Consider hard-coded values.
// Trade-offs: software engineering x performance.
int code;
char * domain;
if ( ( code = ::yp_get_default_domain( & domain ) ) == 0 )
{
char map[] = "auto_query_001";
char * key = argv[ 1 ];
char * value;
int length;
if
(
(
code = ::yp_match
(
domain,
map,
key,
::strlen( key ),
& value,
& length
)
)
== 0
)
{
// Lookup success.
// Send (including the \n) to the standard output.
pointer< char, std_c_free > p_value( value );
std::cout << p_value;
}
else
// Lookup error.
// No output to the standard output.
::exit( code );
}
else
// Lookup error.
// No output to the standard output.
::exit( code );
return EXIT_SUCCESS;
}
The simplest compilation line for the above code could be:
# CC -m64 -lsocket -lnsl \
-o auto_x_query_001 auto_x_query_001.cxx
In this particular example, the equivalent shell script could be as simple as:
# ll /etc/auto_x_query_001
-r-xr-x--- 1 root bin ... /etc/auto_x_query_001
# cat /etc/auto_x_query_001
#!/bin/sh -
/usr/bin/ypmatch "$1" auto_query_001
In general, the main advantage in adopting an indirect executable map is the possibility of adding a dynamic touch or override, thereby changing the otherwise deterministic value statically associated to the lookup key.
For instance, considering the following sample on overriding:
# ypcat -k auto_query_001
area-1 file-server-1:/export/data/tank-1
area-2 file-server-1:/export/data/tank-2
To enforce the nosuid mount option I could have:
# cat /etc/auto_x_query_001
#!/bin/sh -
/usr/bin/ypmatch "$1" auto_query_001 | 2> /dev/null \
/usr/bin/sed -e 's/.*/-nosuid &/'
The typical output of the previous script is:
# /etc/auto_x_query_001 area-1
-nosuid file-server-1:/export/data/tank-1
By referring to auto_x_query_001 instead of auto_query_001 in /etc/auto_master, all the respective mountings will get the nosuid mount flag enforced.
Example 4:
This sort of multi-example attempts to show the extra flexibility provided by combining variable substitution (built-in and custom) and hierarchical mounts.
For instance, let's define a custom variable for depicting the RD (for Research & Development) class a certain workstation.
Note: Save yourself from trouble by not using shell characters.
workstation-1:~# sharectl set -p environment=CLASS=RD autofs
workstation-1:~# sharectl get -p environment autofs
environment=CLASS=RD
Let's say we want to give each client equipment a specific view of /business.corp depending on to which class it belongs (as above described, by means of a custom variable called CLASS). Their /etc/auto_master could include something similar to:
# cat /etc/auto_master
...
/business.corp auto_business.corp -nobrowse
...
Let's say that the auto_business.corp and the auto_projects_RD custom NIS maps are somewhat as follows:
# ypcat -k auto_business.corp
...
projects -fstype=autofs,nobrowse auto_projects_${CLASS}
...
standards file-server-1:/export/standards
templates file-server-2:/export/templates
...
# ypcat -k auto_projects_RD
project_C file-server-4:/export/projects/rd/&
project_B file-server-5:/export/projects/rd/&
project_A file-server-6:/export/projects/rd/&
The following logical structure will result:
# tree -d /business.corp
/business.corp
├── projects
│ ├── project_A
│ ├── project_B
│ └── project_C
├── standards
└── templates
Solaris has the following built-in variables:
(examples are shown for Solaris 11.1 on a typical Intel microprocessor)
ARCH ≡ arch ≡ i86pc
KARCH ≡ arch -k / uname -m ≡ i86pc
CPU ≡ uname -p ≡ i386
HOST ≡ uname -n ≡ ...
OSNAME ≡ uname -s ≡ SunOS
OSREL ≡ uname -r ≡ 5.11
OSVERS ≡ uname -v ≡ 11.1
PLATFORM ≡ uname -i ≡ i86pc
NATISA ≡ isainfo -n ≡ amd64
