DragonFly users List (threaded) for 2009-02
DragonFly BSD
DragonFly users List (threaded) for 2009-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Mon, 23 Feb 2009 05:51:06 +0800

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'.


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.


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...

Bill Hacker

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]