Sometimes, the performance is not important, what you have to remember is to use a system that you know well. You can also learn an other, but when a failure is becoming, you're faster to repair it.
Mathieu. Dusty Doris wrote: >> Despite this, I've seen that LDAP is not widely used. Is this for its >> complexity or are there deeper reasons that suggest to use SQL >> database for >> both (user data, accounting) purposes? Does anybody have links that >> might >> help to build a system made using this architecture? >> > > I use ldap for users and sql for accounting for the same reasons you > listed. Installing and using openldap has a much higher learning > curve than mysql, which is why I would guess more users use mysql. > > There is an old doc in the source under doc/ldap_howto.txt. I wrote > that several years ago and keep promising a new version. Well, I was > finally given a week at the end of this month or early next month to > stop all my projects and start documenting. So, at that time, I will > be re-writing that doc to be more current. > > I agree that ldap is a perfect place to store user objects. For > example, I have it setup like this. > > > ou=users > uid=someuser,ou=users... > radiusgroupname: dial > radiusgroupname: adsl > accountNumber: 11111 > > uid=anotheruser,ou=users... > radiusgroupname: adsl > accountNumber: 11111 > > ou=accounts > accountNumber=11111,ou=accounts... > radiusgroupname: wifi > > Using ldap, I can specify the services the user has access to as an > attribute of that user. I can also do account level groups as well. > In the users above, with my freeradius configuration, I can assure > that someuser has access to adsl and dial, while another user can only > login to adsl. Any user in the 11111 account can login to wifi, which > would be both of those users. > > Now, you can easily do the same thing in mysql as well. But, I feel > that ldap is a better model for this data. Also, with openldap it is > very easy to replicate and setup distribution of these users. Also, > since ldap is a standard protocol, my provisioning system can write to > it whether its from windows, solaris, linux, etc... It just needs to > understand the ldap protocol. Using mysql, means your provisioning > system must understand mysql syntax, although that isn't usually a > difficult task to get setup. Finally, as you said, ldap is optimized > for reads and that's exactly what I'm doing. I've never experienced > any issues with the ldap servers being overloaded. Then again I don't > get a whole lot of traffic maybe 60k-80k logins a day. > > The only downside I can think of with openldap is that it doesn't > support multi-master setups. There are workarounds I've heard of > people using with some kind of heartbeat setup and a shared IP, but I > don't have the need for a multi-master setup. > > As long as my master is replicating to my slaves and freeradius is > hitting my slaves, I can assure that no users are ever denied access > because of an ldap server going down. If the master goes down, the > only effect is on provisioning (such as adding new users or changing > passwords). In this case we take a slave server and manually upgrade > it to a master while we fix the master server. > > Freeradius with its configurable_failover solution, will allow us to > point to all of our slave servers and it takes care of any slave > servers going down automatically for us, without the need for a load > balancer. > > As an alternative for non-freeradius ldap queries, I've also setup two > ldap proxy servers that point back to my three slaves. The two proxy > servers share an IP, so one is always master (on the ip). If it goes > down, the slave takes over that IP. In that scenario, you can point > applications that don't do failover to the proxyldap shared IP and it > will take care of the failover for you. > > I really like ldap, but its taken me some time to become comfortable > with it. > > I hope that doc helps you with your setup, if you need more help, post > questions to the list. Be sure to explain what you are trying to do > and show debug info (radiusd -X) so we can see the difference between > what its doing and what you want it to do. > > Take care. > - List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html