From daf4ee8837407d6e1194eab86caf47a9bf9faa34 Mon Sep 17 00:00:00 2001 From: Linus Nordberg Date: Fri, 28 May 2010 15:32:31 +0200 Subject: Create tools/ directory and move shell scripts there. --- tools/README | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 tools/README (limited to 'tools/README') diff --git a/tools/README b/tools/README new file mode 100644 index 0000000..4e6d2bc --- /dev/null +++ b/tools/README @@ -0,0 +1,48 @@ +Mail[1] to the radsecproxy mailing list Wed, 14 Apr 2010 from Stefan +Winter explaining the radsec-dynsrv.sh and naptr-eduroam.sh scripts. + +------------------------------------------------------------ +Hi, + +the radsec-dynsrv.sh script right now looks up _radsec._tcp.$REALM. For +eduroam, the production discovery will rely on S-NAPTRs of "s" type and +subsequent SRVs. + +I have attached a preliminary version of the discovery script which +takes this logic into account. It could use some public scrutiny (where +"public" might very well evaluate to Kolbjørn Barmen, who wrote the SRV +script and knows much more about bash scripting than I do *cough cough*). + +As with the other script, you call + +naptr-eduroam.sh + +If you need a test case, the DNS domain restena.lu has the NAPTR and the +SRV record live in place. On my system, you get: + +> ./naptr-eduroam.sh restena.lu +server dynamic_radsec.restena.lu { +host radius-1.restena.lu:2083 +type TLS +} + +with our live DNS data (radius-1.restena.lu isn't really +production-ready yet though). + +If you're curious, the S-NAPTR for eduroam right now is + +x-eduroam:radius.tls + +with a possibility of a later IETF allocation of either + +aaa:radius.tls (probable) +eduroam:radius.tls (wishful thinking) + +, in which case changing the script to use the new ones is trivial. + +Greetings, + +Stefan Winter +------------------------------------------------------------ + +[1] https://postlister.uninett.no/sympa/arc/radsecproxy/2010-04/msg00011.html -- cgit v1.1