mirror-stream over ssh w/o 'root' privs

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Solved: (For now .. 'BFBI' method)

- the permissions problem that seemed to require enabling 'root' login 
on the target.

CAVEAT_1: At the present state, this will most likely create new PFS 
directly under '/' (presuming all else is already PFS-mounted).

CAVEAT_2: Security still not optimal. Hopefully a better way can be 
found, but this works 'for further tests'.

Givens:

1) an appropriate hammerfs 'master' on a source server, per man (5) hammer.

2) The modification I posted earlier to fake a 'yes' to creating target 
slave pfs with compatible shared_uuid where none previously exists. The 
new hammer binary so compiled should exist on both source and target.

On (at least) the target server:

Create a bespoke group, and make 'root' a member of that group.

Create a bespoke 'special user', member of that group, AND NO OTHER group.

chown root:<bespoke group> /sbin/hammer

chmod 6664 /sbin/hammer

From the source, do an initial ssh <special user>@<target>.<tld>
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