Create tools/ directory and move shell scripts there.

[radsecproxy.git] / tools / README

diff --git a/tools/README b/tools/README
new file mode 100644 (file)
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 <realm>
+
+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