Confirm with rsyslog update to backported 8.23 version the issue
doesn't occur anymore with configuration intact.
It is important to set delaycompress in logrotate configuration for
all imfile-processed files.
Peter
On Tue, Jul 18, 2017 at 11:10 AM, Peter Viskup wrote:
>
2017-07-20 0:28 GMT+02:00 matthew.gaetano :
> Sorry i didn't really explain why we kept umask. As per documentation we
> continue to add '$umask 000' at the top of the configuration file to prevent
> any possible issues with file creation. We did have issues early on when
Il 20/07/2017 17:33, Bhatt, Prachi ha scritto:
> Hi All,
>
> As part of customer requirement we need to integrate logs from
> Okta(enterprise-grade, identity management service, built for the cloud)
> and AWS Cloudtrail/Cloudwatch to existing Rsyslog solution. Can you
> provide some documents or
On Thu, Jul 20, 2017 at 11:21 AM, Rainer Gerhards
wrote:
> I don't see anything obviously wrong. I think it would make sense to
> enable a debug log, see on this page:
>
> http://www.rsyslog.com/doc/v8-stable/troubleshooting/debug.
> html#enabling-debug-via-rsyslog-conf
You’ll just need to restart rsyslogd, not a whole reboot. Debug mode is
extremely verbose, so you won’t actually want to run in it for long. Usually
what I will do is restart rsyslog in debug sending the output to a log file,
recreate the condition I’m testing, then restart rsyslog in normal
Making changes to rsyslog.conf on Production server. Restart rsyslogd
_after_ successfully verifying conf lines with:
/sbin/rsyslogd -f /etc/rsyslog.conf -N 1
No errors in conf. No errors on restart.
HOWEVER, zero SSH (authpriv) logging to /var/log/secure, although all other
logging appears to
Hi All,
As part of customer requirement we need to integrate logs from
Okta(enterprise-grade, identity management service, built for the cloud) and
AWS Cloudtrail/Cloudwatch to existing Rsyslog solution.
Can you provide some documents or configuration steps to be followed in order
to do this
I don't see anything obviously wrong. I think it would make sense to
enable a debug log, see on this page:
http://www.rsyslog.com/doc/v8-stable/troubleshooting/debug.html#enabling-debug-via-rsyslog-conf
Just as I see that you switched to reading imjournal: may it be
related to the journal so
On Thu, 20 Jul 2017, deoren wrote:
Thanks David. So if I attach the rulesets directly to the inputs, is there
any other way to combine auth facility messages into a single file? Should I
instead not attach rulesets to the inputs and instead call the rulesets via
the call function?
make an
On Thu, 20 Jul 2017, deoren wrote:
# /etc/rsyslog.conf
input(type="imuxsock" socket="/dev/log" ruleset="local")
input(type="imrelp" port="2514" KeepAlive="on" ruleset="remote")
The rules, both 'local' and 'remote', are pulled in via include files.
Am I wrong to believe that rules wrapped
On 7/20/17 7:38 PM, David Lang wrote:
On Thu, 20 Jul 2017, deoren wrote:
Thanks David. So if I attach the rulesets directly to the inputs, is
there any other way to combine auth facility messages into a single
file? Should I instead not attach rulesets to the inputs and instead
call the
>> On Jul 19, 2017, at 8:37 AM, deoren wrote:
>>
>> I've setup a ruleset that is applied to messages arriving from
remote systems via imrelp. One action within that ruleset matches on
auth facility messages and places them into a "combined" auth log file.
Additionally an alert is generated via
On Thu, 20 Jul 2017, Mike Schleif wrote:
action(type="omprog" template="RSYSLOG_TraditionalFileFormat")
If I am reading you correctly, you are telling rsyslog to output the log message
to a program, but don't specify what program to send it to.
You should have a complaint at startup
On 7/20/17 6:54 PM, David Lang wrote:
On Thu, 20 Jul 2017, deoren wrote:
# /etc/rsyslog.conf
input(type="imuxsock" socket="/dev/log" ruleset="local")
input(type="imrelp" port="2514" KeepAlive="on" ruleset="remote")
The rules, both 'local' and 'remote', are pulled in via include files.
Am I
14 matches
Mail list logo