<div class="gmail_quote">On Wed, Nov 14, 2012 at 9:14 AM, Arran Cudbard-Bell <span dir="ltr"><<a href="mailto:a.cudbardb@freeradius.org" target="_blank">a.cudbardb@freeradius.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 13 Nov 2012, at 20:02, Peter Lambrechtsen <<a href="mailto:peter@crypt.co.nz">peter@crypt.co.nz</a>> wrote:<br>
> the ldap.attrmap is also quite useful externalised as a separate file rather than being part of the specific LDAP module configuration.  In our case we run multiple instances of the LDAP Module depending on the path you took to get to the FreeRadius instance.  Some of these paths have the same LDAP -> VSA Attribute mapping but have different LDAP Servers and Base DN/Filters we search on, others have slightly different ones.  So we reference the same ldap.attrmap against different module instances.<br>

> Not a biggie either way as we would just duplicate the mapping across the different instances, but I can see the rationale from having everything inside the single module configuration file.<br>
<br>
</div>The current mappings file doesn't follow any of the conventions of the server, it uses outdated list names and its confusing for new users. It makes much more sense to use one of the schemes previously discussed in another thread, and if you want to use the same mappings with multiple files, then you can move them to an external file and $INCLUDE that.<br>
</blockquote><div><br>Great.  I should have thought about an external $INCLUDE file and yes it does make a whole lot more sense to follow the standard mapping schemes used in other modules rather than having a whacky standalone mapping scheme just for LDAP. Carry on and forget I even mentioned it :)<br>
</div></div>