From mmcgrath at redhat.com Wed Jan 2 16:15:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Jan 2008 10:15:48 -0600 (CST) Subject: Request to remove infofeed Message-ID: There's been a request to remove infofeed in favor of bodhi's interface as they now duplicate information. Is anyone against doing this? https://fedorahosted.org/fedora-infrastructure/ticket/248 -Mike From skvidal at fedoraproject.org Wed Jan 2 16:21:18 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 02 Jan 2008 11:21:18 -0500 Subject: Request to remove infofeed In-Reply-To: References: Message-ID: <1199290878.3921.18.camel@cutter> On Wed, 2008-01-02 at 10:15 -0600, Mike McGrath wrote: > There's been a request to remove infofeed in favor of bodhi's interface as > they now duplicate information. > > Is anyone against doing this? > > https://fedorahosted.org/fedora-infrastructure/ticket/248 > infofeed has more information, though. Look at the feeds on the right of the infofeed. Additionally, there's no single feed for all of the updates in bodhi. I'm not wed to keeping infofeed - but before we remove something we better make sure we provide the same information. -sv From lmacken at redhat.com Wed Jan 2 16:52:19 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 2 Jan 2008 11:52:19 -0500 Subject: Request to remove infofeed In-Reply-To: <1199290878.3921.18.camel@cutter> References: <1199290878.3921.18.camel@cutter> Message-ID: <20080102165219.GC20620@crow.redhat.com> On Wed, Jan 02, 2008 at 11:21:18AM -0500, seth vidal wrote: > > On Wed, 2008-01-02 at 10:15 -0600, Mike McGrath wrote: > > There's been a request to remove infofeed in favor of bodhi's interface as > > they now duplicate information. > > > > Is anyone against doing this? > > > > https://fedorahosted.org/fedora-infrastructure/ticket/248 > > > > infofeed has more information, though. Look at the feeds on the right of > the infofeed. Additionally, there's no single feed for all of the > updates in bodhi. Yes there is, https://admin.fedoraproject.org/updates/rss/rss2.0?status=stable > I'm not wed to keeping infofeed - but before we remove something we > better make sure we provide the same information. It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care? If we were to display these fields too, it would end up looking like name - summary package description update notes bug list rpm changelog Is this what we want? luke From opensource at till.name Wed Jan 2 16:55:02 2008 From: opensource at till.name (Till Maas) Date: Wed, 02 Jan 2008 17:55:02 +0100 Subject: Request to remove infofeed In-Reply-To: References: Message-ID: <200801021755.09041.opensource@till.name> On Mi Januar 2 2008, Mike McGrath wrote: > There's been a request to remove infofeed in favor of bodhi's interface as > they now duplicate information. There is no rawhide feed in bodhi, but there is one in infofeed. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Wed Jan 2 17:09:50 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Jan 2008 11:09:50 -0600 (CST) Subject: Request to remove infofeed In-Reply-To: <20080102165219.GC20620@crow.redhat.com> References: <1199290878.3921.18.camel@cutter> <20080102165219.GC20620@crow.redhat.com> Message-ID: On Wed, 2 Jan 2008, Luke Macken wrote: > > It looks like the infofeed has the RPM summary, description, and recent > changelog. Bodhi doesn't know about any of these things, so it will > require some database changes to store it. I've been meaning to have > bodhi grab the recent RPM changelog upon submission for a little while now, > so I don't have a problem implementing this, if we care? > > If we were to display these fields too, it would end up looking like > > name - summary > package description > > update notes > bug list > > rpm changelog > > Is this what we want? Instead of storing this information in the bodhi db is there somewhere else we can get it from? Koji or pkgdb for example. -Mike From skvidal at fedoraproject.org Wed Jan 2 17:16:45 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 02 Jan 2008 12:16:45 -0500 Subject: Request to remove infofeed In-Reply-To: References: <1199290878.3921.18.camel@cutter> <20080102165219.GC20620@crow.redhat.com> Message-ID: <1199294205.3921.20.camel@cutter> On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote: > > On Wed, 2 Jan 2008, Luke Macken wrote: > > > > It looks like the infofeed has the RPM summary, description, and recent > > changelog. Bodhi doesn't know about any of these things, so it will > > require some database changes to store it. I've been meaning to have > > bodhi grab the recent RPM changelog upon submission for a little while now, > > so I don't have a problem implementing this, if we care? > > > > If we were to display these fields too, it would end up looking like > > > > name - summary > > package description > > > > update notes > > bug list > > > > rpm changelog > > > > Is this what we want? > > Instead of storing this information in the bodhi db is there somewhere > else we can get it from? Koji or pkgdb for example. we have it in the repodata. Which is where the infofeed gets it from :) -sv From mmcgrath at redhat.com Wed Jan 2 18:31:20 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Jan 2008 12:31:20 -0600 (CST) Subject: Request to remove infofeed In-Reply-To: <1199294205.3921.20.camel@cutter> References: <1199290878.3921.18.camel@cutter> <20080102165219.GC20620@crow.redhat.com> <1199294205.3921.20.camel@cutter> Message-ID: On Wed, 2 Jan 2008, seth vidal wrote: > > On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote: > > > > On Wed, 2 Jan 2008, Luke Macken wrote: > > > > > > It looks like the infofeed has the RPM summary, description, and recent > > > changelog. Bodhi doesn't know about any of these things, so it will > > > require some database changes to store it. I've been meaning to have > > > bodhi grab the recent RPM changelog upon submission for a little while now, > > > so I don't have a problem implementing this, if we care? > > > > > > If we were to display these fields too, it would end up looking like > > > > > > name - summary > > > package description > > > > > > update notes > > > bug list > > > > > > rpm changelog > > > > > > Is this what we want? > > > > Instead of storing this information in the bodhi db is there somewhere > > else we can get it from? Koji or pkgdb for example. > > we have it in the repodata. Which is where the infofeed gets it from :) Thats kind of my point actually I know koji stores a lot of this information in it's database even though the rpms themselves have the information. I'd hate to continue to duplicate information that we're already storing all over the place unless there's a real need for it. -Mike From skvidal at fedoraproject.org Wed Jan 2 19:24:28 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 02 Jan 2008 14:24:28 -0500 Subject: Request to remove infofeed In-Reply-To: References: <1199290878.3921.18.camel@cutter> <20080102165219.GC20620@crow.redhat.com> <1199294205.3921.20.camel@cutter> Message-ID: <1199301868.3921.32.camel@cutter> On Wed, 2008-01-02 at 12:31 -0600, Mike McGrath wrote: > On Wed, 2 Jan 2008, seth vidal wrote: > > > > > On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote: > > > > > > On Wed, 2 Jan 2008, Luke Macken wrote: > > > > > > > > It looks like the infofeed has the RPM summary, description, and recent > > > > changelog. Bodhi doesn't know about any of these things, so it will > > > > require some database changes to store it. I've been meaning to have > > > > bodhi grab the recent RPM changelog upon submission for a little while now, > > > > so I don't have a problem implementing this, if we care? > > > > > > > > If we were to display these fields too, it would end up looking like > > > > > > > > name - summary > > > > package description > > > > > > > > update notes > > > > bug list > > > > > > > > rpm changelog > > > > > > > > Is this what we want? > > > > > > Instead of storing this information in the bodhi db is there somewhere > > > else we can get it from? Koji or pkgdb for example. > > > > we have it in the repodata. Which is where the infofeed gets it from :) > > Thats kind of my point actually I know koji stores a lot of this > information in it's database even though the rpms themselves have the > information. I'd hate to continue to duplicate information that we're > already storing all over the place unless there's a real need for it. > well, to be fair the duplication in the infofeeds are pretty minimal. -sv From jmtaylor90 at gmail.com Wed Jan 2 19:38:45 2008 From: jmtaylor90 at gmail.com (Jason) Date: Wed, 02 Jan 2008 14:38:45 -0500 Subject: Intrusion Detection (aide review) Message-ID: <1199302725.3329.38.camel@bruiser.localdomain> Hey gang, I was talking to Mike McGrath the other day on IRC and inquired about the projects use of an IDS. Mike mentioned that project currently employs only hosts.deny type stuff. I recently setup aide for use on a personal server but it looked flexible enough for use in a more robust type environment. The idea behind this write up is to see what others think about employing something like this to give an idea of what aide in particular is capable of. The Name: AIDE (Advanced Intrusion Detection Environment) What it Does: Constructs a database of files as specified in the configuration file (aide.conf). The database stores file attributes including permissions, inode number, user, group, file size, mtime, ctime, atime, growing size, number of links and link name. Based on options specified at compile time, acl, xattr and selinux attributes can be stored as well. When initialized and when checks are run, aide creates a crypto checksum/hash of each file watched using any number of algorithms (e.g. sha1, sha256, etc.). The Config File: This is where the directories/files to be watched (and what in particular is watched on the files) and the directories/files to be excluded, reporting options (default goes to /var/log/aide/aide.log) Misc. Notes: * Postgres can be used to store databases * For usage in multiple machine environments, the database can be stored in a central location and aide ran with --compare to limit resource hogging. * The database and config file can be signed, this makes it so that if a change is manually made to either file, aide will refuse to use it, as the signature will have been voided. * Aide can be run with --update which will create a new database, however it doesn't take effect until manually copied to the check database. This allows updates to be frequently tracked but not put into the check database. The main weakness I noted was in the reporting capabilities. According to the config file notes, reporting can be done via stdout, stdin, stderr, file://, fd: (file descriptor). I only have the one machine and it runs a pretty vanilla config as I don't do anything too fancy with it. With the config I have it seems to work as advertised. So there it is, thoughts? Regards, Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jan 2 19:40:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 Jan 2008 14:40:25 -0500 Subject: Intrusion Detection (aide review) In-Reply-To: <1199302725.3329.38.camel@bruiser.localdomain> References: <1199302725.3329.38.camel@bruiser.localdomain> Message-ID: <20080102144025.2ec04049@redhat.com> On Wed, 02 Jan 2008 14:38:45 -0500 Jason wrote: > I only have the one machine and it runs a pretty vanilla config as I > don't do anything too fancy with it. With the config I have it seems > to work as advertised. So there it is, thoughts? Has it actually detected any intrusions? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sopwith at gmail.com Wed Jan 2 20:11:28 2008 From: sopwith at gmail.com (Elliot Lee) Date: Wed, 2 Jan 2008 12:11:28 -0800 Subject: Intrusion Detection (aide review) In-Reply-To: <1199302725.3329.38.camel@bruiser.localdomain> References: <1199302725.3329.38.camel@bruiser.localdomain> Message-ID: Hey Jason, just a couple of ideas that may help you improve your proposal... On Jan 2, 2008 11:38 AM, Jason wrote: > What it Does: Constructs a database of files as specified in the > configuration file (aide.conf). The database stores file attributes > including permissions, inode number, user, group, file size, mtime, > ctime, atime, growing size, number of links and link name. Based on > options specified at compile time, acl, xattr and selinux attributes can > be stored as well. When initialized and when checks are run, aide > creates a crypto checksum/hash of each file watched using any number of > algorithms (e.g. sha1, sha256, etc.). Not that this type of functionality isn't a good part of intrusion detection, but I think these days intrusion detection really has to focus on more than just watching for changes on files... In addition, RPM already has a database that checks for all these things and knows how to do verification. A quick & dirty solution for file integrity checking could be to just run rpm -Va every night, and then keep good records of the rpm database md5sum and any package installations/upgrades/removals. I think in the Fedora environment, intrusion detection might mean also being able to detect that host X has repeatedly tried to login to these three machines and failed, or that Mike McGrath has logged in from a domain or IP range that he has never connected from before, or that the resource utilization of a particular service has changed drastically in the past few days because someone set up a warez site on the Fedora boxes, or that there's a lot of traffic going over network ports that we didn't know were supposed to have traffic on them... And so on and so forth. None of this stuff is covered by file integrity checking (which is still an important thing). > The main weakness I noted was in the reporting capabilities. According > to the config file notes, reporting can be done via stdout, stdin, > stderr, file://, fd: (file descriptor). Sounds like AIDE already does some postgres stuff - it might be fairly easy to have it dump more info into the DB so that one can create a simple web reporting interface using standard tools. I remember a long time ago when I had Tripwire installed on a system, the biggest problem was that it generated a lot of false positives. A file integrity checker is only good if it generates useful low-noise results, so this makes intelligent reporting tools very important. Best, -- Elliot From jmtaylor90 at gmail.com Wed Jan 2 20:32:04 2008 From: jmtaylor90 at gmail.com (Jason) Date: Wed, 02 Jan 2008 15:32:04 -0500 Subject: Intrusion Detection (aide review) In-Reply-To: References: <1199302725.3329.38.camel@bruiser.localdomain> Message-ID: <1199305924.3329.45.camel@bruiser.localdomain> On Wed, 2008-01-02 at 12:11 -0800, Elliot Lee wrote: > Hey Jason, just a couple of ideas that may help you improve your proposal... > > On Jan 2, 2008 11:38 AM, Jason wrote: > > Not that this type of functionality isn't a good part of intrusion > detection, but I think these days intrusion detection really has to > focus on more than just watching for changes on files... In addition, > RPM already has a database that checks for all these things and knows > how to do verification. A quick & dirty solution for file integrity > checking could be to just run rpm -Va every night, and then keep good > records of the rpm database md5sum and any package > installations/upgrades/removals. > > I think in the Fedora environment, intrusion detection might mean also > being able to detect that host X has repeatedly tried to login to > these three machines and failed, or that Mike McGrath has logged in > from a domain or IP range that he has never connected from before, or > that the resource utilization of a particular service has changed > drastically in the past few days because someone set up a warez site > on the Fedora boxes, or that there's a lot of traffic going over > network ports that we didn't know were supposed to have traffic on > them... And so on and so forth. None of this stuff is covered by file > integrity checking (which is still an important thing). Correct, there is more to intrusion detection than just keeping an eye on file changes. Like you mentioned, looking at logs for repeated login attempts (e.g. brute force nonsense), malformed requests to HTTP services, traffic analysis/benchmarking, keeping installed applications to required apps only, and then properly configuring those apps, keeping up to date with security patches, etc. I just wanted to throw this out there to see if folks thought it was something worth adding to the toolbox or we are good as is. :D > > The main weakness I noted was in the reporting capabilities. According > > to the config file notes, reporting can be done via stdout, stdin, > > stderr, file://, fd: (file descriptor). > > Sounds like AIDE already does some postgres stuff - it might be fairly > easy to have it dump more info into the DB so that one can create a > simple web reporting interface using standard tools. > > I remember a long time ago when I had Tripwire installed on a system, > the biggest problem was that it generated a lot of false positives. A > file integrity checker is only good if it generates useful low-noise > results, so this makes intelligent reporting tools very important. Indeed, lest we fall into the GIGO trap :D > Best, > -- Elliot -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Jan 2 21:37:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 Jan 2008 16:37:11 -0500 Subject: patch for kojid to prevent noarch build failures In-Reply-To: <20071222164129.6da8baa7@redhat.com> References: <20071222164129.6da8baa7@redhat.com> Message-ID: <20080102163711.3b3b1ae0@redhat.com> On Sat, 22 Dec 2007 16:41:29 -0500 Jesse Keating wrote: > Today a number of builds were failing on xenbuilder2/4. They were > perl noarch builds. The failure output was like: > > + '%{_fixperms}' /var/tmp/perl-Module-ExtractUse-0.22-1.fc8-root-/usr > /var/tmp/rpm-tmp.90217: line 32: fg: no job control > > I investigated a failed buildroot and discovered that _fixperms was > not being evaluated and translated in the rpm script as it should have > been. _fixperms is an arch specific macro, and that led me to do some > testing with how the mock rebuild is being called in noarch cases. > > Turns out, this is something I already fixed in upstream koji. Koji > was unnecessarily calling mock with --arch noarch in the noarch build > cases. I hadn't realized this was going to cause builds to fail so I > hadn't done an upstream release with this fix yet. However since this > is failing builds, I'm going to patch the builders manually. Here is > the fix: > > https://fedorahosted.org/koji/changeset/a023693e32d663ab7ad4f4fc85912c987e2a4772 > > diff --git a/builder/kojid b/builder/kojid > index ae4be90..5cf10a2 100755 > --- a/builder/kojid > +++ b/builder/kojid > @@ -457,7 +457,7 @@ class BuildRoot(object): > # run build > session.host.setBuildRootState(self.id,'BUILDING') > args = ['--no-clean'] > - if arch: > + if arch and arch != 'noarch': > args.extend(['--arch', arch]) > args.extend(['--rebuild', srpm]) > rv = self.mock(args) > > I'm providing this here should something happen and the builders get > reverted before I do the next koji upstream release. This patch has been reverted. Turns out it broke kernel-doc builds due to the funky way the kernel accomplishes a noarch subpackage :/ Instead we've re-ordered the arch listings for the builders so that the native arch is listed first, and thus will get the noarch builds. The problem with rpm macros not evaluating only seems to affect xen guests. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Jan 3 04:22:49 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Jan 2008 22:22:49 -0600 (CST) Subject: RFC: Infrastructure Voting Message-ID: I'd like to propose a formalized system for the Infrastructure team to vote. http://fedoraproject.org/wiki/MikeMcGrath/Voting I think this will make decision making a bit easier. It's possible I'm trying to fix something that isn't broken but it would still be nice to be able to tell people why things are the way they are and that a vote took place. While I take a great deal of pride in how transparent and open our team is I do, from time to time, hear complaints about us making decisions behind closed doors. I think this is mostly an educational gap but some of it is the ambiguous way we make decisions which is just kind of "ehh?" "ehh!" then stuff changes :) Thought? Comments? -Mike From paulo.banon at googlemail.com Thu Jan 3 08:15:27 2008 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 3 Jan 2008 09:15:27 +0100 Subject: RFC: Infrastructure Voting In-Reply-To: References: Message-ID: <7a41c4bc0801030015m2a86d5d0gf44598edc43b9751@mail.gmail.com> +1 - even so, IMO, we are already doing this :) Paulo On Jan 3, 2008 5:22 AM, Mike McGrath wrote: > > I'd like to propose a formalized system for the Infrastructure team to > vote. > > http://fedoraproject.org/wiki/MikeMcGrath/Voting > > I think this will make decision making a bit easier. It's possible I'm > trying to fix something that isn't broken but it would still be nice to be > able to tell people why things are the way they are and that a vote took > place. > > While I take a great deal of pride in how transparent and open our team is > I do, from time to time, hear complaints about us making decisions behind > closed doors. I think this is mostly an educational gap but some of it is > the ambiguous way we make decisions which is just kind of "ehh?" "ehh!" > then stuff changes :) > > Thought? Comments? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dapidc at gmail.com Thu Jan 3 10:30:19 2008 From: dapidc at gmail.com (Dapid Candra) Date: Thu, 3 Jan 2008 17:30:19 +0700 Subject: Introduction Message-ID: <1cf035e60801030230r6f421a62q705f07b7272f20dd@mail.gmail.com> Dear all, I just joined this list and I am interested to help in fedora development. I have been using Linux (mainly RedHat since version 4 up to 6.2, and RHEL 3 and up). I want to help in infrastructure since I think my best experiences are in system administration, networking and security. Please let me know what should I learn to start helping. Thank you and regards, Dapid Candra -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Thu Jan 3 14:21:53 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 3 Jan 2008 08:21:53 -0600 (CST) Subject: Introduction In-Reply-To: <1cf035e60801030230r6f421a62q705f07b7272f20dd@mail.gmail.com> References: <1cf035e60801030230r6f421a62q705f07b7272f20dd@mail.gmail.com> Message-ID: On Thu, 3 Jan 2008, Dapid Candra wrote: > Dear all, > > I just joined this list and I am interested to help in fedora development. > > I have been using Linux (mainly RedHat since version 4 up to 6.2, and RHEL 3 > and up). > > I want to help in infrastructure since I think my best experiences are in system administration, networking and security. > > Please let me know what should I learn to start helping. Security ehh? How is your selinux? Also we have a meeting today if you'd like to attend: http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From rordway at oregonstate.edu Thu Jan 3 16:51:29 2008 From: rordway at oregonstate.edu (Ryan Ordway) Date: Thu, 3 Jan 2008 08:51:29 -0800 Subject: RFC: Infrastructure Voting In-Reply-To: References: Message-ID: <63E13EFA-7DD8-403D-973A-8868BB8C0B6E@oregonstate.edu> On Jan 2, 2008, at 8:22 PM, Mike McGrath wrote: > Thought? Comments? +1 :-) Look, we're voting! -- Ryan Ordway E-mail: rordway at oregonstate.edu Unix Systems Administrator rordway at library.oregonstate.edu OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657 From a.badger at gmail.com Thu Jan 3 17:29:35 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 03 Jan 2008 09:29:35 -0800 Subject: Request to remove infofeed In-Reply-To: References: <1199290878.3921.18.camel@cutter> <20080102165219.GC20620@crow.redhat.com> <1199294205.3921.20.camel@cutter> Message-ID: <477D1B7F.4030604@gmail.com> Mike McGrath wrote: > On Wed, 2 Jan 2008, seth vidal wrote: > >> On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote: >>> On Wed, 2 Jan 2008, Luke Macken wrote: >>>> It looks like the infofeed has the RPM summary, description, and recent >>>> changelog. Bodhi doesn't know about any of these things, so it will >>>> require some database changes to store it. I've been meaning to have >>>> bodhi grab the recent RPM changelog upon submission for a little while now, >>>> so I don't have a problem implementing this, if we care? >>>> >>>> If we were to display these fields too, it would end up looking like >>>> >>>> name - summary >>>> package description >>>> >>>> update notes >>>> bug list >>>> >>>> rpm changelog >>>> >>>> Is this what we want? >>> Instead of storing this information in the bodhi db is there somewhere >>> else we can get it from? Koji or pkgdb for example. >> we have it in the repodata. Which is where the infofeed gets it from :) > > Thats kind of my point actually I know koji stores a lot of this > information in it's database even though the rpms themselves have the > information. I'd hate to continue to duplicate information that we're > already storing all over the place unless there's a real need for it. > +1 The packagedb uses information from the repodata as well. ATM I'm using some yum functions to download the repodata and create sqlite databases from it. Then using python-sqlalchemy to grab relevant information from the sqlite dbs. Relevant files are:: yumrepo.py: http://tinyurl.com/2rvtx4 script that syncs package description and summary with repodata: http://tinyurl.com/2kb75g -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Thu Jan 3 20:50:48 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 3 Jan 2008 15:50:48 -0500 Subject: Meeting Log - 2008-01-03 Message-ID: <20080103205048.GD18976@Max.nyc1.dsl.speakeasy.net> 15:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 15:01 * jima 15:01 * f13 15:01 -!- mether [n=ask at fedora/mether] has joined #fedora-meeting 15:01 < jima> (for now, at least) 15:01 * lmacken 15:02 < mmcgrath> dgilmore ricky skvidal paulobanon anyone I'm forgetting ping 15:02 < skvidal> pong 15:02 * skvidal is here 15:03 * poelcat lurking 15:03 * nirik is in the peanut gallery waiting for his olpc to charge up. 15:03 < mmcgrath> then lets get started 15:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 15:03 * iWolf thinks his day meeting was canceled 15:03 * dgilmore is here 15:03 < mmcgrath> .ticket 192 15:03 < zodbot> mmcgrath: #192 (Netapp low on free space) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/192 15:04 < mmcgrath> I've not heard back since RH got off break but I believe this has been ordered and is in transit. I'll follow up after the meeting and find out for sure. 15:04 < skvidal> can we just make the ticket come up automatically? :) 15:04 < skvidal> mmcgrath: do we have power/rackspace for it? 15:05 < mmcgrath> skvidal: No one in GIT has given me any estimates of space or power though I've been told yes, we do have space for these. 15:05 < skvidal> okie doke 15:05 < mmcgrath> worst case scenario we've got 3U of boxes to get rid of and potentially another box to make room for the storage. 15:05 < mmcgrath> any other questions on that? 15:06 < mmcgrath> .ticket 270 15:06 < zodbot> mmcgrath: #270 (Fedora Wiki allows editing raw HTML) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/270 15:07 < mmcgrath> This one's a bit interesting. 15:07 < mmcgrath> quaid: ping 15:07 < mmcgrath> stickster: ping 15:07 < skvidal> w/o the html editing the front wiki page doesn't work, does it? 15:07 < mmcgrath> we'd have to re-do it and many other pages actually 15:08 < skvidal> 15:08 < mmcgrath> though the /wiki/ landing page isn't as important as it once was so I suspect that won't be too difficult. 15:08 < skvidal> disabling the html translator is easy 15:08 < loupgaroublond> can you disable it on a per page basis? 15:08 < skvidal> no 15:08 < skvidal> I believe it is for the whole site or not at all 15:08 < mmcgrath> what I am worried about (and I'd like to contact the docs guys to verify) is that removing html editing might completely disrupt the way the docs teams workflow happens. 15:09 < mmcgrath> Since we're worried about a specific set of commands, I think mod_security may be an easy fix for now. 15:09 * mmcgrath curses wiki 15:09 < mmcgrath> it is a 4 letter word. 15:10 < skvidal> mike is too 15:10 < skvidal> and seth :) 15:10 < mmcgrath> heh 15:10 < dgilmore> good think Dennis is not :) 15:10 < mmcgrath> regardless we're going to have to take a closer look and see exactly what impact we'll have if we disable html or if mod_security is the way to go. 15:10 < poelcat> would that affect existing pages where raw html is used? 15:10 * mmcgrath doesn't think ricky/paulobanon are around to discuss 15:11 < skvidal> poelcat: in the wiki, yes 15:11 < skvidal> poelcat: they would stop working 15:11 < poelcat> that would break all meeting summaries i've posted for releng :) 15:11 < skvidal> b/c the wiki wouldn't know how to parse them to format them 15:11 < skvidal> good times 15:11 < mmcgrath> it'd just look ugly. 15:11 < poelcat> and other "pretty" irc logs 15:11 < mmcgrath> The other thing is we're looking at 1.6 but I'll bring that up later. 15:12 < mmcgrath> Anyone have anything else regarding 270? 15:13 < mmcgrath> .ticket 302 15:13 < zodbot> mmcgrath: #302 (Moin patches) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/302 15:13 < mmcgrath> .fas abob 15:13 * mmcgrath doesn't think abob typically hangs out on IRC. 15:13 < zodbot> mmcgrath: abob 'Daniel Drown' 15:14 * mmcgrath tries to ping mrbawb in #fedora-admin 15:15 < mmcgrath> We'll skip that for now. 15:15 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Moin 1.6 upgrade. 15:15 < mmcgrath> so the Moin guys have released a new version. meanwhile we've been doing a lot of work on Moin. 15:15 < mmcgrath> I'm not sure that any of our patches have made it into 1.6. 15:15 < dgilmore> how badly have we forked moin? 15:15 < mmcgrath> well as it stands with what is in production, not a terrible amount. 15:16 < mmcgrath> AFAIK just the ACL patch and mdomsch's forking patch. 15:16 < mmcgrath> abadger1999 might have applied another one (he mentioned he might be late, had a quick emergency to take care of) 15:16 < mmcgrath> but there's other work thats been going on that we've been intending to apply to fix some of our issues. 15:16 < dgilmore> that should be able to be ported to 1.6 easily then 15:17 < mmcgrath> we may have to put this off till abadger1999 or MrBawb get back. there's been some discussions on the list but its not clear how far they've gotten with each part. 15:17 < mmcgrath> I know MrBawb has been working to get his patches into upstream. 15:18 < mmcgrath> Anyone have anything to add to that? 15:18 < mmcgrath> a great deal of our time is consumed by the wiki right now, which is quite unfortunate. 15:19 -!- fchiulli [n=824c4010 at gateway/web/cgi-irc/ircatwork.com/x-7881b9a46fcf2aaa] has joined #fedora-meeting 15:19 < mmcgrath> alrighty, moving on 15:19 < mmcgrath> fchiulli: howdy 15:20 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Schedule 15:20 < mmcgrath> http://fedoraproject.org/wiki/Infrastructure/Schedule 15:20 < mmcgrath> Nothing new with the sponsorship, there's really not been much going on because of the holidays. 15:21 < mmcgrath> Nothing new with docs though expect more docs to come soon. 15:21 < mmcgrath> no new SOP's and no new sponsors. 15:21 < skvidal> alright good times 15:21 < mmcgrath> very good 15:21 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Voting 15:21 -!- ClausReheis [n=ClausReh at fedora/ClausReheis] has quit "Leaving." 15:21 < mmcgrath> Did everyone have a chance to read over - http://fedoraproject.org/wiki/MikeMcGrath/Voting ? 15:22 < mmcgrath> There's nothing terribly ground breaking there except maybe the fact that some people have more of a vote then others and that everyone can vote. 15:22 * ricky appears. 15:22 < mmcgrath> Both of those aspects make this unique over other teams in Fedora 15:22 < mmcgrath> ricky: yo 15:23 < loupgaroublond> i wanted to ask about the postpone criteria 15:23 < mmcgrath> Does anyone oppose a more strict voting guideline like this? Anyone particularly for it? 15:23 -!- petreu [n=peter at fedora/Standby] has quit "( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )" 15:23 < f13> I don't oppose. I haven't looked it over closely, but I trust your judgement 15:24 < skvidal> mmcgrath: curiousity 15:24 < loupgaroublond> it's hard to predict in advance what percentage of the votes that are *p mean it actually should be postponed, compared to just simple +/-N 15:24 < skvidal> what's the plus? 15:24 < skvidal> and what keeps it working? 15:24 < mmcgrath> skvidal: the main one is a firm decision making process. 15:25 < skvidal> as opposed to what? 15:25 < mmcgrath> as opposed to the way it is now which we sort of talk about it and then we talk about it on the list, some people say yes some people say no and then something just sort of happens. 15:26 < mmcgrath> We do ok with it but I see lots of teams unable to actually make a decision and I want to make sure we avoid that. 15:26 < stickster> mmcgrath: pong 15:26 < skvidal> okay - I wasn't clear that the way things are is a big problem 15:27 < skvidal> and I was worried that we're adding complexity and rigor where it isn't needed 15:27 * mmcgrath worries about that too. 15:27 < skvidal> which creates something else a new contributor would need to learn to effectively contribute 15:27 < mmcgrath> but, for example, the monotone discussion a few weeks back made me re-think it. 15:27 < loupgaroublond> mmcgrath: i'm wondering if having postpone be part of the vote is a good idea, or if it's better to have a pre-vote vote 15:27 < mmcgrath> stickster: you going to be around for a bit? 15:27 < stickster> mmcgrath: yes 15:27 < mmcgrath> stickster: thanks. 15:27 < stickster> mmcgrath: I didn't realize we made "heavy" use of raw HTML 15:28 < stickster> I think the only place I've used it is personal pages IIRC 15:28 < stickster> And if it's disabled on the wiki, meh. 15:28 < mmcgrath> stickster: so docs doesn't use html much in their process? 15:28 < stickster> mmcgrath: You're talking about using {{{#!html ...}}} in the wiki, right? 15:28 < ricky> Yup. 15:28 < stickster> Then no. 15:29 < stickster> In fact, I don't think rely on that for anything. 15:29 < stickster> s/rely/we rely/ 15:29 < mmcgrath> stickster: I had seen you mention - 15:29 < mmcgrath>

