From Matt_Domsch at dell.com Tue Jan 2 04:20:13 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 1 Jan 2007 22:20:13 -0600 Subject: Mirrormanager thoughts Message-ID: <20070102042013.GA16518@lists.us.dell.com> Just a quick status on where we're at with the mirror manager system. Farshad, Mike, Luke, and I have all spent some time thinking about this. Luke started, and I've added to, a page of what we'd like to see in a mirror management system. See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement. Please review this and update/change as you like. Farshad has made a good start implementing parts of this in TurboGears. I've asked for a Trac project into which his source code can be put so we can collaborate on it. I want to make sure we get the schema right for what we need to accomplish before we spend too much time coding. Before we unleash it to we'll need to tie this into the Fedora Account System for user authentication, but that can be tackled in parallel to the rest of the system development. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From mmcgrath at fedoraproject.org Tue Jan 2 14:34:24 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 2 Jan 2007 08:34:24 -0600 Subject: Mirrormanager thoughts In-Reply-To: <20070102042013.GA16518@lists.us.dell.com> References: <20070102042013.GA16518@lists.us.dell.com> Message-ID: <3237e4410701020634oe3bd2d1g6cfb6618d0ee7cda@mail.gmail.com> On 1/1/07, Matt Domsch wrote: > Before we unleash it to we'll need to tie this into the Fedora Account System > for user authentication, but that can be tackled in parallel to the > rest of the system development. There were some discussions that this should not tie into the Fedora Account System though I can't remember what arguments there were for or against, anyone remember? -Mike From skvidal at linux.duke.edu Tue Jan 2 14:42:53 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 02 Jan 2007 09:42:53 -0500 Subject: Mirrormanager thoughts In-Reply-To: <3237e4410701020634oe3bd2d1g6cfb6618d0ee7cda@mail.gmail.com> References: <20070102042013.GA16518@lists.us.dell.com> <3237e4410701020634oe3bd2d1g6cfb6618d0ee7cda@mail.gmail.com> Message-ID: <1167748973.32218.21.camel@cutter> On Tue, 2007-01-02 at 08:34 -0600, Mike McGrath wrote: > On 1/1/07, Matt Domsch wrote: > > Before we unleash it to we'll need to tie this into the Fedora Account System > > for user authentication, but that can be tackled in parallel to the > > rest of the system development. > > There were some discussions that this should not tie into the Fedora > Account System though I can't remember what arguments there were for > or against, anyone remember? mirror admins don't need to sign a CLA or anything else to be mirror admins. And a fair number of them may resent it. -sv From jeff at ocjtech.us Tue Jan 2 15:00:42 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 02 Jan 2007 09:00:42 -0600 Subject: Mirrormanager thoughts In-Reply-To: <1167748973.32218.21.camel@cutter> References: <20070102042013.GA16518@lists.us.dell.com> <3237e4410701020634oe3bd2d1g6cfb6618d0ee7cda@mail.gmail.com> <1167748973.32218.21.camel@cutter> Message-ID: <1167750042.3922.8.camel@lt21223.campus.dmacc.edu> On Tue, 2007-01-02 at 09:42 -0500, seth vidal wrote: > On Tue, 2007-01-02 at 08:34 -0600, Mike McGrath wrote: > > On 1/1/07, Matt Domsch wrote: > > > Before we unleash it to we'll need to tie this into the Fedora Account System > > > for user authentication, but that can be tackled in parallel to the > > > rest of the system development. > > > > There were some discussions that this should not tie into the Fedora > > Account System though I can't remember what arguments there were for > > or against, anyone remember? > > mirror admins don't need to sign a CLA or anything else to be mirror > admins. And a fair number of them may resent it. Does signing the CLA need to be a prerequisite for getting an account in the Fedora Account System? In addition to mirror admins, that would be useful for the hosted projects site. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jan 2 15:15:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 2 Jan 2007 10:15:19 -0500 Subject: Mirrormanager thoughts In-Reply-To: <1167750042.3922.8.camel@lt21223.campus.dmacc.edu> References: <20070102042013.GA16518@lists.us.dell.com> <1167748973.32218.21.camel@cutter> <1167750042.3922.8.camel@lt21223.campus.dmacc.edu> Message-ID: <200701021015.22797.jkeating@redhat.com> On Tuesday 02 January 2007 10:00, Jeffrey C. Ollie wrote: > Does signing the CLA need to be a prerequisite for getting an account in > the Fedora Account System? ?In addition to mirror admins, that would be > useful for the hosted projects site. CLA is not a required part of a Fedora Account. It's required for things like package CVS access, EditGroup, and various other things. It could be made not mandatory for mirror admins. I'd like to keep it mandatory or something similar to the CLA for hosted projects, to CYA should the project admin do something stupid. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Tue Jan 2 19:00:26 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 2 Jan 2007 13:00:26 -0600 Subject: Mirrormanager thoughts In-Reply-To: <20070102042013.GA16518@lists.us.dell.com> References: <20070102042013.GA16518@lists.us.dell.com> Message-ID: <20070102190026.GA6999@lists.us.dell.com> On Mon, Jan 01, 2007 at 10:20:13PM -0600, Matt Domsch wrote: > Just a quick status on where we're at with the mirror manager system. > Farshad, Mike, Luke, and I have all spent some time thinking about > this. > > Farshad has made a good start implementing parts of this in > TurboGears. I've asked for a Trac project into which his source code > can be put so we can collaborate on it. With thanks to Mike and Jesse, https://hosted.fedoraproject.org/projects/mirrormanager/wiki/WikiStart now has a git repository with Farshad's code in it. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From icon at fedoraproject.org Tue Jan 2 21:19:42 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 2 Jan 2007 16:19:42 -0500 Subject: Config stuff and glump (as my introduction) Message-ID: Hello, all: I've been recently invited to join this list, seeing as I'm the original author of Glump (currently maintained by Seth), and also because I'm currently in a similar situation trying to figure out what to use for system config management here at McGill (I was recently made sysadmin again after being a PHP monkey for over a year). Now, I've not touched glump since mid-2005, and it's changed a bit since then. I do hate cfengine (probably party due to the way it's set up here), and I do not consider puppet to be a good alternative, mostly because it's "yet another config language" and because it's written in ruby. To use puppet, I'd have to learn "yet another config language" and ruby, which is prohibitively time-consuming. I've not yet had time to investigate bcfg2, but I will in the near future. However, I'm wondering if I could use and extend glump to do all I need -- will probably be the simplest. :) I'm currently wondering how much pain it would be to write a trac plugin that would do the same thing glump currently does. That should give me an infrastructure with an extensive access to SVN and db for versioning purposes, and built-in documentation/ticketing system. Since trac provides POST-handing, I could also do stuff like edit config files on the system to the point where they are working, and then "bless" them to be uploaded, committed to svn, and be immediately available to all members of that system group (unless that file is managed by a glump-like system). Now, this is pure vapourware. :) The only reason I'm interested in implementing this is because we already use trac extensively, and because writing plugins for it is pretty simple. I will probably start out with just writing a glump plugin that will use the svn repository to hold glump configs and sources, and then go on from there. If you guys are interested in glump, would you also be interested in a "trac-ified" glump? I plan to start working on this as soon as next week. Cheers and happy new year, -- Konstantin Ryabitsev Montr?al, Qu?bec From dlutter at redhat.com Wed Jan 3 01:21:48 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 02 Jan 2007 17:21:48 -0800 Subject: Config stuff and glump (as my introduction) In-Reply-To: References: Message-ID: <1167787308.2907.19.camel@localhost.localdomain> On Tue, 2007-01-02 at 16:19 -0500, Konstantin Ryabitsev wrote: > To use puppet, I'd have to learn "yet another config > language" and ruby, which is prohibitively time-consuming. There is absolutely no reason why a puppet user would need to know ruby - there are plenty of people who use puppet and have no ruby knowledge. As for having to learn another config language vs. extending glump: you can master puppet's language in a couple of hours or so. You would need to weigh that against how long it would take you to extend glump to do what you need it to do. David From icon at fedoraproject.org Wed Jan 3 03:26:08 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 2 Jan 2007 22:26:08 -0500 Subject: Config stuff and glump (as my introduction) In-Reply-To: <1167787308.2907.19.camel@localhost.localdomain> References: <1167787308.2907.19.camel@localhost.localdomain> Message-ID: On 02/01/07, David Lutterkort wrote: > There is absolutely no reason why a puppet user would need to know ruby > - there are plenty of people who use puppet and have no ruby knowledge. Sure, but I try to avoid using tools that I can't fix, especially tools that are integral to the functioning of my systems. Especially since it's the ONLY tool that requires ruby. On the other hand, I know Python, and so does nearly every other person whom I'm likely to consult if I have troubles with something. RHEL/Fedora use Python extensively, and sometimes exclusively, so integrating a Python tool with them would be very simple and straightforward. Many libraries have bindings to Python -- very few have bindings to Ruby. It doesn't make sense for me to rely on Ruby. Simple as that. > As for having to learn another config language vs. extending glump: you > can master puppet's language in a couple of hours or so. You would need > to weigh that against how long it would take you to extend glump to do > what you need it to do. Yes, but at least it would be fun, considering I already did most of the work with glump in the first place. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From mmcgrath at fedoraproject.org Wed Jan 3 03:40:32 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 2 Jan 2007 21:40:32 -0600 Subject: Config stuff and glump (as my introduction) In-Reply-To: References: <1167787308.2907.19.camel@localhost.localdomain> Message-ID: <3237e4410701021940y6a3d4a1bh9d84126b6a9669f0@mail.gmail.com> On 1/2/07, Konstantin Ryabitsev wrote: > On 02/01/07, David Lutterkort wrote: > Sure, but I try to avoid using tools that I can't fix, especially > tools that are integral to the functioning of my systems. Especially > since it's the ONLY tool that requires ruby. I have to say this is a pretty big minus, not only do we not have ruby installed anywhere in our environment that I'm aware of but for the most part we're a python shop. It's still not a no for puppet, just a big strike against in my mind. -Mike From Matt_Domsch at dell.com Wed Jan 3 19:04:59 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 3 Jan 2007 13:04:59 -0600 Subject: Introduction: Matt Domsch Message-ID: <20070103190459.GB31696@lists.us.dell.com> So, I never got around to sending one of these. Here goes. I'm a Linux software architect for Dell. I've been administering Linux systems since 1994 and have been Dell's lead engineer for Linux products since 1999. My team develops and tests Red Hat Enterprise Linux and Novell/SuSE Linux Enterprise Server products on Dell PowerEdge servers and Precision workstations. We use Fedora on our laptops and desktops, fix bugs, and merge those fixes into all of the various streams - upstream and various target distros. I also have the privilage of serving Fedora on the Fedora Project Board. I run the linux-poweredge at dell.com public mailing list (subscribe and read archives at http://lists.us.dell.com) among others, which has several thousand Linux sysadmins on it. I'm a master of many languages and cultures. I blend in. You'll never find me. oops, wrong movie... For Fedora Infrastructure, I'm working on the Mirror Management System. I also want to get gitweb working for anonymous r/o checkouts from the new project hosting service. I'm 'mdomsch' on IRC. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From rzarouali at gmail.com Wed Jan 3 19:13:50 2007 From: rzarouali at gmail.com (Zarouali Rachid) Date: Wed, 3 Jan 2007 20:13:50 +0100 Subject: Introduction: Matt Domsch In-Reply-To: <20070103190459.GB31696@lists.us.dell.com> References: <20070103190459.GB31696@lists.us.dell.com> Message-ID: welcome aboard matt ;) Rachid aka symerian on IRC On 1/3/07, Matt Domsch wrote: > > So, I never got around to sending one of these. Here goes. > > I'm a Linux software architect for Dell. I've been administering > Linux systems since 1994 and have been Dell's lead engineer for Linux > products since 1999. My team develops and tests Red Hat Enterprise > Linux and Novell/SuSE Linux Enterprise Server products on Dell > PowerEdge servers and Precision workstations. We use Fedora on our > laptops and desktops, fix bugs, and merge those fixes into all of the > various streams - upstream and various target distros. I also have > the privilage of serving Fedora on the Fedora Project Board. I run > the linux-poweredge at dell.com public mailing list (subscribe and read > archives at http://lists.us.dell.com) among others, which has several > thousand Linux sysadmins on it. > > I'm a master of many languages and cultures. I blend in. You'll > never find me. oops, wrong movie... > > For Fedora Infrastructure, I'm working on the Mirror Management > System. I also want to get gitweb working for anonymous r/o checkouts > from the new project hosting service. > > I'm 'mdomsch' on IRC. > > Thanks, > Matt > > -- > Matt Domsch > Software Architect > Dell Linux Solutions linux.dell.com & www.dell.com/linux > Linux on Dell mailing lists @ http://lists.us.dell.com > > _______________________________________________ > 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 jkeating at redhat.com Wed Jan 3 19:32:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 3 Jan 2007 14:32:19 -0500 Subject: Introduction: Matt Domsch In-Reply-To: <20070103190459.GB31696@lists.us.dell.com> References: <20070103190459.GB31696@lists.us.dell.com> Message-ID: <200701031432.19926.jkeating@redhat.com> On Wednesday 03 January 2007 14:04, Matt Domsch wrote: > I'm a master of many languages and cultures. ?I blend in. ?You'll > never find me. ?oops, wrong movie... Now where did he go??! -- Jesse Keating Release Engineer: Fedora -------------- 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 Wed Jan 3 20:49:21 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 03 Jan 2007 15:49:21 -0500 Subject: Config stuff and glump (as my introduction) In-Reply-To: <3237e4410701021940y6a3d4a1bh9d84126b6a9669f0@mail.gmail.com> References: <1167787308.2907.19.camel@localhost.localdomain> <3237e4410701021940y6a3d4a1bh9d84126b6a9669f0@mail.gmail.com> Message-ID: <459C16D1.4030801@redhat.com> Mike McGrath wrote: > On 1/2/07, Konstantin Ryabitsev wrote: >> On 02/01/07, David Lutterkort wrote: > >> Sure, but I try to avoid using tools that I can't fix, especially >> tools that are integral to the functioning of my systems. Especially >> since it's the ONLY tool that requires ruby. > > I have to say this is a pretty big minus, not only do we not have ruby > installed anywhere in our environment that I'm aware of but for the > most part we're a python shop. It's still not a no for puppet, just a > big strike against in my mind. I've always been disappointed when I've run across the "but we're a X shop" thing in my career. They've usually ruled out good tools for the wrong reasons. Namely, "but we're a Windows shop, we can't do that", "we're a Sybase shop, we can't use Postgres", "we are going to be a .NET shop, no Python for you!". Python is great, but Ruby can be great also. To a person that has a lot of experience with various dynamic languages, they aren't really all that different, at least when you get beyond Perl and "I have to hack in an object system!?!?". But hey, even /that/ isn't all that hard. They are both very simple languages to learn. Rails became famous because of it's 30 minute tutorial/demo, for instance. At worst case, you get another language to add to your resumes. If it you think chosing Puppet will be a problem due to implementation, at least know you have a couple of folks here who are fluent in Ruby and aren't put off by it, and are willing to help out should that become a problem. David's pretty darn active in the Puppet community and I think you're going to see a lot more interesting plugins for it coming up in the future. I myself do not follow Puppet closely, but I have the Ruby knowledge to work on it and extend it if needed. Do I expect that I'll need to work on it? Not really. The comment about certain libraries not having Ruby bindings is definitely valid, though in many cases the tools in question have command line forms that are preferable to the API's in almost every case, and Ruby is excellent at interacting with them. Cobbler (http://cobbler.et.redhat.com) is written in Python, for instance, but chooses to call a lot of tools directly just because the Python API's are complex and shifting compared to their command line equivalents. It's much easier to just rely on the external interfaces. Yes, it's gluey, but that's what 90% of systems programming ends up being. While one can say they don't want to learn Ruby, I really don't want to know the yum and RPM api's inside and out either. So I think that's a bit of a push to say there are a ton of Python libraries a config management app needs to connect to. A few, yes, but what functionality there is needed that isn't already there? There can't be that much. Another danger with a less-used solution is that you have a smaller user community, so you miss out on features and have less community folks available to fix things should they go wrong. If one adds new features, one can contribute those back upstream. Plus, it makes the knowledge learned from working on it portable -- not just useful for infrastructure, but in other projects, which is an honorable goal. Laziness is a virtue according to Mr. Wall, so I'm all for the solution that involves the least amount of work and best future support for things that need to get done, as opposed to the one that is fun and will create more work in the future. But then again, I'm new, and I don't entirely know what needs to get done. My two cents, anyway... --Michael > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From a.badger at gmail.com Wed Jan 3 21:37:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 03 Jan 2007 13:37:57 -0800 Subject: Config stuff and glump (as my introduction) In-Reply-To: <3237e4410701021940y6a3d4a1bh9d84126b6a9669f0@mail.gmail.com> References: <1167787308.2907.19.camel@localhost.localdomain> <3237e4410701021940y6a3d4a1bh9d84126b6a9669f0@mail.gmail.com> Message-ID: <1167860277.23361.38.camel@localhost.localdomain> On Tue, 2007-01-02 at 21:40 -0600, Mike McGrath wrote: > On 1/2/07, Konstantin Ryabitsev wrote: > > On 02/01/07, David Lutterkort wrote: > > > Sure, but I try to avoid using tools that I can't fix, especially > > tools that are integral to the functioning of my systems. Especially > > since it's the ONLY tool that requires ruby. > > I have to say this is a pretty big minus, not only do we not have ruby > installed anywhere in our environment that I'm aware of but for the > most part we're a python shop. It's still not a no for puppet, just a > big strike against in my mind. This is a minus but I'm not sure it's the huge minus that everyone makes it out to be. I have several reasons for thinking that: Why do we need to hack the tool? * We'd need to hack puppet if we ran into a bug and the upstream developers weren't very responsive. With an active and responsive upstream this is _less_ of an issue. In some ways, this is like the open source vs closed source argument for managers. Just because the manager can't hack on it doesn't mean there aren't other people who are willing to because it's open source. Similarly, just because we aren't ruby gurus doesn't mean that there isn't a dedicated community of hackers surrounding puppet. * We would need to hack puppet if it doesn't have features that we need. We're currently moving from an extremely simple system. It should be pretty easy to determine if puppet will suit our present needs. We also want to allow room to grow. For that we should be comparing puppet's features to its competitors. Would it be any easier to hack on if it were (C|shell|perl)? * If it were written in C we'd all be capable of hacking on it but wouldn't have much fun or be as productive as in python. Ruby isn't python but it shares a lot more with it than with C. I learned python by staring at other people's source code. It's not so far fetched to do the same thing with ruby. Are we really devoid of ruby hackers? * David, at least is quite knowledgable, not only with ruby but also with puppet but I don't know how much time he has to spend with us. He is the maintainer of our FE package, though, so fixing bugs is something he'll be keen to do for more than just us. * puppet is being used in other areas of Red Hat, are there other Fedora Infrastructure people (from outside of Red Hat as well as inside) who are ruby/puppet hackers? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mdehaan at redhat.com Wed Jan 3 22:34:52 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 03 Jan 2007 17:34:52 -0500 Subject: Config stuff and glump (as my introduction) In-Reply-To: <1167860277.23361.38.camel@localhost.localdomain> References: <1167787308.2907.19.camel@localhost.localdomain> <3237e4410701021940y6a3d4a1bh9d84126b6a9669f0@mail.gmail.com> <1167860277.23361.38.camel@localhost.localdomain> Message-ID: <459C2F8C.3040709@redhat.com> Toshio Kuratomi wrote: > > * puppet is being used in other areas of Red Hat, are there other Fedora > Infrastructure people (from outside of Red Hat as well as inside) who > are ruby/puppet hackers? > In case it wasn't clear, I'm also a Ruby user, and have been using it for various things for a few years. Primarily for build system work (one system based on DamageControl, which is Ruby, one not), a couple of rails apps, and some random customer and internal utilities (pre Red Hat). I've also written some C binding stuff for OpenGL should anyone _really_ want to go off the deep end (not hard, really, the Ruby DL module rocks). Basically I've used it for anything someone typically uses Perl for (XML parsing included), and I think I even wrote some libpcap stuff in Ruby at some point. Evidence of Ruby fame, or lack thereof: http://www.rubygarden.org:3000/Ruby/page/show/RubyGolf/QuackingDuck :) > -Toshio > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From a.badger at gmail.com Thu Jan 4 10:10:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Jan 2007 02:10:14 -0800 Subject: PackageDB Progress Message-ID: <1167905414.23361.101.camel@localhost.localdomain> For all those who haven't been following along because of the Holidays, we have data in the database! For all those who have been following along, there's a TurboGears deployment needing some serious UI love! I've coded a read-only view of the Fedora 1-devel Collections with lists of packages in each. Making a similar interface for the Packages should be out later this week. If you want to stare at the horror that is a project in the middle of birth have a gander here: http://admin.fedoraproject.org/pkgdb There's a lot left to do and I'm anxious to start recruiting others to work on various aspects of this. I'll post a more formal list of sub-tasks for this project after the meeting tomorrow but for now, if anyone wants to give feedback on the database schema, it's still got the ugly hacks that I'd love someone to point out a more elegant solution for (schema attached). And anyone that thinks they'd like to take a stab at using TurboGears and SQLAlchemy, prepare to be recruited! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: pkgdb.sql Type: text/x-vhdl Size: 28096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Jan 4 20:02:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Jan 2007 15:02:04 -0500 Subject: Self-Introduction: Bill Nottingham Message-ID: <20070104200204.GA6412@nostromo.devel.redhat.com> I'm a resident old fart here at Red Hat, and somewhat of a Fedora jack-of-all-trades, doing development and helping with testing, releasing, signing, planning, etc. I've been heavily involved in the planning of the Great Merger, and the plans for Fedora 7. I'm also a member of the Fedora Project Board. Fedora infrastructure plans: I am probably going to be one of those annoying people coming up with lots of plans along the lines of "we should do X, Y, and Z, and here are plans for them" without actually doing the implementation. Whether that makes me useful or useless remains to be seen. Bill From timp at redhat.com Thu Jan 4 22:11:56 2007 From: timp at redhat.com (Tim Powers) Date: Thu, 4 Jan 2007 17:11:56 -0500 Subject: Another Self-Introduction: Tim Powers Message-ID: <89F78203-589F-455A-8968-D4A4FC6E5735@redhat.com> I'm one of the other resident old-farts at Red Hat. I'm currently the architect for Red Hat's Release Configuration Management team (aka release engineering). My main focus is on the infrastructure within Red Hat and RHEL. I am willing to contribute ideas etc. without being the one to implement them (again, like Bill). -- Tim Powers Architect, Release Configuration Management Red Hat, Inc. From smooge at gmail.com Thu Jan 4 23:14:11 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 4 Jan 2007 16:14:11 -0700 Subject: Another Self-Introduction: Tim Powers In-Reply-To: <89F78203-589F-455A-8968-D4A4FC6E5735@redhat.com> References: <89F78203-589F-455A-8968-D4A4FC6E5735@redhat.com> Message-ID: <80d7e4090701041514g2abeec34y3dbbbf3f2b98853@mail.gmail.com> On 1/4/07, Tim Powers wrote: > I'm one of the other resident old-farts at Red Hat. > Tim has also done everything including fixing the kitchen sink at Red Hat (at least once or twice when I was there..) His first job was doing Technical Support and then cleaning up Powertools for a while. [We arent supposed to mention that he did jumps out of the Red Hat Black Helicopters to deal with troublesome clients.] > I'm currently the architect for Red Hat's Release Configuration > Management team (aka release engineering). My main focus is on the > infrastructure within Red Hat and RHEL. > > I am willing to contribute ideas etc. without being the one to > implement them (again, like Bill). > > -- > Tim Powers > Architect, Release Configuration Management > Red Hat, Inc. > Everyone gets the good titles these days. -- 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 mgalgoci at redhat.com Thu Jan 4 23:35:56 2007 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Thu, 4 Jan 2007 18:35:56 -0500 Subject: Another Self-Introduction: Tim Powers In-Reply-To: <80d7e4090701041514g2abeec34y3dbbbf3f2b98853@mail.gmail.com> References: <89F78203-589F-455A-8968-D4A4FC6E5735@redhat.com> <80d7e4090701041514g2abeec34y3dbbbf3f2b98853@mail.gmail.com> Message-ID: > > -- > > Tim Powers > > Architect, Release Configuration Management > > Red Hat, Inc. > > > > Everyone gets the good titles these days. > Bah -- Matthew Galgoci GIS Production Operations Red Hat, Inc 919.754.3700 x44155 From linux at elfshadow.net Fri Jan 5 02:45:11 2007 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Thu, 04 Jan 2007 21:45:11 -0500 Subject: IRC Meeting Logs Posted Message-ID: <459DBBB7.9030501@elfshadow.net> The past three infrastructure IRC meeting logs have been posted to the wiki: January 4, 2007: http://fedoraproject.org/wiki/Infrastructure/Meetings/2007-01-04 December 28, 2006: http://fedoraproject.org/wiki/Infrastructure/Meetings/2006-12-28 December 21, 2006: http://fedoraproject.org/wiki/Infrastructure/Meetings/2006-12-21 --Jeffrey From lyz27 at yahoo.com Fri Jan 5 03:03:32 2007 From: lyz27 at yahoo.com (TomLy) Date: Thu, 04 Jan 2007 21:03:32 -0600 Subject: New accounts LDAP server running Message-ID: <1167966212.12346.17.camel@localhost.localdomain> test5.fedora.phx.redhat.com has an instance of FDS running on it with the current schemas and sample data that I've been working with. For a primer on the schema, please see http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/Schema .Pretty screenshot attached. I need to figure out the group situation still and hope to solidify the schema so that development against it may commence. I have already tested and verified apache authentication against it using mod_authnz_ldap. As always, if there's anything I can improve, let me know. ~lyz -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-test5.fedora.phx.redhat.com - Fedora Directory Server - fedora-accounts.png Type: image/png Size: 60260 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 5 04:24:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 4 Jan 2007 23:24:05 -0500 Subject: New accounts LDAP server running In-Reply-To: <1167966212.12346.17.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> Message-ID: <200701042324.05949.jkeating@redhat.com> On Thursday 04 January 2007 22:03, TomLy wrote: > test5.fedora.phx.redhat.com has an instance of FDS running on it with > the current schemas and sample data that I've been working with. These are the completely OSS parts of FDS right? -- Jesse Keating Release Engineer: Fedora -------------- 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 fedoraproject.org Fri Jan 5 14:52:55 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 5 Jan 2007 08:52:55 -0600 Subject: New accounts LDAP server running In-Reply-To: <200701042324.05949.jkeating@redhat.com> References: <1167966212.12346.17.camel@localhost.localdomain> <200701042324.05949.jkeating@redhat.com> Message-ID: <3237e4410701050652k5cff4bbfwb8a2ce943a7d9ae9@mail.gmail.com> On 1/4/07, Jesse Keating wrote: > On Thursday 04 January 2007 22:03, TomLy wrote: > > test5.fedora.phx.redhat.com has an instance of FDS running on it with > > the current schemas and sample data that I've been working with. > > These are the completely OSS parts of FDS right? > I thought the whole thing was OSSed and worked with gcj now? If not its not a huge deal we'll just use a different management frontend. -Mike From jkeating at redhat.com Fri Jan 5 14:55:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 5 Jan 2007 09:55:52 -0500 Subject: New accounts LDAP server running In-Reply-To: <3237e4410701050652k5cff4bbfwb8a2ce943a7d9ae9@mail.gmail.com> References: <1167966212.12346.17.camel@localhost.localdomain> <200701042324.05949.jkeating@redhat.com> <3237e4410701050652k5cff4bbfwb8a2ce943a7d9ae9@mail.gmail.com> Message-ID: <200701050955.52583.jkeating@redhat.com> On Friday 05 January 2007 09:52, Mike McGrath wrote: > I thought the whole thing was OSSed and worked with gcj now? ?If not > its not a huge deal we'll just use a different management frontend. I wasn't sure, which was why I was asking (: -- Jesse Keating Release Engineer: Fedora -------------- 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 fedoraproject.org Fri Jan 5 21:17:13 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 5 Jan 2007 15:17:13 -0600 Subject: Fudcon - Items for discussion Message-ID: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> What should be added or removed? Remember this is going to be a time for us to actually sit in a room and get stuff done. High level goals (Infrastructure Specific): 1) Basic auth/group API for the old Accounting system and the new one in Python. 2) Update System hacking (lmacken lead) 3) Finalize the new postfix server 4) Discuss the "Fedora Noc" + initial coding / Design 5) Volunteer sponsorship 6) Future of the wiki (Moin) 7) Design and coding of new account system (Try to find something that is already out there) 8) Hosting (Jkeating lead) 9) Package Database 10) Backup Server (Finalize) High level goals (general non-infrastructure specific) 1) Lowering the barrier to entry without sacrificing infrastructure / security 2) Volunteer management (coordination might be a better word) 3) VCS / SCM future (Lead by those in the sig) I'd also like to get with some of the other dev's to get an idea of whats important for them to have going forward and whats needed for this release. -Mike From notting at redhat.com Fri Jan 5 21:18:37 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 5 Jan 2007 16:18:37 -0500 Subject: Fudcon - Items for discussion In-Reply-To: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> Message-ID: <20070105211837.GI23650@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > I'd also like to get with some of the other dev's to get an idea of whats > important for them to have going forward and whats needed for this > release. i18n/elvis/rhlinux migration. Bill From a.badger at gmail.com Sat Jan 6 00:25:08 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Jan 2007 16:25:08 -0800 Subject: Fudcon - Items for discussion In-Reply-To: <20070105211837.GI23650@nostromo.devel.redhat.com> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> <20070105211837.GI23650@nostromo.devel.redhat.com> Message-ID: <1168043108.14818.2.camel@localhost.localdomain> On Fri, 2007-01-05 at 16:18 -0500, Bill Nottingham wrote: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > I'd also like to get with some of the other dev's to get an idea of whats > > important for them to have going forward and whats needed for this > > release. > > i18n/elvis/rhlinux migration. Could we have someone at FudCon to give us a tour of what all is in need of migration? I know that there's a bunch of infrastructure there that needs to move but don't have a clear idea of just what it is. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Jan 6 00:47:36 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Jan 2007 16:47:36 -0800 Subject: New accounts LDAP server running In-Reply-To: <1167966212.12346.17.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> Message-ID: <1168044456.14818.24.camel@localhost.localdomain> On Thu, 2007-01-04 at 21:03 -0600, TomLy wrote: > test5.fedora.phx.redhat.com has an instance of FDS running on it with > the current schemas and sample data that I've been working with. For a > primer on the schema, please see > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/Schema .Pretty screenshot attached. > > I need to figure out the group situation still and hope to solidify the > schema so that development against it may commence. I have already > tested and verified apache authentication against it using > mod_authnz_ldap. Do you have some ideas on how we should proceed with development? There are a few separate threads to this: 1) New development is being done in TurboGears. TurboGears has an identity structure that even has an LDAP plugin. We need to test that against our servers. TurboGears also needs to save state (so that you don't have to reauth on every page load), so we'll have to provide a supplemental database to save the session information. 2) Old applications are built using the fedora-accounts python modules. From my brief usage of it, I believe the main API is in the website.py file. We need to compile a list of what applications are using this and port them to the new infrastructure. It may be easiest to port website.py to the new infrastructure so the applications don't have to worry about the changes or it may be better to port the applications to the new LDAP + session interface. It depends on how many apps exist and what they are currently using in website.py. 3) Porting/pointing third party applications that we use to LDAP. This includes MoinMoin, Plone, and OTRS. Since this is the reason we're moving to an LDAP backend, this should be relatively straightforward. 4) OpenID. I think the idea is we host an OpenID server and then new pieces of infrastructure can use either ldap or OpenID to authenticate. The hope is that other places will use Fedora's OpenID service to authenticate our users to their services. I believe that nothing currently has an openID plugin that doesn't have an ldap plugin so this can be put off for a bit. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Sat Jan 6 01:20:46 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 5 Jan 2007 19:20:46 -0600 Subject: Fudcon - Items for discussion In-Reply-To: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> Message-ID: <200701051920.46837.dennis@ausil.us> On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: > What should be added or removed? Remember this is going to be a time > for us to actually sit in a room and get stuff done. > > High level goals (Infrastructure Specific): > 1) Basic auth/group API for the old Accounting system and the new > one in Python. > 2) Update System hacking (lmacken lead) > 3) Finalize the new postfix server > 4) Discuss the "Fedora Noc" + initial coding / Design > 5) Volunteer sponsorship > 6) Future of the wiki (Moin) > 7) Design and coding of new account system (Try to find something > that is already out there) > 8) Hosting (Jkeating lead) > 9) Package Database > 10) Backup Server (Finalize) > > High level goals (general non-infrastructure specific) > 1) Lowering the barrier to entry without sacrificing > infrastructure / security > 2) Volunteer management (coordination might be a better word) > 3) VCS / SCM future (Lead by those in the sig) > > I'd also like to get with some of the other dev's to get an idea of whats > important for them to have going forward and whats needed for this > release. I think in this new world We are going to have greater demands placed on us. We really need to know what we are in for at release time. There is a whole lot of stuff that has always happened by RH IS staff. will this continue to be the case or Will we pick up new tasks? otherwise it sounds good. Should we have a infrastructure dinner to get to know everyone a bit better? -- Dennis Gilmore, RHCE Proud Australian From lyz27 at yahoo.com Sat Jan 6 02:14:08 2007 From: lyz27 at yahoo.com (TomLy) Date: Fri, 05 Jan 2007 20:14:08 -0600 Subject: New accounts LDAP server running In-Reply-To: <1168044456.14818.24.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> <1168044456.14818.24.camel@localhost.localdomain> Message-ID: <1168049648.3151.14.camel@localhost.localdomain> > We need to compile a list of what applications are using this and > port them to the new infrastructure. I'd like to get this moving more sooner than later. Can we get a wiki page going for this? Something that lists the application or function that authenticates and the type of authentication it uses (whether through website.py or apache mods etc.) . I would do this myself, but am not the best person for it. ~tom From mmcgrath at fedoraproject.org Sat Jan 6 02:24:25 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 5 Jan 2007 20:24:25 -0600 Subject: Fudcon - Items for discussion In-Reply-To: <200701051920.46837.dennis@ausil.us> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> <200701051920.46837.dennis@ausil.us> Message-ID: <3237e4410701051824h64e6274aq70ed545435b2f8de@mail.gmail.com> On 1/5/07, Dennis Gilmore wrote: > On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: > I think in this new world We are going to have greater demands placed on us. > We really need to know what we are in for at release time. There is a whole > lot of stuff that has always happened by RH IS staff. will this continue to > be the case or Will we pick up new tasks? otherwise it sounds good. > > Should we have a infrastructure dinner to get to know everyone a bit better? > +1 for an FI Lunch or Dinner. Regarding RH IS, I'm guessing that more and more we'll be moving to the Fedora infrastructure for things, lots of things. Or possibly not moving a whole lot but more that our growth will be on FI and not RH IS. -Mike From lmacken at redhat.com Sat Jan 6 02:28:32 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 05 Jan 2007 21:28:32 -0500 Subject: Fudcon - Items for discussion In-Reply-To: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> Message-ID: <459F0950.4020705@redhat.com> Mike McGrath wrote: > What should be added or removed? Remember this is going to be a time > for us to actually sit in a room and get stuff done. > > High level goals (Infrastructure Specific): > 1) Basic auth/group API for the old Accounting system and the new > one in Python. > 2) Update System hacking (lmacken lead) > 3) Finalize the new postfix server > 4) Discuss the "Fedora Noc" + initial coding / Design > 5) Volunteer sponsorship > 6) Future of the wiki (Moin) > 7) Design and coding of new account system (Try to find something > that is already out there) > 8) Hosting (Jkeating lead) > 9) Package Database > 10) Backup Server (Finalize) During the summit Warren proposed a few security policies for our publictest* machines, which we all agreed on: o must get approval from infrastructure team o denyhosts must be configured o ssh key authentication only I think we should try and discuss and draft a full security policy for all of our infrastructure while we're at FUDCon. We might also want to talk about single sign-on for our applications and such. luke From mgalgoci at redhat.com Sat Jan 6 02:36:28 2007 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Fri, 5 Jan 2007 21:36:28 -0500 Subject: Fudcon - Items for discussion In-Reply-To: <3237e4410701051824h64e6274aq70ed545435b2f8de@mail.gmail.com> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> <200701051920.46837.dennis@ausil.us> <3237e4410701051824h64e6274aq70ed545435b2f8de@mail.gmail.com> Message-ID: > > On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: > > I think in this new world We are going to have greater demands placed on us. > > We really need to know what we are in for at release time. There is a > > whole > > lot of stuff that has always happened by RH IS staff. will this continue to > > be the case or Will we pick up new tasks? otherwise it sounds good. > > > > Should we have a infrastructure dinner to get to know everyone a bit better? > > > > +1 for an FI Lunch or Dinner. Regarding RH IS, I'm guessing that more > and more we'll be moving to the Fedora infrastructure for things, lots > of things. Or possibly not moving a whole lot but more that our > growth will be on FI and not RH IS. when is this fudcon thingy? maybe I should make a cameo. -- Matthew Galgoci GIS Production Operations Red Hat, Inc 919.754.3700 x44155 From nils at breun.nl Sat Jan 6 02:47:15 2007 From: nils at breun.nl (Nils Breunese) Date: Sat, 6 Jan 2007 03:47:15 +0100 Subject: Fudcon - Items for discussion In-Reply-To: <459F0950.4020705@redhat.com> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> <459F0950.4020705@redhat.com> Message-ID: Luke Macken wrote: > During the summit Warren proposed a few security policies for our > publictest* machines, which we all agreed on: > > o must get approval from infrastructure team > o denyhosts must be configured > o ssh key authentication only I use SSH public key authentication on all my servers (password authentication disabled) and I used to run DenyHosts. At some point I decided to replace DenyHosts with Fail2ban [1], because Fail2ban creates (temporary) iptables rules instead of (temporary) entries in / etc/hosts.deny. Have you compared the two? Nils Breunese. [1] http://fail2ban.sourceforge.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From lyz27 at yahoo.com Sat Jan 6 02:45:52 2007 From: lyz27 at yahoo.com (TomLy) Date: Fri, 05 Jan 2007 20:45:52 -0600 Subject: New accounts LDAP server running In-Reply-To: <1168044456.14818.24.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> <1168044456.14818.24.camel@localhost.localdomain> Message-ID: <1168051552.3151.32.camel@localhost.localdomain> > > > Do you have some ideas on how we should proceed with development? Here's the stages that I see at this time: 1. LDAP structure gets stabilized. Of course, there may be slight tweaks to this during the following stages. 2. The syncing mechinism is set up to sync the production DB to LDAP (nightly?) 3. The easy apps are ported to authenticate against LDAP (moin moin, apps that use apache auth). 4. Website.py ported and apps moved to LDAP 5. Turbo gears authentication framework devised and TG apps ported 6. Account system web administration rewritten in TG to work with LDAP 7. Old system retired 8. OpenID Please add/edit this I will make a wiki page out of it when it's accepted. ~tom From a.badger at gmail.com Sat Jan 6 02:57:07 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Jan 2007 18:57:07 -0800 Subject: New accounts LDAP server running In-Reply-To: <1168049648.3151.14.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> <1168044456.14818.24.camel@localhost.localdomain> <1168049648.3151.14.camel@localhost.localdomain> Message-ID: <1168052227.14818.43.camel@localhost.localdomain> On Fri, 2007-01-05 at 20:14 -0600, TomLy wrote: > > We need to compile a list of what applications are using this and > > port them to the new infrastructure. > > I'd like to get this moving more sooner than later. Can we get a wiki > page going for this? Something that lists the application or function > that authenticates and the type of authentication it uses (whether > through website.py or apache mods etc.) . I would do this myself, but > am not the best person for it. > Started a page here: http://www.fedoraproject.org/wiki/Infrastructure/AccountSystem2/LegacyApps I've made three sections: Apps using the Python API * voting * Old Account System interface * Syncing the accounts to the infrastructure servers -- export-*.{py,sh} Apps using the DB Directly Apps using an apache module * OTRS Please fill the lists in with any applications that you can think of. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Jan 6 03:00:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Jan 2007 19:00:31 -0800 Subject: Fudcon - Items for discussion In-Reply-To: References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> <200701051920.46837.dennis@ausil.us> <3237e4410701051824h64e6274aq70ed545435b2f8de@mail.gmail.com> Message-ID: <1168052431.14818.48.camel@localhost.localdomain> On Fri, 2007-01-05 at 21:36 -0500, Matthew Galgoci wrote: > > > On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: > > > I think in this new world We are going to have greater demands placed on us. > > > We really need to know what we are in for at release time. There is a > > > whole > > > lot of stuff that has always happened by RH IS staff. will this continue to > > > be the case or Will we pick up new tasks? otherwise it sounds good. > > > > > > Should we have a infrastructure dinner to get to know everyone a bit better? > > > > > > > +1 for an FI Lunch or Dinner. Regarding RH IS, I'm guessing that more > > and more we'll be moving to the Fedora infrastructure for things, lots > > of things. Or possibly not moving a whole lot but more that our > > growth will be on FI and not RH IS. > > when is this fudcon thingy? maybe I should make a cameo. > Since mgalgoci probably isn't the only one that doesn't know about this: http://barcamp.org/FudconBoston2007 ''' FUDCon Boston 2007 :: 02 February 2007 :: Boston University FUDCon? Bar Camp? Read this First! FUDCon stands for Fedora User and Developer Conference. FUDCon Boston 2007 will be held as a Bar Camp. A Bar Camp is an "un-conference" where people interested in a wide range of issues come together to teach and learn. ''' -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Sat Jan 6 03:17:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 5 Jan 2007 22:17:41 -0500 Subject: Fudcon - Items for discussion In-Reply-To: <1168043108.14818.2.camel@localhost.localdomain> References: <3237e4410701051317j40b82480pd9fc2f9d67e7392d@mail.gmail.com> <20070105211837.GI23650@nostromo.devel.redhat.com> <1168043108.14818.2.camel@localhost.localdomain> Message-ID: <20070106031741.GC27988@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > > i18n/elvis/rhlinux migration. > > Could we have someone at FudCon to give us a tour of what all is in need > of migration? I know that there's a bunch of infrastructure there that > needs to move but don't have a clear idea of just what it is. What's On Elvis: 1) a CVS server. Self-explanatory. - includes pserver (aiyeeee!) - includes sanity checks on translation checkin - includes ACLs for translators so they don't commit to other languages 2) Accounts (ssh v2 keys), split into two groups: - general write access - translators (write access to .po files only) 3) the translation system, which has: - its own separate account database (postgresql) on top. tracking: - translators - their keys - their .htpasswds - languages - translator/language mappings - module statuses - translator status (active, suspended, etc) - web frontend - showing translation status - allowing you to 'reserve' files #1 is pretty easy. #2, well, we know how we're going to tackle that. #3 is all written in perl (which has its good and bad points.) However, since it's written around a database which needs to die, I'm not sure it's useful at all. So, what we need is: - translators in the account system - a way to describe in the account system what langauges a translator is responsible for - a way to enforce that when checkins are done Frankly, I'm of the opinion that most of the rest of the stuff can be scrapped as is and can be replaced by something like damned-lies (progress.gnome.org). In fact, asking other projects what sort of software they use around their translation couldn't hurt. One thing we'll need is a way to integrate this translation framework across multiple SCMs - I'd like to be able to handle software whether it's in git, svn, cvs, or hg. We'll also need a better group organization aside from just 'put everyone in cvsfedora'. Bill From ssrat at ticon.net Sun Jan 7 03:16:25 2007 From: ssrat at ticon.net (David Douthitt) Date: Sat, 06 Jan 2007 21:16:25 -0600 Subject: Config stuff and glump (as my introduction) In-Reply-To: References: Message-ID: <45A06609.5010706@ticon.net> Konstantin Ryabitsev wrote: > I do hate cfengine (probably party due to the way it's set > up here), and I do not consider puppet to be a good alternative, > mostly because it's "yet another config language" and because it's > written in ruby. Well.... I personally think that puppet being written in Ruby is a plus :-P However, puppet itself is not Ruby; it is only developed in Ruby. Ruby is also used extensively for the FreeBSD portsupgrade tool and for Ruby on Rails. I suspect its more widely used than most realize, and if I'm not mistaken, Ruby is included in one or more of the standard Red Hat installs. I must admit that the creation of my first customized Red Hat installation CDROMs was largely done to include Ruby v1.4.... From sopwith at gmail.com Sun Jan 7 15:45:49 2007 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 7 Jan 2007 10:45:49 -0500 Subject: New accounts LDAP server running In-Reply-To: <1167966212.12346.17.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> Message-ID: On Jan 4, 2007, at 10:03 PM, TomLy wrote: > test5.fedora.phx.redhat.com has an instance of FDS running on it with > the current schemas and sample data that I've been working with. > For a > primer on the schema, please see > http://fedoraproject.org/wiki/Infrastructure/AccountSystem2/ > Schema .Pretty screenshot attached. > > I need to figure out the group situation still and hope to solidify > the > schema so that development against it may commence. I have already > tested and verified apache authentication against it using > mod_authnz_ldap. Just noticed that the project_group.prerequisite_id field is not carried over to the new schema, and the page didn't sound like there was a general understanding of why the field is there. It's there to allow you to specify that anyone who joins a group must be in another group first. Most of the time it is used to enforce CLA compliance for a particular group, by setting cla_done as a prerequisite for any groups that give access that needs the CLA (e.g. all the cvs* groups). AFAIK, enforcing CLA compliance is a must for the future, and if we're going to implement a solution for that, it might as well be generic (instead of just a 'needs_cla' field in the DB, for example). Best, -- Elliot From mmcgrath at fedoraproject.org Sun Jan 7 16:38:02 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 7 Jan 2007 10:38:02 -0600 Subject: New accounts LDAP server running In-Reply-To: References: <1167966212.12346.17.camel@localhost.localdomain> Message-ID: <3237e4410701070838o16a2490bu1165fb397ca839b2@mail.gmail.com> On 1/7/07, Elliot Lee wrote: > > On Jan 4, 2007, at 10:03 PM, TomLy wrote: > Just noticed that the project_group.prerequisite_id field is not > carried over to the new schema, and the page didn't sound like there > was a general understanding of why the field is there. > > It's there to allow you to specify that anyone who joins a group must > be in another group first. Most of the time it is used to enforce CLA > compliance for a particular group, by setting cla_done as a > prerequisite for any groups that give access that needs the CLA (e.g. > all the cvs* groups). > > AFAIK, enforcing CLA compliance is a must for the future, and if > we're going to implement a solution for that, it might as well be > generic (instead of just a 'needs_cla' field in the DB, for example). > This is true, it would be nice to enforce this at the LDAP level somewhere. Lyz do you know of any way to do this? We may want to talk to the FDS people. -Mike From mmcgrath at fedoraproject.org Sun Jan 7 17:40:50 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 7 Jan 2007 11:40:50 -0600 Subject: Voting APP Message-ID: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> Hey Toshio, how hard would it be to turn your voting app into a survey app? -Mike From a.badger at gmail.com Sun Jan 7 18:21:43 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 07 Jan 2007 10:21:43 -0800 Subject: New accounts LDAP server running In-Reply-To: <1168051552.3151.32.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> <1168044456.14818.24.camel@localhost.localdomain> <1168051552.3151.32.camel@localhost.localdomain> Message-ID: <1168194103.14818.96.camel@localhost.localdomain> On Fri, 2007-01-05 at 20:45 -0600, TomLy wrote: > 4. Website.py ported and apps moved to LDAP > > 5. Turbo gears authentication framework devised and TG apps ported As long as we're going to port website.py to LDAP we might want to build the TG framework against the website.py interface. Then we could port to a direct LDAP+session db connection at leisure. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sun Jan 7 19:49:31 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 07 Jan 2007 11:49:31 -0800 Subject: Voting APP In-Reply-To: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> References: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> Message-ID: <1168199371.14818.107.camel@localhost.localdomain> On Sun, 2007-01-07 at 11:40 -0600, Mike McGrath wrote: > Hey Toshio, how hard would it be to turn your voting app into a survey app? > It would take a little work. But it's work that needs to be done anyway. Presently, the voting application only shows one issue. To be more generally useful (for surveys, referendum, etc) it needs to be enhanced to show more than one issue, either sequentially or organized with titles on one page. This is pretty necessary for surveys and somewhat useful for elections (as sooner or later we're going to want to run elections for two organizations at the same time.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lyz27 at yahoo.com Sun Jan 7 20:59:18 2007 From: lyz27 at yahoo.com (TomLy) Date: Sun, 07 Jan 2007 14:59:18 -0600 Subject: New accounts LDAP server running In-Reply-To: <3237e4410701070838o16a2490bu1165fb397ca839b2@mail.gmail.com> References: <1167966212.12346.17.camel@localhost.localdomain> <3237e4410701070838o16a2490bu1165fb397ca839b2@mail.gmail.com> Message-ID: <1168203558.2987.24.camel@localhost.localdomain> > > > > AFAIK, enforcing CLA compliance is a must for the future, and if > > we're going to implement a solution for that, it might as well be > > generic (instead of just a 'needs_cla' field in the DB, for example). > > > > This is true, it would be nice to enforce this at the LDAP level > somewhere. Lyz do you know of any way to do this? We may want to > talk to the FDS people. > > -Mike I'll ask the FDS person we were working with if this is doable. This wasn't truly implemented in the db schema as it appears there could only be one prerequisite. This was set to the cla_done group in almost every case (except sysadmin). In this case, adding attributes to the person's shema isn't the solution (as I was thinking previously). This is because it would require a software layer to check the attribute. One of my thoughts on the new account system is to have LDAP handle as much as possible to avoid having to wright a software layer to wrap it. ~lyz From a.badger at gmail.com Sun Jan 7 22:47:05 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 07 Jan 2007 14:47:05 -0800 Subject: Voting APP In-Reply-To: <1168199371.14818.107.camel@localhost.localdomain> References: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> <1168199371.14818.107.camel@localhost.localdomain> Message-ID: <1168210025.14818.159.camel@localhost.localdomain> On Sun, 2007-01-07 at 11:49 -0800, Toshio Kuratomi wrote: > On Sun, 2007-01-07 at 11:40 -0600, Mike McGrath wrote: > > Hey Toshio, how hard would it be to turn your voting app into a survey app? > > > It would take a little work. But it's work that needs to be done > anyway. Presently, the voting application only shows one issue. To be > more generally useful (for surveys, referendum, etc) it needs to be > enhanced to show more than one issue, either sequentially or organized > with titles on one page. This is pretty necessary for surveys and > somewhat useful for elections (as sooner or later we're going to want to > run elections for two organizations at the same time.) Another note: The Fedora Ambassadors had a meeting and I read in their minutes that they had a need to enhance the Voting App for things they want to do but they never contacted me. I was planning to contact them before enhancing the voting application. If someone else is planning to make voting do surveys, it would probably be a good time to talk to the Ambassadors about what their requirements are as well. -Toshio P.S. Voting is a pretty simple python cgi script at the moment. If someone wants to get their feet wet, it would be a fun little project to start working with. You could enhance the cgi or rewrite it with TurboGears depending on how much work you wanted to do with it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at fedoraproject.org Mon Jan 8 01:08:55 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 7 Jan 2007 19:08:55 -0600 Subject: New accounts LDAP server running In-Reply-To: <1168203558.2987.24.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> <3237e4410701070838o16a2490bu1165fb397ca839b2@mail.gmail.com> <1168203558.2987.24.camel@localhost.localdomain> Message-ID: <3237e4410701071708i118922fdyc9c59297bd0a2794@mail.gmail.com> On 1/7/07, TomLy wrote: > > I'll ask the FDS person we were working with if this is doable. This > wasn't truly implemented in the db schema as it appears there could only > be one prerequisite. This was set to the cla_done group in almost every > case (except sysadmin). > > In this case, adding attributes to the person's shema isn't the solution > (as I was thinking previously). This is because it would require a > software layer to check the attribute. One of my thoughts on the new > account system is to have LDAP handle as much as possible to avoid > having to wright a software layer to wrap it. > So what will be the best way to say "in order to be in this group, you must also be in this group and have a signed CLA"? -Mike From sopwith at gmail.com Mon Jan 8 02:00:43 2007 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 7 Jan 2007 21:00:43 -0500 Subject: New accounts LDAP server running In-Reply-To: <1168203558.2987.24.camel@localhost.localdomain> References: <1167966212.12346.17.camel@localhost.localdomain> <3237e4410701070838o16a2490bu1165fb397ca839b2@mail.gmail.com> <1168203558.2987.24.camel@localhost.localdomain> Message-ID: <118DF8DC-0AE2-4D42-A75F-F89B77B6A476@gmail.com> On Jan 7, 2007, at 3:59 PM, TomLy wrote: > I'll ask the FDS person we were working with if this is doable. This > wasn't truly implemented in the db schema as it appears there could > only > be one prerequisite. This was set to the cla_done group in almost > every > case (except sysadmin). > > In this case, adding attributes to the person's shema isn't the > solution > (as I was thinking previously). This is because it would require a > software layer to check the attribute. One of my thoughts on the new > account system is to have LDAP handle as much as possible to avoid > having to wright a software layer to wrap it. Well, realistically speaking, it is a little bit of a pain to implement checking this constraint even in SQL, and I imagine LDAP just can't do it. I don't see a huge need to be worried about implementing the constraint in a software layer, because only the part of the system that adds people to groups will need to worry about it. It is not as if this is something that absolutely every directory client will need to do, just something that will need to go into the administration codebase. (This is assuming, of course that you choose to implement it the same way it is implemented in the old account system. I can think of other ways that /would/ require each and every client to pay attention to it unless there was LDAP support...) Best, -- Elliot From Matt_Domsch at dell.com Mon Jan 8 05:38:31 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 7 Jan 2007 23:38:31 -0600 Subject: Mirrormanager thoughts In-Reply-To: <20070102190026.GA6999@lists.us.dell.com> References: <20070102042013.GA16518@lists.us.dell.com> <20070102190026.GA6999@lists.us.dell.com> Message-ID: <20070108053831.GA4396@lists.us.dell.com> https://hosted.fedoraproject.org/projects/mirrormanager/wiki/WikiStart I've redone the mirrormanager schema and initialization data. I haven't redone the controllers or templates at all yet, so this won't run except in the tg-admin shell and tg-admin toolbox (catwalk is nice). Please take a look. I append the schema file for review. The hierarchy is as follows: Site is the unit of administrative control. Sites have SiteAdmins which will be account names in the Fedora Account System. Sites have one or more Hosts, which are machines under the control of the Site. Sites also provide SiteIPs which are used for the rsync ACLs. These may or may not match Host IPs. Some Hosts offer a private rsync port for other mirrors, particularly useful for disseminating embargoed releases. Can also be used to set up mirror tiering. This is described in the HostPrivateRsync block. Some Hosts are private (e.g. within a company), but could still benefit from the geoip-like redirection, only using CIDR blocks rather than geoip. That's described in the HostIPBlocks. Arch is architectures, there are 4 at present: source, i386, x86_64, and ppc. Content is the highest level unit of data that can be synced. These look like fedora-core-6-i386. Mirror is the combination of a Host and a Content. A Mirror may have a subset of the data provided by the Content. Each Mirror may expose its data to end users via one or more MirrorURLs. Notably, via http, ftp, and rsync simultaneously, though the URLs for each may differ based on the services setup (which is annoying but true). Checking one of these is sufficient to know that the Mirror content exists and is current. Your comments would be appreciated. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com from sqlobject import * from turbogears.database import PackageHub hub = PackageHub("mirrors") __connection__ = hub from mirrors.identity_models import * class Site(SQLObject): name = StringCol(alternateID=True) robot_email = StringCol(default=None) admin_active = BoolCol(default=False) user_active = BoolCol(default=True) private = BoolCol(default=False) admins = MultipleJoin('SiteAdmin') hosts = MultipleJoin('Host') ips = MultipleJoin('SiteIP') class SiteAdmin(SQLObject): username = StringCol() site = ForeignKey('Site') # IP addresses to go in the rsync ACLs class SiteIP(SQLObject): site = ForeignKey('Site') address = StringCol() class Host(SQLObject): name = StringCol() site = ForeignKey('Site') country = StringCol(default=None) internet2 = BoolCol(default=False) pull_from = ForeignKey('Site') mirrors = MultipleJoin('Mirror') private_rsyncs = MultipleJoin('HostPrivateRsync') ip_blocks = MultipleJoin('HostIPBlocks') # for other mirrors to pull from in tiering class HostPrivateRsync(SQLObject): host = ForeignKey('Host') url = StringCol() user = StringCol(default=None) password = StringCol(default=None) # some hosts only serve some IP CIDR blocks # such as private mirrors behind # company firewalls. This lets them first try # the global yum mirrorlist redirector which will # return them their local mirror URL class HostIPBlocks(SQLObject): host = ForeignKey('Host') cidr = StringCol() class Arch(SQLObject): name = StringCol(alternateID=True) class Content(SQLObject): # e.g. fedora-core-6-i386 name = StringCol(alternateID=True) # e.g. core, extras, updates, updates-testing, test, ... category = StringCol() # 5, 6, development version = StringCol() # default subdir starting below / # e.g. 'pub/fedora/core/6/$ARCH/' path = StringCol() canonical = StringCol() arch = ForeignKey('Arch') # these are paths below $ARCH/ # e.g. iso/, os/, debuginfo/ # of course Extras doesn't have these ;-( isos = StringCol(default=None) binarypackages = StringCol(default=None) repodata = StringCol(default=None) debuginfo = StringCol(default='debug/') repoview = StringCol(default=None) mirrors = MultipleJoin('Mirror') # one per Host per Content # fortunately these will be created/modified # by a crawler program rather than manually class Mirror(SQLObject): host = ForeignKey('Host') content = ForeignKey('Content') urls = MultipleJoin('MirrorURL') # sync status dvd_isos_synced = BoolCol(default=False) cd_isos_synced = BoolCol(default=False) binarypackages_synced = BoolCol(default=False) debuginfo_synced = BoolCol(default=False) repoview_synced = BoolCol(default=False) # One per protocol/path one can get at this same data # checking one MirrorURL is the same as checking them all class MirrorURL(SQLObject): mirror = ForeignKey('Mirror') # The equivalent of the dir structure on the masters # e.g. http://mirrors.kernel.org/fedora/core/6/i386/os/ path = StringCol(default=None) From rzarouali at gmail.com Mon Jan 8 11:09:39 2007 From: rzarouali at gmail.com (Zarouali Rachid) Date: Mon, 8 Jan 2007 12:09:39 +0100 Subject: Voting APP In-Reply-To: <1168210025.14818.159.camel@localhost.localdomain> References: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> <1168199371.14818.107.camel@localhost.localdomain> <1168210025.14818.159.camel@localhost.localdomain> Message-ID: does this require a high coding level in python ? i'm not a coder nor a high class sysadmin, but if this can be handle by a newbie in python, why not giving a try ;) Rachid On 1/7/07, Toshio Kuratomi wrote: > > On Sun, 2007-01-07 at 11:49 -0800, Toshio Kuratomi wrote: > > On Sun, 2007-01-07 at 11:40 -0600, Mike McGrath wrote: > > > Hey Toshio, how hard would it be to turn your voting app into a survey > app? > > > > > It would take a little work. But it's work that needs to be done > > anyway. Presently, the voting application only shows one issue. To be > > more generally useful (for surveys, referendum, etc) it needs to be > > enhanced to show more than one issue, either sequentially or organized > > with titles on one page. This is pretty necessary for surveys and > > somewhat useful for elections (as sooner or later we're going to want to > > run elections for two organizations at the same time.) > > Another note: The Fedora Ambassadors had a meeting and I read in their > minutes that they had a need to enhance the Voting App for things they > want to do but they never contacted me. I was planning to contact them > before enhancing the voting application. If someone else is planning to > make voting do surveys, it would probably be a good time to talk to the > Ambassadors about what their requirements are as well. > > -Toshio > > P.S. Voting is a pretty simple python cgi script at the moment. If > someone wants to get their feet wet, it would be a fun little project to > start working with. You could enhance the cgi or rewrite it with > TurboGears depending on how much work you wanted to do with it. > > > _______________________________________________ > 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 rzarouali at gmail.com Mon Jan 8 11:35:23 2007 From: rzarouali at gmail.com (Zarouali Rachid) Date: Mon, 8 Jan 2007 12:35:23 +0100 Subject: [config management] kind of survey Message-ID: Hy all, i have recently join the fedora infrastructure list, so maybe this survey would appear to you a bit odd. i have taken a deeper look at what have been discussed regarding the config management task, many of you have strong experience in different kind of tools like glump, puppet, cfengine ... but i haven't seen any checkup list on : - what's the aim of a new config management system. - how far we want this tool to manage servers config (system,services, both of them, anything else maybe ....). - system limitations (for example : no ruby tools because it has been sealed that ruby should be installed on servers ). i've seen jeff ollie has made a little wiki page listing all config management tools suggested, with pros and cons, here's my little suggestion: first : we should list : - what the new config tool should do for us - perhaps how we want this tool to work, (agent/server or something else) - system things for example : no ruby, if there an agent so it should communicate securely with his server ..... second : looking at jeff wiki's page and other solutions discussed on the list, and see if there is any tool listed there which answer all our requirements, if not then 2 choice : - take a look around and find the "right" tool - lower a little bit our requirements, so one of the tools listed would answer them (definitely the worst solution ). third: -build a test environment with the chosen tool, so everyone can play with it (the more people become familiar with it, the best it would be ;) ) fourth: - make a deployment schedule. fifth: - deploy and enjoy the work done by all people involved in ;=) here my personal view: 1) what the new config tool should do for us: this tool should help us managing system and services configurations of all fp.o servers. by managing, i mean : - building new config to deploy. - easily and smoothly updating several config - versioning all config created and/or updated how we want this tool to work: - all tasks should be done securely, agent/server tool or not. - the tool should give us some report on how tasks goes. system things: well as I'm not used on how servers are deployed , i can't really answer this point but, IMHO, whatever tool is chosen, it should not require something that may change how our systems works, this tool should be nearly invisible system view. 2) about the right tool, after looking at threads in the list archive and looking at jeff page, glump seems to be a good start 3) and 4) would come along the way after all question for 1) and 2) are settled. who's next to answer this little survey ? :) hoping this would help Rachid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Mon Jan 8 15:07:24 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 8 Jan 2007 09:07:24 -0600 Subject: Voting APP In-Reply-To: References: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> <1168199371.14818.107.camel@localhost.localdomain> <1168210025.14818.159.camel@localhost.localdomain> Message-ID: <3237e4410701080707u39ea4f97re24107e8ddf60b28@mail.gmail.com> On 1/8/07, Zarouali Rachid wrote: > does this require a high coding level in python ? > i'm not a coder nor a high class sysadmin, but if this can be handle by a > newbie in python, > why not giving a try ;) > > Rachid > You can always take a look for yourself. I think as far as a survey mechanism goes I may look at already existing projects so we can focus on keeping the voting app exactly what we initially needed it for. http://cvs.fedoraproject.org/viewcvs/fedora-vote/?root=fedora -Mike From Matt_Domsch at dell.com Mon Jan 8 22:06:23 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 8 Jan 2007 16:06:23 -0600 Subject: Mirrormanager thoughts In-Reply-To: <20070108053831.GA4396@lists.us.dell.com> References: <20070102042013.GA16518@lists.us.dell.com> <20070102190026.GA6999@lists.us.dell.com> <20070108053831.GA4396@lists.us.dell.com> Message-ID: <20070108220623.GA30513@lists.us.dell.com> On Sun, Jan 07, 2007 at 11:38:31PM -0600, Matt Domsch wrote: > https://hosted.fedoraproject.org/projects/mirrormanager/wiki/WikiStart > > I've redone the mirrormanager schema and initialization data. I > haven't redone the controllers or templates at all yet, so this won't > run except in the tg-admin shell and tg-admin toolbox (catwalk is > nice). Please take a look. I append the schema file for review. The > hierarchy is as follows: More schema updates. Three new objects. Product is a top-level content name, e.g. 'rhel' or 'fedora'. Products can have many ProductVersions. Some versions are 'test' versions (e.g. 6.90). This needed as the path to fedora-test-6.90 looks like fedora/linux/core/test/6.90/ while the path to fedora-core-6 looks like fedora/linux/core/6/ (the extra 'test' indirection there...) Category is meant to be able to capture the standard directory structure for 'core', 'extras', 'updates', 'updates-testing', 'test', and 'epel' cleanly. It uses $VERSION and $ARCH in the path names to be replaced when creating a Content. > Content is the highest level unit of data that can be synced. Content refers to the combination of a Category, a ProductVersion, and an Arch, and is still the highest level unit of data that can be synced. These have names like fedora-core-6-i386. (product, category, version, arch). The other objects are unchanged fundamentally. Your comments would be appreciated. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com from sqlobject import * from turbogears.database import PackageHub hub = PackageHub("mirrors") __connection__ = hub from mirrors.identity_models import * class Site(SQLObject): name = StringCol(alternateID=True) robot_email = StringCol(default=None) admin_active = BoolCol(default=False) user_active = BoolCol(default=True) private = BoolCol(default=False) admins = MultipleJoin('SiteAdmin') hosts = MultipleJoin('Host') ips = MultipleJoin('SiteIP') class SiteAdmin(SQLObject): username = StringCol() site = ForeignKey('Site') # IP addresses to go in the rsync ACLs class SiteIP(SQLObject): site = ForeignKey('Site') address = StringCol() class Host(SQLObject): name = StringCol() site = ForeignKey('Site') country = StringCol(default=None) internet2 = BoolCol(default=False) pull_from = ForeignKey('Site') mirrors = MultipleJoin('Mirror') private_rsyncs = MultipleJoin('HostPrivateRsync') ip_blocks = MultipleJoin('HostIPBlocks') # for other mirrors to pull from in tiering class HostPrivateRsync(SQLObject): host = ForeignKey('Host') url = StringCol() user = StringCol(default=None) password = StringCol(default=None) # some hosts only serve some IP CIDR blocks # such as private mirrors behind # company firewalls. This lets them first try # the global yum mirrorlist redirector which will # return them their local mirror URL class HostIPBlocks(SQLObject): host = ForeignKey('Host') cidr = StringCol() class Arch(SQLObject): name = StringCol(alternateID=True) class Category(SQLObject): # e.g. core, extras, updates, updates-testing, test, ... name = StringCol(alternateID=True) # with $VERSION and $ARCH for later substitution path = StringCol() canonicalhost = StringCol() sourcepkgpath = StringCol() sourceisopath = StringCol(default=None) contents = MultipleJoin('Content') class Product(SQLObject): name = StringCol(alternateID=True) versions = MultipleJoin('ProductVersion') class ProductVersion(SQLObject): name = StringCol() product = ForeignKey('Product') isTest = BoolCol(default=False) class Content(SQLObject): # e.g. fedora-core-6-i386 name = StringCol(alternateID=True) category = ForeignKey('Category') # 5, 6, development version = ForeignKey('ProductVersion') # default subdir starting below / # e.g. 'pub/fedora/core/6/$ARCH/' path = StringCol() arch = ForeignKey('Arch') # these are paths below $ARCH/ # e.g. iso/, os/, debuginfo/ # of course Extras doesn't have these ;-( isos = StringCol(default=None) binarypackages = StringCol(default=None) repodata = StringCol(default=None) debuginfo = StringCol(default='debug/') repoview = StringCol(default=None) mirrors = MultipleJoin('Mirror') # one per Host per Content # fortunately these will be created/modified # by a crawler program rather than manually class Mirror(SQLObject): host = ForeignKey('Host') content = ForeignKey('Content') urls = MultipleJoin('MirrorURL') # sync status dvd_isos_synced = BoolCol(default=False) cd_isos_synced = BoolCol(default=False) binarypackages_synced = BoolCol(default=False) debuginfo_synced = BoolCol(default=False) repoview_synced = BoolCol(default=False) # One per protocol/path one can get at this same data # checking one MirrorURL is the same as checking them all class MirrorURL(SQLObject): mirror = ForeignKey('Mirror') # The equivalent of the dir structure on the masters # e.g. http://mirrors.kernel.org/fedora/core/6/i386/os/ path = StringCol(default=None) From mmcgrath at fedoraproject.org Tue Jan 9 16:34:43 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 9 Jan 2007 10:34:43 -0600 Subject: FI Future Message-ID: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> As many of you know I have been hired on to work on Fedora Infrastructure full time. This will be a great thing for our group. Initially I'll be spending a lot of time getting our house in order and fixing a lot of those little things that we keep putting off. Many of the mid term goals we've already talked about and are on the Schedule page. I'd like to hear the communities ideas now that we have a dedicated resource (me). I'm especially interested in things that will help other teams do what they need to do. Like how to not screw the doc's guys during the next release or better empowering sponsors. Encouraging new volunteers to come and volunteer management / coordination is also something we need to address soon, we're growing quite quickly. With these things in mind try not to think specifically about our infrastructure team but about the project as a whole and how we can aid the community to thrive. I'll officially be starting the first week in Feburary and will be looking for ways to expand our infrastructure both in Red Hat and outside of Red Hat, perhaps by finding partnership in an additional University. As long as we're smart about what we commit to, I have no doubt that we'll be able to provide the community with everything they need. -Mike From laroche at redhat.com Tue Jan 9 16:37:47 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 9 Jan 2007 17:37:47 +0100 Subject: FI Future In-Reply-To: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> References: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> Message-ID: <20070109163747.GA1694@dudweiler.stuttgart.redhat.com> Hello Mike, Congrats and a welcome to Red Hat. I'll look forward to have FI expand... regards, Florian La Roche On Tue, Jan 09, 2007 at 10:34:43AM -0600, Mike McGrath wrote: > As many of you know I have been hired on to work on Fedora > Infrastructure full time. This will be a great thing for our group. > Initially I'll be spending a lot of time getting our house in order > and fixing a lot of those little things that we keep putting off. > Many of the mid term goals we've already talked about and are on the > Schedule page. > > I'd like to hear the communities ideas now that we have a dedicated > resource (me). I'm especially interested in things that will help > other teams do what they need to do. Like how to not screw the doc's > guys during the next release or better empowering sponsors. > Encouraging new volunteers to come and volunteer management / > coordination is also something we need to address soon, we're growing > quite quickly. With these things in mind try not to think > specifically about our infrastructure team but about the project as a > whole and how we can aid the community to thrive. > > I'll officially be starting the first week in Feburary and will be > looking for ways to expand our infrastructure both in Red Hat and > outside of Red Hat, perhaps by finding partnership in an additional > University. As long as we're smart about what we commit to, I have no > doubt that we'll be able to provide the community with everything they > need. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From jeff at ocjtech.us Tue Jan 9 17:33:55 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 09 Jan 2007 11:33:55 -0600 Subject: FI Future In-Reply-To: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> References: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> Message-ID: <1168364035.3578.53.camel@lt21223.campus.dmacc.edu> On Tue, 2007-01-09 at 10:34 -0600, Mike McGrath wrote: > > I'd like to hear the communities ideas now that we have a dedicated > resource (me). I'm especially interested in things that will help > other teams do what they need to do. Like how to not screw the doc's > guys during the next release or better empowering sponsors. > Encouraging new volunteers to come and volunteer management / > coordination is also something we need to address soon, we're growing > quite quickly. With these things in mind try not to think > specifically about our infrastructure team but about the project as a > whole and how we can aid the community to thrive. A couple of ideas that I've had floating around my mind for a while: Having more Bittorrent seeds for the ISO downloads available on release day. This should make bittorrent a much more attractive download option for users and should relieve the strain on the regular mirrors. What I'd suggest is that some trusted members of the community be set up with early access to the bittorrent trackers so that they can get a local copy of the ISOs and can then be seeds for the general public. This wouldn't need to be a long-term commitment of resources - perhaps 2-3 days before the release day, and then a week or so after release. A few more secondary DNS servers for fedoraproject.org. Again, I'm sure that trusted members of the community would step up to provide the secondary DNS servers. Perhaps DNSSEC should be investigated to make doubly sure that the DNS data isn't messed with. Of course, this would be a long-term committment but shouldn't be very resource-intensive. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rzarouali at gmail.com Tue Jan 9 17:46:51 2007 From: rzarouali at gmail.com (Zarouali Rachid) Date: Tue, 9 Jan 2007 18:46:51 +0100 Subject: FI Future In-Reply-To: <1168364035.3578.53.camel@lt21223.campus.dmacc.edu> References: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> <1168364035.3578.53.camel@lt21223.campus.dmacc.edu> Message-ID: > > Having more Bittorrent seeds for the ISO downloads available on release > day. This should make bittorrent a much more attractive download option > for users and should relieve the strain on the regular mirrors. What > I'd suggest is that some trusted members of the community be set up with > early access to the bittorrent trackers so that they can get a local > copy of the ISOs and can then be seeds for the general public. This > wouldn't need to be a long-term commitment of resources - perhaps 2-3 > days before the release day, and then a week or so after release. > > A few more secondary DNS servers for fedoraproject.org. Again, I'm > sure that trusted members of the community would step up to provide the > secondary DNS servers. Perhaps DNSSEC should be investigated to make > doubly sure that the DNS data isn't messed with. Of course, this would > be a long-term committment but shouldn't be very resource-intensive. > > i'm working for the french cctld registry, maybe i can ask here if the two or only of these suggestions can be handle here mike ? what do you think ? Rachid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Tue Jan 9 20:19:01 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 9 Jan 2007 14:19:01 -0600 Subject: FI Future In-Reply-To: References: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> <1168364035.3578.53.camel@lt21223.campus.dmacc.edu> Message-ID: <3237e4410701091219w34853a7aw9f7a9da986dca401@mail.gmail.com> On 1/9/07, Zarouali Rachid wrote: > > > Having more Bittorrent seeds for the ISO downloads available on release > > day. This should make bittorrent a much more attractive download option > > for users and should relieve the strain on the regular mirrors. What > > I'd suggest is that some trusted members of the community be set up with > > early access to the bittorrent trackers so that they can get a local > > copy of the ISOs and can then be seeds for the general public. This > > wouldn't need to be a long-term commitment of resources - perhaps 2-3 > > days before the release day, and then a week or so after release. This is doable but will require a partner seeder and some coordination. We have in the past had issues actually getting the initial media out to where it needs to go. > > A few more secondary DNS servers for fedoraproject.org. Again, I'm > > sure that trusted members of the community would step up to provide the > > secondary DNS servers. Perhaps DNSSEC should be investigated to make > > doubly sure that the DNS data isn't messed with. Of course, this would > > be a long-term committment but shouldn't be very resource-intensive. We do have a primary and slave DNS server, the issue will be security. Who do we trust to do this, right now the primary is at Duke and the backup is with Jesse Keating (f13). > i'm working for the french cctld registry, > maybe i can ask here if the two or only of these suggestions can be handle > here > mike ? what do you think ? We can certainly look into that. What would it take, what do we risk and what do we gain? -Mike From Matt_Domsch at dell.com Tue Jan 9 21:12:33 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 9 Jan 2007 15:12:33 -0600 Subject: FI Future In-Reply-To: References: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> <1168364035.3578.53.camel@lt21223.campus.dmacc.edu> Message-ID: <20070109211233.GA15132@lists.us.dell.com> On Tue, Jan 09, 2007 at 06:46:51PM +0100, Zarouali Rachid wrote: > Having more Bittorrent seeds for the ISO downloads available on release > day. This should make bittorrent a much more attractive download option > for users and should relieve the strain on the regular mirrors. What > I'd suggest is that some trusted members of the community be set up with > early access to the bittorrent trackers so that they can get a local > copy of the ISOs and can then be seeds for the general public. This > wouldn't need to be a long-term commitment of resources - perhaps 2-3 > days before the release day, and then a week or so after release. We can ask our normal mirrors if they would like to seed. Would need a little script they could run to hardlink the rsync trees into the bittorrent trees so we don't pull it twice. Seth, can we have a "private" tracker that is later made "public" ? I'm not that familiar with bittorrent. I suspect that's security-through-obscurity though - anyone who finds the tracker could hop on. We do have 55 formal mirrors, each serving some subset of {http,ftp,rsync}, and if have a sane embargo window of say 3 days, that's sufficient to get all of those synced. Any less time and we cap out the master servers' bandwidths and not everyone gets synced before the release. If we're going to add early bittorrent seeders (e.g. not just the above mirrors), they would need to have fairly significant bandwidth at their disposal (e.g. larger than a DSL/Cable modem line). And we may need more embargo time to get them distributed. Would be interesting to try with say test2 and test3 rather than starting it only at the final release. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From skvidal at linux.duke.edu Tue Jan 9 21:21:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 09 Jan 2007 16:21:11 -0500 Subject: FI Future In-Reply-To: <20070109211233.GA15132@lists.us.dell.com> References: <3237e4410701090834m2533b0ackef06e93ed45ff7ae@mail.gmail.com> <1168364035.3578.53.camel@lt21223.campus.dmacc.edu> <20070109211233.GA15132@lists.us.dell.com> Message-ID: <1168377671.6566.50.camel@cutter> On Tue, 2007-01-09 at 15:12 -0600, Matt Domsch wrote: > On Tue, Jan 09, 2007 at 06:46:51PM +0100, Zarouali Rachid wrote: > > Having more Bittorrent seeds for the ISO downloads available on release > > day. This should make bittorrent a much more attractive download option > > for users and should relieve the strain on the regular mirrors. What > > I'd suggest is that some trusted members of the community be set up with > > early access to the bittorrent trackers so that they can get a local > > copy of the ISOs and can then be seeds for the general public. This > > wouldn't need to be a long-term commitment of resources - perhaps 2-3 > > days before the release day, and then a week or so after release. > > We can ask our normal mirrors if they would like to seed. Would need > a little script they could run to hardlink the rsync trees into the > bittorrent trees so we don't pull it twice. > > Seth, can we have a "private" tracker that is later made "public" ? > I'm not that familiar with bittorrent. I suspect that's > security-through-obscurity though - anyone who finds the tracker could > hop on. you'd be correct. We've talked about doing this before and it's been a nightmare. it would be far better > > We do have 55 formal mirrors, each serving some subset of > {http,ftp,rsync}, and if have a sane embargo window of say 3 days, > that's sufficient to get all of those synced. Any less time and we > cap out the master servers' bandwidths and not everyone gets synced > before the release. and none of them have the isos in the layout we have them for the torrent. zero. > If we're going to add early bittorrent seeders (e.g. not just the > above mirrors), they would need to have fairly significant bandwidth > at their disposal (e.g. larger than a DSL/Cable modem line). And we > may need more embargo time to get them distributed. Would be > interesting to try with say test2 and test3 rather than starting it > only at the final release. If you want bittorrent seeders you'd be better off having them just be random mirrors who want to participate and can sync down the data in advance from the torrent. However, I'd suggest that this is silly. If only b/c we've not gotten any reliable complaints about problems with performance in the torrent. -sv From a.badger at gmail.com Tue Jan 9 23:44:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Jan 2007 15:44:34 -0800 Subject: Voting APP In-Reply-To: <3237e4410701080707u39ea4f97re24107e8ddf60b28@mail.gmail.com> References: <3237e4410701070940i11a2f91cxa298fb87f9643c7b@mail.gmail.com> <1168199371.14818.107.camel@localhost.localdomain> <1168210025.14818.159.camel@localhost.localdomain> <3237e4410701080707u39ea4f97re24107e8ddf60b28@mail.gmail.com> Message-ID: <1168386274.4180.56.camel@localhost.localdomain> On Mon, 2007-01-08 at 09:07 -0600, Mike McGrath wrote: > On 1/8/07, Zarouali Rachid wrote: > > does this require a high coding level in python ? > > i'm not a coder nor a high class sysadmin, but if this can be handle by a > > newbie in python, > > why not giving a try ;) > > > > Rachid > > > > You can always take a look for yourself. I think as far as a survey > mechanism goes I may look at already existing projects so we can focus > on keeping the voting app exactly what we initially needed it for. > I'm not sure what exactly you're looking for but if you want something that's going to authenticate to the Fedora Account System, it probably would be good to either extend or rewrite the voting application to meet your additional needs. Like I say, the Voting App needs a revamp. When we put together the vote app, there wasn't much out there that we really felt was suitable for our needs as a secure voting system. I don't know that you need the same kind of rigor for a survey, though. I also have some pygtk code for a ballot that I was playing with prior to spot throwing the cgi script out there in case you decide you want to code your own desktop survey app. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu Jan 11 14:55:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Jan 2007 06:55:23 -0800 Subject: Missing part of meeting Message-ID: <1168527323.4545.31.camel@localhost.localdomain> Hey guys, I'll be missing at least the first part of the meeting this week and next. I'll catch up in the logs. I'm working on connecting from the packagedb to the account system right now. I'll send more details when I have something that works as I'm sure lmacken will want some of it for the update system :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Thu Jan 11 19:28:36 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 11 Jan 2007 11:28:36 -0800 Subject: updates tool Message-ID: <45A68FE4.3030209@redhat.com> Hi, I'm trying to get up to speed with how the updates tool works and what it does. I followed the instructions on this page http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem and downloaded the source from CVS. After that I followed the instructions in the README to configure and install. The README was very detailed and helpful! Is there more documentation on how to use the tool now that I have it installed and greater context on how it all goes together? The last part of the README says: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Running the updates system test suite ===================================== All tests are stored in the 'tests' module in this project, and can be run by executing the command `nosetests` in top level of the project. For more information on Nose unit tests, please see: http://somethingaboutorange.com/mrl/projects/nose/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0) I confess I have limited knowledge of python and have never used 'nose.' 1) What is meant by a "project" when it says to execute the `nosetests` command in the top level of "the project?" 2) Is there a UI and if so how do I navigate to it? Thanks, John From lmacken at redhat.com Fri Jan 12 03:01:44 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 11 Jan 2007 22:01:44 -0500 Subject: updates tool In-Reply-To: <45A68FE4.3030209@redhat.com> References: <45A68FE4.3030209@redhat.com> Message-ID: <20070112030144.GB23028@tomservo.rh.rit.edu> On Thu, Jan 11, 2007 at 11:28:36AM -0800, John Poelstra wrote: > Hi, > > I'm trying to get up to speed with how the updates tool works and what it > does. > > I followed the instructions on this page > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem and downloaded > the source from CVS. After that I followed the instructions in the README > to configure and install. The README was very detailed and helpful! That's good to hear! > Is there more documentation on how to use the tool now that I have it > installed and greater context on how it all goes together? The last part > of the README says: Nope, not yet. I'm still neck deep in the code, and working on putting all of the pieces together still to get minimum functionality so we can actually start using it. I'll hopefully throw some more useful docs together once I get a free second away from the code and school work. For now, after following the README, you will be setup with a development environment and a local SQLite database. As far as configuration, `updatessystem/config/app.cfg` contains all of the global config options, and should be fine for testing by default (it won't send out emails and such, as I have that commented out at the moment). >From here `./start-updatessystem` will bring up the system, in which you can interact with by going to http://localhost:8080 All the tool needs to function properly is a directory of built packages (package/version/release/arch format at the moment), which defaults to the 'test-build' directory at the top level of the project. Ideally, we will be able to point the tool at the output from any buildsystem, and it should Just Work. When you go to the 'New update' form, and type in the package name, the system will automagically present you with a list of available package-version-release's to choose from. Once a package is added, and submitted for pushing, an admin[0] is then able to push them out to the updates-stage. > Running the updates system test suite > ===================================== > > All tests are stored in the 'tests' module in this project, and can be > run by executing the command `nosetests` in top level of the project. > > For more information on Nose unit tests, please see: > > http://somethingaboutorange.com/mrl/projects/nose/ > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 0) I confess I have limited knowledge of python and have never used 'nose.' > > 1) What is meant by a "project" when it says to execute the `nosetests` > command in the top level of "the project?" > > 2) Is there a UI and if so how do I navigate to it? python-nose is just a simple "discovery-based unittest extension" that TurboGears can use to test the application itself. It pretty much goes through the project looking for classess and functions beginning with 'test' and executes them. What's awesome is that combined with TurboGears, you can easily define tests that will automatically get run on a clean SQLite database in memory, just by simply inheriting from a DBTest class. Right now most of the tests will probably fail, as I have been making large changes to the project, and have not gotten a chance to update the test cases. I'm presently working on polishing up the push code, and getting basic functionality working in a public test environment. Hopefully this weekend I'll have something public that people can prod with. If you've got any more questions, please ask :) luke [0]: To add yourself as an admin, type 'tg-admin shell' in the top level of the updates system directory and type: >>> me = User.get(1) >>> admin = Group.get(1) >>> me.addGroup(admin) Then ^D, save the db, changes, and you should be good to go. Now you should have access to Pushing and Unpushing updates, as well as TurboGears's CatWalk database tool (all of which will now be displayed for you on the tool) From jkeating at redhat.com Fri Jan 12 03:18:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Jan 2007 22:18:54 -0500 Subject: Future plans of the hosting project Message-ID: <200701112218.54291.jkeating@redhat.com> As per the meeting, these are the things I think we need to do to further the Fedora Hosted Project. 1) Move the hosted git/hg/svn off to another system. Ideally we'd have a dedicated system (perhaps in another colo) that is beefy enough to run a few xen guests. One for each SCM (so that sane configs can be done for web and such), one for Trac itself, one for users to log in and fiddle with raw webspace, and finally one to run apache and serve up the raw webspace. The same storage space could be used for all of these things, so that we don't have to guess at disk size, just make directories and NFS mount them at appropriate places in the guests. 2) Get raw webspace working. Ideally there would be a guest that users log into and be able to fiddle with content in a subdir of their homedir or something. Someway to keep folks locked out of eachother's webspaces and the rest of the system would be good, maybe we have to limit ssh to just sftp and scp and ssh rsync to begin with, dunno. Another guest would actually serve up the content so that no user could log into that box. Some quotas would be in effect to keep a luser from DoSing the box by running it out of space. Raw webspace could be in the flavor of "projectname.hosted.fedoraproject.org" for ease of name based virtual hosting. Sourceforge does this too, sf.net/projects/ for the sf interface, .sf.net for the webspace. Seems to work fairly well. 3) A web tool for admins to create a new project space. Would involve A) creating trac space and setting appropriate admin B) creating fedora account group for SCM repo C) creating SCM repo, setting permissions D) creating raw webspace and DNS hostname And finally 4) some art love to create a nice template for Trac to use other than the default Trac. Something with Fedora branding and nice looking icons/colors and all that fun stuff. There could be room here for "powered by" type images if some company steps up to donate the system/storage for this, as well as a University logo should we get hosting from a Uni. Wild ass guessing, I'd think that 1TB of storage would be more than plenty to last us a while, for all of hosted SCM and webspace, and Trac data. Eventually we could split things out like the raw webspace or SCMs or whatever if something starts to eat more space. As for a single box to run a bunch of guests, I don't know how well this scales, would be worth testing I guess. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nils at breun.nl Fri Jan 12 10:27:17 2007 From: nils at breun.nl (Nils Breunese) Date: Fri, 12 Jan 2007 11:27:17 +0100 Subject: Future plans of the hosting project In-Reply-To: <200701112218.54291.jkeating@redhat.com> References: <200701112218.54291.jkeating@redhat.com> Message-ID: <42A5F15A-0B5B-451E-B794-03E7306DC26D@breun.nl> Jesse Keating wrote: > 2) Get raw webspace working. Ideally there would be a guest that > users log > into and be able to fiddle with content in a subdir of their > homedir or > something. Someway to keep folks locked out of eachother's > webspaces and the > rest of the system would be good, maybe we have to limit ssh to > just sftp and > scp and ssh rsync to begin with, dunno. Another guest would > actually serve > up the content so that no user could log into that box. Some > quotas would be > in effect to keep a luser from DoSing the box by running it out of > space. > Raw webspace could be in the flavor of > "projectname.hosted.fedoraproject.org" > for ease of name based virtual hosting. Sourceforge does this too, > sf.net/projects/ for the sf interface, > .sf.net for > the webspace. Seems to work fairly well. > > 3) A web tool for admins to create a new project space. Would involve > A) creating trac space and setting appropriate admin > B) creating fedora account group for SCM repo > C) creating SCM repo, setting permissions > D) creating raw webspace and DNS hostname Project admins will need shell access to be able to use the trac- admin tool to setup Trac to their liking. A lot of Trac configuration cannot be done through the web interface. Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From jkeating at redhat.com Fri Jan 12 12:47:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Jan 2007 07:47:31 -0500 Subject: Future plans of the hosting project In-Reply-To: <42A5F15A-0B5B-451E-B794-03E7306DC26D@breun.nl> References: <200701112218.54291.jkeating@redhat.com> <42A5F15A-0B5B-451E-B794-03E7306DC26D@breun.nl> Message-ID: <200701120747.35416.jkeating@redhat.com> On Friday 12 January 2007 05:27, Nils Breunese wrote: > Project admins will need shell access to be able to use the trac- > admin tool to setup Trac to their liking. A lot of Trac configuration ? > cannot be done through the web interface. Actually most of their needs are serviced by the webadmin plugin. http://trac.edgewall.org/wiki/WebAdmin Other than creating the trac instance, I have not needed to revert to the shell for any of the administrative stuff for my pungi project space. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nils at breun.nl Fri Jan 12 12:57:03 2007 From: nils at breun.nl (Nils Breunese) Date: Fri, 12 Jan 2007 13:57:03 +0100 Subject: Future plans of the hosting project In-Reply-To: <200701120747.35416.jkeating@redhat.com> References: <200701112218.54291.jkeating@redhat.com> <42A5F15A-0B5B-451E-B794-03E7306DC26D@breun.nl> <200701120747.35416.jkeating@redhat.com> Message-ID: <31AA6642-720E-4296-AAF4-D31262C72562@breun.nl> Op 12-jan-2007, om 13:47 heeft Jesse Keating het volgende geschreven: > On Friday 12 January 2007 05:27, Nils Breunese wrote: >> Project admins will need shell access to be able to use the trac- >> admin tool to setup Trac to their liking. A lot of Trac configuration >> cannot be done through the web interface. > > Actually most of their needs are serviced by the webadmin plugin. > http://trac.edgewall.org/wiki/WebAdmin > > Other than creating the trac instance, I have not needed to revert > to the > shell for any of the administrative stuff for my pungi project space. Ah, I didn't know about that one. I see it will be incorporated into Trac 0.11. Nice. Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Dit deel van het bericht is digitaal ondertekend URL: From mmcgrath at fedoraproject.org Fri Jan 12 14:26:27 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 12 Jan 2007 08:26:27 -0600 Subject: Future plans of the hosting project In-Reply-To: <200701112218.54291.jkeating@redhat.com> References: <200701112218.54291.jkeating@redhat.com> Message-ID: <3237e4410701120626j4f121e51y404148a7bf369dfb@mail.gmail.com> On 1/11/07, Jesse Keating wrote: > As per the meeting, these are the things I think we need to do to further the > Fedora Hosted Project. > > 1) Move the hosted git/hg/svn off to another system. Ideally we'd have a > dedicated system (perhaps in another colo) that is beefy enough to run a few > xen guests. One for each SCM (so that sane configs can be done for web and > such), one for Trac itself, one for users to log in and fiddle with raw > webspace, and finally one to run apache and serve up the raw webspace. The > same storage space could be used for all of these things, so that we don't > have to guess at disk size, just make directories and NFS mount them at > appropriate places in the guests. I think this is doable but probably a mid to long term goal. Perhaps we should figure something out in the meantime so that when push comes to shove we can actually say "we need to move this" if we don't find any suiters out there to volunteer their facilities. > 2) Get raw webspace working. Ideally there would be a guest that users log > into and be able to fiddle with content in a subdir of their homedir or > something. Someway to keep folks locked out of eachother's webspaces and the > rest of the system would be good, maybe we have to limit ssh to just sftp and > scp and ssh rsync to begin with, dunno. Another guest would actually serve > up the content so that no user could log into that box. Some quotas would be > in effect to keep a luser from DoSing the box by running it out of space. > Raw webspace could be in the flavor of "projectname.hosted.fedoraproject.org" > for ease of name based virtual hosting. Sourceforge does this too, > sf.net/projects/ for the sf interface, .sf.net for > the webspace. Seems to work fairly well. doable > 3) A web tool for admins to create a new project space. Would involve > A) creating trac space and setting appropriate admin > B) creating fedora account group for SCM repo > C) creating SCM repo, setting permissions > D) creating raw webspace and DNS hostname I'd even be fine with this working similar to the extras branching process though I know the idea is to let anyone go in there and do whatever. We'll end up with a lot of this kind of thing: http://sourceforge.net/projects/bwres/ (an early attempt at OSS from me back in 2002. haven't done anything with it :-( > 4) some art love to create a nice template for Trac to use other than the > default Trac. Something with Fedora branding and nice looking icons/colors > and all that fun stuff. There could be room here for "powered by" type > images if some company steps up to donate the system/storage for this, as > well as a University logo should we get hosting from a Uni. Up to the web folks. I hear there's many people ready to help. I've been lazy about asking them for kid templates. > Wild ass guessing, I'd think that 1TB of storage would be more than plenty to > last us a while, for all of hosted SCM and webspace, and Trac data. > Eventually we could split things out like the raw webspace or SCMs or > whatever if something starts to eat more space. As for a single box to run a > bunch of guests, I don't know how well this scales, would be worth testing I > guess. If we do stick 1TB somewhere non-phx, we'll need a backup solution. Probably on site. -Mike From email.ahmedkamal at googlemail.com Fri Jan 12 20:01:59 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 12 Jan 2007 22:01:59 +0200 Subject: Yum deltarpm Message-ID: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> Hi, I'm interested in adding deltarpm support to yum in the fedora updates infrastructure. There's already a yum plugin written by a redhat developer, so we have something to start from. I have contacted the developer, and he has no problem helping us move along. Benefits: ======= 1- Clients download faster updates. The README says drpm based update infrastructure can reduce required bandwidth to about 20% on the average 2- Also, from the server side, this should decrease our bandwidth requirements, and free the servers quickly to handle other users Notes ===== 1- The code currently expects redhat satellite server file system hierarchy, so it will need some cleaning/polishing 2- Currently, the server side stores *all* updates issued, when a client requests updating, the server generates an *appropriate* drpm, which the client can download. This has the disadvantages of storing all updates ever released on the server, and also, running active code on the server might not be welcome by mirrors I imagine. This is a current problem! 3- As a solution to that problem, I am proposing we statically (cron-job) generate drpms only for the newest updates. That way we will be serving the majority of users drpms. We will also get rid of having to generate drpms on the fly. The only thing we loose, is if someone is slow to update his system, he won't be benefiting much from the system. Practically, I think the benefits outweigh the cons. What do you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Sat Jan 13 16:10:04 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sat, 13 Jan 2007 10:10:04 -0600 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> Message-ID: <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> On 1/12/07, Ahmed Kamal wrote: > Benefits: > ======= > 1- Clients download faster updates. The README says drpm based update > infrastructure can reduce required bandwidth to about 20% on the average > 2- Also, from the server side, this should decrease our bandwidth > requirements, and free the servers quickly to handle other users > Anything that makes the end user experience better sounds good to me. My questions are, what does it take on our end? And does it require the mirrors to be altered in any way? -Mike From a.badger at gmail.com Sat Jan 13 17:28:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 13 Jan 2007 09:28:41 -0800 Subject: Yum deltarpm In-Reply-To: <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> Message-ID: <1168709321.24970.85.camel@localhost.localdomain> On Sat, 2007-01-13 at 10:10 -0600, Mike McGrath wrote: > On 1/12/07, Ahmed Kamal wrote: > > Benefits: > > ======= > > 1- Clients download faster updates. The README says drpm based update > > infrastructure can reduce required bandwidth to about 20% on the average > > 2- Also, from the server side, this should decrease our bandwidth > > requirements, and free the servers quickly to handle other users > > > > Anything that makes the end user experience better sounds good to me. > My questions are, what does it take on our end? And does it require > the mirrors to be altered in any way? Is the 20% for something that applies to the rpms or something that applies directly to the filesystem? I'm not too keen on the filesystem approach although I hear it can really improve the speed. Patching the rpms would be nice... but does require keeping old versions of the rpms on the end-user's disk. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Jan 13 18:21:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 13 Jan 2007 10:21:25 -0800 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> Message-ID: <1168712485.24970.100.camel@localhost.localdomain> On Sat, 2007-01-13 at 19:42 +0200, Ahmed Kamal wrote: > not sure I understand your question, but they way things should go is, > the client downloads the drpm, client side code combines client side > files from older rpm + the drpm into a new rpm. Then that new rpm is > installed. The required bandwidth should drop to 20%, the numbers need > some testing ofcourse, but I can imagine such savings. > SuSE did a lot of work on distributing the files as less than a whole rpm. Their original tool works as you say, with an "rpm patch file" that combines with an rpm on the client's system which is then installed. The newer tool that they were pushing a couple years ago was also able to upgrade files on the filesystem rather than going through the intermediate step of creating an rpm. I consider this method to be less desirable from a security standpoint than the first. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From email.ahmedkamal at googlemail.com Sat Jan 13 18:40:38 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 13 Jan 2007 20:40:38 +0200 Subject: Yum deltarpm In-Reply-To: <1168712485.24970.100.camel@localhost.localdomain> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> Message-ID: <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> FYI, this yum deltarpm support, is based on that same deltarpm package that is made by suse. This suse package can create new rpms from drpm + (either ondisk files, or old rpm). Either way, a new rpm is created, then installed. Never does it replace files directly. Not sure why this would be bad security wise Hey, why do emails appear to come from the sender, not the FI list. I always hit reply, and end up replying to the original author only! :) On 1/13/07, Toshio Kuratomi wrote: > > On Sat, 2007-01-13 at 19:42 +0200, Ahmed Kamal wrote: > > not sure I understand your question, but they way things should go is, > > the client downloads the drpm, client side code combines client side > > files from older rpm + the drpm into a new rpm. Then that new rpm is > > installed. The required bandwidth should drop to 20%, the numbers need > > some testing ofcourse, but I can imagine such savings. > > > SuSE did a lot of work on distributing the files as less than a whole > rpm. Their original tool works as you say, with an "rpm patch file" > that combines with an rpm on the client's system which is then > installed. The newer tool that they were pushing a couple years ago was > also able to upgrade files on the filesystem rather than going through > the intermediate step of creating an rpm. I consider this method to be > less desirable from a security standpoint than the first. > > -Toshio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Sat Jan 13 19:15:17 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 13 Jan 2007 20:15:17 +0100 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> Message-ID: <20070113201517.89ecd26e.bugs.michael@gmx.net> On Sat, 13 Jan 2007 20:40:38 +0200, Ahmed Kamal wrote: > Hey, why do emails appear to come from the sender, not the FI list. I always > hit reply, and end up replying to the original author only! :) Because ReplyTo is not set, and with Google Mail you then need to click "Reply to all". From dennis at ausil.us Sat Jan 13 20:06:00 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 13 Jan 2007 14:06:00 -0600 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> Message-ID: <200701131406.01077.dennis@ausil.us> On Saturday 13 January 2007 12:40 pm, Ahmed Kamal wrote: > FYI, this yum deltarpm support, is based on that same deltarpm package that > is made by suse. This suse package can create new rpms from drpm + (either > ondisk files, or old rpm). Either way, a new rpm is created, then > installed. Never does it replace files directly. Not sure why this would be > bad security wise I personally don't like the idea of binary delta's there are too many variables with them and too much overhead. for instance say we update cups 4 times during the life of a release. that means we need to create 4 delta's as the end user can have 4 possible states of the package. Windows has always done delta's and for the longest time they only provided delta's from the latest version. which is the reason you had to update a ton of times to get to the latest version. that has changed but its not http://www.directionsonmicrosoft.com/sample/DOMIS/update/2005/02feb/0205fsuttc.htm Apple also provides delta's but they do only deltas from the previous version to latest if you you have an older version you have to get the full version. most packages are so small that i don't think the overhead is worth the pain. OOo and a couple of others i could see maybe, but otherwise I personally don't think its a good idea. It means mirrors need to carry more data. -- Dennis Gilmore, RHCE Proud Australian From a.badger at gmail.com Sat Jan 13 21:46:45 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 13 Jan 2007 13:46:45 -0800 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> Message-ID: <1168724805.24970.116.camel@localhost.localdomain> On Sat, 2007-01-13 at 20:40 +0200, Ahmed Kamal wrote: > FYI, this yum deltarpm support, is based on that same deltarpm package > that is made by suse. This suse package can create new rpms from drpm > + (either ondisk files, or old rpm). Either way, a new rpm is created, > then installed. Never does it replace files directly. Not sure why > this would be bad security wise It's the construction of the rpm from ondisk files that I don't like. You lose the ability to sign the rpm that you're installing. Patching an older rpm is a safer transformation. I just googled and found an August post to yum-devel about what I think is this plugin: https://lists.dulug.duke.edu/pipermail/yum-devel/2006-August/002385.html Is this right? Is there more recent code? It looks like that code is tied into up2date so it wouldn't help Fedora users much. It also needs a server side which implies the mirrors would have to run additional software to make it functional.... -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From email.ahmedkamal at googlemail.com Sat Jan 13 22:03:45 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 14 Jan 2007 00:03:45 +0200 Subject: Yum deltarpm In-Reply-To: <200701131406.01077.dennis@ausil.us> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> Message-ID: <3da3b5b40701131403s5ea19bf5r3e4e3298d53db761@mail.gmail.com> I don't like tracking different update states too, which is why I was suggesting previous-to-latest only drpms. Guess like what apple does. It's not easy for me to determine whether users will like such a feature. Most casual linux users I meet, are not keen on updating their systems. And when they finally decide to, they don't want to download lots of megabytes. One more scenario I could think of, is users in developing countries like mine, where broadband is rare. Deltas make a lot of sense on a modem (tell me about it a few years ago). Anyway, if most of you don't think this is worth the effort, let me know about it. Any idea if OLPC has implemented implemented something similar ? On 1/13/07, Dennis Gilmore wrote: > > On Saturday 13 January 2007 12:40 pm, Ahmed Kamal wrote: > > FYI, this yum deltarpm support, is based on that same deltarpm package > that > > is made by suse. This suse package can create new rpms from drpm + > (either > > ondisk files, or old rpm). Either way, a new rpm is created, then > > installed. Never does it replace files directly. Not sure why this would > be > > bad security wise > > I personally don't like the idea of binary delta's there are too many > variables with them and too much overhead. for instance say we update > cups 4 times during the life of a release. that means we need to create > 4 > delta's as the end user can have 4 possible states of the package. > > Windows has always done delta's and for the longest time they only > provided > delta's from the latest version. which is the reason you had to update a > ton of times to get to the latest version. that has changed but its not > > http://www.directionsonmicrosoft.com/sample/DOMIS/update/2005/02feb/0205fsuttc.htm > > > Apple also provides delta's but they do only deltas from the previous > version > to latest if you you have an older version you have to get the full > version. > > most packages are so small that i don't think the overhead is worth the > pain. > OOo and a couple of others i could see maybe, but otherwise I personally > don't think its a good idea. It means mirrors need to carry more data. > -- > Dennis Gilmore, RHCE > Proud Australian > > _______________________________________________ > 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 email.ahmedkamal at googlemail.com Sat Jan 13 22:11:07 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 14 Jan 2007 00:11:07 +0200 Subject: Yum deltarpm In-Reply-To: <1168724805.24970.116.camel@localhost.localdomain> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <1168724805.24970.116.camel@localhost.localdomain> Message-ID: <3da3b5b40701131411k2722f254q4d93165015798125@mail.gmail.com> The most recent code is at: http://people.redhat.com/~herrmann/deltarpm/ We should be able to sign the drpms (not sure yet!) Reconstructing the new rpm from ondisk files, doesn't look bad security wise, because the new data is signed. If the on disk files are not trusted, this means the system is already compromised! It's not really the drpm's fault. Yes the old code is focused on up2date. It will take some cleaning. And I am all for dropping the server side code completely. drpms are to be generated by a cron-job and *not* on the fly as is the current implementation. So, the servers should not be running additional software. On 1/13/07, Toshio Kuratomi wrote: > > On Sat, 2007-01-13 at 20:40 +0200, Ahmed Kamal wrote: > > FYI, this yum deltarpm support, is based on that same deltarpm package > > that is made by suse. This suse package can create new rpms from drpm > > + (either ondisk files, or old rpm). Either way, a new rpm is created, > > then installed. Never does it replace files directly. Not sure why > > this would be bad security wise > > It's the construction of the rpm from ondisk files that I don't like. > You lose the ability to sign the rpm that you're installing. Patching > an older rpm is a safer transformation. > > I just googled and found an August post to yum-devel about what I think > is this plugin: > > https://lists.dulug.duke.edu/pipermail/yum-devel/2006-August/002385.html > > Is this right? Is there more recent code? It looks like that code is > tied into up2date so it wouldn't help Fedora users much. It also needs > a server side which implies the mirrors would have to run additional > software to make it functional.... > > -Toshio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Jan 13 22:12:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 13 Jan 2007 17:12:51 -0500 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701131403s5ea19bf5r3e4e3298d53db761@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <3da3b5b40701131403s5ea19bf5r3e4e3298d53db761@mail.gmail.com> Message-ID: <200701131712.51742.jkeating@redhat.com> On Saturday 13 January 2007 17:03, Ahmed Kamal wrote: > Any idea if OLPC has implemented implemented something similar ? OLPC doesn't use rpm as a package management system. It is used somewhat to create the deployment images, but after that it is treated as firmware almost for the XOs. When new "firmwares" are available, they will update over a mesh with other users, almost like a virus or worm. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sopwith at gmail.com Sun Jan 14 15:58:10 2007 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 14 Jan 2007 10:58:10 -0500 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701131411k2722f254q4d93165015798125@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <1168724805.24970.116.camel@localhost.localdomain> <3da3b5b40701131411k2722f254q4d93165015798125@mail.gmail.com> Message-ID: On Jan 13, 2007, at 5:11 PM, Ahmed Kamal wrote: > We should be able to sign the drpms (not sure yet!) Reconstructing > the new rpm from ondisk files, doesn't look bad security wise, > because the new data is signed. If the on disk files are not > trusted, this means the system is already compromised! Installed files get modified for reasons other than a hacked system. Think about config files that the sysadmin edits after a package is installed. Think about documentation files, whose may not be installed at all. Think about dealing with file conflicts between installed packages. Run 'rpm -Va' on a sample of Fedora systems and tell me that all those changes just don't matter... And make sure to talk to a sysadmin who has had to recover from a rootkit-ed system, and tell them that the rootkit'd files will get rolled into their newly installed packages if drpm is enabled during recovery. Relying on the integrity of installed files when generating and applying rpm diffs is just a bad idea, period. It's a hack that relies on hope instead of best practices, and it gives up the guarantees that are a substantial part of rpm's value. Any rpm delta solution must produce results that are identical to the original desired file, down to the last byte. Maybe there is a clever way to use a network server and local installed files, along with the rsync algorithm, to generate a .rpm file that is guaranteed to be byte-for-byte identical to the desired file. Mix BitTorrent technology in there, and there is plenty of room for innovation without resorting to a really bad hack. :) Best, -- Elliot From email.ahmedkamal at googlemail.com Sun Jan 14 20:43:58 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 14 Jan 2007 22:43:58 +0200 Subject: Yum deltarpm In-Reply-To: References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <1168724805.24970.116.camel@localhost.localdomain> <3da3b5b40701131411k2722f254q4d93165015798125@mail.gmail.com> Message-ID: <3da3b5b40701141243i40e4cf51p2e58481944f8edb7@mail.gmail.com> Thanks for the reply. The points raised are important and must be validated, before we implement such a system. I will now try to debunk the FUD ;) basically, drpm does construct a byte-for-byte rpm that is equivalent to the new rpm, then it installs that. If constructing such rpm fails for whatever reason, the drpm operation is aborted, and the system falls back to full rpms. One more interesting point to note, is that checking whether constructing a new rpm will be successful, is done prior to downloading the drpm, so bandwidth usage is kept minimal. While researching the topic, I found the mandriva folks were having similar discussions. http://qa.mandriva.com/show_bug.cgi?id=24535 Comment #13 is from the deltarpm author I also stumbled upon a forum poll, about adding deltarpm support for 2007 in Mandriva http://forum.club.mandriva.com/viewtopic.php?t=52030 http://forum.club.mandriva.com/viewtopic.php?t=52029 Surprisingly most users do think it's nice feature to have. Although not too many people voted, but that's what we have. BTW, using bittorrent does not seem like a good idea for yum: http://wiki.linux.duke.edu/YumTodont On 1/14/07, Elliot Lee wrote: > > > On Jan 13, 2007, at 5:11 PM, Ahmed Kamal wrote: > > > We should be able to sign the drpms (not sure yet!) Reconstructing > > the new rpm from ondisk files, doesn't look bad security wise, > > because the new data is signed. If the on disk files are not > > trusted, this means the system is already compromised! > > Installed files get modified for reasons other than a hacked system. > Think about config files that the sysadmin edits after a package is > installed. Think about documentation files, whose may not be > installed at all. Think about dealing with file conflicts between > installed packages. Run 'rpm -Va' on a sample of Fedora systems and > tell me that all those changes just don't matter... And make sure to > talk to a sysadmin who has had to recover from a rootkit-ed system, > and tell them that the rootkit'd files will get rolled into their > newly installed packages if drpm is enabled during recovery. > > Relying on the integrity of installed files when generating and > applying rpm diffs is just a bad idea, period. It's a hack that > relies on hope instead of best practices, and it gives up the > guarantees that are a substantial part of rpm's value. Any rpm delta > solution must produce results that are identical to the original > desired file, down to the last byte. > > Maybe there is a clever way to use a network server and local > installed files, along with the rsync algorithm, to generate a .rpm > file that is guaranteed to be byte-for-byte identical to the desired > file. Mix BitTorrent technology in there, and there is plenty of room > for innovation without resorting to a really bad hack. :) > > Best, > -- Elliot > > > _______________________________________________ > 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 kzak at redhat.com Sun Jan 14 21:08:16 2007 From: kzak at redhat.com (Karel Zak) Date: Sun, 14 Jan 2007 22:08:16 +0100 Subject: Future plans of the hosting project In-Reply-To: <200701112218.54291.jkeating@redhat.com> References: <200701112218.54291.jkeating@redhat.com> Message-ID: <20070114210816.GB31017@petra.dvoda.cz> On Thu, Jan 11, 2007 at 10:18:54PM -0500, Jesse Keating wrote: > As per the meeting, these are the things I think we need to do to further the > Fedora Hosted Project. Yes. Please, go! > 1) Move the hosted git/hg/svn off to another system. Ideally we'd have a > dedicated system (perhaps in another colo) that is beefy enough to run a few > xen guests. One for each SCM (so that sane configs can be done for web and > such), one for Trac itself, one for users to log in and fiddle with raw The Trac should be optional. For example I'd like to use raw web space + git + git web. Nothing other. Karel -- Karel Zak From sopwith at gmail.com Sun Jan 14 22:23:17 2007 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 14 Jan 2007 17:23:17 -0500 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701141243i40e4cf51p2e58481944f8edb7@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701130810g62ae3a4ei6555bc30202f2e17@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <1168724805.24970.116.camel@localhost.localdomain> <3da3b5b40701131411k2722f254q4d93165015798125@mail.gmail.com> <3da3b5b40701141243i40e4cf51p2e58481944f8edb7@mail.gmail.com> Message-ID: <018C8CE6-6BD4-48B0-8E74-D5C6CB5AF987@gmail.com> On Jan 14, 2007, at 3:43 PM, Ahmed Kamal wrote: > basically, drpm does construct a byte-for-byte rpm that is > equivalent to the new rpm, then it installs that. Cool beans - that's all I wanted to know :) Happy hacking, -- Elliot From email.ahmedkamal at googlemail.com Sun Jan 14 22:55:00 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 15 Jan 2007 00:55:00 +0200 Subject: Yum deltarpm In-Reply-To: <018C8CE6-6BD4-48B0-8E74-D5C6CB5AF987@gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168709321.24970.85.camel@localhost.localdomain> <3da3b5b40701130942n5f644e51y3e81b3ee2e3f647e@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <1168724805.24970.116.camel@localhost.localdomain> <3da3b5b40701131411k2722f254q4d93165015798125@mail.gmail.com> <3da3b5b40701141243i40e4cf51p2e58481944f8edb7@mail.gmail.com> <018C8CE6-6BD4-48B0-8E74-D5C6CB5AF987@gmail.com> Message-ID: <3da3b5b40701141455l2f2c5390y1933ce6f696bfb7c@mail.gmail.com> One thing I forgot to mention, is that this will be implemented as a yum plugin. So, it will not affect anyone who doesn't really want to use it. On 1/15/07, Elliot Lee wrote: > > > On Jan 14, 2007, at 3:43 PM, Ahmed Kamal wrote: > > > basically, drpm does construct a byte-for-byte rpm that is > > equivalent to the new rpm, then it installs that. > > Cool beans - that's all I wanted to know :) > > Happy hacking, > -- Elliot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Mon Jan 15 02:26:17 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 14 Jan 2007 20:26:17 -0600 Subject: Future plans of the hosting project In-Reply-To: <200701120747.35416.jkeating@redhat.com> References: <200701112218.54291.jkeating@redhat.com> <42A5F15A-0B5B-451E-B794-03E7306DC26D@breun.nl> <200701120747.35416.jkeating@redhat.com> Message-ID: <3237e4410701141826p7b0cc152t7269b70c10631e8f@mail.gmail.com> On 1/12/07, Jesse Keating wrote: > On Friday 12 January 2007 05:27, Nils Breunese wrote: How much IO is required between the repos and the hosted.fedoraproject.org? Will our SCM have to be hosted at the same site as our web site? -Mike From jkeating at redhat.com Mon Jan 15 13:18:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Jan 2007 08:18:29 -0500 Subject: Future plans of the hosting project In-Reply-To: <3237e4410701141826p7b0cc152t7269b70c10631e8f@mail.gmail.com> References: <200701112218.54291.jkeating@redhat.com> <200701120747.35416.jkeating@redhat.com> <3237e4410701141826p7b0cc152t7269b70c10631e8f@mail.gmail.com> Message-ID: <200701150818.33203.jkeating@redhat.com> On Sunday 14 January 2007 21:26, Mike McGrath wrote: > How much IO is required between the repos and the > hosted.fedoraproject.org? ?Will our SCM have to be hosted at the same > site as our web site? There could be a fair amount of read I/O from Trac. It hits the repo for the source browser, and you can use links to commit numbers in tickets, changelogs, milestones, wiki, etc... Plus if the SCM lives somewhere else, we still have to get Trac file read access to it, which means either a cross site NFS mount or a periodic rsync (which is what I'm doing right now). Neither of these sound very fun. -- Jesse Keating Release Engineer: Fedora -------------- 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 fedoraproject.org Tue Jan 16 04:17:07 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 15 Jan 2007 22:17:07 -0600 Subject: Wiki Upgrade Message-ID: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> Even though we won't get much use regarding caching, do you guys think it will be worth it to upgrade to current stable release of Moin Moin. There's bound to be many features that we can use and it'd be good to freshen up the wiki before the next release. (hopefully a good month before the next release so we can workout any bugs) Ahmed and Paulo, How much work would it take given your tests? -Mike From jkeating at redhat.com Tue Jan 16 04:32:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Jan 2007 23:32:16 -0500 Subject: Wiki Upgrade In-Reply-To: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> Message-ID: <200701152332.21503.jkeating@redhat.com> On Monday 15 January 2007 23:17, Mike McGrath wrote: > Even though we won't get much use regarding caching, do you guys think > it will be worth it to upgrade to current stable release of Moin Moin. > ?There's bound to be many features that we can use and it'd be good to > freshen up the wiki before the next release. ?(hopefully a good month > before the next release so we can workout any bugs) > > Ahmed and Paulo, How much work would it take given your tests? Yes, I'd like to see the latest version there before the big ramp up and heavy useage leading up to the F7 release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Tue Jan 16 05:25:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 16 Jan 2007 00:25:11 -0500 Subject: Wiki Upgrade In-Reply-To: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> Message-ID: <1168925111.21489.84.camel@cutter> On Mon, 2007-01-15 at 22:17 -0600, Mike McGrath wrote: > Even though we won't get much use regarding caching, do you guys think > it will be worth it to upgrade to current stable release of Moin Moin. > There's bound to be many features that we can use and it'd be good to > freshen up the wiki before the next release. (hopefully a good month > before the next release so we can workout any bugs) > > Ahmed and Paulo, How much work would it take given your tests? I don't see any reason not to upgrade if it won't break the world right away. -sv From sbranden at redhat.com Tue Jan 16 14:07:50 2007 From: sbranden at redhat.com (Stacy J. Brandenburg) Date: Tue, 16 Jan 2007 09:07:50 -0500 Subject: Outage tonight Message-ID: <45ACDC36.8010000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am not sure if anyone has let you know or not yet, but we have a planned outage of all services in the DC tonight. It starts at 9:00p Eastern and lasts for up to 6 hours. This will affect www.redhat.com, rhn.redhat.com, and all of the fedora infrastructure. I hope it will not really be 6 hours. I am applying a microcode upgrade to some of the blades in the 65xx chassis as well as installing 2 new border routers. Please be patient tonight. If you notice any problems after the window, please let me know via email and I will take a look. Thanks, - -- ======================================================== = Stacy J. Brandenburg Red Hat Inc. = = Manager, Network Operations sbranden at redhat.com = = 919-754-4313 http://www.redhat.com = ======================================================== Fingerprint 03F7 43BE 1150 CCFA F57B 54DD AEDB 1C27 1828 D94D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFrNw2rtscJxgo2U0RAifSAJsFEveeH38qUmM20utzP59SqRWDOACfeJGF 8L1wH1sDwGStroHAIn0sBPU= =Dc1S -----END PGP SIGNATURE----- From wwoods at redhat.com Tue Jan 16 17:33:36 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 16 Jan 2007 17:33:36 +0000 Subject: Quick introduction, infrastructure stuff for qa Message-ID: <1168968816.3033.51.camel@metroid.rdu.redhat.com> Hi there! I'm Will Woods, and I'm the lead tester / head of QA for Fedora. We're hard at work on bunches of tools and ideas to help test Fedora and make things better.. faster.. stronger. Right now, we've got a couple of repositories of packages for testing that live in David Malcolm's people page: http://people.redhat.com/dmalcolm/tablecloth/ We're also going to be writing some web apps that will need somewhere to live - something to keep track of testing progress / results, some bugzilla-related stuff, a frontend for an automated test lab, and so on. We don't have any hosting for any of it right now, but I'd like this stuff to live somewhere like http://qa.fedoraproject.org/. I'd like to have an official QA repo for our test tools and test packages, hosted at something like http://qa.fedoraproject.org/repo/. Most importantly, we need some help very soon. We currently have a problem - dmalcolm is out of disk quota, so he can't push bugfixed versions of the test tools out until we get a new host for the repos. This is bad! The amount of disk space we'll need is quite small - I think the packages currently take up something like 3MB. We'll be collecting test data and results and accumulating tests, but I don't anticipate this being a significant amount of data (say >10GB) for months, maybe years. Can we make this stuff happen? How do we get started? Thanks in advance for the help, guys. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Tue Jan 16 17:42:43 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 16 Jan 2007 11:42:43 -0600 Subject: Quick introduction, infrastructure stuff for qa In-Reply-To: <1168968816.3033.51.camel@metroid.rdu.redhat.com> References: <1168968816.3033.51.camel@metroid.rdu.redhat.com> Message-ID: <1168969363.9248.3.camel@lt21223.campus.dmacc.edu> On Tue, 2007-01-16 at 17:33 +0000, Will Woods wrote: > > Right now, we've got a couple of repositories of packages for testing > that live in David Malcolm's people page: > http://people.redhat.com/dmalcolm/tablecloth/ > > [...] > > I'd like to have an official QA repo for our test tools and test > packages, hosted at something like http://qa.fedoraproject.org/repo/. > > Most importantly, we need some help very soon. We currently have a > problem - dmalcolm is out of disk quota, so he can't push bugfixed > versions of the test tools out until we get a new host for the repos. > This is bad! Is there a reason that the test tools can't live in Fedora itself? Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at fedoraproject.org Tue Jan 16 18:06:11 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 16 Jan 2007 12:06:11 -0600 Subject: Quick introduction, infrastructure stuff for qa In-Reply-To: <1168968816.3033.51.camel@metroid.rdu.redhat.com> References: <1168968816.3033.51.camel@metroid.rdu.redhat.com> Message-ID: <3237e4410701161006k4de97971s3ba9721fa2015a9b@mail.gmail.com> On 1/16/07, Will Woods wrote: > Hi there! > > I'm Will Woods, and I'm the lead tester / head of QA for Fedora. > > We're hard at work on bunches of tools and ideas to help test Fedora and > make things better.. faster.. stronger. > > Right now, we've got a couple of repositories of packages for testing > that live in David Malcolm's people page: > http://people.redhat.com/dmalcolm/tablecloth/ > > We're also going to be writing some web apps that will need somewhere to > live - something to keep track of testing progress / results, some > bugzilla-related stuff, a frontend for an automated test lab, and so on. > We don't have any hosting for any of it right now, but I'd like this > stuff to live somewhere like http://qa.fedoraproject.org/. > > I'd like to have an official QA repo for our test tools and test > packages, hosted at something like http://qa.fedoraproject.org/repo/. > > Most importantly, we need some help very soon. We currently have a > problem - dmalcolm is out of disk quota, so he can't push bugfixed > versions of the test tools out until we get a new host for the repos. > This is bad! > > The amount of disk space we'll need is quite small - I think the > packages currently take up something like 3MB. We'll be collecting test > data and results and accumulating tests, but I don't anticipate this > being a significant amount of data (say >10GB) for months, maybe years. > > Can we make this stuff happen? How do we get started? > Yooo Will. This should be very doable. What exactly will be in the space and how will it get there? Will you need a shell? Will you need shell access from the outside world? Will the hosted.fedoraproject.org site work? -Mike From mmcgrath at fedoraproject.org Tue Jan 16 20:23:52 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 16 Jan 2007 14:23:52 -0600 Subject: XEN box Message-ID: <3237e4410701161223l2513fa92sc84869141203970f@mail.gmail.com> Anyone know of any of these guests that we can get rid of? db2 18 512 1 -b---- 17750.7 doc-library 55 256 1 -b---- 1279.8 fdstest 23 512 1 -b---- 12236.5 metrics 56 256 1 -b---- 1983.3 plonetest 34 512 1 -b---- 16944.8 test6 47 512 1 -b---- 1330.0 bzrtest 40 512 1 -b---- 9511.6 fedhosting 47 512 1 -b---- 17422.0 mail 50 512 1 -b---- 2347.8 mercurial 45 512 1 -b---- 69931.4 pkgdbtest 51 512 1 -b---- 3150.4 I need to make some room for will :-D Also, Most of these boxes could easily run test with 256 or 128 M of ram. If you get a moment log in and lower yours or send me a request so I can do it. I'll have a request form done soon so in the future expiration dates and official contacts are defined. -Mike From dennis at ausil.us Tue Jan 16 20:34:59 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 16 Jan 2007 14:34:59 -0600 Subject: XEN box In-Reply-To: <3237e4410701161223l2513fa92sc84869141203970f@mail.gmail.com> References: <3237e4410701161223l2513fa92sc84869141203970f@mail.gmail.com> Message-ID: <200701161434.59450.dennis@ausil.us> On Tuesday 16 January 2007 14:23, Mike McGrath wrote: > Anyone know of any of these guests that we can get rid of? > > db2 18 512 1 -b---- 17750.7 > doc-library 55 256 1 -b---- 1279.8 > fdstest 23 512 1 -b---- 12236.5 > metrics 56 256 1 -b---- 1983.3 > plonetest 34 512 1 -b---- 16944.8 > test6 47 512 1 -b---- 1330.0 > bzrtest 40 512 1 -b---- 9511.6 > fedhosting 47 512 1 -b---- 17422.0 > mail 50 512 1 -b---- 2347.8 > mercurial 45 512 1 -b---- 69931.4 > pkgdbtest 51 512 1 -b---- 3150.4 > > db2 can die mail == smtp test6 == luke mackens -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From email.ahmedkamal at googlemail.com Tue Jan 16 21:53:38 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 16 Jan 2007 23:53:38 +0200 Subject: Wiki Upgrade In-Reply-To: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> Message-ID: <3da3b5b40701161353v3ed20142s1aa411fbf4fcc7fe@mail.gmail.com> Sounds good. I will start reading Moin docs right away. I think Paulo played with the new version, so maybe he can better estimate the needed time. On 1/16/07, Mike McGrath wrote: > > Even though we won't get much use regarding caching, do you guys think > it will be worth it to upgrade to current stable release of Moin Moin. > There's bound to be many features that we can use and it'd be good to > freshen up the wiki before the next release. (hopefully a good month > before the next release so we can workout any bugs) > > Ahmed and Paulo, How much work would it take given your tests? > > -Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Tue Jan 16 23:50:23 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 16 Jan 2007 17:50:23 -0600 Subject: Wiki Upgrade In-Reply-To: <3da3b5b40701161353v3ed20142s1aa411fbf4fcc7fe@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> <3da3b5b40701161353v3ed20142s1aa411fbf4fcc7fe@mail.gmail.com> Message-ID: <3237e4410701161550y6aa60a31nadabbff90dbf9e0f@mail.gmail.com> On 1/16/07, Ahmed Kamal wrote: > Sounds good. I will start reading Moin docs right away. I think Paulo played > with the new version, so maybe he can better estimate the needed time. As soon as you get a timeline together let us know so we can coordinate the downtime and backups and all that. -Mike From wtogami at redhat.com Wed Jan 17 15:26:20 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 17 Jan 2007 10:26:20 -0500 Subject: Yum deltarpm In-Reply-To: <200701131406.01077.dennis@ausil.us> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> Message-ID: <45AE401C.9090707@redhat.com> Dennis Gilmore wrote: > On Saturday 13 January 2007 12:40 pm, Ahmed Kamal wrote: >> FYI, this yum deltarpm support, is based on that same deltarpm package that >> is made by suse. This suse package can create new rpms from drpm + (either >> ondisk files, or old rpm). Either way, a new rpm is created, then >> installed. Never does it replace files directly. Not sure why this would be >> bad security wise > > I personally don't like the idea of binary delta's there are too many > variables with them and too much overhead. for instance say we update > cups 4 times during the life of a release. that means we need to create 4 > delta's as the end user can have 4 possible states of the package. Then limit the delta to the most common update paths. If the desired delta doesn't exist when the user tries, it can fall back to download the full RPM. No big loss. > most packages are so small that i don't think the overhead is worth the pain. > OOo and a couple of others i could see maybe, but otherwise I personally > don't think its a good idea. It means mirrors need to carry more data. Then provide deltas only for the biggest things that would benefit the most from delta patching. All else download the original RPM. Some algorithm could attempt to make deltas, and offer deltas where the download savings are something like > 80% and > 2MB. Warren Togami wtogami at redhat.com From mmcgrath at fedoraproject.org Wed Jan 17 15:29:16 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 09:29:16 -0600 Subject: Yum deltarpm In-Reply-To: <45AE401C.9090707@redhat.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> Message-ID: <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> On 1/17/07, Warren Togami wrote: > Then limit the delta to the most common update paths. If the desired > delta doesn't exist when the user tries, it can fall back to download > the full RPM. No big loss. Does anyone track how many updates are released / day? I should start tracking that, I bet its significant. -Mike From skvidal at linux.duke.edu Wed Jan 17 15:31:12 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 Jan 2007 10:31:12 -0500 Subject: Yum deltarpm In-Reply-To: <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> Message-ID: <1169047872.4377.8.camel@cutter> On Wed, 2007-01-17 at 09:29 -0600, Mike McGrath wrote: > On 1/17/07, Warren Togami wrote: > > Then limit the delta to the most common update paths. If the desired > > delta doesn't exist when the user tries, it can fall back to download > > the full RPM. No big loss. > > Does anyone track how many updates are released / day? I should start > tracking that, I bet its significant. > If you're willing to work with per-day granularity - you can do it with repoquery. Just compare the changes in 'updates-released' from one day to the next. Keep in mind the package doesn't always go up. Sometimes old pkgs get removed. So it could remain the same number but new pkgs are released. -sv From mmcgrath at fedoraproject.org Wed Jan 17 15:34:49 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 09:34:49 -0600 Subject: Yum deltarpm In-Reply-To: <1169047872.4377.8.camel@cutter> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> Message-ID: <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> On 1/17/07, seth vidal wrote: > On Wed, 2007-01-17 at 09:29 -0600, Mike McGrath wrote: > > On 1/17/07, Warren Togami wrote: > > > Then limit the delta to the most common update paths. If the desired > > > delta doesn't exist when the user tries, it can fall back to download > > > the full RPM. No big loss. > > > > Does anyone track how many updates are released / day? I should start > > tracking that, I bet its significant. > > > > If you're willing to work with per-day granularity - you can do it with > repoquery. Just compare the changes in 'updates-released' from one day > to the next. > > Keep in mind the package doesn't always go up. Sometimes old pkgs get > removed. So it could remain the same number but new pkgs are released. > > -sv i think a lot of this has been discussed before in Fedora. Anyone know of any threads we can point Ahmed at? Looks like there's a lot of work to be done :-D -Mike From sundaram at fedoraproject.org Wed Jan 17 16:06:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 17 Jan 2007 21:36:53 +0530 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] Message-ID: <45AE499D.2070205@fedoraproject.org> An embedded message was scrubbed... From: Gary Croke Subject: [Fwd: About Fedora Directory Server Project (directory)] Date: Wed, 17 Jan 2007 08:07:58 -0800 Size: 3308 URL: From dennis at ausil.us Wed Jan 17 16:14:47 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 17 Jan 2007 10:14:47 -0600 Subject: Yum deltarpm In-Reply-To: <45AE401C.9090707@redhat.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> Message-ID: <200701171014.48016.dennis@ausil.us> On Wednesday 17 January 2007 09:26, Warren Togami wrote: > Dennis Gilmore wrote: > > On Saturday 13 January 2007 12:40 pm, Ahmed Kamal wrote: > >> FYI, this yum deltarpm support, is based on that same deltarpm package > >> that is made by suse. This suse package can create new rpms from drpm + > >> (either ondisk files, or old rpm). Either way, a new rpm is created, > >> then installed. Never does it replace files directly. Not sure why this > >> would be bad security wise > > > > I personally don't like the idea of binary delta's there are too many > > variables with them and too much overhead. for instance say we update > > cups 4 times during the life of a release. that means we need to create > > 4 delta's as the end user can have 4 possible states of the package. > > Then limit the delta to the most common update paths. If the desired > delta doesn't exist when the user tries, it can fall back to download > the full RPM. No big loss. i could see for OOo the need and maybe firefox but that is really about it. X in the old days but no now. If the user is not really wanting to update because of to many updates chances are that they dont have the latest versions installed. Im not saying that we should not do it. Just that personally im not a fan, and I dont think the gains will be worth the pain. Please prove me wrong if i am. -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From paulo.banon at googlemail.com Wed Jan 17 16:14:53 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Wed, 17 Jan 2007 17:14:53 +0100 Subject: Wiki Upgrade In-Reply-To: <3237e4410701161550y6aa60a31nadabbff90dbf9e0f@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> <3da3b5b40701161353v3ed20142s1aa411fbf4fcc7fe@mail.gmail.com> <3237e4410701161550y6aa60a31nadabbff90dbf9e0f@mail.gmail.com> Message-ID: <7a41c4bc0701170814m4391b5edvf17ad85afa9146e0@mail.gmail.com> Not much work needed. What have i done: - deploy new MoinMoin instalation - copy (mainly) the Data directory into the new directory. - test Nothing much more than this. Paulo On 1/17/07, Mike McGrath wrote: > > On 1/16/07, Ahmed Kamal wrote: > > Sounds good. I will start reading Moin docs right away. I think Paulo > played > > with the new version, so maybe he can better estimate the needed time. > > As soon as you get a timeline together let us know so we can > coordinate the downtime and backups and all that. > > -Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Wed Jan 17 16:17:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 Jan 2007 11:17:11 -0500 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <45AE499D.2070205@fedoraproject.org> References: <45AE499D.2070205@fedoraproject.org> Message-ID: <1169050631.4377.13.camel@cutter> On Wed, 2007-01-17 at 21:36 +0530, Rahul Sundaram wrote: > email message attachment ([Fwd: About Fedora Directory Server Project > (directory)]) > > -------- Forwarded Message -------- > > From: Gary Croke > > To: sundaram at fedoraproject.org > > Subject: [Fwd: About Fedora Directory Server Project (directory)] > > Date: Wed, 17 Jan 2007 08:07:58 -0800 > > > > Buzzword, buzzword, marketing-speak, buzzword buzzword. -sv From jkeating at redhat.com Wed Jan 17 16:21:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 Jan 2007 11:21:54 -0500 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <1169050631.4377.13.camel@cutter> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> Message-ID: <200701171121.54788.jkeating@redhat.com> On Wednesday 17 January 2007 11:17, seth vidal wrote: > Buzzword, buzzword, marketing-speak, buzzword buzzword. close-source software, buzzword, marketing-speak -- Jesse Keating Release Engineer: Fedora -------------- 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 fedoraproject.org Wed Jan 17 16:27:49 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 10:27:49 -0600 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <200701171121.54788.jkeating@redhat.com> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> Message-ID: <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> On 1/17/07, Jesse Keating wrote: > On Wednesday 17 January 2007 11:17, seth vidal wrote: > > Buzzword, buzzword, marketing-speak, buzzword buzzword. > > close-source software, buzzword, marketing-speak > Perhaps we should write a policy and get it board approved. "We will not run any software that does not meet the approval of one of our licenses" Are we currently breaking that rule anywhere in our infrastructure? It'd be nice to just point him to the policy so they know. We've had people ask us in the past to install stuff. -Mike From skvidal at linux.duke.edu Wed Jan 17 16:33:59 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 Jan 2007 11:33:59 -0500 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> Message-ID: <1169051639.4377.15.camel@cutter> On Wed, 2007-01-17 at 10:27 -0600, Mike McGrath wrote: > On 1/17/07, Jesse Keating wrote: > > On Wednesday 17 January 2007 11:17, seth vidal wrote: > > > Buzzword, buzzword, marketing-speak, buzzword buzzword. > > > > close-source software, buzzword, marketing-speak > > > > Perhaps we should write a policy and get it board approved. "We will > not run any software that does not meet the approval of one of our > licenses" Are we currently breaking that rule anywhere in our > infrastructure? cisco switches and LB. > It'd be nice to just point him to the policy so they know. We've had > people ask us in the past to install stuff. My only problem with a policy is someone else trying to hold our feet to the fire in a completely unreasonable place. Like bios firmware or some such thing. -sv From mmcgrath at fedoraproject.org Wed Jan 17 16:35:31 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 10:35:31 -0600 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <1169051639.4377.15.camel@cutter> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> <1169051639.4377.15.camel@cutter> Message-ID: <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> On 1/17/07, seth vidal wrote: > On Wed, 2007-01-17 at 10:27 -0600, Mike McGrath wrote: > > On 1/17/07, Jesse Keating wrote: > > > On Wednesday 17 January 2007 11:17, seth vidal wrote: > > > > Buzzword, buzzword, marketing-speak, buzzword buzzword. > cisco switches and LB. > The LB is easy to replace if we want to. But what to do about the cisco switches (and pix in front of that I guess) -Mike From jkeating at redhat.com Wed Jan 17 16:35:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 Jan 2007 11:35:50 -0500 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> References: <45AE499D.2070205@fedoraproject.org> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> Message-ID: <200701171135.51002.jkeating@redhat.com> On Wednesday 17 January 2007 11:27, Mike McGrath wrote: > On 1/17/07, Jesse Keating wrote: > > On Wednesday 17 January 2007 11:17, seth vidal wrote: > > > Buzzword, buzzword, marketing-speak, buzzword buzzword. > > > > close-source software, buzzword, marketing-speak > > Perhaps we should write a policy and get it board approved. "We will > not run any software that does not meet the approval of one of our > licenses" Are we currently breaking that rule anywhere in our > infrastructure? If you consider internal Red Hat stuff, like Brew for core, distill for composing core (at least FC6), the update tool currently used, those are all closed source, but replacements or opensourceing of all of these are in progress. > > It'd be nice to just point him to the policy so they know. We've had > people ask us in the past to install stuff. > -Mike yeah... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Wed Jan 17 16:36:47 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 Jan 2007 11:36:47 -0500 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> <1169051639.4377.15.camel@cutter> <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> Message-ID: <1169051807.4377.19.camel@cutter> On Wed, 2007-01-17 at 10:35 -0600, Mike McGrath wrote: > On 1/17/07, seth vidal wrote: > > On Wed, 2007-01-17 at 10:27 -0600, Mike McGrath wrote: > > > On 1/17/07, Jesse Keating wrote: > > > > On Wednesday 17 January 2007 11:17, seth vidal wrote: > > > > > Buzzword, buzzword, marketing-speak, buzzword buzzword. > > > > cisco switches and LB. > > > > The LB is easy to replace if we want to. But what to do about the > cisco switches (and pix in front of that I guess) I'm inclined not to sweat them overly much. It's a niche we cannot easily provide for ourselves. Moreover, we just don't have the time right now to sort that out. At least not that I can tell. -sv From mmcgrath at fedoraproject.org Wed Jan 17 16:41:18 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 10:41:18 -0600 Subject: Wiki Upgrade In-Reply-To: <7a41c4bc0701170814m4391b5edvf17ad85afa9146e0@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> <3da3b5b40701161353v3ed20142s1aa411fbf4fcc7fe@mail.gmail.com> <3237e4410701161550y6aa60a31nadabbff90dbf9e0f@mail.gmail.com> <7a41c4bc0701170814m4391b5edvf17ad85afa9146e0@mail.gmail.com> Message-ID: <3237e4410701170841w4b053730g7096c623a016b214@mail.gmail.com> On 1/17/07, Paulo Santos wrote: > Not much work needed. > What have i done: > - deploy new MoinMoin instalation > - copy (mainly) the Data directory into the new directory. > - test > > Nothing much more than this. > > Paulo > Can you get something set back up using a more recent backup for signoff from the website team? -Mike From jeff at ocjtech.us Wed Jan 17 16:53:48 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 17 Jan 2007 10:53:48 -0600 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> <1169051639.4377.15.camel@cutter> <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> Message-ID: <1169052828.3750.12.camel@lt21223.campus.dmacc.edu> On Wed, 2007-01-17 at 10:35 -0600, Mike McGrath wrote: > On 1/17/07, seth vidal wrote: > > On Wed, 2007-01-17 at 10:27 -0600, Mike McGrath wrote: > > > On 1/17/07, Jesse Keating wrote: > > > > On Wednesday 17 January 2007 11:17, seth vidal wrote: > > > > > Buzzword, buzzword, marketing-speak, buzzword buzzword. > > > cisco switches and LB. > > The LB is easy to replace if we want to. But what to do about the > cisco switches While it's possible to stick a bunch of 4 port ethernet cards into a Linux box and bridge them, I wouldn't necessarily recommend it. > (and pix in front of that I guess) What's the PIX used for? Unless you have some odd interfaces plugged into them I'm sure a properly configured Fedora/RHEL box will do pretty much anything a PIX will do. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at fedoraproject.org Wed Jan 17 17:19:13 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 11:19:13 -0600 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <1169052828.3750.12.camel@lt21223.campus.dmacc.edu> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> <1169051639.4377.15.camel@cutter> <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> <1169052828.3750.12.camel@lt21223.campus.dmacc.edu> Message-ID: <3237e4410701170919i184e255aj5965e4aaa154fac6@mail.gmail.com> On 1/17/07, Jeffrey C. Ollie wrote: > > While it's possible to stick a bunch of 4 port ethernet cards into a > Linux box and bridge them, I wouldn't necessarily recommend it. > > > (and pix in front of that I guess) > > What's the PIX used for? Unless you have some odd interfaces plugged > into them I'm sure a properly configured Fedora/RHEL box will do pretty > much anything a PIX will do. > > Jeff We use the pix as a firewall, I'm sure a Fedora/RHEL box would do great. -Mike From notting at redhat.com Wed Jan 17 17:06:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 Jan 2007 12:06:23 -0500 Subject: [Fwd: [Fwd: About Fedora Directory Server Project (directory)]] In-Reply-To: <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> References: <45AE499D.2070205@fedoraproject.org> <1169050631.4377.13.camel@cutter> <200701171121.54788.jkeating@redhat.com> <3237e4410701170827m27ee4833t13e14c534843cffd@mail.gmail.com> <1169051639.4377.15.camel@cutter> <3237e4410701170835l92bf270gc32d0f605360a15d@mail.gmail.com> Message-ID: <20070117170623.GA28487@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > >cisco switches and LB. > > The LB is easy to replace if we want to. But what to do about the > cisco switches (and pix in front of that I guess) I'm inclined to not care (even about the LB.) Bill From notting at redhat.com Wed Jan 17 15:34:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 Jan 2007 10:34:40 -0500 Subject: Yum deltarpm In-Reply-To: <1169047872.4377.8.camel@cutter> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> Message-ID: <20070117153440.GA8489@nostromo.devel.redhat.com> seth vidal (skvidal at linux.duke.edu) said: > > Does anyone track how many updates are released / day? I should start > > tracking that, I bet its significant. > > If you're willing to work with per-day granularity - you can do it with > repoquery. Just compare the changes in 'updates-released' from one day > to the next. Couldn't you also just poll the RSS and parse that? Bill From skvidal at linux.duke.edu Wed Jan 17 21:07:50 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 Jan 2007 16:07:50 -0500 Subject: Yum deltarpm In-Reply-To: <20070117153440.GA8489@nostromo.devel.redhat.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <20070117153440.GA8489@nostromo.devel.redhat.com> Message-ID: <1169068070.4377.28.camel@cutter> On Wed, 2007-01-17 at 10:34 -0500, Bill Nottingham wrote: > seth vidal (skvidal at linux.duke.edu) said: > > > Does anyone track how many updates are released / day? I should start > > > tracking that, I bet its significant. > > > > If you're willing to work with per-day granularity - you can do it with > > repoquery. Just compare the changes in 'updates-released' from one day > > to the next. > > Couldn't you also just poll the RSS and parse that? so you're parsing the parsing of the parsed metadata? aaaaaahh :) -sv From mmcgrath at fedoraproject.org Wed Jan 17 22:03:43 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 16:03:43 -0600 Subject: Request For Resources Message-ID: <3237e4410701171403q3738a254tb293e3e37a2a4b62@mail.gmail.com> http://fedoraproject.org/wiki/Infrastructure/RFR Lets hammer on this asap if we could, I'd like to have Will and company fill one of these out for their Xen instance soon. (gotta start somewhere) -Mike From paulo.banon at googlemail.com Thu Jan 18 00:37:30 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 18 Jan 2007 01:37:30 +0100 Subject: Wiki Upgrade In-Reply-To: <3237e4410701170841w4b053730g7096c623a016b214@mail.gmail.com> References: <3237e4410701152017x1613ca56w860ff310aa6a0094@mail.gmail.com> <3da3b5b40701161353v3ed20142s1aa411fbf4fcc7fe@mail.gmail.com> <3237e4410701161550y6aa60a31nadabbff90dbf9e0f@mail.gmail.com> <7a41c4bc0701170814m4391b5edvf17ad85afa9146e0@mail.gmail.com> <3237e4410701170841w4b053730g7096c623a016b214@mail.gmail.com> Message-ID: <7a41c4bc0701171637q2478940bx961da71fad06d056@mail.gmail.com> Do a backup from the MoinMoin Data directory (Duke) and drop it in app2 (PHX). Simple as that. I still dont have internet access at home, so i cant login to the boxes Paulo On 1/17/07, Mike McGrath wrote: > > On 1/17/07, Paulo Santos wrote: > > Not much work needed. > > What have i done: > > - deploy new MoinMoin instalation > > - copy (mainly) the Data directory into the new directory. > > - test > > > > Nothing much more than this. > > > > Paulo > > > > > Can you get something set back up using a more recent backup for > signoff from the website team? > > -Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ocjtech.us Thu Jan 18 01:23:45 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 17 Jan 2007 19:23:45 -0600 Subject: Request For Resources In-Reply-To: <3237e4410701171403q3738a254tb293e3e37a2a4b62@mail.gmail.com> References: <3237e4410701171403q3738a254tb293e3e37a2a4b62@mail.gmail.com> Message-ID: <1169083425.5393.4.camel@lt21223.campus.dmacc.edu> On Wed, 2007-01-17 at 16:03 -0600, Mike McGrath wrote: > http://fedoraproject.org/wiki/Infrastructure/RFR > > Lets hammer on this asap if we could, I'd like to have Will and > company fill one of these out for their Xen instance soon. (gotta > start somewhere) I like it. One thing that I would add though would be to limit how far out you can set the expiration date - I'd suggest six months. If more time is needed they need to come back and show that they have been making progress and expect to be production ready soon. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at fedoraproject.org Thu Jan 18 02:01:49 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 17 Jan 2007 20:01:49 -0600 Subject: Request For Resources In-Reply-To: <1169083425.5393.4.camel@lt21223.campus.dmacc.edu> References: <3237e4410701171403q3738a254tb293e3e37a2a4b62@mail.gmail.com> <1169083425.5393.4.camel@lt21223.campus.dmacc.edu> Message-ID: <3237e4410701171801s20e99980h9c680f463e92c41a@mail.gmail.com> On 1/17/07, Jeffrey C. Ollie wrote: > On Wed, 2007-01-17 at 16:03 -0600, Mike McGrath wrote: > > http://fedoraproject.org/wiki/Infrastructure/RFR > > > > Lets hammer on this asap if we could, I'd like to have Will and > > company fill one of these out for their Xen instance soon. (gotta > > start somewhere) > > I like it. One thing that I would add though would be to limit how far > out you can set the expiration date - I'd suggest six months. If more > time is needed they need to come back and show that they have been > making progress and expect to be production ready soon. > I had a hard time thinking of whether or not to put a hard limit or just have them put one. In the end I left it open ended because we have to approve it anyway, so if someone put it a year out and we think 3 months is enough, we can have them change it before they get an infrastructure sponsor. I hope we'll have more sponsors than just me :-D If any of you see something that interests you (like a doc plone instance), please let me know! -Mike From a.badger at gmail.com Thu Jan 18 03:35:16 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 17 Jan 2007 19:35:16 -0800 Subject: Yum deltarpm In-Reply-To: <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> Message-ID: <1169091316.14225.14.camel@localhost.localdomain> On Wed, 2007-01-17 at 09:34 -0600, Mike McGrath wrote: > On 1/17/07, seth vidal wrote: > > On Wed, 2007-01-17 at 09:29 -0600, Mike McGrath wrote: > > > On 1/17/07, Warren Togami wrote: > > > > Then limit the delta to the most common update paths. If the desired > > > > delta doesn't exist when the user tries, it can fall back to download > > > > the full RPM. No big loss. > > > > > > Does anyone track how many updates are released / day? I should start > > > tracking that, I bet its significant. > > > > > > > If you're willing to work with per-day granularity - you can do it with > > repoquery. Just compare the changes in 'updates-released' from one day > > to the next. > > > > Keep in mind the package doesn't always go up. Sometimes old pkgs get > > removed. So it could remain the same number but new pkgs are released. > > > > -sv > > i think a lot of this has been discussed before in Fedora. Anyone > know of any threads we can point Ahmed at? Looks like there's a lot > of work to be done :-D The first thread I'm aware of was in 1998 and involved xdelta'ing the rpm's. Google can't locate it so I'm betting it was on contrib-list (whose archives have disappeared from redhat.com) Some of the more recent discussions:: http://www.redhat.com/archives/fedora-devel-list/2005-December/msg00404.html http://www.redhat.com/archives/fedora-devel-list/2005-June/msg00018.html ... and google knows of others as well. Try:: site:redhat.com delta rpm -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From email.ahmedkamal at googlemail.com Thu Jan 18 07:53:16 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 18 Jan 2007 09:53:16 +0200 Subject: Yum deltarpm In-Reply-To: <1169091316.14225.14.camel@localhost.localdomain> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> Message-ID: <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> Appreciating everyone's help, it seems others have attempted this before. Anyway, let's put this through the test of time :) Also, I totally agree with keeping drpms only if they meet certain criteria, i.e. provide >50% savings or similar. Right now, I am trying to figure out how/where the server side will store the drpm metadata. Other.xml.gz seems like a good place, or maybe a new drpm.xml.gz, but I am not sure how such file should be written. Should I just write code that will generate drpms, and that xml metadata file too ? Must the xml file be written according to a specific form, I only need to attach a hash to each drpm, which the clients will use to know whether using the drpm will be successful. On 1/18/07, Toshio Kuratomi wrote: > > On Wed, 2007-01-17 at 09:34 -0600, Mike McGrath wrote: > > On 1/17/07, seth vidal wrote: > > > On Wed, 2007-01-17 at 09:29 -0600, Mike McGrath wrote: > > > > On 1/17/07, Warren Togami wrote: > > > > > Then limit the delta to the most common update paths. If the > desired > > > > > delta doesn't exist when the user tries, it can fall back to > download > > > > > the full RPM. No big loss. > > > > > > > > Does anyone track how many updates are released / day? I should > start > > > > tracking that, I bet its significant. > > > > > > > > > > If you're willing to work with per-day granularity - you can do it > with > > > repoquery. Just compare the changes in 'updates-released' from one day > > > to the next. > > > > > > Keep in mind the package doesn't always go up. Sometimes old pkgs get > > > removed. So it could remain the same number but new pkgs are released. > > > > > > -sv > > > > i think a lot of this has been discussed before in Fedora. Anyone > > know of any threads we can point Ahmed at? Looks like there's a lot > > of work to be done :-D > > The first thread I'm aware of was in 1998 and involved xdelta'ing the > rpm's. Google can't locate it so I'm betting it was on contrib-list > (whose archives have disappeared from redhat.com) > > Some of the more recent discussions:: > > http://www.redhat.com/archives/fedora-devel-list/2005-December/msg00404.html > http://www.redhat.com/archives/fedora-devel-list/2005-June/msg00018.html > > ... and google knows of others as well. Try:: > site:redhat.com delta rpm > > -Toshio > > > _______________________________________________ > 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 rzarouali at gmail.com Thu Jan 18 17:15:41 2007 From: rzarouali at gmail.com (Rachid Zarouali) Date: Thu, 18 Jan 2007 18:15:41 +0100 Subject: Fwd: [config management] kind of survey In-Reply-To: References: Message-ID: just in case some of you missed it ;=) please take some time and answer this little survey thanks Rachid ---------- Forwarded message ---------- From: Zarouali Rachid Date: Jan 8, 2007 12:35 PM Subject: [config management] kind of survey To: fedora-infrastructure-list at redhat.com Hy all, i have recently join the fedora infrastructure list, so maybe this survey would appear to you a bit odd. i have taken a deeper look at what have been discussed regarding the config management task, many of you have strong experience in different kind of tools like glump, puppet, cfengine ... but i haven't seen any checkup list on : - what's the aim of a new config management system. - how far we want this tool to manage servers config (system,services, both of them, anything else maybe ....). - system limitations (for example : no ruby tools because it has been sealed that ruby should be installed on servers ). i've seen jeff ollie has made a little wiki page listing all config management tools suggested, with pros and cons, here's my little suggestion: first : we should list : - what the new config tool should do for us - perhaps how we want this tool to work, (agent/server or something else) - system things for example : no ruby, if there an agent so it should communicate securely with his server ..... second : looking at jeff wiki's page and other solutions discussed on the list, and see if there is any tool listed there which answer all our requirements, if not then 2 choice : - take a look around and find the "right" tool - lower a little bit our requirements, so one of the tools listed would answer them (definitely the worst solution ). third: -build a test environment with the chosen tool, so everyone can play with it (the more people become familiar with it, the best it would be ;) ) fourth: - make a deployment schedule. fifth: - deploy and enjoy the work done by all people involved in ;=) here my personal view: 1) what the new config tool should do for us: this tool should help us managing system and services configurations of all fp.o servers. by managing, i mean : - building new config to deploy. - easily and smoothly updating several config - versioning all config created and/or updated how we want this tool to work: - all tasks should be done securely, agent/server tool or not. - the tool should give us some report on how tasks goes. system things: well as I'm not used on how servers are deployed , i can't really answer this point but, IMHO, whatever tool is chosen, it should not require something that may change how our systems works, this tool should be nearly invisible system view. 2) about the right tool, after looking at threads in the list archive and looking at jeff page, glump seems to be a good start 3) and 4) would come along the way after all question for 1) and 2) are settled. who's next to answer this little survey ? :) hoping this would help Rachid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Thu Jan 18 17:23:20 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 18 Jan 2007 11:23:20 -0600 Subject: [config management] kind of survey In-Reply-To: References: Message-ID: <3237e4410701180923s7c1ca41ob261ae14a21e86ed@mail.gmail.com> On 1/18/07, Rachid Zarouali wrote: > Hy all, > > i have recently join the fedora infrastructure list, so maybe this survey > would appear to you a bit odd. > i have taken a deeper look at what have been discussed regarding the config > management task, > many of you have strong experience in different kind of tools like glump, > puppet, cfengine ... > but i haven't seen any checkup list on : > - what's the aim of a new config management system. To replace the old system and to add some layer of enforcement while making backups of whatever it replaces. > - how far we want this tool to manage servers config (system,services, both > of them, anything else maybe ....). Ideally it would cover everything non-data related on all the servers. Once a box is kicked and the proper packages are installed, the config push would go out, the box would reboot and right away be 'live' We're very close to this in our current system except some configs are out of date. > - system limitations (for example : no ruby tools because it has been sealed > that ruby should be installed on servers ). The fewer changes we have to make the better, this includes packages. At this point I think it'll be best for me to just take everything we know, pick one, test it in our environment and put a proposal together and see if any of the officers want to chop my head off :-D It's just a matter of getting time. Which reminds me my first official day is February 5th (right after FudCON) but I'll be doing orientation and meetings the first couple of days and will probably be unavailable. -Mike From a.badger at gmail.com Thu Jan 18 17:39:50 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Jan 2007 09:39:50 -0800 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> Message-ID: <1169141990.14225.51.camel@localhost.localdomain> On Thu, 2007-01-18 at 09:53 +0200, Ahmed Kamal wrote: > Appreciating everyone's help, it seems others have attempted this > before. Anyway, let's put this through the test of time :) Also, I > totally agree with keeping drpms only if they meet certain criteria, > i.e. provide >50% savings or similar. > > Right now, I am trying to figure out how/where the server side will > store the drpm metadata. Other.xml.gz seems like a good place, or > maybe a new drpm.xml.gz, but I am not sure how such file should be > written. I seem to recall that primary.xml.gz can list arbitrary xml files which the depsolvers will ignore if they don't need them but Seth would know better. > Should I just write code that will generate drpms, and that xml > metadata file too ? That would probably work but you might want to break the steps into two parts. Just remember to think about how the drpms are getting to the repo. Are you going to do the updates on a separate machine and then push them over? Are you going to push the new drpms onto the server, regenerate the metadata, then push the new metadata over? > Must the xml file be written according to a specific form, I only > need to attach a hash to each drpm, which the clients will use to know > whether using the drpm will be successful. > Are you writing this from scratch? If it's using the yum plugin that already exists it might be expecting the metadata in a specific format already. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Thu Jan 18 17:49:28 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 18 Jan 2007 12:49:28 -0500 Subject: Yum deltarpm In-Reply-To: <1169141990.14225.51.camel@localhost.localdomain> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <1168712485.24970.100.camel@localhost.localdomain> <3da3b5b40701131040y53dfd1b0t55fcc4169434e756@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> Message-ID: <1169142568.4377.95.camel@cutter> On Thu, 2007-01-18 at 09:39 -0800, Toshio Kuratomi wrote: > On Thu, 2007-01-18 at 09:53 +0200, Ahmed Kamal wrote: > > Appreciating everyone's help, it seems others have attempted this > > before. Anyway, let's put this through the test of time :) Also, I > > totally agree with keeping drpms only if they meet certain criteria, > > i.e. provide >50% savings or similar. > > > > Right now, I am trying to figure out how/where the server side will > > store the drpm metadata. Other.xml.gz seems like a good place, or > > maybe a new drpm.xml.gz, but I am not sure how such file should be > > written. > > I seem to recall that primary.xml.gz can list arbitrary xml files which > the depsolvers will ignore if they don't need them but Seth would know > better. repomd.xml can list additional files, not primary - but the result is the same. You'd want to tie knowledge of drpms into createrepo. > Are you writing this from scratch? If it's using the yum plugin that > already exists it might be expecting the metadata in a specific format > already. plugins can do whatever, pretty much, when it comes to what kind of metadata they want to deal with. -sv From mmcgrath at fedoraproject.org Thu Jan 18 20:57:07 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 18 Jan 2007 14:57:07 -0600 Subject: Email addresses Message-ID: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> At present we provide two @fedoraproject.org addresses to everyone who has a fedoraproject account. account at fp.o and first.last at fp.o Notting pointed out that its only a matter of time before we have a collision in first.last. Should we just get rid of it? I don't know of anyone using it. -Mike From sundaram at fedoraproject.org Thu Jan 18 20:58:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Jan 2007 02:28:54 +0530 Subject: Email addresses In-Reply-To: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> Message-ID: <45AFDF8E.9080002@fedoraproject.org> Mike McGrath wrote: > At present we provide two @fedoraproject.org addresses to everyone who > has a fedoraproject account. > > account at fp.o > and > first.last at fp.o > > > Notting pointed out that its only a matter of time before we have a > collision in first.last. Should we just get rid of it? I don't know > of anyone using it. I saw it being used in atleast one guy's profile. Maybe a send a mail to everyone with the account that we are dropping off the first.last at fp.o alias would be more prudent just in case someone is using it actively. Moreover it would be useful if users in the account name can set aliases manually. When you sign up for a account, the fact that you get a email id automatically should be better documented in the account pages too. Rahul From mmcgrath at fedoraproject.org Thu Jan 18 21:05:06 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 18 Jan 2007 15:05:06 -0600 Subject: Email addresses In-Reply-To: <45AFDF8E.9080002@fedoraproject.org> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> Message-ID: <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> On 1/18/07, Rahul Sundaram wrote: > Mike McGrath wrote: > I saw it being used in atleast one guy's profile. Maybe a send a mail to > everyone with the account that we are dropping off the first.last at fp.o > alias would be more prudent just in case someone is using it actively. > Moreover it would be useful if users in the account name can set aliases > manually. When you sign up for a account, the fact that you get a email > id automatically should be better documented in the account pages too. > > Rahul > Unless anyone can think of any reason not to, I'll send a list to announce, devel and extras stating that we'll be getting rid of first.last. -Mike From paulo.banon at googlemail.com Thu Jan 18 21:07:01 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 18 Jan 2007 22:07:01 +0100 Subject: Email addresses In-Reply-To: <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> Message-ID: <7a41c4bc0701181307g4d7d5139ud01ad4fba8a59332@mail.gmail.com> I didnt even knew that we could get those email addresses... Paulo On 1/18/07, Mike McGrath wrote: > > On 1/18/07, Rahul Sundaram wrote: > > Mike McGrath wrote: > > I saw it being used in atleast one guy's profile. Maybe a send a mail to > > everyone with the account that we are dropping off the first.last at fp.o > > alias would be more prudent just in case someone is using it actively. > > Moreover it would be useful if users in the account name can set aliases > > manually. When you sign up for a account, the fact that you get a email > > id automatically should be better documented in the account pages too. > > > > Rahul > > > > Unless anyone can think of any reason not to, I'll send a list to > announce, devel and extras stating that we'll be getting rid of > first.last. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at fedoraproject.org Thu Jan 18 21:20:07 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 18 Jan 2007 15:20:07 -0600 Subject: Email addresses In-Reply-To: <7a41c4bc0701181307g4d7d5139ud01ad4fba8a59332@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> <7a41c4bc0701181307g4d7d5139ud01ad4fba8a59332@mail.gmail.com> Message-ID: <3237e4410701181320n34939c47gb79fd770382c9431@mail.gmail.com> On 1/18/07, Paulo Santos wrote: > I didnt even knew that we could get those email addresses... > > Paulo We don't advertise it really. I'm not sure why, I guess we kind of just hope that people don't use it until they've been involved long enough to learn about it :-D Makes them look more official. -Mike From paulo.banon at googlemail.com Thu Jan 18 21:23:41 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Thu, 18 Jan 2007 22:23:41 +0100 Subject: Email addresses In-Reply-To: <3237e4410701181320n34939c47gb79fd770382c9431@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> <7a41c4bc0701181307g4d7d5139ud01ad4fba8a59332@mail.gmail.com> <3237e4410701181320n34939c47gb79fd770382c9431@mail.gmail.com> Message-ID: <7a41c4bc0701181323r523d0e6u570c3a1441389ba7@mail.gmail.com> That makes alot of sense On 1/18/07, Mike McGrath wrote: > > On 1/18/07, Paulo Santos wrote: > > I didnt even knew that we could get those email addresses... > > > > Paulo > > > We don't advertise it really. I'm not sure why, I guess we kind of > just hope that people don't use it until they've been involved long > enough to learn about it :-D Makes them look more official. > > -Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Thu Jan 18 21:42:17 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 18 Jan 2007 16:42:17 -0500 Subject: Email addresses In-Reply-To: <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> Message-ID: <20070118214217.GB15966@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at fedoraproject.org) said: > Unless anyone can think of any reason not to, I'll send a list to > announce, devel and extras stating that we'll be getting rid of > first.last. Maybe just stop for new accounts, and grandfather in what's there? (I don't know if the setup for generating them really allows for this...) Bill From paulo.banon at googlemail.com Fri Jan 19 03:46:35 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Fri, 19 Jan 2007 04:46:35 +0100 Subject: Email addresses In-Reply-To: <20070118214217.GB15966@nostromo.devel.redhat.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> <20070118214217.GB15966@nostromo.devel.redhat.com> Message-ID: <7a41c4bc0701181946u2d01c1c9g9a1d934c0aebd7c2@mail.gmail.com> let me create mine then :D On 1/18/07, Bill Nottingham wrote: > > Mike McGrath (mmcgrath at fedoraproject.org) said: > > Unless anyone can think of any reason not to, I'll send a list to > > announce, devel and extras stating that we'll be getting rid of > > first.last. > > Maybe just stop for new accounts, and grandfather in what's > there? (I don't know if the setup for generating them really > allows for this...) > > Bill > > _______________________________________________ > 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 mmcgrath at fedoraproject.org Fri Jan 19 04:09:02 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 18 Jan 2007 22:09:02 -0600 Subject: Email addresses In-Reply-To: <7a41c4bc0701181946u2d01c1c9g9a1d934c0aebd7c2@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> <20070118214217.GB15966@nostromo.devel.redhat.com> <7a41c4bc0701181946u2d01c1c9g9a1d934c0aebd7c2@mail.gmail.com> Message-ID: <3237e4410701182009g60fed3faj7061e030147e89a4@mail.gmail.com> On 1/18/07, Paulo Santos wrote: > let me create mine then :D > Actually they're auto generated when you create your account at the top of every hour. -Mike From mmcgrath at fedoraproject.org Fri Jan 19 17:34:10 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Fri, 19 Jan 2007 11:34:10 -0600 Subject: Email addresses In-Reply-To: <20070118214217.GB15966@nostromo.devel.redhat.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> <20070118214217.GB15966@nostromo.devel.redhat.com> Message-ID: <3237e4410701190934g33a08f4cm9e36145f1ff214d@mail.gmail.com> On 1/18/07, Bill Nottingham wrote: > Mike McGrath (mmcgrath at fedoraproject.org) said: > > Unless anyone can think of any reason not to, I'll send a list to > > announce, devel and extras stating that we'll be getting rid of > > first.last. > > Maybe just stop for new accounts, and grandfather in what's > there? (I don't know if the setup for generating them really > allows for this...) > Actually I'd rather just drop it for everyone, mostly because we have a lot of first / last combos that are invalid syntactically that will cause us issue when upgrading to postfix. -Mike From wtogami at redhat.com Fri Jan 19 20:30:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 19 Jan 2007 15:30:28 -0500 Subject: Email addresses In-Reply-To: <3237e4410701190934g33a08f4cm9e36145f1ff214d@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <45AFDF8E.9080002@fedoraproject.org> <3237e4410701181305w1ab3ef72m2039980559e7bd38@mail.gmail.com> <20070118214217.GB15966@nostromo.devel.redhat.com> <3237e4410701190934g33a08f4cm9e36145f1ff214d@mail.gmail.com> Message-ID: <45B12A64.5080905@redhat.com> Mike McGrath wrote: > > Actually I'd rather just drop it for everyone, mostly because we have > a lot of first / last combos that are invalid syntactically that will > cause us issue when upgrading to postfix. > +1 for dropping them completely. Warren Togami wtogami at redhat.com From sopwith at gmail.com Sun Jan 21 21:11:57 2007 From: sopwith at gmail.com (Elliot Lee) Date: Sun, 21 Jan 2007 16:11:57 -0500 Subject: Email addresses In-Reply-To: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> Message-ID: <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> On Jan 18, 2007, at 15:57 , Mike McGrath wrote: > At present we provide two @fedoraproject.org addresses to everyone who > has a fedoraproject account. > > account at fp.o > and > first.last at fp.o > > > Notting pointed out that its only a matter of time before we have a > collision in first.last. Should we just get rid of it? I don't know > of anyone using it. Another possible solution - add a 'UNIQUE' constraint onto the human_name field in the db... Best, -- Elliot From email.ahmedkamal at googlemail.com Sun Jan 21 21:52:05 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 21 Jan 2007 23:52:05 +0200 Subject: Email addresses In-Reply-To: <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> Message-ID: <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> while account at fp.o is technically easier, first.last at fp.o looks better and is more professional. If we can keep it, I'd rather do! A check for ASCII characters only + uniqueness might be all that's needed in the web app as suggested On 1/21/07, Elliot Lee wrote: > > > On Jan 18, 2007, at 15:57 , Mike McGrath wrote: > > > At present we provide two @fedoraproject.org addresses to everyone who > > has a fedoraproject account. > > > > account at fp.o > > and > > first.last at fp.o > > > > > > Notting pointed out that its only a matter of time before we have a > > collision in first.last. Should we just get rid of it? I don't know > > of anyone using it. > > Another possible solution - add a 'UNIQUE' constraint onto the > human_name field in the db... > > Best, > -- Elliot > > > _______________________________________________ > 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 linux.duke.edu Sun Jan 21 23:46:15 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 21 Jan 2007 18:46:15 -0500 Subject: Email addresses In-Reply-To: <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> Message-ID: <1169423175.26967.7.camel@cutter> On Sun, 2007-01-21 at 23:52 +0200, Ahmed Kamal wrote: > while account at fp.o is technically easier, first.last at fp.o looks better > and is more professional. If we can keep it, I'd rather do! > A check for ASCII characters only + uniqueness might be all that's > needed in the web app as suggested professional doesn't matter, imo. Fedora is a hobbiest and enthusiast-driven linux distro. no professional needs :) -sv From mmcgrath at fedoraproject.org Mon Jan 22 00:55:28 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 21 Jan 2007 18:55:28 -0600 Subject: Email addresses In-Reply-To: <1169423175.26967.7.camel@cutter> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> <1169423175.26967.7.camel@cutter> Message-ID: <3237e4410701211655w23ae039bib9bae55a1b2a6117@mail.gmail.com> On 1/21/07, seth vidal wrote: > On Sun, 2007-01-21 at 23:52 +0200, Ahmed Kamal wrote: > > professional doesn't matter, imo. Fedora is a hobbiest and > enthusiast-driven linux distro. > > no professional needs :) I'd like to think "mmcgrath" is a professional sounding account :-D But I'd hate to tell the next Mike McGrath that they can't create an account because their first and last name is already taken. Plus saying "no first name last name" accounts is easier than telling those that have special characters in their names that they can't have the first name last name account. -Mike From skvidal at linux.duke.edu Mon Jan 22 00:57:17 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 21 Jan 2007 19:57:17 -0500 Subject: Email addresses In-Reply-To: <3237e4410701211655w23ae039bib9bae55a1b2a6117@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> <1169423175.26967.7.camel@cutter> <3237e4410701211655w23ae039bib9bae55a1b2a6117@mail.gmail.com> Message-ID: <1169427437.26967.25.camel@cutter> On Sun, 2007-01-21 at 18:55 -0600, Mike McGrath wrote: > On 1/21/07, seth vidal wrote: > > On Sun, 2007-01-21 at 23:52 +0200, Ahmed Kamal wrote: > > > > professional doesn't matter, imo. Fedora is a hobbiest and > > enthusiast-driven linux distro. > > > > no professional needs :) > > I'd like to think "mmcgrath" is a professional sounding account :-D > But I'd hate to tell the next Mike McGrath that they can't create an > account because their first and last name is already taken. Plus > saying "no first name last name" accounts is easier than telling those > that have special characters in their names that they can't have the > first name last name account. +1 -sv From a.badger at gmail.com Mon Jan 22 00:58:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 21 Jan 2007 16:58:12 -0800 Subject: Email addresses In-Reply-To: <3237e4410701211655w23ae039bib9bae55a1b2a6117@mail.gmail.com> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> <1169423175.26967.7.camel@cutter> <3237e4410701211655w23ae039bib9bae55a1b2a6117@mail.gmail.com> Message-ID: <1169427492.6687.22.camel@localhost.localdomain> On Sun, 2007-01-21 at 18:55 -0600, Mike McGrath wrote: > On 1/21/07, seth vidal wrote: > > On Sun, 2007-01-21 at 23:52 +0200, Ahmed Kamal wrote: > > > > professional doesn't matter, imo. Fedora is a hobbiest and > > enthusiast-driven linux distro. > > > > no professional needs :) > > I'd like to think "mmcgrath" is a professional sounding account :-D > But I'd hate to tell the next Mike McGrath that they can't create an > account because their first and last name is already taken. Plus > saying "no first name last name" accounts is easier than telling those > that have special characters in their names that they can't have the > first name last name account. +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rzarouali at gmail.com Sun Jan 21 23:57:15 2007 From: rzarouali at gmail.com (Rachid Zarouali) Date: Mon, 22 Jan 2007 00:57:15 +0100 Subject: Email addresses In-Reply-To: <1169423175.26967.7.camel@cutter> References: <3237e4410701181257x38bfe40dl97fcb274149660ba@mail.gmail.com> <2CC6291C-1595-46CC-8205-F00D75D4D744@gmail.com> <3da3b5b40701211352i2dab50a6vfe07c305a1dbd058@mail.gmail.com> <1169423175.26967.7.camel@cutter> Message-ID: On 1/22/07, seth vidal wrote: > > On Sun, 2007-01-21 at 23:52 +0200, Ahmed Kamal wrote: > > while account at fp.o is technically easier, first.last at fp.o looks better > > and is more professional. If we can keep it, I'd rather do! > > A check for ASCII characters only + uniqueness might be all that's > > needed in the web app as suggested > > professional doesn't matter, imo. Fedora is a hobbiest and > enthusiast-driven linux distro. which doesn't mean we won't do our hobbie "professionally" :) no professional needs :) > > -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 mmcgrath at fedoraproject.org Mon Jan 22 18:29:46 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Mon, 22 Jan 2007 12:29:46 -0600 Subject: Wiki Upgrade Message-ID: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> We have a proof of concept up and running for the wiki upgrade at: http://webtest.fedora.redhat.com/wiki We've got a little bit of work to do in testing, the two sites do look different. We need the web guys (and maybe the doc guys?) to look at the website and see what needs to be done and report whats broken. This is something we'd like to get out by the end of February so it will be ready for the Fedora 7 release. Patrick: Who from the website team would be a good point person to coordinate the upgrade with? -Mike From dimitris at glezos.com Mon Jan 22 21:44:18 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Mon, 22 Jan 2007 21:44:18 +0000 Subject: Wiki Upgrade In-Reply-To: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> Message-ID: <45B53032.6020603@glezos.com> O/H Mike McGrath ??????: > We have a proof of concept up and running for the wiki upgrade at: > > http://webtest.fedora.redhat.com/wiki > > We've got a little bit of work to do in testing, the two sites do look > different. On the new wiki we have applied some wiki/foo to enhance the usability of the website. For more info, refer to: http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning There is still some work to be done to "get it right". The page where the migration is coordinated is: http://fedoraproject.org/wiki/Infrastructure/WikiMigration > We need the web guys (and maybe the doc guys?) to look at the website > and see what needs to be done and report whats broken. This is > something we'd like to get out by the end of February so it will be > ready for the Fedora 7 release. I think end of February is a feasible target; although Paulo Santos (who handles the migration and has access to make changes) is the man to answer this. :) -d > Patrick: Who from the website team would be a good point person to > coordinate the upgrade with? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From sundaram at fedoraproject.org Mon Jan 22 22:04:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 23 Jan 2007 03:34:37 +0530 Subject: Wiki Upgrade In-Reply-To: <45B53032.6020603@glezos.com> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> <45B53032.6020603@glezos.com> Message-ID: <45B534F5.2080007@fedoraproject.org> Dimitris Glezos wrote: > O/H Mike McGrath ??????: >> We have a proof of concept up and running for the wiki upgrade at: >> >> http://webtest.fedora.redhat.com/wiki >> >> We've got a little bit of work to do in testing, the two sites do look >> different. > > On the new wiki we have applied some wiki/foo to enhance the usability of the > website. For more info, refer to: > > http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning > The icon to make external links stand out sticks out sorely. We probably could use another icon or something else to differentiate. Rahul From paulo.banon at googlemail.com Tue Jan 23 10:53:42 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Tue, 23 Jan 2007 11:53:42 +0100 Subject: Wiki Upgrade In-Reply-To: <369bce3b0701221508u56845af1jfc92530be5e69c3f@mail.gmail.com> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> <45B53032.6020603@glezos.com> <45B534F5.2080007@fedoraproject.org> <369bce3b0701221508u56845af1jfc92530be5e69c3f@mail.gmail.com> Message-ID: <7a41c4bc0701230253j5de5b0f9m6699b0bf0ca8c376@mail.gmail.com> Hi Thomas, The attachment link isnt in the drop down menu anymore. It is something that needs to be modified manually on the theme template. This was "done" indeed. But as you can probably see, the testing wiki got updated, so my changes were also overwriten. But this is not a big deal, since the link is just a line that needs to be added to the template, since the actual feature is working. Test with http://webtest.fedora.redhat.com/AnyPageYouWant?action=AttachFile Im currently without internet at home, so as soon as i have it back, i'll insert the line again. Also regarding the actual wiki upgrade, i say that we should upgrade it when everyone feels confortable with the new engine, and happy with the design. So, in my opinion is not me that should say when we migrate, it should be a wide decision by everyone involved. Thanks, Paulo On 1/23/07, Thomas Chung wrote: > > On 1/22/07, Rahul Sundaram wrote: > > Dimitris Glezos wrote: > > > O/H Mike McGrath ??????: > > >> We have a proof of concept up and running for the wiki upgrade at: > > >> > > >> http://webtest.fedora.redhat.com/wiki > > >> > > >> We've got a little bit of work to do in testing, the two sites do > look > > >> different. > > > > > > On the new wiki we have applied some wiki/foo to enhance the usability > of the > > > website. For more info, refer to: > > > > > > http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning > > > > > > > The icon to make external links stand out sticks out sorely. We probably > > could use another icon or something else to differentiate. > > Also, I still do not see "Attachments" option under "more actions" > drop down menu: > http://webtest.fedora.redhat.com/wiki > > It's odd that status shows "Done" at: > http://fedoraproject.org/wiki/Infrastructure/WikiMigration > > Regards, > -- > Thomas Chung > http://fedoraproject.org/wiki/ThomasChung > > -- > Fedora-websites-list mailing list > Fedora-websites-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-websites-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From email.ahmedkamal at googlemail.com Tue Jan 23 13:40:18 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 23 Jan 2007 15:40:18 +0200 Subject: Wiki Upgrade In-Reply-To: <7a41c4bc0701230253j5de5b0f9m6699b0bf0ca8c376@mail.gmail.com> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> <45B53032.6020603@glezos.com> <45B534F5.2080007@fedoraproject.org> <369bce3b0701221508u56845af1jfc92530be5e69c3f@mail.gmail.com> <7a41c4bc0701230253j5de5b0f9m6699b0bf0ca8c376@mail.gmail.com> Message-ID: <3da3b5b40701230540o97a1711ybb92f38c79802914@mail.gmail.com> Hi, I have updated the missing link for attachements. Let me know if I can help, till Paulo is back online. PS: I notice the bottom toolbar has the "python" link covered by the side bar on short pages like http://webtest.fedora.redhat.com/wiki/AhmedKamal On 1/23/07, Paulo Santos wrote: > > Hi Thomas, > > The attachment link isnt in the drop down menu anymore. It is something > that needs to be modified manually on the theme template. > This was "done" indeed. But as you can probably see, the testing wiki got > updated, so my changes were also overwriten. But this is not a big deal, > since the link is just a line that needs to be added to the template, since > the actual feature is working. > > Test with > http://webtest.fedora.redhat.com/AnyPageYouWant?action=AttachFile > Im currently without internet at home, so as soon as i have it back, i'll > insert the line again. > > Also regarding the actual wiki upgrade, i say that we should upgrade it > when everyone feels confortable with the new engine, and happy with the > design. So, in my opinion is not me that should say when we migrate, it > should be a wide decision by everyone involved. > > > Thanks, > Paulo > > On 1/23/07, Thomas Chung wrote: > > > > On 1/22/07, Rahul Sundaram wrote: > > > Dimitris Glezos wrote: > > > > O/H Mike McGrath ??????: > > > >> We have a proof of concept up and running for the wiki upgrade at: > > > >> > > > >> http://webtest.fedora.redhat.com/wiki > > > >> > > > >> We've got a little bit of work to do in testing, the two sites do > > look > > > >> different. > > > > > > > > On the new wiki we have applied some wiki/foo to enhance the > > usability of the > > > > website. For more info, refer to: > > > > > > > > http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning > > > > > > > > > > The icon to make external links stand out sticks out sorely. We > > probably > > > could use another icon or something else to differentiate. > > > > Also, I still do not see "Attachments" option under "more actions" > > drop down menu: > > http://webtest.fedora.redhat.com/wiki > > > > It's odd that status shows "Done" at: > > http://fedoraproject.org/wiki/Infrastructure/WikiMigration > > > > Regards, > > -- > > Thomas Chung > > http://fedoraproject.org/wiki/ThomasChung > > > > -- > > Fedora-websites-list mailing list > > Fedora-websites-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-websites-list > > > > > _______________________________________________ > 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 mmcgrath at fedoraproject.org Tue Jan 23 14:49:05 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 23 Jan 2007 08:49:05 -0600 Subject: Wiki Upgrade In-Reply-To: <7a41c4bc0701230253j5de5b0f9m6699b0bf0ca8c376@mail.gmail.com> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> <45B53032.6020603@glezos.com> <45B534F5.2080007@fedoraproject.org> <369bce3b0701221508u56845af1jfc92530be5e69c3f@mail.gmail.com> <7a41c4bc0701230253j5de5b0f9m6699b0bf0ca8c376@mail.gmail.com> Message-ID: <3237e4410701230649y4f9cd043t9710ef1b1afe5298@mail.gmail.com> On 1/23/07, Paulo Santos wrote: > Hi Thomas, > > The attachment link isnt in the drop down menu anymore. It is something that > needs to be modified manually on the theme template. > This was "done" indeed. But as you can probably see, the testing wiki got > updated, so my changes were also overwriten. But this is not a big deal, > since the link is just a line that needs to be added to the template, since > the actual feature is working. > Is there any easy way to prevent this from happening? I mean, we can test the test wiki all we want but will we have to re-do all the changes again when we do the permanent migration? Is there an easy way to avoid duplication of work? -Mike From paulo.banon at googlemail.com Tue Jan 23 15:14:02 2007 From: paulo.banon at googlemail.com (Paulo Santos) Date: Tue, 23 Jan 2007 16:14:02 +0100 Subject: Wiki Upgrade In-Reply-To: <3237e4410701230649y4f9cd043t9710ef1b1afe5298@mail.gmail.com> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> <45B53032.6020603@glezos.com> <45B534F5.2080007@fedoraproject.org> <369bce3b0701221508u56845af1jfc92530be5e69c3f@mail.gmail.com> <7a41c4bc0701230253j5de5b0f9m6699b0bf0ca8c376@mail.gmail.com> <3237e4410701230649y4f9cd043t9710ef1b1afe5298@mail.gmail.com> Message-ID: <7a41c4bc0701230714p4682385fv1c602867443e440b@mail.gmail.com> > Is there any easy way to prevent this from happening? I mean, we can > test the test wiki all we want but will we have to re-do all the > changes again when we do the permanent migration? Is there an easy > way to avoid duplication of work? > > -Mike > > -- > Fedora-websites-list mailing list > Fedora-websites-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-websites-list > Yes, we just need to restore the folowing directories inside data: - user (user logins, preferences, etc) - pages (actual wiki pages) and the following files also inside data: - edit-log (for the recent changes page) - view-log (some history about viewed pages, etc - not sure if we want to keep this) So lets plan the following, do a backup for the described folders and files next week (so that we can idenfify wiki changes), and drop them in webtest. The actual data should be updated, without loosing any modification to the actual engine/plugins/theme. What you guys think ? Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tchung at fedoraproject.org Mon Jan 22 23:08:38 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Mon, 22 Jan 2007 15:08:38 -0800 Subject: Wiki Upgrade In-Reply-To: <45B534F5.2080007@fedoraproject.org> References: <3237e4410701221029y519feebdi60a6224a463489a@mail.gmail.com> <45B53032.6020603@glezos.com> <45B534F5.2080007@fedoraproject.org> Message-ID: <369bce3b0701221508u56845af1jfc92530be5e69c3f@mail.gmail.com> On 1/22/07, Rahul Sundaram wrote: > Dimitris Glezos wrote: > > O/H Mike McGrath ??????: > >> We have a proof of concept up and running for the wiki upgrade at: > >> > >> http://webtest.fedora.redhat.com/wiki > >> > >> We've got a little bit of work to do in testing, the two sites do look > >> different. > > > > On the new wiki we have applied some wiki/foo to enhance the usability of the > > website. For more info, refer to: > > > > http://fedoraproject.org/wiki/DimitrisGlezos/WikiDesignTuning > > > > The icon to make external links stand out sticks out sorely. We probably > could use another icon or something else to differentiate. Also, I still do not see "Attachments" option under "more actions" drop down menu: http://webtest.fedora.redhat.com/wiki It's odd that status shows "Done" at: http://fedoraproject.org/wiki/Infrastructure/WikiMigration Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From mmcgrath at fedoraproject.org Tue Jan 23 16:27:34 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 23 Jan 2007 10:27:34 -0600 Subject: Official mirror requirements In-Reply-To: <45923466.7030406@fedoraproject.org> References: <45923466.7030406@fedoraproject.org> Message-ID: <3237e4410701230827i7bf5023xaef9889c3cac548b@mail.gmail.com> On 12/27/06, Rahul Sundaram wrote: > Hi > > What are the requirements other than bandwidth for the official mirrors > listed at http://fedora.redhat.com/Download/mirrors.html. In particular > do we require them to carry the complete copy including source images > and packages? If not we should probably enforce that or list the mirrors > which only have binary packages as partial mirrors. We can run some > routine checks in a period basis automatically to cross verify this. > > Rahul > I don't think there are bandwith requirements though we do regularly test the mirrors and if they are overloaded would time out. I think they can be somewhat selective (as in not a full copy of all of rawhide, testing, updates, etc) though it should be a requirement. We're currently re-writing a new mirror system that can address some of this stuff. But monitoring an entire mirror is difficult because you'd basically have to download it and md5sum everything which is horribly inefficient. Our checks are much simpler right now. -Mike From Matt_Domsch at dell.com Tue Jan 23 17:41:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 Jan 2007 11:41:45 -0600 Subject: Official mirror requirements In-Reply-To: <3237e4410701230827i7bf5023xaef9889c3cac548b@mail.gmail.com> References: <45923466.7030406@fedoraproject.org> <3237e4410701230827i7bf5023xaef9889c3cac548b@mail.gmail.com> Message-ID: <20070123174145.GA629@lists.us.dell.com> On Tue, Jan 23, 2007 at 10:27:34AM -0600, Mike McGrath wrote: > On 12/27/06, Rahul Sundaram wrote: > >Hi > > > >What are the requirements other than bandwidth for the official mirrors > >listed at http://fedora.redhat.com/Download/mirrors.html. In particular > >do we require them to carry the complete copy including source images > >and packages? If not we should probably enforce that or list the mirrors > >which only have binary packages as partial mirrors. We can run some > >routine checks in a period basis automatically to cross verify this. > > > >Rahul > > > > I don't think there are bandwith requirements though we do regularly > test the mirrors and if they are overloaded would time out. I think > they can be somewhat selective (as in not a full copy of all of > rawhide, testing, updates, etc) though it should be a requirement. > > We're currently re-writing a new mirror system that can address some > of this stuff. But monitoring an entire mirror is difficult because > you'd basically have to download it and md5sum everything which is > horribly inefficient. Our checks are much simpler right now. I'm working on it... :-) We don't force everyone to carry everything. Most folks don't carry Extras right now. Most folks carry only i386 and x86_64. A few only carry updates. And *everyone* uses a different URL to get to their content. Maintaining it manually is impossible anymore - hence the need for some software. See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement for what I've got in mind, a little of which already works. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From sundaram at fedoraproject.org Tue Jan 23 17:54:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 23 Jan 2007 23:24:36 +0530 Subject: Official mirror requirements In-Reply-To: <20070123174145.GA629@lists.us.dell.com> References: <45923466.7030406@fedoraproject.org> <3237e4410701230827i7bf5023xaef9889c3cac548b@mail.gmail.com> <20070123174145.GA629@lists.us.dell.com> Message-ID: <45B64BDC.5090700@fedoraproject.org> Matt Domsch wrote: > I'm working on it... :-) > > We don't force everyone to carry everything. Most folks don't carry > Extras right now. Most folks carry only i386 and x86_64. A few only > carry updates. And *everyone* uses a different URL to get to their > content. Maintaining it manually is impossible anymore - hence the > need for some software. > > See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement for > what I've got in mind, a little of which already works. > Thanks. The original mail was send by me long back before I subscribed to this list and has been struck on the moderation queue for a while I guess. I did find this page and added a note on source packages. It would very useful if the individual mirrors had a note clearly marking the type of access (http/ftp/rynsc), repositories (core/extras), architecture, source and binary packages and other details so users can quickly understand which mirror carry the content they want and how to access them. Rahul From Matt_Domsch at dell.com Tue Jan 23 18:07:20 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 Jan 2007 12:07:20 -0600 Subject: Official mirror requirements In-Reply-To: <45B64BDC.5090700@fedoraproject.org> References: <45923466.7030406@fedoraproject.org> <3237e4410701230827i7bf5023xaef9889c3cac548b@mail.gmail.com> <20070123174145.GA629@lists.us.dell.com> <45B64BDC.5090700@fedoraproject.org> Message-ID: <20070123180720.GB629@lists.us.dell.com> On Tue, Jan 23, 2007 at 11:24:36PM +0530, Rahul Sundaram wrote: > Matt Domsch wrote: > > >I'm working on it... :-) > > > >We don't force everyone to carry everything. Most folks don't carry > >Extras right now. Most folks carry only i386 and x86_64. A few only > >carry updates. And *everyone* uses a different URL to get to their > >content. Maintaining it manually is impossible anymore - hence the > >need for some software. > > > >See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement for > >what I've got in mind, a little of which already works. > > > > Thanks. The original mail was send by me long back before I subscribed > to this list and has been struck on the moderation queue for a while I > guess. I did find this page and added a note on source packages. It > would very useful if the individual mirrors had a note clearly marking > the type of access (http/ftp/rynsc), repositories (core/extras), > architecture, source and binary packages and other details so users can > quickly understand which mirror carry the content they want and how to > access them. Absolutely. And GeoIP, and ... The current mirror list is a mess. There are folks on it that aren't mirrors anymore. Some of the URLs are wrong. I bet it's missing some mirrors too. It really only lists Core, not Extras or anything else. When a release happens, everyone manually sends a "I'm synced" message which someone has to collect and include in the release announcement. All in all, a good opportunity for some nice software. Turns out, Debian's got something, though I haven't found the source for it yet. But they do a lot of what we would want, plus ftp..debian.org DNS maintenance which we don't have to do right now because we're using GeoIP to build the per-country yum lists. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From sundaram at fedoraproject.org Tue Jan 23 20:37:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 Jan 2007 02:07:10 +0530 Subject: LHCP vs Smolt Message-ID: <45B671F6.10203@fedoraproject.org> Hi Looks like we are duplicating efforts here. https://hosted.fedoraproject.org/projects/LHCP https://hosted.fedoraproject.org/projects/smolt Rahul From mmcgrath at fedoraproject.org Tue Jan 23 21:47:12 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 23 Jan 2007 15:47:12 -0600 Subject: LHCP vs Smolt In-Reply-To: <45B671F6.10203@fedoraproject.org> References: <45B671F6.10203@fedoraproject.org> Message-ID: <3237e4410701231347p1bb1909esb47240ae939433ee@mail.gmail.com> We're already in contact with eachother. It seems like duplication but actually we'll be excellent compliments to each other. We'll be working together probably very soon. -Mike On 1/23/07, Rahul Sundaram wrote: > Hi > > Looks like we are duplicating efforts here. > > https://hosted.fedoraproject.org/projects/LHCP > https://hosted.fedoraproject.org/projects/smolt > > Rahul > From mmcgrath at fedoraproject.org Tue Jan 23 17:37:57 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 23 Jan 2007 11:37:57 -0600 Subject: QA project and a Xen Host Message-ID: <3237e4410701230937x2f2cd86eqfc53123eb5ef086c@mail.gmail.com> We've only partially discussed this. wwoods has requested a Fedora QA project. http://fedoraproject.org/wiki/Infrastructure/RFR/QA He's going to fill out some more detailed goals and description but I wanted to hear if there are any objections to this. I'm strongly in favor of setting it up and letting them go at it. -Mike From dennis at ausil.us Tue Jan 23 22:30:19 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 23 Jan 2007 16:30:19 -0600 Subject: QA project and a Xen Host In-Reply-To: <3237e4410701230937x2f2cd86eqfc53123eb5ef086c@mail.gmail.com> References: <3237e4410701230937x2f2cd86eqfc53123eb5ef086c@mail.gmail.com> Message-ID: <200701231630.19646.dennis@ausil.us> On Tuesday 23 January 2007 11:37, Mike McGrath wrote: > We've only partially discussed this. wwoods has requested a Fedora QA > project. > > http://fedoraproject.org/wiki/Infrastructure/RFR/QA > > He's going to fill out some more detailed goals and description but I > wanted to hear if there are any objections to this. I'm strongly in > favor of setting it up and letting them go at it. Im in favour of this also -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From sundaram at fedoraproject.org Wed Jan 24 00:19:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 Jan 2007 05:49:11 +0530 Subject: Open archives? Message-ID: <45B6A5FF.7090909@fedoraproject.org> Hi Why is the archives of this list not public? If sensitive details are being discussed in this list, the list membership itself should be moderated which is not the case at present. If anyone can join the list, I dont see any harm in letting search engines and other services index the content. Rahul From mmcgrath at fedoraproject.org Wed Jan 24 01:15:56 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Tue, 23 Jan 2007 19:15:56 -0600 Subject: Open archives? In-Reply-To: <45B6A5FF.7090909@fedoraproject.org> References: <45B6A5FF.7090909@fedoraproject.org> Message-ID: <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> On 1/23/07, Rahul Sundaram wrote: > Hi > > Why is the archives of this list not public? If sensitive details are > being discussed in this list, the list membership itself should be > moderated which is not the case at present. If anyone can join the list, > I dont see any harm in letting search engines and other services index > the content. > We do have a private (invite only) list that we use for sensitive things though its rarely used, last message was in early November. I'm conflicted about this so I will defer to the community. Basically I guess what we're trying to accomplish is to let search engines index the list? -Mike From a.badger at gmail.com Wed Jan 24 01:24:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 23 Jan 2007 17:24:14 -0800 Subject: Open archives? In-Reply-To: <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> References: <45B6A5FF.7090909@fedoraproject.org> <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> Message-ID: <1169601854.5106.39.camel@localhost.localdomain> On Tue, 2007-01-23 at 19:15 -0600, Mike McGrath wrote: > On 1/23/07, Rahul Sundaram wrote: > > Hi > > > > Why is the archives of this list not public? If sensitive details are > > being discussed in this list, the list membership itself should be > > moderated which is not the case at present. If anyone can join the list, > > I dont see any harm in letting search engines and other services index > > the content. > > > > We do have a private (invite only) list that we use for sensitive > things though its rarely used, last message was in early November. > I'm conflicted about this so I will defer to the community. Basically > I guess what we're trying to accomplish is to let search engines index > the list? I don't have a problem with infrastructure-list being viewable by all. In fact, I probably would find it beneficial to have it available. As you say sysadmin-list exists if there's things that need to be discussed in true privacy. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed Jan 24 01:41:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 Jan 2007 07:11:27 +0530 Subject: Open archives? In-Reply-To: <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> References: <45B6A5FF.7090909@fedoraproject.org> <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> Message-ID: <45B6B947.6080606@fedoraproject.org> Mike McGrath wrote: > > We do have a private (invite only) list that we use for sensitive > things though its rarely used, last message was in early November. > I'm conflicted about this so I will defer to the community. Basically > I guess what we're trying to accomplish is to let search engines index > the list? More importantly increase visibility of the discussions going on here to the rest of the community. I originally thought this was a completely private list for the infrastructure team until you or someone in #fedora-admin said that there was a separate private list and this was a open one with just the archives being closed. I had Thomas Chung (of Fedoranews.org) ask me the same thing a couple of days back. There is good stuff being discussed here. Let is be visible. It makes it easier for me and others to know what is done and maybe that will attract more interest and contributors. Rahul From linux at elfshadow.net Wed Jan 24 03:27:29 2007 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Tue, 23 Jan 2007 22:27:29 -0500 Subject: Open archives? In-Reply-To: <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> References: <45B6A5FF.7090909@fedoraproject.org> <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> Message-ID: <45B6D221.3010802@elfshadow.net> Mike McGrath wrote: > We do have a private (invite only) list that we use for sensitive > things though its rarely used, last message was in early November. > I'm conflicted about this so I will defer to the community. Basically > I guess what we're trying to accomplish is to let search engines index > the list? As long as we still have the private (invite only) list for items of sensitive nature, which do seem to be relatively rare, I don't see a problem letting the archives for this list be open. --Jeffrey From jkeating at redhat.com Wed Jan 24 03:51:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Jan 2007 22:51:04 -0500 Subject: Open archives? In-Reply-To: <45B6D221.3010802@elfshadow.net> References: <45B6A5FF.7090909@fedoraproject.org> <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> <45B6D221.3010802@elfshadow.net> Message-ID: <200701232251.07741.jkeating@redhat.com> On Tuesday 23 January 2007 22:27, Jeffrey Tadlock wrote: > As long as we still have the private (invite only) list for items of > sensitive nature, which do seem to be relatively rare, I don't see a > problem letting the archives for this list be open. Well, except for the email harvesting. :/ -- Jesse Keating Release Engineer: Fedora -------------- 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 Wed Jan 24 06:41:12 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 23 Jan 2007 22:41:12 -0800 Subject: uid/gid in Accounts2 Schema Message-ID: <1169620872.5106.53.camel@localhost.localdomain> I just looked at the LDAP schema and noticed that there's no numeric userid/groupid field. We're going to need to carry over the userid and groupid from the database as those numerics are used in other databases that refer to records in the account system and on our servers as Unix uids. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeroen.janssen at gmail.com Wed Jan 24 09:29:43 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 24 Jan 2007 10:29:43 +0100 Subject: F7 & Infrastructure plan? Message-ID: Hi, I was wondering with the upcoming F7 Test1 Release on 30 January 2007 are there any things for the infrastructure that need to be done yet? On a side node is there a clear overview of the infrastructure deliverables in relation with the major milestones of F7 (on http://fedoraproject.org/wiki/Releases/7 )? Best regards, Jeroen Janssen From email.ahmedkamal at googlemail.com Wed Jan 24 11:47:23 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 24 Jan 2007 13:47:23 +0200 Subject: Yum deltarpm In-Reply-To: <1169142568.4377.95.camel@cutter> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> <1169142568.4377.95.camel@cutter> Message-ID: <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> I've been hacking on the code yesterday, and it seems I am hitting some sort of a bug. Basically, what happens is that the plugin starts, does its work, exits, yum tries installing the new rpm, it goes through the "updating" progress bar, then hangs before doing "cleanup" part?! The thing is, after the hang, all rpm based tools "rpm -q" "rpm -e" "rpm -i" anything, would just sit there stuck! Stracing this, and it is stopped at futex(0xb7988c3c, FUTEX_WAIT, 1, NULL I did find some bug reports about that https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145021 http://lists.centos.org/pipermail/centos-devel/2005-June/001890.html But it should be rare! In my case, this happens everytime. And I have to reboot to clear the lock! I'm probably not releasing the rpmDB lock somehow, anyone faced something similar before ? This is "yum -d 10" output Running Transaction Test Member: ImageMagick.i386 0-6.2.8.0-3.fc6.1 - u Adding Package ImageMagick - 6.2.8.0-3.fc6.1.i386 in mode u Finished Transaction Test Transaction Test Succeeded Member: ImageMagick.i386 0-6.2.8.0-3.fc6.1 - u Adding Package ImageMagick - 6.2.8.0-3.fc6.1.i386 in mode u Running Transaction Updating : ImageMagick ######################### [1/2] On 1/18/07, seth vidal wrote: > > On Thu, 2007-01-18 at 09:39 -0800, Toshio Kuratomi wrote: > > On Thu, 2007-01-18 at 09:53 +0200, Ahmed Kamal wrote: > > > Appreciating everyone's help, it seems others have attempted this > > > before. Anyway, let's put this through the test of time :) Also, I > > > totally agree with keeping drpms only if they meet certain criteria, > > > i.e. provide >50% savings or similar. > > > > > > Right now, I am trying to figure out how/where the server side will > > > store the drpm metadata. Other.xml.gz seems like a good place, or > > > maybe a new drpm.xml.gz, but I am not sure how such file should be > > > written. > > > > I seem to recall that primary.xml.gz can list arbitrary xml files which > > the depsolvers will ignore if they don't need them but Seth would know > > better. > > repomd.xml can list additional files, not primary - but the result is > the same. > > You'd want to tie knowledge of drpms into createrepo. > > > > Are you writing this from scratch? If it's using the yum plugin that > > already exists it might be expecting the metadata in a specific format > > already. > > plugins can do whatever, pretty much, when it comes to what kind of > metadata they want to deal with. > > -sv > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Wed Jan 24 12:43:46 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 24 Jan 2007 06:43:46 -0600 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <200701131406.01077.dennis@ausil.us> <45AE401C.9090707@redhat.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> <1169142568.4377.95.camel@cutter> <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> Message-ID: <45B75482.3070206@math.unl.edu> Ahmed Kamal wrote: > I've been hacking on the code yesterday, and it seems I am hitting > some sort of a bug. ... > But it should be rare! In my case, this happens everytime. And I have > to reboot to clear the lock! rm -f /var/lib/rpm/__db.* doesn't work? -- Rex From jeroen.janssen at gmail.com Wed Jan 24 21:40:04 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 24 Jan 2007 22:40:04 +0100 Subject: Fedora Core 6 + Updates + Extras Respin size = 6Gb Message-ID: Hi, Just FYI, I build a Fedora Core 6 + Updates + Extras "respin" and the total DVD iso is currently 6Gb (I used pungi to build it, but I haven't used the resulting DVD for installation yet). I think with the impending merging of core & extras in F7, this means people either have to use dual-layer DVDs or there need to be two DVDs for installation purposes. (or someone needs to 'cut-down' the number of packages in F7 to get in to fit on 1 DVD). I also ended with about 10 CD isos, but I'm not going to use them. Best regards, Jeroen Janssen From jkeating at redhat.com Wed Jan 24 21:52:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Jan 2007 16:52:55 -0500 Subject: Fedora Core 6 + Updates + Extras Respin size = 6Gb In-Reply-To: References: Message-ID: <200701241652.55358.jkeating@redhat.com> On Wednesday 24 January 2007 16:40, Jeroen Janssen wrote: > Just FYI, I build a Fedora Core 6 + Updates + Extras "respin" and the > total DVD iso is currently 6Gb (I used pungi to build it, but I > haven't used the resulting DVD for installation yet). > > I think with the impending merging of core & extras in F7, this means > people either have to use dual-layer DVDs or there need to be two DVDs > for installation purposes. (or someone needs to 'cut-down' the number > of packages in F7 to get in to fit on 1 DVD). > > I also ended with about 10 CD isos, but I'm not going to use them. We aren't doing spins of "everything in the collection" anymore. We're doing targetted spins, such as Fedora 7 Desktop, or Fedora 7 KDE, or Fedora 7 Server. Those will be even smaller than what FC6 was. -- Jesse Keating Release Engineer: Fedora -------------- 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 fedoraproject.org Wed Jan 24 21:55:39 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 24 Jan 2007 15:55:39 -0600 Subject: Fedora Core 6 + Updates + Extras Respin size = 6Gb In-Reply-To: <200701241652.55358.jkeating@redhat.com> References: <200701241652.55358.jkeating@redhat.com> Message-ID: <3237e4410701241355p505eb3fdrcbe0c892ef2f46a7@mail.gmail.com> On 1/24/07, Jesse Keating wrote: > On Wednesday 24 January 2007 16:40, Jeroen Janssen wrote: > > Just FYI, I build a Fedora Core 6 + Updates + Extras "respin" and the > > total DVD iso is currently 6Gb (I used pungi to build it, but I > > haven't used the resulting DVD for installation yet). > > > > I think with the impending merging of core & extras in F7, this means > > people either have to use dual-layer DVDs or there need to be two DVDs > > for installation purposes. (or someone needs to 'cut-down' the number > > of packages in F7 to get in to fit on 1 DVD). > > > > I also ended with about 10 CD isos, but I'm not going to use them. > > We aren't doing spins of "everything in the collection" anymore. We're doing > targetted spins, such as Fedora 7 Desktop, or Fedora 7 KDE, or Fedora 7 > Server. Those will be even smaller than what FC6 was. > Is it our intention that people will pick whats right and add on via network? -Mike From email.ahmedkamal at googlemail.com Wed Jan 24 21:58:33 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 24 Jan 2007 23:58:33 +0200 Subject: Yum deltarpm In-Reply-To: <45B75482.3070206@math.unl.edu> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> <1169142568.4377.95.camel@cutter> <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> <45B75482.3070206@math.unl.edu> Message-ID: <3da3b5b40701241358w6e5f3dddtbfd0a6eadf8d124f@mail.gmail.com> that does help, I can clear the lock without rebooting anymore! but, the rpm hanging still happens every time. Not sure what's causing the issue though. On 1/24/07, Rex Dieter wrote: > > Ahmed Kamal wrote: > > I've been hacking on the code yesterday, and it seems I am hitting > > some sort of a bug. > ... > > But it should be rare! In my case, this happens everytime. And I have > > to reboot to clear the lock! > > rm -f /var/lib/rpm/__db.* > doesn't work? > > -- Rex > > _______________________________________________ > 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 jkeating at redhat.com Wed Jan 24 22:08:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Jan 2007 17:08:13 -0500 Subject: Fedora Core 6 + Updates + Extras Respin size = 6Gb In-Reply-To: <3237e4410701241355p505eb3fdrcbe0c892ef2f46a7@mail.gmail.com> References: <200701241652.55358.jkeating@redhat.com> <3237e4410701241355p505eb3fdrcbe0c892ef2f46a7@mail.gmail.com> Message-ID: <200701241708.17211.jkeating@redhat.com> On Wednesday 24 January 2007 16:55, Mike McGrath wrote: > Is it our intention that people will pick whats right and add on via > network? That's what we're thinking yes. If what you want isn't on the CD set, the installer has an "Enable complete Collection repository" or some such wording that gives you access to the repo that is everything. The package selection UI will fill in with what is available and listed in comps. Not every single package is accessable, as they aren't all listed in comps (for various reasons). -- Jesse Keating Release Engineer: Fedora -------------- 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 Wed Jan 24 23:19:47 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 24 Jan 2007 15:19:47 -0800 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701241358w6e5f3dddtbfd0a6eadf8d124f@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> <1169142568.4377.95.camel@cutter> <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> <45B75482.3070206@math.unl.edu> <3da3b5b40701241358w6e5f3dddtbfd0a6eadf8d124f@mail.gmail.com> Message-ID: <1169680787.5106.80.camel@localhost.localdomain> On Wed, 2007-01-24 at 23:58 +0200, Ahmed Kamal wrote: > that does help, I can clear the lock without rebooting anymore! but, > the rpm hanging still happens every time. Not sure what's causing the > issue though. Do your scripts leave the constructed rpms around somewhere? You might want to rpm -K to see if the checksums match. Then rpm -qpi to make sure it was signed with the correct key. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From matt at gillens.us Wed Jan 24 23:47:15 2007 From: matt at gillens.us (Matthew Gillen) Date: Wed, 24 Jan 2007 18:47:15 -0500 Subject: Yum deltarpm In-Reply-To: <3da3b5b40701241358w6e5f3dddtbfd0a6eadf8d124f@mail.gmail.com> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701170729s6adb2ae3p5f9ebca6e6b69b29@mail.gmail.com> <1169047872.4377.8.camel@cutter> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> <1169142568.4377.95.camel@cutter> <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> <45B75482.3070206@math.unl.edu> <3da3b5b40701241358w6e5f3dddtbfd0a6eadf8d124f@mail.gmail.com> Message-ID: <45B7F003.9080002@gillens.us> RPM's DB backend gets wedged sometimes. It's become a lot less common than it used to be, but it just happened to me again recently. A solution (maybe not the best) is to rebuild the database. I have a script that does the following: $ cat fixrpmdb.sh #!/bin/sh rm -f /var/lib/rpm/__db* rpm -vv --rebuilddb The '-vv' makes it take longer, but I like it so that I can be sure it's doing something. Hope that helps, Matt Ahmed Kamal wrote: > that does help, I can clear the lock without rebooting anymore! but, the > rpm hanging still happens every time. Not sure what's causing the issue > though. > > On 1/24/07, * Rex Dieter* > wrote: > > Ahmed Kamal wrote: > > I've been hacking on the code yesterday, and it seems I am hitting > > some sort of a bug. > ... > > But it should be rare! In my case, this happens everytime. And I have > > to reboot to clear the lock! > > rm -f /var/lib/rpm/__db.* > doesn't work? > > -- Rex > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From email.ahmedkamal at googlemail.com Wed Jan 24 23:55:36 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 25 Jan 2007 01:55:36 +0200 Subject: Yum deltarpm In-Reply-To: <45B7F003.9080002@gillens.us> References: <3da3b5b40701121201s2aa1bbe6tf152cc3de14f0d22@mail.gmail.com> <3237e4410701170734r3f2fb81bnb40614773b91db9@mail.gmail.com> <1169091316.14225.14.camel@localhost.localdomain> <3da3b5b40701172353k57dfdc10x9f419d137e9fae1a@mail.gmail.com> <1169141990.14225.51.camel@localhost.localdomain> <1169142568.4377.95.camel@cutter> <3da3b5b40701240347y5a791ea5se9ef07a37306797f@mail.gmail.com> <45B75482.3070206@math.unl.edu> <3da3b5b40701241358w6e5f3dddtbfd0a6eadf8d124f@mail.gmail.com> <45B7F003.9080002@gillens.us> Message-ID: <3da3b5b40701241555u4dd6c8c5k872148ad4513402d@mail.gmail.com> Thanks guys, I finally came to the conclusion that the problem was not the python code, but rather the applydeltarpm command that was touching the DB in some wrong way causing it to lockup. I confirmed this by writing a trivial yum plugin that only ran the command using direct on disk files, and yum still hung! BTW, yes, the constructed rpm does pass all signature checks. I'm currently investigating what's causing the issue inside applydeltarpm. On 1/25/07, Matthew Gillen wrote: > > RPM's DB backend gets wedged sometimes. It's become a lot less common > than > it used to be, but it just happened to me again recently. A solution > (maybe > not the best) is to rebuild the database. I have a script that does the > following: > $ cat fixrpmdb.sh > #!/bin/sh > rm -f /var/lib/rpm/__db* > rpm -vv --rebuilddb > > The '-vv' makes it take longer, but I like it so that I can be sure it's > doing something. > > Hope that helps, > Matt > > Ahmed Kamal wrote: > > that does help, I can clear the lock without rebooting anymore! but, the > > rpm hanging still happens every time. Not sure what's causing the issue > > though. > > > > On 1/24/07, * Rex Dieter* > > wrote: > > > > Ahmed Kamal wrote: > > > I've been hacking on the code yesterday, and it seems I am hitting > > > some sort of a bug. > > ... > > > But it should be rare! In my case, this happens everytime. And I > have > > > to reboot to clear the lock! > > > > rm -f /var/lib/rpm/__db.* > > doesn't work? > > > > -- Rex > > > > _______________________________________________ > > Fedora-infrastructure-list mailing list > > Fedora-infrastructure-list at redhat.com > > > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 mmcgrath at fedoraproject.org Thu Jan 25 02:54:43 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 24 Jan 2007 20:54:43 -0600 Subject: Open archives? In-Reply-To: <200701232251.07741.jkeating@redhat.com> References: <45B6A5FF.7090909@fedoraproject.org> <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> <45B6D221.3010802@elfshadow.net> <200701232251.07741.jkeating@redhat.com> Message-ID: <3237e4410701241854n68cdf9a9wb38e0854ac6dbe95@mail.gmail.com> On 1/23/07, Jesse Keating wrote: > On Tuesday 23 January 2007 22:27, Jeffrey Tadlock wrote: > > As long as we still have the private (invite only) list for items of > > sensitive nature, which do seem to be relatively rare, I don't see a > > problem letting the archives for this list be open. > > Well, except for the email harvesting. :/ > Luke, if you wouldn't mind.... Make it so :-D -Mike From lmacken at redhat.com Fri Jan 26 22:57:38 2007 From: lmacken at redhat.com (Luke Macken) Date: Fri, 26 Jan 2007 17:57:38 -0500 Subject: Open archives? In-Reply-To: <3237e4410701241854n68cdf9a9wb38e0854ac6dbe95@mail.gmail.com> References: <45B6A5FF.7090909@fedoraproject.org> <3237e4410701231715v4ad0a2c7wcff8005428e241ae@mail.gmail.com> <45B6D221.3010802@elfshadow.net> <200701232251.07741.jkeating@redhat.com> <3237e4410701241854n68cdf9a9wb38e0854ac6dbe95@mail.gmail.com> Message-ID: <20070126225738.GD30218@tomservo.rh.rit.edu> On Wed, Jan 24, 2007 at 08:54:43PM -0600, Mike McGrath wrote: > On 1/23/07, Jesse Keating wrote: > >On Tuesday 23 January 2007 22:27, Jeffrey Tadlock wrote: > >> As long as we still have the private (invite only) list for items of > >> sensitive nature, which do seem to be relatively rare, I don't see a > >> problem letting the archives for this list be open. > > > >Well, except for the email harvesting. :/ > > > > Luke, if you wouldn't mind.... Make it so :-D fedora-infrastructure-list archives are now public. luke From mmcgrath at fedoraproject.org Mon Jan 29 00:44:18 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Sun, 28 Jan 2007 18:44:18 -0600 Subject: Hackfest schedule Message-ID: <3237e4410701281644j7eaf6a7er5cdfca909faaacb8@mail.gmail.com> http://fedoraproject.org/wiki/Infrastructure/HackFest2007 Here's the schedule, please add anything you'd like to work on if you're going to be there. Those that know what time they'd like to work on their specific projects should include it on this page so others know when to show up if they want to help. Does anyone know the status of Brew? I seem to remember someone mentioning that the scheme would be availble already. -Mike From a.badger at gmail.com Mon Jan 29 02:14:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 28 Jan 2007 18:14:04 -0800 Subject: Hackfest schedule In-Reply-To: <3237e4410701281644j7eaf6a7er5cdfca909faaacb8@mail.gmail.com> References: <3237e4410701281644j7eaf6a7er5cdfca909faaacb8@mail.gmail.com> Message-ID: <1170036844.18675.63.camel@localhost.localdomain> On Sun, 2007-01-28 at 18:44 -0600, Mike McGrath wrote: > http://fedoraproject.org/wiki/Infrastructure/HackFest2007 > > Here's the schedule, please add anything you'd like to work on if > you're going to be there. Those that know what time they'd like to > work on their specific projects should include it on this page so > others know when to show up if they want to help. > > Does anyone know the status of Brew? I seem to remember someone > mentioning that the scheme would be availble already. I asked Jesse about it early last week (Tuesday?) and he said it as still held up in legal. I was hoping we'd have the schema before FudCon and brew itself at FudCon but only Jesse knows if that's still possible. If Brew isn't available for FudCon, I'd like to at least walk away with some plan for how we're going to integrate the packageDB and brew stuff when it does become available. That would be easier if you were already within the Red Hat walls and had looked at Brew but maybe katzj/notting/f13 can smuggle out some screenshots or man pages or something :-). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Tue Jan 30 23:05:45 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 30 Jan 2007 17:05:45 -0600 Subject: rawhide rebuilds on ppc? Message-ID: <20070130230545.GB23729@lists.us.dell.com> dwmw2 asked me if I could do my full rawhide rebuilds on PPC as well as x86_64 and i386. I don't have ppc hardware, and he doesn't have ppc hardware with enough disk space or a local rawhide mirror. :-) As it's just some scripts that call mock, could I run those on the ppc Extras builders in PHX? They use --uniqueext so they can't conflict with a normal Plague build job. Would need some disk space for the results directory (~20GB), and be able to export the results via a web server. I'd still do the i386 and x86_64 builds in my lab here as I have been. Thoughts? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Ryan.Ordway at oregonstate.edu Wed Jan 31 01:09:52 2007 From: Ryan.Ordway at oregonstate.edu (Ordway, Ryan) Date: Tue, 30 Jan 2007 17:09:52 -0800 Subject: back In-Reply-To: <20070130230545.GB23729@lists.us.dell.com> References: <20070130230545.GB23729@lists.us.dell.com> Message-ID: I've been out of it for a few months, but it looks like I should have some more time to devote to FI. I'm digging through my e-mail to find out what's been going on, looks like I've missed a lot. ;-) Ryan -- Ryan Ordway Unix Systems Administrator OSU Libraries E-mail: ryan.ordway at oregonstate.edu 121 The Valley Library Corvallis, OR 97331 Office: VLIB #4657 From ask at develooper.com Wed Jan 31 01:44:26 2007 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue, 30 Jan 2007 17:44:26 -0800 Subject: rawhide rebuilds on ppc? In-Reply-To: <20070130230545.GB23729@lists.us.dell.com> References: <20070130230545.GB23729@lists.us.dell.com> Message-ID: <98B8E198-D891-4FF2-BD6E-F612FD32A806@develooper.com> On Jan 30, 2007, at 15:05, Matt Domsch wrote: What kind of maintenance does the build system require? I have a currently unused Xserve G4 that I could install Linux ppc on. - ask -- http://develooper.com/ - http://askask.com/ From notting at redhat.com Wed Jan 31 02:01:57 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Jan 2007 21:01:57 -0500 Subject: rawhide rebuilds on ppc? In-Reply-To: <20070130230545.GB23729@lists.us.dell.com> References: <20070130230545.GB23729@lists.us.dell.com> Message-ID: <20070131020157.GB18505@nostromo.devel.redhat.com> Matt Domsch (Matt_Domsch at dell.com) said: > dwmw2 asked me if I could do my full rawhide rebuilds on PPC as well > as x86_64 and i386. I don't have ppc hardware, and he doesn't have > ppc hardware with enough disk space or a local rawhide mirror. :-) > > As it's just some scripts that call mock, could I run those on the ppc > Extras builders in PHX? They use --uniqueext so they can't conflict > with a normal Plague build job. Would need some disk space for the > results directory (~20GB), and be able to export the results via a web > server. My concern would be overloading the Extras builders, but I suppose we wouldn't know how bad that would be unless we tried. Bill From dennis at ausil.us Wed Jan 31 02:27:14 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 30 Jan 2007 20:27:14 -0600 Subject: rawhide rebuilds on ppc? In-Reply-To: <20070130230545.GB23729@lists.us.dell.com> References: <20070130230545.GB23729@lists.us.dell.com> Message-ID: <200701302027.14351.dennis@ausil.us> Once upon a time Tuesday 30 January 2007 5:05 pm, Matt Domsch wrote: > dwmw2 asked me if I could do my full rawhide rebuilds on PPC as well > as x86_64 and i386. I don't have ppc hardware, and he doesn't have > ppc hardware with enough disk space or a local rawhide mirror. :-) > > As it's just some scripts that call mock, could I run those on the ppc > Extras builders in PHX? They use --uniqueext so they can't conflict > with a normal Plague build job. Would need some disk space for the > results directory (~20GB), and be able to export the results via a web > server. > > I'd still do the i386 and x86_64 builds in my lab here as I have been. > > Thoughts? personally i would pefer to take one builder offline and let you use it. probably either ppc2 or 3 they have a little more ram than ppc1 all three of them are 4 cpu boxes. plague uses --uniqueext with a job id we would need to set up the proxy to serve up the data. Dennis From imlinux at gmail.com Wed Jan 31 02:34:46 2007 From: imlinux at gmail.com (Mike McGrath) Date: Tue, 30 Jan 2007 20:34:46 -0600 Subject: back In-Reply-To: References: <20070130230545.GB23729@lists.us.dell.com> Message-ID: <3237e4410701301834gd9e99me203d2bfd91f1134@mail.gmail.com> On 1/30/07, Ordway, Ryan wrote: > > I've been out of it for a few months, but it looks like I should have > some more time to devote to FI. I'm digging through my e-mail to find > out what's been going on, looks like I've missed a lot. ;-) > Welcome back Ryah! -Mike From dennis at ausil.us Wed Jan 31 03:13:10 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 30 Jan 2007 21:13:10 -0600 Subject: rawhide rebuilds on ppc? In-Reply-To: <3237e4410701301853s2b3a20d4h51a7d3bc84021ec3@mail.gmail.com> References: <20070130230545.GB23729@lists.us.dell.com> <200701302027.14351.dennis@ausil.us> <3237e4410701301853s2b3a20d4h51a7d3bc84021ec3@mail.gmail.com> Message-ID: <200701302113.10946.dennis@ausil.us> Once upon a time Tuesday 30 January 2007 8:53 pm, Mike McGrath wrote: > On 1/30/07, Dennis Gilmore wrote: > > personally i would pefer to take one builder offline and let you use it. > > probably either ppc2 or 3 they have a little more ram than ppc1 all > > three of them are 4 cpu boxes. > > > > plague uses --uniqueext with a job id we would need to set up the proxy > > to serve up the data. > > How many plague instances do we allow to be built at once on the ppc > boxes? Would it make sense to increase it? one plague instance per system. each one is configured to build one package at a time per cpu so the ppc builders will do 4 at a time and the x86_64/i386 builders will do 2 at a time i dont think it makes any sense to do more than that. Dennis From Matt_Domsch at dell.com Wed Jan 31 04:04:05 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 30 Jan 2007 22:04:05 -0600 Subject: rawhide rebuilds on ppc? In-Reply-To: <98B8E198-D891-4FF2-BD6E-F612FD32A806@develooper.com> References: <20070130230545.GB23729@lists.us.dell.com> <98B8E198-D891-4FF2-BD6E-F612FD32A806@develooper.com> Message-ID: <20070131040405.GA12454@lists.us.dell.com> On Tue, Jan 30, 2007 at 05:44:26PM -0800, Ask Bj?rn Hansen wrote: > > On Jan 30, 2007, at 15:05, Matt Domsch wrote: > > What kind of maintenance does the build system require? I have a > currently unused Xserve G4 that I could install Linux ppc on. It took just a little tweaking after not touching it since FC6's release. Mostly code cleanups to deal with the fact that my mock config files are named 'fedora-devel-i386-core.cfg' yet they cause directories named 'fedora-development-i386-core' to get created in various places. :-) The whole system is just a set of shell scripts that essentially do: for each SRPM in rawhide: setarch i386 mock ... mock .... if successful, generate some logs generate stats rsync to a web server send email I tried to abstract out things like "directory where SRPMS live" and "what arches should I build for" into shell variables, but I very much expect to have the whole rawhide tree NFS-mounted. Would take some work to use remote repos instead. Something like 20 invocations of ls or find on various parts at various times. It took ~60 hours to build core+extras, i386 and x86_64, on 4 dual-socket dual-core servers with 2-4GB RAM each and 2.8-3.6GHz Xeons. Would presumably take nearly a week on a single ppc at first, and a few hours the daily runs which are just incremental. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From imlinux at gmail.com Wed Jan 31 02:53:13 2007 From: imlinux at gmail.com (Mike McGrath) Date: Tue, 30 Jan 2007 20:53:13 -0600 Subject: rawhide rebuilds on ppc? In-Reply-To: <200701302027.14351.dennis@ausil.us> References: <20070130230545.GB23729@lists.us.dell.com> <200701302027.14351.dennis@ausil.us> Message-ID: <3237e4410701301853s2b3a20d4h51a7d3bc84021ec3@mail.gmail.com> On 1/30/07, Dennis Gilmore wrote: > personally i would pefer to take one builder offline and let you use it. > probably either ppc2 or 3 they have a little more ram than ppc1 all three > of them are 4 cpu boxes. > > plague uses --uniqueext with a job id we would need to set up the proxy to > serve up the data. > How many plague instances do we allow to be built at once on the ppc boxes? Would it make sense to increase it? -Mike From mmcgrath at fedoraproject.org Wed Jan 31 17:04:50 2007 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 31 Jan 2007 11:04:50 -0600 Subject: Mirror manager and Xen Message-ID: <3237e4410701310904v218d68a4ve9625894038dc16e@mail.gmail.com> Matt has requested a public xen guest for Mirror Management. Anyone have issues with this? http://fedoraproject.org/wiki/Infrastructure/RFR/wiki/Infrastructure/RFR/MirrorManager -Mike From Matt_Domsch at dell.com Wed Jan 31 19:42:11 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 Jan 2007 13:42:11 -0600 Subject: Mirror manager and Xen In-Reply-To: <3237e4410701310904v218d68a4ve9625894038dc16e@mail.gmail.com> References: <3237e4410701310904v218d68a4ve9625894038dc16e@mail.gmail.com> Message-ID: <20070131194211.GA20028@lists.us.dell.com> On Wed, Jan 31, 2007 at 11:04:50AM -0600, Mike McGrath wrote: > Matt has requested a public xen guest for Mirror Management. Anyone > have issues with this? > > http://fedoraproject.org/wiki/Infrastructure/RFR/wiki/Infrastructure/RFR/MirrorManager Moved to the more appropriate http://fedoraproject.org/wiki/Infrastructure/RFR/MirrorManager /me loves wiki editing... -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com