Bug 238458 - security/sshguard: Update to 2.4.0
Summary: security/sshguard: Update to 2.4.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Adam Weinberger
Depends on:
Reported: 2019-06-10 16:13 UTC by Kevin Zheng
Modified: 2019-07-19 13:10 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (dan.mcgregor)

Patch (1.00 KB, patch)
2019-06-10 16:13 UTC, Kevin Zheng
no flags Details | Diff
Updated patch (3.50 KB, patch)
2019-07-18 23:06 UTC, Kevin Zheng
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Zheng 2019-06-10 16:13:03 UTC
Created attachment 204949 [details]

Update security/sshguard to 2.4.0


- Match "Failed authentication attempt" for Gitea


- Log human-readable service names instead of service code


- Correctly terminate child processes when ``sshguard`` is killed


- No longer accept logs given via standard input
Comment 1 commit-hook freebsd_committer 2019-06-30 19:50:50 UTC
A commit references this bug:

Author: swills
Date: Sun Jun 30 19:50:11 UTC 2019
New revision: 505456
URL: https://svnweb.freebsd.org/changeset/ports/505456

  security/sshguard: update to 2.4.0

  PR:		238458
  Submitted by:	Kevin Zheng <kevinz5000@gmail.com>
  Approved by:	maintainer timeout (dan.mcgregor@usask.ca, >2 weeks)

