WLANPI as a SYSLOG Server?

I recently had a requirement where as I had to troubleshoot a wireless issue, and it was either open terminal sessions to 50-60 APs and run a bunch of debug commands or deploy a single WLC command and send it to a syslog server.

Sounds like a no brainer deploy the single WLC command and send it to a syslog server. Well this is where it became hard, the client had no syslog server available, change control would take to long to install it onto one of their servers, and their SOE was locked down in such a way that we couldn’t use that. Added to this I had travelled to site, and my only laptop that I could use was required to be used for OTA captures in the investigation.

So I remembered that the WLANPI was in my bag and it’s after all running linux, the only question i really had is how well will this hold up if I throw some load on it. Firstly i’ll take you through the steps I undertook on how to get it installed and working and then i’ll tell you what I found. I will pretext this with I am no Linux expert and there maybe better ways of doing this – I would love to hear of these.

So the First step is really simple SSH onto the WLANPI

_   _                   ____  _   _   _              ____ 
| \ | | __ _ _ __   ___ |  _ \(_) | \ | | ___  ___   |___ \
|  \| |/ _` | ‘_ \ / _ \| |_) | | |  \| |/ _ \/ _ \    __) |
| |\  | (_| | | | | (_) |  __/| | | |\  |  __/ (_) |  / __/
|_| \_|\__,_|_| |_|\___/|_|   |_| |_| \_|\___|\___/  |_____|
Welcome to ARMBIAN 5.67.181127 nightly Debian GNU/Linux 9 (stretch) 4.14.83-sunxi64
System load:   0.28 0.25 0.11   Up time:       3 min
Memory usage:  20 % of 482MB   IP:            x.x.x.x
CPU temp:      25°C
Usage of /:    15% of 15G 
[ 0 security updates available, 105 updates total: apt upgrade ]
Last check: 2019-11-14 12:12
Last login: Thu Nov 14 12:14:13 2019 from x.x.x.x
wlanpi@wlanpi:~$

Now we need to install syslog-ng. This is done via the apt-get install process. I did find I had to use sudo to run this.

wlanpi@wlanpi:~$ sudo apt-get install syslog-ng
[sudo] password for wlanpi:
Reading package lists… Done
Building dependency tree

 

We now have to edit the syslog-ng.conf file to setup the syslog server for collecting network syslog date. This is done using VI or Nano (your choice – I used VI)

wlanpi@wlanpi:~$ sudo vi /etc/syslog-ng/syslog-ng.conf

 

Need to insert the red colour lines into the file. In VI press esc and then i to insert and type them in. Press esc to exit out and when completed press esc :wq!

@version: 3.8
@include “scl.conf”
# Syslog-ng configuration file, compatible with default Debian syslogd
# installation.
# First, set some global options.
options { chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
  owner(“root”); group(“adm”); perm(0640); stats_freq(0);
  bad_hostname(“^gconfd$”);
};
########################
# Sources
########################
# This is the default behavior of sysklogd package
# Logs may come from unix stream, but not from another machine.
#
source s_src {
       system();
       internal();
};
source s_network {
       udp(ip(0.0.0.0) port(514));
       tcp(ip(0.0.0.0) port(514));
};
# If you wish to get logs from remote machine you should uncomment
# this and comment the above source line.
#
#source s_net { tcp(ip(127.0.0.1) port(1000)); };
########################
# Destinations
########################
# First some standard logfile
#
destination d_auth { file(“/var/log/auth.log”); };
destination d_cron { file(“/var/log/cron.log”); };
destination d_daemon { file(“/var/log/daemon.log”); };
destination d_kern { file(“/var/log/kern.log”); };
destination d_lpr { file(“/var/log/lpr.log”); };
destination d_mail { file(“/var/log/mail.log”); };
destination d_syslog { file(“/var/log/syslog”); };
destination d_user { file(“/var/log/user.log”); };
destination d_uucp { file(“/var/log/uucp.log”); };
# This files are the log come from the mail subsystem.
#
destination d_mailinfo { file(“/var/log/mail.info”); };
destination d_mailwarn { file(“/var/log/mail.warn”); };
destination d_mailerr { file(“/var/log/mail.err”); };
# Logging for INN news system
#
destination d_newscrit { file(“/var/log/news/news.crit”); };
destination d_newserr { file(“/var/log/news/news.err”); };
destination d_newsnotice { file(“/var/log/news/news.notice”); };
# Some ‘catch-all’ logfiles.
#
destination d_debug { file(“/var/log/debug”); };
destination d_error { file(“/var/log/error”); };
destination d_messages { file(“/var/log/messages”); };
# The root’s console.
#
destination d_console { usertty(“root”); };
# Virtual console.
#
destination d_console_all { file(`tty10`); };
# The named pipe /dev/xconsole is for the nsole’ utility.  To use it,
# you must invoke nsole’ with the -file’ option:
#
#    $ xconsole -file /dev/xconsole […]
#
destination d_xconsole { pipe(“/dev/xconsole”); };
# Send the messages to an other host
#
#destination d_net { tcp(“127.0.0.1” port(1000) log_fifo_size(1000)); };
# Debian only
destination d_ppp { file(“/var/log/ppp.log”); };
destination d_network {file(“/media/usb-drive/network.log”); };
########################
# Filters
########################
# Here’s come the filter options. With this rules, we can set which
# message go where.
filter f_dbg { level(debug); };
filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_err { level(err); };
filter f_crit { level(crit .. emerg); };
filter f_debug { level(debug) and not facility(auth, authpriv, news, mail); };
filter f_error { level(err .. emerg) ; };
filter f_messages { level(info,notice,warn) and
                    not facility(auth,authpriv,cron,daemon,mail,news); };
filter f_auth { facility(auth, authpriv) and not filter(f_debug); };
filter f_cron { facility(cron) and not filter(f_debug); };
filter f_daemon { facility(daemon) and not filter(f_debug); };
filter f_kern { facility(kern) and not filter(f_debug); };
filter f_lpr { facility(lpr) and not filter(f_debug); };
filter f_local { facility(local0, local1, local3, local4, local5,
                        local6, local7) and not filter(f_debug); };
filter f_mail { facility(mail) and not filter(f_debug); };
filter f_news { facility(news) and not filter(f_debug); };
filter f_syslog3 { not facility(auth, authpriv, mail) and not filter(f_debug); };
filter f_user { facility(user) and not filter(f_debug); };
filter f_uucp { facility(uucp) and not filter(f_debug); };
filter f_cnews { level(notice, err, crit) and facility(news); };
filter f_cother { level(debug, info, notice, warn) or facility(daemon, mail); };
filter f_ppp { facility(local2) and not filter(f_debug); };
filter f_console { level(warn .. emerg); };
filter f_network { netmask(“10.0.0.0/255.255.255.0”); };
########################
# Log paths
########################
log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_src); filter(f_cron); destination(d_cron); };
log { source(s_src); filter(f_daemon); destination(d_daemon); };
log { source(s_src); filter(f_kern); destination(d_kern); };
log { source(s_src); filter(f_lpr); destination(d_lpr); };
log { source(s_src); filter(f_syslog3); destination(d_syslog); };
log { source(s_src); filter(f_user); destination(d_user); };
log { source(s_src); filter(f_uucp); destination(d_uucp); };
log { source(s_src); filter(f_mail); destination(d_mail); };
#log { source(s_src); filter(f_mail); filter(f_info); destination(d_mailinfo); };
#log { source(s_src); filter(f_mail); filter(f_warn); destination(d_mailwarn); };
#log { source(s_src); filter(f_mail); filter(f_err); destination(d_mailerr); };
log { source(s_src); filter(f_news); filter(f_crit); destination(d_newscrit); };
log { source(s_src); filter(f_news); filter(f_err); destination(d_newserr); };
log { source(s_src); filter(f_news); filter(f_notice); destination(d_newsnotice); };
#log { source(s_src); filter(f_cnews); destination(d_console_all); };
#log { source(s_src); filter(f_cother); destination(d_console_all); };
#log { source(s_src); filter(f_ppp); destination(d_ppp); };
log { source(s_src); filter(f_debug); destination(d_debug); };
log { source(s_src); filter(f_error); destination(d_error); };
log { source(s_src); filter(f_messages); destination(d_messages); };
log { source(s_src); filter(f_console); destination(d_console_all);
    destination(d_xconsole); };
log { source(s_src); filter(f_crit); destination(d_console); };
log { source(s_network); destination(d_network); };
# All messages send to a remote site
#
#log { source(s_src); destination(d_net); };
###
# Include all config files in /etc/syslog-ng/conf.d/
###
@include “/etc/syslog-ng/conf.d/*.conf”

 

Once the conf file has been edited we need to reload the syslog-ng service using systemctl  reload using sudo:

After the reload we check the service is working

wlanpi@wlanpi:~$ sudo systemctl reload syslog-ng.service
wlanpi@wlanpi:~$ sudo systemctl status syslog-ng.service
 syslog-ng.service – System Logger Daemon
   Loaded: loaded (/lib/systemd/system/syslog-ng.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-11-12 05:43:48 AEDT; 2 days ago
     Docs: man:syslog-ng(8)
  Process: 4738 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 619 (syslog-ng)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/syslog-ng.service
           └─619 /usr/sbin/syslog-ng -F
Nov 12 05:43:47 wlanpi systemd[1]: Starting System Logger Daemon…
Nov 12 05:43:48 wlanpi syslog-ng[619]: [2019-11-12T05:43:48.274701] WARNING: Default value changed for the prefix() option of systemd-journal s
Nov 12 05:43:48 wlanpi systemd[1]: Started System Logger Daemon.
Nov 14 12:21:12 wlanpi systemd[1]: Reloading System Logger Daemon.
Nov 14 12:21:12 wlanpi systemd[1]: Reloaded System Logger Daemon.

 

We then need to create the file to send the data to, easiest way is to VI the file name in the directory you specified and just :wq! it.

wlanpi@wlanpi:~$ cd /media/usb-drive/
wlanpi@wlanpi:/media/usb-drive$ vi network.log

 

We now have the file, to view the incoming data use tail -f and the file name

wlanpi@wlanpi:/media/usb-drive$ ls
network.log
wlanpi@wlanpi:/media/usb-drive$ tail -f network.log

 

So I wouldn’t recommend using the WLANPI as a production syslog server, but it works in a situation where you need one and have no other option.

I managed to have 100 APs running debug for 3 clients going and about 2 hours of debug logs coming through and it took up about 100mb of storage. I was also storing it on an attached USB drive. The WLANPI stood up to this and didn’t crash, it was quite warm at the end of it, but probably no more than any other task I have used it for.

Hopefully this has given you another use case for the very useful WLANPI.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s