No subject

to load the keys and insure access is, in fact, available.
NB: I'm using raw IP for this..

Once looged-in on the target, try 'hammer' (no cmd tail) to get the 
helplist, ELSE 'access denied.'

If not set up correctly. 'REWIND' until that part works.

Log out.

On the source, login as the <special user> and execute:

hammer mirror-copy </master> <special user>@<target>.<tld>:/<slave name>

- Which should return success and a shared_uuid that matches that of 
/master.

Then:

hammer mirror-stream </master> <special user>@<target>.<tld>:/<slave name>

Unless you have 'detach installed and use it, switch to another vtty.

Either way, verify with 'top' or ps waux or tcpdump that it is running.

Arrange to see the target and the <slave name> directory.

Create, edit, add, delete, otherwise make changes to files in /master.

Confirm that /<slave name> reflects those changes within the default 
5-seconds (max) delay.

RECOMMENDED:

- Use of a roll-cable, or internal LAN and non-routable IP where 
possible, ELSE an in-place VPN tunnel.

- 'The usual' restrictions by IP, protocol rev, matching pem certs, etc. 
as one would apply to nfs, smbfs exports, et al.

FUTURES:

- Is it time to start thinking of filing an RFC to assign a bespoke port 
for 'hammer clustering protocol'?

- If ssh and ordinary TCP are to be used, AND NOT something more 
efficient, (see Plan9), then I, for one, will be wanting to have it take 
advantage of the VIA Padlock engine, which lets an otherwise lowly 
chipset punch well above its weight, at least with AES.

Improvements expected.... none of this is original, and I am pleased to 
be shown a better way..

Will run load tests after getting some sleep...

Bill Hacker