1 |
On Tue, 20 Sep 2005 08:53:18 -0500 |
2 |
"Brian G. Peterson" <brian@×××××××××.com> wrote: |
3 |
|
4 |
> On Tuesday 20 September 2005 07:44 am, Marius Mauch wrote: |
5 |
> > > Brian Peterson wrote: |
6 |
> > > The glsa-check tool is basically useless |
7 |
> > > (as of gentoolkit-0.2.1_pre7), as it shows all GLSAs rather than |
8 |
> > > just GLSAs for tools that correspond to packages installed on the |
9 |
> > > system it is run on. |
10 |
> > |
11 |
> > Can you explain this a bit more? glsa-check hasn't actually changed |
12 |
> > for a long time. Also make sure you don't confuse the --list option |
13 |
> > with the --test option. |
14 |
> |
15 |
> Sure. |
16 |
> |
17 |
> glsa-check --test |
18 |
> |
19 |
> run by itself, does nothing except give a command summary. |
20 |
> |
21 |
> glsa-check --list |
22 |
> |
23 |
> lists *all* unapplied GLSAs, regardless of whether the package is |
24 |
> installed on the running system. |
25 |
> |
26 |
> So, you need to --test each and every GLSA to see if it applies to |
27 |
> your system. |
28 |
> |
29 |
> glsa-test --test all |
30 |
> |
31 |
> gives a list of GLSAs that apply to a running system, but then |
32 |
> provides no details about these GLSAs in the list. |
33 |
> |
34 |
> My take on this as a system administrator who manages many production |
35 |
> servers running gentoo is that I should be able to run some command, |
36 |
> perhaps 'glsa-check --test all' that would give me the output of |
37 |
> --list for each GLSA that 'glsa-check --test' reports. This would |
38 |
> allow me to run glsa-check in a cron job and have the output sent to |
39 |
> me, so that I have enough information to know decide if I need to do |
40 |
> something on a running production server. |
41 |
|
42 |
As a system administrator you should know how to combine both to get |
43 |
what you want: |
44 |
|
45 |
glsa-check --list $(glsa-check --test new) |
46 |
|
47 |
> You can't 'glsa-check --pretend --fix all', as this isn't a valid |
48 |
> combination of commands. 'glsa-check --pretend all' gives a huge |
49 |
> list that you need to sort through to find the GLSAs that it thinks |
50 |
> need applying. Running: |
51 |
|
52 |
Well, pretend and fix are very different operations. |
53 |
|
54 |
> glsa-check --pretend all | grep -B 1 -A 4 "following updates" |
55 |
> produces an almost usable result of only the GLSAs that need to be |
56 |
> applied with the package name that they apply to. I think that by |
57 |
> default --pretend should *only* list GLSAs that need applying. |
58 |
|
59 |
Maybe, but internal that's much more complicated (as "all" is simply |
60 |
expanded to all GLSAs, and pretend on a single GLSA should show some |
61 |
info even if there is nothing todo). Guess the easiest would be to add |
62 |
a new target "affected", would just have to see how bad it is for |
63 |
performance. |
64 |
|
65 |
> I think that having a sensible default of 'all' for the package list |
66 |
> of --test would make a lot of sense, although this is minor. |
67 |
|
68 |
Maybe, but generally "new" is a much better default than "all". |
69 |
|
70 |
> From a standpoint of making glsa-check a useful tool, integration to |
71 |
> emerge is going to be the clear 'solution' to this problem, but |
72 |
> glsa-check as it exists today requires too many manual steps to make |
73 |
> it very useful for the proactive monitoring of running systems, |
74 |
> especially when you have more than a single system to keep track of. |
75 |
|
76 |
Use bash to your advantage ;) |
77 |
|
78 |
> For the easiest short-term solution, the output of --test and |
79 |
> --pretend would tell us what the GLSA summary is (like --list), and |
80 |
> only for GLSAs that need to be applied, so that we can assess whether |
81 |
> we should apply the patch or not. Make sense? |
82 |
|
83 |
Well, the reason why --test doesn't list the summaries is that you can |
84 |
use different operations on it's output, like --dump, --list or |
85 |
--pretend (or something completely unrelated). It's designed to be |
86 |
flexible and to be used in scripts and not to be the most convinient |
87 |
thing in the world. Hope that clears things up a little. |
88 |
|
89 |
Marius |
90 |
|
91 |
-- |
92 |
Public Key at http://www.genone.de/info/gpg-key.pub |
93 |
|
94 |
In the beginning, there was nothing. And God said, 'Let there be |
95 |
Light.' And there was still nothing, but you could see a bit better. |