(2013-01-15, 00:19)wimble Wrote: And, off the top of my head, I'm not sure how to tell whether they're in use!
It's tricky, particularly finding a solution that works for all distributions.
"netstat -an | grep <ip address>" will determine if the client/slave has an active NFS connection to the NFS server. However, idle NFS mounts will be closed periodically so they won't always appear in netstat which could lead to false positives (or negatives, depending on how you want to interpret the results). Maybe there is a way to maintain a persistent NFS connection?
Alternatively, with OpenELEC, you have the autostart.sh script which could create a flag file to /storage to indicate the client is now "up", but unfortunately there is no corresponding "autostop.sh" to remove any such flag file when the client is shutdown... There's probably a way to create/delete the flag file in Raspbmc.
As a last resort, and perhaps actually the most reliable "server-side" method, you could just "ping" the various clients from the NFS server on a frequent basis, however this assumes your clients have static IP addresses (or their hostnames are unique and resolvable on your network). When they don't respond to a ping, you can assume they are down and sync their folder with that of "master".
(2013-01-15, 00:19)wimble Wrote: A possibility would be to symlink the master directory into the subordinates. So they've got both .xbmc directories and .xbmc-master. And then put Code:
[ `hostname` != 'master' ] && rm -fr .xbmc; cp -r .xbmc-master .xbmc
into the boot sequence (substitute the hostname of your master for the word "master").
Rather than use cp, you'd be better off with rsync, as this will be a much quicker.
Since not all XBMC distributions support rsync, the best solution would be to have the client/slave ssh into the NFS server during boot (authenticating with keys, so no password is required) and have the slave instruct the server to kick off the rsync process so that it runs entirely on the server.
Adding the following commands to autostart.sh for OpenELEC would do the job quite nicely, identifying each slave by its unique MAC address and then requesting the NFS server to sync master to the slave folder.
Using rsync the update would be pretty quick with next to no network traffic - running cp on the Pi would cause the entire "master" folder to be read by the Pi, and then written out again to the slave folder (so twice the network overhead, which will be considerable, potentially taking several minutes over the Pi's 100Mbit network!).
The same script should work for Raspbmc, however I'm not sure what the standard practice is for running jobs at boot (probably initd?)
*** NOTE: Use the following script with caution, as it can delete files... ***
Code:
#!/bin/sh
NFS_SERVER=root@freenas2
NFS_SHARE=/mnt/share/OpenELEC
HOME_PATH=Storage
XBMC_MASTER=rpi_master
THIS_SLAVE=rpi_slave
case $(ifconfig eth0 | grep -i 'hwaddr' | awk '{ print $5 }' | tr '[A-Z]' '[a-z]') in
b8:27:eb:1e:df:b4) THIS_SLAVE=${THIS_SLAVE}1;;
b8:27:eb:1e:ee:cc) THIS_SLAVE=${THIS_SLAVE}2;;
b8:27:eb:3d:21:94) THIS_SLAVE=${THIS_SLAVE}3;;
*) echo "Unknown XBMC slave - halting!";
sleep 99999999;;
esac
ssh ${NFS_SERVER} "cd ${NFS_SHARE}; rsync -tprogl --delete ${XBMC_MASTER}/${XBMC_PATH}/.xbmc ${THIS_SLAVE}/${XBMC_PATH}; sync"
(Modify lines 3 through 7 to suit your own requirements). For Raspbmc, HOME_PATH should be set to "home/pi".
The script will sync just the .xbmc sub-folder of rpi_master to each slave (eg. rpi_slave1, rpi_slave2, rpi_slave3 etc.). The NFS server is called freenas2, and it is exporting /mnt/share/OpenELEC (within which are the folders rpi_master, rpi_slave1, rpi_slave2 etc.). Potentially this NFS information could be extracted from the kernel command line.
If it were possible for the server to reliably detect when the client is down, the server could simply kick off the rsync process itself for each "downed" client, though this still leaves a window (between runs of the update script) when a client is started and may not be in perfect sync with the master, in which case initiating the sync during boot is probably best (and actually the simplest) solution.