List Archive: gentoo-security
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tuesday 20 September 2005 07:44 am, Marius Mauch wrote:
> > Brian Peterson wrote:
> > The glsa-check tool is basically useless
> > (as of gentoolkit-0.2.1_pre7), as it shows all GLSAs rather than just
> > GLSAs for tools that correspond to packages installed on the system
> > it is run on.
> Can you explain this a bit more? glsa-check hasn't actually changed for
> a long time. Also make sure you don't confuse the --list option with
> the --test option.
run by itself, does nothing except give a command summary.
lists *all* unapplied GLSAs, regardless of whether the package is installed on
the running system.
So, you need to --test each and every GLSA to see if it applies to your
glsa-test --test all
gives a list of GLSAs that apply to a running system, but then provides no
details about these GLSAs in the list.
My take on this as a system administrator who manages many production servers
running gentoo is that I should be able to run some command, perhaps
'glsa-check --test all' that would give me the output of --list for each GLSA
that 'glsa-check --test' reports. This would allow me to run glsa-check in a
cron job and have the output sent to me, so that I have enough information to
know decide if I need to do something on a running production server.
You can't 'glsa-check --pretend --fix all', as this isn't a valid combination
of commands. 'glsa-check --pretend all' gives a huge list that you need to
sort through to find the GLSAs that it thinks need applying.
glsa-check --pretend all | grep -B 1 -A 4 "following updates"
produces an almost usable result of only the GLSAs that need to be applied
with the package name that they apply to. I think that by default --pretend
should *only* list GLSAs that need applying.
I think that having a sensible default of 'all' for the package list of --test
would make a lot of sense, although this is minor.
>From a standpoint of making glsa-check a useful tool, integration to emerge is
going to be the clear 'solution' to this problem, but glsa-check as it exists
today requires too many manual steps to make it very useful for the proactive
monitoring of running systems, especially when you have more than a single
system to keep track of.
For the easiest short-term solution, the output of --test and --pretend would
tell us what the GLSA summary is (like --list), and only for GLSAs that need
to be applied, so that we can assess whether we should apply the patch or
not. Make sense?
Thanks for asking. :)
email@example.com mailing list