On Tue, 2011-10-25 at 16:12 -0400, Mike Wohlgemuth wrote:
> I don't see any way to get fail2ban to reopen the log file without
> also forgetting the current ban list.
As I recall, it's supposed to make temporary bans. So does it really
need to keep a ban list forever? You'd be banning things tha
On 10/25/2011 4:12 PM, Mike Wohlgemuth wrote:
> On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
>> It looks like you would have to modify the syslog logrotate script
>> and add a second command in the postrotate section after it restarts
>> syslogd. Does fail2ban accept a SIGHUP to close and reo
On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
> It looks like you would have to modify the syslog logrotate script
> and add a second command in the postrotate section after it restarts
> syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
>
>
That was my first thought, bu
On 10/25/2011 01:23 AM, Andre Speelmans wrote:
> Change the config file for logrotate so that it does not create a new
> file, but that it uses copy-and-truncate. The exact syntax is easily
> found in the man-page.
>
Ah, that looks like what I need. I read the man page and spaced on the
implicati
> It looks like you would have to modify the syslog logrotate script
> and add a second command in the postrotate section after it restarts
> syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
Or make it do copy-truncate, which is meant just for these cases where
a daemon kee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/2011 09:07 AM, Andre Speelmans wrote:
>> I was referring to the fail2ban RPM. This has to be a problem for
>> just about any installation that uses logrotate.
>
> Most daemons seem to use their own logfile and therefore can use their
> own lo
> I was referring to the fail2ban RPM. This has to be a problem for
> just about any installation that uses logrotate.
Most daemons seem to use their own logfile and therefore can use their
own logrotate configuration script in /etc/logrotate.d.
But /var/log/secure is not handled by a specific da
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/2011 12:23 AM, Andre Speelmans wrote:
>> It sounds like fail2ban still has the old log file open. You need to
>> have logrotate tell fail2ban that the log file has changed.
>
> Change the config file for logrotate so that it does not create a
> It sounds like fail2ban still has the old log file open. You need to
> have logrotate tell fail2ban that the log file has changed.
Change the config file for logrotate so that it does not create a new
file, but that it uses copy-and-truncate. The exact syntax is easily
found in the man-page.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/24/2011 12:14 PM, Mike Wohlgemuth wrote:
> I've installed fail2ban on Fedora 15 to block repeated failed ssh
> connections. It works great up until logrotate kicks in. When it
> rotates /var/log/secure then fail2ban stops noticing failed ssh
On Mon, Oct 24, 2011 at 20:17, Marvin Kosmal wrote:
> Hi
>
> This does not address your problem directly.
>
> I use a program called denyhosts for blocking ssh attempts. It creates a
> list in /etc/hosts.deny.
>
> Great program.
>
+1 to denyhosts.
> Good luck
>
> Marvin
>
--
Suvayu
Open
On Mon, Oct 24, 2011 at 10:14 AM, Mike Wohlgemuth wrote:
> I've installed fail2ban on Fedora 15 to block repeated failed ssh
> connections. It works great up until logrotate kicks in. When it
> rotates /var/log/secure then fail2ban stops noticing failed ssh
> attempts. Using fail2ban-client to
I've installed fail2ban on Fedora 15 to block repeated failed ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
attempts. Using fail2ban-client to reload the jail fixes the problem,
but it also causes fail2ban
13 matches
Mail list logo
