Syslog not logging events though the server is receiving syslog packets

Recent issue with a new centos syslog-ng box which was configured as a syslog destination for a number of devices, but we weren't seeing logs being generated.

Things we tested

 - Checked syslog-ng.conf - all good.

 - Sent test syslogs via a command line syslog generator - all good.

 - Ran tcpdump on the interface receiving syslog via 'tcpdump -A -i bond1 udp port 514' and could see traffic for syslog successfully.
 - Re-ran syslog, still no traffic

Solution

 - Issue was resolved after adding the following to /etc/sysctl.conf and running sysctl -p.

# Drop packets that look like they are spoofed.  Default = 1.
# 0 = don't check;
# 1 = drop packets that as sourced at a directly connected interface
#     but were input from another interface;
# 2 = drop any packets that look spoofed.
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.bond1.rp_filter = 0

tac_plus install on Ubuntu - Fixing the crypt error message during build

I'm going to add a couple of posts later on in regards to the process of installing tac_plus on Ubuntu but I thought I'd pre-empt the full post with a quick fix if you're trying to install and hit the following error:

authen.cpp: In member function 'int tauthen::changepass(int)':
authen.cpp:1057:52: error: 'crypt' was not declared in this scope
I initially added #define <crypt.h>' to authen.cpp but was finding that the passwords being generated by the function wasn't matching what the tac_plus web front end was generating.

Ended up tracing the fix back to adding #include <unistd.h> to the define section in tac_plus.h.

Testing following a successful build showed passwords being generated successfully by both the tac_plus program and the php web front end.

Hope this shortcuts the build process for people.

tac_plus Deep-Dive #1 - Command Authorization and db tables

First in a few posts I hope to get up to here covering tac_plus (using the version from networkforums.com) which I've been looking into over the weekend.  All the work I've been doing so far has been in relation to cisco devices

Primary interest has been how we get command authorization working on our network equipment.  Having someone 'reload' a core device in the middle of the day is only something we want to happen once...

So as a quick overview of how some of the values in the database come together:

1. The column 'cmd_dflt' in the user table marks whether an unlisted command will be permitted or denied if it doesn't exist explicitly in the node table.  0 is the default value and means non explicit commands will be denied.  Set to 1 and commands not explicitly included will be allowed.
2. The node table contains the command sets applied to users/groups.
3. Entries with the 'service' column set to 52 are returned to the device on exec (eg once logged in).  It's here you can return the priviledge level.  (value1 would be 'priv-lvl' and value is '1' or '15'.
4. Entries in relation to command authorization will have a service value of 56.  Type value set to 57 means permitted, type value set to 58 is denied.