Turns out this is due to there being another log category specifically for
rpz-passthru messages, separate from the rpz category. So an intentional
feature rather than a bug.
Ok to close.
https://gitlab.isc.org/isc-projects/bind9/-/issues/4483
It appears that this issue has already been fixed upstream, as can be seen
in the current source file for this filter at
https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/named-refused.conf
Which has:
prefregex = ^%(__line_prefix)s(?: error:)?\s*client(?: @\S*)? #\S+(?: \([\S.]+
The commit that fixes this is here:
https://github.com/fail2ban/fail2ban/commit/43954692260bc57f6b7afd08115f8906b8fabce0
As best I can tell, this issue seems to have been fixed in the 0.10.5
release.
Evan
On Thu, 4 Mar 2021, Evan Harris wrote:
It appears that this issue has already been
No, $HOME isn't. $HOME in your case is "/raid/home/user/.
Actually it's not. In the particular example I gave logs for, $HOME is
/home/user. It just happens that /home is a symlink to /raid/home.
How should the configuration be changed for multiple home directories being
stored and mounted
I guess I don't understand what needs to be changed. $HOME is /home, which
is where the local users homes are. There are additional mount points
(/raid, and one other) that hold additional network mounts of remotely store
users' home directories.
How should the configuration be changed for m
Unfortunately using convert or other tools that recompress the jpeg end up
with a generational quality loss, which most people would probably want to
avoid.
On Sat, 07 Jun 2008 22:49:55 -0400 Jay Berkenbilt wrote:
I've verified that this bug still applies to the current beta of libtiff
4.0.
Package: ampache
Version: 3.5.4-9
Severity: important
In using ampache, trying to perform a "Clean" function on a catalog either
through the web admin interface or through running catalog_update.inc (as
done from cron or manually) completes immediately without performing the
requested maintenan
Package: ampache
Version: 3.5.4-9
Severity: important
In trying to use ampache, I'm getting tons of errors similar to the following:
2011-08-02 19:36:21 [ampache] (PHP Error) -> [Error] Function eregi() is
deprecated in file /usr/share/ampache/www/modules/getid3/getid3.php(112)
2011-08-02 19:36
Package: grub-pc
Version: 1.98-1
After installing a fresh copy of Debian testing onto an encrypted root
partition, attempting to run update-grub results in following error:
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
Dev is mounted from udev, and / is from /de
Package: gallery
Version: 1.5.10.dfsg-1
I recently upgraded one of my systems to debian testing/squeeze, and gallery
gives lots of deprecated warnings that leave the web interface unusable. It
appears to be due to incompatibilities/problems with the new version of
php5.
Here are a just a f
The issue is not fixed by simply quoting policy and taking no action to
correct the problem.
10.5 specifies that "In general, symbolic links within a top-level directory
should be relative".
It should be fairly easy to make a symlink that does work on the target
system if it takes into acc
Package: linux-headers-2.6.32-5-common
Version: 2.6.32-15
If /usr/src is symlinked to a different location, the symlinks within the
package for 'Kbuild' and 'scripts' end up being broken since ../.. traverses
from the actual location.
This is likely a problem for all the versions of this pac
I'm no longer running the app that exhibited the problem. Since I never got
a response to the bug report, I never did further testing, just continued
with the workaround of using mv.
Evan
On Wed, 28 Oct 2009, Eugene V. Lyubimkin wrote:
Hello Evan, without a test case I not see much chanc
I stopped running the app that exhibited the behaviour more than a year ago.
But as far as I can remember, it was never fixed while I still was, so I
just worked around it.
Evan
On Sun, 25 Oct 2009, Eugene V. Lyubimkin wrote:
Hello Evan, do you encounter this big leak with 5.10.x Perl ver
Package: coreutils
Version: 6.10-6
Severity: minor
Here is a simple patch to allow using a fixed size random file source with
shred. Shred has the limitation that if --random-source= is
specified, the source must be at least as large as the destination, which
may not be feasible in many case
Package: apcupsd
Version: 3.14.4-1lenny1
Severity: normal
apctest does not appear to work properly when using the snmp driver. With
the exact same configuration, apcupsd works fine, but apctest fails with the
error "apctest: there is a problem here! We have no device open.".
I'm using an AP
Package: abcde
Version: 2.3.99.6-1
Severity: normal
There is a small bug in abcde relating to the track number tagging.
It looks like it may just be a syntax oversight.
On line 809 of the abcde script, there is an option to the $TAGGER command:
-T "${TRACKNUM:-$1/$TRACKS}"
The braces appear to
Package: audacious
Version: 1.5.1-4
Severity: normal
It appears that disabling plugins via the audacious configuration does not
actually prevent them from loading.
The amidi-plug plugin (in package audacious-plugins-extra) prints some
annoying startup messages to the console when it gets loa
Package: audacious-plugins-extra
Version: 1.5.1-2
Severity: minor
The amidi-plug plugin prints status messages to the console when using
audacious from the command line.
Tried disabling the plugin within audacious, but it still seems to get
loaded. Can't uninstall the package because I want s
the package rather than
the 2.5.1p2 release until there is a new upstream release that incorporates
those fixes as well.
Evan
On Sat, 9 Dec 2006, Bdale Garbee wrote:
severity 402221 wishlist
thanks
On Fri, 2006-12-08 at 17:03 -0600, Evan Harris wrote:
It appears that on Nov. 9 2006
Package: amanda-server
Version: 2.5.1p1-2
It appears that on Nov. 9 2006, version 2.5.1p2 has been released with many
bugfixes. Release announcement available here:
http://groups.yahoo.com/group/amanda-hackers/message/5221
Evan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Package: amanda-server
Version: 2.5.1p1-2
Apparently, the security model for version 2.5.1 and later has changed.
Consequently, running amrecover after the install fails with the following
error:
AMRECOVER Version 2.5.1p1. Contacting server on localhost ...
NAK: user root from localhost is n
Package: linux-wlan-ng
Version: 0.2.0+0.2.1pre21-1.1
Version 0.2.2 of the upstream is available. Please update.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I am having the same problem, although the --postcleanup option doesn't
appear to workaround it. Luckily the --ignore-small-errors is working.
I mirror from a lower level source mirror, and I don't think I've _ever_
seen a mirror here (which is run once a week) complete without complaining
about
Package: amavis-ng
Version: 0.1.6.9-1
When amavis-ng reaches the configured limits for unpacking messages, it
fails to clean up the files. Since the default behavior when reaching the
limits is to reject the message with a temporary failure, with each
delivery, amavis-ng leaks more diskspace, an
X-Envelope-From and X-Envelope-To additions and necessary smtp changes to
get it to the right destination.
Evan
On Thu, 28 Jul 2005, Don Armstrong wrote:
> On Thu, 28 Jul 2005, Evan Harris wrote:
> > /etc/default/spamass-milter:
> >
> > OPTIONS="-i 127.0.0.1 -r 7 -m -B
> The -m just disables changes to Subject: Content-Type: and the body of
> the message. That's it. It'll still add the various X-Spam headers.
I realize that, the problem is it is still doing the body mods. The subject
mods and Content-Type are both disabled globally, and appear to be working
pr
Package: spamass-milter
Version: 0.3.0-1
When using -m to prevent modification of the message, this setting appears
to be ignored. Markup still happens, unless the default spamassassin prefs
disable it. Unfortunately, I do not want to disable it for local users,
just for mail that may be "passi
Package: amavis-ng-milter-helper
Version: 0.1.6.9-1
When amavis-milter creates its pid file, it is created with perms of 666.
It should not be world-writable.
In addition, the milter socket also is created unsafely as world-writable.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
The debian package is still quite out of date. Please update to latest
0.94.
Evan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Yes, the current stock version has that fix and works properly for files
>4gig.
Evan
On Sun, 10 Apr 2005, Paul Slootman wrote:
> On Wed 14 Jul 2004, Evan Harris wrote:
> >
> > I also submitted the problem to the upstream rsync authors, and they have
> > already
32 matches
Mail list logo