This is a paragraph of text that 15:29 < mmcgrath> has lots of good info for you!

15:29 < mmcgrath> in an email, was that for something else or for the wiki? 15:29 * mmcgrath just wanted to clear it up. 15:31 < mmcgrath> loupgaroublond: not ignoring you, we'll get back to voting in a moment. 15:31 < stickster> mmcgrath: Oh sorry. 15:31 < stickster> mmcgrath: I was trying there to make the point that in some future content management system, being able to set up the use of attributes on XHTML makes it more useful and portable back and forth with good content markup systems like DocBook 15:31 < stickster> Has nothing to do with moin, though, don't worry 15:31 < mmcgrath> solid. 15:32 * mmcgrath really needs to go through the docs process once :) 15:32 < ricky> As a side note, I'm not sure that mod_security can do great filtering on form submissions. 15:32 < stickster> mmcgrath: We'll get into this at FUDCon, mmkay? 15:32 < stickster> Ouch 15:32 < mmcgrath> stickster: will do, thanks. 15:32 < loupgaroublond> mmcgrath: np 15:32 < ricky> I wouldn't even call it XSS, because people are explicitly allowed to insert their own HTML. 15:32 < stickster> That sounded like "Don't worry your li'l head about it"... not meant badly, I assure you! 15:32 * stickster shuts up now 15:32 < mmcgrath> ricky: it should be able to filter that stuff just fine. For example we could disallow people from submiting a