From owner-freebsd-bugs@FreeBSD.ORG Fri Sep 11 18:10:05 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8085A106566B for ; Fri, 11 Sep 2009 18:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFD78FC13 for ; Fri, 11 Sep 2009 18:10:05 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8BIA5Us097721 for ; Fri, 11 Sep 2009 18:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8BIA5uj097720; Fri, 11 Sep 2009 18:10:05 GMT (envelope-from gnats) Date: Fri, 11 Sep 2009 18:10:05 GMT Message-Id: <200909111810.n8BIA5uj097720@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Chris Cowart Cc: Subject: Re: conf/138692: 450.status-security should exit with rc=0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Cowart List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 18:10:05 -0000 The following reply was made to PR conf/138692; it has been noted by GNATS. From: Chris Cowart To: bug-followup@FreeBSD.org, ben@b1c1l1.com Cc: Subject: Re: conf/138692: 450.status-security should exit with rc=0 Date: Fri, 11 Sep 2009 11:06:27 -0700 --s9fJI615cBHmzTOP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Remko Lodder wrote: >>> Description: >>/etc/periodic/daily/450.status-security sets rc=3D3 when >>daily_status_security_enable=3D"YES". According to periodic(8), this >>means that the output "must not be masked." However, this script >>only prints a single message or even nothing at all: >> >> case "${daily_status_security_output}" in >> "") >> ;; >> /*) >> echo " (output logged separately)";; >> *) >> echo " (output mailed separately)";; >> esac;; >> >> Please apply the attached patch to set rc=3D0, to indicate that there >> is "nothing notable" in the output. > > This informs you that a security script had been runned and will > report it's output via a different email (standard). > If you configure it to not be enabled at all; it wil tell you nothing. > If you select the other option it will be logged via > a different way. >=20 > I do not see the arugments you are proposing. I think the current > output is just fine, when I read my daily email > and see that there is additional output seperately; I will read that > seperate email. I believe there are a couple issues at work here. Firstly, while this may not be a typical case, there are environments where someone (hopefully a team) administers 100 or more FreeBSD servers. I certainly work in one of these, and I believe Ben does too. Part of the growing pains and a lesson of scalability comes on the day you realize you're spending an hour paging through dailies, every day, just to find the 1 or 2 e-mails with a small gem of information that you care about. The rest is just noise and a waste of time. On that day, you embark on a crusade to achieve the grand vision of "the machine doesn't send me an e-mail unless it has something interesting to say." Like a good system administrator, you consult the man page. There's a sudden, rare moment of geeky hope and excitement when you notice instructions in the man page that walk you through achieving _exactly the thing you wanted to do_ (normally, you have to piece two or three things together, try it out, rinse, repeat, etc.): "To only see important information from daily periodic jobs, add the following lines to /etc/periodic.conf...". So, you try it. The next day, you get your periodics, and while they're considerably shorter each, a lot of them had interesting definitions of "important information." You sigh. Not exactly what you wanted, but it's never _that easy_. You begin tuning. Oh, nagios is already monitoring disks and portaudit? Disabled. IPFW denies traffic every day... that's why the rule is there. Disabled. You get the idea. That should do it. The next day, you get your periodics, but now you're starting to think the man page was joking when it said "important information." I _nearly_ succeeded with quieting down the daily. Unfortunately, I'm still getting one "daily run output" email from each host each day. Do you know what "important" thing it thinks it needs to tell me? |=20 | Security check: | (output mailed separately) |=20 | -- End of daily output -- |=20 Every. Single. Day. 130 copies. Delightful. But I want the security job to run! I do! I'm very interested in the rc=3D1 and rc=3D3 output from those jobs. So I leave it enabled and I hack procmail to hide these "success" messages from me. At first, I didn't understand why you thought Ben's argument was flawed. Telling me the output was mailed separately is not noteworthy, not remarkable, not uncommon. It's noise. It's rc=3D1. I didn't get it until I looked more closely at the 450.status-security script. Although it would improve my inbox volume the way I want it, Ben's patch would cause the _entire security run_ output to masked in the case that the output was configured to be inlined. That's because security runs are a nested call to periodic. Unfortunately, periodic itself doesn't return a different value depending on the "severity" of its output. I would propose at _least_ the following patch to make the e-mail or logged cases more sane and consistent with the documentation by making it possible (and not by default, because by default, rc=3D0 causes the output to be included) to suppress the "output (logged|mailed) separately" lines: | --- 450.status-security 2008-12-31 23:50:16.000000000 -0800 | +++ /home/ccowart/450.status-security 2009-09-11 10:56:08.000000000 -07= 00 | @@ -23,16 +23,17 @@ | export security_output=3D"${daily_status_security_output}" | case "${daily_status_security_output}" in | "") | - ;; | + rc=3D3;; | /*) | - echo " (output logged separately)";; | + echo " (output logged separately)" | + rc=3D0;; | *) | - echo " (output mailed separately)";; | + echo " (output mailed separately)" | + rc=3D0;; | esac;; | esac | =20 | - periodic security | - rc=3D3;; | + periodic security || rc=3D3;; | =20 | *) rc=3D0;; | esac Realistically, the problem is still going to exist in the inlined output case (which I would prefer to use, because it means 1 email per machine instead of two). Assume I configure the periodics to include the security output inline. Now assume no security check has "noteworthy" output (all rc=3D0, output_success=3DNO). The daily status-security is still going to indicate non-maskable output (rc=3D3), and thus my daily will look like: |=20 | Security check: |=20 | -- End of daily output -- |=20 This is pretty lame, but I can't see a way around it without either 1) disabling the security run in "daily" and setting up a separate cron for it, or 2) doing some redesigning on periodic so its return code is a function of the return codes of the scripts it runs. I think the latter would be ideal, but I realize it's a much more significant undertaking. The patch I'm suggesting above helps minimize the noise in the easy (email or logged) case while preserving the inlined output as "notable" given "periodic daily" can't currently determine whether it was otherwise. --=20 Chris Cowart http://www.timesinks.net/ --s9fJI615cBHmzTOP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iQIcBAEBAgAGBQJKqpGhAAoJEGdJs2Q92uldLZkQAKownnVR7IwjYCbJzUcn/Fe5 c2wnW4WF3HzHtPDBmXAu59FVdOLR0RR5mTrIpeDlnuF0hFmTqe+u9cD3N7LkJmYS mhMDvRe1JIqAXr6zQaYQuYPcArj3ASvKamaK3F7WKXKJEhIkj3SXRSM0cWq4aSvb C0kNk0bt0TL1kDp/leTmf85O6J2vz+tBYkDlhRgjE9YA/pilJqUhIXDHBYyfPpR8 AVUa//yHqYq1hVsv+vTX3Nwui009WVsvrXwbcSkKXbUdA3sw2BbT4eBsMiZ3GKh3 64CxjDtYqt/CH/JoOnKPueOCuhgU2rgNFOwJjp3XRhZCjd4+LkFBoQJBbC++HUg2 F0NZcgp8E71ePXg9+I+NToe50flQlJqtlDXqgILHvfBzJkCnMhBg3415hvQT80oZ yPIz0QscQ3FJusm6BIFFveHb/f7tDT22t+pn0/IyZ7wq6tODE00UeptBBn6k5A2I kvODb96Wj/q9o2pfBMuT8sWET+IMb2jTYo+iv91R/9+YVcnXvCaHZph0H+GC9XPY 1Oyo6NOUBItYQe1pYgSAf+kMuMDCn8aChmZb/yTrzgD7VduPJQPqZk7bxjCTpjcl tE2UBpmyVjl9mErTZlnRQuPW7Vr/FgQnnKRSVZgM9tuquio6zYQjJtsq167hWSEf Tpndt2OUz6ciroQ2BLhS =FkiD -----END PGP SIGNATURE----- --s9fJI615cBHmzTOP--