| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| | |
- Command line Parameter Support is only available with the new config format, here is a sample:
action(type="omprog" binary="/path/omprog.py --option=value --option2=\"value 2\"")
- Also fixed a seqfault wenn using the new config format and no template parameter was specified.
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This interface permits us to pass a user-pointer to librelp, which
it will pass back to us on message reception. This is the foundation
for some more advanced features that require access to imrelp's
configration object.
|
| | |\| |
|
| | | |
| | |
| | |
| | |
| | | |
always bears the risk that one or another is not maintained when
an update happpens
|
| | |\|
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Too quick hacking, obviously, one too late, one too early, now
it should fit ;) Thanks to Tomas Heinrich for pointing this out.
|
| | |\| |
|
| | | |
| | |
| | |
| | | |
No regression, this was in recently written, never-released code.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
and make imjournal use it.
The new mode is needed, as imjournal uses journal's timestamp
as message generation time (which otherwise is when the message
entered the system, and the ratelimiter uses this as current
timestamp in order to save performance).
It is debatable if imjournal is doing the right thing here. But
it doesn't feel totally wrong. So let's safe that debate for
later ;)
|
| | |\| |
|
| | | | |
|
| | |\| |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This option specifies whether imjournal should ignore messages
that are currently in journal. This option is only used when there
is no StateFile to avoid message loss.
modified: doc/imjournal.html
modified: plugins/imjournal/imjournal.c
Conflicts:
doc/imjournal.html
plugins/imjournal/imjournal.c
|
| | |\|
| | |
| | |
| | |
| | | |
Conflicts:
doc/imjournal.html
|
| | | |
| | |
| | |
| | | |
most importantly, convert sample to new-style config format
|
| | | |
| | |
| | |
| | |
| | | |
... was changed in the interim, so the result of the merge was
sub-optimal ;)
|
| | | |\
| | | |
| | | |
| | | |
| | | | |
Conflicts:
plugins/imjournal/imjournal.c
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
modified: doc/imjournal.html
modified: plugins/imjournal/imjournal.c
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
plugins/imjournal/imjournal.c
|
| | | | |/
| | |/|
| | | |
| | | |
| | | | |
modified: doc/imjournal.html
modified: plugins/imjournal/imjournal.c
|
| | |\ \ \
| | | |/
| | |/| |
|
| | | | |
| | | |
| | | |
| | | | |
thanks to David Lang for alerting me.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
thanks to David Lang for alerting me.
|
| | | | | |
|
| | |\| | |
|
| | | | | |
|
| | |\| | |
|
| | | | | |
|
| | |\| | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The original imjournal code did not support ratelimiting at all. We
now have our own ratelimiter. This can mitigate against journal
database corruption, when the journal re-sends old data. This is a
current bug in systemd journal, but we won't outrule this to happen
in the future again. So it is better to have a safeguard in place.
By default, we permit 20,000 messages witin 10 minutes. This may
be a bit restrictive, but given the risk potential it seems reasonable.
Users requiring larger traffic flows can always adjust the value.
|
| | |\| | |
|
| | | | |
| | | |
| | | |
| | | | |
do to bugs in systemd, the module can lead to a DoS to the local machine
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There is a time window, between rsyslog reporting syntax
errors and the daemon returning with failure, this may cause
systemctl restart rsyslog to not report any error inmediately
but later in the logs which is confusing to users.
The appropiate steps to correct this annoyance is to notify
systemd with a simple sd_notify(0, "READY=1"); just before
entering the main loop.
Tested in openSUSE 12.3/13.1 x86_64
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Those are documented here:
http://www.freedesktop.org/wiki/Software/systemd/syslog/
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The message that reports how many messages were lost due to
ratelimiting was sent before reseting the state that led to it. If it
itself got ratelimited, this could lead to an endless loop.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
which controls the number of bits being used for
Diffie-Hellman key generation
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* "console"
* "bsd_security" - this is called "security" under BSD, but that name
was unfortunately already taken by some standard facility. So I
|