Comment 2 Steve Wills freebsd_committer 2019-06-30 19:51:11 UTC
Committed, thanks!
Comment 3 Adam Weinberger freebsd_committer 2019-06-30 22:34:35 UTC
'service sshguard status' always seems to fail, and I suspect it is because the process name is now 'sh', not 'sshguard'.
Comment 4 Kevin Zheng 2019-06-30 22:38:25 UTC
I'd suggest removing the PID file override option from the rc.d and always setting it from rc.d so that status always returns the correct result.
Comment 5 Adam Weinberger freebsd_committer 2019-07-01 00:52:27 UTC
(In reply to Kevin Zheng from comment #4)
I don't set the pidfile location at all. I'm using only defaults. See below. Despite the pidfile containing the correct pid, sshguard won't find it. Try it for yourself.

Again, this is because rc.d/sshguard has:
but the pidfile points to a process named:
  sh /usr/local/sbin/sshguard

Instead, it needs to be:

$ grep PID_FILE /usr/local/etc/sshguard.conf

$ grep sshguard /etc/rc.conf

$ sudo service sshguard stop
sshguard not running? (check /var/run/sshguard.pid).

$ sudo service sshguard start
Starting sshguard.

$ cat /var/run/sshguard.pid

$ sudo ps aux|grep 80319
root    80319   0.0  0.0  11592   2980  -  Ss   18:41        0:00.00 /bin/sh /usr/local/sbin/sshguard -i /var/run/sshguard.pid

$ service sshguard status
sshguard is not running.
Comment 6 commit-hook freebsd_committer 2019-07-01 00:57:13 UTC
A commit references this bug:

Author: adamw
Date: Mon Jul  1 00:57:10 UTC 2019
New revision: 505533
URL: https://svnweb.freebsd.org/changeset/ports/505533

  Fix rc(8) script process detection

  The pidfile points to a process named sh, not sshg-blocker

  PR:		238458

Comment 7 Adam Weinberger freebsd_committer 2019-07-01 12:10:54 UTC
I'm sorry, but I'm still having continued problems. Fixing the procname has exposed the fact that sshguard never exits now.

The master process never exits. To actually stop it, you have to kill the master process, which dissociates all its children, which you then have to kill one by one. Then, you have to remove the stale pidfile, before sshguard will actually start up again.

Kevin, did you test this before submitting this patch? Does it work for you? Please, add a fix here, or we should revert this update and bump PORTEPOCH.
Comment 8 Kevin Zheng 2019-07-01 16:32:51 UTC
(In reply to Adam Weinberger from comment #7)
My mistake for not testing with rc.d. Let me test and get back with a patch.
Comment 9 Kevin Zheng 2019-07-01 17:03:50 UTC
(In reply to Kevin Zheng from comment #8)
This seems to be an upstream problem. While that's being fixed let's revert and bump PORTEPOCH.
Comment 10 commit-hook freebsd_committer 2019-07-01 17:56:54 UTC
A commit references this bug:

Author: adamw
Date: Mon Jul  1 17:56:49 UTC 2019
New revision: 505626
URL: https://svnweb.freebsd.org/changeset/ports/505626

  Back out r505456. sshguard 2.4.0 misbehaves

  SSHGuard has always exited cleanly on FreeBSD. In 2.4.0, sshguard fixed that.
  It is impossible to terminate sshguard without manually killing each process.

  So, apologies to everyone who's already updated, but you'll have to manually
  kill all the processes:
    pkill -f sshguard
    pkill -f sshg-
    pkill -f tail
    rm /var/run/sshguard.pid

  So, back this out while awaiting upstream fix.

  PR:		238458

Comment 11 Kevin Zheng 2019-07-01 20:31:59 UTC
I no longer believe it was an upstream issue. Could you please try 2.4.0, but removing the local patch for files/sshguard.in?
Comment 12 commit-hook freebsd_committer 2019-07-06 15:33:16 UTC
A commit references this bug:

Author: adamw
Date: Sat Jul  6 15:33:11 UTC 2019
New revision: 505999
URL: https://svnweb.freebsd.org/changeset/ports/505999

  sshguard: Update to 2.4.0 and fix rc(8) script

  There is some strange new behaviour on the rc script in 2.4.0. It
  would either hang on start, or hang on stop. A custom stop function
  seemed the easiest way to achieve both.

  PR:		238458

Comment 13 Adam Weinberger freebsd_committer 2019-07-06 15:34:55 UTC
The sshguard.in patch was necessary. Without it, sshguard wouldn't start. Unfortunately, letting it start also prevented it from stopping. I think it should be fine now.
Comment 14 Christos Chatzaras 2019-07-16 20:32:28 UTC
Issue 1:

If you run:

service sshguard stop

when sshguard doesn't run it shows:

kill: illegal process id:

rc.d script needs to check if /var/run/sshguard.pid exists before it tries to kill the pid.


Issue 2:

service sshguard restart
sshguard already running?  (pid=1867).

There are 2 sshguard processes running. Maybe this issue is related to this.

ps -aux | grep sshg
root  17170    0.3  0.0 12156  2972  -  SC   23:28      0:00.16 /usr/local/libexec/sshg-blocker -a 30 -p 120 -s 1800 -w /usr/local/etc/sshguard.whitelist
root   1867    0.0  0.0 11624  3060  -  Ss   23:28      0:00.00 /bin/sh /usr/local/sbin/sshguard -i /var/run/sshguard.pid
root  11191    0.0  0.0 12500  3848  -  SC   23:28      0:00.00 /usr/local/libexec/sshg-parser
root  17272    0.0  0.0 11624  3056  -  S    23:28      0:00.00 /bin/sh /usr/local/sbin/sshguard -i /var/run/sshguard.pid
root  22269    0.0  0.0 11584  3040  -  S    23:28      0:00.00 /bin/sh /usr/local/libexec/sshg-fw-ipfw
Comment 15 Kevin Zheng 2019-07-17 18:02:05 UTC
In 2.4.0 the driver (/bin/sh) became the process to kill; it is no longer sshg-blocker. However, the rc.d script still seems to be passing sshg-blocker to check_pidfile().

I realized I don't know what's going on in this rc.d script. I think I'll rewrite it.
Comment 16 Adam Weinberger freebsd_committer 2019-07-17 20:18:40 UTC
The problem here is that the pidfile refers to the "/bin/sh /usr/local/bin/sshguard" process, but it's the sshg-blocker process that needs to be killed to actually shut down sshguard.

I don't have a good idea how else to structure the rc script to accommodate that. If you can fix it, that would be great.
Comment 17 Kevin Zheng 2019-07-18 23:05:50 UTC
In 2.4.0 the process to kill is /bin/sh, *not* sshg-blocker. Could you try this attached patch and see if this makes it behave once and for all?
Comment 18 Kevin Zheng 2019-07-18 23:06:07 UTC
Created attachment 205877 [details]
Updated patch
Comment 19 Adam Weinberger freebsd_committer 2019-07-19 02:04:34 UTC
Ah! The wrong PID. Clever, good catch. This fixes it.
Comment 20 commit-hook freebsd_committer 2019-07-19 02:10:00 UTC
A commit references this bug:

Author: adamw
Date: Fri Jul 19 02:09:12 UTC 2019
New revision: 506904
URL: https://svnweb.freebsd.org/changeset/ports/506904

  sshguard: Fix rc(8) script, broken in update and then broken further in followup commits

  Also clean up some comments while here.

  PR:		238458
  Submitted by:	Kevin Zheng

Comment 21 Kevin Zheng 2019-07-19 02:25:30 UTC
Thanks, Adam, for helping out with this. If there are no objections from the current maintainer, I'm also happy to take maintainership for this port.
Comment 22 Adam Weinberger freebsd_committer 2019-07-19 02:44:00 UTC
Hi Kevin,

Dan has responded quite quickly in the recent past, but there have been a troubling number of timeouts on this port. Please file a new PR that sets you as maintainer, and if there's no response in 2 weeks, it's yours.
Comment 23 Christos Chatzaras 2019-07-19 13:10:39 UTC
Everything is fine now.