Hi,
for the policy/rules to be 'simpler' I think we need to have the following in place
clients.conf
- a proper construct for moonshot clients defined like eg
client blah.blah {
ipaddr = 192.168.0.1
shortname = SERVICENAME
virtual_server = moonshot
}
(obviously this would be a RADSEC client if doing things right - but this is just a quick'n'dirty(tm) example
to get the ball rolling)
sites-enabled/moonshot
a symlink to sites-available/moonshot (as per others!)
sites-available/moonshot
a modified 'default' VS with all the things that just arent applicable to moonshot
completely removed - eg CHAP/accounting(?) etc and calling a new inner-tunnel
sites-enabled/moonshot-inner-tunnel
a symlink to sites-available/moonshot-inner-tunnel (as per others!)
sites-available/moonshot-inner-tunnel
a modified version of inner-tunnel (once again, all stuff not required is removed)
this will call a new EAP module
mods-enabled/moonshot-eap
a symlink to mods-available/moonshot-eap
mods-available/moonshot-eap
a modified 'eap' instance which removes anything not required by moonshot (and sets the default
type to TTLS - a-ha!, yes!)
within these 3 new config files moonshot policies can be defined.
the is the BCP method that I would deploy eduroam config to a site (pretty much not touching ANY of
the standard files) and means that we have a very clear idea of what files need to be edited and have
control of vertical/horizontal for policies/rules etc in a moonshot client/path - this ALSO means
all of these ca be dropped onto a working 3.x eduroam/RADIUS install and it will work and not modify
their eduroam/RADIUS packets
alan
|