Tue Mar 11 19:55:37 PDT 2014
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.
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
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.
- 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.
- 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...
More information about the Users