1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2017-03-30T16:51:24Z"
content="""
Using a remote for this seems problimatic, because the remote is not
pointing at a single well-defined data store, but instead whatever peers
happen to exist on the network.
For one, `copy --to=udp-multicast` would not try to send files that it thinks
are already located in that remote. I suppose this could be dealt with by
making the transfers always seem to fail, so it never thinks that the
multicast remote has any files.
But then, `copy --from=udp-multicast` would not try to receive files,
unless it thinks they're in that remote. And we just established it should
not think any files are in that remote. So that's a problem.
Also, the copy from/to would need to be operating on the same file at the
same time, which seems problimatic. If a receiving git-annex is a little
slower than the sender, or is operating on a slightly different set of
files, it would then miss a file being broadcast by the sender.
These issues seem to point to this needing to use some other, more
special-purpose commands for muticast.
----
It probably needs encryption, both for privacy and to ensure that files
are being received from the sender you intended, and not someone else
who might be broadcasting the contents of a different repository.
Here's how to set up encryption and authentication with uftp,
so that both client and server actually encrypt and check that they're
talking with a known entity. It took a while to figure out.
Client:
uftp_keymgt -g rsa:512 ~/client_key
# Parse the fingerprint value from its output; does not
# seem to be a better way, except perhaps using openssl to examine
# the key file. This is CLIENT_FINGERPRINT
# Pick a UID for the client. This is an 8-diget hex number,
# which needs to be unique across clients. Default is based on IP
# adddres, but for git-annex it could be derived from the git-annex
# UUID. This is CLIENT_UID.
Server:
uftp_keymgt -g rsa:512 ~/servant_key
# Parse the SERVER_FINGERPRINT from its output.
# Pick a SERVER_UID for the server.
Client:
# create a file "authlist" that contains "$SERVER_UID|$SERVER_FINGERPRINT"
uftpd -E -d -D/tmp/xx -k ~/client_key -U $CLIENT_UID -S '@authlist'
Server:
# create file "authlist" that contains "$CLIENT_UID|$CLIENT_FINGERPRINT"
# lines for each allowed client
uftp -c -Y aes256-cbc -h sha1 -k ~/server_key -U $SERVER_UID -H '@authlist' file_to_send
----
Notice that the client and server UID and key generation steps above
are the same. So, a command like `git annex multicast --gen-address`
could be run on both the server and clients, and could store
the addresses in the git-annex branch.
The uftp authlist file would be derived from all known such addresses.
(Unlike `p2p --gen-address`, where the address allows connecting with
and authentication with a remote over TOR, these multicast addresses
are safe to make public.)
The process of setting up a multicast classroom would then be:
1. Teacher runs `git annex multicast --gen-address; git annex sync`
2. Students each run `git annex multicast --gen-address; git annex sync`
3. Teacher runs `git annex sync` once all the students have generated addresses.
(Now the students all have received the teacher's address, and the teacher
has received all the student's addresses.)
4. Students each run `git annex multicast-receive`, which listens for
files going by and stores them.
5. Once the students are listening (*ahem*), teacher runs
`git annex multicast-send [file]` to distribute files.
"""]]
|
