Is there an archival location (besides various mailing list archives) where I can find the CentOS errata?
To clarify, I'm referring to the errata sent out on the announce list, which refers to updates to packages CentOS has modified from upstream.
Kevan Benson wrote:
Is there an archival location (besides various mailing list archives) where I can find the CentOS errata?
To clarify, I'm referring to the errata sent out on the announce list, which refers to updates to packages CentOS has modified from upstream.
the announce list is it
On Tuesday 04 September 2007 11:47, Karanbir Singh wrote:
Kevan Benson wrote:
Is there an archival location (besides various mailing list archives) where I can find the CentOS errata?
To clarify, I'm referring to the errata sent out on the announce list, which refers to updates to packages CentOS has modified from upstream.
the announce list is it
Thanks. just for future reference, are there any plans to institute some sort of html archive of this, maybe similar to https://rhn.redhat.com/errata/?
Kevan Benson wrote:
On Tuesday 04 September 2007 11:47, Karanbir Singh wrote:
Kevan Benson wrote:
Is there an archival location (besides various mailing list archives) where I can find the CentOS errata?
To clarify, I'm referring to the errata sent out on the announce list, which refers to updates to packages CentOS has modified from upstream.
the announce list is it
Thanks. just for future reference, are there any plans to institute some sort of html archive of this, maybe similar to https://rhn.redhat.com/errata/?
build a mechanism, we can look at it and adopt it :)
there are some rss feeds, but not official and not going to be there for long so I am not going to publish the url anymore. we should have something more concrete for rss shortly ( a few weeks ) - if you want to take that on, feel free to do so.
On Tuesday 04 September 2007 12:07, Karanbir Singh wrote:
Kevan Benson wrote:
On Tuesday 04 September 2007 11:47, Karanbir Singh wrote:
Kevan Benson wrote:
Is there an archival location (besides various mailing list archives) where I can find the CentOS errata?
To clarify, I'm referring to the errata sent out on the announce list, which refers to updates to packages CentOS has modified from upstream.
the announce list is it
Thanks. just for future reference, are there any plans to institute some sort of html archive of this, maybe similar to https://rhn.redhat.com/errata/?
build a mechanism, we can look at it and adopt it :)
there are some rss feeds, but not official and not going to be there for long so I am not going to publish the url anymore. we should have something more concrete for rss shortly ( a few weeks ) - if you want to take that on, feel free to do so.
I just might, since I need to process all the CentOS errata anyways.
I could whip up some MySQL schema that stores the relevant errata info CentOS publishes and a CGI or PHP script of some sort could display it as needed, RSS or HTML, even take care of the mailing when a new errata is submitted (or after X days and new errata exist). That would kill two (or three!) birds with one stone.
Although, if you already have something lined up for the RSS, it might make sense to just generate the HTML for the errata and put it up, so there's at least something to look at for archives. I'll be processing the old errata anyways, not hard to pull it all out and stick it in some directory structure while I'm at it. That does lead to a need for someone to maintain it though.
Each has it's own benefits. If you're serious about wanting something, let me know, as I'm serious about doing it.
Kevan Benson wrote:
I just might, since I need to process all the CentOS errata anyways.
interesting, why ?
I could whip up some MySQL schema that stores the relevant errata info CentOS publishes and a CGI or PHP script of some sort could display it as needed, RSS or HTML, even take care of the mailing when a new errata is submitted (or after X days and new errata exist). That would kill two (or three!) birds with one stone.
considering we are unlikely to have millions of announcements, I'd pass on the database. Surely, a flat file should do the job nicely. Mailings for CentOS-5 come from the buildsystem, and there is a fair bit of automation with CentOS-4/3 announcements as well.
Although, if you already have something lined up for the RSS, it might make sense to just generate the HTML for the errata and put it up, so there's at least something to look at for archives.>
I seem to be missing the point here, if the rss feed exists, why do we need to further process this into html ?
I'll be processing the old errata anyways, not hard to pull it all out and stick it in some directory structure while I'm at it. That does lead to a need for someone to maintain it though.
again, i seem to be missing the point here. Why do you need to do this ? just use the yum metadata for everything and you should be sorted.
On Tuesday 04 September 2007 15:36, Karanbir Singh wrote:
Kevan Benson wrote:
I just might, since I need to process all the CentOS errata anyways.
interesting, why ?
A side venture of mine. A centralized heterogeneous update notification system. Instead of listing package names, it links directly to the OS's supplied errata page, condensing multiple packages to the single errata the references them. Email me off list if you want more info than that.
Obviously, Redhat errata cover 99% of the packages listed from a CentOS system, but the specific CentOS packages don't show up in my program as Errata, but as the package name as they don't match a known package from Redhat.
I would much rather list official CentOS errata info for those packages than skip directly to the Redhat errata page the package was modified from, for multiple reasons (and most of them aren't self-serving, I promise).
I could whip up some MySQL schema that stores the relevant errata info CentOS publishes and a CGI or PHP script of some sort could display it as needed, RSS or HTML, even take care of the mailing when a new errata is submitted (or after X days and new errata exist). That would kill two (or three!) birds with one stone.
considering we are unlikely to have millions of announcements, I'd pass on the database. Surely, a flat file should do the job nicely. Mailings for CentOS-5 come from the buildsystem, and there is a fair bit of automation with CentOS-4/3 announcements as well.
Well, it mailing are already automated, that does take away some of the impetus to implement this. Although there is still the added benefit that a the web based errata archive (see below) and the RSS will necessarily always be in sync, adding/modifying an errata entry would be simple, and the display of errata info and RSS of errata info could both be 60-or-so line scripts.
Although, if you already have something lined up for the RSS, it might make sense to just generate the HTML for the errata and put it up, so there's at least something to look at for archives.>
I seem to be missing the point here, if the rss feed exists, why do we need to further process this into html ?
There may not be a need, but it is very nice to be able to go to your OS vendor's web page and search for anything that might affect your system, or for info regarding a specific package and actually have information available.
I'll admit, it does fit my above stated goal, but that's not the only reason I think it's worthwhile. Every other enterprise OS has their errata listed online. CentOS seems to be in the somewhat unique situation of having an upstream provider that has most the errata listed, so there's been less of a drive for this.
I'll be processing the old errata anyways, not hard to pull it all out and stick it in some directory structure while I'm at it. That does lead to a need for someone to maintain it though.
again, i seem to be missing the point here. Why do you need to do this ? just use the yum metadata for everything and you should be sorted.
Yeah, I'll admit my needs are somewhat unique. :)
Kevan Benson wrote:
A side venture of mine. A centralized heterogeneous update notification system. Instead of listing package names, it links directly to the OS's supplied errata page, condensing multiple packages to the single errata the references them. Email me off list if you want more info than that.
Could you not achieve the same result with a yum plugin that just displays the update portion of a package changelog, along with its name and version when you ask for a 'yum list updates'?
There may not be a need, but it is very nice to be able to go to your OS vendor's web page and search for anything that might affect your system, or for info regarding a specific package and actually have information available.
We have spoken about this a few times, in various forums, and there really isnt a sane mechanism to get package list, machine state, extra non-rpm apps and other security related info from a machine - tunel it out over a secure link into ( for example ) a centos mirror network, and then give the user feedback on whats due and what the relevent errata state for the machine is -> unless we adopt a rhn like ( or redcarpnet / zenworks like ) agent process. Call me odd, but at this stage I am not all that keen on implementing something of that nature.
I'll admit, it does fit my above stated goal, but that's not the only reason I think it's worthwhile. Every other enterprise OS has their errata listed online. CentOS seems to be in the somewhat unique situation of having an upstream provider that has most the errata listed, so there's been less of a drive for this.
not sure I understand, http://lists.centos.org/ has a list you can get to via a webbrowser and even search around there for info if you like.
On Wednesday 05 September 2007 07:25, Karanbir Singh wrote:
Kevan Benson wrote:
A side venture of mine. A centralized heterogeneous update notification system. Instead of listing package names, it links directly to the OS's supplied errata page, condensing multiple packages to the single errata the references them. Email me off list if you want more info than that.
Could you not achieve the same result with a yum plugin that just displays the update portion of a package changelog, along with its name and version when you ask for a 'yum list updates'?
If I was relying on yum entirely, probably. I really meant heterogeneous. As in windows, OS X, Solaris, as well as yum, apt and urpm based systems. Besides that, does the RPM metadata have names and links to errata?
There may not be a need, but it is very nice to be able to go to your OS vendor's web page and search for anything that might affect your system, or for info regarding a specific package and actually have information available.
We have spoken about this a few times, in various forums, and there really isnt a sane mechanism to get package list, machine state, extra non-rpm apps and other security related info from a machine - tunel it out over a secure link into ( for example ) a centos mirror network, and then give the user feedback on whats due and what the relevent errata state for the machine is -> unless we adopt a rhn like ( or redcarpnet / zenworks like ) agent process. Call me odd, but at this stage I am not all that keen on implementing something of that nature.
Yeah, it does take an agent, and that's what I did. I'm not really referring to the update notification system as being a CentOS thing, that's a separate commercial venture I have.
I'll admit, it does fit my above stated goal, but that's not the only reason I think it's worthwhile. Every other enterprise OS has their errata listed online. CentOS seems to be in the somewhat unique situation of having an upstream provider that has most the errata listed, so there's been less of a drive for this.
not sure I understand, http://lists.centos.org/ has a list you can get to via a webbrowser and even search around there for info if you like.
I think one of us is referring to apples, the other apple pie.
I'm not questioning the availability of the information, just it's presentation and accessibility.
On Wednesday 05 September 2007 08:49, you wrote:
On Wednesday 05 September 2007 07:25, Karanbir Singh wrote:
Kevan Benson wrote:
I'll admit, it does fit my above stated goal, but that's not the only reason I think it's worthwhile. Every other enterprise OS has their errata listed online. CentOS seems to be in the somewhat unique situation of having an upstream provider that has most the errata listed, so there's been less of a drive for this.
not sure I understand, http://lists.centos.org/ has a list you can get to via a webbrowser and even search around there for info if you like.
I think one of us is referring to apples, the other apple pie.
I'm not questioning the availability of the information, just it's presentation and accessibility.
So, should I take the silence on this topic as no, there isn't any desire for a web-based errata list beyond the searchable archives of the announce list, or just that everyone's too busy to comment?
On Mon, 2007-09-10 at 09:11 -0700, Kevan Benson wrote:
On Wednesday 05 September 2007 08:49, you wrote:
On Wednesday 05 September 2007 07:25, Karanbir Singh wrote:
Kevan Benson wrote:
I'll admit, it does fit my above stated goal, but that's not the only reason I think it's worthwhile. Every other enterprise OS has their errata listed online. CentOS seems to be in the somewhat unique situation of having an upstream provider that has most the errata listed, so there's been less of a drive for this.
not sure I understand, http://lists.centos.org/ has a list you can get to via a webbrowser and even search around there for info if you like.
I think one of us is referring to apples, the other apple pie.
I'm not questioning the availability of the information, just it's presentation and accessibility.
So, should I take the silence on this topic as no, there isn't any desire for a web-based errata list beyond the searchable archives of the announce list, or just that everyone's too busy to comment?
FWIW: I do think it is useful. Lists are not very useful for asking things like "give me all vulnerabilities for package X from date A to date Z". Some more flexible database would be very useful.
-- Daniel
Kevan Benson wrote:
So, should I take the silence on this topic as no, there isn't any desire for a web-based errata list beyond the searchable archives of the announce list, or just that everyone's too busy to comment?
well, as I said before as well - build the mechanism and tools, and we can look at it :)
On Mon, 10 Sep 2007, Kevan Benson wrote:
So, should I take the silence on this topic as no, there isn't any desire for a web-based errata list beyond the searchable archives of the announce list, or just that everyone's too busy to comment?
Kevan ...
Produce a mock up, and accessible underlying generating code, database schema, and the rest, if you wish it to be reviewed for comment. It is easy to propose work for others; harder to do the work.
By way of Requirements it will need to cover all NERVA population, 3 active releases, base, and all adjunct archives, track CVE's with live links, and emit an RSS, and yet be searchible, capable of subscription self-management, and not add to workflow.
-- Russ Herrold
On Monday 10 September 2007 12:22, R P Herrold wrote:
On Mon, 10 Sep 2007, Kevan Benson wrote:
So, should I take the silence on this topic as no, there isn't any desire for a web-based errata list beyond the searchable archives of the announce list, or just that everyone's too busy to comment?
Kevan ...
Produce a mock up, and accessible underlying generating code, database schema, and the rest, if you wish it to be reviewed for comment. It is easy to propose work for others; harder to do the work.
The whole point of this (tangent to this) thread is because I AM offering to do it, I just didn't want to devote hours of my time to something that wasn't going to be accepted because of some unknown (to me) criteria.
By way of Requirements it will need to cover all NERVA population,
?
3 active releases, base, and all adjunct archives, track CVE's with live links, and emit an RSS, and yet be searchible,
All can be handled through a very simple querying of the DB it would be stored in, although I'm not sure what you are referring to by adjunct archives.
capable of subscription self-management,
? We're talking about RSS here, right? I take it you mean differing feeds so you don't have to see all errata (E.g. Redhat 5 errata feed, etc.). That's easily handled through the utilization of a DB back-end as well.
and not add to workflow.
Well, that's a tall order. Everything adds to workflow unless it replaces something else or utilizes existing data automatically. Karanbir already noted that the errata posted to the list are automatically generated, otherwise I would suggest generating them out of this as well, which would replace some existing workload (possibly) while adding new functionality.
The real question is, what level of added workflow are you prepared to accept? At a bare minimum (and easiest for me), errata would have a name, short description, associated set of affected releases, and content (most likely being the same content as the mail sent to the announce list). That's a copy and paste on the CentOS dev's end at most, and an automated insertion mechanism at least.
I'm serious about providing this, if you guys are serious about using it.
On Mon, 2007-09-10 at 15:22 -0400, R P Herrold wrote:
Kevan ...
Produce a mock up, and accessible underlying generating code, database schema, and the rest, if you wish it to be reviewed for comment. It is easy to propose work for others; harder to do the work.
By way of Requirements it will need to cover all NERVA population, 3 active releases, base, and all adjunct archives, track CVE's with live links, and emit an RSS, and yet be searchible, capable of subscription self-management, and not add to workflow.
It would be nice if there was a VUXML representation[1] as well, it is used by other projects, and tools for using it are available.
-- Daniel
On Monday 10 September 2007 14:03, Daniel de Kok wrote:
On Mon, 2007-09-10 at 15:22 -0400, R P Herrold wrote:
Kevan ...
Produce a mock up, and accessible underlying generating code, database schema, and the rest, if you wish it to be reviewed for comment. It is easy to propose work for others; harder to do the work.
By way of Requirements it will need to cover all NERVA population, 3 active releases, base, and all adjunct archives, track CVE's with live links, and emit an RSS, and yet be searchible, capable of subscription self-management, and not add to workflow.
It would be nice if there was a VUXML representation[1] as well, it is used by other projects, and tools for using it are available.
-- Daniel
Looks like that's what Redhat's using, which is what I was going to emulate anyways. Nice to have a definition.
https://rhn.redhat.com/rpc/recent-errata.pxt
Daniel de Kok wrote:
It would be nice if there was a VUXML representation[1] as well, it is used by other projects, and tools for using it are available.
-- Daniel
humm, and/or Oval definitely ( http://oval.mitre.org/ )
On Mon, 10 Sep 2007, Karanbir Singh wrote:
Daniel de Kok wrote:
It would be nice if there was a VUXML representation[1] as well, it is used by other projects, and tools for using it are available.
humm, and/or Oval definitely ( http://oval.mitre.org/ )
Please show me a lightweight implementation that works with older OVAL standards.
Last time I checked, the reference implementation was the only existing implementation, it was 4MB big, written in java (?) and choked on the Red Hat OVAL output because it failed to be backward compatible with earlier releases.
For me (and sarah !), completely useless :)
Dag Wieers wrote:
Please show me a lightweight implementation that works with older OVAL standards.
http://oval.mitre.org/language/download/interpreter/index.html
Last time I checked, the reference implementation was the only existing implementation, it was 4MB big, written in java (?) and choked on the Red Hat OVAL output because it failed to be backward compatible with earlier releases.
Not sure where you saw the java implementation, the only 2 different ones I have seen are done in C++ and seem to work quite well. Although, to be honest, I have not really used this beyond general prodding as a point of interest.
Kevan Benson escribió:
On Tuesday 04 September 2007 12:07, Karanbir Singh wrote:
Kevan Benson wrote:
On Tuesday 04 September 2007 11:47, Karanbir Singh wrote:
Kevan Benson wrote:
Is there an archival location (besides various mailing list archives) where I can find the CentOS errata?
To clarify, I'm referring to the errata sent out on the announce list, which refers to updates to packages CentOS has modified from upstream.
the announce list is it
Thanks. just for future reference, are there any plans to institute some sort of html archive of this, maybe similar to https://rhn.redhat.com/errata/?
build a mechanism, we can look at it and adopt it :)
there are some rss feeds, but not official and not going to be there for long so I am not going to publish the url anymore. we should have something more concrete for rss shortly ( a few weeks ) - if you want to take that on, feel free to do so.
I just might, since I need to process all the CentOS errata anyways.
I could whip up some MySQL schema that stores the relevant errata info CentOS publishes and a CGI or PHP script of some sort could display it as needed, RSS or HTML, even take care of the mailing when a new errata is submitted (or after X days and new errata exist). That would kill two (or three!) birds with one stone.
gmane archive already provides several RSS feeds[1], no need to reinvent the wheel. You can then code around that any mail notification you need. Though I can't see what you get going through the pain of mail->rss->mail :)
[1] http://dir.gmane.org/gmane.linux.centos.announce
Angel Marin wrote:
gmane archive already provides several RSS feeds[1], no need to reinvent the wheel. You can then code around that any mail notification you need. Though I can't see what you get going through the pain of mail->rss->mail :)
The rss feeds I am hoping we can publish will contain changelog info as well as direct links to packages on the mirror.centos.org network. Apart from that most of the info contained in the emails will be the same as whats in the rss feed.
-
Angel Marin -
Dag Wieers -
Daniel de Kok -
Karanbir Singh -
Kevan Benson -
R P Herrold