[RADIATOR] New features and changes in the next Radiator release

[Hartmaier Alexander]

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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*