From sundaram at fedoraproject.org Fri Aug 1 02:33:25 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Aug 2008 08:03:25 +0530 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: <489275F5.5010603@fedoraproject.org> 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? Yes. Refer http://blogs.opennms.org/?p=222 http://blogs.opennms.org/?p=223 Rahul From jonathansteffan at gmail.com Fri Aug 1 03:21:29 2008 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 31 Jul 2008 21:21:29 -0600 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <48912A78.1040807@nigelj.com> References: <48912A78.1040807@nigelj.com> Message-ID: <48928139.5020902@gmail.com> 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. I would recommend looking at ZenOSS. We tested Zabbix for a while at $dayjob and ended up using ZenOSS. -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From jonathansteffan at gmail.com Fri Aug 1 03:22:58 2008 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Thu, 31 Jul 2008 21:22:58 -0600 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> Message-ID: <48928192.2020900@gmail.com> brett lentz wrote: > Also, zenoss uses rpath, which makes maintaining it a huge pain. Just their appliance does. We are using ZenOSS on RHEL (well, CentOS) 5.2. -- Jonathan Steffan daMaestro GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 From mmcgrath at redhat.com Fri Aug 1 03:35:13 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 31 Jul 2008 22:35:13 -0500 (CDT) Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <48928139.5020902@gmail.com> References: <48912A78.1040807@nigelj.com> <48928139.5020902@gmail.com> Message-ID: On Thu, 31 Jul 2008, Jonathan Steffan wrote: > 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. > > I would recommend looking at ZenOSS. We tested Zabbix for a while at > $dayjob and ended up using ZenOSS. > ETA when it will be in Fedora? -Mike From michael.yingbull at gmail.com Fri Aug 1 04:48:14 2008 From: michael.yingbull at gmail.com (Michael Yingbull) Date: Thu, 31 Jul 2008 22:48:14 -0600 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <48928192.2020900@gmail.com> References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> Message-ID: <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> We're running it on a regular RHEL machine as well at $dayjob. We've not seen those problems. On Thu, Jul 31, 2008 at 9:22 PM, Jonathan Steffan wrote: > brett lentz wrote: > > Also, zenoss uses rpath, which makes maintaining it a huge pain. > > Just their appliance does. We are using ZenOSS on RHEL (well, CentOS) 5.2. > > -- > Jonathan Steffan > daMaestro > GPG Fingerprint: 93A2 3E2F DC26 5570 3472 5B16 AD12 6CE7 0D86 AF59 > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.e.anderson at gmail.com Fri Aug 1 11:59:04 2008 From: john.e.anderson at gmail.com (John Anderson) Date: Fri, 01 Aug 2008 06:59:04 -0500 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> Message-ID: <1217591944.5403.63.camel@pyrotechnix.eragen.com> On Thu, 2008-07-31 at 22:48 -0600, Michael Yingbull wrote: > We're running it on a regular RHEL machine as well at $dayjob. We've > not seen those problems. Also using Zenoss on Centos 5.2 for monitoring here at $dayjob. I've been keeping it on the current version using their "native" RPM for a year, no issues. Zope is a little bit of a PITA, we just run apache in front of it. I looked at quite a few free monitoring solutions about a year ago, and Zenoss really seemed the most feature full, and definitely best UI. They seem to be developing faster than any of the others as well. The docs are a little rough, but if you have a basic understanding of SNMP it doesn't take that much to figure out. Anyhow, it might be worth your time to try several before committing. > 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 ?) > Zabbix certainly didn't seem very popular at the end vote there. From mmcgrath at redhat.com Fri Aug 1 13:27:39 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 1 Aug 2008 08:27:39 -0500 (CDT) Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <1217591944.5403.63.camel@pyrotechnix.eragen.com> References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> <1217591944.5403.63.camel@pyrotechnix.eragen.com> Message-ID: On Fri, 1 Aug 2008, John Anderson wrote: > On Thu, 2008-07-31 at 22:48 -0600, Michael Yingbull wrote: > > We're running it on a regular RHEL machine as well at $dayjob. We've > > not seen those problems. > > Also using Zenoss on Centos 5.2 for monitoring here at $dayjob. I've > been keeping it on the current version using their "native" RPM for a > year, no issues. > > Zope is a little bit of a PITA, we just run apache in front of it. > > I looked at quite a few free monitoring solutions about a year ago, and > Zenoss really seemed the most feature full, and definitely best UI. They > seem to be developing faster than any of the others as well. > > The docs are a little rough, but if you have a basic understanding of > SNMP it doesn't take that much to figure out. > > Anyhow, it might be worth your time to try several before committing. > Anyone know when zenoss will be in Fedora? It is a requisite of ours. Even an estimate? -Mike From sundaram at fedoraproject.org Fri Aug 1 13:33:52 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 01 Aug 2008 19:03:52 +0530 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> <1217591944.5403.63.camel@pyrotechnix.eragen.com> Message-ID: <489310C0.6070603@fedoraproject.org> Mike McGrath wrote: > > Anyone know when zenoss will be in Fedora? It is a requisite of ours. > Even an estimate? Doesn't look like it is going to be soon looking at https://bugzilla.redhat.com/show_bug.cgi?id=435470 Rahul From rayvd at bludgeon.org Fri Aug 1 17:28:11 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 1 Aug 2008 10:28:11 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <489310C0.6070603@fedoraproject.org> References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> <1217591944.5403.63.camel@pyrotechnix.eragen.com> <489310C0.6070603@fedoraproject.org> Message-ID: <20080801172811.GA30198@bludgeon.org> On Fri, Aug 01, 2008 at 07:03:52PM +0530, Rahul Sundaram wrote: > Mike McGrath wrote: > >> >> Anyone know when zenoss will be in Fedora? It is a requisite of ours. >> Even an estimate? > > Doesn't look like it is going to be soon looking at > > https://bugzilla.redhat.com/show_bug.cgi?id=435470 > > Rahul If it got a little attention and TLC it might move along quicker. :) Also using ZenOSS at work. Also have used OpenNMS. I do like both. I'm a little more familiar with RRD vs however Zabbix does graphs (which really might be simpler than RRD in reality). Ray From mmcgrath at redhat.com Fri Aug 1 17:45:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 1 Aug 2008 12:45:09 -0500 (CDT) Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <20080801172811.GA30198@bludgeon.org> References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> <1217591944.5403.63.camel@pyrotechnix.eragen.com> <489310C0.6070603@fedoraproject.org> <20080801172811.GA30198@bludgeon.org> Message-ID: On Fri, 1 Aug 2008, Ray Van Dolson wrote: > On Fri, Aug 01, 2008 at 07:03:52PM +0530, Rahul Sundaram wrote: > > Mike McGrath wrote: > > > >> > >> Anyone know when zenoss will be in Fedora? It is a requisite of ours. > >> Even an estimate? > > > > Doesn't look like it is going to be soon looking at > > > > https://bugzilla.redhat.com/show_bug.cgi?id=435470 > > > > Rahul > > If it got a little attention and TLC it might move along quicker. :) > > Also using ZenOSS at work. Also have used OpenNMS. I do like both. > I'm a little more familiar with RRD vs however Zabbix does graphs > (which really might be simpler than RRD in reality). > I wouldn't say simpler, just different. Zabbix stores them raw in a database so they can, for example, easily be imported into a spreadsheet. http://tinyurl.com/6agtch -Mike From skvidal at fedoraproject.org Fri Aug 1 18:30:24 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 01 Aug 2008 14:30:24 -0400 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: References: <48912A78.1040807@nigelj.com> <20080731030307.GA32156@bludgeon.org> <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> <1217591944.5403.63.camel@pyrotechnix.eragen.com> <489310C0.6070603@fedoraproject.org> <20080801172811.GA30198@bludgeon.org> Message-ID: <1217615424.3505.10.camel@rosebud> On Fri, 2008-08-01 at 12:45 -0500, Mike McGrath wrote: > On Fri, 1 Aug 2008, Ray Van Dolson wrote: > > > On Fri, Aug 01, 2008 at 07:03:52PM +0530, Rahul Sundaram wrote: > > > Mike McGrath wrote: > > > > > >> > > >> Anyone know when zenoss will be in Fedora? It is a requisite of ours. > > >> Even an estimate? > > > > > > Doesn't look like it is going to be soon looking at > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=435470 > > > > > > Rahul > > > > If it got a little attention and TLC it might move along quicker. :) > > > > Also using ZenOSS at work. Also have used OpenNMS. I do like both. > > I'm a little more familiar with RRD vs however Zabbix does graphs > > (which really might be simpler than RRD in reality). > > > > I wouldn't say simpler, just different. Zabbix stores them raw in a > database so they can, for example, easily be imported into a spreadsheet. > > http://tinyurl.com/6agtch which, imo, is simpler, b/c rrd's mechanism is downright frustrating to parse in anything other than rrd. -sv -- I only speak for me. From rayvd at bludgeon.org Fri Aug 1 20:23:14 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 1 Aug 2008 13:23:14 -0700 Subject: Server Monitoring - A replacement for Nagios? In-Reply-To: <1217615424.3505.10.camel@rosebud> References: <48928192.2020900@gmail.com> <8c0317740807312148g24a072c3y32f71d2ba6323361@mail.gmail.com> <1217591944.5403.63.camel@pyrotechnix.eragen.com> <489310C0.6070603@fedoraproject.org> <20080801172811.GA30198@bludgeon.org> <1217615424.3505.10.camel@rosebud> Message-ID: <20080801202314.GA345@bludgeon.org> On Fri, Aug 01, 2008 at 02:30:24PM -0400, seth vidal wrote: > On Fri, 2008-08-01 at 12:45 -0500, Mike McGrath wrote: > > On Fri, 1 Aug 2008, Ray Van Dolson wrote: > > > > > On Fri, Aug 01, 2008 at 07:03:52PM +0530, Rahul Sundaram wrote: > > > > Mike McGrath wrote: > > > > > > > >> > > > >> Anyone know when zenoss will be in Fedora? It is a requisite of ours. > > > >> Even an estimate? > > > > > > > > Doesn't look like it is going to be soon looking at > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=435470 > > > > > > > > Rahul > > > > > > If it got a little attention and TLC it might move along quicker. :) > > > > > > Also using ZenOSS at work. Also have used OpenNMS. I do like both. > > > I'm a little more familiar with RRD vs however Zabbix does graphs > > > (which really might be simpler than RRD in reality). > > > > > > > I wouldn't say simpler, just different. Zabbix stores them raw in a > > database so they can, for example, easily be imported into a spreadsheet. > > > > http://tinyurl.com/6agtch > > which, imo, is simpler, b/c rrd's mechanism is downright frustrating to > parse in anything other than rrd. > Exactly... although it is certainly possible to do the same things with RRD (including generating an RRD with historical data), it's definitely not as straightforward as the database method... and rrd files also tend to be unwieldy and inefficient to write updates to when you start scaling real high. I know OpenNMS has worked around this by writing their own queuing system for rrd writes and using their own rrd format in a way I believe. I guess from the looks of the state of ZenOSS it's off the table (unless you want to use it on a RHEL machine and could maybe get it via RHX -- would that fit into the philosophy here?) and maybe Zabbix or OpenNMS are the only other realistic alternatives. Of course, OpenNMS isn't packaged for Fedora yet either is it? They do have RPM's however and a yum repo so it might not be a lot of work to get it done. Ray From ricky at fedoraproject.org Mon Aug 4 06:31:19 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 4 Aug 2008 02:31:19 -0400 Subject: serverbeach2 and serverbeach3 reboot Message-ID: <20080804063119.GA4126@Max> serverbeach2 (asterisk1, collab1, ns1) and serverbeach3 (asterisk2, collab2) mysteriously rebooted ~30 minutes ago. Could it have been a power problem of some sort? There were no useful entries in /var/log/messages or anything. If we don't find any leads about this tomorrow, could it be something worth asking ServerBeach about? 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 kwade at redhat.com Mon Aug 4 08:57:51 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Mon, 04 Aug 2008 01:57:51 -0700 Subject: static F10 Alpha relnotes page Message-ID: <1217840271.13450.224.camel@calliope.phig.org> Do we want to turn this page static for the Alpha release? https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes I put out the last call for changes and am making a few myself. Is there a good target for calling to static for now? We'll want to make sure we can edit it. Perhaps as part of making it static we can tell people to post changes to the talk page, then we'll do irregular updates of the static content? Thanks - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Mon Aug 4 12:17:50 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 04 Aug 2008 08:17:50 -0400 Subject: serverbeach2 and serverbeach3 reboot In-Reply-To: <20080804063119.GA4126@Max> References: <20080804063119.GA4126@Max> Message-ID: <1217852270.25781.26.camel@rosebud> On Mon, 2008-08-04 at 02:31 -0400, Ricky Zhou wrote: > serverbeach2 (asterisk1, collab1, ns1) and serverbeach3 (asterisk2, > collab2) mysteriously rebooted ~30 minutes ago. Could it have been a > power problem of some sort? There were no useful entries in > /var/log/messages or anything. If we don't find any leads about this > tomorrow, could it be something worth asking ServerBeach about? > yes, it is something worth inquiring about. also - it looks like something on the systems was not running properly b/c they all had a lot of unsendable mail. hence all the undelivered mail notices. -sv -- I only speak for me. From dev at nigelj.com Mon Aug 4 12:57:54 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 05 Aug 2008 00:57:54 +1200 Subject: static F10 Alpha relnotes page In-Reply-To: <1217840271.13450.224.camel@calliope.phig.org> References: <1217840271.13450.224.camel@calliope.phig.org> Message-ID: <1217854674.6219.9.camel@localhost.localdomain> On Mon, 2008-08-04 at 01:57 -0700, Karsten 'quaid' Wade wrote: > Do we want to turn this page static for the Alpha release? > > https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes > > I put out the last call for changes and am making a few myself. Is > there a good target for calling to static for now? To be perfectly honest, I'm not sure we need to worry about it until the actual release (even them I'm not sure we'll need to). The wiki's internal caching and mod_cache seem to be useful enough together (yet a pain for some other things) that for anonymous users it'll be cached anyway. We now have 3 machines handling wiki data, and it is from a fairly powerful DB, so where the caching doesn't help the backend should be able to pull the weight. > > We'll want to make sure we can edit it. Perhaps as part of making it > static we can tell people to post changes to the talk page, then we'll > do irregular updates of the static content? When making changes to the page, you'd need to go to https://fedoraproject.org/w/index.php?title=Releases/10/Alpha/ReleaseNotes&action=purge (I'm 99% sure that this will work for all users). Basically it'll wipe the MW cache etc and display the fresh copy. I think this would be a rather interesting experiment and I am sure that Mediawiki will pass with flying colours :). And well, if it does turn out we need to use static pages, then it's not that hard to do :). - Nigel From ricky at fedoraproject.org Mon Aug 4 18:27:10 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 4 Aug 2008 14:27:10 -0400 Subject: serverbeach2 and serverbeach3 reboot In-Reply-To: <1217852270.25781.26.camel@rosebud> References: <20080804063119.GA4126@Max> <1217852270.25781.26.camel@rosebud> Message-ID: <20080804182710.GA11496@Max> On 2008-08-04 08:17:50 AM, seth vidal wrote: > yes, it is something worth inquiring about. > > also - it looks like something on the systems was not running properly > b/c they all had a lot of unsendable mail. > > hence all the undelivered mail notices. There was another problem that maybe have been related to undelivered mail - apparently, since January 19th, there has been a FAS account registered with the username "root" (I guess FAS1 didn't block this one). The account name was just changed to something else yesterday :-/ 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 Mon Aug 4 18:28:56 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 4 Aug 2008 14:28:56 -0400 Subject: static F10 Alpha relnotes page In-Reply-To: <1217854674.6219.9.camel@localhost.localdomain> References: <1217840271.13450.224.camel@calliope.phig.org> <1217854674.6219.9.camel@localhost.localdomain> Message-ID: <20080804182856.GB11496@Max> On 2008-08-05 12:57:54 AM, Nigel Jones wrote: > I think this would be a rather interesting experiment and I am sure that > Mediawiki will pass with flying colours :). And well, if it does turn > out we need to use static pages, then it's not that hard to do :). +1 - I think mod_rewriting to static pages should be a thing of the past :-) 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 skvidal at fedoraproject.org Mon Aug 4 18:27:19 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 04 Aug 2008 14:27:19 -0400 Subject: serverbeach2 and serverbeach3 reboot In-Reply-To: <20080804182710.GA11496@Max> References: <20080804063119.GA4126@Max> <1217852270.25781.26.camel@rosebud> <20080804182710.GA11496@Max> Message-ID: <1217874439.25781.50.camel@rosebud> On Mon, 2008-08-04 at 14:27 -0400, Ricky Zhou wrote: > On 2008-08-04 08:17:50 AM, seth vidal wrote: > > yes, it is something worth inquiring about. > > > > also - it looks like something on the systems was not running properly > > b/c they all had a lot of unsendable mail. > > > > hence all the undelivered mail notices. > There was another problem that maybe have been related to undelivered > mail - apparently, since January 19th, there has been a FAS account > registered with the username "root" (I guess FAS1 didn't block this > one). The account name was just changed to something else yesterday > :-/ /me shudders root? seriously? Let's go ahead and validate all the other names we don't like the idea of: 1. pretty much any daemon username in any pkg in fedora 2. all numerics 3. all of the base system usernames -sv -- I only speak for me. From ricky at fedoraproject.org Mon Aug 4 18:40:27 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 4 Aug 2008 14:40:27 -0400 Subject: serverbeach2 and serverbeach3 reboot In-Reply-To: <1217874439.25781.50.camel@rosebud> References: <20080804063119.GA4126@Max> <1217852270.25781.26.camel@rosebud> <20080804182710.GA11496@Max> <1217874439.25781.50.camel@rosebud> Message-ID: <20080804184027.GC11496@Max> On 2008-08-04 02:27:19 PM, seth vidal wrote: > /me shudders > root? seriously? Let's go ahead and validate all the other names we > don't like the idea of: > > 1. pretty much any daemon username in any pkg in fedora > 2. all numerics > 3. all of the base system usernames The current blacklist is in configs/web/applications/fas-prod.cfg.erb, but we'll want to check current names as well. On the next FAS release, it's being changed from a regex to a comma-separated list of strings. The only other restriction on usernames is that they must be lowercase alphanumeric, and must start with a letter. 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 Aug 6 02:21:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 5 Aug 2008 21:21:18 -0500 (CDT) Subject: static F10 Alpha relnotes page In-Reply-To: <1217854674.6219.9.camel@localhost.localdomain> References: <1217840271.13450.224.camel@calliope.phig.org> <1217854674.6219.9.camel@localhost.localdomain> Message-ID: On Tue, 5 Aug 2008, Nigel Jones wrote: > Basically it'll wipe the MW cache etc and display the fresh copy. > > I think this would be a rather interesting experiment and I am sure that > Mediawiki will pass with flying colours :). And well, if it does turn > out we need to use static pages, then it's not that hard to do :). > I'd also prefer not to do anything unless we see something fail. During the actual release it might be good to turn some pages static but not actually use them. Then its just a config push away from going live in case the wiki does fail. AFAIK the wiki has no performance issues when people are not logged in (this includes most people during release day) and as far as when people are logged in its due to how we're doing session management. Ricky's currently looking into one alternative and there's others to look at if it fails for whatever reason. -Mike From dev at nigelj.com Wed Aug 6 08:37:31 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 06 Aug 2008 20:37:31 +1200 Subject: fedorahosted git repo too large In-Reply-To: <20080806034418.GR5655@inocybe.teonanacatl.org> References: <76e72f800808052030y632d8756r4e4b37199ec498c0@mail.gmail.com> <20080806034418.GR5655@inocybe.teonanacatl.org> Message-ID: <1218011851.31379.26.camel@localhost.localdomain> On Tue, 2008-08-05 at 23:44 -0400, Todd Zullinger wrote: > Yuan Yijun wrote: > > I just tried to download revisor git with this command "git pull > > http://git.fedorahosted.org/git/revisor master". I have to repeat > > 4-5 times since it breaks during downloading. The .git folder is > > about 58MB. After "git gc --aggressive" it becomes only 6MB. > > > > Anyone please run gc on server? > > Perhaps better would be repack. There was a recent thread on the git > list and one of the developers pointed out an older mail from Linus > where he described gc --aggressive as "mostly dumb" and recommended > that using something like "repack -a -d -f --depth=250 --window=250" > instead. > > http://article.gmane.org/gmane.comp.gcc.devel/94613 That's actually a very useful article and the methods/reasons behind it sound quite sane and it could be a useful approach for us. I'll try this out on one of the smaller repos (a copy of course) and see what happens. (n.b. I've added f-infrastructure-list to CC's, that's where everyone that manages the hosted server reads :).) - Nigel > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From kanarip at kanarip.com Wed Aug 6 09:23:42 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 06 Aug 2008 11:23:42 +0200 Subject: fedorahosted git repo too large In-Reply-To: <1218011851.31379.26.camel@localhost.localdomain> References: <76e72f800808052030y632d8756r4e4b37199ec498c0@mail.gmail.com> <20080806034418.GR5655@inocybe.teonanacatl.org> <1218011851.31379.26.camel@localhost.localdomain> Message-ID: <48996D9E.9030507@kanarip.com> Nigel Jones wrote: > On Tue, 2008-08-05 at 23:44 -0400, Todd Zullinger wrote: >> Yuan Yijun wrote: >>> I just tried to download revisor git with this command "git pull >>> http://git.fedorahosted.org/git/revisor master". I have to repeat >>> 4-5 times since it breaks during downloading. The .git folder is >>> about 58MB. After "git gc --aggressive" it becomes only 6MB. >>> >>> Anyone please run gc on server? >> Perhaps better would be repack. There was a recent thread on the git >> list and one of the developers pointed out an older mail from Linus >> where he described gc --aggressive as "mostly dumb" and recommended >> that using something like "repack -a -d -f --depth=250 --window=250" >> instead. >> >> http://article.gmane.org/gmane.comp.gcc.devel/94613 > That's actually a very useful article and the methods/reasons behind it > sound quite sane and it could be a useful approach for us. > > I'll try this out on one of the smaller repos (a copy of course) and see > what happens. > We've ended up doing this live as well and I'm happy with the few stabs I took at seeing if everything still works. Feel free to make this a regular thing on the revisor repo and I'll report if anything breaks, so that if it doesn't, this could maybe become a regular thing to do on all repos? Kind regards, Jeroen van Meeuwen -kanarip From dev at nigelj.com Wed Aug 6 10:53:32 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 06 Aug 2008 22:53:32 +1200 Subject: fedorahosted git repo too large In-Reply-To: <48996D9E.9030507@kanarip.com> References: <76e72f800808052030y632d8756r4e4b37199ec498c0@mail.gmail.com> <20080806034418.GR5655@inocybe.teonanacatl.org> <1218011851.31379.26.camel@localhost.localdomain> <48996D9E.9030507@kanarip.com> Message-ID: <1218020012.31379.49.camel@localhost.localdomain> On Wed, 2008-08-06 at 11:23 +0200, Jeroen van Meeuwen wrote: > Nigel Jones wrote: > > On Tue, 2008-08-05 at 23:44 -0400, Todd Zullinger wrote: > >> Yuan Yijun wrote: > >>> I just tried to download revisor git with this command "git pull > >>> http://git.fedorahosted.org/git/revisor master". I have to repeat > >>> 4-5 times since it breaks during downloading. The .git folder is > >>> about 58MB. After "git gc --aggressive" it becomes only 6MB. > >>> > >>> Anyone please run gc on server? > >> Perhaps better would be repack. There was a recent thread on the git > >> list and one of the developers pointed out an older mail from Linus > >> where he described gc --aggressive as "mostly dumb" and recommended > >> that using something like "repack -a -d -f --depth=250 --window=250" > >> instead. > >> > >> http://article.gmane.org/gmane.comp.gcc.devel/94613 > > That's actually a very useful article and the methods/reasons behind it > > sound quite sane and it could be a useful approach for us. > > > > I'll try this out on one of the smaller repos (a copy of course) and see > > what happens. > > > > We've ended up doing this live as well and I'm happy with the few stabs > I took at seeing if everything still works. > > Feel free to make this a regular thing on the revisor repo and I'll > report if anything breaks, so that if it doesn't, this could maybe > become a regular thing to do on all repos? Okay, from a server POV it shrunk the 116MB folder down to just 7MB in less than two minutes (based on a trial run in my homedir), which is pretty sweet. A trial with system-config-firewall.git went from ~20M to ~4M. I also did a trial run of anaconda.git and anaconda-images.git: anaconda.git: 183M (97745 objects) -> 64M (a third of the original size) real 26m18.050s user 23m9.395s sys 0m6.568s anaconda-images.git: 54M (1482 objects) -> 41M (didn't expect much here) real 1m57.944s user 1m43.466s sys 0m0.848s Maybe we should run git repack on the big repos on a bi/tri-monthly basis, and git gc (which is very fast - <1 minute on the anaconda repo for example) on a monthly basis. - Nigel From orion at cora.nwra.com Wed Aug 6 21:04:19 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 06 Aug 2008 15:04:19 -0600 Subject: Wrong bugzillla component owner Message-ID: <489A11D3.1030209@cora.nwra.com> I'm still listed in bugzilla as the owner of python-matplotlib, but I'm not. See: https://admin.fedoraproject.org/pkgdb/packages/name/python-matplotlib Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From a.badger at gmail.com Wed Aug 6 22:25:05 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 06 Aug 2008 15:25:05 -0700 Subject: Wrong bugzillla component owner In-Reply-To: <489A11D3.1030209@cora.nwra.com> References: <489A11D3.1030209@cora.nwra.com> Message-ID: <489A24C1.40806@gmail.com> Orion Poplawski wrote: > I'm still listed in bugzilla as the owner of python-matplotlib, but I'm > not. See: > https://admin.fedoraproject.org/pkgdb/packages/name/python-matplotlib > > Thanks! > Thanks for reporting this! I'll take a look. -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 a.badger at gmail.com Wed Aug 6 23:00:08 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 06 Aug 2008 16:00:08 -0700 Subject: Wrong bugzillla component owner In-Reply-To: <489A11D3.1030209@cora.nwra.com> References: <489A11D3.1030209@cora.nwra.com> Message-ID: <489A2CF8.6030305@gmail.com> Orion Poplawski wrote: > I'm still listed in bugzilla as the owner of python-matplotlib, but I'm > not. See: > https://admin.fedoraproject.org/pkgdb/packages/name/python-matplotlib > Hmm... It could be that bugzilla was updated between you sending this and me looking, but jspaleta is currently the owner of python-matplotlib in bugzilla. If you see this again, feel free to ping me here or on IRC: abadger1999 -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 dev at nigelj.com Thu Aug 7 13:11:45 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 08 Aug 2008 01:11:45 +1200 Subject: Puppet Commits Message-ID: <1218114705.31379.63.camel@localhost.localdomain> Sorry for all the puppet commits today, it's been driving me nuts as well. But what happened to 'make check' that could be run before commit? Really what I want to do, is say "lets pretend I'm publictest9.fedoraproject.org, what would I get and will it work?" Is this even possible? Can we fix it? - Nigel From nicu_fedora at nicubunu.ro Thu Aug 7 14:40:36 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 07 Aug 2008 17:40:36 +0300 Subject: Photo gallery Message-ID: <489B0964.1040307@nicubunu.ro> At the Art team we decided to start collecting photos which can be used as desktop wallpapers, make a best-of-breed selection and create one or more packages. The easiest way to get it running was to [ab]use a wiki page - https://fedoraproject.org/wiki/Artwork/Wallpaper_Extras but we understand that this may not be an optimal use of the wiki and having an upstream maybe at fedorahosted may be a better solution. What do you guys thing about that? A gallery plug-in for Trac? A stand-alone gallery? Any other solution better than using the main Fedora wiki? -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From jeff at ocjtech.us Thu Aug 7 15:03:56 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 7 Aug 2008 10:03:56 -0500 Subject: Photo gallery In-Reply-To: <489B0964.1040307@nicubunu.ro> References: <489B0964.1040307@nicubunu.ro> Message-ID: <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> On Thu, Aug 7, 2008 at 9:40 AM, Nicu Buculei wrote: > > What do you guys thing about that? A gallery plug-in for Trac? A stand-alone > gallery? Any other solution better than using the main Fedora wiki? I've had good luck with gallery2. It's PHP but it's already in Fedora (but not EPEL). AFAIK it has a decent security history (or at least as good as PHP web apps get). http://gallery.menalto.com/ My personal gallery is running at: http://www.ocjtech.us/gallery2/ I've only done a few customizations, but it's highly themable so it shouldn't be that hard to give it the "Fedora" look. Jeff From nicu_fedora at nicubunu.ro Thu Aug 7 15:15:32 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 07 Aug 2008 18:15:32 +0300 Subject: Photo gallery In-Reply-To: <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> Message-ID: <489B1194.1040806@nicubunu.ro> Jeffrey Ollie wrote: > On Thu, Aug 7, 2008 at 9:40 AM, Nicu Buculei wrote: >> What do you guys thing about that? A gallery plug-in for Trac? A stand-alone >> gallery? Any other solution better than using the main Fedora wiki? > > I've had good luck with gallery2. It's PHP but it's already in Fedora > (but not EPEL). AFAIK it has a decent security history (or at least as > good as PHP web apps get). Supposedly gallery2 has the features we need, how big of a change is to get it running in fedorahosted? -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From jeff at ocjtech.us Thu Aug 7 15:36:57 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 7 Aug 2008 10:36:57 -0500 Subject: Photo gallery In-Reply-To: <489B1194.1040806@nicubunu.ro> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> Message-ID: <935ead450808070836y1369e7a5y4165f3a116b82433@mail.gmail.com> On Thu, Aug 7, 2008 at 10:15 AM, Nicu Buculei wrote: > Jeffrey Ollie wrote: >> >> On Thu, Aug 7, 2008 at 9:40 AM, Nicu Buculei >> wrote: >>> >>> What do you guys thing about that? A gallery plug-in for Trac? A >>> stand-alone >>> gallery? Any other solution better than using the main Fedora wiki? >> >> I've had good luck with gallery2. It's PHP but it's already in Fedora >> (but not EPEL). AFAIK it has a decent security history (or at least as >> good as PHP web apps get). > > Supposedly gallery2 has the features we need, how big of a change is to get > it running in fedorahosted? Firstly we'd need to get gallery2 into EPEL. Then I think we'd want to wait for version 2.3 of gallery2 which will let us use sqlite databases instead of mysql / pgsql which will make provisioning (and backup/restore) much easier. Then also, we'll need to consider the implications of letting people store images on fedora hosted. The space requirements will certainly need to be figured out (hosted1 has plenty of space at the moment but we want to make sure this is sustainable long-term). Jeff From mmcgrath at redhat.com Thu Aug 7 15:42:50 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 10:42:50 -0500 (CDT) Subject: Photo gallery In-Reply-To: <489B1194.1040806@nicubunu.ro> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> Message-ID: On Thu, 7 Aug 2008, Nicu Buculei wrote: > Jeffrey Ollie wrote: > > On Thu, Aug 7, 2008 at 9:40 AM, Nicu Buculei > > wrote: > > > What do you guys thing about that? A gallery plug-in for Trac? A > > > stand-alone > > > gallery? Any other solution better than using the main Fedora wiki? > > > > I've had good luck with gallery2. It's PHP but it's already in Fedora > > (but not EPEL). AFAIK it has a decent security history (or at least as > > good as PHP web apps get). > > Supposedly gallery2 has the features we need, how big of a change is to get it > running in fedorahosted? > 0 chance of that happening. Galleries aren't part of the fedorahosted solution. But we can probably setup some sort of art.fedoraproject.org site. Couple of requirements include somehow being able to integrate it with FAS though. -Mike From mmcgrath at redhat.com Thu Aug 7 15:44:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 10:44:25 -0500 (CDT) Subject: Photo gallery In-Reply-To: <935ead450808070836y1369e7a5y4165f3a116b82433@mail.gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <935ead450808070836y1369e7a5y4165f3a116b82433@mail.gmail.com> Message-ID: On Thu, 7 Aug 2008, Jeffrey Ollie wrote: > On Thu, Aug 7, 2008 at 10:15 AM, Nicu Buculei wrote: > > Jeffrey Ollie wrote: > >> > >> On Thu, Aug 7, 2008 at 9:40 AM, Nicu Buculei > >> wrote: > >>> > >>> What do you guys thing about that? A gallery plug-in for Trac? A > >>> stand-alone > >>> gallery? Any other solution better than using the main Fedora wiki? > >> > >> I've had good luck with gallery2. It's PHP but it's already in Fedora > >> (but not EPEL). AFAIK it has a decent security history (or at least as > >> good as PHP web apps get). > > > > Supposedly gallery2 has the features we need, how big of a change is to get > > it running in fedorahosted? > > Firstly we'd need to get gallery2 into EPEL. Then I think we'd want > to wait for version 2.3 of gallery2 which will let us use sqlite > databases instead of mysql / pgsql which will make provisioning (and > backup/restore) much easier. Then also, we'll need to consider the > implications of letting people store images on fedora hosted. The > space requirements will certainly need to be figured out (hosted1 has > plenty of space at the moment but we want to make sure this is > sustainable long-term). > Actually we'll probably want to stick with mysql/pgsql so we can run the front end on multiple hosts and store the photos on the netapp. It'll allow us to do most upgrades and maintanence without downtime. -Mike From jeff at ocjtech.us Thu Aug 7 15:57:07 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 7 Aug 2008 10:57:07 -0500 Subject: Photo gallery In-Reply-To: References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <935ead450808070836y1369e7a5y4165f3a116b82433@mail.gmail.com> Message-ID: <935ead450808070857n447f104eo15e26aeea56c762f@mail.gmail.com> On Thu, Aug 7, 2008 at 10:44 AM, Mike McGrath wrote: > > Actually we'll probably want to stick with mysql/pgsql so we can run the > front end on multiple hosts and store the photos on the netapp. It'll > allow us to do most upgrades and maintanence without downtime. Yeah, that'd make the most sense if you're setting up art.fedoraproject.org rather than something on Fedora Hosted. Jeff From jeff at ocjtech.us Thu Aug 7 16:07:18 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 7 Aug 2008 11:07:18 -0500 Subject: Photo gallery In-Reply-To: References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> Message-ID: <935ead450808070907jc7d31cdxd3adcd259cf5635e@mail.gmail.com> On Thu, Aug 7, 2008 at 10:42 AM, Mike McGrath wrote: > Couple of requirements include somehow being able to integrate it > with FAS though. That should be possible, but might involve a custom plugin or something. Jeff From a.badger at gmail.com Thu Aug 7 16:29:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Aug 2008 09:29:13 -0700 Subject: Photo gallery In-Reply-To: <935ead450808070907jc7d31cdxd3adcd259cf5635e@mail.gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <935ead450808070907jc7d31cdxd3adcd259cf5635e@mail.gmail.com> Message-ID: <489B22D9.2040802@gmail.com> Jeffrey Ollie wrote: > On Thu, Aug 7, 2008 at 10:42 AM, Mike McGrath wrote: >> Couple of requirements include somehow being able to integrate it >> with FAS though. > > That should be possible, but might involve a custom plugin or something. > There was also art.gnome.org code that I took a glance at a year or so ago (it was being rewritten at the time from one php web app into a more complicated php web app) and, I think, ccMixter. Also, someone mentioned that mediawiki actually has a photo gallery plugin but I don't know the security record/usefulness of that. Nicu, what are the requirements of the gallery? -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 Thu Aug 7 16:43:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 11:43:48 -0500 (CDT) Subject: Good reading on page load time Message-ID: Here's a good read for our devs. http://www.die.net/musings/page_load_time/ -Mike From martin.sourada at gmail.com Thu Aug 7 17:49:34 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Thu, 07 Aug 2008 19:49:34 +0200 Subject: Photo gallery In-Reply-To: References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> Message-ID: <1218131375.15610.196.camel@pc-notebook> On Thu, 2008-08-07 at 10:42 -0500, Mike McGrath wrote: > 0 chance of that happening. Galleries aren't part of the fedorahosted > solution. But we can probably setup some sort of art.fedoraproject.org > site. Couple of requirements include somehow being able to integrate it > with FAS though. > > -Mike > The core of the whole effort is to get some hand-picked (by the fedora art team) extra wallpapers into fedora package system, so that users will have optionally more wallpapers to chose from available via yum. I considered these names for the binary (sub-)packages: backgrounds-extras-- and these names for the source packages and meta-packages: backgrounds-extras- The meta-package would require all the sub-packages of the given category. I think this is a feasible solution to keep d/l's on updates as low as possible and also not having some monstrous single package. The gallery would ideally serve both for the art team (as a place to submit their pictures for evaluation by the whole team) and users (as an additional place for additional easy-to-download wallpapers). Thus I think it would be nice if it has these features: - Categories/Subcategories - Ability to store big images (ca 1-6 MB), but provide user with low transfer rate when previewing - i.e. creating thumbnails at the server side - Integration with FAS - Some sort of rating system - Ability to download the full quality image easy (e.g. by one-click) - Probably ability to keep sources together with the resultant image in one place (in case it's e.g. a vector graphics or a collage) - Maybe some tag system to let users know what's in repos and what's not - Easy upload (can be either through CLI or Web Interface) - Would be nice if the full quality images/sources had some nice URLs so that we could easily fetch them either by build script or list them as sources in RPM. Do you think we have other requirements, Nicu? Also following the thread here, it seems like art.fedoraproject.org would be better solution for the gallery itself (in case we did it ourselves combined with gallery code in fh.o), I don't know yet what would be the best approach for upstream of the RPM packages. Copying the selected images into fh.o, or creating some build scripts which would fetch the images from art.fp.o and install them to system and have these scripts on fh.o, or just have rpm fetch images and list art.fh.o as upstream? Any thoughts? Martin -------------- 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 Thu Aug 7 17:55:09 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Aug 2008 23:25:09 +0530 Subject: FAS authentication for Red Hat bugzilla Message-ID: <489B36FD.3040103@fedoraproject.org> Hi, Is it possible to setup $subject? It would be nice to use my FAS account for everything related to Fedora. We are almost there now. Rahul From mmcgrath at redhat.com Thu Aug 7 18:03:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 13:03:40 -0500 (CDT) Subject: FAS authentication for Red Hat bugzilla In-Reply-To: <489B36FD.3040103@fedoraproject.org> References: <489B36FD.3040103@fedoraproject.org> Message-ID: On Thu, 7 Aug 2008, Rahul Sundaram wrote: > Hi, > > Is it possible to setup $subject? It would be nice to use my FAS account for > everything related to Fedora. We are almost there now. > Not our call unfortunately. We could run our own bugzilla instance but thats not as clear of a win as it seems. Its all in Red hat's hands though, enabling OpenID on their part would probably be the best option. -Mike From sundaram at fedoraproject.org Thu Aug 7 18:19:45 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 07 Aug 2008 23:49:45 +0530 Subject: FAS authentication for Red Hat bugzilla In-Reply-To: References: <489B36FD.3040103@fedoraproject.org> Message-ID: <489B3CC1.4060605@fedoraproject.org> Mike McGrath wrote: > On Thu, 7 Aug 2008, Rahul Sundaram wrote: > > >> Hi, >> >> Is it possible to setup $subject? It would be nice to use my FAS account for >> everything related to Fedora. We are almost there now. >> >> > > Not our call unfortunately. We could run our own bugzilla instance but > thats not as clear of a win as it seems. Its all in Red hat's hands > though, enabling OpenID on their part would probably be the best option I understand it is in Red Hat's hands. Have you talked to the people associated? Rahul From wakko666 at gmail.com Thu Aug 7 18:34:41 2008 From: wakko666 at gmail.com (brett lentz) Date: Thu, 7 Aug 2008 11:34:41 -0700 Subject: Puppet Commits In-Reply-To: <1218114705.31379.63.camel@localhost.localdomain> References: <1218114705.31379.63.camel@localhost.localdomain> Message-ID: On Thu, Aug 7, 2008 at 6:11 AM, Nigel Jones wrote: > Sorry for all the puppet commits today, it's been driving me nuts as > well. > > But what happened to 'make check' that could be run before commit? > Really what I want to do, is say "lets pretend I'm > publictest9.fedoraproject.org, what would I get and will it work?" > > Is this even possible? Can we fix it? > > - Nigel As far as I'm aware, because we're not using an external node classifier, we can only see what it currently gets, not what it will get. You can find that info by looking at /var/lib/puppet/classes.txt. As far as testing out the changes, the only way I'm familiar with doing that is by stopping puppetd, and running puppetd --test --no-daemonize. Alternately, you can just send SIGUSR1 to puppetd to force it to do a catalog run immediately, so that you aren't waiting around for the errors.. ----Brett. From mmcgrath at redhat.com Thu Aug 7 20:07:19 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 15:07:19 -0500 (CDT) Subject: FAS authentication for Red Hat bugzilla In-Reply-To: <489B3CC1.4060605@fedoraproject.org> References: <489B36FD.3040103@fedoraproject.org> <489B3CC1.4060605@fedoraproject.org> Message-ID: On Thu, 7 Aug 2008, Rahul Sundaram wrote: > Mike McGrath wrote: > > On Thu, 7 Aug 2008, Rahul Sundaram wrote: > > > > > > > Hi, > > > > > > Is it possible to setup $subject? It would be nice to use my FAS account > > > for > > > everything related to Fedora. We are almost there now. > > > > > > > > > > Not our call unfortunately. We could run our own bugzilla instance but > > thats not as clear of a win as it seems. Its all in Red hat's hands > > though, enabling OpenID on their part would probably be the best option > I understand it is in Red Hat's hands. Have you talked to the people > associated? > I've been directed to this ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=294608 Red Hat is waiting for Upstream to get the feature integrated. -Mike From ricky at fedoraproject.org Thu Aug 7 20:50:30 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 7 Aug 2008 16:50:30 -0400 Subject: Meeting Log - 2008-08-07 Message-ID: <20080807205030.GA17129@Max> 20:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 * ianweller 20:00 < mmcgrath> Howdy all, who's about? 20:00 * gregdek ! 20:00 * ianweller !!!!!!!1 20:00 < G> mooo 20:00 * londo is here 20:00 -!- wolfy [n=lonewolf at fedora/wolfy] has left #fedora-meeting ["I can please only one person per day. Today is not your day."] 20:00 < themayor> im around 20:00 * ianweller starts screaming at his USB for not booting his eeepc 20:01 -!- cjb [n=cjb at pullcord.laptop.org] has joined #fedora-meeting 20:01 -!- m_stone [n=mstone at teach.laptop.org] has joined #fedora-meeting 20:01 < mmcgrath> themayor: gregdek: welcome, don't see you guys at the infra meetings that much ;-) 20:01 < mmcgrath> First up, oustanding tickets 20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- tickets 20:01 < mmcgrath> https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&component=Hosted+Projects&order=id&desc=1 20:01 * ricky 20:01 < zodbot> (at fedorahosted.org) 20:01 < themayor> im just happy to finally have internet connection again, ill join anything at this point ;) 20:01 * kanarip ! 20:02 < mmcgrath> Sorry, thats the wrong link... Here's the right one 20:02 * dgilmore is here 20:02 < mmcgrath> https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 20:02 < zodbot> (at fedorahosted.org) 20:02 < mmcgrath> First ticket 20:02 < mmcgrath> .ticket 732 20:02 < zodbot> mmcgrath: #732 (Investigate New System Monitoring Methods) - Fedora Infrastructure - Trac - http://tinyurl.com/69whk6 20:02 < mmcgrath> G: want to take this one? I figure a summary of the last week would be good. Its coming along much more quickly then even I had anticipated. 20:03 * dgilmore would like to say that when doing things like restarting servers and services. please be kind and schedule downtime in nagios so we dont get alerts at 1am 20:03 < G> Yeah I'm actually on a slow-mo mode on this right now, got a few things I have to do, -noc'ers should be getting some e-mails soon though 20:03 < dgilmore> regardless of what the monitoring system is 20:04 < ricky> dgilmore: I think those were false ones last night :-( 20:04 < ricky> Or a VPN blip or something 20:04 < G> the base is up, and appears to relatively stable 20:04 < mmcgrath> ricky: I looked throught he logs and sar last night, I do believe it was a vpn blip. Got into a funky mode and fixed itself. 20:04 < G> that was noc2 (tummy) all last night) 20:04 < ricky> Ah 20:04 < ricky> noc1 gave alerts for stuff on the VPN too :-( 20:04 < G> so yeah, it's progressing 20:05 < mmcgrath> G: good work, really. I suspect we'll be fully converted soon. I look forward to the -noc emails. 20:05 < mmcgrath> G: anything else? If not we'll move on. 20:05 < G> oh for full conversion... 20:05 < G> I'd sooner hold out to September when 1.6.x is out if possible 20:06 < ricky> Hopefully, we can use the time in between to get a good baseline for the alert settings 20:06 < G> It provides several 'missing links' 20:06 < mmcgrath> G: any specific features we're blocking on? 20:06 < G> err hold on one sec, brain is a bit slow, and DNS just died 20:07 * mmcgrath notes we're talking about https://admin.fedoraproject.org/zabbix/ for those who aren't familiar with the actual site. 20:07 < G> okay... 20:08 -!- themayor [n=jack at 216.143.175.220] has quit Read error: 104 (Connection reset by peer) 20:08 < G> 1.6 offers us: better distributed monitoring, ability to proxy results, encryption on the agent, able to cache DB stuff 20:08 -!- themayor [n=jack at 216.143.175.220] has joined #fedora-meeting 20:08 < ricky> Encryption sounds like a cool one 20:09 < mmcgrath> k, well in the meantime that just gives us all the opportunity to make sure that its done right the first time. 20:09 < mmcgrath> G: again, good work. 20:09 < ricky> I'm also curious as to how well distributed monitoring will work. Can we get things setup so that not every single host has to be on the VPN? 20:09 < mmcgrath> ricky: depends on how we want to monitor it. 20:09 < mmcgrath> Anywho, next ticket :) 20:09 < mmcgrath> .ticket 395 20:09 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - http://tinyurl.com/5qb3gv 20:09 < mmcgrath> jcollie: any progress here? 20:09 < jcollie> nope 20:09 < mmcgrath> k, next ticket. 20:10 < mmcgrath> .ticket 446 20:10 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - http://tinyurl.com/3w4uwn 20:10 < mmcgrath> dgilmore: ^^^ 20:10 < mmcgrath> is that done? do we even need that link anymore? 20:10 * mmcgrath thinks dgilmore is pretty busy today with other meetings. 20:10 < mmcgrath> dgilmore: we'll go back to that 20:10 < dgilmore> mmcgrath: we have a wiki page that needs some legal love. 20:11 < dgilmore> but i dont know if its needed any longer 20:11 < mmcgrath> dgilmore: ah, k. has that request been forwarded on to legal? 20:11 < mmcgrath> yeah, the whole spins thing has kind of been re-designed since that request was created. 20:11 < mmcgrath> dgilmore: anywho, we'll move on. 20:11 < dgilmore> mmcgrath: no i need to do that. I need a sentance to say that fedora doesnt provide or endorse the referenced spins 20:11 < dgilmore> yeah 20:11 < mmcgrath> .ticket 576 20:11 < zodbot> mmcgrath: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - http://tinyurl.com/4kevcb 20:11 < mmcgrath> dgilmore: ahh, k. 20:12 < mmcgrath> So this one's blocking on me. 20:12 < mmcgrath> I need to get up, put the thing together and hand out directions on how it works. 20:12 < mmcgrath> .ticket 740 20:12 < zodbot> mmcgrath: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - http://tinyurl.com/66e2es 20:12 < mmcgrath> this one's new to me. 20:13 < mmcgrath> ahh, 20:13 < mmcgrath> gregdek: this one's yours. 20:13 < mmcgrath> gregdek: so the specific use case is giving people the ability to build for OLPC machines using our infrastructure somehow? 20:13 < gregdek> That's the idea. 20:13 < mmcgrath> So there's a couple of ways we could do this. 20:13 < dgilmore> gregdek: build what? 20:14 -!- hhardy_ [n=hhardy at thinker.laptop.org] has joined #fedora-meeting 20:14 < mmcgrath> 1) is to just use koji. My concern there is that I'm not aware of anyone using non-RH/Fedora OS's to build against koji. 20:14 < gregdek> Updated packages, as I understand it, when they don't have their own Fedora boxes. 20:14 -!- epithumia [n=tibbs at fedora/tibbs] has joined #fedora-meeting 20:14 < mmcgrath> and 2) is to use a 3rd party who's wiling to donate their machine but allow FAS to build on it. 20:14 < ricky> What buildsystem does olpc currently use? 20:14 < mmcgrath> gregdek: once the package is built, they'd distribute it somehow or just download it themselves? 20:15 < mmcgrath> ricky: I bet dgilmore knows ;-) 20:15 < gregdek> These are questions I do not readily have the answers to. 20:15 < G> mmcgrath: what about re-rack a couple of old machines, install fedora on them, lock them down etc 20:15 < dgilmore> gregdek: so we are best off getting koji packaged for debian/ubuntu/SuSE/mandriva etc 20:15 < mmcgrath> gregdek: sure thing. 20:15 < dgilmore> ricky: fedora's koji 20:15 < themayor> yeah 20:15 < ricky> Oh 20:15 < mmcgrath> G: we could do that, but we're still tight on space in PHX. it is an option though. 20:15 < gregdek> It's my understanding that we've tried getting koji into other distros with limited success...? 20:15 < G> mmcgrath: ahhh rack space 20:15 < mmcgrath> dgilmore: do you happen to know if its possible to build OLPC packages on SuSE's Open Build System? 20:16 < dgilmore> mmcgrath: i have no idea. i looked at the crack it is and cried 20:16 < mmcgrath> heh 20:16 < mmcgrath> gregdek: not sure, there's two parts to koji (obviously) the client and the server. 20:16 < mmcgrath> I'd think the client could be put in other distros fairly easily. 20:16 < mmcgrath> the server part though, not sure. 20:16 -!- tibbs|h [n=tibbs at fedora/tibbs] has quit Nick collision from services. 20:16 -!- epithumia is now known as tibbs|h 20:16 < dgilmore> im guessing whats really wanted here is somewhere that people could log in, run mock and do development builds 20:16 < mmcgrath> dgilmore: whats your opinion on that? 20:17 < ricky> So they're currently building OLPC packages on Fedora, and they need to build it on their distro instead? 20:17 < mmcgrath> gregdek: did you see them as having signed the CLA and considered contributors? 20:17 < dgilmore> mmcgrath: client should be no problems i would think 20:17 < gregdek> mmcgrath: I think that's reasonable. 20:17 < gregdek> Given the easy CLA process. 20:17 < dgilmore> ricky: there is olpc specific tags that they can scratch build in 20:18 < dgilmore> and mock is in debian, which worked last i tested 20:18 < gregdek> People are currently using mock to build in Debian, yes. 20:18 < gregdek> AIUI. 20:18 < ricky> Wow, cool 20:18 < mmcgrath> gregdek: dgilmore: lets get some questions together and put in that ticket and make sure they get answered then meet up again next week. 20:18 < mmcgrath> how's that sound? 20:18 < gregdek> Brilliant. 20:18 < dgilmore> mmcgrath: sounds fine. 20:18 < mmcgrath> schweet. 20:19 < mmcgrath> Ok. So thats the end of the tickets, I've got a couple of items to discuss 20:19 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- PPC builders 20:19 < mmcgrath> I've added a few ppc builders, ppc6 is on the way hopefully. 20:19 < mmcgrath> dgilmore: how'd they look? 20:19 < mmcgrath> .builders 20:19 < zodbot> mmcgrath: Enabled: 12 Ready: 12 Disabled: 11 20:19 < mmcgrath> .building ppc4 20:19 < zodbot> mmcgrath: ppc4 - tasks/765415/eclipse-3.4.0-18.fc10.src.rpm:ppc64 20:19 < mmcgrath> pretty quiet right now 20:19 < dgilmore> mmcgrath: poking at it now. it seems ok other than disk 20:20 < mmcgrath> yeah 20:20 < mmcgrath> Just so everyone knows, our bladecenter builders came with lots of power and memory, not much disk. Its our biggest limiter especially on the PPC hosts. I'm hoping some firmware upgrades will give us access to the tools we need to disable the hardware raid and enable software raid. 20:20 < mmcgrath> that'd give us the ability to do raid0 and thus, get more disk space (and faster disk) out of those boxes. 20:21 < mmcgrath> I'm just happy they've booted and have an OS on them. 20:21 < mmcgrath> So thats really all there. 20:21 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- CVS boxes 20:21 < dgilmore> .building ppc5 20:21 < zodbot> dgilmore: ppc5 - Not doing anything 20:21 < mmcgrath> As some of you have seen I've built cvs1 and cvs2. I'm going to be doing some proof of concepts on them but soon the current cvs.fedoraproject.org will get replaced with something more... modern. 20:21 < ricky> :-D 20:21 < mmcgrath> And far less scary. 20:22 < abadger1999> yay! 20:22 < dgilmore> mmcgrath: its not that scary 20:22 < ricky> chroots. 20:22 < mmcgrath> So expect that soon. I'll coordinate with releng. I suspect this will be ready long before F10 ships, but probably won't go live until after that just to make sure we don't break F10 needlessly. 20:22 < mmcgrath> Next topic 20:22 -!- lxo [n=aoliva at 201.82.112.27] has joined #fedora-meeting 20:22 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- haproxy 20:23 < mmcgrath> I've been evaluating a few proxy / HA balancers and haproxy seems to fit best with our use case. Its got a decent base and all my tests have... well just worked. no fuss. 20:23 < mmcgrath> We're looking to use this to replace mod_proxy_balancer which just isn't cutting it with us anymore. Its not as feature rich nor as mature as what our environment now needs. 20:23 -!- lx0 [n=aoliva at 201.82.112.27] has quit Read error: 110 (Connection timed out) 20:23 < mmcgrath> it will also play well when we start to abstract our caching servers and add geoDNS. 20:23 < dgilmore> mmcgrath: what else was considered? 20:24 < ricky> What will we put in front of it for SSL? 20:24 < G> mmcgrath: will this change the basic workflow on how webapps operate? 20:24 < mmcgrath> If the plan goes right, it will mean faster load times for our users as content will be served geographically close to them. 20:24 < mmcgrath> ricky: nope, behind SSL. 20:24 < mmcgrath> G: for the first rollout no 20:24 < ricky> mmcgrath: But what will we use for the SSL part? 20:25 < mmcgrath> dgilmore: I've looked at mod_proxy_balancer (what we currently use), piranha, and Pound 20:25 < mmcgrath> ricky: apache 20:25 < mmcgrath> ricky: this will literally replace the balancer:// bits in our configs. Other then that the proxy servers, for now, remain the same. 20:26 < G> mmcgrath: balancer:// becomes...? 20:26 < ricky> Oh, so it'll be web app -> haproxy -> apache? 20:26 < mmcgrath> balancer will likely become http://localhost:haproxyPort/ 20:26 < ricky> Or maybe I'm misinterpreting this page. 20:26 < G> mmcgrath: gotcha 20:26 < mmcgrath> well it'll be browser -> apache -> haproxy -> app whereas right now its browser -> apache -> mod_proxy_balancer(apache) -> app 20:27 < ricky> Ahh 20:27 < mmcgrath> haproxy has far better metrics and a great stats page to see wtf is going on when things start to bork. 20:27 * mmcgrath gets the screenshot 20:27 < dgilmore> mmcgrath: :) 20:28 < mmcgrath> http://haproxy.1wt.eu/img/haproxy-stats.png <-- Older version' 20:28 < ricky> Very descriptive website :-) 20:28 < mmcgrath> but you get the idea. 20:29 < mmcgrath> The stats include things like when the worker just came back, and when the last time the actual farm was down. 20:29 < mmcgrath> All very useful and just not things we're getting out of mod_proxy_balancer, even with the mod_proxy_balancer stats. 20:29 < ricky> Nice 20:29 < mmcgrath> Anyone have any questions on that? If not I'll open the floor. 20:29 < ricky> So what do you see the "final" setup as being? 20:30 < ricky> Will we still use apache for caching, or will we look at squid or something at some point? 20:30 < mmcgrath> ricky: not sure yet, it depends on what we decide our caching strategy is and what we use to cache. 20:30 < ricky> All right 20:30 < mmcgrath> well, for now yes. But ultimately we'll likely be implementing squid or maybe even invest more time in memcached. 20:31 < mmcgrath> lots more research is needed and we'll have to re-examine how our applications work, where the expensive network calls are (IE: from the app to DB, or from the app to the user) that type of thing 20:31 < mdomsch> mmcgrath, wildcard certs yet? 20:31 < G> ohh yeah... 20:31 < mmcgrath> mdomsch: yes, actually we do have a *.fedoraproject.org cert as of last week. I sent an email to I think sysadmin-web-members. 20:31 < G> thats the only blocker on the new wikis basically 20:31 * mmcgrath goes ahead and opens the floor 20:31 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:31 < G> mmcgrath: I don't recall getting one 20:31 < lmacken> mmcgrath: How is the appFc/appRhel merge going ? 20:32 < mmcgrath> G: boo, well I have it and its ready to be deployed if you or ricky or someone else wants to do it. If not I'll probably hit it up next week. 20:32 < G> I had two things for Open Floor, but I've forgotten one 20:32 < mmcgrath> lmacken: its going ok. I hit some snags but I expect to be done with it early this week late last week. 20:32 < mdomsch> at some point in the next month or so we'll want to enable https for mirrors.fp.o 20:32 < lmacken> mmcgrath: cool 20:32 < mmcgrath> mdomsch: sure thing, that should be a low-cost operation now :) 20:32 < G> mmcgrath: yeah, we can't do it for fp.o until we are using *.fp.o 20:32 < mdomsch> but right now yum doesn't do anything useful with https (except encrypt, no validation), so it's of limited value 20:32 < G> (well not really) 20:33 < ricky> mdomsch: By the way, http://fedoraproject.org/wiki/Infrastructure/SOP/MirrorManager could use some love, when you have some time 20:33 < zodbot> (at fedoraproject.org) 20:33 < mdomsch> ok 20:33 < G> Anyone, I did have the whole l10n wiki stuff :) 20:33 < mdomsch> next, serving yum metadata from Fedora-owned servers... 20:33 < mmcgrath> well if anyone wants to get that setup let me know. I have a few kind of strict requrements for its use (IE, don't let it get on a test server) 20:33 < mmcgrath> well if anyone wants to get that setup let me know. I have a few kind of strict requrements for its use (IE, don't let it get on a test se 20:34 < mmcgrath> oof 20:34 < G> As the wildcart certs a ready, it just needs some TLC from our translators (I'll poke couf today) 20:34 < ricky> What will be the translator workflow for the l10ned wiki? 20:34 < mmcgrath> ricky: I'm a little curious about that myself 20:34 < mmcgrath> G: what two things did you have to discuss? 20:35 < G> mmcgrath: wiki, and as I said, I forgot the other 20:35 < mmcgrath> ah, k. 20:35 < ricky> It's an interesting tradeoff between ease-of-implementation (for me) and letting translators keep their processes (for fedora-web, at least) 20:35 < mmcgrath> ricky: yeah. I'll be curious to see how it actually goes when the time comes. 20:35 < G> really the workflow wouldn't be much different to how it was with the old wiki 20:36 < mmcgrath> Ok, well kind of a short meeting this time around, still have plenty of time left. Anyone have anything else they'd like to discuss? 20:36 < mmcgrath> or re-discuss even? 20:36 < G> Also we have Mediawiki talking to FAS via json :) 20:36 < abadger1999> rh bz3 20:36 < mmcgrath> G: we'll be gitting rid of the http auth plugin completely after that gets deployed, right? 20:37 < G> if someone (anyone) wants to take a look at bug 458220 it'd be much appreciated 20:37 < buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=458220 medium, medium, ---, nobody at fedoraproject.org, NEW, Review Request: php-pecl-json - PECL library to implement JSON in PHP 20:37 < G> mmcgrath: correct! 20:37 < mmcgrath> solid 20:37 < mdomsch> how bad would it suck if we started pushing the yum sqlite databases from mirrors.fp.o instead of from the mirrors themselves? 20:37 < mmcgrath> mdomsch: the sqlite db's as they currently are? 20:37 < mmcgrath> or will the format / size change? 20:37 < mdomsch> yeah; all 30MB of each of them 20:38 < mmcgrath> mdomsch: not sure, go ahead and submit a ticket and we'll get an estimate together. 20:38 < abadger1999> mdomsch: Why not just repomd.xml? 20:38 < ivazquez> Wouldn't that cause sync issues galore? 20:38 < mdomsch> (opensuse pushes all repository metadata from their owned servers; only packages are downloaded via redirects to the mirrors) 20:38 < mmcgrath> mdomsch: and you're sure from mirrors.fp.o and not download.fedora.redhat.com ? 20:38 < mdomsch> i'm looking 20:38 < mdomsch> yeah, maybe d.f.r.c 20:38 < mdomsch> not sure yet 20:38 < mmcgrath> mdomsch: if we can do it from d.f.rh.c or even alias some secure.mirrors.fp.o or something I think that'd be good. 20:39 < mmcgrath> AFAIK those mirros aren't getting that much traffic now that they're not in the public view. 20:39 < G> ivazquez: yum would fall onto a new server if the content wasn't yet on one 20:39 -!- vwbusguy [n=scott at c-68-51-66-81.hsd1.in.comcast.net] has quit "Leaving" 20:39 < abadger1999> G: But right after a push, everyone will be out of date. 20:39 < mmcgrath> G: it is a good point though, d.f.r.c or mirrors.fp.o would have the content first. 20:39 < G> abadger1999: yeah 20:39 < mmcgrath> could be a couple of hours where people would think all mirrors are bad. 20:39 < G> what about... 20:39 < mmcgrath> mdomsch: how do we protect against that? 20:39 < mdomsch> yeah, d.f.r.c may wind up being the last mirror listed 20:40 < abadger1999> mdomsch: Not going to try to do versioned repodata? 20:40 < mdomsch> so it gets used only if none of the other mirrors are current 20:40 < G> how about just distribute hashes of all the sqlite dbs like the mirrorlists are 20:40 < mdomsch> abadger1999, yeah, probably will do versioned repodata, at least timestamped 20:40 < mmcgrath> mdomsch: might be time again to look into pushed updates debian style 20:40 < G> i.e. 20:40 < ivazquez> It would be nice if there was some sort of prioqueue that mirrors could get dumped on, then read the mirrors down that way. 20:40 < G> Current: 20:40 < mdomsch> mmcgrath, we _absolutely_ need push mirroring 20:40 < G> Old: 20:40 -!- fchiulli [i=824c4012 at gateway/web/ajax/mibbit.com/x-f301c807820557dc] has joined #fedora-meeting 20:40 < mdomsch> I haven't had time to do anything about push mirroring though 20:40 < mdomsch> volunteers? :-) 20:41 < G> that way yum can use either or, but it can warn you if it's an old hash 20:41 < mdomsch> g: yes exactly 20:41 < G> (i.e. "Heck, the mirror doesn't have the latest, you might want to check back in a few hours" 20:41 < mdomsch> I've started working on this a couple weeks ago 20:42 < mmcgrath> mdomsch: how serious of a risk do you estimate we're actually in. 20:42 < mmcgrath> both in reality, and compared to the other major distros. 20:42 < mdomsch> adding in metalink support, which gets us a common format for ... 20:42 < mdomsch> the only real problem is maliciously stale mirrors targeting specific netblocks 20:42 -!- cassmodiah [n=cass at p54AB5FCB.dip.t-dialin.net] has quit "www.spielen-unter-linux.de | #linuxgaming.de auf freenode" 20:43 < G> mdomsch: yeah might pay to offer two or three checksums for each file though 20:43 < mdomsch> and by malicious, I mean "one that lies to MM and says it's up-to-date" when it's not 20:43 < mmcgrath> 20:43 < ivazquez> Prompt for some checksum. 20:43 < mdomsch> g: yeah; that's an extension to metalinks I need to add 20:44 < mdomsch> I've started that thread with the metalink spec authors 20:44 < G> mdomsch: ahh great 20:44 < mdomsch> but, when we have it, we get metalinks for ISOs etc for free 20:44 < kanarip> it could be as simple as letting yum always grab the headers from at least two different mirrors, and if they differ, take a third and drop the non-matching 20:44 < mmcgrath> mdomsch: well it sounds like we have options there to examine. I don't see any blockers though really. 20:44 < mdomsch> I've wanted to avoid serving the metadata itself (sqlite dbs & large XML files) from our own servers 20:45 < mdomsch> but if push comes to shove, good to have that as an option 20:45 < mdomsch> that's all for now 20:45 < mmcgrath> mdomsch: if we didn't do that, are we talking about bad as in someone submits a bug abouta bad mirror, or we get torn a new one on lwn? 20:45 < mdomsch> worst case, the latter 20:46 < mmcgrath> k 20:46 < abadger1999> not necessarily justified though.... 20:46 < mmcgrath> mdomsch: yeah, go ahead and create a ticket and we'll get it figured out. 20:46 < mmcgrath> abadger1999: same old song and dance then ;-) 20:46 < abadger1999> Yep :-/ 20:46 < abadger1999> One FYI: red hat bugzilla was upgraded last weekend. So far it looks like they did a really good job on compat... only fas's bugzilla sync script appears to be broken. 20:47 < G> mmcgrath: is our Wildcard cert chained? 20:47 < mmcgrath> G: "chained" ? 20:47 < mmcgrath> abadger1999: is it still borked? 20:47 < G> mmcgrath: yeah, one issuers chain the certs together so there is basically 3 certs 20:47 < abadger1999> Until dkl implements an equivalent to updatePerms() in the xmlrpc API, I have to sync fas => bugzilla manually. If someone complains, ping me to update the tables. 20:48 < mmcgrath> G: oh, not sure. I haven't even opened the attachment yet to look at it. 20:48 < abadger1999> (OTherwise I'm doing it once a day) 20:48 < mmcgrath> abadger1999: will do, thanks for the heads up. 20:48 < mmcgrath> G: ping me after the meeting, I'll take a look. 20:48 < mmcgrath> Anyone have anything else they'd like to discuss? If not we'll close the meeting in 30 seconds? 20:48 < G> the site cert, the issuing cert (chained to the site cert) and the issuing cert of the issurer thats in the browsers etc 20:48 < ricky> I think you just need to look at who signed it 20:48 < mmcgrath> 15 20:49 < mmcgrath> 5 20:49 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting end 20:49 < mmcgrath> Thanks for coming everyone! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeff at ocjtech.us Thu Aug 7 21:15:18 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 7 Aug 2008 16:15:18 -0500 Subject: Photo gallery In-Reply-To: <1218131375.15610.196.camel@pc-notebook> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> Message-ID: <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> My comments below are all regarding gallery2 (gallery2.menalto.com): 2008/8/7 Martin Sourada : > Thus I think it would be nice if it has these features: > > - Categories/Subcategories You could either do this by creating albums / subalbums or by using tags: http://codex.gallery2.org/Gallery2:Modules:tags > - Ability to store big images (ca 1-6 MB), but provide user with low > transfer rate when previewing - i.e. creating thumbnails at the server > side You can define up to 4 sizes that the original image will be resized to. For example, my site has 640x640, 1024x1024, 1280x1280 and original size images available, plus the thumbnails shown in the album view. I've uploaded some very large TIFF files (20-30MB IIRC) and it handled it just fine. > - Integration with FAS >From what I can tell this would be possible, but may need some PHP coding. > - Some sort of rating system http://codex.gallery2.org/Gallery2:Modules:rating > - Ability to download the full quality image easy (e.g. by one-click) Gallery2 can do it in a couple clicks (view original size image, right click on image and "save image as..." > - Probably ability to keep sources together with the resultant image in > one place (in case it's e.g. a vector graphics or a collage) That wouldn't be something that was "built in". > - Maybe some tag system to let users know what's in repos and what's > not http://codex.gallery2.org/Gallery2:Modules:tags > - Easy upload (can be either through CLI or Web Interface) http://codex.gallery2.org/Gallery2:How_to_Add_Items IIRC f-spot has the built-in ability to upload images to a gallery2 site as well. > - Would be nice if the full quality images/sources had some nice URLs > so that we could easily fetch them either by build script or list them > as sources in RPM. http://codex.gallery2.org/Gallery2:Modules:rewrite Jeff From jeff at ocjtech.us Thu Aug 7 21:16:16 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 7 Aug 2008 16:16:16 -0500 Subject: Photo gallery In-Reply-To: <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> Message-ID: <935ead450808071416r68a9f03dp554e35df2e724874@mail.gmail.com> On Thu, Aug 7, 2008 at 4:15 PM, Jeffrey Ollie wrote: > My comments below are all regarding gallery2 (gallery2.menalto.com): Oops... that's gallery.menalto.com Jeff From mmcgrath at redhat.com Thu Aug 7 21:18:30 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 16:18:30 -0500 (CDT) Subject: [serverbeach.com #1327168] IMPORTANT ServerBeach Message - Network Maintenance Notification *SERVICE IMPACTING* - Virginia - August 19th 2:00am-2:15am CDT (fwd) Message-ID: FYI all: THIS AN IMPORTANT MESSAGE CONCERNING YOUR SERVER - PLEASE READ CAREFULLY SERVER(S) AFFECTED: ip 64.34.163.94 ip 64.34.163.95 ip 64.34.163.96 Please be advised that on Tuesday, August 19th between 2:00am and 2:15am CDT we will be conducting maintenance on some of our production leaf switches in Virginia. This will cause a brief network outage for your server(s) listed above for no more than fifteen minutes. From ricky at fedoraproject.org Thu Aug 7 21:27:03 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 7 Aug 2008 17:27:03 -0400 Subject: Photo gallery In-Reply-To: <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> Message-ID: <20080807212241.GB17129@Max> On 2008-08-07 04:15:18 PM, Jeffrey Ollie wrote: > > - Integration with FAS > > >From what I can tell this would be possible, but may need some PHP coding. Nigel may have already done most of the work for this - we'd probably just need to hook it in :-) 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 Aug 7 21:40:22 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 7 Aug 2008 17:40:22 -0400 Subject: [serverbeach.com #1327168] IMPORTANT ServerBeach Message - Network Maintenance Notification *SERVICE IMPACTING* - Virginia - August 19th 2:00am-2:15am CDT (fwd) In-Reply-To: References: Message-ID: <20080807214022.GC17129@Max> On 2008-08-07 04:18:30 PM, Mike McGrath wrote: > SERVER(S) AFFECTED: > > ip 64.34.163.94 > ip 64.34.163.95 > ip 64.34.163.96 Specifically, will bring hte following hosts down: serverbeach1 serverbeach2 serverbeach3 asterisk1 collab1 ns1 asterisk2 collab2 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 Thu Aug 7 21:42:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 16:42:47 -0500 (CDT) Subject: Puppet and modules Message-ID: So I've been working on modules for a bit now getting better educated on them. One thing that we haven't completely come to an agreement on is what should be a module, and what should the module be called. So until we come up with a perfect test of it. Here's what you should go by: Is it a package you're trying to configure? If yes. it should be a module. And that module should have the exact same name as the module. For now http is an exception to this because there's efficiencies to be gained. You don't have to go switch everything you're doing to modules right away but when you're looking to configure something, like postfix, for example. hit up the modules/ directory first. if its not in there. Look elsewhere. Having a good test question will be essential to keeping modules clean and not end up in an environment like we (and I'm sure many) are in where stuff is just stored all over the place. This may change in the future but until that point, stick with this. -Mike From martin.sourada at gmail.com Thu Aug 7 22:02:15 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 08 Aug 2008 00:02:15 +0200 Subject: Photo gallery In-Reply-To: <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> Message-ID: <1218146535.15610.202.camel@pc-notebook> Thanks for the info. Looks like the gallery2 would satisfy our needs pretty good. The only two issues I noticed is the missing integration with FAS (which might be already in progress, as noted by Ricky), and easy way to handle images sources (which is not a show-stopper for us, though it would be nice if we could implement that nicely as well). I guess we could set-up a test gallery2 implementation on one of our fedorapeople accounts and if it works well, ask for transferring it to art.fedoraproject.org here? Thanks, Martin -------------- 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 a.badger at gmail.com Fri Aug 8 00:53:50 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 07 Aug 2008 17:53:50 -0700 Subject: Photo gallery In-Reply-To: <1218146535.15610.202.camel@pc-notebook> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> <1218146535.15610.202.camel@pc-notebook> Message-ID: <489B991E.8010004@gmail.com> Martin Sourada wrote: > Thanks for the info. Looks like the gallery2 would satisfy our needs > pretty good. The only two issues I noticed is the missing integration > with FAS (which might be already in progress, as noted by Ricky), and > easy way to handle images sources (which is not a show-stopper for us, > though it would be nice if we could implement that nicely as well). > > I guess we could set-up a test gallery2 implementation on one of our > fedorapeople accounts and if it works well, ask for transferring it to > art.fedoraproject.org here? > We also need to decide if we want to run the software in Fedora Infrastructure. Searching for CVEs was somewhat hard since gallery is a common name for photo gallery software. I found 5 CVE's against Menalto Gallery this year and 9 last year. There are other CVE's that weren't picked up in my search as they did not identify gallery as "menalto" (I googled and found references...) I'm not sure how this compares to other gallery software but it is less than phpnuke, drupal, and other things that I have been against. We do not yet have SELinux turned on on our app servers (although lmacken and dwalsh have gotten us much closer recently). I am pretty sure we do have mod_security deployed. Do we feel comfortable with this? What are the alternatives that fit the criteria and are they worse? -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 Fri Aug 8 01:06:43 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 7 Aug 2008 20:06:43 -0500 (CDT) Subject: Photo gallery In-Reply-To: <489B991E.8010004@gmail.com> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> <935ead450808071415l78a392aek914a015d45080c6e@mail.gmail.com> <1218146535.15610.202.camel@pc-notebook> <489B991E.8010004@gmail.com> Message-ID: On Thu, 7 Aug 2008, Toshio Kuratomi wrote: > > We do not yet have SELinux turned on on our app servers (although lmacken and > dwalsh have gotten us much closer recently). I am pretty sure we do have > mod_security deployed. Do we feel comfortable with this? What are the > alternatives that fit the criteria and are they worse? > mod_security deployed but needs testing and love. -Mike From nicu_fedora at nicubunu.ro Fri Aug 8 06:13:40 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 08 Aug 2008 09:13:40 +0300 Subject: Photo gallery In-Reply-To: <1218131375.15610.196.camel@pc-notebook> References: <489B0964.1040307@nicubunu.ro> <935ead450808070803n1ac852a8ydc8cbbb19efa4c4f@mail.gmail.com> <489B1194.1040806@nicubunu.ro> <1218131375.15610.196.camel@pc-notebook> Message-ID: <489BE414.8020406@nicubunu.ro> Martin Sourada wrote: > > The gallery would ideally serve both for the art team (as a place to > submit their pictures for evaluation by the whole team) and users (as an > additional place for additional easy-to-download wallpapers). Thus I > think it would be nice if it has these features: > > - Categories/Subcategories > - Ability to store big images (ca 1-6 MB), but provide user with low > transfer rate when previewing - i.e. creating thumbnails at the server > side > - Integration with FAS > - Some sort of rating system > - Ability to download the full quality image easy (e.g. by one-click) > - Probably ability to keep sources together with the resultant image in > one place (in case it's e.g. a vector graphics or a collage) > - Maybe some tag system to let users know what's in repos and what's > not > - Easy upload (can be either through CLI or Web Interface) > - Would be nice if the full quality images/sources had some nice URLs > so that we could easily fetch them either by build script or list them > as sources in RPM. > > Do you think we have other requirements, Nicu? RSS feeds would be also nice to have and it seems there is a Gallery2 module for that - http://codex.gallery2.org/Gallery2:Modules:rss (I have never tested it) -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From bkearney at redhat.com Fri Aug 8 11:20:55 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 08 Aug 2008 07:20:55 -0400 Subject: Puppet and modules In-Reply-To: References: Message-ID: <489C2C17.1070700@redhat.com> Mike McGrath wrote: > So I've been working on modules for a bit now getting better educated on > them. One thing that we haven't completely come to an agreement on is > what should be a module, and what should the module be called. So until > we come up with a perfect test of it. Here's what you should go by: > > > Is it a package you're trying to configure? If yes. it should be a > module. And that module should have the exact same name as the module. > > For now http is an exception to this because there's efficiencies to be > gained. You don't have to go switch everything you're doing to modules > right away but when you're looking to configure something, like postfix, > for example. hit up the modules/ directory first. if its not in there. > Look elsewhere. > > Having a good test question will be essential to keeping modules clean and > not end up in an environment like we (and I'm sure many) are in where > stuff is just stored all over the place. This may change in the future > but until that point, stick with this. Just to make sure you have seen these resources: Existing Modules http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration http://reductivelabs.com/trac/puppet/wiki/Lab42Infrastructure Proposed Standards: http://reductivelabs.com/trac/puppet/wiki/ModuleStandards http://reductivelabs.com/trac/puppet/wiki/ModuleDocumentationStandards Also Genome and Thincrust are using alot of puppet, and may have some modules to use http://genome.et.redhat.com/ http://www.thincrust.net -- bk From mmcgrath at redhat.com Fri Aug 8 14:35:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 8 Aug 2008 09:35:15 -0500 (CDT) Subject: FAS1 rebuilt Message-ID: I rebuilt fas1 today, I know there were some hot fixes applied to the old fas1 so I replaced these files: S.5....T /usr/lib/python2.4/site-packages/fas/cla.py S.5....T /usr/lib/python2.4/site-packages/fas/controllers.py S.5....T /usr/lib/python2.4/site-packages/fas/group.py S.5....T /usr/lib/python2.4/site-packages/fas/help.py S.5....T /usr/lib/python2.4/site-packages/fas/templates/openid/id.html S.5....T /usr/lib/python2.4/site-packages/fas/templates/openid/sreg.xml S.5....T /usr/lib/python2.4/site-packages/fas/templates/user/edit.html S.5....T /usr/lib/python2.4/site-packages/fas/user.py S.5....T /usr/lib/python2.4/site-packages/fas/validators.py The ssh key has changed also keep your eyes open for any oddities that come up. This rebuild was a conversion from x86_64 to i686. The box had recently started swapping. -Mike From kanarip at kanarip.com Fri Aug 8 15:09:19 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 08 Aug 2008 17:09:19 +0200 Subject: Puppet and modules In-Reply-To: <489C2C17.1070700@redhat.com> References: <489C2C17.1070700@redhat.com> Message-ID: <489C619F.10209@kanarip.com> Bryan Kearney wrote: > Just to make sure you have seen these resources: > > Existing Modules > http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration > http://reductivelabs.com/trac/puppet/wiki/Lab42Infrastructure > > > Proposed Standards: > http://reductivelabs.com/trac/puppet/wiki/ModuleStandards > http://reductivelabs.com/trac/puppet/wiki/ModuleDocumentationStandards > > Also Genome and Thincrust are using alot of puppet, and may have some > modules to use > http://genome.et.redhat.com/ > http://www.thincrust.net > Additionally, there is some on http://git.puppetmanaged.org/ Kind regards, Jeroen van Meeuwen -kanarip From mmcgrath at redhat.com Fri Aug 8 19:28:01 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 8 Aug 2008 14:28:01 -0500 (CDT) Subject: haproxy deployment Message-ID: So we've got haproxy running in production now for the wiki. I'm keeping a close eye on it as I hope others will as well. The old config still exists and has what was changed commented out so if anything goes wrong and I'm not around. Revert it. To check out the stats: https://admin.fedoraproject.org/haproxy/proxy1/ https://admin.fedoraproject.org/haproxy/proxy2/ https://admin.fedoraproject.org/haproxy/proxy3/ -Mike From a.badger at gmail.com Sat Aug 9 02:17:16 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Aug 2008 19:17:16 -0700 Subject: RFC: script to run sqlalchemy migrations on the db Message-ID: <489CFE2C.3040801@gmail.com> FAS started using the python-migrate package to update its db. This is a good thing for third-parties that want to install their own FAS server as it lets us ship the database changes in a way that is easy for those users to apply to their own production databases. However, it doesn't work very well in our particular environment because we're a bit more strict about our permissions than the migrate authors envision. In order to perform migrations, you need to have a user that can modify the schema for the db. This is either hte owner of the db or the superuser. In our setup, we create the db with the superuser and then run our web apps with another user. This prevents the normal web app from modifying the db schema. To work around this I propose writing a script that does this: # 1) Create a db user. # 2) grant access to all the values in the specified db # 3) run the migrate commands to create the manage.py script and run it with the new username and password # 4) Reassign any new tables to the postgres user # 5) Remove the temporary db user The command line to invoke it would then look like this: sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO Does this look: 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate commands will be and if there's any caveats to this 2) Secure -- the point of this would be to keep protecting the db superuser with a sudo account on db2 and not being able to use it without a shell on db2. If the security of this solution is less than what giving a password to a superuser account would be then we might as well do that instead. If this looks good, I'll work on coding something up. -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 Sat Aug 9 18:05:49 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 9 Aug 2008 13:05:49 -0500 (CDT) Subject: RFC: script to run sqlalchemy migrations on the db In-Reply-To: <489CFE2C.3040801@gmail.com> References: <489CFE2C.3040801@gmail.com> Message-ID: On Fri, 8 Aug 2008, Toshio Kuratomi wrote: > FAS started using the python-migrate package to update its db. This is a good > thing for third-parties that want to install their own FAS server as it lets > us ship the database changes in a way that is easy for those users to apply to > their own production databases. > > However, it doesn't work very well in our particular environment because we're > a bit more strict about our permissions than the migrate authors envision. In > order to perform migrations, you need to have a user that can modify the > schema for the db. This is either hte owner of the db or the superuser. In > our setup, we create the db with the superuser and then run our web apps with > another user. This prevents the normal web app from modifying the db schema. > A classic complaint I have between dev's and sysadmin's. I think what you have below is good, generally sysadmins don't want to install a bunch of python libraries on the database for a specific application. > To work around this I propose writing a script that does this: > # 1) Create a db user. > # 2) grant access to all the values in the specified db > # 3) run the migrate commands to create the manage.py script and run it with > the new username and password > # 4) Reassign any new tables to the postgres user > # 5) Remove the temporary db user > > The command line to invoke it would then look like this: > > sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO > > Does this look: > 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate > commands will be and if there's any caveats to this > > 2) Secure -- the point of this would be to keep protecting the db superuser > with a sudo account on db2 and not being able to use it without a shell on > db2. If the security of this solution is less than what giving a password to > a superuser account would be then we might as well do that instead. > > If this looks good, I'll work on coding something up. > I'd almost have the sysadmins run a command on one of the app servers that has workflow like this 1) pre upgrade check 2) Prompt the user to run a command on the database server, cut and paste. 3) click OK or agree or something 4) Perform upgrade 5) If possible, have the upgrade script remove the user created in step 2, otherwise prompt 6) win. I think those steps work with the steps you outlined above. I'm curious what others think? -Mike From gradyfausta at laksmono.com Sun Aug 10 02:27:07 2008 From: gradyfausta at laksmono.com (Grady Laksmono) Date: Sat, 9 Aug 2008 19:27:07 -0700 Subject: Introduction Message-ID: Hello, My name is Grady Laksmono, and I've been becoming Fedora Ambassador for a while now, and since I've a technical background, I'd love to contribute to Fedora infrastructure and/or anything related with source code.. :) Nice to meet all of you Cheers, Grady -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sun Aug 10 15:17:23 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 Aug 2008 08:17:23 -0700 Subject: RFC: script to run sqlalchemy migrations on the db In-Reply-To: References: <489CFE2C.3040801@gmail.com> Message-ID: <489F0683.3040203@gmail.com> Mike McGrath wrote: > On Fri, 8 Aug 2008, Toshio Kuratomi wrote: >> # 1) Create a db user. >> # 2) grant access to all the values in the specified db >> # 3) run the migrate commands to create the manage.py script and run it with >> the new username and password >> # 4) Reassign any new tables to the postgres user >> # 5) Remove the temporary db user >> >> The command line to invoke it would then look like this: >> >> sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO >> >> Does this look: >> 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate >> commands will be and if there's any caveats to this >> >> 2) Secure -- the point of this would be to keep protecting the db superuser >> with a sudo account on db2 and not being able to use it without a shell on >> db2. If the security of this solution is less than what giving a password to >> a superuser account would be then we might as well do that instead. >> >> If this looks good, I'll work on coding something up. >> > > I'd almost have the sysadmins run a command on one of the app servers that > has workflow like this > > 1) pre upgrade check > 2) Prompt the user to run a command on the database server, cut and paste. > 3) click OK or agree or something > 4) Perform upgrade > 5) If possible, have the upgrade script remove the user created in step 2, > otherwise prompt > 6) win. > > I think those steps work with the steps you outlined above. I'm curious > what others think? The additions sound reasonable:: app2 $ migrate-runner -h db2 -d fas2 /usr/share/fas/database This script must create a temporary db user, fas2temp on db2. That user will have permission to modify anything in the fas2 database. If you stop this script in the middle of running you will want to remove the created user from the db. To continue, enter your password for sudo on db2: Running: ssh db2 pg_temp_user --verbose --create fas2 pg_temp_user: checking for db fas2... yes [sudo -u postgres psql select from pg_users where name = 'fas2temp'] pg_temp_user: checking for existing fas2temp... no [if yes, then abort and have the admin remove the account, check for other issues, etc] pg_temp_user: generating password... success pg_temp_user: create fas2temp... success [sudo -u postgres cat temppasswdfile | sudo -u postgres createuser fas2temp -P -E && sudo -u postgres rm temppasswdfile || sudo -u postgres rm temppasswdfile] pg_temp_user: setting fas2temp permissions on fas2 [echo "grant all on fas2 to fas2temp" | sudo -u postgres psql fas2] [print fas2temp passwd to stdout which migrate-runner captures] Received password for fas2temp Running migrate [various script invocations that loupgaroublond helps me create] Running: ssh db2 pg_temp_user --verbose --remove fas2 pg_temp_user: checking for db fas2... yes pg_temp_user: checking for existing fas2temp... yes pg_temp_user: removing fas2temp... success Successfully upgraded database -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 a.badger at gmail.com Sun Aug 10 15:25:43 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 Aug 2008 08:25:43 -0700 Subject: Introduction In-Reply-To: References: Message-ID: <489F0877.2080600@gmail.com> Grady Laksmono wrote: > Hello, > My name is Grady Laksmono, and I've been becoming Fedora Ambassador for > a while now, and since I've a technical background, I'd love to > contribute to Fedora infrastructure and/or anything related with source > code.. :) > Hi Grady! I tend to deal with most of the large coding projects in Infrastructure. Welcome aboard! Are you a python programmer? We have a large number of apps written in python and are always looking for new people to help out there. If not, what are your interests? I'll see if we can match you up with a project that needs your skills! -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 gradyfausta at laksmono.com Sun Aug 10 17:50:04 2008 From: gradyfausta at laksmono.com (Grady Laksmono) Date: Sun, 10 Aug 2008 10:50:04 -0700 Subject: Introduction In-Reply-To: <489F0877.2080600@gmail.com> References: <489F0877.2080600@gmail.com> Message-ID: Hi Toshio, The main language that I use for programming is Java, but I've just in love with Python and has been programming with it about 10 weeks ago for a game project using Panda 3D game engine. I'm definitely interested to do work with codes, using Python and/or any other languages such as C/C++, PHP, and Java. I listed my previous experiences (in which most of the time deal with the web development), and my technical skills at http://laksmono.com/curriculum-vitae/ I checked out https://fedorahosted.org, and I'm interested with the Amber project (https://fedorahosted.org/amber/) by reading its description. I thought that it would be very helpful to have this feature to be released in Fedora 10. Cheers, Grady Laksmono www.laksmono.com 2008/8/10 Toshio Kuratomi > Grady Laksmono wrote: > >> Hello, >> My name is Grady Laksmono, and I've been becoming Fedora Ambassador for a >> while now, and since I've a technical background, I'd love to contribute to >> Fedora infrastructure and/or anything related with source code.. :) >> >> Hi Grady! > > I tend to deal with most of the large coding projects in Infrastructure. > Welcome aboard! > > Are you a python programmer? We have a large number of apps written in > python and are always looking for new people to help out there. If not, > what are your interests? I'll see if we can match you up with a project > that needs your skills! > > -Toshio > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sun Aug 10 22:54:18 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 Aug 2008 15:54:18 -0700 Subject: Introduction In-Reply-To: References: <489F0877.2080600@gmail.com> Message-ID: <489F719A.2030509@gmail.com> Grady Laksmono wrote: > Hi Toshio, > The main language that I use for programming is Java, but I've just in > love with Python and has been programming with it about 10 weeks ago for > a game project using Panda 3D game engine. I'm definitely interested to > do work with codes, using Python and/or any other languages such as > C/C++, PHP, and Java. I listed my previous experiences (in which most of > the time deal with the web development), and my technical skills at > http://laksmono.com/curriculum-vitae/ > > I checked out https://fedorahosted.org, and I'm interested with the > Amber project (https://fedorahosted.org/amber/) by reading its > description. I thought that it would be very helpful to have this > feature to be released in Fedora 10. > Excellent! Robin Norwood is the lead developer of amber. I've CC'd him. Robin, do you have any python work for a new contributor to get their feet wet with the amber code? -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 loupgaroublond at gmail.com Mon Aug 11 07:55:16 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 11 Aug 2008 09:55:16 +0200 Subject: RFC: script to run sqlalchemy migrations on the db In-Reply-To: <489CFE2C.3040801@gmail.com> References: <489CFE2C.3040801@gmail.com> Message-ID: <7f692fec0808110055t53f8d8e1r2c81ce62e5fbae8f@mail.gmail.com> 2008/8/9 Toshio Kuratomi : > FAS started using the python-migrate package to update its db. This is a > good thing for third-parties that want to install their own FAS server as it > lets us ship the database changes in a way that is easy for those users to > apply to their own production databases. > > However, it doesn't work very well in our particular environment because > we're a bit more strict about our permissions than the migrate authors > envision. In order to perform migrations, you need to have a user that can > modify the schema for the db. This is either hte owner of the db or the > superuser. In our setup, we create the db with the superuser and then run > our web apps with another user. This prevents the normal web app from > modifying the db schema. > > To work around this I propose writing a script that does this: > # 1) Create a db user. > # 2) grant access to all the values in the specified db > # 3) run the migrate commands to create the manage.py script and run it with > the new username and password > # 4) Reassign any new tables to the postgres user > # 5) Remove the temporary db user > > The command line to invoke it would then look like this: > > sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO > > Does this look: > 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate > commands will be and if there's any caveats to this > > 2) Secure -- the point of this would be to keep protecting the db superuser > with a sudo account on db2 and not being able to use it without a shell on > db2. If the security of this solution is less than what giving a password > to a superuser account would be then we might as well do that instead. > > If this looks good, I'll work on coding something up. I don't see how this is any more secure than just either granting some user sudo or creating a long term admin DB role just for the FAS DB that is well protected. As I see it: 1) the FAS run time itself has not been security audited and vetted, therefore the least damage it can do to the DB the better. 2) Most of the admins, or rather the people in charge of upgrading FAS on our servers have been security audited and vetted through a system of mutual respect in a meritocracy. Why do we need a temporary superuser account every time we upgrade? 3) If we store the long term superuser account for FAS somewhere so upgrade scripts can be done automatically, then all I think we need is some SELinux / file perm policy that prevents FAS from accessing those files itself. As for feasibility, I don't think the migrate scripts themselves can create new users on the fly, nor do I think that's where we want to do it. We probably want to create per project wrappers that get called instead of manage.py. Have we spoken to upstream about this yet too? Or maybe I just need to wake up more, and I'll get it. -Yaakov From cra at WPI.EDU Mon Aug 11 14:30:12 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 11 Aug 2008 10:30:12 -0400 Subject: bugzilla down? Message-ID: <20080811143012.GA26527@angus.ind.WPI.EDU> I'm getting 503 Service Temporarily Unavailable from bugzilla.redhat.com. From mmcgrath at redhat.com Mon Aug 11 14:31:00 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Aug 2008 09:31:00 -0500 (CDT) Subject: RFC: script to run sqlalchemy migrations on the db In-Reply-To: <7f692fec0808110055t53f8d8e1r2c81ce62e5fbae8f@mail.gmail.com> References: <489CFE2C.3040801@gmail.com> <7f692fec0808110055t53f8d8e1r2c81ce62e5fbae8f@mail.gmail.com> Message-ID: On Mon, 11 Aug 2008, Yaakov Nemoy wrote: > 2008/8/9 Toshio Kuratomi : > > FAS started using the python-migrate package to update its db. This is a > > good thing for third-parties that want to install their own FAS server as it > > lets us ship the database changes in a way that is easy for those users to > > apply to their own production databases. > > > > However, it doesn't work very well in our particular environment because > > we're a bit more strict about our permissions than the migrate authors > > envision. In order to perform migrations, you need to have a user that can > > modify the schema for the db. This is either hte owner of the db or the > > superuser. In our setup, we create the db with the superuser and then run > > our web apps with another user. This prevents the normal web app from > > modifying the db schema. > > > > To work around this I propose writing a script that does this: > > # 1) Create a db user. > > # 2) grant access to all the values in the specified db > > # 3) run the migrate commands to create the manage.py script and run it with > > the new username and password > > # 4) Reassign any new tables to the postgres user > > # 5) Remove the temporary db user > > > > The command line to invoke it would then look like this: > > > > sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO > > > > Does this look: > > 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate > > commands will be and if there's any caveats to this > > > > 2) Secure -- the point of this would be to keep protecting the db superuser > > with a sudo account on db2 and not being able to use it without a shell on > > db2. If the security of this solution is less than what giving a password > > to a superuser account would be then we might as well do that instead. > > > > If this looks good, I'll work on coding something up. > > I don't see how this is any more secure than just either granting some > user sudo or creating a long term admin DB role just for the FAS DB > that is well protected. > You must be a developer ;-) > As I see it: > > 1) the FAS run time itself has not been security audited and vetted, > therefore the least damage it can do to the DB the better. Even if it had... You shouldn't consider it 'secure'. We've done plenty of audits. AFAIK there is no industry standard for vetting. > 2) Most of the admins, or rather the people in charge of upgrading FAS > on our servers have been security audited and vetted through a system > of mutual respect in a meritocracy. Why do we need a temporary > superuser account every time we upgrade? Those users don't have db accounts, fas does. And we don't want to give the fas user more rights then it needs. > 3) If we store the long term superuser account for FAS somewhere so > upgrade scripts can be done automatically, then all I think we need is > some SELinux / file perm policy that prevents FAS from accessing those > files itself. > If the upgrade script can create a temporary user and get rid of it. Why risk having that account used during a non-upgrade time. I'm fine with using SElinux as a backup to primary security policies. But using SELinux as a primary security of some kind. No thanks, we've had to disable it in the past for various reasons before we were able to re-enable it even in permissive mode. -Mike From mmcgrath at redhat.com Mon Aug 11 14:31:41 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Aug 2008 09:31:41 -0500 (CDT) Subject: bugzilla down? In-Reply-To: <20080811143012.GA26527@angus.ind.WPI.EDU> References: <20080811143012.GA26527@angus.ind.WPI.EDU> Message-ID: On Mon, 11 Aug 2008, Chuck Anderson wrote: > I'm getting 503 Service Temporarily Unavailable from > bugzilla.redhat.com. > There were some major network issues today. I'm not sure the specifics yet but the various teams in charge of those services are aware and working on it. -Mike From loupgaroublond at gmail.com Mon Aug 11 15:30:03 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 11 Aug 2008 17:30:03 +0200 Subject: RFC: script to run sqlalchemy migrations on the db In-Reply-To: References: <489CFE2C.3040801@gmail.com> <7f692fec0808110055t53f8d8e1r2c81ce62e5fbae8f@mail.gmail.com> Message-ID: <7f692fec0808110830w430a68abvf68ee07acae2426f@mail.gmail.com> On Mon, Aug 11, 2008 at 4:31 PM, Mike McGrath wrote: > On Mon, 11 Aug 2008, Yaakov Nemoy wrote: > >> 2008/8/9 Toshio Kuratomi : >> > FAS started using the python-migrate package to update its db. This is a >> > good thing for third-parties that want to install their own FAS server as it >> > lets us ship the database changes in a way that is easy for those users to >> > apply to their own production databases. >> > >> > However, it doesn't work very well in our particular environment because >> > we're a bit more strict about our permissions than the migrate authors >> > envision. In order to perform migrations, you need to have a user that can >> > modify the schema for the db. This is either hte owner of the db or the >> > superuser. In our setup, we create the db with the superuser and then run >> > our web apps with another user. This prevents the normal web app from >> > modifying the db schema. >> > >> > To work around this I propose writing a script that does this: >> > # 1) Create a db user. >> > # 2) grant access to all the values in the specified db >> > # 3) run the migrate commands to create the manage.py script and run it with >> > the new username and password >> > # 4) Reassign any new tables to the postgres user >> > # 5) Remove the temporary db user >> > >> > The command line to invoke it would then look like this: >> > >> > sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO >> > >> > Does this look: >> > 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate >> > commands will be and if there's any caveats to this >> > >> > 2) Secure -- the point of this would be to keep protecting the db superuser >> > with a sudo account on db2 and not being able to use it without a shell on >> > db2. If the security of this solution is less than what giving a password >> > to a superuser account would be then we might as well do that instead. >> > >> > If this looks good, I'll work on coding something up. >> >> I don't see how this is any more secure than just either granting some >> user sudo or creating a long term admin DB role just for the FAS DB >> that is well protected. >> > > You must be a developer ;-) > >> As I see it: >> >> 1) the FAS run time itself has not been security audited and vetted, >> therefore the least damage it can do to the DB the better. > > Even if it had... You shouldn't consider it 'secure'. We've done plenty > of audits. AFAIK there is no industry standard for vetting. > >> 2) Most of the admins, or rather the people in charge of upgrading FAS >> on our servers have been security audited and vetted through a system >> of mutual respect in a meritocracy. Why do we need a temporary >> superuser account every time we upgrade? > > Those users don't have db accounts, fas does. And we don't want to give > the fas user more rights then it needs. > >> 3) If we store the long term superuser account for FAS somewhere so >> upgrade scripts can be done automatically, then all I think we need is >> some SELinux / file perm policy that prevents FAS from accessing those >> files itself. >> > > If the upgrade script can create a temporary user and get rid of it. Why > risk having that account used during a non-upgrade time. I'm fine with > using SElinux as a backup to primary security policies. But using SELinux > as a primary security of some kind. No thanks, we've had to disable it in > the past for various reasons before we were able to re-enable it even in > permissive mode. I see then. My recommendation is to have an outside wrapper that just takes random db url stuff, including a superuser username and password, creates a new superuser, passes the new user to migrate.py and lets migrate.py take over from there. It's doable, I just don't see what security we gain, over having certain dedicated users (namely toshio and/or ricky) who are the only ones who can run migrate.py, using the superuser password. -Yaakov From ianweller at gmail.com Mon Aug 11 15:47:15 2008 From: ianweller at gmail.com (Ian Weller) Date: Mon, 11 Aug 2008 10:47:15 -0500 Subject: bugzilla down? In-Reply-To: <20080811143012.GA26527@angus.ind.WPI.EDU> References: <20080811143012.GA26527@angus.ind.WPI.EDU> Message-ID: <20080811154715.GA27760@gmail.com> On Mon, Aug 11, 2008 at 10:30:12AM -0400, Chuck Anderson wrote: > I'm getting 503 Service Temporarily Unavailable from > bugzilla.redhat.com. > I've seen these happening periodically (downtimes of about 2 minutes each) since the Bugzilla was upgraded last week. -- 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 -------------- 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 Mon Aug 11 15:55:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Aug 2008 10:55:40 -0500 (CDT) Subject: bugzilla down? In-Reply-To: <20080811154715.GA27760@gmail.com> References: <20080811143012.GA26527@angus.ind.WPI.EDU> <20080811154715.GA27760@gmail.com> Message-ID: On Mon, 11 Aug 2008, Ian Weller wrote: > On Mon, Aug 11, 2008 at 10:30:12AM -0400, Chuck Anderson wrote: > > I'm getting 503 Service Temporarily Unavailable from > > bugzilla.redhat.com. > > > I've seen these happening periodically (downtimes of about 2 minutes > each) since the Bugzilla was upgraded last week. > Could be unrelated to the network stuff today then. I'll send a ticket. -Mike From mmcgrath at redhat.com Mon Aug 11 16:34:01 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Aug 2008 11:34:01 -0500 (CDT) Subject: *.fedoraproject.org Message-ID: We now have a *.fedoraproject.org wildcard cert. This will make creating websites significantly easier. We already have some plans for the translated wiki and such. I'm going to be implementing this cert soon for much of our infrastructure. My tests worked fine but just the same, conversion to production might produce some cert oddness. Please do keep your eyes open. I've never worked with a wildcard cert before and right now plain old "fedoraproject.org" doesn't work. This makes sense but I'm wondering if anyone knows a way around it. Is it not possible to create a cert for your entire domain as you'll always have at least a *.example.com and a root "example.com" cert? correct me if I'm wrong on that. -Mike From mmcgrath at redhat.com Mon Aug 11 16:35:45 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Aug 2008 11:35:45 -0500 (CDT) Subject: bugzilla down? In-Reply-To: <20080811154715.GA27760@gmail.com> References: <20080811143012.GA26527@angus.ind.WPI.EDU> <20080811154715.GA27760@gmail.com> Message-ID: On Mon, 11 Aug 2008, Ian Weller wrote: > On Mon, Aug 11, 2008 at 10:30:12AM -0400, Chuck Anderson wrote: > > I'm getting 503 Service Temporarily Unavailable from > > bugzilla.redhat.com. > > > I've seen these happening periodically (downtimes of about 2 minutes > each) since the Bugzilla was upgraded last week. > Ok, here's the scoop. They are seeing the same thing and its a multi-team effort to try to fix it. I'm not sure about the specifics but they are aware and working on it. -Mike From a.badger at gmail.com Mon Aug 11 16:43:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 11 Aug 2008 09:43:55 -0700 Subject: RFC: script to run sqlalchemy migrations on the db In-Reply-To: <489F0683.3040203@gmail.com> References: <489CFE2C.3040801@gmail.com> <489F0683.3040203@gmail.com> Message-ID: <48A06C4B.5030305@gmail.com> Toshio Kuratomi wrote: > > app2 $ migrate-runner -h db2 -d fas2 /usr/share/fas/database > This script must create a temporary db user, fas2temp on db2. > That user will have permission to modify anything in the fas2 database. > If you stop this script in the middle of running you will want to remove > the created user from the db. > To continue, enter your password for sudo on db2: > > Running: ssh db2 pg_temp_user --verbose --create fas2 > pg_temp_user: checking for db fas2... yes > [sudo -u postgres psql select from pg_users where name = 'fas2temp'] > pg_temp_user: checking for existing fas2temp... no > [if yes, then abort and have the admin remove the account, check for > other issues, etc] > pg_temp_user: generating password... success > pg_temp_user: create fas2temp... success > [sudo -u postgres cat temppasswdfile | sudo -u postgres createuser > fas2temp -P -E && sudo -u postgres rm temppasswdfile || sudo -u postgres > rm temppasswdfile] > pg_temp_user: setting fas2temp permissions on fas2 > [echo "grant all on fas2 to fas2temp" | sudo -u postgres psql fas2] > [print fas2temp passwd to stdout which migrate-runner captures] > Received password for fas2temp > Running migrate > [various script invocations that loupgaroublond helps me create] > Running: ssh db2 pg_temp_user --verbose --remove fas2 > pg_temp_user: checking for db fas2... yes > pg_temp_user: checking for existing fas2temp... yes [One more step needed here:] pg_temp_user: updating table ownership to postgres... success [This detects all the tables in the fas2 db and reassigns ownership from the fas2temp user to the database superuser.] > pg_temp_user: removing fas2temp... success > Successfully upgraded database > > -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 opensource at till.name Mon Aug 11 17:29:54 2008 From: opensource at till.name (Till Maas) Date: Mon, 11 Aug 2008 19:29:54 +0200 Subject: *.fedoraproject.org In-Reply-To: References: Message-ID: <200808111930.00096.opensource@till.name> On Mon August 11 2008, Mike McGrath wrote: > We now have a *.fedoraproject.org wildcard cert. This will make creating Yippie, this is superp. > I've never worked with a wildcard cert before and right now plain old > "fedoraproject.org" doesn't work. This makes sense but I'm wondering if > anyone knows a way around it. Is it not possible to create a cert for > your entire domain as you'll always have at least a *.example.com and a > root "example.com" cert? correct me if I'm wrong on that. The best documentation I know is this, but I did not search for it recently: https://wiki.cacert.org/wiki/VhostTaskForce Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Mon Aug 11 19:54:13 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 11 Aug 2008 14:54:13 -0500 (CDT) Subject: DNS serial number Message-ID: Should the first serial number for a day be 00 or 01? EX: 2008081001 or 2008081000 -Mike From skvidal at fedoraproject.org Mon Aug 11 19:56:44 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 11 Aug 2008 15:56:44 -0400 Subject: DNS serial number In-Reply-To: References: Message-ID: <1218484604.18047.10.camel@rosebud> On Mon, 2008-08-11 at 14:54 -0500, Mike McGrath wrote: > Should the first serial number for a day be 00 or 01? EX: > > 2008081001 or 2008081000 > 01 imo -sv From roland at redhat.com Mon Aug 11 20:03:47 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 11 Aug 2008 13:03:47 -0700 (PDT) Subject: DNS serial number In-Reply-To: Mike McGrath's message of Monday, 11 August 2008 14:54:13 -0500 References: Message-ID: <20080811200347.118A0154272@magilla.localdomain> Uh, who cares? It should be at least one less than the number for the second zone update of the day. ;-) The elisp mode I use for zone files does 0. When in doubt, start a 0/1-origin flame war just for the hell of it. From kanarip at kanarip.com Mon Aug 11 20:04:03 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 11 Aug 2008 22:04:03 +0200 Subject: DNS serial number In-Reply-To: References: Message-ID: <48A09B33.4060106@kanarip.com> Mike McGrath wrote: > Should the first serial number for a day be 00 or 01? EX: > > 2008081001 or 2008081000 > Common practice is 01, along with (usually) appending your (account) name to the '; serial (mmcgrath)' in case you want other people with the same amount of control over the zone to be able to track down who made the last change. -Jeroen From gvarisco at redhat.com Mon Aug 11 20:16:05 2008 From: gvarisco at redhat.com (Gianluca Varisco) Date: Mon, 11 Aug 2008 22:16:05 +0200 Subject: DNS serial number In-Reply-To: References: Message-ID: <48A09E05.1010603@redhat.com> Mike McGrath wrote: > Should the first serial number for a day be 00 or 01? EX: > > 2008081001 or 2008081000 > > -Mike > I always use 01 as first serial number for a day ;-) Cheers, -- Gianluca Varisco, RHCE Intern - Web Engineering, Red Hat Italia Tel.: +39 02 5681 4487 Fax : +39 02 669 3111 Cel.: +39 333 574 0934 Address/Indirizzo: Via Antonio Da Recanate 1 20124 Milano From rordway at oregonstate.edu Mon Aug 11 20:30:38 2008 From: rordway at oregonstate.edu (Ryan Ordway) Date: Mon, 11 Aug 2008 13:30:38 -0700 Subject: DNS serial number In-Reply-To: <48A09E05.1010603@redhat.com> References: <48A09E05.1010603@redhat.com> Message-ID: <3E2074ED-ACF7-47CF-A443-BF00CFEF380C@oregonstate.edu> On Aug 11, 2008, at 1:16 PM, Gianluca Varisco wrote: > Mike McGrath wrote: >> Should the first serial number for a day be 00 or 01? EX: >> 2008081001 or 2008081000 >> -Mike > > I always use 01 as first serial number for a day ;-) 01 FTW! -- Ryan Ordway E-mail: rordway at oregonstate.edu Unix Systems Administrator rordway at library.oregonstate.edu OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657 From ebrown at redhat.com Tue Aug 12 13:03:28 2008 From: ebrown at redhat.com (Eric Brown) Date: Tue, 12 Aug 2008 09:03:28 -0400 Subject: *.fedoraproject.org In-Reply-To: References: Message-ID: <48A18A20.406@redhat.com> Mike McGrath wrote: > We now have a *.fedoraproject.org wildcard cert. This will make creating > websites significantly easier. We already have some plans for the > translated wiki and such. I'm going to be implementing this cert soon for > much of our infrastructure. My tests worked fine but just the same, > conversion to production might produce some cert oddness. Please do keep > your eyes open. > > I've never worked with a wildcard cert before and right now plain old > "fedoraproject.org" doesn't work. This makes sense but I'm wondering if > anyone knows a way around it. Is it not possible to create a cert for > your entire domain as you'll always have at least a *.example.com and a > root "example.com" cert? correct me if I'm wrong on that. You are correct. You must have the *.domain CERT *and* the root domain CERT. No way around it. -- Eric Brown | Manager, Information Services | Red Hat, Inc. (o) +1.404.442.2033 (c) +1.404.964.6062 | Key ID: 0xA092F823 GPG: B8E5 9D48 5ECC 09BD 160E 4698 52EC 3DCB A092 F823 From rnorwood at redhat.com Tue Aug 12 17:55:46 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 13:55:46 -0400 Subject: Public demo of amber and eventual production instance In-Reply-To: <20080725140741.190bad5f@solitude.devel.redhat.com> References: <20080725140741.190bad5f@solitude.devel.redhat.com> Message-ID: <20080812135546.01c5e02f@solitude.devel.redhat.com> On Fri, 25 Jul 2008 14:07:41 -0400 Robin Norwood wrote: > 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? Ping - what do I need to do to get moving on hosting resources for Amber/Fedora Applications? (Note: It hasn't yet been approved as a Feature, it's up for approval during Wednesday's FESCO meeting. Ticket: https://fedorahosted.org/fedora-infrastructure/ticket/666 -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 Aug 12 17:58:57 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 12:58:57 -0500 (CDT) Subject: publictest10 Message-ID: publictest10 is our most heavily used test server and it has OOMed a few times. We have a couple of options. 1) move pt10 somewhere where it will have more ram (preferably outside of PHX) 2) create new pt servers 3) move some apps off of pt10 and on to other test servers I generally lean towards 1. Anyone have any preferences? Has anyone done an audit of the box in a while to see what the big memory hogs are? -Mike From mmcgrath at redhat.com Tue Aug 12 18:23:22 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 13:23:22 -0500 (CDT) Subject: Public demo of amber and eventual production instance In-Reply-To: <20080812135546.01c5e02f@solitude.devel.redhat.com> References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> Message-ID: On Tue, 12 Aug 2008, Robin Norwood wrote: > On Fri, 25 Jul 2008 14:07:41 -0400 > Robin Norwood wrote: > > > 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? > > Ping - what do I need to do to get moving on hosting resources for > Amber/Fedora Applications? (Note: It hasn't yet been approved as a > Feature, it's up for approval during Wednesday's FESCO meeting. > as in have it hosted in a production supported / backed-up instance at a location like https://admin.fedoraproject.org/amber/ ? If so work with your project sponsor. -Mike From ricky at fedoraproject.org Tue Aug 12 19:41:47 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 12 Aug 2008 15:41:47 -0400 Subject: publictest10 In-Reply-To: References: Message-ID: <20080812194147.GA4885@Max> On 2008-08-12 12:58:57 PM, Mike McGrath wrote: > publictest10 is our most heavily used test server and it has OOMed a few > times. We have a couple of options. > > 1) move pt10 somewhere where it will have more ram (preferably outside of > PHX) > > 2) create new pt servers > > 3) move some apps off of pt10 and on to other test servers I'd kind of lean towards rebuilding pt10 as well if we're going to be shuffling apps around. It's been around for a pretty long time, and it's gotten in kind of a weird state (I had FAS problems on pt10 that I wasn't able to reproduce anywhere else, which is why I had to move to pt9). Although I'm just as curious about what it was, rebuilding may be the most efficient solution. 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 stickster at gmail.com Tue Aug 12 20:33:32 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 12 Aug 2008 20:33:32 +0000 Subject: Tasks and followup Message-ID: <1218573212.4986.72.camel@victoria> Apologies for this being an idea with no code attached. I'm hoping that some of the able folks are on this list and will see something achievable. Something the Community Architecture folks and I have discovered is that when we sign up new folks for an account, there's not any way to mark them for follow up or to indicate a note for where they did it. A couple methods for doing this come to mind: 1. Simple but effective -- a way to tag account holders arbitrarily. This might help with a number of things, like skill sets, karma, and so forth. In this case, the tag would allow Ambassadors to follow up on particular shows by listing everyone with "FooCon 2008" in their tag list. 2. More complicated but possibly more predictable -- A plugin for FAS that would allow ambassadors to request or create a special signup portal, and use it at a show to help visitors sign up (e.g. join.fp.o/foocon2008 or foocon2008.join.fp.o). -- 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 mmcgrath at redhat.com Tue Aug 12 20:52:39 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 15:52:39 -0500 (CDT) Subject: Tasks and followup In-Reply-To: <1218573212.4986.72.camel@victoria> References: <1218573212.4986.72.camel@victoria> Message-ID: On Tue, 12 Aug 2008, Paul W. Frields wrote: > Apologies for this being an idea with no code attached. I'm hoping that > some of the able folks are on this list and will see something > achievable. > > Something the Community Architecture folks and I have discovered is that > when we sign up new folks for an account, there's not any way to mark > them for follow up or to indicate a note for where they did it. A > couple methods for doing this come to mind: > > 1. Simple but effective -- a way to tag account holders arbitrarily. > This might help with a number of things, like skill sets, karma, and so > forth. In this case, the tag would allow Ambassadors to follow up on > particular shows by listing everyone with "FooCon 2008" in their tag > list. > > 2. More complicated but possibly more predictable -- A plugin for FAS > that would allow ambassadors to request or create a special signup > portal, and use it at a show to help visitors sign up (e.g. > join.fp.o/foocon2008 or foocon2008.join.fp.o). > I'd say 2 is pretty easy in a plugin. https://admin.fedoraproject.org/accounts/promo/sign-up/MyPromo where MyPromo could just be arbitrary. It'd get flagged somewhere that we could get it later. The point of this is so users can sign up with some sort of flag on how they found out about Fedora, and then run stats on it later? -Mike From stickster at gmail.com Tue Aug 12 21:07:30 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 12 Aug 2008 21:07:30 +0000 Subject: Tasks and followup In-Reply-To: References: <1218573212.4986.72.camel@victoria> Message-ID: <1218575250.4986.88.camel@victoria> On Tue, 2008-08-12 at 15:52 -0500, Mike McGrath wrote: > On Tue, 12 Aug 2008, Paul W. Frields wrote: > > > Apologies for this being an idea with no code attached. I'm hoping that > > some of the able folks are on this list and will see something > > achievable. > > > > Something the Community Architecture folks and I have discovered is that > > when we sign up new folks for an account, there's not any way to mark > > them for follow up or to indicate a note for where they did it. A > > couple methods for doing this come to mind: > > > > 1. Simple but effective -- a way to tag account holders arbitrarily. > > This might help with a number of things, like skill sets, karma, and so > > forth. In this case, the tag would allow Ambassadors to follow up on > > particular shows by listing everyone with "FooCon 2008" in their tag > > list. > > > > 2. More complicated but possibly more predictable -- A plugin for FAS > > that would allow ambassadors to request or create a special signup > > portal, and use it at a show to help visitors sign up (e.g. > > join.fp.o/foocon2008 or foocon2008.join.fp.o). > > > > I'd say 2 is pretty easy in a plugin. > > https://admin.fedoraproject.org/accounts/promo/sign-up/MyPromo > > where MyPromo could just be arbitrary. It'd get flagged somewhere that we > could get it later. > > The point of this is so users can sign up with some sort of flag on how > they found out about Fedora, and then run stats on it later? Not just stats, but also to get people "assigned" geographically to Ambassadors or some other mentor group, in a way that makes sense and maximizes stickiness. -- 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 mmcgrath at redhat.com Tue Aug 12 21:47:54 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 16:47:54 -0500 (CDT) Subject: Tasks and followup In-Reply-To: <1218575250.4986.88.camel@victoria> References: <1218573212.4986.72.camel@victoria> <1218575250.4986.88.camel@victoria> Message-ID: On Tue, 12 Aug 2008, Paul W. Frields wrote: > On Tue, 2008-08-12 at 15:52 -0500, Mike McGrath wrote: > > On Tue, 12 Aug 2008, Paul W. Frields wrote: > > > > > Apologies for this being an idea with no code attached. I'm hoping that > > > some of the able folks are on this list and will see something > > > achievable. > > > > > > Something the Community Architecture folks and I have discovered is that > > > when we sign up new folks for an account, there's not any way to mark > > > them for follow up or to indicate a note for where they did it. A > > > couple methods for doing this come to mind: > > > > > > 1. Simple but effective -- a way to tag account holders arbitrarily. > > > This might help with a number of things, like skill sets, karma, and so > > > forth. In this case, the tag would allow Ambassadors to follow up on > > > particular shows by listing everyone with "FooCon 2008" in their tag > > > list. > > > > > > 2. More complicated but possibly more predictable -- A plugin for FAS > > > that would allow ambassadors to request or create a special signup > > > portal, and use it at a show to help visitors sign up (e.g. > > > join.fp.o/foocon2008 or foocon2008.join.fp.o). > > > > > > > I'd say 2 is pretty easy in a plugin. > > > > https://admin.fedoraproject.org/accounts/promo/sign-up/MyPromo > > > > where MyPromo could just be arbitrary. It'd get flagged somewhere that we > > could get it later. > > > > The point of this is so users can sign up with some sort of flag on how > > they found out about Fedora, and then run stats on it later? > > Not just stats, but also to get people "assigned" geographically to > Ambassadors or some other mentor group, in a way that makes sense and > maximizes stickiness. > So something more exact then timezone, locale and country or could this metric bet completely independent of those values? -Mike From mmcgrath at redhat.com Tue Aug 12 21:50:42 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 16:50:42 -0500 (CDT) Subject: Tasks and followup In-Reply-To: References: <1218573212.4986.72.camel@victoria> <1218575250.4986.88.camel@victoria> Message-ID: On Tue, 12 Aug 2008, Mike McGrath wrote: > On Tue, 12 Aug 2008, Paul W. Frields wrote: > > > On Tue, 2008-08-12 at 15:52 -0500, Mike McGrath wrote: > > > On Tue, 12 Aug 2008, Paul W. Frields wrote: > > > > > > > Apologies for this being an idea with no code attached. I'm hoping that > > > > some of the able folks are on this list and will see something > > > > achievable. > > > > > > > > Something the Community Architecture folks and I have discovered is that > > > > when we sign up new folks for an account, there's not any way to mark > > > > them for follow up or to indicate a note for where they did it. A > > > > couple methods for doing this come to mind: > > > > > > > > 1. Simple but effective -- a way to tag account holders arbitrarily. > > > > This might help with a number of things, like skill sets, karma, and so > > > > forth. In this case, the tag would allow Ambassadors to follow up on > > > > particular shows by listing everyone with "FooCon 2008" in their tag > > > > list. > > > > > > > > 2. More complicated but possibly more predictable -- A plugin for FAS > > > > that would allow ambassadors to request or create a special signup > > > > portal, and use it at a show to help visitors sign up (e.g. > > > > join.fp.o/foocon2008 or foocon2008.join.fp.o). > > > > > > > > > > I'd say 2 is pretty easy in a plugin. > > > > > > https://admin.fedoraproject.org/accounts/promo/sign-up/MyPromo > > > > > > where MyPromo could just be arbitrary. It'd get flagged somewhere that we > > > could get it later. > > > > > > The point of this is so users can sign up with some sort of flag on how > > > they found out about Fedora, and then run stats on it later? > > > > Not just stats, but also to get people "assigned" geographically to > > Ambassadors or some other mentor group, in a way that makes sense and > > maximizes stickiness. > > > > So something more exact then timezone, locale and country or could this > metric bet completely independent of those values? > Another note on that, if we split up the ambassadors into regions (I suspect they already are) would it be better to just create a group for each region managed by the ambassadors? -Mike From lmacken at redhat.com Tue Aug 12 22:19:15 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 12 Aug 2008 18:19:15 -0400 Subject: Tasks and followup In-Reply-To: <1218573212.4986.72.camel@victoria> References: <1218573212.4986.72.camel@victoria> Message-ID: <20080812221915.GG3675@x300> On Tue, Aug 12, 2008 at 08:33:32PM +0000, Paul W. Frields wrote: > Apologies for this being an idea with no code attached. I'm hoping that > some of the able folks are on this list and will see something > achievable. > > Something the Community Architecture folks and I have discovered is that > when we sign up new folks for an account, there's not any way to mark > them for follow up or to indicate a note for where they did it. A > couple methods for doing this come to mind: > > 1. Simple but effective -- a way to tag account holders arbitrarily. > This might help with a number of things, like skill sets, karma, and so > forth. In this case, the tag would allow Ambassadors to follow up on > particular shows by listing everyone with "FooCon 2008" in their tag > list. We could possibly do this by using the 'myfedora' application namespace that already exists in the FAS person config model. Each user in the db can have a list of configs for a variety of different apps (currently hardcoded to asterisk, moin, myfedora, and openid). For MyFedora we were thinking about storing various widget settings in this field, but the namespace has not yet been decided on. I'm not familiar with the FAS codebase, but we may be able to do something like this:: from fas.model import Person, Configs Person.configs.append( Configs(application='myfedora', value="{ 'tags' : ['FUDCon2008Boston'], 'skills': ['python', 'c++', 'trolling'], 'karma' : -8, }")) luke From stickster at gmail.com Tue Aug 12 23:43:40 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 12 Aug 2008 19:43:40 -0400 Subject: [Fwd: Re: Tasks and followup] Message-ID: <1218584620.3756.11.camel@victoria> -------- Forwarded Message -------- > On Tue, 12 Aug 2008, Mike McGrath wrote: > > On Tue, 12 Aug 2008, Paul W. Frields wrote: > > > On Tue, 2008-08-12 at 15:52 -0500, Mike McGrath wrote: > > > > On Tue, 12 Aug 2008, Paul W. Frields wrote: > > > > > > > > > Apologies for this being an idea with no code attached. I'm hoping that > > > > > some of the able folks are on this list and will see something > > > > > achievable. > > > > > > > > > > Something the Community Architecture folks and I have discovered is that > > > > > when we sign up new folks for an account, there's not any way to mark > > > > > them for follow up or to indicate a note for where they did it. A > > > > > couple methods for doing this come to mind: > > > > > > > > > > 1. Simple but effective -- a way to tag account holders arbitrarily. > > > > > This might help with a number of things, like skill sets, karma, and so > > > > > forth. In this case, the tag would allow Ambassadors to follow up on > > > > > particular shows by listing everyone with "FooCon 2008" in their tag > > > > > list. > > > > > > > > > > 2. More complicated but possibly more predictable -- A plugin for FAS > > > > > that would allow ambassadors to request or create a special signup > > > > > portal, and use it at a show to help visitors sign up (e.g. > > > > > join.fp.o/foocon2008 or foocon2008.join.fp.o). > > > > > > > > > > > > > I'd say 2 is pretty easy in a plugin. > > > > > > > > https://admin.fedoraproject.org/accounts/promo/sign-up/MyPromo > > > > > > > > where MyPromo could just be arbitrary. It'd get flagged somewhere that we > > > > could get it later. > > > > > > > > The point of this is so users can sign up with some sort of flag on how > > > > they found out about Fedora, and then run stats on it later? > > > > > > Not just stats, but also to get people "assigned" geographically to > > > Ambassadors or some other mentor group, in a way that makes sense and > > > maximizes stickiness. > > > > > > > So something more exact then timezone, locale and country or could this > > metric bet completely independent of those values? > > > > Another note on that, if we split up the ambassadors into regions (I > suspect they already are) would it be better to just create a group for > each region managed by the ambassadors? We could create FAS groups for regions, sure. But there's also particular ambassadors to consider -- for example, an Ambassador who works on Websites might target a new signup for helping with Websites, even though that new person lives in a different country. Maybe groups plus the portal plugin would do the trick. I'll ask around with the Ambassadors. -- 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 Wed Aug 13 00:29:55 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 13 Aug 2008 12:29:55 +1200 Subject: Public demo of amber and eventual production instance In-Reply-To: References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> Message-ID: <1218587395.2767.1.camel@fantail.jnet.net.nz> On Tue, 2008-08-12 at 13:23 -0500, Mike McGrath wrote: > On Tue, 12 Aug 2008, Robin Norwood wrote: > > > On Fri, 25 Jul 2008 14:07:41 -0400 > > Robin Norwood wrote: > > > > > 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? > > > > Ping - what do I need to do to get moving on hosting resources for > > Amber/Fedora Applications? (Note: It hasn't yet been approved as a > > Feature, it's up for approval during Wednesday's FESCO meeting. > > > > as in have it hosted in a production supported / backed-up instance at a > location like https://admin.fedoraproject.org/amber/ ? If so work with > your project sponsor. Surely it'd be better suited as 'amber.fedoraproject.org', or something like that, hopefully I'll be back later today/tomorrow to help if needed. (Note, we'd need to get the wildcard cert on the proxy servers first, but that's not too bigger deal) > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From ricky at fedoraproject.org Wed Aug 13 00:37:49 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 12 Aug 2008 20:37:49 -0400 Subject: Public demo of amber and eventual production instance In-Reply-To: <1218587395.2767.1.camel@fantail.jnet.net.nz> References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> Message-ID: <20080813003749.GB4885@Max> On 2008-08-13 12:29:55 PM, Nigel Jones wrote: > Surely it'd be better suited as 'amber.fedoraproject.org', or something > like that, hopefully I'll be back later today/tomorrow to help if > needed. If it requires auth, we'll probably want it at admin.fedoraproject.org so that it can share cookies with our other applications. 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 Aug 13 01:09:20 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 20:09:20 -0500 (CDT) Subject: Public demo of amber and eventual production instance In-Reply-To: <20080813003749.GB4885@Max> References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> <20080813003749.GB4885@Max> Message-ID: On Tue, 12 Aug 2008, Ricky Zhou wrote: > On 2008-08-13 12:29:55 PM, Nigel Jones wrote: > > Surely it'd be better suited as 'amber.fedoraproject.org', or something > > like that, hopefully I'll be back later today/tomorrow to help if > > needed. > If it requires auth, we'll probably want it at admin.fedoraproject.org > so that it can share cookies with our other applications. > it is probably time to better describe what goes where and why. I'm fond of the admin.fedoraproject.org/blah/ for stuff. But if this is an application that end users will be using that doesn't seem quite right. -Mike From mmcgrath at redhat.com Wed Aug 13 01:10:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 12 Aug 2008 20:10:46 -0500 (CDT) Subject: [Fwd: Re: Tasks and followup] In-Reply-To: <1218584620.3756.11.camel@victoria> References: <1218584620.3756.11.camel@victoria> Message-ID: On Tue, 12 Aug 2008, Paul W. Frields wrote: --- Snips some cleanup --- > > We could create FAS groups for regions, sure. But there's also > particular ambassadors to consider -- for example, an Ambassador who > works on Websites might target a new signup for helping with Websites, > even though that new person lives in a different country. > > Maybe groups plus the portal plugin would do the trick. I'll ask around > with the Ambassadors. > When people sponsor someone we do track that. But for a group of sponsors we're not. -Mie From ricky at fedoraproject.org Wed Aug 13 01:15:40 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 12 Aug 2008 21:15:40 -0400 Subject: Public demo of amber and eventual production instance In-Reply-To: References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> <20080813003749.GB4885@Max> Message-ID: <20080813011540.GC4885@Max> On 2008-08-12 08:09:20 PM, Mike McGrath wrote: > it is probably time to better describe what goes where and why. I'm fond > of the admin.fedoraproject.org/blah/ for stuff. But if this is an > application that end users will be using that doesn't seem quite right. Hmm, I wonder if this could lead into a discussion of whether FAS accounts are generally targetted towards 100% end users as well and if end user apps should have the possibility of separate auth (OpenID would be really cool for this). 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 Aug 13 02:31:25 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 22:31:25 -0400 Subject: Public demo of amber and eventual production instance In-Reply-To: References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> <20080813003749.GB4885@Max> Message-ID: <20080812223125.693f5f5e@solitude.devel.redhat.com> On Tue, 12 Aug 2008 20:09:20 -0500 (CDT) Mike McGrath wrote: > On Tue, 12 Aug 2008, Ricky Zhou wrote: > > > On 2008-08-13 12:29:55 PM, Nigel Jones wrote: > > > Surely it'd be better suited as 'amber.fedoraproject.org', or > > > something like that, hopefully I'll be back later today/tomorrow > > > to help if needed. > > If it requires auth, we'll probably want it at > > admin.fedoraproject.org so that it can share cookies with our other > > applications. > > > > it is probably time to better describe what goes where and why. I'm > fond of the admin.fedoraproject.org/blah/ for stuff. But if this is > an application that end users will be using that doesn't seem quite > right. Yes, it isn't really a fedora 'admin' app. As you said, it's targeted at end users. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From mmcgrath at redhat.com Wed Aug 13 06:49:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 13 Aug 2008 01:49:47 -0500 (CDT) Subject: Public demo of amber and eventual production instance In-Reply-To: <20080812223125.693f5f5e@solitude.devel.redhat.com> References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> <20080813003749.GB4885@Max> <20080812223125.693f5f5e@solitude.devel.redhat.com> Message-ID: On Tue, 12 Aug 2008, Robin Norwood wrote: > On Tue, 12 Aug 2008 20:09:20 -0500 (CDT) > Mike McGrath wrote: > > > On Tue, 12 Aug 2008, Ricky Zhou wrote: > > > > > On 2008-08-13 12:29:55 PM, Nigel Jones wrote: > > > > Surely it'd be better suited as 'amber.fedoraproject.org', or > > > > something like that, hopefully I'll be back later today/tomorrow > > > > to help if needed. > > > If it requires auth, we'll probably want it at > > > admin.fedoraproject.org so that it can share cookies with our other > > > applications. > > > > > > > it is probably time to better describe what goes where and why. I'm > > fond of the admin.fedoraproject.org/blah/ for stuff. But if this is > > an application that end users will be using that doesn't seem quite > > right. > > Yes, it isn't really a fedora 'admin' app. As you said, it's targeted > at end users. > Does it have an authed interface for admins or does it pull everything from our repos and such? -Mike From dev at nigelj.com Wed Aug 13 08:45:30 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 13 Aug 2008 20:45:30 +1200 Subject: Wiki Outage Notification - 2008-08-14 03:00 UTC & 2008-08-15 03:00 UTC Message-ID: <1218617130.2767.23.camel@fantail.jnet.net.nz> There will be an outage starting at 2008-08-14 03:00 UTC, which will last approximately 1 hour. A second outage is scheduled to start at 2008-08-15 03:00 UTC lasting approximately 30 minutes. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-08-14 03:00 UTC' date -d '2008-08-15 03:00 UTC' Affected Services: Fedora Project Wiki Unaffected Services: All Other Websites CVS / Source Control Buildsystem Database DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/754 Reason for Outage: We will be performing database changes to the wiki database to enable searching by default for specific categories and to switch to the internal authentication methods. We hope to be able to leave the wiki Read Only during both outages. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. Thanks, Nigel Jones From Matt_Domsch at dell.com Wed Aug 13 13:16:14 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 13 Aug 2008 08:16:14 -0500 Subject: MM metalinks plan Message-ID: <20080813131614.GA1939@auslistsprd01.us.dell.com> A quick note following my hints on IRC. I've been working on adding metalinks to MirrorManager, and think it's in pretty good shape. A few nits left (what type of doc to return on error, if any, and adding back in the date-generated fields with proper format after conversation with the upstream metalink maintainer). Note, I don't expect yum for < F10 to be able to make use of metalinks, but I'm hoping, with Seth's help, to get the necessary bits into yum "soonish". Which brings me to my next point. I'm on vacation, and essentially unreachable, starting Friday night 8/15, returning Sunday 8/24. So, rather than push this into production and then duck out, I'm going to hold off until after I'm back. Hopefully the production instances of MM won't fall over while I'm out, but if so, people know how to reach me, and I can arrange limited connectivity as needed (and as my DTs from being disconnected drive me back...) Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rnorwood at redhat.com Wed Aug 13 14:45:19 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 13 Aug 2008 10:45:19 -0400 Subject: Public demo of amber and eventual production instance In-Reply-To: References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> <20080813003749.GB4885@Max> <20080812223125.693f5f5e@solitude.devel.redhat.com> Message-ID: <20080813104519.1bbdd681@solitude.devel.redhat.com> On Wed, 13 Aug 2008 01:49:47 -0500 (CDT) Mike McGrath wrote: > On Tue, 12 Aug 2008, Robin Norwood wrote: > > > On Tue, 12 Aug 2008 20:09:20 -0500 (CDT) > > Mike McGrath wrote: > > > > > On Tue, 12 Aug 2008, Ricky Zhou wrote: > > > > > > > On 2008-08-13 12:29:55 PM, Nigel Jones wrote: > > > > > Surely it'd be better suited as 'amber.fedoraproject.org', or > > > > > something like that, hopefully I'll be back later > > > > > today/tomorrow to help if needed. > > > > If it requires auth, we'll probably want it at > > > > admin.fedoraproject.org so that it can share cookies with our > > > > other applications. > > > > > > > > > > it is probably time to better describe what goes where and why. > > > I'm fond of the admin.fedoraproject.org/blah/ for stuff. But if > > > this is an application that end users will be using that doesn't > > > seem quite right. > > > > Yes, it isn't really a fedora 'admin' app. As you said, it's > > targeted at end users. > > > > Does it have an authed interface for admins or does it pull everything > from our repos and such? It auth against FAS. First, anyone with a FAS account can log in, and post comments and whatnot. Second, if the user happens to own a package that provides a given application, she can edit the app's description, and do things like delete comments and screenshots. Third, if a user is a member of the 'amber_admins' group, he can do the above for all apps, and a few other things. Does that answer your question? -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From mmcgrath at redhat.com Wed Aug 13 17:03:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 13 Aug 2008 12:03:09 -0500 (CDT) Subject: Public demo of amber and eventual production instance In-Reply-To: <20080813104519.1bbdd681@solitude.devel.redhat.com> References: <20080725140741.190bad5f@solitude.devel.redhat.com> <20080812135546.01c5e02f@solitude.devel.redhat.com> <1218587395.2767.1.camel@fantail.jnet.net.nz> <20080813003749.GB4885@Max> <20080812223125.693f5f5e@solitude.devel.redhat.com> <20080813104519.1bbdd681@solitude.devel.redhat.com> Message-ID: On Wed, 13 Aug 2008, Robin Norwood wrote: > On Wed, 13 Aug 2008 01:49:47 -0500 (CDT) > Mike McGrath wrote: > > > On Tue, 12 Aug 2008, Robin Norwood wrote: > > > > > On Tue, 12 Aug 2008 20:09:20 -0500 (CDT) > > > Mike McGrath wrote: > > > > > > > On Tue, 12 Aug 2008, Ricky Zhou wrote: > > > > > > > > > On 2008-08-13 12:29:55 PM, Nigel Jones wrote: > > > > > > Surely it'd be better suited as 'amber.fedoraproject.org', or > > > > > > something like that, hopefully I'll be back later > > > > > > today/tomorrow to help if needed. > > > > > If it requires auth, we'll probably want it at > > > > > admin.fedoraproject.org so that it can share cookies with our > > > > > other applications. > > > > > > > > > > > > > it is probably time to better describe what goes where and why. > > > > I'm fond of the admin.fedoraproject.org/blah/ for stuff. But if > > > > this is an application that end users will be using that doesn't > > > > seem quite right. > > > > > > Yes, it isn't really a fedora 'admin' app. As you said, it's > > > targeted at end users. > > > > > > > Does it have an authed interface for admins or does it pull everything > > from our repos and such? > > It auth against FAS. First, anyone with a FAS account can log in, and > post comments and whatnot. Second, if the user happens to own a > package that provides a given application, she can edit the app's > description, and do things like delete comments and screenshots. > Third, if a user is a member of the 'amber_admins' group, he can do the > above for all apps, and a few other things. > > Does that answer your question? > Yep, thanks. -Mike From orion at cora.nwra.com Wed Aug 13 23:12:11 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 13 Aug 2008 17:12:11 -0600 Subject: Wiki migration Message-ID: <48A36A4B.7080207@cora.nwra.com> Would it be possible to get a hold of any scripts/software used in the migration of fedoraproject.org to MediaWiki? Thanks... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From mmcgrath at redhat.com Wed Aug 13 23:58:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 13 Aug 2008 18:58:15 -0500 (CDT) Subject: Wiki migration In-Reply-To: <48A36A4B.7080207@cora.nwra.com> References: <48A36A4B.7080207@cora.nwra.com> Message-ID: On Wed, 13 Aug 2008, Orion Poplawski wrote: > Would it be possible to get a hold of any scripts/software used in the > migration of fedoraproject.org to MediaWiki? Thanks... > They could use a little love but they're at: http://git.fedorahosted.org/git/fedora-infrastructure.git/?p=fedora-infrastructure.git;a=tree;f=scripts/moin2mw;h=56537b7f646f079fd80e58b573ecab031157ac1f;hb=HEAD -Mike From mmcgrath at redhat.com Fri Aug 15 01:48:11 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 14 Aug 2008 20:48:11 -0500 (CDT) Subject: So everyone is aware Message-ID: We have a lot of work ahead of us. http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html From dev at nigelj.com Fri Aug 15 04:08:14 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 15 Aug 2008 16:08:14 +1200 Subject: So everyone is aware In-Reply-To: References: Message-ID: <1218773294.6714.4.camel@fantail.jnet.net.nz> On Thu, 2008-08-14 at 20:48 -0500, Mike McGrath wrote: > We have a lot of work ahead of us. > Thanks for the warning, I look forward to helping! > http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Nigel Jones From graeme at graemef.net Sun Aug 17 19:13:46 2008 From: graeme at graemef.net (Graeme Fowler) Date: Sun, 17 Aug 2008 20:13:46 +0100 Subject: So everyone is aware In-Reply-To: References: Message-ID: <1219000426.1278.2.camel@ernie.internal.graemef.net> Hi Long-time lurker, first time poster... On Thu, 2008-08-14 at 20:48 -0500, Mike McGrath wrote: > We have a lot of work ahead of us. It's all gone very quiet on this list, and there's only been Paul's "We're working on it" update to -announce. Given the number of Fedora boxes I'm currently directly or indirectly responsible for, the lull in chatter is making me feel very nervous indeed. Without wanting to sound rude or pushy - what's really going on behind the scenes here? Thanks, and apologies if everyone is head-down in a stew of tasks right now (especially on a Sunday). Graeme From mmcgrath at redhat.com Sun Aug 17 22:43:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 17 Aug 2008 17:43:18 -0500 (CDT) Subject: So everyone is aware In-Reply-To: <1218773294.6714.4.camel@fantail.jnet.net.nz> References: <1218773294.6714.4.camel@fantail.jnet.net.nz> Message-ID: On Fri, 15 Aug 2008, Nigel Jones wrote: > On Thu, 2008-08-14 at 20:48 -0500, Mike McGrath wrote: > > We have a lot of work ahead of us. > > > Thanks for the warning, I look forward to helping! Ok, I've started allowing access again where we can. Right now sysadmin-web has been notified of some things. More groups to follow. -Mike From orion at cora.nwra.com Mon Aug 18 18:02:32 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 18 Aug 2008 12:02:32 -0600 Subject: Old matplotlib bugzilla component Message-ID: <48A9B938.8090505@cora.nwra.com> I found the source of my matplotlib confusion. Apparently there is still an old "maplotlib" Fedora component. Can this be removed? The package is "python-matplotlib" in fedora. Thanks! (Please CC me, list delivery is disabled) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Axel.Thimm at ATrpms.net Tue Aug 19 08:29:43 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Aug 2008 11:29:43 +0300 Subject: FAS password reset mail not arriving Message-ID: <20080819082943.GA26020@victor.nirvana> Hi, as per the mailed instructions I submitted a password reset by entering account & mail into the FAS web portal. But I never received the mail with the URL reset. Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From aphukan.fedora at gmail.com Tue Aug 19 08:35:13 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Tue, 19 Aug 2008 14:05:13 +0530 Subject: FAS password reset mail not arriving In-Reply-To: <20080819082943.GA26020@victor.nirvana> References: <20080819082943.GA26020@victor.nirvana> Message-ID: <48AA85C1.5030705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > Hi, > > as per the mailed instructions I submitted a password reset by > entering account & mail into the FAS web portal. But I never received > the mail with the URL reset. > > Thanks! > > ---------------------------------------------------------------------- > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list hi, it takes time... mine took almost an hour .. as far as i know, there are lots of requests queued up. so be patient. regards, amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiqhb4ACgkQisV6fTFpwA3DJQCgpgV0/aIk5u1RYpBA90pq788+ nLAAmwe5LbX2xzKNPcOgMok9CDj0yr0k =rzze -----END PGP SIGNATURE----- From nicu_fedora at nicubunu.ro Tue Aug 19 08:42:40 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 19 Aug 2008 11:42:40 +0300 Subject: FAS password reset mail not arriving In-Reply-To: <20080819082943.GA26020@victor.nirvana> References: <20080819082943.GA26020@victor.nirvana> Message-ID: <48AA8780.407@nicubunu.ro> Axel Thimm wrote: > > as per the mailed instructions I submitted a password reset by > entering account & mail into the FAS web portal. But I never received > the mail with the URL reset. Speaking of password reset, the other day I logged into FAS and was informed by the application about a password reset request, received the mail, followed the link and changed my password. Only to find today in my inbox the (mass) email informing me that I need to reset my password or else in 15 days my account will be deleted. This is confusing, as my password was just reset so I took the assumption that it was just a mass message, not one sent only to those that did not reset their passwords. But anyway, just for my peace of mind, logged into FAS and saw it not complained like the other day about my password. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From dev at nigelj.com Tue Aug 19 08:44:28 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 19 Aug 2008 20:44:28 +1200 Subject: FAS password reset mail not arriving In-Reply-To: <20080819082943.GA26020@victor.nirvana> References: <20080819082943.GA26020@victor.nirvana> Message-ID: <1219135468.28853.5.camel@fantail.jnet.net.nz> On Tue, 2008-08-19 at 11:29 +0300, Axel Thimm wrote: > Hi, > > as per the mailed instructions I submitted a password reset by > entering account & mail into the FAS web portal. But I never received > the mail with the URL reset. I just noted this in the topic of #fedora-admin. Due to having thousands of accounts in FAS we have to be careful that we don't flood the pipes too much. As a result our mail queue is VERY full at the moment, and password reset e-mails are getting tacked onto the end. You will get your password reset e-mail, I assure you (I see plenty of them in the queue), if you get multiple, only the last reset e-mail will work. We really apologize for this, but there is a fine art in getting e-mail servers sending at the right pace, and we don't want Google etc to start thinking we only exist to spam people. - Nigel -- Nigel Jones From Axel.Thimm at ATrpms.net Tue Aug 19 08:58:14 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 19 Aug 2008 11:58:14 +0300 Subject: FAS password reset mail not arriving In-Reply-To: <1219135468.28853.5.camel@fantail.jnet.net.nz> References: <20080819082943.GA26020@victor.nirvana> <1219135468.28853.5.camel@fantail.jnet.net.nz> Message-ID: <20080819085814.GB26238@victor.nirvana> Hi, On Tue, Aug 19, 2008 at 08:44:28PM +1200, Nigel Jones wrote: > On Tue, 2008-08-19 at 11:29 +0300, Axel Thimm wrote: > > as per the mailed instructions I submitted a password reset by > > entering account & mail into the FAS web portal. But I never received > > the mail with the URL reset. > I just noted this in the topic of #fedora-admin. Due to having > thousands of accounts in FAS we have to be careful that we don't flood > the pipes too much. As a result our mail queue is VERY full at the > moment, and password reset e-mails are getting tacked onto the end. > > You will get your password reset e-mail, I assure you (I see plenty of > them in the queue), if you get multiple, only the last reset e-mail will > work. > > We really apologize for this, but there is a fine art in getting e-mail > servers sending at the right pace, and we don't want Google etc to start > thinking we only exist to spam people. OK, thanks for clarifying. BTW I did not submit a request multiple times, if you see plenty of request for me in the queue then something is wrong. Also being hosting quite a few multi-thousand lists: Sending out even the exact same mail a couple of thousand times at a high rate doesn't yet mark you as a spammer, this is also true of the large lists @redhat.com. Although I highly appreciate any act of caution these days! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dev at nigelj.com Tue Aug 19 09:02:31 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 19 Aug 2008 21:02:31 +1200 Subject: FAS password reset mail not arriving In-Reply-To: <20080819085814.GB26238@victor.nirvana> References: <20080819082943.GA26020@victor.nirvana> <1219135468.28853.5.camel@fantail.jnet.net.nz> <20080819085814.GB26238@victor.nirvana> Message-ID: <1219136551.28853.10.camel@fantail.jnet.net.nz> On Tue, 2008-08-19 at 11:58 +0300, Axel Thimm wrote: > Hi, > > On Tue, Aug 19, 2008 at 08:44:28PM +1200, Nigel Jones wrote: > > On Tue, 2008-08-19 at 11:29 +0300, Axel Thimm wrote: > > > as per the mailed instructions I submitted a password reset by > > > entering account & mail into the FAS web portal. But I never received > > > the mail with the URL reset. > > I just noted this in the topic of #fedora-admin. Due to having > > thousands of accounts in FAS we have to be careful that we don't flood > > the pipes too much. As a result our mail queue is VERY full at the > > moment, and password reset e-mails are getting tacked onto the end. > > > > You will get your password reset e-mail, I assure you (I see plenty of > > them in the queue), if you get multiple, only the last reset e-mail will > > work. > > > > We really apologize for this, but there is a fine art in getting e-mail > > servers sending at the right pace, and we don't want Google etc to start > > thinking we only exist to spam people. > > OK, thanks for clarifying. BTW I did not submit a request multiple > times, if you see plenty of request for me in the queue then something > is wrong. Errr I didn't actually check to see what was going to you, I was making a rash generalization to * that if you request multiple then only the last will work :) > > Also being hosting quite a few multi-thousand lists: Sending out even > the exact same mail a couple of thousand times at a high rate > doesn't yet mark you as a spammer, this is also true of the large > lists @redhat.com. Although I highly appreciate any act of caution > these days! Good point, but yeah, not really that good to flood the pipes. - Nigel -- Nigel Jones From mike at mikemccarthy.co.uk Tue Aug 19 13:29:40 2008 From: mike at mikemccarthy.co.uk (mike at mikemccarthy.co.uk) Date: Tue, 19 Aug 2008 15:29:40 +0200 Subject: Introduction Message-ID: <21010061.22861219152580328.JavaMail.servlet@kundenserver> Hi, I'm Mike McCarthy, a sysadmin by day and general geek by night from the UK.? I mainly work with RHEL, TRU64 and recently some AIX but tend to mess around with Fedora in my free time.? I recently became an RHCE and have been looking for further excuses to develop my Linux skills and just a chance to contribute somehow so here I am.? I look forwards to helping and getting to know a few of you. M -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Tue Aug 19 14:56:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 19 Aug 2008 09:56:48 -0500 (CDT) Subject: FAS password reset mail not arriving In-Reply-To: <1219136551.28853.10.camel@fantail.jnet.net.nz> References: <20080819082943.GA26020@victor.nirvana> <1219135468.28853.5.camel@fantail.jnet.net.nz> <20080819085814.GB26238@victor.nirvana> <1219136551.28853.10.camel@fantail.jnet.net.nz> Message-ID: On Tue, 19 Aug 2008, Nigel Jones wrote: > Good point, but yeah, not really that good to flood the pipes. > Yeah, this was by far the most email we've sent at a single time. we've got over 11,000 accounts in FAS now. Sounds like we need to look at our smtp setup. Verify for sure how many emails we can send at a time. Then make sure our mass mailing scripts can do that. Also, the the host that our smtp server is on is... very busy right now, db servers ,app servers, etc are all on there while we're getting stuff back online :) Even with all that stuff going on I'm amazed at how responsive everything is and how low the load generally is. -Mike From bugs.michael at gmx.net Wed Aug 20 13:50:24 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 20 Aug 2008 15:50:24 +0200 Subject: Fw: Returned mail: see transcript for details In-Reply-To: References: <20080722230749.a9c678da.bugs.michael@gmx.net> Message-ID: <20080820155024.a8e12db1.bugs.michael@gmx.net> On Tue, 22 Jul 2008 22:10:33 -0500 (CDT), Mike McGrath wrote: > 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. This is back, now with a traceback upon commit. smtplib.SMTPRecipientsRefused: {'cvsextras at fedora.redhat.com': (550, '5.1.1 : Recipient address rejected: User unknown in local recipient table')} > > ----- The following addresses had permanent fatal errors ----- > > > > (reason: 554 5.7.1 : Relay access denied) From a.badger at gmail.com Thu Aug 21 18:44:41 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 Aug 2008 11:44:41 -0700 Subject: securing FAS certs Message-ID: <48ADB799.3070206@gmail.com> Hey bright idea bringers! The Fedora Certificates issued by FAS are currently set to be autogenerated if you have an account in FAS. This has one drawback. We have to keep the password for the CA keys that sign the FAS certificates in a file on the filesystem so that the automatic signing can use them. Has anyone else had to confront this problem? Right now I'm thinking of coding something that involves human interaction to sign the certs and send email notifying people when their cert is ready to download. That's certainly doable, but introduces a wait time that isn't in the current design. I'd love input on better ways to do this. -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 jeff at ocjtech.us Thu Aug 21 19:18:49 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 21 Aug 2008 14:18:49 -0500 Subject: securing FAS certs In-Reply-To: <48ADB799.3070206@gmail.com> References: <48ADB799.3070206@gmail.com> Message-ID: <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> 2008/8/21 Toshio Kuratomi : > > The Fedora Certificates issued by FAS are currently set to be autogenerated > if you have an account in FAS. This has one drawback. We have to keep the > password for the CA keys that sign the FAS certificates in a file on the > filesystem so that the automatic signing can use them. > > Has anyone else had to confront this problem? Right now I'm thinking of > coding something that involves human interaction to sign the certs and send > email notifying people when their cert is ready to download. That's > certainly doable, but introduces a wait time that isn't in the current > design. I'd love input on better ways to do this. What about using a crypto card like Jesse plans on using for Sigul? Jeff From mmcgrath at redhat.com Thu Aug 21 19:21:34 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 21 Aug 2008 14:21:34 -0500 (CDT) Subject: securing FAS certs In-Reply-To: <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> Message-ID: On Thu, 21 Aug 2008, Jeffrey Ollie wrote: > 2008/8/21 Toshio Kuratomi : > > > > The Fedora Certificates issued by FAS are currently set to be autogenerated > > if you have an account in FAS. This has one drawback. We have to keep the > > password for the CA keys that sign the FAS certificates in a file on the > > filesystem so that the automatic signing can use them. > > > > Has anyone else had to confront this problem? Right now I'm thinking of > > coding something that involves human interaction to sign the certs and send > > email notifying people when their cert is ready to download. That's > > certainly doable, but introduces a wait time that isn't in the current > > design. I'd love input on better ways to do this. > > What about using a crypto card like Jesse plans on using for Sigul? > I've never actually used a crypto card... Do they add additional security if they're sitting in a colo always plugged in? If so how do they do that? -Mike From ricky at fedoraproject.org Thu Aug 21 19:34:38 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 21 Aug 2008 15:34:38 -0400 Subject: securing FAS certs In-Reply-To: References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> Message-ID: <20080821193438.GD31338@sphe.res.cmu.edu> On 2008-08-21 02:21:34 PM, Mike McGrath wrote: > I've never actually used a crypto card... Do they add additional security > if they're sitting in a colo always plugged in? If so how do they do > that? I might be wrong, but I think with such a card, encryption/signing takes place entirely on the card, and thus the secret key is never transferred anywhere off the card. 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 Thu Aug 21 19:40:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 21 Aug 2008 14:40:58 -0500 (CDT) Subject: securing FAS certs In-Reply-To: <20080821193438.GD31338@sphe.res.cmu.edu> References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> <20080821193438.GD31338@sphe.res.cmu.edu> Message-ID: On Thu, 21 Aug 2008, Ricky Zhou wrote: > On 2008-08-21 02:21:34 PM, Mike McGrath wrote: > > I've never actually used a crypto card... Do they add additional security > > if they're sitting in a colo always plugged in? If so how do they do > > that? > I might be wrong, but I think with such a card, encryption/signing takes > place entirely on the card, and thus the secret key is never transferred > anywhere off the card. > Ah, so the theory being that if someone happens to hit us, they're only hitting us for as long as the machine is up / card is in. And I assume the card actually tracks serial numbers and things so we can revoke anything that was signed in a questionable time? -Mike From jeff at ocjtech.us Thu Aug 21 19:25:17 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 21 Aug 2008 14:25:17 -0500 Subject: securing FAS certs In-Reply-To: References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> Message-ID: <935ead450808211225o62fa1a1y445e78e51fb5879@mail.gmail.com> On Thu, Aug 21, 2008 at 2:21 PM, Mike McGrath wrote: > On Thu, 21 Aug 2008, Jeffrey Ollie wrote: >> What about using a crypto card like Jesse plans on using for Sigul? > > I've never actually used a crypto card... Do they add additional security > if they're sitting in a colo always plugged in? If so how do they do > that? I'm not sure either, but the impression that I get is that while you can get the crypto card to sign certificates, you can't extract the private key from it. Jeff From a.badger at gmail.com Thu Aug 21 20:22:28 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 21 Aug 2008 13:22:28 -0700 Subject: securing FAS certs In-Reply-To: References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> <20080821193438.GD31338@sphe.res.cmu.edu> Message-ID: <48ADCE84.6050608@gmail.com> Mike McGrath wrote: > On Thu, 21 Aug 2008, Ricky Zhou wrote: > >> On 2008-08-21 02:21:34 PM, Mike McGrath wrote: >>> I've never actually used a crypto card... Do they add additional security >>> if they're sitting in a colo always plugged in? If so how do they do >>> that? >> I might be wrong, but I think with such a card, encryption/signing takes >> place entirely on the card, and thus the secret key is never transferred >> anywhere off the card. >> > > Ah, so the theory being that if someone happens to hit us, they're only > hitting us for as long as the machine is up / card is in. And I assume > the card actually tracks serial numbers and things so we can revoke > anything that was signed in a questionable time? > That seems like it would work well. Jesse's been having troubles obtaining the card he wants, though (and his is a gpg card, not for ssl certificates). the big thing might be having open source drivers. -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 Thu Aug 21 20:30:04 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 21 Aug 2008 16:30:04 -0400 Subject: Warning: Email bounces from Saturday August 16th until Tuesday August 19th 2008 Message-ID: <1219350604.8530.178.camel@rosebud> Brief explanation: For a number of addresses @fedoraproject.org there were windows when those email addresses would have bounced reporting that the address did not exist. This happened as a result of the re-installation of the mail forwarding server. Please check all mailing list subscriptions to make sure you have not been inadvertently unsubscribed or disabled due to this error. Gory Details: During it's re-installation the postfix mail server was installed but it was not configured in the alternatives system so that its /usr/bin/newaliases command was the one being run. As a result sendmail's newaliases command was being run and it was changing the permissions of the aliases file such that postfix could not read it. It did not get noticed until Tuesday due to other issues taking precedence. The alias-generation would run once every 30 minutes. Breaking the aliases. Then our configuration management system would run on a slightly out-of-pace schedule with the aliases and correct the permissions. This problem has been corrected, sorry for the inconvenience. -sv -- I only speak for me. Friends don't let Friends use Sendmail From dev at nigelj.com Thu Aug 21 22:35:45 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 22 Aug 2008 10:35:45 +1200 Subject: Infrastructure IRC Log - 2008-08-21 Message-ID: <1219358145.3492.2.camel@fantail.jnet.net.nz> For those that missed it... Today's IRC Log 08:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 08:02 < G> I iz here :) 08:02 < jeremy> G: no you're not 08:02 < fchiulli> fchiulli: is here 08:03 * MrBawb / 08:03 < G> jeremy: bleh 08:03 * nirik is sitting in the nosebleed seats in the back 08:03 * ianweller 08:03 < G> jeremy: good point, I left my brain in the other Nigel :) 08:03 < jeremy> G: there's two nigels? I had been wondering how you got so much done :-) 08:04 < mmcgrath> Ok guys lets get started. 08:04 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- "Issues" 08:04 < mmcgrath> So yeah, i'd imagine lots of us here want to talk about these crazy issues that paul has notified everyone about. 08:04 < mmcgrath> Unfortunately all I can say right now is that it won't happen in this meeting and I'm sorry. I really am. 08:05 < ianweller> :( 08:05 < mmcgrath> It pains me to have to not comment but I just can't so for right now, this is just going to be a boring, normal meeting. :) 08:05 < G> fine my me 08:05 < G> *fine by me 08:05 < fchiulli> I'll just have to cry in my beer. :-) 08:05 < smooge> I still say its zombies 08:05 * mmcgrath loves my team. 08:05 * lmacken rolls in late 08:06 < ianweller> can you give us an ETA or is that even way out there 08:06 * abadger1999 here 08:06 < mmcgrath> I'm not going to ever be untruthful to you guys, really. So all I can say.. is that I can't say. 08:06 < ianweller> mmcgrath: thanks :) 08:06 < mmcgrath> ianweller: sorry, I can't give you a quantitiative answer like "in 2 days" or anything like that. 08:06 * dgilmore notes he is a zombie 08:06 < ianweller> damn 08:06 < mmcgrath> Ok, so. Lets look at the tickets. 08:06 * londo is here 08:07 < G> mmcgrath: we still have tickets? wow I forgot :P 08:07 < mmcgrath> oh and I think zodbot is mostly back up :) 08:07 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 08:07 < zodbot> (at fedorahosted.org) 08:07 < zodbot> mmcgrath: http://tinyurl.com/47e37y 08:07 < mmcgrath> boo zodbot. 08:07 -!- ianweller changed the topic of #fedora-meeting to: Infrastructure -- tickets 08:07 < ianweller> hah wow 08:07 < mmcgrath> :) 08:07 < mmcgrath> ok. 08:08 < mmcgrath> so lets do 08:08 < mmcgrath> .ticket 732 08:08 < mmcgrath> first 08:08 < zodbot> mmcgrath: #732 (Investigate New System Monitoring Methods) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/732 08:08 < mmcgrath> G: want to take this one? 08:08 < G> Yeah okay 08:09 < mmcgrath> so have at it. 08:09 < mmcgrath> I still see some segfaulting :) 08:09 < G> Right so Zabbix has been working okay, but I encountered some issues with the distributed monitoring in 1.4.x, looks like we'll need to use the 1.5.x branch (due to be 1.6 in September) 08:10 < rsc> G: Is Fedora Infrastructures' Zabbix already somewhere running? 08:10 < G> 1.6 allows us to set up Zabbix proxies on certain hosts to take some of the grunt work off noc1 but still only have one source of announcements etc 08:10 < G> (example is, VPN servers and noc2) 08:10 < mmcgrath> rsc: it is 08:11 < mmcgrath> rsc: along side our nagios install 08:11 < rsc> mmcgrath: URL? 08:11 < G> rsc: yeah, we've got an instance going, seems to be fairly stable 08:11 < mmcgrath> https://admin.fedoraproject.org/zabbix/ 08:11 < G> mmcgrath: btw segfaults? where? 08:11 < rsc> mmcgrath: btw I'm still lacking THAT infrastructure mail/explanation for the last week ;) 08:11 < lmacken> G: i've seen some on app1 08:11 < G> lmacken: rpm -q zabbix-agent? 08:11 < mmcgrath> G: I thought I saw some on bastion as well 08:12 < mmcgrath> skvidal: we should send an email out about that. Can you do that? 08:12 < lmacken> G: zabbix-agent-1.4.6-1.el5 08:12 < rsc> mmcgrath: but can't login with FAS data there... 08:12 < G> argh 08:12 < skvidal> mmcgrath: what do you want an email about? 08:12 < mmcgrath> rsc: correct. 08:12 < G> lmacken: I'll talk to jeff 08:12 < mmcgrath> skvidal: about why some mail was dropping and that some people have gotten unsubscribed from lists as a result of it. 08:12 < skvidal> mmcgrath: oh, you're just being a dick, I see 08:12 < skvidal> mmcgrath: oh - I see 08:13 < mmcgrath> skvidal: heh, no. there was really a problem and it affected people :) 08:13 < skvidal> mmcgrath: oh - I thought you were just screwing w/me 08:13 < mmcgrath> skvidal: sorry not right now :) 08:13 < skvidal> sorry 08:13 < skvidal> yah 08:13 < jcollie> eh, more segfaults? need to get everybody updated to the latest RPMs :) 08:13 < mmcgrath> no no on :) 08:13 < mmcgrath> G: did we get the new new rpm in the repo? 08:13 < skvidal> I can email to f-i 08:13 < skvidal> or does it need to go to announce? 08:13 < jcollie> G: no, I don't think so 08:13 < G> anyway, the two main points are, a full zabbix deployment will conflict with our infrastructure freeze 08:13 < mmcgrath> skvidal: I'd say devel-announce and f-i would be good. 08:14 < G> (for F10) 08:14 < rsc> mmcgrath: why? For nagios I was able to read the stuff at least. 08:14 < G> rsc: you still can 08:14 < G> rsc: Monitoring tab 08:14 < rsc> G: I would like to just read at zabbix. 08:14 < G> https://admin.fedoraproject.org/zabbix/dashboard.php 08:15 < G> mmcgrath: whats the proceedure for that? 08:15 < mmcgrath> G: sorry? to just read zabbix? 08:15 < skvidal> mmcgrath: what day were the bounces? All my days have run together 08:15 < skvidal> tuesday right? 08:15 < mmcgrath> skvidal: it was likely over a longer period of time then that. 08:15 < jcollie> i'd say that since the F10 beta is going to slip for a while we don't have to freeze just yet 08:15 < mmcgrath> no one reported it till tuesday though. 08:15 < skvidal> so I'll say sat -> tues 08:16 < G> mmcgrath: no, Infrastructure Frezze and a full scale zabbix deployment? 08:16 < mmcgrath> sure 08:16 < mmcgrath> G: oh, so the infrastructure freeze is still a bit out I'll get an exact day for that. 08:16 < mmcgrath> as far as the full scale zabbix deployment, we're lucky to have nagios up still so we can set it up in tandum. 08:17 < mmcgrath> as soon as the monitoring of nagios has been duplicated. I'd say we just... tell people to setup their alerts. 08:17 < jcollie> i don't think that rel-eng knows when beta will be out since they can't do any builds or composes yet 08:17 < G> mmcgrath: roger that 08:17 < mmcgrath> jcollie: until I hear otherwise. The schedule hasn't shipped. now, i'd certainly think its going to, but right now I'm moving assuming it's still on schedule. 08:18 < mmcgrath> err schedule hasn't slipped anyway :) 08:18 < G> Anyway, to finish up, I'm working some documentation for Zabbix and the _right_ way on doing stuff such as setting up triggers and monitoring items so I don't have to wack people over the head and clean up stuff every day :) 08:18 < jcollie> yeah haven't seen much of f13 lately 08:19 < G> And thats about it from me 08:19 < abadger1999> G: Excellent (documentation) 08:19 < mmcgrath> G: yeah a policy thing would be good. 08:20 < G> yeah, Nagios has got very tatty 08:21 < fchiulli> Now I can go back and work on my ticket. Hot damn. 08:21 < mmcgrath> heheh 08:21 < mmcgrath> Ok 08:21 < mmcgrath> G: anything else on that? 08:21 < G> mmcgrath: nah, lets roll on 08:21 < mmcgrath> solid 08:21 < mmcgrath> .ticket 753 08:21 < zodbot> mmcgrath: #753 (Mini-freeze for Fedora 10 beta) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/753 08:22 * mmcgrath isn't familiar with this one 08:22 < G> heh, I guess we kinda discussed this? 08:22 < mmcgrath> yeah I guess so 08:22 < mmcgrath> If Jesse needs a freeze we'll give him one. I'll make sure to discuss this next week. 08:22 < mmcgrath> .ticket 395 08:22 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/395 08:22 < mmcgrath> I'm pretty sure there's no new work on this 08:23 < mmcgrath> jcollie: anything? 08:23 < jcollie> nope 08:23 < G> btw, in relation to F10 Beta slipping, I'm pretty sure I heard on -devel-list that it'll be at least a week 08:23 < jcollie> we should try and get something done soon though 08:23 < mmcgrath> k 08:23 < mmcgrath> that sounds reasonable. 08:23 < mmcgrath> .ticket 446 08:23 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/446 08:23 < mmcgrath> dgilmore: ping? 08:23 < dgilmore> mmcgrath: pong 08:24 < mmcgrath> anything about the spins stuff? is that not needed anymore? if not can we get the ticket closed? 08:24 < dgilmore> mmcgrath: we have a wiki page. need an appropriate disclaimer 08:24 < dgilmore> im not sure if we do need it? 08:27 < mmcgrath> dgilmore: not sure, you just said you'd take this one so I keep pinging you about it :) 08:27 < dgilmore> mmcgrath: i should get hold of the spins people and determine if its still neeeded 08:27 < dgilmore> if it is then get the proper disclaimer 08:28 < dgilmore> page is at http://fedoraproject.org/wiki/Spins 08:28 < mmcgrath> 08:28 < dgilmore> not really anything to add 08:28 < dgilmore> so lets move on :) 08:28 < mmcgrath> hah, k 08:28 < mmcgrath> .ticket 576 08:28 < zodbot> mmcgrath: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/576 08:28 < mmcgrath> I was actually going to try to do this this week but I got distracted :) 08:29 < mmcgrath> so we'll say thats a next week thing 08:29 < mmcgrath> .ticket 740 08:29 < zodbot> mmcgrath: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740 08:29 < jcollie> heh and we probably could have actually used it :) 08:29 < mmcgrath> dgilmore: you have any more thoughts on that? 08:30 < dgilmore> mmcgrath: let me look 08:30 < dgilmore> ok so what i think they are looking for is 08:30 < dgilmore> a sand box system 08:30 < dgilmore> somewhere to do mock builds. 08:31 < dgilmore> possibly also to run koji commands from 08:31 * dgilmore should find someone to package koji for debian 08:32 < mmcgrath> hmm 08:32 < mmcgrath> dgilmore: we should probably hit this up on the list and see if its even something we should be doing. 08:32 < G> I still say, rack up a couple of the decommissoned xen hosts install Fedora on them, and throw them in a different part of the network, lock them down and ... 08:32 < dgilmore> we should get clarification that is what they want 08:32 < mmcgrath> I don't see any immediate benefit to Fedora but I'm not sure what the cost is quite yet. 08:32 < mmcgrath> yeah. 08:32 < mmcgrath> G: yeah we'd probably try to host that all somewhere else 08:33 < dgilmore> mmcgrath: a benefit for fedora would be closer working relationship. which should have the benefit of being able to build smaller fedora systems 08:34 < mmcgrath> 08:34 < mmcgrath> dgilmore: lets hold off till we find out what they want. 08:34 < mmcgrath> gregdek posted that ticket, ther emight be a better contact at RH 08:35 < dgilmore> mmcgrath: im guessing gdk is the best contact 08:35 < mmcgrath> err not at RH, at OLPC. 08:35 < mmcgrath> my bad. 08:35 < dgilmore> mmcgrath: but im guessing he doesnt know the requirements 08:35 < mmcgrath> either way we should get a clear idea of what they want to do. 08:35 < mmcgrath> 08:35 < dgilmore> m_stone: is likely the best contact 08:35 < mmcgrath> k 08:35 < mmcgrath> for now though, probably nothing new there? 08:36 < gregdek> I think best wait. 08:36 < gregdek> They'd really rather see koji back online first. :) 08:36 < mmcgrath> heh 08:36 < mmcgrath> fair enough 08:36 < mmcgrath> so next ticket 08:36 < mmcgrath> No new ticket. 08:36 < mmcgrath> Soooo. 08:36 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- IBM tech 08:36 < mmcgrath> An IBM tech is headed to fix a bad drive in xen14 right now. That should happen in the next hour or two. 08:37 < G> goodie :) 08:37 < mmcgrath> yeah, it'll be good to have xen14 back online. 08:37 < mmcgrath> and thats really all I have for this meeting 08:37 < G> mmcgrath: can we get him to leave a couple of extra servers behind while he's at it? :) 08:37 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 08:37 < mmcgrath> G: we can but we'd have no where to put them all :) 08:38 < jcollie> DNS servers... can we get some more? 08:38 < mmcgrath> although I am going to get rid of some 2U's. 08:38 < G> spoil sport :) 08:38 < smooge> DNS-SEC should we sign our zone? 08:38 < mmcgrath> jcollie: yeah, Its not really a priority right now though, we don't really have any dns issues right now but we can get another dns server or two up. 08:38 < mmcgrath> smooge: we could I think jcollie was even looking at that a few months back. 08:38 < mmcgrath> jcollie: ? 08:39 < jcollie> smooge: i've been using it for my home domain ... we need to figure out how to make the workflow work right 08:39 < jcollie> you have to resign your domain every 30 days 08:39 < jcollie> plus some key rotations 08:39 < smooge> ouch. 08:39 < mmcgrath> really? 08:40 < jcollie> yeah the signatures on the domain have a expiration date ... i think the default is 30 days - not sure if you can extend it or not 08:40 < mmcgrath> eeeenteresting 08:40 < G> Oh yeah, https://admin.fedoraproject.org/fingerprints has a short list of our Package Signing Keys and SSH Host Fingerprints :) 08:41 < jcollie> the tools are very much in their infancy.. for right now i'd say hold off on dns-sec, at least until we get more comfortable 08:41 < mmcgrath> G: that it does. We'll get cvs in there as soon as its back online as well. 08:41 < mmcgrath> jcollie: sounds good to me. If its something you feel like tackling though some day. i'm fine with being an early adopter there. 08:41 < G> mmcgrath: yeah 08:41 < mmcgrath> especially if it can help mature that technology more quickly. 08:42 < jcollie> yeah, i'm working on the procedures with my personal domain... once i have it figured out i'll work on how to do fedora domains 08:42 < mmcgrath> schweet. 08:42 * smooge needs to get that workflow into csi 08:42 < mmcgrath> :) 08:42 < mmcgrath> so much needs to get into csi 08:42 < G> mmcgrath: zabbix stuff maybe :) 08:42 < smooge> well hopefully I will have some time week after next to write some rough stuff 08:43 < mmcgrath> yeah 08:43 * mmcgrath hopes he will too 08:43 < mmcgrath> Ok, so anyone have anything else they'd like to discuss? If not I'll close the meeting in 30 08:43 < smooge> what I need is a newer system at home and then hope the pain meds don't make me too dopey 08:43 * G told Amazon to forget my order for the second nagios book :) 08:43 < mmcgrath> :) 08:43 < G> mmcgrath: ummm I don't think so, except... 08:44 < mmcgrath> mhmmm? 08:44 < jcollie> mmcgrath: if you want to set up a couple guests i'll set up secondary dns services on them 08:44 < jcollie> maybe we want a sysadmin-dns group? 08:44 < mmcgrath> jcollie: we'll get something up. 08:44 < mmcgrath> good question. I'm not sure we'll need it. 08:44 < G> I move to say that everyone here appreciates the hard work Mike, Toshio, Jeremy, Seth and Luke (and anyone else I've forgotten) has put it the last week. It's much appreciated 08:44 < mmcgrath> in theory we won't even need access to that box to admin it. 08:44 < skvidal> G: ricky, jeremy, too 08:44 < jcollie> mmcgrath: either that or approve me for sysadmin-main :) 08:44 < skvidal> ah, you said jeremy 08:45 < abadger1999> G: And dgilmore 08:45 < mmcgrath> and G 08:45 < skvidal> nod 08:45 < G> skvidal: Dennis and Ricky 08:45 < G> yeah 08:45 < jcollie> mmcgrath: access to the box would be more for troubleshooting 08:45 < mmcgrath> G helpped get our web services back online :) 08:45 < jcollie> mmcgrath: could lump it under sysadmin-tools maybe 08:45 < G> mmcgrath: right but you folks did the grunt work to get the core back up 08:46 < mmcgrath> jcollie: yeah that makes sense actually. 08:46 < mmcgrath> sysadmin-tools I mean. 08:46 < mmcgrath> G: thanks for the kind words and work :) 08:46 < mmcgrath> Ok, we'll close the meeting early :) 08:46 < mmcgrath> 30 08:47 < mmcgrath> 15 08:47 < G> mmcgrath: yeah, thats all I had to say :) 08:47 < mmcgrath> 10 08:47 < mmcgrath> 5 08:47 < dgilmore> mmcgrath: i have a dns server ill gladly offer as tertiary 08:47 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting end! 08:47 < mmcgrath> dgilmore: naw, I think if anything we'll move in to running more of our own servers. 08:47 < mmcgrath> best to keep those internal if we can. 08:47 < mmcgrath> Thanks for coming to the meeting everyone!!! 08:48 -!- mmcgrath 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 08:48 * ianweller hopes everything is fixed soonish :) 08:48 < jcollie> mmcgrath: dgilmore: esp since we can set up xen guests in multiple geographical locations 08:50 < mmcgrath> jcollie: yeah -- Nigel Jones From stickster at gmail.com Fri Aug 22 12:44:14 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 22 Aug 2008 08:44:14 -0400 Subject: Security assessment Message-ID: <1219409054.21605.39.camel@victoria> Eric Christensen (IRC: Sparks) offered to provide some assistance or input on security assessment. I let him know that the Infrastructure team has of course been constantly looking at how to ensure best security practices, but that we very much encouraged community input, and asked him to get in touch. -- 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 lutter at redhat.com Fri Aug 22 20:06:55 2008 From: lutter at redhat.com (David Lutterkort) Date: Fri, 22 Aug 2008 13:06:55 -0700 Subject: securing FAS certs In-Reply-To: <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> Message-ID: <1219435615.4728.30.camel@localhost.localdomain> On Thu, 2008-08-21 at 14:18 -0500, Jeffrey Ollie wrote: > What about using a crypto card like Jesse plans on using for Sigul? I wonder if a TPM can be (ab)used for this, too; they are pretty common on newer hardware, and store a key in HW that can not be extracted. Not sure though if anybody has looked at using it to sign SSL certs, and especially at keeping logs of what was signed in a way that makes it impossible to tamper with those logs, e.g. to hide the signing of some certs. David From mmcgrath at redhat.com Fri Aug 22 20:53:28 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 22 Aug 2008 15:53:28 -0500 (CDT) Subject: securing FAS certs In-Reply-To: <1219435615.4728.30.camel@localhost.localdomain> References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> <1219435615.4728.30.camel@localhost.localdomain> Message-ID: On Fri, 22 Aug 2008, David Lutterkort wrote: > On Thu, 2008-08-21 at 14:18 -0500, Jeffrey Ollie wrote: > > What about using a crypto card like Jesse plans on using for Sigul? > > I wonder if a TPM can be (ab)used for this, too; they are pretty common > on newer hardware, and store a key in HW that can not be extracted. > > Not sure though if anybody has looked at using it to sign SSL certs, and > especially at keeping logs of what was signed in a way that makes it > impossible to tamper with those logs, e.g. to hide the signing of some > certs. > Possibly. I was looking earlier too for something like ssh-agent or gpg agent to serve this purpose... Haven't seen anything. Which.. well strikes me as strange. It'd be a software way to do what we're talking about. -Mike From mmcgrath at redhat.com Fri Aug 22 22:30:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 22 Aug 2008 17:30:23 -0500 (CDT) Subject: Test servers Message-ID: So we're in kind of an awkward but probably beneficial spot right now for our test server infrastructure. Its _ALL_ down right now. And we need to build it back up. We've talked about another layer of test servers and I think its probably time for that so here's what I propose. Rebuild our test servers external to PHX. There is an open ticket for this already, we're just going to be doing it finally. Create a staging environment in the publictest and test areas in PHX. Staging will be identical to our production environment where possible with the exception of production data and where new features are being implemented and are not in production yet. Staging will be in puppet. All of it. Just like production is and they'll get rebuilt regularly. We can use puppet's environments to do this but I'm going to talk with kanarip about implementation and such. We actually have a very basic testing environment setup in puppet now but its not really tested or documented yet. Staging will be different. What to know about the old pt servers: 1) AFAIK at this point in time, no data has been lost or anything. The old servers are just off. 2) PT10 was kind of a mess and needed to be rebuilt anyway. 3) If you need to recover something ask but we're not going to blanket replace everyone's home dirs. Hopefully you weren't developing on the public test servers but were simply using it to show others. This isn't all a done deal yet. I want to see what others say since this affects a lot of people, we have a lot of testers. -Mike From kanarip at kanarip.com Fri Aug 22 22:55:17 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 23 Aug 2008 00:55:17 +0200 Subject: Test servers In-Reply-To: References: Message-ID: <48AF43D5.2020702@kanarip.com> Mike McGrath wrote: > So we're in kind of an awkward but probably beneficial spot right now for > our test server infrastructure. > > Its _ALL_ down right now. And we need to build it back up. We've talked > about another layer of test servers and I think its probably time for that > so here's what I propose. > > Rebuild our test servers external to PHX. There is an open ticket for > this already, we're just going to be doing it finally. > > Create a staging environment in the publictest and test areas in PHX. > > Staging will be identical to our production environment where possible > with the exception of production data and where new features are being > implemented and are not in production yet. > > Staging will be in puppet. All of it. Just like production is and > they'll get rebuilt regularly. We can use puppet's environments to do > this but I'm going to talk with kanarip about implementation and such. We > actually have a very basic testing environment setup in puppet now but its > not really tested or documented yet. Staging will be different. > So, a few things on staging environments: Puppet can stage the following things: - the manifest to use (e.g. site.pp) for an environment, including all imported files (e.g. classes/*.pp etc) - the modulepath to use This means that you can split into environments what you use from the modules in those environments, but not what is in configs/ right now. For what is in configs/ to become staged, it needs to go into modules. Preferably, we would stage using git branches (development -> testing -> production, for example). A simple plan without too many details: - What we have right now becomes the production branch (configs/ can stay where it is) - We branch off to development (and testing if desirable), and start moving configs/ content into the modules for as far as these are related to the modules (e.g. templates, new files, but not "simple" files). - Changes go into the development branch first, then are pulled into / pushed to production. Any other thoughts? Kind regards, Jeroen van Meeuwen -kanarip From mark at wormgoor.com Sat Aug 23 07:43:59 2008 From: mark at wormgoor.com (Mark Wormgoor) Date: Sat, 23 Aug 2008 09:43:59 +0200 Subject: securing FAS certs In-Reply-To: <48ADCE84.6050608@gmail.com> References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> <20080821193438.GD31338@sphe.res.cmu.edu> <48ADCE84.6050608@gmail.com> Message-ID: <48AFBFBF.3080608@wormgoor.com> Toshio Kuratomi schreef: > Mike McGrath wrote: >> On Thu, 21 Aug 2008, Ricky Zhou wrote: >> >>> On 2008-08-21 02:21:34 PM, Mike McGrath wrote: >>>> I've never actually used a crypto card... Do they add additional >>>> security >>>> if they're sitting in a colo always plugged in? If so how do they do >>>> that? >>> I might be wrong, but I think with such a card, encryption/signing takes >>> place entirely on the card, and thus the secret key is never transferred >>> anywhere off the card. >>> >> >> Ah, so the theory being that if someone happens to hit us, they're only >> hitting us for as long as the machine is up / card is in. And I assume >> the card actually tracks serial numbers and things so we can revoke >> anything that was signed in a questionable time? >> > That seems like it would work well. Jesse's been having troubles > obtaining the card he wants, though (and his is a gpg card, not for ssl > certificates). Most of these cards work with OpenSSL just fine - though I'm not sure what additional hardware drivers are required to interface to the card. All the card does is protect the private key from being obtained. When someone has (root) access to the machine, he can use the key for signing anyway. As such, an hsm should be connected only to a very secure machine, not running any other services and with highly restricted access. Connecting one to a Xen machine does not sound like a good idea :) These keys are protected against hardware intrusion depending on their security level and will zero out the keys upon hardware tampering. Kind regards, Mark From Axel.Thimm at ATrpms.net Sat Aug 23 21:01:31 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 00:01:31 +0300 Subject: cvs: Permission denied (publickey). Message-ID: <20080823210131.GA13091@victor.nirvana> Hi, I saw that some people are using CVS again, so I tried as well, but I got: athimm at devel(1012):/home/.../smart/devel$ cvs up Permission denied (publickey). cvs [update aborted]: end of file from server (consult above messages if any) I have a new FAS password, all certs updated, I even checked the cvs procedures for newbies on fpo, but I had no luck. What am I doing wrong? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeff at ocjtech.us Sat Aug 23 21:06:07 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sat, 23 Aug 2008 16:06:07 -0500 Subject: cvs: Permission denied (publickey). In-Reply-To: <20080823210131.GA13091@victor.nirvana> References: <20080823210131.GA13091@victor.nirvana> Message-ID: <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> 2008/8/23 Axel Thimm : > > I saw that some people are using CVS again, so I tried as well, but I > got: > > athimm at devel(1012):/home/.../smart/devel$ cvs up > Permission denied (publickey). > cvs [update aborted]: end of file from server (consult above messages if any) > > I have a new FAS password, all certs updated, I even checked the cvs > procedures for newbies on fpo, but I had no luck. What am I doing > wrong? Did you upload a new SSH public key? -- Jeff "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5:"A Late Delivery from Avalon" From Axel.Thimm at ATrpms.net Sat Aug 23 21:32:33 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 00:32:33 +0300 Subject: cvs: Permission denied (publickey). In-Reply-To: <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> Message-ID: <20080823213233.GB13091@victor.nirvana> On Sat, Aug 23, 2008 at 04:06:07PM -0500, Jeffrey Ollie wrote: > 2008/8/23 Axel Thimm : > > > > I saw that some people are using CVS again, so I tried as well, but I > > got: > > > > athimm at devel(1012):/home/.../smart/devel$ cvs up > > Permission denied (publickey). > > cvs [update aborted]: end of file from server (consult above messages if any) > > > > I have a new FAS password, all certs updated, I even checked the cvs > > procedures for newbies on fpo, but I had no luck. What am I doing > > wrong? > > Did you upload a new SSH public key? It won't let me: Error! The following error(s) have occured with your request: * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... Have DSA keys now been banned? Why? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jeff at ocjtech.us Sat Aug 23 21:37:13 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sat, 23 Aug 2008 16:37:13 -0500 Subject: cvs: Permission denied (publickey). In-Reply-To: <20080823213233.GB13091@victor.nirvana> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> Message-ID: <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> 2008/8/23 Axel Thimm : > On Sat, Aug 23, 2008 at 04:06:07PM -0500, Jeffrey Ollie wrote: >> 2008/8/23 Axel Thimm : >> > >> > I saw that some people are using CVS again, so I tried as well, but I >> > got: >> > >> > athimm at devel(1012):/home/.../smart/devel$ cvs up >> > Permission denied (publickey). >> > cvs [update aborted]: end of file from server (consult above messages if any) >> > >> > I have a new FAS password, all certs updated, I even checked the cvs >> > procedures for newbies on fpo, but I had no luck. What am I doing >> > wrong? >> >> Did you upload a new SSH public key? > > It won't let me: > > Error! > > The following error(s) have occured with your request: > > * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... > > Have DSA keys now been banned? Yes. > Why? The primary reason is that it's nearly impossible to tell if the key was generated on a Debian system with the compromised OpenSSL versions. I've heard rumblings that DSA keys are weaker for other reasons, but I've not seen any good explanations. In any case, it's probably a good idea to regenerate your SSH keys every now and then, I know I had been using mine FAR too long. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From smooge at gmail.com Sat Aug 23 23:09:34 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 23 Aug 2008 17:09:34 -0600 Subject: cvs: Permission denied (publickey). In-Reply-To: <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> Message-ID: <80d7e4090808231609p7adfac61g1216e42298aa9a7b@mail.gmail.com> On Sat, Aug 23, 2008 at 3:37 PM, Jeffrey Ollie wrote: > 2008/8/23 Axel Thimm : >> On Sat, Aug 23, 2008 at 04:06:07PM -0500, Jeffrey Ollie wrote: >>> 2008/8/23 Axel Thimm : >>> > >>> > I saw that some people are using CVS again, so I tried as well, but I >>> > got: >>> > >>> > athimm at devel(1012):/home/.../smart/devel$ cvs up >>> > Permission denied (publickey). >>> > cvs [update aborted]: end of file from server (consult above messages if any) >>> > >>> > I have a new FAS password, all certs updated, I even checked the cvs >>> > procedures for newbies on fpo, but I had no luck. What am I doing >>> > wrong? >>> >>> Did you upload a new SSH public key? >> >> It won't let me: >> >> Error! >> >> The following error(s) have occured with your request: >> >> * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... >> >> Have DSA keys now been banned? > > Yes. > >> Why? > > The primary reason is that it's nearly impossible to tell if the key > was generated on a Debian system with the compromised OpenSSL > versions. I've heard rumblings that DSA keys are weaker for other > reasons, but I've not seen any good explanations. > There are several mathematical weaknesses in DSA keys that were outlined during the OpenSSL problems. I believe the main one is that the DSA signature can give away the private key. -- 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 wolfy at nobugconsulting.ro Sat Aug 23 23:16:53 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 24 Aug 2008 02:16:53 +0300 Subject: buildgroups directory vanished from http://buildsys.fedoraproject.org ? Message-ID: <48B09A65.9080604@nobugconsulting.ro> While trying to test build a program for EL-5, mock bails out with: INFO: Results and/or logs in: /var/lib/mock//epel-5-x86_64/result ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/epel-5-x86_64/root/ install buildsys-build http://buildsys.fedoraproject.org/buildgroups/rhel5/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: groups. Please verify its path and try again It looks like the buildgroups does not exist any more. Could someone please fix it (or tell me what to use instead, if it's gone for good) ? Manuel From jeff at ocjtech.us Sun Aug 24 00:21:46 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sat, 23 Aug 2008 19:21:46 -0500 Subject: cvs: Permission denied (publickey). In-Reply-To: <80d7e4090808231609p7adfac61g1216e42298aa9a7b@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <80d7e4090808231609p7adfac61g1216e42298aa9a7b@mail.gmail.com> Message-ID: <935ead450808231721g5f42d885x968fc3fdc2305a0f@mail.gmail.com> On Sat, Aug 23, 2008 at 6:09 PM, Stephen John Smoogen wrote: > > There are several mathematical weaknesses in DSA keys that were > outlined during the OpenSSL problems. I believe the main one is that > the DSA signature can give away the private key. I've heard that too, but I haven't found papers or anything that discusses the matter in more detail. Anyone have any pointers? -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From mmcgrath at redhat.com Sun Aug 24 00:59:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 23 Aug 2008 19:59:31 -0500 (CDT) Subject: buildgroups directory vanished from http://buildsys.fedoraproject.org ? In-Reply-To: <48B09A65.9080604@nobugconsulting.ro> References: <48B09A65.9080604@nobugconsulting.ro> Message-ID: On Sun, 24 Aug 2008, Manuel Wolfshant wrote: > While trying to test build a program for EL-5, mock bails out with: > > INFO: Results and/or logs in: /var/lib/mock//epel-5-x86_64/result > ERROR: Command failed: > # /usr/bin/yum --installroot /var/lib/mock/epel-5-x86_64/root/ install > buildsys-build > http://buildsys.fedoraproject.org/buildgroups/rhel5/x86_64/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Not Found > Trying other mirror. > Error: Cannot retrieve repository metadata (repomd.xml) for repository: > groups. Please verify its path and try again > > > > It looks like the buildgroups does not exist any more. Could someone > please fix it (or tell me what to use instead, if it's gone for good) ? > Unlike some of our other servers the buildsys server was considered legacy only waiting until we could move EPEL to koji. Its rebuild hasn't been as clean as some of our more modern installs. We're still shaking some bugs out of it. I'll take a look at this. -Mike From wolfy at nobugconsulting.ro Sun Aug 24 01:21:52 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sun, 24 Aug 2008 04:21:52 +0300 Subject: buildgroups directory vanished from http://buildsys.fedoraproject.org ? In-Reply-To: References: <48B09A65.9080604@nobugconsulting.ro> Message-ID: <48B0B7B0.7060900@nobugconsulting.ro> On 08/24/2008 03:59 AM, Mike McGrath wrote: > On Sun, 24 Aug 2008, Manuel Wolfshant wrote: > > >> While trying to test build a program for EL-5, mock bails out with: >> >> INFO: Results and/or logs in: /var/lib/mock//epel-5-x86_64/result >> ERROR: Command failed: >> # /usr/bin/yum --installroot /var/lib/mock/epel-5-x86_64/root/ install >> buildsys-build >> http://buildsys.fedoraproject.org/buildgroups/rhel5/x86_64/repodata/repomd.xml: >> [Errno 14] HTTP Error 404: Not Found >> Trying other mirror. >> Error: Cannot retrieve repository metadata (repomd.xml) for repository: >> groups. Please verify its path and try again >> >> >> >> It looks like the buildgroups does not exist any more. Could someone >> please fix it (or tell me what to use instead, if it's gone for good) ? >> >> > > Unlike some of our other servers the buildsys server was considered legacy > only waiting until we could move EPEL to koji. Its rebuild hasn't been as > clean as some of our more modern installs. We're still shaking some bugs > out of it. I'll take a look at this. Thanks for looking at this. Until there is a fix, any chance to have the actual content that existed below /buildgroups be made available for download, please ? I could just replicate it on a local server and do local mock builds. I am most interested in EL-4/5 and Fedora >=6 (yes, I do know Fedora < 8 is considered legacy ) From Axel.Thimm at ATrpms.net Sun Aug 24 08:37:50 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 11:37:50 +0300 Subject: Please restore ssh-dsa (was: cvs: Permission denied (publickey).) In-Reply-To: <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> Message-ID: <20080824083750.GA18904@victor.nirvana> On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: > 2008/8/23 Axel Thimm : > > On Sat, Aug 23, 2008 at 04:06:07PM -0500, Jeffrey Ollie wrote: > >> 2008/8/23 Axel Thimm : > >> > > >> > I saw that some people are using CVS again, so I tried as well, but I > >> > got: > >> > > >> > athimm at devel(1012):/home/.../smart/devel$ cvs up > >> > Permission denied (publickey). > >> > cvs [update aborted]: end of file from server (consult above messages if any) > >> > > >> > I have a new FAS password, all certs updated, I even checked the cvs > >> > procedures for newbies on fpo, but I had no luck. What am I doing > >> > wrong? > >> > >> Did you upload a new SSH public key? > > > > It won't let me: > > > > Error! > > > > The following error(s) have occured with your request: > > > > * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... > > > > Have DSA keys now been banned? > > Yes. > > > Why? > > The primary reason is that it's nearly impossible to tell if the key > was generated on a Debian system with the compromised OpenSSL > versions. That's overreacting. What happens if Gentoo makes a similar mistake with RSA keys, will we ban them, too? DSA is a decent technology. > I've heard rumblings that DSA keys are weaker for other reasons, but > I've not seen any good explanations. Hearsay, your honour! On the contrary, I've heard that DSA gathers at 1024 bits at least as much entropy as RSA with 2048, and DSA was the recommended "new" algorithm half a decade ago. Currently RSA and DSA are equal up. Please restore the possibility to use DSA. People doing so are knowledgable enough (DSA is not the default with ssh-keygen) to have dealt with any keys they may have created on Debian systems during the time window their rnd gen was bad. If they haven't you won't save them anyway. > In any case, it's probably a good idea to regenerate your SSH keys > every now and then, I know I had been using mine FAR too long. There are different opinions on this as well. If you access several dozens of systems scattered world-wide in differently administered environments you will be glad not to have to change the keys that often and to use only a few keys, and not one for every host. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From opensource at till.name Sun Aug 24 11:20:22 2008 From: opensource at till.name (Till Maas) Date: Sun, 24 Aug 2008 13:20:22 +0200 Subject: cvs: Permission denied (publickey). In-Reply-To: <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> Message-ID: <200808241320.34721.opensource@till.name> On Sat August 23 2008, Jeffrey Ollie wrote: > 2008/8/23 Axel Thimm : > > Have DSA keys now been banned? > > Yes. > > > Why? > > The primary reason is that it's nearly impossible to tell if the key > was generated on a Debian system with the compromised OpenSSL This is also true for RSA keys. > versions. I've heard rumblings that DSA keys are weaker for other > reasons, but I've not seen any good explanations. | In addition, any DSA key must be considered compromised if it has been used | on a machine with a 'bad' OpenSSL. Simply using a 'strong' DSA key (i.e., | generated with a 'good' OpenSSL) to make a connection from such a machine | may have compromised it. This is due to an 'attack' on DSA that allows the | secret key to be found if the nonce used in the signature is known or | reused. http://wiki.debian.org/SSLkeys#head-d841ac769390d013577ce3fd2be24b8cf5a74cfb If you look at the descriptions of the dsa signing algorithm, e.g. in the handbook of applied cryptography[1], you notice, that there is a random parameter that is meant to kept secret. Regards, Till [1] http://www.cacr.math.uwaterloo.ca/hac/about/chap11.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From Axel.Thimm at ATrpms.net Sun Aug 24 13:36:56 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 16:36:56 +0300 Subject: Please restore ssh-dsa (was: cvs: Permission denied (publickey).) In-Reply-To: <20080824083750.GA18904@victor.nirvana> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <20080824083750.GA18904@victor.nirvana> Message-ID: <20080824133656.GC23503@victor.nirvana> > On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: > > The primary reason is that it's nearly impossible to tell if the key > > was generated on a Debian system with the compromised OpenSSL > > versions. OK, I checked and it is far from impossible. After all the bug was that there are only 32k possible keys per arch/size/type - Debian has even issued blacklists for all keys of typical und some untypical sizes like 1024/2048/1023/2047/4096/8192 and for some sizes they even packaged it up, see http://packages.debian.org/unstable/main/openssh-blacklist http://packages.debian.org/unstable/main/openssh-blacklist-extra If there is paranoia floating around, then why not use that blacklist in Fedora/RHEL as well instead of nuking all DSA keys and still allowing the bad RSA keys? And if your are really paranoic then one can package up these blacklists for general use by Fedora/RHEL's openssh. I don't know if openssh has a blacklist-reject ability already coded in, though. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From stickster at gmail.com Sun Aug 24 14:21:10 2008 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 24 Aug 2008 10:21:10 -0400 Subject: Some noteworty praise Message-ID: <1219587670.14053.9.camel@salma.internal.frields.org> This whole team got a well-deserved attaboy from Tim Burke, who is the Director of Linux Development inside Red Hat. https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01023.html ''' Dear Fedorans, There's an old expression: When the going gets tough; the tough get going. The hardcore Fedora guys here at RH have been as tough, determined, hard-working and resilient as I have ever seen. It is a privilege to work among them. They didn't ask for a week of grief. They didn't deserve a week of grief. This burden was inflicted on them through no fault of their own. Through it all they have risen to the occasion and gone well beyond. In addition, they have at all times had the interests and spirit of the community front and center. Because this is an ongoing investigation I am unable to articulate their individual heroics in detail. If you have been lucky enough to meet any of them at Fudcon, OLS, a local LUG meeting or online, you know who I'm talking about. You know the magic they perform. We at Red Hat are proud of every one of them. We stand behind them shoulder to shoulder 100%. Inside the walls of Red Hat, the word "heroes" has almost never been used. Glad we saved it for these guys. In deep admiration Tim Burke, Director Linux Development ''' I couldn't agree more. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - 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 stickster at gmail.com Sun Aug 24 14:25:06 2008 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 24 Aug 2008 10:25:06 -0400 Subject: Some noteworty praise In-Reply-To: <1219587670.14053.9.camel@salma.internal.frields.org> References: <1219587670.14053.9.camel@salma.internal.frields.org> Message-ID: <1219587907.14053.14.camel@salma.internal.frields.org> On Sun, 2008-08-24 at 10:21 -0400, Paul W. Frields wrote: > This whole team got a well-deserved attaboy from Tim Burke, who is the > Director of Linux Development inside Red Hat. > > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01023.html > > ''' > Dear Fedorans, > > There's an old expression: When the going gets tough; the tough get going. > > The hardcore Fedora guys here at RH have been as tough, determined, > hard-working and resilient as I have ever seen. It is a privilege to > work among them. They didn't ask for a week of grief. They didn't > deserve a week of grief. This burden was inflicted on them through no > fault of their own. Through it all they have risen to the occasion and > gone well beyond. In addition, they have at all times had the interests > and spirit of the community front and center. > > Because this is an ongoing investigation I am unable to articulate their > individual heroics in detail. If you have been lucky enough to meet any > of them at Fudcon, OLS, a local LUG meeting or online, you know who I'm > talking about. You know the magic they perform. We at Red Hat are proud > of every one of them. We stand behind them shoulder to shoulder 100%. > Inside the walls of Red Hat, the word "heroes" has almost never been > used. Glad we saved it for these guys. > > In deep admiration > Tim Burke, Director Linux Development > ''' > > I couldn't agree more. Sorry to reply to myself -- but I wanted to point out that the Fedora Infrastructure team is a strong fraternity of people from all around this community. Tim is well aware of the many long hours that we all spent, both inside and outside Red Hat, on getting things back in order over the last week or so. So this note is not just about Red Hat employees, it's about all of you on this list who've put your back into the work, and got it done without question or complaint. Enjoy the rest of your weekend. Paul -------------- 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 smooge at gmail.com Sun Aug 24 15:34:36 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 24 Aug 2008 09:34:36 -0600 Subject: Please restore ssh-dsa (was: cvs: Permission denied (publickey).) In-Reply-To: <20080824083750.GA18904@victor.nirvana> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <20080824083750.GA18904@victor.nirvana> Message-ID: <80d7e4090808240834g4183a3bby34ce1965530acb4@mail.gmail.com> 2008/8/24 Axel Thimm : > On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: >> 2008/8/23 Axel Thimm : >> > On Sat, Aug 23, 2008 at 04:06:07PM -0500, Jeffrey Ollie wrote: >> >> 2008/8/23 Axel Thimm : >> >> > >> >> > I saw that some people are using CVS again, so I tried as well, but I >> >> > got: >> >> > >> >> > athimm at devel(1012):/home/.../smart/devel$ cvs up >> >> > Permission denied (publickey). >> >> > cvs [update aborted]: end of file from server (consult above messages if any) >> >> > >> >> > I have a new FAS password, all certs updated, I even checked the cvs >> >> > procedures for newbies on fpo, but I had no luck. What am I doing >> >> > wrong? >> >> >> >> Did you upload a new SSH public key? >> > >> > It won't let me: >> > >> > Error! >> > >> > The following error(s) have occured with your request: >> > >> > * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... >> > >> > Have DSA keys now been banned? >> >> Yes. >> >> > Why? >> >> The primary reason is that it's nearly impossible to tell if the key >> was generated on a Debian system with the compromised OpenSSL >> versions. > > That's overreacting. What happens if Gentoo makes a similar mistake > with RSA keys, will we ban them, too? DSA is a decent technology. > No because RSA doesn't leak information into your public key nor does it rely on the 'random' secret key to the same extent. Th >> I've heard rumblings that DSA keys are weaker for other reasons, but >> I've not seen any good explanations. > > Hearsay, your honour! On the contrary, I've heard that DSA gathers at > 1024 bits at least as much entropy as RSA with 2048, and DSA was the > recommended "new" algorithm half a decade ago. Currently RSA and DSA > are equal up. > I take your hearsay, and counter with my hearsay that DSA will be replaced next year with DSA2 which can use 4 bits of entropy and be as secure as 4096 RSA. -- 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 smooge at gmail.com Sun Aug 24 15:39:15 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 24 Aug 2008 09:39:15 -0600 Subject: Please restore ssh-dsa (was: cvs: Permission denied (publickey).) In-Reply-To: <20080824133656.GC23503@victor.nirvana> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <20080824083750.GA18904@victor.nirvana> <20080824133656.GC23503@victor.nirvana> Message-ID: <80d7e4090808240839v5e83ec02sa4648484cf51b343@mail.gmail.com> 2008/8/24 Axel Thimm : >> On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: >> > The primary reason is that it's nearly impossible to tell if the key >> > was generated on a Debian system with the compromised OpenSSL >> > versions. > > OK, I checked and it is far from impossible. After all the bug was > that there are only 32k possible keys per arch/size/type - Debian has > even issued blacklists for all keys of typical und some untypical > sizes like 1024/2048/1023/2047/4096/8192 and for some sizes they even > packaged it up, see > > http://packages.debian.org/unstable/main/openssh-blacklist > http://packages.debian.org/unstable/main/openssh-blacklist-extra > > If there is paranoia floating around, then why not use that blacklist > in Fedora/RHEL as well instead of nuking all DSA keys and still > allowing the bad RSA keys? > All RSA keys were nuked too. > And if your are really paranoic then one can package up these > blacklists for general use by Fedora/RHEL's openssh. I don't know if > openssh has a blacklist-reject ability already coded in, though. No it does not. -- 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 Axel.Thimm at ATrpms.net Sun Aug 24 15:43:14 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 18:43:14 +0300 Subject: Please restore ssh-dsa (was: cvs: Permission denied (publickey).) In-Reply-To: <80d7e4090808240834g4183a3bby34ce1965530acb4@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <20080824083750.GA18904@victor.nirvana> <80d7e4090808240834g4183a3bby34ce1965530acb4@mail.gmail.com> Message-ID: <20080824154314.GA28399@victor.nirvana> On Sun, Aug 24, 2008 at 09:34:36AM -0600, Stephen John Smoogen wrote: > >> > * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... > >> > > >> > Have DSA keys now been banned? > >> > >> Yes. > >> > >> > Why? > >> > >> The primary reason is that it's nearly impossible to tell if the key > >> was generated on a Debian system with the compromised OpenSSL > >> versions. > > > > That's overreacting. What happens if Gentoo makes a similar mistake > > with RSA keys, will we ban them, too? DSA is a decent technology. > > No because RSA doesn't leak information into your public key nor does > it rely on the 'random' secret key to the same extent. Th Your mixing different issues: What you are referring to is using a good DSA key from a bad host. The context above was about the DSA/RSA keys generated in the bad two year window. Both DSA and RSA from that time frame are equally predictable. > >> I've heard rumblings that DSA keys are weaker for other reasons, but > >> I've not seen any good explanations. > > > > Hearsay, your honour! On the contrary, I've heard that DSA gathers at > > 1024 bits at least as much entropy as RSA with 2048, and DSA was the > > recommended "new" algorithm half a decade ago. Currently RSA and DSA > > are equal up. > > I take your hearsay, and counter with my hearsay that DSA will be > replaced next year with DSA2 which can use 4 bits of entropy and be as > secure as 4096 RSA. Cool, then let the hearsays determine our processes. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Aug 24 15:48:40 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 18:48:40 +0300 Subject: Please restore ssh-dsa In-Reply-To: <80d7e4090808240839v5e83ec02sa4648484cf51b343@mail.gmail.com> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <20080824083750.GA18904@victor.nirvana> <20080824133656.GC23503@victor.nirvana> <80d7e4090808240839v5e83ec02sa4648484cf51b343@mail.gmail.com> Message-ID: <20080824154840.GB28399@victor.nirvana> On Sun, Aug 24, 2008 at 09:39:15AM -0600, Stephen John Smoogen wrote: > 2008/8/24 Axel Thimm : > >> On Sat, Aug 23, 2008 at 04:37:13PM -0500, Jeffrey Ollie wrote: > >> > The primary reason is that it's nearly impossible to tell if the key > >> > was generated on a Debian system with the compromised OpenSSL > >> > versions. > > > > OK, I checked and it is far from impossible. After all the bug was > > that there are only 32k possible keys per arch/size/type - Debian has > > even issued blacklists for all keys of typical und some untypical > > sizes like 1024/2048/1023/2047/4096/8192 and for some sizes they even > > packaged it up, see > > > > http://packages.debian.org/unstable/main/openssh-blacklist > > http://packages.debian.org/unstable/main/openssh-blacklist-extra > > > > If there is paranoia floating around, then why not use that blacklist > > in Fedora/RHEL as well instead of nuking all DSA keys and still > > allowing the bad RSA keys? > > All RSA keys were nuked too. Please read up the complete thread (and maybe the subject line as well :) - with nuking of ssh keys I'm not referring to the internally used ssh keys, which were all replaced, but the nuking of all user DSA keys for using in FAS/cvs. s/nuked/banned/g for a better phrasing - sorry, me no naitif ingisch spieka. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From smooge at gmail.com Sun Aug 24 16:19:26 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 24 Aug 2008 10:19:26 -0600 Subject: Please restore ssh-dsa (was: cvs: Permission denied (publickey).) In-Reply-To: <20080824154314.GA28399@victor.nirvana> References: <20080823210131.GA13091@victor.nirvana> <935ead450808231406t53e903d8ua40ae39a7e1c2aca@mail.gmail.com> <20080823213233.GB13091@victor.nirvana> <935ead450808231437o8fb3d34jf9eb3da2c53511e1@mail.gmail.com> <20080824083750.GA18904@victor.nirvana> <80d7e4090808240834g4183a3bby34ce1965530acb4@mail.gmail.com> <20080824154314.GA28399@victor.nirvana> Message-ID: <80d7e4090808240919p7c398751iabf59bd1c6a9272b@mail.gmail.com> 2008/8/24 Axel Thimm : > On Sun, Aug 24, 2008 at 09:34:36AM -0600, Stephen John Smoogen wrote: >> >> > * ssh_key: Error - Not a valid RSA SSH key: ssh-dss ... >> >> > >> >> > Have DSA keys now been banned? >> >> >> >> Yes. >> >> >> >> > Why? >> >> >> >> The primary reason is that it's nearly impossible to tell if the key >> >> was generated on a Debian system with the compromised OpenSSL >> >> versions. >> > >> > That's overreacting. What happens if Gentoo makes a similar mistake >> > with RSA keys, will we ban them, too? DSA is a decent technology. >> >> No because RSA doesn't leak information into your public key nor does >> it rely on the 'random' secret key to the same extent. Th > > Your mixing different issues: What you are referring to is using a > good DSA key from a bad host. The context above was about the DSA/RSA > keys generated in the bad two year window. Both DSA and RSA from that > time frame are equally predictable. You wanted to know about other weaknesses in the DSA string. I wrote it in the wrong spot. In the end, it is easier to audit bad RSA over DSA and having one set to look for in case of another bad OpenSSL is easier on the volunteer admins to deal with. >> >> I've heard rumblings that DSA keys are weaker for other reasons, but >> >> I've not seen any good explanations. >> > >> > Hearsay, your honour! On the contrary, I've heard that DSA gathers at >> > 1024 bits at least as much entropy as RSA with 2048, and DSA was the >> > recommended "new" algorithm half a decade ago. Currently RSA and DSA >> > are equal up. >> >> I take your hearsay, and counter with my hearsay that DSA will be >> replaced next year with DSA2 which can use 4 bits of entropy and be as >> secure as 4096 RSA. > > Cool, then let the hearsays determine our processes. Ok lets turn off the sarcasm.. I am sorry I started it. -- 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 Axel.Thimm at ATrpms.net Sun Aug 24 16:44:39 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 19:44:39 +0300 Subject: Maintaining a partial cvs workarea Message-ID: <20080824164439.GA29038@victor.nirvana> Hi, I'm keeping only a partial checkout of the packages, e.g. the ones I'm maintaining. Now I'd like to be able to cvs up and have all updates flow in, but if I do so cvs will want to get all other thousand packages in. Until now I'm using a poor man's solution with a for loop and pushd/popd, but it's extremely slow due to login in for each package. Is there a more clever way to get cvs up running w/o pulling in all of the cvsroot? I could probably manually edit CVS/Entries, but this feels a bit dirty. What are other packagers doing? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Aug 24 16:53:40 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 19:53:40 +0300 Subject: Maintaining a partial cvs workarea In-Reply-To: <20080824164439.GA29038@victor.nirvana> References: <20080824164439.GA29038@victor.nirvana> Message-ID: <20080824165340.GA30850@victor.nirvana> Hi, On Sun, Aug 24, 2008 at 07:44:39PM +0300, Axel Thimm wrote: > I'm keeping only a partial checkout of the packages, e.g. the ones I'm > maintaining. Now I'd like to be able to cvs up and have all updates > flow in, but if I do so cvs will want to get all other thousand > packages in. > > Until now I'm using a poor man's solution with a for loop and > pushd/popd, but it's extremely slow due to login in for each package. > > Is there a more clever way to get cvs up running w/o pulling in all of > the cvsroot? I could probably manually edit CVS/Entries, but this feels > a bit dirty. What are other packagers doing? Sometimes it helps posting a problem to think more about it and solve it. For posterity and google searches: Actually what I wanted is already the default. But one usually wants cvs to automatically discover new folders and pull them in (the -d option). This is so common, that at one time in your cvs life you will add it to ~/.cvsrc as a default option like $ cat ~/.cvsrc diff -ud update -P -d and you will forget about it, and you will make silly help requests like the one I did above. :) Now you dont need to remove the otherwise useful -d switch to update, instead use cvs -fq up to get the desired (non-verbose) updating w/o getting new packages in. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 24 18:13:54 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 24 Aug 2008 20:13:54 +0200 Subject: Maintaining a partial cvs workarea In-Reply-To: <20080824164439.GA29038@victor.nirvana> References: <20080824164439.GA29038@victor.nirvana> Message-ID: <48B1A4E2.8010507@kanarip.com> Axel Thimm wrote: > Hi, > > I'm keeping only a partial checkout of the packages, e.g. the ones I'm > maintaining. Now I'd like to be able to cvs up and have all updates > flow in, but if I do so cvs will want to get all other thousand > packages in. > > Until now I'm using a poor man's solution with a for loop and > pushd/popd, but it's extremely slow due to login in for each package. > > Is there a more clever way to get cvs up running w/o pulling in all of > the cvsroot? I could probably manually edit CVS/Entries, but this feels > a bit dirty. What are other packagers doing? > I do: mkdir ~/CVS/ cvs co package1 cvs co package2 (just for reference of what is on my computer) Then, to update all of my checkouts, I do: cd ~/CVS cvs up -d Kind regards, Jeroen van Meeuwen -kanarip From cweyl at alumni.drew.edu Sun Aug 24 20:51:38 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 24 Aug 2008 13:51:38 -0700 Subject: CSS? Message-ID: <7dd7ab490808241351x61b1be4am75dcc558f01c9b1b@mail.gmail.com> Hey all -- I know this is probably last thing from a priority perspective right now, but I'd been using the stylesheets at: http://admin.fedoraproject.org/css/layout.css http://admin.fedoraproject.org/css/content.css http://admin.fedoraproject.org/css/docbook.css Any idea when they'll be back online? (Or should I be using them at a different location...?) Thanks- -Chris -- Chris Weyl Ex astris, scientia From cweyl at alumni.drew.edu Sun Aug 24 21:16:33 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 24 Aug 2008 14:16:33 -0700 Subject: Maintaining a partial cvs workarea In-Reply-To: <20080824164439.GA29038@victor.nirvana> References: <20080824164439.GA29038@victor.nirvana> Message-ID: <7dd7ab490808241416j21c6d1d4va3b9b66f5d68364e@mail.gmail.com> 2008/8/24 Axel Thimm : > Hi, > > I'm keeping only a partial checkout of the packages, e.g. the ones I'm > maintaining. Now I'd like to be able to cvs up and have all updates > flow in, but if I do so cvs will want to get all other thousand > packages in. > > Until now I'm using a poor man's solution with a for loop and > pushd/popd, but it's extremely slow due to login in for each package. > > Is there a more clever way to get cvs up running w/o pulling in all of > the cvsroot? I could probably manually edit CVS/Entries, but this feels > a bit dirty. What are other packagers doing? With respect to the ssh logins required for each cvs operation, I tend to use opportunistic connection multiplexing. e.g., in my ~/.ssh/config I have: ---- ControlMaster auto ControlPath ~/.ssh/sockets/%h_%p_%r_multi.sock Host cvs.fedora.redhat.com Compression yes CompressionLevel 3 ---- And then I just do a "ssh -f -N cvs.fedora.redhat.com". It authenticates me once, then just kicks around in the background until I perform a network operation though CVS, at which point the "new" connection is routed through the existing one. If I haven't forked off a connection to c.f.r.c, no biggie, ssh just connects per usual. This won't help with selectively pulling down CVS, but it should make each operation a smidge faster :-) -Chris -- Chris Weyl Ex astris, scientia From dennis at ausil.us Sun Aug 24 21:51:05 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 24 Aug 2008 16:51:05 -0500 Subject: Maintaining a partial cvs workarea In-Reply-To: <7dd7ab490808241416j21c6d1d4va3b9b66f5d68364e@mail.gmail.com> References: <20080824164439.GA29038@victor.nirvana> <7dd7ab490808241416j21c6d1d4va3b9b66f5d68364e@mail.gmail.com> Message-ID: <200808241651.18302.dennis@ausil.us> On Sunday 24 August 2008 04:16:33 pm Chris Weyl wrote: > 2008/8/24 Axel Thimm : > > Hi, > > > > I'm keeping only a partial checkout of the packages, e.g. the ones I'm > > maintaining. Now I'd like to be able to cvs up and have all updates > > flow in, but if I do so cvs will want to get all other thousand > > packages in. > > > > Until now I'm using a poor man's solution with a for loop and > > pushd/popd, but it's extremely slow due to login in for each package. > > > > Is there a more clever way to get cvs up running w/o pulling in all of > > the cvsroot? I could probably manually edit CVS/Entries, but this feels > > a bit dirty. What are other packagers doing? > > With respect to the ssh logins required for each cvs operation, I tend > to use opportunistic connection multiplexing. e.g., in my > ~/.ssh/config I have: > > ---- > ControlMaster auto > ControlPath ~/.ssh/sockets/%h_%p_%r_multi.sock > > Host cvs.fedora.redhat.com > Compression yes > CompressionLevel 3 > ---- > > And then I just do a "ssh -f -N cvs.fedora.redhat.com". It > authenticates me once, then just kicks around in the background until > I perform a network operation though CVS, at which point the "new" > connection is routed through the existing one. If I haven't forked > off a connection to c.f.r.c, no biggie, ssh just connects per usual. > > This won't help with selectively pulling down CVS, but it should make > each operation a smidge faster :-) > > -Chris That shouldnt work with the Makefiles. since they all use cvs.fedoraproject.org not the old legacy address :) 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 cweyl at alumni.drew.edu Sun Aug 24 21:55:41 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 24 Aug 2008 14:55:41 -0700 Subject: Maintaining a partial cvs workarea In-Reply-To: <200808241651.18302.dennis@ausil.us> References: <20080824164439.GA29038@victor.nirvana> <7dd7ab490808241416j21c6d1d4va3b9b66f5d68364e@mail.gmail.com> <200808241651.18302.dennis@ausil.us> Message-ID: <7dd7ab490808241455y18ccd5ffp169d39632a21feb4@mail.gmail.com> 2008/8/24 Dennis Gilmore : > That shouldnt work with the Makefiles. since they all use > cvs.fedoraproject.org not the old legacy address :) s/cvs.fedora.redhat.com/cvs.fedoraproject.org/ in the above then :) I've never had any issues.... Though, I _really_ ought to update my checkout to use the new addy. (Yes, I've had my cvs checkout since way before it became an old legacy address, and I hate change :-) ) -Chris -- Chris Weyl Ex astris, scientia From Axel.Thimm at ATrpms.net Mon Aug 25 07:32:48 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 25 Aug 2008 10:32:48 +0300 Subject: Maintaining a partial cvs workarea In-Reply-To: <7dd7ab490808241455y18ccd5ffp169d39632a21feb4@mail.gmail.com> References: <20080824164439.GA29038@victor.nirvana> <7dd7ab490808241416j21c6d1d4va3b9b66f5d68364e@mail.gmail.com> <200808241651.18302.dennis@ausil.us> <7dd7ab490808241455y18ccd5ffp169d39632a21feb4@mail.gmail.com> Message-ID: <20080825073248.GB1665@victor.nirvana> On Sun, Aug 24, 2008 at 02:55:41PM -0700, Chris Weyl wrote: > 2008/8/24 Dennis Gilmore : > > That shouldnt work with the Makefiles. since they all use > > cvs.fedoraproject.org not the old legacy address :) > > s/cvs.fedora.redhat.com/cvs.fedoraproject.org/ in the above then :) > I've never had any issues.... Though, I _really_ ought to update my > checkout to use the new addy. > > (Yes, I've had my cvs checkout since way before it became an old > legacy address, and I hate change :-) ) I also need to move my Roots to something new age. Wasn't there a tool for CVS? Or some perl/sed magic to do that? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jkeating at redhat.com Mon Aug 25 20:56:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Aug 2008 16:56:08 -0400 Subject: securing FAS certs In-Reply-To: <48AFBFBF.3080608@wormgoor.com> References: <48ADB799.3070206@gmail.com> <935ead450808211218v1049cdbdh3f9db43a0287f8ed@mail.gmail.com> <20080821193438.GD31338@sphe.res.cmu.edu> <48ADCE84.6050608@gmail.com> <48AFBFBF.3080608@wormgoor.com> Message-ID: <1219697768.7942.5.camel@luminos.localdomain> On Sat, 2008-08-23 at 09:43 +0200, Mark Wormgoor wrote: > > Most of these cards work with OpenSSL just fine - though I'm not sure > what additional hardware drivers are required to interface to the card. The crypto cards I'm aware of require a binary kernel driver. Not suitable for Fedora infrastructure. The gpg smartcards I ordered are finally on the way, a billing snafu prevented them from showing up earlier. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 mmcgrath at redhat.com Tue Aug 26 00:58:00 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 25 Aug 2008 19:58:00 -0500 (CDT) Subject: Notification - 2008-08-26 23:00 UTC Message-ID: There was an outage starting at 2008-08-26 23:00 UTC, which lasted approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-08-26 23:00 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/784 Reason for Outage: Cooling issues in our primary datacenter caused some ambient temperatures to hit 39C/102F. After hitting a critical point many of our servers shut themselves down. After the issue was corrected and things cooled down, we powered up the servers without issue. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From Matt_Domsch at dell.com Tue Aug 26 13:22:48 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 26 Aug 2008 08:22:48 -0500 Subject: Broken link - mirrors.fp.o/publiclist failing since 8/19 Message-ID: <20080826132248.GB26241@auslistsprd01.us.dell.com> Not clear why it's failing, but app4 is throwing 404s to this, though the content is there... ----- Forwarded message from Bennet Fauber ----- Delivered-To: webmaster at fedoraproject.org Date: Tue, 19 Aug 2008 15:08:45 -0400 (EDT) From: Bennet Fauber To: webmaster at fedoraproject.org Cc: Subject: Broken link On the page at http://fedoraproject.org/get-fedora the link to "See all mirrors" (which points to http://mirrors.fedoraproject.org/publiclist/Fedora/9/ ) returns Not Found The requested URL /mirrorlists/publiclist//Fedora/9/ was not found on this server. as do the following http://mirrors.fedoraproject.org/publiclist/Fedora/9/ http://mirrors.fedoraproject.org/publiclist/Fedora/ http://mirrors.fedoraproject.org/publiclist/ http://mirrors.fedoraproject.org/ Maybe I'm missing something really obvious...? -- bennet -- Mathematics Department University of Michigan (734) 763-6521 -- Fedora-websites-list mailing list Fedora-websites-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-websites-list ----- End forwarded message ----- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jkeating at redhat.com Tue Aug 26 13:59:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Aug 2008 09:59:01 -0400 Subject: Puppet help - group membership on specific host Message-ID: <1219759141.17206.14.camel@luminos.localdomain> I need a puppet trick. We have a shared user, masher, that has write access to the mash/ directory on the koji store (but not the packages!). This user currently exists on nfs1 and releng2. On releng2 the user is used to run the rawhide creation cron, which involves running mock. To run mock, the user must be in the 'mock' group. However this group (which comes from the mock package) doesn't exist on nfs1 and we'd like to keep it that way. So, I need a way in puppet to express that the 'masher' user on releng2 needs to be in the mock group, but only on releng2. Any thoughts/examples? This is probably one of those "puppet tricks" we should have in a wiki somewhere. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 smooge at gmail.com Tue Aug 26 17:49:22 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 26 Aug 2008 11:49:22 -0600 Subject: securing FAS certs In-Reply-To: <48ADB799.3070206@gmail.com> References: <48ADB799.3070206@gmail.com> Message-ID: <80d7e4090808261049r51a6402dpe919caeff071f66@mail.gmail.com> 2008/8/21 Toshio Kuratomi : > Hey bright idea bringers! > > The Fedora Certificates issued by FAS are currently set to be autogenerated > if you have an account in FAS. This has one drawback. We have to keep the > password for the CA keys that sign the FAS certificates in a file on the > filesystem so that the automatic signing can use them. > > Has anyone else had to confront this problem? Right now I'm thinking of > coding something that involves human interaction to sign the certs and send > email notifying people when their cert is ready to download. That's > certainly doable, but introduces a wait time that isn't in the current > design. I'd love input on better ways to do this. > It depends on the level of security we are wanting. The most secure places I have been at always make sure there is a human in the loop, and that human's events are regularly and randomly audited. Even having hardware tokens to generate things (we had a device that was hooked in via a serial port so it did not need a kernel driver) for a high level of CIA you may want a set of humans looking at it. However it puts in a delay. We would put a 24 hour delay in getting/creating certs for people which meant we had time to confirm that the person really was supposed to get it etc.. If the delay and the fact that we aren't doing background checks on applicants, we probably want to do a multi-tier level of creating tokens. One set would be ones that people need to be vetted somehow and have more keys to the kingdom. The other set would be for people doing common work flow at the project. I wonder if we can come up with some serial port key generator. I think the design was a locked box where you keyed in the the master number via itsy-bitty dipswitches. -- 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 dan-fedora-i at drown.org Tue Aug 26 22:01:09 2008 From: dan-fedora-i at drown.org (Daniel Drown) Date: Tue, 26 Aug 2008 22:01:09 +0000 Subject: Puppet help - group membership on specific host In-Reply-To: <1219759141.17206.14.camel@luminos.localdomain> References: <1219759141.17206.14.camel@luminos.localdomain> Message-ID: <20080826220109.GA32053@vps.drown.org> On Tue, 26 Aug 2008, Jesse Keating wrote: > I need a puppet trick. We have a shared user, masher, that has write > access to the mash/ directory on the koji store (but not the packages!). > This user currently exists on nfs1 and releng2. On releng2 the user is > used to run the rawhide creation cron, which involves running mock. To > run mock, the user must be in the 'mock' group. However this group > (which comes from the mock package) doesn't exist on nfs1 and we'd like > to keep it that way. > > So, I need a way in puppet to express that the 'masher' user on releng2 > needs to be in the mock group, but only on releng2. > > Any thoughts/examples? This is probably one of those "puppet tricks" we > should have in a wiki somewhere. how about something like: user { "masher": ensure => "present", [etcetc] groups => $fqdn ? { "releng2" => ["mock"], "nfs1" => [] } } From skvidal at fedoraproject.org Wed Aug 27 03:57:25 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 26 Aug 2008 23:57:25 -0400 Subject: nfs1 and a test kernel Message-ID: <1219809445.12096.84.camel@rosebud> Having some issues with lockd dying on nfs1 - kevin fenzi was nice enough to point out: https://bugzilla.redhat.com/show_bug.cgi?id=453094 which suggests trying one of the kernels from: http://people.redhat.com/dzickus/el5/ so - any objections if I try one of those on nfs1 to see if it cures what ails us? -sv -- I only speak for me. From mmcgrath at redhat.com Wed Aug 27 13:16:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 27 Aug 2008 08:16:25 -0500 (CDT) Subject: nfs1 and a test kernel In-Reply-To: <1219809445.12096.84.camel@rosebud> References: <1219809445.12096.84.camel@rosebud> Message-ID: On Tue, 26 Aug 2008, seth vidal wrote: > Having some issues with lockd dying on nfs1 - kevin fenzi was nice > enough to point out: > > https://bugzilla.redhat.com/show_bug.cgi?id=453094 > > which suggests trying one of the kernels from: > > http://people.redhat.com/dzickus/el5/ > > so - any objections if I try one of those on nfs1 to see if it cures > what ails us? > Sure. we've tried everything else and the problem continues. Its better then it was but nfs is still aboard the failboat. -Mike From mmcgrath at redhat.com Wed Aug 27 19:08:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 27 Aug 2008 14:08:06 -0500 (CDT) Subject: Puppet move Message-ID: Hey guys I'm moving puppet this afternoon from xen13 to xen14. It'll be off for a bit, please leave it that way. -Mike From valholla75 at gmail.com Thu Aug 28 01:37:32 2008 From: valholla75 at gmail.com (Mike Watters) Date: Wed, 27 Aug 2008 20:37:32 -0500 Subject: Introductions Message-ID: <48B6015C.3050404@gmail.com> Hello, I have applied to the sysadmin group and would like to give you an overview my experience. I have been a systems admin or security analyst for 12 years at 3 major worldwide (US based) companies. the majority of the time I was a systems admin for Solaris, AIX I did about 2years of admin work for SGI and HPUX boxes. I did 2 years of security analyst for Solaris, AIX and RHEL. I have been using Fedora from Fedora 7 release. I am proficient in Perl, bash, ksh scripting. I am competent with C, C++ and Java ( I prefer C ) I am looking to learn Python. My programming/scripting is almost all CLI apps. I did some TCL/TK stuff long ago. I am learning GTK and Glade in my free time. using libglade and C. I am looking for a sponsor for the Sysadmin group Please let me know if you would like any further info. personal info. I have been married for 9 years and have 3 children, 2 boys 7 and 5 and 1 girl 18mo. I shoot pool on an APA league one night a week, I took the summer off to get some projects done around the house. I look to start again in a couple of weeks for the Fall session. I am a SL 5 in the APA. the ratings are from 2 ( extreme novice ) to 7 ( break and run 3 or more of 10 racks ) -- Mike From jkeating at redhat.com Thu Aug 28 04:44:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Aug 2008 21:44:02 -0700 Subject: rawhide, /mnt/koji and /pub/fedora Message-ID: <1219898642.5180.15.camel@luminos.localdomain> So I realized something last night. We created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this. Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there. For now, I'm syncing rawhide by hand. Comments? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 jkeating at redhat.com Thu Aug 28 04:52:30 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Aug 2008 21:52:30 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219898642.5180.15.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> Message-ID: <1219899150.5180.17.camel@luminos.localdomain> On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote: > Comments? One comment just made on IRC by G: f13: can't be allow masher to sudo to ftpsync and run a sync command? We would have to allow masher to sudo with no password in order to run the rsync command. I'm not sure how far we can narrow it down since the rsync source changes each day, only the dest (and other options) remain the same. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 dev at nigelj.com Thu Aug 28 04:55:26 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 28 Aug 2008 16:55:26 +1200 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219899150.5180.17.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> Message-ID: <1219899326.16777.6.camel@fantail.jnet.net.nz> On Wed, 2008-08-27 at 21:52 -0700, Jesse Keating wrote: > On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote: > > Comments? > > One comment just made on IRC by G: > > f13: can't be allow masher to sudo to ftpsync and run a sync > command? > G = $me :) > We would have to allow masher to sudo with no password in order to run > the rsync command. I'm not sure how far we can narrow it down since the > rsync source changes each day, only the dest (and other options) remain > the same. Why not something like: sudo /usr/local/bin/rawhideftpsync.sh that runs: rsync .... ... Just a thought. > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Nigel Jones From jkeating at redhat.com Thu Aug 28 05:51:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 27 Aug 2008 22:51:21 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219899326.16777.6.camel@fantail.jnet.net.nz> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> Message-ID: <1219902681.5180.20.camel@luminos.localdomain> On Thu, 2008-08-28 at 16:55 +1200, Nigel Jones wrote: > Why not something like: > > sudo /usr/local/bin/rawhideftpsync.sh > that runs: rsync .... ... I think I'd rather not have yet another script to puppet manage and such, so if we could just maybe allow rsync it might be fine. I just noticed we're going to have to do the same to allow it to do mail as the rawhide user (or somebody is going to have to tell me how to set the From address to something else when calling /bin/mail). -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 Thu Aug 28 06:52:13 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 28 Aug 2008 08:52:13 +0200 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219902681.5180.20.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> <1219902681.5180.20.camel@luminos.localdomain> Message-ID: <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> 2008/8/28 Jesse Keating > On Thu, 2008-08-28 at 16:55 +1200, Nigel Jones wrote: > > Why not something like: > > > > sudo /usr/local/bin/rawhideftpsync.sh > > that runs: rsync .... ... > > I think I'd rather not have yet another script to puppet manage and > such, so if we could just maybe allow rsync it might be fine. as nigel said, just allow masher to only sudo su - ftpsync from sudoer or to just rsync the specific dir I just noticed we're going to have to do the same to allow it to do mail > as the rawhide user (or somebody is going to have to tell me how to set > the From address to something else when calling /bin/mail). yeah, you can easily do that by invoking : /bin/mail -r From_adress hope that mailx is up to date ;) -- 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 kanarip at kanarip.com Thu Aug 28 09:57:50 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 28 Aug 2008 11:57:50 +0200 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219899326.16777.6.camel@fantail.jnet.net.nz> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> Message-ID: <48B6769E.6010108@kanarip.com> Nigel Jones wrote: > On Wed, 2008-08-27 at 21:52 -0700, Jesse Keating wrote: >> On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote: >>> Comments? >> One comment just made on IRC by G: >> >> f13: can't be allow masher to sudo to ftpsync and run a sync >> command? >> > G = $me :) >> We would have to allow masher to sudo with no password in order to run >> the rsync command. I'm not sure how far we can narrow it down since the >> rsync source changes each day, only the dest (and other options) remain >> the same. > Why not something like: > > sudo /usr/local/bin/rawhideftpsync.sh > that runs: rsync .... ... > > Just a thought. You could configure sudoers to allow the masher user to only be able to execute whatever it sudo's as the ftpsync user: masher hostname.domain.tld=(ftpsync) NOPASSWD: rsync $rsync_opts foo. bar Does that narrow it down sufficiently? Kind regards, Jeroen van Meeuwen -kanarip From aphukan.fedora at gmail.com Thu Aug 28 12:41:52 2008 From: aphukan.fedora at gmail.com (Amitakhya Phukan) Date: Thu, 28 Aug 2008 18:11:52 +0530 Subject: hello In-Reply-To: <486C771D.8090101@gmail.com> References: <980ad8bc0807020651q3bd06fdbgf1b67c5b13d34daa@mail.gmail.com> <486C771D.8090101@gmail.com> Message-ID: <48B69D10.4070701@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amitakhya Phukan wrote: > 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. hi, anyone out there to sponsor me ? :) regards, amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki2nQ0ACgkQisV6fTFpwA05NwCeNDi4M+DhhKCydwEs8X3G08W5 hDAAn1KvNl1o658WB92fnMDZSpvhIN/s =AzUe -----END PGP SIGNATURE----- From mmcgrath at redhat.com Thu Aug 28 13:42:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Aug 2008 08:42:09 -0500 (CDT) Subject: Introductions In-Reply-To: <48B6015C.3050404@gmail.com> References: <48B6015C.3050404@gmail.com> Message-ID: On Wed, 27 Aug 2008, Mike Watters wrote: > Hello, > I have applied to the sysadmin group and would like to give you an overview my > experience. > > I have been a systems admin or security analyst for 12 years at 3 major > worldwide (US based) companies. the majority of the time I was a systems > admin for Solaris, AIX > I did about 2years of admin work for SGI and HPUX boxes. I did 2 years of > security analyst for Solaris, AIX and RHEL. I have been using Fedora from > Fedora 7 release. I am proficient in Perl, bash, ksh scripting. I am > competent with C, C++ and Java ( I prefer C ) I am looking to learn Python. > > My programming/scripting is almost all CLI apps. I did some TCL/TK stuff long > ago. > I am learning GTK and Glade in my free time. using libglade and C. > > I am looking for a sponsor for the Sysadmin group > > Please let me know if you would like any further info. > > personal info. I have been married for 9 years and have 3 children, 2 boys 7 > and 5 and 1 girl 18mo. I shoot pool on an APA league one night a week, I > took the summer off to get some projects done around the house. I look to > start again in a couple of weeks for the Fall session. I am a SL 5 in the APA. > the ratings are from 2 ( extreme novice ) to 7 ( break and run 3 or more of > 10 racks ) > Welcome Mike! Keep on people until you find a sponsor. Make sure to come to our meetings if you can make them: http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From mmcgrath at redhat.com Thu Aug 28 13:42:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Aug 2008 08:42:40 -0500 (CDT) Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219898642.5180.15.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> Message-ID: On Wed, 27 Aug 2008, Jesse Keating wrote: > So I realized something last night. We created a user "masher" to have > the ability to write to /mnt/koji/mash/ but not any of the other koji > space. This is useful to prevent too much damage from a horribly wrong > rawhide compose. To make things easier in the rawhide compose configs, > we decided to run the cron/scripts as the masher user. This is also > good because it means things run unprivileged. However I ran into a > snag. We have another user, 'ftpsync' that has write access > to /pub/fedora/. Previously the rawhide script was ran as root, and > thus it was no problem to su ftpsync for the rsync calls. The masher > user does not possess the capability of doing this. > > Since the ftpsync user is only really used to sync data onto the Fedora > netapp, I propose that we collapse ftpsync and masher into one user > (masher). It'll require minimal puppet changes, mostly just moving some > cron jobs from ftpsync over to masher. It will require UID changes, > either changing masher to the ftpsync UID (which breaks our new range we > just setup), or chmodding some stuff on the Fedora netapp and changing > what UID has write access there. > > For now, I'm syncing rawhide by hand. > > Comments? Fine by me. ftpsync isn't really one of ours anyway :) -Mike From skvidal at fedoraproject.org Thu Aug 28 13:54:28 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 28 Aug 2008 09:54:28 -0400 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: References: <1219898642.5180.15.camel@luminos.localdomain> Message-ID: <1219931668.12096.131.camel@rosebud> On Thu, 2008-08-28 at 08:42 -0500, Mike McGrath wrote: > On Wed, 27 Aug 2008, Jesse Keating wrote: > > > So I realized something last night. We created a user "masher" to have > > the ability to write to /mnt/koji/mash/ but not any of the other koji > > space. This is useful to prevent too much damage from a horribly wrong > > rawhide compose. To make things easier in the rawhide compose configs, > > we decided to run the cron/scripts as the masher user. This is also > > good because it means things run unprivileged. However I ran into a > > snag. We have another user, 'ftpsync' that has write access > > to /pub/fedora/. Previously the rawhide script was ran as root, and > > thus it was no problem to su ftpsync for the rsync calls. The masher > > user does not possess the capability of doing this. > > > > Since the ftpsync user is only really used to sync data onto the Fedora > > netapp, I propose that we collapse ftpsync and masher into one user > > (masher). It'll require minimal puppet changes, mostly just moving some > > cron jobs from ftpsync over to masher. It will require UID changes, > > either changing masher to the ftpsync UID (which breaks our new range we > > just setup), or chmodding some stuff on the Fedora netapp and changing > > what UID has write access there. > > > > For now, I'm syncing rawhide by hand. > > > > Comments? > > Fine by me. ftpsync isn't really one of ours anyway :) > it and masher are, however, names that need to get added to the banlist in fas, I think. -sv From mmcgrath at redhat.com Thu Aug 28 15:13:33 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Aug 2008 10:13:33 -0500 (CDT) Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219931668.12096.131.camel@rosebud> References: <1219898642.5180.15.camel@luminos.localdomain> <1219931668.12096.131.camel@rosebud> Message-ID: On Thu, 28 Aug 2008, Seth Vidal wrote: > On Thu, 2008-08-28 at 08:42 -0500, Mike McGrath wrote: > > On Wed, 27 Aug 2008, Jesse Keating wrote: > > > > > So I realized something last night. We created a user "masher" to have > > > the ability to write to /mnt/koji/mash/ but not any of the other koji > > > space. This is useful to prevent too much damage from a horribly wrong > > > rawhide compose. To make things easier in the rawhide compose configs, > > > we decided to run the cron/scripts as the masher user. This is also > > > good because it means things run unprivileged. However I ran into a > > > snag. We have another user, 'ftpsync' that has write access > > > to /pub/fedora/. Previously the rawhide script was ran as root, and > > > thus it was no problem to su ftpsync for the rsync calls. The masher > > > user does not possess the capability of doing this. > > > > > > Since the ftpsync user is only really used to sync data onto the Fedora > > > netapp, I propose that we collapse ftpsync and masher into one user > > > (masher). It'll require minimal puppet changes, mostly just moving some > > > cron jobs from ftpsync over to masher. It will require UID changes, > > > either changing masher to the ftpsync UID (which breaks our new range we > > > just setup), or chmodding some stuff on the Fedora netapp and changing > > > what UID has write access there. > > > > > > For now, I'm syncing rawhide by hand. > > > > > > Comments? > > > > Fine by me. ftpsync isn't really one of ours anyway :) > > > > it and masher are, however, names that need to get added to the banlist > in fas, I think. > Anyone care to think of a less manual way of doing this? -Mike From jkeating at j2solutions.net Thu Aug 28 15:42:22 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 28 Aug 2008 08:42:22 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <48B6769E.6010108@kanarip.com> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> <48B6769E.6010108@kanarip.com> Message-ID: <1219938142.6655.0.camel@luminos.localdomain> On Thu, 2008-08-28 at 11:57 +0200, Jeroen van Meeuwen wrote: > > You could configure sudoers to allow the masher user to only be able to > execute whatever it sudo's as the ftpsync user: > > masher hostname.domain.tld=(ftpsync) NOPASSWD: rsync $rsync_opts > foo. bar > > Does that narrow it down sufficiently? I think so. I'll play with this some today. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- 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 jkeating at redhat.com Thu Aug 28 16:22:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 09:22:43 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> <1219902681.5180.20.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> Message-ID: <1219940563.6655.3.camel@luminos.localdomain> On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > yeah, you can easily do that by invoking : /bin/mail -r From_adress > hope that mailx is up to date ;) Looks like that's not working in EL5. Pitty. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 skvidal at fedoraproject.org Thu Aug 28 16:27:12 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 28 Aug 2008 12:27:12 -0400 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219940563.6655.3.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> <1219902681.5180.20.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> <1219940563.6655.3.camel@luminos.localdomain> Message-ID: <1219940832.12096.151.camel@rosebud> On Thu, 2008-08-28 at 09:22 -0700, Jesse Keating wrote: > On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > > yeah, you can easily do that by invoking : /bin/mail -r From_adress > > hope that mailx is up to date ;) > > Looks like that's not working in EL5. Pitty. > a simple python script to do that is easy enough. -sv From jeff at ocjtech.us Thu Aug 28 16:34:10 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 28 Aug 2008 11:34:10 -0500 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219940832.12096.151.camel@rosebud> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> <1219902681.5180.20.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> <1219940563.6655.3.camel@luminos.localdomain> <1219940832.12096.151.camel@rosebud> Message-ID: <935ead450808280934geaacc62lef2da37d45bf5822@mail.gmail.com> On Thu, Aug 28, 2008 at 11:27 AM, Seth Vidal wrote: > On Thu, 2008-08-28 at 09:22 -0700, Jesse Keating wrote: >> On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: >> > yeah, you can easily do that by invoking : /bin/mail -r From_adress >> > hope that mailx is up to date ;) >> >> Looks like that's not working in EL5. Pitty. > > a simple python script to do that is easy enough. Looks like configs/system/sendmail-unicode.py is already out there... -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From opensource at till.name Thu Aug 28 16:38:06 2008 From: opensource at till.name (Till Maas) Date: Thu, 28 Aug 2008 18:38:06 +0200 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219940563.6655.3.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> <1219940563.6655.3.camel@luminos.localdomain> Message-ID: <200808281838.13708.opensource@till.name> On Thu August 28 2008, Jesse Keating wrote: > On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > > yeah, you can easily do that by invoking : /bin/mail -r From_adress > > hope that mailx is up to date ;) > > Looks like that's not working in EL5. Pitty. This works for me on CentOS 5, after the "--" sendmail options can be used: /bin/mail -s SUBJECT to at example.com -- -f from at example.com -F "freeform from part" Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From laxathom at fedoraproject.org Thu Aug 28 17:08:32 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 28 Aug 2008 19:08:32 +0200 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219940563.6655.3.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> <1219899150.5180.17.camel@luminos.localdomain> <1219899326.16777.6.camel@fantail.jnet.net.nz> <1219902681.5180.20.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> <1219940563.6655.3.camel@luminos.localdomain> Message-ID: <62bc09df0808281008l6cd6e74do7ac8bfaa2fb1ecfd@mail.gmail.com> 2008/8/28 Jesse Keating > On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > > yeah, you can easily do that by invoking : /bin/mail -r From_adress > > hope that mailx is up to date ;) > > Looks like that's not working in EL5. Pitty. > hm... is installed rhel-5.2 working with mailx-8.1.1 on the box ? if so, that will imply to update it. This feature has been integrated from release 9.25 another way could be to add ~r From-adress in the header of the file content (should work for version =< 10.2 ). -- 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 Thu Aug 28 17:13:44 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 28 Aug 2008 10:13:44 -0700 Subject: Introductions In-Reply-To: <48B6015C.3050404@gmail.com> References: <48B6015C.3050404@gmail.com> Message-ID: <48B6DCC8.2010102@gmail.com> Mike Watters wrote: > Hello, > I have applied to the sysadmin group and would like to give you an > overview my experience. > > I have been a systems admin or security analyst for 12 years at 3 major > worldwide (US based) companies. the majority of the time I was a > systems admin for Solaris, AIX > I did about 2years of admin work for SGI and HPUX boxes. I did 2 years > of security analyst for Solaris, AIX and RHEL. I have been using Fedora > from Fedora 7 release. I am proficient in Perl, bash, ksh scripting. > I am competent with C, C++ and Java ( I prefer C ) I am looking to > learn Python. > > My programming/scripting is almost all CLI apps. I did some TCL/TK > stuff long ago. > I am learning GTK and Glade in my free time. using libglade and C. > > I am looking for a sponsor for the Sysadmin group > > Please let me know if you would like any further info. > > personal info. I have been married for 9 years and have 3 children, 2 > boys 7 and 5 and 1 girl 18mo. I shoot pool on an APA league one night a > week, I took the summer off to get some projects done around the > house. I look to start again in a couple of weeks for the Fall session. > I am a SL 5 in the APA. the ratings are from 2 ( extreme novice ) to > 7 ( break and run 3 or more of 10 racks ) > Hi Mike, are you interested in continuing to learn python? If so, I have a bunch of projects that you can help out with from command line apps to TurboGears web applications. If you're on IRC, you can ping me on irc.freenode.net #fedora-admin abadger1999 and let me know what you might be interested in. -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 orion at cora.nwra.com Thu Aug 28 17:40:39 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Aug 2008 11:40:39 -0600 Subject: Strange popen behavior on xen builders? In-Reply-To: <48B6CEBB.4070602@cora.nwra.com> References: <489B804D.3010705@cora.nwra.com> <48A9F487.5000904@cora.nwra.com> <48B6CEBB.4070602@cora.nwra.com> Message-ID: <48B6E317.6090301@cora.nwra.com> Orion Poplawski wrote: > Orion Poplawski wrote: >> Filed bug #459442 as I have a simple test case. Once everything is >> back up we can test again. >> > > It appears that the pipe2 syscall on the x86_64 xen kernels is broken > and that rawhide glibc has moved to using pipe2 from pipe in rawhide. > > This seems like a blocker to me. > Okay, looks like a known issue with the xen kernels. New test kernels are available, see the bug for more info. We should get a fixed version onto the Fedora xen builders very soon, and maybe disable them until they can be fixed? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From valholla75 at gmail.com Thu Aug 28 18:09:08 2008 From: valholla75 at gmail.com (Mike) Date: Thu, 28 Aug 2008 13:09:08 -0500 Subject: Introductions In-Reply-To: <48B6DCC8.2010102@gmail.com> References: <48B6015C.3050404@gmail.com> <48B6DCC8.2010102@gmail.com> Message-ID: Toshio, I am most definitely interested, I will jump on IRC as soon as I can find a hole in the firewall at work, Otherwise I will be on when I get back home. I am in US Central Time. if I can find a hole before the meeting I will attend. if possible can you shoot me an email with a cli project so I can get a jump on it. 2008/8/28 Toshio Kuratomi > Mike Watters wrote: > >> Hello, >> I have applied to the sysadmin group and would like to give you an >> overview my experience. >> >> I have been a systems admin or security analyst for 12 years at 3 major >> worldwide (US based) companies. the majority of the time I was a systems >> admin for Solaris, AIX >> I did about 2years of admin work for SGI and HPUX boxes. I did 2 years of >> security analyst for Solaris, AIX and RHEL. I have been using Fedora from >> Fedora 7 release. I am proficient in Perl, bash, ksh scripting. I am >> competent with C, C++ and Java ( I prefer C ) I am looking to learn Python. >> >> My programming/scripting is almost all CLI apps. I did some TCL/TK stuff >> long ago. >> I am learning GTK and Glade in my free time. using libglade and C. >> >> I am looking for a sponsor for the Sysadmin group >> >> Please let me know if you would like any further info. >> >> personal info. I have been married for 9 years and have 3 children, 2 >> boys 7 and 5 and 1 girl 18mo. I shoot pool on an APA league one night a >> week, I took the summer off to get some projects done around the house. I >> look to start again in a couple of weeks for the Fall session. I am a SL 5 >> in the APA. the ratings are from 2 ( extreme novice ) to 7 ( break and >> run 3 or more of 10 racks ) >> >> > Hi Mike, are you interested in continuing to learn python? If so, I have > a bunch of projects that you can help out with from command line apps to > TurboGears web applications. > > If you're on IRC, you can ping me on irc.freenode.net #fedora-admin > abadger1999 and let me know what you might be interested in. > > -Toshio > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Thu Aug 28 13:49:21 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 28 Aug 2008 09:49:21 -0400 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219898642.5180.15.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> Message-ID: <20080828134921.GA3708@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > So I realized something last night. We created a user "masher" to have > the ability to write to /mnt/koji/mash/ but not any of the other koji > space. This is useful to prevent too much damage from a horribly wrong > rawhide compose. To make things easier in the rawhide compose configs, > we decided to run the cron/scripts as the masher user. This is also > good because it means things run unprivileged. However I ran into a > snag. We have another user, 'ftpsync' that has write access > to /pub/fedora/. Previously the rawhide script was ran as root, and > thus it was no problem to su ftpsync for the rsync calls. The masher > user does not possess the capability of doing this. > > Since the ftpsync user is only really used to sync data onto the Fedora > netapp, I propose that we collapse ftpsync and masher into one user > (masher). It'll require minimal puppet changes, mostly just moving some > cron jobs from ftpsync over to masher. It will require UID changes, > either changing masher to the ftpsync UID (which breaks our new range we > just setup), or chmodding some stuff on the Fedora netapp and changing > what UID has write access there. > > For now, I'm syncing rawhide by hand. > > Comments? Is changing the user that owns the files going to cause unnecessary rsync churn for mirrors? Bill From mmcgrath at redhat.com Thu Aug 28 19:58:03 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Aug 2008 14:58:03 -0500 (CDT) Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <20080828134921.GA3708@nostromo.devel.redhat.com> References: <1219898642.5180.15.camel@luminos.localdomain> <20080828134921.GA3708@nostromo.devel.redhat.com> Message-ID: On Thu, 28 Aug 2008, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > So I realized something last night. We created a user "masher" to have > > the ability to write to /mnt/koji/mash/ but not any of the other koji > > space. This is useful to prevent too much damage from a horribly wrong > > rawhide compose. To make things easier in the rawhide compose configs, > > we decided to run the cron/scripts as the masher user. This is also > > good because it means things run unprivileged. However I ran into a > > snag. We have another user, 'ftpsync' that has write access > > to /pub/fedora/. Previously the rawhide script was ran as root, and > > thus it was no problem to su ftpsync for the rsync calls. The masher > > user does not possess the capability of doing this. > > > > Since the ftpsync user is only really used to sync data onto the Fedora > > netapp, I propose that we collapse ftpsync and masher into one user > > (masher). It'll require minimal puppet changes, mostly just moving some > > cron jobs from ftpsync over to masher. It will require UID changes, > > either changing masher to the ftpsync UID (which breaks our new range we > > just setup), or chmodding some stuff on the Fedora netapp and changing > > what UID has write access there. > > > > For now, I'm syncing rawhide by hand. > > > > Comments? > > Is changing the user that owns the files going to cause unnecessary rsync > churn for mirrors? > Only if we change the uid of ftpsync. If we change the uid of masher we're good on the mirrors. -Mike From frankc.fedora at gmail.com Thu Aug 28 20:30:52 2008 From: frankc.fedora at gmail.com (Frank Chiulli) Date: Thu, 28 Aug 2008 13:30:52 -0700 Subject: Introductions In-Reply-To: References: <48B6015C.3050404@gmail.com> <48B6DCC8.2010102@gmail.com> Message-ID: 2008/8/28 Mike : > Toshio, > > I am most definitely interested, I will jump on IRC as soon as I can find a > hole in the firewall at work, Otherwise I will be on when I get back home. > I am in US Central Time. if I can find a hole before the meeting I will > attend. > > if possible can you shoot me an email with a cli project so I can get a jump > on it. > > Mike, You might take a look at http://www.mibbit.com. It's a web interface to IRC. Frank From jkeating at redhat.com Thu Aug 28 20:31:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 13:31:32 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: References: <1219898642.5180.15.camel@luminos.localdomain> <20080828134921.GA3708@nostromo.devel.redhat.com> Message-ID: <1219955492.6655.16.camel@luminos.localdomain> On Thu, 2008-08-28 at 14:58 -0500, Mike McGrath wrote: > > Is changing the user that owns the files going to cause unnecessary rsync > > churn for mirrors? > > > > Only if we change the uid of ftpsync. If we change the uid of masher > we're good on the mirrors. I went the sudo route. I was able to narrow the command down considerably for safety. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 wtogami at redhat.com Thu Aug 28 20:31:27 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 28 Aug 2008 16:31:27 -0400 Subject: New Key Repo Locations Message-ID: <48B70B1F.4010206@redhat.com> This is the latest draft of New Key repo locations. Jesse Keating points out that the deep levels are necessary because mirrors exclude releases by directory name like "9/". Please let me know if you see any errors in the below. Release Before (no yum repo file) http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os/ Release After (no yum repo file) http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os.newkey/ fedora http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ fedora-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os.newkey/ fedora-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/ fedora-debuginfo-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug.newkey/ fedora-source http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/ fedora-source-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS.newkey/ updates http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/ updates-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/ updates-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/debug/ updates-debuginfo-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/debug/ updates-source http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS/ updates-source-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS.newkey/ updates-testing http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/ updates-testing-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/ updates-testing-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/debug/ updates-testing-debuginfo-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/debug/ updates-testing-source http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS/ updates-testing-source-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS.newkey/ From jkeating at redhat.com Thu Aug 28 20:36:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 13:36:51 -0700 Subject: New Key Repo Locations In-Reply-To: <48B70B1F.4010206@redhat.com> References: <48B70B1F.4010206@redhat.com> Message-ID: <1219955811.6655.19.camel@luminos.localdomain> > On Thu, 2008-08-28 at 16:31 -0400, Warren Togami wrote: > This is the latest draft of New Key repo locations. Jesse Keating > points out that the deep levels are necessary because mirrors exclude > releases by directory name like "9/". Please let me know if you see any > errors in the below. Also, "newkey" is literal. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 mmcgrath at redhat.com Thu Aug 28 21:02:30 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 28 Aug 2008 16:02:30 -0500 (CDT) Subject: publictest15 Message-ID: Publictest15 is up and ready. If you were using publictest10, start getting your stuff set back up on publictest15. If you need things restored create a ticket and let us know what and why. Remember, the pt servers don't get backed up, you should never be storing info there where it is the only place that info exists. -Mike From jkeating at redhat.com Thu Aug 28 22:17:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 15:17:44 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <200808281838.13708.opensource@till.name> References: <1219898642.5180.15.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> <1219940563.6655.3.camel@luminos.localdomain> <200808281838.13708.opensource@till.name> Message-ID: <1219961864.6655.34.camel@luminos.localdomain> On Thu, 2008-08-28 at 18:38 +0200, Till Maas wrote: > /bin/mail -s SUBJECT to at example.com -- -f from at example.com -F > "freeform from > part" Ah, that was the missing part. Thanks. I've tossed in git, will tag it once the current run is done. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 jkeating at redhat.com Thu Aug 28 22:17:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 15:17:44 -0700 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <200808281838.13708.opensource@till.name> References: <1219898642.5180.15.camel@luminos.localdomain> <62bc09df0808272352p38658f3cy3687486f65dbe314@mail.gmail.com> <1219940563.6655.3.camel@luminos.localdomain> <200808281838.13708.opensource@till.name> Message-ID: <1219961864.6655.34.camel@luminos.localdomain> On Thu, 2008-08-28 at 18:38 +0200, Till Maas wrote: > /bin/mail -s SUBJECT to at example.com -- -f from at example.com -F > "freeform from > part" Ah, that was the missing part. Thanks. I've tossed in git, will tag it once the current run is done. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 kanarip at kanarip.com Thu Aug 28 23:51:15 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 Aug 2008 01:51:15 +0200 Subject: New Key Repo Locations In-Reply-To: <48B70B1F.4010206@redhat.com> References: <48B70B1F.4010206@redhat.com> Message-ID: <48B739F3.9010506@kanarip.com> Warren Togami wrote: > This is the latest draft of New Key repo locations. Jesse Keating > points out that the deep levels are necessary because mirrors exclude > releases by directory name like "9/". Please let me know if you see any > errors in the below. > If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also excluded? If it's not, then I guess there's no point in the new directory being created either. Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from. Has creating/composing an entirely new 9.1/ release tree been considered? I guess recreating the entire release tree is a PITA (jigdo, iso, torrent, foo) even though updates would not be included other then maybe the updated fedora-release package (with the new rpm-gpg-keys and new repo configuration files)? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Thu Aug 28 23:59:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 16:59:22 -0700 Subject: New Key Repo Locations In-Reply-To: <48B739F3.9010506@kanarip.com> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> Message-ID: <1219967962.6655.44.camel@luminos.localdomain> On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote: > If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also > excluded? If it's not, then I guess there's no point in the new > directory being created either. Yes, if 9 is excluded (or included) that means the admin either doesn't care about 9 and doesn't want to mirror it, or explicitly cares about it and only wants to mirror it. Either way I wish to honor those choices by not changing the top level directory where "9" or "8" will be. This also means we won't have to re-file our export approval. > > Will the ISOs be respun to reflect the changes as well so that what is > in os/ or in os.newkey/ meets what each of the ISO expects? I guess this > is primarily relevant to respins, netinstalls and so forth, as the old > RPM-GPG-KEYs will be in the root of those ISOs and I can only presume > they are used, and people will want to use os.newkey/ as the tree to > install from. At this time, the isos will not be respun. We will however re-sign the SHA1SUM file with the new gpg key. We are certain that the content on the ISOs (and the numerous hard copies floating about) are safe. The only content to be left in the repos these isos will be able to access out of the box will be the transition fedora-update release, and the fixed packagekit for gpg importing. We'll also have mirrormanager direct all requests for the old dir directly to mirrors which we have ultimate control over. > > Has creating/composing an entirely new 9.1/ release tree been > considered? I guess recreating the entire release tree is a PITA (jigdo, > iso, torrent, foo) even though updates would not be included other then > maybe the updated fedora-release package (with the new rpm-gpg-keys and > new repo configuration files)? It was considered briefly, but not very much. Calling something 9.1 would also have a bit of an assumption that we've fixed some bugs or otherwise made it a better release, which we aren't doing. We're merely re-signing content and placing it in a slightly different directory, but it's still 9, not 9+something. (ditto 8) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 jonstanley at gmail.com Fri Aug 29 00:12:00 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 28 Aug 2008 20:12:00 -0400 Subject: New Key Repo Locations In-Reply-To: <1219967962.6655.44.camel@luminos.localdomain> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> Message-ID: Sorry for the top post, I'm on my crackberry. We need to male sure to CLEARLY communicate this to mirror admins. I'm sure that more than 1 excludes releases/9/ since it is considered to be static content after release in order to reduce the number of files for rsync to consider. On 8/28/08, Jesse Keating wrote: > On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote: >> If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also >> excluded? If it's not, then I guess there's no point in the new >> directory being created either. > > Yes, if 9 is excluded (or included) that means the admin either doesn't > care about 9 and doesn't want to mirror it, or explicitly cares about it > and only wants to mirror it. Either way I wish to honor those choices > by not changing the top level directory where "9" or "8" will be. This > also means we won't have to re-file our export approval. > >> >> Will the ISOs be respun to reflect the changes as well so that what is >> in os/ or in os.newkey/ meets what each of the ISO expects? I guess this >> is primarily relevant to respins, netinstalls and so forth, as the old >> RPM-GPG-KEYs will be in the root of those ISOs and I can only presume >> they are used, and people will want to use os.newkey/ as the tree to >> install from. > > At this time, the isos will not be respun. We will however re-sign the > SHA1SUM file with the new gpg key. We are certain that the content on > the ISOs (and the numerous hard copies floating about) are safe. The > only content to be left in the repos these isos will be able to access > out of the box will be the transition fedora-update release, and the > fixed packagekit for gpg importing. We'll also have mirrormanager > direct all requests for the old dir directly to mirrors which we have > ultimate control over. > >> >> Has creating/composing an entirely new 9.1/ release tree been >> considered? I guess recreating the entire release tree is a PITA (jigdo, >> iso, torrent, foo) even though updates would not be included other then >> maybe the updated fedora-release package (with the new rpm-gpg-keys and >> new repo configuration files)? > > It was considered briefly, but not very much. Calling something 9.1 > would also have a bit of an assumption that we've fixed some bugs or > otherwise made it a better release, which we aren't doing. We're merely > re-signing content and placing it in a slightly different directory, but > it's still 9, not 9+something. (ditto 8) > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating > -- Sent from Gmail for mobile | mobile.google.com Jon Stanley Fedora Bug Wrangler jstanley at fedoraproject.org From jkeating at redhat.com Fri Aug 29 00:22:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 17:22:11 -0700 Subject: New Key Repo Locations In-Reply-To: References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> Message-ID: <1219969331.6655.45.camel@luminos.localdomain> On Thu, 2008-08-28 at 20:12 -0400, Jon Stanley wrote: > Sorry for the top post, I'm on my crackberry. We need to male sure to > CLEARLY communicate this to mirror admins. I'm sure that more than 1 > excludes releases/9/ since it is considered to be static content after > release in order to reduce the number of files for rsync to consider. Yes, of course, this wouldn't be a silent change. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 kanarip at kanarip.com Fri Aug 29 00:32:08 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 Aug 2008 02:32:08 +0200 Subject: New Key Repo Locations In-Reply-To: <1219967962.6655.44.camel@luminos.localdomain> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> Message-ID: <48B74388.90801@kanarip.com> Jesse Keating wrote: > On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote: >> If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also >> excluded? If it's not, then I guess there's no point in the new >> directory being created either. > > Yes, if 9 is excluded (or included) that means the admin either doesn't > care about 9 and doesn't want to mirror it, or explicitly cares about it > and only wants to mirror it. Either way I wish to honor those choices > by not changing the top level directory where "9" or "8" will be. This > also means we won't have to re-file our export approval. > So, if 9/ is excluded from, say, the hourly sync a mirror does (since it only needs to be mirrored once), the os.newkey/ won't end up on the mirror, which is my primary concern. (I guess this has been answered, partly, in another reply in this thread already). >> Will the ISOs be respun to reflect the changes as well so that what is >> in os/ or in os.newkey/ meets what each of the ISO expects? I guess this >> is primarily relevant to respins, netinstalls and so forth, as the old >> RPM-GPG-KEYs will be in the root of those ISOs and I can only presume >> they are used, and people will want to use os.newkey/ as the tree to >> install from. > > At this time, the isos will not be respun. We will however re-sign the > SHA1SUM file with the new gpg key. We are certain that the content on > the ISOs (and the numerous hard copies floating about) are safe. The > only content to be left in the repos these isos will be able to access > out of the box will be the transition fedora-update release, and the > fixed packagekit for gpg importing. We'll also have mirrormanager > direct all requests for the old dir directly to mirrors which we have > ultimate control over. > I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files. For the other part, where mirrormanager directs requests to mirrors we have ultimate control over... is this going to interfere with the local mirrors someone like myself may have set up at home and at multiple customer sites? E.g., will clients in these netblocks be redirected to mirrors the Fedora Project has ultimate control over, or am I misunderstanding what you are saying? >> Has creating/composing an entirely new 9.1/ release tree been >> considered? I guess recreating the entire release tree is a PITA (jigdo, >> iso, torrent, foo) even though updates would not be included other then >> maybe the updated fedora-release package (with the new rpm-gpg-keys and >> new repo configuration files)? > > It was considered briefly, but not very much. Calling something 9.1 > would also have a bit of an assumption that we've fixed some bugs or > otherwise made it a better release, which we aren't doing. We're merely > re-signing content and placing it in a slightly different directory, but > it's still 9, not 9+something. (ditto 8) > This sounds to me like a not-really-technical argument. You're right in that the naming in releases/X.Y does imply a new and improved install tree. I think there's some other serious consequences to choosing to do it in the original X/ release tree though. I'm thinking, who gives a c* that there's not actually 'new and improved' content in the trees even though the naming suggests that there is, while it does carry an entirely new tree with ISOs and jigdo's and stuff that have the new signed content and make a full match between what you download and what you start using, like with a normal release. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Fri Aug 29 03:53:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 28 Aug 2008 20:53:12 -0700 Subject: New Key Repo Locations In-Reply-To: <48B74388.90801@kanarip.com> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> Message-ID: <1219981992.6655.50.camel@luminos.localdomain> On Fri, 2008-08-29 at 02:32 +0200, Jeroen van Meeuwen wrote: > I'm not sure how that solves the net install use case, especially if > mirrormanager is going to redirect to os.newkey/, as signatures used on > os.newkey/ packages will not meet what the installer expects the > signature to be on these files. See bug 998. Installer doesn't expect keys. > For the other part, where mirrormanager directs requests to mirrors we > have ultimate control over... is this going to interfere with the local > mirrors someone like myself may have set up at home and at multiple > customer sites? E.g., will clients in these netblocks be redirected to > mirrors the Fedora Project has ultimate control over, or am I > misunderstanding what you are saying? It's only for the queries for the old location. This drives all queries for the old locations to our server so that we can get them the transition fedora-release, pk and nothing else. Once they get the new fedora-release, they'll be hitting the new url, which mirror manager will do the normal thing, drive them to site local, or drive them to geo locations. As to what to do about site local mirrors for the old location, I don't think that has been fully discussed, that's probably a good item for nit-picking. > > >> Has creating/composing an entirely new 9.1/ release tree been > >> considered? I guess recreating the entire release tree is a PITA (jigdo, > >> iso, torrent, foo) even though updates would not be included other then > >> maybe the updated fedora-release package (with the new rpm-gpg-keys and > >> new repo configuration files)? > > > > It was considered briefly, but not very much. Calling something 9.1 > > would also have a bit of an assumption that we've fixed some bugs or > > otherwise made it a better release, which we aren't doing. We're merely > > re-signing content and placing it in a slightly different directory, but > > it's still 9, not 9+something. (ditto 8) > > > > This sounds to me like a not-really-technical argument. You're right in > that the naming in releases/X.Y does imply a new and improved install > tree. I think there's some other serious consequences to choosing to do > it in the original X/ release tree though. I'm thinking, who gives a c* > that there's not actually 'new and improved' content in the trees even > though the naming suggests that there is, while it does carry an > entirely new tree with ISOs and jigdo's and stuff that have the new > signed content and make a full match between what you download and what > you start using, like with a normal release. It's a lot of work for little gain. What you're downloading, the isos, and what you start using, the content from the isos, will be matching, the same. It's the updates or extra packages you install after that which will have a new key on them. Rpm doesn't currently possess a way to verify the GPG keys on installed packages, so I'm told, so those installed from isos having the old key doesn't much matter. It's the new packages one would fetch over the internet that matter. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 wtogami at redhat.com Fri Aug 29 04:15:23 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 29 Aug 2008 00:15:23 -0400 Subject: New Key Repo Locations In-Reply-To: <48B74388.90801@kanarip.com> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> Message-ID: <48B777DB.9010108@redhat.com> Jeroen van Meeuwen wrote: >>> Will the ISOs be respun to reflect the changes as well so that what is >>> in os/ or in os.newkey/ meets what each of the ISO expects? I guess this >>> is primarily relevant to respins, netinstalls and so forth, as the old >>> RPM-GPG-KEYs will be in the root of those ISOs and I can only presume >>> they are used, and people will want to use os.newkey/ as the tree to >>> install from. >> At this time, the isos will not be respun. We will however re-sign the >> SHA1SUM file with the new gpg key. We are certain that the content on >> the ISOs (and the numerous hard copies floating about) are safe. The >> only content to be left in the repos these isos will be able to access >> out of the box will be the transition fedora-update release, and the >> fixed packagekit for gpg importing. We'll also have mirrormanager >> direct all requests for the old dir directly to mirrors which we have >> ultimate control over. >> > > I'm not sure how that solves the net install use case, especially if > mirrormanager is going to redirect to os.newkey/, as signatures used on > os.newkey/ packages will not meet what the installer expects the > signature to be on these files. > You misunderstand the New Key plan. Mirrormanager for the existing repos fedora, updates and updates-testing will not redirect to the new location. Please read the plan again carefully. Warren Togami wtogami at redhat.com From jonathan at jonmasters.org Fri Aug 29 06:25:06 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Fri, 29 Aug 2008 02:25:06 -0400 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219898642.5180.15.camel@luminos.localdomain> References: <1219898642.5180.15.camel@luminos.localdomain> Message-ID: <1219991106.32464.48.camel@perihelion> On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote: > We have another user, 'ftpsync' that has write access > to /pub/fedora/. Previously the rawhide script was ran as root, and > thus it was no problem to su ftpsync for the rsync calls. The masher > user does not possess the capability of doing this. Now I'm no Fedora sysadmin (and the infrastructure doesn't appear to be publicly documented anywhere - beyond the basics) so it's likely that the mounts in question simply don't do ACLs right or you'd have already discussed it...but for the sake of mentioning it, you could just add an additional ACL onto the /pub/fedora directory writeable by master. Jon. From jonathan at jonmasters.org Fri Aug 29 06:27:49 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Fri, 29 Aug 2008 02:27:49 -0400 Subject: rawhide, /mnt/koji and /pub/fedora In-Reply-To: <1219991106.32464.48.camel@perihelion> References: <1219898642.5180.15.camel@luminos.localdomain> <1219991106.32464.48.camel@perihelion> Message-ID: <1219991269.32464.50.camel@perihelion> On Fri, 2008-08-29 at 02:25 -0400, Jon Masters wrote: > Now I'm no Fedora sysadmin (and the infrastructure doesn't appear to be > publicly documented anywhere - beyond the basics) so it's likely that > the mounts in question simply don't do ACLs right or you'd have already > discussed it...but for the sake of mentioning it, you could just add an > additional ACL onto the /pub/fedora directory writeable by master. s/master/masher/ (too used to typing "Masters" when I start typing those letters) Jon. From Axel.Thimm at ATrpms.net Fri Aug 29 08:14:05 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 29 Aug 2008 11:14:05 +0300 Subject: New Key Repo Locations In-Reply-To: <48B777DB.9010108@redhat.com> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> Message-ID: <20080829081405.GE22094@victor.nirvana> On Fri, Aug 29, 2008 at 12:15:23AM -0400, Warren Togami wrote: > Jeroen van Meeuwen wrote: >> I'm not sure how that solves the net install use case, especially if >> mirrormanager is going to redirect to os.newkey/, as signatures used on >> os.newkey/ packages will not meet what the installer expects the >> signature to be on these files. >> > > You misunderstand the New Key plan. Mirrormanager for the existing > repos fedora, updates and updates-testing will not redirect to the new > location. Please read the plan again carefully. Hi, where can this plan be read, I didn't see it in this list or any URL pointing to it. W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ronin3510 at gmail.com Fri Aug 29 09:00:27 2008 From: ronin3510 at gmail.com (ronin3510) Date: Fri, 29 Aug 2008 12:00:27 +0300 Subject: New Key Repo Locations In-Reply-To: <20080829081405.GE22094@victor.nirvana> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> Message-ID: <18a1fce80808290200ve2beb64j12b479f746016b85@mail.gmail.com> I think this is what you're looking for http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html 2008/8/29 Axel Thimm > On Fri, Aug 29, 2008 at 12:15:23AM -0400, Warren Togami wrote: > > Jeroen van Meeuwen wrote: > >> I'm not sure how that solves the net install use case, especially if > >> mirrormanager is going to redirect to os.newkey/, as signatures used on > >> os.newkey/ packages will not meet what the installer expects the > >> signature to be on these files. > >> > > > > You misunderstand the New Key plan. Mirrormanager for the existing > > repos fedora, updates and updates-testing will not redirect to the new > > location. Please read the plan again carefully. > > Hi, > > where can this plan be read, I didn't see it in this list or any URL > pointing to it. > > W/o knowing all details, why not move os to os.oldkey and use os as > the new key's content? If the key is considered compromised what > mirror admin would like to keep the old signed packages around anyhow? > -- > Axel.Thimm at ATrpms.net > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Fri Aug 29 10:54:40 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 Aug 2008 12:54:40 +0200 Subject: New Key Repo Locations In-Reply-To: <20080829081405.GE22094@victor.nirvana> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> Message-ID: <48B7D570.2050806@kanarip.com> Axel Thimm wrote: > W/o knowing all details, why not move os to os.oldkey and use os as > the new key's content? If the key is considered compromised what > mirror admin would like to keep the old signed packages around anyhow? > I think then the problem becomes that every existing installation points to os/ where it would need os.oldkey/ to get the packages it can check gpg keys on. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Fri Aug 29 11:32:35 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 Aug 2008 13:32:35 +0200 Subject: New Key Repo Locations In-Reply-To: <1219981992.6655.50.camel@luminos.localdomain> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <1219981992.6655.50.camel@luminos.localdomain> Message-ID: <48B7DE53.9050608@kanarip.com> Jesse Keating wrote: > On Fri, 2008-08-29 at 02:32 +0200, Jeroen van Meeuwen wrote: >> I'm not sure how that solves the net install use case, especially if >> mirrormanager is going to redirect to os.newkey/, as signatures used on >> os.newkey/ packages will not meet what the installer expects the >> signature to be on these files. > > See bug 998. Installer doesn't expect keys. > Right, that one slipped my mind. I guess that addresses the concern of net installations as well. >> For the other part, where mirrormanager directs requests to mirrors we >> have ultimate control over... is this going to interfere with the local >> mirrors someone like myself may have set up at home and at multiple >> customer sites? E.g., will clients in these netblocks be redirected to >> mirrors the Fedora Project has ultimate control over, or am I >> misunderstanding what you are saying? > > It's only for the queries for the old location. This drives all queries > for the old locations to our server so that we can get them the > transition fedora-release, pk and nothing else. This invalidates the .jigdo files then, right? These query the mirrorlist for the old location and need an old RPM file (or the checksums won't match). Once they get the new > fedora-release, they'll be hitting the new url, which mirror manager > will do the normal thing, drive them to site local, or drive them to geo > locations. As to what to do about site local mirrors for the old > location, I don't think that has been fully discussed, that's probably a > good item for nit-picking. > I guess if queries for the old location is redirected to a mirror fp.o has ultimate control over, just to update fedora-release and pk, it would not really pose a big problem as the clients will be redirected back to their local mirrors once they get these two updates. I'm sure there's some situations that block access to mirrors other then their own local mirror, but the admins at these locations should be smart enough to rewrite the requested URL in a (transparent?) proxy (which I presume they'll have anyway). > It's a lot of work for little gain. What you're downloading, the isos, > and what you start using, the content from the isos, will be matching, > the same. It's the updates or extra packages you install after that > which will have a new key on them. Rpm doesn't currently possess a way > to verify the GPG keys on installed packages, so I'm told, so those > installed from isos having the old key doesn't much matter. It's the > new packages one would fetch over the internet that matter. > Given that one bug that slipped my mind, you're right... Not even including the updates/ and/or updates.newkey/ repository during the installation would form a problem. For the composing part, I don't see how including os.newkey/ and updates.newkey/ would form a problem (even though it might). Kind regards, Jeroen van Meeuwen -kanarip From Axel.Thimm at ATrpms.net Fri Aug 29 13:32:19 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 29 Aug 2008 16:32:19 +0300 Subject: New Key Repo Locations In-Reply-To: <48B7D570.2050806@kanarip.com> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> Message-ID: <20080829133219.GA3009@victor.nirvana> On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: > Axel Thimm wrote: >> W/o knowing all details, why not move os to os.oldkey and use os as >> the new key's content? If the key is considered compromised what >> mirror admin would like to keep the old signed packages around anyhow? >> > > I think then the problem becomes that every existing installation points > to os/ where it would need os.oldkey/ to get the packages it can check > gpg keys on. But isn't this desired behaviour? We don't actually want os.oldkey/ to be used anymore (mid-term) as we need to revoce the key in case it has been stolen. Maybe we don't need os.*key at all. E.g. if a key has been stolen, burn all signed stuff and recreate them with a new key. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kanarip at kanarip.com Fri Aug 29 13:42:31 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 Aug 2008 15:42:31 +0200 Subject: New Key Repo Locations In-Reply-To: <20080829133219.GA3009@victor.nirvana> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> Message-ID: <48B7FCC7.1090208@kanarip.com> Axel Thimm wrote: > On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: >> Axel Thimm wrote: >>> W/o knowing all details, why not move os to os.oldkey and use os as >>> the new key's content? If the key is considered compromised what >>> mirror admin would like to keep the old signed packages around anyhow? >>> >> I think then the problem becomes that every existing installation points >> to os/ where it would need os.oldkey/ to get the packages it can check >> gpg keys on. > > But isn't this desired behaviour? We don't actually want os.oldkey/ to > be used anymore (mid-term) as we need to revoce the key in case it has > been stolen. Maybe we don't need os.*key at all. > > E.g. if a key has been stolen, burn all signed stuff and recreate them > with a new key. > The problem then becomes that a fedora-release package update needs to come from the old location which is the only location a currently running client knows about, signed with the old key (which again is all the running client knows about at this point). In addition, I think they are burning everything-but-the-relevant pieces (such as a fedora-release file with an updated repo config, and the packagekit update that is able to gpg key import). Kind regards, Jeroen van Meeuwen From Axel.Thimm at ATrpms.net Fri Aug 29 13:57:05 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 29 Aug 2008 16:57:05 +0300 Subject: New Key Repo Locations In-Reply-To: <48B7FCC7.1090208@kanarip.com> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> Message-ID: <20080829135705.GC3009@victor.nirvana> On Fri, Aug 29, 2008 at 03:42:31PM +0200, Jeroen van Meeuwen wrote: > Axel Thimm wrote: >> On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: >>> Axel Thimm wrote: >>>> W/o knowing all details, why not move os to os.oldkey and use os as >>>> the new key's content? If the key is considered compromised what >>>> mirror admin would like to keep the old signed packages around anyhow? >>>> >>> I think then the problem becomes that every existing installation >>> points to os/ where it would need os.oldkey/ to get the packages it >>> can check gpg keys on. >> >> But isn't this desired behaviour? We don't actually want os.oldkey/ to >> be used anymore (mid-term) as we need to revoce the key in case it has >> been stolen. Maybe we don't need os.*key at all. >> >> E.g. if a key has been stolen, burn all signed stuff and recreate them >> with a new key. >> > > The problem then becomes that a fedora-release package update needs to > come from the old location which is the only location a currently > running client knows about, signed with the old key (which again is all > the running client knows about at this point). If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open. IOW the users do need to acknowledge the change of keys (like you do when an ssh host key has been changed). Otherwise any user with an F9 DVD is susceptible for being spoofed anyway, we won't be able to cure that: The people that stole the key just need to get control over a mirror or even worse officially setup a mirror of their own and distribute their own content signed with the stolen key! The only way to not have this happen is to loudly announce that the old key is being revoked and content signed with it needs to be cast away and replaced. All this assumes that there is real suspicion that the old key has been stolen, but the new key procedure does indicate that case. Otherwise, if it is just being done for good measure, then it's a bad step. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kanarip at kanarip.com Fri Aug 29 14:13:15 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 29 Aug 2008 16:13:15 +0200 Subject: New Key Repo Locations In-Reply-To: <20080829135705.GC3009@victor.nirvana> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> Message-ID: <48B803FB.8020702@kanarip.com> Axel Thimm wrote: > If ATM the key is considered stolen, the users need to stop using the > key immediately anyway. Issuing a new package signed with the old key > is just keeping the racing window open. > > (...snip...) > I agree with you for the most part, but I'll leave the risk assessment and corresponding consequential response paradigm to the ones that know best what happened and are actually in a position to decide whether or not to revoke keys and nuke content or to make it an easy transition now just to be safe rather then sorry. Kind regards, Jeroen van Meeuwen -kanarip From jonstanley at gmail.com Fri Aug 29 18:56:38 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 29 Aug 2008 14:56:38 -0400 Subject: New Key Repo Locations In-Reply-To: <20080829135705.GC3009@victor.nirvana> References: <48B70B1F.4010206@redhat.com> <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> Message-ID: 2008/8/29 Axel Thimm : > If ATM the key is considered stolen, the users need to stop using the > key immediately anyway. Issuing a new package signed with the old key > is just keeping the racing window open. I don't think that the key is considered stolen atm. What has happened (to my limited knowledge) is that the machine storing the (encrypted) key was compromised, however, during the window of the compromise, the passphrase to the key was not entered. Therefore, what "they" have is an encrypted key that "they" don't know the passphrase to. > IOW the users do need to acknowledge the change of keys (like you do > when an ssh host key has been changed). Otherwise any user with an F9 > DVD is susceptible for being spoofed anyway, we won't be able to cure > that: The people that stole the key just need to get control over a Let's assume that the key *was* actually compromised, passhphrase and all. With the current plan, without additional intermediate compromises (say the user's DNS server), I still don't see the risk. We're using MM to redirect ALL requests for the old repo location to mirrors that we have ultimate control over. Therefore, "they" can setup a mirror and sign stuff with the old key, but it won't be used by the default config. Which brings up an interesting question in my mind - how are we ensuring that the old key is actually removed from user machines and no longer trusted? I remember something about the new fedora-release obsoleting the old key, but that was seen as not something we could do. Why not? > The only way to not have this happen is to loudly announce that the > old key is being revoked and content signed with it needs to be cast > away and replaced. That's pretty much what's happening. The issue that we have with a clean transistion is that the PackageKit that was included in Fedora 9 GA did not have the ability to import new keys, and we want this transition to be as painless as possible for our users. > All this assumes that there is real suspicion that the old key has > been stolen, but the new key procedure does indicate that > case. Otherwise, if it is just being done for good measure, then it's > a bad step. Why is it bad to exercise an abundance of caution in this situation? From apocaliv at hotmail.com Sat Aug 30 10:04:16 2008 From: apocaliv at hotmail.com (Alessio Santoro) Date: Sat, 30 Aug 2008 10:04:16 +0000 Subject: introducing myself In-Reply-To: <48B89597.9080208@gmail.com> References: <48B89597.9080208@gmail.com> Message-ID: > > Hi fedora!> > I'm Alessio and i'm an Italian webmaster. I ask you now sorry for my bad> > english!> > I'm interesting to help the fedore project as a webmaster, developing> > the websites and administrating it. But i'm interested to joint into Infrastructure group before> > My experiences:> > I worked a freelance webmaster for 3 years (and i'm working now),> > developing many different websites from e-commerces to blogs.> > 90% of websites that i developed were in PHP/MySQL language. This is the> > first language that i learned and i used (and i use).> > I know also (basic) C/C++, HTML, Perl, Python. I'm not a designer!! :P> > I managed many websites (personal and company websites), i have a good> > experience with many opensource CMS like Wiki, PHPnuke, Joomla,> > osCommerce, OpenCommercio...and much more!> > I worked for 2 years (parallament to these) in the Domains and Hosting> > sector. I worked for 2 hosting companies as a PHP developer (first) and> > a System Administrator. I have a good expericence with Cpanel, Plesk> > panel and other server panels, linux systems (server), ssh and linux> > server applications (ftp, dns applications...).> > I used Fedora, CentOS, RedHat and Ubuntu as linux system. I have also a> > Windows experience (I used and i'm using Windows 2000, Windows ME,> > Windows XP and Windows Vista).> > I have also a little experience in the game developing sector.> > > > My fedora account username is apocaliv.> > I hope that i can help the fedora project and the fedora infrastructure group.> > I wait your answer. Best Regards _________________________________________________________________ Sintonizzati su Messenger e accendi la TV! http://messengertv.msn.com/mkt/it-it/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: From Axel.Thimm at ATrpms.net Sat Aug 30 16:46:31 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 30 Aug 2008 19:46:31 +0300 Subject: New Key Repo Locations In-Reply-To: References: <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> Message-ID: <20080830164631.GA3831@victor.nirvana> On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: > 2008/8/29 Axel Thimm : > > > If ATM the key is considered stolen, the users need to stop using the > > key immediately anyway. Issuing a new package signed with the old key > > is just keeping the racing window open. > > I don't think that the key is considered stolen atm. What has happened > (to my limited knowledge) is that the machine storing the (encrypted) > key was compromised, however, during the window of the compromise, the > passphrase to the key was not entered. Therefore, what "they" have is > an encrypted key that "they" don't know the passphrase to. > > > IOW the users do need to acknowledge the change of keys (like you do > > when an ssh host key has been changed). Otherwise any user with an F9 > > DVD is susceptible for being spoofed anyway, we won't be able to cure > > that: The people that stole the key just need to get control over a > > Let's assume that the key *was* actually compromised, passhphrase and > all. With the current plan, without additional intermediate > compromises (say the user's DNS server), I still don't see the risk. > We're using MM to redirect ALL requests for the old repo location to > mirrors that we have ultimate control over. I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is. One of them is mine, and for what I know I could be the one having stolen the key injecting bad packages right now. Or maybe the key & passphrase show up on some hacker forums and anyone and his cat will be able to spoof us up. Also most security breaches actually happen with insider knowledge, so I could have registered a mirror just for trojaning the users that would be redirected to me. We'll see what the investigation will turn up, maybe we will see former Fedorians exercising criminal skills alongside packaging. > Therefore, "they" can setup a mirror and sign stuff with the old > key, but it won't be used by the default config. Why not? See above. Maybe new mirrors since the incident have not been allowed to registered, but what if the intruder registered them beforehand? > Which brings up an interesting question in my mind - how are we > ensuring that the old key is actually removed from user machines and > no longer trusted? I remember something about the new fedora-release > obsoleting the old key, but that was seen as not something we could > do. Why not? I also don't see a reason. Removing a key in %pre or %post is not an issue with rpm >= 4.3 (maybe even earlier). > > The only way to not have this happen is to loudly announce that the > > old key is being revoked and content signed with it needs to be cast > > away and replaced. > > That's pretty much what's happening. The issue that we have with a > clean transistion is that the PackageKit that was included in Fedora 9 > GA did not have the ability to import new keys, and we want this > transition to be as painless as possible for our users. Possibly better to have a non-painless and non-automatic transition, so F9 DVD owners don't get into any bad mirrors. > > All this assumes that there is real suspicion that the old key has > > been stolen, but the new key procedure does indicate that > > case. Otherwise, if it is just being done for good measure, then it's > > a bad step. > > Why is it bad to exercise an abundance of caution in this situation? Because there is not really such a thing as a grey zone in security assertions, it is either a security issue (of a certain gravity) or not. Either the key is considered compromized and one needs to do the full program, or it is reasonably considered safe (by a brute-force safe passphrase and really assuming the passphrase has not been lost to the intruder as well), in which case no steps are needed, but phasing it out before the computing power gets accessible to break it (e.g. new keys for F10 upwards). The current program looks like a mix of assuming "safe" (so the old key can be used for signing new packages, even if it just a few) and assuming "compromised" needing a resiging of all content. But actually w/o knowing the details and the outcome of the current investigation one can't really say much. It just looks like contradicting security measures (assuming "safe" vs "compromized"). [1] # lynx --dump 'http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=x86_64' # repo = fedora-9 arch = x86_64 Using preferred netblock Using Internet2 countr y = DE country = RO country = GB country = PL country = EE country = IT country = ES country = MD country = IL country = FR country = FI country = NL country = NO country = CH country = CZ country = SE country = DK country = LV country = IS country = AT country = IE http://mirror.atrpms.net/fedora/linux/releases/9/Everything/x86_64/os http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/releases/9/ Everything/x86_64/os http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/linux/releases/9/ Everything/x86_64/os http://ftp.stw-bonn.de/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.uni-bayreuth.de/linux/fedora/linux/releases/9/Everything/x86_64/os http://ftp.uni-koeln.de/mirrors/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.sunet.se/pub/Linux/distributions/fedora/linux/releases/9/Everything/x 86_64/os http://ftp.rhnet.is/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/release s/9/Everything/x86_64/os http://ftp.cica.es/fedora/linux/releases/9/Everything/x86_64/os http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/linux/releases/9/Everything /x86_64/os http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/9/E verything/x86_64/os http://ftp.sh.cvut.cz/MIRRORS/fedora/linux/releases/9/Everything/x86_64/os http://sunsite.rediris.es/mirror/fedora-redhat/releases/9/Everything/x86_64/os ftp://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everything/ x86_64/os http://ftp.SURFnet.nl/pub/os/Linux/distr/fedora/linux/releases/9/Everything/x86 _64/os http://ftp.lip6.fr/ftp/pub/linux/distributions/fedora/releases/9/Everything/x86 _64/os http://ftp.crc.dk/fedora/linux/releases/9/Everything/x86_64/os http://fr2.rpmfind.net/linux/fedora/releases/9/Everything/x86_64/os http://ftp.ps.pl/pub/Linux/fedora-linux/releases/9/Everything/x86_64/os http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/9/Everything/x86_64/os http://ultra.linux.cz/MIRRORS/fedora.redhat.com/linux/releases/9/Everything/x86 _64/os http://ftp.heanet.ie/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.klid.dk/ftp/fedora/linux/releases/9/Everything/x86_64/os http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/ releases/9/Everything/x86_64/os http://gd.tuwien.ac.at/opsys/linux/fedora/linux/releases/9/Everything/x86_64/os http://ftp.wcss.pl/pub/linux/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.uvsq.fr/pub/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.cru.fr/pub/linux/fedora/releases/9/Everything/x86_64/os http://mirrors.linux.edu.lv/ftp.redhat.com/pub/fedora/linux/releases/9/Everythi ng/x86_64/os ftp://ftp.uib.no/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.man.poznan.pl/pub/linux/fedora/releases/9/Everything/x86_64/os http://ftp.linux.org.uk/pub/distributions/fedora/linux/releases/9/Everything/x8 6_64/os http://fedora.inode.at/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.pbone.net/pub/fedora/linux/releases/9/Everything/x86_64/os http://fedora.fastbull.org/linux/releases/9/Everything/x86_64/os ftp://ftp.proxad.net/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everythi ng/x86_64/os http://ftp.gui.uva.es/sites/fedora.redhat.com/linux/releases/9/Everything/x86_6 4/os http://ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everythi ng/x86_64/os http://redhat.linux.ee/pub/fedora/linux/releases/9/Everything/x86_64/os http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/releases/9/Everything/x86_64/o s -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Matt_Domsch at dell.com Sat Aug 30 17:37:52 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 30 Aug 2008 12:37:52 -0500 Subject: New Key Repo Locations In-Reply-To: <20080830164631.GA3831@victor.nirvana> References: <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> Message-ID: <20080830173752.GB25725@auslistsprd01.us.dell.com> On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote: > On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: > > We're using MM to redirect ALL requests for the old repo location to > > mirrors that we have ultimate control over. > > I don't think that's true, see [1] for 64 mirrors that are suggested > for my location that are certainly not under Red Hat/Fedora control, > actually it looks like none is. that's the plan, it's not implemented yet. In fact, I'll probably just do it with plain HTTP redirects in an httpd.conf file rather than special-case it in MM. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From wtogami at redhat.com Sun Aug 31 03:48:45 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 30 Aug 2008 23:48:45 -0400 Subject: New Key Repo Locations In-Reply-To: <20080830173752.GB25725@auslistsprd01.us.dell.com> References: <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> <20080830173752.GB25725@auslistsprd01.us.dell.com> Message-ID: <48BA149D.3020901@redhat.com> Matt Domsch wrote: > On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote: >> On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: >>> We're using MM to redirect ALL requests for the old repo location to >>> mirrors that we have ultimate control over. >> I don't think that's true, see [1] for 64 mirrors that are suggested >> for my location that are certainly not under Red Hat/Fedora control, >> actually it looks like none is. > > that's the plan, it's not implemented yet. In fact, I'll probably > just do it with plain HTTP redirects in an httpd.conf file rather than > special-case it in MM. > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html Matt, you are misunderstanding the plan. No redirections are necessary at any level of this plan. Warren From wtogami at redhat.com Sun Aug 31 03:53:36 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 30 Aug 2008 23:53:36 -0400 Subject: New Key Repo Locations In-Reply-To: <20080830164631.GA3831@victor.nirvana> References: <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> Message-ID: <48BA15C0.2030503@redhat.com> Axel Thimm wrote: > > Either the key is considered compromized and one needs to do the full > program, or it is reasonably considered safe (by a brute-force safe > passphrase and really assuming the passphrase has not been lost to the > intruder as well), in which case no steps are needed, but phasing it > out before the computing power gets accessible to break it (e.g. new > keys for F10 upwards). > > The current program looks like a mix of assuming "safe" (so the old > key can be used for signing new packages, even if it just a few) and > assuming "compromised" needing a resiging of all content. It turns out that we're ahead of schedule in re-signing. Due to bodhi limitations we needed to resign all updates before pushing any new updates, and that is done now. I have to check with Jesse but I suspect resigning of Everything should be done early during this upcoming week. (It might even be close to done now, I dunno.) http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html The re-signing of Everything however is not blocking implementation of the first stages of the plan - which includes updates going out. Anyhow, updates should begin flowing soon, and shortly thereafter the old key is removed. Oh, did you actually test rpm -e during %post? According to skvidal it doesn't work because it locks the transaction. Jeremy thinks the only assured way we can remove the old key is with a hardcoded hack in rpm that will be removed in F10 rpm. Warren Togami wtogami at redhat.com From skvidal at fedoraproject.org Sun Aug 31 04:06:00 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 31 Aug 2008 00:06:00 -0400 Subject: New Key Repo Locations In-Reply-To: <48BA15C0.2030503@redhat.com> References: <48B739F3.9010506@kanarip.com> <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> <48BA15C0.2030503@redhat.com> Message-ID: <1220155560.15215.11.camel@rosebud> On Sat, 2008-08-30 at 23:53 -0400, Warren Togami wrote: > Axel Thimm wrote: > > > > Either the key is considered compromized and one needs to do the full > > program, or it is reasonably considered safe (by a brute-force safe > > passphrase and really assuming the passphrase has not been lost to the > > intruder as well), in which case no steps are needed, but phasing it > > out before the computing power gets accessible to break it (e.g. new > > keys for F10 upwards). > > > > The current program looks like a mix of assuming "safe" (so the old > > key can be used for signing new packages, even if it just a few) and > > assuming "compromised" needing a resiging of all content. > > It turns out that we're ahead of schedule in re-signing. Due to bodhi > limitations we needed to resign all updates before pushing any new > updates, and that is done now. I have to check with Jesse but I suspect > resigning of Everything should be done early during this upcoming week. > (It might even be close to done now, I dunno.) > > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html > The re-signing of Everything however is not blocking implementation of > the first stages of the plan - which includes updates going out. > > Anyhow, updates should begin flowing soon, and shortly thereafter the > old key is removed. Oh, did you actually test rpm -e during %post? > According to skvidal it doesn't work because it locks the transaction. > Jeremy thinks the only assured way we can remove the old key is with a > hardcoded hack in rpm that will be removed in F10 rpm. > I tested rpm -e during %post on two f9 systems, It locked the rpmdb hard. -sv From Axel.Thimm at ATrpms.net Sun Aug 31 07:29:19 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 31 Aug 2008 10:29:19 +0300 Subject: New Key Repo Locations In-Reply-To: <1220155560.15215.11.camel@rosebud> References: <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> <48BA15C0.2030503@redhat.com> <1220155560.15215.11.camel@rosebud> Message-ID: <20080831072919.GB25578@victor.nirvana> On Sun, Aug 31, 2008 at 12:06:00AM -0400, Seth Vidal wrote: > On Sat, 2008-08-30 at 23:53 -0400, Warren Togami wrote: > > Anyhow, updates should begin flowing soon, and shortly thereafter > > the old key is removed. Oh, did you actually test rpm -e during > > %post? According to skvidal it doesn't work because it locks the > > transaction. Jeremy thinks the only assured way we can remove the > > old key is with a hardcoded hack in rpm that will be removed in > > F10 rpm. > > I tested rpm -e during %post on two f9 systems, It locked the rpmdb > hard. Have you tried with gpg-pubkey entries? I had asked on rpm-devel back in these days when I was using the following snippet: %post if [ "$1" = 1 ]; then for key in \ gpg-pubkey-db42a60e-37ea5438,RPM-GPG-KEY.redhat \ gpg-pubkey-66534c2b-3e60b428,RPM-GPG-KEY.atrpms \ gpg-pubkey-e42d547b-3960bdf1,RPM-GPG-KEY.freshrpms \ gpg-pubkey-b8693f2c-3f48c249,RPM-GPG-KEY.newrpms \ gpg-pubkey-6b8d79e6-3f49313d,RPM-GPG-KEY.dag \ gpg-pubkey-bbf04688-4018dbeb,RPM-GPG-KEY.biorpms \ gpg-pubkey-68d9802a-406db022,RPM-GPG-KEY.ccrma \ gpg-pubkey-4f2a6fd2-3f9d9d3b,RPM-GPG-KEY.redhat-fedora \ ; do : rpm -e --allmatches `echo $key | awk -F, '{print $1}'` > /dev/null 2>&1 || : rpm --import /usr/share/atrpms/`echo $key | awk -F, '{print $2}'` done fi I'm not using this anymore, since I can't vouch for the trust to all third party repos, but the code was running fine back then w/o locking up rpmdb. Maybe an rpm regression? Or maybe it works for gpg-pubkeys only? Should we loop in Panu? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Aug 31 07:35:35 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 31 Aug 2008 10:35:35 +0300 Subject: New Key Repo Locations In-Reply-To: <48B70B1F.4010206@redhat.com> References: <48B70B1F.4010206@redhat.com> Message-ID: <20080831073535.GA13825@victor.nirvana> How about as an alternative to creating new SRPMS.newkey etc folders to overcome the proxy issues, to keep it canonical and instead release 9.1 and 8.1? The benefits, other than staying in line with the established layout practices are that one could merge in the updates (like the unity project does) and even offer an advantage to the user when installing from 9.1. Furthermore one could always check whether a system is "vulnerable" by checking its version. Or does this need export regulations due to changing the version number? Hopefully not. -- Axel.Thimm at ATrpms.net -------------- 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 Sun Aug 31 08:18:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 31 Aug 2008 01:18:25 -0700 Subject: New Key Repo Locations In-Reply-To: <48BA149D.3020901@redhat.com> References: <1219967962.6655.44.camel@luminos.localdomain> <48B74388.90801@kanarip.com> <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> <20080830173752.GB25725@auslistsprd01.us.dell.com> <48BA149D.3020901@redhat.com> Message-ID: <48BA53D1.7070103@gmail.com> Warren Togami wrote: > Matt Domsch wrote: >> On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote: >>> On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: >>>> We're using MM to redirect ALL requests for the old repo location to >>>> mirrors that we have ultimate control over. >>> I don't think that's true, see [1] for 64 mirrors that are suggested >>> for my location that are certainly not under Red Hat/Fedora control, >>> actually it looks like none is. >> >> that's the plan, it's not implemented yet. In fact, I'll probably >> just do it with plain HTTP redirects in an httpd.conf file rather than >> special-case it in MM. >> > > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html > Matt, you are misunderstanding the plan. No redirections are necessary > at any level of this plan. > Warren, I think we need to add redirection as step 6.1. If we don't lock out mirrors that we don't control at that stage, there's nothing to prevent the following scenario:: Person with the key has brute forced passphrase and compromises mirror. uploads packages signed with old key to the F-9 repo on the old mirror. Among other things these packages subvert yum so that it will only update from compromised mirrors and removes the new key from the NEWREPO. User downloads F-9 ISO. Installs F-9 with old key as valid. User hits the compromised mirror on first yum update and installs compromised packages. -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 Axel.Thimm at ATrpms.net Sun Aug 31 08:37:06 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 31 Aug 2008 11:37:06 +0300 Subject: New Key Repo Locations In-Reply-To: <48BA53D1.7070103@gmail.com> References: <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> <20080830173752.GB25725@auslistsprd01.us.dell.com> <48BA149D.3020901@redhat.com> <48BA53D1.7070103@gmail.com> Message-ID: <20080831083706.GC14535@victor.nirvana> On Sun, Aug 31, 2008 at 01:18:25AM -0700, Toshio Kuratomi wrote: > Warren Togami wrote: > > Matt Domsch wrote: > >> On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote: > >>> On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote: > >>>> We're using MM to redirect ALL requests for the old repo location to > >>>> mirrors that we have ultimate control over. > >>> I don't think that's true, see [1] for 64 mirrors that are suggested > >>> for my location that are certainly not under Red Hat/Fedora control, > >>> actually it looks like none is. > >> > >> that's the plan, it's not implemented yet. In fact, I'll probably > >> just do it with plain HTTP redirects in an httpd.conf file rather than > >> special-case it in MM. > >> > > > > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html > > Matt, you are misunderstanding the plan. No redirections are necessary > > at any level of this plan. > > > Warren, I think we need to add redirection as step 6.1. > > If we don't lock out mirrors that we don't control at that stage, > there's nothing to prevent the following scenario:: > > Person with the key has brute forced passphrase and compromises mirror. > uploads packages signed with old key to the F-9 repo on the old mirror. > Among other things these packages subvert yum so that it will only > update from compromised mirrors and removes the new key from the > NEWREPO. User downloads F-9 ISO. Installs F-9 with old key as valid. > User hits the compromised mirror on first yum update and installs > compromised packages. I more and more like the idea of killing F8 and F9 and going F8.1 and F9.1. The person with the F9 DVD might even manually download a bad signed package and think it is Fedora signed. He might even turn on malicious or compromized 3rd party repos that carry malicious packages signed with the old key and not notice how willing his DVD install will swallow these packages in. Once again, either the intruder is considered unable to sign packages due to a very good passphrase (and then we don't even need to start this stepdance), or if signed malware is realistic then the old key and all assorted bits need to be considered dead including old F9 DVDs. Much more than RHEL Fedora is an open system with many software flow channels from volunteer mirrors to 3rd party repos, driver ISVs, sf.net rpms, etc. as well as manual installs. So even if the Fedora mirrors issue is dealt with there are still lots of open spots. I propose to a) resping F8/F9 with updates (all signed with the new key) to create 8.1, 9.1. Fedora unity recenty did some respins, so maybe it is just cut and paste. b) empty F8/F9 updates and just place a package in there that will automatically upgrade any F8/F9 system to F8.1/F9.1. Redirect all mirrormanager controlled URLs to a controlled entity that only serves this package for F8/F9. Being a single package this will be a much lighter load than turning off all mirrors. The mirrors will still be used for 8.1/9.1. c) make sure users get alerted about this, maybe by some applet. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From skvidal at fedoraproject.org Sun Aug 31 14:32:32 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 31 Aug 2008 10:32:32 -0400 Subject: New Key Repo Locations In-Reply-To: <20080831072919.GB25578@victor.nirvana> References: <48B777DB.9010108@redhat.com> <20080829081405.GE22094@victor.nirvana> <48B7D570.2050806@kanarip.com> <20080829133219.GA3009@victor.nirvana> <48B7FCC7.1090208@kanarip.com> <20080829135705.GC3009@victor.nirvana> <20080830164631.GA3831@victor.nirvana> <48BA15C0.2030503@redhat.com> <1220155560.15215.11.camel@rosebud> <20080831072919.GB25578@victor.nirvana> Message-ID: <1220193152.15215.17.camel@rosebud> On Sun, 2008-08-31 at 10:29 +0300, Axel Thimm wrote: > On Sun, Aug 31, 2008 at 12:06:00AM -0400, Seth Vidal wrote: > > On Sat, 2008-08-30 at 23:53 -0400, Warren Togami wrote: > > > Anyhow, updates should begin flowing soon, and shortly thereafter > > > the old key is removed. Oh, did you actually test rpm -e during > > > %post? According to skvidal it doesn't work because it locks the > > > transaction. Jeremy thinks the only assured way we can remove the > > > old key is with a hardcoded hack in rpm that will be removed in > > > F10 rpm. > > > > I tested rpm -e during %post on two f9 systems, It locked the rpmdb > > hard. > > Have you tried with gpg-pubkey entries? I had asked on rpm-devel back > in these days when I was using the following snippet: > > %post > if [ "$1" = 1 ]; then > for key in \ > gpg-pubkey-db42a60e-37ea5438,RPM-GPG-KEY.redhat \ > gpg-pubkey-66534c2b-3e60b428,RPM-GPG-KEY.atrpms \ > gpg-pubkey-e42d547b-3960bdf1,RPM-GPG-KEY.freshrpms \ > gpg-pubkey-b8693f2c-3f48c249,RPM-GPG-KEY.newrpms \ > gpg-pubkey-6b8d79e6-3f49313d,RPM-GPG-KEY.dag \ > gpg-pubkey-bbf04688-4018dbeb,RPM-GPG-KEY.biorpms \ > gpg-pubkey-68d9802a-406db022,RPM-GPG-KEY.ccrma \ > gpg-pubkey-4f2a6fd2-3f9d9d3b,RPM-GPG-KEY.redhat-fedora \ > ; do > : > rpm -e --allmatches `echo $key | awk -F, '{print $1}'` > /dev/null 2>&1 || : > rpm --import /usr/share/atrpms/`echo $key | awk -F, '{print $2}'` > done > fi > > I'm not using this anymore, since I can't vouch for the trust to all > third party repos, but the code was running fine back then w/o locking > up rpmdb. Maybe an rpm regression? Or maybe it works for gpg-pubkeys > only? Should we loop in Panu? yes, I tried gpg-pubkey specifically, both with and without the full extension. -sv From jkeating at redhat.com Sun Aug 31 15:24:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 31 Aug 2008 08:24:19 -0700 Subject: New Key Repo Locations In-Reply-To: <20080831073535.GA13825@victor.nirvana> References: <48B70B1F.4010206@redhat.com> <20080831073535.GA13825@victor.nirvana> Message-ID: <1220196259.29094.9.camel@luminos.localdomain> On Sun, 2008-08-31 at 10:35 +0300, Axel Thimm wrote: > The benefits, other than staying in line with the established layout > practices are that one could merge in the updates (like the unity > project does) and even offer an advantage to the user when installing > from 9.1. Furthermore one could always check whether a system is > "vulnerable" by checking its version. > > Or does this need export regulations due to changing the version > number? Hopefully not. It would need new export controls, which is the least of the problems. We are going to have a hard enough time doing a full release for Fedora 10, trying to squeeze in a 9.1 and an 8.1 release is just going to make 10 that much worse. Add to that it won't help at all the already burned or mastered copies of the original isos in existence. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 martin.langhoff at gmail.com Wed Aug 6 10:17:02 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 06 Aug 2008 10:17:02 -0000 Subject: fedorahosted git repo too large In-Reply-To: <1218011851.31379.26.camel@localhost.localdomain> References: <76e72f800808052030y632d8756r4e4b37199ec498c0@mail.gmail.com> <20080806034418.GR5655@inocybe.teonanacatl.org> <1218011851.31379.26.camel@localhost.localdomain> Message-ID: <46a038f90808060316q82cfe2cocf70175cb9e2ac0d@mail.gmail.com> On Wed, Aug 6, 2008 at 8:37 PM, Nigel Jones wrote: >> http://article.gmane.org/gmane.comp.gcc.devel/94613 > That's actually a very useful article and the methods/reasons behind it > sound quite sane and it could be a useful approach for us. Agreed. git gc on all repos on an infrequent cronjob is a good idea. But --aggressive is a very bad idea as it throws away delta-chain work that's been done. Specially bad on larger repos as the potential delta pairs to evaluate is much much larger. cheers, martin (also a git dev) -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff