“Before applying this update, make sure all previously released errata relevant to your system have been applied.”
That does not say pick and choose errata or only install security errata. In reality, one should only NOT install an update if that update causes problems. That is any Errata update, not just security updates.
The reason, all updates are built on a staged system. Any updates built today are built on / linked against the updates from yesterday.
If you use a perl package (that is an example name, could be any package) built against today’s update set on 6.3 .. it may or may not work at all, or work correctly. It also could possibly introduce security issues never tested for because that combination is unique to your install.
I might work fine, it might be horrible.
yes it helped thanks!
Although the state of the thing itself is not very helpful :(
My intention was to automatically get warned, when there are pending security updates. I therefore reworked the “yum” plugin of Munin [1]
But as I see now, this will not work for CentOS
as long as the data (a working updateinfo.xml)
is not existent in the repos..
I will add a note in the Munin yum plugin to inform other CentOS users about this #fail.
It would be good to add such a hint also in the CentOS package of the yum-plugin-security. Until now there is no info about the no-op nor in the man page neither under /usr/share/doc.
Shall I create a bug report addressing the missing doc?
Or will it get answered with “won’t fix” as the fix would need to fork an own CentOS version of the plugin, so no longer simply copy the package from upstream (rh)
when I install the updates I usually install all pending updates btw.
As written in my other mail, the intention is to get triggered when security updates are pending.
fyi and cheers,
Gabriele
If you just want to be notified (or start a job, or whatever) then why not set up something to watch the CentOS-announce list, parse the subject lines for “Security”, and then do whatever you need to do after that.
You’re actually going to want to look for ‘CESA’ which indicates a security update announcement.
John
because I want the alert for my individual machines. So the proposed method is no solution for an automagical trigger :)
As said in my earlier mail I use Munin for system monitoring and want the raven to croak when a node has pending security updates:
You still can do that without expending too much effort.
One way would be to monitor CentOS-announce, parse the subject lines, copy the security update filenames to a text or database file. (sqlite is made for this kind of thing.) You can either keep a list on each machine or have a central data repository, whichever suits you best.
Then all you need to do is have each machine run “yum check-update” on whatever timed basis you wish. Capture the list of pending updates, compare it against your database, and then do your thing.
Although the proposal you made is /possible/ to implement, I will not do it, because I think that this is the wrong way to solve the issue.
Pardon me, but I think it is madness to maintain the info outside of yum.
And your method is not suitable to use within Munin monitoring. And a Munin capable solution is what I am looking for with highest priority.
I don’t like to spend time in creating ugly workarounds.. and therefore would highly appreciate if the CentOS-Developers will add the data to the yum repositories. Then I can use Munin to monitor the pending security packages also for CentOS as now only for my RHEL machines.
All the best and thanks again,
Gabriele
It’s not that simple. Please have a look at the list archives in the past couple months where this was addressed. The threads were either here or on the CentOS-devel mailing list.
If memory serves the primary factor that is holding this up is a space requirements issue; the threads can shed more light on it, however.
John
thanks to Nux! who posted the following link in the first reply of this thread:
————————–
We have an alert for CentOS packages with security updates, and I was curious how it works. Turns out that what it does is do a search engine search for
And then fetches the top result looking for the string /Security Advisory/
We update all packages to tip whenever we update. This not-completely-accurate method turns the ordinary “you have some updates, zzzz” to the occasional “you have security updates! zomg!”
Amusing. Keeps people awake.
Anyway, if we did have such a tool, we should definitely build it such that the only thing it does is look at your current machine and say,
“you’re not at tip, and some of your packages have security problems. update to tip.” That would not increase the size of the tree nor encourage people to unsafely do partial updates. And it wouldn’t require a huge historical analysis.
12 thoughts on - Yum-plugin-security
This plugin does not work on CentOS, at least not yet, there were previous discussions. e.g. http://CentOS-devel.1051824.n5.nabble.com/CentOS-devel-yum-plugin-security-and-shellshock-td5710031.html
HTH
CentOS only tests that things work when doing all updates … it does not test any other grouping of packages.
In reality that is also true for upstream support as well … see the first line in any upstream update in the solutions section. Here is an example:
https://rhn.redhat.com/errata/RHSA-2014-1870.html
First line in Solution Section:
“Before applying this update, make sure all previously released errata relevant to your system have been applied.”
That does not say pick and choose errata or only install security errata. In reality, one should only NOT install an update if that update causes problems. That is any Errata update, not just security updates.
The reason, all updates are built on a staged system. Any updates built today are built on / linked against the updates from yesterday.
If you use a perl package (that is an example name, could be any package) built against today’s update set on 6.3 .. it may or may not work at all, or work correctly. It also could possibly introduce security issues never tested for because that combination is unique to your install.
I might work fine, it might be horrible.
yes it helped thanks!
Although the state of the thing itself is not very helpful :(
My intention was to automatically get warned, when there are pending security updates. I therefore reworked the “yum” plugin of Munin [1]
But as I see now, this will not work for CentOS
as long as the data (a working updateinfo.xml)
is not existent in the repos..
I will add a note in the Munin yum plugin to inform other CentOS users about this #fail.
It would be good to add such a hint also in the CentOS package of the yum-plugin-security. Until now there is no info about the no-op nor in the man page neither under /usr/share/doc.
Shall I create a bug report addressing the missing doc?
Or will it get answered with “won’t fix” as the fix would need to fork an own CentOS version of the plugin, so no longer simply copy the package from upstream (rh)
# rpm -ql yum-plugin-security
/etc/yum/pluginconf.d/security.conf
/usr/lib/yum-plugins/security.py
/usr/lib/yum-plugins/security.pyc
/usr/lib/yum-plugins/security.pyo
/usr/share/doc/yum-plugin-security-1.1.30
/usr/share/doc/yum-plugin-security-1.1.30/COPYING
/usr/share/man/man8/yum-security.8.gz
Cheers,
Gabriele
[1] https://github.com/munin-monitoring/munin/commits/devel/plugins/node.d.linux/yum.in
when I install the updates I usually install all pending updates btw.
As written in my other mail, the intention is to get triggered when security updates are pending.
fyi and cheers,
Gabriele
If you just want to be notified (or start a job, or whatever) then why not set up something to watch the CentOS-announce list, parse the subject lines for “Security”, and then do whatever you need to do after that.
You’re actually going to want to look for ‘CESA’ which indicates a security update announcement.
John
because I want the alert for my individual machines. So the proposed method is no solution for an automagical trigger :)
As said in my earlier mail I use Munin for system monitoring and want the raven to croak when a node has pending security updates:
http://gallery.munin-monitoring.org/distro/plugins/node.d.linux/yum.html
But thanks for sharing your idea ~
Cheers,
Gabriele
You still can do that without expending too much effort.
One way would be to monitor CentOS-announce, parse the subject lines, copy the security update filenames to a text or database file. (sqlite is made for this kind of thing.) You can either keep a list on each machine or have a central data repository, whichever suits you best.
Then all you need to do is have each machine run “yum check-update” on whatever timed basis you wish. Capture the list of pending updates, compare it against your database, and then do your thing.
Although the proposal you made is /possible/ to implement, I will not do it, because I think that this is the wrong way to solve the issue.
Pardon me, but I think it is madness to maintain the info outside of yum.
And your method is not suitable to use within Munin monitoring. And a Munin capable solution is what I am looking for with highest priority.
I don’t like to spend time in creating ugly workarounds.. and therefore would highly appreciate if the CentOS-Developers will add the data to the yum repositories. Then I can use Munin to monitor the pending security packages also for CentOS as now only for my RHEL machines.
All the best and thanks again,
Gabriele
It’s not that simple. Please have a look at the list archives in the past couple months where this was addressed. The threads were either here or on the CentOS-devel mailing list.
http://lists.CentOS.org/pipermail/CentOS
http://lists.CentOS.org/pipermail/CentOS-devel
If memory serves the primary factor that is holding this up is a space requirements issue; the threads can shed more light on it, however.
John
thanks to Nux! who posted the following link in the first reply of this thread:
————————–
We have an alert for CentOS packages with security updates, and I was curious how it works. Turns out that what it does is do a search engine search for
[$package $version site:https://rhn.redhat.com/errata/%5D
{yeah, doesn’t even put $version in quotes!}
And then fetches the top result looking for the string /Security Advisory/
We update all packages to tip whenever we update. This not-completely-accurate method turns the ordinary “you have some updates, zzzz” to the occasional “you have security updates! zomg!”
Amusing. Keeps people awake.
Anyway, if we did have such a tool, we should definitely build it such that the only thing it does is look at your current machine and say,
“you’re not at tip, and some of your packages have security problems. update to tip.” That would not increase the size of the tree nor encourage people to unsafely do partial updates. And it wouldn’t require a huge historical analysis.
— greg