From a.badger at gmail.com Sun Dec 2 18:22:06 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 02 Dec 2007 10:22:06 -0800 Subject: [Fwd: Cron /usr/local/bin/restart-memhogs.sh] Message-ID: <4752F7CE.9040701@gmail.com> Looks like smolt is hitting the limit of 700MB pretty easily. I was going to up the limit but I found that smolt was timing out even when running with less than 700MB of memory. Restarting the server stopped that from happening. So one possibility is that once smolt allocates so much memory, some portion of what it does takes too much time to scan through that memory. If that's so we actually want to decrease the amount of memory smolt can allocate before being restarted. Another possibility is that the smolt server is getting stuck somewhere in processing and that's preventing either the smolt server or the database from processing future sendProfile's correctly. In this scenario, restarting the server due to memory usage is fixing this as a side effect. We really want to find and fix the bug if this is the case. -------- Original Message -------- Subject: Cron /usr/local/bin/restart-memhogs.sh Date: Sat, 1 Dec 2007 18:30:02 -0700 From: root at app4.fedora.phx.redhat.com (Cron Daemon) To: root at app4.fedora.phx.redhat.com Restarting smolt 31069 RSS: 691732 smolt: stopped smolt: started -Toshio From mmcgrath at redhat.com Sun Dec 2 18:28:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 02 Dec 2007 12:28:50 -0600 Subject: [Fwd: Cron /usr/local/bin/restart-memhogs.sh] In-Reply-To: <4752F7CE.9040701@gmail.com> References: <4752F7CE.9040701@gmail.com> Message-ID: <4752F962.3040609@redhat.com> Toshio Kuratomi wrote: > Looks like smolt is hitting the limit of 700MB pretty easily. I was > going to up the limit but I found that smolt was timing out even when > running with less than 700MB of memory. Restarting the server stopped > that from happening. > > So one possibility is that once smolt allocates so much memory, some > portion of what it does takes too much time to scan through that > memory. If that's so we actually want to decrease the amount of > memory smolt can allocate before being restarted. > > Another possibility is that the smolt server is getting stuck > somewhere in processing and that's preventing either the smolt server > or the database from processing future sendProfile's correctly. In > this scenario, restarting the server due to memory usage is fixing > this as a side effect. We really want to find and fix the bug if this > is the case. Smolt is running heaver than normal right now as all of the Fedora clients are doing their monthly checkin over the next few days. Fortunately smolt hasn't really been restarted until this heavier period. Unfortunately now that we're seeing a bunch of check-ins we'll have to take a closer look into what is going on. It should be pretty easy for us to verify on another machine. -Mike From mmcgrath at redhat.com Sun Dec 2 21:57:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 02 Dec 2007 15:57:26 -0600 Subject: FAS reminder about hosted groups Message-ID: <47532A46.4000104@redhat.com> When creating groups for hosted, make sure cla_done is a requisite. There's a bug in the current account system code where sometimes this requisite goes away when adding people to the group. -Mike From mmcgrath at redhat.com Mon Dec 3 22:24:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 03 Dec 2007 16:24:11 -0600 Subject: Mail lists for hosted Message-ID: <4754820B.70106@redhat.com> Anyone know of any mail list software besides mailman that they've used and like? I ask because I'm not a huge fan of mailman. The hosted mailing list will probably have precedence and I think it is likely that whatever we do in hosted is what we'll end up doing with the rest of Fedora's mail lists when the time comes. -Mike From skvidal at fedoraproject.org Mon Dec 3 22:33:19 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 03 Dec 2007 17:33:19 -0500 Subject: Mail lists for hosted In-Reply-To: <4754820B.70106@redhat.com> References: <4754820B.70106@redhat.com> Message-ID: <1196721199.27005.18.camel@cutter> On Mon, 2007-12-03 at 16:24 -0600, Mike McGrath wrote: > Anyone know of any mail list software besides mailman that they've used > and like? I ask because I'm not a huge fan of mailman. The hosted > mailing list will probably have precedence and I think it is likely that > whatever we do in hosted is what we'll end up doing with the rest of > Fedora's mail lists when the time comes. > then we should stick with mailman, if only b/c it is definitely the path of least resistance and it is what everyone knows. alternatively you can look at the neverending perl-module-pain that is sympa -sv From mastahnke at gmail.com Mon Dec 3 23:52:41 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 3 Dec 2007 17:52:41 -0600 Subject: Mail lists for hosted In-Reply-To: <1196721199.27005.18.camel@cutter> References: <4754820B.70106@redhat.com> <1196721199.27005.18.camel@cutter> Message-ID: <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> On Dec 3, 2007 4:33 PM, seth vidal wrote: > > On Mon, 2007-12-03 at 16:24 -0600, Mike McGrath wrote: > > Anyone know of any mail list software besides mailman that they've used > > and like? I ask because I'm not a huge fan of mailman. The hosted > > mailing list will probably have precedence and I think it is likely that > > whatever we do in hosted is what we'll end up doing with the rest of > > Fedora's mail lists when the time comes. > > > > then we should stick with mailman, if only b/c it is definitely the path > of least resistance and it is what everyone knows. > > alternatively you can look at the neverending perl-module-pain that is > sympa > > -sv > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > several projects are switching to google-groups for mailling lists. I am not sure I like the idea. It's certainly isn't open source, but I thought I'd throw it out there as an option. stahnma From jason at 3dogs.us Tue Dec 4 00:19:07 2007 From: jason at 3dogs.us (Jason Hartley) Date: Mon, 3 Dec 2007 19:19:07 -0500 Subject: Mail lists for hosted In-Reply-To: <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> References: <4754820B.70106@redhat.com> <1196721199.27005.18.camel@cutter> <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> Message-ID: <113193470712031619tae3ee31vd69a2b65f049ab42@mail.gmail.com> On 12/3/07, Michael Stahnke wrote: > On Dec 3, 2007 4:33 PM, seth vidal wrote: > > > > On Mon, 2007-12-03 at 16:24 -0600, Mike McGrath wrote: > > > Anyone know of any mail list software besides mailman that they've used > > > and like? I ask because I'm not a huge fan of mailman. The hosted > > > mailing list will probably have precedence and I think it is likely that > > > whatever we do in hosted is what we'll end up doing with the rest of > > > Fedora's mail lists when the time comes. > > > > > > > then we should stick with mailman, if only b/c it is definitely the path > > of least resistance and it is what everyone knows. > > > > alternatively you can look at the neverending perl-module-pain that is > > sympa > > > > -sv > > > > > > > > _______________________________________________ > > Fedora-infrastructure-list mailing list > > Fedora-infrastructure-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > several projects are switching to google-groups for mailling lists. I > am not sure I like the idea. It's certainly isn't open source, but I > thought I'd throw it out there as an option. > stahnma > What kind of pains are you having with Mailman? Google-groups is nice, but I think Mailman edges out with a few more features. I briefly looked Google-groups to replace Mailman that I use for my personal mailing lists. Maybe it is that I am more familiar with Mailman, but I felt that Mailman was more mailing list centric. Whereas Google-groups leaned more towards a discussion group. There is also the whole control argument, but I do not know if that applies here. Regards, Jason Hartley From opensource at till.name Tue Dec 4 00:20:04 2007 From: opensource at till.name (Till Maas) Date: Tue, 04 Dec 2007 01:20:04 +0100 Subject: Mail lists for hosted In-Reply-To: <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> References: <4754820B.70106@redhat.com> <1196721199.27005.18.camel@cutter> <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> Message-ID: <200712040120.05970.opensource@till.name> On Di Dezember 4 2007, Michael Stahnke wrote: > several projects are switching to google-groups for mailling lists. I > am not sure I like the idea. It's certainly isn't open source, but I > thought I'd throw it out there as an option. Afaik, groups is only an interface to the usenet[1], or does google do something else, too? There is a news-to-mail interface available for Fedora's mailing lists[2], so maybe this can be used in google groups, too, like, e.g. http://groups.google.de/group/ru-firebird?lnk=gschg which is also available via gmane: http://dir.gmane.org/gmane.comp.db.firebird.russian Regards, Till [1] http://en.wikipedia.org/wiki/Usenet [2] http://dir.gmane.org/index.php?prefix=gmane.linux.redhat.fedora From skvidal at fedoraproject.org Tue Dec 4 01:26:07 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 03 Dec 2007 20:26:07 -0500 Subject: Mail lists for hosted In-Reply-To: <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> References: <4754820B.70106@redhat.com> <1196721199.27005.18.camel@cutter> <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> Message-ID: <1196731568.27005.22.camel@cutter> On Mon, 2007-12-03 at 17:52 -0600, Michael Stahnke wrote: > several projects are switching to google-groups for mailling lists. I > am not sure I like the idea. It's certainly isn't open source, but I > thought I'd throw it out there as an option. > stahnma > google groups is not open source and is therefore a non-starter. -sv From michael.yingbull at gmail.com Tue Dec 4 05:26:43 2007 From: michael.yingbull at gmail.com (Michael Yingbull) Date: Mon, 3 Dec 2007 23:26:43 -0600 Subject: Mail lists for hosted In-Reply-To: <1196731568.27005.22.camel@cutter> References: <4754820B.70106@redhat.com> <1196721199.27005.18.camel@cutter> <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> <1196731568.27005.22.camel@cutter> Message-ID: <8c0317740712032126n78a63715naef815ecf5797e29@mail.gmail.com> I've heard good things about sympa (aside from issues of being in a maze of perl modules, all alike...). I've not looked at it with an technical eye lately, however. On Dec 3, 2007 7:26 PM, seth vidal wrote: > > On Mon, 2007-12-03 at 17:52 -0600, Michael Stahnke wrote: > > > several projects are switching to google-groups for mailling lists. I > > am not sure I like the idea. It's certainly isn't open source, but I > > thought I'd throw it out there as an option. > > stahnma > > > > google groups is not open source and is therefore a non-starter. > > -sv > > > _______________________________________________ > 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 skvidal at fedoraproject.org Tue Dec 4 19:49:37 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 04 Dec 2007 14:49:37 -0500 Subject: Mail lists for hosted In-Reply-To: <8c0317740712032126n78a63715naef815ecf5797e29@mail.gmail.com> References: <4754820B.70106@redhat.com> <1196721199.27005.18.camel@cutter> <7874d9dd0712031552t6e625757h5df4ea12a37c18c0@mail.gmail.com> <1196731568.27005.22.camel@cutter> <8c0317740712032126n78a63715naef815ecf5797e29@mail.gmail.com> Message-ID: <1196797777.26017.1.camel@cutter> On Mon, 2007-12-03 at 23:26 -0600, Michael Yingbull wrote: > I've heard good things about sympa (aside from issues of being in a > maze of perl modules, all alike...). It has some neat features. A couple of them I really like. For example: log in to the web interface and you can go to the mail archive, click on any message and say "send this to me" and it will mail it to you again just like it was a new email. Really handy if you accidentally delete a list email. > I've not looked at it with an technical eye lately, however. The perl modules needed for it are a seriously special kind of hell and it breaks in, umm, obscure ways when it runs out of disk space but it's not impossible to use. -sv From mmcgrath at redhat.com Wed Dec 5 03:13:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 04 Dec 2007 21:13:06 -0600 Subject: New hosted setup Message-ID: <47561742.9050900@redhat.com> I'm nearing completion of the hosted setup and I'm at a point where I can either make some temporary convoluted puppet configs, or I can just disable the puppet configs for the production instance and get started on the new instance. I've chosen the latter. If you have any changes to make to hosted please coordinate it with me. I expect the new site to be up by the end of the week at the latest. -Mike From Matt_Domsch at dell.com Wed Dec 5 19:50:22 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 5 Dec 2007 13:50:22 -0600 Subject: Wanted: more Mirror Wranglers Message-ID: <20071205195022.GC30906@auslistsprd01.us.dell.com> It's been a little over a year since I claimed the self-appointed title of Fedora Mirror Wrangler. I have received quite a few kudos for doing it - and it's fun coordinating a few hundred mirrors, providing the best download experience for a few hundred thousand users. For the benefit of Fedora as a whole, I'd like additional people to step up and become Mirror Wranglers too. Tasks include: * understanding the database schema and code behind MirrorManager, and being able to enhance it as necessary * moderating new mirror requests * moderating the mirror-list and mirror-list-d requests * participating on these lists * manually scrubbing the database occasionally (I added ~30 F8 mirrors a few weeks ago where they were mirrors at some point, but hadn't added themselves into MM, or had added themselves incorrectly). Any volunteers? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From skvidal at fedoraproject.org Wed Dec 5 20:13:34 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 05 Dec 2007 15:13:34 -0500 Subject: epylog log reports Message-ID: <1196885614.8994.26.camel@cutter> Hi guys, I've added excludes and weeded out a ton of crap from the epylog reports. You'll note that: 1. the report is now down to about 1/6th the size it was 2. there is still an metric buttload of stuff coming in the logs The stuff showing up there now are legitimate reports. If you see something in the sections at the bottom then it needs to be fixed. Please do so. :) -sv From skvidal at fedoraproject.org Wed Dec 5 20:19:59 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 05 Dec 2007 15:19:59 -0500 Subject: epylog log reports In-Reply-To: <1196885614.8994.26.camel@cutter> References: <1196885614.8994.26.camel@cutter> Message-ID: <1196885999.8994.28.camel@cutter> On Wed, 2007-12-05 at 15:13 -0500, seth vidal wrote: > Hi guys, > I've added excludes and weeded out a ton of crap from the epylog > reports. You'll note that: > > 1. the report is now down to about 1/6th the size it was > 2. there is still an metric buttload of stuff coming in the logs > > The stuff showing up there now are legitimate reports. If you see > something in the sections at the bottom then it needs to be fixed. > > Please do so. :) > One more thing - if you can't fix it but you know how or you have a question about how to fix something or whatever, ping me and I'll help. -sv From damian.myerscough at gmail.com Wed Dec 5 20:10:11 2007 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Wed, 05 Dec 2007 21:10:11 +0100 Subject: Wanted: more Mirror Wranglers In-Reply-To: <20071205195022.GC30906@auslistsprd01.us.dell.com> References: <20071205195022.GC30906@auslistsprd01.us.dell.com> Message-ID: <1196885411.4243.1.camel@dhcppc0> Hello, It's been awhile since I manage to give a good contribution to the fedora project, anyways I think I could help with this as I am getting a little more time now to contribute to the Fedora Project. On Wed, 2007-12-05 at 13:50 -0600, Matt Domsch wrote: > It's been a little over a year since I claimed the self-appointed > title of Fedora Mirror Wrangler. I have received quite a few kudos for > doing it - and it's fun coordinating a few hundred mirrors, providing > the best download experience for a few hundred thousand users. > > For the benefit of Fedora as a whole, I'd like additional people to > step up and become Mirror Wranglers too. Tasks include: > > * understanding the database schema and code behind MirrorManager, and > being able to enhance it as necessary > > * moderating new mirror requests > > * moderating the mirror-list and mirror-list-d requests > > * participating on these lists > > * manually scrubbing the database occasionally (I added ~30 F8 mirrors > a few weeks ago where they were mirrors at some point, but hadn't > added themselves into MM, or had added themselves incorrectly). > > > Any volunteers? > > Thanks, > Matt > -- Regards, Damian Myerscough From Matt_Domsch at dell.com Wed Dec 5 23:14:06 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 5 Dec 2007 17:14:06 -0600 Subject: Wanted: more Mirror Wranglers In-Reply-To: <1196885411.4243.1.camel@dhcppc0> References: <20071205195022.GC30906@auslistsprd01.us.dell.com> <1196885411.4243.1.camel@dhcppc0> Message-ID: <20071205231406.GC20314@auslistsprd01.us.dell.com> On Wed, Dec 05, 2007 at 09:10:11PM +0100, Damian Myerscough wrote: > Hello, > > It's been awhile since I manage to give a good contribution to the > fedora project, anyways I think I could help with this as I am getting a > little more time now to contribute to the Fedora Project. fantastic! I've received a few offers. I'm going to let the request sit out there for a few days, then start coordinating the volunteers. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From kupfer at stw-bonn.de Thu Dec 6 01:30:17 2007 From: kupfer at stw-bonn.de (Andreas Kupfer) Date: Thu, 6 Dec 2007 02:30:17 +0100 Subject: Wanted: more Mirror Wranglers In-Reply-To: <20071205195022.GC30906@auslistsprd01.us.dell.com> References: <20071205195022.GC30906@auslistsprd01.us.dell.com> Message-ID: <20071206023017.f78f46be.kupfer@stw-bonn.de> On Wed, 5 Dec 2007 13:50:22 -0600 Matt Domsch wrote: > * understanding the database schema and code behind MirrorManager, and > being able to enhance it as necessary > > * moderating new mirror requests > > * moderating the mirror-list and mirror-list-d requests > > * participating on these lists > > * manually scrubbing the database occasionally (I added ~30 F8 mirrors > a few weeks ago where they were mirrors at some point, but hadn't > added themselves into MM, or had added themselves incorrectly). > > > Any volunteers? I'm not that good in Python, but I could certainly help with the other stuff. Yours, Andreas aka ScottyTM -- The figures looked more or less human. And they were engaged in religion. You could tell by the knives (it's not murder if you do it for a god). -- (Terry Pratchett, Small Gods) From jonathansteffan at gmail.com Thu Dec 6 21:28:13 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 6 Dec 2007 14:28:13 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath Message-ID: <20071206142813.5dcc973f@damaestrojr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah, what a wonderful scholastic assignment. It's also great that Mike is going to have to open the letter once it actually makes to him. Dear Mr. McGrath, As long time Fedora developers, we both have watched and lived through the growing pains of Fedora releases. With the onset of the merging between core and extras, we have successfully created the needed infrastructure on which even basic Linux users can create their own Fedora-based derivative distribution. Along with this achievement comes the task of providing hosting infrastructure for an average user/developer to be able to share his/her creation with the world. An additional benefit in being directly involved in the sharing of the "Spins" is the ability to data mine what packages people are including in custom spins as to give our developer base more focus. To be able to fulfill this task, please consider requesting additional resources to archive signed updates so that they can be publicly accessed for the duration of a release life-cycle. The long road of Fedora development has been bumpy and even not enjoyable at times. Throughout the duration of the Fedora 7 release, we have made some very amazing changes that helped to open Fedora up to the masses. One of the most community-based features is the ability to Re-Mix and Re-Spin the distribution as the end-user sees fit. Being the server team lead for Fedora Unity, I've had to come up with unique ways to share the Re-Spins we compose. After trying many approaches with different technologies, we have settled on using Jigdo, the jigsaw downloader. Debian has used Jigdo for some time now and after poking their system for a while I've seen they keep every update they push. I do understand that Debian is considered a stable distribution much in the way RHEL is considered stable. This makes the updates tree not as active and it is easier to find mirrors to carry the full data set for an extended period of time. We, however, need to find a way to offer this same extended life for signed packages that have hit the Fedora updates tree. The amount of storage and bandwidth able to be saved can be illustrated by a simple comparison between the efficiency of chopping up a 3.4GB iso9660 file system arbitrarily (by a static chunk size) and the same file system based on contents (file by file.) For a BitTorrent, Fedora's current choice for sharing Spins, the hosted data is only valid for a given chunk on a single ISO. This data's footprint (equal to the combined chunk sizes of the entire torrent) can be used for nothing but this Spin. To be able to host 5 Spins composed from similar trees via BitTorrent, we now have a footprint of 17GB, not to mention "seeders" have to run BitTorrent software to be able to contribute to the swarm. Alternatively, Jigdo can be used to reduce the footprint of these 5 Spins to about 4GB. The amount of additional data needing to be hosted for each Spin, in addition to what data is already pushed to the mirrors, is about 150MB per ISO with anaconda and about 200KB for ISOs without the installer bits. To help illustrate the efficiency of using Jigdo vs BitTorrent, the footprint for 250 Spins is 850GB for BitTorrent and about 40GB for Jigdo. Additionally, a reduction in overhead can be achieved by removing the need for the BitTorrent tracker and all related network traffic without requiring any additional work on the part of mirror administrators. The current updates system is getting better each release, but I think we should adjust our policies to also have an ?updates-archive? repository. This repository will include all signed updates that had once lived in the updates repo, for the duration of the releases life-cycle. I don't expect all mirrors would want to carry this extra data so making the new repo optional will be a must. With the new MirrorManager, we will be able to effectively point users at mirrors that have been willing to take on the extra footprint. These requests to MirrorManager could be used to compose reports on what packages the community is utilizing most, allowing us to better focus our efforts. By providing an unified point of entry for data, we will be able to also log requests for package data found on in-house and non-official spins. By utilizing the abilities of MirrorManager to return specific mirrors for pre-defined IP blocks, we will enable end-users and companies to download from on-site mirrors while maintaining complete transparency. I hope that with advancements in Jigdo client software we will be able to look at using Jigdo to host our official images. Please let me know your thoughts on this matter. As always, thanks, - -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 - -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWGltrRJs5w2Gr1kRAinaAKCSRaTWjuCtsGQKWsvuhCXKm0qSdQCfbj/N 52VVTOYXSQn4qLlfXThEpMg= =ciP1 -----END PGP SIGNATURE----- From poelstra at redhat.com Thu Dec 6 21:38:12 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 06 Dec 2007 13:38:12 -0800 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206142813.5dcc973f@damaestrojr> References: <20071206142813.5dcc973f@damaestrojr> Message-ID: <47586BC4.6040808@redhat.com> Jonathan Steffan said the following on 12/06/2007 01:28 PM Pacific Time: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ah, what a wonderful scholastic assignment. It's also great that Mike > is going to have to open the letter once it actually makes to him. > > Dear Mr. McGrath, > > As long time Fedora developers, we both have watched and lived through > the growing pains of Fedora releases. With the onset of the merging > between core and extras, we have successfully created the needed > infrastructure on which even basic Linux users can create their own > Fedora-based derivative distribution. Along with this achievement comes > the task of providing hosting infrastructure for an average > user/developer to be able to share his/her creation with the world. An > additional benefit in being directly involved in the sharing of the > "Spins" is the ability to data mine what packages people are including > in custom spins as to give our developer base more focus. To be able to > fulfill this task, please consider requesting additional resources to > archive signed updates so that they can be publicly accessed for the > duration of a release life-cycle. > > The long road of Fedora development has been bumpy and even not > enjoyable at times. Throughout the duration of the Fedora 7 release, we > have made some very amazing changes that helped to open Fedora up to > the masses. One of the most community-based features is the ability to > Re-Mix and Re-Spin the distribution as the end-user sees fit. Being the > server team lead for Fedora Unity, I've had to come up with unique ways > to share the Re-Spins we compose. After trying many approaches with > different technologies, we have settled on using Jigdo, the jigsaw > downloader. Debian has used Jigdo for some time now and after poking > their system for a while I've seen they keep every update they push. I > do understand that Debian is considered a stable distribution much in > the way RHEL is considered stable. This makes the updates tree not as > active and it is easier to find mirrors to carry the full data set for > an extended period of time. We, however, need to find a way to offer > this same extended life for signed packages that have hit the Fedora > updates tree. > > The amount of storage and bandwidth able to be saved can be illustrated > by a simple comparison between the efficiency of chopping up a 3.4GB > iso9660 file system arbitrarily (by a static chunk size) and the same > file system based on contents (file by file.) For a BitTorrent, > Fedora's current choice for sharing Spins, the hosted data is only > valid for a given chunk on a single ISO. This data's footprint (equal > to the combined chunk sizes of the entire torrent) can be used for > nothing but this Spin. To be able to host 5 Spins composed from similar > trees via BitTorrent, we now have a footprint of 17GB, not to mention > "seeders" have to run BitTorrent software to be able to contribute to > the swarm. Alternatively, Jigdo can be used to reduce the footprint of > these 5 Spins to about 4GB. The amount of additional data needing to be > hosted for each Spin, in addition to what data is already pushed to the > mirrors, is about 150MB per ISO with anaconda and about 200KB for ISOs > without the installer bits. To help illustrate the efficiency of using > Jigdo vs BitTorrent, the footprint for 250 Spins is 850GB for > BitTorrent and about 40GB for Jigdo. Additionally, a reduction in > overhead can be achieved by removing the need for the BitTorrent > tracker and all related network traffic without requiring any > additional work on the part of mirror administrators. > > The current updates system is getting better each release, but I think > we should adjust our policies to also have an ?updates-archive? > repository. This repository will include all signed updates that had > once lived in the updates repo, for the duration of the releases > life-cycle. I don't expect all mirrors would want to carry this extra > data so making the new repo optional will be a must. With the new > MirrorManager, we will be able to effectively point users at mirrors > that have been willing to take on the extra footprint. These requests > to MirrorManager could be used to compose reports on what packages the > community is utilizing most, allowing us to better focus our efforts. > By providing an unified point of entry for data, we will be able to > also log requests for package data found on in-house and non-official > spins. By utilizing the abilities of MirrorManager to return specific > mirrors for pre-defined IP blocks, we will enable end-users and > companies to download from on-site mirrors while maintaining complete > transparency. I hope that with advancements in Jigdo client software we > will be able to look at using Jigdo to host our official images. Please > let me know your thoughts on this matter. > > Hasn't the door already been opened for this? http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19 http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19#t13:44 Also, I see an incomplete feature page here: http://fedoraproject.org/wiki/Features/JigdoRelease John From jkeating at redhat.com Thu Dec 6 21:42:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 6 Dec 2007 16:42:57 -0500 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206142813.5dcc973f@damaestrojr> References: <20071206142813.5dcc973f@damaestrojr> Message-ID: <20071206164257.56c1884f@redhat.com> On Thu, 6 Dec 2007 14:28:13 -0700 Jonathan Steffan wrote: > The amount of storage and bandwidth able to be saved can be > illustrated by a simple comparison between the efficiency of chopping > up a 3.4GB iso9660 file system arbitrarily (by a static chunk size) > and the same file system based on contents (file by file.) For a > BitTorrent, Fedora's current choice for sharing Spins, the hosted > data is only valid for a given chunk on a single ISO. This data's > footprint (equal to the combined chunk sizes of the entire torrent) > can be used for nothing but this Spin. To be able to host 5 Spins > composed from similar trees via BitTorrent, we now have a footprint > of 17GB, not to mention "seeders" have to run BitTorrent software to > be able to contribute to the swarm. Alternatively, Jigdo can be used > to reduce the footprint of these 5 Spins to about 4GB. The amount of > additional data needing to be hosted for each Spin, in addition to > what data is already pushed to the mirrors, is about 150MB per ISO > with anaconda and about 200KB for ISOs without the installer bits. To > help illustrate the efficiency of using Jigdo vs BitTorrent, the > footprint for 250 Spins is 850GB for BitTorrent and about 40GB for > Jigdo. Additionally, a reduction in overhead can be achieved by > removing the need for the BitTorrent tracker and all related network > traffic without requiring any additional work on the part of mirror > administrators. Question. Spins.fp.o is mostly about Live images no? Live images are essentially a big squasfs image wrapped up in an iso with some bootable stuff involved? How would jigdo possibly help here? -- 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 opensource at till.name Thu Dec 6 21:53:22 2007 From: opensource at till.name (Till Maas) Date: Thu, 06 Dec 2007 22:53:22 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206142813.5dcc973f@damaestrojr> References: <20071206142813.5dcc973f@damaestrojr> Message-ID: <200712062253.26813.opensource@till.name> On Do Dezember 6 2007, Jonathan Steffan wrote: > The current updates system is getting better each release, but I think > we should adjust our policies to also have an ?updates-archive? > repository. This repository will include all signed updates that had > once lived in the updates repo, for the duration of the releases > life-cycle. I don't expect all mirrors would want to carry this extra Once the repositories are presto enabled, an updates-archive with all the delta rpms would not take as much space as a full rpm repository but provide the same functionality. 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 jonathansteffan at gmail.com Thu Dec 6 22:18:37 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 6 Dec 2007 15:18:37 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <200712062253.26813.opensource@till.name> References: <20071206142813.5dcc973f@damaestrojr> <200712062253.26813.opensource@till.name> Message-ID: <20071206151837.51096b7c@damaestrojr> On Thu, 06 Dec 2007 22:53:22 +0100 Till Maas wrote: > On Do Dezember 6 2007, Jonathan Steffan wrote: > > > The current updates system is getting better each release, but I > > think we should adjust our policies to also have an > > ?updates-archive? repository. This repository will include all > > signed updates that had once lived in the updates repo, for the > > duration of the releases life-cycle. I don't expect all mirrors > > would want to carry this extra > > Once the repositories are presto enabled, an updates-archive with all > the delta rpms would not take as much space as a full rpm repository > but provide the same functionality. Yes, this is correct. I left it out of the letter due to the need for a specific client to deal with the presto data. PyJigdo could do such a task, if this is the route we want to go. -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From jonathansteffan at gmail.com Thu Dec 6 22:29:25 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 6 Dec 2007 15:29:25 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206164257.56c1884f@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <20071206164257.56c1884f@redhat.com> Message-ID: <20071206152925.2daa8bc9@damaestrojr> On Thu, 6 Dec 2007 16:42:57 -0500 Jesse Keating wrote:. > > Question. Spins.fp.o is mostly about Live images no? Live images are > essentially a big squasfs image wrapped up in an iso with some > bootable stuff involved? How would jigdo possibly help here? This is correct. In it's current state, jigdo is only of value for installer images. I have a goal of getting pyJigdo to be able to deal with a squashfs, pulling the bits from rpms and then sticking them into the squash. I have not worked out the technical details as of yet, but it is planned. http://pyjigdo.org/ -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From kanarip at kanarip.com Fri Dec 7 01:05:15 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 02:05:15 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206164257.56c1884f@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <20071206164257.56c1884f@redhat.com> Message-ID: <47589C4B.8090104@kanarip.com> Jesse Keating wrote: > Question. Spins.fp.o is mostly about Live images no? Live images are > essentially a big squasfs image wrapped up in an iso with some bootable > stuff involved? How would jigdo possibly help here? > As Jigdo needs an expanded tree somewhere (online) of the contents of an ISO image, so for Live Media, Jigdo isn't a very viable solution. -Jeroen From kanarip at kanarip.com Fri Dec 7 01:10:26 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 02:10:26 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <200712062253.26813.opensource@till.name> References: <20071206142813.5dcc973f@damaestrojr> <200712062253.26813.opensource@till.name> Message-ID: <47589D82.3050409@kanarip.com> Till Maas wrote: > On Do Dezember 6 2007, Jonathan Steffan wrote: > >> The current updates system is getting better each release, but I think >> we should adjust our policies to also have an ???updates-archive??? >> repository. This repository will include all signed updates that had >> once lived in the updates repo, for the duration of the releases >> life-cycle. I don't expect all mirrors would want to carry this extra > > Once the repositories are presto enabled, an updates-archive with all the > delta rpms would not take as much space as a full rpm repository but provide > the same functionality. > If in some way a mirror can regenerate a full, original RPM from all delta RPMs, so that Jigdo can use it as a slice, a combination of the two would be possible. Without that ability, all Jigdo recognizes is full RPMs on the ISO image (slices), against no (zero) matches in the updates-archive/ folder (all partial slices). -Jeroen From kanarip at kanarip.com Fri Dec 7 01:13:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 02:13:40 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47586BC4.6040808@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47586BC4.6040808@redhat.com> Message-ID: <47589E44.5010003@kanarip.com> John Poelstra wrote: > Hasn't the door already been opened for this? > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19 > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-nov-19#t13:44 > The Release Meeting addressed releasing spins via Jigdo, yes. What had been proposed -and accepted- in the Release Meeting though was releasing /custom/ spins built of the release tree, via Jigdo. In particular the Everything Spin comes to mind, composed of the full tree in releases/$releasever/Everything/$basearch. However, Jonathan's mail addresses a request to keep signed copies of updates available in updates/$releasever/$basearch (or somewhere else) for the entire release cycle, so that: - Re-Spins and Remixes can be composed at any time during the release cycle and hosted with the Fedora Project without too large a footprint, and - Optionally older packages can be used by respinners and remixes, when needed, for example in case of a yum or rpm update that breaks its compatibilities with anaconda, or a kernel that just doesn't do the job. > > Also, I see an incomplete feature page here: > http://fedoraproject.org/wiki/Features/JigdoRelease > As the owner of the feature; Jigdo hasn't got the integration bits yet to make full use of Fedora Project infrastructure, as I'm working with upstream to get some changes done, and pyJigdo (a python alternative "wrapper" around upstream Jigdo that does integrate it with the existing Fedora Project in full), hasn't been released stable yet. Then again, mind that it is an alternative. If people really start using Jigdo it hits the mirrorlist for every single slice -possibly (or inevitably) overloading the mirrorlist. With pyJigdo this problem, and another couple of problems are solved (such as multi-image downloading, error recovery, scanning more then one local directory for slices, ..., ...). -Jeroen From jonathansteffan at gmail.com Fri Dec 7 01:22:03 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 6 Dec 2007 18:22:03 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47589C4B.8090104@kanarip.com> References: <20071206142813.5dcc973f@damaestrojr> <20071206164257.56c1884f@redhat.com> <47589C4B.8090104@kanarip.com> Message-ID: <20071206182203.05a9d811@damaestrojr> On Fri, 07 Dec 2007 02:05:15 +0100 Jeroen van Meeuwen wrote: > Jesse Keating wrote: > > Question. Spins.fp.o is mostly about Live images no? Live images > > are essentially a big squasfs image wrapped up in an iso with some > > bootable stuff involved? How would jigdo possibly help here? > > > > As Jigdo needs an expanded tree somewhere (online) of the contents of > an ISO image, so for Live Media, Jigdo isn't a very viable solution. Well, as I've expressed in https://www.redhat.com/archives/fedora-infrastructure-list/2007-December/msg00023.html we could make it so jigdo supports sticking data that has been published to a tree in some form. To generate the jigdo definition, the squash would need to be opened and the resulting bits would need to be hashed. Thus, putting the data back together would also involve creating a squashfs and sticking data into it. I've not looked into this outside of just conceptual design. If there are any squashfs gurus that would like to comment, please do. -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From jonathansteffan at gmail.com Fri Dec 7 01:31:57 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 6 Dec 2007 18:31:57 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47589D82.3050409@kanarip.com> References: <20071206142813.5dcc973f@damaestrojr> <200712062253.26813.opensource@till.name> <47589D82.3050409@kanarip.com> Message-ID: <20071206183157.46ff7da5@damaestrojr> On Fri, 07 Dec 2007 02:10:26 +0100 Jeroen van Meeuwen wrote: > Till Maas wrote: > > On Do Dezember 6 2007, Jonathan Steffan wrote: > > > >> The current updates system is getting better each release, but I > >> think we should adjust our policies to also have an > >> ???updates-archive??_ repository. This repository will include all > >> signed updates that had once lived in the updates repo, for the > >> duration of the releases life-cycle. I don't expect all mirrors > >> would want to carry this extra > > > > Once the repositories are presto enabled, an updates-archive with > > all the delta rpms would not take as much space as a full rpm > > repository but provide the same functionality. > > > > If in some way a mirror can regenerate a full, original RPM from all > delta RPMs, so that Jigdo can use it as a slice, a combination of the > two would be possible. This would be nice to be able to utilize the mirrors CPU, but most likely is not practical and we will not be able to accomplished without mirror admins running special handlers and at that point I would expect admins would rather waste the disk space vs supporting a home-brew handler. > Without that ability, all Jigdo recognizes is full RPMs on the ISO > image (slices), against no (zero) matches in the updates-archive/ > folder (all partial slices). Yes, this would require changes to the client software which would basically obsolete the current jigdo client. We would most likely need to utilize yum metadata to put all the pieces back together (not a real problem but it does restrict what platforms we can run pyJigdo on, not that it runs on anything but fedora at the moment) correctly. Using presto is also not as bandwidth efficient, but is more disk efficient (with regards to mirroring an entire tree of archived updates.) I specially left out using presto in the mix because there would be a lot of restrictions placed on where the client software could run if we went this route. I am, however, not in objection to utilizing existing systems we are developing. We would get the benefit of both having delta enabled repos for use with yum and a full archive of all updates released for the duration of a release. Granted multiple deltas would need to be downloaded to achieve a specific version of a package, but that also depends on how the deltas are generated. If anyone knows what the current plan is for generation of deltas, please chime in. Are we doing deltas against the previous public release or are we doing deltas against the release package? In both cases, what is our expected retention policy? -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From mmcgrath at redhat.com Fri Dec 7 14:48:10 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 07 Dec 2007 08:48:10 -0600 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206142813.5dcc973f@damaestrojr> References: <20071206142813.5dcc973f@damaestrojr> Message-ID: <47595D2A.1090007@redhat.com> Jonathan Steffan wrote: > The amount of storage and bandwidth able to be saved can be illustrated > by a simple comparison between the efficiency of chopping up a 3.4GB > iso9660 file system arbitrarily (by a static chunk size) and the same > file system based on contents (file by file.) For a BitTorrent, > Fedora's current choice for sharing Spins, the hosted data is only > valid for a given chunk on a single ISO. This data's footprint (equal > to the combined chunk sizes of the entire torrent) can be used for > nothing but this Spin. To be able to host 5 Spins composed from similar > trees via BitTorrent, we now have a footprint of 17GB, not to mention > "seeders" have to run BitTorrent software to be able to contribute to > the swarm. Alternatively, Jigdo can be used to reduce the footprint of > these 5 Spins to about 4GB. The amount of additional data needing to be > hosted for each Spin, in addition to what data is already pushed to the > mirrors, is about 150MB per ISO with anaconda and about 200KB for ISOs > without the installer bits. To help illustrate the efficiency of using > Jigdo vs BitTorrent, the footprint for 250 Spins is 850GB for > BitTorrent and about 40GB for Jigdo. Additionally, a reduction in > overhead can be achieved by removing the need for the BitTorrent > tracker and all related network traffic without requiring any > additional work on the part of mirror administrators. > My concern with jigdo is with how many people use it? It seems silly to host both torrent and jigdo (as much of this letter points out the benefits of switching to jigdo, those benefits disappear if we simply add jigdo to the mix. Most people already have bittorrent. Lets say we were going to give Jigdo a trial run for Fedora 9 and we were going to judge jigdo a success if a certain % (compared to bittorrent) use jigdo. What % would that be? While google trends is sort of crazy in that I don't know what it says, it does say something: http://google.com/trends?q=bittorrent%2C+jigdo -Mike From kanarip at kanarip.com Fri Dec 7 15:14:58 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 16:14:58 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47595D2A.1090007@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> Message-ID: <47596372.3060208@kanarip.com> Mike McGrath wrote: > Jonathan Steffan wrote: >> The amount of storage and bandwidth able to be saved can be illustrated >> by a simple comparison between the efficiency of chopping up a 3.4GB >> iso9660 file system arbitrarily (by a static chunk size) and the same >> file system based on contents (file by file.) For a BitTorrent, >> Fedora's current choice for sharing Spins, the hosted data is only >> valid for a given chunk on a single ISO. This data's footprint (equal >> to the combined chunk sizes of the entire torrent) can be used for >> nothing but this Spin. To be able to host 5 Spins composed from similar >> trees via BitTorrent, we now have a footprint of 17GB, not to mention >> "seeders" have to run BitTorrent software to be able to contribute to >> the swarm. Alternatively, Jigdo can be used to reduce the footprint of >> these 5 Spins to about 4GB. The amount of additional data needing to be >> hosted for each Spin, in addition to what data is already pushed to the >> mirrors, is about 150MB per ISO with anaconda and about 200KB for ISOs >> without the installer bits. To help illustrate the efficiency of using >> Jigdo vs BitTorrent, the footprint for 250 Spins is 850GB for >> BitTorrent and about 40GB for Jigdo. Additionally, a reduction in >> overhead can be achieved by removing the need for the BitTorrent >> tracker and all related network traffic without requiring any >> additional work on the part of mirror administrators. >> > > My concern with jigdo is with how many people use it? It seems silly to > host both torrent and jigdo (as much of this letter points out the > benefits of switching to jigdo, those benefits disappear if we simply > add jigdo to the mix. Most people already have bittorrent. Lets say we > were going to give Jigdo a trial run for Fedora 9 FYI, we have done so, and we are doing so officially for Fedora 9. and we were going to > judge jigdo a success if a certain % (compared to bittorrent) use > jigdo. What % would that be? > Jigdo would in this case be particularly useful to those with a local mirror as they have 99% of the content already (90% if you have F9T3?). Because it is particularly useful to some, and completely weird and strange for others, the number of users that will use it if BitTorrent is an alternative wouldn't be a very good indicator to see if it is actually a viable distribution method for the whole of Fedora, neither is it the goal for these proposals. However on the other hand we do have a couple of people with local mirrors, and last time I checked, test releases are downloaded a couple of times. We are hoping that these users in particular try out Jigdo and become happy bandwidth and time savers. For the Fedora Project, the greatest benefit of doing a trial Jigdo release with Fedora 9 is to get to know the feeling, see the numbers, get some feedback, and not having to host 68GB of Everything spins on different media, instead of 450MB -giving the same results. The same goes for any other additional installation media composed off the release tree -even rebranded downstream distributions, although there isn't much of those as long as updates keep expiring from the mirrors. The original proposal was in fact that Fedora 9 CDs would be released and hosted by Fedora Project but it seemed to be a better path to do so via Release Engineering > While google trends is sort of crazy in that I don't know what it says, > it does say something: > > http://google.com/trends?q=bittorrent%2C+jigdo > Right, I do hope our gut feeling rather then the number of hits on Google comes up with a decision... Another consideration in the entire footprint discussion may be to expire FC{1,2,3,4,5,6} from the master mirror. Kind regards, Jeroen van Meeuwen -kanarip From mmcgrath at redhat.com Fri Dec 7 15:18:12 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 07 Dec 2007 09:18:12 -0600 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47596372.3060208@kanarip.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> Message-ID: <47596434.9090004@redhat.com> Jeroen van Meeuwen wrote: > Mike McGrath wrote: >> Jonathan Steffan wrote: >>> The amount of storage and bandwidth able to be saved can be illustrated >>> by a simple comparison between the efficiency of chopping up a 3.4GB >>> iso9660 file system arbitrarily (by a static chunk size) and the same >>> file system based on contents (file by file.) For a BitTorrent, >>> Fedora's current choice for sharing Spins, the hosted data is only >>> valid for a given chunk on a single ISO. This data's footprint (equal >>> to the combined chunk sizes of the entire torrent) can be used for >>> nothing but this Spin. To be able to host 5 Spins composed from similar >>> trees via BitTorrent, we now have a footprint of 17GB, not to mention >>> "seeders" have to run BitTorrent software to be able to contribute to >>> the swarm. Alternatively, Jigdo can be used to reduce the footprint of >>> these 5 Spins to about 4GB. The amount of additional data needing to be >>> hosted for each Spin, in addition to what data is already pushed to the >>> mirrors, is about 150MB per ISO with anaconda and about 200KB for ISOs >>> without the installer bits. To help illustrate the efficiency of using >>> Jigdo vs BitTorrent, the footprint for 250 Spins is 850GB for >>> BitTorrent and about 40GB for Jigdo. Additionally, a reduction in >>> overhead can be achieved by removing the need for the BitTorrent >>> tracker and all related network traffic without requiring any >>> additional work on the part of mirror administrators. >>> >> >> My concern with jigdo is with how many people use it? It seems silly >> to host both torrent and jigdo (as much of this letter points out the >> benefits of switching to jigdo, those benefits disappear if we simply >> add jigdo to the mix. Most people already have bittorrent. Lets say >> we were going to give Jigdo a trial run for Fedora 9 > > FYI, we have done so, and we are doing so officially for Fedora 9. > > and we were going to >> judge jigdo a success if a certain % (compared to bittorrent) use >> jigdo. What % would that be? >> > > Jigdo would in this case be particularly useful to those with a local > mirror as they have 99% of the content already (90% if you have > F9T3?). Because it is particularly useful to some, and completely > weird and strange for others, the number of users that will use it if > BitTorrent is an alternative wouldn't be a very good indicator to see > if it is actually a viable distribution method for the whole of > Fedora, neither is it the goal for these proposals. I'm talking specifically about people going to the get-fedora page and clicking on the torrent link vs the jigdo link. Out of every 100 people, how many people will click on the jigdo link? -Mike From mmcgrath at redhat.com Fri Dec 7 15:25:42 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 07 Dec 2007 09:25:42 -0600 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071206142813.5dcc973f@damaestrojr> References: <20071206142813.5dcc973f@damaestrojr> Message-ID: <475965F6.1040800@redhat.com> Jonathan Steffan wrote: > The amount of storage and bandwidth able to be saved can be illustrated > by a simple comparison between the efficiency of chopping up a 3.4GB > iso9660 file system arbitrarily (by a static chunk size) and the same > file system based on contents (file by file.) For a BitTorrent, > Fedora's current choice for sharing Spins, the hosted data is only > valid for a given chunk on a single ISO. This data's footprint (equal > to the combined chunk sizes of the entire torrent) can be used for > nothing but this Spin. To be able to host 5 Spins composed from similar > trees via BitTorrent, we now have a footprint of 17GB, not to mention > "seeders" have to run BitTorrent software to be able to contribute to > the swarm. Alternatively, Jigdo can be used to reduce the footprint of > these 5 Spins to about 4GB. The amount of additional data needing to be > hosted for each Spin, in addition to what data is already pushed to the > mirrors, is about 150MB per ISO with anaconda and about 200KB for ISOs > without the installer bits. To help illustrate the efficiency of using > Jigdo vs BitTorrent, the footprint for 250 Spins is 850GB for > BitTorrent and about 40GB for Jigdo. Additionally, a reduction in > overhead can be achieved by removing the need for the BitTorrent > tracker and all related network traffic without requiring any > additional work on the part of mirror administrators. > This paragraph shows the savings we would make on the jigdo server. How much would our storage needs increase by needing to keep all RPM's around on the mirrors? -Mike From kanarip at kanarip.com Fri Dec 7 15:31:19 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 16:31:19 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47596434.9090004@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> Message-ID: <47596747.2030503@kanarip.com> Mike McGrath wrote: >> and we were going to >>> judge jigdo a success if a certain % (compared to bittorrent) use >>> jigdo. What % would that be? >>> >> >> Jigdo would in this case be particularly useful to those with a local >> mirror as they have 99% of the content already (90% if you have >> F9T3?). Because it is particularly useful to some, and completely >> weird and strange for others, the number of users that will use it if >> BitTorrent is an alternative wouldn't be a very good indicator to see >> if it is actually a viable distribution method for the whole of >> Fedora, neither is it the goal for these proposals. > > I'm talking specifically about people going to the get-fedora page and > clicking on the torrent link vs the jigdo link. Out of every 100 > people, how many people will click on the jigdo link? > Given the choice to download, say, the Fedora 9 i386 vanilla DVD, frankly, I expect only people that know Jigdo, or want to get to know Jigdo as it may have some benefits for them, and want to use it, are going to use it, so in all my optimism: roughly 10 out of a 100. For other spins without regular bittorrent seeds obviously the rate is 100%, and some of the people that get to know Jigdo that way will be using it again for our respins, and if possible, again for other spins (non-Everything?), and again, and again. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Fri Dec 7 15:39:46 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 07 Dec 2007 16:39:46 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <475965F6.1040800@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <475965F6.1040800@redhat.com> Message-ID: <47596942.60907@kanarip.com> Mike McGrath wrote: > This paragraph shows the savings we would make on the jigdo server. How > much would our storage needs increase by needing to keep all RPM's > around on the mirrors? > For Fedora 8, per arch, at this moment that would be: $ du -sch fedora-unity/releases/8/Everything/x86_64/ \ fedora-unity/updates/8/x86_64/ 19G fedora-unity/releases/8/Everything/x86_64/ 5.0G fedora-unity/updates/8/x86_64/ 24G total minus the updates in the normal tree already: $ du -sch fedora/releases/8/Everything/x86_64/ fedora/updates/8/x86_64/ 19G fedora/releases/8/Everything/x86_64/ 3.9G fedora/updates/8/x86_64/ 23G total For Fedora 7, per arch, that'd be: $ du -sch fedora-unity/releases/7/Everything/x86_64/ \ fedora-unity/updates/7/x86_64/ 16G fedora-unity/releases/7/Everything/x86_64/ 18G fedora-unity/updates/7/x86_64/ 34G total again minus the updates in the tree already: $ du -sch fedora/releases/7/Everything/x86_64/ fedora/updates/7/x86_64/ 16G fedora/releases/7/Everything/x86_64/ 13G fedora/updates/7/x86_64/ 28G total So, roughly, 12GB per release per arch, not taking into account the ever growing number of packages. Kind regards, Jeroen van Meeuwen -kanarip -- P.S. For everyone wondering, yes this host archives every single bit that ever hits the mirrors except for development/ and releases/test/. From cra at WPI.EDU Fri Dec 7 15:53:44 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 7 Dec 2007 10:53:44 -0500 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47595D2A.1090007@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> Message-ID: <20071207155344.GM25455@angus.ind.WPI.EDU> On Fri, Dec 07, 2007 at 08:48:10AM -0600, Mike McGrath wrote: > My concern with jigdo is with how many people use it? It seems silly to > host both torrent and jigdo (as much of this letter points out the > benefits of switching to jigdo, those benefits disappear if we simply > add jigdo to the mix. Most people already have bittorrent. Lets say we > were going to give Jigdo a trial run for Fedora 9 and we were going to > judge jigdo a success if a certain % (compared to bittorrent) use > jigdo. What % would that be? Some people CAN'T use bittorrent because of firewalls. There should be no reason at all why anyone couldn't use Jigdo, because it uses standard FTP or HTTP to download the slices. There are clients available for all the important OSes. Jigdo and Bittorrent are really two different beasts that do different things to benefit different use cases. Bittorrent is best for getting all the bits for an ISO set when you have nothing currently. Jigdo is good for getting bits that are packed differently but are otherwise identical to the bits you have already, plus it can also get all the bits via separate and possibly distributed downloads. So Jigdo in this sense has a superset of the functionality of Bittorrent. I think we need to have some overlap by providing both services, certainly at least for a transition period, but perhaps even long term. The real benefit to Jigdo is that you can distribute one set of files that represent the Everthing universe of content via HTTP/FTP (or ISOs via Bittorrent), and then a bunch of Jigdo templates for all the various spins. From mmcgrath at redhat.com Fri Dec 7 15:52:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 07 Dec 2007 09:52:49 -0600 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071207155344.GM25455@angus.ind.WPI.EDU> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <20071207155344.GM25455@angus.ind.WPI.EDU> Message-ID: <47596C51.8050808@redhat.com> Chuck Anderson wrote: > On Fri, Dec 07, 2007 at 08:48:10AM -0600, Mike McGrath wrote: > >> My concern with jigdo is with how many people use it? It seems silly to >> host both torrent and jigdo (as much of this letter points out the >> benefits of switching to jigdo, those benefits disappear if we simply >> add jigdo to the mix. Most people already have bittorrent. Lets say we >> were going to give Jigdo a trial run for Fedora 9 and we were going to >> judge jigdo a success if a certain % (compared to bittorrent) use >> jigdo. What % would that be? >> > > Some people CAN'T use bittorrent because of firewalls. There should > be no reason at all why anyone couldn't use Jigdo, because it uses > standard FTP or HTTP to download the slices. There are clients > available for all the important OSes. > Those that can't use bittorrent can use the mirrors as well. -Mike From lmacken at redhat.com Fri Dec 7 21:52:38 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 7 Dec 2007 16:52:38 -0500 Subject: Port 80 blocked on publictest machines Message-ID: <20071207215238.GL7316@crow.myhome.westell.com> I just made the change in puppet to block port 80 on our publictest machines. Theoretically, the apps on those servers shouldn't be touching our production db, but we shouldn't underestimate human stupidity. Let us know if stuff breaks. luke From mdehaan at redhat.com Mon Dec 10 22:55:47 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 10 Dec 2007 17:55:47 -0500 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <47596747.2030503@kanarip.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> Message-ID: <475DC3F3.707@redhat.com> Jeroen van Meeuwen wrote: > Mike McGrath wrote: >>> and we were going to >>>> judge jigdo a success if a certain % (compared to bittorrent) use >>>> jigdo. What % would that be? >>>> >>> >>> Jigdo would in this case be particularly useful to those with a >>> local mirror as they have 99% of the content already (90% if you >>> have F9T3?). Because it is particularly useful to some, and >>> completely weird and strange for others, the number of users that >>> will use it if BitTorrent is an alternative wouldn't be a very good >>> indicator to see if it is actually a viable distribution method for >>> the whole of Fedora, neither is it the goal for these proposals. >> >> I'm talking specifically about people going to the get-fedora page >> and clicking on the torrent link vs the jigdo link. Out of every 100 >> people, how many people will click on the jigdo link? >> > > Given the choice to download, say, the Fedora 9 i386 vanilla DVD, > frankly, I expect only people that know Jigdo, or want to get to know > Jigdo as it may have some benefits for them, and want to use it, are > going to use it, so in all my optimism: > > roughly 10 out of a 100. I would venture less. As a former Debian user (and knowing other Debian users), our favorite install system was always the ~100 MB net install image, which we can do for Fedora already (though it's not 100 MB) Spins are perhaps interesting for users that don't do minimal net-installs, and don't want to build their system with yum later, but jigdo is something that advanced users would use. They seem to be two different groups. Jigdo did not seem to be very popular among anyone I talked to once they figured out the minimal install images were available. Fedora's MMV, of course. From kanarip at kanarip.com Mon Dec 10 23:41:24 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 11 Dec 2007 00:41:24 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <475DC3F3.707@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> Message-ID: <475DCEA4.1010207@kanarip.com> Michael DeHaan wrote: > Jeroen van Meeuwen wrote: >> Mike McGrath wrote: >>>> and we were going to >>>>> judge jigdo a success if a certain % (compared to bittorrent) use >>>>> jigdo. What % would that be? >>>>> >>>> >>>> Jigdo would in this case be particularly useful to those with a >>>> local mirror as they have 99% of the content already (90% if you >>>> have F9T3?). Because it is particularly useful to some, and >>>> completely weird and strange for others, the number of users that >>>> will use it if BitTorrent is an alternative wouldn't be a very good >>>> indicator to see if it is actually a viable distribution method for >>>> the whole of Fedora, neither is it the goal for these proposals. >>> >>> I'm talking specifically about people going to the get-fedora page >>> and clicking on the torrent link vs the jigdo link. Out of every 100 >>> people, how many people will click on the jigdo link? >>> >> >> Given the choice to download, say, the Fedora 9 i386 vanilla DVD, >> frankly, I expect only people that know Jigdo, or want to get to know >> Jigdo as it may have some benefits for them, and want to use it, are >> going to use it, so in all my optimism: >> >> roughly 10 out of a 100. > > I would venture less. As a former Debian user (and knowing other > Debian users), our favorite install system was always the ~100 MB net > install image, which we can do for Fedora already (though it's not 100 MB) > Assuming you do have a network connection, like the example above; What would you want to do if there's no Jigdo, but you do have the Fedora 9 DVD, and you want/need the CD version too? Download another ~4GB of ISO images? How about off-line? It's fairly simple to create the Jigdo files and host them. Let's try it and get the real numbers, then decide if it's valuable enough for all of us to continue distributing installation media with. > Spins are perhaps interesting for users that don't do minimal > net-installs, and don't want to build their system with yum later, but > jigdo is something that advanced users would use. They seem to be two > different groups. > > Jigdo did not seem to be very popular among anyone I talked to once they > figured out the minimal install images were available. > We on the other hand have hundreds -if not thousands- of users download the CD version of Fedora 7 and Fedora 8 while supposedly they are in possession of the DVD images already. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Tue Dec 11 12:25:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Dec 2007 07:25:51 -0500 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <475DCEA4.1010207@kanarip.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <475DCEA4.1010207@kanarip.com> Message-ID: <20071211072551.3ef87f2a@redhat.com> On Tue, 11 Dec 2007 00:41:24 +0100 Jeroen van Meeuwen wrote: > We on the other hand have hundreds -if not thousands- of users > download the CD version of Fedora 7 and Fedora 8 while supposedly > they are in possession of the DVD images already. What makes you say that? When I poked at fedoraunity.org the only download option I saw was jigdo, so how are you determining that these people are using jigdo by choice rather than by necessity? -- 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 kanarip at kanarip.com Tue Dec 11 13:02:48 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 11 Dec 2007 14:02:48 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071211072551.3ef87f2a@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <475DCEA4.1010207@kanarip.com> <20071211072551.3ef87f2a@redhat.com> Message-ID: <475E8A78.1000406@kanarip.com> Jesse Keating wrote: > On Tue, 11 Dec 2007 00:41:24 +0100 > Jeroen van Meeuwen wrote: > >> We on the other hand have hundreds -if not thousands- of users >> download the CD version of Fedora 7 and Fedora 8 while supposedly >> they are in possession of the DVD images already. > > What makes you say that? When I poked at fedoraunity.org the only > download option I saw was jigdo, so how are you determining that these > people are using jigdo by choice rather than by necessity? > I don't think I said anything about those users /choosing/ to use Jigdo, but if I was likely to be misunderstood in that aspect I apologize. Talking about necessity though, users interested in the Fedora 9 Everything Spin would need to use Jigdo as it is the only way anyone offers it (officially). Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Tue Dec 11 14:38:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 11 Dec 2007 09:38:17 -0500 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <475E8A78.1000406@kanarip.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <475DCEA4.1010207@kanarip.com> <20071211072551.3ef87f2a@redhat.com> <475E8A78.1000406@kanarip.com> Message-ID: <20071211093817.1de8fda7@redhat.com> On Tue, 11 Dec 2007 14:02:48 +0100 Jeroen van Meeuwen wrote: > I don't think I said anything about those users /choosing/ to use > Jigdo, but if I was likely to be misunderstood in that aspect I > apologize. Ok, Michael was talking about choosing, which is what led me to assume that you were too. -- 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 Tue Dec 11 20:05:02 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 11 Dec 2007 14:05:02 -0600 Subject: fedorahosted.org is ready for testing Message-ID: <475EED6E.1040005@redhat.com> I'd like to move all the services and things from their current location to the serverbeach hardware tomorrow around noon. In the mean time I'd like some help testing. We've changed the domain name to fedorahosted.org so we can avoid any namespace issues in the future regarding email addresses or server addresses. I've requested an SSL cert but it could be a bit before we get it (https on that site will hit the hosted.fedoraproject.org cert and throw a warning). Feel free to test by checking out and committing to your repo, those changes (if using fedorahoste.org addresses below) will be wiped out when we do the final move. Git users: git://git.fedorahosted.org/git/$PROJECT (anon, ro) http://git.fedorahosted.org/git/$PROJECT (anon, ro) ssh://git.fedorahosted.org/git/$PROJECT (auth, rw) rsync://git.fedorahosted.org/git/$PROJECT (anon, ro) HG users: http://hg.fedorahosted.org/hg/$PROJECT (anon, ro) ssh://hg.fedorahosted.org/hg/$PROJECT (auth, rw) rsync://hg.fedorahosted.org/hg/$PROJECT (anon, ro) BZR users: http://bzr.fedorahosted.org/bzr/$PROJECT (anon, ro) ssh://bzr.fedorahosted.org/bzr/$PROJECT (auth, rw) rsync://bzr.fedorahosted.org/bzr/$PROJECT (anon, ro) SVN users: http://svn.fedorahosted.org/svn/$PROJECT (anon, ro) ssh://svn.fedorahosted.org/svn/$PROJECT (auth, rw) rsync://svn.fedorahosted.org/svn/$PROJECT (anon, ro) I'm also working on putting a little website together with content about what it is, how to ask for it and move that content off of the wiki. -Mike From mmcgrath at redhat.com Tue Dec 11 20:14:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 11 Dec 2007 14:14:19 -0600 Subject: fedorahosted.org is ready for testing In-Reply-To: <475EED6E.1040005@redhat.com> References: <475EED6E.1040005@redhat.com> Message-ID: <475EEF9B.90308@redhat.com> Mike McGrath wrote: > I'd like to move all the services and things from their current > location to the serverbeach hardware tomorrow around noon. In the > mean time I'd like some help testing. We've changed the domain name > to fedorahosted.org so we can avoid any namespace issues in the future > regarding email addresses or server addresses. I've requested an SSL > cert but it could be a bit before we get it (https on that site will > hit the hosted.fedoraproject.org cert and throw a warning). Feel free > to test by checking out and committing to your repo, those changes (if > using fedorahoste.org addresses below) will be wiped out when we do > the final move. Oops, forgot http://fedorahosted.org/ -Mike From jonathansteffan at gmail.com Tue Dec 11 20:47:50 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Tue, 11 Dec 2007 13:47:50 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <475DC3F3.707@redhat.com> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> Message-ID: <20071211134750.47894a0b@damaestro> On Mon, 10 Dec 2007 17:55:47 -0500 Michael DeHaan wrote: > Jeroen van Meeuwen wrote: > > Mike McGrath wrote: > >>> and we were going to > >>>> judge jigdo a success if a certain % (compared to bittorrent) > >>>> use jigdo. What % would that be? > >>> > >>> Jigdo would in this case be particularly useful to those with a > >>> local mirror as they have 99% of the content already (90% if you > >>> have F9T3?). Because it is particularly useful to some, and > >>> completely weird and strange for others, the number of users that > >>> will use it if BitTorrent is an alternative wouldn't be a very > >>> good indicator to see if it is actually a viable distribution > >>> method for the whole of Fedora, neither is it the goal for these > >>> proposals. > >> > >> I'm talking specifically about people going to the get-fedora page > >> and clicking on the torrent link vs the jigdo link. Out of every > >> 100 people, how many people will click on the jigdo link? > >> > Jigdo did not seem to be very popular among anyone I talked to once > they figured out the minimal install images were available. I will admit, our poll on spins.fedoraunity.org showed that more users want to use BitTorrent. I still think these users just had no concept of what Jigdo is *good* at and were left to deal with our growing pains setting everything up. We do apologize for that. We do, however, 110% support Jigdo in many cases: * Testing images can easily be "upgraded" to the next release, only downloading what has changed * Re-Spins: The same goes for Re-Spins, an end users (and the testers) can easily "update" their ISO, again, only having to download what has changed * Any Spin: Not all mirrors chose to carry the ISO images. A next-hop or local mirror might not be available with the ISO images for direct download. This very close mirror will be able to be used to "put together" the ISO image and with our awesome new MirrorManager the acquisition of this data source will be automatic. * Bandwidth Optimization/Utilization: We are able to utilize mirrors around the globe without requiring mirror admins to think twice about hosting Jigdo data, they already are hosting most of the data needed to put the image back together and have to install no additional software (as in the case of running a torrent seed.) * Official Releases: This "letter" was directed at requesting all updates be archived in some form; this bullet is about official releases. These official releases will *always* be able to be hosted via Jigdo with *very little* additional storage requirements because the Fedora and Everything trees that were composed against are exploded and hosted indefinitely. Please do understand that some of our ambitions are based around releasing an optimized, and if need-be completely rewritten, client that will solve a lot of the issues people have had with Jigdo in the past. The only client I know of that works is jigdo-lite and that is just a shell script. We currently are maintaining backwards compatibility with the existing Jigdo concept (pyjigdo being basically just a wrapper) but might find we need to take it to the next level due to needs outside of the scope of the original Jigdo and my plan has been to implement full compatibility in pure python and then add new bells and whistles that can be switched on and off, depending on the source .jigdo definition. -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From imtiaz.rahi at gmail.com Wed Dec 12 07:23:32 2007 From: imtiaz.rahi at gmail.com (Imtiaz Rahi) Date: Wed, 12 Dec 2007 13:23:32 +0600 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071211134750.47894a0b@damaestro> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <20071211134750.47894a0b@damaestro> Message-ID: On Dec 12, 2007 2:47 AM, Jonathan Steffan wrote: > On Mon, 10 Dec 2007 17:55:47 -0500 > Michael DeHaan wrote: > > > Jeroen van Meeuwen wrote: > > > Mike McGrath wrote: > > >>> and we were going to > > >>>> judge jigdo a success if a certain % (compared to bittorrent) > > >>>> use jigdo. What % would that be? > > >>> > > >>> Jigdo would in this case be particularly useful to those with a > > >>> local mirror as they have 99% of the content already (90% if you > > >>> have F9T3?). Because it is particularly useful to some, and > > >>> completely weird and strange for others, the number of users that > > >>> will use it if BitTorrent is an alternative wouldn't be a very > > >>> good indicator to see if it is actually a viable distribution > > >>> method for the whole of Fedora, neither is it the goal for these > > >>> proposals. > > >> > > >> I'm talking specifically about people going to the get-fedora page > > >> and clicking on the torrent link vs the jigdo link. Out of every > > >> 100 people, how many people will click on the jigdo link? > > >> > > Jigdo did not seem to be very popular among anyone I talked to once > > they figured out the minimal install images were available. > > I will admit, our poll on spins.fedoraunity.org showed that more users > want to use BitTorrent. I still think these users just had no concept > of what Jigdo is *good* at and were left to deal with our growing pains > setting everything up. We do apologize for that. We do, however, 110% > support Jigdo in many cases: > > * Testing images can easily be "upgraded" to the next release, only > downloading what has changed > * Re-Spins: The same goes for Re-Spins, an end users (and the testers) > can easily "update" their ISO, again, only having to download what has > changed > * Any Spin: Not all mirrors chose to carry the ISO images. A next-hop > or local mirror might not be available with the ISO images for direct > download. This very close mirror will be able to be used to "put > together" the ISO image and with our awesome new MirrorManager the > acquisition of this data source will be automatic. > * Bandwidth Optimization/Utilization: We are able to utilize mirrors > around the globe without requiring mirror admins to think twice about > hosting Jigdo data, they already are hosting most of the data needed to > put the image back together and have to install no additional software > (as in the case of running a torrent seed.) > * Official Releases: This "letter" was directed at requesting all > updates be archived in some form; this bullet is about official > releases. These official releases will *always* be able to be hosted > via Jigdo with *very little* additional storage requirements because > the Fedora and Everything trees that were composed against are exploded > and hosted indefinitely. Jigdo support will be a fantastic addition definitely. Bandwidth is very costly in my country. So, using jigdo makes a lot of sense to me. Have not yet done it just for proper knowhow. Cheers, Imtiaz -------------- next part -------------- An HTML attachment was scrubbed... URL: From laroche at redhat.com Wed Dec 12 10:19:00 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 12 Dec 2007 11:19:00 +0100 Subject: fedorahosted.org is ready for testing In-Reply-To: <475EED6E.1040005@redhat.com> References: <475EED6E.1040005@redhat.com> Message-ID: <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> > I'm also working on putting a little website together with content about > what it is, how to ask for it and move that content off of the wiki. Hello Mike, new site looks really great. How much of it is using selinux to further tighten it up? I think we should add that to as many as possible Fedora infrastructure setups as possible. (Probably as a F9+ target.) regards, Florian La Roche From paulo.banon at googlemail.com Wed Dec 12 10:23:17 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Wed, 12 Dec 2007 11:23:17 +0100 Subject: fedorahosted.org is ready for testing In-Reply-To: <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> References: <475EED6E.1040005@redhat.com> <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> Message-ID: <7a41c4bc0712120223y301f6006h6852c000ab24bdb@mail.gmail.com> And is this the preparation to officially announce hosted ? :) Paulo On Dec 12, 2007 11:19 AM, Florian La Roche wrote: > > I'm also working on putting a little website together with content about > > what it is, how to ask for it and move that content off of the wiki. > > Hello Mike, > > new site looks really great. How much of it is using selinux > to further tighten it up? I think we should add that to as many as > possible Fedora infrastructure setups as possible. (Probably as > a F9+ target.) > > regards, > > Florian La Roche > > _______________________________________________ > 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 fantec at proxad.net Wed Dec 12 11:18:31 2007 From: fantec at proxad.net (Francois Petillon) Date: Wed, 12 Dec 2007 12:18:31 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071211134750.47894a0b@damaestro> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <20071211134750.47894a0b@damaestro> Message-ID: <475FC387.50000@proxad.net> Jonathan Steffan wrote: > * Any Spin: Not all mirrors chose to carry the ISO images. A next-hop > or local mirror might not be available with the ISO images for direct > download. This very close mirror will be able to be used to "put > together" the ISO image and with our awesome new MirrorManager the > acquisition of this data source will be automatic. > * Bandwidth Optimization/Utilization: We are able to utilize mirrors > around the globe without requiring mirror admins to think twice about > hosting Jigdo data, they already are hosting most of the data needed to > put the image back together and have to install no additional software > (as in the case of running a torrent seed.) I will speak as a mirror admin (ftp.free.fr/ftp.proxad.net). As far as I am concerned, bandwidth is not a real issue but disk IOs are. Disk capacity is growing exponentially, sequential access bandwidth grows linearly but disk seeks decrease at a very slow pace (SSD are coming but they do not match yet the needed capacity). Thus, improving server performances means either adding more disks or optimizing disks access (ie reading more data per each disk seeks). The "biggest" mirrors I manage are stored on a two-disks RAID1 volume (to avoid stripping which induce disks seeks) and IO are optimized by doing 1 MB chunk readahead (using posix_fadvise). If I need additionnal bandwidth, I may increase the readahead chunk size. But this is usable only if the file I read is big enough (and if the fragmentation is kept low). As long as jigdo use is uncommon, I just don't mind but if it had to be commonly used, it would mean a very sensible decrease in performances. Fran?ois From jkeating at redhat.com Wed Dec 12 13:10:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 08:10:05 -0500 Subject: fedorahosted.org is ready for testing In-Reply-To: <7a41c4bc0712120223y301f6006h6852c000ab24bdb@mail.gmail.com> References: <475EED6E.1040005@redhat.com> <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> <7a41c4bc0712120223y301f6006h6852c000ab24bdb@mail.gmail.com> Message-ID: <20071212081005.383ec24e@redhat.com> On Wed, 12 Dec 2007 11:23:17 +0100 "Paulo Santos" wrote: > And is this the preparation to officially announce hosted ? :) I'm still not quite happy to announce hosted as moving out of beta. This is certainly a step forward. I'd still like to get hosted consumers the ability to theme their hosted environment, as well as some raw webspace, before we call it production. -- 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 Wed Dec 12 14:17:13 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Dec 2007 08:17:13 -0600 Subject: fedorahosted.org is ready for testing In-Reply-To: <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> References: <475EED6E.1040005@redhat.com> <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> Message-ID: <475FED69.8080308@redhat.com> Florian La Roche wrote: >> I'm also working on putting a little website together with content about >> what it is, how to ask for it and move that content off of the wiki. >> > > Hello Mike, > > new site looks really great. How much of it is using selinux > to further tighten it up? I think we should add that to as many as > possible Fedora infrastructure setups as possible. (Probably as > a F9+ target.) > We've had luke working on this a little, I still have yet to see a solid proposal on how to config manage puppet modules and deploy them on a larger scale. All of the selinux tools I've seen work at the machine level. -Mike From mmcgrath at redhat.com Wed Dec 12 14:25:54 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Dec 2007 08:25:54 -0600 Subject: fedorahosted.org is ready for testing In-Reply-To: <475FED69.8080308@redhat.com> References: <475EED6E.1040005@redhat.com> <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> <475FED69.8080308@redhat.com> Message-ID: <475FEF72.20503@redhat.com> Mike McGrath wrote: > Florian La Roche wrote: >>> I'm also working on putting a little website together with content >>> about what it is, how to ask for it and move that content off of the >>> wiki. >>> >> >> Hello Mike, >> >> new site looks really great. How much of it is using selinux >> to further tighten it up? I think we should add that to as many as >> possible Fedora infrastructure setups as possible. (Probably as >> a F9+ target.) >> > > We've had luke working on this a little, I still have yet to see a > solid proposal on how to config manage puppet modules and deploy them > on a larger scale. All of the selinux tools I've seen work at the > machine level. Sorry, this should s/puppet modules/selinux policies/ -Mike From Matt_Domsch at Dell.com Wed Dec 12 21:02:07 2007 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Wed, 12 Dec 2007 15:02:07 -0600 Subject: Welcome new Mirror Wranglers! Message-ID: Thank you each for volunteering to help with managing Fedora's list of mirror servers. You have all been added to the email alias 'mirror-admin at fedoraproject.org', which is how you are getting this email. First, please send me your Fedora Account System username, as presumably the email address stored in the FAS for you is where you want these mails to go. Second, I recommend you subscribe to the relatively low volume fedora-infrastructure-list at redhat.com , which is where all the interesting Infrastructure discussion happens. (http://www.redhat.com/mailman/listinfo/fedora-infrastructure-list). This includes outage notices, freeze changes, and the like. Third, we are always happy to have more mirrors, provided they have sufficient capacity to really be of benefit. In the US and Europe, we don't really need more mirrors. Rest of the world, we definitely do. Requests will come to the mirror-admin at fedoraproject.org address, and will need a response. Be sure to "reply to all". I'll append my template. Be sure to copy ftp+fedora at redhat.com and mirror-admin on your reply, so everyone sees it, and so the rsync ACL on the master download servers will get updated. Rule of thumb: new mirrors with >= 1Gbit pipes, or in countries not already well-served (such as India, China, or anything in South America or South Africa) should be approved. Mirrors on DSL/Cable modem lines in the US or Europe, thanks, but no. Private mirrors should be directed to pull from a listed public mirror. When approved, you should then approve their subscriptions to mirror-list and mirror-list-d. There's a password required to moderate that list. Not sure how best to handle that aspect... Fourth, the MirrorManager code itself. https://fedorahosted.org/mirrormanager/wiki/WikiStart has instructions, and a list of items known needing love is at https://fedorahosted.org/mirrormanager/wiki/HelpWanted. I cut my python teeth writing this code, and it's had a few reviews, but there are probably ways to make it better. The TG controller pieces are really pretty hokey - nothing as nice as the bodhi code is. If you've got other ideas, by all means, please let us know. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux Public Mirror Acceptance Template We would be pleased to have you as a public mirror. Thank you for your contribution to Fedora! Please see http://fedoraproject.org/wiki/Infrastructure/Mirroring for guidance, and register your mirror in Mirrormanager at https://admin.fedoraproject.org/mirrormanager. By doing so, you will appear on the mirror list for Fedora 7 and future automatically. Most mirrors should rsync from one of the Tier 1 mirrors listed at http://fedoraproject.org/wiki/Infrastructure/Mirroring or from another mirror close network-wise listed on http://mirrors.fedoraproject.org/publiclist/. Thanks again, Matt Fedora Mirror Wrangler From damian.myerscough at gmail.com Wed Dec 12 21:58:04 2007 From: damian.myerscough at gmail.com (Damian Myerscough) Date: Wed, 12 Dec 2007 22:58:04 +0100 Subject: Welcome new Mirror Wranglers! In-Reply-To: References: Message-ID: <1197496684.4243.11.camel@dhcppc0> Hello Matt, My FAS username is damian and my email is Damian.Myerscough at gmail.com On Wed, 2007-12-12 at 15:02 -0600, Matt_Domsch at Dell.com wrote: > Thank you each for volunteering to help with managing Fedora's list of > mirror servers. You have all been added to the email alias > 'mirror-admin at fedoraproject.org', which is how you are getting this > email. > > First, please send me your Fedora Account System username, as presumably > the email address stored in the FAS for you is where you want these > mails to go. > > > Second, I recommend you subscribe to the relatively low volume > fedora-infrastructure-list at redhat.com , which is where all the > interesting Infrastructure discussion happens. > (http://www.redhat.com/mailman/listinfo/fedora-infrastructure-list). > This includes outage notices, freeze changes, and the like. > > Third, we are always happy to have more mirrors, provided they have > sufficient capacity to really be of benefit. In the US and Europe, we > don't really need more mirrors. Rest of the world, we definitely do. > Requests will come to the mirror-admin at fedoraproject.org address, and > will need a response. Be sure to "reply to all". I'll append my > template. Be sure to copy ftp+fedora at redhat.com and mirror-admin on > your reply, so everyone sees it, and so the rsync ACL on the master > download servers will get updated. Rule of thumb: new mirrors with >= > 1Gbit pipes, or in countries not already well-served (such as India, > China, or anything in South America or South Africa) should be approved. > Mirrors on DSL/Cable modem lines in the US or Europe, thanks, but no. > Private mirrors should be directed to pull from a listed public mirror. > When approved, you should then approve their subscriptions to > mirror-list and mirror-list-d. There's a password required to moderate > that list. Not sure how best to handle that aspect... > > Fourth, the MirrorManager code itself. > https://fedorahosted.org/mirrormanager/wiki/WikiStart has instructions, > and a list of items known needing love is at > https://fedorahosted.org/mirrormanager/wiki/HelpWanted. I cut my python > teeth writing this code, and it's had a few reviews, but there are > probably ways to make it better. The TG controller pieces are really > pretty hokey - nothing as nice as the bodhi code is. > > If you've got other ideas, by all means, please let us know. > > Thanks, > Matt > > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > > Public Mirror Acceptance Template > > We would be pleased to have you as a public mirror. Thank you for your > contribution to Fedora! > > > Please see http://fedoraproject.org/wiki/Infrastructure/Mirroring > for guidance, and register your mirror in Mirrormanager at > https://admin.fedoraproject.org/mirrormanager. By doing so, you will > appear on the mirror list for Fedora 7 and future automatically. > > Most mirrors should rsync from one of the Tier 1 mirrors listed at > http://fedoraproject.org/wiki/Infrastructure/Mirroring or from another > mirror close network-wise listed on > http://mirrors.fedoraproject.org/publiclist/. > > > Thanks again, > > Matt > Fedora Mirror Wrangler > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Regards, Damian Myerscough From mmcgrath at redhat.com Thu Dec 13 03:33:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Dec 2007 21:33:19 -0600 Subject: Request for monotone Message-ID: <4760A7FF.3070801@redhat.com> we've had a request to support monotone on hosted. Instead of having this conversation in private I thought it best to put it on the list. So thoughts? This is part "do we want to support monotone" and part "do we want hosted to be more then svn, hg, git, bzr". In general I'm happy supporting only those 4, we can't be everything for everyone and AFAIK we're the only OSS project with a hosted offering that supports 4 SCM's. Thoughts? -Mike From loupgaroublond at gmail.com Thu Dec 13 03:46:14 2007 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 12 Dec 2007 22:46:14 -0500 Subject: Request for monotone In-Reply-To: <4760A7FF.3070801@redhat.com> References: <4760A7FF.3070801@redhat.com> Message-ID: <7f692fec0712121946i979e366mcaf457c953958851@mail.gmail.com> On Dec 12, 2007 10:33 PM, Mike McGrath wrote: > we've had a request to support monotone on hosted. Instead of having > this conversation in private I thought it best to put it on the list. > So thoughts? This is part "do we want to support monotone" and part "do > we want hosted to be more then svn, hg, git, bzr". > > In general I'm happy supporting only those 4, we can't be everything for > everyone and AFAIK we're the only OSS project with a hosted offering > that supports 4 SCM's. > > Thoughts? +0 From jeff at ocjtech.us Thu Dec 13 03:50:28 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 12 Dec 2007 21:50:28 -0600 Subject: Request for monotone In-Reply-To: <4760A7FF.3070801@redhat.com> References: <4760A7FF.3070801@redhat.com> Message-ID: <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> On 12/12/07, Mike McGrath wrote: > we've had a request to support monotone on hosted. Instead of having > this conversation in private I thought it best to put it on the list. > So thoughts? This is part "do we want to support monotone" and part "do > we want hosted to be more then svn, hg, git, bzr". > > In general I'm happy supporting only those 4, we can't be everything for > everyone and AFAIK we're the only OSS project with a hosted offering > that supports 4 SCM's. I think that if: 1) The SCM is in RHEL/EPEL. 2) There are real projects that want to use it (and that we feel like will stick around). 3) Implementation is fairly straightforward 4) Someone on the hosted admin team is willing/able to install/support it. We should. Supporting more than just SVN and CVS is one way we can distinguish Fedora Hosted from other project hosting. Jeff From jkeating at redhat.com Thu Dec 13 03:55:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 22:55:32 -0500 Subject: Request for monotone In-Reply-To: <4760A7FF.3070801@redhat.com> References: <4760A7FF.3070801@redhat.com> Message-ID: <20071212225532.1211feb3@redhat.com> On Wed, 12 Dec 2007 21:33:19 -0600 Mike McGrath wrote: > we've had a request to support monotone on hosted. Instead of having > this conversation in private I thought it best to put it on the > list. So thoughts? This is part "do we want to support monotone" and > part "do we want hosted to be more then svn, hg, git, bzr". > > In general I'm happy supporting only those 4, we can't be everything > for everyone and AFAIK we're the only OSS project with a hosted > offering that supports 4 SCM's. So far, the SCMs we support have been driven mostly by the SCMs that Trac supports, with the exception to bzr which I had nothing to do with setting up. So the questions are, does Trac support monotone, does monotone lend itself to a hosted environment (easy ssh commit access, http anon access, useful web browser, easy to create empty repos for developers to fill, etc...), is it in EPEL, does it have a security track record, and uh... is there anybody on the infrastructure team that feels like they could become our site expert on it? -- 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 smooge at gmail.com Thu Dec 13 03:57:07 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Dec 2007 20:57:07 -0700 Subject: Request for monotone In-Reply-To: <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> Message-ID: <80d7e4090712121957s1ba807b6sb03eb596ad5915c6@mail.gmail.com> On Dec 12, 2007 8:50 PM, Jeffrey Ollie wrote: > On 12/12/07, Mike McGrath wrote: > > we've had a request to support monotone on hosted. Instead of having > > this conversation in private I thought it best to put it on the list. > > So thoughts? This is part "do we want to support monotone" and part "do > > we want hosted to be more then svn, hg, git, bzr". > > > > In general I'm happy supporting only those 4, we can't be everything for > > everyone and AFAIK we're the only OSS project with a hosted offering > > that supports 4 SCM's. > > I think that if: > > 1) The SCM is in RHEL/EPEL. > 2) There are real projects that want to use it (and that we feel like > will stick around). > 3) Implementation is fairly straightforward > 4) Someone on the hosted admin team is willing/able to install/support it. > > We should. > > Supporting more than just SVN and CVS is one way we can distinguish > Fedora Hosted from other project hosting. > I would also say that the people wanting XYZ SCM need to volunteer to help 'us' on it. As in hosted-help-monotone questions go to someone who can answer them versus someone else who can't. If they can provide that help and training.. that is a +, if they can't it is a definate -. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at fedoraproject.org Thu Dec 13 03:56:04 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 12 Dec 2007 22:56:04 -0500 Subject: Request for monotone In-Reply-To: <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> Message-ID: <1197518164.8989.32.camel@cutter> On Wed, 2007-12-12 at 21:50 -0600, Jeffrey Ollie wrote: > On 12/12/07, Mike McGrath wrote: > > we've had a request to support monotone on hosted. Instead of having > > this conversation in private I thought it best to put it on the list. > > So thoughts? This is part "do we want to support monotone" and part "do > > we want hosted to be more then svn, hg, git, bzr". > > > > In general I'm happy supporting only those 4, we can't be everything for > > everyone and AFAIK we're the only OSS project with a hosted offering > > that supports 4 SCM's. > > I think that if: > > 1) The SCM is in RHEL/EPEL. > 2) There are real projects that want to use it (and that we feel like > will stick around). > 3) Implementation is fairly straightforward > 4) Someone on the hosted admin team is willing/able to install/support it. > > We should. > > Supporting more than just SVN and CVS is one way we can distinguish > Fedora Hosted from other project hosting. > we are supporting more the svn/cvs. We're supporting: git, bzr, hg, cvs, svn that's quite a lot, actually. -sv From jkeating at redhat.com Thu Dec 13 04:22:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 12 Dec 2007 23:22:19 -0500 Subject: Request for monotone In-Reply-To: <1197518164.8989.32.camel@cutter> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> Message-ID: <20071212232219.21b60098@redhat.com> On Wed, 12 Dec 2007 22:56:04 -0500 seth vidal wrote: > cvs AFAIK we don't actually offer CVS for hosted projects. Trac doesn't support it, and our first rule should be "Do No Harm" (: -- 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 smooge at gmail.com Thu Dec 13 05:27:47 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 12 Dec 2007 22:27:47 -0700 Subject: Request for monotone In-Reply-To: <20071212232219.21b60098@redhat.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> <20071212232219.21b60098@redhat.com> Message-ID: <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> On Dec 12, 2007 9:22 PM, Jesse Keating wrote: > On Wed, 12 Dec 2007 22:56:04 -0500 > seth vidal wrote: > > > cvs > > AFAIK we don't actually offer CVS for hosted projects. Trac doesn't > support it, and our first rule should be "Do No Harm" (: > I thought the first rule was "Be Evil" and then "Do More Harm". I mean we should be supporting RCS (it works great over SSH) and SCCS. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Thu Dec 13 05:24:13 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Dec 2007 23:24:13 -0600 Subject: Request for monotone In-Reply-To: <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> <20071212232219.21b60098@redhat.com> <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> Message-ID: <4760C1FD.6060902@redhat.com> Stephen John Smoogen wrote: > On Dec 12, 2007 9:22 PM, Jesse Keating wrote: > >> On Wed, 12 Dec 2007 22:56:04 -0500 >> seth vidal wrote: >> >> >>> cvs >>> >> AFAIK we don't actually offer CVS for hosted projects. Trac doesn't >> support it, and our first rule should be "Do No Harm" (: >> >> > > I thought the first rule was "Be Evil" and then "Do More Harm". I mean > we should be supporting RCS (it works great over SSH) and SCCS. > I have to admit I am worried about slippery slope. I'd hate to support a VCS that only has 2 or 3 repos on it. Especially if its not one we have in-house expertise with. -Mike From mastahnke at gmail.com Thu Dec 13 06:10:53 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 13 Dec 2007 00:10:53 -0600 Subject: Request for monotone In-Reply-To: <4760C1FD.6060902@redhat.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> <20071212232219.21b60098@redhat.com> <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> <4760C1FD.6060902@redhat.com> Message-ID: <7874d9dd0712122210n645a3770hab570680f6e7c7c2@mail.gmail.com> On Dec 12, 2007 11:24 PM, Mike McGrath wrote: > Stephen John Smoogen wrote: > > On Dec 12, 2007 9:22 PM, Jesse Keating wrote: > > > >> On Wed, 12 Dec 2007 22:56:04 -0500 > >> seth vidal wrote: > >> > >> > >>> cvs > >>> > >> AFAIK we don't actually offer CVS for hosted projects. Trac doesn't > >> support it, and our first rule should be "Do No Harm" (: > >> > >> > > > > I thought the first rule was "Be Evil" and then "Do More Harm". I mean > > we should be supporting RCS (it works great over SSH) and SCCS. > > > > I have to admit I am worried about slippery slope. I'd hate to support > a VCS that only has 2 or 3 repos on it. Especially if its not one we > have in-house expertise with. > > -Mike > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > I tend to think if you can't use one of the vc systems already provided, you need specialty hosting and with that, probably a lot of care and feeding. We are already offering the most common SCMs in use (except CVS ^^ see above). Always saying 'yes' and allowing new things to pop up is not maintainable in the long term. I am actually surprised we offer as many SCMs as we do. stahnma From paulo.banon at googlemail.com Thu Dec 13 09:15:19 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 13 Dec 2007 10:15:19 +0100 Subject: Request for monotone In-Reply-To: <7874d9dd0712122210n645a3770hab570680f6e7c7c2@mail.gmail.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> <20071212232219.21b60098@redhat.com> <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> <4760C1FD.6060902@redhat.com> <7874d9dd0712122210n645a3770hab570680f6e7c7c2@mail.gmail.com> Message-ID: <7a41c4bc0712130115s318dcd2sbd862fd8ed09568@mail.gmail.com> I tend to agree with stahnma. Currently we already offer the most common SCMs, and from what i can see no one has really good knowledge with monotone, which may be a problem regarding some future troubleshooting/administration/whatever. If we still think that monotone, would be a good addition though, we could always send some emails and see what would be the acceptance of it and the number of projects to be created. For now i would say no to monotone, since we don't have the in-house expertise, and any relevant data on how many projects would be actually using it. Paulo On Dec 13, 2007 7:10 AM, Michael Stahnke wrote: > On Dec 12, 2007 11:24 PM, Mike McGrath wrote: > > Stephen John Smoogen wrote: > > > On Dec 12, 2007 9:22 PM, Jesse Keating wrote: > > > > > >> On Wed, 12 Dec 2007 22:56:04 -0500 > > >> seth vidal wrote: > > >> > > >> > > >>> cvs > > >>> > > >> AFAIK we don't actually offer CVS for hosted projects. Trac doesn't > > >> support it, and our first rule should be "Do No Harm" (: > > >> > > >> > > > > > > I thought the first rule was "Be Evil" and then "Do More Harm". I mean > > > we should be supporting RCS (it works great over SSH) and SCCS. > > > > > > > I have to admit I am worried about slippery slope. I'd hate to support > > a VCS that only has 2 or 3 repos on it. Especially if its not one we > > have in-house expertise with. > > > > -Mike > > > > > > _______________________________________________ > > Fedora-infrastructure-list mailing list > > Fedora-infrastructure-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > I tend to think if you can't use one of the vc systems already > provided, you need specialty hosting and with that, probably a lot of > care and feeding. We are already offering the most common SCMs in use > (except CVS ^^ see above). Always saying 'yes' and allowing new > things to pop up is not maintainable in the long term. I am actually > surprised we offer as many SCMs as we do. > > stahnma > > _______________________________________________ > 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 diaa.radwan at gmail.com Thu Dec 13 10:15:28 2007 From: diaa.radwan at gmail.com (Diaa Radwan) Date: Thu, 13 Dec 2007 12:15:28 +0200 Subject: Request for monotone In-Reply-To: <20071212225532.1211feb3@redhat.com> References: <4760A7FF.3070801@redhat.com> <20071212225532.1211feb3@redhat.com> Message-ID: <182b9f450712130215l12b4bf79s964bf71834b0cc0e@mail.gmail.com> On Dec 13, 2007 5:55 AM, Jesse Keating wrote: > On Wed, 12 Dec 2007 21:33:19 -0600 > Mike McGrath wrote: > > > we've had a request to support monotone on hosted. Instead of having > > this conversation in private I thought it best to put it on the > > list. So thoughts? This is part "do we want to support monotone" and > > part "do we want hosted to be more then svn, hg, git, bzr". > > > > In general I'm happy supporting only those 4, we can't be everything > > for everyone and AFAIK we're the only OSS project with a hosted > > offering that supports 4 SCM's. > > > So far, the SCMs we support have been driven mostly by the SCMs that > Trac supports, with the exception to bzr which I had nothing to do with > setting up. There's trac support for monotone http://tracmtn.1erlei.de/ ; but it won't answer all your questions. > > So the questions are, does Trac support monotone, does monotone lend > itself to a hosted environment (easy ssh commit access, http anon > access, useful web browser, easy to create empty repos for developers > to fill, etc...), is it in EPEL, does it have a security track record, > and uh... is there anybody on the infrastructure team that feels like > they could become our site expert on it? > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > From mmcgrath at redhat.com Thu Dec 13 14:21:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 13 Dec 2007 08:21:26 -0600 Subject: Request for monotone In-Reply-To: <4760A7FF.3070801@redhat.com> References: <4760A7FF.3070801@redhat.com> Message-ID: <47613FE6.2090407@redhat.com> Mike McGrath wrote: > we've had a request to support monotone on hosted. Instead of having > this conversation in private I thought it best to put it on the list. > So thoughts? This is part "do we want to support monotone" and part > "do we want hosted to be more then svn, hg, git, bzr". > > In general I'm happy supporting only those 4, we can't be everything > for everyone and AFAIK we're the only OSS project with a hosted > offering that supports 4 SCM's. > > Thoughts? FIWI I've decided to put this to a vote today in the meeting - #fedora-meeting: https://fedorahosted.org/fedora-infrastructure/ticket/283 -Mike From poelstra at redhat.com Thu Dec 13 17:08:29 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 13 Dec 2007 09:08:29 -0800 Subject: Request for monotone In-Reply-To: <7a41c4bc0712130115s318dcd2sbd862fd8ed09568@mail.gmail.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> <20071212232219.21b60098@redhat.com> <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> <4760C1FD.6060902@redhat.com> <7874d9dd0712122210n645a3770hab570680f6e7c7c2@mail.gmail.com> <7a41c4bc0712130115s318dcd2sbd862fd8ed09568@mail.gmail.com> Message-ID: <4761670D.2000601@redhat.com> Paulo Santos said the following on 12/13/2007 01:15 AM Pacific Time: > I tend to agree with stahnma. Currently we already offer the most common > SCMs, and from what i can see no one has really good knowledge with > monotone, which may be a problem regarding some future > troubleshooting/administration/whatever. > If we still think that monotone, would be a good addition though, we > could always send some emails and see what would be the acceptance of it > and the number of projects to be created. > > For now i would say no to monotone, since we don't have the in-house > expertise, and any relevant data on how many projects would be actually > using it. > > > Paulo Can someone put forth a strong argument as to why monotone provides better functionality than the existing 4 choices? Otherwise I think we have done our due diligence by providing freedom to projects *choose* a SCM from the supported list which includes most of the currently widely used SCMs. Having too many choices isn't always a good thing. One of many links I found on google: http://www.apa.org/monitor/jun04/toomany.html John From ricky at fedoraproject.org Thu Dec 13 20:53:21 2007 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 13 Dec 2007 15:53:21 -0500 Subject: Meeting Log - 2007-12-13 Message-ID: <20071213205321.GG23295@Max.nyc1.dsl.speakeasy.net> 15:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here 15:01 * ricky 15:01 * lmacken 15:01 * f13 15:01 * mmcgrath 15:01 * jeremy 15:01 < jeremy> (although I might disappear in a few) 15:02 * jima 15:02 * jima may disappear at any time, for any or no reason 15:03 -!- bpepple [n=bpepple at adsl-75-60-198-211.dsl.wotnoh.sbcglobal.net] has quit "Ex-Chat" 15:03 < mmcgrath> dgilmore: ping 15:03 < mmcgrath> skvidal: ping 15:03 < mmcgrath> abadger1999: ping 15:03 < mmcgrath> lmacken: ping 15:03 < skvidal> pong 15:03 < mmcgrath> ivazquez: ping 15:03 < paulobanon> pong 15:03 < mmcgrath> iWolf: ping 15:03 -!- notting [i=notting at redhat/notting] has joined #fedora-meeting 15:03 < dgilmore> sup mmcgrath 15:03 < skvidal> -1 15:03 < abadger1999> pong 15:03 < dgilmore> -1 15:03 < ricky> That was fast :) 15:03 < skvidal> oh, wait, sorry, no one asked for a vote on anything, yet 15:03 < paulobanon> yay, in the office working and meeting here so i might split soonish 15:03 < mmcgrath> hehe not voting quite yet. 15:03 < skvidal> -1 anyway 15:03 < mmcgrath> warren: ping 15:03 * warren here 15:03 < mmcgrath> ping anyone else I forgot to ping: ping! 15:04 < dgilmore> skvidal: the answer is always no 15:04 < skvidal> damn right 15:04 < dgilmore> oh wait its 42 15:04 -!- stahnma [n=stahnma at c-76-18-178-254.hsd1.tn.comcast.net] has joined #fedora-meeting 15:04 < jima> dgilmore: 42 "no"s 15:04 < skvidal> dgilmore: or "Run Away" 15:04 < skvidal> which is also a good answer 15:04 < mmcgrath> k, lets get started. 15:04 < mmcgrath> First up is meeting items 15:04 < skvidal> and "I don't care what the machine says, I NEVER TOUCHED THE MAN" 15:04 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Items 15:04 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 15:04 < mmcgrathbot> mmcgrath: http://tinyurl.com/2hyyz6 15:05 -!- giarc [n=cwt at ool-435124e0.dyn.optonline.net] has joined #fedora-meeting 15:05 < mmcgrath> .ticket 192 15:05 < mmcgrathbot> mmcgrath: #192 (Netapp low on free space) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/192 15:05 < mmcgrath> f13: how's the GC stuff going? 15:07 < f13> mmcgrath: a question for mikem, on how close we are to automation. 15:07 < f13> mmcgrath: I think he said we needed some server changes before we could fully automate, but those should be rolled into the new upstream koji release we're doing before the refresh 15:07 < f13> we've got a ton of packages that could be flushed soon. 15:07 -!- MrBawb [i=abob at guppy.drown.org] has joined #fedora-meeting 15:07 < f13> so if we get critical we can flush the trash and recover a lot of space 15:08 -!- mikem23 [i=iimike at nat/redhat/x-b06c3d5d18f5e9d0] has joined #fedora-meeting 15:08 -!- loupgaroublond [n=yankee at pool-72-95-243-109.pitbpa.east.verizon.net] has joined #fedora-meeting 15:08 < mmcgrath> mikem23: yo, we're talking about GC and were wondering how all of that is going. 15:08 < mmcgrath> how close are we to automation on it? 15:09 < jima> i asked the other day if it was feasible to put a control for maintainers to flag (scratch?) builds for deletion sooner rather than later 15:09 < mikem23> mmcgrath, well, I have the cronjobs in place (granted I need to move them to the new host). 15:09 < jima> not sure who the best person to talk to that about is, though. 15:09 < mikem23> mmcgrath, there are some issues I need to smooth out. 15:10 < mmcgrath> jima: your best bet is to file a ticket in the koji queue. 15:10 < mmcgrath> mikem23: solid, but you don't see any blockers or anything that would prevent us from doing automation in the near future? 15:10 < mikem23> 1 - there are some issues that tend to cause some of the nightly gc scripts to fail 15:10 < jima> mmcgrath: *nod* 15:11 < mikem23> 2 - I need to get a few small updates to the koji hub to reduce memory/network usage and fix a silly bug. 15:11 < mikem23> 3 - I need to play with frequency. 15:12 < mikem23> mmcgrath, in principle it's automated now. 15:12 -!- G__ [n=njones at wikipedia/NigelJ] has joined #fedora-meeting 15:12 < warren> Is GC alone going to keep us running through the holidays without more storage 15:12 < mikem23> being run through cron sounds automated to me 15:12 < mmcgrath> just needs some tweaking then? 15:12 < warren> ? 15:12 < mikem23> ok, so about space... 15:12 < mikem23> basically /mnt/koji is too small 15:13 < dgilmore> mikem23: we are working on making it bigger 15:13 < mikem23> now, there are a healthy number of builds headed for deletion in about two weeks 15:13 < mikem23> see, the gc has these grace periods 15:14 < mikem23> if we get desperate, we flush the trashcan by overriding the grace period 15:14 < mikem23> right now the grace period is set to two weeks 15:14 < mmcgrath> Its good to know what our options are. 15:15 < mikem23> http://fedoraproject.org/wiki/Koji/GarbageCollection explains the gc lifecycle 15:15 < f13> I'm farily confident that with what we have queued up to flush, we should be able to make it through the holidays 15:15 < mmcgrath> f13: excellent. 15:15 < mmcgrath> anyone have anything else regarding GC or ticket 192? 15:16 < paulobanon> any plans yet for more storage ? 15:16 < paulobanon> or only after the results of the gc 15:16 < mmcgrath> paulobanon: the plans are in motion but these things always take time. 15:16 < mmcgrath> I should send a followup and see how far along we are. 15:17 < paulobanon> sounds good 15:17 < mmcgrath> anything else? 15:17 < mmcgrath> allrighty, we'll move on. 15:17 < mmcgrath> .ticket 270 15:17 < mmcgrathbot> mmcgrath: #270 (Fedora Wiki allows editing raw HTML) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/270 15:17 < mmcgrath> This is an issue discovered recently and I think it warrents some discussion. 15:17 < mmcgrath> ricky: care to explain further? 15:17 < jima> is there anything on the wiki that genuinely needs raw html? 15:18 < ricky> jima: I think some of the group banners use it, don't remember if the front page uses it right now. 15:18 < mikem23> I don't think the main wiki page would look quite as nice without raw html, but maybe I'm wrong. 15:18 * mikem23 checks 15:18 * jima would have clicked the search link, but didn't want to abuse the poor wiki 15:18 < ricky> Basically, it's possible to put javascript, etc. on the wiki that could access cookies, etc 15:19 < mikem23> ok, I think I'm wrong about that 15:19 < f13> some of the irc logs page use html 15:19 < f13> and I think some of the fever stuff used html 15:19 < ricky> With this version of Moin's auth, the only cookie should be a MOIN_ID (which would just give full control over the wiki account), but that's pretty much the full extent of it. 15:20 < dgilmore> ricky: that could be bad 15:20 < mikem23> we should probably look at how raw html is used and see is we can replace it with macros instead 15:20 < abadger1999> dgilmore: Moin's cookie is already subject to sniffing.... 15:20 < mmcgrath> So the options here are A) Acknowledge the security issue and try to negate it as much as possible or B) disable html editing. 15:21 < lmacken> 416 pages are using raw html 15:21 < dgilmore> mmcgrath: i vote to disable it 15:21 < mmcgrath> Anyone interested in keeping it? 15:21 < lmacken> err.. maybe not pages, but "matches" 15:22 < mmcgrath> ricky: what would happen to the current pages if we did disable it? 15:22 < paulobanon> we will have to announce it prior to the disable to make sure that the other teams fix their stuff 15:22 * ricky tests something. 15:22 < mmcgrath> paulobanon: yeah 15:22 < abadger1999> If upstream moin implements a "safe html" which doesn't accept scripts we could reenable. 15:22 < mmcgrath> its possible they already have that and we just don't know it. 15:23 < paulobanon> abadger1999: im sure they wont implement anything new until 1.6 is out, until we do it our selfs and offer the patch to them 15:23 < paulobanon> mmcgrath: last time i checked we were using the latest Moin-stable 15:23 < paulobanon> havent checked for the last 1 or 2 months though 15:23 -!- G [n=njones at wikipedia/NigelJ] has quit Connection timed out 15:24 < mmcgrath> ricky: what are you testing and how long will it take? :) 15:24 < ricky> Looks like it'll just show the HTML source. 15:24 < abadger1999> paulobanon: I checked ~1 week ago and we're still on the latest stable. 15:24 < mmcgrath> k 15:24 < ricky> (just looking at what {{{#!fake test}}} does) 15:24 < mmcgrath> I also say we disable it until such a time comes that we can make sure scripts won't be allowed. 15:24 < lmacken> we would probably lose stuff like the spiffy sidebar in http://fedoraproject.org/wiki/Artwork 15:25 < mmcgrath> ricky: paulobanon: will one of you guys put together a one or two week plan to notify everyone about what we're going to do, why and then do it? 15:25 < loupgaroublond> is it possible to make a template that provides sidebar like capabilities in moin? 15:26 < paulobanon> loupgaroublond: i think that there is a theme with some sidebars, not sure though 15:26 < ricky> loupgaroublond: Yeah, I think we can create macros that output certain HTML. 15:27 < loupgaroublond> that answers lmacken's question then :) 15:27 < paulobanon> mmcgrath: sounds good. Is there any "general" ML that can be used to inform everyone related ? 15:27 < warren> "safe html" in other sites has proven to be ... unsafe 15:27 < warren> everyone reinvents the wheel and gets it wrong 15:28 < paulobanon> warren: sad, but true 15:28 < mmcgrath> paulobanon: send an email to fedora-announce-list, I don't think enough of the right people are on fedora-devel-announce 15:28 -!- cwt_ [n=cwt at ool-435124e0.dyn.optonline.net] has joined #fedora-meeting 15:28 * ricky sees http://moinmo.in/HelpOnMacros#head-7c57db7e2451458a42840f17268344df06492a2e, I'll start looking at create macros for common uses. 15:28 < warren> "Sorry, your your new trapezoidal wheel isn't working out for us." 15:30 < mmcgrath> Solid, anyone have anything else to comment on that ticket? 15:30 < MrBawb> speaking of safe html, I'm looking at an exploit that gets in via an activex exploit 15:30 < MrBawb> and uploads a keylogger to windows machines 15:31 < mmcgrath> ok, moving on. To the vote! 15:31 < mmcgrath> .ticket 283 15:31 < mmcgrathbot> mmcgrath: #283 (Vote: Support Monotone?) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/283 15:31 < mmcgrath> Little background. 15:31 < dgilmore> mmcgrath: there website lists "Monotone is slow, doesn't scale well to large codebases and historeis." 15:31 < mmcgrath> We've had a request from Roland McGrath to support monotone because he wants to host elfutils on fedora hosted. 15:31 -!- llaumgui [n=llaumgui at cro34-2-82-226-153-125.fbx.proxad.net] has quit Remote closed the connection 15:31 < dgilmore> eww 15:31 < mmcgrath> I've not heard back whether or not it can even be integrated with FAS but assuming it can, lets take the vote. 15:32 < mmcgrath> ============= Vote Start 2 minutes =========== 15:32 < dgilmore> -1 15:32 -!- llaumgui [n=llaumgui at cro34-2-82-226-153-125.fbx.proxad.net] has joined #fedora-meeting 15:32 < f13> I won't vote until the questions I asked on list are answered. 15:32 < abadger1999> +0 I'm not against monotone. I am against monotone without some monotone-familiar admins joining infra. 15:32 < loupgaroublond> who is eligible to vote? 15:32 < f13> or rather, I won't vote /for/ monotone 15:32 -!- llaumgui [n=llaumgui at cro34-2-82-226-153-125.fbx.proxad.net] has quit Remote closed the connection 15:32 < mmcgrath> f13: would you like us to vote next week? 15:33 < dgilmore> mmcgrath: id like to see us support elfutils but i dont see what we gain by monotone 15:33 < f13> mmcgrath: well, if we don't have anybody who can answer the questions I posed, I"ll just vote -1 15:33 -!- bpepple [n=bpepple at adsl-75-60-198-211.dsl.wotnoh.sbcglobal.net] has joined #fedora-meeting 15:33 < lmacken> I'm all for turning elfutils into an open source project (finally).. but unless roland or someone else steps up to help us with monotone, I'm a bit weary towards it 15:34 < mmcgrath> lmacken: I'm not even sure I like the sound of that. 15:34 < mmcgrath> I worry about people showing up to work on just one thing. 15:34 < lmacken> yeah, true 15:34 < mmcgrath> they tend not to be around when you need them. 15:35 < mmcgrath> Ok, I think monotone is a bit unclear to all of us here, let me see if we can get Roland to answer these questions by next week and we'll vote then. In the meantime we can all do a little research. 15:35 < mmcgrath> I guess we're not in a hurry to say yes or no to it. 15:35 * ricky sees http://monotone.ca/docs/Other-Transports.html. 15:35 < mmcgrath> ================ Vote End =============== 15:35 < loupgaroublond> is there any chance that one project can be moved over to another scm? 15:35 -!- llaumgui [n=llaumgui at cro34-2-82-226-153-125.fbx.proxad.net] has joined #fedora-meeting 15:35 < mmcgrath> we'll do it next week. 15:35 < mmcgrath> loupgaroublond: what do you mean? 15:36 < loupgaroublond> have him switch over to git or hg, or does it have to be monotone? 15:36 < warren> I've used monotone myself, it is very capable, the pidgin project uses it. 15:36 < warren> loupgaroublond, or bzr 15:36 < loupgaroublond> or bzr, sure :) 15:36 < mmcgrath> loupgaroublond: I haven't specifically asked that but I will. 15:37 < loupgaroublond> i'm not asking if monotone is good or not, i'm jsut asking if we can ask roland to switch to something else, because i feel like this debate could get very hairy otherwise 15:38 -!- jcollie [n=jcollie at 161.210.6.204] has joined #fedora-meeting 15:38 < abadger1999> ricky: That's a good doc. That seems like half the battle. Still have to find out about anonymous access. 15:38 < warren> It does add risk to our server to add more and more different systems 15:38 * mmcgrath really wants to leave it at 4 systems. 15:38 < warren> we might justify adding monotone only if several other projects want it 15:38 < mmcgrath> err scms. 15:39 < loupgaroublond> does trac support monotone? 15:39 < ricky> loupgaroublond: I saw a plugin mentioned, but pidgin's trac doesn't seem to have support enabled. 15:39 -!- giarc [n=cwt at ool-435124e0.dyn.optonline.net] has quit Read error: 110 (Connection timed out) 15:39 * mmcgrath just sent jesse's questions and some others to Roland McGrath, we should know more next week. 15:39 * ricky recalls the "fun" that we've already had with the git plugin. 15:40 * mmcgrath blames the git plugin for all the zombie git processes we see on hosted1. 15:40 < mmcgrath> anywho. 15:40 * abadger1999 notes that gna has support four three SCMs so we're not the only project with multiple SCMs for hosting. 15:40 < mmcgrath> anyone have anything else to discuss on this topic? 15:40 < abadger1999> s/four/for/ 15:40 < mmcgrath> abadger1999: excellent, which scms are they? 15:40 < abadger1999> cvs, svn, and tla 15:41 < warren> we're in way better shape 15:41 < warren> those suck =) 15:41 < abadger1999> Well... way more modern :-) 15:41 < mmcgrath> :) 15:41 * paulobanon wants to do an off-time vote -1 15:41 < mmcgrath> Alrighty, moving on.... 15:42 -!- J5 [i=quintice at nat/redhat/x-6905b79a0881d913] has quit "Ex-Chat" 15:42 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Schedule 15:42 < mmcgrath> http://fedoraproject.org/wiki/Infrastructure/Schedule 15:42 < mmcgrath> Nothing much new going on there. 15:42 -!- J5 [i=quintice at nat/redhat/x-85cfe85621f1df08] has joined #fedora-meeting 15:42 < mmcgrath> The coporate sponsorship is still the same though we need to get pier1 or serverbeach's logo on the hosted site (I'm still waiting for them to send it) 15:43 < mmcgrath> no new documentation or SOP's that I can think of from this week. 15:43 < mmcgrath> And no new sponsors that I can think of. 15:43 < mmcgrath> so, nothing there. 15:43 < mmcgrath> and with that... 15:43 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:43 < mmcgrath> does anyone have anything they'd like to discuss? 15:43 < paulobanon> anything new with the bladecenter or the german server ? 15:43 < mmcgrath> Nothing new with the blade center. 15:44 < mmcgrath> the german server got shipped to a RH office and is now being shipped to the colo. 15:44 < skvidal> are we going to have a meeting next week? 15:44 * mmcgrath not sure what happened there but is trying to find out so it doesn't happen in the future. 15:44 < skvidal> I ask b/c I'm sure a lot of people are traveling or planning travel 15:44 < mmcgrath> skvidal: on the 20th? 15:44 < dgilmore> skvidal: hope not ill be on a train i think 15:44 < paulobanon> its my birthday! 15:44 < paulobanon> :D 15:44 < mmcgrath> skvidal: I'll go ahead and try to schedule one but if no one shows up it will likely be very very short. 15:45 < skvidal> okie doke 15:45 < skvidal> I'll be around 15:45 < skvidal> I just thought I'd ask 15:45 < abadger1999> I wrote an initial patch to get moin to handle subscriptions better. MrBawb has been doing an excellent job of enhancing that. 15:45 < mmcgrath> yeah if you guys haven't seen MrBawb's benchmarking you should, he's done a good job. 15:45 < paulobanon> mmcgrath: where can i read it ? 15:46 < dgilmore> mmcgrath: my train gets to union station at 12:15pm next thurs 15:46 < mmcgrath> dgilmore: you've got a busy day ahead of you :) 15:46 < dgilmore> mmcgrath: that i do 15:46 < mmcgrath> MrBawb: where are your benchmarks? 15:46 < abadger1999> MrBawb is working on getting it to the place that upstream will accept it. 15:47 < abadger1999> I think we should start thinking about whether/when we want to apply it to our installation. 15:47 < ricky> Curious - what's the ACL patch that we're currently using? 15:47 < MrBawb> mmcgrath: http://dan.drown.org/fedora/compare-storage.html 15:48 < MrBawb> right now I'm working on getting the code to the standards that the MoinMoin people want 15:48 < MrBawb> naming, and using their locking,e tc 15:48 < mmcgrath> ricky: it allows us to set an acl on say /InfrastructurePrivate/ and having it automatically apply to /InfrastructurePrivate/CreditCards 15:49 < ricky> Aha. 15:49 < mmcgrath> Alrighty, anyone have anything else? If not I'll close the meeting in 30. 15:51 < mmcgrath> 15 15:51 < mmcgrath> 5 15:51 < paulobanon> go go go 15:51 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mdehaan at redhat.com Thu Dec 13 21:35:43 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 13 Dec 2007 16:35:43 -0500 Subject: Request for monotone In-Reply-To: <4761670D.2000601@redhat.com> References: <4760A7FF.3070801@redhat.com> <935ead450712121950s424a2e2bg22e3e1d324e28beb@mail.gmail.com> <1197518164.8989.32.camel@cutter> <20071212232219.21b60098@redhat.com> <80d7e4090712122127g2d85a57fs24052309c574de75@mail.gmail.com> <4760C1FD.6060902@redhat.com> <7874d9dd0712122210n645a3770hab570680f6e7c7c2@mail.gmail.com> <7a41c4bc0712130115s318dcd2sbd862fd8ed09568@mail.gmail.com> <4761670D.2000601@redhat.com> Message-ID: <4761A5AF.2010107@redhat.com> John Poelstra wrote: > Paulo Santos said the following on 12/13/2007 01:15 AM Pacific Time: >> I tend to agree with stahnma. Currently we already offer the most >> common SCMs, and from what i can see no one has really good knowledge >> with monotone, which may be a problem regarding some future >> troubleshooting/administration/whatever. >> If we still think that monotone, would be a good addition though, we >> could always send some emails and see what would be the acceptance of >> it and the number of projects to be created. >> >> For now i would say no to monotone, since we don't have the in-house >> expertise, and any relevant data on how many projects would be >> actually using it. >> >> >> Paulo > > Can someone put forth a strong argument as to why monotone provides > better functionality than the existing 4 choices? Otherwise I think > we have done our due diligence by providing freedom to projects > *choose* a SCM from the supported list which includes most of the > currently widely used SCMs. +1. Doing something to curb rapid-SCM-expansion we're seeing everywhere would be welcome IMHO, and might do some good in getting people to contribute more on the big 4 (or 5, or 6, etc). I heard someone comment how he needed to understand 6 SCM tools to understand all the upstreams his project was using. I know I'm not helping to maintain any of our existing SCM support, but it seems like it would be creating a lot of extra work for infrastructure and not many people would use it. Bigger fish to fry? Besides, everyone should just be using git :) --Michael From mmcgrath at redhat.com Thu Dec 13 21:58:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 13 Dec 2007 15:58:32 -0600 Subject: Request for monotone In-Reply-To: <20071212225532.1211feb3@redhat.com> References: <4760A7FF.3070801@redhat.com> <20071212225532.1211feb3@redhat.com> Message-ID: <4761AB08.1090803@redhat.com> Jesse Keating wrote: > On Wed, 12 Dec 2007 21:33:19 -0600 > Mike McGrath wrote: > > >> we've had a request to support monotone on hosted. Instead of having >> this conversation in private I thought it best to put it on the >> list. So thoughts? This is part "do we want to support monotone" and >> part "do we want hosted to be more then svn, hg, git, bzr". >> >> In general I'm happy supporting only those 4, we can't be everything >> for everyone and AFAIK we're the only OSS project with a hosted >> offering that supports 4 SCM's. >> > > > So far, the SCMs we support have been driven mostly by the SCMs that > Trac supports, with the exception to bzr which I had nothing to do with > setting up. > > So the questions are, does Trac support monotone, does monotone lend > itself to a hosted environment (easy ssh commit access, http anon > access, useful web browser, easy to create empty repos for developers > to fill, etc...), is it in EPEL, does it have a security track record, > and uh... is there anybody on the infrastructure team that feels like > they could become our site expert on it? > Reply (slightly edited) from Roland: > How do we integrate access control with the Fedora Account System? > > Can it integrate with FAS somehow? > > Does it have easy ssh based commit access? > The ssh-based access is just like ssh-based access to git, so the account system integration is exactly the same except for what the forced command to run the server is. The simplest thing is to support only ssh-based access. To support monotone's own authenticated TCP protocol would require a simple hook in the account system to maintain a flat file listing write-authorized key identifiers (user at domain). (The public key bits themselves live in the repository database and can get there just by an ssh-authorized user making a commit.) > > Does it have http based anonymous access? > No kind of direct access is based on http. It is very easy to set up its own TCP protocol server for anonymous-only access, or to have an "anonymous" ssh user. (With the caveat of one shared database, as I explained earlier.) > > Does trac support it? > Not AFAIK, but I would be willing to work on it if it buys something. We are not interested in using Trac for elfutils any time soon. (We use Fedora bugzilla and that is all we need in the way of formality.) > > Does it have a useful Web browser view? > Yes, see http://viewmtn.angrygoats.net/ for an example. I have not packaged viewmtn for Fedora yet, but I would be glad to do it and make this very simple to set up. > > How easy is it to create new repos? > Trivial. You need a directory that the server daemon (for non-ssh server setup) or ssh user can write, and then initialization is one quick command. > > How long until we get monotone in EPEL? > For EL5, it's only as long as it takes me to figure out how to request the branch. > > What is its security track record? > I've never heard of an exploit. The monotone project (http://monotone.ca) and others have had public servers running for a long time (since long before git existed, for example). -Mike From jkeating at redhat.com Fri Dec 14 02:45:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 13 Dec 2007 21:45:43 -0500 Subject: Request for monotone In-Reply-To: <4761AB08.1090803@redhat.com> References: <4760A7FF.3070801@redhat.com> <20071212225532.1211feb3@redhat.com> <4761AB08.1090803@redhat.com> Message-ID: <20071213214543.145a9036@redhat.com> On Thu, 13 Dec 2007 15:58:32 -0600 Mike McGrath wrote: > No kind of direct access is based on http. It is very easy to set up > its own TCP protocol server for anonymous-only access, or to have an > "anonymous" ssh user. (With the caveat of one shared database, as I > explained earlier.) This would be my only real concern then. To be good upstreams we have to allow for anon access to the code, so I would like to see a packaged server to serve anon access. But the rest of the answers seem to be fair and it would be something of a boon to get elfutils out in the open. -- 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 dlutter at redhat.com Fri Dec 14 21:57:20 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 14 Dec 2007 13:57:20 -0800 Subject: fedorahosted.org is ready for testing In-Reply-To: <475FEF72.20503@redhat.com> References: <475EED6E.1040005@redhat.com> <20071212101900.GA4164@dudweiler.stuttgart.redhat.com> <475FED69.8080308@redhat.com> <475FEF72.20503@redhat.com> Message-ID: <1197669440.12473.12.camel@localhost.localdomain> On Wed, 2007-12-12 at 08:25 -0600, Mike McGrath wrote: > Mike McGrath wrote: > > > > We've had luke working on this a little, I still have yet to see a > > solid proposal on how to config manage puppet modules and deploy them > > on a larger scale. All of the selinux tools I've seen work at the > > machine level. > > Sorry, this should s/puppet modules/selinux policies/ Very timely typo though; there's some people on the puppet lists who are interested in distributing selinux policy through puppet[1] Might be worth for whoever is doing that for Fedora infrastructure to get in touch with them. David [1] http://mail.madstop.com/pipermail/puppet-users/2007-December/005493.html From jonathansteffan at gmail.com Sat Dec 15 05:53:16 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Fri, 14 Dec 2007 22:53:16 -0700 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <475FC387.50000@proxad.net> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <20071211134750.47894a0b@damaestro> <475FC387.50000@proxad.net> Message-ID: <20071214225316.752391b5@damaestro> On Wed, 12 Dec 2007 12:18:31 +0100 Francois Petillon wrote: > I will speak as a mirror admin (ftp.free.fr/ftp.proxad.net). As far > as I am concerned, bandwidth is not a real issue but disk IOs are. -SNIP- > As long as jigdo use is uncommon, I just don't mind but if it had to > be commonly used, it would mean a very sensible decrease in > performances. So, you are against deltarpms also then? The access time for the data being served as a Jigdo would be the same as anyone using yum against your mirror source. Also, in most cases download requests would be spread across multiple sources... though this can be changed by an end user or by the behavior of MirrorManager redirection results. -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From opensource at till.name Sat Dec 15 20:15:22 2007 From: opensource at till.name (Till Maas) Date: Sat, 15 Dec 2007 21:15:22 +0100 Subject: fedorahosted.org is ready for testing In-Reply-To: <475EED6E.1040005@redhat.com> References: <475EED6E.1040005@redhat.com> Message-ID: <200712152115.28490.opensource@till.name> Hiyas, On Tuesday 11 December 2007 21:05:02 Mike McGrath wrote: > Git users: > http://git.fedorahosted.org/git/$PROJECT (anon, ro) > HG users: > http://hg.fedorahosted.org/hg/$PROJECT (anon, ro) > BZR users: > http://bzr.fedorahosted.org/bzr/$PROJECT (anon, ro) > SVN users: > http://svn.fedorahosted.org/svn/$PROJECT (anon, ro) Will there be https access to these locations, too? 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 opensource at till.name Sat Dec 15 20:24:04 2007 From: opensource at till.name (Till Maas) Date: Sat, 15 Dec 2007 21:24:04 +0100 Subject: fedorahosted.org is ready for testing In-Reply-To: <475EED6E.1040005@redhat.com> References: <475EED6E.1040005@redhat.com> Message-ID: <200712152124.06483.opensource@till.name> On Tuesday 11 December 2007 21:05:02 Mike McGrath wrote: > the hosted.fedoraproject.org cert and throw a warning). Feel free to > test by checking out and committing to your repo, those changes (if ^^^^^^^^^^^^^^^^^ > using fedorahoste.org addresses below) will be wiped out when we do the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > final move. Is this still the plan/situation? It seems to me that hosted.fedoraproject.org and fedorahosted.org serve the same content. 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 lee at wb0tra.no-ip.org Sat Dec 15 22:35:38 2007 From: lee at wb0tra.no-ip.org (Lee Lorentz) Date: Sat, 15 Dec 2007 16:35:38 -0600 Subject: New member introduction Message-ID: <002001c83f6a$d1699520$0400a8c0@xp1> Sorry; my subscription to the list was using the wrong email address. Should be fixed now. -----Original Message----- From: Lee Lorentz [mailto:lee at wb0tra.no-ip.org] Sent: Saturday, December 15, 2007 16:23 To: 'fedora-infrastructure-list at redhat.com' Subject: New member introduction I'm still working through the "Getting Started" instructions for Infrastructure and the web page says it is time to introduce myself. Lee Lorentz in Annandale, Minnesota, USA. Email I've been a PC database developer and programmer since the dBASE II days (early 1980's?). I'm currently migrating from Visual FoxPro over to the LAMP stack for development work. I manage a database (MySQL on CentOS v4) at work with over 75 million records in a single table, so database performance is a big deal for me. My official bachelors degree is in "Elective Studies" (nice generic title) but the course concentration was in networking and systems analysis. My first Linux exposure was to Mandrake for which I can't remember the version and I've been a Fedora user since FC2. I now have boxes at home running FC6, F7, and CentOS v4, and I hope to soon have a new laptop running F8. I've been working with MySQL for 2-3 years now and about the same with php. I don't claim to be an expert with either but I've already been able to make some small contributions in optimizing queries for smolt. I hope to be able to make further contributions along this line, but am open to requests to help out anywhere someone thinks I can help. I put in a lot of hours at work so I'm uncertain how much I can contribute but given the benefits I've gained from using Fedora I want to try to give something back. My nics on irc are wb0tra_home and wb0tra_work. "WB0TRA" is my ham radio license which I've held since 1975. I try to maintain connections to the fedora-admin, mysql, smolt, fedora-unity, scalug, and scalug-hams channels. You can see more info on me at my home page http://wb0tra.no-ip.org/ and at http://www.qrz.com/callsign/WB0TRA From mmcgrath at redhat.com Sat Dec 15 23:58:42 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 15 Dec 2007 17:58:42 -0600 Subject: fedorahosted.org is ready for testing In-Reply-To: <200712152115.28490.opensource@till.name> References: <475EED6E.1040005@redhat.com> <200712152115.28490.opensource@till.name> Message-ID: <47646A32.3060707@redhat.com> Till Maas wrote: > Hiyas, > > On Tuesday 11 December 2007 21:05:02 Mike McGrath wrote: > > >> Git users: >> http://git.fedorahosted.org/git/$PROJECT (anon, ro) >> > > >> HG users: >> http://hg.fedorahosted.org/hg/$PROJECT (anon, ro) >> > > >> BZR users: >> http://bzr.fedorahosted.org/bzr/$PROJECT (anon, ro) >> > > >> SVN users: >> http://svn.fedorahosted.org/svn/$PROJECT (anon, ro) >> > > Will there be https access to these locations, too? > > No. -Mike From mmcgrath at redhat.com Sat Dec 15 23:59:05 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 15 Dec 2007 17:59:05 -0600 Subject: fedorahosted.org is ready for testing In-Reply-To: <200712152124.06483.opensource@till.name> References: <475EED6E.1040005@redhat.com> <200712152124.06483.opensource@till.name> Message-ID: <47646A49.7040800@redhat.com> Till Maas wrote: > On Tuesday 11 December 2007 21:05:02 Mike McGrath wrote: > > >> the hosted.fedoraproject.org cert and throw a warning). Feel free to >> test by checking out and committing to your repo, those changes (if >> > ^^^^^^^^^^^^^^^^^ > >> using fedorahoste.org addresses below) will be wiped out when we do the >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> final move. >> > > Is this still the plan/situation? It seems to me that hosted.fedoraproject.org > and fedorahosted.org serve the same content. > They do, in the future they will not and hosted.fedoraproject.org will go away. -Mike From mmcgrath at redhat.com Mon Dec 17 05:43:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 16 Dec 2007 23:43:00 -0600 Subject: Notice: puppet on the boxes Message-ID: <47660C64.4080706@redhat.com> During an update of the builders last night we also did a puppet update and some incompatibilities between the old and new puppet versions exist. I plan on updating the rest of the servers tomorrow morning but in the meantime if you make a change it might not end up on the servers immediately. If I find any issues we may have to roll back the builders. -Mike From fantec at proxad.net Mon Dec 17 16:26:46 2007 From: fantec at proxad.net (Francois Petillon) Date: Mon, 17 Dec 2007 17:26:46 +0100 Subject: Jigdo - A Professional Letter to Mike McGrath In-Reply-To: <20071214225316.752391b5@damaestro> References: <20071206142813.5dcc973f@damaestrojr> <47595D2A.1090007@redhat.com> <47596372.3060208@kanarip.com> <47596434.9090004@redhat.com> <47596747.2030503@kanarip.com> <475DC3F3.707@redhat.com> <20071211134750.47894a0b@damaestro> <475FC387.50000@proxad.net> <20071214225316.752391b5@damaestro> Message-ID: <4766A346.4020603@proxad.net> Jonathan Steffan wrote: > So, you are against deltarpms also then? The problem is not being for / against anything. Deltarpms may be interesting for low-bandwidth client that would keep all downloaded rpms. But it would be a IO waste for servers if users have to download several files to rebuild the final ISO. I was just trying to remind the choices you make may change servers efficiency (and as all mirrors do not have the same issues, it would be difficult to please everyone). > The access time for the data being served as a Jigdo would be the same > as anyone using yum against your mirror source. Yes. But it would be more IO costy than downloading an ISO if you have to download most of the packages to build the ISO. > Also, in most cases download requests would be spread across multiple > sources... At the server level (and as long as you do not speak about parallelizing downloads), there won't be much difference (you will still have to manage n% of the downloads/connections). Fran?ois From a.badger at gmail.com Mon Dec 17 17:17:39 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 17 Dec 2007 09:17:39 -0800 Subject: python-fedora: fas1 API addition Message-ID: <4766AF33.8020103@gmail.com> This is mostly for the people developing python/TG apps that need to talk to the Account System. If you are querying fas1 using the fedora.accounts.fas module you may want to look into porting to a new method I added and deployed over the weekend. The method is get_users() and it returns public information about all the users in the FAS. This is useful when you have to hit the FAS for a lot of information about people -- for instance, querying the FAS to map userid's to human_name for every person in your db. In that scenario you would have to spend a large amount of time waiting for the db to respond to your queries if you had to send them as individual requests via get_user_info(). This has recently become more of an issue since we're starting to create app servers outside of the phx colo. Those servers take more time to contact the db server inside of phx which means every round trip to the db server is more expensive. Example usage[*]: >>> from fedora.accounts.fas import AccountSystem >>> fas = AccountSystem() >>> userList = fas.get_users() >>> print userList[100068]['username'] toshio >>> userListByName = fas.get_users(keyField='username') >>> print userListByName['toshio']['id'] 100068 Refer to the docstring for more information: $ pydoc fedora.accounts.fas.AccountSystem.get_users [*] You'll need to be able to access the fedora-db-access file to actually use this code. Your TG app running under supervisor has that permission but your regular user may not. -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 mmcgrath at redhat.com Tue Dec 18 16:45:22 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 18 Dec 2007 10:45:22 -0600 Subject: FUDCon / Hackfest Message-ID: <4767F922.8050302@redhat.com> I've added a couple of topics to the http://barcamp.org/FUDConRaleigh2008 site. One of which is all about Fedora Infrastructure. I'd like it is those of you on the team can make it to this meeting to talk with others about Infrastructure, what we're doing, where we're going and our general philosophies. Not at all mandatory, as with any barcamp, there's bound to be lots of good topics going on at once. I've also got a FAS2 topic on there (Hopefully ricky will co-talk that one with me). Also during the hackfest its important for the infrastructure team members to be alert at the needs of whats going on. At the last hackfest I ended up spending most of my time accomplishing tasks that the other teams / people needed to get their work done. So mostly this is just a heads up, those of you on the teams will likely be asked to do stuff during the hack fest, make sure to set a little time aside for it :) Also if anyone else out there has anything they think is worth talking about don't hesitate to add it to the list. -Mike From mmcgrath at redhat.com Wed Dec 19 23:00:40 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 19 Dec 2007 17:00:40 -0600 Subject: Search domains in our environment (Proposal) Message-ID: <4769A298.8070008@redhat.com> Note: I'm treading into an area which I've always deemed bad practice so poke, prod and question where required. Right now we are using /etc/hosts relatively heavily in our environment. This is to help us clean up our apache configs and further blur the line of our servers and where they live. The suggestion in the past has been to host our own DNS server in PHX that provides a common view to fedoraproject.org but inside PHX. (You'll not that you cannot get to fedoraproject.org from inside PHX). Now that we have a vpn.fedoraproject.org domain, this allows us to do some dns trickery that we could not do before. So, for example, on bastion you can see this in action. The current search location set to: search fedora.phx.redhat.com vpn.fedoraproject.org fedoraproject.org So on bastion you can ping app1 which will use 10.8.34.59. However if I ping proxy3 (which is not in phx) I'll get address 192.168.1.7. and if I ping torrent (which is not in phx and not on the vpn) I'll get address 152.3.220.165. In theory, this will allow us to do interesting things in our german colo (they have the server now BTW, we are just waiting on IP info, it just got there yesterday). The trick here is having each group of servers have a preference for the local address. There's no reason for proxy1 to contact app1 over the vpn as they're on the same LAN. And there could, in theory, be instances where we'd want the serverbeach servers to have preference for other serverbeach servers. In cases of geographically separated servers this actually does add a tiny amount of redundancy. In that if a link goes down or dns goes down but the box does have connectivity to the internet still somehow, it might be able to get to the vpn instead of its direct connection. Again, tiny but there especially true when we get our redundant VPN server installed. So what does this mean? * You'll be able to get to any vpn host in our environment without having to know where it is. * We'll have to change any reference to fqdn's where our servers are contacting other servers. This will allow us to move servers around, even to other data centers, without having to change the configs. * The proxy servers are in a slightly special situation right now. We're using hosts entries on the proxy servers mostly because our DNS server in PHX flaked out on us once. We can re-examine this setup even still, to be consistent I'd like to switch to using non-fqdn access to our application servers. * We will have to be diligent in making sure all of our hosts have unique names as we've basically made the domain names negligent. * This will allow us to have a preference for vpn, remote or local traffic on a per machine basis should the need arise. (so for example, We get part of a DR site up and PHX goes down. We could very easily login to proxy3, change the search from vpn being first to local as both app5 and proxy3 are in tummy.com and we can be more efficient that way) Comments? +1's? -1's? I'm basically going for ease of use among the admins and since most people "ssh puppet1" instead of "ssh puppet1.fedora.phx.redhat.com" I think in our diverse environment it will be worth it and is easier then hosting a separate DNS server in each of our locations. -Mike From mmcgrath at redhat.com Wed Dec 19 23:06:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 19 Dec 2007 17:06:43 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <4769A298.8070008@redhat.com> References: <4769A298.8070008@redhat.com> Message-ID: <4769A403.6080404@redhat.com> Mike McGrath wrote: > Comments? +1's? -1's? I'm basically going for ease of use among the > admins and since most people "ssh puppet1" instead of "ssh > puppet1.fedora.phx.redhat.com" I think in our diverse environment it > will be worth it and is easier then hosting a separate DNS server in > each of our locations. I forgot to mention one other concern. A MitM attack or DNS poisoning. This possibility does exist, but exists in our environment as is anyway. This is something we should look at mitigating but other than running a DNS server at every site, I'm not totally sure how to fix it. I consider all of our donations as partnerships. After all, they have local access to the box. At the same time though it is something we should count as a risk and mitigate as much as possible. -Mike From smooge at gmail.com Wed Dec 19 23:19:42 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 19 Dec 2007 16:19:42 -0700 Subject: Search domains in our environment (Proposal) In-Reply-To: <4769A403.6080404@redhat.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> Message-ID: <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> On Dec 19, 2007 4:06 PM, Mike McGrath wrote: > Mike McGrath wrote: > > Comments? +1's? -1's? I'm basically going for ease of use among the > > admins and since most people "ssh puppet1" instead of "ssh > > puppet1.fedora.phx.redhat.com" I think in our diverse environment it > > will be worth it and is easier then hosting a separate DNS server in > > each of our locations. > > > I forgot to mention one other concern. A MitM attack or DNS poisoning. > This possibility does exist, but exists in our environment as is > anyway. This is something we should look at mitigating but other than > running a DNS server at every site, I'm not totally sure how to fix it. > I consider all of our donations as partnerships. After all, they have > local access to the box. At the same time though it is something we > should count as a risk and mitigate as much as possible. > As far as I can tell the only way to lower the risk of DNS poisoning is local DNS servers. Having them getting DNS files from a central host via a signed methodology would be not much different than /etc/hosts except you can use other tricks and failovers -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Wed Dec 19 23:15:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 19 Dec 2007 17:15:00 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> Message-ID: <4769A5F4.2010401@redhat.com> Stephen John Smoogen wrote: > On Dec 19, 2007 4:06 PM, Mike McGrath wrote: > >> Mike McGrath wrote: >> >>> Comments? +1's? -1's? I'm basically going for ease of use among the >>> admins and since most people "ssh puppet1" instead of "ssh >>> puppet1.fedora.phx.redhat.com" I think in our diverse environment it >>> will be worth it and is easier then hosting a separate DNS server in >>> each of our locations. >>> >> I forgot to mention one other concern. A MitM attack or DNS poisoning. >> This possibility does exist, but exists in our environment as is >> anyway. This is something we should look at mitigating but other than >> running a DNS server at every site, I'm not totally sure how to fix it. >> I consider all of our donations as partnerships. After all, they have >> local access to the box. At the same time though it is something we >> should count as a risk and mitigate as much as possible. >> >> > > As far as I can tell the only way to lower the risk of DNS poisoning > is local DNS servers. Having them getting DNS files from a central > host via a signed methodology would be not much different than > /etc/hosts except you can use other tricks and failovers > We could also implement stricter IP tables rules regarding creating external TCP connections. -Mike From smooge at gmail.com Wed Dec 19 23:33:41 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 19 Dec 2007 16:33:41 -0700 Subject: Search domains in our environment (Proposal) In-Reply-To: <4769A5F4.2010401@redhat.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> Message-ID: <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> On Dec 19, 2007 4:15 PM, Mike McGrath wrote: > Stephen John Smoogen wrote: > > On Dec 19, 2007 4:06 PM, Mike McGrath wrote: > > > >> Mike McGrath wrote: > >> > >>> Comments? +1's? -1's? I'm basically going for ease of use among the > >>> admins and since most people "ssh puppet1" instead of "ssh > >>> puppet1.fedora.phx.redhat.com" I think in our diverse environment it > >>> will be worth it and is easier then hosting a separate DNS server in > >>> each of our locations. > >>> > >> I forgot to mention one other concern. A MitM attack or DNS poisoning. > >> This possibility does exist, but exists in our environment as is > >> anyway. This is something we should look at mitigating but other than > >> running a DNS server at every site, I'm not totally sure how to fix it. > >> I consider all of our donations as partnerships. After all, they have > >> local access to the box. At the same time though it is something we > >> should count as a risk and mitigate as much as possible. > >> > >> > > > > As far as I can tell the only way to lower the risk of DNS poisoning > > is local DNS servers. Having them getting DNS files from a central > > host via a signed methodology would be not much different than > > /etc/hosts except you can use other tricks and failovers > > > > We could also implement stricter IP tables rules regarding creating > external TCP connections. > Yes that would help on MitM attacks but not much on the DNS side. Since we are looking for redundancy, could we draw a picture of what it should look like in the end? Need it to see what we have and how we are improving things in the future and what other ideas might be useful. Hope this makes sense.. on painkillers. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at fedoraproject.org Wed Dec 19 23:39:47 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 18:39:47 -0500 Subject: Search domains in our environment (Proposal) In-Reply-To: <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> Message-ID: <1198107587.6888.3.camel@cutter> On Wed, 2007-12-19 at 16:33 -0700, Stephen John Smoogen wrote: > On Dec 19, 2007 4:15 PM, Mike McGrath wrote: > > Stephen John Smoogen wrote: > > > On Dec 19, 2007 4:06 PM, Mike McGrath wrote: > > > > > >> Mike McGrath wrote: > > >> > > >>> Comments? +1's? -1's? I'm basically going for ease of use among the > > >>> admins and since most people "ssh puppet1" instead of "ssh > > >>> puppet1.fedora.phx.redhat.com" I think in our diverse environment it > > >>> will be worth it and is easier then hosting a separate DNS server in > > >>> each of our locations. > > >>> > > >> I forgot to mention one other concern. A MitM attack or DNS poisoning. > > >> This possibility does exist, but exists in our environment as is > > >> anyway. This is something we should look at mitigating but other than > > >> running a DNS server at every site, I'm not totally sure how to fix it. > > >> I consider all of our donations as partnerships. After all, they have > > >> local access to the box. At the same time though it is something we > > >> should count as a risk and mitigate as much as possible. > > >> > > >> > > > > > > As far as I can tell the only way to lower the risk of DNS poisoning > > > is local DNS servers. Having them getting DNS files from a central > > > host via a signed methodology would be not much different than > > > /etc/hosts except you can use other tricks and failovers > > > > > > > We could also implement stricter IP tables rules regarding creating > > external TCP connections. > > > > Yes that would help on MitM attacks but not much on the DNS side. > Since we are looking for redundancy, could we draw a picture of what > it should look like in the end? Need it to see what we have and how we > are improving things in the future and what other ideas might be > useful. > The reason for all of this is the firewall in place at the PHX colo. If that wasn't there we wouldn't need any of the games at all. We could just have foo.fedoraproject.org be resolveable from anywhere and foo.vpn.fedoraproject.org just mean 'go over the vpn to get to it'. seth 'big fan of simple networking' vidal -sv From admin at arcnetworks.biz Wed Dec 19 23:54:58 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 19 Dec 2007 18:54:58 -0500 Subject: Search domains in our environment (Proposal) In-Reply-To: <1198107587.6888.3.camel@cutter> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> <1198107587.6888.3.camel@cutter> Message-ID: <5d66540b0712191554x5f88b6c8p4edad5ddd8ee04f2@mail.gmail.com> > The reason for all of this is the firewall in place at the PHX colo. If > that wasn't there we wouldn't need any of the games at all. We could > just have foo.fedoraproject.org be resolveable from anywhere and > foo.vpn.fedoraproject.org just mean 'go over the vpn to get to it'. > > seth 'big fan of simple networking' vidal > -sv +1, but do we still need the firewall for other things? -Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Wed Dec 19 23:57:51 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 18:57:51 -0500 Subject: Search domains in our environment (Proposal) In-Reply-To: <5d66540b0712191554x5f88b6c8p4edad5ddd8ee04f2@mail.gmail.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> <1198107587.6888.3.camel@cutter> <5d66540b0712191554x5f88b6c8p4edad5ddd8ee04f2@mail.gmail.com> Message-ID: <1198108671.6888.5.camel@cutter> On Wed, 2007-12-19 at 18:54 -0500, Anand Capur wrote: > > The reason for all of this is the firewall in place at the PHX > colo. If > that wasn't there we wouldn't need any of the games at all. We > could > just have foo.fedoraproject.org be resolveable from anywhere > and > foo.vpn.fedoraproject.org just mean 'go over the vpn to get to > it'. > > seth 'big fan of simple networking' vidal > -sv > > +1, but do we still need the firewall for other things? So the firewall is something that came with the space. It's red hat's firewall and I don't think we have any choice for the hosts inside phx. In general, I'm a much bigger fan of hosts-based firewalling and clamping down on exposure paths that way than an edge firewall for a network. In this case it would also make our setup a good bit simpler if we didn't have the edge firewall at all. -sv From mmcgrath at redhat.com Thu Dec 20 01:24:09 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 19 Dec 2007 19:24:09 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <1198108671.6888.5.camel@cutter> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> <1198107587.6888.3.camel@cutter> <5d66540b0712191554x5f88b6c8p4edad5ddd8ee04f2@mail.gmail.com> <1198108671.6888.5.camel@cutter> Message-ID: <4769C439.3050901@redhat.com> seth vidal wrote: > On Wed, 2007-12-19 at 18:54 -0500, Anand Capur wrote: > >> The reason for all of this is the firewall in place at the PHX >> colo. If >> that wasn't there we wouldn't need any of the games at all. We >> could >> just have foo.fedoraproject.org be resolveable from anywhere >> and >> foo.vpn.fedoraproject.org just mean 'go over the vpn to get to >> it'. >> >> seth 'big fan of simple networking' vidal >> -sv >> >> +1, but do we still need the firewall for other things? >> > > So the firewall is something that came with the space. It's red hat's > firewall and I don't think we have any choice for the hosts inside phx. > > In general, I'm a much bigger fan of hosts-based firewalling and > clamping down on exposure paths that way than an edge firewall for a > network. In this case it would also make our setup a good bit simpler if > we didn't have the edge firewall at all. > Just so my stance on this is also public. In general I also agree that it is good to remove the PHX firewall from the mix. The biggest being IP space. (think about the builders and such). There's also a firewall there that we could re-implement ourselves. While long term I do want to re-think our interactions with PHX but I can't say for sure exactly what that will be. If, for example, we got funding to host all non-buildsystem stuff in our new German colo, many of these problems might go away. I'd very much like to research the alternatives but for now I think the search domain method would suit us well. -Mike From skvidal at fedoraproject.org Thu Dec 20 01:49:24 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 19 Dec 2007 20:49:24 -0500 Subject: Search domains in our environment (Proposal) In-Reply-To: <4769C439.3050901@redhat.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> <1198107587.6888.3.camel@cutter> <5d66540b0712191554x5f88b6c8p4edad5ddd8ee04f2@mail.gmail.com> <1198108671.6888.5.camel@cutter> <4769C439.3050901@redhat.com> Message-ID: <1198115364.6888.7.camel@cutter> On Wed, 2007-12-19 at 19:24 -0600, Mike McGrath wrote: > seth vidal wrote: > > On Wed, 2007-12-19 at 18:54 -0500, Anand Capur wrote: > > > >> The reason for all of this is the firewall in place at the PHX > >> colo. If > >> that wasn't there we wouldn't need any of the games at all. We > >> could > >> just have foo.fedoraproject.org be resolveable from anywhere > >> and > >> foo.vpn.fedoraproject.org just mean 'go over the vpn to get to > >> it'. > >> > >> seth 'big fan of simple networking' vidal > >> -sv > >> > >> +1, but do we still need the firewall for other things? > >> > > > > So the firewall is something that came with the space. It's red hat's > > firewall and I don't think we have any choice for the hosts inside phx. > > > > In general, I'm a much bigger fan of hosts-based firewalling and > > clamping down on exposure paths that way than an edge firewall for a > > network. In this case it would also make our setup a good bit simpler if > > we didn't have the edge firewall at all. > > > > Just so my stance on this is also public. In general I also agree that > it is good to remove the PHX firewall from the mix. The biggest being > IP space. (think about the builders and such). There's also a firewall > there that we could re-implement ourselves. While long term I do want > to re-think our interactions with PHX but I can't say for sure exactly > what that will be. If, for example, we got funding to host all > non-buildsystem stuff in our new German colo, many of these problems > might go away. > > I'd very much like to research the alternatives but for now I think the > search domain method would suit us well. > option 2: all hosts we maintain are written in /etc/hosts or hosts.db or something comparable specific to the site. that would keep mitm down to a minimum, too, but it means keeping that file current. -sv From mmcgrath at redhat.com Thu Dec 20 01:50:43 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 19 Dec 2007 19:50:43 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <1198115364.6888.7.camel@cutter> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <80d7e4090712191519i1525f4f6u593e9e80b5081971@mail.gmail.com> <4769A5F4.2010401@redhat.com> <80d7e4090712191533p724c002en184d771b3134554a@mail.gmail.com> <1198107587.6888.3.camel@cutter> <5d66540b0712191554x5f88b6c8p4edad5ddd8ee04f2@mail.gmail.com> <1198108671.6888.5.camel@cutter> <4769C439.3050901@redhat.com> <1198115364.6888.7.camel@cutter> Message-ID: <4769CA73.8080101@redhat.com> seth vidal wrote: > On Wed, 2007-12-19 at 19:24 -0600, Mike McGrath wrote: > >> seth vidal wrote: >> >>> On Wed, 2007-12-19 at 18:54 -0500, Anand Capur wrote: >>> >>> >>>> The reason for all of this is the firewall in place at the PHX >>>> colo. If >>>> that wasn't there we wouldn't need any of the games at all. We >>>> could >>>> just have foo.fedoraproject.org be resolveable from anywhere >>>> and >>>> foo.vpn.fedoraproject.org just mean 'go over the vpn to get to >>>> it'. >>>> >>>> seth 'big fan of simple networking' vidal >>>> -sv >>>> >>>> +1, but do we still need the firewall for other things? >>>> >>>> >>> So the firewall is something that came with the space. It's red hat's >>> firewall and I don't think we have any choice for the hosts inside phx. >>> >>> In general, I'm a much bigger fan of hosts-based firewalling and >>> clamping down on exposure paths that way than an edge firewall for a >>> network. In this case it would also make our setup a good bit simpler if >>> we didn't have the edge firewall at all. >>> >>> >> Just so my stance on this is also public. In general I also agree that >> it is good to remove the PHX firewall from the mix. The biggest being >> IP space. (think about the builders and such). There's also a firewall >> there that we could re-implement ourselves. While long term I do want >> to re-think our interactions with PHX but I can't say for sure exactly >> what that will be. If, for example, we got funding to host all >> non-buildsystem stuff in our new German colo, many of these problems >> might go away. >> >> I'd very much like to research the alternatives but for now I think the >> search domain method would suit us well. >> >> > > option 2: > > all hosts we maintain are written in /etc/hosts or hosts.db or > something comparable specific to the site. > > that would keep mitm down to a minimum, too, but it means keeping that > file current. > > Does search in resolv.conf work with multiple /etc/hosts entries. If so we could do that though, like DNS, we'd need to maintain multiple hostnames / ip's. If that doesn't work then we'd have to maintain multiple /etc/hosts files. -Mike From jeff at ocjtech.us Thu Dec 20 14:12:02 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 20 Dec 2007 08:12:02 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <4769A403.6080404@redhat.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> Message-ID: <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> On 12/19/07, Mike McGrath wrote: > > I forgot to mention one other concern. A MitM attack or DNS poisoning. > This possibility does exist, but exists in our environment as is > anyway. This is something we should look at mitigating but other than > running a DNS server at every site, I'm not totally sure how to fix it. > I consider all of our donations as partnerships. After all, they have > local access to the box. At the same time though it is something we > should count as a risk and mitigate as much as possible. I believe that DNSSEC is supposed to be the solution to the MitM/DNS poisoning problem. It's been a while since I messed with it, but with DNSSEC your DNS entries get signed with a public key and then properly configured systems will check the signatures on all lookups involving fedora*.org. Having this as a part of the standard setup in Fedora's BIND package would be awesomely cool because then every Fedora machine would be protected against someone spoofing their DNS and possibly causing problems. I've been meaning to set this up for my personal domain so I could work on the details over the holiday break... Jeff From mmcgrath at redhat.com Thu Dec 20 14:41:08 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 08:41:08 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> Message-ID: <476A7F04.4050301@redhat.com> Jeffrey Ollie wrote: > On 12/19/07, Mike McGrath wrote: > >> I forgot to mention one other concern. A MitM attack or DNS poisoning. >> This possibility does exist, but exists in our environment as is >> anyway. This is something we should look at mitigating but other than >> running a DNS server at every site, I'm not totally sure how to fix it. >> I consider all of our donations as partnerships. After all, they have >> local access to the box. At the same time though it is something we >> should count as a risk and mitigate as much as possible. >> > > I believe that DNSSEC is supposed to be the solution to the MitM/DNS > poisoning problem. It's been a while since I messed with it, but with > DNSSEC your DNS entries get signed with a public key and then properly > configured systems will check the signatures on all lookups involving > fedora*.org. Having this as a part of the standard setup in Fedora's > BIND package would be awesomely cool because then every Fedora machine > would be protected against someone spoofing their DNS and possibly > causing problems. > > I've been meaning to set this up for my personal domain so I could > work on the details over the holiday break... > If you find a solution that might work for us while you're setting it up let us know, its certainly an avenue worth looking at. -Mike From mmcgrath at redhat.com Thu Dec 20 16:40:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 10:40:39 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> Message-ID: <476A9B07.4090401@redhat.com> Jeffrey Ollie wrote: > On 12/19/07, Mike McGrath wrote: > >> I forgot to mention one other concern. A MitM attack or DNS poisoning. >> This possibility does exist, but exists in our environment as is >> anyway. This is something we should look at mitigating but other than >> running a DNS server at every site, I'm not totally sure how to fix it. >> I consider all of our donations as partnerships. After all, they have >> local access to the box. At the same time though it is something we >> should count as a risk and mitigate as much as possible. >> > > I believe that DNSSEC is supposed to be the solution to the MitM/DNS > poisoning problem. It's been a while since I messed with it, but with > DNSSEC your DNS entries get signed with a public key and then properly > configured systems will check the signatures on all lookups involving > fedora*.org. Having this as a part of the standard setup in Fedora's > BIND package would be awesomely cool because then every Fedora machine > would be protected against someone spoofing their DNS and possibly > causing problems. > > I've been meaning to set this up for my personal domain so I could > work on the details over the holiday break... > Also it appears that Paul Wounters is giving a session at FUDCon called "Integrating DNSSEC -- Proposal and demonstration of DNSSEC aware software. -Mike From jeff at ocjtech.us Thu Dec 20 16:51:33 2007 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 20 Dec 2007 10:51:33 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <476A9B07.4090401@redhat.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> <476A9B07.4090401@redhat.com> Message-ID: <935ead450712200851h625de879r96e0e814f7479359@mail.gmail.com> On 12/20/07, Mike McGrath wrote: > > Also it appears that Paul Wounters is giving a session at FUDCon called > "Integrating DNSSEC -- Proposal and demonstration of DNSSEC aware > software. Heh, now if someone would just buy me a plane ticket and pay for my hotel I could afford to show up :). What's the chances of some of these sessions being webcasted live, or at least recorded? Jeff From mmcgrath at redhat.com Thu Dec 20 16:48:46 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 10:48:46 -0600 Subject: Search domains in our environment (Proposal) In-Reply-To: <935ead450712200851h625de879r96e0e814f7479359@mail.gmail.com> References: <4769A298.8070008@redhat.com> <4769A403.6080404@redhat.com> <935ead450712200612o27234f86i56ae7e11a44cc951@mail.gmail.com> <476A9B07.4090401@redhat.com> <935ead450712200851h625de879r96e0e814f7479359@mail.gmail.com> Message-ID: <476A9CEE.70405@redhat.com> Jeffrey Ollie wrote: > On 12/20/07, Mike McGrath wrote: > >> Also it appears that Paul Wounters is giving a session at FUDCon called >> "Integrating DNSSEC -- Proposal and demonstration of DNSSEC aware >> software. >> > > Heh, now if someone would just buy me a plane ticket and pay for my > hotel I could afford to show up :). What's the chances of some of > these sessions being webcasted live, or at least recorded? > Some of them actually will be, at least they were last year. I'll hit up the FAB and see if we have any official resources to commit. -Mike From ricky at fedoraproject.org Thu Dec 20 20:43:56 2007 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 20 Dec 2007 15:43:56 -0500 Subject: Meeting Log - 2007-12-20 Message-ID: <20071220204356.GC32660@Max.nyc1.dsl.speakeasy.net> 15:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Role Call! Who's here? 15:04 < ivazquez> Pong. 15:04 * bpepple sits in the peanut gallery. 15:04 * jeremy 15:04 * nirik is in the cheap seats in the back. 15:04 * skvidal is here 15:04 < frankc> * frank 15:04 * mmcgrath 15:04 * lmacken 15:04 < jcollie> yo 15:04 -!- MrBawb [i=abob at guppy.drown.org] has joined #fedora-meeting 15:05 * abadger1999 is here 15:06 < abadger1999> Hey MrBawb, just in time! 15:06 < MrBawb> hooray! 15:06 < mmcgrath> ok, lets get started. 15:07 * couf somewhat 15:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 15:08 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 15:08 < mmcgrathbot> mmcgrath: http://tinyurl.com/2hyyz6 15:08 -!- loupgaroublond [n=yankee at pool-71-182-186-246.pitbpa.east.verizon.net] has joined #fedora-meeting 15:09 < mmcgrath> .tickety 192 15:09 < mmcgrath> .ticket 192 15:09 < mmcgrathbot> mmcgrath: #192 (Netapp low on free space) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/192 15:10 < mmcgrath> So we've added some space from the netapp that we recently discovered, a tiny amount in compared what we're using. 15:11 < jcollie> so did i hear right that a new netapp is on order? 15:11 < mmcgrath> jcollie: its in the process of being ordered. 15:11 < mmcgrath> I just informed our RH people where to ship it. 15:12 < MrBawb> feel free to say no way, but what about non-netapp storage? 15:12 < mmcgrath> actually we didn't order an additional netapp this time around. 15:12 < mmcgrath> its just a disk tray from Dell with around 10T of storage. 15:12 < MrBawb> ah 15:12 < mmcgrath> and its going to be dedicated to the build system. 15:12 < mmcgrath> any other questions on that? 15:13 * mmcgrath is hoping for delivery sometime in the next 2 weeks but with christmas and such its hard to say. 15:13 < mmcgrath> ok, next ticket. 15:13 < mmcgrath> .tiny 270 15:13 < mmcgrathbot> mmcgrath: Error: '270' is not a valid url. 15:13 < mmcgrath> crap 15:13 < mmcgrath> .ticket 270 15:13 < mmcgrathbot> mmcgrath: #270 (Fedora Wiki allows editing raw HTML) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/270 15:13 < mmcgrath> ricky: ping? 15:13 < dgilmore> soory im late 15:14 < dgilmore> sorry even 15:14 * mmcgrath thinks ricky isn't around right now. 15:14 < mmcgrath> thats fine we'll move on 15:14 < mmcgrath> .ticket 283 15:14 < mmcgrathbot> mmcgrath: #283 (Vote: Support Monotone?) - Fedora Infrastructure - Trac - https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/283 15:14 < mmcgrath> So we've had the conversation on the mailing list. 15:15 < mmcgrath> Anyone have any questions with this from this last week? 15:15 < jcollie> so is roland opposed to converting to git/hg/bzr? 15:15 -!- stahnma [n=stahnma at c-76-18-178-254.hsd1.tn.comcast.net] has joined #fedora-meeting 15:15 < mmcgrath> Just a reminder is whether or not to support monotone which would also get elfutils on fedorahosted. 15:15 < mmcgrath> Which is good, but supporting all scm's under the sun is bad. 15:15 < mmcgrath> jcollie: yeah, he's opposed to everything that is not monotone. 15:16 < mmcgrath> So I'll give a 5 minute vote, +1 for, -1 against +0 not voting and -NEEDMOREINFO to prefer to wait till next week. 15:17 < dgilmore> I kinda think we should support monotone to get elfutils completely out of the closet 15:17 < mmcgrath> ============== Voteing begins now =========== 15:17 < dgilmore> +1 15:17 < jcollie> +1 15:17 -!- llaumgui [n=llaumgui at cro34-2-82-226-153-125.fbx.proxad.net] has joined #fedora-meeting 15:17 < lmacken> +1 15:17 < ivazquez> I'm not a fan of monotone but nothing jumped out at me as being a negative. +0 15:17 < abadger1999> +0 15:17 -!- CyberSpy [n=cyberspy at cpe-065-191-024-225.nc.res.rr.com] has quit Remote closed the connection 15:17 < MrBawb> +0 15:17 < stahnma> -1, why support more things.... 15:18 < skvidal> +0 15:18 < couf> +0 15:18 * mmcgrath has to admit this comes down to monotone -1 and elfutils +1. 15:19 < skvidal> mmcgrath: right 15:20 < mmcgrath> a 5 minute vote might seem kind of long. 15:21 < abadger1999> Who's going to work on integrating monotone? Roland or one of us? 15:22 < mmcgrath> 1 minute yet. 15:22 < mmcgrath> abadger1999: it'll have to be one of us unless he wants to join the team. 15:22 < mmcgrath> which I'll try to get him to do but if thats all he's going to do I fear it won't do us any good. 15:22 < mmcgrath> Either way its just knowledge. We can learn it. 15:22 < jima> oops 15:22 < mmcgrath> jima: you going to vote? 15:23 < mmcgrath> +0 can't decide. 15:23 < jima> -1 for monotone 15:23 < mmcgrath> =================== Voting Done =============== 15:23 < jima> no one's familiar with it, right? 15:23 < mmcgrath> So that makes +3-2=+1 15:23 < mmcgrath> So I'll start working out the details with Rolland. 15:23 * ricky appers. 15:24 < ricky> **appears 15:24 < mmcgrath> It could be there comes a technical hurdle or something else that we can't overcome. 15:24 < mmcgrath> But for now we'll go forward under the assumption that we're going to support monotone. 15:24 < mmcgrath> ricky: yo 15:24 * ivazquez will as well 15:25 < mmcgrath> allrighty 15:25 < mmcgrath> next topic 15:25 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Fedora Schedule 15:25 < mmcgrath> http://fedoraproject.org/wiki/Infrastructure/Schedule 15:26 < mmcgrath> So not much going on on the sponsorship side. We're still waiting on peer1 for their logo and info. 15:26 * MrBawb -> afk 15:26 * mmcgrath did add this to the wiki 15:26 < mmcgrath> .tiny http://fedoraproject.org/wiki/Infrastructure/Architecture?action=AttachFile&do=view&target=GlobalNetwork.png 15:26 < mmcgrathbot> mmcgrath: http://tinyurl.com/2elthq 15:27 < mmcgrath> I'll be updating that documentation in coming weeks. 15:27 < mmcgrath> Before FUDCon. 15:27 < mmcgrath> Nothing new on the SOP front. 15:28 < dgilmore> mmcgrath: kickstart and puppet SOP's worked well 15:28 < mmcgrath> ahhh yes /me forgot dgilmore got to test those this week. 15:28 < mmcgrath> On the sponsorship front we've also got J5 working with us to do some development work. he's now on the sysadmin-test group. 15:28 < dgilmore> only minnor issues and part of that is probably that i prefer to use the cycaleds and serial console 15:29 < mmcgrath> 15:29 < mmcgrath> Alrighty. So thats all I've got 15:29 < mmcgrath> dgilmore: can you give us a quick overview of what we did with the builders this last week? 15:29 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Builder upgrades. 15:29 < dgilmore> mmcgrath: sure 15:30 < dgilmore> so to start with I built a new hub 15:30 < dgilmore> its a xen guest on Xen1 15:30 < dgilmore> when we switched over i shut the builders down 15:30 < dgilmore> brough the new hub up and got it in place 15:31 < dgilmore> then one by one did a reinstall on the builders 15:31 < dgilmore> we made a slight change in the way the builders are put together 15:31 < dgilmore> we made /var/lib/mock a raid0 with ext2 on it 15:31 < dgilmore> it should give a small speed improvement in builds 15:32 < dgilmore> and if a drive dies we dont care that we lost the file system 15:32 < dgilmore> ppc4 had some quirks 15:32 < dgilmore> i had to change the drive it boos off in the SP 15:32 < dgilmore> hammer2 is still the only physical x86_64 host 15:33 < dgilmore> the rest of the x86_64 boxes are xen guests 15:33 < mmcgrath> solid 15:33 < dgilmore> so thats the run down 15:33 < dgilmore> any questions 15:33 < mmcgrath> all in all it seems like things are back in good order right? 15:33 < dgilmore> yes 15:33 < dgilmore> all done 15:33 * mmcgrath wishes ppc1 would get back in to order. 15:33 < jcollie> yeah builds are back to a decent speed 15:33 < dgilmore> we now are using mock 0.9.x 15:33 < ivazquez> Should we perhaps get another x86_64 box? Or are we fine with what we have? 15:34 * dgilmore too stupid ibm 15:34 < dgilmore> we have 4 x86_64 15:34 < dgilmore> we could always use more 15:34 < dgilmore> ivazquez: we do have replacement hardware just need power for it 15:34 < mmcgrath> We have a whole blade center sitting on the floor somewhere waiting to get installed. 15:34 < ivazquez> I can't help but think of what would happen if it goes down hard (knock on wood). 15:34 < mmcgrath> the earliest I've heard is january. 15:35 * skvidal holds his breath 15:35 * skvidal passes out from holding his breath 15:35 < mmcgrath> heh 15:35 < mmcgrath> dgilmore: have anything else on the builders? 15:35 * mmcgrath notes dgilmore is sitting just 10 feet from him. 15:36 < mmcgrath> he says no :) 15:36 < mmcgrath> ok 15:36 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:36 < mmcgrath> Anyone have anything else they want to discuss? 15:36 < skvidal> mmcgrath: can you reach out and hit dgilmore from there? 15:36 < mmcgrath> skvidal: not quite. 15:36 < mmcgrath> I could hit him with an orange. 15:36 < skvidal> mmcgrath: lean over 15:36 < skvidal> oo oo 15:36 < skvidal> good 15:36 < skvidal> throw fruit 15:36 < mmcgrath> heheh 15:37 < skvidal> ook 15:37 * dgilmore slaps skvidal 15:37 < mmcgrath> Ok, if no one has anything else they'd like to discuss I'll close the meeting in 30. 15:37 < mmcgrath> 15 15:37 < abadger1999> MrBawb: Want to update us on Moin? 15:38 < dgilmore> abadger1999: he dropped off 15:38 < mmcgrath> thats a good thing to talk about 15:38 < mmcgrath> MrBawb: you still afk? 15:38 < mmcgrath> we can wait a bit and see if he appears. 15:38 < abadger1999> Oh well. 15:38 < mmcgrath> abadger1999: we'll nab him next time. 15:39 * mmcgrath creates ticket for it to make sure 15:39 < mmcgrath> ok, anyone have anything else? if not I'll close in 30. 15:39 * dgilmore hands mmcgrath toys 15:40 < mmcgrath> a10 15:40 * ricky sees collaboration server :) 15:40 < mmcgrath> ricky: its comin :) 15:40 -!- frankc [n=824c405d at gateway/web/cgi-irc/ircatwork.com/x-091c4d5bcc04fde6] has left #fedora-meeting [] 15:40 < ricky> Cool. 15:40 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Dec 21 02:20:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 20:20:16 -0600 Subject: Moin 1.6 beta. Message-ID: <476B22E0.8040307@redhat.com> Another idea, what good and bad would come from us upgrading to the 1.6 beta? -Mike From smooge at gmail.com Fri Dec 21 02:37:23 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 20 Dec 2007 19:37:23 -0700 Subject: Moin 1.6 beta. In-Reply-To: <476B22E0.8040307@redhat.com> References: <476B22E0.8040307@redhat.com> Message-ID: <80d7e4090712201837w2a0dabe6i3bf8d9e7e713f2@mail.gmail.com> On Dec 20, 2007 7:20 PM, Mike McGrath wrote: > Another idea, what good and bad would come from us upgrading to the 1.6 > beta? > Well my questions would be: What are we trying to accomplish? Who is on base to accomplish this? I am not sure that this would be the best 'python' learning experience but since I just made our PFY do moin as his first project.. I should probably do the same. Who are the human chattel we have to throw at it? When do we need to see results of what we are trying to accomplish? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From a.badger at gmail.com Fri Dec 21 04:21:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 20 Dec 2007 20:21:34 -0800 Subject: Moin 1.6 beta. In-Reply-To: <476B22E0.8040307@redhat.com> References: <476B22E0.8040307@redhat.com> Message-ID: <476B3F4E.7060402@gmail.com> Mike McGrath wrote: > Another idea, what good and bad would come from us upgrading to the 1.6 > beta? > What features were you thinking it provides us with? Better ability to cache pages? Here's another thought: is it only page saves which are causing us problems? I think moin has a similar URL for all actions that cause writing to the disk. For instance, saving an edit appears to call PAGENAME#preview and starting an edit uses PAGENAME?action=edit. Could we cluster just requests to read from the wiki and filter writes to a single app server by using these URLs? -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 mmcgrath at redhat.com Fri Dec 21 04:24:05 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 20 Dec 2007 22:24:05 -0600 Subject: Moin 1.6 beta. In-Reply-To: <476B3F4E.7060402@gmail.com> References: <476B22E0.8040307@redhat.com> <476B3F4E.7060402@gmail.com> Message-ID: <476B3FE5.5020800@redhat.com> Toshio Kuratomi wrote: > Mike McGrath wrote: > >> Another idea, what good and bad would come from us upgrading to the 1.6 >> beta? >> >> > What features were you thinking it provides us with? Better ability to > cache pages? > That, the other thing I'm thinking of is if we're going to start patching our instance heavily, perhaps we want to stick with 1.6. I don't necessarily want to upgrade to 1.6 but I do want us to talk about it. > Here's another thought: is it only page saves which are causing us > problems? I think moin has a similar URL for all actions that cause > writing to the disk. For instance, saving an edit appears to call > PAGENAME#preview and starting an edit uses PAGENAME?action=edit. Could > we cluster just requests to read from the wiki and filter writes to a > single app server by using these URLs? > The page saves are causing our inability to cluster Moin in any efficient way. I've thought about altering proxy location by action, that would help with some things but I've yet to set it up and see if it works the way we think it will. (for example, altering the user, watched pages, etc are still a question mark in my head). -Mike From vpivaini at cs.helsinki.fi Fri Dec 21 17:41:48 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Fri, 21 Dec 2007 19:41:48 +0200 Subject: Moin 1.6 beta. In-Reply-To: <476B22E0.8040307@redhat.com> References: <476B22E0.8040307@redhat.com> Message-ID: <200712211941.48440.vpivaini@cs.helsinki.fi> Mike McGrath kirjoitti: > Another idea, what good and bad would come from us upgrading to the 1.6 > beta? Good: Xapian integration and with it, hopefully a better search? http://moinmo.in/HelpOnXapian -- Ville-Pekka Vainio From mmcgrath at redhat.com Fri Dec 21 18:57:44 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 12:57:44 -0600 Subject: Moin 1.6 beta. In-Reply-To: <200712211941.48440.vpivaini@cs.helsinki.fi> References: <476B22E0.8040307@redhat.com> <200712211941.48440.vpivaini@cs.helsinki.fi> Message-ID: <476C0CA8.8000805@redhat.com> Ville-Pekka Vainio wrote: > Mike McGrath kirjoitti: > >> Another idea, what good and bad would come from us upgrading to the 1.6 >> beta? >> > > Good: Xapian integration and with it, hopefully a better search? > http://moinmo.in/HelpOnXapian > Yeah, we can certainly do that too. I guess I started this thread because I see all the changes / patches and things that could possible be implemented into our wiki and I'm wondering if sticking with upstreams next release would help mitigate any integration issues we might have. It just feels like a lot of work is being done (good) and I want to make sure we're in the best possible spot for our future. -Mike From a.badger at gmail.com Fri Dec 21 19:25:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 21 Dec 2007 11:25:31 -0800 Subject: Moin 1.6 beta. In-Reply-To: <476B3FE5.5020800@redhat.com> References: <476B22E0.8040307@redhat.com> <476B3F4E.7060402@gmail.com> <476B3FE5.5020800@redhat.com> Message-ID: <476C132B.1090902@gmail.com> Mike McGrath wrote: > Toshio Kuratomi wrote: >> Mike McGrath wrote: >> >>> Another idea, what good and bad would come from us upgrading to the 1.6 >>> beta? >>> >>> >> What features were you thinking it provides us with? Better ability to >> cache pages? >> > > That, the other thing I'm thinking of is if we're going to start > patching our instance heavily, perhaps we want to stick with 1.6. I > don't necessarily want to upgrade to 1.6 but I do want us to talk about it. > Very good point. That would definitely be another reason to move to 1.6 so we're closer to the code base that our patches are going to apply to upstream. >> Here's another thought: is it only page saves which are causing us >> problems? I think moin has a similar URL for all actions that cause >> writing to the disk. For instance, saving an edit appears to call >> PAGENAME#preview and starting an edit uses PAGENAME?action=edit. Could >> we cluster just requests to read from the wiki and filter writes to a >> single app server by using these URLs? >> > > The page saves are causing our inability to cluster Moin in any > efficient way. I've thought about altering proxy location by action, > that would help with some things but I've yet to set it up and see if it > works the way we think it will. (for example, altering the user, > watched pages, etc are still a question mark in my head). > It looks like subscribing to a page and starting the user preferences editor via the link in the sidebar can be grabbed via the ?action= string as well. Saving of the User Preferences page looks like it doesn't use a special URL but perhaps sending all POST requests to the writable server would catch that. -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 mmcgrath at redhat.com Fri Dec 21 19:23:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 13:23:47 -0600 Subject: puppet woes Message-ID: <476C12C3.6060304@redhat.com> So we're hitting some odd things in puppet: http://reductivelabs.com/trac/puppet/ticket/952 In fairness, we're using a version of puppet in a test repo. I'm going to attempt to roll it back now. -Mike From tchung at fedoraproject.org Sat Dec 22 00:24:24 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Fri, 21 Dec 2007 16:24:24 -0800 Subject: Fwd: Fedora News site: Help Needed In-Reply-To: <476C4F41.7070307@fedoraproject.org> References: <476C4F41.7070307@fedoraproject.org> Message-ID: <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> I just been informed that new cms is ready for news project. Please let me know the detail. Regards, ---------- Forwarded message ---------- From: Rahul Sundaram Date: Dec 21, 2007 3:41 PM Subject: Fedora News site: Help Needed To: Thomas Chung Cc: fedora-news-list at redhat.com, For discussions about marketing and expanding the Fedora user base Hi, Fedora infrastructure is looking for a person to manage a new news site for Fedora which is currently planned to be a drupal instance. If anyone wants to volunteer to lead that effort or help coordinate with others, please contact the infrastructure team. Rahul From admin at arcnetworks.biz Sat Dec 22 01:54:14 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Fri, 21 Dec 2007 20:54:14 -0500 Subject: Fedora News site: Help Needed In-Reply-To: <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> References: <476C4F41.7070307@fedoraproject.org> <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> Message-ID: <5d66540b0712211754u116bd4d8sd909218609b85f87@mail.gmail.com> On 12/21/07, Thomas Chung wrote: > > I just been informed that new cms is ready for news project. > Please let me know the detail. > Regards, > > ---------- Forwarded message ---------- > From: Rahul Sundaram > Date: Dec 21, 2007 3:41 PM > Subject: Fedora News site: Help Needed > To: Thomas Chung > Cc: fedora-news-list at redhat.com, For discussions about marketing and > expanding the Fedora user base > > > Hi, > > Fedora infrastructure is looking for a person to manage a new news site > for Fedora which is currently planned to be a drupal instance. If anyone > wants to volunteer to lead that effort or help coordinate with others, > please contact the infrastructure team. > > Rahul I'd love to do this. I wanted to start a Fedora Magazine, but there was a lack of interest. -Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Sat Dec 22 03:45:29 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 21 Dec 2007 22:45:29 -0500 Subject: Fwd: Fedora News site: Help Needed In-Reply-To: <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> References: <476C4F41.7070307@fedoraproject.org> <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> Message-ID: <476C8859.7030506@redhat.com> > > Hi, > > Fedora infrastructure is looking for a person to manage a new news site > for Fedora which is currently planned to be a drupal instance. If anyone > wants to volunteer to lead that effort or help coordinate with others, > please contact the infrastructure team. > > Rahul Is this envisioned to be like a Slashdot-type news blog with comments and such? Warren From mmcgrath at redhat.com Sat Dec 22 05:17:27 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 21 Dec 2007 23:17:27 -0600 Subject: Fwd: Fedora News site: Help Needed In-Reply-To: <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> References: <476C4F41.7070307@fedoraproject.org> <369bce3b0712211624y23dfb6aehe4726fdf135a87d2@mail.gmail.com> Message-ID: <476C9DE7.3030808@redhat.com> Thomas Chung wrote: > I just been informed that new cms is ready for news project. > Please let me know the detail. > Regards, Presently there's ticket: https://fedorahosted.org/fedora-infrastructure/ticket/178 We basically need someone to own this project, have a vision and time for it. If you think thats you, lets get started. Think about your needs, what you're trying to do, etc. -Mike From jkeating at redhat.com Sat Dec 22 21:41:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 16:41:29 -0500 Subject: patch for kojid to prevent noarch build failures Message-ID: <20071222164129.6da8baa7@redhat.com> 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. -- 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 Matt_Domsch at Dell.com Sat Dec 22 22:56:17 2007 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Sat, 22 Dec 2007 16:56:17 -0600 Subject: Proposal - Official Forum References: Message-ID: I am forwarding this to the fedora-infrastructure-list which would be a better place for this discussion. How would forums benefit the Fedora community, over and above how we currently use public email lists? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: affix at ihack.co.uk on behalf of Keiran Smith Sent: Sat 12/22/2007 8:05 AM To: Fedora Account System Subject: Proposal - Official Forum I would like to propose that Fedora adopt an official forum. In the forum users can exchange tips and tricks for the operating system Users will also be able to ask for help from the community thus making it alot easier for users to obtain help with fedora. As for the moderation Im sure some of the fedora Marketing, Ambassadors, web Teams would be happy to help as moderators. I am unsure if this has been proposed before. I am sorry if it has. Thanks, Keiran Smith From jkeating at redhat.com Sat Dec 22 23:16:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 18:16:09 -0500 Subject: Proposal - Official Forum In-Reply-To: References: Message-ID: <20071222181609.0270b802@redhat.com> On Sat, 22 Dec 2007 16:56:17 -0600 wrote: > How would forums benefit the Fedora community, over and above how we > currently use public email lists? We already have fedoraforum.org, why would we duplicate that? -- 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 jkeating at redhat.com Sat Dec 22 23:41:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 22 Dec 2007 18:41:40 -0500 Subject: patch for kojid to prevent noarch build failures In-Reply-To: <20071222164129.6da8baa7@redhat.com> References: <20071222164129.6da8baa7@redhat.com> Message-ID: <20071222184140.315faba9@redhat.com> On Sat, 22 Dec 2007 16:41:29 -0500 Jesse Keating wrote: > I'm going to patch the builders manually. This has been completed. -- 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 Sun Dec 23 14:05:32 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 23 Dec 2007 08:05:32 -0600 Subject: puppet woes In-Reply-To: <476C12C3.6060304@redhat.com> References: <476C12C3.6060304@redhat.com> Message-ID: <476E6B2C.9000305@redhat.com> Mike McGrath wrote: > So we're hitting some odd things in puppet: > > http://reductivelabs.com/trac/puppet/ticket/952 > > In fairness, we're using a version of puppet in a test repo. I'm > going to attempt to roll it back now. A new version is out 0.24.1 for us to install. I've pushed it to epel-testing and will update the servers when it hits the public mirror in a couple hours. Side note to this, xen1 had some strange issues in the last couple of days. yesterday a bunch of the guests died and this morning it died all together, lets keep an eye on it. -Mike From mmcgrath at redhat.com Mon Dec 24 05:54:11 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 23 Dec 2007 23:54:11 -0600 (CST) Subject: puppet woes In-Reply-To: <476E6B2C.9000305@redhat.com> References: <476C12C3.6060304@redhat.com> <476E6B2C.9000305@redhat.com> Message-ID: On Sun, 23 Dec 2007, Mike McGrath wrote: > Mike McGrath wrote: > > So we're hitting some odd things in puppet: > > > > http://reductivelabs.com/trac/puppet/ticket/952 > > > > In fairness, we're using a version of puppet in a test repo. I'm going to > > attempt to roll it back now. > > A new version is out 0.24.1 for us to install. I've pushed it to epel-testing > and will update the servers when it hits the public mirror in a couple hours. > Side note to this, xen1 had some strange issues in the last couple of days. > yesterday a bunch of the guests died and this morning it died all together, > lets keep an eye on it. > This seems to have fixed our crashing problems. we'll need to check each node is working properly from any changes we've made in the last week or so. -Mike From vpivaini at cs.helsinki.fi Tue Dec 25 21:45:10 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 25 Dec 2007 23:45:10 +0200 Subject: Moin 1.6 beta. In-Reply-To: <476B22E0.8040307@redhat.com> References: <476B22E0.8040307@redhat.com> Message-ID: <200712252345.10897.vpivaini@cs.helsinki.fi> Hi all, Just a reminder, that Moin 1.6.0 is released: http://moinmo.in/MoinMoinRelease1.6 Apparently 1.6 also has discussion pages, I've never tested those, but it seems this is something people have been missing. -- Ville-Pekka Vainio From mmcgrath at redhat.com Wed Dec 26 04:28:51 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 25 Dec 2007 22:28:51 -0600 (CST) Subject: Moin 1.6 beta. In-Reply-To: <200712252345.10897.vpivaini@cs.helsinki.fi> References: <476B22E0.8040307@redhat.com> <200712252345.10897.vpivaini@cs.helsinki.fi> Message-ID: On Tue, 25 Dec 2007, Ville-Pekka Vainio wrote: > Hi all, > > Just a reminder, that Moin 1.6.0 is released: > http://moinmo.in/MoinMoinRelease1.6 > > Apparently 1.6 also has discussion pages, I've never tested those, but it > seems this is something people have been missing. Interesting. We'll have to work with the Moin maintainer and see if we can get this up and going "as is". Those of you working on Moin, how much will this mess up what you're working on, is anyone against upgrading to 1.6? Is anyone particularly for it? -Mike From a.badger at gmail.com Wed Dec 26 05:41:03 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 25 Dec 2007 21:41:03 -0800 Subject: Moin 1.6 beta. In-Reply-To: References: <476B22E0.8040307@redhat.com> <200712252345.10897.vpivaini@cs.helsinki.fi> Message-ID: <4771E96F.4090904@gmail.com> Mike McGrath wrote: > > On Tue, 25 Dec 2007, Ville-Pekka Vainio wrote: > >> Hi all, >> >> Just a reminder, that Moin 1.6.0 is released: >> http://moinmo.in/MoinMoinRelease1.6 >> >> Apparently 1.6 also has discussion pages, I've never tested those, but it >> seems this is something people have been missing. > > Interesting. We'll have to work with the Moin maintainer and see if we > can get this up and going "as is". > > Those of you working on Moin, how much will this mess up what you're > working on, is anyone against upgrading to 1.6? Is anyone particularly > for it? > I'm for it. I handed off my patch to MrBawb but we knew we'd have to maintain a version of the patch against 1.5.x for our use and one against upstream's development branch. Having our patch apply to something more recent can only help that situation. MrBawb, do you concur? -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 admin at arcnetworks.biz Wed Dec 26 19:35:29 2007 From: admin at arcnetworks.biz (Anand Capur) Date: Wed, 26 Dec 2007 14:35:29 -0500 Subject: Hmm... -- ** PROBLEM alert - app5.vpn.fedoraproject.org/Puppet is CRITICAL ** Message-ID: <5d66540b0712261135y257b302enefc7d52aa9bf5b6f@mail.gmail.com> I've noticed a pattern on this. Date/Time: Wed Dec 26 12:33:24 MST 2007 Date/Time: Wed Dec 26 06:33:24 MST 2007 Date/Time: Wed Dec 26 00:33:24 MST 2007 Date/Time: Tue Dec 25 18:33:24 MST 2007 Date/Time: Tue Dec 25 12:23:27 MST 2007 Anyone else see it/know why it's like that? -Anand ---------- Forwarded message ---------- From: Nagios Monitoring User Date: Dec 26, 2007 2:33 PM Subject: ** PROBLEM alert - app5.vpn.fedoraproject.org/Puppet is CRITICAL ** To: sysadmin-members at fedoraproject.org ***** Nagios ***** Notification Type: PROBLEM Service: Puppet Host: app5.vpn.fedoraproject.org Address: app5.vpn.fedoraproject.org State: CRITICAL Date/Time: Wed Dec 26 12:33:24 MST 2007 Additional Info: PROCS CRITICAL: 0 processes with args /usr/bin/ruby /usr/sbin/puppetd, UID = 0 (root) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricky at fedoraproject.org Wed Dec 26 19:45:25 2007 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 26 Dec 2007 14:45:25 -0500 Subject: Hmm... -- ** PROBLEM alert - app5.vpn.fedoraproject.org/Puppet is CRITICAL ** In-Reply-To: <5d66540b0712261135y257b302enefc7d52aa9bf5b6f@mail.gmail.com> References: <5d66540b0712261135y257b302enefc7d52aa9bf5b6f@mail.gmail.com> Message-ID: <20071226194525.GB27098@Max.nyc1.dsl.speakeasy.net> On 2007-12-26 02:35:29 PM, Anand Capur wrote: > I've noticed a pattern on this. > Date/Time: Wed Dec 26 12:33:24 MST 2007 > Date/Time: Wed Dec 26 06:33:24 MST 2007 > Date/Time: Wed Dec 26 00:33:24 MST 2007 > Date/Time: Tue Dec 25 18:33:24 MST 2007 > Date/Time: Tue Dec 25 12:23:27 MST 2007 > Anyone else see it/know why it's like that? I'm guessing that it's when the nagios runs/email notifications are scheduled. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dan-fedora-i at drown.org Thu Dec 27 01:33:57 2007 From: dan-fedora-i at drown.org (Daniel Drown) Date: Wed, 26 Dec 2007 20:33:57 -0500 Subject: Moin 1.6 beta. In-Reply-To: <4771E96F.4090904@gmail.com> References: <476B22E0.8040307@redhat.com> <200712252345.10897.vpivaini@cs.helsinki.fi> <4771E96F.4090904@gmail.com> Message-ID: <20071227013357.GA32358@vps.drown.org> On Tue, 25 Dec 2007, Toshio Kuratomi wrote: > I'm for it. > > I handed off my patch to MrBawb but we knew we'd have to maintain a > version of the patch against 1.5.x for our use and one against > upstream's development branch. Having our patch apply to something more > recent can only help that situation. MrBawb, do you concur? Yeah, I expect that the Moin developers will want to only apply the patch to their development tree. They were supposed to look over the code and get back to me about that, but I haven't heard from them. I'll ping them again. From ricky at fedoraproject.org Thu Dec 27 20:13:28 2007 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 27 Dec 2007 15:13:28 -0500 Subject: Meeting Log - 2007-12-27 Message-ID: <20071227201328.GC27098@Max.nyc1.dsl.speakeasy.net> Happy holidays, everybody! 15:07:28 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here 15:07:34 * mmcgrath is assuming this meeting will not really happen :) 15:07:38 -!- jmtaylor [n=jason at c-76-112-119-170.hsd1.mi.comcast.net] has joined #fedora-meeting 15:07:45 * ricky is somewhat here. 15:08:15 * nirik is wandering around in the peanut gallery. 15:08:51 < mmcgrath> The only thing I had worth talking about was the Moin 1.6 upgrade, and much of thats been on the list already. 15:08:56 < mmcgrath> perhaps we should take it up next week. 15:09:18 < ricky> Sounds good to me :) 15:09:48 < mmcgrath> then in grand tradition 15:09:53 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:10:03 < mmcgrath> anyone have anything they want to discuss on this very short meeting? 15:10:27 < mmcgrath> alllrighty 15:10:36 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed! 15:10:39 < mmcgrath> that was amazing. 15:10:44 * ricky sends the meeting log :) 15:10:46 < mmcgrath> 3 minute meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Fri Dec 28 20:21:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 28 Dec 2007 12:21:10 -0800 Subject: Vacationing Dec 29 - Jan 2 Message-ID: <47755AB6.4080802@gmail.com> Just a note that I'll be traveling this holiday weekend Saturday Dec-29 -> Wed Jan 2. If you need to get in touch with me I'll be feeding my computer addiction about once a day but not necessarily at regular hours. -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 Roberto.Quagliozzi at edftrading.com Fri Dec 28 23:05:23 2007 From: Roberto.Quagliozzi at edftrading.com (Roberto.Quagliozzi at edftrading.com) Date: Fri, 28 Dec 2007 23:05:23 +0000 Subject: I'm not here! Message-ID: I will be out of the office starting 28/12/2007 and will not return until 02/01/2008. If you have an urgent query please call the helpdesk on x4999. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From ivazqueznet at gmail.com Fri Dec 28 23:32:34 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 28 Dec 2007 18:32:34 -0500 Subject: I'm not here! In-Reply-To: References: Message-ID: <1198884754.27210.1.camel@ignacio.lan> On Fri, 2007-12-28 at 23:05 +0000, Roberto.Quagliozzi at edftrading.com wrote: > I will be out of the office starting 28/12/2007 and will not return until > 02/01/2008. > > If you have an urgent query please call the helpdesk on x4999. An extension hardly helps if we don't have the main phone number, now does it... -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed