View source for NFS - Automate attaching / detaching of shares

==Prerequisites and what this article is NOT about==
The Prerequisites to understand and handle this article are:
* ''Administrative'' privileges to the system
* Profound knowledge of 
** ''user administration'', 
** ''bash editing'', 
** ''nfs'' administration

This article does not cover the ''nfs'' administration of a linux/unix system.

The solution shown here is in principle scalable to any system. But specially the way nfs clients are handled here is only a quick hack, not threaded and therefore only useful for small networks with about a couple of PCs. Further development is possible.

This solution requires a new unpriviledged user, that is in the ''sudoers'' list allowed to do the ''mount'' and ''unmount'' command. Additionally it requires the instantiation of ''passwordless ssh connections'' between the machines for this user.

For some systems, this might be an security whole.

==The problem: add or removing shares==

Mainly the intention of this HowTo was the problem, that in case you are removing an exported - and mounted - nfs file system from a network this will have severe side effects:
* All applications depending on the file system will fail/hang
* The ''Desktop Manager'' which will be left in an unusable state for minutes
* Drives will not be ''synced'', data loss can occur

==The solution: Publisher/Subscriber Pattern==
If a nfs exported filesystem is removed from the ''nfs server'', it must also be removed on all computers that are connected to the ''nfs server''. This machine therefore has to have a list of these computers. In the view of the ''publisher/subscriber'' pattern it is the publisher.

The ''nfs clients'' are the ''subscribers''. That's the way ''nfs'' is used. They provide the mechanisms to add or remove files from the server. 

Therefore they must connect to the server - and that's the problem of most of the current nfs client implementations: Mostly, they connect in certain time intervals to the ''nfs servers'' in the network. The publisher pattern however wants the subscribers (clients) to be reported ''immediately'', when the system state changed, e.g. a drive is unmounted.

==All informations in the ''/etc/exports''==

The one and only file on the nfs server to handle
* nfs shares
* possibly connected clients
is the ''/etc/exports''.

===Shares===
It is easy to extract all exported shares of the nfs server with a little bash and awk charm and store it in a bash variable called ''EXPORTS''
 EXPORTS=`cat /etc/exports | grep -v ^# | grep " " | cut -f 1 | awk '{system("echo -n " $1 "----")}' | sed s/----/"  "/g`

It filters out all commentary lines, all empty lines, and writes them - devided by spaces - in the string.

===Clients===
It could be possible, to extract these information for each share of this file with a little bash magic. Feel free to do this. It also might be possible to write all this in perl ;) Drop me a mail, if you made something new.

In this solution I quickly source the variables of each nfs server in a configuration file, called ''nfs_clientlist.sh'':

 ############################################################
 ### PLEASE EDIT ############################################
 ############################################################
 
 # All CLIENTLIST that use the nfs server on this machine
 CLIENTLIST=" server_giga ibmr31 ibmr31_w "
 
 # The hostname of this machine.
 # Might be different with more than on network card.
 #THISHOST=$HOSTNAME
 THISHOST=printer_giga
 
 ############################################################

==Trigger the remotely mount/unmount of shares==
For the ''nfs servers'' machine to be able trigger the ''mount/unmount'' on connected clients there might be two way's:
* Writing a client/server program that communicates on a special port.
* Issuing a bash ''mount/umount'' via ssh on the remote machine

The first approach might be possible in e.g. perl/pyhton, but for my purposes connection/reconnecting