On 2015-06-19 09:16, Heikki Vatiainen wrote: > 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? Yes, sadly. > > 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? We use a Perl daemon based on Message::Passing to read from a special fifo file generated with mkfifo and enqueue the log messages in RabbitMQ from where they are stored in Elasticsearch by another damon on the central log servers.
> > 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. That would be a great improvement over the current blocking nature of Radiator which would allow to scale it with multiple cores much better! I can recommend POE which we use in our inhouse NMS since over ten years without an issue. > > Thanks, > Heikki > Best regards, Alex *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
