On 06/18/2015 01:01 PM, Hartmaier Alexander wrote: > Especially the work on sharing state between instances, we had problems > with tacacs sessions from Cisco WLCs that authorize on a different > server than the authentication happened which lead to non-working user > rights.
Thanks for your comments. Does WLC do this when it has been configured with multiple TACACS+ servers? That is, it does not try to use the same server for all requests that belong to the user's session even if that server is responding? I'll make a note that this is one case where state sharing would be needed for TACACS+. > Regarding logging I'd love to see support for noSQL databases and > messages queues like RabbitMQ and Elasticsearch which can be used as log > target. I would be interested to hear your and others' views about how to work with different noSQL DBs and how they should be used with Radiator. For example, there has been interest in Apache Cassandra for AuthBy CQL, AuthLog CQL, session database etc. With SQL we can use DBI to cover all the SQL databases. With noSQL it seems each noSQL server needs its own interface. Or in other words, if support for them is done one by one, which noSQL servers should be supported first? For example MongoDB has good Perl support and is widely used, but CQL seems to be a good, maybe better, match for this type of application. Amazon Dynamo DB is, of course, restricted to AWS (and has been used by us in one custom setup). What comes to Elasticsearch, would using Logstash to read the files while they are generated do the trick, at least for now? About message queues, are you thinking about RabbitMQ, or the other MQs, for logging only? I mentioned control plane in my previous message, but we are also thinking about data plane to have something to distribute requests between different instances. Pushing logs in a MQ could also be done too. Using both control and data plane is interesting because it allows for more automatic and easier set up of multiple instances as opposed to creating configuration files manually. A queue can be monitored to see if the instances are starting to have problems processing all the requests. If this happens, the queue management can log the problem or start additional instances. Other useful features include log routing, as you mentioned, maybe as a control plane service too. Thanks, Heikki -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator