From rnorwood at redhat.com Tue Jul 1 17:17:56 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 1 Jul 2008 13:17:56 -0400 Subject: Advice on deploying wsgi app using jsonfas In-Reply-To: <20080630171804.3f9adadc@solitude.devel.redhat.com> References: <20080630171804.3f9adadc@solitude.devel.redhat.com> Message-ID: <20080701131756.28b7df26@solitude.devel.redhat.com> On Mon, 30 Jun 2008 17:18:04 -0400 Robin Norwood wrote: > Unable to write to session file /var/www/.fedora_session: [Errno 13] > Permission denied: '/var/www/.fedora_session' Ok, I think I figured this out a bit more. When Toshio gave me code to do the FAS stuff, he included a class called 'UserCache'. Setting this up is what was triggering the creation of the evil .fedora_session file. Just getting rid of the code that sets up the cache seems to be enough to get me working again, and users can still log in. I'm not sure what the performance implications are, but I can discuss with Toshio when he gets back. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From poelstra at redhat.com Tue Jul 1 20:46:27 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 01 Jul 2008 13:46:27 -0700 Subject: Red Hat (Fedora) Bugzilla 3.2 Upgrade on July 26th, 2008 Message-ID: <486A97A3.6090506@redhat.com> I'm sending this on behalf of Dave Lawrence and the bugzilla team at Red Hat. Fedora uses this instance of bugilla too. Please forward this on to people or groups I missed. Thank you, John ------------------------------- Greetings, The Red Hat Bugzilla team is happy to announce that the release of the next version of Red Hat Bugzilla will occur on July 26th, 2008. The next version will be based on the upcoming upstream 3.2 code base soon to be released. For previewing the next release please go to: https://partner-bugzilla.redhat.com We encourage everyone to please go to the above site and provide any final testing and feedback where possible. Please verify that the features you have come to reply on day to day in our current Bugzilla are still available and working properly. Please use the new UI and make sure that you can accomplish the same tasks. Do not worry about making changes, this is a test snapshot and is not live data. Also emails will not be sent for changes so do what you like. Also please make sure your stored queries/reports/whines still work and display as expected. Some notable changes since 2.18: Ajax optimizations on searching and displaying bug Improved needinfo actor support Changed guided bug entry UI enhancements XMLRPC API: New API plus compatibility with old API. (please verify your scripts that use XMLRPC against the test system before the release date) There are numerous other changes behind the scenes that we haven't listed. The goal is to make sure that functionality that people have come to expect in 2.18 is possible in the new system. There are also numerous new features/fixes that are part of the upcoming 3.2 release provided by the upstream Bugzilla community. For more detailed information on what has changed since the last release, check out the Release Notes. We have done extensive work at laying out what we feel the requirements are to maintain feature parity with our current system as well as compiled a list of feature enhancements that people would like to see in the next release. Our goal is to deliver a working bugzilla with the bare essential requirements similar to what is currently being used in our current 2.18 system. After that we will begin work on enhancements as time and resources permit. To view the final release requirements list please refer to our Bugzilla 3 Tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=406071. Please file any enhancement requests or bug reports in our current Bugzilla system at bugzilla.redhat.com. File them under the Bugzilla product and relevant component with the version 3.2. Also send questions to bugzilla-owner at redhat.com. With everyone's help we can make this a great release. Thanks The Red Hat Bugzilla Team From aphukan at fedoraproject.org Wed Jul 2 13:51:03 2008 From: aphukan at fedoraproject.org (Amitakhya Phukan) Date: Wed, 2 Jul 2008 19:21:03 +0530 Subject: hello Message-ID: <980ad8bc0807020651q3bd06fdbgf1b67c5b13d34daa@mail.gmail.com> hi people! i was away for a long time and now i am back. i am looking forward to contributing to fedora infrastructure now and am looking for some work :) can anyone please help me out here ? regards, amit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Wed Jul 2 14:44:42 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Jul 2008 09:44:42 -0500 (CDT) Subject: hello In-Reply-To: <980ad8bc0807020651q3bd06fdbgf1b67c5b13d34daa@mail.gmail.com> References: <980ad8bc0807020651q3bd06fdbgf1b67c5b13d34daa@mail.gmail.com> Message-ID: On Wed, 2 Jul 2008, Amitakhya Phukan wrote: > hi people! > > i was away for a long time and now i am back. i am looking forward to contributing to fedora infrastructure now and am > looking for some work :) > > can anyone please help me out here ? > Sounds like you need a sponsor! Which FIG are you interested in? -Mike From aphukan.fedora at gmail.com Thu Jul 3 06:52:13 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Thu, 03 Jul 2008 12:22:13 +0530 Subject: hello In-Reply-To: References: <980ad8bc0807020651q3bd06fdbgf1b67c5b13d34daa@mail.gmail.com> Message-ID: <486C771D.8090101@gmail.com> Mike McGrath wrote: > On Wed, 2 Jul 2008, Amitakhya Phukan wrote: > > >> hi people! >> >> i was away for a long time and now i am back. i am looking forward to contributing to fedora infrastructure now and am >> looking for some work :) >> >> can anyone please help me out here ? >> >> > > Sounds like you need a sponsor! Which FIG are you interested in? > > -Mike hi, sysadmin-test and sysadmin-hosted interest me as of now. regards, amit. From sbathe at redhat.com Fri Jul 4 06:08:04 2008 From: sbathe at redhat.com (Saurabh Bathe) Date: Fri, 04 Jul 2008 11:38:04 +0530 Subject: Need a hand... In-Reply-To: <935ead450806160505n6de3514ds48f26110e8148b74@mail.gmail.com> References: <935ead450806160505n6de3514ds48f26110e8148b74@mail.gmail.com> Message-ID: <486DBE44.2000604@redhat.com> Jeffrey Ollie wrote: > On Sun, Jun 15, 2008 at 8:38 PM, Mike McGrath wrote: >> Anyone in the sysadmin-hosted group able to work on this project? >> >> https://fedorahosted.org/fedora-infrastructure/ticket/508 > > And actually, if someone wanted to split that ticket into multiple > requests (maybe even the OP) it'd be easier to track which ones have > been done. I have worked on the conversion of these projects from their CVS to SVN. I have SVN dumpfiles, what next? I think this is also time that I say I would like to be a active helper in the group. I have been doing general sysadmin stuff for about 5-6 years now. Quite good with Apache/Tomcat/Mail/LDAP/Nagios. Can do bash/perl. Have maintained CVS and svn (though I would not say I am an expert or know a lot there). Understand a bit of Puppet and Xen. For Fedora Infrastructure, I think I would be helpful in sysadmin-hosted, sysadmin-cvs, sysadmin-web. But am willing to work on whatever else needs to get done :). -- Thanks, Saurabh Bathe Senior Systems Administrator Red Hat, Inc From timothyb at opensourceaddict.com Sat Jul 5 12:56:02 2008 From: timothyb at opensourceaddict.com (Timothy Buck) Date: Sat, 5 Jul 2008 05:56:02 -0700 Subject: Introduction for timothyb Message-ID: <43796e4c0807050556v1624ff2y20aa828a80e500ec@mail.gmail.com> Hello everyone, My name is Timothy andI am a 23 years old who lives in the Reno/Tahoe area. I have been using linux/unix in some fashion for the past 4 years, from setting up a webserver to host websites for friends to my current day job of administering red hat 3/4/5 servers for a large online retail company. I am however a networking junkie at heart and spend a fair amount of time working with cisco devices. I currently have my ccna and am activly pursuing my ccnp. I started programming with php and have since moved on to learning python... however I am not as skilled in it as I would like but am working on it. Anything else anyone wants to know just ask. Thanks for your time everyone, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Sat Jul 5 17:36:11 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 5 Jul 2008 12:36:11 -0500 (CDT) Subject: Need a hand... In-Reply-To: <486DBE44.2000604@redhat.com> References: <935ead450806160505n6de3514ds48f26110e8148b74@mail.gmail.com> <486DBE44.2000604@redhat.com> Message-ID: On Fri, 4 Jul 2008, Saurabh Bathe wrote: > Jeffrey Ollie wrote: > > On Sun, Jun 15, 2008 at 8:38 PM, Mike McGrath wrote: > > > Anyone in the sysadmin-hosted group able to work on this project? > > > > > > https://fedorahosted.org/fedora-infrastructure/ticket/508 > > > > And actually, if someone wanted to split that ticket into multiple > > requests (maybe even the OP) it'd be easier to track which ones have > > been done. > > I have worked on the conversion of these projects from their CVS to SVN. > I have SVN dumpfiles, what next? > Sweet, well now you can either apply for sysadmin-hosted and set it up yourself or you can put those dumps somewhere and we will. Make sure that the cvs repos are no longer being used. > I think this is also time that I say I would like to be a active helper in the > group. > > For Fedora Infrastructure, I think I would be helpful in sysadmin-hosted, > sysadmin-cvs, sysadmin-web. But am willing to work on whatever else needs to > get done :). > Start with sysadmin-hosted and we'll get you up on sysadmin-web in the near future. -Mike From mmcgrath at redhat.com Sat Jul 5 17:36:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 5 Jul 2008 12:36:47 -0500 (CDT) Subject: Introduction for timothyb In-Reply-To: <43796e4c0807050556v1624ff2y20aa828a80e500ec@mail.gmail.com> References: <43796e4c0807050556v1624ff2y20aa828a80e500ec@mail.gmail.com> Message-ID: On Sat, 5 Jul 2008, Timothy Buck wrote: > Hello everyone, > ?? My name is Timothy andI am a 23 years old who lives in the Reno/Tahoe area. I have been using linux/unix in some > fashion for the past 4 years, from setting up a webserver to host websites for friends to my current day job of > administering red hat 3/4/5 servers for a large online retail company.? I am however a networking junkie at heart and > spend a fair amount of time working with cisco devices. I currently have my ccna and am activly pursuing my ccnp. I > started programming with php and have since moved on to learning python... however I am not as skilled in it as I > would like but am working on it.? Anything else anyone wants to know just ask. > Welcome Timothy, we have weekly meetings it would be good for you to attend: http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From finnzi at finnzi.com Sat Jul 5 19:37:58 2008 From: finnzi at finnzi.com (=?ISO-8859-1?Q?Finnur_=D6rn_Gu=F0mundsson?=) Date: Sat, 05 Jul 2008 19:37:58 +0000 Subject: Introduction Message-ID: <486FCD96.9040403@finnzi.com> Hi, My name is Finnur ?rn Gu?mundsson. I live in the Reykjavik area (Hafnarfjordur), Iceland. I am 25 year old. I work as a Sysadmin at TM Software, a large ASP company here in Iceland. My job roles are: Deploying and managing SAN networks & storage systems for us and our customers, administering linux/unix machines (of course!), core services (DNS/NTP etc), deploying/debugging hardware (x86 servers mostly) and loads of other stuff. We use RHEL/CentOS as our distro of choice. I have been watching this mailing list for a while and would like to contribute something back to the Fedora community in some way (Be it packaging, documentation, sysadmin stuff or anything else). Interests include *NIX, clustering (HA), storage related stuff and more. I am a RHCA (verify it! 804005656115566). My programming/scripting skills stink but i am working on that .... Catch you all on the next meeting. I'll hang out in #fedora-admin as finnzi Laters all, Finnur From mmcgrath at redhat.com Sun Jul 6 03:42:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 5 Jul 2008 22:42:25 -0500 (CDT) Subject: Introduction In-Reply-To: <486FCD96.9040403@finnzi.com> References: <486FCD96.9040403@finnzi.com> Message-ID: On Sat, 5 Jul 2008, Finnur ?rn Gu?mundsson wrote: > Hi, > > My name is Finnur ?rn Gu?mundsson. I live in the Reykjavik area > (Hafnarfjordur), Iceland. I am 25 year old. > > I work as a Sysadmin at TM Software, a large ASP company here in Iceland. > My job roles are: Deploying and managing SAN networks & storage systems for us > and our customers, administering linux/unix machines (of course!), core > services (DNS/NTP etc), deploying/debugging hardware (x86 servers mostly) and > loads of other stuff. We use RHEL/CentOS as our distro of choice. > > I have been watching this mailing list for a while and would like to > contribute something back to the Fedora community in some way (Be it > packaging, documentation, sysadmin stuff or anything else). > Well the good news is every area you just mentioned... needs help! I'd suggest picking one and pursuing it first to get a feel for how Fedora as an organization does things. Let us know what you want to do (packaging, documentation and sysadmin work are all different teams), we'll get you pointed in the right direction. -Mike From alex at meatfreezer.com Sun Jul 6 04:11:46 2008 From: alex at meatfreezer.com (Alex Shepard) Date: Sat, 5 Jul 2008 21:11:46 -0700 Subject: intro Message-ID: Hi all, My name is Alex Shepard. I've been lurking for a few weeks, but I'd like to pitch in and help out if I can find something to work on. I'm 33, work for a startup called Eye-Fi ih the US (in the bay area), doing systems infrastructure and development. I'm pretty good at generic linux web sysadmin stuff, network engineering, systems monitoring (esp nagios & cacti). I'm also a halfway decent coder... I'm pretty good with perl, php, java, javascript, and can read c and variants and python. I wouldn't mind helping out really anywhere. My strengths are probably in web/hosted/tools/devel, but if I had to pick I'm mostly curious about how the FC team manages releases, so sysadmin-releng and sysadmin-build sound like fun. I'll try to drop in at the next irc meeting and say hi. Cheers! -alex From mmcgrath at redhat.com Sun Jul 6 15:42:10 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 6 Jul 2008 10:42:10 -0500 (CDT) Subject: intro In-Reply-To: References: Message-ID: On Sat, 5 Jul 2008, Alex Shepard wrote: > Hi all, > > My name is Alex Shepard. I've been lurking for a few weeks, but I'd like to > pitch in and help out if I can find something to work on. > > I'm 33, work for a startup called Eye-Fi ih the US (in the bay area), doing > systems infrastructure and development. I'm pretty good at generic linux web > sysadmin stuff, network engineering, systems monitoring (esp nagios & cacti). > I'm also a halfway decent coder... I'm pretty good with perl, php, java, > javascript, and can read c and variants and python. > > I wouldn't mind helping out really anywhere. My strengths are probably in > web/hosted/tools/devel, but if I had to pick I'm mostly curious about how the > FC team manages releases, so sysadmin-releng and sysadmin-build sound like > fun. > Excellent, the release engineering team is a separate team but there's a lot of overlap between the two of us, we often work very close together. They have meetings on Mondays - http://fedoraproject.org/wiki/Meetings Take a look, I'm sure they'd be happy to have you as part of the team. -Mike From buck_1970 at hotmail.com Sun Jul 6 20:12:29 2008 From: buck_1970 at hotmail.com (Reggie Buckner) Date: Sun, 6 Jul 2008 16:12:29 -0400 Subject: Fedora-infrastructure-list Digest, Vol 26, Issue 6 In-Reply-To: <20080706160004.F04E56190E8@hormel.redhat.com> References: <20080706160004.F04E56190E8@hormel.redhat.com> Message-ID: Greetings to all, Its Reggie Buckner. I had some personal issues and was away for a while, but now I am back and ready to get involved. To recap my interests lie in system administration, telecom/network infrastructure ( Ethernet, WAN links, Servers, Load Balancers (Radware , F5), and scripting (BASH, Korn working on PERL and Python). I am willing to sign a contibutors agreement and get a account. I dont quite understand the ticketing system but willing to learn. If you have anything going with Asterisk I am willing to get involved with that. Also tell Matt that I am back and willing to assist him Hope all is well with the team and Fedora rocks! See you all later. Reggie Buckner _________________________________________________________________ The i?m Talkaton. Can 30-days of conversation change the world? http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld From klaus at myexpertise.net Sun Jul 6 22:15:49 2008 From: klaus at myexpertise.net (Klaus P. Schreyack) Date: Sun, 6 Jul 2008 15:15:49 -0700 (PDT) Subject: Introduction: Kschreyack In-Reply-To: <25651550.551215382498564.JavaMail.root@zmail.myexpertise.net> Message-ID: <32107807.571215382549018.JavaMail.root@zmail.myexpertise.net> Hi Everyone, I wanted to take a moment to introduce myself. My name is Klaus Schreyack. I'm 40 years old and I'm a Systems Administrator who works for a financial services company in Los Angeles. I've been working seriously with Linux since 2004. I have my RHCT for v5, an MCSE 2003 Certificate, and I'm working towards my RHCE. Over the last two years my interest has focused on Open Source solutions, from which I seem to derive the most satisfaction. I am skilled with the common tcp applications and work with CentOS and RHEL, supporting 70+ servers. I'm also familiar with GWOS, having set it up for my company a few weeks ago. After reviewing the FIG's I have an interest in sysadmin-hosted and sysadmin-noc, but I'm willing to help out anywhere I can. Well, that's it. I'm going to hang out in the meeting on Thursdays to get a feel for things. Look forward to seeing you all then. Thanks. Sincerely, Klaus P. Schreyack Systems Administrator RHCT5 MCSE 2003 A+ Certified klaus at myexpertise.net From mmcgrath at redhat.com Mon Jul 7 03:48:56 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 6 Jul 2008 22:48:56 -0500 (CDT) Subject: puppet and git Message-ID: Sooooo. We've been doing puppet wrong. Not really wrong but there's a better way now using modules. more info: http://reductivelabs.com/trac/puppet/wiki/PuppetModules Long story short, I (and probably kanarip if I can sucker him into it :) will start converting some stuff that we've got to the more module format. Some benefits: * Easier to share with others * Much better organization / easier to find stuff * The standard actually involves writing a README file per module. Thats a good thing and can help explain some things better. Before we go making a bunch of changes I'm going to make sure to keep everyone in the loop with whats going on. One thing I did want to discuss is that puppet does have some native support for git now and people are using it. I have to say I'm on the fence about it. Fedora as an organization is moving more to git, the websites team already uses it. What are the thoughts on this list? -Mike From jeff at ocjtech.us Mon Jul 7 03:58:18 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sun, 6 Jul 2008 22:58:18 -0500 Subject: puppet and git In-Reply-To: References: Message-ID: <935ead450807062058n454cbde4g39b36b838645deab@mail.gmail.com> On Sun, Jul 6, 2008 at 10:48 PM, Mike McGrath wrote: > > One thing I did want to discuss > is that puppet does have some native support for git now and people are > using it. I have to say I'm on the fence about it. Fedora as an > organization is moving more to git, the websites team already uses it. CVS -1 Git +1 The Puppet source code itself is being managed by Git.... Jeff From mmcgrath at redhat.com Mon Jul 7 04:02:11 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 6 Jul 2008 23:02:11 -0500 (CDT) Subject: Introduction: Kschreyack In-Reply-To: <32107807.571215382549018.JavaMail.root@zmail.myexpertise.net> References: <32107807.571215382549018.JavaMail.root@zmail.myexpertise.net> Message-ID: On Sun, 6 Jul 2008, Klaus P. Schreyack wrote: > Hi Everyone, > > I wanted to take a moment to introduce myself. My name is Klaus Schreyack. I'm 40 years old and I'm a Systems Administrator who works for a financial services company in Los Angeles. I've been working seriously with Linux since 2004. I have my RHCT for v5, an MCSE 2003 Certificate, and I'm working towards my RHCE. Over the last two years my interest has focused on Open Source solutions, from which I seem to derive the most satisfaction. > > I am skilled with the common tcp applications and work with CentOS and RHEL, supporting 70+ servers. I'm also familiar with GWOS, having set it up for my company a few weeks ago. After reviewing the FIG's I have an interest in sysadmin-hosted and sysadmin-noc, but I'm willing to help out anywhere I can. > > Well, that's it. I'm going to hang out in the meeting on Thursdays to get a feel for things. Look forward to seeing you all then. Thanks. > Excellent, we hang out in #fedora-admin on irc.freenode.net most of the time. But the meetings are in #fedora-meeting. When we do a check to see who's there at the start of each meeting, speak up! -Mike From ianweller at gmail.com Mon Jul 7 07:18:11 2008 From: ianweller at gmail.com (Ian Weller) Date: Mon, 7 Jul 2008 02:18:11 -0500 (CDT) Subject: puppet and git In-Reply-To: References: Message-ID: On Sun, 6 Jul 2008, Mike McGrath wrote: > Long story short, I (and probably kanarip if I can sucker him into it :) > will start converting some stuff that we've got to the more module format. > Some benefits: > I'm cool with it. I'd be much happier using git anyway. -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams From kanarip at kanarip.com Mon Jul 7 14:20:40 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 07 Jul 2008 10:20:40 -0400 Subject: puppet and git In-Reply-To: References: Message-ID: <48722638.4040401@kanarip.com> Mike McGrath wrote: > Sooooo. We've been doing puppet wrong. Not really wrong but there's a > better way now using modules. > > more info: http://reductivelabs.com/trac/puppet/wiki/PuppetModules > > Long story short, I (and probably kanarip if I can sucker him into it :) > will start converting some stuff that we've got to the more module format. > Some benefits: > > * Easier to share with others > * Much better organization / easier to find stuff > * The standard actually involves writing a README file per module. Thats > a good thing and can help explain some things better. > > Before we go making a bunch of changes I'm going to make sure to keep > everyone in the loop with whats going on. One thing I did want to discuss > is that puppet does have some native support for git now and people are > using it. I have to say I'm on the fence about it. Fedora as an > organization is moving more to git, the websites team already uses it. > > What are the thoughts on this list? > The GIT support isn't actually native (and neither is the support for any other of the SCM's), and I haven't been able to clone the git module for a couple of months now. Another GIT module (in the works) is at: http://git.puppetmanaged.org/?p=modules/git/.git;a=summary (and I hope you like it). There's other more Fedora specific modules as well (like a better puppet module then the one listed on puppet's wiki, or so I'd like to think) because it manages more of puppet, and allows $domain's to override what the module ships (in files and manifests). I'd like to work on the puppet configuration for Fedora Project as well (but you know that), as soon as I get back from my holiday. Kind regards, Jeroen van Meeuwen -kanarip From rnorwood at redhat.com Mon Jul 7 16:07:50 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 7 Jul 2008 12:07:50 -0400 Subject: FAS instance on publictest10? Message-ID: <20080707120750.1621ddfd@solitude.devel.redhat.com> Hi, I've been trying to use the FAS instance on publictest10, and it's acting very strangely. Basically, after a restart, it goes like this: o FAS works fine, both from the web UI and using the API for a few minutes. o After a few minutes, it starts to give 500 errors with stuff like this in the error_log: [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] File "/usr/lib/python2.4/site-packages/fas/model/fasmodel.py", line 6 1, in ? [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] PeopleTable = Table('people', metadata, autoload=True) [...] [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] File "/usr/lib/python2.4/site-packages/sqlalchemy/databases/postgres. py", line 462, in reflecttable [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] raise exceptions.NoSuchTableError(table.name) [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] NoSuchTableError: people Very strange. Any ideas what's going on here? If FAS on publictest10 is going through some development upheaval, I can set one up locally for development and try a public deployment of amber again in a few weeks. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From a.badger at gmail.com Mon Jul 7 17:50:24 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 07 Jul 2008 10:50:24 -0700 Subject: puppet and git In-Reply-To: References: Message-ID: <48725760.8090008@gmail.com> Mike McGrath wrote: > Sooooo. We've been doing puppet wrong. Not really wrong but there's a > better way now using modules. > > more info: http://reductivelabs.com/trac/puppet/wiki/PuppetModules > > Long story short, I (and probably kanarip if I can sucker him into it :) > will start converting some stuff that we've got to the more module format. > Some benefits: > > * Easier to share with others > * Much better organization / easier to find stuff > * The standard actually involves writing a README file per module. Thats > a good thing and can help explain some things better. > > Before we go making a bunch of changes I'm going to make sure to keep > everyone in the loop with whats going on. One thing I did want to discuss > is that puppet does have some native support for git now and people are > using it. I have to say I'm on the fence about it. Fedora as an > organization is moving more to git, the websites team already uses it. > > What are the thoughts on this list? > I don't see a benefit to using git in this situation but I also don't see how it will cause us any extra pain. A big fat +0 from me. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rnorwood at redhat.com Tue Jul 8 15:06:50 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 8 Jul 2008 11:06:50 -0400 Subject: FAS instance on publictest10? In-Reply-To: <20080707120750.1621ddfd@solitude.devel.redhat.com> References: <20080707120750.1621ddfd@solitude.devel.redhat.com> Message-ID: <20080708110650.4548c593@solitude.devel.redhat.com> On Mon, 7 Jul 2008 12:07:50 -0400 Robin Norwood wrote: > Hi, > > I've been trying to use the FAS instance on publictest10, and it's > acting very strangely. Basically, after a restart, it goes like this: > > o FAS works fine, both from the web UI and using the API for a few > minutes. > > o After a few minutes, it starts to give 500 errors with stuff like > this in the error_log: > > [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] File > "/usr/lib/python2.4/site-packages/fas/model/fasmodel.py", line 6 1, > in ? [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] > PeopleTable = Table('people', metadata, autoload=True) > [...] > [Mon Jul 07 08:23:07 2008] [error] [client 127.0.0.1] File > "/usr/lib/python2.4/site-packages/sqlalchemy/databases/postgres. py", > line 462, in reflecttable [Mon Jul 07 08:23:07 2008] [error] [client > 127.0.0.1] raise exceptions.NoSuchTableError(table.name) [Mon Jul > 07 08:23:07 2008] [error] [client 127.0.0.1] NoSuchTableError: people > > > Very strange. > > Any ideas what's going on here? If FAS on publictest10 is going > through some development upheaval, I can set one up locally for > development and try a public deployment of amber again in a few weeks. This still seems to be broken - anybody have any suggestions? I was hoping to let the websites team and others have a look at what I've got so far so I can get some feedback this week. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From mmcgrath at redhat.com Tue Jul 8 19:24:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 8 Jul 2008 14:24:23 -0500 (CDT) Subject: puppet and git (README) Message-ID: Ok, I've got a git puppet mechanism up and working. Its in a very simplistic form right now but works pretty well. I'll be sending a follow up email with directions and will be updating all relevant documentation. -Mike From jkeating at redhat.com Tue Jul 8 19:33:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 08 Jul 2008 15:33:11 -0400 Subject: puppet and git (README) In-Reply-To: References: Message-ID: <1215545591.21388.21.camel@localhost.localdomain> On Tue, 2008-07-08 at 14:24 -0500, Mike McGrath wrote: > Ok, I've got a git puppet mechanism up and working. Its in a very > simplistic form right now but works pretty well. I'll be sending a follow > up email with directions and will be updating all relevant documentation. > > -Mike > What mike forgot to mention, don't make any changes in puppet without talking to him first. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From laxathom at fedoraproject.org Tue Jul 8 19:46:34 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 8 Jul 2008 21:46:34 +0200 Subject: puppet and git (README) In-Reply-To: References: Message-ID: <62bc09df0807081246k66f75021m40f40cc512468d59@mail.gmail.com> On Tue, Jul 8, 2008 at 9:24 PM, Mike McGrath wrote: > Ok, I've got a git puppet mechanism up and working. Its in a very > simplistic form right now but works pretty well. I'll be sending a follow > up email with directions and will be updating all relevant documentation. > > nice -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Tue Jul 8 21:20:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 8 Jul 2008 16:20:25 -0500 (CDT) Subject: puppet and git (README) In-Reply-To: <1215545591.21388.21.camel@localhost.localdomain> References: <1215545591.21388.21.camel@localhost.localdomain> Message-ID: On Tue, 8 Jul 2008, Jesse Keating wrote: > On Tue, 2008-07-08 at 14:24 -0500, Mike McGrath wrote: > > Ok, I've got a git puppet mechanism up and working. Its in a very > > simplistic form right now but works pretty well. I'll be sending a follow > > up email with directions and will be updating all relevant documentation. > > > > -Mike > > > > What mike forgot to mention, don't make any changes in puppet without > talking to him first. > This is true. If you made a change please go back in time and don't make it :) Actually I didn't see any commits go through so I think we're golden. The puppet system is now on puppet! Our repos are all in one git repo (minus private, still working on that). Here's how to use it: Old | New ---------------------------------|-------------------------------------- cvs -d /cvs/puppet co manifests | git clone /git/puppet cvs -d /cvs/puppet co configs | git clone /git/puppet cvs commit | git commit make install | git push That should be enough to get you by. I've got a syntax check on post commit and it will let you know when you've broken something. I'm going to try to get this into a pre-commit but there are some speed issues. You'll also note that make install has been replaced by git push. This is an instant install and is much faster. I'm going to work on the Makefiles but make push should still work and I am going to try to get a "make test" back to a normal working order. The cvs repos have been moved to /cvs/puppet.disabled/ Once this move has proved working fine I'll start working on some cleanup. I'm also working on a way to do test runs of puppet before you push on the actual machines in question. This is still fuzzy in my brain but I'm pretty sure its possible. -Mike From laxathom at fedoraproject.org Tue Jul 8 21:26:18 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 8 Jul 2008 23:26:18 +0200 Subject: puppet and git (README) In-Reply-To: References: <1215545591.21388.21.camel@localhost.localdomain> Message-ID: <62bc09df0807081426t4d48ee10x4f0ec25295d1ed1a@mail.gmail.com> On Tue, Jul 8, 2008 at 11:20 PM, Mike McGrath wrote: > On Tue, 8 Jul 2008, Jesse Keating wrote: > > > On Tue, 2008-07-08 at 14:24 -0500, Mike McGrath wrote: > > > Ok, I've got a git puppet mechanism up and working. Its in a very > > > simplistic form right now but works pretty well. I'll be sending a > follow > > > up email with directions and will be updating all relevant > documentation. > > > > > > -Mike > > > > > > > What mike forgot to mention, don't make any changes in puppet without > > talking to him first. > > > > This is true. If you made a change please go back in time and don't make > it :) Actually I didn't see any commits go through so I think we're > golden. The puppet system is now on puppet! Our repos are all in one git > repo (minus private, still working on that). > > Here's how to use it: > > Old | New > ---------------------------------|-------------------------------------- > cvs -d /cvs/puppet co manifests | git clone /git/puppet > cvs -d /cvs/puppet co configs | git clone /git/puppet > cvs commit | git commit git commit _-a_ (not the same thing, doing a git add then a git commit) > make install | git push > > That should be enough to get you by. I've got a syntax check on post > commit and it will let you know when you've broken something. I'm going > to try to get this into a pre-commit but there are some speed issues. > > You'll also note that make install has been replaced by git push. This is > an instant install and is much faster. I'm going to work on the Makefiles > but make push should still work and I am going to try to get a "make test" > back to a normal working order. > > The cvs repos have been moved to /cvs/puppet.disabled/ > > Once this move has proved working fine I'll start working on some cleanup. > I'm also working on a way to do test runs of puppet before you push on the > actual machines in question. This is still fuzzy in my brain but I'm > pretty sure its possible. > > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From rnorwood at redhat.com Tue Jul 8 21:46:07 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 8 Jul 2008 17:46:07 -0400 Subject: FAS instance on publictest10? In-Reply-To: <20080708110650.4548c593@solitude.devel.redhat.com> References: <20080707120750.1621ddfd@solitude.devel.redhat.com> <20080708110650.4548c593@solitude.devel.redhat.com> Message-ID: <20080708174607.223e14c8@solitude.devel.redhat.com> Ricky set up a FAS instance on pt9 that seems to work fine so far, so I'm done whining. :-) Thanks! -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From lmacken at redhat.com Wed Jul 9 00:48:57 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 8 Jul 2008 20:48:57 -0400 Subject: FAS instance on publictest10? In-Reply-To: <20080708174607.223e14c8@solitude.devel.redhat.com> References: <20080707120750.1621ddfd@solitude.devel.redhat.com> <20080708110650.4548c593@solitude.devel.redhat.com> <20080708174607.223e14c8@solitude.devel.redhat.com> Message-ID: <20080709004857.GE4157@x300.bos.redhat.com> On Tue, Jul 08, 2008 at 05:46:07PM -0400, Robin Norwood wrote: > Ricky set up a FAS instance on pt9 that seems to work fine so far, so > I'm done whining. :-) Hmmm, so what is the difference between the pt10 and pt9 deployments? We've been testing the bleeding-edge python-fedora package on pt10, so if that is causing the issues we definitely need to track it down asap. luke From ricky at fedoraproject.org Wed Jul 9 00:51:04 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 8 Jul 2008 20:51:04 -0400 Subject: FAS instance on publictest10? In-Reply-To: <20080709004857.GE4157@x300.bos.redhat.com> References: <20080707120750.1621ddfd@solitude.devel.redhat.com> <20080708110650.4548c593@solitude.devel.redhat.com> <20080708174607.223e14c8@solitude.devel.redhat.com> <20080709004857.GE4157@x300.bos.redhat.com> Message-ID: <20080709005104.GA5008@Max> On 2008-07-08 08:48:57 PM, Luke Macken wrote: > Hmmm, so what is the difference between the pt10 and pt9 deployments? > We've been testing the bleeding-edge python-fedora package on pt10, so > if that is causing the issues we definitely need to track it down asap. I manually updated python-fedora on pt9 to test that as well - so far, so good, although I still never figured out what was causing the NoSuchTable errors on publictest10. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Wed Jul 9 06:20:36 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 9 Jul 2008 02:20:36 -0400 Subject: puppet and git (README) In-Reply-To: References: <1215545591.21388.21.camel@localhost.localdomain> Message-ID: <20080709062036.GC5008@Max> On 2008-07-08 04:20:25 PM, Mike McGrath wrote: > Our repos are all in one git repo (minus private, still working on > that). Hey, the private repo is now in git as well :-) Here's how to use it: Old | New ---------------------------------|-------------------------------------- cvs -d /cvs/private co private | git clone /git/private chmod 700 private | chmod 700 private cvs commit | git commit make install | git push I just used git-cvsimport for the converstion, and modified /usr/local/bin/syncPuppetMaster.sh (does this need to be put in puppet?) to pull and rsync from there similar to before. Rsyncing isn't completely ideal, but since the configs and manifests are in the same repo and need to be merged with the normal puppet stuff, it was the only way I could think of, short of splitting the configs and manifests into separate repos. Feel free to further restructure - this was just a "get it working first" attempt. The old private repo was moved to /cvs/private.disabled Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rnorwood at redhat.com Wed Jul 9 15:12:33 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 9 Jul 2008 11:12:33 -0400 Subject: FAS instance on publictest10? In-Reply-To: <20080709005104.GA5008@Max> References: <20080707120750.1621ddfd@solitude.devel.redhat.com> <20080708110650.4548c593@solitude.devel.redhat.com> <20080708174607.223e14c8@solitude.devel.redhat.com> <20080709004857.GE4157@x300.bos.redhat.com> <20080709005104.GA5008@Max> Message-ID: <20080709111233.49045a46@solitude.devel.redhat.com> On Tue, 8 Jul 2008 20:51:04 -0400 Ricky Zhou wrote: > On 2008-07-08 08:48:57 PM, Luke Macken wrote: > > Hmmm, so what is the difference between the pt10 and pt9 > > deployments? We've been testing the bleeding-edge python-fedora > > package on pt10, so if that is causing the issues we definitely > > need to track it down asap. > I manually updated python-fedora on pt9 to test that as well - so far, > so good, although I still never figured out what was causing the > NoSuchTable errors on publictest10. Well, this morning things started misbehaving on pt9, too...just differently. :-( >From web browser, if I go to: http://publictest9.fedoraproject.org/accounts/ and log in, I get redirected to publictest10! If I browse back to pt9, it appears I did log in successfully. The equivalent thing happens if I log out from pt9. Looking at the /etc/fas.cfg on pt9, this is probably the cause of that: samadhi.baseurl = 'http://publictest10.fedoraproject.org' I didn't fix it b/c I haven't familiarized myself with your puppet stuff yet. Second, a few minutes ago I was getting 500 errors from that fas instance when logging in from my app, but now I can't reproduce it. :-/ Looking at the logs, it looks like the 500 errors are related to this error: [Wed Jul 09 14:59:40 2008] [error] raise exceptions.DBAPIError.instance(statement, parameters, e, connection_invalidated= is_disconnect) [Wed Jul 09 14:59:40 2008] [error] ProgrammingError: (ProgrammingError) server closed the connection unexpectedly [Wed Jul 09 14:59:40 2008] [error] \tThis probably means the server terminated abnormally [Wed Jul 09 14:59:40 2008] [error] \tbefore or while processing the request. [Wed Jul 09 14:59:40 2008] [error] 'SELECT session.id AS session_id, session.data AS session_data, session.expiration_time A S session_expiration_time \\nFROM session \\nWHERE session.id = %(param_1)s' {'param_1': '620e1904fbcde17dacb96779e77ec9db223 48554'} But, like I said, they aren't happening now. Curious. Maybe it just needed a second cup of coffee. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From a.badger at gmail.com Wed Jul 9 18:33:00 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 09 Jul 2008 11:33:00 -0700 Subject: [Fwd: Cron /var/lib/pgsql/vacstat.py check] Message-ID: <4875045C.3020605@gmail.com> Since the plan is to move koji to db3 within the week I'd like to hold off on this. The dump and reload to move to the new server should be more effective than a manual vacuum. -Toshio -------- Original Message -------- Subject: Cron /var/lib/pgsql/vacstat.py check Date: Wed, 9 Jul 2008 13:20:05 GMT From: root at db2.fedora.phx.redhat.com (Cron Daemon) To: postgres at db2.fedora.phx.redhat.com Traceback (most recent call last): File "/var/lib/pgsql/vacstat.py", line 650, in ? Commands[command](opts) File "/var/lib/pgsql/vacstat.py", line 150, in test_all test_transactions(opts) File "/var/lib/pgsql/vacstat.py", line 147, in test_transactions raise XIDOverflowWarning, '\n'.join(overflows) __main__.XIDOverflowWarning: Used over half the transaction ids for koji. Please schedule a vacuum of that entire database soon: sudo -u postgres vacuumdb -zvd koji -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mikeb at redhat.com Wed Jul 9 18:58:59 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 09 Jul 2008 14:58:59 -0400 Subject: [Fwd: Cron /var/lib/pgsql/vacstat.py check] In-Reply-To: <4875045C.3020605@gmail.com> References: <4875045C.3020605@gmail.com> Message-ID: <1215629940.8627.3.camel@localhost.localdomain> On Wed, 2008-07-09 at 11:33 -0700, Toshio Kuratomi wrote: > Since the plan is to move koji to db3 within the week I'd like to hold > off on this. The dump and reload to move to the new server should be > more effective than a manual vacuum. Note that you still need to analyze all the tables after a dump/reload to regenerate database statistics. Otherwise postgres may choose some less-than-optimal query plans. > -Toshio > > -------- Original Message -------- > Subject: Cron /var/lib/pgsql/vacstat.py check > Date: Wed, 9 Jul 2008 13:20:05 GMT > From: root at db2.fedora.phx.redhat.com (Cron Daemon) > To: postgres at db2.fedora.phx.redhat.com > > Traceback (most recent call last): > File "/var/lib/pgsql/vacstat.py", line 650, in ? > Commands[command](opts) > File "/var/lib/pgsql/vacstat.py", line 150, in test_all > test_transactions(opts) > File "/var/lib/pgsql/vacstat.py", line 147, in test_transactions > raise XIDOverflowWarning, '\n'.join(overflows) > __main__.XIDOverflowWarning: Used over half the transaction ids for > koji. Please schedule a vacuum of that entire database soon: > sudo -u postgres vacuumdb -zvd koji > > > _______________________________________________ > 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 Jul 9 19:27:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 09 Jul 2008 12:27:07 -0700 Subject: [Fwd: Cron /var/lib/pgsql/vacstat.py check] In-Reply-To: <1215629940.8627.3.camel@localhost.localdomain> References: <4875045C.3020605@gmail.com> <1215629940.8627.3.camel@localhost.localdomain> Message-ID: <4875110B.8060006@gmail.com> Mike Bonnet wrote: > On Wed, 2008-07-09 at 11:33 -0700, Toshio Kuratomi wrote: >> Since the plan is to move koji to db3 within the week I'd like to hold >> off on this. The dump and reload to move to the new server should be >> more effective than a manual vacuum. > > Note that you still need to analyze all the tables after a dump/reload > to regenerate database statistics. Otherwise postgres may choose some > less-than-optimal query plans. > Good point. Also note, we're currently debating whether to move to postgres-8.3 for koji now or later. 8.3 has a whole slew of enhancements that could make our lives better[1]_. On the debit side we haven't tested koji with 8.3 here. However, dgilmore has been running sparc.koji.fp.o (FC6) with pg-8.3 which is pretty similar to our environment. .. _[1]: Combing the NEWS for changes from 8.1=>8.3 I came up with the list here: https://fedorahosted.org/fedora-infrastructure/ticket/547 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mikeb at redhat.com Wed Jul 9 19:47:59 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Wed, 09 Jul 2008 15:47:59 -0400 Subject: [Fwd: Cron /var/lib/pgsql/vacstat.py check] In-Reply-To: <4875110B.8060006@gmail.com> References: <4875045C.3020605@gmail.com> <1215629940.8627.3.camel@localhost.localdomain> <4875110B.8060006@gmail.com> Message-ID: <1215632879.8627.6.camel@localhost.localdomain> On Wed, 2008-07-09 at 12:27 -0700, Toshio Kuratomi wrote: > Mike Bonnet wrote: > > On Wed, 2008-07-09 at 11:33 -0700, Toshio Kuratomi wrote: > >> Since the plan is to move koji to db3 within the week I'd like to hold > >> off on this. The dump and reload to move to the new server should be > >> more effective than a manual vacuum. > > > > Note that you still need to analyze all the tables after a dump/reload > > to regenerate database statistics. Otherwise postgres may choose some > > less-than-optimal query plans. > > > Good point. > > Also note, we're currently debating whether to move to postgres-8.3 for > koji now or later. 8.3 has a whole slew of enhancements that could make > our lives better[1]_. On the debit side we haven't tested koji with 8.3 > here. However, dgilmore has been running sparc.koji.fp.o (FC6) with > pg-8.3 which is pretty similar to our environment. If dgilmore hasn't seen any issues with Postgres 8.3, I'm all for using that. In addition, if we do run into performance/scaling issues, I'm sure the Postgres developers will be much more eager to assist us with them if we're running 8.3 rather than an older version. > .. _[1]: Combing the NEWS for changes from 8.1=>8.3 I came up with the > list here: https://fedorahosted.org/fedora-infrastructure/ticket/547 > > -Toshio > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From mmcgrath at redhat.com Wed Jul 9 23:08:59 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 9 Jul 2008 18:08:59 -0500 (CDT) Subject: PHX Jul 10,11 Message-ID: Hey all, I'll be in Phoenix on July 10th and 11th. I'll be installing two new application servers and, at last, db3! I'll be sending some outage notifications though I'm not expecting any longer outage in the next couple of days, 10-20 minutes tops. I'll also probably be out most of monday recovering, its a vacation day for me but I'll be around a bit. -Mike From smooge at gmail.com Wed Jul 9 23:16:00 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 9 Jul 2008 17:16:00 -0600 Subject: PHX Jul 10,11 In-Reply-To: References: Message-ID: <80d7e4090807091616o2ccf8ceeqbf1ee4732db25d21@mail.gmail.com> On Wed, Jul 9, 2008 at 5:08 PM, Mike McGrath wrote: > Hey all, I'll be in Phoenix on July 10th and 11th. I'll be installing two > new application servers and, at last, db3! I'll be sending some outage > notifications though I'm not expecting any longer outage in the next > couple of days, 10-20 minutes tops. I'll also probably be out most of > monday recovering, its a vacation day for me but I'll be around a bit. > Ah... so close to NM yet so far. Good luck.. worse comes to worse I could try and drive overnight to help out ;). > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Thu Jul 10 14:34:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 10 Jul 2008 09:34:15 -0500 (CDT) Subject: Outage Notification - 2008-07-11 17:00 UTC Message-ID: There will be an outage starting at 2008-07-11 17:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-07-11 17:00 UTC' Affected Services: Websites CVS / Source Control Buildsystem Database DNS Mail Fedora Hosted Unaffected Services: Torrent Fedora People talk.fedoraproject.org Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/694 Reason for Outage: Many of our services were updated last week some of them need to be rebooted to take up a new kernel. Additionally I'll be on site in Phoenix working on a few things and will have to take a couple of services down while I make some network changes. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From ricky at fedoraproject.org Thu Jul 10 19:53:34 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 10 Jul 2008 15:53:34 -0400 Subject: Meeting Log - 2008-07-03 Message-ID: <20080710195334.GD8214@Max> 16:00 * f13 16:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 16:01 * lmacken 16:01 * abadger1999 is here 16:02 * iWolf lurks 16:02 * londo lurks as well 16:02 < fchiulli> fchiulli is here 16:02 * skvidal is 16:02 < mmcgrath> alllrighty, lets get started 16:02 * ivazquez is here 16:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 16:02 < mmcgrath> http://fedoraproject.org/wiki/Infrastructure 16:02 < mmcgrath> err thats not tickets :) 16:03 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 16:03 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 16:03 < mmcgrath> there we go 16:03 < mmcgrath> ok, item number one 16:03 < mmcgrath> .ticket 671 16:03 < zodbot> mmcgrath: #671 (in.fedoraproject.org) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/671 16:03 < mmcgrath> So I don't understand this ticket. 16:03 -!- mccann [n=jmccann at nat/redhat-us/x-6e5438c39f34df8c] has quit Remote closed the connection 16:04 < mmcgrath> it starts off saying mether talked to me (he didn't about this) 16:04 -!- vwbusguy- [n=scott at c-68-51-66-81.hsd1.in.comcast.net] has quit "Leaving" 16:04 < mmcgrath> I gather they're requesting hosting space from us. 16:04 < mmcgrath> We have a localized fedoraproject.org page. 16:04 < mmcgrath> we're soon going to have a localized wiki. 16:04 < mmcgrath> once spins get back in order all of that will be taken care of. 16:04 < ivazquez> I think it was less "with" than "at". 16:05 < mmcgrath> f13: are we able to produce spins right now? mether seems to think no. 16:06 < mmcgrath> I asked in the ticket for someone from the Indian team to be present during this meeting, is anyone around? 16:06 < ivazquez> Do we know who's on the team? 16:06 < mmcgrath> ivazquez: no idea 16:06 < f13> mmcgrath: Spins are being made as we chat 16:07 < f13> slowly (: 16:07 < mmcgrath> ok, then I'm going to make some comments on this ticket because I don't think they have a clear idea of what they want and I know I don't have a clear idea of it. 16:07 < mmcgrath> next ticket 16:07 < mmcgrath> .ticket 395 16:07 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:08 -!- jeff_hann [n=arares at 89.40.98.185] has quit 16:08 < mmcgrath> jcollie: any word? 16:08 < jcollie> whups we have a meeting don't we 16:08 < mmcgrath> :) 16:08 < jcollie> no nothing new other than a lot of people have signed up for sip accounts and appear to have them working 16:09 < mmcgrath> jcollie: yeah, so far I've heard no complaints with the system, just that we need more docs :) 16:09 < jcollie> we need docs yep 16:09 < mmcgrath> all in all I and I think everyone else has been very pleased. 16:09 < mmcgrath> well if nothing else on 395 we'll move on 16:09 < mmcgrath> .ticket 446 16:09 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 16:09 < mmcgrath> dgilmore: ping? 16:09 < mmcgrath> ianweller: ping you on this too 16:09 < mmcgrath> spevack: ping 16:10 < mmcgrath> whats the current deal with spins? does this ticket fall under what has been going on in the websites team? I know mizmo has been working on stuff. 16:10 < dgilmore> mmcgrath: we have a page up. Just need good text making it clear that they are not provided directly by fedora 16:11 < mmcgrath> dgilmore: excellent, go ahead and close that bug when we're all set. 16:11 < mmcgrath> next ticket is 16:11 < mmcgrath> .ticket 547 16:11 < zodbot> mmcgrath: #547 (Koji DB Server as postgres 8.3) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/547 16:11 < mmcgrath> I'll be out in PHX soon to install the new db server looks like next week actually (on thursday and friday) 16:12 < abadger1999> Cool. 16:12 < f13> nice 16:12 < mmcgrath> we'll run our tests, make sure its cool and do a clean cutover at that time of koji. 16:12 < dgilmore> mmcgrath: /me goes back to working construction 16:13 < mmcgrath> side note, it seems the network throughput we should be seeing in PHX... we aren't. I've got a ticket open with the team. 16:13 < mmcgrath> dgilmore: solid 16:13 < mmcgrath> thast really all there is on postgres 16:13 < mmcgrath> .ticket 576 16:13 < zodbot> mmcgrath: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/576 16:13 < mmcgrath> G: you around? 16:13 * mmcgrath thinks not but is pinging anyway 16:14 < ivazquez> I think he punched out a few hours ago. 16:14 < mmcgrath> ok, so no G. one thing I was thinking about was using encfssh 16:14 < ianweller> oh hi 16:14 < mmcgrath> though I'm not sure of all of its features. would that require a shared password? 16:14 < mmcgrath> anyone else use encfs for anything? I do in a limited capacity 16:15 < mmcgrath> ok, we'll move on for now on that 16:15 < jcollie> well one thing would be nice with whatever we come up with is ability to sync a copy locally to a laptop or somehing 16:15 < mmcgrath> .ticket 361 16:15 < zodbot> mmcgrath: #361 (fedorahosted.org default trac header logo/location icon) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/361 16:16 < mmcgrath> jcollie: yeah, encfssh I think would allow for that via unison 16:16 < mmcgrath> or rsync. 16:16 < mmcgrath> ianweller: did you want to be lead on this? 16:16 * mmcgrath can't remember. 16:16 < ianweller> mizmo just left for home 16:16 < mmcgrath> it might have been ricky who's on vacation 16:16 < ianweller> i don't remember where the logo was in the deeper areas of the wiki 16:17 < jcollie> i think we're just waiting for mizmo to finish the design 16:17 < ianweller> do you guys know how to change the default logo? 16:17 < mmcgrath> ahh, got'cha. 16:17 < mmcgrath> ianweller: I seem to remember its pretty simple 16:17 < ianweller> ok 16:17 < mmcgrath> f13: do you remember? 16:17 < ianweller> well once we get that from her i think we can do it 16:17 < mmcgrath> I don't know off hand but I bet google or the #trac guys will know real easy 16:17 < jcollie> probably can be done by editing the config file 16:18 < ivazquez> Oh, just a bit on a tangent here... 16:18 < mmcgrath> ivazquez: shoot 16:18 < ivazquez> What about a Trac theme that's blue? 16:18 < f13> I don't recall off teh top of my head, but yeah I think we can get the logo in place. It just might be a site modificatino that we'll have to keep up every time we update trac 16:18 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit "Konversation terminated!" 16:18 < ivazquez> You know, to match the rest of our stuff? :P 16:18 < mmcgrath> I'm fine with that, just needs to have the work done 16:18 -!- ChitleshGoorah [n=chitlesh at fedora/ChitleshGoorah] has joined #fedora-meeting 16:18 < f13> ivazquez: that'd be great, got css? 16:18 < f13> (: 16:18 < ivazquez> I know CSS. I suppose that's a start :P 16:18 < jcollie> it'll be even easier when we move to trac 0.11 since it uses genshi templates 16:19 < mmcgrath> 16:19 -!- drago01 [n=linux at chello062178124130.3.13.univie.teleweb.at] has quit Read error: 104 (Connection reset by peer) 16:19 < mmcgrath> so nothing new on the logos and I think a good theme would be excellent 16:19 < mmcgrath> next ticket 16:20 < f13> especially if we want to compete with launchpad 16:20 < mmcgrath> .ticket 448 16:20 < zodbot> mmcgrath: #448 (Hosting request for fedora-quotes) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/448 16:20 < mmcgrath> I thought we took care of that 16:20 * mmcgrath clicks 16:20 * mmcgrath pings ajax 16:20 -!- inode0 [n=inode0 at fedora/inode0] has left #fedora-meeting [] 16:20 < jcollie> i don't think that the new repo on fp.o was ever set up 16:22 < mmcgrath> jcollie: I thought he was just going to use his fedorapeople space for a while 16:22 < mmcgrath> I'll make a note on the ticket and we'll talk next time. 16:22 -!- stickster is now known as stickster_afk 16:22 < mmcgrath> because I think what he wanted was more open then we actually have the ability to provide right now 16:23 < mmcgrath> ok, that brings us to some other topics. 16:23 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- l10n wiki 16:23 -!- petreu [n=petreu at fedora/Standby] has quit Remote closed the connection 16:23 < mmcgrath> Just so you guys know G's working on a translated wiki solution. We almost have it ready. 16:23 < ianweller> \o/ 16:23 < mmcgrath> Additionally we're going to have a wildcard cert soon for fedoraproject.org 16:23 < ianweller> \o/ 16:23 < mmcgrath> which is some exciting news if it behaves like I think it will. allowing for stuff like "en.fedoraproject.org" and "de.fedoraproject.org" 16:24 < mmcgrath> for our website and wiki interactions. 16:24 < jcollie> extra coolness 16:24 < mmcgrath> this is all part of a larger plan to further internationalize our infrastructure 16:24 < mmcgrath> G's been working hard on that 16:24 < mmcgrath> next bit 16:25 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- DB funkiness 16:25 < mmcgrath> err actually 16:25 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- FAS2 funkiness 16:25 < mmcgrath> http://mmcgrath.fedorapeople.org/fas-conn-img1.png 16:25 < mmcgrath> long story short, fas2 is spiking and using WAY more db connections then we have told it it can use. 16:26 < mmcgrath> and we're not exactly sure where this is happening. 16:26 < ivazquez> Can we instrument SA? 16:26 < SmootherFrOgZ> wooo 16:26 < mmcgrath> I'm going to continue looking into it but I want to make everyone aware this is causing problems. 16:26 -!- alexxed [n=alex at dyn-86.105.67.31.tm.upcnet.ro] has joined #fedora-meeting 16:26 < mmcgrath> when FAS2 500's it causes our other FAS dependant apps to 500 16:26 < SmootherFrOgZ> i'm in if you want a hand mmcgrath 16:27 < SmootherFrOgZ> mmcgrath: does all came from fasclient or more ? 16:28 < mmcgrath> SmootherFrOgZ: yeah, thats part of it. 16:28 < mmcgrath> but in theory we could probably be ddosed right now pretty easily. 16:28 < mmcgrath> ivazquez: we can, I don't think its at the SA level. I believe its at mod_wsgi and apache threads. 16:28 * ChitleshGoorah wants to know whether ticket 627 will be discussed in this meeting 16:29 < mmcgrath> but, like I said, we really don't know for sure. almost no changes I've made to SA or wsgi hsa made any difference 16:29 < mmcgrath> .ticket 627 16:29 < zodbot> mmcgrath: #627 (Request: A FEL mailing list) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/627 16:29 < mmcgrath> ChitleshGoorah: it didn't have a meeting tag so no. it hasn't. 16:29 < mmcgrath> ChitleshGoorah: what about it? 16:29 < ChitleshGoorah> a mailing list for FEL 16:30 < mmcgrath> thats the request is for. 16:30 < mmcgrath> ChitleshGoorah: you want to know when or something? 16:30 -!- drago01 [n=linux at chello062178124130.3.13.univie.teleweb.at] has joined #fedora-meeting 16:30 -!- kital [n=Joerg_Si at fedora/kital] has quit Read error: 104 (Connection reset by peer) 16:31 < ChitleshGoorah> mmcgrath: I just want to know whether someone is taking care of the request 16:31 < SmootherFrOgZ> is someone already works on that ? 16:31 < mmcgrath> SmootherFrOgZ: no one was, I'll get it after the meeting. 16:31 < mmcgrath> ok, so back to FAS2 issues. 16:32 < mmcgrath> anyone who has an interest in looking at why FAS2 is taking all those connections up please do, even if you don't figure it out email me or the list with anything you think or test. It could help. 16:32 < mmcgrath> and thast really all I have for the meeting. 16:32 < mmcgrath> so 16:32 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 16:32 < SmootherFrOgZ> i'll 16:32 < mmcgrath> anyone have anything to discuss? 16:32 < ivazquez> fas-planet 16:33 < SmootherFrOgZ> mmcgrath: do we have a ticket about this issue ? 16:33 < ivazquez> What's the next step to getting it in place? 16:33 * nirik wonders what the progress on ticket 651 is. 16:34 < SmootherFrOgZ> .ticket 651 16:34 < mmcgrath> SmootherFrOgZ: not yet. 16:34 < zodbot> SmootherFrOgZ: #651 (system account for tier2 ppc32/x86_64 hosting for cvsextras) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/651 16:34 -!- kital [n=Joerg_Si at fedora/kital] has joined #fedora-meeting 16:34 < mmcgrath> nirik: I'm going to have loupgaroublond work on that soon actually, its going to be his first fas project. 16:34 < nirik> ok, cool. 16:35 < mmcgrath> SmootherFrOgZ: I'll open a ticket after the meeting. 16:35 < mmcgrath> anyone have anything else they'd like to discuss? 16:35 < ivazquez> fas-planet 16:35 < SmootherFrOgZ> mmcgrath: feel free to add me to it 16:35 < SmootherFrOgZ> thx 16:35 < ivazquez> What's the next step to getting it in place? 16:35 < mmcgrath> SmootherFrOgZ: sure 16:35 < mmcgrath> ivazquez: the plugin? 16:36 < ivazquez> Yes. 16:36 < f13> hrm. 16:36 < mmcgrath> not sure. 16:36 < f13> that system account thing makes me a little nervous 16:36 < mmcgrath> ivazquez: have you checked with skvidal that it'll work in our setup? 16:36 < mmcgrath> f13: me too 16:37 * skvidal scrolls up 16:37 < ivazquez> I have not, but I'm out of ways to think about how it won't work. 16:37 < skvidal> ah 16:37 < skvidal> sorry - I was reading fas-planet 16:38 < skvidal> okay 16:38 < skvidal> yah - we just need to be able to query that data 16:38 < skvidal> do we have that ,yet? 16:38 < mmcgrath> ivazquez: skvidal: you two want to make sure thats all good. 16:38 < ivazquez> Can do. 16:38 < mmcgrath> ivazquez: make sure your plugin has an interface for skvidal's script to pull from. 16:38 -!- nim-nim [n=nim-nim at fedora/nim-nim] has joined #fedora-meeting 16:39 < skvidal> okie doke 16:39 < ivazquez> The plugin contains both the FAS plugin and a script to pull the data. 16:39 < mmcgrath> 16:39 < ivazquez> All it needs is the static portion of the planet config file. 16:39 -!- sdziallas [n=sebastia at p57A2D0A2.dip.t-dialin.net] has quit "Ex-Chat" 16:39 < skvidal> ivazquez: I can't wait to tell our users to reset it all again :) 16:39 -!- balor [n=balor at gimili.plus.com] has quit Read error: 110 (Connection timed out) 16:40 < ivazquez> I could probably whip something up to import the .planet files. 16:41 < ivazquez> I mean, not right *this* second, but yeah. 16:42 < ivazquez> I'll open a ticket so we can track it. 16:42 < mmcgrath> solid. 16:42 < mmcgrath> Anyone have anything else to discuss? 16:43 < ivazquez> I suppose I'll request hosting for fas-planet as well. 16:44 < f13> mmcgrath: probably not this meeting, but soon I'll ask for a publictest insance for doing message bus testing 16:44 < f13> and start talking about how we could/should use such a bus 16:45 < mmcgrath> f13: solid. 16:45 < abadger1999> f13: What bus were you planning on looking into? 16:45 < mmcgrath> abadger1999: ohh, you haven't seen f13's screencast :D 16:45 < f13> abadger1999: qpid, the AMQP implementation that's used by RH MRG 16:46 < f13> mmcgrath: notting has brought up an interesting question over in #fedora-devel 16:46 < f13> mmcgrath: archives. is out of space, and we can remove from master what was put on archives, but that's not going to last long. 16:46 < f13> what's our future storage strategy? 16:47 -!- notting [n=notting at redhat/notting] has joined #fedora-meeting 16:47 < mmcgrath> f13: we've got 3.5T of space waiting to be used that was donated from HP, its primarly for secondary but for now we can use it for both. 16:47 < mmcgrath> problem.... 16:47 < mmcgrath> its got 3, count it, 3 bad disks in it right onw. 16:47 < mmcgrath> so I'm trying to figure out what to do about it and get it under warranty, etc. 16:47 < f13> oof 16:47 < mmcgrath> its hosted in PHX. 16:47 < mmcgrath> xen11. 16:47 < f13> where "both" == secondary and archives ? 16:47 < mmcgrath> yeah, we'll probably keep them as separate sites for now just so we can split them up if the time comes. 16:48 < notting> archives right now is something @bu? 16:48 < mmcgrath> I'm also though hoping to have a 10T solution for our primary mirror by the end of the year though. 16:48 < mmcgrath> so we'll have a lot of options. 16:48 < mmcgrath> notting: correct. 16:49 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 16:49 < mmcgrath> Ok, anyone have anything else they'd like to discuss? if not we'll end the meeting in 30. 16:49 < f13> mmcgrath: so if we move stuff that's on archives off of master, that gives us enough space to last out the year for Fedora releases? 16:49 < f13> I think you confirmed this once, I just want to make sure 9: 16:49 < f13> (: 16:49 < f13> (I hadn't realized archives. was out of space) 16:49 < mmcgrath> I haven't done the math recently. 16:50 < f13> k 16:50 < mmcgrath> but either way I'm hoping to have the 'new' archives box up before F9+1 ships :) 16:50 < f13> sure 16:50 < f13> aaah 16:51 < f13> yeah, that'll help us land F!10 16:51 < mmcgrath> actually we need to make sure we'll have enough room for the alpha too. 16:51 < ivazquez> Do we have a FAS2 test instance running anywhere? 16:51 < mmcgrath> ivazquez: publictest10 16:51 < ivazquez> Alright. 16:51 -!- chitlesh_ [n=chitlesh at 52-40.76-83.cust.bluewin.ch] has joined #fedora-meeting 16:51 < mmcgrath> Ok, anyone have anything else? if not we'll close the meeting in 30 16:52 < ivazquez> I'll package fas-planet in the meantime so we can put it into the FI repo for now. 16:52 < mmcgrath> ivazquez: excellent 16:52 < mmcgrath> 15 16:52 < SmootherFrOgZ> ivazquez: cool 16:52 -!- alexxed [n=alex at dyn-86.105.67.31.tm.upcnet.ro] has quit "Leaving." 16:52 < mmcgrath> 5 16:52 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting end! 16:52 < mmcgrath> thanks for coming everyone!! 16:52 < fchiulli> Enjoy the weekend all. 16:53 < mmcgrath> indeed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Jul 10 20:30:50 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 10 Jul 2008 16:30:50 -0400 Subject: Meeting Log - 2008-07-10 Message-ID: <20080710203050.GE8214@Max> 16:00 -!- ricky changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 16:01 < ricky> This is going to be a fast one, isn't it? :-) 16:02 -!- smooge [n=smooge at canopus.unm.edu] has quit "-ENOCAFFEINE" 16:02 < ricky> abadger1999, dgilmore, f13, lmacken, paulobanon , skvidal anybody I forgot, ping :-) 16:02 * f13 16:02 < skvidal> hi ricky 16:02 * abadger1999 here briefly 16:02 < G> ricky: here 16:02 * kc8hfi here, watching, learning 16:02 < ricky> ianweller_afk, jima, jcollie: ping 16:02 < ricky> All right :-) 16:02 -!- ianweller_afk [n=ianwelle at fedora/ianweller] has quit Read error: 104 (Connection reset by peer) 16:02 < G> Mike on a plane? 16:03 < ricky> I think 16:03 < ricky> Aw, I killed ianweller_afk :-( 16:03 -!- ricky changed the topic of #fedora-meeting to: Infrastructure -- Tickets 16:03 < ricky> tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 16:03 < skvidal> ricky: I think f13 did 16:03 < ricky> Oh, that thing. Hehe 16:03 < ricky> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 16:03 < zodbot> ricky: http://tinyurl.com/2hyyz6 16:03 < skvidal> it means ian needs to update :) 16:03 < ricky> .ticket 671 16:03 < zodbot> ricky: #671 (in.fedoraproject.org) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/671 16:04 < f13> skvidal: I did? 16:04 < ricky> mmcgrath_afk isn't around, but anybody from Fedora India around to give an update on this? 16:04 < skvidal> f13: your /me 16:04 < ricky> f13: There was that old bug with blank /me s 16:04 < f13> ah 16:04 < ricky> mether: ping 16:04 < skvidal> remember how warren and jeremy used to logoff whenever this meeting happened? 16:05 < warren> I could leave for old time's sake. 16:05 < ricky> Looks like he's not around atm 16:05 < ricky> .ticket 395 16:05 < zodbot> ricky: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:06 < mether> ricky: pong 16:06 < G> ricky: can I just say something about the in.fp.o thing? 16:06 < ricky> Oop, back to that for a bit, then 16:06 < ricky> G: Sure 16:06 < ricky> mether: We're talking about the in.fp.o ticket 16:07 < mether> yeah 16:07 < mether> I am not sure what more information I could provide 16:07 < G> I don't object in principle, but my only complaint about it is the fact that while it isn't an ISO language code yet, it has the potential to be 16:08 < mether> you mean fp.org.in would be better? 16:08 < ricky> (Which means that in.fp.o will have a translated website/wiki soon) 16:08 < G> I just don't know if using other ISO 639-1 style subdomains is such a good idea 16:08 < G> fp.org.in or even india.fp.o 16:08 < ricky> Er, may 16:08 < mether> thats fine by me 16:08 < G> I only object to in.fp.o 16:09 < ricky> could india + in be too confusing? 16:09 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit "Konversation terminated!" 16:09 < ricky> Since they both sound like front page-style things? 16:09 < G> I think Hindi is hi or hd from memory 16:09 < mether> hi 16:09 < mether> yes 16:09 -!- jbrothers [n=jbrother at 208.46.128.30] has joined #fedora-meeting 16:10 < ricky> So would this be a request for us to host it? 16:10 < mether> host the website? yes 16:10 -!- giallu [n=giallu at 81-174-47-170.dynamic.ngi.it] has joined #fedora-meeting 16:10 -!- ianweller_afk [n=ianwelle at 66.232.222.84] has joined #fedora-meeting 16:10 < G> mether: the other thing to take note is, when we deploy l10n wikis, anly language with x% of the websites translated will be eligable for the localised wiki, would I think would solve all bar one of your problems 16:11 * ricky doesn't know how these kinds of requests work, so it might be best to wait for mmcgrath_afk unless anybody else here has something to say 16:12 < G> thats all I have to say 16:12 < ricky> I guess we've at least clarified the request - hosting for a kind of Indian portal site? 16:12 -!- fchiulli [i=824c400f at gateway/web/ajax/mibbit.com/x-9ab3c49250c03945] has joined #fedora-meeting 16:12 < f13> mether: if we host the webpage, youre not expecting us to host the translated isos too are you? 16:12 < ricky> mether: Is that accurate to say? 16:13 < f13> 'cause I thought the point of that was to host them off near the people consuming them. 16:13 < mether> no, we probably will find another hosting place for that, I could host the website there too but from my previous discussion I had the impression that mmcgrath was interested in this 16:14 < f13> ok 16:14 < ricky> All right, I guess we'll table this until mmcgrath_afk is around, then :-) Thanks, mether 16:14 < mether> ok, thanks 16:14 < ricky> .ticket 395 16:14 < zodbot> ricky: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:14 < ricky> jcollie: Are you around to discuss how public meetings will work? 16:16 < ricky> Hope I didn't miss him by those couple of minutes :-( 16:17 < ricky> Oh, he said he was taking off 16:17 < ricky> All right 16:17 < ricky> .ticket 446 16:17 < zodbot> ricky: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 16:18 < ricky> dgilmore: ping 16:19 < ricky> Hm.. to #547! 16:19 -!- smooge [n=smooge at canopus.unm.edu] has joined #fedora-meeting 16:19 < ricky> .ticket 547 16:19 < zodbot> ricky: #547 (Koji DB Server as postgres 8.3) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/547 16:20 < ricky> I guess mmcgrath_afk will be working on that very soon :-) 16:20 < G> yay! 16:20 < ricky> And dgilmore mentioned that it works with the sparc koji, so hopefully, it'll go smoothly 16:20 < ricky> .ticket 576 16:20 < zodbot> ricky: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/576 16:21 < ricky> G: Any plans on this? I know you've been busy lately 16:21 < G> ricky: no progress, need to poke Mike again 16:21 * dgilmore is here briefly 16:21 < ricky> mmcgrath_afk Mentioned something about encfs last time, I think 16:21 < ricky> All right 16:22 < ricky> dgilmore: Did you have anythink to say about the spins page ticket? 16:22 < ricky> Looks like a lot of spins work has been going on from websites 16:22 < dgilmore> ricky: no 16:22 < ricky> Ah, OK 16:22 * dgilmore is afk 16:22 < ricky> .ticket 361 16:22 < zodbot> ricky: #361 (fedorahosted.org default trac header logo/location icon) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/361 16:23 < ricky> Mairin sent me a banner recently (putting on fedorapeople) 16:24 < ricky> (http://ricky.fedorapeople.org/fedora-hosted-banner.png) 16:24 < ricky> So I'll try to get that setup in puppet, etc. soon 16:24 < ricky> .ticket 448 16:24 < zodbot> ricky: #448 (Hosting request for fedora-quotes) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/448 16:25 < ricky> I always manage to forget what we agreed on last time with this 16:25 < ricky> He was going to put it on fedorapeople.org, I think 16:25 < ricky> I guess we can close the ticket when that's all setpu 16:25 < ricky> **setup 16:26 -!- thomasj [n=thomasj at fedora/thomasj] has left #fedora-meeting [] 16:26 -!- ricky changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 16:26 < ricky> Anybody have anything to discuss? 16:26 * ricky wonders what cool new workflows puppet in git will allow us to take 16:27 < ricky> I wonder what mmcgrath_afk was planning with allowing us to test puppet changes on specific servers 16:27 < G> I can't think of anything off the top of my head 16:28 < ricky> All right, I'll close in 30 if nobody has anything 16:29 -!- ricky changed the topic of #fedora-meeting to: Infrastructure -- Meeting End -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From thinklinux.ssh at gmail.com Thu Jul 10 20:34:45 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Fri, 11 Jul 2008 02:04:45 +0530 Subject: Meeting Log - 2008-07-10 In-Reply-To: <20080710203050.GE8214@Max> References: <20080710203050.GE8214@Max> Message-ID: > 16:03 < ricky> .ticket 671 > 16:03 < zodbot> ricky: #671 (in.fedoraproject.org) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/671 > 16:04 < f13> skvidal: I did? > 16:04 < ricky> mmcgrath_afk isn't around, but anybody from Fedora India around to give an update on this? I shall discuss and update you on this tomorow. Sorry for not being at the meeting. (Its 2Am here ;) -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From thinklinux.ssh at gmail.com Thu Jul 10 20:42:00 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Fri, 11 Jul 2008 02:12:00 +0530 Subject: Meeting Log - 2008-07-10 In-Reply-To: References: <20080710203050.GE8214@Max> Message-ID: > I shall discuss and update you on this tomorow. > Sorry for not being at the meeting. (Its 2Am here ;) oops ...so sorry, I did not notice mether have alrady talked on it. So sorry for the mistake. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From stickster at gmail.com Fri Jul 11 15:47:37 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 11 Jul 2008 15:47:37 +0000 Subject: [Fwd: Re: Announcing the Fedora EDU Spin Preview] Message-ID: <1215791257.8058.30.camel@victoria> Anyone have insight into this? Paul -------- Forwarded Message -------- > From: Jeroen van Meeuwen > Reply-To: Development discussions related to Fedora > > To: Development discussions related to Fedora > > Subject: Re: Announcing the Fedora EDU Spin Preview > Date: Fri, 11 Jul 2008 01:16:35 +0200 > > Luke Macken wrote: > > On Thu, Jul 10, 2008 at 11:49:44AM -0400, Christopher Aillon wrote: > >> Also, you need to get approval from the Spin SIG and Board before you > >> can call it a spin. > >> > >> https://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess > > > > Sadly, this is more of a roadblock than a process at the moment, seeing > > as how it has been blocking on the creation of a fedora-spins mailing > > list for the past 3 months. Does someone with postfix/mailman knowledge > > want to help get this ball rolling ? > > > > I don't know what the problem is exactly... We have multiple mailing > lists running in all kinds of locations... @redhat.com, > @fedorahosted.org and @lists.fedoraproject.org... Not sure what's > holding us back. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 Fri Jul 11 16:21:40 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 11 Jul 2008 11:21:40 -0500 Subject: [Fwd: Re: Announcing the Fedora EDU Spin Preview] In-Reply-To: <1215791257.8058.30.camel@victoria> References: <1215791257.8058.30.camel@victoria> Message-ID: <935ead450807110921i2957c782va08a5836f1f7a665@mail.gmail.com> 2008/7/11 Paul W. Frields : > Anyone have insight into this? The issue is that something in postfix on collab1 (where the lists.fedoraproject.org mailing lists run) and/or bastion (which serves as a central mail gateway) is rewriting "@lists.fedoraproject.org" addresses in the message headers to "@fedoraproject.org". When someone then tries to reply to a mailing list post the message is bounced as "@fedoraproject.org" is an invalid address. I don't have enough postfix-fu to fix the problem and no one with enough postfix-fu has had the time, access, and/or interest in fixing the problem. Until this problem is fixed I've been hesitant to create any (more) lists.fedoraproject.org mailing lists. lists.fedorahosted.org has a similar problem, except that "@fedorahosted.org" works due to some quirks of how postfix interprets email addresses (AFAIK without a some hackery postfix can't treat "@lists." differently from "@"). Jeff > -------- Forwarded Message -------- >> From: Jeroen van Meeuwen >> Reply-To: Development discussions related to Fedora >> >> To: Development discussions related to Fedora >> >> Subject: Re: Announcing the Fedora EDU Spin Preview >> Date: Fri, 11 Jul 2008 01:16:35 +0200 >> >> Luke Macken wrote: >> > On Thu, Jul 10, 2008 at 11:49:44AM -0400, Christopher Aillon wrote: >> >> Also, you need to get approval from the Spin SIG and Board before you >> >> can call it a spin. >> >> >> >> https://fedoraproject.org/wiki/SIGs/Spins/SpinSubmissionProcess >> > >> > Sadly, this is more of a roadblock than a process at the moment, seeing >> > as how it has been blocking on the creation of a fedora-spins mailing >> > list for the past 3 months. Does someone with postfix/mailman knowledge >> > want to help get this ball rolling ? >> > >> >> I don't know what the problem is exactly... We have multiple mailing >> lists running in all kinds of locations... @redhat.com, >> @fedorahosted.org and @lists.fedoraproject.org... Not sure what's >> holding us back. >> >> Kind regards, >> >> Jeroen van Meeuwen >> -kanarip >> > -- > Paul W. Frields > gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ > irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > From kanarip at kanarip.com Fri Jul 11 16:25:33 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 11 Jul 2008 18:25:33 +0200 Subject: [Fwd: Re: Announcing the Fedora EDU Spin Preview] In-Reply-To: <935ead450807110921i2957c782va08a5836f1f7a665@mail.gmail.com> References: <1215791257.8058.30.camel@victoria> <935ead450807110921i2957c782va08a5836f1f7a665@mail.gmail.com> Message-ID: <4877897D.5000001@kanarip.com> Jeffrey Ollie wrote: > 2008/7/11 Paul W. Frields : >> Anyone have insight into this? > > The issue is that something in postfix on collab1 (where the > lists.fedoraproject.org mailing lists run) and/or bastion (which > serves as a central mail gateway) is rewriting > "@lists.fedoraproject.org" addresses in the message > headers to "@fedoraproject.org". When someone then tries > to reply to a mailing list post the message is bounced as > "@fedoraproject.org" is an invalid address. I don't have > enough postfix-fu to fix the problem and no one with enough postfix-fu > has had the time, access, and/or interest in fixing the problem. > > Until this problem is fixed I've been hesitant to create any (more) > lists.fedoraproject.org mailing lists. > > lists.fedorahosted.org has a similar problem, except that > "@fedorahosted.org" works due to some quirks of how > postfix interprets email addresses (AFAIK without a some hackery > postfix can't treat "@lists." differently from "@"). > Has anyone checked the "masquerade domains" and "masquerade domains except" settings or their postfix equivalents? Kind regards, Jeroen van Meeuwen -kanarip From dennis at ausil.us Fri Jul 11 17:01:13 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 11 Jul 2008 12:01:13 -0500 Subject: [Fwd: Re: Announcing the Fedora EDU Spin Preview] In-Reply-To: <935ead450807110921i2957c782va08a5836f1f7a665@mail.gmail.com> References: <1215791257.8058.30.camel@victoria> <935ead450807110921i2957c782va08a5836f1f7a665@mail.gmail.com> Message-ID: <200807111201.19557.dennis@ausil.us> On Friday 11 July 2008, Jeffrey Ollie wrote: > 2008/7/11 Paul W. Frields : > > Anyone have insight into this? > > The issue is that something in postfix on collab1 (where the > lists.fedoraproject.org mailing lists run) and/or bastion (which > serves as a central mail gateway) is rewriting > "@lists.fedoraproject.org" addresses in the message > headers to "@fedoraproject.org". When someone then tries > to reply to a mailing list post the message is bounced as > "@fedoraproject.org" is an invalid address. I don't have > enough postfix-fu to fix the problem and no one with enough postfix-fu > has had the time, access, and/or interest in fixing the problem. The issue is not postfix. the issue is mailman setting the replyto wrong. Even when i explicitly set the reply to correctly on the secondary arch list it is still wrong. > Until this problem is fixed I've been hesitant to create any (more) > lists.fedoraproject.org mailing lists. > > lists.fedorahosted.org has a similar problem, except that > "@fedorahosted.org" works due to some quirks of how > postfix interprets email addresses (AFAIK without a some hackery > postfix can't treat "@lists." differently from "@"). im pretty sure it only works because lists.fedorahosted.org and fedorahosted.org are on the same box. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From jeff at ocjtech.us Fri Jul 11 18:34:43 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 11 Jul 2008 13:34:43 -0500 Subject: [Fwd: Re: Announcing the Fedora EDU Spin Preview] In-Reply-To: <200807111201.19557.dennis@ausil.us> References: <1215791257.8058.30.camel@victoria> <935ead450807110921i2957c782va08a5836f1f7a665@mail.gmail.com> <200807111201.19557.dennis@ausil.us> Message-ID: <935ead450807111134j4f1aa1e7o39a1c5b83d7ddaa9@mail.gmail.com> 2008/7/11 Dennis Gilmore : > On Friday 11 July 2008, Jeffrey Ollie wrote: >> 2008/7/11 Paul W. Frields : >> > Anyone have insight into this? >> >> The issue is that something in postfix on collab1 (where the >> lists.fedoraproject.org mailing lists run) and/or bastion (which >> serves as a central mail gateway) is rewriting >> "@lists.fedoraproject.org" addresses in the message >> headers to "@fedoraproject.org". When someone then tries >> to reply to a mailing list post the message is bounced as >> "@fedoraproject.org" is an invalid address. I don't have >> enough postfix-fu to fix the problem and no one with enough postfix-fu >> has had the time, access, and/or interest in fixing the problem. > > The issue is not postfix. the issue is mailman setting the replyto wrong. > Even when i explicitly set the reply to correctly on the secondary arch list > it is still wrong. The attached excerpts from the mail log on collab1 and the packet capture of mailman sending out a test message to the rel-eng lists show that mailman is sending out messages with the proper "@lists.fedoraproject.org" headers. Date: Fri, 11 Jul 2008 13:07:22 -0500 From: "Jeffrey Ollie" To: "Discussion list for Fedora Release Engineering" . Subject: test 1 2 3 MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: rel-eng at lists.fedoraproject.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Discussion list for Fedora Release Engineering . List-Id: Discussion list for Fedora Release Engineering . List-Unsubscribe: , . List-Archive: List-Post: List-Help: List-Subscribe: , . Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rel-eng-bounces at lists.fedoraproject.org Errors-To: rel-eng-bounces at lists.fedoraproject.org >> Until this problem is fixed I've been hesitant to create any (more) >> lists.fedoraproject.org mailing lists. >> >> lists.fedorahosted.org has a similar problem, except that >> "@fedorahosted.org" works due to some quirks of how >> postfix interprets email addresses (AFAIK without a some hackery >> postfix can't treat "@lists." differently from "@"). > > im pretty sure it only works because lists.fedorahosted.org and > fedorahosted.org are on the same box. That was my conclusion as well. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman.log Type: application/octet-stream Size: 3715 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mailman.cap Type: application/octet-stream Size: 12561 bytes Desc: not available URL: From loupgaroublond at gmail.com Thu Jul 17 10:44:01 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jul 2008 12:44:01 +0200 Subject: doing FAS2 with sqlalchemy-migrate Message-ID: <7f692fec0807170344w415214b6n7f83ea55192f93e0@mail.gmail.com> Hey List, There are alot of tickets for FAS2 outstanding that require some changes to the DB. Toshio is working on getting sqlalchemy-migrate into Fedora now, so I felt it would be fitting to get FAS2 to be an example of how to do it right. (This means I am probably doing something wrong.) http://git.fedorahosted.org/git/fas.git?p=fas.git;a=commitdiff;h=21643256e4840aa2179b8f2d6cf230ab714603a9 This git commit sets up migration for us. The instructions how to use it are there. In short, the overlying design is to assume the DB has already been configured and deployed using the old method. This will manage changes we do on top. This will make it easier for people with working development trees to simply migrate their dev systems over without having to start their DB fresh. Please poke holes in this plan, so we can have something more solid that can be used as a gold standard for Fedora Infrastructure development. -Yaakov From mmcgrath at redhat.com Thu Jul 17 14:14:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Jul 2008 09:14:23 -0500 (CDT) Subject: Database Upgrades Message-ID: So next week will be an interesting week regarding our databases. It just so happened this way but db1 and db3 will be ready at about the same time. The new db1 will replace the old db1 exactly. We'd already migrated to it a couple of weeks ago but had to revert after some memory issues came up. I believe that has been resolved. db3 is a little different. db2 will remain as the primary database for all databases except for koji. Koji will get moved to db3 which will also have Postgresql 8.3 on it. I'd like to leave db2 at 8.1 for the immediate future, after we've determined db3 is a success we'll schedule a time to update db2 to 8.3 as well. Initial, very basic tests (db import) showed that with koji at least, postgresql 8.3 was significantly faster. 8.5 hours instead of 14.4 hours to import the koji database. -Mike From oliver at linux-kernel.at Thu Jul 17 14:29:10 2008 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 17 Jul 2008 16:29:10 +0200 Subject: Database Upgrades In-Reply-To: References: Message-ID: <487F5736.4030503@linux-kernel.at> Mike McGrath wrote: > So next week will be an interesting week regarding our databases. It just > so happened this way but db1 and db3 will be ready at about the same time. > The new db1 will replace the old db1 exactly. We'd already migrated to it > a couple of weeks ago but had to revert after some memory issues came up. > I believe that has been resolved. > > db3 is a little different. db2 will remain as the primary database for > all databases except for koji. Koji will get moved to db3 which will also > have Postgresql 8.3 on it. I'd like to leave db2 at 8.1 for the immediate > future, after we've determined db3 is a success we'll schedule a time to > update db2 to 8.3 as well. > > Initial, very basic tests (db import) showed that with koji at least, > postgresql 8.3 was significantly faster. 8.5 hours instead of 14.4 hours > to import the koji database. Mike, just to let you know. My koji runs on pgsql 8.3.3 since yesterday - AFAICS no problems. -of From lmacken at redhat.com Thu Jul 17 14:40:29 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 17 Jul 2008 10:40:29 -0400 Subject: doing FAS2 with sqlalchemy-migrate In-Reply-To: <7f692fec0807170344w415214b6n7f83ea55192f93e0@mail.gmail.com> References: <7f692fec0807170344w415214b6n7f83ea55192f93e0@mail.gmail.com> Message-ID: <20080717144029.GC22081@x300.bos.redhat.com> On Thu, Jul 17, 2008 at 12:44:01PM +0200, Yaakov Nemoy wrote: > Hey List, > > There are alot of tickets for FAS2 outstanding that require some > changes to the DB. Toshio is working on getting sqlalchemy-migrate > into Fedora now, so I felt it would be fitting to get FAS2 to be an > example of how to do it right. (This means I am probably doing > something wrong.) > > http://git.fedorahosted.org/git/fas.git?p=fas.git;a=commitdiff;h=21643256e4840aa2179b8f2d6cf230ab714603a9 > > This git commit sets up migration for us. The instructions how to use > it are there. In short, the overlying design is to assume the DB has > already been configured and deployed using the old method. This will > manage changes we do on top. This will make it easier for people with > working development trees to simply migrate their dev systems over > without having to start their DB fresh. > > Please poke holes in this plan, so we can have something more solid > that can be used as a gold standard for Fedora Infrastructure > development. I reviewed and approved python-migrate yesterday. It's currently waiting to be built. https://bugzilla.redhat.com/show_bug.cgi?id=452388 luke From loupgaroublond at gmail.com Thu Jul 17 15:45:44 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jul 2008 17:45:44 +0200 Subject: doing FAS2 with sqlalchemy-migrate In-Reply-To: <20080717144029.GC22081@x300.bos.redhat.com> References: <7f692fec0807170344w415214b6n7f83ea55192f93e0@mail.gmail.com> <20080717144029.GC22081@x300.bos.redhat.com> Message-ID: <7f692fec0807170845g2229d87dua96b685008f79459@mail.gmail.com> On Thu, Jul 17, 2008 at 4:40 PM, Luke Macken wrote: > > I reviewed and approved python-migrate yesterday. It's currently > waiting to be built. > > https://bugzilla.redhat.com/show_bug.cgi?id=452388 How long does that take? I'll have to change the docs once it's done. -Yaakov From ricky at fedoraproject.org Thu Jul 17 20:30:39 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 17 Jul 2008 16:30:39 -0400 Subject: Meeting Log - 2008-07-17 Message-ID: <20080717203039.GA23412@Max> 16:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's Here? 16:00 * ricky 16:00 * ianweller 16:00 * SmootherFrOgZ 16:00 < G> baaa 16:01 * abadger1999 16:01 < mmcgrath> Ok, lets get cracking 16:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 16:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 16:02 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 16:02 * skvidal is 16:02 * dgilmore 16:02 < mmcgrath> .ticket 395 16:02 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:02 < mmcgrath> jcollie: around? 16:03 < mmcgrath> ok, we'll skip that for now 16:03 < mmcgrath> .ticket 446 16:03 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 16:03 < mmcgrath> dgilmore: ping ^^ 16:04 -!- balor [n=balor at gimili.plus.com] has joined #fedora-meeting 16:04 < mmcgrath> wow, going to be a short meeting I suspect. 16:04 < ricky> Heh. 16:04 < mmcgrath> .ticket 547 16:04 < SmootherFrOgZ> ^^ 16:04 < zodbot> mmcgrath: #547 (Koji DB Server as postgres 8.3) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/547 16:04 < mmcgrath> I've been working on testing the imports and things. 16:05 < SmootherFrOgZ> do you want help on this part ? 16:05 < mmcgrath> So far so good. When I first started testing I had a ext3 abort on me but haven't seen that happen since. And have done many more restores with it 16:05 < mmcgrath> SmootherFrOgZ: thanks but I think we're all set. I'm just waiting to hear back from f13 about the exact outage times. 16:05 < mmcgrath> It will take 8-10 hours to import 16:05 < SmootherFrOgZ> k 16:06 < mmcgrath> It took 5 fewer hours to import to 8.3 then to 8.1 of the same hardware configuration. 16:06 < mmcgrath> so we may see significant performance gain with koji. 16:06 < mmcgrath> .ticket 576 16:06 < zodbot> mmcgrath: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/576 16:06 < G> no update here 16:07 < mmcgrath> G: you given any further thought to this? I've been testing some sshfs and encfs combo's with success. its an option worth looking at 16:07 < mmcgrath> 16:07 < mmcgrath> next ticket 16:07 < G> yeah, it's been playing at the back of my mind :) 16:07 < mmcgrath> .ticket 448 16:07 < zodbot> mmcgrath: #448 (Hosting request for fedora-quotes) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/448 16:07 * mmcgrath swore this was all fixed 16:07 < mmcgrath> I'll comment and close it. 16:07 < ricky> Thanks 16:07 * ricky should have done that last week 16:08 < mmcgrath> Ok, thats that. 16:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Torrent1 16:08 < mmcgrath> skvidal: ^^ 16:08 < mmcgrath> whats the torrent1 plan? its been up and running for a while. 16:09 < skvidal> it has been 16:09 < skvidal> yay 16:09 < mmcgrath> yeah 16:09 < skvidal> we can give it a shot for alpha 16:09 < skvidal> we'll see how much whatever-the-hell-xen-does 16:09 < skvidal> makes it blow up 16:09 < skvidal> :) 16:09 < mmcgrath> Thats till in a few weeks right? 16:09 < mmcgrath> f13: ping 16:10 < mmcgrath> notting: ping 16:10 < G> yeah, begining of August iirc 16:10 < notting> mmcgrath: yes? 16:10 < mmcgrath> do either of you know how much room is needed for the alpha release? 16:10 < skvidal> mmcgrath: there's 244G free on torrent1 16:10 < skvidal> we should be fine :) 16:10 < notting> if you budget the amount that was needed for f9, you can't go wrong 16:10 -!- sdziallas [n=sebastia at p57A2F945.dip.t-dialin.net] has joined #fedora-meeting 16:10 * nirik notes that the Xfce spin should be done... but it's not up anywhere yet... I think f13 was going to see about trying to put it on torrent1. 16:10 < dgilmore> notting: +10% 16:10 < mmcgrath> skvidal: there's also about that much on the primary mirror. 16:11 < dgilmore> mmcgrath: can i put sparc there 16:11 < mmcgrath> no sparc for you! 16:11 < skvidal> dgilmore: hush 16:11 < skvidal> mmcgrath: nod 16:11 < mmcgrath> I'll make a ticket and check it out 16:11 < skvidal> mmcgrath: only sad thing 16:11 < skvidal> archive.fp.o has 7.7G free :( 16:11 < dgilmore> ouch 16:11 < skvidal> yah 16:12 < skvidal> not sure what we should do there 16:12 < G> yeah, that came up on nagios when I added it 16:12 < mmcgrath> skvidal: hopefully the HP box will be fixed by then. 16:13 < mmcgrath> I've purchased the warranty, its not gone through yet though. 16:13 < skvidal> nod 16:13 < mmcgrath> it has multiple T of storage available. 16:13 < skvidal> okay 16:13 < skvidal> yay for multiple T 16:13 < mmcgrath> skvidal: any other concerns with torrent1? 16:14 < skvidal> other than the ongoing disaster that is sb1? 16:14 < skvidal> no 16:14 < ricky> *cough*better than sb3*cough* 16:14 < mmcgrath> heh 16:14 < mmcgrath> ok, moving on 16:14 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Outage next week 16:15 < G> heh 16:15 < dgilmore> mmcgrath: power it all off :) 16:15 < ricky> Innage 16:15 < mmcgrath> I would have liked to do this tonight or tomorrow but I actually won't be around much this weekend so that seemed bad. 16:15 < mmcgrath> heh 16:15 < dgilmore> i assume this is to migrate to db3? 16:15 < mmcgrath> So here's whats going to happen. Hopefully monday night. 16:15 < ricky> And db1 at the same time 16:15 < mmcgrath> dgilmore: yeah, and the db1 migration. 16:15 < G> just as long as the voting app doesn't go down :) 16:15 < dgilmore> mmcgrath: lots of people will be absent next week 16:16 < ricky> It shouldn't 16:16 < dgilmore> fedora has a big presence at OLS 16:16 < G> (esp as we are in the middle of the FESCo elections) 16:16 < mmcgrath> .ticket 705 16:16 < zodbot> mmcgrath: #705 (DB upgrade (db1 db2)) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/705 16:16 < mmcgrath> G: it should be ok. 16:16 < mmcgrath> the longest outage will be koji, for around 10 hours. 16:16 < mmcgrath> That doesn't include much buffer for error. If something happens after hour 1, we're calling off the outage and doing it another time. 16:16 < dgilmore> mmcgrath: do we have postgresql-8.3 built? 16:16 < mmcgrath> The shorter outages are in smolt and mediawiki. 16:16 < G> dgilmore: yep 16:17 < mmcgrath> I'm hoping less then an hour. I'll be testing though. 16:17 < mmcgrath> dgilmore: yeah, its already on db3 and I've imported to it twice with success. 16:17 < mmcgrath> Just shy of 9 hours. 16:17 < dgilmore> then you need to analyze it 16:17 < dgilmore> but that can be done under load 16:17 < abadger1999> dgilmore: Yep. I've been tracking the F-9 builds and rebuilding for EL-5. 16:17 < dgilmore> abadger1999: :) 16:17 < mmcgrath> dgilmore: we need to analyze _after_ a fresh import? 16:17 < mmcgrath> do the pgsql admins drink a lot or just hate operations people and... logic? 16:18 < abadger1999> I think so. 16:18 < dgilmore> mmcgrath: its recommended 16:18 < abadger1999> Not a vacuum but analyse yes. 16:18 < ricky> Hehe 16:18 < mmcgrath> what a useless piece of crap. 16:18 < SmootherFrOgZ> haha 16:18 < mmcgrath> seriously, how could someone think thats ok? 16:18 < abadger1999> (analyze runs over your data as it sits on the disks and decides what query plans will be better) 16:18 < dgilmore> supposed to get the planers right 16:18 < mmcgrath> we don't have to deal with any of that bs in mysql, and never have. 16:18 < dgilmore> indeed 16:19 < mmcgrath> anyway, ok. I'll be analyzing the tables as well. 16:19 * mmcgrath needs to not think about that right now as it just makes him angry at the world. 16:19 < mmcgrath> skvidal: did you just take sb1 down? 16:19 < skvidal> no 16:19 < mmcgrath> .ping serverbeach1.fedoraproject.org 16:19 < zodbot> pong 16:19 < skvidal> but I've noticed it has issues everytime we talk about it 16:19 < mmcgrath> hrm 16:19 < abadger1999> It's shy. 16:19 < G> VPN most likely 16:19 < mmcgrath> yeah, that pong is a lie. I can't get to it 16:20 < skvidal> G: not from where I am 16:20 < skvidal> the pong is a lie 16:20 < mmcgrath> zodbot's pinging system is pretty weak. 16:20 < G> .ping 16:20 < zodbot> pong 16:20 < skvidal> hahah 16:20 < ricky> Blech. 16:20 < ricky> .ping aw243hy2a3i420r 16:20 < zodbot> pong 16:20 < mmcgrath> oh, its that kind of ping :) 16:20 < mmcgrath> heheheh 16:20 < dgilmore> .slap serverbeach1.fedoraproject.org 16:20 < mmcgrath> .list 16:20 < zodbot> mmcgrath: Admin, Channel, ChannelLogger, ChannelStats, Config, Fedora, Internet, Koji, Later, Misc, Owner, Plugin, RSS, Seen, ShrinkUrl, String, Time, URL, Unix, UrbanDict, User, and Web 16:20 < mmcgrath> .list Internet 16:20 < zodbot> mmcgrath: dns, hexip, and whois 16:20 < ricky> .list Web 16:20 < zodbot> ricky: doctype, fetch, headers, netcraft, size, title, urlquote, and urlunquote 16:20 < ianweller> .help pi9nt 16:20 < zodbot> ianweller: Error: There is no command "pi9nt". 16:20 < ianweller> .help ping 16:20 < zodbot> ianweller: (ping takes no arguments) -- Checks to see if the bot is alive. 16:20 < mmcgrath> .list misc 16:20 < zodbot> mmcgrath: apropos, help, last, list, more, ping, source, tell, and version 16:20 < skvidal> so 16:20 < skvidal> sb1 is down 16:20 < ianweller> hahahahhahhahhhaahahaha 16:20 < ricky> .misc ping 16:20 < zodbot> pong 16:20 < mmcgrath> ahwell. 16:20 < ianweller> we've been trusting on that forever?! 16:20 < G> oh SPAM! 16:20 < skvidal> .spam 16:21 < ricky> Woooohoo, "Rapid" Reboot time! 16:21 < mmcgrath> Ok, so thats really all I have right now so I'll open the floor. 16:21 < skvidal> ricky: "rapid" is right 16:21 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 16:21 < mmcgrath> who has things they'd like to discuss? 16:21 * skvidal suggests we poke sb1 in the eye 16:21 * ianweller suggests the spleen 16:21 < mmcgrath> skvidal: how is that possible? How did sb1 _just_ go down as we were talking about it? 16:21 < mmcgrath> did anyone even ssh to it or anything? 16:21 < skvidal> yep 16:21 * ricky couldn't get it 16:21 < skvidal> I ssh'd in and run 'df -h' 16:21 < ricky> **in 16:21 < mmcgrath> skvidal: and that killed it? 16:21 < skvidal> and then I logged out 16:21 < G> heh 16:21 < skvidal> apparently it did 16:21 < ianweller> skvidal: well don't do that then. ;) 16:22 < mmcgrath> thats amazing 16:22 < skvidal> yah 16:22 < skvidal> so 16:22 * dgilmore notes he will be more distracted than usual for the next 3 weeks 16:22 < ricky> :-) 16:22 < G> I've got nothing in particular, the proxy4->proxy1 rename went well 16:22 -!- SMParrish_mobile [i=20800ca5 at gateway/web/ajax/mibbit.com/x-4c55ac3e294ff48b] has left #fedora-meeting [] 16:22 < skvidal> do we have any hosts with enough ram and enough disk to take a torrent1 image? 16:22 < mmcgrath> G: yes it did, thank you for that. 16:22 * ricky will probably start obsessing over sb3 again.. soonish 16:22 < skvidal> ricky: are you scheduling the sb1 reboot now or should I? 16:22 < G> ummm lets see what else 16:22 < mmcgrath> skvidal: let me think about that. 16:23 < skvidal> mmcgrath: oh and they need to be not behind a firewall 16:23 < poelcat> is there an RFE ticket about email diff notifications from the wiki? 16:23 < ricky> skvidal: Sure, I'll get it 16:23 < mmcgrath> thats the real trick. 16:23 * poelcat couldn't find one 16:23 < skvidal> mmcgrath: option2 is what I suggested before 16:23 < mmcgrath> poelcat: I've not seen one. 16:23 < mmcgrath> skvidal: give option 2 a try. 16:23 * poelcat will create one 16:23 < skvidal> mmcgrath: we nuke sb1 from orbit and reinstall the fucker as SOLELY torrent 16:23 < skvidal> mmcgrath: okay, I'll see if I can do it tomorrow. 16:23 < G> poelcat: I'm sure I saw one 16:23 < mmcgrath> ianweller: do you know? 16:23 < skvidal> ricky: please do hit the reboot 16:24 < G> poelcat: the other things to note: 16:24 < ianweller> mmcgrath: no i do not know 16:24 < ricky> (Reboot initiated) 16:24 < poelcat> the more and more page watches I add the more painful clicking on the URL is getting :) 16:24 < ricky> skvidal: Ooh, let me know what luck you have with bare metal kickstarting 16:24 < ricky> (I've not had any luck with sb3 :-() 16:24 < poelcat> particuarly with all the feature page changes 16:24 < ianweller> G: weren't you looking into that? 16:24 < G> 1. Mediawiki only sends 1 notification per page per gap/whatever - i.e. you have to actually goto the page or view the diff to start getting new notifications 16:25 < skvidal> ricky: I shall, we did them before they can't be _that_ hard ;) 16:25 * dgilmore notes mediawiki sucks 16:25 < G> 2. As a result, the link to the diff is a dynamic one that'll always be from notifiededit-1 to current 16:25 < dgilmore> its only saving grace is a database backend 16:26 < poelcat> dgilmore: i was going to recommend moin, but they don't have a db ;-) 16:26 * nirik is happy with the rss feed of changes. 16:26 < G> poelcat: thats definately not how to get on my side :) 16:26 < ricky> skvidal: All I know is that the SOP (and a few other tries) didn't work - feel free to give it a kick or two :-) 16:27 < G> poelcat: so the problem is, Mediawiki's notification system is already fundamentally flawed in 1.11 :) 16:28 < mmcgrath> G: poelcat: mind taking that to the ticket? We can probably close the meeting quicker :) 16:28 < poelcat> mmcgrath: you got it 16:28 < mmcgrath> sweet 16:28 < ricky> I really wonder what they were thinking when they decided to put a link to the diff in the email 16:28 < mmcgrath> Ok, anyone have anything else they'd like to discuss? If not we can close the meeting in 30 16:28 < G> ricky: it saves on spam 16:29 < mmcgrath> 20 16:29 < ricky> Actually, I wonder how crazy wikipedia editors keep track of stuff like they do 16:29 < mmcgrath> 10 16:29 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting End -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Fri Jul 18 02:56:27 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Jul 2008 21:56:27 -0500 (CDT) Subject: Outage Notification - 2008-07-22 04:59 UTC (MAJOR) Message-ID: There will be an outage starting at 2008-07-22 04:59 UTC, which will last approximately 10 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-07-22 04:59 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Fedora Hosted Talk Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/705 Reason for Outage: Re-migrating db1 to its new hardware (memory issues have hopefully been resolved). Moving koji database from db2 to a dedicated new server, db3. The db1 outage will cause the wiki and smolt to be offline for no longer then an hour. The koji move will cause the buildsystem (and whatever depends on the build system) to be down for between 8 and 10 hours. We haven't padded the outage so if something goes wrong, we'll have to abort and re-schedule it for another time. Likely the next night so be prepared. Also please make sure any builds you complete any builds prior to the time of the outage. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From mmcgrath at redhat.com Fri Jul 18 15:18:08 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Jul 2008 10:18:08 -0500 (CDT) Subject: Database Upgrades In-Reply-To: References: Message-ID: On Thu, 17 Jul 2008, Mike McGrath wrote: > So next week will be an interesting week regarding our databases. It just > so happened this way but db1 and db3 will be ready at about the same time. > The new db1 will replace the old db1 exactly. We'd already migrated to it > a couple of weeks ago but had to revert after some memory issues came up. > I believe that has been resolved. > > db3 is a little different. db2 will remain as the primary database for > all databases except for koji. Koji will get moved to db3 which will also > have Postgresql 8.3 on it. I'd like to leave db2 at 8.1 for the immediate > future, after we've determined db3 is a success we'll schedule a time to > update db2 to 8.3 as well. > > Initial, very basic tests (db import) showed that with koji at least, > postgresql 8.3 was significantly faster. 8.5 hours instead of 14.4 hours > to import the koji database. > >From this point on please don't make any changes to db1, db2, db3, or the new db1 without coordinating with me first. This db freeze will be over after the upgrades. -Mike From lmacken at redhat.com Sun Jul 20 07:06:39 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 20 Jul 2008 03:06:39 -0400 Subject: doing FAS2 with sqlalchemy-migrate In-Reply-To: <7f692fec0807170845g2229d87dua96b685008f79459@mail.gmail.com> References: <7f692fec0807170344w415214b6n7f83ea55192f93e0@mail.gmail.com> <20080717144029.GC22081@x300.bos.redhat.com> <7f692fec0807170845g2229d87dua96b685008f79459@mail.gmail.com> Message-ID: <20080720070639.GA29757@x300> On Thu, Jul 17, 2008 at 05:45:44PM +0200, Yaakov Nemoy wrote: > On Thu, Jul 17, 2008 at 4:40 PM, Luke Macken wrote: > > > > I reviewed and approved python-migrate yesterday. It's currently > > waiting to be built. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=452388 > > How long does that take? > > I'll have to change the docs once it's done. python-migrate is now in updates-testing From loupgaroublond at gmail.com Sun Jul 20 08:16:11 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 20 Jul 2008 10:16:11 +0200 Subject: doing FAS2 with sqlalchemy-migrate In-Reply-To: <20080720070639.GA29757@x300> References: <7f692fec0807170344w415214b6n7f83ea55192f93e0@mail.gmail.com> <20080717144029.GC22081@x300.bos.redhat.com> <7f692fec0807170845g2229d87dua96b685008f79459@mail.gmail.com> <20080720070639.GA29757@x300> Message-ID: <7f692fec0807200116q237c5d9fwdfe98669ee5bf130@mail.gmail.com> On Sun, Jul 20, 2008 at 9:06 AM, Luke Macken wrote: > On Thu, Jul 17, 2008 at 05:45:44PM +0200, Yaakov Nemoy wrote: >> On Thu, Jul 17, 2008 at 4:40 PM, Luke Macken wrote: >> > >> > I reviewed and approved python-migrate yesterday. It's currently >> > waiting to be built. >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=452388 >> >> How long does that take? >> >> I'll have to change the docs once it's done. > > python-migrate is now in updates-testing I'll modify the documentation to presume it's already in Fedora then, namely just adding 'python-migrate' to the list of dependencies. -Yaakov From ricky at fedoraproject.org Tue Jul 22 08:01:58 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 22 Jul 2008 04:01:58 -0400 Subject: Database outage puppet updates Message-ID: <20080722080158.GA7181@Max> During tonight's outage, I've accumulated a good number of unpushed commits in my puppet clone, specifically on the db node manifests, the db service, db backup scripts, and just about all of the noc1 nagios hosts and hostgroups (and the pgsql service). I plan to push all these changes in one shot tomorrow if the db migration works out, so I'd appreciate it if everybody could avoid pushing puppet changes in these areas until this has happened in order to prevent ugly/complex merges. Thanks a lot, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Tue Jul 22 14:37:28 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Jul 2008 07:37:28 -0700 Subject: [Fwd: Cron /bin/sleep $(($RANDOM/20)); /usr/bin/fasClient -i] Message-ID: <4885F0A8.9010806@gmail.com> I've updated fasClient with what we have in fas's git repository on fas[12], app[123456], publictest10, publictest9, fedorapeople.org,and releng2. We shouldn't get more DeprecationWarnings from those hosts. We'll have a new FAS package in the next few days that will incorporate these changes. -Toshio -------- Original Message -------- Subject: Cron /bin/sleep $(($RANDOM/20)); /usr/bin/fasClient -i Date: Tue, 22 Jul 2008 06:29:37 -0700 From: root at publictest10.fedoraproject.org (Cron Daemon) To: root at publictest10.fedoraproject.org /usr/bin/fasClient:377: DeprecationWarning: send_request(input) is deprecated. Use send_request(req_params) instead request = self.send_request('group/list', auth=True, input=params) /usr/bin/fasClient:424: DeprecationWarning: send_request(input) is deprecated. Use send_request(req_params) instead data = self.send_request('user/list', auth=True, input=params) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Tue Jul 22 17:19:37 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 22 Jul 2008 13:19:37 -0400 Subject: Database outage puppet updates In-Reply-To: <20080722080158.GA7181@Max> References: <20080722080158.GA7181@Max> Message-ID: <20080722171937.GB7181@Max> On 2008-07-22 04:01:58 AM, Ricky Zhou wrote: > I plan to push all these changes in one shot tomorrow if the db > migration works out, so I'd appreciate it if everybody could avoid > pushing puppet changes in these areas until this has happened in order > to prevent ugly/complex merges. Thanks, everybody - the commits are pushed now, so push away! Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Jul 22 21:07:49 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 22 Jul 2008 23:07:49 +0200 Subject: Fw: Returned mail: see transcript for details Message-ID: <20080722230749.a9c678da.bugs.michael@gmx.net> A commit to Fedora non-pkg CVS triggered the following: [...] Begin forwarded message: Date: Mon, 21 Jul 2008 20:28:08 -0400 From: Mail Delivery Subsystem To: mschwendt Subject: Returned mail: see transcript for details The original message was received at Mon, 21 Jul 2008 20:28:07 -0400 from bastion.fedora.phx.redhat.com [10.8.34.50] ----- The following addresses had permanent fatal errors ----- (reason: 554 5.7.1 : Relay access denied) ----- Transcript of session follows ----- ... while talking to mail-int.fedora.redhat.com.: >>> DATA <<< 554 5.7.1 : Relay access denied 554 5.0.0 Service unavailable <<< 554 5.5.1 Error: no valid recipients -- From mmcgrath at redhat.com Wed Jul 23 03:10:33 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jul 2008 22:10:33 -0500 (CDT) Subject: Fw: Returned mail: see transcript for details In-Reply-To: <20080722230749.a9c678da.bugs.michael@gmx.net> References: <20080722230749.a9c678da.bugs.michael@gmx.net> Message-ID: We had some mail issues today wrt cvs mail. If you get this again please let us know. I made some changes today that fixed nirik's and someone elses issue but may have introduced another. I was never able to recreate the error myself. -Mike On Tue, 22 Jul 2008, Michael Schwendt wrote: > A commit to Fedora non-pkg CVS triggered the following: > > [...] > > Begin forwarded message: > > Date: Mon, 21 Jul 2008 20:28:08 -0400 > From: Mail Delivery Subsystem > To: mschwendt > Subject: Returned mail: see transcript for details > > > The original message was received at Mon, 21 Jul 2008 20:28:07 -0400 > from bastion.fedora.phx.redhat.com [10.8.34.50] > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 5.7.1 : Relay access denied) > > ----- Transcript of session follows ----- > ... while talking to mail-int.fedora.redhat.com.: > >>> DATA > <<< 554 5.7.1 : Relay access denied > 554 5.0.0 Service unavailable > <<< 554 5.5.1 Error: no valid recipients > > > > -- > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Wed Jul 23 03:13:53 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jul 2008 22:13:53 -0500 (CDT) Subject: bash $TMOUT Message-ID: Sooooo, I'd like to set a $TMOUT for all of our bash sessions. I see a lot of shells just needlessly open. This is going to piss people off though, I haven't even done it yet and its pissing me off :) Are there any very vocal oppositions to this? Any alternatives? I'd like to at a minimum install it on fedorapeople. -Mike From dev at nigelj.com Wed Jul 23 03:19:06 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 23 Jul 2008 15:19:06 +1200 Subject: bash $TMOUT In-Reply-To: References: Message-ID: <4886A32A.4020008@nigelj.com> Mike McGrath wrote: > Sooooo, I'd like to set a $TMOUT for all of our bash sessions. I see a > lot of shells just needlessly open. This is going to piss people off > though, I haven't even done it yet and its pissing me off :) > > Are there any very vocal oppositions to this? Any alternatives? I'd like > to at a minimum install it on fedorapeople. > I object your honour! a) It's a PITA, login, get distracted for an hour or two and find out that your session died.... b) I think this is the problem I have with proxy4 (now proxy1) where it cuts me off after an hour... hmmm c) Fedora People is a different story, yes please do, 3 hours maybe... - Nigel > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > From mmcgrath at redhat.com Wed Jul 23 03:33:57 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jul 2008 22:33:57 -0500 (CDT) Subject: bash $TMOUT In-Reply-To: <4886A32A.4020008@nigelj.com> References: <4886A32A.4020008@nigelj.com> Message-ID: On Wed, 23 Jul 2008, Nigel Jones wrote: > Mike McGrath wrote: > > Sooooo, I'd like to set a $TMOUT for all of our bash sessions. I see a > > lot of shells just needlessly open. This is going to piss people off > > though, I haven't even done it yet and its pissing me off :) > > > > Are there any very vocal oppositions to this? Any alternatives? I'd like > > to at a minimum install it on fedorapeople. > > > I object your honour! > > a) It's a PITA, login, get distracted for an hour or two and find out that > your session died.... > b) I think this is the problem I have with proxy4 (now proxy1) where it cuts > me off after an hour... hmmm > c) Fedora People is a different story, yes please do, 3 hours maybe... > I was thinking 8 hours.. and the problems you're seeing with proxy4 is something else. -Mike From mmcgrath at redhat.com Wed Jul 23 03:35:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jul 2008 22:35:48 -0500 (CDT) Subject: bash $TMOUT In-Reply-To: References: <4886A32A.4020008@nigelj.com> Message-ID: On Tue, 22 Jul 2008, Mike McGrath wrote: > On Wed, 23 Jul 2008, Nigel Jones wrote: > > > Mike McGrath wrote: > > > Sooooo, I'd like to set a $TMOUT for all of our bash sessions. I see a > > > lot of shells just needlessly open. This is going to piss people off > > > though, I haven't even done it yet and its pissing me off :) > > > > > > Are there any very vocal oppositions to this? Any alternatives? I'd like > > > to at a minimum install it on fedorapeople. > > > > > I object your honour! > > > > a) It's a PITA, login, get distracted for an hour or two and find out that > > your session died.... > > b) I think this is the problem I have with proxy4 (now proxy1) where it cuts > > me off after an hour... hmmm > > c) Fedora People is a different story, yes please do, 3 hours maybe... > > > > I was thinking 8 hours.. and the problems you're seeing with proxy4 is > something else. > Trying to prevent stuff like this: XXX pts/7 XXX 06Jul08 10:11 0.06s 0.10s sshd: XXX [priv] ^^^^^^^ holy moly :) -Mike From kanarip at kanarip.com Wed Jul 23 07:33:51 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 23 Jul 2008 09:33:51 +0200 Subject: bash $TMOUT In-Reply-To: References: <4886A32A.4020008@nigelj.com> Message-ID: <4886DEDF.9050707@kanarip.com> Mike McGrath wrote: > Trying to prevent stuff like this: > > XXX pts/7 XXX 06Jul08 10:11 0.06s 0.10s sshd: XXX [priv] > ^^^^^^^ holy moly :) > holy alright ^^^^ -Jeroen From jorge at konnekt.org Wed Jul 23 13:54:21 2008 From: jorge at konnekt.org (Jorge Bras) Date: Wed, 23 Jul 2008 14:54:21 +0100 Subject: bash $TMOUT In-Reply-To: References: Message-ID: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> Hi there, If people start using screen they just have to reconnect, et voila, continue to work. At least for me, screen was the solution. just my 2 cents. ./bras On Jul 23, 2008, at 4:13 AM, Mike McGrath wrote: > Sooooo, I'd like to set a $TMOUT for all of our bash sessions. I > see a > lot of shells just needlessly open. This is going to piss people off > though, I haven't even done it yet and its pissing me off :) > > Are there any very vocal oppositions to this? Any alternatives? > I'd like > to at a minimum install it on fedorapeople. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Wed Jul 23 14:07:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Jul 2008 09:07:58 -0500 (CDT) Subject: bash $TMOUT In-Reply-To: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> Message-ID: On Wed, 23 Jul 2008, Jorge Bras wrote: > > Hi there, > > If people start using screen they just have to reconnect, et voila, continue > to work. > At least for me, screen was the solution. > > just my 2 cents. > Even in screen's case it'd kill the session during the timeout, unless someone unset $TMOUT Perhaps thats what we'll do, and if people have a problem with it, they can set their own $TMOUT value in their .bashrc file. -Mike From cra at WPI.EDU Wed Jul 23 16:15:02 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jul 2008 12:15:02 -0400 Subject: bash $TMOUT In-Reply-To: References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> Message-ID: <20080723161502.GT23765@angus.ind.WPI.EDU> On Wed, Jul 23, 2008 at 09:07:58AM -0500, Mike McGrath wrote: > Perhaps thats what we'll do, and if people have a problem with it, they > can set their own $TMOUT value in their .bashrc file. Can we have tcsh? From mmcgrath at redhat.com Wed Jul 23 18:37:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Jul 2008 13:37:09 -0500 (CDT) Subject: Spam headers @fp.o addresses Message-ID: I've started adding spam headers to all @fp.o emails. Please keep your eyes and ears out for any strangeness. We'll likely have to further configure things. I've also been considering changing the standard spam headers to fedora specific headers so people understand where they are coming from and can use them, in conjunction with their local spam scanners. I'm really not sure what happens to our spam headers if another spamassassin server scans them, I'd assume ours would just vanish. -Mike From skvidal at fedoraproject.org Wed Jul 23 18:40:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Jul 2008 14:40:06 -0400 Subject: Spam headers @fp.o addresses In-Reply-To: References: Message-ID: <1216838406.10981.39.camel@rosebud> On Wed, 2008-07-23 at 13:37 -0500, Mike McGrath wrote: > I've started adding spam headers to all @fp.o emails. Please keep your > eyes and ears out for any strangeness. We'll likely have to further > configure things. I've also been considering changing the standard spam > headers to fedora specific headers so people understand where they are > coming from and can use them, in conjunction with their local spam > scanners. > > I'm really not sure what happens to our spam headers if another > spamassassin server scans them, I'd assume ours would just vanish. > Yes, b/c they can't really be trusted to not have been added elsewhere. -sv From ricky at fedoraproject.org Wed Jul 23 20:40:37 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 23 Jul 2008 16:40:37 -0400 Subject: bash $TMOUT In-Reply-To: References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> Message-ID: <20080723204037.GB21798@Max> On 2008-07-23 09:07:58 AM, Mike McGrath wrote: > On Wed, 23 Jul 2008, Jorge Bras wrote: > > If people start using screen they just have to reconnect, et voila, continue > > to work. > > At least for me, screen was the solution. A downside with that solution is that if I detach a screen session and end my SSH session, the next time I reattach, I lose my SSH agent, and that means having to type SSH passwords repeatedly until I completely destroy and reconstruct the screen session. > Even in screen's case it'd kill the session during the timeout, unless > someone unset $TMOUT > > Perhaps thats what we'll do, and if people have a problem with it, they > can set their own $TMOUT value in their .bashrc file. Hey, if it's not particularly frowned upon to override that value (with the knowledge that you have to be extremely careful in locking your laptop/desktop), then I'm all for it :-) Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Jul 23 20:50:10 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Jul 2008 15:50:10 -0500 (CDT) Subject: bash $TMOUT In-Reply-To: <20080723204037.GB21798@Max> References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> <20080723204037.GB21798@Max> Message-ID: On Wed, 23 Jul 2008, Ricky Zhou wrote: > On 2008-07-23 09:07:58 AM, Mike McGrath wrote: > > On Wed, 23 Jul 2008, Jorge Bras wrote: > > > If people start using screen they just have to reconnect, et voila, continue > > > to work. > > > At least for me, screen was the solution. > A downside with that solution is that if I detach a screen session > and end my SSH session, the next time I reattach, I lose my SSH agent, > and that means having to type SSH passwords repeatedly until I > completely destroy and reconstruct the screen session. > > > Even in screen's case it'd kill the session during the timeout, unless > > someone unset $TMOUT > > > > Perhaps thats what we'll do, and if people have a problem with it, they > > can set their own $TMOUT value in their .bashrc file. > Hey, if it's not particularly frowned upon to override that value (with > the knowledge that you have to be extremely careful in locking your > laptop/desktop), then I'm all for it :-) > yeah, so far nothing's really "happened" because of bad voodoo. I'm not quite convinced a firm policy will help anything but at a minimum I think $TMOUT will help clean up old sessions. -Mike From brothers at logn.org Wed Jul 23 22:28:49 2008 From: brothers at logn.org (Jared Brothers) Date: Wed, 23 Jul 2008 18:28:49 -0400 Subject: bash $TMOUT In-Reply-To: <20080723204037.GB21798@Max> References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> <20080723204037.GB21798@Max> Message-ID: <5b2e5c580807231528ufdc98d4w45269404d22f392e@mail.gmail.com> 2008/7/23 Ricky Zhou : > On 2008-07-23 09:07:58 AM, Mike McGrath wrote: >> On Wed, 23 Jul 2008, Jorge Bras wrote: >> > If people start using screen they just have to reconnect, et voila, continue >> > to work. >> > At least for me, screen was the solution. > A downside with that solution is that if I detach a screen session > and end my SSH session, the next time I reattach, I lose my SSH agent, > and that means having to type SSH passwords repeatedly until I > completely destroy and reconstruct the screen session. The trick to using screen and an ssh agent is to reset the environment variables that point to your ssh connection. Here is a script I use to store the connection information in a file that is sourced by my shell if it can't find my agent, and the "ss" alias I use to rejoin my session from another location. I found this somewhere on the web and modified it. ~ % grep ssh-env .zaliases alias -- ss='~/bin/ssh-env && screen -d -R' ~ % cat bin/ssh-env #!/bin/sh SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY" for x in ${SSHVARS} ; do echo "export $x=\"$(eval echo \$$x)\"" done 1>$HOME/.ssh/env ~ % grep .ssh/env .zshenv ssh-add -l >/dev/null 2>&1 || { [[ -r ~/.ssh/env ]] && source ~/.ssh/env } -- Jared Brothers From cra at WPI.EDU Thu Jul 24 00:39:07 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jul 2008 20:39:07 -0400 Subject: bash $TMOUT In-Reply-To: <20080723204037.GB21798@Max> References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> <20080723204037.GB21798@Max> Message-ID: <20080724003907.GJ5960@angus.ind.WPI.EDU> On Wed, Jul 23, 2008 at 04:40:37PM -0400, Ricky Zhou wrote: > On 2008-07-23 09:07:58 AM, Mike McGrath wrote: > > On Wed, 23 Jul 2008, Jorge Bras wrote: > > > If people start using screen they just have to reconnect, et voila, continue > > > to work. > > > At least for me, screen was the solution. > A downside with that solution is that if I detach a screen session > and end my SSH session, the next time I reattach, I lose my SSH agent, > and that means having to type SSH passwords repeatedly until I > completely destroy and reconstruct the screen session. 1. Isn't it a bad idea to be storing your SSH keys long term in process memory of a remote system anyway? Or are these keys only for Fedora stuff? 2. Doesn't running screen with shells and stuff in it kinda defeat the purpose of $TMOUT? I mean, if the idea is to free up resources, you aren't really freeing up much if you can keep an idle screen session with 10 shells open in it with emacs or whathaveyou. From mmcgrath at redhat.com Thu Jul 24 00:44:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Jul 2008 19:44:25 -0500 (CDT) Subject: bash $TMOUT In-Reply-To: <20080724003907.GJ5960@angus.ind.WPI.EDU> References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> <20080723204037.GB21798@Max> <20080724003907.GJ5960@angus.ind.WPI.EDU> Message-ID: On Wed, 23 Jul 2008, Chuck Anderson wrote: > On Wed, Jul 23, 2008 at 04:40:37PM -0400, Ricky Zhou wrote: > > On 2008-07-23 09:07:58 AM, Mike McGrath wrote: > > > On Wed, 23 Jul 2008, Jorge Bras wrote: > > > > If people start using screen they just have to reconnect, et voila, continue > > > > to work. > > > > At least for me, screen was the solution. > > A downside with that solution is that if I detach a screen session > > and end my SSH session, the next time I reattach, I lose my SSH agent, > > and that means having to type SSH passwords repeatedly until I > > completely destroy and reconstruct the screen session. > > 1. Isn't it a bad idea to be storing your SSH keys long term in > process memory of a remote system anyway? Or are these keys only for > Fedora stuff? > > 2. Doesn't running screen with shells and stuff in it kinda defeat the > purpose of $TMOUT? I mean, if the idea is to free up resources, you > aren't really freeing up much if you can keep an idle screen session > with 10 shells open in it with emacs or whathaveyou. > 1) yes 2) The idea is more to ensure that sessions aren't just left open for someone to come upon and mess with. 6 days is a long time to have been logged in especially in idle. Means there's a shell who knows where protected by who knows what. I'd hate for someone to start a screen session on their remote machine, ssh into ours, and just leave it there for days having their machine get hacked, someone attaching to that screen session. Just one such example of an attack, the more obvious is having company over for the night, "mind if I use your computer?" sort of thing, or in a dorm room, or who knows what. Its not complete protection, but I think its a good first step. -Mike From cra at WPI.EDU Thu Jul 24 00:48:14 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jul 2008 20:48:14 -0400 Subject: bash $TMOUT In-Reply-To: References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> <20080723204037.GB21798@Max> <20080724003907.GJ5960@angus.ind.WPI.EDU> Message-ID: <20080724004814.GK5960@angus.ind.WPI.EDU> On Wed, Jul 23, 2008 at 07:44:25PM -0500, Mike McGrath wrote: > The idea is more to ensure that sessions aren't just left open for someone > to come upon and mess with. 6 days is a long time to have been logged in > especially in idle. Means there's a shell who knows where protected by > who knows what. I'd hate for someone to start a screen session on their > remote machine, ssh into ours, and just leave it there for days having > their machine get hacked, someone attaching to that screen session. > > Just one such example of an attack, the more obvious is having company > over for the night, "mind if I use your computer?" sort of thing, or in a > dorm room, or who knows what. Its not complete protection, but I think > its a good first step. Ok. I wonder if there is a way to launch "vlock" or similar instead of just forcing an autologout then? From ricky at fedoraproject.org Thu Jul 24 01:05:04 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 23 Jul 2008 21:05:04 -0400 Subject: bash $TMOUT In-Reply-To: <20080724003907.GJ5960@angus.ind.WPI.EDU> References: <9416EB39-4E69-410B-9DA7-5D668CA1864E@konnekt.org> <20080723204037.GB21798@Max> <20080724003907.GJ5960@angus.ind.WPI.EDU> Message-ID: <20080724010504.GH21798@Max> On 2008-07-23 08:39:07 PM, Chuck Anderson wrote: > 1. Isn't it a bad idea to be storing your SSH keys long term in > process memory of a remote system anyway? Or are these keys only for > Fedora stuff? Yes and yes :-) Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Jul 24 20:24:02 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 24 Jul 2008 16:24:02 -0400 Subject: Meeting Log - 2008-07-24 Message-ID: <20080724202402.GA6744@Max> 16:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 16:00 * ricky 16:00 < ivazquez> Pong. 16:01 * abadger1999 here 16:01 < fchiulli> * fchiulli lurking about 16:01 < mmcgrath> fchiulli: howdy! 16:01 < mmcgrath> Ok, lets get started. This could be a short meeting. 16:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 16:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 16:02 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 16:02 < mmcgrath> .ticket 671 16:02 < zodbot> mmcgrath: #671 (in.fedoraproject.org) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/671 16:02 < mmcgrath> anyone representing in.fedoraproject.org around? 16:02 -!- kschreyack [n=kschreya at mail.wirelesscapital.com] has joined #fedora-meeting 16:02 < ricky> mether: ping 16:03 < alex[slx]> Just going to watch this one (first time). 16:03 * skvidal is here, but late 16:04 < mmcgrath> Ok, moving on 16:04 < mmcgrath> .ticket 395 16:04 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:04 < mmcgrath> jcollie: you about? 16:05 < mmcgrath> k, moving on :) 16:06 < mmcgrath> .ticket 446 16:06 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 16:06 < mmcgrath> dgilmore: you around? 16:06 * mmcgrath suspects OLS 16:06 < mmcgrath> next ticket 16:06 < mmcgrath> .ticket 576 16:06 < zodbot> mmcgrath: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/576 16:06 < mmcgrath> I don't think there is anything new there 16:07 < mmcgrath> ricky: you heard anything? 16:07 * mmcgrath has been using sshfs and encfs pretty successfully. 16:07 < mmcgrath> scripted its pretty easy to setup 16:07 < ricky> G: I know you've been busy this week - any new thoughts? 16:09 < mmcgrath> heh, I suspect he's gone too 16:09 < mmcgrath> so moving on! 16:09 < mmcgrath> see, I told you this would be short :) 16:09 < ricky> Heh, yeah 16:09 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- DB outage 16:09 < mmcgrath> So the db outage was this week. 16:10 < mmcgrath> uber thanks to ricky! 16:10 < mmcgrath> It went pretty well, bit longer then we'd expected because of a bad first dump. 16:10 < mmcgrath> other then that though. All of the database servers have been putting along quite well 16:10 < mmcgrath> thats really all I have on that 16:10 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- network issues 16:11 < mmcgrath> We continue to see network issues between most of our hosts in the main fedora rack in PHX. 16:11 -!- MadBus [n=scott at c-68-51-66-81.hsd1.in.comcast.net] has left #Fedora-meeting ["Leaving"] 16:11 < mmcgrath> some changes went in today that seem to have helpped some hosts, but not others. 16:11 < mmcgrath> nothing really new there. 16:11 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- mmcgrath gone 16:11 < mmcgrath> I'll be gone starting tomorrow till Sunday and I'll be camping. 16:11 < mmcgrath> so don't expect for me to be around much 16:11 < ricky> Cool :-) 16:12 < fchiulli> mmcgrath: May the weather gods shine down on you. 16:12 < mmcgrath> :) 16:12 < mmcgrath> paintball. 16:12 * abadger1999 gets the orbital laser primed to make the batman symbol in case of emergencies :-) 16:12 < mmcgrath> rock climbing 16:12 < mmcgrath> and paintball rock climbing. 16:12 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 16:13 < mmcgrath> Who's got stuff to discuss? 16:13 < ricky> Anybody that has stuff on lockbox should start thinking about moving it :-) 16:14 < mmcgrath> ricky: yeah, might want to send an email to the list about that too. I'm pretty sure we're good there though 16:14 < ricky> Once all of the logs are in place, I'll probably talk to spevack and stickster about moving their stats stuff over 16:14 < ricky> Cool 16:14 < mmcgrath> ricky: one thing I'd like to do is look at moving the logging to tcp. 16:14 < mmcgrath> looks like we can setup spooling so that even when log1 goes down, it won't lose logs. 16:14 < mmcgrath> needs a closer look. 16:14 < ricky> Ah, cool 16:14 < mmcgrath> Anyone else have anything to discuss? 16:15 * stickster blinks 16:15 < abadger1999> python-fedora-0.3 has been deployed to fas and app servers. 16:15 < abadger1999> Looks good for deploying to the rest of infrastructure after we have the new fas package 16:15 < abadger1999> (fasClient needed tweaks) 16:15 < ricky> Ah, yes - hopefully, we'll have a FAS update with that soon. 16:16 < mmcgrath> yeah 16:16 < mmcgrath> stickster: do you know when the new privacy policy will be a go? 16:16 < stickster> mmcgrath: I don't -- since spot is at OLS and I'll be in BOS next week, I'd say we can give you an update by then 16:17 < abadger1999> Can we update the fas server before the privacy policy is live or do they have to be concurrent? 16:17 < ricky> abadger1999: At worst, moving over early is making things slightly better 16:17 < ricky> (As in, it's breaking our current policy less now) 16:17 < abadger1999> That was my thought too. 16:17 < stickster> Right, there's no problem with tightening up the actual services early. 16:18 < stickster> As long as when our new policy goes into action, it doesn't conflict with the actual service :-) 16:18 < mmcgrath> 16:18 < abadger1999> heh. Cool. 16:18 < stickster> But I am certain that you guys have once again outdone yourselves in that regard 16:18 -!- fchiulli_ [i=824c4010 at gateway/web/ajax/mibbit.com/x-35e769ac5445486c] has joined #fedora-meeting 16:18 * stickster washes Infrastructure car a little 16:18 < mmcgrath> what link do we use to refer to the new policy, same link? 16:19 < stickster> *wax on* *wax off* 16:19 < stickster> mmcgrath: Yes, the link won't change. 16:19 -!- fchiulli [i=824c4010 at gateway/web/ajax/mibbit.com/x-7817b8260bce18db] has quit "http://www.mibbit.com ajax IRC Client" 16:19 < stickster> We'll get the content slotted into the right place. 16:20 -!- fchiulli_ is now known as fchiulli 16:21 < mmcgrath> k 16:21 < mmcgrath> so thats that then. 16:21 < mmcgrath> anyone have anything else to discuss? 16:22 < mmcgrath> we'll close in 30 16:22 < mmcgrath> 15 16:22 < mmcgrath> 5 16:22 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting end! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bressers at redhat.com Fri Jul 25 11:45:22 2008 From: bressers at redhat.com (Josh Bressers) Date: Fri, 25 Jul 2008 07:45:22 -0400 Subject: YUM security issues... In-Reply-To: <5039.1216653594@devserv.devel.redhat.com> References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> Message-ID: <24312.1216986322@devserv.devel.redhat.com> On 21 July 2008, Josh Bressers wrote: > On 19 July 2008, "Justin Cappos" wrote: > > > > By the way, did you remove the ability for mirror admins to select a > > subnet where they'll serve all of the traffic? We're particularly > > concerned about this issue in the short term. We took our mirror > > down (mirror1.lockdownhosting.com) quite a while ago so we can't check > > for ourselves. > > > > I don't know the answer to this, so I'm adding the Fedora Infrastructure > list to the CC. > > For you Fedora Infrastructure guys, this is regarding this paper: > http://www.cs.arizona.edu/people/justin/packagemanagersecurity/ > > Thanks. > Sadly I'm resending this. The Fedora Infrastructure group doesn't have their act together, so my original message is stuck in a moderator queue nobody has the password for. I've subscribed to the list for the purpose of sending this mail. Can someone respond to the above question from Justin. Thanks. -- JB From jonrob at fedoraproject.org Fri Jul 25 13:18:03 2008 From: jonrob at fedoraproject.org (Jonathan Roberts) Date: Fri, 25 Jul 2008 14:18:03 +0100 Subject: WP MU Help Message-ID: <507738ef0807250618j731ed39aw9bcb2850a8b9a347@mail.gmail.com> Hi all, I've come here before talking about getting a news.fp.o site set up and running, and we've had a test instance up in the past with Lyceum but we decided to move in the direction of MU. Bret McMillan has been working very hard on this over the past several months and has now got a test instance up on publictest13. He has set-up a public git repo so that others can get the code he's been working on at: http://fedorapeople.org/~bretm/wordpress-mu.git And says to focus on the fedora branch as bretm-security is effectively dead now that those changes are upstream. There is a short to do list of tasks he still needs to accomplish, and we're looking for anyone who's interested in lending a hand to push this along. The todo list is (directly from Bret): 1) update wp-config.php generation to account for FORCE_SSL_LOGIN & FORCE_SSL_ADMIN directives 2) figure out why "blog/" url-path is missing for the primary blog when installed w/ VHOST == no, causes: https://bugzilla.redhat.com/show_bug.cgi?id=455801 3) do the formal RPM submission admin stuff 4) integrating w/ fedora account system; I have written a plugin internally for delegating authentication to mod_auth_*... once it clears the RH process for open-sourcing, can just use that 5) munging the puppet configs for publictest13; I'm slowly learning puppet, and have no idea what the norms are for Fedora Infrastructure in this regard. Guidance/help greatly appreciated. Any help would be hugely appreciated, along with any guidance on how to proceed from where we are now to going live with this :) Best, Jon From mmcgrath at redhat.com Fri Jul 25 15:29:42 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Jul 2008 10:29:42 -0500 (CDT) Subject: YUM security issues... In-Reply-To: <24312.1216986322@devserv.devel.redhat.com> References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> Message-ID: On Fri, 25 Jul 2008, Josh Bressers wrote: > On 21 July 2008, Josh Bressers wrote: > > On 19 July 2008, "Justin Cappos" wrote: > > > > > > By the way, did you remove the ability for mirror admins to select a > > > subnet where they'll serve all of the traffic? We're particularly > > > concerned about this issue in the short term. We took our mirror > > > down (mirror1.lockdownhosting.com) quite a while ago so we can't check > > > for ourselves. > > > > > > > I don't know the answer to this, so I'm adding the Fedora Infrastructure > > list to the CC. > > > > For you Fedora Infrastructure guys, this is regarding this paper: > > http://www.cs.arizona.edu/people/justin/packagemanagersecurity/ > > > > Thanks. > > > > Sadly I'm resending this. The Fedora Infrastructure group doesn't have > their act together, so my original message is stuck in a moderator queue > nobody has the password for. I've subscribed to the list for the purpose > of sending this mail. > > Can someone respond to the above question from Justin. > Wow, what a nice way to ask for help. One wonders why you didn't just file a bug or contact admin at fedoraproject.org. https://fedorahosted.org/fedora-infrastructure/ Side note, I'm still waiting on RHIT to email me a password for the list. -Mike From mmcgrath at redhat.com Fri Jul 25 15:37:33 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Jul 2008 10:37:33 -0500 (CDT) Subject: YUM security issues... In-Reply-To: References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> Message-ID: On Fri, 25 Jul 2008, Mike McGrath wrote: > On Fri, 25 Jul 2008, Josh Bressers wrote: > > > On 21 July 2008, Josh Bressers wrote: > > > On 19 July 2008, "Justin Cappos" wrote: > > > > > > > > By the way, did you remove the ability for mirror admins to select a > > > > subnet where they'll serve all of the traffic? We're particularly > > > > concerned about this issue in the short term. We took our mirror > > > > down (mirror1.lockdownhosting.com) quite a while ago so we can't check > > > > for ourselves. > > > > > > > AFAIK, this service is still in place and working fine. Though I am a little confused about the question. It sounds like you'd like to direct all subnet traffic to a specific mirror. But you're also saying you took your mirror down. Are you worried people in your subnet are being directed to a down mirror? -Mike From jkeating at redhat.com Fri Jul 25 15:42:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jul 2008 11:42:21 -0400 Subject: YUM security issues... In-Reply-To: References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> Message-ID: <1217000541.3119.19.camel@localhost.localdomain> On Fri, 2008-07-25 at 10:37 -0500, Mike McGrath wrote: > > AFAIK, this service is still in place and working fine. Though I am a > little confused about the question. It sounds like you'd like to direct > all subnet traffic to a specific mirror. But you're also saying you took > your mirror down. Are you worried people in your subnet are being > directed to a down mirror? More like taking over a subnet and directing all clients at a rouge mirror. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bressers at redhat.com Fri Jul 25 15:43:40 2008 From: bressers at redhat.com (Josh Bressers) Date: Fri, 25 Jul 2008 11:43:40 -0400 Subject: YUM security issues... In-Reply-To: References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> Message-ID: <3449.1217000620@devserv.devel.redhat.com> On 25 July 2008, Mike McGrath wrote: > On Fri, 25 Jul 2008, Mike McGrath wrote: > > > On Fri, 25 Jul 2008, Josh Bressers wrote: > > > > > On 21 July 2008, Josh Bressers wrote: > > > > On 19 July 2008, "Justin Cappos" wrote: > > > > > > > > > > By the way, did you remove the ability for mirror admins to select a > > > > > subnet where they'll serve all of the traffic? We're particularly > > > > > concerned about this issue in the short term. We took our mirror > > > > > down (mirror1.lockdownhosting.com) quite a while ago so we can't check > > > > > for ourselves. > > > > > > > > > > > AFAIK, this service is still in place and working fine. Though I am a > little confused about the question. It sounds like you'd like to direct > all subnet traffic to a specific mirror. But you're also saying you took > your mirror down. Are you worried people in your subnet are being > directed to a down mirror? > No, the problem is what happens when a malicious mirror claims a subnet? This is currently being viewed as a security issue due to this research: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html -- JB From mmcgrath at redhat.com Fri Jul 25 15:43:59 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Jul 2008 10:43:59 -0500 (CDT) Subject: YUM security issues... In-Reply-To: <1217000541.3119.19.camel@localhost.localdomain> References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> Message-ID: On Fri, 25 Jul 2008, Jesse Keating wrote: > On Fri, 2008-07-25 at 10:37 -0500, Mike McGrath wrote: > > > > AFAIK, this service is still in place and working fine. Though I am a > > little confused about the question. It sounds like you'd like to direct > > all subnet traffic to a specific mirror. But you're also saying you took > > your mirror down. Are you worried people in your subnet are being > > directed to a down mirror? > > More like taking over a subnet and directing all clients at a rouge > mirror. > that makes more sense. Domsch? -Mike From mdomsch at fedoraproject.org Fri Jul 25 16:07:10 2008 From: mdomsch at fedoraproject.org (Matt Domsch) Date: Fri, 25 Jul 2008 11:07:10 -0500 Subject: YUM security issues... In-Reply-To: References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> Message-ID: <20080725160710.GM20156@humbolt.us.dell.com> On Fri, Jul 25, 2008 at 10:43:59AM -0500, Mike McGrath wrote: > On Fri, 25 Jul 2008, Jesse Keating wrote: > > > On Fri, 2008-07-25 at 10:37 -0500, Mike McGrath wrote: > > > > > > AFAIK, this service is still in place and working fine. Though I am a > > > little confused about the question. It sounds like you'd like to direct > > > all subnet traffic to a specific mirror. But you're also saying you took > > > your mirror down. Are you worried people in your subnet are being > > > directed to a down mirror? > > > > More like taking over a subnet and directing all clients at a rouge > > mirror. > > that makes more sense. Domsch? Yes, this is a known challenge with subnet delegation in MirrorManager. We're trusting package signing (and soon, repodata signing) to prevent rogue mirrors from issuing unsigned data. In addition, I'm working on adding in a way to prevent stale mirrors (with signed content) from being used. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Fri Jul 25 16:35:39 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Jul 2008 11:35:39 -0500 (CDT) Subject: YUM security issues... In-Reply-To: <20080725160710.GM20156@humbolt.us.dell.com> References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> Message-ID: On Fri, 25 Jul 2008, Matt Domsch wrote: > On Fri, Jul 25, 2008 at 10:43:59AM -0500, Mike McGrath wrote: > > On Fri, 25 Jul 2008, Jesse Keating wrote: > > > > > On Fri, 2008-07-25 at 10:37 -0500, Mike McGrath wrote: > > > > > > > > AFAIK, this service is still in place and working fine. Though I am a > > > > little confused about the question. It sounds like you'd like to direct > > > > all subnet traffic to a specific mirror. But you're also saying you took > > > > your mirror down. Are you worried people in your subnet are being > > > > directed to a down mirror? > > > > > > More like taking over a subnet and directing all clients at a rouge > > > mirror. > > > > that makes more sense. Domsch? > > Yes, this is a known challenge with subnet delegation in > MirrorManager. We're trusting package signing (and soon, repodata > signing) to prevent rogue mirrors from issuing unsigned data. In > addition, I'm working on adding in a way to prevent stale mirrors > (with signed content) from being used. > Perhaps it might also be a good idea to add a comment to the default yum.conf for gpgcheck explaining what a bad idea it is to set to 0. I could imagine people setting it to 0 not understanding what they're doing. Especially if they're familiar with gpg's encryption bits, but not its signing functionality. -Mike From bressers at redhat.com Fri Jul 25 16:46:15 2008 From: bressers at redhat.com (Josh Bressers) Date: Fri, 25 Jul 2008 12:46:15 -0400 Subject: YUM security issues... In-Reply-To: <20080725160710.GM20156@humbolt.us.dell.com> References: <60e301c40807181725t68ca771apd5ba5a6cc9a848ee@mail.gmail.com> <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> Message-ID: <9189.1217004375@devserv.devel.redhat.com> On 25 July 2008, Matt Domsch wrote: > > Yes, this is a known challenge with subnet delegation in > MirrorManager. We're trusting package signing (and soon, repodata > signing) to prevent rogue mirrors from issuing unsigned data. In > addition, I'm working on adding in a way to prevent stale mirrors > (with signed content) from being used. > How does one get this subnet delegation though? Can I request any subnet I want, or do we do some sort of verification? What happens if the client decided its mirror is bad, I presume it will go off and find a better one, even with delegation? Thanks. -- JB From Matt_Domsch at dell.com Fri Jul 25 17:44:03 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 25 Jul 2008 12:44:03 -0500 Subject: YUM security issues... In-Reply-To: <9189.1217004375@devserv.devel.redhat.com> References: <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> Message-ID: <20080725174402.GN20156@humbolt.us.dell.com> On Fri, Jul 25, 2008 at 12:46:15PM -0400, Josh Bressers wrote: > On 25 July 2008, Matt Domsch wrote: > > > > Yes, this is a known challenge with subnet delegation in > > MirrorManager. We're trusting package signing (and soon, repodata > > signing) to prevent rogue mirrors from issuing unsigned data. In > > addition, I'm working on adding in a way to prevent stale mirrors > > (with signed content) from being used. > > > > How does one get this subnet delegation though? Can I request any subnet I > want, or do we do some sort of verification? At present there is no verification (I'm not at all sure how one _could_ verify except by ARIN & co delegation). However there are limits as to how large a block can be requested. Nothing larger than a IPv4 /16 can be automatically requested. Fedora Infrastructure admins can add larger blocks, and request ARIN & co data when doing so. > What happens if the client decided its mirror is bad, I presume it will go > off and find a better one, even with delegation? Yes, the mirrorlist returned includes quite a few mirrors, in priority order. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From bressers at redhat.com Fri Jul 25 17:52:26 2008 From: bressers at redhat.com (Josh Bressers) Date: Fri, 25 Jul 2008 13:52:26 -0400 Subject: YUM security issues... In-Reply-To: <20080725174402.GN20156@humbolt.us.dell.com> References: <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> Message-ID: <12698.1217008346@devserv.devel.redhat.com> On 25 July 2008, Matt Domsch wrote: > On Fri, Jul 25, 2008 at 12:46:15PM -0400, Josh Bressers wrote: > > On 25 July 2008, Matt Domsch wrote: > > > > > > Yes, this is a known challenge with subnet delegation in > > > MirrorManager. We're trusting package signing (and soon, repodata > > > signing) to prevent rogue mirrors from issuing unsigned data. In > > > addition, I'm working on adding in a way to prevent stale mirrors > > > (with signed content) from being used. > > > > > > > How does one get this subnet delegation though? Can I request any subnet I > > want, or do we do some sort of verification? > > At present there is no verification (I'm not at all sure how one > _could_ verify except by ARIN & co delegation). However there are > limits as to how large a block can be requested. Nothing larger than > a IPv4 /16 can be automatically requested. Fedora Infrastructure > admins can add larger blocks, and request ARIN & co data when doing so. > That's a lot of IPs though. Can I request multiple /16s, or only one? How many mirrors are doing this? Does the mirror have to be part of the /16 to request it? Thanks for the patience here. I'm trying to understand the risk we're dealing with. Thanks. -- JB From rnorwood at redhat.com Fri Jul 25 18:07:41 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 25 Jul 2008 14:07:41 -0400 Subject: Public demo of amber and eventual production instance Message-ID: <20080725140741.190bad5f@solitude.devel.redhat.com> Hi, So sometime next week I'd like to link to the publictest10.fedoraproject.org/amber site and ask for feedback. In the meantime I'm going to install the latest changes on it, and load it up with all the data from F9. Just a heads-up, and a humble request not to break things (like the FAS instance I'm using) too much next week. If anyone has specific plans in that area, ping me and we can work things out. Second, Fedora Applications/Amber is eventually going to need an actual production server ready around the Fedora 10 release date. I'd like to get to the point where I can make a formal request for aforementioned resources. What do I need to do to get there? Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From jsamuel at cs.arizona.edu Fri Jul 25 18:36:12 2008 From: jsamuel at cs.arizona.edu (Justin Samuel) Date: Fri, 25 Jul 2008 11:36:12 -0700 Subject: YUM security issues... In-Reply-To: <20080725174402.GN20156@humbolt.us.dell.com> References: <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> Message-ID: <488A1D1C.8090804@cs.arizona.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Domsch wrote: > On Fri, Jul 25, 2008 at 12:46:15PM -0400, Josh Bressers wrote: >> On 25 July 2008, Matt Domsch wrote: >>> Yes, this is a known challenge with subnet delegation in >>> MirrorManager. We're trusting package signing (and soon, repodata >>> signing) to prevent rogue mirrors from issuing unsigned data. In >>> addition, I'm working on adding in a way to prevent stale mirrors >>> (with signed content) from being used. >>> >> How does one get this subnet delegation though? Can I request any subnet I >> want, or do we do some sort of verification? > > At present there is no verification (I'm not at all sure how one > _could_ verify except by ARIN & co delegation). However there are > limits as to how large a block can be requested. Nothing larger than > a IPv4 /16 can be automatically requested. Fedora Infrastructure > admins can add larger blocks, and request ARIN & co data when doing so. > > >> What happens if the client decided its mirror is bad, I presume it will go >> off and find a better one, even with delegation? > > Yes, the mirrorlist returned includes quite a few mirrors, in priority order. Our testing showed that when our client was in a MirrorManager-defined CIDR block for a mirror, the returned mirrorlist included only the single mirror. -- It's dangerous either way, of course, but I'm just wondering if our testing was faulty, if this has changed since we tested, or if it might be behaving differently than you expect. Possibly you tested with a block that was already defined by other mirrors and so multiple entries were returned in the mirrorist? That's just a guess, we didn't test with a block that was defined by more than one mirror (as far as we knew, at least). - -- Justin Samuel https://www.cs.arizona.edu/~jsamuel/ gpg: 0xDDF1F3EE [66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EE] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIih0cK5arj93x8+4RAklWAKC+Lewfd+pixUvL2MvbdCYxnjHBpQCdHtNd x5BQsM6GqW5zKpJt+RH8Vco= =w9yV -----END PGP SIGNATURE----- From Matt_Domsch at dell.com Fri Jul 25 19:06:16 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 25 Jul 2008 14:06:16 -0500 Subject: YUM security issues... In-Reply-To: <12698.1217008346@devserv.devel.redhat.com> References: <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> Message-ID: <20080725190616.GA2978@auslistsprd01.us.dell.com> On Fri, Jul 25, 2008 at 01:52:26PM -0400, Josh Bressers wrote: > That's a lot of IPs though. Can I request multiple /16s, or only one? As many as you like. And recall, such changes are made using your FAS credentials. > How many mirrors are doing this? 374 total Hosts 185 have at least 1 netblock entry 94 of these are "private" - don't serve the public > Does the mirror have to be part of the /16 to request it? no. Take for example Dell's mirrors. Netblock 143.166/16 is Dell US, but the mirror IPs are located inside the 10/8 private space. > Thanks for the patience here. I'm trying to understand the risk we're > dealing with. I'm happy for the comments and review. Keep it coming! -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at Dell.com Fri Jul 25 18:47:52 2008 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Fri, 25 Jul 2008 13:47:52 -0500 Subject: YUM security issues... In-Reply-To: <488A1D1C.8090804@cs.arizona.edu> References: <12283.1216515059@devserv.devel.redhat.com> <60e301c40807191913i572fea18h77d8a83a68234d39@mail.gmail.com> <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <488A1D1C.8090804@cs.arizona.edu> Message-ID: Fedora 7 definitely behaves differently than Fedora 8 and 9. The behavior I describe began with F8. For F7 and earlier, the yum policy would chose any random mirror from the returned list, so having many mirrors on the list, some of which are unreachable from inside an organization, would be bad. The yum default policy was changed to treat the mirrorlist as a priority list, so MM returns a longer list. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: Justin Samuel [mailto:jsamuel.cs.arizona.edu at gmail.com] On Behalf Of Justin Samuel Sent: Friday, July 25, 2008 1:36 PM To: Domsch, Matt Cc: Josh Bressers; Mike McGrath; fedora-infrastructure-list at redhat.com; Justin Cappos; security at fedoraproject.org Subject: Re: YUM security issues... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Domsch wrote: > On Fri, Jul 25, 2008 at 12:46:15PM -0400, Josh Bressers wrote: >> On 25 July 2008, Matt Domsch wrote: >>> Yes, this is a known challenge with subnet delegation in >>> MirrorManager. We're trusting package signing (and soon, repodata >>> signing) to prevent rogue mirrors from issuing unsigned data. In >>> addition, I'm working on adding in a way to prevent stale mirrors >>> (with signed content) from being used. >>> >> How does one get this subnet delegation though? Can I request any subnet I >> want, or do we do some sort of verification? > > At present there is no verification (I'm not at all sure how one > _could_ verify except by ARIN & co delegation). However there are > limits as to how large a block can be requested. Nothing larger than > a IPv4 /16 can be automatically requested. Fedora Infrastructure > admins can add larger blocks, and request ARIN & co data when doing so. > > >> What happens if the client decided its mirror is bad, I presume it will go >> off and find a better one, even with delegation? > > Yes, the mirrorlist returned includes quite a few mirrors, in priority order. Our testing showed that when our client was in a MirrorManager-defined CIDR block for a mirror, the returned mirrorlist included only the single mirror. -- It's dangerous either way, of course, but I'm just wondering if our testing was faulty, if this has changed since we tested, or if it might be behaving differently than you expect. Possibly you tested with a block that was already defined by other mirrors and so multiple entries were returned in the mirrorist? That's just a guess, we didn't test with a block that was defined by more than one mirror (as far as we knew, at least). - -- Justin Samuel https://www.cs.arizona.edu/~jsamuel/ gpg: 0xDDF1F3EE [66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EE] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIih0cK5arj93x8+4RAklWAKC+Lewfd+pixUvL2MvbdCYxnjHBpQCdHtNd x5BQsM6GqW5zKpJt+RH8Vco= =w9yV -----END PGP SIGNATURE----- From bressers at redhat.com Sat Jul 26 01:11:27 2008 From: bressers at redhat.com (Josh Bressers) Date: Fri, 25 Jul 2008 21:11:27 -0400 Subject: YUM security issues... In-Reply-To: <20080725190616.GA2978@auslistsprd01.us.dell.com> References: <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> Message-ID: <29888.1217034687@devserv.devel.redhat.com> On 25 July 2008, Matt Domsch wrote: > On Fri, Jul 25, 2008 at 01:52:26PM -0400, Josh Bressers wrote: > > That's a lot of IPs though. Can I request multiple /16s, or only one? > > As many as you like. And recall, such changes are made using your FAS > credentials. Are these ever checked? Does say a mail get generated every time someone adds one of these? My fear would be that someone could blanket quite a large IP space without anyone noticing. Granted that would no doubt generate a huge volume of traffic, but if they're serving up a frozen repo, they probably won't be pushing all that much data. > > > How many mirrors are doing this? > > 374 total Hosts > 185 have at least 1 netblock entry > 94 of these are "private" - don't serve the public > wow, that's quite a few. I wasn't expecting numbers this high honestly. > > > Does the mirror have to be part of the /16 to request it? > > no. Take for example Dell's mirrors. Netblock 143.166/16 is Dell US, > but the mirror IPs are located inside the 10/8 private space. > OK, so here is the problem the way I see it, signing the repository won't fix it. I'll try to explain this clearly, Justin can yell at me if I've gotten any of this wrong. So let's say Mallory (the bad guy) decides that he wants to host a malicious mirror and wait for a nasty security flaw. He sets up his mirror and even claims some IP subnets to serve. Bob and Alice are happily installing valid updates from him for some period of time. Since Mallory has claimed to serve a specific subnet, he has a rather impressive view of what Bob and Alice have installed. Now let's say there is a horrible security bug found in a mail server. Mallory knows for a fact that Bob and Alice both have it installed as he's been their mirror for a while. Mallory stops updating his mirror, so none of the users being served will get the mail server updates. Mallory also knows the IP address of the vulnerable clients and can easily break into their systems. So from what I understand MirrorManager will check on the mirrors to ensure they're not out of date. Mallory knows this and makes sure that when MirrorManager connects to his mirror, it lies and serves up current metadata. So here is the problem. The repodata was valid. The packages are signed. Even if we sign the repodata, this attack works. Being able to acquire an IP block simply makes this attack easier to do. It's still very possible that a bad mirror will wait for users to connect, serve up old content then use this knowledge to break into their system. What this problem boils down to, is we need a way for clients to ask MirrorManager what the current valid repo data is. Ideally we want the results to be signed in some manner so it can't be spoofed. Some thoughts I've had are: 1) Have MirrorManager use https and return some repo verification data. 2) Sign the repo data, and if it's older than X, don't use it (I don't like this solution, but it's probably the easiest, just push out a new signed repo file once a day, even if nothing changes.) 3) Always get repo data from fedoraproject.org (probably not practical due to resource issues) 4) use DNS, have the client query .repo.fedoraproject.org if the lookup fails, the repo is invalid. (this is really cheap from a resource standpoint, but hard to do technically) 5) ??? Thanks. -- JB From a.badger at gmail.com Sat Jul 26 01:41:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 25 Jul 2008 18:41:27 -0700 Subject: YUM security issues... In-Reply-To: <29888.1217034687@devserv.devel.redhat.com> References: <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> Message-ID: <488A80C7.8020504@gmail.com> Josh Bressers wrote: > On 25 July 2008, Matt Domsch wrote: >> On Fri, Jul 25, 2008 at 01:52:26PM -0400, Josh Bressers wrote: >>> That's a lot of IPs though. Can I request multiple /16s, or only one? >> As many as you like. And recall, such changes are made using your FAS >> credentials. > > Are these ever checked? Does say a mail get generated every time someone > adds one of these? My fear would be that someone could blanket quite a > large IP space without anyone noticing. Granted that would no doubt > generate a huge volume of traffic, but if they're serving up a frozen repo, > they probably won't be pushing all that much data. > >> >>> How many mirrors are doing this? >> 374 total Hosts >> 185 have at least 1 netblock entry >> 94 of these are "private" - don't serve the public >> > > wow, that's quite a few. I wasn't expecting numbers this high honestly. > >>> Does the mirror have to be part of the /16 to request it? >> no. Take for example Dell's mirrors. Netblock 143.166/16 is Dell US, >> but the mirror IPs are located inside the 10/8 private space. >> > > OK, so here is the problem the way I see it, signing the repository won't > fix it. I'll try to explain this clearly, Justin can yell at me if I've > gotten any of this wrong. > > So let's say Mallory (the bad guy) decides that he wants to host a > malicious mirror and wait for a nasty security flaw. He sets up his mirror > and even claims some IP subnets to serve. Bob and Alice are happily > installing valid updates from him for some period of time. Since Mallory > has claimed to serve a specific subnet, he has a rather impressive view of > what Bob and Alice have installed. > > Now let's say there is a horrible security bug found in a mail server. > Mallory knows for a fact that Bob and Alice both have it installed as he's > been their mirror for a while. Mallory stops updating his mirror, so none > of the users being served will get the mail server updates. Mallory also > knows the IP address of the vulnerable clients and can easily break into > their systems. > > So from what I understand MirrorManager will check on the mirrors to ensure > they're not out of date. Mallory knows this and makes sure that when > MirrorManager connects to his mirror, it lies and serves up current > metadata. > > > So here is the problem. The repodata was valid. The packages are signed. > Even if we sign the repodata, this attack works. Being able to acquire an > IP block simply makes this attack easier to do. It's still very possible > that a bad mirror will wait for users to connect, serve up old content then > use this knowledge to break into their system. > > What this problem boils down to, is we need a way for clients to ask > MirrorManager what the current valid repo data is. Ideally we want the > results to be signed in some manner so it can't be spoofed. > > Some thoughts I've had are: > > 1) Have MirrorManager use https and return some repo verification data. We'd need to push repo verification data for both the latest and previous repo information. MirrorManager would have to be updated with new data as part of the updates/rawhide push so that it's always up to date with the mirror. We'll have to revise mirrormanager's caching model so that it always has access to the latest repository verification information. > 2) Sign the repo data, and if it's older than X, don't use it (I don't like > this solution, but it's probably the easiest, just push out a new > signed repo file once a day, even if nothing changes.) This is going to have to have some policy attached to it. Do we continue to sign the repo data for EOL releases because people use them even though we tell people they're EOL? > 3) Always get repo data from fedoraproject.org (probably not practical due > to resource issues) This is the easiest to implement. It means the small repomd.xml file always comes from our server. But the rest of the metadata can come from the individual mirrors. However, it does mean that *very* large swaths of the mirrors will be unable to serve packages to users at any time because their metadata won't match with ours for some period after we have an update pushed. Maybe we could do this with versioned repodata and the client can decide how far back in time or how many past revisions it is willing to accept. > 4) use DNS, have the client query > .repo.fedoraproject.org > if the lookup fails, the repo is invalid. (this is really cheap from a > resource standpoint, but hard to do technically) I don't know enough about implementing this one to comment. Also, all of these solutions need client-side support. That being the case, it should be generic enough that other repomd consuming clients and distributions will be willing to use it. Otherwise we'll be securing our updates and mirror infrastructure with the default package manager but doing nothing for the ecosystem as a whole. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Sat Jul 26 03:08:19 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jul 2008 23:08:19 -0400 Subject: YUM security issues... In-Reply-To: <488A80C7.8020504@gmail.com> References: <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <488A80C7.8020504@gmail.com> Message-ID: <1217041699.10981.108.camel@rosebud> On Fri, 2008-07-25 at 18:41 -0700, Toshio Kuratomi wrote: > > 3) Always get repo data from fedoraproject.org (probably not practical due > > to resource issues) > This is the easiest to implement. It means the small repomd.xml file > always comes from our server. But the rest of the metadata can come > from the individual mirrors. However, it does mean that *very* large > swaths of the mirrors will be unable to serve packages to users at any > time because their metadata won't match with ours for some period after > we have an update pushed. Maybe we could do this with versioned > repodata and the client can decide how far back in time or how many past > revisions it is willing to accept. We don't need to version the metadata, we have timestamps in them already. We can easily do a comparison from this timestamp to now. And we can set this number to be different from the base repo as to the updates repo. But as you've already mentioned we're stuck with the question of EOL'd releases and how to deal with things deeply out of date. I can make yum throw out warnings and alerts but at what point does it actually STOP doing anything and does that not open us up to a different kind of DoS? > I don't know enough about implementing this one to comment. > > Also, all of these solutions need client-side support. That being the > case, it should be generic enough that other repomd consuming clients > and distributions will be willing to use it. Otherwise we'll be > securing our updates and mirror infrastructure with the default package > manager but doing nothing for the ecosystem as a whole. We need to make sure that whatever we implement is trivially done so by people running a local downstream branch of fedora or centos or what-have-you. Or, as you say, we've saved ourselves and screwed everyone else. -sv From josemanimala at gmail.com Sat Jul 26 11:48:47 2008 From: josemanimala at gmail.com (jose manimala) Date: Sat, 26 Jul 2008 17:18:47 +0530 Subject: Back Message-ID: <53a863600807260448n64f1278do9a887bf17b846b70@mail.gmail.com> Hey, I have been inactive for sometime but I have been closely monitoring and reading up on the wiki and am willing to help with any project that is python related. So please let me know if something need be done. regards Jose M Manimala -------------- next part -------------- An HTML attachment was scrubbed... URL: From bressers at redhat.com Sat Jul 26 17:06:08 2008 From: bressers at redhat.com (Josh Bressers) Date: Sat, 26 Jul 2008 13:06:08 -0400 Subject: YUM security issues... In-Reply-To: <1217041699.10981.108.camel@rosebud> References: <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <488A80C7.8020504@gmail.com> <1217041699.10981.108.camel@rosebud> Message-ID: <7905.1217091968@devserv.devel.redhat.com> On 25 July 2008, seth vidal wrote: > > But as you've already mentioned we're stuck with the question of EOL'd > releases and how to deal with things deeply out of date. > > I can make yum throw out warnings and alerts but at what point does it > actually STOP doing anything and does that not open us up to a different > kind of DoS? > This is of course a policy decision that can be dictated via a configuration file. There is also the issue of what happens when the client keeps getting back "old" data? It need to go find some new data as in our attack scenario, they are running something that needs updating. I would think that the client should try some number of mirrors, if they all return the same old data, it's probably EOL or something similar. If an attacker has enough control over you to prevent you connecting to arbitrary mirrors, you likely have bigger issues than this. > > We need to make sure that whatever we implement is trivially done so by > people running a local downstream branch of fedora or centos or > what-have-you. Or, as you say, we've saved ourselves and screwed > everyone else. > Yes, I'm starting to think we should be having this discussion with yum upstream. Now that I have a grasp of what MirrorManager does, I don't think there's really anything to fix there. We need to fix the client. Seth, which list would you suggest to move this discussion so I can stop pestering the infrastructure folks? Thanks. -- JB From skvidal at fedoraproject.org Sat Jul 26 17:20:39 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 26 Jul 2008 13:20:39 -0400 Subject: YUM security issues... In-Reply-To: <7905.1217091968@devserv.devel.redhat.com> References: <5039.1216653594@devserv.devel.redhat.com> <24312.1216986322@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <488A80C7.8020504@gmail.com> <1217041699.10981.108.camel@rosebud> <7905.1217091968@devserv.devel.redhat.com> Message-ID: <1217092839.10981.120.camel@rosebud> On Sat, 2008-07-26 at 13:06 -0400, Josh Bressers wrote: > This is of course a policy decision that can be dictated via a > configuration file. But our default is what people will use which is what we need to get straight. > There is also the issue of what happens when the > client keeps getting back "old" data? It need to go find some new data as > in our attack scenario, they are running something that needs updating. I > would think that the client should try some number of mirrors, if they all > return the same old data, it's probably EOL or something similar. Except that if they are being given a single netblock mirror then they're sol for finding another mirror. > If an > attacker has enough control over you to prevent you connecting to arbitrary > mirrors, you likely have bigger issues than this. They can keep you from knowing about other mirrors, definitely. > Yes, I'm starting to think we should be having this discussion with yum > upstream. Now that I have a grasp of what MirrorManager does, I don't > think there's really anything to fix there. We need to fix the client. Unless throwing out warnings, errors and generally exploding when the repodata is too old is good enough, I'm not sure how much more yum is going to be able to do to alert the user that they are not getting any updates applied. And we need to make sure to draw packagekit into this discussion b/c they're going to need to honor the warnings, too. If something is not broken but only 'worrisome' what is, from a security standpoint, a good enough warning? We can't seem to rely on users reading logs, or even reading dialog output. At least that's what the gpg-key import discussion around PK seemed to illustrate. > > Seth, which list would you suggest to move this discussion so I can stop > pestering the infrastructure folks? > yum-devel at lists.linux.duke.edu, thanks, -sv From a.badger at gmail.com Sun Jul 27 20:07:24 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 27 Jul 2008 13:07:24 -0700 Subject: Email aliases and new cvs requests Message-ID: <488CD57C.7020007@gmail.com> Hi guys, Last week Seth implemented email aliases for the people who should be notified of changes to packages. I used this new functionality to have getnotifylist, which looks up who to notify on cvs commits, stop querying the pkgdb directly (a slow operation with multiple points where it could fail) and instead just construct the alias from the packagename. This works well except for one case: When a new package is created, the alias for the package does not yet exist. This means that when someone makes the initial branch for a package they get a bounce message because we were unable to send to the non-existent email address. I think the solution is going to have to be that the pkgdb has to do the branching. Or, at least, the pkgdb is going to need to know which packages need branching and cvs-int will have to query for those with a cron job and perform the action. That way the new package can be added to the pkgdb along with a branch request. The packagedb will record the new package and add the need for cvs branches to a queue. The packagedb will take the branch request through various stages until it is done. Here's my idea for stages: 1) Request for new package with new branch is added to the packagedb. 2) Request is marked approved by an admin 3) Packagedb create the record for the package 4) Packagedb waits for the email alias to be created (currently, the packagedb doesn't know for sure that the alias has been created... we'll just wait an appropriate length of time. If this proves problematic we can create a URL that records that aliases has been created that is only authorized to certain users.) 5) Packagedb records that the package is ready to be branched. 6) cvs-int has a cron job that queries for packages to branch, branches them, and then records that they have been created. If anyone can think of a better way to solve this, please let me know. I'll start work on this about the middle of next week. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From laxathom at fedoraproject.org Sun Jul 27 20:53:23 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sun, 27 Jul 2008 22:53:23 +0200 Subject: Email aliases and new cvs requests In-Reply-To: <488CD57C.7020007@gmail.com> References: <488CD57C.7020007@gmail.com> Message-ID: <62bc09df0807271353o1baf4e32u2aaa0b89704e1c21@mail.gmail.com> 2008/7/27 Toshio Kuratomi > Hi guys, > > Last week Seth implemented email aliases for the people who should be > notified of changes to packages. I used this new functionality to have > getnotifylist, which looks up who to notify on cvs commits, stop querying > the pkgdb directly (a slow operation with multiple points where it could > fail) and instead just construct the alias from the packagename. > > This works well except for one case: When a new package is created, the > alias for the package does not yet exist. This means that when someone > makes the initial branch for a package they get a bounce message because we > were unable to send to the non-existent email address. > > I think the solution is going to have to be that the pkgdb has to do the > branching. Or, at least, the pkgdb is going to need to know which packages > need branching and cvs-int will have to query for those with a cron job and > perform the action. That way the new package can be added to the pkgdb > along with a branch request. The packagedb will record the new package and > add the need for cvs branches to a queue. The packagedb will take the > branch request through various stages until it is done. > > Here's my idea for stages: > > 1) Request for new package with new branch is added to the packagedb. + email is sent to the related mailling list to notify that. > > 2) Request is marked approved by an admin > 3) Packagedb create the record for the package > 4) Packagedb waits for the email alias to be created (currently, the > packagedb doesn't know for sure that the alias has been created... we'll > just wait an appropriate length of time. If this proves problematic we can > create a URL that records that aliases has been created that is only > authorized to certain users.) > 5) Packagedb records that the package is ready to be branched. > 6) cvs-int has a cron job that queries for packages to branch, branches > them, and then records that they have been created. Sound a nice plan/procedure. By the way, Why don't make Packagedb able to run cvs-int with related arguments ? (this will avoid to have cvs-int check when there are no packages to branch) > > If anyone can think of a better way to solve this, please let me know. I'll > start work on this about the middle of next week. > > I'm really interesting by this task. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sun Jul 27 21:10:44 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 27 Jul 2008 14:10:44 -0700 Subject: Email aliases and new cvs requests In-Reply-To: <62bc09df0807271353o1baf4e32u2aaa0b89704e1c21@mail.gmail.com> References: <488CD57C.7020007@gmail.com> <62bc09df0807271353o1baf4e32u2aaa0b89704e1c21@mail.gmail.com> Message-ID: <488CE454.4040604@gmail.com> Xavier Lamien wrote: > Here's my idea for stages: > > 1) Request for new package with new branch is added to the packagedb. > > > + email is sent to the related mailling list to notify that. > Right now only cvsadmins can branch packages so we can send them mail so they can process the queue. > > 2) Request is marked approved by an admin > 3) Packagedb create the record for the package > 4) Packagedb waits for the email alias to be created (currently, the > packagedb doesn't know for sure that the alias has been created... > we'll just wait an appropriate length of time. If this proves > problematic we can create a URL that records that aliases has been > created that is only authorized to certain users.) > 5) Packagedb records that the package is ready to be branched. > 6) cvs-int has a cron job that queries for packages to branch, > branches them, and then records that they have been created. > > > Sound a nice plan/procedure. > By the way, Why don't make Packagedb able to run cvs-int with related > arguments ? > (this will avoid to have cvs-int check when there are no packages to branch) > Security. It's easier for us to audit cron jobs that are on the local machine than it is for us to check what commands are being sent from the packagedb over the network to cvs-int. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From laxathom at fedoraproject.org Sun Jul 27 21:29:26 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sun, 27 Jul 2008 23:29:26 +0200 Subject: Email aliases and new cvs requests In-Reply-To: <488CE454.4040604@gmail.com> References: <488CD57C.7020007@gmail.com> <62bc09df0807271353o1baf4e32u2aaa0b89704e1c21@mail.gmail.com> <488CE454.4040604@gmail.com> Message-ID: <62bc09df0807271429i3ec1b833w727df1581ba2f694@mail.gmail.com> 2008/7/27 Toshio Kuratomi > Xavier Lamien wrote: > > Here's my idea for stages: >> >> 1) Request for new package with new branch is added to the packagedb. >> >> + email is sent to the related mailling list to notify that. >> >> Right now only cvsadmins can branch packages so we can send them > mail so they can process the queue. > it's what i'm talking about, send mail to cvsadmin, i thought they had a mailling list for that. > > >> 2) Request is marked approved by an admin >> 3) Packagedb create the record for the package >> 4) Packagedb waits for the email alias to be created (currently, the >> packagedb doesn't know for sure that the alias has been created... >> we'll just wait an appropriate length of time. If this proves >> problematic we can create a URL that records that aliases has been >> created that is only authorized to certain users.) >> 5) Packagedb records that the package is ready to be branched. >> 6) cvs-int has a cron job that queries for packages to branch, >> branches them, and then records that they have been created. >> >> >> Sound a nice plan/procedure. >> By the way, Why don't make Packagedb able to run cvs-int with related >> arguments ? >> (this will avoid to have cvs-int check when there are no packages to >> branch) >> >> Security. It's easier for us to audit cron jobs that are on the local > machine than it is for us to check what commands are being sent from the > packagedb over the network to cvs-int. > > > -Toshio > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Mon Jul 28 01:39:14 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 27 Jul 2008 20:39:14 -0500 (CDT) Subject: Email aliases and new cvs requests In-Reply-To: <488CD57C.7020007@gmail.com> References: <488CD57C.7020007@gmail.com> Message-ID: On Sun, 27 Jul 2008, Toshio Kuratomi wrote: > Hi guys, > > Last week Seth implemented email aliases for the people who should be notified > of changes to packages. I used this new functionality to have getnotifylist, > which looks up who to notify on cvs commits, stop querying the pkgdb directly > (a slow operation with multiple points where it could fail) and instead just > construct the alias from the packagename. > > This works well except for one case: When a new package is created, the > alias for the package does not yet exist. This means that when someone makes > the initial branch for a package they get a bounce message because we were > unable to send to the non-existent email address. > > I think the solution is going to have to be that the pkgdb has to do the > branching. Or, at least, the pkgdb is going to need to know which packages > need branching and cvs-int will have to query for those with a cron job and > perform the action. That way the new package can be added to the pkgdb along > with a branch request. The packagedb will record the new package and add the > need for cvs branches to a queue. The packagedb will take the branch request > through various stages until it is done. > > Here's my idea for stages: > > 1) Request for new package with new branch is added to the packagedb. > 2) Request is marked approved by an admin > 3) Packagedb create the record for the package > 4) Packagedb waits for the email alias to be created (currently, the packagedb > doesn't know for sure that the alias has been created... we'll just wait an > appropriate length of time. If this proves problematic we can create a URL > that records that aliases has been created that is only authorized to certain > users.) > 5) Packagedb records that the package is ready to be branched. > 6) cvs-int has a cron job that queries for packages to branch, branches them, > and then records that they have been created. > > If anyone can think of a better way to solve this, please let me know. I'll > start work on this about the middle of next week. > "Seth implemented email aliases" What was the criteria for each alias? Is there any way to just use the criteria to initially select who should be on the other end of the alias and email them directly for package creation and then use the alias after its been created? -Mike From skvidal at fedoraproject.org Mon Jul 28 01:40:51 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 27 Jul 2008 21:40:51 -0400 Subject: Email aliases and new cvs requests In-Reply-To: References: <488CD57C.7020007@gmail.com> Message-ID: <1217209251.4468.11.camel@rosebud> On Sun, 2008-07-27 at 20:39 -0500, Mike McGrath wrote: > "Seth implemented email aliases" What was the criteria for each alias? toshio setup a path from the pkgdb to pull the notify list + commit list, iirc from each pkg and that's what I used to generate the alias list. It's all checked into fedora infrastructure's git tree. -sv From a.badger at gmail.com Mon Jul 28 04:31:26 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 27 Jul 2008 21:31:26 -0700 Subject: Email aliases and new cvs requests In-Reply-To: References: <488CD57C.7020007@gmail.com> Message-ID: <488D4B9E.20605@gmail.com> Mike McGrath wrote: > On Sun, 27 Jul 2008, Toshio Kuratomi wrote: > >> Hi guys, >> >> Last week Seth implemented email aliases for the people who should be notified >> of changes to packages. I used this new functionality to have getnotifylist, >> which looks up who to notify on cvs commits, stop querying the pkgdb directly >> (a slow operation with multiple points where it could fail) and instead just >> construct the alias from the packagename. >> >> This works well except for one case: When a new package is created, the >> alias for the package does not yet exist. This means that when someone makes >> the initial branch for a package they get a bounce message because we were >> unable to send to the non-existent email address. >> >> I think the solution is going to have to be that the pkgdb has to do the >> branching. Or, at least, the pkgdb is going to need to know which packages >> need branching and cvs-int will have to query for those with a cron job and >> perform the action. That way the new package can be added to the pkgdb along >> with a branch request. The packagedb will record the new package and add the >> need for cvs branches to a queue. The packagedb will take the branch request >> through various stages until it is done. >> >> Here's my idea for stages: >> >> 1) Request for new package with new branch is added to the packagedb. >> 2) Request is marked approved by an admin >> 3) Packagedb create the record for the package >> 4) Packagedb waits for the email alias to be created (currently, the packagedb >> doesn't know for sure that the alias has been created... we'll just wait an >> appropriate length of time. If this proves problematic we can create a URL >> that records that aliases has been created that is only authorized to certain >> users.) >> 5) Packagedb records that the package is ready to be branched. >> 6) cvs-int has a cron job that queries for packages to branch, branches them, >> and then records that they have been created. >> >> If anyone can think of a better way to solve this, please let me know. I'll >> start work on this about the middle of next week. >> > > > "Seth implemented email aliases" What was the criteria for each alias? > > Is there any way to just use the criteria to initially select who should > be on the other end of the alias and email them directly for package > creation and then use the alias after its been created? > We can fallback to getting this information directly from the packagedb. But only if we can figure out one of the following:: * If the cvs hook that returns the email address can detect that the alias does not exist. * If the cvs hook that sends out email can tell that this is the initial branching of a package. I wasn't able to think of a way to do either of these. If you can, then we could definitely do this as a quick fix. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Mon Jul 28 16:04:01 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 28 Jul 2008 11:04:01 -0500 (CDT) Subject: Fedora Weekly News Issue 136 (fwd) Message-ID: What happened to our beat guy? Anyone else want to volunteer? -Mike ---------- Forwarded message ---------- Date: Mon, 28 Jul 2008 10:17:10 -0400 From: Pascal Calarco Reply-To: fedora-list at redhat.com To: fedora-announce-list at redhat.com Subject: Fedora Weekly News Issue 136 === Fedora Weekly News Issue 136 Welcome to Fedora Weekly News Issue 136 for the week ending July 26, 2008. http://fedoraproject.org/wiki/FWN/Issue136 Fedora Weekly News keep you updated with the latest issues, events and activities in the fedora community. If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news, and can be done in only about 1 hour per week of your time. We are still looking for a beat writer to summarize the Fedora Events and Meetings that happened during each week. http://fedoraproject.org/wiki/NewsProject/Join * 1 Fedora Weekly News Issue 136 o 1.1 Announcements + 1.1.1 FESCo Election Results + 1.1.2 Cast your vote for the Fedora 10 Codename! + 1.1.3 Fedora 10 Alpha Freeze + 1.1.4 Announcing the Fedora OLPC Special Interest Group + 1.1.5 Fedora Unity releases updated Fedora 9 Re-Spin + 1.1.6 Feature Process Improvements + 1.1.7 FUEL opens up collaborative standardization of localization terms o 1.2 Planet Fedora + 1.2.1 Shameless Recruiting Pitch + 1.2.2 Intel's Moblin moves to Fedora + 1.2.3 Events + 1.2.4 Tech Tidbits + 1.2.5 Other Interesting Posts o 1.3 Marketing + 1.3.1 Linus Torvalds' personal Linux distro? Fedora 9, of course + 1.3.2 Asus Eee PC Fedora Respin + 1.3.3 Zimbra changes license to address Fedora concerns + 1.3.4 Seneca College teams with FOSS projects for hands-on learning + 1.3.5 Intel's Moblin switches from Ubuntu in favor of Fedora + 1.3.6 Fedora launches OLPC group + 1.3.7 Ring. Ring. It's Fedora calling + 1.3.8 Linux Symposium Proceedings Available + 1.3.9 Video: Fedora Live o 1.4 Ambassadors + 1.4.1 FAD EMEA 2008 - Date & Location Determined + 1.4.2 Planning for Fedora 10 Release Parties + 1.4.3 Event Reports Reminder o 1.5 Developments + 1.5.1 Erratum: FWN#133 "Shark" is a JIT not a VM + 1.5.3 XULRunner Security Update Breakage Stimulates Bodhi Discussion + 1.5.4 Broken Upgrade Paths Due to NEVR + 1.5.5 Application Installer "Amber" Provides Browser Interface to Packages + 1.5.6 RPM Inspires Intel Moblin2 Shift From Ubuntu o 1.6 Artwork + 1.6.1 Nodoka development + 1.6.2 Gathering feed-back about Fedora 10 theme proposals + 1.6.3 A possible Bluecurve revival o 1.7 Security Advisories + 1.7.1 Fedora 9 Security Advisories + 1.7.2 Fedora 8 Security Advisories === Announcements In this section, we cover announcements from the Fedora Project. https://www.redhat.com/mailman/listinfo/fedora-announce-list https://www.redhat.com/mailman/listinfo/fedora-devel-announce Contributing Writer: Max Spevack === FESCo Election Results Brian Pepple announced the results of the Fedora Engineering Steering Committee election[1]: "The results of the Fedora Engineering Steering Committee (FESCo) election are in: Bill Nottingham, Kevin Fenzi, Dennis Gilmore, Brian Pepple, and David Woodhouse have been elected to full two-release terms, and Jarod Wilson, Josh Boyer, Jon Stanley and Karsten Hopp have been elected to a one-release term." [1] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00010.html === Cast your vote for the Fedora 10 Codename! Josh Boyer reminded folks to vote[1]: "As long as you have signed the CLA and belong to one additional group in the Fedora Account System, you can cast your vote. Voting will end and be tallied at 23:59:59 28 July 2008 UTC." [1] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00011.html === Fedora 10 Alpha Freeze Jesse Keating announced[1]: "We have our first development freeze of the Fedora 10 cycle tomorrow. This is the alpha freeze, which is non-blocking. Release Engineering will be making a freeze inside the buildsystem of tomorrow's rawhide content. This will be the basis of the Fedora 10 Alpha release." [1] https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00008.html === Announcing the Fedora OLPC Special Interest Group Greg DeKoenigsberg announced[1]: "Thus, I am proud to announce the formation of the Fedora OLPC Special Interest Group. Our mission: to provide the OLPC project with a strong, sustainable, scalable, community-driven base platform for innovation. Immediate Goals: 1. To identify and take responsible ownership of as many OLPC base packages as possible. 2. To maintain an excellent Sugar environment for Fedora, including a dedicated Sugar spin. 3. To identify useful opportunities for collaboration (infrastructure, localization, etc.)" [1] http://www.redhat.com/archives/fedora-announce-list/2008-July/msg00009.html === Fedora Unity releases updated Fedora 9 Re-Spin Jeroen van Meeuwen informed us[1]: "The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD) of Fedora 9. These Re-Spin ISOs are based on the officially released Fedora 9 installation media and include all updates released as of July 18th, 2008. The ISO images are available for i386 and x86_64 architectures via Jigdo starting Sunday, July 20th, 2008." [1] http://www.redhat.com/archives/fedora-announce-list/2008-July/msg00007.html === Feature Process Improvements John Poelstra had some excellent news on the feature front[1]: "I was recently talking with Paul Frields about how to make the feature process more accessible... this combined with feedback in the rpm thread have led to a (hopefully) clearer presentation of how the feature process works." [1] http://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00009.html === FUEL opens up collaborative standardization of localization terms FUEL (Frequently Used Entries for Localization) aims at solving the problem of inconsistency and lack of standardization in computer software translation across the platform for all Languages. It will try to provide a standardized and consistent look of computer for a language computer users. https://fedorahosted.org/fuel === Planet Fedora In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide. http://planet.fedoraproject.org Contributing Writer: Max Spevack === Shameless Recruiting Pitch We begin this week's summary of Planet Fedora with a recruitment pitch for Fedora Weekly News beat writers, scribed by Karsten Wade. === Intel's Moblin moves to Fedora The topic that took Planet Fedora by storm on Friday and Saturday was the announcement of Intel's Moblin moving from Ubuntu to Fedora as its base OS. Yaakov Nemoy, John Palmieri, Seth Vidal, and Karsten Wade all weighed in with their thoughts. === Events A number of event reports were posted on Planet Fedora this week. * LUG Radio Live UK, attended by Max Spevack. * Ottawa Linux Symposium (day 1), as reported by Dennis Gilmore. * LTSP Hackfest (day 1), which included hackers from numerous Linux distros, and Fedora's own Warren Togami. * A GUADEC trip report (including pictures) from Dimitris Glezos. * A second place finish in the 2008 RoboCup World Championships, with a report from Tim Niemueller. In other event news: * Sandro "red" Mathys has posted details about the upcoming Fedora Ambassador Day EMEA. * James Morris shared his Ottawa Linux Symposium paper with us, which is a detailed update on SELinux. === Tech Tidbits Transifex 0.3 has been released. "Transifex 0.3 is a major release, including a lot of under-the-hood changes. We?ve added full i18n support, and now in addition to the templates, per-module information stored in the database, such as names and descriptions, can be translated as well," explains project lead Dimitris Glezos. Lorenzo Villani is working on adding the ZYpp stack into Fedora. He explains, "It seems that with the latest releases of sat-solver, libzypp and zypper, the whole stack has become more stable on Fedora, especially, in the past few weeks I wasn?t able to update packages due to various resolver?s problems, but now it seems that 'zypper up' does its job smoothly." Fedora Electronics Lab now has its own mailing list, and there has been lots of discussion about this particular respin on Planet Fedora over the past few days. Red Hat Magazine has a great article about NetworkManager, written by Kyle Gonzales. === Other Interesting Posts Nicu Buculei gave us a detailed look at the first round of themes that have been developed by the Art Team for Fedora 10. David Nalley authored what might be the first in a four part series about Fedora's new "Freedom, Friends, Features, First" marketing focus. This post focuses on the Freedom topic. === Marketing In this section, we cover the Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: Pascal Calarco === Linus Torvalds' personal Linux distro? Fedora 9, of course Larry Cafiero reported[1] that the creator of Linux, Linus Torvalds, currently uses Fedora 9 "on most of his computers" as reported in a recent interview[2]. "I've used different distributions over the years ... Fedora had fairly good support for PowerPC back when I used that, so I grew used to it. But I actually don't care too much about the distribution, as long as it makes it easy to install and keep reasonably up-to-date," Torvalds added. [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00150.html [2] http://www.simple-talk.com/opinion/geek-of-the-week/linus-torvalds,-geek-of-the-week/ === Asus Eee PC Fedora Respin Valent Turkovic asked[1] if there was interest in working on a Fedora spin for the Eee PC. Clint Savage reported[2] that his kickstart for the Eee is working almost perfectly, and Mathieu Bridon pointed[3] to the [EeePc wiki page] for this activity. [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00156.html [2] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00164.html [3] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00160.html === Zimbra changes license to address Fedora concerns Rahul Sundaram reported[1] that Yahoo has responded[2] to the suggestion that the license language for Zimbra be modified to allow it to be consonant with the Fedora project, which now paves the way for Zimbra to be made available in Fedora. "Our colleagues in the Fedora community were concerned that the old version of 6.2 did not give licensees enough certainty that they could keep exercising their license, even if they followed its requirements. We thought this change was a reasonable request, and we were very pleased that we were able to respond to the Fedora community in the way they asked. Many thanks to our Fedora friends for their input," the Yahoo spokesman explained. Jeroen Van Meeuwen added[3] that efforts are already underway to package Zimbra for Fedora. [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00147.html [2] http://www.zimbra.com/forums/announcements/19581-license-5-0-7-foss.html [3] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00172.html === Seneca College teams with FOSS projects for hands-on learning Rahul Sundaram shared[1] a feature[2] from Linux.com detailing the growth of the free and open source software program at Seneca College in Toronto, Canada. Beginning this fall, thanks to Fedora, it will add the graduate-level Linux/Unix System Administration program. The article continues with Greg DeKoenigsberg, Fedora's liaison with Seneca, saying, "There's a lot of knowledge that's just not taught that you need [in order] to participate in an open source project. There's a difference in how open source is approached [compared to] traditional software, and it's not like you can learn it in a book. It's very much an apprenticeship model." [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00176.html [2] http://www.linux.com/feature/140097 === Intel's Moblin switches from Ubuntu in favor of Fedora Rahul Sundaram shared[1] news reported in the UK's Register that Intel has shifted from use of Ubuntu to Fedora. "Under the changes, the existing Ubuntu-based kernel is out and Fedora is in, along with a set of Gnome-compatible mobile components that updates Moblin's previous Gnome implementation." Intel's director of Linux and open-source strategy explained that "there was no falling out with Ubuntu, but the move to Fedora was a technical decision based on the desire to adopt RPM for package management." Rahul followed up with more information on this development[3], reported later in heise open source[4]. [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00185.html [2] http://www.theregister.co.uk/2008/07/23/moblin_reworked/ [3] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00205.html [4] http://www.heise-online.co.uk/open/Intel-switches-from-Ubuntu-to-Fedora-for-Mobile-Linux--/news/111166 === Fedora launches OLPC group Rahul Sundaram forwarded[1] news[2] that the Fedora Project has started a Open Laptop per Child[3] Special Interest Group to help with the educational computing effort. Fedora will offer increased help with package maintenance for OLPC, "maintain an excellent Sugar environment for Fedora, including a dedicated Sugar spin; to identify opportunities for collaboration on things such as infrastructure and localisation." A discussion list has also been established[4] for this, and all are welcome to join these efforts. [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00186.html [2] http://www.tectonic.co.za/?p=2647 [3] http://www.laptop.org/ [4] https://www.redhat.com/mailman/listinfo/fedora-olpc-list === Ring. Ring. It's Fedora calling Rahul Sundaram shared[1] a story in CNET News[2] this week about Fedora Talk[3], a VOIP project that "allows Fedora contributors to use any standard VoIP hardware or software to sign into the Fedora system and make and receive calls to other Fedora contributors." CNET added, "It's an intriguing way for the Fedora community to tighten the development process by bringing developers together. IM, mailing lists, and e-mail are great, but talking with someone is sometimes the best way to make things happen." [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00207.html [2] http://news.cnet.com/8301-13505_3-9998526-16.html [3] http://talk.fedoraproject.org/ === Linux Symposium Proceedings Available Rahul Sundaram posted[1] that the 2001-2008 proceedings of the Linux Symposium[3] were now freely-available[4], along with the GCC Summit Proceedings. [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00210.html [2] http://ols.fedoraproject.org [3] http://www.linuxsymposium.org/ [4] http://ols.fedoraproject.org/ === Video: Fedora Live Rahul Sundaram shared[1] a recent article in Red Hat Magazine[2] featuring the Fedora Project's Paul Frields talking with developer Jeremy Katz "to discuss the Live USB feature debuted in Fedora 9 ... See a live demo of the persistent desktop, and find out how to get more involved in the next Fedora release." [1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00188.html [2] http://www.redhatmagazine.com/2008/07/23/video-fedora-live/ === Ambassadors In this section, we cover Fedora Ambassadors Project. http://fedoraproject.org/wiki/Ambassadors Contributing Writer: Jeffrey Tadlock === FAD EMEA 2008 - Date & Location Determined Sandro Mathys announced[1] that the data and location for FAD EMEA 2008 have been determined. It will take place in Basel, Switzerland from 2008-11-14 to 2008-11-16. Additional information is available on the FAD EMEA 2008 wiki page[2]. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00304.html [2] https://fedoraproject.org/wiki/FAD/FADEMEA2008 === Planning for Fedora 10 Release Parties Francesco Ugolini posted[1] to the ambassadors list a request for feedback for planning for Fedora 10 release parties. We had great success with out Fedora 9 release parties - be sure to get your suggestions in for planning Fedora 10 release parties in the future. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00328.html === Event Reports Reminder Max Spevack posted[1] a reminder that event reports are required if you were the leader of an event. Event reports are also encouraged from attendees of events as well. The event reporting guidelines page[2] covers what should be included in an event report. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00326.html [2] https://fedoraproject.org/wiki/FedoraEvents/ReportingGuidelines === Developments In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley === Erratum: FWN#133 "Shark" is a JIT not a VM Gary Benson kindly corrected an error in FWN#133 "Java, So Many Free Choices"[1] which reported on the work being done by Red Hat engineers to expand the availability of a FOSS Java across more architectures. The gist of the correction is that Shark is not a Virtual Machine(VM) as stated in the article. Gary explained that OpenJDK is composed of a VM named HotSpot and a class library. HotSpot runs on a limited number of architectures and so there have been two independent attempts to increase VM coverage. One of these is pre-existing project named CACAO which is a VM whose maintainers are implementing the OpenJDK class interface. The other is a Red Hat initiative, named zero, to remove architecture-specific code from HotSpot in order to make compilation on diverse platforms easier. As zero is slow and in need of a JIT. This JIT could well end up being Shark. Thanks to Gary for taking the time to clarify this point. We encourage readers to correct important technical issues and misunderstandings and can be contacted via "news at fedoraproject.org". [1] http://fedoraproject.org/wiki/FWN/Issue133#Java.2C_So_Many_Free_Choices === New libraw1394 Rebuild Exposes Closed ACLs A simple warning made[1] by Jarod Wilson of a soname bump of libraw1394 (which among other things allows easy switching between juju and the older drivers) revealed that Fedora's KDE maintainers are not using open ACLs for their packages. The issue of whether open ACLs should be used to allow any interested community member (e.g. with a FAS account) to start making changes without bureaucracy has been visited several times on @fedora-devel and has been argued[1a] to be one of the exciting "post-merge" aspects of the FedoraProject. Objections have included those based on security (see FWN#112 "Open By Default: New FAS Groups Proposed"[1b]) and the logistics of co-ordinating such open access (see FWN#91 "Community Control And Documentation Of New Workflows"[1c]). At times it has appeared that those who were non-Red Hat employees and contributing to the pre-merge "Extras" repository were the strongest advocates for open ACLs. [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01159.html [1a] http://lwn.net/Articles/237700/ [1b] http://fedoraproject.org/wiki/FWN/Issue112#Open_By_Default:_New_FAS_Groups_Proposed [1c] http://fedoraproject.org/wiki/FWN/Issue91#Community_Control_And_Documentation_Of_New_Workflows Jarod provided a short list of affected packages including kdebase and kdebase3 and wondered whether he should "do a fancy chainbuild[2], or just let rawhide be busted for a day?" Following advice received[3] offlist he decided that the procedure would be to first bump and tag each of the packages, and then from within the devel-branch of a dependent package issue a: [jwilson foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10" [2] http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained.builds [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01161.html This eventually worked[4], but first Jarod had to contact maintainers that disallowed commit access using open ACLs and get them to do the bump and tag in order to use the above method. [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01316.html Early on in the chain of events Kevin Koffler noted[5] the necessity to do this for the KDE packages. "Drago01" wondered why there were closed ACLs to which Rex Dieter replied[6] that it was not necessary for non-core development platform bits and he would try to change the ACLs for them. Konrad Meyer defended[7] the choice on the basis that "KDE is a major system component and the KDE team (which is something like 6-8 people) does a very good job of fixing things as soon as they need fixing." Further probing for an actual reason by Rahul Sundaram resulted in Konrad stating[8] that it was necessary to prevent people from making mistakes and that the kernel package was handled similarly. Rahul was unconvinced by this and Jon Stanley agreed[9] it should be possible, as with GNOME, to use open ACLs to allow anyone to help. [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01164.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01192.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01181.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01223.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01225.html === XULRunner Security Update Breakage Stimulates Bodhi Discussion After Michael Schwendt published[1] a summary of broken dependencies for Fedora 9 it was noticed[2] by Martin Sourada that most of the problems were due to a recent update of xulrunner which now provides gecko-libs (see FWN#110[3].) Martin discovered that gxine, which was his particular responsibility, did not depend on a specific version of gecko-libs and thus removed the versioned dependencies. He suggested that a review by carried out of the other affected packages to determine whether this was also the case for them. [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01175.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01177.html [3] http://fedoraproject.org/wiki/FWN/Issue110#Gecko-libs.Now.Provided.By.Xulrunnerdevel Martin was further concerned that the policies for pushing security updates for a stable release be examined in the light of this particular case because it would fail to install due to all the broken dependencies. He suggested that it ought to be possible to use chain builds (the Koji buildsystem allows packages to be grouped into sets during the build process and to only report success if all the packages complete perfectly) to ensure that such breakage does not occur. He also wondered why the security update was not mentioned on the "-devel(-announce) list?" Nicolas Mailhot agreed[4] strongly wondering: "why the hell is this stuff not tested in -devel first? [...] When the update process is not streamlined in -devel, it's no surprise it bombs in -stable when security updates are due." The answers to these questions came from Adel Gadllah (drago01) who replied[5] that as it was a security fix it had to go to updates-stable immediately instead of following the normal procedure[6]. David Nielsen interjected[7] that this method did not deliver a quick security fix because those using, for example, epiphany failed to get the update because the dependencies had not been properly handled. Michael Schwendt also made[8] the same point: "Doesn't matter. It doesn't install at all if it breaks dependencies of *installed* packages. Not even *skip-broken helps in that case." Adel clarified[9] that he was explaining "why it was done, not that it was the right thing to do. As I already said, bodhi should block updates that break deps." [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01182.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01183.html [6] Generally bleeding-edge changes for the next version of Fedora are published in the "fedora-rawhide" repository, which is derived from a CVS branch named "-devel". The "fedora-updatestesting" repository contains bleeding edge changes for the current maintained release, the idea being that volunteers will test them and provide feedback before they are pushed to the "fedora-updates" repository for general consumption. [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01184.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01185.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01188.html === Broken Upgrade Paths Due to NEVR A report listing packages which failed to upgrade smoothly was emailed[1] to the list on Mon 21st. This would appear[2] to be the output of Jesse Keating's revamped version of the old Extras script upgradecheck (previously discussed in FWN#108 "Package EVR Problems"[3]) which examines Koji tags[4] to determine whether upgrades from one package version to another will work. [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01253.html [2] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgradepaths.py;hb=HEAD [3] http://fedoraproject.org/wiki/FWN/Issue108#Package.EVR.Problems [4] http://fedoraproject.org/wiki/Koji Michael Schwendt noticed[5] that at least one reported failure, of audacity to upgrade from "dist-f8-updates-testing" to "dist-f9-updates" was a false positive because it omitted to take the possible intermediate tag "dist-f9-updates-testing" into account. Jesse Keating pondered[6] the idea and while admitting the possibility that someone might "at one time [have] installed F8 testing updates, and then upgraded to F9 + updates, but without F9 updates-testing. However, it's more plausible that if they were using updates-testing on F8 that they would upgrade to F9 + updates + updates-testing." He suggested that he would break the testing down into two separate paths: "F8, F8-updates, f9-updates" and "F8-updates-testing, F9-updates-testing" and also list the person that built the broken instance instead of listing the owners of the broken packages. [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01296.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01317.html As the owner can change per branch Michael Schwendt suggested that the pkgdb could be queried for branch-specific ownership data, but Jesse thought that it was more interesting to know who built the package rather than who owned it. He hoped that "the -contact fedoraproject org or some such gets created soon so that the script can just email that + the person whom built the problematic package" and Seth Vidal quickly implemented[7] this after Toshio Kuratomi made some changes to pkgdb. [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01489.html === Application Installer "Amber" Provides Browser Interface to Packages A description was posted[1] by Owen Taylor of a visual means to rate, browse and install packaged applications in a repository. The discussion around this revealed some differences over the advisability of providing separate ways for ordinary end-users on the one hand and package maintainers on the other to discover and discuss the software available from the FedoraProject. Owen's post was to announce that he had hacked up a web-browser plugin (a detailed README is available[2] which includes discussion of security and cross-browser support) which used PackageKit to allow the installation of packages selected from this website. He had hopes that this would be "robust against inter-distro differences in package names" and wondered "[w]hat do people think... does this make sense as part of the PackageKit project?" [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01433.html [2] http://git.o/shsoup.net/cgit/packagekit-plugin/tree/README Following a suggestion from Tom Callaway that it be integrated with PackageDB (this is the central repository of meta-information on packages and is currently targeted to the needs of package maintainers and release-engineering[3] to track ownership and ACLs[4]) there were questions from Jeff Spaleta about what that meant. Owen replied[5] with more detail, and explained that the web application would take information from PackageDB but that the plugin would use PackageKit (and YUM and hence comps.xml) to display actual installable packages. He listed other possible operations beyond simple installation of packages. It would be possible to offer installation to any anonymous user, but after authentication rating and commenting on packages could be authorized for users in the FAS[6] class. Similarly, the ability to edit package information could be authorized for package owners. [3] https://admin.fedoraproject.org/pkgdb [4] https://fedorahosted.org/packagedb/ [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01440.html [6] https://admin.fedoraproject.org/accounts/ Jeff emphasized[7] that he would prefer to see Owen's interface replace, or augment, the existing PackageDB one[8] in order to increase user-maintainer communication by simplifying and reducing the number of interfaces. Bill Nottingham wondered[9] "Does anyone actually use packagedb to browse for available software?" and although there were a couple of affirmative replies there was no aggregate data presented to answer this question. Nicolas Mailhot replied[10] with some possible uses for expanded meta-information based upon the experience of the Fonts SIG. [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01442.html [8] https://admin.fedoraproject.org/pkgdb [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01445.html [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01474.html Robin Norwood explained[11] to Jeff that the PackageDB was for one audience "(mostly) targeted at people interested in the plumbing of Fedora" while the new interface was "targeted at people who are looking for applications to install and 'do stuff' with." He posted[12] a link to the Feature page for this ApplicationInstaller. Work seems to have progressed quite far with both the web-application side, which is tentatively named "Amber" and is available for proof-of-concept testing[13] and also with Owen's plugin. [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01460.html [12] http://fedoraproject.org/wiki/Features/ApplicationInstaller [13] http://publictest10.fedoraproject.org/amber Jeff re-iterated[14] his point that "driving users to a different site than the package maintainers... and allowing them to comment [is] going to cause a communication gap" and characterized this as "driveby commenting and rating." Matthias Clasen did not accept that the use cases and requirements were the same as those for PackageDB and argued that "[t]his is not an effort to improve package quality or gain new contributors. This is an effort to make life of users better. It is not about packages, but about applications." Robin was[15] against Jeff's idea of a "monolithic app" and emphasized that he was using existing infrastructure to provide a new interface and also planning easy export of the data. He envisioned this data as providing, for example, a feed of comments about each package to PackageDB: "More of a semantic web type idea than an isolated database or a 'one-stop shop'." [14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01472.html [15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01481.html === RPM Inspires Intel Moblin2 Shift From Ubuntu An excited Peter Robinson copied[1] a link to "The Register" to the list. The article claimed that Intel's next version of "Moblin"[2] (cunningly codenamed Moblin2) would be replacing the "Ubuntu-based kernel" with the Fedora kernel and cited Dirk Hohndel. Specifically it attributed a desire to "move to Fedora [as] a technical decision based on the desire to adopt RPM for package management [and also that] having a vibrant community push is the winning factor." The article has since been rebuffed[3] by Hohndel in a comment on one of his blogs as "not only low on detail, it's also high in content that's made up or blown out of proportion" but he does confirm that "we decided to move to an rpm based distribution as that gave us better build tools and most importantly a better way to manage the licenses under which the individual packages are released." [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01381.html [2] Moblin is a GNU/Linux-based software stack for Mobile Internet Devices which includes Xorg,GStreamer,ALSA,the MatchboxWM, GTK, Cairo, Pango, D-Bus, Avahi, Evolution Data Server and more. In order to make life easy for developers a Moblin Image Creator makes it easy to create a small 350-600MB binary image for a particular architecture. Moblin explicitly aims to provide an alternative to GNOME and KDE. http://www.moblin.org/resource.center.php [3] http://www.hohndel.org/communitymatters/moblin/moblin-at-oscon/ Commentary on @fedora-devel tended to cautious optimism mixed with a desire for a lot more information. Jeff Spaleta asked[4] whether the idea was to have Moblin2 be a "part of the larger Fedora project or is it going to be a downstream derived distribution that will include components such that it can not carry the Fedora name?" and broached the idea that Moblin2 might be a candidate for a Secondary Architecture (see FWN#90[5] and FWN#92[6].) DavidWoodhouse (posting with an Intel.com sig) also liked[7] the idea of a Moblin2 SIG producing a Fedora spin for MIDs (Mobile Internet Devices.) [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01386.html [5] http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal [6] http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01417.html While "yersinia" thought that the emphasis on RPM was interesting Hansde Goede was intrigued[8] by the emphasis on community activity. Hans suggested that Jeff Spaleta contact Dirk Hohndel to emphasize the dynamic nature of the FOSS community behind Fedora. Jeff suggested that Karsten Wade could meet with Dirk at this week's OSCON[9]. Ex-Red Hat star employee Arjanvande Ven volunteered[10] to do what he could to help make contact with Dirk, describing himself as "on the other side of a cube wall" from him. In response to Rahul Sundaram's request for concrete information from Intel Arjan responded[11] that he would do his best to get the right people to make contact, but that much of the speculation on @fedora-devel concerned topics which have an "eh we don't know yet" answer. He also repeated cautions against believing anything which journalists write. [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01397.html [9] http://en.oreilly.com/oscon2008/public/content/home [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01447.html [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01523.html Paul Frields followed up[12] with details of a meeting at OSCON with senior Fedora hackers. It seemed that the ability to use OpenSuSE's Open Build System (which is based on RPM) was one of the main motivations behind Intel's move. Apparently Koji (the Fedora Project's buildsystem) lacks some specific functionality. Discussion between Paul Frields and Jeff Spaleta centered[13] around whether the apparent Moblin2 plan of acting as a downstream derivative of the Fedora kernel would allow them to garner community contributions and whether this mattered anyway given Intel's vast resources. [12] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00198.html [13] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00214.html Arthur Pemberton thought that this was a good opportunity to take on some of the anti-RPM and anti-YUM misinformation which had been spread about. David Nielsen thought it was best to merely demand proof from those spreading FUD. Seth Vidal conceded[14] that perhaps not enough had been done to publicize the improvements in YUM and RPM over the last few years and cited[15] a particular case-study of a smartpm user comparing it with YUM to the advantage of the latter. [14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01503.html [15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01507.html === Artwork In this section, we cover the Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: Nicu Buculei === Nodoka development After Martin Sourada laid out some plans last week for the Nodoka GTK2 theme engine development, he updated the Fedora Art list with news about the topic: "Considering that the Feature freeze for F10 is nearing and I haven't finished yet with the sketching, I'll push it for Fedora 11, while in Fedora 10 we'll have new notification theme [1], maybe the Echo icons and some minor improvements to the gtk theme/engine." [1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00217.html === Gathering feed-back about Fedora 10 theme proposals After the first round of the theme creation process for Fedora 10 ended, Nicu Buculei started gathering[1] feed-back from the community (everyone is invited to participated, including the Fedora Weekly News readers): "Since the first round for F10 themes just ended, I wrote to my (infamous) blog an article[2] listing all the proposals, including thumbnails and descriptions and asked for feedback (noting that the preferred way is this mailing list). Also posted about it on FedoraForum[3]." [1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00222.html [2] http://nicubunu.blogspot.com/2008/07/fedora-10-themes-round-1.html [3] http://forums.fedoraforum.org/showthread.php?p=1050722 === A possible Bluecurve revival Andy Fitzsimon shared[1] on the Fedora Art list a theme mockup "I didn't design it specifically for fedora but I hope someone here finds it useful for future mocks" and very quickly Hylke Bons expressed his interest[2] and idea about using it in combination with his own project[3] "I think this will fit well in my attempt to ressurect Bluecurve" (Bluecurve is the venerable theme introduced in Red Hat Linux 8 and used as a default until Fedora 6). [1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00225.html [2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00226.html [3] http://bomahy.nl/hylke/wip/bluetwist.png === Security Advisories In this section, we cover Security Advisories from fedora-package-announce. https://www.redhat.com/mailman/listinfo/fedora-package-announce Contributing Writer: David Nalley === Fedora 9 Security Advisories * mantis-1.1.2-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00801.html * dbmail-2.2.9-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01094.html * libetpan-0.54-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01093.html * php-5.2.6-2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01021.html * ruby-1.8.6.230-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01016.html * gnutls-2.0.4-3.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00980.html * licq-1.3.5-2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00879.html * perl-5.10.0-27.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00874.html * linuxdcpp-1.0.1-3.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01106.html * sipp-3.1-2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01160.html === Fedora 8 Security Advisories * wireshark-1.0.2-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00798.html * asterisk-1.4.21.2-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00839.html * mantis-1.1.2-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg00813.html -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From justinc at cs.washington.edu Sat Jul 26 02:04:35 2008 From: justinc at cs.washington.edu (Justin Cappos) Date: Fri, 25 Jul 2008 19:04:35 -0700 Subject: YUM security issues... In-Reply-To: <29888.1217034687@devserv.devel.redhat.com> References: <5039.1216653594@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> Message-ID: <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> Yes, you clearly described one of the attacks we see with MirrorManager. A few comments: > 1) Have MirrorManager use https and return some repo verification data. Is the verification data a signed repomd.xml? Can you expand on this a little? By the way, before I forget it would be a good idea to avoid using a detached signature for repomd.xml. If you have the signature and data in separate files, you can have false positives for incorrect signatures (for example when the files are updated). > 2) Sign the repo data, and if it's older than X, don't use it (I don't like > this solution, but it's probably the easiest, just push out a new > signed repo file once a day, even if nothing changes.) You also want to make sure clients don't accept older versions of the metadata than what they've seen. In other words, if they'll accept metadata up to 1 week old, and they've downloaded metadata from yesterday, they shouldn't accept metadata that was signed 5 days ago. > 3) Always get repo data from fedoraproject.org (probably not practical due > to resource issues) I think this is similar to what openSUSE / SUSE Linux Enterprise do (they actually serve signed metadata from their Download Redirector), so it may be practical for you to do in practice. However, you need to worry about man-in-the-middle attackers... > 4) use DNS, have the client query > .repo.fedoraproject.org > if the lookup fails, the repo is invalid. (this is really cheap from a > resource standpoint, but hard to do technically) Same comment about man-in-the-middle attacks. DNS-cache poisoning trivially circumvents this protection... Thanks, Justin From kevin at tummy.com Mon Jul 28 16:26:03 2008 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 28 Jul 2008 10:26:03 -0600 Subject: Email aliases and new cvs requests In-Reply-To: <488CD57C.7020007@gmail.com> References: <488CD57C.7020007@gmail.com> Message-ID: <20080728102603.327d35c7@ohm.scrye.com> On Sun, 27 Jul 2008 13:07:24 -0700 Toshio Kuratomi wrote: > Hi guys, > > Last week Seth implemented email aliases for the people who should be > notified of changes to packages. I used this new functionality to > have getnotifylist, which looks up who to notify on cvs commits, stop > querying the pkgdb directly (a slow operation with multiple points > where it could fail) and instead just construct the alias from the > packagename. > > This works well except for one case: When a new package is created, > the alias for the package does not yet exist. This means that when > someone makes the initial branch for a package they get a bounce > message because we were unable to send to the non-existent email > address. > > I think the solution is going to have to be that the pkgdb has to do > the branching. Or, at least, the pkgdb is going to need to know > which packages need branching and cvs-int will have to query for > those with a cron job and perform the action. That way the new > package can be added to the pkgdb along with a branch request. The > packagedb will record the new package and add the need for cvs > branches to a queue. The packagedb will take the branch request > through various stages until it is done. On advantage to this approach is that it might get us further toward allowing people to request new package adds and branches directly in packagedb, only needing cvsadmin approval, instead of the manual process now with bugzilla cvs requests. > Here's my idea for stages: > > 1) Request for new package with new branch is added to the packagedb. > 2) Request is marked approved by an admin > 3) Packagedb create the record for the package > 4) Packagedb waits for the email alias to be created (currently, the > packagedb doesn't know for sure that the alias has been created... > we'll just wait an appropriate length of time. If this proves > problematic we can create a URL that records that aliases has been > created that is only authorized to certain users.) > 5) Packagedb records that the package is ready to be branched. > 6) cvs-int has a cron job that queries for packages to branch, > branches them, and then records that they have been created. > > If anyone can think of a better way to solve this, please let me > know. I'll start work on this about the middle of next week. Well, the information is in several places, it's just a matter of which one is the easiest/most reliable/least blocking way to get it. The above sounds ok to me, as long as it also gets us closer to a more automated way of processing new packages / new branches. > > -Toshio > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Matt_Domsch at dell.com Mon Jul 28 17:07:54 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 28 Jul 2008 12:07:54 -0500 Subject: YUM security issues... In-Reply-To: <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> References: <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> Message-ID: <20080728170754.GB4775@auslistsprd01.us.dell.com> Seth, James Antill, and I met a week ago to discuss. These are the steps we believe are necessary to resolve. I didn't realize this hadn't been posted yet. 1. repomd.xml needs to be signed. Either attached or detached sig (advice sought). If attached, format would be delimiter / size of above ? signature 2. mirrormanager will start using metalinks or something quite like that, to publish the repomd.xml file pointers on the various mirrors worldwide. This will include typed checksums, a time stamp, and a file size, plus the various URL methods and countries for the mirrors. (I've been coding this on planes this week). One challenge here is that the metalink XML format doesn't allow for >1 set of attributes for a given file. We would like to include attributes for repomd.xml for the last several days, because slightly stale mirrors really are OK (pending rsync). 3. mirrormanager requests will use https. 4. yum will enable https cert verification and CRL checking. Right now it secures the stream but doesn't verify the cert. 5. yum will grow repomd.xml signature check 6. yum will grow metalink parsing 7. fedora-release yum.repos.d/* files will point at the new metalink=https://mirrors.fedoraproject.org/metalink?... URL. Seem reasonable? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From neo.reeves at gmail.com Mon Jul 28 17:39:59 2008 From: neo.reeves at gmail.com (Neo Reeves) Date: Mon, 28 Jul 2008 22:39:59 +0500 Subject: Intro Message-ID: Hello everyone, My name is Mohamed Sameeh and I am one of the Fedora Ambassadors for Maldives. I've been in the Linux World Since Redhat 9 and I've been in the field of IT for over 5 years now. During the course I have administered Linux Mail Servers, High Traffic Web Severs with MySQL and Oracle back ends, Linux NAT Firewall/Routers. I have a good undersatanding of Internet and Networking along with a handful of programming skills. I am CompTIA Network+ and CCNA certified. And I currently work for the government of Maldives. I have programming skills in PHP, Perl, C and Shell Scripts. Here are links to some of the scripts that I have written: A simple script I wrote to backup a NAT/Firewall - http://blog.fourthirty.org/wp-content/uploads/2008/05/bacup.pl Another script I wrote to get a dump of my telephone companies phone records from their website - http://blog.fourthirty.org/wp-content/uploads/2008/05/edir.pl I am fairly good with Visual Basic too in case some programming for Mono is needed. I often program small scripts for the servers I manage to perform specific tasks. But I don't think that I am a pro at Programming or a master in System Administration. But I would like to offer all help I could to the Fedora Project as time and my knowledge permits me. I am eager to learn and is always working on ways to improve my various skills in the IT field. So if any of you think that I could be of assistance to you please let me know. It would be an honor to give my best input in it. Thnx, Sameeh -------------- next part -------------- An HTML attachment was scrubbed... URL: From bressers at redhat.com Mon Jul 28 17:43:29 2008 From: bressers at redhat.com (Josh Bressers) Date: Mon, 28 Jul 2008 13:43:29 -0400 Subject: YUM security issues... In-Reply-To: <20080728170754.GB4775@auslistsprd01.us.dell.com> References: <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> Message-ID: <22258.1217267009@devserv.devel.redhat.com> On 28 July 2008, Matt Domsch wrote: > Seth, James Antill, and I met a week ago to discuss. These are the > steps we believe are necessary to resolve. I didn't realize this > hadn't been posted yet. > > > 1. repomd.xml needs to be signed. Either attached or detached sig > (advice sought). If attached, format would be > > > delimiter / size of above ? > signature > > > 2. mirrormanager will start using metalinks or something quite like > that, to publish the repomd.xml file pointers on the various > mirrors worldwide. This will include typed checksums, a time > stamp, and a file size, plus the various URL methods and countries > for the mirrors. (I've been coding this on planes this week). > > One challenge here is that the metalink XML format doesn't allow for > >1 set of attributes for a given file. We would like to include > attributes for repomd.xml for the last several days, because slightly stale > mirrors really are OK (pending rsync). > > 3. mirrormanager requests will use https. > > 4. yum will enable https cert verification and CRL checking. Right now it > secures the stream but doesn't verify the cert. > > 5. yum will grow repomd.xml signature check > > 6. yum will grow metalink parsing > > 7. fedora-release yum.repos.d/* files will point at the new > metalink=https://mirrors.fedoraproject.org/metalink?... URL. > > > Seem reasonable? > This does seem reasonable, the only question I have is how often does yum ask MirrorManager for a new repo.xml file? This strikes me as a good solution to the problems at hand. Thanks guys, the work is appreciated. -- JB From jkeating at redhat.com Mon Jul 28 18:25:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jul 2008 14:25:48 -0400 Subject: YUM security issues... In-Reply-To: <20080728170754.GB4775@auslistsprd01.us.dell.com> References: <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> Message-ID: <1217269548.3151.20.camel@localhost.localdomain> On Mon, 2008-07-28 at 12:07 -0500, Matt Domsch wrote: > 1. repomd.xml needs to be signed. Either attached or detached sig > (advice sought). If attached, format would be I would prefer a detached sig, so that the checksum of repomd.xml itself doesn't change if the GPG sig for it does. This is important as there are control files in the compose to track consistency of the tree itself, and having the repomd.xml change it's key would invalidate this control file. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon Jul 28 18:58:53 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jul 2008 00:28:53 +0530 Subject: Fedora Weekly News Issue 136 (fwd) In-Reply-To: References: Message-ID: <488E16ED.4040706@fedoraproject.org> Mike McGrath wrote: > What happened to our beat guy? Anyone else want to volunteer? > > -Mike The beat guy was in training last week. He would resume this week IIRC Rahul From skvidal at fedoraproject.org Mon Jul 28 19:22:59 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jul 2008 15:22:59 -0400 Subject: YUM security issues... In-Reply-To: <1217269548.3151.20.camel@localhost.localdomain> References: <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> <1217269548.3151.20.camel@localhost.localdomain> Message-ID: <1217272979.4468.23.camel@rosebud> On Mon, 2008-07-28 at 14:25 -0400, Jesse Keating wrote: > On Mon, 2008-07-28 at 12:07 -0500, Matt Domsch wrote: > > 1. repomd.xml needs to be signed. Either attached or detached sig > > (advice sought). If attached, format would be > > I would prefer a detached sig, so that the checksum of repomd.xml itself > doesn't change if the GPG sig for it does. This is important as there > are control files in the compose to track consistency of the tree > itself, and having the repomd.xml change it's key would invalidate this > control file. > detached sig definitely. Independent of how (or why) this is done we will maintain backward compat. Signing the repomd.xml directly will not allow backward compat (nor cross compat with apt/smart/etc). I've already written the code for the detached sig - it'll be checked into yum upstream this afternoon. -sv From skvidal at fedoraproject.org Mon Jul 28 19:30:57 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jul 2008 15:30:57 -0400 Subject: YUM security issues... In-Reply-To: <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> References: <5039.1216653594@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> Message-ID: <1217273457.4468.30.camel@rosebud> On Fri, 2008-07-25 at 19:04 -0700, Justin Cappos wrote: > Yes, you clearly described one of the attacks we see with MirrorManager. > > A few comments: > > > 1) Have MirrorManager use https and return some repo verification data. > > Is the verification data a signed repomd.xml? Can you expand on this a little? > > By the way, before I forget it would be a good idea to avoid using a > detached signature for repomd.xml. If you have the signature and > data in separate files, you can have false positives for incorrect > signatures (for example when the files are updated). And if that happens then it regets to another mirror and attempts to find a valid cert. Detached sigs is how it will be b/c otherwise we're breaking backward compat with older clients. And that's just chockful of pain. > > 2) Sign the repo data, and if it's older than X, don't use it (I don't like > > this solution, but it's probably the easiest, just push out a new > > signed repo file once a day, even if nothing changes.) > > You also want to make sure clients don't accept older versions of the > metadata than what they've seen. In other words, if they'll accept > metadata up to 1 week old, and they've downloaded metadata from > yesterday, they shouldn't accept metadata that was signed 5 days ago. And do what if they can't? think about it - at some point every repo will be 'too old' and then what? The client cannot use it at all? If that's the case then we're intentionally putting a sundown into our code, what a nightmare that is. The best we can do is warn and alert the user that the metadata is old. Stopping working is just preposterous - it's just a different kind of DoS if we do that. If the user cannot read and take warnings then there is really nothing that can be done for them. -sv From mmcgrath at redhat.com Mon Jul 28 20:54:38 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 28 Jul 2008 15:54:38 -0500 (CDT) Subject: Intro In-Reply-To: References: Message-ID: On Mon, 28 Jul 2008, Neo Reeves wrote: > Hello everyone, > > My name is Mohamed Sameeh and I am one of the Fedora Ambassadors for Maldives. I've been in the Linux World Since > Redhat 9 and I've been in the field of IT for over 5 years now. During the course I have administered Linux Mail > Servers, High Traffic Web Severs with MySQL and Oracle back ends, Linux NAT Firewall/Routers. I have a good > undersatanding of Internet and Networking along with a handful of programming skills. > > I am CompTIA Network+ and CCNA certified. And I currently work for the government of Maldives. > > I have programming skills in PHP, Perl, C and Shell Scripts. Here are links to some of the scripts that I have > written: > > A simple script I wrote to backup a NAT/Firewall - http://blog.fourthirty.org/wp-content/uploads/2008/05/bacup.pl > Another script I wrote to get a dump of my telephone companies phone records from their website - > http://blog.fourthirty.org/wp-content/uploads/2008/05/edir.pl > > I am fairly good with Visual Basic too in case some programming for Mono is needed. > > I often program small scripts for the servers I manage to perform specific tasks. But I don't think that I am a pro at > Programming or a master in System Administration. But I would like to offer all help I could to the Fedora Project as > time and my knowledge permits me. I am eager to learn and is always working on ways to improve my various skills in > the IT field. So if any of you think that I could be of assistance to you please let me know. It would be an honor to > give my best input in it. > Welcome Neo, is there a specific area you were interested in? Just the Infrastructure team in general or in programming, documentation, etc? -Mike From mikem at fedoraproject.org Mon Jul 28 21:28:33 2008 From: mikem at fedoraproject.org (Mike McLean) Date: Mon, 28 Jul 2008 17:28:33 -0400 Subject: YUM security issues... In-Reply-To: <20080728170754.GB4775@auslistsprd01.us.dell.com> References: <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> Message-ID: <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> On Mon, Jul 28, 2008 at 1:07 PM, Matt Domsch wrote: > 1. repomd.xml needs to be signed. Either attached or detached sig > (advice sought). If attached, format would be I see a number of good ideas to improve the situation, but I don't think I've seen anyone suggest the following. Would it be feasible to audit the mirror content? We have the list of mirrors, we know what the content should be. I think we'd only need to validate the mirrored repomd.xml, right? Doesn't seem to onerous... yes, yes, not perfect, malicious mirror could change the content, etc, but at least we'd have some measure of detection. From skvidal at fedoraproject.org Mon Jul 28 21:29:09 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jul 2008 17:29:09 -0400 Subject: YUM security issues... In-Reply-To: <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> References: <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> Message-ID: <1217280549.4468.41.camel@rosebud> On Mon, 2008-07-28 at 17:28 -0400, Mike McLean wrote: > On Mon, Jul 28, 2008 at 1:07 PM, Matt Domsch wrote: > > 1. repomd.xml needs to be signed. Either attached or detached sig > > (advice sought). If attached, format would be > > I see a number of good ideas to improve the situation, but I don't > think I've seen anyone suggest the following. > > Would it be feasible to audit the mirror content? We have the list of > mirrors, we know what the content should be. I think we'd only need to > validate the mirrored repomd.xml, right? Doesn't seem to onerous... > > yes, yes, not perfect, malicious mirror could change the content, etc, > but at least we'd have some measure of detection. which is the point. A malicious mirror could safely lie to us and not lie to their targets. Additionally, mirrormanager DOES check the mirrors. -sv From katzj at redhat.com Mon Jul 28 21:37:35 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jul 2008 17:37:35 -0400 Subject: YUM security issues... In-Reply-To: <1217280549.4468.41.camel@rosebud> References: <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> <1217280549.4468.41.camel@rosebud> Message-ID: <1217281055.12821.29.camel@aglarond.local> On Mon, 2008-07-28 at 17:29 -0400, seth vidal wrote: > On Mon, 2008-07-28 at 17:28 -0400, Mike McLean wrote: > > On Mon, Jul 28, 2008 at 1:07 PM, Matt Domsch wrote: > > > 1. repomd.xml needs to be signed. Either attached or detached sig > > > (advice sought). If attached, format would be > > > > I see a number of good ideas to improve the situation, but I don't > > think I've seen anyone suggest the following. > > > > Would it be feasible to audit the mirror content? We have the list of > > mirrors, we know what the content should be. I think we'd only need to > > validate the mirrored repomd.xml, right? Doesn't seem to onerous... > > > > yes, yes, not perfect, malicious mirror could change the content, etc, > > but at least we'd have some measure of detection. > > which is the point. A malicious mirror could safely lie to us and not > lie to their targets. > > Additionally, mirrormanager DOES check the mirrors. Except, of course, for mirrors which are internal to a specific site and thus can't be contacted by MM Jeremy From skvidal at fedoraproject.org Mon Jul 28 21:38:35 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jul 2008 17:38:35 -0400 Subject: YUM security issues... In-Reply-To: <1217281055.12821.29.camel@aglarond.local> References: <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> <1217280549.4468.41.camel@rosebud> <1217281055.12821.29.camel@aglarond.local> Message-ID: <1217281115.4468.43.camel@rosebud> On Mon, 2008-07-28 at 17:37 -0400, Jeremy Katz wrote: > On Mon, 2008-07-28 at 17:29 -0400, seth vidal wrote: > > On Mon, 2008-07-28 at 17:28 -0400, Mike McLean wrote: > > > On Mon, Jul 28, 2008 at 1:07 PM, Matt Domsch wrote: > > > > 1. repomd.xml needs to be signed. Either attached or detached sig > > > > (advice sought). If attached, format would be > > > > > > I see a number of good ideas to improve the situation, but I don't > > > think I've seen anyone suggest the following. > > > > > > Would it be feasible to audit the mirror content? We have the list of > > > mirrors, we know what the content should be. I think we'd only need to > > > validate the mirrored repomd.xml, right? Doesn't seem to onerous... > > > > > > yes, yes, not perfect, malicious mirror could change the content, etc, > > > but at least we'd have some measure of detection. > > > > which is the point. A malicious mirror could safely lie to us and not > > lie to their targets. > > > > Additionally, mirrormanager DOES check the mirrors. > > Except, of course, for mirrors which are internal to a specific site and > thus can't be contacted by MM > and if they're evil then the folks involved are screwed anyway.... which, after all, is why we're in favor of repomd.xml signing -sv From mikem.rtp at gmail.com Mon Jul 28 21:54:39 2008 From: mikem.rtp at gmail.com (Mike McLean) Date: Mon, 28 Jul 2008 17:54:39 -0400 Subject: YUM security issues... In-Reply-To: <1217280549.4468.41.camel@rosebud> References: <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> <1217280549.4468.41.camel@rosebud> Message-ID: <4f50e0680807281454s5f025158y1abda51d3f14be8f@mail.gmail.com> On Mon, Jul 28, 2008 at 5:29 PM, seth vidal wrote: > On Mon, 2008-07-28 at 17:28 -0400, Mike McLean wrote: >> Would it be feasible to audit the mirror content? We have the list of >> mirrors, we know what the content should be. I think we'd only need to >> validate the mirrored repomd.xml, right? Doesn't seem to onerous... >> >> yes, yes, not perfect, malicious mirror could change the content, etc, >> but at least we'd have some measure of detection. > > which is the point. A malicious mirror could safely lie to us and not > lie to their targets. Depends on who 'us' is. We could run such checks from a number of different locations. Anyway, I didn't mean to suggest this as a total solution. > Additionally, mirrormanager DOES check the mirrors. Good to know. From mikem at fedoraproject.org Mon Jul 28 21:57:39 2008 From: mikem at fedoraproject.org (Mike McLean) Date: Mon, 28 Jul 2008 17:57:39 -0400 Subject: YUM security issues... In-Reply-To: <1217281115.4468.43.camel@rosebud> References: <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807251904u4157a362jd01e5b5087271e47@mail.gmail.com> <20080728170754.GB4775@auslistsprd01.us.dell.com> <4f50e0680807281428i35406862y5dcad4f2e46b687a@mail.gmail.com> <1217280549.4468.41.camel@rosebud> <1217281055.12821.29.camel@aglarond.local> <1217281115.4468.43.camel@rosebud> Message-ID: <4f50e0680807281457m39a020f4ueffb3fa62d99c4b9@mail.gmail.com> On Mon, Jul 28, 2008 at 5:38 PM, seth vidal wrote: > On Mon, 2008-07-28 at 17:37 -0400, Jeremy Katz wrote: >> Except, of course, for mirrors which are internal to a specific site and >> thus can't be contacted by MM > > and if they're evil then the folks involved are screwed anyway.... Well, depends. Having an evil system on an internal network is bad, but not as bad as having your servers compromised. From a.badger at gmail.com Tue Jul 29 02:23:44 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 Jul 2008 19:23:44 -0700 Subject: cvsextras renamed to packager Message-ID: <488E7F30.8010508@gmail.com> cvsextras has been renamed to packager today. grepping puppet, applications, and various other sources, I only found one place that I had to change today, most of the work for this had already been done. This is just a reminder that any scripts that depends on querying the "cvsextras" group will now need to query "packager". -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Tue Jul 29 02:34:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jul 2008 08:04:23 +0530 Subject: cvsextras renamed to packager In-Reply-To: <488E7F30.8010508@gmail.com> References: <488E7F30.8010508@gmail.com> Message-ID: <488E81AF.7020807@fedoraproject.org> Toshio Kuratomi wrote: > cvsextras has been renamed to packager today. grepping puppet, > applications, and various other sources, I only found one place that I > had to change today, most of the work for this had already been done. > This is just a reminder that any scripts that depends on querying the > "cvsextras" group will now need to query "packager". Has documentation been updated too? Rahul From a.badger at gmail.com Tue Jul 29 03:31:37 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 Jul 2008 20:31:37 -0700 Subject: cvsextras renamed to packager In-Reply-To: <488E81AF.7020807@fedoraproject.org> References: <488E7F30.8010508@gmail.com> <488E81AF.7020807@fedoraproject.org> Message-ID: <488E8F19.9080908@gmail.com> Rahul Sundaram wrote: > Toshio Kuratomi wrote: >> cvsextras has been renamed to packager today. grepping puppet, >> applications, and various other sources, I only found one place that I >> had to change today, most of the work for this had already been done. >> This is just a reminder that any scripts that depends on querying the >> "cvsextras" group will now need to query "packager". > > Has documentation been updated too? > No. documebtation still references cvsextras. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From neo.reeves at gmail.com Tue Jul 29 06:16:32 2008 From: neo.reeves at gmail.com (Neo Reeves) Date: Tue, 29 Jul 2008 11:16:32 +0500 Subject: Intro In-Reply-To: References: Message-ID: Thanks Mike, actually I am interested in programming but I have no idea whether my current level of programming skills would be of much help for the current developers involved. - Neo On Tue, Jul 29, 2008 at 1:54 AM, Mike McGrath wrote: > On Mon, 28 Jul 2008, Neo Reeves wrote: > > > Hello everyone, > > > > My name is Mohamed Sameeh and I am one of the Fedora Ambassadors for > Maldives. I've been in the Linux World Since > > Redhat 9 and I've been in the field of IT for over 5 years now. During > the course I have administered Linux Mail > > Servers, High Traffic Web Severs with MySQL and Oracle back ends, Linux > NAT Firewall/Routers. I have a good > > undersatanding of Internet and Networking along with a handful of > programming skills. > > > > I am CompTIA Network+ and CCNA certified. And I currently work for the > government of Maldives. > > > > I have programming skills in PHP, Perl, C and Shell Scripts. Here are > links to some of the scripts that I have > > written: > > > > A simple script I wrote to backup a NAT/Firewall - > http://blog.fourthirty.org/wp-content/uploads/2008/05/bacup.pl > > Another script I wrote to get a dump of my telephone companies phone > records from their website - > > http://blog.fourthirty.org/wp-content/uploads/2008/05/edir.pl > > > > I am fairly good with Visual Basic too in case some programming for Mono > is needed. > > > > I often program small scripts for the servers I manage to perform > specific tasks. But I don't think that I am a pro at > > Programming or a master in System Administration. But I would like to > offer all help I could to the Fedora Project as > > time and my knowledge permits me. I am eager to learn and is always > working on ways to improve my various skills in > > the IT field. So if any of you think that I could be of assistance to you > please let me know. It would be an honor to > > give my best input in it. > > > > Welcome Neo, is there a specific area you were interested in? Just the > Infrastructure team in general or in programming, documentation, etc? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- .:: BELIEVE THE UNBELIEVABLE ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Tue Jul 29 13:30:05 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Jul 2008 08:30:05 -0500 (CDT) Subject: Intro In-Reply-To: References: Message-ID: On Tue, 29 Jul 2008, Neo Reeves wrote: > Thanks Mike, actually I am interested in programming but I have no idea whether my current level of programming skills > would be of much help for the current developers involved. > Well I'd say start looking at bugs for some of your favorite apps and get to submitting patches. There's almost certainly some simple bugs out there just waiting so you can get comfortable with the process. Then you can challenge yourself with more difficult bugs. -Mike From neo.reeves at gmail.com Tue Jul 29 14:25:58 2008 From: neo.reeves at gmail.com (Neo Reeves) Date: Tue, 29 Jul 2008 19:25:58 +0500 Subject: Intro In-Reply-To: References: Message-ID: Thnx, Will do. -Neo On Tue, Jul 29, 2008 at 6:30 PM, Mike McGrath wrote: > On Tue, 29 Jul 2008, Neo Reeves wrote: > > > Thanks Mike, actually I am interested in programming but I have no idea > whether my current level of programming skills > > would be of much help for the current developers involved. > > > > Well I'd say start looking at bugs for some of your favorite apps and get > to submitting patches. There's almost certainly some simple bugs out > there just waiting so you can get comfortable with the process. Then you > can challenge yourself with more difficult bugs. > > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- .:: BELIEVE THE UNBELIEVABLE ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalgoci at redhat.com Tue Jul 29 14:30:58 2008 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Tue, 29 Jul 2008 10:30:58 -0400 (EDT) Subject: EnableSendfile on koji Message-ID: Can someone please check and let me know what the EnableSendfile setting is on the koji apache configs? Thanks! -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 From mmcgrath at redhat.com Tue Jul 29 14:37:26 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Jul 2008 09:37:26 -0500 (CDT) Subject: Review Request Message-ID: Bret has been working on a package for deployment in Fedora Infrastructure. Anyone care to fast track it? https://bugzilla.redhat.com/457060 -Mike From dennis at ausil.us Tue Jul 29 14:57:46 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 29 Jul 2008 09:57:46 -0500 Subject: EnableSendfile on koji In-Reply-To: References: Message-ID: <200807290957.54837.dennis@ausil.us> On Tuesday 29 July 2008, Matthew Galgoci wrote: > Can someone please check and let me know what the EnableSendfile setting is > on the koji apache configs? > > Thanks! there is no setting EnableSendfile in kojis apache configs -- Dennis Gilmore -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From justinc at cs.washington.edu Tue Jul 29 16:35:03 2008 From: justinc at cs.washington.edu (Justin Cappos) Date: Tue, 29 Jul 2008 09:35:03 -0700 Subject: YUM security issues... In-Reply-To: <29888.1217034687@devserv.devel.redhat.com> References: <5039.1216653594@devserv.devel.redhat.com> <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> Message-ID: <60e301c40807290935ve608497h530792b2f9d2dfaa@mail.gmail.com> I was wondering if any changes have been made or are planned for MirrorManager (i.e. preventing mirrors from arbitrary grabbing parts of the address space). We're submitting the final version of our paper soon (the version that will appear in print) and I'd like to include any updates about this. Thanks, Justin On Fri, Jul 25, 2008 at 6:11 PM, Josh Bressers wrote: > On 25 July 2008, Matt Domsch wrote: >> On Fri, Jul 25, 2008 at 01:52:26PM -0400, Josh Bressers wrote: >> > That's a lot of IPs though. Can I request multiple /16s, or only one? >> >> As many as you like. And recall, such changes are made using your FAS >> credentials. > > Are these ever checked? Does say a mail get generated every time someone > adds one of these? My fear would be that someone could blanket quite a > large IP space without anyone noticing. Granted that would no doubt > generate a huge volume of traffic, but if they're serving up a frozen repo, > they probably won't be pushing all that much data. > >> >> > How many mirrors are doing this? >> >> 374 total Hosts >> 185 have at least 1 netblock entry >> 94 of these are "private" - don't serve the public >> > > wow, that's quite a few. I wasn't expecting numbers this high honestly. > >> >> > Does the mirror have to be part of the /16 to request it? >> >> no. Take for example Dell's mirrors. Netblock 143.166/16 is Dell US, >> but the mirror IPs are located inside the 10/8 private space. >> > > OK, so here is the problem the way I see it, signing the repository won't > fix it. I'll try to explain this clearly, Justin can yell at me if I've > gotten any of this wrong. > > So let's say Mallory (the bad guy) decides that he wants to host a > malicious mirror and wait for a nasty security flaw. He sets up his mirror > and even claims some IP subnets to serve. Bob and Alice are happily > installing valid updates from him for some period of time. Since Mallory > has claimed to serve a specific subnet, he has a rather impressive view of > what Bob and Alice have installed. > > Now let's say there is a horrible security bug found in a mail server. > Mallory knows for a fact that Bob and Alice both have it installed as he's > been their mirror for a while. Mallory stops updating his mirror, so none > of the users being served will get the mail server updates. Mallory also > knows the IP address of the vulnerable clients and can easily break into > their systems. > > So from what I understand MirrorManager will check on the mirrors to ensure > they're not out of date. Mallory knows this and makes sure that when > MirrorManager connects to his mirror, it lies and serves up current > metadata. > > > So here is the problem. The repodata was valid. The packages are signed. > Even if we sign the repodata, this attack works. Being able to acquire an > IP block simply makes this attack easier to do. It's still very possible > that a bad mirror will wait for users to connect, serve up old content then > use this knowledge to break into their system. > > What this problem boils down to, is we need a way for clients to ask > MirrorManager what the current valid repo data is. Ideally we want the > results to be signed in some manner so it can't be spoofed. > > Some thoughts I've had are: > > 1) Have MirrorManager use https and return some repo verification data. > 2) Sign the repo data, and if it's older than X, don't use it (I don't like > this solution, but it's probably the easiest, just push out a new > signed repo file once a day, even if nothing changes.) > 3) Always get repo data from fedoraproject.org (probably not practical due > to resource issues) > 4) use DNS, have the client query > .repo.fedoraproject.org > if the lookup fails, the repo is invalid. (this is really cheap from a > resource standpoint, but hard to do technically) > 5) ??? > > Thanks. > > -- > JB > From Matt_Domsch at dell.com Tue Jul 29 19:03:30 2008 From: Matt_Domsch at dell.com (Domsch, Matt) Date: Tue, 29 Jul 2008 14:03:30 -0500 Subject: YUM security issues... In-Reply-To: <60e301c40807290935ve608497h530792b2f9d2dfaa@mail.gmail.com> References: <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807290935ve608497h530792b2f9d2dfaa@mail.gmail.com> Message-ID: <20080729190330.GF14119@humbolt.us.dell.com> On Tue, Jul 29, 2008 at 11:35:03AM -0500, Justin Cappos wrote: > I was wondering if any changes have been made or are planned for > MirrorManager (i.e. preventing mirrors from arbitrary grabbing parts > of the address space). We're submitting the final version of our > paper soon (the version that will appear in print) and I'd like to > include any updates about this. Yesterday I sent the long list of steps planned or under way. Some of these involve MM, some yum. As for "arbitrary grabbing of address space", I'm open to ideas. Perhaps a /16 is too large for "anyone" to be able to grab - e.g. could should limit the auto-granted size by some amount. However, it doesn't eliminate the concern. If Mallory wants to attack specifically Alice, he only need know the addresses Alice is likely to be coming from and add those in, even one-at-a-time. Restricting to a /16 seemed reasonable to me. A good balance of "big enough to be useful", yet small enough that it can't affect too many people. Larger allocations are available on request, by showing some form of ARIN assignment. Still, one could request such and run a mirror inside that assignment that is still malicious. And I'm not willing to throw out this very useful feature, for fear someone could use it for evil. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Tue Jul 29 21:52:34 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Jul 2008 16:52:34 -0500 (CDT) Subject: x86-8 is offline for a while Message-ID: I'm getting some of the composer stuff ready for ticket #652 -Mike From bressers at redhat.com Wed Jul 30 11:59:55 2008 From: bressers at redhat.com (Josh Bressers) Date: Wed, 30 Jul 2008 07:59:55 -0400 Subject: YUM security issues... In-Reply-To: <20080729190330.GF14119@humbolt.us.dell.com> References: <1217000541.3119.19.camel@localhost.localdomain> <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807290935ve608497h530792b2f9d2dfaa@mail.gmail.com> <20080729190330.GF14119@humbolt.us.dell.com> Message-ID: <23827.1217419195@devserv.devel.redhat.com> On 29 July 2008, "Domsch, Matt" wrote: > On Tue, Jul 29, 2008 at 11:35:03AM -0500, Justin Cappos wrote: > > I was wondering if any changes have been made or are planned for > > MirrorManager (i.e. preventing mirrors from arbitrary grabbing parts > > of the address space). We're submitting the final version of our > > paper soon (the version that will appear in print) and I'd like to > > include any updates about this. > > As for "arbitrary grabbing of address space", I'm open to ideas. > Perhaps a /16 is too large for "anyone" to be able to grab - e.g. could > should limit the auto-granted size by some amount. However, it > doesn't eliminate the concern. If Mallory wants to attack > specifically Alice, he only need know the addresses Alice is likely to > be coming from and add those in, even one-at-a-time. > > Restricting to a /16 seemed reasonable to me. A good balance of "big > enough to be useful", yet small enough that it can't affect too many > people. Larger allocations are available on request, by showing some > form of ARIN assignment. Still, one could request such and run a > mirror inside that assignment that is still malicious. And I'm not > willing to throw out this very useful feature, for fear someone could > use it for evil. > I think this is fine, and even desirable in most instances. As long as yum will try the next mirror in the list if the primary one is outdated, this becomes a non issue. If anything, I'd suggest you advertise this feature more. I had no idea MirrorManager could do this, and I suspect there are a number of organizations that could benefit from knowing this. Thanks. -- JB From justinc at cs.washington.edu Wed Jul 30 15:42:44 2008 From: justinc at cs.washington.edu (Justin Cappos) Date: Wed, 30 Jul 2008 08:42:44 -0700 Subject: YUM security issues... In-Reply-To: <23827.1217419195@devserv.devel.redhat.com> References: <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807290935ve608497h530792b2f9d2dfaa@mail.gmail.com> <20080729190330.GF14119@humbolt.us.dell.com> <23827.1217419195@devserv.devel.redhat.com> Message-ID: <60e301c40807300842xf9a4176u8584707144228aee@mail.gmail.com> You might also think about requiring the mirror's IP address to fall in the subnet (or else they ask for your approval). This might further complicate an attacker using this for evil. Thank you for providing this information... Justin On Wed, Jul 30, 2008 at 4:59 AM, Josh Bressers wrote: > On 29 July 2008, "Domsch, Matt" wrote: >> On Tue, Jul 29, 2008 at 11:35:03AM -0500, Justin Cappos wrote: >> > I was wondering if any changes have been made or are planned for >> > MirrorManager (i.e. preventing mirrors from arbitrary grabbing parts >> > of the address space). We're submitting the final version of our >> > paper soon (the version that will appear in print) and I'd like to >> > include any updates about this. >> >> As for "arbitrary grabbing of address space", I'm open to ideas. >> Perhaps a /16 is too large for "anyone" to be able to grab - e.g. could >> should limit the auto-granted size by some amount. However, it >> doesn't eliminate the concern. If Mallory wants to attack >> specifically Alice, he only need know the addresses Alice is likely to >> be coming from and add those in, even one-at-a-time. >> >> Restricting to a /16 seemed reasonable to me. A good balance of "big >> enough to be useful", yet small enough that it can't affect too many >> people. Larger allocations are available on request, by showing some >> form of ARIN assignment. Still, one could request such and run a >> mirror inside that assignment that is still malicious. And I'm not >> willing to throw out this very useful feature, for fear someone could >> use it for evil. >> > > I think this is fine, and even desirable in most instances. As long as yum > will try the next mirror in the list if the primary one is outdated, this > becomes a non issue. > > If anything, I'd suggest you advertise this feature more. I had no idea > MirrorManager could do this, and I suspect there are a number of > organizations that could benefit from knowing this. > > Thanks. > > -- > JB > From stickster at gmail.com Wed Jul 30 19:24:09 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 30 Jul 2008 19:24:09 +0000 Subject: Release Planning Recap :: 2008-07-30, UTC 1700 In-Reply-To: <1217444037.2864.1.camel@adam> References: <1217443393.3694.96.camel@victoria> <1217444037.2864.1.camel@adam> Message-ID: <1217445849.3694.110.camel@victoria> On Wed, 2008-07-30 at 19:53 +0100, Jonathan Roberts wrote: > > === Marketing === > > * Not much on plate for Alpha in particular > > * Geek news will be all over the Alpha, are we doing anything to > > publicize it? > > ** Paul has been working with Kara on e.g. a press blog entry > > ** Our announcement should also serve as testing recruitment > > Re: this, I should have said in the call, we came up with a list of > approved URLs for the announcement last time around. Let's get this down > somewhere so we don't do it again and again. I think we had something > like: > > join.fp.o > get.fp.o > fp.o > > + release notes and release summary (which for alpha/beta are one) Correct Jon, I believe there is some back material on this on fedora-websites-list or fedora-infrastructure-list. Thanks for the reminder. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 dev at nigelj.com Thu Jul 31 02:59:04 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 31 Jul 2008 14:59:04 +1200 Subject: Server Monitoring - A replacement for Nagios? Message-ID: <48912A78.1040807@nigelj.com> Okay, so while this was intended to be a primary discussion point for tomorrows Infrastructure meeting we had a little bit of discussion first in #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like Nagios that I begun to setup for testing this week. In summary the discussion ended positively we think it will do the job quite well and we really need to now sit down and work out if we want to try implementing it on a limited scale in parallel with Nagios (to act as a comparison). The related part of the agenda for tomorrow now will be: * Do we want to push this into a limited trial (say 10 key-ish machines in our infrastructure) * How long would such a trial last for * What are we going to use as a metric for such a trial * Are there other concerns Personally I'd like to see this as a step forward in revamping sysadmin-noc so we can reduce the work load on members in sysadmin-main. Review the log below. -- Nigel 10:43 < mmcgrath> G: so whats your take on how big the zabbix db will get? Should we put it on db1 or on its own box? 10:43 < mmcgrath> if its on its own (probably the same one zabbix is on) we're lowering points of failure, but we might have to re-spec noc1 and noc2. 10:43 < G> mmcgrath: I'm not sure 10:44 < G> this is where it's great to have people like wakko666 and jcollie who use it atDAYJOB 10:44 < mmcgrath> yeah. 10:44 < G> maybe we need a nocdb1 10:44 < mmcgrath> If it needs to be pretty quick once it gets full of stuff, we might justwant to put it on db1. 10:44 < mmcgrath> if it stays light though, we'll probably just keep it localhost to noc1 and give noc1 more ram / disk space. 10:45 < wakko666> mmcgrath: the rate of growth for the zabbix DB directly depends on the poll rates for all of the checks 10:45 < mmcgrath> wakko666: if you don't mind my asking.... how many hosts do you have andhow big is the db? 10:45 < G> yeah, from what I can tell also, zabbix does it's own housekeeping to try and consolidate some of the data 10:45 < mmcgrath> and how much stuff do you monitor? pretty default stuff? or more then the default. 10:46 < wakko666> we have 50 hosts in production, and another 100 hosts outside that across two zabbix nodes 10:47 < mmcgrath> wakko666: is the two zabbix nodes for high availability or was it because one zabbix node couldn't handle the traffic? 10:47 < wakko666> it's because they're in different locations 10:47 < mmcgrath> 10:47 < mmcgrath> Do you have a dedicated db? How big is the raw database? 10:48 < fchiulli_> mmcgrath: I'm assuming that part of the discussion will be whether to have more than one zabbix monitoring host. 10:48 < wakko666> mmcgrath: we've got a dedicated mysql db for each node. the production data is currently around 10-20 GB, the non-production node sits at around 40-50 GB 10:48 < wakko666> the key thing to note is that zabbix keeps data in two forms, with tunable knobs for each. 10:48 < dgilmore> wakko666: over what time period? 10:48 < mmcgrath> wakko666: you don't happen to have sar data for those hosts you could give to me would you? :) 10:49 < wakko666> dgilmore: we're at about 3-4 months right now 10:49 < mmcgrath> I suppose we can start out small and move it later... its not really that big of a risk. 10:49 < wakko666> mmcgrath: unfortunately, today was my last day there. i was "reorganized" out of a job. ;-) 10:49 < dgilmore> wakko666: so your anticipating up to 80gb for production a year? 10:49 < mmcgrath> wakko666: doah, well... hope all is well. 10:50 < wakko666> dgilmore: sort of. as i was saying, there are two knobs. poll data, and trend data. 10:50 < wakko666> typically, we keep all polled data for about 7 days worth, then only keep trend data after that 10:50 < ricky> mmcgrath: IT's in now :-) 10:50 < dgilmore> much like cacti does 10:50 < mmcgrath> ricky: hilarious. 10:50 < wakko666> mmcgrath: yeah, i'll probably be fine. though, i wouldn't mind findinga spot at RH. ;-) 10:51 < G> wakko666: wait a second, I thought if you setup multiple nodes they could sharethe same tasks? 10:51 < mmcgrath> and, correct me if I'm wrong, but zabbix doesn't store RRD right? the graphs come from the database? 10:51 < G> mmcgrath: correct from what I can tell 10:51 < wakko666> mmcgrath: correct. graphs are auto-generated, not RRD. so you can create new graphs and they're autopopulated with old data 10:52 < wakko666> G: yes, nodes share the data from the tasks. the zabbix-agent.conf and zabbix-server.conf help configure which node performs the polling 10:52 < mmcgrath> wakko666: were you using auto-recovery services? 10:52 < G> wakko666: k, so it's one big db and you just assign hosts to each node? 10:53 < wakko666> mmcgrath: auto-recovery? not sure what you mean. perhaps you mean auto-discovery? 10:53 < G> wakko666: remote commands :) 10:53 < mmcgrath> wakko666: like if httpd dies on an app server, have zabbix restart it. 10:53 < wakko666> G: can be, or you can set up a db per node, or db on some nodes and not others. it's pretty flexible 10:54 < wakko666> mmcgrath: ah ha! yeah, you can have zabbix execute commands on healthcheck failure 10:54 < wakko666> really, the big limitation of zabbix is a couple of things 10:54 < G> I'd like to see noc1/noc2 share the zabbix checks 10:54 < wakko666> currently, in 1.4, there's no repeated notifications. one notify is allyou get. 10:54 < G> wakko666: yeah, I noticed that 10:54 < wakko666> (it's coming in 1.6, which is due in Sept) 10:54 < mmcgrath> G: yeah, I'm totally fine re-thinking how we have our noc's setup. The big things I want are: 10:55 < mmcgrath> paged alerts when a service is not available. 10:55 < mmcgrath> and email alerts when an individual service in a farm goes down. 10:55 < G> mmcgrath: yeah 10:55 < wakko666> mmcgrath: yup, no troubles doing those, and you'll likely get finer granularity than with nagios 10:55 < mmcgrath> that got kind of tricky in one nagios instance. 10:55 < G> yep, exactly 10:56 < mmcgrath> well, and even tricker in one nagios instance in PHX :) 10:56 < mmcgrath> wakko666: if there's some services that noc1 can't get to but noc2 can, can you tell zabbix to always check those with noc2? 10:56 < G> mmcgrath: the nice thing is, is that you can run the zabbix-server on more thanone server, and the web interface on totally different servers 10:57 < wakko666> yeah... with multiple nodes, you define checks per node. so you'd configure a particular host on noc2's zabbix node. 10:57 < G> yeah, thats what we really want 10:57 < mmcgrath> yep. 10:57 < G> actually #fedora-meeting is free, shall we have an impromptu there? 10:57 < wakko666> works for me. 10:58 < mmcgrath> G: sure -- Discussion moved to #fedora-meeting -- 10:58 -!- G changed the topic of #fedora-meeting to: sysadmin-noc - System Monitoring Needs 10:58 < mmcgrath> W00t 10:58 < G> ricky: dgilmore: jcollie: you folks around? 10:58 < mmcgrath> G: so I want zabbix to monitor when new versions of my packages are around, build them, and push them via bodhi when new versions are out :) 10:58 * mmcgrath runs 10:59 < wakko666> lol 10:59 < G> mmcgrath: haha :) 10:59 < ricky> G: pongish 10:59 < G> okay, so if you open your hym books to http://publictest3.fedoraproject.org/zabbix/overview.php we have a basic-ish setup atm 11:00 < wakko666> looks like the basic Linux Server template... 11:00 < G> wakko666: yeah :) 11:00 < G> wakko666: except I started moving some of the specific checks like apache into other templates and started linking them 11:00 < dgilmore> G: not really 11:01 < wakko666> G: that works. one suggestion: copy the default graphs for Zabbix Server into the Linux Server template so you get some default graphing for each host 11:01 < mmcgrath> G: any luck getting ahold of fchuili? 11:02 < G> argh, I meant to ping him back before 11:02 < G> dgilmore: no problem :) 11:02 < G> wakko666: ricky: you have accounts there now, irc nick/test 11:02 < mmcgrath> I'll drop him an email 11:03 < G> wakko666: they were in default settings iirc 11:03 < G> oh maybe not 11:03 < mmcgrath> G: you don't happen to know if we can plug this in to FAS do you? 11:03 * dgilmore will note he tried zabbix aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaannd founnnnnnnnnnnnnnnnnnnnd ituseleeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeess hard to configure and didnt work right 11:04 < G> wakko666: okay, done that now 11:04 * dgilmore wonders when ajax will gggget XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx fied:)pretty please 11:04 < G> mmcgrath: I don't think so, kinda like cacti in a way 11:04 < mmcgrath> dgilmore: thats so funny, G set this up in a matter of hours and have noproblems at all ;-) 11:05 < wakko666> i'm not sure about plugging the auth into FAS, but it's PHP so at the very least it should be hackable 11:05 < dgilmore> mmcgrath: monitoring localhost worked 11:05 < dgilmore> mmcgrath: but that was it 11:05 < G> http://publictest3.fedoraproject.org/zabbix/charts.php?period=86400&dec=0&inc=0&left=0&right=0&stime=yyyymmddhhmm&from=0&groupid=0&hostid=10017&graphid=5 11:05 < ricky> Worst case, we put it behind basic auth. 11:05 < mmcgrath> dgilmore: time for another look :) 11:05 < G> I like the stuff like that 11:05 < mmcgrath> ricky: yeah, thats what I was thinking 11:05 < dgilmore> mmcgrath: it was about 3 or 4 months ago i think 11:05 < G> dgilmore: I got 4 hosts monitored in no time, only trouble was iptables on the pt machines :) 11:06 < wakko666> one note: stacked graphs occasionally don't render quite right. sometimes zabbix leaves white space between data sets 11:06 < G> wakko666: yeah, but it still shows the trend quite nicely 11:06 < wakko666> G: agreed. 11:07 < wakko666> for the web servers, setting up app-specific web checks is great, and fairly easy to do 11:07 < G> hmmm whats on PT7, it takes a bit of beating 11:08 < G> http://publictest3.fedoraproject.org/zabbix/charts.php?period=43200&dec=0&inc=0&left=0&right=0&stime=yyyymmddhhmm&from=0&groupid=0&hostid=10026&graphid=31 11:08 < G> okay, so I think the first thing is: 11:08 < G> What are our requirements? 11:08 < ricky> pt7 looks fine to me 11:08 < G> I can easily add the following: 11:08 < ricky> Ah, it's back in the green now. 11:09 < G> -> Equal checking abilities to nagios (i.e. the type of checks) 11:09 < ricky> Could you walk us through the processes of adding a complex check? 11:09 < G> -> Ability to send out e-mails/pagers 11:09 < ricky> And also, is there any sort of equivalent screen to https://admin.fedoraproject.org/nagios/cgi-bin//status.cgi?host=all&servicestatustypes=28&hoststatustypes=15 in nagios? 11:09 < mmcgrath> and what is the difference between a "web" check and just your normal check? 11:09 < mmcgrath> how do we write custom plugins? 11:09 < mmcgrath> why is the sky blue? 11:09 < G> -> Ability to customise stuff 11:10 < ricky> (As little information as possible - a view with *just* what problems are going on) 11:10 < G> ricky: yes 11:10 < wakko666> mmcgrath: by 'web check' i mean, a semi-intelligent check of a web-app, where you can set up a series of steps for it to check through such as "hit koji.fp.org,click packages, click builds, etc" 11:10 < G> http://publictest3.fedoraproject.org/zabbix/tr_status.php?onlytrue=true&noactions=false&compact=false&select=false&txt_select=&sort=priority 11:10 < dgilmore> can i just edit a nice easy to read config file to do things? 11:11 < G> dgilmore: and break it while you try to work out why it broke 11:11 < wakko666> dgilmore: all config is done through the zabbix web gui 11:11 < G> errr 11:11 < G> and break it and spend ages working out why you broke it 11:11 < wakko666> ricky: the zabbix equivalent to that nagios screen is the Monitoring ->Overview screen, though under Screens, you can set up a customized view as well. 11:12 < dgilmore> wakko666: to me thats really bad 11:12 < G> wakko666: the triggers = true page is like that too 11:12 < G> (the link I pasted just before) 11:12 * dgilmore personally doesnt like configuring though a web gui. maybe why zabbix did not work out for me 11:12 < wakko666> dgilmore: it's a different paradigm. i don't equate different to bad. not having config files doesn't strike me as a flaw. 11:13 < abadger1999> wakko666: makes it harder to manage it via puppet. 11:14 < wakko666> abadger1999: yes and no. there are config files for the polling server daemon and the client-side agent. at $dayjob, i push the agent configs via puppet 11:14 < abadger1999> I guess abadger1999 was referring to things like configuration for specificchecks and things like that 11:15 < G> wakko666: custom checks are defined in the agent config right? 11:15 < wakko666> to me, the big thing with zabbix is that it's essential to back up the db, and export your configs on a regular basis. it's painful to spend hours setting zabbix up, and have your db get corrupted and have to do all that work all over again 11:16 < ricky> So the exciting question: What problems that we're seeing with nagios does zabbix solve? 11:16 < wakko666> G: custom checks can be one of two things. custom zabbix-agent checks,and zabbix server-side remote checks 11:16 < G> wakko666: oh thats extra nifyt 11:16 < ricky> One thing is combining cacti functionality - what else? 11:16 < G> *nifty 11:16 < G> ricky: distributed monitoring :) 11:17 < ricky> Can you elaborate a bit? :-) 11:17 < G> and has Brett pointed out before, complex checks 11:17 < wakko666> for me, zabbix does templates and rapid configuration of new hosts significantly better than nagios 11:17 < G> errr complex web checks 11:17 < G> yeah, the templating looks _REALLY_ good 11:18 < wakko666> zabbix also is more granular than both cacti and nagios. the default network traffic checks are done every 5 seconds 11:18 < mmcgrath> G: I take it it has similar workflow that nagios has? (not that we usedit?) 11:18 < G> build a profile of the typical application server apply the template to all theapp servers and your home free 11:18 < ricky> Do you have a link where I can see the templating coolness in action? 11:18 < mmcgrath> but outage happens, someone ack's it and starts working? 11:18 < G> mmcgrath: ack etc? yeah 11:18 < f13> darn, I have to leave, but I'm really interested in what platform wins out. Particularly interested in zenoss vs zabbix 11:18 < ricky> Because right now, I'm visualizing hostgroups in nagios 11:18 < wakko666> mmcgrath: yes. same basic workflow 11:19 < wakko666> f13: i vote zabbix over zenoss simply because zabbix doesn't use rpath 11:19 < ricky> f13: zenoss = zope :-( 11:19 < mmcgrath> wakko666: G: how hard is it to script outages? 11:19 < G> that'd be something brett would have to answer 11:20 < f13> wakko666: there is that. 11:20 < f13> ricky: good point. 11:20 < f13> zenoss had something going for it in that previous cacti/nagios stuff would work with it, or so was the claim 11:20 < wakko666> outages are the one thing about zabbix that is a bit unclear to me. i think the best analogue is to disable monitoring (a single drop-down box), or to acknowledgethe alert 11:21 * ricky still hasn't figured out where he can see templates 11:21 < wakko666> being that zabbix doesn't do repeated alerts, you'll only get a single "down" page anyway... 11:21 < mmcgrath> wakko666: as in its difficult to schedule an outage ahead of time? 11:21 < G> ricky: http://publictest3.fedoraproject.org/zabbix/hosts.php?groupid=0&config=2 11:21 < wakko666> ricky: Configuration > Items or Triggers. there's a Template drop-down 11:21 < ricky> Aha 11:22 < wakko666> mmcgrath: yeah, basically. as far as i've seen, zabbix doesn't yet havethe concept of scheduled outages. a service is either up or down, and not much beyond that 11:23 < wakko666> i suspect that may be on their todo list for the next version, though 11:23 < ricky> So where can I see the linkage between a template and the checks for that template? 11:23 < G> I don't think it's an exact issue 11:23 < G> ricky: Items 11:23 < jcollie> you could always shut down the zabbix server :) 11:24 < wakko666> ricky: the expression column will have the template name in it 11:24 < mmcgrath> I've only looked a little bit but... how well does service deps work? 11:24 < wakko666> ricky: err... not expression column... the name column. 11:24 < ricky> I think I got it 11:24 < wakko666> mmcgrath: dependencies are dead easy. 11:24 < G> mmcgrath: it'd appear you can add multiple dependences per trigger 11:25 < G> http://publictest3.fedoraproject.org/zabbix/triggers.php?form=update&triggerid=10043&hostid=10001 11:25 < wakko666> if you check apache on host A, but that check goes through router B, youadd a dependency on the apache check so that the check doesn't execute unless the checks for router B are passing. 11:28 < mmcgrath> So really 11:29 < mmcgrath> G: how about this... We give it a quick talk tomorrow at the meeting there. If there's no blockers or major opposition. We get it on noc1 and get to work? 11:29 < G> mmcgrath: so your happy with what I've done on pt3 so far? 11:30 < mmcgrath> Yeah so far. I'd like to see it monitoring a couple of things along side nagios, both sending notifications, and see how it does in production. 11:30 < mmcgrath> so not spending a ton of time on it, but monitoring a few critical bits that frequently have problems. 11:30 < G> in that case sure, except if we are putting into production, I guess we should grab Jeff's 0.4.6 update and put it in f-i until it appears in epel 11:31 < G> I'll be happy to lead that task 11:31 < G> wakko666: jcollie: you both in sysadmin-noc? 11:31 < mmcgrath> G: excellent. 11:31 < wakko666> G: applying now. :) 11:31 < G> I'll sponsor you :) 11:32 < wakko666> yay! :-) 11:32 < G> mmcgrath: I think we'll leave the internal authentication for now, I'll leave the main part readable by everyone, and add accounts for everyone in sysadmin-main/noc thatsactive 11:33 < G> wakko666: done 11:33 < mmcgrath> G: thats fine. 11:34 < G> okay, so adjourned until the inframeeting 2000UTC tomorrow :) 11:34 < ricky> How can I trigger a check? 11:34 < wakko666> ricky: turn off the service that it's checking. ;-) 11:34 < ricky> Oh. 11:35 < wakko666> you can also just flip the logic of the trigger. 11:35 -!- G changed the topic of #fedora-meeting to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule 11:36 < G> I'll post a log to the infra-list soon so people can have a read before the main meeting 11:37 < mmcgrath> G: good ide 11:37 < mmcgrath> a From rayvd at bludgeon.org Thu Jul 31 03:03:07 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 30 Jul 2008 20:03:07 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <48912A78.1040807@nigelj.com> References: <48912A78.1040807@nigelj.com> Message-ID: <20080731030307.GA32156@bludgeon.org> On Thu, Jul 31, 2008 at 02:59:04PM +1200, Nigel Jones wrote: > Okay, so while this was intended to be a primary discussion point for > tomorrows Infrastructure meeting we had a little bit of discussion first in > #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like > Nagios that I begun to setup for testing this week. Just curious, what are the technical reasons for choosing Zabbix over ZenOSS? Ray From mmcgrath at redhat.com Thu Jul 31 03:04:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 30 Jul 2008 22:04:31 -0500 (CDT) Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <20080731030307.GA32156@bludgeon.org> References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> Message-ID: On Wed, 30 Jul 2008, Ray Van Dolson wrote: > On Thu, Jul 31, 2008 at 02:59:04PM +1200, Nigel Jones wrote: > > Okay, so while this was intended to be a primary discussion point for > > tomorrows Infrastructure meeting we had a little bit of discussion first in > > #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like > > Nagios that I begun to setup for testing this week. > > Just curious, what are the technical reasons for choosing Zabbix over > ZenOSS? > I think some of us have developed an allergy to Zope after the whole plone thing. -Mike From wakko666 at gmail.com Thu Jul 31 03:18:15 2008 From: wakko666 at gmail.com (brett lentz) Date: Wed, 30 Jul 2008 20:18:15 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> Message-ID: Also, zenoss uses rpath, which makes maintaining it a huge pain. ---Brett. (Wakko666) On 7/30/08, Mike McGrath wrote: > On Wed, 30 Jul 2008, Ray Van Dolson wrote: > >> On Thu, Jul 31, 2008 at 02:59:04PM +1200, Nigel Jones wrote: >> > Okay, so while this was intended to be a primary discussion point for >> > tomorrows Infrastructure meeting we had a little bit of discussion first >> > in >> > #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like >> > Nagios that I begun to setup for testing this week. >> >> Just curious, what are the technical reasons for choosing Zabbix over >> ZenOSS? >> > > I think some of us have developed an allergy to Zope after the whole plone > thing. > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From Matt_Domsch at dell.com Thu Jul 31 03:57:19 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 30 Jul 2008 22:57:19 -0500 Subject: YUM security issues... In-Reply-To: <60e301c40807300842xf9a4176u8584707144228aee@mail.gmail.com> References: <20080725160710.GM20156@humbolt.us.dell.com> <9189.1217004375@devserv.devel.redhat.com> <20080725174402.GN20156@humbolt.us.dell.com> <12698.1217008346@devserv.devel.redhat.com> <20080725190616.GA2978@auslistsprd01.us.dell.com> <29888.1217034687@devserv.devel.redhat.com> <60e301c40807290935ve608497h530792b2f9d2dfaa@mail.gmail.com> <20080729190330.GF14119@humbolt.us.dell.com> <23827.1217419195@devserv.devel.redhat.com> <60e301c40807300842xf9a4176u8584707144228aee@mail.gmail.com> Message-ID: <20080731035719.GA24620@auslistsprd01.us.dell.com> On Wed, Jul 30, 2008 at 08:42:44AM -0700, Justin Cappos wrote: > You might also think about requiring the mirror's IP address to fall > in the subnet (or else they ask for your approval). This might > further complicate an attacker using this for evil. The challenge here is a) private servers often are on RFC1918 addresses, so they don't fall inside the public-visible netblock assignments. If it's a private server, MM doesn't even crawl it (they're likely unreachable anyhow), relying on them to run report_mirror. This also keeps our crawl times down to 4-6 hours, it only crawls the 50% of listed servers that are public. b) malicious sysadmins could change their DNS entry after getting the netblock set up by a Fedora sysadmin, so as to no longer be inside the netblock. I feel the window of opportunity here is small, and we're going to make changes to make it even smaller. Users can't install unsigned packages, the worst a malicious mirror can do is serve "stale" content for a period of time we'll be able to control (it may be ridiculously small, like "never" (which is easy to implement but a PITA for mirrors that sync only once a day), or up to 1 week (I haven't worked out how to do this cleanly, but it's nicer to users of mirrors who are good citizens) which is clearly what I want. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dlutter at redhat.com Thu Jul 31 04:26:39 2008 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 30 Jul 2008 21:26:39 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <48912A78.1040807@nigelj.com> References: <48912A78.1040807@nigelj.com> Message-ID: <1217478399.25288.156.camel@localhost.localdomain> On Thu, 2008-07-31 at 14:59 +1200, Nigel Jones wrote: > Okay, so while this was intended to be a primary discussion point for > tomorrows Infrastructure meeting we had a little bit of discussion first > in #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool > like Nagios that I begun to setup for testing this week. There was an interesting talk at OLS comparing Nagios, Zabbix, Zenoss, and Hyperic[1] - the upshot was that none of them is a clear frontrunner (how's that for being helpful ?) David [1] http://www.krisbuytaert.be/presentations/MonitoringShootOut.odp From dev at nigelj.com Thu Jul 31 04:37:27 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 31 Jul 2008 16:37:27 +1200 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <1217478399.25288.156.camel@localhost.localdomain> References: <48912A78.1040807@nigelj.com> <1217478399.25288.156.camel@localhost.localdomain> Message-ID: <48914187.6060608@nigelj.com> David Lutterkort wrote: > On Thu, 2008-07-31 at 14:59 +1200, Nigel Jones wrote: > >> Okay, so while this was intended to be a primary discussion point for >> tomorrows Infrastructure meeting we had a little bit of discussion first >> in #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool >> like Nagios that I begun to setup for testing this week. >> > > There was an interesting talk at OLS comparing Nagios, Zabbix, Zenoss, > and Hyperic[1] - the upshot was that none of them is a clear frontrunner > (how's that for being helpful ?) > > David > > [1] http://www.krisbuytaert.be/presentations/MonitoringShootOut.odp > That covered a lot of the exact same things that I'd been thinking (especially in terms of pros/cons etc). Looking ahead 1.6 does seem to add a large number of the missing links, and it's due out in September, so plenty of time for us to start getting configs perfect etc :) - Nigel From robk at ningaui.net Thu Jul 31 04:51:38 2008 From: robk at ningaui.net (Rob K) Date: Thu, 31 Jul 2008 14:51:38 +1000 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <48914187.6060608@nigelj.com> References: <48912A78.1040807@nigelj.com> <1217478399.25288.156.camel@localhost.localdomain> <48914187.6060608@nigelj.com> Message-ID: <352bdb60807302151r17b39b7cv54b739c472830447@mail.gmail.com> Where could OpenNMS fit into this? They've been pretty friendly to us, and it's a solid bit of gear. -- Rob K http://ningaui.net I swear, if I collected all seven dragonballs, I'd bring back Jon Postel. - Raph From rayvd at bludgeon.org Thu Jul 31 06:22:41 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 30 Jul 2008 23:22:41 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <352bdb60807302151r17b39b7cv54b739c472830447@mail.gmail.com> References: <48912A78.1040807@nigelj.com> <1217478399.25288.156.camel@localhost.localdomain> <48914187.6060608@nigelj.com> <352bdb60807302151r17b39b7cv54b739c472830447@mail.gmail.com> Message-ID: <20080731062241.GA2100@bludgeon.org> On Thu, Jul 31, 2008 at 02:51:38PM +1000, Rob K wrote: > Where could OpenNMS fit into this? They've been pretty friendly to us, > and it's a solid bit of gear. OpenNMS is rock solid, but it's Tomcat/Java powered... would it run well with OpenJDK? Is Fedora open to using Sun's JDK? Also, although it's gotten a lot better (more configuration done via the UI), the XML based config files are seriously annoying. :) Ray From dev at nigelj.com Thu Jul 31 06:23:27 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 31 Jul 2008 18:23:27 +1200 Subject: Outage Notification - 2008-07-31 03:30 UTC to 2008-07-31 06:20 UTC Message-ID: <48915A5F.2020306@nigelj.com> An unplanned outage occurred as of approximately 2008-07-31 03:30 UTC and is mostly resolved as of 2008-07-31 06:20 UTC Affected Services where: - Websites - Package DB, Mirror Manager Admin Interface, Bodhi, Translate - Account System (FAS) - Any other authenticated requests - Buildsystem Partial Outages: - Hosted (Trac authentication) - Wiki (Read Only, some pages may appear broken as well) Unaffected Services: - CVS / Source Control - Database - DNS - Mail - Torrent - Fedora Talk Reason for Outage: Our main filer took a turn for the worst, and took down one of our main database servers and other associated infrastructure. We have now for the most part resolved the issue, and diagnostic work has begun, we apologise for any inconvenience. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. Regards, Nigel Jones From wakko666 at gmail.com Thu Jul 31 07:01:26 2008 From: wakko666 at gmail.com (brett lentz) Date: Thu, 31 Jul 2008 00:01:26 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <20080731062241.GA2100@bludgeon.org> References: <48912A78.1040807@nigelj.com> <1217478399.25288.156.camel@localhost.localdomain> <48914187.6060608@nigelj.com> <352bdb60807302151r17b39b7cv54b739c472830447@mail.gmail.com> <20080731062241.GA2100@bludgeon.org> Message-ID: -1 to XML config files. ---Brett (wakko666) On 7/30/08, Ray Van Dolson wrote: > On Thu, Jul 31, 2008 at 02:51:38PM +1000, Rob K wrote: >> Where could OpenNMS fit into this? They've been pretty friendly to us, >> and it's a solid bit of gear. > > OpenNMS is rock solid, but it's Tomcat/Java powered... would it run > well with OpenJDK? Is Fedora open to using Sun's JDK? Also, although > it's gotten a lot better (more configuration done via the UI), the XML > based config files are seriously annoying. :) > > Ray > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From robk at ningaui.net Thu Jul 31 07:43:32 2008 From: robk at ningaui.net (Rob K) Date: Thu, 31 Jul 2008 17:43:32 +1000 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <20080731062241.GA2100@bludgeon.org> References: <48912A78.1040807@nigelj.com> <1217478399.25288.156.camel@localhost.localdomain> <48914187.6060608@nigelj.com> <352bdb60807302151r17b39b7cv54b739c472830447@mail.gmail.com> <20080731062241.GA2100@bludgeon.org> Message-ID: <352bdb60807310043m7ec24195j7a290fb88debf7bf@mail.gmail.com> On Thu, Jul 31, 2008 at 4:22 PM, Ray Van Dolson wrote: > On Thu, Jul 31, 2008 at 02:51:38PM +1000, Rob K wrote: >> Where could OpenNMS fit into this? They've been pretty friendly to us, >> and it's a solid bit of gear. > OpenNMS is rock solid, but it's Tomcat/Java powered... would it run > well with OpenJDK? Is Fedora open to using Sun's JDK? Also, although > it's gotten a lot better (more configuration done via the UI), the XML > based config files are seriously annoying. :) It should work Just fine - it'd be seriously better than any of the PHP driven horrors I've dealt with, and Java is officially a Good Guy. XML config files, meh. At least they can be programattically created and maintained by puppet etc. I work with XML from beyond Euclidean space every day and I remain sane-ish. Dealing with huge BIND rigs has taken the shine off apparently 'readable' non-XML config files. It's certainly worth a try, and as I say, the OpenNMS guys have shown willing to throw their hat into the fray. > Ray -- Rob K http://ningaui.net I swear, if I collected all seven dragonballs, I'd bring back Jon Postel. - Raph From john.e.anderson at gmail.com Thu Jul 31 14:38:00 2008 From: john.e.anderson at gmail.com (John Anderson) Date: Thu, 31 Jul 2008 09:38:00 -0500 Subject: Intro Message-ID: <1217515080.5403.20.camel@pyrotechnix.eragen.com> Hello all, I'd like to introduce myself to the list and I'd be very interested in helping out some. My name is John Anderson, and I am the network admin at a small biotech in Wisconsin. We're primarily a CentOS shop in the server room, with a few OpenBSD boxes, and Fedora on the workstations. I migrated our Nagios to Zenoss last year, and currently maintain our Zenoss monitoring. I see that could be a current project for you, and I'd be very interested in that. Other things I've done or are familiar with: * Very familiar with cluster suite, I've built quite a few HA clusters on it in the last year, mostly apache, mysql and tomcat * Installed spacewalk here, using that to manage our Centos updates * I manage our Zimbra mail server, pretty familiar with postfix and sendmail * I've done some xen, some esx * lots of mysql, a very small bit of oracle * I can script well in PHP, Python, some perl I've also been trying to do a little packaging as well. I'm currently mcgarnicle on freenode, I'm hoping to lurk in your meeting today. Anyhow thanks for listening and I'd love to give a hand somewhere. John From mmcgrath at redhat.com Thu Jul 31 14:47:14 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 31 Jul 2008 09:47:14 -0500 (CDT) Subject: Intro In-Reply-To: <1217515080.5403.20.camel@pyrotechnix.eragen.com> References: <1217515080.5403.20.camel@pyrotechnix.eragen.com> Message-ID: On Thu, 31 Jul 2008, John Anderson wrote: > > I've also been trying to do a little packaging as well. > > I'm currently mcgarnicle on freenode, I'm hoping to lurk in your meeting > today. > heh, welcome mcgarnicle. Do you happen to have much experience with heartbeat? -Mike From john.e.anderson at gmail.com Thu Jul 31 14:54:51 2008 From: john.e.anderson at gmail.com (John Anderson) Date: Thu, 31 Jul 2008 09:54:51 -0500 Subject: Intro In-Reply-To: References: <1217515080.5403.20.camel@pyrotechnix.eragen.com> Message-ID: <1217516091.5403.25.camel@pyrotechnix.eragen.com> On Thu, 2008-07-31 at 09:47 -0500, Mike McGrath wrote: > On Thu, 31 Jul 2008, John Anderson wrote: > > > > I've also been trying to do a little packaging as well. > > > > I'm currently mcgarnicle on freenode, I'm hoping to lurk in your meeting > > today. > > > > heh, welcome mcgarnicle. Do you happen to have much experience with > heartbeat? > > -Mike I've done apache and tomcat HA using heartbeat with the old style config a little while back. I haven't used the newer XML one yet. John From poelstra at redhat.com Thu Jul 31 14:56:47 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 31 Jul 2008 07:56:47 -0700 Subject: [Fwd: bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage | August 2nd, 2008 - 9:00 AM EST - 7:00 PM EST] Message-ID: <4891D2AF.90909@redhat.com> Reminder: This Weekend -------- Original Message -------- Subject: bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage | August 2nd, 2008 - 9:00 AM EST - 7:00 PM EST Date: Tue, 29 Jul 2008 00:05:42 -0400 From: Dave Lawrence O U T A G E R E Q U E S T F O R M ===================================== Severity: Severity Two (High) Scheduled Date: August 2nd, 2008 Scheduled Time: 9:00 AM EST - 7:00 PM EST Estimated Time Required: 10 hours Performed By: Red Hat Engineering Operations People/Groups Impacted: Users of bugzilla.redhat.com and any services that rely on bugzilla.redhat.com Site/Services Affected: bugzilla.redhat.com Web UI, Database, XMLRPC Impact: bugzilla.redhat.com will be unavailable during the posted time on August 2nd, 2008. Description: On August 2nd, bugzilla.redhat.com will go down for an update to the latest upstream code base. During this time the web servers will be reinstalled with the latest OS updates as well as the latest Bugzilla code. Also the database servers will undergo a data migration to be made compatible with the latest Bugzilla code. The web UI, database, and all XMLRPC services will be unavailable during the migration. Services that rely on bugzilla.redhat.com may not function properly during this time so please let your users know about the outage as well. Also please take time to point your services/scripts at our test server https://partner-bugzilla.redhat.com to make sure that they will still work with the new system once it goes live. Care has been taken to make the new system backwards compatible as much as possible with the old XMLRPC API but still confirm that they work properly. If you encounter any problems, please contact bugzilla-owner redhat com or file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=3.2 Signoff: kbaker redhat com From mmcgrath at redhat.com Thu Jul 31 18:01:07 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 31 Jul 2008 13:01:07 -0500 (CDT) Subject: Asterisk and Trac upgrades Message-ID: Asterisk and Trac have both been upgraded today, please keep let us know if anything strange goes on. -Mike From mmcgrath at redhat.com Thu Jul 31 21:16:16 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 31 Jul 2008 16:16:16 -0500 (CDT) Subject: Meeting this week Message-ID: An embedded and charset-unspecified text was scrubbed... Name: meeting.07-31-08.txt URL: