Setup remote syslog

This document aims to go through the steps necessary to configure the Sangoma SBC to configure the Syslog function to push basic SBC SIP and call routing present syslog be used with a Virgin SIP Trunking Service

This guide is appropriate for all Sangoma SBCs including all hardware, hybrid, VM and MSBG types

Notice: To complete this procedure the SBC service to be stopped and restarted in order for the changes to take effect, for systems that are in deployments live serving customers we recommend performing the stop and start actions during a schedule maintenance period.

This guide expects the Sangoma SBC SIP setup to be complete and does not cover any directly SIP related config 

The guide will create 1 and modify 3 files present within the SBC file system. The file management tool that will be used through this guide is VI, this is a standard tool and the guide will not present step by step instructions for edits performed within VI

Open

To help make this example guide more complete we will use some example network configuration:

The default gateway IP for LAN – 192.168.5.1

The SBC LAN IP address - 192.168.5.205

The Syslog server LAN IP address - 192.168.5.229*

*This can be a public IP address, but the SBC must have IP routing (via default GW or static routes) so that the traffic can flow to the public IP address

STEP 1: Log into the Sangoma SBC using the WebUI interface.

The default user is root and password is sangoma.

Open

STEP 2: Once logged in, the Control Panel will be displayed by the SBC WebUI

• Confirm that SBC is healthy and that activity is not high.

• The modification of the files requires little SBC system resources and therefore can be performed at almost anytime

• However if the SBC is operating in a live system with heavy traffic we recommend performing the editing operations during times of low activity.
  
  

STEP 3: Login to the SBC CLI – this will require a terminal program that connect over SSH – Putty is a very common example of this type of program.

The default user is root and password is sangoma, this is the same as the WebUI user and password.

STEP 4: Create a new file

An example method of creating a file at the required location within the SBC is given by the command below:

touch /usr/local/nsc/conf/autoload_configs/modules_custom.xml

Open the new file for editing, the example command uses vi to open the new file:

vi /usr/local/nsc/conf/autoload_configs/modules_custom.xml

Enter the following text to the new file:

1 <?xml version="1.0" encoding="UTF-8"?>
2
3 <include>
4          <load module="mod_syslog.so"/>
5 </include>

Example Screen shot from vi:

STEP 5: The next step is to modify the existing SBC syslog file, which by default will not send all the logging to syslog at the required level.

To access the SBC software config file:

vi /usr/local/nsc/conf/autoload_configs/syslog.conf.xml

NOTE: A very important config given below is the loglevel parameter this will define the level of tracing pushed by the SBC to the syslog server.

If you wish to have call level tracing (including SIP tracing) then the option to choose should be debug

If only basic informational logging then required log level could be info

The syslog conf file will already include text, I recommend entering the following information to the config file:

<param name="facility" value="local6"/>

<param name="ident" value="nsc"/>

<param name="loglevel" value="debug"/>

<param name="uuid" value="true"/>

An example screen shot of the modified contents of the syslog.conf.xml file, in this example the loglevel set is debug:

STEP 6: To configure the syslog utility, this is the Linux standard syslog utility rsyslog, to begin to modify this file enter the CLI command below:

vi /etc/rsyslog.d/nsc.conf

The Syslog config follows standard Rsyslog config rules, as such a standard addition to push to a syslog server there are three main components

Syslog logger entity . user level          @host or /path/to/file

Syslog logger entity – there are many applications that can output logging to syslog, this config the filtering of specific entities or all logging. In the previous step an entry defined the facility value = local6 this is the syslog for all "NetBorder Session Controller" service output and will have syslog tag as `nsc`.

user level – in this case the ’ * ‘defines every logger entity

@host - This config component defines the destination of the syslog output, a file path will define the output to a file while @ followed by a host name or IP address will define a syslog listening server as the destination.

Enter the following text:

local6.*                       @host

The bottom of the screen shot shows the addition of the config to the existing rsyslog config file: /etc/rsyslog.d/nsc.conf

STEP 7: Disable flooding of nsc syslog into /var/log/message editing the file: rsyslog.conf

vi /etc/rsyslog.conf

Update the line 42 by appending ;local6.none

*.info;mail.none;authpriv.none;cron.none;local4.none                       /var/log/messages

as

*.info;mail.none;authpriv.none;cron.none;local4.none;local6.none    /var/log/messages

STEP 8: Stop SBC and rsyslog services then restart

To this point the changes made to the SBC configuration will not change the running configuration of the SBC, in order to update the running config with the changes

restart nsc and rsyslog services

service nsc restart

service rsyslog restart

After completing the above the SBC should be sending syslog messages to the service at the host or ip that was configured in step 6.

Extras

Stopping Syslog

As the configuration is not webUI driven it is not possible to stop syslog by the SBC UI Control Panel, to do this will require a CLI console command.

Use the service command to stop the syslog service, example command:

service rsyslog stop

To restart syslog

service rsyslog start

Using this command should be reliable but given the nature of the feature not being fully implemented caution should always be exercised when performing service actions