syslog help

I have the same syslog configuration on my host as a jail, but the host does not appear to be logging properly.

The logs, /var/log/messages/log and /var/log/cron/log, appear empty other than the line indicating the logfile was turned over.

My changes are basically, move all logs to a directory, ie:
1. /var/log/messages -> /var/log/messages/log (I do this because I don't want /var/log cluttered with a zillion files)
2. rotate each log file nightly and keep 10 logs

On my workstation jail, this works flawlessly, but on the host, /var/log/messages/log only has the log rotated message and nothing else. In addition, it seems my router logs are getting printed to the host's console - I have my router syslog listening on the network and the messages being printed to the console should be written to separate files:
/var/log/ap/<ip address>/log

I have 2 access points in my house and I want to have separate logs so I can easily figure out where something originated.

host and workstation syslog.conf:

Code:
*.err;kern.warning;auth.notice;mail.crit                /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages/log
security.*                                      /var/log/security/log
auth.info;authpriv.info                         /var/log/auth/log
mail.info                                       /var/log/mail/log
#lpr.info                                        /var/log/lpd-errs
#ftp.info                                        /var/log/xferlog
cron.*                                          /var/log/cron/log
!-devd
*.=debug                                        /var/log/debug/log
*.emerg                                         *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info                                   /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
# touch /var/log/all.log and chmod it to mode 600 before it will work
#*.*                                            /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.*                                            @loghost
# uncomment these if you're running inn
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
# Uncomment this if you wish to see messages produced by devd
# !devd
# *.>=info
#!ppp
#*.*                                             /var/log/ppp.log

#include                                         /etc/syslog.d
include                                         /usr/local/etc/syslog.d

router syslog.conf
Code:
*.err;kern.warning;auth.notice;mail.crit                /dev/console

# write AP logs to separate files
+192.168.1.3
*.* /var/log/ap/192.168.1.3
+192.168.1.4
*.* /var/log/ap/192.168.1.4

# the remaining logs apply locally
+@
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local7.none   /var/log/messages/log
security.*                                      /var/log/security/log
auth.info;authpriv.info                         /var/log/auth/log
mail.info                                       /var/log/mail/log
#lpr.info                                        /var/log/lpd-errs
#ftp.info                                        /var/log/xferlog
cron.*                                          /var/log/cron/log
!-devd
*.=debug                                        /var/log/debug/log
*.emerg                                         *
 
but the host does not appear to be logging properly.
syslogd(8) has a default flag -s:
Code:
 % grep syslogd /etc/defaults/rc.conf
syslogd_enable="YES"            # Run syslog daemon (or NO).
syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a different one.
syslogd_flags="-s"              # Flags to syslogd (if enabled).
syslogd_oomprotect="YES"        # Don't kill syslogd when swap space is exhausted.

Code:
     -s      Operate in secure mode.  Do not log messages from remote
             machines.  If specified twice, no network socket will be opened
             at all, which also disables logging to remote machines.
 
syslogd(8) has a default flag -s:
Code:
 % grep syslogd /etc/defaults/rc.conf
syslogd_enable="YES"            # Run syslog daemon (or NO).
syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a different one.
syslogd_flags="-s"              # Flags to syslogd (if enabled).
syslogd_oomprotect="YES"        # Don't kill syslogd when swap space is exhausted.

Code:
     -s      Operate in secure mode.  Do not log messages from remote
             machines.  If specified twice, no network socket will be opened
             at all, which also disables logging to remote machines.
Yes, I should have posted:
syslogd_flags="-ss -vv"
syslogd_enable="YES"

Then, I wonder if perhaps my router jail is somehow leaking logs to the first tty1 then? I have my host setup on the first 3 ttys, then 4 and 5 for my router, and 6,7,8 for my workstation. Hmm, I don't have the oomprotect, I suppose I hope the system will never get in that state to begin with.
 
I still haven't sorted this out and needed my logs to troubleshoot an issue.

Again, the confusing thing is that syslog appears to log properly in my jails:

I have a workstation jail which I use for my desktop / workstation purposes, it has a graphical env. I have a router jail which I only remote into when there are issues or I need to make networking changes. I modified the syslog conf here to indeed listen on the local network for syslog traffic and write those to 2 separate files.

The host syslog does not listen on the network.

I still wonder why:
*.err;kern.warning;auth.notice;mail.crit /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages/log
security.* /var/log/security/log
auth.info;authpriv.info /var/log/auth/log
mail.info /var/log/mail/log
cron.* /var/log/cron/log
!-devd
*.=debug /var/log/debug/log
*.emerg *

does not appear to log to /var/log/messages/log
 
Interesting issue, but at the same time... no offense (!) but from my perspective all you need is a good look at syslogd(8) as well as syslog.conf(5).

I mean, for starters, you previously mentioned -ss but all that does is make things "worse" because it only locks things down even further.

But... when dealing a problem the first step to take is to break things down into easier managerable chunks and also confirm the current state of the problem (I'm actually in the middle of writing a guide about this). Let's start with the core issue: you set up a jail, and then it doesn't seem to provide any logs at all, right?

So here's the thing... a jail doesn't perform a full bootup sequence, it only starts a few daemons as specified by /etc/defaults/rc.conf unless you set up overrides:
Code:
root@gamma:/etc # file rc.conf
rc.conf: cannot open `rc.conf' (No such file or directory)
root@gamma:/etc # service -e
/etc/rc.d/var_run
/etc/rc.d/cleanvar
/etc/rc.d/newsyslog
/etc/rc.d/virecover
/etc/rc.d/cleartmp
/etc/rc.d/os-release
/etc/rc.d/motd
/etc/rc.d/syslogd
/etc/rc.d/utx
/etc/rc.d/cron
^ This is on my (phat) Gamma jail which I've set up a few days ago.

See... syslogd doesn't always announce its presence, it doesn't constantly mention its own start/stop. So first: let's try to prove that things are actually running using logger(1) => logger -t gamma_log "Confirming suspicions..." and what do you know:

Code:
root@gamma:/var/log # tail -3 messages
Apr 21 15:06:34 gamma peter[5465]: /usr/sbin/service: WARNING: $sendmail_enable is not set properly - see rc.conf(5).
Apr 21 15:07:44 gamma peter[5678]: /usr/sbin/service: WARNING: $sendmail_enable is not set properly - see rc.conf(5).
Apr 21 15:10:47 gamma gamma_log[5730]: Confirming suspicions...
See what I mean? Now I know for sure that logging in my jail is fully functional.

Once you have that out of the way you can focus on the next step: centralizing your logging. The 'how' will heavily depend on your situation, in specific the way in which your jail is able to access/contact the host or not.

As for your "leaking to the tty" comment... nah: that's simply /dev/console at work for you.

Hope this can give you some ideas... but also: what exactly are you trying to achieve here? Getting logs from your jail onto your host?

That could be as easy as simply making a dedicated logging directory for your jail on your host (say /var/log/myjail), then using mount_nullfs(8) to make that location accessible for your jail after which you set up syslog.conf to log certain messages (facilities and/or levels) to a file in that mounted location.

Maybe food for thought?
 
Thanks for the reply, I will start tinkering more.

Yes, I've used the logger -t to test logging.

No, my host has no logs at all. The jails all log fine (in their respective locations). I don't want centralized logging at this point. I believe I had logging working on the host at one point and I keep my configuration in git, so I likely tried that, but I think to your point, I need to try a barebones syslog conf and then go from there to see what is breaking it on my end. Yes, I should bypass rc.conf and just run it manually, that will be a great help too.
 
Yes, I've used the logger -t to test logging.

No, my host has no logs at all. The jails all log fine (in their respective locations). I don't want centralized logging at this point. I believe I had logging working on the host at one point and I keep my configuration in git, so I likely tried that, but I think to your point, I need to try a barebones syslog conf and then go from there to see what is breaking it on my end.
That sounds like a good idea. Generic things which you could do is make sure the daemon is running ( # service syslogd status as well as using ps:
Code:
root@bsd:/home/peter # service syslogd status
syslogd is running as pid 1215.
root@bsd:/home/peter # ps ax -p 1215
 PID TT  STAT    TIME COMMAND
1215  -  SCs  0:00.08 /usr/sbin/syslogd -ss
root@bsd:/home/peter # ps ax | grep syslogd
 1215  -  SCs    0:00.08 /usr/sbin/syslogd -ss
 1218  -  I      0:00.00 syslogd: syslogd.casper (syslogd)
 1219  -  Is     0:00.00 syslogd: system.net (syslogd)
15621  3  S+     0:00.00 grep syslogd
Worst case scenario: make sure syslogd is not running, then perform a manual "debug session". Once again I advice you to take your time and check syslogd(8) but for now you could consider using: # /usr/bin/syslogd -dF -m1 -ss and take things from there.

This would fire up syslogd in debugging mode (= lots out output!), keeps it running on the foreground and also 'marks' every single minute. And of course we lock things down as well just in case.

That command is bound to give you some clues as to what is going on.

Hope this can also help... keep in mind: one step at a time, and also take your time.
 
Interesting, that is strange.

So, I did revert back to the conf from here:

And, the only diff is the line ends with a space.

Once I did that, it worked.

But, the jails don't have a space at the end of the line and work fine.
 
Back
Top