DragonFly users List (threaded) for 2009-02
mirror-stream over ssh w/o 'root' privs
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.
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...