tools/README

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