Monitor Gentoo portage

[Hari Sekhon]

Pierre Cassimans wrote:
> You could use the output of glsa-check. That are the packages that 
> needs to be updated for security reasons, so you can see them as critical.
>
> Nice project
>
> On Fri, Feb 15, 2008 at 12:54 PM, Hari Sekhon <hpsekhon at googlemail.com 
> <mailto:hpsekhon at googlemail.com>> wrote:
>
>     Matthias Kellermann wrote:
>     > Hari Sekhon schrieb:
>     >> Matthias Kellermann wrote:
>     >>> Hi list,
>     >>>
>     >>> does anyone know a Nagios plugin for monitoring Gentoo's
>     portage for
>     >>> updates? A quick google search did not give any results
>     >> That sounds like a good idea and one that I am quite interested in
>     >> since I run a lot of gentoo servers.
>     >>
>     >> Could you please elaborate on what exactly you want this plugin to
>     >> do, perhaps I can write it...
>     >>
>     >> -h
>     >
>     > The plugin should check the output of "emerge -upD --newuse
>     world" for
>     > updates. It's been a while since I've used Gentoo on a daily
>     basis so
>     > I'm not sure if the output of the above command shows any difference
>     > between critical and non-critical updates.
>     >
>     > I wrote a similar plugin for FreeBSD where I use portaudit to see if
>     > there are any critical packages on the system. This way I can divide
>     > between critical packages and normal updates and give the right
>     state
>     > back to Nagios (1 = non-critical, yellow / 2 = critical, red).
>     When you say critical and non-critical updates do you mean the
>     severity
>     of the security package announcements? Ie. whether is a remote
>     exploitable service and might be considered Critical or whether it
>     takes
>     some previous user account to elevate privilege and therefore is
>     not as
>     severe and only "Important" or "Warning" in Nagios.
>
>     I take it that you do not mean any old package that has updates or the
>     thing would be permanently triggered?
>
>     I've just had a look at this and it doesn't look like it distinguishes
>     between security upgrades deemed Critical/Non-Critical. So I guess it
>     would be an all-or-nothing Critical/OK result.
>
>     Any other ideas on this are welcome.
>
>     I'll have a go at writing this since I think this is a neat idea and I
>     have a lot of gentoo to test it on here.
>
>     -h
>
>     --
>     Hari Sekhon
>
>
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2008.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     _______________________________________________
>     Nagios-users mailing list
>     Nagios-users at lists.sourceforge.net
>     <mailto:Nagios-users at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/nagios-users
>     ::: Please include Nagios version, plugin version (-v) and OS when
>     reporting any issue.
>     ::: Messages without supporting info will risk being sent to /dev/null
>
>
Yes I already use this for our internal package alerts and am writing 
the plugin around this.

It does not tell you about non-security related upgrades available 
though, so you would need to go back to emerge as well if you wanted 
that feature (although I'm not sure how useful it is since on my systems 
there are always packages that will need upgrading as mentioned, you'd 
be running emerge every single day and risk breaking things that 
currently work)

-h

-- 
Hari Sekhon


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null