README
1Mail[1] to the radsecproxy mailing list Wed, 14 Apr 2010 from Stefan
2Winter explaining the radsec-dynsrv.sh and naptr-eduroam.sh scripts.
3
4------------------------------------------------------------
5Hi,
6
7the radsec-dynsrv.sh script right now looks up _radsec._tcp.$REALM. For
8eduroam, the production discovery will rely on S-NAPTRs of "s" type and
9subsequent SRVs.
10
11I have attached a preliminary version of the discovery script which
12takes this logic into account. It could use some public scrutiny (where
13"public" might very well evaluate to Kolbjørn Barmen, who wrote the SRV
14script and knows much more about bash scripting than I do *cough cough*).
15
16As with the other script, you call
17
18naptr-eduroam.sh <realm>
19
20If you need a test case, the DNS domain restena.lu has the NAPTR and the
21SRV record live in place. On my system, you get:
22
23> ./naptr-eduroam.sh restena.lu
24server dynamic_radsec.restena.lu {
25host radius-1.restena.lu:2083
26type TLS
27}
28
29with our live DNS data (radius-1.restena.lu isn't really
30production-ready yet though).
31
32If you're curious, the S-NAPTR for eduroam right now is
33
34x-eduroam:radius.tls
35
36with a possibility of a later IETF allocation of either
37
38aaa:radius.tls (probable)
39eduroam:radius.tls (wishful thinking)
40
41, in which case changing the script to use the new ones is trivial.
42
43Greetings,
44
45Stefan Winter
46------------------------------------------------------------
47
48[1] https://postlister.uninett.no/sympa/arc/radsecproxy/2010-04/msg00011.html
49