Re: [RADIATOR] ServerTACACSPLUS logging improvements

[Hartmaier Alexander]

On 2016-06-24 13:57, Heikki Vatiainen wrote:
> On 24.06.2016 14:08, Hartmaier Alexander wrote:
>
>>> We also thought about further improvements for unexpectedly closed
>>> connections so that they can be logged and handled more easily. However,
>>> this is the first step before doing further changes.
>> We still get the 'Could not get peer name on TacacsplusConnection
>> socket: Transport endpoint is not connected' log message without
>> additional infos for which endpoint. Please don't add an additional
>> debugging message but improve the existing one!
> The error getpeername() sees is just that: the connection has gone away
> (while it was just established) so there's not much to improve this
> message anymore. The additional message I mentioned is available at
> trace 4 and it can stay because it's logged at the moment when the
> remote IP and port are first and surely available.
>
> However, maybe you could see what it shows on trace 4 now. The further
> changes in logging are planned to make unexpectedly closed connections
> logged so that are, for example, logged at INFO or WARNING level (trace
> 3 or 2). This should keep the log littering down, successfully opened
> connections are now logged unless debugging is enabled, while
> unexpectedly closed and unsuccessfully established connections are
> logged at higher log level.
>
> Maybe you could use trace 4 now to see where the shortlived client
> connections come from?

I've collected trace 4 logs:

Tue Jun 28 08:18:50 2016: DEBUG: ServerTACACSPLUS: New connection from
1.2.3.4:11422
Tue Jun 28 08:18:50 2016: ERR: Could not get peer name on
TacacsplusConnection socket: Transport endpoint is not connected
Tue Jun 28 08:18:50 2016: DEBUG: TacacsplusConnection disconnected from :

As you can see is the last message lacking the source infos although
I've applied the latest patchset.
Any idea why?
But the 'New connection' message should be enough to find the bad boys
which seem to be two Cisco IOS routers.
>
> Thanks for your comments,
> Heikki
>
Thanks, 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

Re: [RADIATOR] Is the Radiator NFV customizable?

[Tuure Vartiainen]

Hello,

> On 27 Jun 2016, at 10:34, Nadav Hod  wrote:
> 
> I have the impression that the VNF is much like an appliance, where the only 
> interface the user has with the VNF is the configuration file. I was hoping 
> the amazing Radiator team could clear up the following issues:
> 

yes, VNF is a kind of an software appliance which is meant to be configured 
through different interfaces.

> 1) Is the operating system (CentOS if I recall correctly) fully writeable so 
> that other applications can interface with Radiator (such as logrotate, rsync 
> etc.)?
> 

Yes. Radiator VNF is not restricted to using CentOS, but we are using CentOS as 
a base Linux distribution 
for Radiator VNF. Adaptation for Ubuntu/Debian will require some work but it is 
feasible.

> 2) Can patches (including security) be applied to the underlying OS? Does 
> this void warranty?
> 

Yes, patches can be applied and do not void warranty/support.

> 3) Are there any common use cases when it's best not to use Radiator as NFV?
> 

Radiator VNF is meant for AAA cases which require scaling for performance, 
either 
automatically or manually.

> 4) Does the VNF include all the common perl modules necessary for Radiator? 
> Can more be installed and updated?
> 

Yes. Modules can be updated and more modules can be installed.

> 5) What are the specs for the VNF? Is there any resource allocation necessary 
> from the hypervisor's side?
> 

Radiator VNF does not have any strict requirements. Currently we are running 
Radiator VNF on 
OpenStack, but it can also be adapted to run on a bare metal hardware or in 
VMware vCloud.

Default minimum HA setup of Radiator VNF consists of 11 virtual machines:

- 2 Radiator load balancers (RADIUS or Diameter)
- 2 Radiator AAA workers (number of workers scales according to load)
- 3 Database/message broker nodes
- 2 External database connector nodes (LDAP, SQL, RADIUS or Diameter)
- 2 Management nodes

With OpenStack, creating Radiator VNF stack is automated through its Heat 
orchestration.


BR
-- 
Tuure Vartiainen 

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