Rsyslog – Reading imfile from Perforce Directory

rsyslogsyslogUbuntu

I am facing an issue in an Ubuntu server where Rsyslog is not able to read any file from the Perforce logs directory.

I tested that Rsyslog configuration for the imfile module is working properly since it is able to read from other directories including /home.

I also added syslog user to perforce group and vice-versa but it still didn't work.

One workaround I found but obviously not suitable for production is to do something like:

tail -f /perforce/logs/log.csv >> /home/monitoredlogfile

some useful info :

drwxr----- 2 perforce perforce 4096 Jun 11 14:01 logs

id syslog uid=104(syslog) gid=108(syslog) groups=108(syslog),4(adm),1010(perforce)

id perforce uid=1010(perforce) gid=1010(perforce) groups=1010(perforce),108(syslog)

Any idea what could be going wrong ?

Best Answer

Your perforce group can only read the repo /perforce/logs you need to add "x" to that folder to allow this group to access that folder.

Also be sure your /perforce folder has the same permission. Even if your /perforce/logs has rwxrwxrwx as persmission, if your /perforce is only rwx------ then the group won't never be able to access it.

If you don't want to play with the application permission you could use ACL instead to give access to syslog user to your folder

$ sudo setfacl -m u:syslog:rx -R /perforce/logs/ 
$ sudo getfacl /perforce/logs/

Careful : once I tried that with Kubernetes (giving access to syslog to /var/lib/docker/containers), but it broke new pods (they had DNS resolution issue). I had no other choice than run rsyslog as root instead of syslog

Related Solutions

RSyslog – Fixing Issues with Log Files Outside /var/log

SELinux will prevent processes that are labeled syslogd_t to write to files that are (probably) labeled default_t. You need to label the file with something syslogd_t can write to. Files in /var/log are mostly labeled var_log_t, a type syslogd_t can surely write to.

You should not just relabel the files in /Testing to var_log_t, because that's bound to break at some point, when somebody executes an autorelabel at the next boot or runs restorecon -FvR /.

Instead, write a little policy that automatically and consistently labels your files in /Testing. Something to get your started. Your policy file could look similar to this:

/Testing(/.*)?    --    gen_context(system_u:object_r:var_log_t)

SELinux policy writing however, is a tad tricky. Which is why you should put stuff at the default location for that stuff.

However, I personally feel that logging should really go into /var/log. It's there for a reason. No matter how good you think your reason is for writing to /Testing, it's probably better to write to something like /var/log/testing.

Edit: no, no, no, no, no. That won't do. That was silly. You do not want to write a policy to allow syslogd_t to write to var_log_t, because that is already allowed by the default policy. You need to write filecontext rules (a .fc file), like my new snippet above, to label /Testing as var_log_t if you must...

Linux – rsyslog not logging messages

The only thing you need in rsyslog.conf to forward to a remote IP address is

*.* @@192.0.2.25:514;

Regarding your other question...

I tried executing logger -p cron.info TEST on the client machine and found nothing is added to /var/log/cron!

Be sure you restart rsyslogd after changing the configuration; you also need to be sure that /var/log/cron exists.

EDIT

To demonstrate what successful log entries look like, I started rsyslogd with rsyslogd -c4 -d; this sends all debugging to my ssh session. I am logging cron.info to /var/log/syslog. In a different ssh session, I ran logger -p cron.info "my test again"... this is what I see before it logs successfully to /var/log/syslog...

4578.692833385:b6d8fb70: Message from UNIX socket: #3
4578.692906216:b6d8fb70: logmsg: flags 4, from 'Bucksnort', msg Jul 15 10:02:58 mpenning: my test again
4578.692936284:b6d8fb70: Message has legacy syslog format.
4578.692977796:b6d8fb70: main Q: entry added, size now 1 entries
4578.693017277:b6d8fb70: wtpAdviseMaxWorkers signals busy
4578.693079869:b6d8fb70: main Q: EnqueueMsg advised worker start
4578.693117891:b6d8fb70: --------imuxsock calling select, active file descriptors (max 5): 3 5
4578.693210533:b7590b70: main Q: entry deleted, state 0, size now 0 entries
4578.693246128:b7590b70: testing filter, f_pmask 0
4578.693269892:b7590b70: testing filter, f_pmask 255
4578.693296429:b7590b70: Called action, logging to builtin-file
4578.693340007:b7590b70: file to log to: /var/log/syslog
4578.693369336:b7590b70: doWrite, pData->pStrm 0x96b6268, lenBuf 50
4578.693400172:b7590b70: strm 0x96b6268: file 7(syslog) flush, buflen 50
4578.693487314:b7590b70: strm 0x96b6268: file 7 write wrote 50 bytes
4578.693512965:b7590b70: testing filter, f_pmask 0
4578.693530524:b7590b70: testing filter, f_pmask 0
4578.693547988:b7590b70: testing filter, f_pmask 0
4578.693564966:b7590b70: testing filter, f_pmask 0
4578.693581783:b7590b70: testing filter, f_pmask 0
4578.693599197:b7590b70: testing filter, f_pmask 0
4578.693616153:b7590b70: testing filter, f_pmask 0
4578.693632854:b7590b70: testing filter, f_pmask 0
4578.693649647:b7590b70: testing filter, f_pmask 0
4578.693666837:b7590b70: testing filter, f_pmask 0
4578.693683852:b7590b70: testing filter, f_pmask 0
4578.693700593:b7590b70: testing filter, f_pmask 128
4578.693717070:b7590b70: testing filter, f_pmask 0
4578.693734486:b7590b70: testing filter, f_pmask 1
4578.693751624:b7590b70: testing filter, f_pmask 240
4578.693769534:b7590b70: Called action, logging to builtin-pipe
4578.693791155:b7590b70:  (/dev/xconsole)
4578.693820288:b7590b70: main Q:Reg/w0: worker IDLE, waiting for work.

Best Answer

Related Solutions

RSyslog – Fixing Issues with Log Files Outside /var/log

Linux – rsyslog not logging messages

Related Topic