conf/138692: 450.status-security should exit with rc=0
Chris Cowart
ccowart at timesinks.net
Fri Sep 11 18:10:05 UTC 2009
The following reply was made to PR conf/138692; it has been noted by GNATS.
From: Chris Cowart <ccowart at timesinks.net>
To: bug-followup at FreeBSD.org, ben at 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--
More information about the freebsd-bugs
mailing list