From mmcgrath at redhat.com Wed Jul 1 21:33:49 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 1 Jul 2009 16:33:49 -0500 (CDT) Subject: memcached opinions Message-ID: I'm not sure if we have any memcached experience on the list but I thought I'd ask. Can anyone explain this: http://pastebin.ca/1481219 Notice how memcached1 has a much higher hit rate and memcached2 has a much lower hit rate? -Mike From smooge at gmail.com Wed Jul 1 23:13:06 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 1 Jul 2009 17:13:06 -0600 Subject: memcached opinions In-Reply-To: References: Message-ID: <80d7e4090907011613r6670507fh6f8a4cb3a7ebb3fd@mail.gmail.com> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath wrote: > I'm not sure if we have any memcached experience on the list but I thought > I'd ask. ?Can anyone explain this: > > http://pastebin.ca/1481219 > > Notice how memcached1 has a much higher hit rate and memcached2 has a much > lower hit rate? > The time for memcached1 is 5x less than memcached2 being up. That can have an effect on caching as right after a system comes up its rates are usually much higher and then over time fall off (iirc). I think it would take bringing both up at the same time to figure out if there is a true disparity over caching. > ? ? ? ?-Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Thu Jul 2 00:08:25 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 1 Jul 2009 19:08:25 -0500 (CDT) Subject: memcached opinions In-Reply-To: <80d7e4090907011613r6670507fh6f8a4cb3a7ebb3fd@mail.gmail.com> References: <80d7e4090907011613r6670507fh6f8a4cb3a7ebb3fd@mail.gmail.com> Message-ID: On Wed, 1 Jul 2009, Stephen John Smoogen wrote: > On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath wrote: > > I'm not sure if we have any memcached experience on the list but I thought > > I'd ask. ?Can anyone explain this: > > > > http://pastebin.ca/1481219 > > > > Notice how memcached1 has a much higher hit rate and memcached2 has a much > > lower hit rate? > > > > The time for memcached1 is 5x less than memcached2 being up. That can > have an effect on caching as right after a system comes up its rates > are usually much higher and then over time fall off (iirc). I think it > would take bringing both up at the same time to figure out if there is > a true disparity over caching. > I thought that exact same thing :) memcahed1: STAT uptime 9143 STAT get_hits 311736 STAT get_misses 11255 memcached2: STAT uptime 9144 STAT get_hits 49679 STAT get_misses 11116 -Mike From smooge at gmail.com Thu Jul 2 00:29:37 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 1 Jul 2009 18:29:37 -0600 Subject: memcached opinions In-Reply-To: References: <80d7e4090907011613r6670507fh6f8a4cb3a7ebb3fd@mail.gmail.com> Message-ID: <80d7e4090907011729t3e0ae36apc8040de1718fba86@mail.gmail.com> On Wed, Jul 1, 2009 at 6:08 PM, Mike McGrath wrote: > On Wed, 1 Jul 2009, Stephen John Smoogen wrote: > >> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath wrote: >> > I'm not sure if we have any memcached experience on the list but I thought >> > I'd ask. ?Can anyone explain this: >> > >> > http://pastebin.ca/1481219 >> > >> > Notice how memcached1 has a much higher hit rate and memcached2 has a much >> > lower hit rate? >> > >> >> The time for memcached1 is 5x less than memcached2 being up. That can >> have an effect on caching as right after a system comes up its rates >> are usually much higher and then over time fall off (iirc). I think it >> would take bringing both up at the same time to figure out if there is >> a true disparity over caching. >> > > I thought that exact same thing :) > > memcahed1: > STAT uptime 9143 > STAT get_hits 311736 > STAT get_misses 11255 > > memcached2: > STAT uptime 9144 > STAT get_hits 49679 > STAT get_misses 11116 > Now that shows something not kosher. My guess is some app is not talking to both? What apps use memcached for what? -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Thu Jul 2 00:39:44 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 1 Jul 2009 19:39:44 -0500 (CDT) Subject: memcached opinions In-Reply-To: <80d7e4090907011729t3e0ae36apc8040de1718fba86@mail.gmail.com> References: <80d7e4090907011613r6670507fh6f8a4cb3a7ebb3fd@mail.gmail.com> <80d7e4090907011729t3e0ae36apc8040de1718fba86@mail.gmail.com> Message-ID: On Wed, 1 Jul 2009, Stephen John Smoogen wrote: > On Wed, Jul 1, 2009 at 6:08 PM, Mike McGrath wrote: > > On Wed, 1 Jul 2009, Stephen John Smoogen wrote: > > > >> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath wrote: > >> > I'm not sure if we have any memcached experience on the list but I thought > >> > I'd ask. ?Can anyone explain this: > >> > > >> > http://pastebin.ca/1481219 > >> > > >> > Notice how memcached1 has a much higher hit rate and memcached2 has a much > >> > lower hit rate? > >> > > >> > >> The time for memcached1 is 5x less than memcached2 being up. That can > >> have an effect on caching as right after a system comes up its rates > >> are usually much higher and then over time fall off (iirc). I think it > >> would take bringing both up at the same time to figure out if there is > >> a true disparity over caching. > >> > > > > I thought that exact same thing :) > > > > memcahed1: > > STAT uptime 9143 > > STAT get_hits 311736 > > STAT get_misses 11255 > > > > memcached2: > > STAT uptime 9144 > > STAT get_hits 49679 > > STAT get_misses 11116 > > > > Now that shows something not kosher. My guess is some app is not > talking to both? What apps use memcached for what? > I was just talking to ricky about this a bit in IRC. So here's the scoop. We've got mediawiki using memcached for a couple of things, including session data (which is weird and wrong but fast). The recent addition to the group is Fedora community, specifically in it's implementation of beaker. I'm going to get ahold of luke tomorrow to verify and test some stuff but I think this line in the config: beaker.cache.url = memcached1;memcached I'm not sure how beaker reads that, but I suspect it might be only sending information to memcached1 and ignoring memcached2 altogether. If this theory holds it'd explain why memcached1 not only has a higher request rate but also a higher hit rate because I suspect fedoracommunity requests some of the same info over and over again compared to the wiki which probably has a broader data pool it pulls from. -Mike From a.badger at gmail.com Thu Jul 2 00:50:12 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 01 Jul 2009 17:50:12 -0700 Subject: memcached opinions In-Reply-To: References: <80d7e4090907011613r6670507fh6f8a4cb3a7ebb3fd@mail.gmail.com> <80d7e4090907011729t3e0ae36apc8040de1718fba86@mail.gmail.com> Message-ID: <4A4C0444.2060207@gmail.com> On 07/01/2009 05:39 PM, Mike McGrath wrote: > On Wed, 1 Jul 2009, Stephen John Smoogen wrote: > >> On Wed, Jul 1, 2009 at 6:08 PM, Mike McGrath wrote: >>> On Wed, 1 Jul 2009, Stephen John Smoogen wrote: >>> >>>> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath wrote: >>>>> I'm not sure if we have any memcached experience on the list but I thought >>>>> I'd ask. Can anyone explain this: >>>>> >>>>> http://pastebin.ca/1481219 >>>>> >>>>> Notice how memcached1 has a much higher hit rate and memcached2 has a much >>>>> lower hit rate? >>>>> >>>> >>>> The time for memcached1 is 5x less than memcached2 being up. That can >>>> have an effect on caching as right after a system comes up its rates >>>> are usually much higher and then over time fall off (iirc). I think it >>>> would take bringing both up at the same time to figure out if there is >>>> a true disparity over caching. >>>> >>> >>> I thought that exact same thing :) >>> >>> memcahed1: >>> STAT uptime 9143 >>> STAT get_hits 311736 >>> STAT get_misses 11255 >>> >>> memcached2: >>> STAT uptime 9144 >>> STAT get_hits 49679 >>> STAT get_misses 11116 >>> >> >> Now that shows something not kosher. My guess is some app is not >> talking to both? What apps use memcached for what? >> > > I was just talking to ricky about this a bit in IRC. So here's the scoop. > > We've got mediawiki using memcached for a couple of things, including > session data (which is weird and wrong but fast). > > The recent addition to the group is Fedora community, specifically in it's > implementation of beaker. I'm going to get ahold of luke tomorrow to > verify and test some stuff but I think this line in the config: > > beaker.cache.url = memcached1;memcached > > I'm not sure how beaker reads that, but I suspect it might be only sending > information to memcached1 and ignoring memcached2 altogether. If this > theory holds it'd explain why memcached1 not only has a higher request > rate but also a higher hit rate because I suspect fedoracommunity requests > some of the same info over and over again compared to the wiki which > probably has a broader data pool it pulls from. > easy test: reverse that: beaker.cache.url = memcached2;memcached1 and see if the cache hit ratio reverses itself. -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 smooge at gmail.com Thu Jul 2 01:12:46 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 1 Jul 2009 19:12:46 -0600 Subject: Need some looking at iptables change. Message-ID: <80d7e4090907011812v632d41f9yd9d24d974ee5934b@mail.gmail.com> --- configs/system/iptables-template.conf.erb | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configs/system/iptables-template.conf.erb b/configs/system/iptables-template.conf.erb index c83c482..90a6115 100644 --- a/configs/system/iptables-template.conf.erb +++ b/configs/system/iptables-template.conf.erb @@ -24,6 +24,7 @@ # Temporary measure for ro access to nfs1 -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.113 --dport 48621:48624 -j ACCEPT +-A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.113 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 111 -j ACCEPT @@ -31,6 +32,7 @@ -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.114 --dport 48621:48624 -j ACCEPT +-A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.114 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 111 -j ACCEPT @@ -38,6 +40,7 @@ -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.83 --dport 48621:48624 -j ACCEPT +-A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.83 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 111 -j ACCEPT @@ -45,6 +48,7 @@ -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.196 --dport 48621:48624 -j ACCEPT +-A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.196 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 111 -j ACCEPT -- 1.5.5.6 -- 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 Thu Jul 2 02:10:17 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 1 Jul 2009 20:10:17 -0600 Subject: Need some looking at iptables change. In-Reply-To: <80d7e4090907011812v632d41f9yd9d24d974ee5934b@mail.gmail.com> References: <80d7e4090907011812v632d41f9yd9d24d974ee5934b@mail.gmail.com> Message-ID: <80d7e4090907011910p7ca260f3w6a5eda683219c8c1@mail.gmail.com> Make the patch smaller. --- configs/system/iptables-template.conf.erb | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/configs/system/iptables-template.conf.erb b/configs/system/iptables-template.conf.erb index 90a6115..9ccbec0 100644 --- a/configs/system/iptables-template.conf.erb +++ b/configs/system/iptables-template.conf.erb @@ -24,7 +24,6 @@ # Temporary measure for ro access to nfs1 -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.113 --dport 48621:48624 -j ACCEPT --A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.113 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 111 -j ACCEPT @@ -32,7 +31,6 @@ -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.114 --dport 48621:48624 -j ACCEPT --A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.114 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 111 -j ACCEPT @@ -40,7 +38,6 @@ -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.83 --dport 48621:48624 -j ACCEPT --A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.83 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 111 -j ACCEPT @@ -48,7 +45,6 @@ -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 48621:48624 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.196 --dport 48621:48624 -j ACCEPT --A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 2049 -j ACCEPT -A INPUT -p udp -m udp -s 10.8.34.196 --dport 2049 -j ACCEPT -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 111 -j ACCEPT @@ -61,6 +57,7 @@ -A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 8140 -j ACCEPT -A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 873 -j ACCEPT -A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 80 -j ACCEPT +-A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 51234:51235 -j ACCEPT -A INPUT -p tcp -m tcp -d 10.8.34.50 --dport 25 -j ACCEPT -A INPUT -s 10.8.34.113 -j REJECT --reject-with icmp-host-prohibited -A INPUT -s 10.8.34.114 -j REJECT --reject-with icmp-host-prohibited -- 1.5.5.6 -- 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 ricky at fedoraproject.org Thu Jul 2 02:22:42 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 1 Jul 2009 22:22:42 -0400 Subject: Need some looking at iptables change. In-Reply-To: <80d7e4090907011910p7ca260f3w6a5eda683219c8c1@mail.gmail.com> References: <80d7e4090907011812v632d41f9yd9d24d974ee5934b@mail.gmail.com> <80d7e4090907011910p7ca260f3w6a5eda683219c8c1@mail.gmail.com> Message-ID: <20090702022242.GC12013@alpha.rzhou.org> On 2009-07-01 08:10:17 PM, Stephen John Smoogen wrote: > Make the patch smaller. > --- > configs/system/iptables-template.conf.erb | 5 +---- > 1 files changed, 1 insertions(+), 4 deletions(-) > > diff --git a/configs/system/iptables-template.conf.erb > b/configs/system/iptables-template.conf.erb > index 90a6115..9ccbec0 100644 > --- a/configs/system/iptables-template.conf.erb > +++ b/configs/system/iptables-template.conf.erb > @@ -24,7 +24,6 @@ > # Temporary measure for ro access to nfs1 > -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 48621:48624 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.113 --dport 48621:48624 -j ACCEPT > --A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 51234:51235 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 2049 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.113 --dport 2049 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.113 --dport 111 -j ACCEPT > @@ -32,7 +31,6 @@ > > -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 48621:48624 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.114 --dport 48621:48624 -j ACCEPT > --A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 51234:51235 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 2049 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.114 --dport 2049 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.114 --dport 111 -j ACCEPT > @@ -40,7 +38,6 @@ > > -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 48621:48624 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.83 --dport 48621:48624 -j ACCEPT > --A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 51234:51235 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 2049 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.83 --dport 2049 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.83 --dport 111 -j ACCEPT > @@ -48,7 +45,6 @@ > > -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 48621:48624 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.196 --dport 48621:48624 -j ACCEPT > --A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 51234:51235 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 2049 -j ACCEPT > -A INPUT -p udp -m udp -s 10.8.34.196 --dport 2049 -j ACCEPT > -A INPUT -p tcp -m tcp -s 10.8.34.196 --dport 111 -j ACCEPT > @@ -61,6 +57,7 @@ > -A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 8140 -j ACCEPT > -A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 873 -j ACCEPT > -A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 80 -j ACCEPT > +-A INPUT -p tcp -m tcp -d 10.8.34.125 --dport 51234:51235 -j ACCEPT > -A INPUT -p tcp -m tcp -d 10.8.34.50 --dport 25 -j ACCEPT > -A INPUT -s 10.8.34.113 -j REJECT --reject-with icmp-host-prohibited > -A INPUT -s 10.8.34.114 -j REJECT --reject-with icmp-host-prohibited > -- > 1.5.5.6 Looks good to me. 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 a.badger at gmail.com Thu Jul 2 03:23:09 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 01 Jul 2009 20:23:09 -0700 Subject: Licensing Guidelines for apps we write Message-ID: <4A4C281D.1070109@gmail.com> Hi, I've had a chance to talk to spot and I've drafted the following policy about licensing the things that we write in Fedora Infrastructure: https://fedoraproject.org/wiki/Infrastructure_Licensing Do people like it? Is a GPL family license pretty much everywhere good for everyone or are there places that we'd like the general rule to be "MIT" or something looser instead? I want to relicense python-fedora (GPLv2 => LGPLv2+), pkgdb and fas (GPLv2 => AGPLv3+) if we approve this. I'll talk to the contributors to those projects to make sure they have no objections first, but is that generally acceptable? Anyone else want to join in on the relicensing? Having things under compatible licenses will make code sharing possible. (GPLv2 only is not compatible with AGPLv3+) which is my incentive for migrating apps that I'm contributing to onto a common licensing scheme. I'm putting this on the meeting agenda for Thursday but discussion in the mailing list is also welcome. -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 bashton at brennanashton.com Thu Jul 2 03:49:12 2009 From: bashton at brennanashton.com (Brennan Ashton) Date: Wed, 1 Jul 2009 20:49:12 -0700 Subject: Licensing Guidelines for apps we write In-Reply-To: <4A4C281D.1070109@gmail.com> References: <4A4C281D.1070109@gmail.com> Message-ID: <981da310907012049p380ec1a6sc445fa441b74f741@mail.gmail.com> On Wed, Jul 1, 2009 at 8:23 PM, Toshio Kuratomi wrote: > Hi, I've had a chance to talk to spot and I've drafted the following > policy about licensing the things that we write in Fedora Infrastructure: > > ?https://fedoraproject.org/wiki/Infrastructure_Licensing > > Do people like it? ?Is a GPL family license pretty much everywhere good > for everyone or are there places that we'd like the general rule to be > "MIT" or something looser instead? > > I want to relicense python-fedora (GPLv2 => LGPLv2+), pkgdb and fas > (GPLv2 => AGPLv3+) if we approve this. ?I'll talk to the contributors to > those projects to make sure they have no objections first, but is that > generally acceptable? ?Anyone else want to join in on the relicensing? > Having things under compatible licenses will make code sharing possible. > (GPLv2 only is not compatible with AGPLv3+) which is my incentive for > migrating apps that I'm contributing to onto a common licensing scheme. > > I'm putting this on the meeting agenda for Thursday but discussion in > the mailing list is also welcome. > > -Toshio Triageweb, the metrics application that is still in development right now that I am writing is GPLv2 if I remember correctly, but I have no preference on the matter, and will go with what is ever easiest for everyone else. Just let me know. Best Regards, Brennan Ashton From thinklinux.ssh at gmail.com Thu Jul 2 04:21:50 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Thu, 2 Jul 2009 09:51:50 +0530 Subject: May I have a sample output of this script? Message-ID: Hi, I just wanted to see how the maps look like. Is this being run for generating maps available somewhere under fp.o? https://fedorahosted.org/fedora-infrastructure/browser/scripts/geoip/generate-worldmap.py Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From nigjones at redhat.com Thu Jul 2 04:37:36 2009 From: nigjones at redhat.com (Nigel Jones) Date: Thu, 2 Jul 2009 00:37:36 -0400 (EDT) Subject: Licensing Guidelines for apps we write In-Reply-To: <4A4C281D.1070109@gmail.com> Message-ID: <13854533.611246509471940.JavaMail.nigjones@njones.bne.redhat.com> ----- "Toshio Kuratomi" wrote: > Hi, I've had a chance to talk to spot and I've drafted the following > policy about licensing the things that we write in Fedora > Infrastructure: > > https://fedoraproject.org/wiki/Infrastructure_Licensing > > Do people like it? Is a GPL family license pretty much everywhere > good > for everyone or are there places that we'd like the general rule to > be > "MIT" or something looser instead? > > I want to relicense python-fedora (GPLv2 => LGPLv2+), pkgdb and fas > (GPLv2 => AGPLv3+) if we approve this. I'll talk to the contributors > to > those projects to make sure they have no objections first, but is > that > generally acceptable? Anyone else want to join in on the > relicensing? > Having things under compatible licenses will make code sharing > possible. > (GPLv2 only is not compatible with AGPLv3+) which is my incentive for > migrating apps that I'm contributing to onto a common licensing > scheme. > > I'm putting this on the meeting agenda for Thursday but discussion in > the mailing list is also welcome. I definitely won't be at the meeting tomorrow, but yes, this is something that must be done, +1 from me. I guess to fit in, we should do the some for the voting app. - Nigel From a.badger at gmail.com Thu Jul 2 04:49:09 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 01 Jul 2009 21:49:09 -0700 Subject: Licensing Guidelines for apps we write In-Reply-To: <13854533.611246509471940.JavaMail.nigjones@njones.bne.redhat.com> References: <13854533.611246509471940.JavaMail.nigjones@njones.bne.redhat.com> Message-ID: <4A4C3C45.90302@gmail.com> On 07/01/2009 09:37 PM, Nigel Jones wrote: > > ----- "Toshio Kuratomi" wrote: > >> Hi, I've had a chance to talk to spot and I've drafted the following >> policy about licensing the things that we write in Fedora >> Infrastructure: >> >> https://fedoraproject.org/wiki/Infrastructure_Licensing >> >> Do people like it? Is a GPL family license pretty much everywhere >> good >> for everyone or are there places that we'd like the general rule to >> be >> "MIT" or something looser instead? >> >> I want to relicense python-fedora (GPLv2 => LGPLv2+), pkgdb and fas >> (GPLv2 => AGPLv3+) if we approve this. I'll talk to the contributors >> to >> those projects to make sure they have no objections first, but is >> that >> generally acceptable? Anyone else want to join in on the >> relicensing? >> Having things under compatible licenses will make code sharing >> possible. >> (GPLv2 only is not compatible with AGPLv3+) which is my incentive for >> migrating apps that I'm contributing to onto a common licensing >> scheme. >> >> I'm putting this on the meeting agenda for Thursday but discussion in >> the mailing list is also welcome. > > I definitely won't be at the meeting tomorrow, but yes, this is something that must be done, +1 from me. > > I guess to fit in, we should do the some for the voting app. > That would be ideal. Relicensing all of our GPLv2-only apps to reflect these Guidelines would be good. Mirrormanager is MIT licensed and that doesn't need to be relicensed to fit in as MIT is compatible with all of the GPL family of licenses. -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 bugs.michael at gmx.net Thu Jul 2 12:07:56 2009 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 2 Jul 2009 14:07:56 +0200 Subject: pkgdb -> bugzilla sync broken? Message-ID: <20090702140756.62ff9886@noname.noname> How often is bugzilla.redhat.com updated with changes in Fedora pkgdb? It has yet to sync the audacious* ownership changes from June 29th. Perhaps it's broken? https://bugzilla.redhat.com/describecomponents.cgi?product=Fedora From jonstanley at gmail.com Thu Jul 2 13:57:46 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 2 Jul 2009 09:57:46 -0400 Subject: pkgdb -> bugzilla sync broken? In-Reply-To: <20090702140756.62ff9886@noname.noname> References: <20090702140756.62ff9886@noname.noname> Message-ID: On Thu, Jul 2, 2009 at 8:07 AM, Michael Schwendt wrote: > How often is bugzilla.redhat.com updated with changes in Fedora pkgdb? > It has yet to sync the audacious* ownership changes from June 29th. > Perhaps it's broken? It is. Toshio has a change that should be live in the next hour or so that fixes it. python-bugzilla changed between 0.3.x and 0.5 causing it to break. To directly answer the question, it happens once an hour :) From rahul at redhat.com Thu Jul 2 14:03:21 2009 From: rahul at redhat.com (Rahul Sundaram) Date: Thu, 02 Jul 2009 19:33:21 +0530 Subject: Licensing Guidelines for apps we write In-Reply-To: <4A4C281D.1070109@gmail.com> References: <4A4C281D.1070109@gmail.com> Message-ID: <4A4CBE29.2070007@redhat.com> On 07/02/2009 08:53 AM, Toshio Kuratomi wrote: > Hi, I've had a chance to talk to spot and I've drafted the following > policy about licensing the things that we write in Fedora Infrastructure: > > https://fedoraproject.org/wiki/Infrastructure_Licensing > > Do people like it? Is a GPL family license pretty much everywhere good > for everyone or are there places that we'd like the general rule to be > "MIT" or something looser instead? Has Red Hat Legal been consulted on this? Rahul From a.badger at gmail.com Thu Jul 2 14:39:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Jul 2009 07:39:37 -0700 Subject: Licensing Guidelines for apps we write In-Reply-To: <4A4CBE29.2070007@redhat.com> References: <4A4C281D.1070109@gmail.com> <4A4CBE29.2070007@redhat.com> Message-ID: <4A4CC6A9.9060803@gmail.com> On 07/02/2009 07:03 AM, Rahul Sundaram wrote: > On 07/02/2009 08:53 AM, Toshio Kuratomi wrote: >> Hi, I've had a chance to talk to spot and I've drafted the following >> policy about licensing the things that we write in Fedora Infrastructure: >> >> https://fedoraproject.org/wiki/Infrastructure_Licensing >> >> Do people like it? Is a GPL family license pretty much everywhere good >> for everyone or are there places that we'd like the general rule to be >> "MIT" or something looser instead? > > Has Red Hat Legal been consulted on this? > I've consulted spot. Spot based his input on the policy on feedback he received while relicensing Fedora Community to AGPLv3+. -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 Jul 2 15:10:35 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 2 Jul 2009 10:10:35 -0500 (CDT) Subject: Licensing Guidelines for apps we write In-Reply-To: <4A4CBE29.2070007@redhat.com> References: <4A4C281D.1070109@gmail.com> <4A4CBE29.2070007@redhat.com> Message-ID: On Thu, 2 Jul 2009, Rahul Sundaram wrote: > On 07/02/2009 08:53 AM, Toshio Kuratomi wrote: > > Hi, I've had a chance to talk to spot and I've drafted the following > > policy about licensing the things that we write in Fedora Infrastructure: > > > > https://fedoraproject.org/wiki/Infrastructure_Licensing > > > > Do people like it? Is a GPL family license pretty much everywhere good > > for everyone or are there places that we'd like the general rule to be > > "MIT" or something looser instead? > > Has Red Hat Legal been consulted on this? > I think since spot was involved thats a yes. -Mike From thinklinux.ssh at gmail.com Thu Jul 2 17:34:50 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Thu, 2 Jul 2009 23:04:50 +0530 Subject: Suggestions required for generating Ambassadors map. Message-ID: Hi, Taking forward the previous work of automating the ambassadors list, I just committed a new scrip[1] into fama trac. This will extract the location data from the fas and generate a text (or whatever) file, which can be used to generate ambassadors map. A proof of concept map using google map (I know its not free and can not be used for our purpose) is here. [2] Warning: This may take a bit time to render. The problem being, which mapping software should we use? 1. Google map - non free. 2. Shomyu - Bochecha (the creator) does not seem to like the idea of using this for the particular purpose. 3. OSM - Does not have a nice api for creating a standalone map. I am out of my ideas about the mapping app, please suggest. Thanks. [1] https://fedorahosted.org/fama/browser/membership-map.py [2] http://susmit.fedorapeople.org/ambassadors/ambasadors_map_concept/ambassadors_map.html -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From ricky at fedoraproject.org Thu Jul 2 20:50:51 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 2 Jul 2009 16:50:51 -0400 Subject: Meeting Log - 2009-07-02 Message-ID: <20090702205051.GD12013@alpha.rzhou.org> 20:00 < mmcgrath> #startmeeting 20:00 < fedbot> Meeting started Thu Jul 2 20:00:29 2009 UTC. The chair is mmcgrath. 20:00 < fedbot> Information about MeetBot at http://wiki.debian.org/MeetBot , Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 < dgilmore> gday mmcgrath 20:00 * ricky 20:00 < mmcgrath> #topic Infrastructure -- Who's here? 20:00 -!- fedbot changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 * johe|home takes a seat 20:00 < mmcgrath> dgilmore: how's it going? 20:00 * SmootherFrOgZ is 20:01 * sijis sijis is here. 20:01 * ke4qqq is 20:01 < dgilmore> mmcgrath: 2 builders to go 20:01 < SmootherFrOgZ> dgilmore: for stg ? 20:01 < smooge> hello 20:01 < mmcgrath> dgilmore: excellent, happy to hear it. 20:01 < mmcgrath> Well lets get started 20:01 -!- StabbyMc [n=StabbyMc at rrcs-71-41-150-146.sw.biz.rr.com] has left #fedora-meeting ["Stab ya later!"] 20:01 < mmcgrath> #topic Infrastructure -- Tickets 20:01 -!- fedbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:01 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 < mmcgrath> .ticket 1503 20:02 < mmcgrath> abadger1999: take it 20:02 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:02 < dgilmore> SmootherFrOgZ: nope 20:02 < abadger1999> So we've had a new license pop up in apps we've written recently 20:02 < abadger1999> AGPLv3+ 20:02 < abadger1999> That's incompatible with GPLv2 which is what the majority of our apps use presently. 20:03 < abadger1999> After looking over the situation with spot, it seems like it would be good to move everything to AGPLv3+. 20:03 < dgilmore> im ok with the move 20:03 < abadger1999> (With libraries going to LGPLv2+) 20:03 < smooge> abadger1999, when you say we use.. do you mean we right or other stuff 20:03 < abadger1999> We write. 20:03 < smooge> s/right/write/ 20:03 < smooge> thanks 20:04 < abadger1999> smooge: This would not affect code that we don't write. 20:04 < abadger1999> And it's a recommendation rather than a hard and fast rule. 20:04 < mmcgrath> abadger1999: have you run into anyone saying "ehh, I don't think we should do this." ? 20:04 < abadger1999> ie: mdomsch wants mirrormanager to be MIT; mediawiki plugins should follow mediawiki's license 20:04 < abadger1999> mmcgrath: So far everyone's been positive. 20:04 < mmcgrath> abadger1999: ok, so how do we actually _do_ it? 20:05 < mmcgrath> sed? 20:05 < abadger1999> yeah, we have to replace COPYING files with AGPL/LGPL and then change the headers in source files. 20:05 < smooge> well you need to look at each app and see if its something we wrote or pulled in from somewhere else 20:06 < sijis> do you need to get written proof from author before changing? 20:06 < ricky> How urgent is this time-wise? 20:06 < smooge> if its pulled in we need to deal with it.. if its something we wrote 100% we should be able to replace COPYING/headers 20:06 < abadger1999> sijis: for the majority of things no, but I am going to notify authors of pkgdb and python-fedora before I make chanes. 20:06 < mmcgrath> ricky: I'd say not real urgent, but the longer we wait... the longer we're going to wait I suspect. 20:06 < ricky> For example, with FAS, I'd like to eventually rewrite the OpenID provider part instead of dealing with licensing pain because of samadhi or anything. 20:06 < abadger1999> sijis: The CLA gives us the ability to do a relicense if the contribution was made without an explicit license. 20:07 < mmcgrath> abadger1999: some seemed timid about that on f-a-b. I'm less timid. 20:07 < abadger1999> ricky the other option is to find out what jcollie thinks about AGPLv3+ 20:07 < mmcgrath> but we should ask 20:07 < mmcgrath> abadger1999: lets take an app like fas first. 20:07 < mmcgrath> just see how it goes. 20:08 < abadger1999> yeah, it's common courtesy and also gives people a chancce to holler "Oh wait, I actually didn't own the copyright to that code.. sorry." 20:08 -!- mcepl [n=mcepl at 49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has left #fedora-meeting [] 20:08 < mmcgrath> abadger1999: are you going to lead the effort on this? 20:08 < abadger1999> I'd like to do python-fedora soon It's moving to LGPLv2+ which is more permissive 20:08 < mmcgrath> should we open a ticket for each app? 20:08 < sijis> how many apps are we talking about for this? +/-15? 20:08 < abadger1999> mmcgrath: I can. Yes, each app. 20:08 < mmcgrath> sijis: less then 15 20:08 < abadger1999> sijis: Less htan 15 20:09 < mmcgrath> abadger1999: sounds good, so anything else? 20:09 < abadger1999> A ticket for each app will let us come back next week and say -- half of our app authors like a licensing policy but don't want to change *their* app. 20:09 < abadger1999> Which would mean we need to rethink. 20:10 < abadger1999> I think that's all unless someone wants to shout that it's a bad idea now :-) 20:10 -!- kolesovdv [n=kolesovd at 82.162.141.18] has joined #fedora-meeting 20:10 < mmcgrath> anyone have anything to say? If not now, take it to the list. 20:10 < mmcgrath> and do it sooner, not later. 20:10 < mmcgrath> Ok, so next topic 20:10 < mmcgrath> #topic Infrastructure -- The merge, outages and issues. 20:10 -!- fedbot changed the topic of #fedora-meeting to: Infrastructure -- The merge, outages and issues. 20:11 < mmcgrath> So we had a merge last week. 20:11 < mmcgrath> and since the merge we've had some issues 20:11 < mmcgrath> and it's not something obvious. 20:11 < smooge> define merge for me? 20:11 < mmcgrath> and, in fact, could be completely unrelated. 20:11 < mmcgrath> smooge: merge from staging to master branches in puppet. 20:11 < ricky> smooge: We made a ton of changes in the staging branch and merged them to production :-) 20:11 < mmcgrath> Which basically involved refactoring a bunch of puppet code, cleaning things up, creating some new modules, etc, etc. 20:11 < mmcgrath> I've not seen a wiki outage since yesterday. 20:12 < mmcgrath> I need to go through the logs and look. 20:12 -!- cassmodiah [n=cass at fedora/cassmodiah] has quit Remote closed the connection 20:12 < mmcgrath> while doing some digging we, just in general, found strange issues in our environment. 20:13 < smooge> mmcgrath, ricky thanks.. 20:13 < smooge> what have been the strange ones 20:13 < mmcgrath> for example - http://mmcgrath.fedorapeople.org/proxy-errors.html 20:13 < mmcgrath> 200,000+ 502's per day. 20:13 < mmcgrath> just seems massive to me. 20:14 < ricky> In terms of the big outages, they've all seemed to happen during mysql database backups (which lock tables) or smolt render stats jobs. 20:14 < ricky> The proxy errors and 500s seem to be something else though. 20:14 < mmcgrath> 20:14 < mmcgrath> and our current lead on the 500's errors for fas is a new mod_wsgi 20:14 < ricky> Have the 500 errors stayed normal? 20:14 < mmcgrath> jbowes is working on that. 20:15 < ricky> (As in, have they gone up after the merge or not?) 20:15 < mmcgrath> ricky: hard to say 20:15 < mmcgrath> http://mmcgrath.fedorapeople.org/JuneErrors.html 20:15 < mmcgrath> I'll re-check today now that it's been a few more days. 20:15 < mmcgrath> clearly we had a major spike 20:16 < sijis> mmcgrath: the first graph shows it being mostly proxy2 20:16 < mmcgrath> but it seems to have gone back down. 20:16 < ricky> Strange. 20:16 < mmcgrath> sijis: yeah, and proxy2 is an odd beast. 20:16 < mmcgrath> proxy2 is load balanced with proxy1 behind the PHX balancer. 20:16 < mmcgrath> _however_ 20:16 < mmcgrath> anything in phx uses proxy2 directly to get to the account system. 20:16 < mmcgrath> which not only includes shell accounts. 20:17 < mmcgrath> but also includes our web applications contacting fas for session, auth, etc. 20:17 < mmcgrath> which is a significant amount of traffic. 20:17 < smooge> interesting.. is there a reason for just proxy2? 20:17 < ricky> Funny that proxy1 seems fine. 20:17 < mmcgrath> ricky: well it does get a lot less traffic. 20:17 < ricky> Like it didn't jump significantly at all. 20:17 < ricky> I guess. 20:17 < mmcgrath> smooge: the network team won't let us contact the balancer IP directly. 20:18 < sijis> so you are forced to pick a proxy? 20:18 < smooge> ah ok could we setup another proxy? 20:18 < mmcgrath> smooge: we have two of them there. 20:18 < mmcgrath> but no good way to balance between the two of them. 20:18 < mmcgrath> we could put a load balancer in there, but it'd be just another box, and would need to be rebooted as often as proxy2 is anyway 20:18 < ricky> Is the problem really coming from our PHX admin.fp.o setup though? 20:19 < smooge> mmcgrath, no what I meant was one that was just for that so we could cut down on what might be causing the erorrs? 20:19 < ricky> The 502s really jumped everywhere, so that's what I want to know the root cause of. 20:20 < smooge> so if its a bruteforce attack on stuff we could get an idea of what app is being targeted or soemthing 20:20 < mmcgrath> I think the errors are on our end, I need to do more log checking to know for sure though 20:20 < ricky> But the brute force shouldn't be causing 502, it should be working :-) 20:20 < mmcgrath> but yeah we can add and remove more proxy servers in PHX if we want to 20:20 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit Read error: 104 (Connection reset by peer) 20:20 < ricky> mmcgrath: Can we separate that graph into apache 502s and haproxy 502s? 20:21 < ricky> Right now they're lumped together in the source where you're getting it from, right? 20:21 -!- ddumas [n=ddumas at h69-131-97-205.wltonh.dsl.dynamic.tds.net] has joined #fedora-meeting 20:21 < mmcgrath> ricky: I don't think so, because if haproxy or the app server returned a 502, apache would log a 502. 20:21 < mmcgrath> so proxyX will always have our largest number of 502's 20:21 < mmcgrath> then haproxy (if we're logging that, not even sure) 20:21 < mmcgrath> then the app server 20:22 < mmcgrath> although the app servers probably don't throw 502 20:22 < ricky> mmcgrath: But some 502s are coming from apache, as in proxy1 couldn't contact locahost:10009 20:22 < ricky> Those are the strangest ones to me. 20:22 < mmcgrath> I'll have to look closer then. 20:22 < sijis> firewall? 20:23 < ricky> sijis: I don't think so - it definitely works a large percent of the time 20:23 < mmcgrath> sijis: I'd actually think that's the app server not responding to haproxy, and thus not responding to the proxy server. 20:23 < ricky> But that should strictly cause haproxy 502s not apache 502s, correct? 20:23 < mmcgrath> and I'm not seeing us hitting our haproxy limit. 20:23 < ricky> and we've seen both :-( 20:23 < mmcgrath> ricky: when looking at the logs, how can you tell the difference? 20:24 < mmcgrath> oh from it saying it couldn't contact localhost:10009 20:24 < ricky> I'm not sure. I'd expect the apache 502s to show up in the apache error log and both types of 502s to show up in the error log. 20:24 < ricky> I'll have to verify that tohugh. 20:24 < ricky> **though 20:24 < mmcgrath> hm 20:24 < mmcgrath> hm 20:24 < mmcgrath> hmmmm 20:24 < ricky> Was your source for these graphs the error log or the access log? 20:25 < mmcgrath> acciess I believe 20:25 < sijis> is haproxy on a different server or on proxy2? 20:25 * mmcgrath looks 20:25 < mmcgrath> sijis: each proxy server has it's own haproxy service on the same host 20:25 < mmcgrath> ricky: access.log 20:26 < mmcgrath> perhaps we should continue discussing this after the meeting. 20:26 < ricky> Ah, OK. 20:26 < mmcgrath> any objections? 20:26 < ricky> Sure thing 20:26 < sijis> nope. 20:27 < mmcgrath> # topic Infrastructure -- Eye in know db. - INNODB 20:27 -!- kolesovdv [n=kolesovd at 82.162.141.18] has quit Remote closed the connection 20:27 < mmcgrath> #topic Infrastructure -- Eye in know db. - INNODB 20:27 -!- fedbot changed the topic of #fedora-meeting to: Infrastructure -- Eye in know db. - INNODB 20:27 < mmcgrath> ricky: this one's you. Talk about your plans, what's going on, what's going wrong, etc. 20:27 < smooge> is that a rock band? 20:27 < ricky> Any MySQL experts around, by the way? :-) 20:27 < mmcgrath> ricky: abadger1999 is a mysql expert 20:27 < Jeff_S> ricky: for some definition of expert 20:27 < mmcgrath> :-P 20:28 < ricky> Part of the big outages we've seen since the merge seems to be due to mysql backups (and smolt's stats refresh script, which might be a separate problem) 20:28 < ricky> We've seen this behavior with the zabbix database, where the backup would lock entire tables 20:28 < abadger1999> ricky: Yep, of the yum erase '*ysql' ; yum install 'postgres*' variety 20:28 < ricky> abadger1999: Hehe 20:28 * mmcgrath notes we've always had a small problem with backups and outages. But they've been tiny blips. Lately they've been throwing nagios alerts. 20:29 < smooge> how many mysql databases do we have? 20:29 < ricky> We'd like to move to using the --single-transaction option to mysqldump, which combined with InnoDB, should make backups not lock the entire table 20:30 < Jeff_S> ricky: yes! 20:30 < ricky> THe main mysql usage we have is mediawiki, smolt, and zabbix 20:30 < ricky> Although we have a few others for stuff like cacti, prelude/prewikka, etc. 20:30 < Jeff_S> ricky: FWIW, we've also had good luck with http://www.zmanda.com/backup-mysql.html (community edition) 20:30 < smooge> ricky, are they seperate servers or one single one 20:30 -!- kolesovdv [n=kolesovd at 82.162.141.18] has joined #fedora-meeting 20:30 < ricky> Jeff_S: Thanks, I'll take a look at that later 20:30 < ricky> smooge: They're all on db1 20:30 < mmcgrath> smooge: all mysql db's are on db1 20:31 < ricky> So far, the biggest pain we've had so far is the host_links table in smolt 20:31 < mmcgrath> ricky: and how big is it? 20:31 < mmcgrath> O:-) 20:31 < ricky> It has above 70M rows, and I haven't gotten a single successful conversion to InnoDB yet. 20:31 < ricky> And the thing with --single-transaction is that the tables need to be InnoDB to be sure that everything gets dumped in a consistent state 20:31 < Jeff_S> but single-transaction will probably solve your main problem of locking the table(s) 20:32 < abadger1999> ricky: We're able to dump that table? Are we able to reload it except as innodb? 20:32 < smooge> wow thats quite a bit 20:32 < mmcgrath> ricky: and what are the downsides to innodb? (space, etc, etc) 20:32 < abadger1999> slower 20:32 < Jeff_S> mmcgrath: slower at certain operations 20:32 < ricky> So the approaches that we've tried so far are: converting using alter table, and sedding a dump to change the table type, and loading it. 20:32 < mmcgrath> how much slower? 20:32 < ricky> The first didn't finish after some large number of hours, and the second is going now. 20:32 < ricky> mmcgrath: I'm actually not that sure about the downsides yet. Apparently loading huge tables is a huge pain. 20:33 < mmcgrath> ricky: I'm going to want render-stats metrics too 20:33 < Jeff_S> mmcgrath: depends on the dataset & queries. the locking though more than makes up for it IMO 20:33 < ricky> Also, some tables needed MyISAM for full text search - the only table affected by this is mediawiki's searchindex tables 20:33 < abadger1999> :-( 20:33 < ricky> (Which is just a copy of another InnoDB table, I believe) 20:33 < mmcgrath> ricky: and, in theory, we'll be able to get rid of that when we have a fedora search engine. 20:33 < ricky> Hopefully. 20:34 < ricky> Anyway, we'll probably have a mysql outage some time in the future once we get a successful test in staging. 20:34 < Jeff_S> mmcgrath: one of our past employees wrote this, I think it explains the reasons for using InnoDB pretty well http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB 20:34 < mmcgrath> ricky: yeah, how have the other conversions gone? 20:34 < ricky> what might be the case now is that maybe our configs aren't tuned for large innodb tables. 20:34 < smooge> ok what books/sites should I read to catch up how to help this. (DB's are not my specialty :/) 20:35 -!- hanthana [n=hanthana at 124.43.57.16] has quit Remote closed the connection 20:35 < ricky> mmcgrath: All of the other tables in the smolt db other than host_links have finished in <20 minutes 20:35 < ricky> Apart from the smolt db, most of the mediawiki db is already innodb 20:36 < ricky> The other databases that need conversions are: cacti, prelude._format, prewikka, and transifex (which isn't used anymore anyway) 20:36 < mmcgrath> ricky: I believe I went through and did some innodb conversions back in the day on some of those. 20:36 -!- openpercept_ [n=openperc at fedora/openpercept] has joined #fedora-meeting 20:36 -!- tatica is now known as tatica-out 20:36 -!- sharkcz [n=dan at plz1-v-4-17.static.adsl.vol.cz] has quit "Ukon?uji" 20:36 < ricky> prelude and prewikka are pretty much dispensable since that stuff is still being tested (lmacken even purged and recreated some of those dbs recently) 20:37 < mmcgrath> ricky: how big were those dumps? 20:37 -!- openpercept [n=openperc at fedora/openpercept] has quit Nick collision from services. 20:37 < ricky> So smolt is basically the big hurdle - although I have some questoins about the smolt upgrade and the db changes there 20:37 < ricky> The dump of the smolt database is 2.5G 20:37 * lmacken looks at the time, and rolls in late 20:37 < mmcgrath> ricky: 20:38 < mmcgrath> alter table host modify column cpu_model varchar(80); 20:38 < mmcgrath> alter table host add column cpu_stepping int(11) DEFAULT NULL; 20:38 < mmcgrath> alter table host add column cpu_family int(11) DEFAULT NULL; 20:38 < mmcgrath> alter table host add column cpu_model_num int(11) DEFAULT NULL; 20:38 < mmcgrath> that's the smolt upgrade. 20:38 < ricky> mmcgrath: Oh, OK - that's no problem at all then. 20:38 < ricky> The host table took <20 minutes, so we can do that before or after, and it's fine 20:38 * mmcgrath doesn't really even know what "int(11)" means 20:38 < lmacken> have you guys been using SQLAlchemy-migrate for that stuff? or doing it by hand? 20:38 < mmcgrath> I need to look that up :) 20:39 < mmcgrath> lmacken: honestly I can't stand alchemy-migrate so I've been doing it by hand. 20:39 < lmacken> mmcgrath: heh. I've never used it before 20:39 < mmcgrath> :) 20:39 < mmcgrath> ricky: ok, so anything else on the db front? 20:40 < ricky> Nope, but if anybody knows a lot about MySQL, let us know about your experiences with stuff like this 20:40 < ricky> Jeff_S: Thanks again for the links! 20:40 < mmcgrath> k 20:40 < Jeff_S> ricky: np. I'm glad to have our current DBA lend a hand if needed 20:40 < mmcgrath> #topic Infrastructure -- Posse 20:40 -!- fedbot changed the topic of #fedora-meeting to: Infrastructure -- Posse 20:41 < mmcgrath> So I haven't been as transparent with this as I should be 20:41 < mmcgrath> It's basically this 20:41 < mmcgrath> #link http://teachingopensource.org/index.php/POSSE_2009 20:41 < mmcgrath> we're providing some guests for a week for them to use. 20:41 < mmcgrath> +1 to open source :) 20:41 < ricky> Is it going to be on fasClient? :-) 20:41 < mmcgrath> ricky: nope, they're completely disconnected atm. 20:42 < mmcgrath> this is their first time through this. 20:42 < ricky> Ah, OK 20:42 < mmcgrath> maybe next year. 20:42 < mmcgrath> but all of these guests are on cnode1 20:42 -!- opossum1er [n=opossum1 at cnv94-4-88-160-98-200.fbx.proxad.net] has joined #fedora-meeting 20:42 < mmcgrath> part of the cloud stuff. 20:42 < smooge> what servers are their guest on 20:42 < ricky> Hehe 20:42 < smooge> ah 20:42 < mmcgrath> I ended up not using osuosl1 20:42 < mmcgrath> since it's RHEL5 and for some reason xen+fedora 11 seems to be my white whale. 20:42 -!- opossum1er [n=opossum1 at cnv94-4-88-160-98-200.fbx.proxad.net] has quit Client Quit 20:42 < mmcgrath> but cnode1 was F10, and using KVM worked just fine 20:43 < mmcgrath> Anyone have any other questions on that? 20:43 -!- Pikachu_2014 [n=Pikachu_ at 85-169-128-251.rev.numericable.fr] has quit Read error: 60 (Operation timed out) 20:43 -!- Pikachu_2014 [n=Pikachu_ at 85-169-128-251.rev.numericable.fr] has joined #fedora-meeting 20:43 < mmcgrath> Ok 20:43 < mmcgrath> #topic Infrastructure -- Open Floor 20:43 -!- fedbot changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:43 < mmcgrath> anyone have anything they'd like to discuss? 20:44 < lmacken> I'm going to be deploying a new version of bodhi tonight/tomorrow to support EPEL :) 20:44 < lmacken> hopefully we'll be able to start queueing updates up tonight 20:44 < smooge> yeah 20:44 < lmacken> and ideally mashing repos tomorrow 20:45 < mmcgrath> lmacken: sounds good 20:45 < mmcgrath> and on a related note, I need to rebuild relepel1 20:45 * mmcgrath fail built it 20:45 < mmcgrath> anyone have anything else? 20:45 < mmcgrath> smooge: ? 20:46 < smooge> sorry 20:46 < smooge> keyboard problems 20:46 < smooge> I am checking to see what boxes need updates and I am working on seeing what ones I can do 20:46 < smooge> I should have that done by tonight/tomorrow. 20:47 < smooge> After that I am checking to see that func and puppet are working on the boxes 20:47 < smooge> and then finding out all the secret handshakes and such 20:47 < mmcgrath> heheh 20:47 < mmcgrath> fun times 20:47 < smooge> I should have the func done by friday and then it will be time to work on zabbix 20:48 < mmcgrath> smooge: excellent. 20:48 < mmcgrath> Ok, and with that if no one has anything else we'll close in 30 20:48 < smooge> zabbix will be next weeks project 20:48 < smooge> done 20:49 < mmcgrath> ok everyone, thanks for coming! 20:49 < mmcgrath> #endmeeting 20:49 -!- fedbot 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/Meeting_channel for meeting schedule 20:49 < fedbot> Meeting ended Thu Jul 2 20:49:12 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:49 < fedbot> Minutes: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-07-02-20.00.html 20:49 < fedbot> Log: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-07-02-20.00.log.html -------------- 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 Fri Jul 3 00:59:21 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 2 Jul 2009 18:59:21 -0600 Subject: Systems updated Message-ID: <80d7e4090907021759o6a8412f6kbb547dd34f68e602@mail.gmail.com> Been updated as of 2009-07-02 bastion2 collab1 memcached1 memcached2 ns1 # had some issues with old transactions ns2 publictest2 torrent1 xen6 Skipped asterisk2 # needs to be fixed to f11 buildsys.fedoraproject.org compose-x86.fedora.phx.redhat.com koji1.fedora.phx.redhat.com koji1.stg.fedora.phx.redhat.com koji2.fedora.phx.redhat.com ppc1.fedora.phx.redhat.com publictest1.fedoraproject.org publictest3.fedoraproject.org rawhide1.fedoraproject.org releng2.fedora.phx.redhat.com x86-8.fedora.phx.redhat.com -- Stephen J Smoogen. Fedora Infrastructure. From a.badger at gmail.com Fri Jul 3 03:34:26 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Jul 2009 20:34:26 -0700 Subject: pkgdb -> bugzilla sync broken? In-Reply-To: <20090702140756.62ff9886@noname.noname> References: <20090702140756.62ff9886@noname.noname> Message-ID: <4A4D7C42.3060709@gmail.com> On 07/02/2009 05:07 AM, Michael Schwendt wrote: > How often is bugzilla.redhat.com updated with changes in Fedora pkgdb? > It has yet to sync the audacious* ownership changes from June 29th. > Perhaps it's broken? > > https://bugzilla.redhat.com/describecomponents.cgi?product=Fedora > This should be fixed now. The changes I made this morning weren't perfect so complete syncing of every package wasn't occurring until an hour ago. -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 Matt_Domsch at dell.com Fri Jul 3 05:08:33 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 3 Jul 2009 00:08:33 -0500 Subject: Suggestions required for generating Ambassadors map. In-Reply-To: References: Message-ID: <20090703050833.GB9279@mock.linuxdev.us.dell.com> On Thu, Jul 02, 2009 at 11:04:50PM +0530, susmit shannigrahi wrote: > The problem being, which mapping software should we use? MirrorManager and DrJef's maps both use matplotlib, basemap, and GeoIP. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From thinklinux.ssh at gmail.com Fri Jul 3 05:38:12 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Fri, 3 Jul 2009 11:08:12 +0530 Subject: Suggestions required for generating Ambassadors map. In-Reply-To: <20090703050833.GB9279@mock.linuxdev.us.dell.com> References: <20090703050833.GB9279@mock.linuxdev.us.dell.com> Message-ID: > MirrorManager and DrJef's maps both use matplotlib, basemap, and GeoIP. Fine, thanks. But mirrormanager map is a collection of dots showing locations, i.e, a non interactive map. Is it possible to add something like onclick(popup message) to the map using above technique thus making it interactive? Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From jeff at ocjtech.us Fri Jul 3 06:06:24 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 3 Jul 2009 01:06:24 -0500 Subject: Suggestions required for generating Ambassadors map. In-Reply-To: References: Message-ID: <935ead450907022306o45615ee2rf1dde30ee82b4f8a@mail.gmail.com> On Thu, Jul 2, 2009 at 12:34 PM, susmit shannigrahi wrote: > > The problem being, which mapping software should we use? > > 1. Google map - non free. > 2. Shomyu - Bochecha (the creator) does not seem to like the idea of > using this for the particular purpose. > 3. OSM - Does not have a nice api for creating a standalone map. > > I am out of my ideas about the mapping app, please suggest. Use OpenLayers to create the front end using Open Street Map as the backend source for the map. http://openlayers.org/ -- Jeff Ollie From thinklinux.ssh at gmail.com Fri Jul 3 06:13:31 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Fri, 3 Jul 2009 11:43:31 +0530 Subject: Suggestions required for generating Ambassadors map. In-Reply-To: <935ead450907022306o45615ee2rf1dde30ee82b4f8a@mail.gmail.com> References: <935ead450907022306o45615ee2rf1dde30ee82b4f8a@mail.gmail.com> Message-ID: > Use OpenLayers to create the front end using Open Street Map as the > backend source for the map. > > http://openlayers.org/ Great!!!! You saved me :) Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From poelstra at redhat.com Fri Jul 3 21:19:59 2009 From: poelstra at redhat.com (John Poelstra) Date: Fri, 03 Jul 2009 14:19:59 -0700 Subject: logistics list Message-ID: <4A4E75FF.1010401@redhat.com> The logistics at lists.fedoraproject.org mailing list has been created to meet the requirements discussed here: http://www.redhat.com/archives/fedora-advisory-board/2009-July/msg00000.html Anyone is welcome to join the list at: https://admin.fedoraproject.org/mailman/listinfo/logistics and participants are strongly encouraged to use it only for important topics that need to be coordinated across teams. I have also take the liberty to sign up leads from each the teams that attended the Fedora 11 Release Readiness meetings (assuming they will be the same for Fedora 12) as well as the people who have expressed an interest in helping with or learning more about the Fedora Zikula CMS implementation. Feel free to adjust things by adding or removing yourself. John From lmacken at redhat.com Sat Jul 4 03:25:35 2009 From: lmacken at redhat.com (Luke Macken) Date: Fri, 3 Jul 2009 23:25:35 -0400 Subject: bodhi 0.6.0 with EPEL support Message-ID: <20090704032535.GD8337@x300.pdf.local> Hey all, I just deployed bodhi 0.6.0 to app1-6 and releng{2,1.stg}. This release contains patches from both Dennis Gilmore and myself to support pushing updates for EPEL. I just submitted my first EPEL update into bodhi, so things seem to be working properly so far. It should be safe to start queueing EPEL updates, and we'll try doing a small push early next week. Please file bugs here: https://fedorahosted.org/bodhi/newticket Thanks, luke From itamar at ispbrasil.com.br Sat Jul 4 03:45:21 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Sat, 4 Jul 2009 00:45:21 -0300 Subject: bodhi 0.6.0 with EPEL support In-Reply-To: <20090704032535.GD8337@x300.pdf.local> References: <20090704032535.GD8337@x300.pdf.local> Message-ID: there are no way to push updates for fc7, fc8 and now fc9, so there are a way to remove these from new update from in autocomplete field? On Sat, Jul 4, 2009 at 12:25 AM, Luke Macken wrote: > Hey all, > > I just deployed bodhi 0.6.0 to app1-6 and releng{2,1.stg}. ?This release > contains patches from both Dennis Gilmore and myself to support pushing > updates for EPEL. > > I just submitted my first EPEL update into bodhi, so things seem to be > working properly so far. ?It should be safe to start queueing EPEL > updates, and we'll try doing a small push early next week. > > Please file bugs here: https://fedorahosted.org/bodhi/newticket > > Thanks, > > luke > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From thinklinux.ssh at gmail.com Sat Jul 4 15:19:16 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sat, 4 Jul 2009 20:49:16 +0530 Subject: Review request for hosting mapping applications. Message-ID: Hi, I have just created a test instance for clickable map here: http://publictest15.fedoraproject.org/amb_map/ambassadors.html A script takes out lat/long data (which is not private according to privacy policy) from FAS and generates this map. I have used openlayers for this purpose, and as far as I have checked, all the components used are fedora compatibly licensed. The directory (/srv/web/amb_map) contains a javascript file, openlayers.js. Please check this for discrepancies, if any. Another thing, I can see all the markers have shifted 3 degrees east and 1 degree south. Can anyone please help in correcting this? Any help in this regard will be very nice to have. Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From jeff at ocjtech.us Sun Jul 5 13:11:30 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sun, 5 Jul 2009 08:11:30 -0500 Subject: Review request for hosting mapping applications. In-Reply-To: References: Message-ID: <935ead450907050611nb168eadv318b3b27bb9d157f@mail.gmail.com> On Sat, Jul 4, 2009 at 10:19 AM, susmit shannigrahi wrote: > > I have just created a test instance for clickable map here: > http://publictest15.fedoraproject.org/amb_map/ambassadors.html > A script takes out lat/long data (which is not private according to > privacy policy) > from FAS and generates this map. Hmm.... the map was showing up yesterday and looked pretty good. It's not showing up today for some reason. > I have used openlayers for this purpose, and as far as I have checked, > all the components used are fedora compatibly licensed. OpenLayers is packaged in Fedora, so I think we're good on the licensing. https://admin.fedoraproject.org/pkgdb/packages/name/openlayers -- Jeff Ollie From thinklinux.ssh at gmail.com Sun Jul 5 14:41:26 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sun, 5 Jul 2009 20:11:26 +0530 Subject: Calendaring idea In-Reply-To: References: <4A3A9082.7090803@redhat.com> Message-ID: > It's sure worth a look. ?Susmit, what do you think? Looks like we have hit the usual hardle, java. http://code.google.com/p/calagator/wiki/DevelopmentSoftware says it need java 1.6 for solr which provides search functionality. I am not sure if it works with openjdk or not. Can anyone please update in that regard? Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From thinklinux.ssh at gmail.com Sun Jul 5 15:12:33 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sun, 5 Jul 2009 20:42:33 +0530 Subject: Review request for hosting mapping applications. In-Reply-To: <935ead450907050611nb168eadv318b3b27bb9d157f@mail.gmail.com> References: <935ead450907050611nb168eadv318b3b27bb9d157f@mail.gmail.com> Message-ID: > > Hmm.... the map was showing up yesterday and looked pretty good. ?It's > not showing up today for some reason. Thanks for the comment. Yes, it is unavailable today, as I was rewriting the app. The code now is very short and much elegant. The map should be available now. http://publictest15.fedoraproject.org/amb_map/ambassadors.html >> I have used openlayers for this purpose, and as far as I have checked, >> all the components used are fedora compatibly licensed. > > OpenLayers is packaged in Fedora, so I think we're good on the licensing. > https://admin.fedoraproject.org/pkgdb/packages/name/openlayers Great!!!! Thanks. :) -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From djuran at redhat.com Sun Jul 5 19:20:43 2009 From: djuran at redhat.com (David Juran) Date: Sun, 5 Jul 2009 15:20:43 -0400 (EDT) Subject: package category "new-package" for fedora-package-announce In-Reply-To: <1676393634.8261246821261864.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <973250499.8281246821643731.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Hello! Would it be possible to add a new category for new packages to the fedora-package-announce list? I'm interested in seeing what new packages are released to Fedora but I don't have the time/patience to wade through the full bulk of the fedora-package-announce list. So in the same way that there currently exists a category for security updates, would it be possible to implement a category for new packages? -- David Juran Sr. Consultant Red Hat +358-504-146348 From lmacken at redhat.com Mon Jul 6 14:01:55 2009 From: lmacken at redhat.com (Luke Macken) Date: Mon, 6 Jul 2009 10:01:55 -0400 Subject: package category "new-package" for fedora-package-announce In-Reply-To: <973250499.8281246821643731.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <1676393634.8261246821261864.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <973250499.8281246821643731.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <20090706140155.GC4110@x300> On Sun, Jul 05, 2009 at 03:20:43PM -0400, David Juran wrote: > Hello! > > Would it be possible to add a new category for new packages to the fedora-package-announce list? > I'm interested in seeing what new packages are released to Fedora but I don't have the time/patience to wade through the full bulk of the fedora-package-announce list. So in the same way that there currently exists a category for security updates, would it be possible to implement a category for new packages? Hi David, Would prepending something like [NEW] to the subject (similar to how we add [SECURITY]) suffice? This would be a fairly trivial change to bodhi. luke From djuran at redhat.com Mon Jul 6 14:09:56 2009 From: djuran at redhat.com (David Juran) Date: Mon, 06 Jul 2009 17:09:56 +0300 Subject: package category "new-package" for fedora-package-announce In-Reply-To: <20090706140155.GC4110@x300> References: <1676393634.8261246821261864.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <973250499.8281246821643731.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <20090706140155.GC4110@x300> Message-ID: <1246889396.4902.1.camel@localhost.localdomain> On Mon, 2009-07-06 at 10:01 -0400, Luke Macken wrote: > Would prepending something like [NEW] to the subject (similar to how we > add [SECURITY]) suffice? This would be a fairly trivial change to > bodhi. Sure, that would make it easy enough to filter (-: -- David Juran Sr. Consultant Red Hat +358-504-146348 -------------- 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 tmz at pobox.com Mon Jul 6 14:24:32 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 6 Jul 2009 10:24:32 -0400 Subject: package category "new-package" for fedora-package-announce In-Reply-To: <20090706140155.GC4110@x300> References: <1676393634.8261246821261864.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <973250499.8281246821643731.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <20090706140155.GC4110@x300> Message-ID: <20090706142432.GX4753@inocybe.localdomain> Luke Macken wrote: > Would prepending something like [NEW] to the subject (similar to how > we add [SECURITY]) suffice? This would be a fairly trivial change > to bodhi. If that's done, making a 'New' topic in the mailman list should be trivial as well. Then folks could subscribe and choose to only receive that topic. I'm not a list admin for the package announce list, so I don't want to volunteer anyone for more work, but I would be happy to help as a list admin there though, if it would help. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Damn you vile woman, you've impeded my work since the day I escaped your vile womb! -- Stewie Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at j2solutions.net Mon Jul 6 14:44:26 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 6 Jul 2009 07:44:26 -0700 Subject: package category "new-package" for fedora-package-announce In-Reply-To: <1246889396.4902.1.camel@localhost.localdomain> References: <1676393634.8261246821261864.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <973250499.8281246821643731.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <20090706140155.GC4110@x300> <1246889396.4902.1.camel@localhost.localdomain> Message-ID: On Jul 6, 2009, at 7:09, David Juran wrote: > On Mon, 2009-07-06 at 10:01 -0400, Luke Macken wrote: > >> Would prepending something like [NEW] to the subject (similar to >> how we >> add [SECURITY]) suffice? This would be a fairly trivial change to >> bodhi. > > Sure, that would make it easy enough to filter (-: > I would prefer x-update_type or similar. Allow for filtering without dirtying up the subject. I would also make it easier to make topics on the mailman side. -- Jes From mmcgrath at redhat.com Mon Jul 6 16:15:47 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 6 Jul 2009 11:15:47 -0500 (CDT) Subject: Some ongoing issues Message-ID: So we've got some ongoing issues in our environment right now. Some of them are unrelated. All are being worked on but one in particular I want to discuss on the list here because I just don't know what changed. The problem: When one of the fas servers goes offline, most of our other apps get taken offline. The way it is supposed to work: When one of our fas servers goes offline, haproxy takes it out of the farm and sends all requests to the still online fas server. Thus, possibly, generating a few errors for a short time but generally goes un-noticed. The details: When one of the fas servers goes offline, haproxy is hanging on that connection. The application servers hang or possibly try to re-use connections to fas, thus causing the number of httpd processes to sky rocket on the app servers. Ultimately hitting MaxClients and taking everything offline. This happens fairly quickly, matter of seconds. It seems that even after haproxy flags the fas server as dead (takes about 15s), that any connections open at that time to the old server aren't killed. They just hang. Outstanding questions: What changed? Does python-fedora (our primary interface to fas) now do something differently with keepalive? Anyone else using haproxy seeing this same issue? I've got redispatch enabled still. -Mike From thinklinux.ssh at gmail.com Mon Jul 6 19:05:45 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Tue, 7 Jul 2009 00:35:45 +0530 Subject: [Request for Resources] Global ambassadors map. Message-ID: Hi, Here is the details for the RFR of global ambassadors map project. I have also updated the ticket #1514. Thanks. ----------------------------------------------------------------------------- Project Sponsor ----------------------------------------------------------------------------- Name: Susmit Shannigrahi Fedora Account Name: susmit Group: Ambassadors Infrastructure Sponsor: None so far. ----------------------------------------------------------------------------- Secondary Contact info ----------------------------------------------------------------------------- Name: Joerg Simon Fedora Account Name: jsimon Group: Ambassadors ----------------------------------------------------------------------------- Project Info: ----------------------------------------------------------------------------- Project Name: Global Ambassadors map. Target Audience: Anyone needing any info about fp.o. Inside and outside fp.o. Expiration/Delivery Date (required): As soon as possible. :) Description/Summary: Mapping app extracting location info of Ambassadors and put it on a map, along with necessary contact information. Project plan (Detailed): Ambassadors are interface between the project and the people. So, whenever wants to know something about fedora, he/she cantacts an ambassador. So far, this has been a tedious process of searching through a number of user pages to know who is the nearest ambassador to contact. This map will enable anyone to locate the location of an ambassador and/or the nearest one whom to ask help for. This can be extended for all other sub projects too. Goals: , nothing to add. ----------------------------------------------------------------------------- Specific resources needed: ----------------------------------------------------------------------------- 1. Hosting of https://fedorahosted.org/fama/browser/ambassadors_map/ambassadors.html 2. Hosting of https://fedorahosted.org/fama/browser/ambassadors_map/ambassadors_location.txt (contains data for the map) 3. Hosting and putting into cron this python script https://fedorahosted.org/fama/browser/membership-map.py. Also, automated authentication using dummy fas account to get location data from fas. 4.Preferably Puppet managed. ----------------------------------------------------------------------------- Additional Info (Optional) : ----------------------------------------------------------------------------- A test instance is here: http://publictest15.fedoraproject.org/amb_map/ambassadors.html Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From onekopaka at gmail.com Tue Jul 7 02:40:28 2009 From: onekopaka at gmail.com (Darren VanBuren) Date: Mon, 6 Jul 2009 19:40:28 -0700 Subject: Self introduction Message-ID: <208905F5-940D-47D9-9897-E314687F6978@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello f-i-l! If you're on the websites team, you may know me already, and if you're in #fedora-admin frequently on freenode you might also know me. So, I'm 14 years old (might be scary for some of you to find out), and I'm mostly working with the Fedora infrastructure to work on a new project for Fedora, blogs.fedoraproject.org. In my defense for working on blogs, is I run my own blog on my own server (right out of the WordPress svn tree!), and it's fairly successful. If you wanna check it out, visit http://oks.kicks-ass.net/~onekopaka/blog/ . So yep. That's pretty much my intro email... Darren VanBuren onekopaka at gmail.com ==================== http://oks.verymad.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFKUrWdBkMMSWb0YpYRAinUAKC7jhApP69Z03TQw+JJHDFX+KwylACfc9Hz Ms3tlYEfdI9+xaWZKd/iLfY= =+44U -----END PGP SIGNATURE----- From jonstanley at gmail.com Tue Jul 7 02:55:24 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 6 Jul 2009 22:55:24 -0400 Subject: Self introduction In-Reply-To: <208905F5-940D-47D9-9897-E314687F6978@gmail.com> References: <208905F5-940D-47D9-9897-E314687F6978@gmail.com> Message-ID: On Mon, Jul 6, 2009 at 10:40 PM, Darren VanBuren wrote: > So yep. That's pretty much my intro email... Welcome Darren! I just sponsored Darren into sysadmin-web, let me know if he breaks anything! Just kidding, I'm sure that won't happen :) From Matt_Domsch at Dell.com Tue Jul 7 02:57:27 2009 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Mon, 6 Jul 2009 21:57:27 -0500 Subject: Self introduction In-Reply-To: References: <208905F5-940D-47D9-9897-E314687F6978@gmail.com> Message-ID: Wasn't Ricky about 14 when he started with us? :-) Welcome Darren. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora-infrastructure-list-bounces at redhat.com] On Behalf Of Jon Stanley Sent: Monday, July 06, 2009 9:55 PM To: Fedora Infrastructure Subject: Re: Self introduction On Mon, Jul 6, 2009 at 10:40 PM, Darren VanBuren wrote: > So yep. That's pretty much my intro email... Welcome Darren! I just sponsored Darren into sysadmin-web, let me know if he breaks anything! Just kidding, I'm sure that won't happen :) _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From jonstanley at gmail.com Wed Jul 8 17:06:19 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 8 Jul 2009 13:06:19 -0400 Subject: zodbot minor issue Message-ID: There's a minor issue with the supybot-based config of MeetBot. Until it can be resolved, it's important that zodbot be started with it's cwd in /srv/web/meetbot. Weird, yes. But effective at making it work :) From ian at ianweller.org Wed Jul 8 17:50:12 2009 From: ian at ianweller.org (Ian Weller) Date: Wed, 8 Jul 2009 12:50:12 -0500 Subject: zodbot minor issue In-Reply-To: References: Message-ID: <20090708175012.GB29325@deathray.ianweller.org> On Wed, Jul 08, 2009 at 01:06:19PM -0400, Jon Stanley wrote: > There's a minor issue with the supybot-based config of MeetBot. Until > it can be resolved, it's important that zodbot be started with it's > cwd in /srv/web/meetbot. Weird, yes. But effective at making it work > :) I'd add that to https://fedoraproject.org/wiki/ISOP:ZODBOT :) -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin at tummy.com Wed Jul 8 17:53:33 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 8 Jul 2009 11:53:33 -0600 Subject: zodbot minor issue In-Reply-To: References: Message-ID: <20090708115333.6e6f9356@ohm.scrye.com> On Wed, 8 Jul 2009 13:06:19 -0400 Jon Stanley wrote: > There's a minor issue with the supybot-based config of MeetBot. Until > it can be resolved, it's important that zodbot be started with it's > cwd in /srv/web/meetbot. Weird, yes. But effective at making it work > :) I have reported this issue to upstream. Another workaround, if one is wanted would be to make a meetingLocalConfig.py and put the correct logDir in there. It works as expected when reading it from the config file. I'll update as upstream is able to fix this. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From smooge at gmail.com Thu Jul 9 00:11:32 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 8 Jul 2009 18:11:32 -0600 Subject: Removed old logs from proxy2 Message-ID: <80d7e4090907081711u615b1deo5afda4adfea68b50@mail.gmail.com> Found out that majority of space being used was /var/log/httpd and most were in the /admin.fedoraproject.org-access.log.* ones. Checked with mmcgrath about removing old ones and got ok. Confirmed on log1 that the logs were copied over and removed /var/log/httpd/admin.fedoraproject.org-access.log.2009-06-26 /var/log/httpd/admin.fedoraproject.org-access.log.2009-06-27 /var/log/httpd/admin.fedoraproject.org-access.log.2009-06-28 disk space moved to 22% free. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From ricky at fedoraproject.org Thu Jul 9 23:41:12 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 9 Jul 2009 19:41:12 -0400 Subject: Meeting Log - 2009-07-09 Message-ID: <20090709234112.GA16247@alpha.rzhou.org> 20:00 < mmcgrath> #startmeeting 20:00 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 < zodbot> Meeting started Thu Jul 9 20:00:28 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 < mmcgrath> #topic Infrastructure -- Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 < ggruener> ping 20:01 * tmz listens in for once 20:01 -!- notting [n=notting at redhat/notting] has joined #fedora-meeting 20:01 * johe waves 20:01 * SmootherFrOgZ is 20:01 -!- thomasj_ is now known as thomasj 20:01 * rjune_wrk lurks 20:01 -!- GeroldKa [n=GeroldKa at fedora/geroldka] has quit "Verlassend" 20:02 * dgilmore 20:02 < mmcgrath> k, lets get started 20:02 < mmcgrath> #topic Infrastructure -- tickets 20:02 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- tickets 20:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:02 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 < ssmoogen> here 20:02 < mmcgrath> so 20:02 < mmcgrath> .ticket 1503 20:02 < mmcgrath> abadger1999: around? 20:02 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:02 * nirik is here in the back. 20:03 -!- herlo [n=clints at fedora/herlo] has joined #fedora-meeting 20:03 -!- kolesovdv [n=kolesovd at 82.162.141.18] has joined #fedora-meeting 20:03 * mmcgrath assumes he's not around 20:04 -!- ivana [n=varekova at ip-89-103-124-118.karneval.cz] has quit Read error: 110 (Connection timed out) 20:04 < mmcgrath> so 20:04 < abadger1999> mmcgrath: I'm here. Nothing new on this since last week. 20:04 * herlo is here for the infra meeting 20:04 < mmcgrath> abadger1999: oh, k. Sounds good. 20:04 < mmcgrath> #topic Infrastructure -- Proxy timeouts 20:04 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Proxy timeouts 20:04 < abadger1999> No one's objected, I guess we can ake it off of the meeting for a bit 20:04 -!- thekad [n=kad at 187.142.23.8] has joined #fedora-meeting 20:05 < mmcgrath> So, after much debugging, testing, re-debugging. We determined the problem was a difference in how ProxyPass handles proxying and RewriteRule [P] handles proxying. 20:05 < mmcgrath> Annoying on all fronts 20:05 < mmcgrath> and was causing great issues. 20:05 < mmcgrath> but thing seem to have calmed down quite a bit. I'm going to re-run our metrics tests in a bit to see if we're back down to pre-merge levels. 20:06 < mmcgrath> anyone have any questions on that? 20:06 < ssmoogen> yes 20:06 < ssmoogen> what did we settle on 20:06 < ssmoogen> ProxyPass or RewriteRule 20:06 < mmcgrath> well, we're back to RewriteRule 20:06 < johe> what proxy do we use, if i may ask 20:06 < mmcgrath> which is what we were before the merge. 20:06 < abadger1999> Do we know what the difference is or just that they are different? 20:06 < mmcgrath> johe: apache + mod_proxy 20:07 < mmcgrath> abadger1999: well, according to a guy in #httpd there isn't one. 20:07 < abadger1999> hah 20:07 < mmcgrath> I suspect ProxyPass takes on some default values. 20:07 < ssmoogen> mmcgrath, hehehe 20:07 < johe> thought about nginx for proxy? 20:07 < mmcgrath> johe: people bring up $OTHER_PROXY all the time but no one's ever really been able to answer why it'd be worth moving to. 20:08 < mmcgrath> I think RewriteRule might either take on different timeout values then ProxyPass or maybe doesn't even have them and behaves in a more raw manner. 20:08 < mmcgrath> There were also some keepalive values we altered. 20:08 < johe> okay, we should discuss this later on :-) 20:08 < mmcgrath> johe: we can discuss it now if you want, if not now take it to the list. 20:09 < johe> i take it to the list 20:09 < dgilmore> johe: it is a fairly simple process we use 20:09 < mmcgrath> cool 20:09 < mmcgrath> Ok 20:09 < mmcgrath> sooo.... 20:09 * mmcgrath thinks. 20:09 < mmcgrath> #topic Infrastructure -- Databases 20:09 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Databases 20:09 < mmcgrath> So we continue to see some database issues 20:09 < mmcgrath> but the wiki outages seem to be gone 20:09 < mmcgrath> https://admin.fedoraproject.org/haproxy/proxy1/ 20:10 < mmcgrath> shows 0 downtime since the last haproxy reboot. 20:10 < mmcgrath> that's a very good thing. 20:10 < mmcgrath> The last outstanding issue seems to be with smolt. 20:10 < mmcgrath> now, this is something that came about after the merge, but I actually think we were having it before. 20:10 < mmcgrath> I think ricky disabled some caching that we were doing against smolt. 20:11 < mmcgrath> so even when it went down, nagios didn't notice because it kept pulling up the cached version. 20:11 < mmcgrath> There's still a few options we're investigating 20:11 < mmcgrath> mostly based around switching to innodb, changing how we do backups, and using different queries for render-stats 20:11 < mmcgrath> as render-stats seems to be the thing taking everything down 20:12 < thekad> mmcgrath I was talking with ricky about myisam->innodb last night, specifically about the host_links table 20:12 < ssmoogen> what does render-stats do? 20:12 < mmcgrath> ssmoogen: it generates - http://smolts.org/static/stats/stats.html 20:13 < mmcgrath> thekad: you have some experience with this? 20:13 < dgilmore> mmcgrath: i think innodb would be a helpful move 20:13 < mmcgrath> myisam vs innodb I mean 20:13 < mmcgrath> dgilmore: everything we've heard has said it will be a godo thing, except for when we actually go to do it. 20:13 < mmcgrath> importing from an innodb dump I think took 14 hours, vs les then 1 hour for myisam. 20:13 < thekad> mmcgrath, a bit, yeah, I was telling him that the amount of time that table takes to load doesn't sound like too far fetched 20:13 < mmcgrath> so we're worried about other impacts. 20:14 < thekad> load from a mysqldump I mean 20:14 < mmcgrath> thekad: will we see a similar slow down (more than n order of magnitude) for usage of the table? 20:14 < dgilmore> mmcgrath: you should be able to convert on the fly 20:14 < dgilmore> but not sure what effect that would have 20:14 < thekad> mmcgrath, that's possible, I was telling him to maybe run a couple tests with a tenth of the rows, then doubling it 20:15 < mmcgrath> dgilmore: we were trying, we never got through one, usually killed it around 20 hours 20:15 < thekad> mmcgrath, the thing is, all the sanity checks that you disable while loading it, are done during every transaction 20:15 < mmcgrath> thekad: so I think the general thought is we want to move to innodb, but we want to see what we're getting ourselves into :) 20:15 < dgilmore> mmcgrath: gahh ok 20:16 < mmcgrath> thekad: our understanding is innodb will be 'slower' then myisam. Do you know exactly what that means? 20:16 < mmcgrath> I know it's larger then myisam. 20:16 < mmcgrath> so i'd just assumed that extra time was just because it's reading more from the disks. 20:16 < dgilmore> mmcgrath: in some ways it will be quicker 20:16 < thekad> mmcgrath, innodb does some data integrity checks on every operation, myisam doesn't support FKs for example, so that brings an overhead 20:17 < dgilmore> since yu can do row level locking for updates 20:17 < mmcgrath> thekad: 'every operation' we talking writes or reads or both? 20:17 < dgilmore> so there could be multiple updates at ones 20:17 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit Remote closed the connection 20:17 < thekad> mmcgrath, writes, I mean update, insert, delete 20:17 < dgilmore> mmcgrath: i think he means writes here 20:17 < mmcgrath> thekad: how's it's read compare? 20:18 -!- than_home [n=than at p5B3FED8C.dip.t-dialin.net] has joined #fedora-meeting 20:18 < thekad> mmcgrath, almost the same, it degrades a bit because of the IO operations, but makes up for it by using indexes and other stuff innodb has 20:18 < thekad> so it should be mostly the same, if not a lil' bit faster 20:19 < mmcgrath> thekad: are there different indexing options we should look at for our larger tables? or do the types of indexes offered by myisam directly map to innodb indexes? 20:19 < ssmoogen> thekad my minimal reading was that if one needed to scale to mysql clustering.. innodb was needed. 20:19 < thekad> the clear advantage of using innodb is data integrity, if you don't mind about that too much, there's no real gain from innodb 20:19 < thekad> ssmoogen, that is correct 20:20 < thekad> mmcgrath, I think you can tweak them a little, may need to give some more reading about that though 20:20 < mmcgrath> k 20:20 < mmcgrath> thekad: well thanks for your help on that, please do stick around and help us through that transition. 20:21 < mmcgrath> right now ricky's got lead on that, i'm sort of just keeping tabs and testing from time to time. 20:21 < thekad> mmcgrath, there can be some more options such as clustering, sharding, master/slave, we can check them all and evaluate some more 20:21 < mmcgrath> Anyone have any questions on this before we move on? 20:21 < thekad> mmcgrath, ok 20:21 < mmcgrath> thekad: thanks 20:22 < mmcgrath> so withour merge outages and smolt, thats really about all I've been up to. 20:22 < mmcgrath> I'll open the floor 20:22 < mmcgrath> #topic Infrastructure -- Open Floor 20:22 < ssmoogen> my only question is how we can test to see how we spread the load 20:22 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:22 < mmcgrath> ssmoogen: well, I've done clustering in the past and we can do that if we have to :) 20:22 < mmcgrath> I'd like to avoid it though 20:23 < lmacken> So yeah, bodhi now supports EPEL. 20:23 < mmcgrath> lmacken: take it 20:23 < lmacken> It required more hacking than I expected, but the result makes bodhi much more flexible and gives me a much better idea of what is needed from the model in the upcoming bodhi rewrite. 20:23 < ssmoogen> mmcgrath, my only experience with mysql has been with spread out clusters :). If you have another app get another DB :).. which I usually thought was horse manure but was what the Mysql people I dealt with believed in 20:23 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 20:23 < ssmoogen> oh sorry.. 20:23 < lmacken> I also fixed a lot of other bugs in the process. 20:24 < lmacken> Also, I just updated the Bodhi SOP with details on how to push updates as well: https://fedoraproject.org/wiki/Bodhi_Infrastructure_SOP 20:24 < mmcgrath> ssmoogen: :) 20:24 < lmacken> that's all I got :) 20:24 < ssmoogen> thanks lmacken and dgilmore 20:24 < dgilmore> lmacken: thanks. 20:24 < ssmoogen> lmacken, does bodhi have workflows? 20:24 < abadger1999> Yay! 20:24 < mmcgrath> dgilmore: how have the pushes been going? 20:24 < ssmoogen> as in forcing people to push things into testing versus publish to production? 20:24 < dgilmore> lmacken: did we get the bug fixed preventing the summary email of testing updates being sent? 20:24 < lmacken> ssmoogen: not exactly, but Fedora Community will be putting those in place soon 20:25 < lmacken> dgilmore: yeah, I sent those out by hand last night 20:25 < dgilmore> mmcgrath: I have one issue i need to fix. all packages are getting touched on each update 20:25 < dgilmore> lmacken: ok ive not seen them 20:25 < mmcgrath> dgilmore: on the master mirror? 20:25 < mmcgrath> dgilmore: about how long does it take to do a push (both real time and actual person typing time) 20:25 < dgilmore> mmcgrath: yeah 20:26 < abadger1999> lmacken: Seems like the wrong layer... if it's just in Community, people can still circumvent it. 20:26 < dgilmore> mmcgrath: seems to take about 3-4 hours for a push. which is longer that the 30 minutes or so previously 20:26 < abadger1999> like cvs force tagging and our koji workflow 20:26 < lmacken> abadger1999: right, but the workflow layer has to encompass more than just bodhi (eg: cvs, koji, etc) 20:27 < mmcgrath> dgilmore: I've never actually gone through the bodhi process. Is it pretty intensive work for 3-4 hours? Or is it type a few things and go get some tea? 20:27 < abadger1999> As a whole... but the bottom layers ahve to support the locking down that we want to do at the top. 20:27 < lmacken> dgilmore: http://lists.fedoraproject.org/pipermail/epel-package-announce/2009-July/000004.html -- I may have accidently sent it to the package-announce-list by hand instead 20:27 < dgilmore> lmacken: i have to say anything workflow wise in fedora community feels like the wrong place for it 20:27 < dgilmore> lmacken: yep wrong list 20:27 < lmacken> well, propose something better :) 20:28 < lmacken> the plan for fcomm v2.0 was initially: workflows 20:28 < lmacken> I wanted to tackle security bug tracking in there as well as others 20:28 < dgilmore> lmacken: it all has to work without fedora community 20:29 -!- Southern_Gentlem [n=notfred at fedora/Southern-Gentleman] has quit Read error: 110 (Connection timed out) 20:29 < dgilmore> it can happen in community but it needs to work with koji,cvs,bodhi,pkgdb also 20:29 < lmacken> all of the workflows already work w/o it. 20:29 < lmacken> we're just making it easier 20:29 < dgilmore> lmacken: maybe i miss understood what your trying to do 20:29 < abadger1999> lmacken: Not in this case. In this case, we're trying to prevent people from doing something. 20:29 < abadger1999> lmacken: So that has to be enabled at the bottom layer. 20:30 < dgilmore> abadger1999: which in preventing things it needs to happen at the lowest level not the highest 20:30 < lmacken> anyway, we can take the workflow tangent elsewhere :) 20:30 < mmcgrath> yeah 20:31 < dgilmore> mmcgrath: real world doing things is about 30 minutes or so a push 20:31 < ssmoogen> hi guys.. I need a picture on both sides ... I sense people may be in violent agreement but IRC is not the medium to convey the pictures 20:31 < mmcgrath> dgilmore: k. 20:31 < lmacken> ssmoogen: agreed. we'll make sure to lay out a full roadmap for any workflow things we are thinking about attempting, and take everyones thoughts and suggestions into consideration beforehand 20:31 -!- GeroldKa [n=GeroldKa at fedora/geroldka] has joined #fedora-meeting 20:31 < dgilmore> alot of it is checking on what people are trying to push into stable 20:32 < dgilmore> mmcgrath: biggest issue so far is people pushing straight to stable 20:32 < lmacken> I'm going to try and get EPEL integrated into Fedora Community soon sa well 20:32 < ssmoogen> dgilmore, and hitting them with a stun gun when it isnt security :) 20:32 < dgilmore> and bypassing testing 20:32 < dgilmore> ssmoogen: right the only ones ive allowed though are security ones 20:32 < dgilmore> like mmcgrath's nagios packages 20:33 * nb|away is here but late 20:33 < mmcgrath> dgilmore: ah, the issue being that's not in the spirit of epel? 20:33 -!- nb|away is now known as nb 20:33 < dgilmore> mmcgrath: right 20:33 < abadger1999> These things need to get discussed here. we're looking at how to enforce policy on all of our apps... that needs to be talked about as a fedora infrastructure issue. 20:33 < dgilmore> it was something much more easily controlled in the old setup 20:34 < dgilmore> mmcgrath: i think i can do some work on bodhi to support epel policies better 20:34 < mmcgrath> yeah. 20:34 -!- Sonar_Guy [n=Who at fedora/sonarguy] has joined #fedora-meeting 20:34 < mmcgrath> I mean, at the end of the day we have to trust the packagers somewhat, but I'm sure there's somethign we can do. 20:35 < mmcgrath> abadger1999: so what are some bullet points we should hit? 20:35 -!- Southern_Gentlem [n=notfred at fedora/Southern-Gentleman] has joined #fedora-meeting 20:35 < ssmoogen> trust? humans? mmcgrath are you sure you are a system administrator? 20:35 < abadger1999> What's the policy we're trying to enforce? --dgilmore has ideas on that for EPEL. 20:35 < abadger1999> Do we also need enforcment for Fedora? 20:36 < mmcgrath> ah 20:36 < abadger1999> What apps need to change to enforce that workflow? -- for updates, that would be bodhi. 20:36 < ssmoogen> abadger1999, I have heard f13 would like it.. but I would take that to be a cultural thing 20:36 < dgilmore> abadger1999: all packages but security updates need to go through testing 20:36 < mmcgrath> in EPEL we have a good track record of "build" -> "testing" -> "stable" 20:36 < abadger1999> What UI do we want to put on top of that? Probably has Bodhi and Fedora Community changes. 20:36 < mmcgrath> but that's largely because of the man behind the scenes. 20:37 < dgilmore> mmcgrath: right it was easy to do with the old scripts 20:37 -!- than_home [n=than at p5B3FED8C.dip.t-dialin.net] has quit Read error: 110 (Connection timed out) 20:37 -!- than_home [n=than at nat/redhat/x-02ba6102c49f6b0c] has joined #fedora-meeting 20:38 < mmcgrath> dgilmore: what did you have in mind for it? 20:38 < dgilmore> we made packages lie in testing for between a week and just over a month 20:38 < mmcgrath> I mean, in EPEL, we could enforce "nothing but securty" if we wanted 20:38 < dgilmore> mmcgrath: automate moving things to testing if people try them in stable 20:39 < mmcgrath> lmacken: how painful would that be? 20:39 < mmcgrath> dgilmore: would that all be 'behind the scenes stuff'? 20:39 < dgilmore> and enforcing at least two weeks in testing without autokarma moving to stable 20:39 < mmcgrath> and if they wanted somethign pushed to testing, would it stay there until they push it to stable? 20:39 < dgilmore> mmcgrath: i think it needs to be 20:39 < mmcgrath> abadger1999: how's that work now, do you know? 20:40 < dgilmore> mmcgrath: right, it would stay in testing until moved to stable 20:40 < lmacken> mmcgrath: to enforce testing except for security updates? bodhi /used/ to do that, but I made it configurable after many complaints 20:40 < dgilmore> but we should make it in testing two weeks without karma 20:40 * mmcgrath suspects this doesn't seem to need any UI changes in bodhi 20:40 < mmcgrath> am I right on that? 20:40 -!- Sonar_Guy [n=Who at fedora/sonarguy] has quit "Leaving" 20:41 < ssmoogen> dgilmore, your description of wait/karma was exactly what I was hoping for from bodhi 20:41 < lmacken> right, but it may need some backend tweaks depending on what poly we want to enforce 20:41 < abadger1999> More error messages, maybe some documentation that there's limits in place 20:41 < dgilmore> lmacken: i think we could do it all with the client when running admin tasks 20:41 -!- giallu [n=giallu at fedora/giallu] has joined #fedora-meeting 20:41 < lmacken> dgilmore: cool 20:42 < dgilmore> lmacken: to give us the list of packages that we want to push 20:42 < abadger1999> Maybe take out the ability to select "stable" when creating an update. 20:42 < dgilmore> abadger1999: unless its a security update 20:42 < abadger1999> dgilmore: Isn't that what security is for? 20:43 < abadger1999> ie: testing/security instead of testing/stable/security 20:43 < dgilmore> abadger1999: well the bugzilla security update was only requested to go to testing 20:44 < dgilmore> abadger1999: the type of update is different to the location 20:44 < dgilmore> but maybe we can tweak that and add some policy support to bodhi 20:44 < abadger1999> Hmm.. in Fedora, I know I've flagged an update as security and then the security team reviews it and pushes it to stable... no matter whether I selected testing or stable initially. 20:44 < dgilmore> that way epel can have one set of rules and Fedora another 20:45 < abadger1999> But perhaps that's the particular person who handled that security update rather than policy. 20:45 < dgilmore> abadger1999: the security team doesnt look at epel 20:45 < dgilmore> at least not yet 20:45 < abadger1999> 20:45 -!- Sonar_Guy [n=Who at fedora/sonarguy] has joined #fedora-meeting 20:45 < abadger1999> but the policies of epel and fedora only diverge when explicitly stated. 20:45 < dgilmore> abadger1999: pushing policy is one of them 20:46 < abadger1999> 20:46 < mmcgrath> Ok, so I think we're generally in agreement about what all has to happen. 20:46 < mmcgrath> is this all blocking on luke to get it done? 20:46 < dgilmore> mmcgrath: :) right 20:46 < mmcgrath> lmacken: what would you need? 20:46 < lmacken> mmcgrath: tickets saying exactly what you guys want to happen :) 20:46 < dgilmore> mmcgrath: it will need his help. but im going to work on what i can 20:46 < mmcgrath> ok 20:47 < mmcgrath> well, not to take up the rest of the meeting with that, anything else to discuss on that topic? 20:47 < ssmoogen> lmacken, how can I help 20:48 < lmacken> ssmoogen: I'm not sure yet, we need to figure out exactly what needs to get done first 20:48 -!- itamarjp [n=itamar at 189-015-126-186.xd-dynamic.ctbcnetsuper.com.br] has quit Remote closed the connection 20:48 < mmcgrath> dgilmore: you ok being on ticket patrol? Getting which ones need to be created and creating them? 20:48 < dgilmore> mmcgrath: :) sure 20:48 < mmcgrath> Ok, well if there's nothing else on that topic 20:48 < mmcgrath> anyone have anything else while the floor is open? 20:48 < nb> blogs.fp.org is going pretty well, basically everything is ready I believe except for we are blocking on FAS integration. FWIW, I'd rather stick with our original solution of letting people sign up, as long as they use a @fedoraproject.org email address, as wordpress-mu is not that cooperative with authentication plugins, but we'll keep working on it. 20:48 < ssmoogen> lmacken, ok let me know how I can help test and document... and I will do the best I can 20:49 < lmacken> ssmoogen: will do :) 20:49 -!- cassmodiah [n=cass at fedora/cassmodiah] has joined #fedora-meeting 20:50 < nb> we have a plugin that nigel made, but for some reason it keeps letting everyone in as long as they have a cla_done username, no matter if the password is correct or not 20:50 < mmcgrath> nb: what seems to be the problem? 20:50 < mmcgrath> interesting 20:50 < mmcgrath> and hilarious ;) 20:50 < nb> yeah 20:50 < mmcgrath> is it ignoring the json response or something? 20:50 < nb> not sure, i havent looked into it much, nigel couldn't figure out what was wrong the other night 20:51 * nb hopes to look at it some today 20:51 -!- rishi [n=rishi at gnu-india/supporter/debarshi] has quit Read error: 110 (Connection timed out) 20:51 < mmcgrath> nb: excellent. thanks for the roundup. 20:51 < mmcgrath> Anyone have anything else? 20:51 < nb> its /usr/share/wordpress-mu/wp-content/mu-plugins/fasauth.php if anyone knows much about php and fas 20:51 < nb> on publictest15 20:51 -!- nim-nim [n=nim-nim at fedora/nim-nim] has joined #fedora-meeting 20:52 < mmcgrath> nb: might be good to hit up the f-i-l 20:52 < nb> good idea 20:52 < mmcgrath> Ok, if no one has anything else we'll close the meeting in 30 20:52 < tmz> something fairly minor, we occassionally get folks having permission problems with git repos on hosted. 20:52 < abadger1999> nb: I looked briefly the other day -- couldn't figure out which methods it was calling when it verified the password though. 20:53 < ssmoogen> my only statement is that I am still catching up and hopefully will be promoted to ricky's assistant soon 20:53 < mmcgrath> tmz: what was the latest? 20:53 < tmz> I think I've found and fixed the last of the current problems causing those. but to ensure they don't come back, I think a cron job to check for a few common problems might be good. 20:53 < mmcgrath> ssmoogen: :) 20:53 < tmz> mmcgrath: the latest one was docs/install-guide and docs/release-notes. 20:54 < tmz> both lacked the core.sharerepository setting. 20:54 < mmcgrath> were they created incorrectly? 20:54 < tmz> and that cause the reflogs to have the wrong perms. 20:54 < mmcgrath> 20:54 < tmz> I'm guessing they were creating without either --shared option to git init, or cloned and then the sharerepository option never set. 20:55 < tmz> the setup scripts should keep this from happening on new repos. 20:55 < mmcgrath> 20:56 < mmcgrath> Ok, things are quiet :) 20:56 < mmcgrath> tmz: thanks for that. 20:56 < mmcgrath> if no one has anything else I'll close in 30 20:56 < mmcgrath> 10 20:56 < mmcgrath> #endmeeting 20:56 -!- zodbot 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/Meeting_channel for meeting schedule 20:56 < zodbot> Meeting ended Thu Jul 9 20:56:53 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:57 < zodbot> Minutes: http://tinyurl.com/ng4xmx 20:57 < mmcgrath> Thanks everyone! 20:57 < zodbot> Minutes (text): http://tinyurl.com/nhtce2 20:57 < zodbot> Log: http://tinyurl.com/lc8v5k -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From johe.stephan at googlemail.com Fri Jul 10 07:38:58 2009 From: johe.stephan at googlemail.com (=?ISO-8859-1?Q?J=F6rg_Stephan?=) Date: Fri, 10 Jul 2009 09:38:58 +0200 Subject: Why not Proxy with Nginx ? Message-ID: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> Hi there, on the meeting yesterday i've heared from the proxy problems with apache + mod_proxy so i just wanne tell a bit from an other proxy which i set up a few weeks ago in firm. So talking about Nginx. In the firm i work we had problems with the many different URLs behind the old proxy and we come to an state were apache has been to slow. One of the main points why i looked for a different Software was the IP-Forward Problem we always had. So i found Nginx. Nginx is a very fast proxy http://wiki.nginx.org/Main and it comes with many modules to handle the connection. On the other hand it is very easy to use. So, take a short look: proxy_redirect off; proxy_set_header X-Real-IP $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffers 32 4k; this does all the IP-Forwarding and the (in this case webdav) is the configuration of the server server { listen 80; server_name isg-dav1.XX.XXXXX.de; access_log /var/log/nginx/localhost.access.log; error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/nginx-default; } location / { proxy_pass http://isg-dav.XXXX.XXXXX.de; include /etc/nginx/proxy.conf; } } So if any question, i try to answer them, Greets Joerg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Fri Jul 10 11:35:57 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 10 Jul 2009 06:35:57 -0500 (CDT) Subject: Why not Proxy with Nginx ? In-Reply-To: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> References: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> Message-ID: On Fri, 10 Jul 2009, J?rg Stephan wrote: > Hi there, > > on the meeting yesterday i've heared from the proxy problems with apache + mod_proxy so i just wanne tell a bit from an > other proxy which i set up a few weeks ago in firm. So talking about Nginx. In the firm i work we had problems with the > many different URLs behind the old proxy and we come to an state were apache has been to slow. One of the main points why > i looked for a different Software was the IP-Forward Problem we always had. > So i found Nginx. Nginx is a very fast proxy http://wiki.nginx.org/Main and it comes with many modules to handle the > connection. On the other hand it is very easy to use. > > So, take a short look: > > proxy_redirect????????? off; > proxy_set_header??????? X-Real-IP?????? $host; > proxy_set_header??????? X-Forwarded-For $proxy_add_x_forwarded_for; > client_max_body_size??? 10m; > client_body_buffer_size 128k; > proxy_connect_timeout?? 90; > proxy_send_timeout????? 90; > proxy_read_timeout????? 90; > proxy_buffers?????????? 32 4k; > > this does all the IP-Forwarding > > and the (in this case webdav) is the configuration of the server > > server { > ??????? listen?? 80; > ??????? server_name? isg-dav1.XX.XXXXX.de; > ??????? access_log? /var/log/nginx/localhost.access.log; > ??????? error_page?? 500 502 503 504? /50x.html; > ??????? location = /50x.html { > ??????????????? root?? /var/www/nginx-default; > ??????? } > ??????? location / { > ??????????????? proxy_pass??????? http://isg-dav.XXXX.XXXXX.de; > ??????????????? include /etc/nginx/proxy.conf; > ??????? } > } > > So if any question, i try to answer them, > Stuff like this comes up from time to time and the question I always have is: What is it we're wanting to do that we can't currently do with the setup we have now? We're a group with a lot of turnover and almost everyone knows how to use apache so why is it worth it to us to switch to nginx? -Mike From johe.stephan at googlemail.com Fri Jul 10 11:52:51 2009 From: johe.stephan at googlemail.com (=?ISO-8859-1?Q?J=F6rg_Stephan?=) Date: Fri, 10 Jul 2009 13:52:51 +0200 Subject: Why not Proxy with Nginx ? In-Reply-To: References: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> Message-ID: <644549460907100452q9237b46x770ccd3b0b9ec65a@mail.gmail.com> Well, maybe there isnt any reason to change. You are right, everybody knows apache, and as long as apache works fine there is definitely no reason, but as we were running into proxy problems i thought it wo be the right time to show up an alternative to the apache proxy. If you take a look at the modules page http://wiki.nginx.org/NginxModulesyou just see all nginx can do. Apache is first of all an http server which can do reverse proxy. Nginx is first of all an proxy. I just wanted to show an alternative, thats all. Greetz Joerg -------------- next part -------------- An HTML attachment was scrubbed... URL: From johe.stephan at googlemail.com Fri Jul 10 12:00:07 2009 From: johe.stephan at googlemail.com (=?ISO-8859-1?Q?J=F6rg_Stephan?=) Date: Fri, 10 Jul 2009 14:00:07 +0200 Subject: Why not Proxy with Nginx ? In-Reply-To: <644549460907100452q9237b46x770ccd3b0b9ec65a@mail.gmail.com> References: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> <644549460907100452q9237b46x770ccd3b0b9ec65a@mail.gmail.com> Message-ID: <644549460907100500p6145d4c9g8ea5182724935bef@mail.gmail.com> http://www.linuxjournal.com/article/10108 just to point to 2009/7/10 J?rg Stephan > > > Well, > maybe there isnt any reason to change. You are right, everybody knows > apache, and as long as apache works fine there is definitely no reason, but > as we were running into proxy problems i thought it wo be the right time to > show up an alternative to the apache proxy. > If you take a look at the modules page http://wiki.nginx.org/NginxModulesyou just see all nginx can do. Apache is first of all an http server which > can do reverse proxy. Nginx is first of all an proxy. > > I just wanted to show an alternative, thats all. > > Greetz Joerg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmacken at redhat.com Fri Jul 10 13:40:22 2009 From: lmacken at redhat.com (Luke Macken) Date: Fri, 10 Jul 2009 09:40:22 -0400 Subject: Why not Proxy with Nginx ? In-Reply-To: References: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> Message-ID: <20090710134022.GA3113@x300> On Fri, Jul 10, 2009 at 06:35:57AM -0500, Mike McGrath wrote: > Stuff like this comes up from time to time and the question I always have > is: What is it we're wanting to do that we can't currently do with the > setup we have now? We're a group with a lot of turnover and almost > everyone knows how to use apache so why is it worth it to us to switch to > nginx? If we are wanting "to serve static files faster", then yes, Nginx would do that for us[0]. I use Nginx for all of my personal application deployments, and I've been extremely impressed with it's speed and ease of configuration. However, it's WSGI support is a bit questionable, so we would only want to use it as for serving static files & reverse proxying. You can also configure it to hit memcached before apache, which is pretty neat. Mike is right though, if it's not solving an real problems for us, we're better off using what we are already familiar with until we see an obviously need for it. luke [0]: http://blog.webfaction.com/a-little-holiday-present From mmcgrath at redhat.com Fri Jul 10 13:56:07 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 10 Jul 2009 08:56:07 -0500 (CDT) Subject: Why not Proxy with Nginx ? In-Reply-To: <20090710134022.GA3113@x300> References: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> <20090710134022.GA3113@x300> Message-ID: On Fri, 10 Jul 2009, Luke Macken wrote: > On Fri, Jul 10, 2009 at 06:35:57AM -0500, Mike McGrath wrote: > > Stuff like this comes up from time to time and the question I always have > > is: What is it we're wanting to do that we can't currently do with the > > setup we have now? We're a group with a lot of turnover and almost > > everyone knows how to use apache so why is it worth it to us to switch to > > nginx? > > If we are wanting "to serve static files faster", then yes, Nginx would > do that for us[0]. I use Nginx for all of my personal application > deployments, and I've been extremely impressed with it's speed and ease > of configuration. However, it's WSGI support is a bit questionable, so > we would only want to use it as for serving static files & reverse > proxying. You can also configure it to hit memcached before apache, > which is pretty neat. > That is interesting though, does it just store entire html pages in memcached? -Mike From lmacken at redhat.com Fri Jul 10 14:10:15 2009 From: lmacken at redhat.com (Luke Macken) Date: Fri, 10 Jul 2009 10:10:15 -0400 Subject: Why not Proxy with Nginx ? In-Reply-To: References: <644549460907100038h1b684ad9m8f54232bf56d065b@mail.gmail.com> <20090710134022.GA3113@x300> Message-ID: <20090710141015.GB3113@x300> On Fri, Jul 10, 2009 at 08:56:07AM -0500, Mike McGrath wrote: > On Fri, 10 Jul 2009, Luke Macken wrote: > > > On Fri, Jul 10, 2009 at 06:35:57AM -0500, Mike McGrath wrote: > > > Stuff like this comes up from time to time and the question I always have > > > is: What is it we're wanting to do that we can't currently do with the > > > setup we have now? We're a group with a lot of turnover and almost > > > everyone knows how to use apache so why is it worth it to us to switch to > > > nginx? > > > > If we are wanting "to serve static files faster", then yes, Nginx would > > do that for us[0]. I use Nginx for all of my personal application > > deployments, and I've been extremely impressed with it's speed and ease > > of configuration. However, it's WSGI support is a bit questionable, so > > we would only want to use it as for serving static files & reverse > > proxying. You can also configure it to hit memcached before apache, > > which is pretty neat. > > > > That is interesting though, does it just store entire html pages in > memcached? As far as I know nginx doesn't store things in memcached itself, but in your web application you can do fancy things like cache fully rendered HTML pages in memcached, and you can tell nginx to look there first. This article, "Pylons on Nginx with Memcached and SSI", is what inspired me to dive into this stuff a while back: http://www.reshetseret.com/app/blog/?p=3 They use a simple decorator to do the caching. However, this won't work out of the box with TurboGears2 since there is a piece of ToscaWidgets middleware that injects the widget resources at the last minute -- so your cache would be missing a ton of JS and CSS files. However, I've been thinking about having Moksha inject a piece of middleware at the top of the stack to optionally throw the rendered output in memcached. Anyway... fun stuff :) luke From lmacken at redhat.com Fri Jul 10 18:41:44 2009 From: lmacken at redhat.com (Luke Macken) Date: Fri, 10 Jul 2009 14:41:44 -0400 Subject: bodhi 0.6.0 with EPEL support In-Reply-To: <20090704032535.GD8337@x300.pdf.local> References: <20090704032535.GD8337@x300.pdf.local> Message-ID: <20090710184144.GE3113@x300> Oh yeah, I also updated our Bodhi SOP with some details on how to push updates for EPEL. https://fedoraproject.org/wiki/Bodhi_Infrastructure_SOP On Fri, Jul 03, 2009 at 11:25:35PM -0400, Luke Macken wrote: > Hey all, > > I just deployed bodhi 0.6.0 to app1-6 and releng{2,1.stg}. This release > contains patches from both Dennis Gilmore and myself to support pushing > updates for EPEL. > > I just submitted my first EPEL update into bodhi, so things seem to be > working properly so far. It should be safe to start queueing EPEL > updates, and we'll try doing a small push early next week. > > Please file bugs here: https://fedorahosted.org/bodhi/newticket > > Thanks, > > luke > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Fri Jul 10 21:22:42 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 10 Jul 2009 16:22:42 -0500 (CDT) Subject: Outage Notification - 2009-07-10 22:00 UTC and 2009-07-15 20:00 UTC Message-ID: There will be two outages coming up. The first starting at 2009-07-10 22:00 UTC lasting for around 50-60 hours. The second outage starting at 2009-07-15 20:00 UTC and lasting up to 10 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-10 22:00 UTC' date -d '2009-07-15 20:00 UTC' Affected Services: Unaffected Services: Buildsystem CVS / Source Control Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Reason for Outage: RDU netapp syncing and tray installation. This isn't getting wide distribution because based on the settings in place today, it won't impact us. Our i2 mirror (of which this is part of it) is offline from other issues anyway and being worked on. More then anything this is a heads up. Soon our primary mirror system will go from 1T to upwards of 8T of usable storage. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From mmcgrath at redhat.com Fri Jul 10 22:44:43 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 10 Jul 2009 17:44:43 -0500 (CDT) Subject: New rule Message-ID: I'm going to document this somewhere, we talked about it on IRC a while back but I never sent an email to the list. Hot patching servers is bad! Don't do it! But if you _must_ do it for whatever reason, you _MUST_ open a ticket about it and leave it open until the hot patch is removed: https://fedorahosted.org/fedora-infrastructure/ticket/1524 -Mike From kanarip at kanarip.com Fri Jul 10 23:06:29 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 11 Jul 2009 01:06:29 +0200 Subject: New rule Message-ID: +1, hot fixing is bad. We usually call them emergency changes though, in terms of ITIL Service Management; point is, regardless, *they are still changes*, no matter how big, small, insignificant or obvious. Without the actual change being logged, either before or after the actual change, there is *no* way to follow up on it. You can imagine what the consequences could be.... -- Jeroen @ android Mike McGrath wrote: >I'm going to document this somewhere, we talked about it on IRC a while >back but I never sent an email to the list. > >Hot patching servers is bad! Don't do it! But if you _must_ do it for >whatever reason, you _MUST_ open a ticket about it and leave it open until >the hot patch is removed: > >https://fedorahosted.org/fedora-infrastructure/ticket/1524 > > -Mike > >_______________________________________________ >Fedora-infrastructure-list mailing list >Fedora-infrastructure-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From nigjones at redhat.com Fri Jul 10 23:19:01 2009 From: nigjones at redhat.com (Nigel Jones) Date: Fri, 10 Jul 2009 19:19:01 -0400 (EDT) Subject: New rule In-Reply-To: Message-ID: <29637158.1461247268000090.JavaMail.nigjones@njones.bne.redhat.com> I've been saying this for ages, but YES! I agree 150% :) ----- "Mike McGrath" wrote: > I'm going to document this somewhere, we talked about it on IRC a > while > back but I never sent an email to the list. > > Hot patching servers is bad! Don't do it! But if you _must_ do it > for > whatever reason, you _MUST_ open a ticket about it and leave it open > until > the hot patch is removed: > > https://fedorahosted.org/fedora-infrastructure/ticket/1524 > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From skvidal at fedoraproject.org Fri Jul 10 23:25:55 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 10 Jul 2009 19:25:55 -0400 (EDT) Subject: New rule In-Reply-To: References: Message-ID: On Fri, 10 Jul 2009, Mike McGrath wrote: > I'm going to document this somewhere, we talked about it on IRC a while > back but I never sent an email to the list. > > Hot patching servers is bad! Don't do it! But if you _must_ do it for > whatever reason, you _MUST_ open a ticket about it and leave it open until > the hot patch is removed: > > https://fedorahosted.org/fedora-infrastructure/ticket/1524 > what got broken? and do you mean hot-patches like apps or hot patches like: yum update httpd ? -sv From a.badger at gmail.com Fri Jul 10 23:48:35 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 10 Jul 2009 16:48:35 -0700 Subject: New rule In-Reply-To: References: Message-ID: <4A57D353.1070902@gmail.com> On 07/10/2009 03:44 PM, Mike McGrath wrote: > I'm going to document this somewhere, we talked about it on IRC a while > back but I never sent an email to the list. > > Hot patching servers is bad! Don't do it! But if you _must_ do it for > whatever reason, you _MUST_ open a ticket about it and leave it open until > the hot patch is removed: > > https://fedorahosted.org/fedora-infrastructure/ticket/1524 > We should have a keyword or a component to make searching easier as well. For now I've added Hotfix to the keywords for that bug but if people forget to use that we can use a component or something else. -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 Jul 10 23:52:28 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 10 Jul 2009 18:52:28 -0500 (CDT) Subject: New rule In-Reply-To: References: Message-ID: On Fri, 10 Jul 2009, Seth Vidal wrote: > > > On Fri, 10 Jul 2009, Mike McGrath wrote: > > > I'm going to document this somewhere, we talked about it on IRC a while > > back but I never sent an email to the list. > > > > Hot patching servers is bad! Don't do it! But if you _must_ do it for > > whatever reason, you _MUST_ open a ticket about it and leave it open until > > the hot patch is removed: > > > > https://fedorahosted.org/fedora-infrastructure/ticket/1524 > > > > what got broken? and do you mean hot-patches like apps or hot patches like: > yum update httpd ? > I'm talking specifically about altering code because outside of a normal rpm/puppet deployment. So this would exclude configs and things puppet normally deploys. But if you run into a bug in some code and it needs to get fixed, go in, fix it, contact upstream and open a bug so we all know about it. We've done this in the past for security reasons (git web and the recent nagios bug comes to mind) and for general usability problems or outages. -Mike From opensource at till.name Sun Jul 12 20:23:24 2009 From: opensource at till.name (Till Maas) Date: Sun, 12 Jul 2009 22:23:24 +0200 Subject: Bugzilla bot account / Fedora mail alias Message-ID: <200907122223.32248.opensource@till.name> Hiyas, I will eventually want to use a bugzilla account for a certain service[0]. To make it easier for someone else to reclaim this account in case i vanish, I would like to use a Fedora mail alias for this. Is there some type of bot account type in FAS that I can use to create the additional mail alias or some other procedure for this? Regards Till [0] https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From smooge at gmail.com Sun Jul 12 20:38:48 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 12 Jul 2009 14:38:48 -0600 Subject: Fedora Planet Spam Message-ID: <80d7e4090907121338t7b3b032ha94c49e69db5647d@mail.gmail.com> I am wondering if someone's blog got hacked.. or if we need to go over best use policies with people soon. http://uditsharma.in/?p=48 -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From frankc.fedora at gmail.com Sun Jul 12 22:04:33 2009 From: frankc.fedora at gmail.com (Frank Chiulli) Date: Sun, 12 Jul 2009 15:04:33 -0700 Subject: exim: SELinux Message-ID: This is a recently installed/patched F11 system. It was a fresh install to one disk leaving my home directory untouched on another disk. Today, I installed exim and removed sendmail via yum at the command line. I am using the same exim.conf file that I had used with F10 after having compared it to the original one. I am now receiving the following message when I attempt to retrieve mail from my ISP: Jul 12 14:26:36 flinux setroubleshoot: SELinux is preventing exim (exim_t) "getattr" boot_t. For complete SELinux messages. run sealert -l e699bb55-c0dc-4bbf-a57e-3d82d6dadcad sealert -l e699bb55-c0dc-4bbf-a57e-3d82d6dadcad Summary: SELinux is preventing exim (exim_t) "getattr" boot_t. Detailed Description: SELinux denied access requested by exim. It is not expected that this access is required by exim and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:system_r:exim_t:s0 Target Context system_u:object_r:boot_t:s0 Target Objects /boot [ dir ] Source exim Source Path /usr/sbin/exim Port Host flinux Source RPM Packages exim-4.69-10.fc11 Target RPM Packages filesystem-2.4.21-1.fc11 Policy RPM selinux-policy-3.6.12-62.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name flinux Platform Linux flinux 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun 16 23:19:53 EDT 2009 i686 athlon Alert Count 289 First Seen Sun Jul 12 14:22:12 2009 Last Seen Sun Jul 12 14:23:53 2009 Local ID e699bb55-c0dc-4bbf-a57e-3d82d6dadcad Line Numbers Raw Audit Messages node=flinux type=AVC msg=audit(1247433833.210:331): avc: denied { getattr } for pid=2508 comm="exim" path="/boot" dev=sda1 ino=2 scontext=unconfined_u:system_r:exim_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=dir node=flinux type=SYSCALL msg=audit(1247433833.210:331): arch=40000003 syscall=195 success=no exit=-13 a0=bfa2e2c2 a1=bfa2e6b8 a2=b7dbfff4 a3=0 items=0 ppid=2447 pid=2508 auid=500 uid=93 gid=93 euid=93 suid=93 fsuid=93 egid=93 sgid=93 fsgid=93 tty=(none) ses=1 comm="exim" exe="/usr/sbin/exim" subj=unconfined_u:system_r:exim_t:s0 key=(null) Any thoughts/suggestions? Thanks, Frank From spurath at students.uni-mainz.de Sun Jul 12 22:20:10 2009 From: spurath at students.uni-mainz.de (Thomas Spura) Date: Mon, 13 Jul 2009 00:20:10 +0200 Subject: exim: SELinux In-Reply-To: References: Message-ID: <1247437210.2554.7.camel@localhost.localdomain> Am Montag, den 13.07.2009, 00:04 +0200 schrieb Frank Chiulli: > SELinux is preventing exim (exim_t) "getattr" boot_t. > > Detailed Description: > > SELinux denied access requested by exim. It is not expected that this access is > required by exim and this access may signal an intrusion attempt. It is also > possible that the specific version or configuration of the application is > causing it to require additional access. > Any thoughts/suggestions? I once had a similar issue, try: touch /.autorelabel && reboot -Thomas From frankc.fedora at gmail.com Mon Jul 13 00:11:08 2009 From: frankc.fedora at gmail.com (Frank Chiulli) Date: Sun, 12 Jul 2009 17:11:08 -0700 Subject: exim: SELinux In-Reply-To: <1247437210.2554.7.camel@localhost.localdomain> References: <1247437210.2554.7.camel@localhost.localdomain> Message-ID: Thomas, Thanks for the suggestion. Unfortunately it did not work. I'm still getting the same error. Frank On Sun, Jul 12, 2009 at 3:20 PM, Thomas Spura wrote: > Am Montag, den 13.07.2009, 00:04 +0200 schrieb Frank Chiulli: >> SELinux is preventing exim (exim_t) "getattr" boot_t. >> >> Detailed Description: >> >> SELinux denied access requested by exim. It is not expected that this access is >> required by exim and this access may signal an intrusion attempt. It is also >> possible that the specific version or configuration of the application is >> causing it to require additional access. >> Any thoughts/suggestions? > > I once had a similar issue, try: > > touch /.autorelabel && reboot > > ? ? ? ?-Thomas > > From skvidal at fedoraproject.org Mon Jul 13 02:12:41 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 12 Jul 2009 22:12:41 -0400 (EDT) Subject: Fedora Planet Spam In-Reply-To: <80d7e4090907121338t7b3b032ha94c49e69db5647d@mail.gmail.com> References: <80d7e4090907121338t7b3b032ha94c49e69db5647d@mail.gmail.com> Message-ID: On Sun, 12 Jul 2009, Stephen John Smoogen wrote: > I am wondering if someone's blog got hacked.. or if we need to go over > best use policies with people soon. > > http://uditsharma.in/?p=48 > you can ban people from the planet by modifying the /etc/planet/fpbuilder.conf and adding their username to the ignore_users list -sv From didar.hossain at gmail.com Mon Jul 13 09:14:22 2009 From: didar.hossain at gmail.com (Didar Hossain) Date: Mon, 13 Jul 2009 14:44:22 +0530 Subject: exim: SELinux In-Reply-To: References: <1247437210.2554.7.camel@localhost.localdomain> Message-ID: <62d32bf20907130214r6977870bt7fdf9f3a719c9c9@mail.gmail.com> On Mon, Jul 13, 2009 at 5:41 AM, Frank Chiulli wrote: > Thomas, > Thanks for the suggestion. ?Unfortunately it did not work. ?I'm still > getting the same error. > > Frank Is Exim not executing it's job as it is supposed to - as in delivery of mail is hampered by this error? I am no SELinux or Exim expert, but, AFAIK the "/boot" directory is not supposed to be related to the regular functioning of Exim. Didar From frankc.fedora at gmail.com Mon Jul 13 12:17:05 2009 From: frankc.fedora at gmail.com (Frank Chiulli) Date: Mon, 13 Jul 2009 05:17:05 -0700 Subject: exim: SELinux In-Reply-To: <62d32bf20907130214r6977870bt7fdf9f3a719c9c9@mail.gmail.com> References: <1247437210.2554.7.camel@localhost.localdomain> <62d32bf20907130214r6977870bt7fdf9f3a719c9c9@mail.gmail.com> Message-ID: Didar, Mail is arriving. I just get one SELinux message for every mail message. I agree...exim should not be referencing /boot AFAIK. But I'm not an expert. Frank On Mon, Jul 13, 2009 at 2:14 AM, Didar Hossain wrote: > On Mon, Jul 13, 2009 at 5:41 AM, Frank Chiulli wrote: >> Thomas, >> Thanks for the suggestion. ?Unfortunately it did not work. ?I'm still >> getting the same error. >> >> Frank > > Is Exim not executing it's job as it is supposed to - as in delivery > of mail is hampered by this error? > > I am no SELinux or Exim expert, but, AFAIK the "/boot" directory is > not supposed to be related to the regular functioning of Exim. > > Didar > From me at davidjmemmett.co.uk Mon Jul 13 12:22:03 2009 From: me at davidjmemmett.co.uk (David JM Emmett) Date: Mon, 13 Jul 2009 13:22:03 +0100 Subject: exim: SELinux In-Reply-To: References: <1247437210.2554.7.camel@localhost.localdomain> <62d32bf20907130214r6977870bt7fdf9f3a719c9c9@mail.gmail.com> Message-ID: <1247487723.8571.80.camel@can11.canstudiosltd.thecan> Don't mean to be completely rude but doesn't this belong on a support forum? On Mon, 2009-07-13 at 05:17 -0700, Frank Chiulli wrote: > Didar, > Mail is arriving. I just get one SELinux message for every mail message. > > I agree...exim should not be referencing /boot AFAIK. But I'm not an expert. > > Frank > > On Mon, Jul 13, 2009 at 2:14 AM, Didar Hossain wrote: > > On Mon, Jul 13, 2009 at 5:41 AM, Frank Chiulli wrote: > >> Thomas, > >> Thanks for the suggestion. Unfortunately it did not work. I'm still > >> getting the same error. > >> > >> Frank > > > > Is Exim not executing it's job as it is supposed to - as in delivery > > of mail is hampered by this error? > > > > I am no SELinux or Exim expert, but, AFAIK the "/boot" directory is > > not supposed to be related to the regular functioning of Exim. > > > > Didar > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From nigel.metheringham at dev.intechnology.co.uk Mon Jul 13 13:06:03 2009 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 13 Jul 2009 14:06:03 +0100 Subject: exim: SELinux In-Reply-To: References: <1247437210.2554.7.camel@localhost.localdomain> <62d32bf20907130214r6977870bt7fdf9f3a719c9c9@mail.gmail.com> Message-ID: <6789D2EA-A556-4199-A25E-6A51695495C8@dev.intechnology.co.uk> On 13 Jul 2009, at 13:17, Frank Chiulli wrote: > Mail is arriving. I just get one SELinux message for every mail > message. > > I agree...exim should not be referencing /boot AFAIK. But I'm not > an expert. Without having seen the config I can only make wild guesses... However the wild guess I would make is that exim is doing a check for available space in the spool and log directories, and this is triggering the SELinux check on the statvfs() call. It is a wild guess though :-) Can you make sure that there are no references to boot in the config files Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] From ian at ianweller.org Mon Jul 13 17:07:13 2009 From: ian at ianweller.org (Ian Weller) Date: Mon, 13 Jul 2009 12:07:13 -0500 Subject: marketing needs some input on a news platform Message-ID: <20090713170713.GI9645@deathray.ianweller.org> https://fedoraproject.org/wiki/FooBar#Platform_options What does Infrastructure think? We're currently leaning between using WordPress and piggybacking on Zikula. -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nb at fedoraproject.org Tue Jul 14 02:53:33 2009 From: nb at fedoraproject.org (Nick Bebout) Date: Mon, 13 Jul 2009 21:53:33 -0500 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <200907122223.32248.opensource@till.name> References: <200907122223.32248.opensource@till.name> Message-ID: <4A5BF32D.8010400@fedoraproject.org> What would you like the alias to be, and where would you like the email to go to? Nick nb at fedoraproject.org On 07/12/2009 03:23 PM, Till Maas wrote: > Hiyas, > > I will eventually want to use a bugzilla account for a certain service[0]. To > make it easier for someone else to reclaim this account in case i vanish, I > would like to use a Fedora mail alias for this. > > Is there some type of bot account type in FAS that I can use to create the > additional mail alias or some other procedure for this? > > Regards > Till > > [0] https://fedoraproject.org/wiki/Using_FEver_to_track_upstream_changes > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 njbhatt18 at gmail.com Tue Jul 14 03:12:00 2009 From: njbhatt18 at gmail.com (Bhatt Niraj) Date: Tue, 14 Jul 2009 08:42:00 +0530 Subject: about me and my experience Message-ID: <8426c1370907132012s2f7617dft7abaefe09c7f1a0b@mail.gmail.com> Hi everyone, My self Niraj Bhatt, recently I joined fedora community. I completed master in computer science then RHCE and now preparing for RHCSS. I am working as Unix Administrator in Tata Consultancy Services (TCS). Right now I am handling 900+ servers. I have sound knowledge of apache, mysql, php, clustering, Load Balancer (BIG IP), LDAP and performance tunning. I want to becomes the part of fedora development so I joined this community. I am managing www.vglug.info (Linux User Group) web site. To promote open source I am taking seminar in colleges. -- Niraj Bhatt ------------------------------------------------------------ Give me space to stand, i will move the earth -------------- next part -------------- An HTML attachment was scrubbed... URL: From didar.hossain at gmail.com Tue Jul 14 06:30:50 2009 From: didar.hossain at gmail.com (Didar Hossain) Date: Tue, 14 Jul 2009 12:00:50 +0530 Subject: exim: SELinux In-Reply-To: <1247487723.8571.80.camel@can11.canstudiosltd.thecan> References: <1247437210.2554.7.camel@localhost.localdomain> <62d32bf20907130214r6977870bt7fdf9f3a719c9c9@mail.gmail.com> <1247487723.8571.80.camel@can11.canstudiosltd.thecan> Message-ID: <62d32bf20907132330m782640c3q8ef20c512dbf0a73@mail.gmail.com> On Mon, Jul 13, 2009 at 5:52 PM, David JM Emmett wrote: > Don't mean to be completely rude but doesn't this belong on a support > forum? Agree, this does not seem to be related to a system managed by the Infra team. The "fedora-list" is the appropriate mailing list for this thread. Didar From mmcgrath at redhat.com Tue Jul 14 13:30:55 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 14 Jul 2009 08:30:55 -0500 (CDT) Subject: marketing needs some input on a news platform In-Reply-To: <20090713170713.GI9645@deathray.ianweller.org> References: <20090713170713.GI9645@deathray.ianweller.org> Message-ID: On Mon, 13 Jul 2009, Ian Weller wrote: > https://fedoraproject.org/wiki/FooBar#Platform_options > > What does Infrastructure think? We're currently leaning between using > WordPress and piggybacking on Zikula. > Disclaimer: I've not actually used WordPress or Zikula to do anything other then testing so below are very quick opinions: If you're going for a more professional news site I'd think Zikula is what you're looking for. It'll have some workflow built in to it. We're already in pretty good with the Zikula developers, they seem to care about what we're up to so that's a plus and you guys will probably functionally be doing things similar to what the docs team is doing (in terms of typing, someone editing, someone publishing, etc) so we'll have some joint knowledge there. -Mike From mmcgrath at redhat.com Tue Jul 14 16:53:59 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 14 Jul 2009 11:53:59 -0500 (CDT) Subject: about me and my experience In-Reply-To: <8426c1370907132012s2f7617dft7abaefe09c7f1a0b@mail.gmail.com> References: <8426c1370907132012s2f7617dft7abaefe09c7f1a0b@mail.gmail.com> Message-ID: On Tue, 14 Jul 2009, Bhatt Niraj wrote: > Hi everyone, > ? > My self Niraj Bhatt, recently I joined fedora community. I completed master in computer science then RHCE and now > preparing for RHCSS. I am working as Unix Administrator in Tata Consultancy Services (TCS). > ? > Right now I am handling 900+ servers. I have sound knowledge of apache, mysql, php, clustering, Load Balancer (BIG IP), > LDAP and performance tunning. > I want to becomes the part of fedora development so I joined this community. I am managing www.vglug.info (Linux User > Group) web site. To promote open source I am taking seminar in colleges. > Hello Niraj, welcome to the group. Was there anything in particular you were interested in working on? -Mike From njbhatt18 at gmail.com Tue Jul 14 18:50:09 2009 From: njbhatt18 at gmail.com (Bhatt Niraj) Date: Tue, 14 Jul 2009 20:50:09 +0200 Subject: about me and my experience In-Reply-To: References: <8426c1370907132012s2f7617dft7abaefe09c7f1a0b@mail.gmail.com> Message-ID: <8426c1370907141150l6ad20246pd857a7a3ff217600@mail.gmail.com> Hi Mike, First of all thank you very much for allow me to work in fedora community. I would like to work in apache, mysql, and performance tunning. Regards, Niraj Bhatt 2009/7/14 Mike McGrath > On Tue, 14 Jul 2009, Bhatt Niraj wrote: > > > Hi everyone, > > > > My self Niraj Bhatt, recently I joined fedora community. I completed > master in computer science then RHCE and now > > preparing for RHCSS. I am working as Unix Administrator in Tata > Consultancy Services (TCS). > > > > Right now I am handling 900+ servers. I have sound knowledge of apache, > mysql, php, clustering, Load Balancer (BIG IP), > > LDAP and performance tunning. > > I want to becomes the part of fedora development so I joined this > community. I am managing www.vglug.info (Linux User > > Group) web site. To promote open source I am taking seminar in colleges. > > > > Hello Niraj, welcome to the group. Was there anything in particular you > were interested in working on? > > -Mike > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -- Niraj Bhatt ------------------------------------------------------------ Give me space to stand, i will move the earth -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Tue Jul 14 21:08:31 2009 From: opensource at till.name (Till Maas) Date: Tue, 14 Jul 2009 23:08:31 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <4A5BF32D.8010400@fedoraproject.org> References: <200907122223.32248.opensource@till.name> <4A5BF32D.8010400@fedoraproject.org> Message-ID: <200907142308.33208.opensource@till.name> Hiyas, On Tue July 14 2009, Nick Bebout wrote: > What would you like the alias to be, and where would you like the email > to go to? How about the alias "upstream-release-monitoring"? Please forward it to "cnucnu.fedora till name" with '@' and '.' added. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jonstanley at gmail.com Tue Jul 14 21:52:47 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 14 Jul 2009 17:52:47 -0400 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <200907142308.33208.opensource@till.name> References: <200907122223.32248.opensource@till.name> <4A5BF32D.8010400@fedoraproject.org> <200907142308.33208.opensource@till.name> Message-ID: On Tue, Jul 14, 2009 at 5:08 PM, Till Maas wrote: > How about the alias "upstream-release-monitoring"? Please forward it to > "cnucnu.fedora till name" with '@' and '.' added. I'd personally prefer to make a mailing list for this, rather than put the point of failure on a single person (again). Also, have you filed an RFR to get this hosted in Fedora? From mmcgrath at redhat.com Wed Jul 15 03:44:15 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 14 Jul 2009 22:44:15 -0500 (CDT) Subject: ASU Message-ID: anyone know anyone at ASU? -Mike From davivercillo at gmail.com Wed Jul 15 04:41:52 2009 From: davivercillo at gmail.com (Davi Vercillo C. Garcia) Date: Wed, 15 Jul 2009 01:41:52 -0300 Subject: About me Message-ID: Hi everybody, My name is Davi Vercillo C. Garcia and I'm from Brazil, Rio de Janeiro - RJ. I'm 22 years old and I'm a undergraduate student of Computer Science at Federal University of Rio de Janeiro. I always had interesting on computers and networking, specially GNU/Linux. I've used GNU/Linux at my workstations, desktops, notebooks and servers (off course) since 2001. I started with Slackware and, after it, Debian, Fedora, RHEL, Mandriva, CentOS, etc. Today, I'm using Fedora 11 (Workstation/Desktop) and RHEL5 (Servers). I have some basic/intermediate experience with networking, clustering, system administration and programming (C, Java and Python - my favourite option). At this moment, I'm trainee on sysadmin at a hpc lab at my university, called (NACAD) and I'm monitor of basic programming call for Engineering courses at my university. I would like to help Fedora community grow and keep moving... (Johnny Walker ? =P) PS: My English is not perfect,so please, ignore some mistakes, if it happens. Thanks, -- Davi Vercillo Carneiro Garcia http://www.google.com/profiles/davivercillo Federal University of Rio de Janeiro Department of Computer Science DCC-IM/UFRJ - http://www.dcc.ufrj.br /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ From snaevar at gmail.com Wed Jul 15 07:12:55 2009 From: snaevar at gmail.com (=?UTF-8?B?SGrDtnJsZWlmdXIgSsOzbnNzb24=?=) Date: Wed, 15 Jul 2009 09:12:55 +0200 Subject: Greetings Message-ID: <3362cef90907150012u6c226b9bn11e080cdde188398@mail.gmail.com> Hi My name is Hjorleifur I am a 30 year old sysadmin and an avid Linux user from Iceland currently living in Sweden. I have been using Redhat/RHEL/FEDORA since Cartman(6.1) and probably every release since. As well as other Linux Distros, NetBSD,FreeBSD etc. I have experience in running production environment's for financial institutions. Past roles I have held are Software developer (c++,vb,vb.net) on windows ;). DBA Team Leader (Oracle and SQL Server),Infrastructure Team Leader running VMware VI3 clusters, Linux, Windows, Hpux servers and various application servers on thees platforms. And recently I have been experimenting with Opensolaris. The fields/technology's that interest me most are Cloud computing , clusters hpc(though I do have not much experience there) and fail over, load balance and virtualization. I am interested in helping Fedora move forward and if can help that would great. With regards Hjorleifur -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Wed Jul 15 07:39:27 2009 From: opensource at till.name (Till Maas) Date: Wed, 15 Jul 2009 09:39:27 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> Message-ID: <200907150939.37028.opensource@till.name> On Tue July 14 2009, Jon Stanley wrote: > On Tue, Jul 14, 2009 at 5:08 PM, Till Maas wrote: > > How about the alias "upstream-release-monitoring"? Please forward it to > > "cnucnu.fedora till name" with '@' and '.' added. > > I'd personally prefer to make a mailing list for this, rather than put > the point of failure on a single person (again). If it really makes sense, why not. But I do not see any advantages in this. If I become MIA, then someone from Fedora Infrastructure can just change the target of the alias to get the e-mail addresses, that are send there. Nevertheless I am not quite sure, if someone even needs to receive these e- mails, because they are probably only bugzilla notification mails. In case there is an mailinglist, then it needs to be made sure that only trusted people can join it, because they all can recover the bugzilla password. > Also, have you filed an RFR to get this hosted in Fedora? I do not yet have anything ready that can be hosted. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Wed Jul 15 19:49:38 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Jul 2009 12:49:38 -0700 Subject: [PATCH] Re-enable rawhide compose. In-Reply-To: <1245086925.3206.221.camel@localhost.localdomain> References: <1244432380-7816-1-git-send-email-jkeating@redhat.com> <877hzma6e2.fsf@meyering.net> <1244492607.3206.73.camel@localhost.localdomain> <87zlci8lti.fsf@meyering.net> <1244513311.3206.81.camel@localhost.localdomain> <87r5xrw1r9.fsf@meyering.net> <87prd6odj1.fsf@meyering.net> <1245086925.3206.221.camel@localhost.localdomain> Message-ID: <1247687378.3073.1193.camel@localhost.localdomain> On Mon, 2009-06-15 at 10:28 -0700, Jesse Keating wrote: > There isn't, we don't have a formal policy about patches when we aren't > in an infrastructure freeze. I just haven't had a chance to review the > patch and/or apply it. The patch is flagged for follow up so I will get > to it soon. Looks like Bill already applied this patch. -- 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 ricky at fedoraproject.org Thu Jul 16 00:00:40 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 15 Jul 2009 20:00:40 -0400 Subject: About me In-Reply-To: References: Message-ID: <20090716000040.GE18580@alpha.rzhou.org> On 2009-07-15 01:41:52 AM, Davi Vercillo C. Garcia wrote: > I have some basic/intermediate experience with networking, clustering, > system administration and programming (C, Java and Python - my > favourite option). At this moment, I'm trainee on sysadmin at a hpc > lab at my university, called (NACAD) and I'm monitor of basic > programming call for Engineering courses at my university. Excellent :-) We love Python and use it extensively in Fedora. Most of our main web applications and scripts are written in it. > I would like to help Fedora community grow and keep moving... (Johnny > Walker ? =P) As you've seen already, we mostly hang out in #fedora-admin. We also have weekly meetings on Thursdays at 20:00 UTC in #fedora-meeting, if you can make the one tomorrow, make sure to introduce yourself there as well :-) As I mentioned on IRC, we have a list of tickets at https://fedorahosted.org/fedora-infrastructure/report/1, so feel free to let us know if you find anything there that you'd be interested in working on. We also always have a long list of tasks involving development on a lot of our web applications (mostly using TurboGears 1/2). Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Jul 16 00:06:43 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 15 Jul 2009 20:06:43 -0400 Subject: Greetings In-Reply-To: <3362cef90907150012u6c226b9bn11e080cdde188398@mail.gmail.com> References: <3362cef90907150012u6c226b9bn11e080cdde188398@mail.gmail.com> Message-ID: <20090716000643.GF18580@alpha.rzhou.org> On 2009-07-15 09:12:55 AM, Hj?rleifur J?nsson wrote: > My name is Hjorleifur I am a 30 year old sysadmin and an avid Linux user from > Iceland currently living in Sweden. > I have been using Redhat/RHEL/FEDORA since? Cartman(6.1) and probably every > release since. As well as other Linux Distros, NetBSD,FreeBSD etc. > I have experience in running production environment's for financial > institutions.? Past roles I have held are Software developer (c++,vb,vb.net) on > windows ;). DBA Team Leader (Oracle and SQL Server),Infrastructure Team Leader > running VMware VI3 clusters, Linux, Windows, Hpux servers? and various > application servers on thees platforms.? And recently I have been experimenting > with Opensolaris. > > The fields/technology's that interest me most are Cloud computing , clusters > hpc(though I do have not much experience there) and fail over, load balance and > virtualization. Hey, welcome - we're heavy users of virtualization (currently mostly xen and possibly looking at some KVM too). I think there's actually a cloud project going on at the moment, although I'm not 100% what stage that is at right now. We have some pretty simple load balancing for our web apps with haproxy, and at least one use of heartbeat, although I'm not all that familiar with the heartbeat setup either. We usually hang out on #fedora-admin on Freenode, and we have weekly meetings in #fedora-meeting on Thursdays at 20:00 UTC - if you can make tomorrow's meeting, make sure to come and say hi. 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 a.badger at gmail.com Thu Jul 16 16:32:30 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 09:32:30 -0700 Subject: About me In-Reply-To: <20090716000040.GE18580@alpha.rzhou.org> References: <20090716000040.GE18580@alpha.rzhou.org> Message-ID: <4A5F561E.5060403@gmail.com> On 07/15/2009 05:00 PM, Ricky Zhou wrote: > On 2009-07-15 01:41:52 AM, Davi Vercillo C. Garcia wrote: >> I would like to help Fedora community grow and keep moving... (Johnny >> Walker ? =P) > As you've seen already, we mostly hang out in #fedora-admin. We also > have weekly meetings on Thursdays at 20:00 UTC in #fedora-meeting, if > you can make the one tomorrow, make sure to introduce yourself there as > well :-) > > As I mentioned on IRC, we have a list of tickets at > https://fedorahosted.org/fedora-infrastructure/report/1, so feel free to > let us know if you find anything there that you'd be interested in > working on. We also always have a long list of tasks involving > development on a lot of our web applications (mostly using TurboGears > 1/2). > Individual app authors also hang out on IRC. So if you introduce yourself, we can point you at individual apps that need work as well! -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 davivercillo at gmail.com Thu Jul 16 17:12:56 2009 From: davivercillo at gmail.com (Davi Vercillo C. Garcia) Date: Thu, 16 Jul 2009 14:12:56 -0300 Subject: About me In-Reply-To: <4A5F561E.5060403@gmail.com> References: <20090716000040.GE18580@alpha.rzhou.org> <4A5F561E.5060403@gmail.com> Message-ID: Hi Toshio, > Individual app authors also hang out on IRC. ?So if you introduce > yourself, we can point you at individual apps that need work as well! Yesterday I was there, talking with ricky about what I can do to help fedora-infraestructure's team. I was working with ticket system, looking for something with bad descriptions and changing it. Today I'll take the meeting and there I'll introduce myself again. Thanks, -- Davi Vercillo Carneiro Garcia http://www.google.com/profiles/davivercillo Federal University of Rio de Janeiro Department of Computer Science DCC-IM/UFRJ - http://www.dcc.ufrj.br /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ From ricky at fedoraproject.org Thu Jul 16 21:04:52 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 16 Jul 2009 17:04:52 -0400 Subject: Meeting Log - 2009-07-16 Message-ID: <20090716210452.GF13177@alpha.rzhou.org> 20:00 < mmcgrath> #startmeeting 20:00 < zodbot> Meeting started Thu Jul 16 20:00:11 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 < ricky> (switch it) 20:00 < mmcgrath> #topic Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Who's here? 20:00 * ricky 20:01 * nirik is here in the cheap seats in the back. 20:01 * sijis is here. 20:01 * dgilmore is here 20:01 * nb 20:01 * dgilmore pulls nirik out of teh cheap seats 20:01 < mmcgrath> K, lets get started with the tickets 20:01 < mmcgrath> #topic Infrastructure -- Tickets 20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 -!- trgeier [n=tgeier at c-67-175-200-175.hsd1.il.comcast.net] has joined #fedora-meeting 20:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:02 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 < mmcgrath> Ok, so the only one there is on abadger1999 20:02 < mmcgrath> .ticket 1503 20:02 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:02 < mmcgrath> abadger1999: around? 20:02 < smooge> meeting 20:02 < smooge> here 20:02 < abadger1999> Yep. 20:02 * f13 20:03 < davivercillo> **davivercillo is here 20:03 < abadger1999> phew. So I've been busy and haven't done on anything again. I'll take this off the meeting for now. 20:03 < abadger1999> I'll go ahead with relicensing python-fedora first. 20:03 < abadger1999> Then I think we'll do FAS or pkgdb. 20:04 * ianweller is here 20:04 < mmcgrath> abadger1999: ok 20:04 < smooge> abadger1999, do we have a list of apps we write? 20:04 < abadger1999> After we see that it seems prettystraightforward to do that we can go ahead with everything else. 20:04 < abadger1999> smooge: Unfortunately no -- I go off of memory/what's in puppet/what's running on the app servers. 20:05 < smooge> abadger1999, and do you have an idea on how we will publish local changes to meet AGPL needs. 20:05 < jeff_hann> hello all 20:05 < ricky> You can get a decent list in appRhel.pp 20:05 < ricky> But not totally complete either. 20:05 < davivercillo> Hi everybody, I'm new here ! I'm from Brazil and I would like to help you with something... try at lest... 20:05 < abadger1999> smooge: That's a good point. So I made several proposals in the wiki page. 20:05 < smooge> ricky, ok thanks.. 20:05 * johe here, late but here 20:05 < abadger1999> davivercillo: Welcome! 20:05 < davivercillo> abadger1999: thanks ! =D 20:05 < ricky> jeff_hann, davivercillo: Hey, welcome! 20:05 < abadger1999> smooge: We can do several things... 20:06 < heffer> i'm here too :) 20:06 < abadger1999> 1) Not hotfix. Everything has to be released as a tarball which we can link to. 20:06 < abadger1999> Pro: simple. Con: limiting 20:06 -!- Southern_Gentlem [n=notfred at fedora/Southern-Gentleman] has quit Remote closed the connection 20:06 < f13> 'released as a tarball'? 20:07 < abadger1999> 2) thanks to our new policy, hotfixes have tickets. 20:07 < abadger1999> f13: Well.... I suppose we can point people to a revision/branch in revision control... But it needs to be the source that we're running on the server. 20:07 -!- kolesovdv [n=kolesovd at 82.162.141.18] has joined #fedora-meeting 20:07 < abadger1999> f13: So it can't be HEAD. 20:07 < dgilmore> f13: released as a tarball that can be packaged 20:07 < abadger1999> f13: It would have to be a branch dedicated to mirror produciton. 20:08 < f13> sorry I think I'm not quite following the discussion 20:08 < abadger1999> So baack to #2 -- If we have a patch to the hotfixes in the tickets we can probably link to tarball + list of tickets. 20:08 < f13> I thought the no hotfix policy meant that fixes have to be in rpm form in the repo 20:08 < f13> or in puppet 20:08 < f13> but not just modified directly on the box in question 20:09 < abadger1999> f13: This is a different policy.... licensing Guideline. 20:09 < dgilmore> f13: they should be yes 20:09 < abadger1999> f13: We're going to try to switch to the AGPLv3. 20:09 < f13> ah right, nuance there 20:09 < abadger1999> f13: (In part because moksha/ fedora community is) 20:10 < abadger1999> f13: So we have to figure out how to provide the code that we're running on the servers to people at all times. 20:10 < abadger1999> smooge: Other options that aren't so painful? 20:10 < f13> imho we are either running rpm code, or running signed tagged checkouts 20:11 -!- Southern_Gentlem [n=notfred at fedora/Southern-Gentleman] has joined #fedora-meeting 20:11 < smooge> I am wondering if a git archive meets the AGPL need. 20:11 < f13> and thus we can either point to the srpm, or to the source repo we're running a checkout from 20:11 < dgilmore> i think we should always use rpms 20:11 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit Remote closed the connection 20:11 < abadger1999> f13: Early on in infrastructure I proposed that we use checkouts from revision control. 20:11 < f13> releasing tarballs is a bit of a hassle and redundant in today's scm days 20:11 < dgilmore> then they are always available via the infra repo 20:11 -!- Sonar_Guy [n=Who at adsl-074-171-066-196.sip.aby.bellsouth.net] has joined #fedora-meeting 20:11 < smooge> I would prefer if we used RPMS so we can do the worlds easiest tripwire (rpm -V) 20:11 < abadger1999> I stil think that's nice... but I don't think mixing rpms and checkouts for a single app is good. 20:12 < f13> if we go with scm checkouts, the process to get it checked out and deployed has to be in puppet 20:12 * ricky agrees with what abadger1999 says 20:12 < abadger1999> We'd either want rpms always (with hotfixes) or checkouts always for any given app. 20:12 < f13> so using a tag is somewhat necessary 20:12 * nirik wonders also if there couldn't be a wiki page or something noting why something is in infrastructure and not just EPEL. ;) 20:12 < smooge> f13 I would like it to be the following: 20:12 < ricky> Luke always manages to get hotfixes into RPMs - maybe we can aim for the same? 20:12 < dgilmore> abadger1999: does the direct link to the source need to be on each web page 20:12 < abadger1999> heh, last time he complained about it though ;-) 20:13 < abadger1999> spot: ping 20:13 < f13> he's at LS 20:13 < f13> in canadia 20:13 < abadger1999> Yeah... 20:13 < smooge> git pull, make changes, git commit, git whatevermakes branches, git push; make rpm; make push-to-repo; puppet do your thing 20:13 < abadger1999> I hear they have internet there ;-) 20:13 < f13> don't even have to do that 20:13 < mdomsch> abadger1999, barely generally... 20:13 < f13> git pull/ chnage/ commit/ tag push ; push --tags 20:14 < f13> puppet config would always be pulling from a given tag in the repo 20:14 < abadger1999> mmcgrath: care to go over why you'd rather have rpms than checkouts again? 20:14 * mmcgrath might be missing something too 20:14 -!- Sonar_Guy [n=Who at fedora/sonarguy] has quit Client Quit 20:14 -!- Sonar_Guy [n=Who at fedora/sonarguy] has joined #fedora-meeting 20:14 < mdomsch> abadger1999, for the same reason we don't install everything into /usr/local? 20:14 < mmcgrath> abadger1999: you're talking about packages right? 20:15 < mmcgrath> like fas? 20:15 < abadger1999> mmcgrath: correct 20:15 < abadger1999> mdomsch: But -- we'd be able to track what's installed because the code is in the scm. either HEAD of a specific branch or a tag. 20:15 < ricky> rpm -V, package dependencies and puppet's facilties for managing packages are nice 20:15 < abadger1999> using puppet to pull it will give us repeatablity. 20:15 < dgilmore> f13: id like to know why you think pulling from scm is better? 20:15 < f13> HEAD is bad 20:15 < skvidal> abadger1999: so now we have 2 pkging systems? 20:15 < mmcgrath> abadger1999: IIRC it's part of our freesoftware policy. And for the same functionality and ease of updates as why Fedora doesn't ship tarballs. 20:16 < ricky> It's also pretty consistent between apps 20:16 < ricky> That's why I like RPMs 20:16 < abadger1999> skvidal: That's one strike against it, sure. 20:16 < skvidal> abadger1999: it's a big strike, imo 20:16 < f13> dgilmore: during development of an app, its moving quite a lot faster than what we can push through creating tarball, building rpm, stuffing tha trpm into a repo somewhere, and then updating the host 20:16 < mmcgrath> abadger1999: what benefit do we get? 20:16 < abadger1999> dgilmore: I'm not sure if we need a direct link on every page. Fedora community I believe links to the fedorahosted web page which links to the source repo. 20:17 < f13> it's far easier and smoother to cherry pick a hot fix into the "live" tag, and push that change set, letting the server pick up the live tag at the next puppet run 20:17 < skvidal> f13: not sure it is easier for anyone else looking to replicate what we do 20:17 < f13> once things get more stable, I definitely agree that rpms are the way to go 20:17 < dgilmore> abadger1999: ok, just curious as to how we meet the requirement thatthe live code is available 20:17 < abadger1999> mmcgrath: It's nice from a developer's standpoint. Gets the most benefits when it's an app that runs at a single location. 20:17 < skvidal> f13: nor does it provide the unity of system 20:17 < f13> skvidal: correct, it is not a perfect solution. There are none 20:17 < smooge> could we ship them as conaries? 20:17 -!- fbijlsma [n=fbijlsma at p54B2CF21.dip.t-dialin.net] has joined #fedora-meeting 20:18 < skvidal> I think we'd end up making our very own 'stow' type of system 20:18 < mmcgrath> abadger1999: you can do that in the test environment if you want :) but not in production 20:18 < skvidal> which is just implementing another package system 20:18 < dgilmore> f13: i have to say its maybe easier from a developer standpoint but not from a sysadmin perspective 20:18 < abadger1999> mmcgrath: Allows the developer to not have to deal with making a release (update versions, make tarball, make rpm, deploy) instead they can deploy using (the developer's) normal scm tool. 20:18 < abadger1999> Those are the benefits. 20:18 < f13> dgilmore: from a sysadmin perspective, does it matter much when its entirely driven by puppet? 20:18 < abadger1999> (as I see them). But there's definitely cons. 20:19 < mmcgrath> abadger1999: but once it's in production it's not about them 20:19 < dgilmore> f13: i think so 20:19 < ricky> Even in puppet, it would add a good deal of complexity. 20:19 < f13> mmcgrath: so we're only talking about once in production? 20:19 < f13> but a test instance in development wouldn't have to play by the same rules? 20:19 < mmcgrath> well I'm talking a minimum of once it's in production. 20:19 < mmcgrath> I'd prefer it in staging. 20:19 < mdomsch> agpl doesn't seem to note any difference 20:19 < abadger1999> mmcgrath: Well... that depends... what are you going to want to do to fas or packagedb that you wouldn't toss at a developer and would benefit from an rpm? 20:19 < mmcgrath> on the publictest servers I don't have a preference since so much actual development goes on there. 20:20 < mmcgrath> abadger1999: I'd hope they'd be developing on their workstation, not in production is all. 20:20 < abadger1999> mmcgrath: If we're sticking with rpms over scm, I definitely want rpms in staging. 20:20 < dgilmore> abadger1999: right do same thing across the board 20:20 < mmcgrath> just so I'm clear who's advocating the tarball method, who's advocating rpms and who has no preference? 20:21 < mmcgrath> +1 rpm 20:21 * ricky likes RPMs in staging/production 20:21 < mdomsch> public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version 20:21 < ianweller> +0 20:21 -!- kital [n=Joerg_Si at fedora/kital] has joined #fedora-meeting 20:21 < dgilmore> mmcgrath: i think tarballs should lead to rpms and we should use rpms 20:21 < f13> I'm advocating checkouts from a specific tag in scm at least during the time where changes are rapid. 20:21 < mdomsch> quoth agpl 20:21 < skvidal> +1 rpm 20:21 < f13> whether that time is restricted to pre-staging or not, I don't really care 20:21 < ricky> I think the argument here is that changes should be rapid in testing/development, not in staging/prod 20:21 < smooge> mdomsch, what difference 20:21 * mdomsch uses staging as a test platform 20:22 < mdomsch> rpm + patches from scm 20:22 < ricky> Currently, people are free to go from SCM on publictest machines though 20:22 < mmcgrath> ricky: and typically do 20:22 < smooge> mdomsch, nm.. figured it out 20:22 * ianweller certainly does :) 20:22 < skvidal> mdomsch: what does '+patches' mean? 20:22 < skvidal> mdomsch: do you mean patching the fs itself - or do you mean %patches? 20:23 < mdomsch> skvidal, most often, git-format-patch HEAD^; scp 0001-foobar.patch app1.stg 20:23 < skvidal> mdomsch: nod 20:23 < abadger1999> No preference -- as long as we do it across the board. 20:23 < f13> so, lets propose that once an app goes to staging, all modifications to the app must happen through rpms 20:23 < mdomsch> test; fix; repeat; cut version 20:23 < ianweller> if we go RPMs are we going to require that on pt servers 20:23 < smooge> ok stupid question time.. do changes to configuration files count as patches that need to be publci. 20:23 < f13> since one can easily generate a rpm with patches from git 20:23 < f13> before one does the actual full release 20:23 < mmcgrath> f13: I'd make an exception for emergency patches that require a ticket. 20:23 < skvidal> smooge: I don't think so 20:24 * abadger1999 agrees with mdomsch's use of staging 20:24 < f13> mmcgrath: why make an exception? It takes only a few minutes to generate a patched rpm 20:24 < smooge> skvidal, I just want to get that dealt with before the "Red Hat breaks the AGPL by not publishing their passwords" slashdot fest 20:24 < mdomsch> I don't want to have to respin the RPM just to test a fix on staging 20:24 < skvidal> :) 20:24 < ricky> mmcgrath: What is the policy on testing hotfixes on staging? 20:24 < f13> mdomsch: apparently it isn't about your wants though. 20:24 < ricky> mmcgrath: Like when we were doing FAS testing there, I ran it off of a patched wsgi file somtimes. 20:24 < abadger1999> smooge: I agree with skvidal. configs are managed via puppet 20:25 < f13> mdomsch: if we go strict to just rpms in production, it seems that we want the same thing in staging 20:25 < mmcgrath> it's been my experience that in our environment, requireing a full rebuild of an rpm is a pretty high cost. 20:25 < mmcgrath> not everyone has access to the signing key for one thing. 20:25 < mdomsch> f13, fair enough; but I do want a place to test things before production. Staging has been that so far. if staging isn't going to be that, fine; but something else needs to be. 20:25 < smooge> mdomsch, mmcgrath are we using staging for devepment or for integration.. or both 20:25 -!- thekad [n=kad at 189.187.93.83] has joined #fedora-meeting 20:25 < mmcgrath> next you'll have to make sure that the next release of the rpm (whatever it is) is at least higher then what yours is. 20:25 < mmcgrath> smooge: a little of both. It's really supposed to be for integration/staging. 20:25 < ricky> staging has been mostly for staging deployments and debugging issues (like FAS 500s) in an environment with close-to-prod data 20:25 < abadger1999> mdomsch: +1 20:26 < mmcgrath> but we don't have a fully functional development environment. 20:26 < smooge> so we need some .devel. boxes for everything? 20:26 < f13> mdomsch: isn't that what publictest instances are for? 20:26 < abadger1999> The policy on staging has been -- okay to break it for a short period... but by the time it is deployed it has to be right. 20:26 < mmcgrath> f13: we don't have enough pt boxes though 20:26 < f13> ah. 20:26 < mmcgrath> many of them are being used for proof of concepts and things. 20:26 < ricky> smooge: devel mostly happens on pt machines or home machines right now 20:26 < abadger1999> So rpm + patch hotfix in staging seems to fit that idea -- but it becomes an rpm by the time it goes to production. 20:26 * smooge starts to look up .pt. boxes to figure out how many are needed 20:26 < mmcgrath> this is one of those instances where we see the flaws in our process, but fixing the process isn't that feasible at the moment because of man hours and hosting space 20:27 < mmcgrath> in theory, for a full environment, we'd need 20:27 < mmcgrath> 1 db server 20:27 < mmcgrath> 2 app servers 20:27 < mmcgrath> 1 proxy server 20:27 < mmcgrath> 1 bapp server 20:27 < mmcgrath> 1 releng box 20:27 < mmcgrath> 1 koji box 20:27 < mdomsch> abadger1999, right. code running in staging doesn't have to be published in a downloadable fashion per agpl as it's not public. 20:27 < mmcgrath> 1 cvs host 20:27 < mmcgrath> so that's a minimum 8 per environment. 20:27 < f13> mdomsch: that's a very strange interpretation of "public" 20:27 < mmcgrath> so if we do a full staging and devel environment that's 16 new boxes 20:27 < mmcgrath> err new hosts. 20:27 < f13> mdomsch: I wonder if they assume "staging" isn't on the internet 20:28 < f13> where ours is 20:28 < mdomsch> "It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. " 20:28 < f13> so if we're going to allow rpms + patches with tickets in production, then rpms + patches (without tickets) should be OK in staging 20:28 < mdomsch> the only "users" of the staging server is us 20:28 < mmcgrath> abadger1999: are we discussing this for legal obligations or just to get our policy figured out? 20:28 < f13> mdomsch: except that the staging servers are accessable by the entire world. 20:28 < jwb> i missed something. how did agpl get involved here? 20:28 < mdomsch> therefore: rpms only in production; rpms + patches in staging. 20:28 < thekad> mmcgrath, can we compress a little? i.e. using a db server for both dev and stg? or is it needed for stg to be on its own? maybe we need less machines 20:29 < f13> jwb: we're talking about re-licensing all of Fedora web apps as agpl 20:29 < mdomsch> f13, they are? 20:29 < mmcgrath> thekad: not reliably 20:29 < f13> jwb: and if we do, there are things we have to consider 20:29 < jwb> ok.... 20:29 < f13> mdomsch: Hrm, I was under the impression that they were. 20:29 < ricky> technmeg: We usually don't want real data on development 20:29 < jwb> why agpl? 20:29 < mmcgrath> abadger1999: if this time next year no one is using fedoracommunity, can we get rid of it and go back to GPL? 20:29 < abadger1999> thekad: staging is supposed to be more secure than devel. So separate db servers. 20:29 < mmcgrath> :) 20:29 < f13> jwb: moksha alreasy is agpl 20:29 < thekad> abadger1999, gotcha 20:29 < mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right? 20:29 < abadger1999> jwb: Largely because moksha/community switched to it. 20:30 < mmcgrath> mdomsch: correct 20:30 < ricky> mdomsch: It isn't, but the staging proxy server is 20:30 < abadger1999> jwb: Here's some additional justification: https://fedoraproject.org/wiki/Infrastructure_Licensing 20:30 < ricky> So it's similar to the prod setup 20:30 < f13> mdomsch: I stand corrected 20:30 -!- j6k [n=j6k at 195-240-118-19.ip.telfort.nl] has quit 20:30 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 20:31 < mmcgrath> lets take a step back and look at the hot fix we did for mirrormanager last week. 20:31 -!- lxo [n=aoliva at 150.187.40.27] has joined #fedora-meeting 20:31 < f13> Proposal: Production env is ran by rpms, plus hotfixes with associated tickets with code available. staging is ran from rpms and code patches. 20:31 < mmcgrath> Pretend mirrormanager was AGPL. 20:31 < mmcgrath> abadger1999: would we have not been able to do what we did? 20:31 -!- mizmo [n=duffy at 66.187.234.199] has quit Read error: 110 (Connection timed out) 20:31 < smooge> f13, lets table that for mmcgrath's stuff then we will discuss proposal 20:31 < abadger1999> mmcgrath: Where's the ticket for that? 20:32 < jwb> abadger1999, thanks 20:32 < abadger1999> Let's look at it and see what we might need to do differently. 20:32 < mmcgrath> .ticket 1524 20:32 < zodbot> mmcgrath: #1524 (Hot Fix - mirrormanager) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1524 20:32 -!- mizmo [n=duffy at nat/redhat/x-4bd73725e762e35e] has joined #fedora-meeting 20:32 < abadger1999> So mirrormanager --- we have a base of an rpm that's available from the repo on http://infrastructure.fedoraproject.org/ 20:32 < mdomsch> include srpm 20:32 < abadger1999> We don't have a patch in the ticket... 20:33 < f13> I think might have had to generate a patch file that does the revert, and attached the patch file to the ticket 20:33 < mdomsch> abadger1999, you have a pointer to the patch 20:33 < f13> (and then have something on MM that points to the ticket queue to look for changes) 20:33 < abadger1999> Right. Partial instructions on how to generate a patch 20:33 < f13> you have a pointer to the patch that was reversed. 20:33 < abadger1999> 20:33 < f13> now, I don't think anybody would sue us over the minor nit pick 20:34 < mmcgrath> abadger1999: ok, now take this same scenario 20:34 < mdomsch> especially as the patch is public 20:34 < mmcgrath> and lets say that it wasn't a revert. But I had to add a line of code. 20:34 < f13> mmcgrath: you'd generate a patch file, attach it to the ticket 20:34 < ricky> Attaching the patch sounds reasonable to me. 20:34 < mmcgrath> and that alone, would make me legally compliant? 20:34 < f13> (or reference the commit upstream) 20:34 < mdomsch> or commit the patch to MM upstream, with a pointer to the commit 20:35 < f13> mmcgrath: provided that the mirrormanager site has some link to the ticket queue 20:35 < mmcgrath> mdomsch: it dawns on me that I actually have commit access in MM and should have done that ;-) 20:35 < abadger1999> mmcgrath: I'd say that we need a patch, rather than just hte line of code pasted in the ticket. 20:35 < abadger1999> (as the patch tells where in the code to apply it). 20:36 < f13> (side note, using git am would be perfect here, as it also contains info about the author, and has the commit message) 20:36 < abadger1999> We'd also need to point people at the patch. 20:36 < abadger1999> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&keywords=%7EHOTFIX&order=priority 20:36 < zodbot> abadger1999: http://tinyurl.com/nglq4f 20:36 < f13> an dhas the shasum of the patch which won't change when applied upstream 20:36 < abadger1999> I thought that would do us... but it's not quite enough :-( 20:36 < abadger1999> We need two keywords per hotfix. 20:37 < abadger1999> Hotfix Appname 20:37 < mmcgrath> So the one bit there that's confusing to me is that mirrormanager would have to link to my hosted ticket some how? 20:37 < f13> mmcgrath: right. MirrorManager would have to have a link to wherever the patch is posted. 20:37 < mmcgrath> holy fuck do I hate AGPL 20:37 < ricky> :-( 20:37 < abadger1999> That way mirrormanager can say infrastructure.fedoraproject.org rpm/srpm + URL that finds just mirrormanager hotfixes. 20:37 < f13> be it the infra ticket queue, the MM ticket queue, or the MM upstream repo 20:37 < davivercillo> :P 20:37 < jwb> mmcgrath, heh. and i thought i was the only one 20:38 < f13> mmcgrath: hate or not, it's actually making us be much better about our patch management. 20:38 < abadger1999> mmcgrath: well, we haven't relicensed anything yet -- now's the time to holler if it's not going to fly. 20:38 -!- fbijlsma [n=fbijlsma at p54B2CF21.dip.t-dialin.net] has quit "Leaving" 20:38 < f13> the infrastructure ticket could have been moved to MM"s trac instead 20:38 < mmcgrath> how will the actual implementation of this "linking to bug fixing" work? 20:38 < ricky> f13: That makes them harder for us to track though :-( 20:39 < abadger1999> mdomsch: Re: or commit the patch to MM upstream, with a pointer to the commit 20:39 < mdomsch> MM is the upstream project. It doesn't need a link to all the downstream implementations thereof. 20:39 < abadger1999> mdomsch: I don't think that's enough. 20:39 < thekad> f13, having moved to MM's trac and referencing that trac on f-i's trac would work? 20:39 < f13> ricky: rather, a ticket with the patch could have been filed at MM site. 20:39 < ricky> A central web area where we store current patches to our apps? 20:39 < mmcgrath> is that a legal question? 20:39 < abadger1999> mdomsch: Unless there's a branch dedicated to what we deploy. 20:39 < mmcgrath> mine I mean. 20:39 < mdomsch> The downstream implementations need a link to the code they're running: that can be "pointer to upstream version" plus patches 20:39 < abadger1999> mdomsch: ie, a patch against HEAD might not apply to what we have in production. 20:39 -!- cyberpear [n=james at fedora/cyberpear] has joined #fedora-meeting 20:40 < f13> mmcgrath: probably a legal question 20:40 < mdomsch> abadger1999, rpmfusion uses MM now too. I'd need a separate branch for them too? 20:40 < mmcgrath> Ok 20:40 < mdomsch> repeat for other folks wanting to run MM 20:40 < mmcgrath> so I think here's what we generally agree on. 20:40 < mdomsch> and then give those downstream users commit rights on my repo? 20:40 < mdomsch> uh, no thanks. 20:40 < f13> mmcgrath: I'm looking at the Community site right now, and they just have a footer that points to the hosted site for both Fedora COmmunity and Moksha 20:40 < f13> no other details. 20:40 < f13> mdomsch: why would they have commit access? 20:40 < f13> mdomsch: they can post patches in tickets just like everybody else 20:40 < f13> you can choose to apply them if you want. 20:41 < f13> but that's not a matter for us 20:41 < mdomsch> f13, for abadger's suggested "FI deployment branch" 20:41 < f13> lets forget that MM is done by one of us 20:41 < mmcgrath> so I think we agree, you make a change. Put the patch in fedora-infrastructure trac right? 20:41 < abadger1999> mdomsch: Yep. So I don't think the "pointer to scm commit" is going to work well. 20:41 < mdomsch> mmcgrath, I agree. 20:41 -!- mcepl [n=mcepl at 49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has left #fedora-meeting [] 20:41 < f13> In /our/ deployment of MM, we need to account for not only the upstream source we use, but also the modifications /we/ make 20:41 < mdomsch> abadger1999, it _can_ work for apps we own; but none other. 20:41 < abadger1999> f13: Note that I talked to spot and specifically brought up this point. 20:41 < mmcgrath> Should we ask legal about the "linking app back to bug tracking" bit? 20:41 < ricky> OK, that sounds fine to me, but it's hard to collect them in a central place to link off of the web app pag. 20:41 < ricky> **page 20:41 < f13> so putting a footer in our deployment of MM that points to not just the upstream source, we can point to say our infra repo where hotfix patches go 20:42 < mdomsch> f13, right 20:42 < abadger1999> f13: So it's possible that community is out of compliance -- or is in compliance as long as we don't hotfix it. Or... 20:42 < ricky> It wouldn't be too hard to setup a directory containing all currently applied live patches 20:42 < mmcgrath> abadger1999: did spot say that was a hard requirement? 20:42 < smooge> ricky, we send them to a src.rpm file? 20:42 < mmcgrath> Does oracle ship any products similar but with a less confusing license? 20:42 < f13> abadger1999: nod. I think it depends on how 'exact' we have to be in offering the source 20:42 < ricky> smooge: Well, I'm just talking about live patches here, not package changes 20:42 < mdomsch> corresponding == exact 20:43 < f13> then Fedora Community will be out of compliance the moment we apply a patch 20:43 < f13> since their pages only point you to fedorahosted, not even the git repo 20:43 -!- jeff_hann [n=arares at 188.24.37.69] has quit Remote closed the connection 20:43 < f13> you have to go somewhere else once you get to fedora hosted to get to the source code 20:43 < abadger1999> f13: Yeah -- I'm a bit worried about that actually. 20:43 < ricky> OK, so are we basically waiting on legal advice about the linking requirements at this point? 20:43 < f13> well the page tells you how to get it 20:43 < dgilmore> f13: my understanding is that it needs to point at what is live. so i could setup the service exactly as it is in our infra 20:43 < abadger1999> f13: Since even git repo != what we have deployed without additional instructions 20:43 < ricky> Because otherwise, it doesn't seem to be moving forward all that much 20:44 < jwb> make a pi icon that you can click and it just starts spewing the live source 20:44 < abadger1999> Can we eliminate some things? 20:44 < f13> IMHO it should be enough to point to A) upstream source, B) any changes we make to it. 20:44 < jwb> like the agpl? 20:44 < jwb> sorry, i should shut up 20:44 < f13> A) can be the upstream source repo, B) can be a ticket query that shows any active hotfixes 20:44 < abadger1999> jwb: No that's valid. 20:45 < mmcgrath> abadger1999: and you talked to spot specifically about having our applications point directly to trac? 20:45 < jwb> abadger1999, perhaps. but i have little vested in this 20:45 < f13> (and I guess hotfixes will have to remain active if they are only in our rpm and not the upstream source) 20:45 < abadger1999> Proposal #1 -- Don't use AGPL as license. 20:45 < abadger1999> mmcgrath: No -- just whether we have to provide any hotfixes that go onto our servers. 20:45 < f13> I really don't want to get into banning software due to it's free license 20:45 < abadger1999> We didn't talk about how to provide them. 20:45 < jwb> f13, bannign? 20:46 < f13> banning that is 20:46 < abadger1999> f13: Not quite what we're saying 20:46 < f13> sure it is 20:46 < mmcgrath> we ban software based on free licenses already :) 20:46 < abadger1999> f13: This is about how we license our stuff. 20:46 < f13> define "our stuff" 20:46 < abadger1999> f13: Not about third-party stuff. 20:46 < mmcgrath> "Don't use AGPL as license" meaning FAS, mirrormanager, etc. 20:46 < f13> is Fedora Community "our stuff" or third party? 20:46 < ricky> Proposal #2: Central directory containing all patches linked directly on website footers as well as source? 20:46 < abadger1999> If we write it 20:46 < f13> define "we" 20:46 < ricky> (That's if the trac ticket thing doesn't fly) 20:46 < abadger1999> f13: That's actually a problem 20:46 < mmcgrath> f13: he's saying "don't apply AGPL to our software" not "don't use software that is under AGPL" 20:46 < jwb> my point is, looking at the number of questions and hurdles the AGPL would force on you, why in the name of all things Fedora would you want to use that when it causes so much hassle to just get a damn _fix_ onto your services? 20:46 < dgilmore> f13: things written with fedoraproject use intended 20:46 < abadger1999> Fedora Community acts like a third party but wants in-house treatment. 20:47 < abadger1999> We have to shift that one way or another. 20:47 < ricky> Agreed 20:47 < f13> jwb: because the AGPL actually ensures that the source code for the web service you're using is actually available 20:47 < f13> unlike other licenses where you can patch it to hell and back and never be required to provide your changes 20:47 * mmcgrath is actually fine with people making changes to fas and not making that code available as long as they're not distributing it 20:48 < dgilmore> abadger1999: right i view it as third party due to the way that things have been done 20:48 < jwb> f13, i don't think that is really causing Fedora any pain 20:48 < f13> mmcgrath: define "distribution" 20:48 < jwb> whereas using AGPL seems to... 20:48 < abadger1999> jwb: What f13 said and that Community is using it -- which means that sharing code with community is harder. 20:48 < thekad> mmcgrath, +1 20:48 < mdomsch> idea: how about a web page that lists the apps we have in deployment, with links to a) their upstream source; b) the live patch queue; for each app. 20:48 < mmcgrath> f13: don't have to, thats for legal to decide 20:48 < mmcgrath> as well as what day of the week it is ;) 20:48 < f13> Lets look at koji code 20:49 * abadger1999 notes that we're at 46minutes. 20:49 < f13> if somebody, like say oracle, took koji code and started using it and made it available to people, but patched it to add functionality 20:49 -!- cyberpea1 [n=james at fedora/cyberpear] has joined #fedora-meeting 20:49 < ricky> mmcgrath: I would be pretty disappointed if somebody added an good OpenID provider to FAS and started running it without it being free :-) Of course, the chances of that happening are almost nine. 20:49 < f13> we'd want those code changes, particularly as they're a compeditor 20:49 < ricky> **none 20:49 < dgilmore> f13: they could 20:49 -!- sharkcz [n=dan at plz1-v-4-17.static.adsl.vol.cz] has quit "Ukon?uji" 20:49 < dgilmore> f13: as koji is currently licensed 20:49 < f13> with the way that koji is licensed now, they can do just that, and we have no recourse 20:49 < thekad> yeah, nine are too many 20:49 < smooge> mdomsch, I think in the end we will need to get a legal idea on what is required in the sharing of the code. Do patches count? Or is it the full tree? Do config file changes count if the config file is listed as beign AGPL also. 20:49 < ricky> thekad: :-) 20:50 < dgilmore> f13: they do have to post there code for there customers 20:50 < f13> if it were AGPL, they'd be required to make those changes available. 20:50 < f13> dgilmore: not as a webapp 20:50 < f13> dgilmore: client code ran on the computer yes, but none of the hub code would be required to be made public to their customers 20:50 < abadger1999> dgilmore: They're not distributing hte web ap.. only letting people use it. 20:50 < mmcgrath> abadger1999: so before the cost of not moving our apps to AGPL meant sharing code was very nasty. Now, moving our apps to AGPL means doing practical things might be illegal? 20:50 < dgilmore> f13: right. 20:50 -!- RadicalRo [n=radical at 193.254.32.144] has quit "Leaving." 20:50 < abadger1999> mmcgrath: Yes. 20:51 < f13> mmcgrath: practical very often gets in the way of opensource licensing 20:51 < mmcgrath> we've got some decisions to make. 20:51 < abadger1999> Although doing practical things has always been illegal. 20:51 < jwb> mmcgrath, burdensome at best. illegal at worst 20:51 -!- cyberpea2 [n=james at fedora/cyberpear] has quit Read error: 110 (Connection timed out) 20:51 < abadger1999> This just hits us in a place where we haven't considered before. 20:51 < f13> the burden really only seems to be on A) making the site footer link to places we put source 20:51 < thekad> I think we should get advice from legal and be done with it, because I don't know about you guys, but IANAL 20:51 < abadger1999> (As an example -- we can't link a pretty common piece of javascript to any app because it's CC licensed which is not compatible with the GPL) 20:51 < f13> the rest of it is really just good practice (posting patches to tickets for hotfixes we make) 20:52 < ricky> abadger1999: Oh :-( that's starting to get pretty annoying then. We can currently do that with GPLv2? 20:52 < abadger1999> ricky: That was an example of something that's illegal now. 20:52 < mmcgrath> abadger1999: "now" as in the AGPL world or now as in like right this second? 20:53 -!- lxo [n=aoliva at 150.187.40.27] has quit Connection timed out 20:53 < ricky> Oh, OK. 20:53 < abadger1999> But we are used to thinking about different licenses conflicting so we know to check that out no matter how nice it would be to reuse that code. 20:53 < abadger1999> mmcgrath: right this second 20:53 < abadger1999> GPL (any version) not compatible with CC (any variant) 20:53 < f13> abadger1999: define "link to javascript"? 20:54 < mmcgrath> As someone who loves and believes in free software. I _CAN'T IMAGINE_ what some exec things if a mess like this were to be brought up to him. 20:54 < mmcgrath> s/things/thinks/ 20:54 < skvidal> mmcgrath: she would think "I have hired people to do this for me" 20:54 < f13> abadger1999: I could have sworn recently legal said that the act of say importing one python module and using its api didn't mean it's license had to be fully compatible with your software's license. 20:55 < f13> but I could be on crack, so blah. 20:55 < smooge> ok how about this.. can we dual license? 20:55 < abadger1999> smooge: Nooooooo ;-) 20:55 < mdomsch> f13, I'd love to to get more info on that if so... 20:55 < mdomsch> really. 20:55 < abadger1999> Query -- is there anything else to announce/discuss today? 20:56 < abadger1999> I've got nothing else but this. 20:56 < mmcgrath> abadger1999: I don't think so. 20:56 < mmcgrath> we spent literally the whole meeting on this. 20:56 < ricky> Yeah, we're almost at the 1 hour mark on just this 20:56 < abadger1999> Okay -- we have 6 minutes -- shall we list our questions for spot? 20:56 < mmcgrath> which is a strong indication.... we've bitten off quite a bit here. 20:56 < mmcgrath> abadger1999: yeah 20:56 < mmcgrath> #topic Infrastructure -- Questions for legal 20:56 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Questions for legal 20:56 < ricky> 1) Explain the linking requirements 20:56 < mmcgrath> 1) Do we have to link the application to the ticket 20:57 < mmcgrath> 2) Is it really "absolutely critical" that fedoracommunity be AGPL 20:57 * mdomsch has another meeting; thanks all. 20:57 < ricky> mdomsch: See you later 20:57 < mmcgrath> mdomsch: laters 20:57 < f13> 3) Is linking to a list of tickets with patches to the application enough to cover "modifications" 20:57 < smooge> 4) Do config changes count as code changes if the config file is marked as being AGPL 20:57 < ricky> 4) Can we get a clarification of what the consequences would be if fcomm stays AGPL but our apps stay as they are? 20:58 < abadger1999> 4) which of (A) patch (B) full tree or (C) description of what line to change in which file suitable for the requirement 20:58 < smooge> we need one more 4 20:58 < jwb> btw, i'm not against AGPL as a whole. but it seems like lots of work for little gain here 20:58 < davivercillo> people... I'm not feeling fine... I think that I'm getting sick, so I'm gonna home to rest a little bit... see you soon ! have a nice meeting ! 20:58 < davivercillo> bye 20:58 < smooge> bye 20:58 < mmcgrath> jwb: I'm not either, I just want someone else to use it, not me :) 20:58 < ricky> davivercillo: Thanks for stopping by, sorry we didn't get a chance to discuss anything else 20:59 < mmcgrath> Ok, any other questions? 20:59 < abadger1999> davivercillo: Thanks for being here -- we can talk some other day in #fedora-admin 20:59 < mmcgrath> davivercillo: take it easy, see you next week. 20:59 < jwb> abadger1999, dual license might not be so bad 20:59 < abadger1999> 5) Can we link to a whole list of patches for all of our apps or does it need to be the specific patches per app? 20:59 < davivercillo> thanks ! 20:59 < jwb> abadger1999, stuff in staging is $not_agpl. stuff in production is 20:59 < ricky> would that double the requirements we have to hold up? 20:59 < f13> honestly, I think it wouldn't take much work on our part to comply with AGPL 20:59 -!- davivercillo [n=daviverc at 146.164.31.95] has left #fedora-meeting [] 21:00 < skvidal> f13: I think I agree w/you 21:00 < abadger1999> jwb: Is that question 6) 21:00 < jwb> abadger1999, actually. scratch that 21:00 < ricky> I agree with f13, but there's still the question of how worth it it is for the work 21:00 < f13> provided legal responds well to our questions, such as just linking to tickets. 21:00 < abadger1999> Okay 21:00 < skvidal> ricky: same question could be asked of the GPL - but surely we value what we get from it 21:00 < f13> ricky: I think it's very little work we wouldn't/shouldn't already be doing. 21:00 < jwb> abadger1999, no. because if staging is public, then people could just take the staging code before it hits production and circumvent what you'd want from AGPL 21:00 -!- cyberpear [n=james at fedora/cyberpear] has quit Connection timed out 21:00 < mmcgrath> Ok all we're at time. 21:00 < f13> jwb: I was corrected, staging isn't "public" 21:00 < mmcgrath> anyone have anything else? If not we'll close the meeting 21:00 < abadger1999> 6) Do we need to link to the source from every page of the app? 21:01 < jwb> f13, so hotfixes are the largest concern then? 21:01 < f13> jwb: yes 21:01 < ricky> Staging is web-accessible, ubt we do not necessarily consider it public 21:01 < smooge> close 21:01 < ricky> *8but 21:01 < ricky> **but 21:01 < ricky> So let's make that 7) Does staging count if it's web-accessible 21:01 < jwb> f13, hm. my concerns are lessened but not completely 21:01 < f13> ricky: uh, mmcgrath earlier said it wasn't public. 21:01 < jwb> confused as to how it's not public 21:01 < ricky> https://admin.fedoraproject.org/community/ 21:01 < ricky> That's the type of public I'm talking about 21:01 < abadger1999> I'll write the questions up and pass them to the list for a few hours before making sure that spot sees them. 21:02 < ricky> app1.stg is not publicly accessible, but the proxy server that serves the app is 21:02 < mmcgrath> https://admin.stg.fedoraproject.org/community/ is I think the link you want. 21:02 < abadger1999> jwb: We're trying to divide it on the term "users". 21:02 < f13> mmcgrath, app1.stg isn't reachable outside FI, right? 21:02 < f13> mdomsch: correct 21:02 < mmcgrath> app1.stg isn't 21:02 < jwb> abadger1999, maybe that's a question for legal too 21:02 < ricky> mmcgrath: Oops, thanks 21:02 < mmcgrath> it's through a proxy server 21:02 < f13> er. 21:02 < f13> that's a symantic 21:02 < abadger1999> jwb: Okay.. care to phrase it for me? 21:03 < f13> if the world can get to the site, it's public 21:03 < f13> and AGPL would apply 21:03 < ricky> jwb: My #7 is that exact question 21:03 < jwb> ricky, oh, ok 21:03 < jwb> abadger1999, then whatever ricky said :) 21:03 < mmcgrath> Ok guys we're going over, anyone have anything else? 21:03 < f13> so it looks like staging /would/ have to account for AGPL 21:03 < mmcgrath> abadger1999: you have everything you need to keep you busy? 21:03 < abadger1999> mmcgrath: For weeks and weeks ;-) 21:03 < mmcgrath> f13: sorry my misunderstanding, when you said app1.stg I thought you ment the host, I wasn't thinking about the apps 21:03 < abadger1999> Close it up and lets continue on list 21:04 < mmcgrath> Ok, if no one has anything else I'll close in 10 21:04 < mmcgrath> #endmeeting 21:04 -!- zodbot 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/Meeting_channel for meeting schedule 21:04 < zodbot> Meeting ended Thu Jul 16 21:04:24 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 21:04 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.html 21:04 < jwb> f13, so if staging is public, ew 21:04 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.txt 21:04 < mmcgrath> Thanks for coming everyone 21:04 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.log.html -------------- 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 Thu Jul 16 21:41:32 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Jul 2009 14:41:32 -0700 Subject: trac-git-plugin updated on hosted1/2 Message-ID: <1247780492.3012.22.camel@localhost.localdomain> This is a new upstream snapshot that fixes some of the ongoing issues we've had with the git plugin. Some were already patched from a different upstream, but I've had to throw those changes out in favor of the actual upstream changes. I tested it a bit on hosted2 and couldn't find any problems, but keep your eye open for any tickets related to git plugin in hosted. -- 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 Thu Jul 16 22:41:34 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 16 Jul 2009 16:41:34 -0600 Subject: Cron run-parts /etc/cron.hourly In-Reply-To: <20090716215213.24CA28F8438@puppet1.fedora.phx.redhat.com> References: <20090716215213.24CA28F8438@puppet1.fedora.phx.redhat.com> Message-ID: <80d7e4090907161541y78cd72c4j8e81ebbc2c78f34@mail.gmail.com> This script was stuck on the fact that hosted1 went down as it was getting stuff this morning. So it was stopping others from completing. Killed the git's and ten ran by hand to finish. On Thu, Jul 16, 2009 at 3:52 PM, Cron Daemon wrote: > /etc/cron.hourly/syncStatic.sh: > > /etc/cron.hourly/syncStatic.sh: line 23: 31157 Terminated ? ? ? ? ? ? ?/usr/bin/git clone git://git.fedorahosted.org/git/fedora-web.git > /dev/null 2>&1 > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From a.badger at gmail.com Thu Jul 16 22:57:29 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 15:57:29 -0700 Subject: Relicensing Part II Message-ID: <4A5FB059.1050503@gmail.com> Alright! So the last two weeks there wasn't much comment on: https://fedorahosted.org/fedora-infrastructure/ticket/1524 https://fedoraproject.org/wiki/Infrastructure_Licensing but I think people were either sleeping or didn't entirely understand what the AGPL's requirements mean for us as this week we filled the whole meeting with discussion[1]_. We arrived at a few conclusions about options we did not want to explore but got into a few questions that need answers from legal before we can continue. Please clarify the questions or add new ones if you can think of other things that we need to know from legal. Once that's done or tomorrow (whichever comes first) I'll make sure that spot gets the list so we can get some input and better consider our options. Questions follow: == What we decided == * Continue to deploy as rpms to production and as the basis of staging. * In production, hotfixes need to have tickets in trac. Those tickets may be required to contain patches applied to the server if we determine that's the best course under legal. - If that's not the best course, hotfix tickets still need to contain an indication of what the hotfix does but this could be "I reverted commit 12345" or "I changed three files to import simplejson instead of json (python-2.4 compatibility)" * In staging, we want to deploy with a base rpm and may add patches and local changes on top of that to test things. When we get to the point where we are satisfied, this needs to be turned into an rpm and be deployed to production/installed in the staging env. * In publictest, we want people to be able to deploy from SCM, make local changes, etc. publictest are pure development machines. == Explain the linking requirements == How the running app leads people to the source for the app is causing the most concerns. Here's a list of questions. There's a lot because we don't have a feel for what's allowed and not allowed yet. Where relevant, assume that the running applications have rpms/srpms present on infrastructure.fedoraproject.org, an upstream trac/scm instance on fedorahosted.org, and that we are running with some number of hotfixes to the live application. * Do we need to link to the source from every page of the app? * What are legal means of giving people access to the corresponding source? + Source repository at no particular version (assuming all of our patches are applied to trunk -- and trunk might contain other changes as well, including full or partial reversions of those changes in a later revision) + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) + Pointing exactly to source repository branch or tag of the exact version we're running + Home page of the project (example: http://fedorahosted.org/fas) + Just a page specifically linking to the sources and all of the patches we've applied + links to base srpm and page listing patches + links to base srpm and tickets in trac that have patches attached + links to base srpm and tickets in trac that point to commits in SCM that are applied against different versions (HEAD vs the last release, for instance) + A page linking to the sources and a page linking to any hotfixes we've applied to any of our apps (ie, a query in infrastructure's trac that gets all hotfixes for all of our apps). + I'm assuming these to be fine: tarball, srpm that matches what's running, actual links to base tarball and to all of the patches * Do config changes count as code changes if the config file is marked as being AGPL? - If yes, what do we have to do to make config files not be licensed under AGPL? (We want to protect passwords, for instance). == Related to Other Apps == Our original impetus for relicensing is so we can freely share code with fedoracommunity. The cost of maintaining AGPL compliance with other apps needs to be weighed against the cost of reinventing code in fedoracommunity (or waiting for fedoracommunity developers to relicense their code for use elsewhere *cough CSRF middleware cough* :-) ). * Is it really "absolutely critical" that fedoracommunity be AGPL? * Can we get a clarification of what the consequences would be if fedora community stays AGPL but our apps stay as they are (GPLv2)? == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """ Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. """ * Is the preamble legally binding/part of the AGPL or should we ignore anything there? * admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself? * Can we be just as liberal with what's running on the publictest machines as we are with staging? .. _[1]: Meeting Minutes http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.html -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 jkeating at redhat.com Thu Jul 16 23:10:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Jul 2009 16:10:45 -0700 Subject: Relicensing Part II In-Reply-To: <4A5FB059.1050503@gmail.com> References: <4A5FB059.1050503@gmail.com> Message-ID: <1247785845.3012.25.camel@localhost.localdomain> On Thu, 2009-07-16 at 15:57 -0700, Toshio Kuratomi wrote: > > * admin.stg.fedoraproject.org is accessible by the general public but it > isn't meant for the general public's use -- it's for developers to > collaborate on what will be on the production site, > admin.fedoraproject.org. Those developers collaborate over the internet > which is why it's available on the internet. Does this excuse us from > providing source to people who do not have shell access to the server > itself? > > * Can we be just as liberal with what's running on the publictest > machines as we are with staging? Its worth noting that Publictest instances are also accessible by the public, so AGPL concerns may strike us there, just as they may strike us with the staging environment. -- 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 a.badger at gmail.com Thu Jul 16 23:23:11 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 16:23:11 -0700 Subject: Relicensing Part II In-Reply-To: <1247785845.3012.25.camel@localhost.localdomain> References: <4A5FB059.1050503@gmail.com> <1247785845.3012.25.camel@localhost.localdomain> Message-ID: <4A5FB65F.7000507@gmail.com> On 07/16/2009 04:10 PM, Jesse Keating wrote: > On Thu, 2009-07-16 at 15:57 -0700, Toshio Kuratomi wrote: >> >> * admin.stg.fedoraproject.org is accessible by the general public but it >> isn't meant for the general public's use -- it's for developers to >> collaborate on what will be on the production site, >> admin.fedoraproject.org. Those developers collaborate over the internet >> which is why it's available on the internet. Does this excuse us from >> providing source to people who do not have shell access to the server >> itself? >> >> * Can we be just as liberal with what's running on the publictest >> machines as we are with staging? > > Its worth noting that Publictest instances are also accessible by the > public, so AGPL concerns may strike us there, just as they may strike us > with the staging environment. > I figure if it's going to hit us hard in staging, we may not want to go the AGPL route at all. If they don't hit us in staging, just want confirm that the same rationale will apply to the publictest instances. Maybe reword this question to: * If we can run apps in staging without providing source to those without shell accounts there, can we also run apps on publictest boxes without providing source to those without shell accounts there. -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 Fri Jul 17 02:59:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 19:59:01 -0700 Subject: Add patch to global.pp Message-ID: <4A5FE8F5.40305@gmail.com> ricky and I were considering adding patch to global.pp and dennis brought up that it might be a command used to do malicious stuff. So what do you guys think? Pros: patch makes some things much easier to do. Want to cherrypick a change as a hotfix? Many times patch is needed to apply the diff. Want to replicate some changes from server1 to servers 2, 3, and 4? diff on server1, patch on the others. Need to review a change that someone else has done and then apply it? Read the diff they give you and apply it rather than grabbing the whole file, doing the diff yourself, and then applying it. Cons: patch is a commonly used utility that is often used to edit files. So the principle of not installing things that aren't needed makes it one more tool that an attacker won't have if they get remote execution on a box they shouldn't. However, there's many other things that an attacker can do if they gain remote execution. Rather than retrieving a diff and applying that to a file, the attacker can just retrieve a file and then replace the existing one; we have wget, curl, and scp installed. ed, sed, perl, python, and other text processing tools are available. I'm thinking if the attacker can gain the ability to execute a remote command and they have permission to touch files that are going to cause us harm, lack of patch isn't going to save us. Other: * patch doesn't have any deps that aren't already installed on one of our boxes. What's the consensus here? -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 jkeating at redhat.com Fri Jul 17 03:50:25 2009 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Jul 2009 20:50:25 -0700 Subject: Add patch to global.pp In-Reply-To: <4A5FE8F5.40305@gmail.com> References: <4A5FE8F5.40305@gmail.com> Message-ID: <1247802625.3012.29.camel@localhost.localdomain> On Thu, 2009-07-16 at 19:59 -0700, Toshio Kuratomi wrote: > What's the consensus here? If we install patch, will git come next, since people will want to git am stuff? Not that I'm against having patch, it would make things easier. -- 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 Fri Jul 17 03:59:52 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 16 Jul 2009 22:59:52 -0500 (CDT) Subject: Add patch to global.pp In-Reply-To: <4A5FE8F5.40305@gmail.com> References: <4A5FE8F5.40305@gmail.com> Message-ID: On Thu, 16 Jul 2009, Toshio Kuratomi wrote: > ricky and I were considering adding patch to global.pp and dennis > brought up that it might be a command used to do malicious stuff. So > what do you guys think? > > Pros: > patch makes some things much easier to do. Want to cherrypick a change > as a hotfix? Many times patch is needed to apply the diff. Want to > replicate some changes from server1 to servers 2, 3, and 4? diff on > server1, patch on the others. Need to review a change that someone else > has done and then apply it? Read the diff they give you and apply it > rather than grabbing the whole file, doing the diff yourself, and then > applying it. > > Cons: > patch is a commonly used utility that is often used to edit files. So > the principle of not installing things that aren't needed makes it one > more tool that an attacker won't have if they get remote execution on a > box they shouldn't. However, there's many other things that an attacker > can do if they gain remote execution. Rather than retrieving a diff and > applying that to a file, the attacker can just retrieve a file and then > replace the existing one; we have wget, curl, and scp installed. ed, > sed, perl, python, and other text processing tools are available. I'm > thinking if the attacker can gain the ability to execute a remote > command and they have permission to touch files that are going to cause > us harm, lack of patch isn't going to save us. > > Other: > * patch doesn't have any deps that aren't already installed on one of > our boxes. > > What's the consensus here? > +0 no opinion if it would be of some use. I've generally scp'd files where needed and copied from there. Same number of commands and files copied as if you were to patch scp blah.py app1: ; ssh app1 ; sudo cp blah.py /usr/blah scp blah.patch app1: ; ssh app1; sudo patch -p1 < blah.patch -Mike From a.badger at gmail.com Fri Jul 17 04:24:56 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 21:24:56 -0700 Subject: Add patch to global.pp In-Reply-To: <1247802625.3012.29.camel@localhost.localdomain> References: <4A5FE8F5.40305@gmail.com> <1247802625.3012.29.camel@localhost.localdomain> Message-ID: <4A5FFD18.3090300@gmail.com> On 07/16/2009 08:50 PM, Jesse Keating wrote: > On Thu, 2009-07-16 at 19:59 -0700, Toshio Kuratomi wrote: >> What's the consensus here? > > If we install patch, will git come next, since people will want to git > am stuff? Not that I'm against having patch, it would make things > easier. Well I won't be adding that one :-) Thinking about this more seriously, patch can be useful on text files on any system. git is only useful on systems where we're making git checkouts. git-am, if I'm reading the man page right would only be useful where we have git checkouts and are receiving patches via mail? -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 Fri Jul 17 04:28:17 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 16 Jul 2009 21:28:17 -0700 Subject: Add patch to global.pp In-Reply-To: References: <4A5FE8F5.40305@gmail.com> Message-ID: <4A5FFDE1.2000409@gmail.com> On 07/16/2009 08:59 PM, Mike McGrath wrote: > +0 no opinion if it would be of some use. I've generally scp'd files > where needed and copied from there. Same number of commands and files > copied as if you were to patch > > scp blah.py app1: ; ssh app1 ; sudo cp blah.py /usr/blah > > scp blah.patch app1: ; ssh app1; sudo patch -p1 < blah.patch > Good point. Of more use when you're showing someone else your changes/receiving changes from someone else. -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 jkeating at j2solutions.net Fri Jul 17 06:44:53 2009 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 16 Jul 2009 23:44:53 -0700 Subject: Add patch to global.pp In-Reply-To: <4A5FFD18.3090300@gmail.com> References: <4A5FE8F5.40305@gmail.com> <1247802625.3012.29.camel@localhost.localdomain> <4A5FFD18.3090300@gmail.com> Message-ID: <6E04AB91-2BDE-4980-B97E-40784CA5EF32@j2solutions.net> On Jul 16, 2009, at 21:24, Toshio Kuratomi wrote: > On 07/16/2009 08:50 PM, Jesse Keating wrote: >> On Thu, 2009-07-16 at 19:59 -0700, Toshio Kuratomi wrote: >>> What's the consensus here? >> >> If we install patch, will git come next, since people will want to >> git >> am stuff? Not that I'm against having patch, it would make things >> easier. > > Well I won't be adding that one :-) > > Thinking about this more seriously, patch can be useful on text > files on > any system. git is only useful on systems where we're making git > checkouts. git-am, if I'm reading the man page right would only be > useful where we have git checkouts and are receiving patches via mail? > Git am works on any file generated with git format-patch. That is most often used with email but it does encapsulate the author and the commit message and has a checksum itself that can be verified against the upstream repo. Probably not something we need in global. -- Jes From opensource at till.name Fri Jul 17 07:44:51 2009 From: opensource at till.name (Till Maas) Date: Fri, 17 Jul 2009 09:44:51 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> Message-ID: <200907170944.57815.opensource@till.name> On Tue July 14 2009, Jon Stanley wrote: > On Tue, Jul 14, 2009 at 5:08 PM, Till Maas wrote: > > How about the alias "upstream-release-monitoring"? Please forward it to > > "cnucnu.fedora till name" with '@' and '.' added. > > I'd personally prefer to make a mailing list for this, rather than put > the point of failure on a single person (again). Btw. I just remembered which bot bugzilla account already exists: ftbfs - https://admin.fedoraproject.org/accounts/user/view/ftbfs There seems to be no mailing list involved, too. Nevertheless, what is the next step for this? Has this to be discussed on some meeting or should I file a ticket somewhere? Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jonstanley at gmail.com Fri Jul 17 12:33:24 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 17 Jul 2009 08:33:24 -0400 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <200907170944.57815.opensource@till.name> References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> <200907170944.57815.opensource@till.name> Message-ID: On Fri, Jul 17, 2009 at 3:44 AM, Till Maas wrote: > Btw. I just remembered which bot bugzilla account already exists: ftbfs - > https://admin.fedoraproject.org/accounts/user/view/ftbfs > There seems to be no mailing list involved, too. Nah, I don't much care if no one cares to see the mail. ftbfs goes to /dev/null pretty much (actually to ftbfs at domsch.com). I can create the requested alias, and you can create a bugzilla account with it. It needs no special permissions to file bugs (which is all it should be doing). From jonstanley at gmail.com Fri Jul 17 12:42:53 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 17 Jul 2009 08:42:53 -0400 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <200907170944.57815.opensource@till.name> References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> <200907170944.57815.opensource@till.name> Message-ID: On Fri, Jul 17, 2009 at 3:44 AM, Till Maas wrote: > Btw. I just remembered which bot bugzilla account already exists: ftbfs - > https://admin.fedoraproject.org/accounts/user/view/ftbfs > There seems to be no mailing list involved, too. The alias is created - it's just a mail alias, not a full FAS account. You'll have to make a Bugzilla account with that mail address, and that's it! :). It may take up to 30 minutes to be live, though. From me at davidjmemmett.co.uk Fri Jul 17 12:45:08 2009 From: me at davidjmemmett.co.uk (David JM Emmett) Date: Fri, 17 Jul 2009 13:45:08 +0100 Subject: Add patch to global.pp In-Reply-To: <4A5FE8F5.40305@gmail.com> References: <4A5FE8F5.40305@gmail.com> Message-ID: <79760415-1F3D-4314-98C6-12DD972F24C7@davidjmemmett.co.uk> Maybe I'm missing something here but if an attacker has access don't you have bigger problems? -- Cheers, David JM Emmett Sent from my iPhone On 17 Jul 2009, at 03:59, Toshio Kuratomi wrote: > ricky and I were considering adding patch to global.pp and dennis > brought up that it might be a command used to do malicious stuff. So > what do you guys think? > > Pros: > patch makes some things much easier to do. Want to cherrypick a > change > as a hotfix? Many times patch is needed to apply the diff. Want to > replicate some changes from server1 to servers 2, 3, and 4? diff on > server1, patch on the others. Need to review a change that someone > else > has done and then apply it? Read the diff they give you and apply it > rather than grabbing the whole file, doing the diff yourself, and then > applying it. > > Cons: > patch is a commonly used utility that is often used to edit files. So > the principle of not installing things that aren't needed makes it one > more tool that an attacker won't have if they get remote execution > on a > box they shouldn't. However, there's many other things that an > attacker > can do if they gain remote execution. Rather than retrieving a diff > and > applying that to a file, the attacker can just retrieve a file and > then > replace the existing one; we have wget, curl, and scp installed. ed, > sed, perl, python, and other text processing tools are available. I'm > thinking if the attacker can gain the ability to execute a remote > command and they have permission to touch files that are going to > cause > us harm, lack of patch isn't going to save us. > > Other: > * patch doesn't have any deps that aren't already installed on one of > our boxes. > > What's the consensus here? > > -Toshio > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From Matt_Domsch at dell.com Fri Jul 17 12:48:34 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 17 Jul 2009 07:48:34 -0500 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> <200907170944.57815.opensource@till.name> Message-ID: <20090717124832.GA26244@mock.linuxdev.us.dell.com> On Fri, Jul 17, 2009 at 08:42:53AM -0400, Jon Stanley wrote: > On Fri, Jul 17, 2009 at 3:44 AM, Till Maas wrote: > > > Btw. I just remembered which bot bugzilla account already exists: ftbfs - > > https://admin.fedoraproject.org/accounts/user/view/ftbfs > > There seems to be no mailing list involved, too. > > The alias is created - it's just a mail alias, not a full FAS account. > You'll have to make a Bugzilla account with that mail address, and > that's it! :). It may take up to 30 minutes to be live, though. The trick is, you can't create a bugzilla account with @fedoraproject.org directly for some reason. Maybe this is fixed. I had to create a bugzilla account with another email address, then request of the bugzilla administrators to change the email address for the account. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From opensource at till.name Fri Jul 17 12:51:15 2009 From: opensource at till.name (Till Maas) Date: Fri, 17 Jul 2009 14:51:15 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <20090717124832.GA26244@mock.linuxdev.us.dell.com> References: <200907122223.32248.opensource@till.name> <20090717124832.GA26244@mock.linuxdev.us.dell.com> Message-ID: <200907171451.22238.opensource@till.name> On Fri July 17 2009, Matt Domsch wrote: > On Fri, Jul 17, 2009 at 08:42:53AM -0400, Jon Stanley wrote: > > The alias is created - it's just a mail alias, not a full FAS account. > > You'll have to make a Bugzilla account with that mail address, and > > that's it! :). It may take up to 30 minutes to be live, though. > > The trick is, you can't create a bugzilla account with > @fedoraproject.org directly for some reason. Maybe this is fixed. I > had to create a bugzilla account with another email address, then > request of the bugzilla administrators to change the email address for > the account. Thank you both, I'll report back, whether or not it worked. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ricky at fedoraproject.org Fri Jul 17 12:58:10 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 17 Jul 2009 08:58:10 -0400 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <20090717124832.GA26244@mock.linuxdev.us.dell.com> References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> <200907170944.57815.opensource@till.name> <20090717124832.GA26244@mock.linuxdev.us.dell.com> Message-ID: <20090717125810.GB25524@alpha.rzhou.org> On 2009-07-17 07:48:34 AM, Matt Domsch wrote: > The trick is, you can't create a bugzilla account with > @fedoraproject.org directly for some reason. Maybe this is fixed. I > had to create a bugzilla account with another email address, then > request of the bugzilla administrators to change the email address for > the account. Hi, are you talking about a restriction in bugzilla, or the current limitation where FAS doesn't assign bugzilla permissions to accounts that don't match the email address given in FAS? If it's the former, hopefully that's fixed now - I think I've created an @fedoraproject.org account once at some point in the past 2 years or so :-) 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 opensource at till.name Fri Jul 17 13:29:41 2009 From: opensource at till.name (Till Maas) Date: Fri, 17 Jul 2009 15:29:41 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <20090717125810.GB25524@alpha.rzhou.org> References: <200907122223.32248.opensource@till.name> <20090717124832.GA26244@mock.linuxdev.us.dell.com> <20090717125810.GB25524@alpha.rzhou.org> Message-ID: <200907171529.47624.opensource@till.name> On Fri July 17 2009, Ricky Zhou wrote: > On 2009-07-17 07:48:34 AM, Matt Domsch wrote: > > The trick is, you can't create a bugzilla account with > > @fedoraproject.org directly for some reason. Maybe this is fixed. I > > had to create a bugzilla account with another email address, then > > request of the bugzilla administrators to change the email address for > > the account. > > Hi, are you talking about a restriction in bugzilla, or the current > limitation where FAS doesn't assign bugzilla permissions to accounts > that don't match the email address given in FAS? > > If it's the former, hopefully that's fixed now - I think I've created an > @fedoraproject.org account once at some point in the past 2 years or so I was able to create the bugzilla account using the @fpo address. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Fri Jul 17 16:33:10 2009 From: opensource at till.name (Till Maas) Date: Fri, 17 Jul 2009 18:33:10 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: References: <200907122223.32248.opensource@till.name> <200907170944.57815.opensource@till.name> Message-ID: <200907171833.17017.opensource@till.name> On Fri July 17 2009, Jon Stanley wrote: > On Fri, Jul 17, 2009 at 3:44 AM, Till Maas wrote: > > Btw. I just remembered which bot bugzilla account already exists: ftbfs - > > https://admin.fedoraproject.org/accounts/user/view/ftbfs > > There seems to be no mailing list involved, too. > > Nah, I don't much care if no one cares to see the mail. ftbfs goes to > /dev/null pretty much (actually to ftbfs at domsch.com). I can create > the requested alias, and you can create a bugzilla account with it. > It needs no special permissions to file bugs (which is all it should > be doing). Unfortunately I seem to need some special permissions, because I would like to file the bugs with status "ASSIGNED" and with Keywords "FutureFeature", because this is what the triage SIG wanted for the old FEVer bugs. If I try to set the status from "NEW" to "ASSGINED" after the bug is created, I get an error that the account does not have the necessary permissions. I also specified both when I created the bug, but both were silently not set. The first bug I created is: https://bugzilla.redhat.com/show_bug.cgi?id=512384 So I guess I need a seperate FAS account for this and apply for fedorabugs or is there some other way to do this? The ftbfs bugzilla account is capable of changing the status iirc. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Matt_Domsch at Dell.com Fri Jul 17 16:51:41 2009 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Fri, 17 Jul 2009 11:51:41 -0500 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <200907171833.17017.opensource@till.name> References: <200907122223.32248.opensource@till.name><200907170944.57815.opensource@till.name> <200907171833.17017.opensource@till.name> Message-ID: My FTBFS bugzilla account is in the 'editbugs' group in bugzilla so it can set the blocked/dependson lists. That may also be necessary to change them to ASSIGNED. You have to first file the bug as NEW, then modify it to be ASSIGNED (and set nomail=1 to avoid sending the mail on this act). -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: fedora-infrastructure-list-bounces at redhat.com [mailto:fedora-infrastructure-list-bounces at redhat.com] On Behalf Of Till Maas Sent: Friday, July 17, 2009 11:33 AM To: Fedora Infrastructure Subject: Re: Bugzilla bot account / Fedora mail alias On Fri July 17 2009, Jon Stanley wrote: > On Fri, Jul 17, 2009 at 3:44 AM, Till Maas wrote: > > Btw. I just remembered which bot bugzilla account already exists: > > ftbfs - https://admin.fedoraproject.org/accounts/user/view/ftbfs > > There seems to be no mailing list involved, too. > > Nah, I don't much care if no one cares to see the mail. ftbfs goes to > /dev/null pretty much (actually to ftbfs at domsch.com). I can create > the requested alias, and you can create a bugzilla account with it. > It needs no special permissions to file bugs (which is all it should > be doing). Unfortunately I seem to need some special permissions, because I would like to file the bugs with status "ASSIGNED" and with Keywords "FutureFeature", because this is what the triage SIG wanted for the old FEVer bugs. If I try to set the status from "NEW" to "ASSGINED" after the bug is created, I get an error that the account does not have the necessary permissions. I also specified both when I created the bug, but both were silently not set. The first bug I created is: https://bugzilla.redhat.com/show_bug.cgi?id=512384 So I guess I need a seperate FAS account for this and apply for fedorabugs or is there some other way to do this? The ftbfs bugzilla account is capable of changing the status iirc. Regards Till From ricky at fedoraproject.org Fri Jul 17 20:06:45 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Fri, 17 Jul 2009 16:06:45 -0400 Subject: New SOP: Non-human accounts Message-ID: <20090717200645.GB9004@alpha.rzhou.org> Hey, just a heads up, Toshio and I were discussing this on IRC, so we started a non-human accounts SOP at https://fedoraproject.org/wiki/Non-human_Accounts_Infrastructure_SOP It's still a draft at this point, but feel free to add instructions and policies for any account types we missed. 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 a.badger at gmail.com Fri Jul 17 20:46:03 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 17 Jul 2009 13:46:03 -0700 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: References: <200907122223.32248.opensource@till.name><200907170944.57815.opensource@till.name> <200907171833.17017.opensource@till.name> Message-ID: <4A60E30B.3000303@gmail.com> > So I guess I need a seperate FAS account for this and apply for > fedorabugs or is there some other way to do this? The ftbfs bugzilla > account is capable of changing the status iirc. > Okay, I've taken care of this in FAS. It should sync to bugzilla within the hour. If not, let me know. -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 smooge at gmail.com Fri Jul 17 22:43:20 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 17 Jul 2009 16:43:20 -0600 Subject: log1 filling up.. Message-ID: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> The majority of the logs are 8579992 ./bastion2 12937952 ./cvs2 27913380 ./secondary1 28753276 ./192.168.1.14 31164048 ./192.168.1.25 36747548 ./proxy1 59465200 ./192.168.1.7 78840240 ./proxy2 12937612 ./cvs2/2009 26187812 ./192.168.1.14/2009 27904380 ./secondary1/2009 30327316 ./proxy1/2009 30495152 ./192.168.1.25/2009 54589944 ./192.168.1.7/2009 Is it ok to compress older month logs 01/, 02/, 03/, 04, ? -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From jonstanley at gmail.com Sat Jul 18 00:31:55 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 17 Jul 2009 20:31:55 -0400 Subject: log1 filling up.. In-Reply-To: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> References: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> Message-ID: Yeah I thought that had already been done. Would rather not compress http logs from the proxies for 2009 if it can be avoided. Sorry for the top post,on my CrackBerry :) On 7/17/09, Stephen John Smoogen wrote: > The majority of the logs are > > 8579992 ./bastion2 > 12937952 ./cvs2 > 27913380 ./secondary1 > 28753276 ./192.168.1.14 > 31164048 ./192.168.1.25 > 36747548 ./proxy1 > 59465200 ./192.168.1.7 > 78840240 ./proxy2 > > > 12937612 ./cvs2/2009 > 26187812 ./192.168.1.14/2009 > 27904380 ./secondary1/2009 > 30327316 ./proxy1/2009 > 30495152 ./192.168.1.25/2009 > 54589944 ./192.168.1.7/2009 > > Is it ok to compress older month logs 01/, 02/, 03/, 04, ? > > -- > Stephen J Smoogen. > > Ah, but a man's reach should exceed his grasp. Or what's a heaven for? > -- Robert Browning > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -- Sent from my mobile device From mmcgrath at redhat.com Sat Jul 18 05:39:09 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 18 Jul 2009 00:39:09 -0500 (CDT) Subject: log1 filling up.. In-Reply-To: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> References: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> Message-ID: On Fri, 17 Jul 2009, Stephen John Smoogen wrote: > The majority of the logs are > > 8579992 ./bastion2 > 12937952 ./cvs2 > 27913380 ./secondary1 > 28753276 ./192.168.1.14 > 31164048 ./192.168.1.25 > 36747548 ./proxy1 > 59465200 ./192.168.1.7 > 78840240 ./proxy2 > > > 12937612 ./cvs2/2009 > 26187812 ./192.168.1.14/2009 > 27904380 ./secondary1/2009 > 30327316 ./proxy1/2009 > 30495152 ./192.168.1.25/2009 > 54589944 ./192.168.1.7/2009 > > Is it ok to compress older month logs 01/, 02/, 03/, 04, ? > I'd say yes. I believe 01 and 02 are already compressed. I've ack'ed the nagios alert so we won't get any more until it's either fixed or goes critical (at 10%) -Mike From opensource at till.name Sat Jul 18 07:23:10 2009 From: opensource at till.name (Till Maas) Date: Sat, 18 Jul 2009 09:23:10 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <4A60E30B.3000303@gmail.com> References: <200907122223.32248.opensource@till.name> <4A60E30B.3000303@gmail.com> Message-ID: <200907180923.26648.opensource@till.name> On Fri July 17 2009, Toshio Kuratomi wrote: > > So I guess I need a seperate FAS account for this and apply for > > fedorabugs or is there some other way to do this? The ftbfs bugzilla > > account is capable of changing the status iirc. > > Okay, I've taken care of this in FAS. It should sync to bugzilla within > the hour. If not, let me know. According to the bugzilla preferences[0], the upstream-release-monitoring account still does not have any permissions. Regards Till [0] https://bugzilla.redhat.com/userprefs.cgi?tab=permissions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Sat Jul 18 15:12:13 2009 From: opensource at till.name (Till Maas) Date: Sat, 18 Jul 2009 17:12:13 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: References: <200907122223.32248.opensource@till.name> <200907142308.33208.opensource@till.name> Message-ID: <200907181712.20634.opensource@till.name> On Tue July 14 2009, Jon Stanley wrote: > Also, have you filed an RFR to get this hosted in Fedora? Afaics[0] I need a sponsor to get it hosted in Fedora. Can and will you be the sponsor? Regards Till [0] https://fedoraproject.org/wiki/Infrastructure/RFR -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Sat Jul 18 17:39:33 2009 From: opensource at till.name (Till Maas) Date: Sat, 18 Jul 2009 19:39:33 +0200 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <4A60E30B.3000303@gmail.com> References: <200907122223.32248.opensource@till.name> <4A60E30B.3000303@gmail.com> Message-ID: <200907181939.44362.opensource@till.name> On Fri July 17 2009, Toshio Kuratomi wrote: > > So I guess I need a seperate FAS account for this and apply for > > fedorabugs or is there some other way to do this? The ftbfs bugzilla > > account is capable of changing the status iirc. > > Okay, I've taken care of this in FAS. It should sync to bugzilla within > the hour. If not, let me know. I just checked again and the permissions are now there. Strangely it is still not possible to create new bugs with status "ASSIGNED". It now returns an exception: Previously it was silently ignored. Setting them to ASSIGNED afterwards is now possible and also reporting them with the FutureFeature keyword. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Sat Jul 18 18:18:20 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 18 Jul 2009 11:18:20 -0700 Subject: Bugzilla bot account / Fedora mail alias In-Reply-To: <200907181939.44362.opensource@till.name> References: <200907122223.32248.opensource@till.name> <4A60E30B.3000303@gmail.com> <200907181939.44362.opensource@till.name> Message-ID: <4A6211EC.6010401@gmail.com> On 07/18/2009 10:39 AM, Till Maas wrote: > On Fri July 17 2009, Toshio Kuratomi wrote: >>> So I guess I need a seperate FAS account for this and apply for >>> fedorabugs or is there some other way to do this? The ftbfs bugzilla >>> account is capable of changing the status iirc. >> >> Okay, I've taken care of this in FAS. It should sync to bugzilla within >> the hour. If not, let me know. > > I just checked again and the permissions are now there. Strangely it is still > not possible to create new bugs with status "ASSIGNED". It now returns an > exception: > status.'> > Previously it was silently ignored. > Setting them to ASSIGNED afterwards is now possible and also reporting them > with the FutureFeature keyword. > Excellent. I flipped a few bits manually this morning. Let me know if you have further problems. -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 smooge at gmail.com Sat Jul 18 20:12:28 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 18 Jul 2009 14:12:28 -0600 Subject: log1 filling up.. In-Reply-To: References: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> Message-ID: <80d7e4090907181312h6c83d75bw892254935c0fd119@mail.gmail.com> On Fri, Jul 17, 2009 at 11:39 PM, Mike McGrath wrote: > On Fri, 17 Jul 2009, Stephen John Smoogen wrote: > >> The majority of the logs are >> >> 8579992 ./bastion2 >> 12937952 ? ? ? ?./cvs2 >> 27913380 ? ? ? ?./secondary1 >> 28753276 ? ? ? ?./192.168.1.14 >> 31164048 ? ? ? ?./192.168.1.25 >> 36747548 ? ? ? ?./proxy1 >> 59465200 ? ? ? ?./192.168.1.7 >> 78840240 ? ? ? ?./proxy2 >> >> >> 12937612 ? ? ? ?./cvs2/2009 >> 26187812 ? ? ? ?./192.168.1.14/2009 >> 27904380 ? ? ? ?./secondary1/2009 >> 30327316 ? ? ? ?./proxy1/2009 >> 30495152 ? ? ? ?./192.168.1.25/2009 >> 54589944 ? ? ? ?./192.168.1.7/2009 >> >> Is it ok to compress older month logs 01/, 02/, 03/, 04, ? >> > > I'd say yes. ?I believe 01 and 02 are already compressed. ?I've ack'ed the > nagios alert so we won't get any more until it's either fixed or goes > critical (at 10%) > Ok it looks like 01 and 02 are compressed with bzip2. script to compress for 03 04 ( for i in $(find ./*/2009/03/ -type f); do bzip2 -v $i; done ) &> ~/compress.logs -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From lists at jasonwalsh.us Sun Jul 19 23:59:13 2009 From: lists at jasonwalsh.us (Jason Walsh) Date: Sun, 19 Jul 2009 18:59:13 -0500 Subject: An Introduction Message-ID: Hello Fedora Infrastucture, My name is Jason Walsh, I am 16 years old and have been using GNU/Linux for about 2 years now. My first exposure to Linux was an Ubuntu 7.04 beta, and I continued using Ubuntu for several months after that. Following Ubuntu, I wanted to learn more about Linux, and switched to Arch, which I stayed on for about 10 months. Along with some friends, I currently admister an Arch Linux server on which we have deployed several Web technologies including PHP, Python, and Rails. I'm still fairly new to Fedora, only having been using it since the release of Leonidas. Already, however, I love it, as I feel it combines both ease-of-use and cutting edge software. Around the same time I started running Linux, I cut my teeth on programming with Java. Shortly after, I learned the breath of fresh air that is Python. I have been actively coding personal projects in Python for about a year now, and have contributed small amounts of code to the open-source project Crunchy. While I have mainly used Django for Web development, I have also dabbled in TurboGears and other frameworks. I want to become involved in the Fedora project because I really like the Fedora distribution itself, enjoy working on open source projects, and believe in the philosophy of free software. I feel that the infrastructure group is the place where I can be most useful to the Fedora project. This summer I am working as an intern at an IT company in their Managed Services department, doing things such as monitoring, system deployment, and image creation. (Unfortunately, with the exception of a few RHCE's, it's an entirely M$ shop). At the end of summer, I will begin my junior year in high school, which promises to be busy. However, I think I will be able to donate about 3-4 hours a week to the project. My entire "FOSS career" has been self-motivated and self-taught, and hope to continue that with the infrastrcuture project. I'm located in Middle America, Central Standard Time. My IRC nick is jpwdsm, and I'm on XMPP as jason at jabber.org. Sorry if that was a little long winded :) Thanks, Jason Walsh From ricky at fedoraproject.org Mon Jul 20 00:41:54 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 19 Jul 2009 20:41:54 -0400 Subject: An Introduction In-Reply-To: References: Message-ID: <20090720004154.GD20460@alpha.rzhou.org> On 2009-07-19 06:59:13 PM, Jason Walsh wrote: > Around the same time I started running Linux, I cut my teeth on > programming with Java. Shortly after, I learned the breath of fresh > air that is Python. I have been actively coding personal projects in > Python for about a year now, and have contributed small amounts of > code to the open-source project Crunchy. While I have mainly used > Django for Web development, I have also dabbled in TurboGears and > other frameworks. Hey, welcome - a lot of our apps are written in Python, primarily TurboGears, so that's great! If you're interested in working with those, we always have a lot of tasks on most of our web apps. We mostly hang out in #fedora-admin on Freenode if you're not there already, and we have weekly meetings in #fedora-meeting at 20:00 UTC on Thursdays (if you can make it, please come any say hi there :-)) 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 smooge at gmail.com Mon Jul 20 03:26:45 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 19 Jul 2009 21:26:45 -0600 Subject: log1 filling up.. In-Reply-To: <80d7e4090907181312h6c83d75bw892254935c0fd119@mail.gmail.com> References: <80d7e4090907171543x57d23c5fjc8dc1298203390e5@mail.gmail.com> <80d7e4090907181312h6c83d75bw892254935c0fd119@mail.gmail.com> Message-ID: <80d7e4090907192026u60ec431fv2f31c4b836d5ef8b@mail.gmail.com> On Sat, Jul 18, 2009 at 2:12 PM, Stephen John Smoogen wrote: > On Fri, Jul 17, 2009 at 11:39 PM, Mike McGrath wrote: >> On Fri, 17 Jul 2009, Stephen John Smoogen wrote: >> >>> The majority of the logs are >>> >>> 8579992 ./bastion2 >>> 12937952 ? ? ? ?./cvs2 >>> 27913380 ? ? ? ?./secondary1 >>> 28753276 ? ? ? ?./192.168.1.14 >>> 31164048 ? ? ? ?./192.168.1.25 >>> 36747548 ? ? ? ?./proxy1 >>> 59465200 ? ? ? ?./192.168.1.7 >>> 78840240 ? ? ? ?./proxy2 >>> >>> >>> 12937612 ? ? ? ?./cvs2/2009 >>> 26187812 ? ? ? ?./192.168.1.14/2009 >>> 27904380 ? ? ? ?./secondary1/2009 >>> 30327316 ? ? ? ?./proxy1/2009 >>> 30495152 ? ? ? ?./192.168.1.25/2009 >>> 54589944 ? ? ? ?./192.168.1.7/2009 >>> >>> Is it ok to compress older month logs 01/, 02/, 03/, 04, ? >>> >> >> I'd say yes. ?I believe 01 and 02 are already compressed. ?I've ack'ed the >> nagios alert so we won't get any more until it's either fixed or goes >> critical (at 10%) >> > > Ok it looks like 01 and 02 are compressed with bzip2. > > script to compress for 03 04 > > ( for i in $(find ./*/2009/03/ -type f); do bzip2 -v $i; done ) &> > ~/compress.logs > Done. Took a while longer than I expected... Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/GuestVolGroup00-root 22060924 12492712 8431280 60% / /dev/xvda1 256666 33175 210239 14% /boot tmpfs 3072000 0 3072000 0% /dev/shm /dev/xvdb1 381885660 197832520 164654484 55% /var/log We should be good for another 2 months :) > > > -- > Stephen J Smoogen. > > Ah, but a man's reach should exceed his grasp. Or what's a heaven for? > -- Robert Browning > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From smooge at gmail.com Mon Jul 20 03:34:37 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 19 Jul 2009 21:34:37 -0600 Subject: Cron /bin/rpm -Va --nofiles --nomd5 In-Reply-To: <20090719000007.C2EBA1AF3CB@log1.fedora.phx.redhat.com> References: <20090719000007.C2EBA1AF3CB@log1.fedora.phx.redhat.com> Message-ID: <80d7e4090907192034k1174cd51k7c3a28051a3d2e39@mail.gmail.com> Fixed install sudo yum install audit-libs.i386 Box has a lot of i386 installed on it. On Sat, Jul 18, 2009 at 6:00 PM, Cron Daemon wrote: > Unsatisfied dependencies for pam-0.99.6.2-4.el5.i386: libaudit.so.0 > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From ricky at fedoraproject.org Mon Jul 20 04:13:41 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Jul 2009 00:13:41 -0400 Subject: MirrorManager crawler patch Message-ID: <20090720041341.GF20460@alpha.rzhou.org> Hey, I think we might have found a bug in the mirror crawler where it did not do the repomd sha256sum check if a mirror is checked via FTP. I think the crawler might still need a good bit of cleanup apart from this, but here is an initial attempt at a patch to fix this: http://ricky.fedorapeople.org/mirrormanager/0001-Check-sha256sum-of-repomd.xml-on-FTP-mirrors.patch I did some testing of this against fedora.bu.edu on bapp1 and it seemed to mark the F10/F11 repodata directories outdated as expected. Given the mirror issues that we've been havin recently, it might be worth considering live patching this until the next mirrormanager release. 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 Jul 20 04:28:34 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Jul 2009 00:28:34 -0400 Subject: MirrorManager crawler patch In-Reply-To: <20090720041341.GF20460@alpha.rzhou.org> References: <20090720041341.GF20460@alpha.rzhou.org> Message-ID: <20090720042834.GG20460@alpha.rzhou.org> On 2009-07-20 12:13:41 AM, Ricky Zhou wrote: > Hey, I think we might have found a bug in the mirror crawler where it > did not do the repomd sha256sum check if a mirror is checked via FTP. I > think the crawler might still need a good bit of cleanup apart from > this, but here is an initial attempt at a patch to fix this: > > http://ricky.fedorapeople.org/mirrormanager/0001-Check-sha256sum-of-repomd.xml-on-FTP-mirrors.patch I just took a closer look at this with Matt, and it turns out that my extra code in this patch shouldn't be necessary (and in fact, doesn't seem to run at all). I'm going to look at testing this more on another outdated site. 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 Jul 20 05:27:11 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Jul 2009 01:27:11 -0400 Subject: MirrorManager crawler patch In-Reply-To: <20090720042834.GG20460@alpha.rzhou.org> References: <20090720041341.GF20460@alpha.rzhou.org> <20090720042834.GG20460@alpha.rzhou.org> Message-ID: <20090720052711.GH20460@alpha.rzhou.org> On 2009-07-20 12:28:34 AM, Ricky Zhou wrote: > I just took a closer look at this with Matt, and it turns out that my > extra code in this patch shouldn't be necessary (and in fact, doesn't > seem to run at all). I'm going to look at testing this more on another > outdated site. Hi, Matt and I just spoke on IRC more, and I think we have a slightly better idea of the issue now. I think mirrormanager returning outdated mirrors might have actually been related to the mounts issue as well. One issue that we realized was that for F10 updates, yum uses a URL similar to http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch to generate the directory to get repodata from. However, this returns the path to pub/fedora.redhat/linux/updates/10/x86_64 on mirrors, and while that may be up to date (since mirrormanager only checks the 10 newest files in that directory, and the recent timestamp issues may have made this test unreliable), the pub/fedora.redhat/linux/updates/10/x86_64/repodata may not be. In the case of the bu mirror, we found that pub/fedora.redhat/linux/updates/10/x86_64/repodata was properly marked outdated, but pub/fedora.redhat/linux/updates/10/x86_64 was not. Another issue that Matt mentioned is that report_mirror will tell mirrormanager to mark any directory that the site claims to have as up2date, the idea being that mirrors run rsync && report_mirror. This does seem to be cause issues during mass mirror issues like this though, and Matt also brought up the issue that some mirrors may run report_mirror even if the rsync fails. Some issues/responses we discussed: 1) For the first issue, we need to mark an entire repository outdated if the repodata is outdated. This should start happening properly as well now that the timestamps issue is fixed, although we can do this explicitly in the code as well. 2) MirrorManager currently doesn't check timestamps, and the solution to this isn't trivial, especially since with FTP, which returns directory listing data as just the text of the output. This is almost impossible to parse accurately, especially when time zones are involved, and when time zone data isn't even returned by FTP. 3) Perhaps it could be good to change some behavior with report_mirror. Right now, when public mirrors run it, it gives the benefit of starting to send traffic to the mirror as soon as possible after syncing, but in situations like the current one, this behavior can lead to outdated mirrors being marked up2date in MirrorManager. 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 bruno at wolff.to Mon Jul 20 14:34:47 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 20 Jul 2009 09:34:47 -0500 Subject: MirrorManager crawler patch In-Reply-To: <20090720052711.GH20460@alpha.rzhou.org> References: <20090720041341.GF20460@alpha.rzhou.org> <20090720042834.GG20460@alpha.rzhou.org> <20090720052711.GH20460@alpha.rzhou.org> Message-ID: <20090720143447.GA1590@wolff.to> On Mon, Jul 20, 2009 at 01:27:11 -0400, Ricky Zhou wrote: > 2) MirrorManager currently doesn't check timestamps, and the solution to > this isn't trivial, especially since with FTP, which returns > directory listing data as just the text of the output. This is > almost impossible to parse accurately, especially when time zones are > involved, and when time zone data isn't even returned by FTP. Maybe you could check a hash of the repomd.xml file? You shouldn't have to track too many different hashes. From ricky at fedoraproject.org Mon Jul 20 15:32:51 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 20 Jul 2009 11:32:51 -0400 Subject: MirrorManager crawler patch In-Reply-To: <20090720143447.GA1590@wolff.to> References: <20090720041341.GF20460@alpha.rzhou.org> <20090720042834.GG20460@alpha.rzhou.org> <20090720052711.GH20460@alpha.rzhou.org> <20090720143447.GA1590@wolff.to> Message-ID: <20090720153251.GJ20460@alpha.rzhou.org> On 2009-07-20 09:34:47 AM, Bruno Wolff III wrote: > > 2) MirrorManager currently doesn't check timestamps, and the solution to > > this isn't trivial, especially since with FTP, which returns > > directory listing data as just the text of the output. This is > > almost impossible to parse accurately, especially when time zones are > > involved, and when time zone data isn't even returned by FTP. > > Maybe you could check a hash of the repomd.xml file? You shouldn't have to > track too many different hashes. For what it's worth, this hash checking already happens on repomd.xml files for mirrors that are crawled via HTTP, and my patch added that check to FTP mirrors as well. When talking on IRC with Matt, we realized that the check shouldn't be necessary at all though, since the other files in the repodata are successfully getting the repodata directory marked outdated (and we did confirm that this was happening with the last bu mirror crawl). Overall, I think the crawling has been working fine even without the timestamp checking (apart from some issues caused by the timestamp problem we recently saw), I just wanted to mention why that was currently disabled. As another side note, mirrormanager is currently aware of what directories are repositories: < mdomsch> sure < mdomsch> so, MM does know that that dir is a repository < mdomsch> class Directory: repository = SingleJoin('Repository') < mdomsch> bu the crawler doesn't do anything special with that knowledge < mdomsch> perhaps it should < mdomsch> by definition, a Repository is a Directory that has a child directory named 'repodata' < mdomsch> but the whole directory tree starting at that Directory down, is part of the repository So all of the framework should be in place for marking an entire repository out of date if the repodata is out of date. 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 Tue Jul 21 17:05:16 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 21 Jul 2009 13:05:16 -0400 Subject: Fedora Community Post-mortem meeting log Message-ID: <20090721170516.GA25342@alpha.rzhou.org> 16:30 < mmcgrath> #startmeeting 16:30 < zodbot> Meeting started Tue Jul 21 16:30:32 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30 < mmcgrath> abadger1999: ping 16:30 < mmcgrath> rishi: ping 16:30 < mmcgrath> err 16:30 < mmcgrath> ricky: ping 16:30 < mmcgrath> rishi: sorry 16:30 < abadger1999> yep. 16:30 < mmcgrath> lmacken: ping 16:30 < ricky> pong 16:30 < mmcgrath> spot: ping 16:30 < mmcgrath> J5: ping 16:30 -!- tc141516 [i=blewis at fedora/tc1415] has joined #fedora-meeting 16:31 < J5> pong 16:31 -!- Viking-Ice [n=johannbg at valhalla.rhi.hi.is] has quit "Ex-Chat" 16:31 -!- nixdude [n=jhp at pool-70-109-10-41.atl.dsl-w.verizon.net] has joined #fedora-meeting 16:31 -!- Viking-Ice [n=johannbg at valhalla.rhi.hi.is] has joined #fedora-meeting 16:31 * spot is here 16:31 -!- drago01 [n=linux at chello062178124130.3.13.univie.teleweb.at] has joined #fedora-meeting 16:31 * nixdude 1s too 16:32 < mmcgrath> I've not seen lmacken today so I'll assume he's not able to make it. 16:32 < mmcgrath> So this meeting's just a quick round up of what happened during the fedora community deployment, trying to shake out some communication issues, and hopefully clear up any misunderstandings. 16:32 < mmcgrath> or missed emails or notifications or anything 16:32 < mmcgrath> We have a hard stop in 30 minutes when the packaging committee meets and I hope it won't go anywhere near that long. 16:33 < mmcgrath> There's two main points of contention that I know of 16:33 < mmcgrath> 1) deployment times/expectations and 2) is the very late in the game license change. 16:33 < mmcgrath> anyone have anything they'd like to add to that? 16:33 < abadger1999> General communication is an issue but could be talked about some other time. 16:33 < mmcgrath> K, so I'll knock 1) out because I think it's more straight forward then 2) 16:33 < mmcgrath> yeah 16:34 < mmcgrath> So around the F10 launch, just a day or so before the launch J5 came to me asking for fedora community to be deployed. 16:34 < smooge> ok here I am 16:34 < ricky> s/10/11 :-) 16:34 < mmcgrath> We didn't know much about it at that time 16:34 < mmcgrath> ricky: this was F10 16:34 < ricky> Oh, wow, my mistake :-) 16:34 -!- neverho0d [n=psv at 62.68.142.214] has quit Read error: 110 (Connection timed out) 16:34 < mmcgrath> it was in our final freeze and I made it known that it was just not possible to deploy it at that time. 16:34 < mmcgrath> that final 2 week freeze is critical 16:35 < mmcgrath> So flash forward to F11. 16:35 < mmcgrath> We had a few minor issues when deploying to test, 16:35 < mmcgrath> we got it ready in staging. 16:35 < mmcgrath> but at no point in time did I have a date for when this was to go live. 16:35 < mmcgrath> Now, on the F11 release date, lmacken told me that it was to go live that day and that spot said so. 16:35 < mmcgrath> This put me in a horribly ackward position. 16:36 < mmcgrath> spot is very much one of us, but he's also the boss (both my manager and the Fedora Project Engineering lead) 16:36 < spot> So, we definitely had a communication breakdown here. 16:36 -!- stickster is now known as stickster_food 16:36 < spot> In our Fedora Community meetings, I repeatedly asked luke to make sure you knew about our schedule 16:37 < spot> I'm not sure where it fell apart, but we definitely can do better. 16:37 < mmcgrath> So if it was just a communications breakdown (that happens) then there's not much else to discuss on it. We'll just all be more careful next time. 16:37 < mmcgrath> There were also some announcements that went out about it being live before it was actually live 16:37 < spot> Yeah, we had every intent of giving you advance notice. 16:37 -!- shepherd [n=shepherd at unaffiliated/shepherd] has quit Read error: 60 (Operation timed out) 16:37 < mmcgrath> but I don't think those were public 16:38 -!- sm|test-1ox [n=morpheus at 209.132.186.254] has joined #fedora-meeting 16:38 < spot> mmcgrath: yeah, that was because it was mentioned in the early F11 interviews 16:38 -!- runa_b [n=runab at 209.132.186.254] has joined #fedora-meeting 16:38 < mmcgrath> 16:38 < spot> before the instance was live 16:38 < J5> It partly has to do with not being clear on what checkmarks need to be hit to get things deployed. What do you do to get it into staging and then what was needed after things were in staging to say ok it is good to go 16:38 -!- paragn_ [n=paragn at 209.132.186.254] has joined #fedora-meeting 16:38 -!- shepherd [n=shepherd at unaffiliated/shepherd] has joined #fedora-meeting 16:39 < mmcgrath> so one note I think I'd like to make more clear (not related to fedora community directly) is that maybe we should have a more clear feature process similar to the OS. 16:39 < mmcgrath> our livecycle is very tied to the Fedora releases. 16:39 < J5> agreed 16:39 < abadger1999> J5: Partly but not all -- we would not make a new app go-live date coincide with the release date no matter what. 16:39 < mmcgrath> and I think we're starting to get into a little groove where stuff that gets deployed is related to the Fedora release (start.fedoraproject.org, mirrorlist, etc) all could directly impact users. 16:39 < abadger1999> We could announce it was live on that date but it would have already been deployed on the production instance long before that date.... just the announcement would coincide. 16:40 -!- runab__ [n=runab at 209.132.188.254] has joined #fedora-meeting 16:40 < spot> abadger1999: sure. that makes sense. 16:40 -!- paragn__ [n=paragn at 209.132.188.254] has joined #fedora-meeting 16:40 -!- sm|test-box [n=morpheus at fedora/sankarshan] has quit Read error: 104 (Connection reset by peer) 16:40 < mmcgrath> Ok, so does anyone have anything else on the deployment thing? It seems we all agree communication could be better and I don't think anyone is against a better documented Fedora-Infrastructure -> Fedora (OS) lifecycle 16:41 < mmcgrath> Ok, 16:41 -!- azneita [n=azneita at 121.97.142.237] has quit Remote closed the connection 16:41 < mmcgrath> the next bit is the licensing. 16:41 < mmcgrath> which has come under more light over the last couple of meetings. 16:41 -!- paragn [n=paragn at fedora/paragn] has quit Read error: 60 (Operation timed out) 16:41 < mmcgrath> in particular things like hot patching concern me as an operations guy. 16:42 < mmcgrath> I'm still learning how the agpl will affect us 16:42 -!- giallu [n=giallu at fedora/giallu] has quit Read error: 60 (Operation timed out) 16:42 < mmcgrath> So what happened there? Is it too late to go back and release it under a GPL license? 16:42 < spot> well, we really want it under the AGPL 16:43 < spot> the reason we didn't use the GPL is because the GPL is not a good fit for web apps 16:43 -!- runa_b [n=runab at 209.132.186.254] has quit Read error: 60 (Operation timed out) 16:43 -!- sm|test-box [n=morpheus at 209.132.188.254] has joined #fedora-meeting 16:43 < spot> we wanted to encourage people to use the FC/moksha code, but we also want to get back improvements 16:43 < mmcgrath> who's "we", because it's not the infrastructure team. AGPL means a lot more process, and higher barriers to running this app then before. 16:43 < spot> under the GPL, someone (*cough*google*cough*canonical*cough*) could take moksha and FC, make a ton of changes, and run it 16:44 < spot> without any requirement that they share their fixes, or changes, or anything 16:44 < mmcgrath> and that's a problem for who? 16:44 < mmcgrath> it's just not something we wanted to allow them to do? 16:44 < abadger1999> spot: Did you get the email I sent you: I believe Subject: Licensing Part II ? 16:44 < spot> we want to be able to get those fixes 16:44 < spot> and encourage open development 16:44 < mmcgrath> spot: I have to be honest, the license in mokesha will probably prevent me from ever using it in any of my projects. 16:44 < abadger1999> spot: we == moksha & Fedora Community. 16:44 < spot> mmcgrath: why exactly? 16:45 < mmcgrath> it's just too much of a pain to comply with. especially from an operations point of view. 16:45 < spot> mmcgrath: really? a url to fixes is too much of a pain? 16:45 < mmcgrath> I can't just go in and make a change. 16:45 < jwb> mmcgrath, maybe if you state your concerns first, it might help 16:45 < mmcgrath> spot: a week ago mirrormanger broke and I had a pot on the stove. 16:45 < abadger1999> jwb: The concerns were in the Licensing Part II email. 16:45 < mmcgrath> It took a couple of seconds to fix. 16:45 < jwb> abadger1999, ok 16:45 < spot> mmcgrath: to comply with the AGPL, you just need to have a link to the source that is running. 16:46 < mmcgrath> that couple of seconds, takes much longer when I have other stuff to do with linking to this or that and publishing, etc. 16:46 < spot> that could be a link to the base source control and a link to the hotfixes 16:46 < mmcgrath> except none of our code currently does that. 16:46 < abadger1999> spot: I think infra needs to know more about what compliance to the AGPL means in order to understand how costly/inexpensive it is to comply. 16:46 < spot> honestly, you should be tracking your hotfixes anyways 16:46 < jwb> spot, that is sort of orthogonal 16:46 < spot> no, not really 16:46 < mmcgrath> awhat about config files? 16:47 < spot> mmcgrath: config files aren't code. 16:47 < jwb> yes, sure. but if they don't right now, they aren't violating a license 16:47 < mmcgrath> additionally if I worked at either of the last two places I worked with, they'd immediatly say no to using it. 16:47 < ricky> With something like mod_wsgi, code and configuration can be very mixed at times. 16:47 < mmcgrath> just because of that. 16:47 < ricky> But I think the bigger concern is exactly how we have to link to hotfixes 16:47 < abadger1999> spot: But they're in the tarball along with the code and the only license in the tarball is AGPLv3. 16:47 < J5> A lot of people say no to GPL 16:47 < spot> mmcgrath: because they ran proprietary web apps 16:47 < spot> we don't. 16:47 < abadger1999> So how do we differentiate. 16:47 < J5> because of the same reasons 16:47 < abadger1999> J5: Yeah, once of the infra developers does, in fact. 16:47 < mmcgrath> spot: they also ran open source apps, it took a long time to get them to do it. 16:48 < mmcgrath> now imagine if the barrier to using those apps was even higher. 16:48 * abadger1999 notes meeting reaches halfway point. 16:48 < spot> abadger1999: well, we've never been that anal about configs in any other fedora package 16:48 < spot> abadger1999: but we can explicitly relicense the configs if it helps people sleep at night 16:48 < abadger1999> spot: We've never had a license that might require us to release them. 16:48 < smooge> spot, config files may be code depending on how they are implemented and if the file has a "AGPL" header in it. I couldn't find an exclusion to config files in the AGPL :/ 16:49 < mmcgrath> I'm not talking about developing code, I'm talking about very practical operations issues. 16:49 < spot> abadger1999: thats not true, there are plenty of licenses that could be interpreted that way 16:49 < J5> I personally think LGPL would make sense in some of the code in Moksha 16:49 < smooge> spot, I am not against the AGPL, I just want to make sure we have a process in place so that we know the following: 16:49 < spot> mmcgrath: the issue is this, you need to make the code that is running available. 16:49 -!- sassmann [n=sassmann at g229133070.adsl.alicedsl.de] has quit Read error: 113 (No route to host) 16:49 < abadger1999> spot: We just need to know what the rules are for compliance. If there's some escape hatch built into the code vs config that says configs are uncopyrightable therefore they are freely copyable/do not fall under AGPL, that's fine. 16:49 < spot> to the user of the web app 16:49 -!- jeff_hann [n=arares at 188.24.37.69] has quit "Leaving" 16:49 < mmcgrath> spot: and alter the webapp to point at it. 16:50 < spot> well, the webapp can point to a directory or a git tree or a url where source can be found 16:50 < smooge> a) How do we run in staging. Who are the 'customers' we need to publish the code for. {If some joe comes across it do we have to show them the exact code at that moment?} 16:50 -!- rishi [n=rishi at gnu-india/supporter/debarshi] has quit "Ex-Chat" 16:50 < ricky> One thing we were concerned about is how we need to link to hotfixes. 16:50 < spot> it doesn't have to be an explicit link 16:50 < spot> you just have to be able to get it from there 16:50 < abadger1999> spot: Are you talking Fedora or Fedora Infra? 16:50 * spot sighs 16:50 < ricky> OK, and what about what smooge said? Does this entire process need to be followed for our staging environment too just because it's web accessible? 16:50 < spot> this is a royal pain to do over irc. 16:50 < mmcgrath> but git trees and directories don't come out of thin air. We have to put them somewhere, we have to back them up 16:50 < mmcgrath> etc, etc. 16:50 -!- jeff_hann [n=arares at 188.24.37.69] has joined #fedora-meeting 16:51 < mmcgrath> spot: imagine being legally liable for it. 16:51 < J5> ricky: why wouldn't a hotfix go into version control and the app be packaged first? 16:51 < spot> mmcgrath: guess what, i am. ;) 16:51 < smooge> spot I agree. I will send my problems via email and we can work out a process there. 16:51 < spot> no, lets try this again. 16:51 < spot> the webapp 16:51 < spot> has to have a link to the source of the code it is running 16:51 < spot> thats it. 16:51 < jwb> and if someone hotfixes a python bit that's live? 16:51 < mmcgrath> and the benefit to us is now canonical and google won't use mokesha? 16:51 < spot> that link can go to a page that says "here is the base git" and "here is a directory that contains any hotfixes we have applied" 16:52 < J5> mmcgrath: launchpad was just AGPL'ed 16:52 < ricky> J5: In staging, it probably should, but we use staging for debugging as well. One thing I did recently was write some debugging middleware for FAS in staging and leave that running for a few days 16:52 * mmcgrath writes down another reason not to use launchpad. 16:52 < nixdude> lol 16:52 < mmcgrath> I really don't like the AGPL and here's why. It protects the developer at the cost of the user. 16:52 < spot> honestly, i'm starting to get a little pissed off at the AGPL hate here. 16:53 < spot> you should be tracking your damn hotfixes anyway 16:53 < abadger1999> spot: People don't understand the AGPL. 16:53 < spot> and if you're doing that, its trivial to put up a link to them 16:53 < mmcgrath> spot: but having to do so in public is a higher burden then you think it to be. 16:53 < mmcgrath> from your point of view we don't get it 16:53 < spot> mmcgrath: if you're doing it right, you have nothing to fear. 16:53 < mmcgrath> from our point of view you don't get it. 16:53 < J5> mmcgrath: actually it protects users at the cost of the developers - you said it yourself, you are afraid of what it will cost us to do hotfixes but it allows users to not be locked in 16:53 < spot> if you're doing it wrong, you have more to fear than AGPL clauses 16:53 < abadger1999> Without understanding, people don't know what they can implement to comply and how much time that will take; what changes will be needed. 16:54 < abadger1999> https://www.redhat.com/archives/fedora-infrastructure-list/2009-July/msg00094.html 16:54 < spot> abadger1999: you can implement it pretty much any way you want as long as the user can get the source that is running 16:54 < ricky> https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7Ehotfix&order=priority 16:54 < smooge> well ok lets try a different tack. what we need to do to properly track changes: 16:54 < mmcgrath> spot: you mean as long as the developer can get the source that is running right? 16:54 < spot> mmcgrath: no, the user of the webapp 16:54 < spot> any user of the webapp 16:55 < abadger1999> That's the summary of questions people asked at the last infra meeting about AGPL. 16:55 < mmcgrath> spot: and if the webapp doesn't have some way to do that we have to constantly patch the app to do it? 16:55 < spot> thats why FC has a link at the bottom of the page 16:55 * abadger1999 notes we are down to 7 minutes. 16:55 < mmcgrath> spot: but none of that links to where we track bugs 16:55 < spot> mmcgrath: then fix the webapp so it doesn't. 16:56 * mmcgrath doesn't think s/AGPL/GPL/ is legal though :) 16:56 < lmacken> Hey guys, sorry I'm late :) 16:56 < spot> mmcgrath: if you say "we put hotfixes for FC and moksha ", we'll link to it. 16:56 * lmacken wsa thinking it was at 13:00 16:56 < spot> and we're compliant 16:56 < mmcgrath> spot: and from your poitn of view, as someone that doesn't actually have to do that work, it seems trivial doesn't it? 16:56 < abadger1999> spot: I was wondering if that covers us or not -- it doesn't link to the version of code that we're running.... even with hotfixes. 16:56 -!- mishti [n=runab at 209.132.188.254] has quit No route to host 16:56 < abadger1999> But once again, that was once of the questions in the email. 16:56 < ricky> lmacken: Hey, I have a bodhi question for you after this meeting if you'll be around 16:56 < spot> abadger1999: legal says it does cover us because the code we're running is there. 16:56 < mmcgrath> so what, we just copy the file into puppet, alter it, and hope upstream doesn't change it? 16:56 < abadger1999> spot: But it's not. 16:57 -!- sm|test-1ox [n=morpheus at 209.132.186.254] has quit Read error: 110 (Connection timed out) 16:57 -!- paragn_ [n=paragn at 209.132.186.254] has quit Connection timed out 16:57 < lmacken> ricky: ok 16:57 < spot> abadger1999: how is it not there? we're linking to git 16:57 -!- mcepl [n=mcepl at 49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has joined #fedora-meeting 16:57 < abadger1999> spot: There's code i nthe moksha/fedoracommunity repo -- but it's not necessarily what we're running. 16:57 < spot> abadger1999: the code that we're running is in git. 16:58 < spot> unless one of you applied hotfixes without telling lmacken or J5 16:58 < J5> abadger1999: you can get to the revision 16:58 < ricky> what if mmcgrath finds a security bug in fcomm and doesn't have commit access? 16:58 < spot> or without checking it into git 16:58 < abadger1999> spot: Where? What revision? 16:58 -!- cassmodiah [n=cass at fedora/cassmodiah] has quit Read error: 110 (Connection timed out) 16:58 < abadger1999> What tag/branch/etc 16:58 < spot> abadger1999: i'm pretty sure "HEAD" is the answer 16:58 < ricky> I can see this being painful when it happens that we aren't upstream, or that we're not directly involved in development 16:58 -!- nim-nim [n=nim-nim at fedora/nim-nim] has quit Read error: 104 (Connection reset by peer) 16:59 < spot> abadger1999: and even if it wasn't, legal said it was sufficient to point to git 16:59 < abadger1999> spot: So even though we aren't running HEAD, it's sufficient to point to HEAD? 16:59 * mmcgrath notes 1 minut left 16:59 < spot> abadger1999: as long as the code we're running is actually in git 16:59 < jwb> they are telling you it's not 16:59 < spot> now, if you guys have a directory or a git repo or something 16:59 < spot> where you store hotfixes 16:59 < abadger1999> spot: k. So we don't need to point to our hotfixes either as long as they've been checked into some branch in git at some point? 16:59 < spot> we can link to that too 17:00 < abadger1999> Even if they've later been reverted, etc? 17:00 < spot> and we're compliant 17:00 < spot> yeah, sure. 17:00 < abadger1999> Excellent. 17:00 < mmcgrath> ugh 17:00 < mmcgrath> what a pita 17:00 < ricky> So what do we do for cases where we don't have commit access like the one I mentioned above? 17:00 < spot> you're making a mountain out of a molehill here. 17:00 < mmcgrath> Ok, we're at the stop point guys, sorry. We said hard stop so we're going to hard stop. 17:00 < mmcgrath> spot: you don't have to live with the consequences of this decision. 17:00 * mmcgrath does 17:00 < abadger1999> spot: System admins have to understand the worse case scenarios. 17:01 < mmcgrath> #stopmeeting 17:01 < mmcgrath> #meetingstop 17:01 < mmcgrath> it's one of those 17:01 < ricky> #endmeeting 17:01 < nirik> (endmeeting) 17:01 < ricky> (But you have to do it) 17:01 < mmcgrath> #endmeeting 17:01 < zodbot> Meeting ended Tue Jul 21 17:01:25 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 17:01 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora-meeting.2009-07-21-16.30.html 17:01 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora-meeting.2009-07-21-16.30.txt 17:01 < mmcgrath> there we go 17:01 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora-meeting.2009-07-21-16.30.log.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Tue Jul 21 17:09:04 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Jul 2009 10:09:04 -0700 Subject: Relicensing Part II (redux) Message-ID: <4A65F630.8080907@gmail.com> Resending since spot didn't get it the first time. Okay, at the infrastructure meeting this week we had a long discussion about using AGPL in infrastructure and we decided we need more information about what the AGPL requires of us. Here's a run down and then the questions we had. == What we decided == We arrived at a few conclusions with the amount of knowledge we currently have: * Continue to deploy as rpms to production and as the basis of staging. * In production, hotfixes need to have tickets in trac (this is current policy). Those tickets may be required to contain patches applied to the server if we determine that's the best course under legal. - If that's not the best course, hotfix tickets still need to contain an indication of what the hotfix does but this could be "I reverted commit 12345" or "I changed three files to import simplejson instead of json (python-2.4 compatibility)" * In staging, we want to deploy with a base rpm and may add patches and local changes on top of that to test things. When we get to the point where we are satisfied, this needs to be turned into an rpm and be deployed to production/installed in the staging env. * In publictest, we want people to be able to deploy from SCM, make local changes, etc. publictest are pure development machines. == Explain the linking requirements == How the running app leads people to the source for the app is causing the most concerns. Here's a list of questions. There's a lot because we don't have a feel for what's allowed and not allowed yet. Where relevant, assume that the running applications have rpms/srpms present on infrastructure.fedoraproject.org, an upstream trac/scm instance on fedorahosted.org, and that we are running with some number of hotfixes to the live application. * Do we need to link to the source from every page of the app? * What are legal means of giving people access to the corresponding source? + Source repository at no particular version (assuming all of our patches are applied to trunk -- and trunk might contain other changes as well, including full or partial reversions of those changes in a later revision) + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) + Pointing exactly to source repository branch or tag of the exact version we're running + Home page of the project (example: http://fedorahosted.org/fas) + Just a page specifically linking to the sources and all of the patches we've applied + links to base srpm and page listing patches + links to base srpm and tickets in trac that have patches attached + links to base srpm and tickets in trac that point to commits in SCM that are applied against different versions (HEAD vs the last release, for instance) + A page linking to the sources and a page linking to any hotfixes we've applied to any of our apps (ie, a query in infrastructure's trac that gets all hotfixes for all of our apps). + I'm assuming these to be fine: tarball, srpm that matches what's running, actual links to base tarball and to all of the patches * Do config changes count as code changes if the config file is marked as being AGPL? - If yes, what do we have to do to make config files not be licensed under AGPL? (We want to keep passwords private, for instance). == Related to Other Apps == Our original impetus for relicensing is so we can freely share code with fedoracommunity. The cost of maintaining AGPL compliance with other apps needs to be weighed against the cost of reinventing code in fedoracommunity (or waiting for fedoracommunity developers to relicense their code for use elsewhere *cough CSRF middleware cough* :-) ). * Is it really "absolutely critical" that fedoracommunity be AGPL? * Can we get a clarification of what the consequences would be if fedora community stays AGPL but our apps stay as they are (GPLv2)? == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """ Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. """ * Is the preamble legally binding/part of the AGPL or should we ignore anything there? * admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself? * If we can run apps in staging without providing source to those without shell accounts there, can we also run apps on publictest boxes without providing source to those without shell accounts there? .. _[1]: Meeting Minutes http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2009-07-16-20.00.html .. Proposed Guidelines: https://fedoraproject.org/wiki/Infrastructure_Licensing -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 tmz at pobox.com Thu Jul 23 15:59:06 2009 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 23 Jul 2009 11:59:06 -0400 Subject: Checking / fixing permissions on hosted git projects Message-ID: <20090723155906.GX4338@inocybe.localdomain> Hey all, Every so often we've had problems with uses having permissions problems in git repos on hosted. This is less of an issue over the past few months as we backported a patch from upstream git to ensure that git sets the permissions properly as well as setting the right permissions with the gitsetup.sh script when creating new repos?. ? Except for the minor issue that it issues a mildly overly broad 'chmod -R g+w .' -- which makes any files in the objects tree group writable even though they are not intended nor required to be writable by anyone. Objects are read only for git. To help ensure that we don't end up with any new permissions problems I whipped up a git-check-perms script which might be useful to run as a cron job once a daily or even weekly. It should alert us to any new problems with git or with our setup/import scripts. It can also be used to correct any problems found, after we've looked into what caused them, of course. The script is in ~tmz/bin/git-check-perms on hosted1. Before the output of this is clean and suitable for a cron job, there are a few minor things that should be fixed. Mostly this is fixing files in the objects dir that have unneeded write permissions. There are also a few config and commit-list files that would get group write permissions added. Neither of these things cause any real problems, but they differ from how we'd like to setup and import git projects, so making them consistent will make things simpler all around. The list of changes the script would make is attached. If anyone has a moment to check that it looks sane, that would great. The short list of non-objects dir issues is: /git/Virtualization_Guide.git/commit-list: Not group writable (should be "0664") /git/augeas.git/commit-list: Not group writable (should be "0664") /git/collie.git/commit-list: Not group writable (should be "0664") /git/comps-extras.git/logs: Not SETGID (should be "02775") /git/comps-extras.git/logs/refs: Not SETGID (should be "02775") /git/comps-extras.git/logs/refs/heads: Not SETGID (should be "02775") /git/docs/install-guide.git/config: Not group writable (should be "0664") /git/docs/release-notes.git/config: Not group writable (should be "0664") /git/fastback.git/commit-list: Not group writable (should be "0664") /git/grubby.git/commit-list: Not group writable (should be "0664") /git/grubby.git/config: Not group writable (should be "0664") /git/moksha.git/commit-list: Not group writable (should be "0664") /git/pam_url.git/config: Not group writable (should be "0664") /git/piranha.git/commit-list: Not group writable (should be "0664") /git/simon.git/commit-list: Not group writable (should be "0664") /git/sssd.git/commit-list: Not group writable (should be "0664") -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Becoming aware of my character defects leads me naturally to the next step of blaming my parents. -------------- next part -------------- A non-text attachment was scrubbed... Name: git-perms.gz Type: application/x-gzip Size: 41006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From nb at fedoraproject.org Thu Jul 23 16:16:39 2009 From: nb at fedoraproject.org (Nick Bebout) Date: Thu, 23 Jul 2009 12:16:39 -0400 Subject: blogs.fedoraproject.org Update Message-ID: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> This is just a quick note to update everyone on the status of blogs.fedoraproject.org We have the FAS authentication plugin working, puppet set up, and are now working on installing and testing a spam filter plugin, currently we are testing bad behavior. As soon as this is done we plan to deploy it. Nick From jx.serrano at gmail.com Thu Jul 23 16:37:30 2009 From: jx.serrano at gmail.com (Julius Serrano) Date: Fri, 24 Jul 2009 00:37:30 +0800 Subject: Introduction Message-ID: <6cc649e10907230937x6d38d2deod722cb90b9ae90bd@mail.gmail.com> Hi, I am Julius Serrano and I've been using linux for quite some time now. I started with red hat 6.0 but I had most of my experiences with RH7.2, RH9.0, RHEL4 and RHEL5. I am a programmer and a systems and database administrator by profession. I have skills with Python (which is my language of choice), PHP and Java, although my Python web framework experience mostly come from Zope. Programming is my main passion but I also have administration skills. My sysadmin experience cover NIS, LDAP, NFS, Samba, some Postfix, some Xen failover clustering, and some DRBD. I also have experience with the administration of Apache, Nagios, CVS and Subversion. As for being a db admin, I manage MySQL databases including their replication. I want to be involved in the Fedora project and I hope to somehow contribute something, in one way or another, to F12. Right now, I am mostly trying to familiarize myself on things and the meeting later would probably give me a good start. Thank you very much. Cheers, Julius Serrano -------------- next part -------------- An HTML attachment was scrubbed... URL: From davivercillo at gmail.com Thu Jul 23 16:47:02 2009 From: davivercillo at gmail.com (Davi Vercillo C. Garcia) Date: Thu, 23 Jul 2009 13:47:02 -0300 Subject: Introduction In-Reply-To: <6cc649e10907230937x6d38d2deod722cb90b9ae90bd@mail.gmail.com> References: <6cc649e10907230937x6d38d2deod722cb90b9ae90bd@mail.gmail.com> Message-ID: Hi, Welcome ! Bye, -- Davi Vercillo C. Garcia Fedora Project Contributor https://fedoraproject.org/wiki/User:davivercillo Federal University of Rio de Janeiro Department of Computer Science DCC-IM/UFRJ http://www.dcc.ufrj.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricky at fedoraproject.org Thu Jul 23 17:00:06 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 23 Jul 2009 13:00:06 -0400 Subject: Introduction In-Reply-To: <6cc649e10907230937x6d38d2deod722cb90b9ae90bd@mail.gmail.com> References: <6cc649e10907230937x6d38d2deod722cb90b9ae90bd@mail.gmail.com> Message-ID: <20090723170006.GH5734@alpha.rzhou.org> On 2009-07-24 12:37:30 AM, Julius Serrano wrote: > I am? Julius Serrano and I've been using linux for quite some time now. I > started with red hat 6.0 but I had most of my experiences with RH7.2, RH9.0, > RHEL4 and RHEL5. I am a programmer and a systems and database administrator by > profession. I have skills with Python (which is my language of choice), PHP and > Java, although my Python web framework experience mostly come from Zope. > Programming is my main passion but I also have administration skills. My > sysadmin experience cover NIS, LDAP, NFS, Samba, some Postfix, some Xen > failover clustering, and some DRBD. I also have experience with the > administration of Apache, Nagios, CVS and Subversion. As for being a db admin, > I manage MySQL databases including their replication. Hey, welcome - Python is our language of choice too :-) We usually have a few Python/TurboGears-related challenges going on. We have weekly meetings on Thursdays at 20:00 UTC (the next one is in about 3 hours) in #fedora-meeting on Freenode, so if you can make that, be sure to stop in and say hi to everybody. 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 Matt_Domsch at dell.com Thu Jul 23 18:46:45 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 23 Jul 2009 13:46:45 -0500 Subject: Relicensing Part II (redux) In-Reply-To: <4A65F630.8080907@gmail.com> References: <4A65F630.8080907@gmail.com> Message-ID: <20090723184644.GA16803@auslistsprd01.us.dell.com> On Tue, Jul 21, 2009 at 10:09:04AM -0700, Toshio Kuratomi wrote: > Resending since spot didn't get it the first time. > > Okay, at the infrastructure meeting this week we had a long discussion > about using AGPL in infrastructure and we decided we need more > information about what the AGPL requires of us. Here's a run down and > then the questions we had. I invited Bradley Kuhn of the Software Freedom Conservancy to join today's IRC meeting. Not sure if he can join, but he's well versed in the AGPLv3 and I had pointed him at this thread. He offered to join and discuss with us. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Thu Jul 23 18:48:03 2009 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 23 Jul 2009 13:48:03 -0500 Subject: Relicensing Part II (redux) In-Reply-To: <20090723184644.GA16803@auslistsprd01.us.dell.com> References: <4A65F630.8080907@gmail.com> <20090723184644.GA16803@auslistsprd01.us.dell.com> Message-ID: <20090723184803.GB16803@auslistsprd01.us.dell.com> On Thu, Jul 23, 2009 at 01:46:45PM -0500, Matt Domsch wrote: > On Tue, Jul 21, 2009 at 10:09:04AM -0700, Toshio Kuratomi wrote: > > Resending since spot didn't get it the first time. > > > > Okay, at the infrastructure meeting this week we had a long discussion > > about using AGPL in infrastructure and we decided we need more > > information about what the AGPL requires of us. Here's a run down and > > then the questions we had. > > I invited Bradley Kuhn of the Software Freedom Conservancy to join > today's IRC meeting. Not sure if he can join, but he's well versed in > the AGPLv3 and I had pointed him at this thread. He offered to join > and discuss with us. He's at OSCON this week, so I invited him to attend future Thursday meeting. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From a.badger at gmail.com Thu Jul 23 19:22:49 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 23 Jul 2009 12:22:49 -0700 Subject: Relicensing Part II (redux) In-Reply-To: <20090723184803.GB16803@auslistsprd01.us.dell.com> References: <4A65F630.8080907@gmail.com> <20090723184644.GA16803@auslistsprd01.us.dell.com> <20090723184803.GB16803@auslistsprd01.us.dell.com> Message-ID: <4A68B889.8060708@gmail.com> On 07/23/2009 11:48 AM, Matt Domsch wrote: > On Thu, Jul 23, 2009 at 01:46:45PM -0500, Matt Domsch wrote: >> On Tue, Jul 21, 2009 at 10:09:04AM -0700, Toshio Kuratomi wrote: >>> Resending since spot didn't get it the first time. >>> >>> Okay, at the infrastructure meeting this week we had a long discussion >>> about using AGPL in infrastructure and we decided we need more >>> information about what the AGPL requires of us. Here's a run down and >>> then the questions we had. >> >> I invited Bradley Kuhn of the Software Freedom Conservancy to join >> today's IRC meeting. Not sure if he can join, but he's well versed in >> the AGPLv3 and I had pointed him at this thread. He offered to join >> and discuss with us. > > He's at OSCON this week, so I invited him to attend future Thursday > meeting. > Excellent. Depending on when spot hears back from Red Hat legal and whether we have more questions after that, we may just be a case study for him or we may still be in the midst of figuring out what we want to do. -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 Jul 23 19:51:05 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 23 Jul 2009 14:51:05 -0500 (CDT) Subject: Checking / fixing permissions on hosted git projects In-Reply-To: <20090723155906.GX4338@inocybe.localdomain> References: <20090723155906.GX4338@inocybe.localdomain> Message-ID: On Thu, 23 Jul 2009, Todd Zullinger wrote: > Hey all, > > Every so often we've had problems with uses having permissions > problems in git repos on hosted. This is less of an issue over the > past few months as we backported a patch from upstream git to ensure > that git sets the permissions properly as well as setting the right > permissions with the gitsetup.sh script when creating new repos?. > > ? Except for the minor issue that it issues a mildly overly broad > 'chmod -R g+w .' -- which makes any files in the objects tree group > writable even though they are not intended nor required to be > writable by anyone. Objects are read only for git. > > To help ensure that we don't end up with any new permissions problems > I whipped up a git-check-perms script which might be useful to run as > a cron job once a daily or even weekly. It should alert us to any new > problems with git or with our setup/import scripts. It can also be > used to correct any problems found, after we've looked into what > caused them, of course. The script is in ~tmz/bin/git-check-perms on > hosted1. > > Before the output of this is clean and suitable for a cron job, there > are a few minor things that should be fixed. Mostly this is fixing > files in the objects dir that have unneeded write permissions. There > are also a few config and commit-list files that would get group write > permissions added. Neither of these things cause any real problems, > but they differ from how we'd like to setup and import git projects, > so making them consistent will make things simpler all around. > > The list of changes the script would make is attached. If anyone has > a moment to check that it looks sane, that would great. The short > list of non-objects dir issues is: > > /git/Virtualization_Guide.git/commit-list: Not group writable (should be "0664") > /git/augeas.git/commit-list: Not group writable (should be "0664") > /git/collie.git/commit-list: Not group writable (should be "0664") > /git/comps-extras.git/logs: Not SETGID (should be "02775") > /git/comps-extras.git/logs/refs: Not SETGID (should be "02775") > /git/comps-extras.git/logs/refs/heads: Not SETGID (should be "02775") > /git/docs/install-guide.git/config: Not group writable (should be "0664") > /git/docs/release-notes.git/config: Not group writable (should be "0664") > /git/fastback.git/commit-list: Not group writable (should be "0664") > /git/grubby.git/commit-list: Not group writable (should be "0664") > /git/grubby.git/config: Not group writable (should be "0664") > /git/moksha.git/commit-list: Not group writable (should be "0664") > /git/pam_url.git/config: Not group writable (should be "0664") > /git/piranha.git/commit-list: Not group writable (should be "0664") > /git/simon.git/commit-list: Not group writable (should be "0664") > /git/sssd.git/commit-list: Not group writable (should be "0664") > This all seems very reasonable to me. Thanks for putting that together. -Mike From mmcgrath at redhat.com Thu Jul 23 19:54:54 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 23 Jul 2009 14:54:54 -0500 (CDT) Subject: blogs.fedoraproject.org Update In-Reply-To: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> References: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> Message-ID: On Thu, 23 Jul 2009, Nick Bebout wrote: > This is just a quick note to update everyone on the status of > blogs.fedoraproject.org > > We have the FAS authentication plugin working, puppet set up, and are now > working on installing and testing a spam filter plugin, currently we are > testing bad behavior. As soon as this is done we plan to deploy it. > Thanks Nick. -Mike From thinklinux.ssh at gmail.com Thu Jul 23 19:57:34 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Fri, 24 Jul 2009 01:27:34 +0530 Subject: blogs.fedoraproject.org Update In-Reply-To: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> References: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> Message-ID: On Thu, Jul 23, 2009 at 9:46 PM, Nick Bebout wrote: > This is just a quick note to update everyone on the status of > blogs.fedoraproject.org > > We have the FAS authentication plugin working, puppet set up, and are now > working on installing and testing a spam filter plugin, currently we are > testing bad behavior. ?As soon as this is done we plan to deploy it. It is not working for me. I can't login with my FAS credentials. Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India From onekopaka at gmail.com Thu Jul 23 19:58:54 2009 From: onekopaka at gmail.com (Darren VanBuren) Date: Thu, 23 Jul 2009 12:58:54 -0700 Subject: blogs.fedoraproject.org Update In-Reply-To: References: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> Message-ID: Uses fas on pt3 for auth Darren VanBuren ------------------------- Sent from my iPod Try Fedora 10 today. Fire it up. http://fedoraproject.org/ On Jul 23, 2009, at 12:57, susmit shannigrahi wrote: > On Thu, Jul 23, 2009 at 9:46 PM, Nick Bebout > wrote: >> This is just a quick note to update everyone on the status of >> blogs.fedoraproject.org >> >> We have the FAS authentication plugin working, puppet set up, and >> are now >> working on installing and testing a spam filter plugin, currently >> we are >> testing bad behavior. As soon as this is done we plan to deploy it. > > It is not working for me. > I can't login with my FAS credentials. > Thanks. > > > -- > Regards, > Susmit. > > ============================================= > ssh > 0x86DD170A > http://www.fedoraproject.org/wiki/user:susmit > ============================================= > Sent from Calcutta, WB, India > > _______________________________________________ > 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 Thu Jul 23 20:00:20 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 23 Jul 2009 16:00:20 -0400 Subject: blogs.fedoraproject.org Update In-Reply-To: References: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> Message-ID: <20090723200020.GK5734@alpha.rzhou.org> On 2009-07-24 01:27:34 AM, susmit shannigrahi wrote: > It is not working for me. > I can't login with my FAS credentials. Hi, this is not live yet, please do not enter your real FAS credentials there (it's currently going against a test FAS). When we do make this live, it will be over SSL to avoid passwords being transmitted in plaintext. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Jul 23 21:03:10 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 23 Jul 2009 17:03:10 -0400 Subject: Meeting Log - 2009-07-23 Message-ID: <20090723210310.GA27214@alpha.rzhou.org> 20:00 < mmcgrath> #startmeeting 20:00 < zodbot> Meeting started Thu Jul 23 20:00:16 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 * ricky 20:00 < mmcgrath> #topic Infrastructure -- Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 20:00 * ricky (oops) 20:00 * dgilmore 20:00 * dgilmore 20:00 * dgilmore 20:00 * LinuxCode 20:01 * johe here 20:01 * nirik is around. 20:01 < mmcgrath> K. lets get started on ticket 20:01 < mmcgrath> s 20:01 < mmcgrath> #topic Infrastructure -- Tickets 20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 20:01 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:01 * davivercillo is here 20:01 < mmcgrath> So the first and only meeting item is, again, 20:01 < mmcgrath> .ticket 1503 20:01 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:01 < onekopaka> hello 20:01 < mmcgrath> last time we talked about the the whole metting 20:01 * onekopaka was here. 20:02 < mmcgrath> this time lets kill it after 10 minutes max. 20:02 < onekopaka> is* 20:02 < mmcgrath> abadger1999: around? 20:02 < dgilmore> mmcgrath: i think we could again 20:02 < smooge> here 20:02 * abadger1999 arrives 20:02 < dgilmore> did we get input on what source we have to make available? and how we have to make it available if we went with AGPL everywhere? 20:02 < mmcgrath> abadger1999: so give us the latest poop 20:02 < smooge> dgilmore, spot is working on it with legal 20:02 < LinuxCode> I assume this is the AGPLv3 issue ? 20:02 < smooge> or I should wait until abadger1999 20:03 * skvidal is here 20:03 < LinuxCode> wasnt somebody supposed to be here ? 20:03 -!- mchua [n=mchua at nat/redhat/x-fd7206a424906029] has joined #fedora-meeting 20:03 < ricky> LinuxCode: They were at OSCON 20:03 < LinuxCode> ohh 20:03 < abadger1999> spot is talking to legal. So I think we don't have much to say here. 20:03 < LinuxCode> the person spot mentioned ? 20:03 < abadger1999> Unless people have new questions since last year 20:03 < mmcgrath> abadger1999: so no progress since last week? 20:03 * LinuxCode hasnt, but sees both sides of the argument 20:04 < dgilmore> abadger1999: right. until we clear up the legal requirements we can do anything 20:04 < abadger1999> mmcgrath: Well, spot has the list of questions now and it has gone from him to legal. But we haven't gotten a writeup yet. 20:04 < abadger1999> So we can make no progress. 20:04 < mmcgrath> k 20:04 < mmcgrath> Is Bradley Kuhn here? 20:04 * mmcgrath notes domsch invited him 20:05 < ricky> I think he was OSCONing, so mdomsch moved it up a week 20:05 < mmcgrath> ah, k 20:05 < abadger1999> I'd like to go ahead with relicensing python-fedora to lgplv2+ since that won't be affected by whatever we decide regarding agpl. 20:05 < mmcgrath> ah. so he did :) 20:05 < mmcgrath> abadger1999: What all are we accomplishing with that? 20:06 < abadger1999> mmcgrath: Right now it's gplv2. LGPLv2+ will make it so more people can use it. 20:06 < abadger1999> for instance, if someone writes code with the apache license, python-fedora will work under the LGPLv2+. 20:06 < abadger1999> also, mdomsch would like it to change. 20:07 < mmcgrath> k 20:07 < mmcgrath> well, if thats all we have on that I'll move on 20:07 < abadger1999> mirrormanager is MIT licensed. But when used with python-fedora, the combined work is GPLv2. 20:07 < skvidal> together - they fight crime! 20:07 < abadger1999> with python-fedora LGPLv2+, mirrormanager remains MIT in practice. 20:07 < onekopaka> hmm. 20:08 < abadger1999> s/inpractice// 20:08 < mmcgrath> skvidal: that's good, I'm pretty sure smolt is committing some.... 20:08 < mmcgrath> abadger1999: ok, thanks for that 20:08 < mmcgrath> anyone have anything else on this topic before we move on? 20:08 * LinuxCode shakes head 20:08 < mmcgrath> k 20:09 < mmcgrath> #topic Infrastructure -- Mirrors and 7 years bad luck. 20:09 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Mirrors and 7 years bad luck. 20:09 < LinuxCode> haha 20:09 < smooge> you broke it 20:09 < LinuxCode> its your fault 20:09 < LinuxCode> lol 20:09 < mmcgrath> So, as far as I know the mirrorsr are on the mend. 20:09 < LinuxCode> +1 can confirm that 20:09 < smooge> I believe so. 20:09 -!- Sonar_Gal [n=Andrea at fedora/SonarGal] has quit "Leaving" 20:09 < LinuxCode> had first updates today 20:10 < mmcgrath> jwb just did a push that finished. 20:10 < mmcgrath> so there's a bash update coming out. 20:10 < mmcgrath> we're trying to time how long it takes that update takes to get to our workstations 20:10 < jwb> mmcgrath, i see it on d.f.r.c, but i haven't gotten it via yum yet 20:10 < mmcgrath> so if any of you see a bash update available, please do ping me and let me know. 20:10 < jwb> (and i'm doing yum clean metadata/yum update every little bit) 20:10 * mmcgrath verifies he also doesn't have it 20:11 * LinuxCode cleans up and sees if it has made it to the UK 20:11 < mmcgrath> yeah, no update yet. 20:11 < mmcgrath> So keep an eye on that. 20:11 < mmcgrath> Here's some of the stuff that's been done 20:11 < mmcgrath> 1) we've put limits on the primary mirrors 20:11 < mmcgrath> 2) we've started building our own public mirrors system which, for now, will be very similar to the old mirrors system. 20:11 < mmcgrath> but we control it 20:12 < mmcgrath> 3) we've leaned harder on various groups that we're blockign on to get our i2 mirror back up and our other primary mirror back up 20:12 -!- davivercillo [n=daviverc at 146.164.31.95] has quit Nick collision from services. 20:12 < mmcgrath> we're supposed to have 3 of them. 20:12 < mmcgrath> But still no root cause, though it sounds like a combination of thigns 20:12 < mmcgrath> err things. 20:13 < mmcgrath> To me the biggest issue isn't that the problem came up, it's that it took so long to fix and our hands were largely tied for it. 20:13 -!- davivercillo [n=daviverc at 146.164.31.95] has joined #fedora-meeting 20:13 * davivercillo came back... 20:13 < mmcgrath> So we're working hard to build our own mirrors out that we can work on, monitor, etc. 20:13 < Southern_Gentlem> su 20:13 < Southern_Gentlem> su 20:13 < ricky> Password: 20:13 < LinuxCode> yeh, was a bummer that it took that long 20:13 < dgilmore> mmcgrath: how is that going to work? 20:13 < nirik> Southern_Gentlem: sudio? :) 20:14 < Southern_Gentlem> wrong window sorry 20:14 < ricky> dgilmore: It'll just be rsync servers that mount the netapp 20:14 < mmcgrath> dgilmore: for now we've got sync1 and sync2 up (which are RR behind sync.fedoraproject.org) which we're going to dedicate to our tier0 and tier1 mirrors. 20:14 < mmcgrath> They mount the netapp and basically do the same thing download.fedora.redhat.com did 20:14 < mmcgrath> Long term though... 20:14 < ricky> Have we decided to dedicate it, or just have connection slots reserved for tier 0/1? 20:14 < dgilmore> mmcgrath: ok what about from other data centres? 20:14 < dgilmore> RDU and TPA? 20:15 < ricky> rsync's connection limiting allows us to be pretty flexible with how we do that 20:15 < mmcgrath> ricky: right now we're not going to tell others about it and we might explicitly deny access the non tier0/1 mirrors 20:15 < smooge> TPA? 20:15 < LinuxCode> mmcgrath, so, the other mirrors grab from sync1 and sync2 ? 20:15 < mmcgrath> notting: FYI this might interest you. 20:15 < ricky> OK 20:15 < ricky> smooge: Tampa, I think 20:15 < mmcgrath> LinuxCode: only tier0 and 1 20:15 < LinuxCode> k 20:15 < smooge> oh I thought Tampa was gone 20:15 < mmcgrath> dgilmore: so the future of that is going to look like this. 20:15 < ricky> The other mirrors should technically grab from tier 0 or 1 20:15 < mmcgrath> TPA's mirror has been offline since February but it is physically in PHX2 now just not completely hooked up. 20:15 < smooge> ah ok 20:15 < mmcgrath> They're going to get it setup, get the snapmirror working again, then we'll have some servers there that mount that netapp and share. 20:16 < mmcgrath> it'll be similar if not identical to what we have in PHX1. 20:16 < mmcgrath> for me the concern is 1) is the limiting factor bandwidth or disk space. 20:16 < mmcgrath> and if it's bandwidth, we might need additional servers in PHX2 which I understand has a much faster pipe. 20:16 < mmcgrath> That's all regular internet stuff. 20:16 < LinuxCode> mmcgrath, what about failure ? 20:16 < mmcgrath> on the I2 side we're going to get RDU setup 20:16 < ricky> And will we get access to the rsync servers on the non-PHX sites? 20:17 < dgilmore> mmcgrath: so the same thing in RDU? 20:17 < mmcgrath> LinuxCode: well we'll have one in PHX and one in PHX2 so we'll be redundant in that fashion. 20:17 < LinuxCode> k 20:17 < mmcgrath> dgilmore: similar in RDU, though probably not a whole farm of servers. 20:17 < dgilmore> couple of boxes in front of teh netapp? 20:17 < mmcgrath> we'll have proper I2 access there. 20:17 * SmootherFrOgZ is around btw 20:17 < mmcgrath> but one thing I'm trying to focus on there is using ibiblio as another primary mirror. 20:17 -!- mdomsch [n=Matt_Dom at 24.174.1.212] has joined #fedora-meeting 20:17 < mmcgrath> Or at least work it in to our SOP so it can be pushed to very quickly and easily instead of pulled from. 20:17 < mmcgrath> we see one sign of problems from our primary mirrors and that can be setup and going. 20:17 < mmcgrath> we were lucky this last week. 20:18 < mmcgrath> no ssh vulnerabilities were actually real for example :) 20:18 < mmcgrath> so that's really what it's all going to look like. 20:18 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 20:18 < mmcgrath> smooge has some concerns about IOPS on the disk trays. 20:19 < mmcgrath> and we may have to take a more active role in determining what kind of trays we want in the future. 20:19 < dgilmore> mmcgrath: cool 20:19 < mmcgrath> this one was done between the storage team and netapp and months of their research. 20:19 < dgilmore> mmcgrath: its all sata right? 20:19 < smooge> yes.. the trays and how they are 'set' up were based on if they were FC. 20:19 < dgilmore> how big are the disks? 20:19 < smooge> and now they are 1TB SATAs 20:20 < smooge> the issue is that the SATAs perform at 1/3 the rate FC would 20:20 < dgilmore> so we have one shelf in each location? 20:20 < mmcgrath> smooge: I'd have hopped that months of research would have shown that though. 20:20 < smooge> but the FC would cost 8x more 20:20 < mmcgrath> I think their thoughts were that our FC rates were very underutilized. 20:20 < dgilmore> smooge: right id expect that kind of decrease in performance 20:21 < mmcgrath> So the longer term future on all of this is still in question. 20:21 < LinuxCode> mmcgrath, for the cost, you could make more mirrors 20:21 < smooge> mmcgrath, it could have been but more like 3/5's of capacity 20:21 < mmcgrath> and I'm pretty sure our problems, caused kernel.org's problems last week as well. 20:21 < LinuxCode> and maybe raid6+0 them 20:21 < mmcgrath> and his' machines are f'ing crazy fast. 20:21 < LinuxCode> ehh raid5+0 20:21 < LinuxCode> raid6 be slow 20:21 < smooge> LinuxCode, the issue comes down to the number of spindles either way 20:22 < LinuxCode> hmm 20:22 < smooge> and the bandwidth of the controllers 20:22 < mmcgrath> LinuxCode: raid6 and raid5 with lots of disks have nearly identical read performance. 20:22 < LinuxCode> true that mmcgrath 20:22 < mmcgrath> But still, no ETA on any of that. 20:22 < LinuxCode> even with stripping applied too ? 20:22 < smooge> anyway.. it is what it is or whats done is done or some other saying 20:22 < LinuxCode> smooge, hehe 20:22 < mmcgrath> I have a meeting with Eric (my primary RH contact) to find out about funding for new servers and what not for all of this. 20:23 < mmcgrath> and the scary part is we had these issues with just 1T of storage. 20:23 < mmcgrath> these trays were purchased so we could have closer to 8T of storage to use. 20:23 < LinuxCode> hmmm 20:23 < mmcgrath> If we find the trays can't handle it.... then I don't know what's going to happen but I know the storage team won't be happy. 20:23 < mmcgrath> So anyone have any additional questions on any of this? 20:23 < LinuxCode> are these san trays ? 20:24 < smooge> netapp 20:24 < LinuxCode> k 20:24 < mmcgrath> K, so that's that. 20:25 < mmcgrath> #topic Infrastructure -- Oddities and messes 20:25 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Oddities and messes 20:25 -!- sdziallas_ [n=sebastia at p5B045F68.dip.t-dialin.net] has joined #fedora-meeting 20:25 < mmcgrath> So have things seemed more fluxy then normal to anyone else or is it just me? 20:25 < mmcgrath> We've largely corrected the ProxyPass vs RewriteRule [P] 20:25 < mmcgrath> thing 20:25 -!- sdziallas [n=sebastia at fedora/sdziallas] has quit Nick collision from services. 20:25 -!- sdziallas_ is now known as sdziallas 20:25 < mmcgrath> but I still feel there's lots of little outstanding bugs that have crept in over the last several weeks that we're still figuring out. 20:25 < mmcgrath> of particular concern to me at the moment is smolt. 20:26 < mmcgrath> but there were other things like the openvpn issue ricky discovered yesterday. 20:26 < dgilmore> it seems like nagios has been having moments 20:26 < dgilmore> where we get alot of alerts 20:26 < ricky> Are we sure that the smolt changes were necessarily from the merge? 20:26 < ricky> smolt was one of the ones whose proxy config was complex enough that I didn't touch it much 20:26 -!- Pikachu_2014 [n=Pikachu_ at 85-169-128-251.rev.numericable.fr] has joined #fedora-meeting 20:27 < mmcgrath> ricky: I actually think the smolt issues were discovered not because of the change but because of a cache change you made. 20:27 < ricky> Ahhh, yeah. 20:27 < mmcgrath> I think nagios had been checking a cached page the whole time so even when smolt went down, nagios just didn't notice. 20:27 < LinuxCode> hehe 20:27 < mmcgrath> or at least didn't notice it unless things went horribly bad. 20:27 < mmcgrath> I'd like to have more people looking at it though 20:27 -!- sijis [n=sijis at adsl-75-49-223-86.dsl.emhril.sbcglobal.net] has joined #fedora-meeting 20:28 < mmcgrath> onekopaka has been doing some basic hits from the outside. 20:28 < mmcgrath> basically a "time smoltSendProfile -a" 20:28 < onekopaka> mmcgrath: I have. 20:28 < mmcgrath> and the times were all over the place. 20:28 * sijis is sorry for being late. 20:28 < mmcgrath> including about a 5% failure rate. 20:28 < mmcgrath> Of course I hate to be spending time on something that is clearly not in Fedora's critical path, but we've got to knock it out 20:28 -!- thekad [n=kad at 189.187.137.181] has joined #fedora-meeting 20:28 < LinuxCode> does smolt provide some debugging output thats useful ? 20:29 < mmcgrath> LinuxCode: it's almost entirely blocking on db. 20:29 < LinuxCode> as to network, dns issues 20:29 < mmcgrath> we even have the queries. 20:29 < LinuxCode> hmm 20:29 < LinuxCode> weird 20:29 < davivercillo> mmcgrath: I can try to help you with this ... 20:29 < ricky> Do we know which queries are causing the locked queries though? 20:30 < mmcgrath> ricky: not really 20:30 < mmcgrath> I still don't even understand why they're being locked 20:30 < mmcgrath> and why does locktime not mean anything? 20:30 < LinuxCode> is there a conn limit set up on the db end for the smolt unit ? 20:30 < ricky> locktime? 20:30 < mmcgrath> LinuxCode: it's not that weird, it's got 80 million rows :) 20:30 < mmcgrath> ricky: yeah in the slow queries log 20:30 < ricky> The time column on processlist is the that the query has been in its current state 20:30 < abadger1999> Do we have any reproducers? I can try with postgres but we'd need to know whether we've gained anyhting or not. 20:30 < ricky> Hm, I remember looking the slow queries one up 20:31 < mmcgrath> davivercillo: how's your db experience? 20:32 < LinuxCode> mmcgrath, so queries get processed or a connection passes to the db server, but it doesnt handle it, correct ? 20:32 < davivercillo> mmcgrath: not so much yet... but I can learn fast ! :D 20:32 < mmcgrath> LinuxCode: the queries take several seconds to complete 20:32 < mmcgrath> for example 20:32 -!- mcepl [n=mcepl at 49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has left #fedora-meeting [] 20:32 < LinuxCode> hmmm 20:33 < mmcgrath> I don't even have an example at the moment. 20:33 < LinuxCode> np 20:33 < ricky> Ah, lock_time is the time the query spent waiting for a lock 20:33 < mmcgrath> but they're there. 20:33 < ricky> So for the queries in the lock state with high times in processlist, they should have high lock_time if they're in the slow query log 20:33 < mmcgrath> ricky: so if a query is running on a table for 326 seconds... does that mean it was locked that whole time? 20:33 < ricky> Depends on where the 326 number came from 20:34 < mmcgrath> ricky: in the slow queries log, do you see any queries that have a Lock_time above 0? 20:34 < mmcgrath> oh, there actually are some. 20:35 < mmcgrath> only 56 of 2856 though 20:35 < mmcgrath> So anyway 20:35 < mmcgrath> davivercillo: how's your python? 20:35 < LinuxCode> could it be that smolt sends some weird query, that then causes it to hickup ? 20:35 < mmcgrath> LinuxCode: nope, it's not weird queries :) 20:35 < LinuxCode> just a wild though 20:35 < LinuxCode> t 20:35 < davivercillo> mmcgrath: I think that is nice... 20:35 < mmcgrath> it's just the size of the db 20:35 < LinuxCode> hehe 20:36 < onekopaka> joins + size = slowness 20:36 < mmcgrath> well and that's something else we need to figure out, we've spent so much time optimizing render-stats (which is still pretty killer) 20:36 < LinuxCode> mmcgrath, yeh but if you do something funky + huge db = inefficient 20:36 < mmcgrath> but we haven't looket at optimizing the sending profiles. 20:36 < davivercillo> mmcgrath: I did that script checkMirror.py, do u remember ? 20:36 < mmcgrath> huge db == inefficient :) 20:36 < davivercillo> :P 20:36 < LinuxCode> mmcgrath, haha of course 20:36 < mmcgrath> davivercillo: yeah but that was smaller :) 20:36 < LinuxCode> but there is no way around that 20:36 < mmcgrath> davivercillo: ping me after the meeting, we'll go over some stuff. 20:37 < davivercillo> mmcgrath: yep, I know... :P 20:37 < mmcgrath> if any of you are curious and want to poke around 20:37 < davivercillo> mmcgrath: Ok ! 20:37 < mmcgrath> you can get a sample db to download and import here: 20:37 < mmcgrath> https://fedorahosted.org/releases/s/m/smolt/smolt.gz 20:37 < mmcgrath> It's about 500M 20:37 < thekad> mmcgrath, yes! thanks! 20:37 * thekad has been waiting to load something like that 20:37 < mmcgrath> Ok, I don't want to take up the rest of th emeeting with smolt stuff so we'll move on. 20:38 < mmcgrath> #topic Infrastructure -- Open Floor 20:38 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:38 < mmcgrath> Anyone have anything they'd like to discuss? 20:39 < dgilmore> importing meat pies from australia? 20:39 * mdomsch invited Bradley Kuhn to a future meeting to talk about agplv3 20:39 < thekad> mmcgrath, actually, about this smolt stuff, is there a ticket where we can track? 20:39 < mdomsch> we may have it cleared up by then, maybe not. 20:39 < SmootherFrOgZ> dgilmore: :) 20:39 < dgilmore> mdomsch: have at it 20:39 < mmcgrath> thekad: not actually sure. I'll create one if not. 20:39 < LinuxCode> mmcgrath, Id just like to know when you guys have time to help me do that new mapping of infra 20:39 < LinuxCode> it will probably take a few weeks, if not longer 20:39 < mmcgrath> mdomsch: yeah we were talking about it a bit earlier. I saw your first email but not th esecond email :) 20:40 < smooge> dgilmore, are they mutton meat pies? 20:40 < thekad> I've seen this topic pop up several times, but we start from scratch every time, I think we could benefit there :) 20:40 < dgilmore> smooge: no 20:40 < LinuxCode> if that ticket still even exists 20:40 < smooge> dgilmore, then no thankyou 20:40 < dgilmore> smooge: four'n'twenty pies 20:40 < dgilmore> smooge: best ones ever 20:40 -!- jayhex [n=jayhex at 122.53.116.156] has joined #fedora-meeting 20:40 < mmcgrath> Ok, anyone have anything else they'd like to discuss? 20:41 * thekad is being dragged away by his 2yo daughter bi5 20:41 < smooge> dgilmore, as long as they don't have raisins and such in them 20:41 < LinuxCode> mmcgrath, see above 20:41 < LinuxCode> to replace this 20:41 < LinuxCode> https://fedoraproject.org/wiki/Infrastructure/Architecture 20:41 < LinuxCode> was in the talk some time ago 20:41 < mmcgrath> LinuxCode: yeah you were going to add docs to git.fedorapeople.org 20:41 < LinuxCode> there was a ticket, but not sure what happened to it 20:41 < mmcgrath> err git.fedorahosted.org/git/fedora-infrastructure.git :) 20:41 < LinuxCode> k 20:42 < LinuxCode> well I will have time now, but need you guys to explain to me exactly whats where 20:42 < mmcgrath> .ticket 1084 20:42 < zodbot> mmcgrath: #1084 (Fix proxy -> app docs) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1084 20:42 < LinuxCode> so I just ask some stupid questions now and then 20:42 < mmcgrath> LinuxCode: Do you have some time to work on it this afternoon? 20:42 < LinuxCode> its kinda late now 20:42 < LinuxCode> ;-p 20:42 < LinuxCode> 21:42 20:43 < mmcgrath> LinuxCode: yeah I'll add some stuff. 20:43 < LinuxCode> k 20:43 < mmcgrath> for those docs I think it's less important on where stuff physically is, and more important on how the pieces fit together. 20:43 < LinuxCode> a list be ok 20:43 < LinuxCode> that give me a starting point 20:43 < mmcgrath> that's really what people are talking about when they do architecture 20:43 < LinuxCode> yah of course 20:43 < LinuxCode> to give people a better idea 20:43 < mmcgrath> LinuxCode: i'll update that ticket shortly actually 20:43 < LinuxCode> excellent 20:43 < smooge> I have an open floor question 20:43 < mmcgrath> I think starting on the Proxy servers first would be a good way to go. 20:43 < mmcgrath> smooge: have at it 20:44 < LinuxCode> def 20:44 < LinuxCode> we talk another time 20:44 < smooge> Someone was working on a inventory system earlier. Does anyone remember who it was , where it was, etc? 20:44 < smooge> I can't find any reference versus IRC :) 20:44 < LinuxCode> inventory.... 20:44 < LinuxCode> kinda rings a bell.... 20:44 * nirik thinks it was ocsinventory. Not sure who was doing it tho. 20:45 < mmcgrath> smooge: I think it was boodle 20:45 < sijis> i saw something on the list about ipplan. is that it? 20:45 < mmcgrath> .any boodle 20:45 < zodbot> mmcgrath: I have not seen boodle. 20:45 < smooge> boodle is a tool? 20:45 < smooge> boodle is a person? 20:45 < mmcgrath> mdomsch: you work with boodle right? 20:45 -!- sharkcz [n=dan at plz1-v-4-17.static.adsl.vol.cz] has quit "Ukon?uji" 20:45 < mmcgrath> boodle is a dude(le) 20:45 < ricky> Heh 20:45 < LinuxCode> http://publictest10.fedoraproject.org/ocsreports/ 20:45 < LinuxCode> thats in my ticket 20:45 < LinuxCode> not sure if that helps 20:45 < mdomsch> mmcgrath, yes 20:45 < LinuxCode> the machine aint up 20:45 < smooge> LinuxCode, what ticket 20:46 < mmcgrath> mdomsch: he was working on the inventory stuff 20:46 < LinuxCode> https://fedorahosted.org/fedora-infrastructure/ticket/1084 20:46 < LinuxCode> scroll to bottom 20:46 < LinuxCode> 03/16/09 20:36:44 changed by boodle 20:46 < mdomsch> mmcgrath, I remember; I haven't seen anything on that in a bit 20:46 < mdomsch> ha 20:46 < smooge> LinuxCode, thanks.. my browser skills FAILED 20:46 < mdomsch> yeah, since about then 20:46 < LinuxCode> smooge, haha 20:46 < mmcgrath> mdomsch: I just didn't know if he was still working on it or what 20:46 < LinuxCode> ;-D 20:46 < mmcgrath> butI think smooge has an itch to get it going. 20:46 < mmcgrath> and it's probably best to let him scratch it :) 20:46 < mdomsch> smooge, go for it 20:47 < mdomsch> just put a note in that ticket so he knows 20:47 < LinuxCode> that be something useful to me actually 20:47 < thekad> bump the ticket 20:47 < smooge> ok cool. mdomsch can you send me an email address so I can contact him too 20:47 < LinuxCode> to make those updated diagrams 20:47 < ricky> smooge: What was the software you had experience with again? 20:47 < smooge> exactly what he was using 20:47 < mmcgrath> I swear there was an inventory ticket he was working on 20:47 < ricky> Oh 20:47 < ricky> oscinventory? That might have ended... a bit poorly 20:47 < smooge> mmcgrath, probably I have epic fail this week with searching 20:48 < ricky> I remember one of the ones he was trying, I found bad security problems on a quick lookover 20:48 < LinuxCode> ricky, with the app ? 20:48 < mmcgrath> ricky: do you know what happened with pb10? 20:48 < ricky> Yeah, grepping my IRC logs now 20:48 < mmcgrath> err pt10 20:48 * mdomsch has to run; later 20:48 < mmcgrath> mdomsch: laterz 20:48 -!- mdomsch [n=Matt_Dom at 24.174.1.212] has quit "Leaving" 20:48 < LinuxCode> http://publictest10.fedoraproject.org/glpi/ 20:48 < LinuxCode> there is that one too 20:48 < LinuxCode> also kinda rings a bell 20:48 < smooge> yeah.. they tie into one another 20:48 < ricky> I have no idea, it might have just not gotten started on reboot 20:49 < LinuxCode> smooge, kk 20:49 < smooge> ocsng is the tool that polls the boxes 20:49 < smooge> glpi is the perty front end where you can enter data 20:49 < mmcgrath> .ticket 1171 20:49 < zodbot> mmcgrath: #1171 (Requesting a public test box to evaluate GLPI and OCS) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1171 20:49 < mmcgrath> smooge: see that ticket as well 20:49 < thekad> mmcgrath, that's the one 20:49 < ricky> Yeah, OSC was the security hole one 20:50 < smooge> geez I really failed 20:50 < ricky> Like I was able to delete a row from some table without logging on or anything 20:50 < thekad> .ticket 1084 20:50 < zodbot> thekad: #1084 (Fix proxy -> app docs) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1084 20:50 < smooge> I went looking for GLPI 20:50 < thekad> that's the next one 20:50 < ricky> I didn't look much closer at the security stuff after an initial look at it though. 20:50 < LinuxCode> ricky, did you report that ? 20:50 < nirik> ricky: nasty. ;( It's in fedora, you might note that to the maintainer. 20:50 -!- easter_egg [n=freeman at 201-75-42-40-ma.cpe.vivax.com.br] has joined #fedora-meeting 20:51 < mmcgrath> well 20:51 < mmcgrath> just the same 20:51 < mmcgrath> smooge: you want to open up an "inventory management" ticket? 20:51 < ricky> mmcgrath: Looks like publictest10 just didn't get started on a reboot - should I start it again? 20:51 -!- kolesovdv [n=kolesovd at 82.162.141.18] has quit Remote closed the connection 20:51 < smooge> mmcgrath, put that down as an action please 20:51 < mmcgrath> ricky: sure, smooge might be able to use it 20:51 < smooge> I will start on it right away 20:51 < mmcgrath> #action Smooge will create a ticket and get started on inventory management 20:52 < smooge> ricky, we will see if the updated version has the bug and then work it out 20:52 * davivercillo need to go home now ! See you later ! 20:52 < ricky> OK. I just remember getting a really bad impression from that and the other code, but hopefully some of this is fixed. 20:52 < davivercillo> Good Night ! 20:52 < mmcgrath> davivercillo: ping me when you get time later 20:52 < mmcgrath> or tomorrow :) 20:52 < mmcgrath> or whenever 20:53 < davivercillo> mmcgrath: for sure 20:53 < davivercillo> bye 20:53 -!- davivercillo [n=daviverc at 146.164.31.95] has left #fedora-meeting [] 20:53 < mmcgrath> So we've only got 7 minutes left, anyone have anything else to discuss? 20:54 * ricky wonders if sijis wanted to say anything about blogs 20:54 < mmcgrath> sijis: anything? 20:54 < mmcgrath> abadger1999: or anything about zikula? 20:54 < sijis> yeah, as you saw, the authentication part on the blogs is working. 20:54 < ricky> Thanks for working on that plugin 20:54 < abadger1999> mmcgrath: When should we get docs people started in staging? 20:55 < sijis> we are able to also verify that minimum gropu memberships are met before allowing a login 20:55 < abadger1999> I think they have all of the packages in review. 20:55 -!- kolesovdv [n=kolesovd at 82.162.141.18] has joined #fedora-meeting 20:55 < abadger1999> But htey're not all reviewed yet/some are blocking on licensing. 20:55 -!- danielbruno [n=danielbr at thor.argo.com.br] has quit Remote closed the connection 20:55 < thekad> sijis, which groups are those? cla_done? 20:55 < sijis> a person has to be in cla_done an another other non-cla group 20:55 < ricky> Is http://publictest15.fedoraproject.org/cms/ really as far as they're going to take the test instance? Not trying to complain, but I'm just used to seeing slightly more complete setups in testing first 20:55 < mmcgrath> abadger1999: how long till the licensing is resolved do you think? 20:56 < sijis> there are few minor things to work out.. but it should be ready to be tested. 20:57 < ke4qqq> ricky - we need to spend more time on pt15 - we largely haven't done anything with it in months. specifically we need to get all of the pieces that we have packaged, and beat on it 20:57 < abadger1999> mmcgrath: I encountered problems in both packages I reviewed. One has been resolved (I just need to do a final review) the other is waiting upstream. docs has contacted several people related to that 20:57 < ricky> Ah, cool, so maybe not quite staging-ready yet 20:57 < ke4qqq> ricky: hopefully not far off 20:57 < abadger1999> ianweller also encountered some major problems in one that he reviewed -- but I think it might have been optional. 20:57 < ricky> Cool, thanks 20:58 < abadger1999> ke4qqq and sparks would know for sure. 20:59 < ke4qqq> we still have three (and maybe four) though that includes the one thats waiting abadger1999's final approval, that are blocked on licensing probs 20:59 < mmcgrath> abadger1999: hmm 20:59 < mmcgrath> abadger1999: what are the odds they won't be resolved? 20:59 < abadger1999> ke4qqq: Want to field that? And any contingency if that happens? 20:59 < ke4qqq> mmcgrath: I think we'll workaround - upstream is pretty committed to fixing stuff 21:00 < ke4qqq> there is just a ton of stuff 21:00 < mmcgrath> 21:00 < mmcgrath> Ok, so we're at the end of the meeting time, anyone have anything else to discuss? 21:00 < jayhex> just want to say hi before we end. Julius Serrano here. 21:00 < mmcgrath> jayhex: hello Julius! 21:00 -!- oget_ [n=oget at c-69-137-139-64.hsd1.pa.comcast.net] has joined #fedora-meeting 21:00 -!- oget_ is now known as oget_zzz 21:00 < mmcgrath> thanks for saying hey. 21:00 < thekad> welcome jayhex 21:00 < ricky> jayhex: Hey, welcome! 21:01 < sijis> jayhex: welcome. 21:01 -!- danielbruno [n=danielbr at thor.argo.com.br] has joined #fedora-meeting 21:01 < mmcgrath> Ok, if no one has anything else, we'll close in 30 21:01 -!- biertie [n=bert at 174.57-247-81.adsl-dyn.isp.belgacom.be] has joined #fedora-meeting 21:02 < mmcgrath> #endmeeting 21:02 -!- zodbot 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/Meeting_channel for meeting schedule 21:02 < zodbot> Meeting ended Thu Jul 23 21:02:06 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 21:02 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-23/fedora-meeting.2009-07-23-20.00.html 21:02 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-23/fedora-meeting.2009-07-23-20.00.txt 21:02 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-23/fedora-meeting.2009-07-23-20.00.log.html -------------- 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 Sat Jul 25 03:53:23 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 25 Jul 2009 03:53:23 +0000 Subject: Proposed setup for sigul bridge/server for review Message-ID: <1248494005-30782-1-git-send-email-jkeating@redhat.com> Here is my initial stab at a class for the signing server(s). There is a bridge that clients communicate with (and I'm thinking of forcing this through an ssh tunnel through bastion) and that interacts with koji. There is also the server itself that has the gpg keys on it and does the signing action. The server initiates a connection to the bridge, so only the bridge has to listen for connections. I think I have this mostly setup right, but I'd like some more eyes on it before I commit. Thanks! -- Jes From jkeating at redhat.com Sat Jul 25 03:53:24 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 25 Jul 2009 03:53:24 +0000 Subject: [PATCH] Setup sigul bridge and client In-Reply-To: <1248494005-30782-1-git-send-email-jkeating@redhat.com> References: <1248494005-30782-1-git-send-email-jkeating@redhat.com> Message-ID: <1248494005-30782-2-git-send-email-jkeating@redhat.com> Add a sigul module with bridge and server classes. Adjust the sign-bridge1 node to use the new classes. --- .../nodes/sign-bridge1.fedora.phx.redhat.com.pp | 17 +++- modules/sigul/files/server.conf | 47 ++++++++++ modules/sigul/manifests/init.pp | 97 ++++++++++++++++++++ modules/sigul/templates/bridge.conf.erb | 30 ++++++ 4 files changed, 189 insertions(+), 2 deletions(-) create mode 100644 modules/sigul/files/server.conf create mode 100644 modules/sigul/manifests/init.pp create mode 100644 modules/sigul/templates/bridge.conf.erb diff --git a/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp b/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp index 3bfcb8a..6c5d295 100644 --- a/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp @@ -3,7 +3,9 @@ node "sign-bridge1.fedora.phx.redhat.com" { include phx include fas::client #include global - #include pkgsigner + # Include the builder infrastructure so that we get the same rpm versions + include yum::repo::builder-infrastructure + include sigul::bridge # Hack but it's easy to predict and easy to follow: # exec { "disable-ssh": @@ -16,6 +18,17 @@ node "sign-bridge1.fedora.phx.redhat.com" { # command => '/etc/init.d/puppet stop; /sbin/chkconfig puppet off', # } + # Firewall Rules, allow sigul server through. + $tcpPorts = [ '44333' ] + $custom = [ ] + + iptables { '/etc/sysconfig/iptables': + content => template('system/iptables-template.conf.erb'), + } + + service { iptables: + ensure => running, + hasstatus => true, + } - } diff --git a/modules/sigul/files/server.conf b/modules/sigul/files/server.conf new file mode 100644 index 0000000..513cad5 --- /dev/null +++ b/modules/sigul/files/server.conf @@ -0,0 +1,47 @@ +# This is a configuration for the sigul server. + +[server] +# Host name of the publically acessible bridge to clients +bridge-hostname: sign-bridge1 +# Port on which the bridge expects server connections +bridge-port: 44333 +# Maximum accepted size of payload stored on disk +max-file-payload-size: 1073741824 +# Maximum accepted size of payload stored in server's memory +max-memory-payload-size: 1048576 +# Nickname of the server's certificate in the NSS database specified below +server-cert-nickname: sigul-server-cert + +[database] +# Path to a directory containing a SQLite database +;database-path: /var/lib/sigul + +[gnupg] +# Path to a directory containing GPG configuration and keyrings +gnupg-home: /var/lib/sigul/gnupg +# Default primary key type for newly created keys +gnupg-key-type: RSA +# Default primary key length for newly created keys +gnupg-key-length: 4096 +# Default subkey type for newly created keys, empty for no subkey +gnupg-subkey-type: +# Default subkey length for newly created keys if gnupg-subkey-type is not empty +; gnupg-subkey-length: 2048 +# Default key usage flags for newly created keys +gnupg-key-usage: encrypt, sign +# Length of key passphrases used for newsly created keys +passphrase-length: 64 + +[daemon] +# The user to run as +unix-user: sigul +# The group to run as +unix-group: sigul + +[nss] +# Path to a directory containing a NSS database +nss-dir: /var/lib/sigul +# Password for accessing the NSS database. If not specified, the server will +# ask on startup +; nss-password is not specified by default + diff --git a/modules/sigul/manifests/init.pp b/modules/sigul/manifests/init.pp new file mode 100644 index 0000000..aae73eb --- /dev/null +++ b/modules/sigul/manifests/init.pp @@ -0,0 +1,97 @@ +class sigul { + + package { "sigul": + ensure => installed, + } +} + +class sigul::bridge inherits sigul { + + package { "koji"; + ensure => installed, + } + + file { "/etc/sigul/bridge.conf": + owner => "root", + group => "sigul", + mode => 0640, + content => template("sigul/bridge.conf.erb") + require => [ Package["sigul"] ], + } + + file { "/var/lib/sigul/cert8.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_bridge_cert8.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/key3.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_bridge_key3.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/secmod.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_bridge_secmod.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/.fedora-server-ca.cert": + owner => "sigul", + group => "sigul", + mode => 0644, + source => "puppet:///config/secure/fedora-ca.cert", + } + + file { "/var/lib/sigul/.fedora.cert": + owner => "sigul", + group => "sigul", + mode => 0644, + source => "puppet:///config/secure/sigul_key_and_cert.pem", + } + +} + +class sigul::server inherits sigul { + + file { "/etc/sigul/server.conf": + owner => "root", + group => "sigul", + mode => 0640, + source => "puppet:///sigul/server.conf" + require => [ Package["sigul"] ], + } + + file { "/var/lib/sigul/cert8.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_server_cert8.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/key3.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_server_key3.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/secmod.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_server_secmod.db", + require => Package["sigul"], + } + +} + diff --git a/modules/sigul/templates/bridge.conf.erb b/modules/sigul/templates/bridge.conf.erb new file mode 100644 index 0000000..01f3ee9 --- /dev/null +++ b/modules/sigul/templates/bridge.conf.erb @@ -0,0 +1,30 @@ +# This is a configuration for the sigul bridge. + +[bridge] +# Nickname of the bridge's certificate in the NSS database specified below +bridge-cert-nickname: sigul-bridge-cert +# Port on which the bridge expects client connections +client-listen-port: 44334 +# Port on which the bridge expects server connections +server-listen-port: 44333 +# A Fedora account system group required for access to the signing server. If +# empty, no Fedora account check is done. +#required-fas-group: +required-fas-group: signers +# User name and password for an account on the Fedora account system that can +# be used to verify group memberships +fas-user-name: fedoradummy +fas-password: <%= fedoraDummyUserPassword %> + +[daemon] +# The user to run as +unix-user: sigul +# The group to run as +unix-group: sigul + +[nss] +# Path to a directory containing a NSS database +nss-dir: /var/lib/sigul +# Password for accessing the NSS database. If not specified, the bridge will +# ask on startup +; nss-password: -- 1.5.5.6 From jkeating at redhat.com Sat Jul 25 03:53:25 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 25 Jul 2009 03:53:25 +0000 Subject: [PATCH] Have sign-vault1 use the sigul::server class to get its In-Reply-To: <1248494005-30782-2-git-send-email-jkeating@redhat.com> References: <1248494005-30782-1-git-send-email-jkeating@redhat.com> <1248494005-30782-2-git-send-email-jkeating@redhat.com> Message-ID: <1248494005-30782-3-git-send-email-jkeating@redhat.com> --- .../nodes/sign-vault1.fedora.phx.redhat.com.pp | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp b/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp index 4c57d01..912d050 100644 --- a/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp @@ -4,7 +4,9 @@ node "sign-vault1" { include phx include fas::client #include global - include pkgsigner + # Include the builder infrastructure so that we get the same rpm versions + include yum::repo::builder-infrastructure + include sigul::server # Hack but it's easy to predict and easy to follow: # exec { "disable-ssh": @@ -17,5 +19,7 @@ node "sign-vault1" { # command => '/etc/init.d/puppet stop; /sbin/chkconfig puppet off', # } +# Need iptables blocking everything here + } -- 1.5.5.6 From ricky at fedoraproject.org Sat Jul 25 04:14:04 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 25 Jul 2009 00:14:04 -0400 Subject: Proposed setup for sigul bridge/server for review In-Reply-To: <1248494005-30782-1-git-send-email-jkeating@redhat.com> References: <1248494005-30782-1-git-send-email-jkeating@redhat.com> Message-ID: <20090725041404.GO27214@alpha.rzhou.org> On 2009-07-25 03:53:23 AM, Jesse Keating wrote: > There is a bridge that clients communicate with (and I'm thinking > of forcing this through an ssh tunnel through bastion) and that > interacts with koji. There is also the server itself that has > the gpg keys on it and does the signing action. The server > initiates a connection to the bridge, so only the bridge has to > listen for connections. > > I think I have this mostly setup right, but I'd like some more eyes > on it before I commit. Thanks! Looks excellent to me, my only two comments are that you might want to make the files: /var/lib/sigul/.fedora-server-ca.cert /var/lib/sigul/.fedora.cert require => Package["sigul"], as well since they require the /var/lib/sigul directory (which I assume is provided by the package). 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 jkeating at redhat.com Sat Jul 25 04:56:12 2009 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 24 Jul 2009 21:56:12 -0700 Subject: Proposed setup for sigul bridge/server for review In-Reply-To: <20090725041404.GO27214@alpha.rzhou.org> References: <1248494005-30782-1-git-send-email-jkeating@redhat.com> <20090725041404.GO27214@alpha.rzhou.org> Message-ID: <1248497772.2861.124.camel@localhost.localdomain> On Sat, 2009-07-25 at 00:14 -0400, Ricky Zhou wrote: > Looks excellent to me, my only two comments are that you might want to > make the files: > > /var/lib/sigul/.fedora-server-ca.cert > /var/lib/sigul/.fedora.cert > > require => Package["sigul"], > > as well since they require the /var/lib/sigul directory (which I assume > is provided by the package). Good catch. I'll do that. I'm also going to squash the two commits into one since they are all related and the second one was an after thought. -- 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 Sat Jul 25 05:07:22 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 25 Jul 2009 05:07:22 +0000 Subject: [PATCH] Setup sigul bridge and client In-Reply-To: <1248498442-3872-1-git-send-email-jkeating@redhat.com> References: <1248498442-3872-1-git-send-email-jkeating@redhat.com> Message-ID: <1248498442-3872-2-git-send-email-jkeating@redhat.com> Add a sigul module with bridge and server classes. Adjust the sign-bridge1 node to use the new classes. Have sign-vault1 use the sigul::server class to get its configuration --- .../nodes/sign-bridge1.fedora.phx.redhat.com.pp | 17 +++- .../nodes/sign-vault1.fedora.phx.redhat.com.pp | 6 +- modules/sigul/files/server.conf | 47 +++++++++ modules/sigul/manifests/init.pp | 99 ++++++++++++++++++++ modules/sigul/templates/bridge.conf.erb | 30 ++++++ 5 files changed, 196 insertions(+), 3 deletions(-) create mode 100644 modules/sigul/files/server.conf create mode 100644 modules/sigul/manifests/init.pp create mode 100644 modules/sigul/templates/bridge.conf.erb diff --git a/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp b/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp index 3bfcb8a..6c5d295 100644 --- a/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign-bridge1.fedora.phx.redhat.com.pp @@ -3,7 +3,9 @@ node "sign-bridge1.fedora.phx.redhat.com" { include phx include fas::client #include global - #include pkgsigner + # Include the builder infrastructure so that we get the same rpm versions + include yum::repo::builder-infrastructure + include sigul::bridge # Hack but it's easy to predict and easy to follow: # exec { "disable-ssh": @@ -16,6 +18,17 @@ node "sign-bridge1.fedora.phx.redhat.com" { # command => '/etc/init.d/puppet stop; /sbin/chkconfig puppet off', # } + # Firewall Rules, allow sigul server through. + $tcpPorts = [ '44333' ] + $custom = [ ] + + iptables { '/etc/sysconfig/iptables': + content => template('system/iptables-template.conf.erb'), + } + + service { iptables: + ensure => running, + hasstatus => true, + } - } diff --git a/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp b/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp index 4c57d01..912d050 100644 --- a/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp +++ b/manifests/nodes/sign-vault1.fedora.phx.redhat.com.pp @@ -4,7 +4,9 @@ node "sign-vault1" { include phx include fas::client #include global - include pkgsigner + # Include the builder infrastructure so that we get the same rpm versions + include yum::repo::builder-infrastructure + include sigul::server # Hack but it's easy to predict and easy to follow: # exec { "disable-ssh": @@ -17,5 +19,7 @@ node "sign-vault1" { # command => '/etc/init.d/puppet stop; /sbin/chkconfig puppet off', # } +# Need iptables blocking everything here + } diff --git a/modules/sigul/files/server.conf b/modules/sigul/files/server.conf new file mode 100644 index 0000000..513cad5 --- /dev/null +++ b/modules/sigul/files/server.conf @@ -0,0 +1,47 @@ +# This is a configuration for the sigul server. + +[server] +# Host name of the publically acessible bridge to clients +bridge-hostname: sign-bridge1 +# Port on which the bridge expects server connections +bridge-port: 44333 +# Maximum accepted size of payload stored on disk +max-file-payload-size: 1073741824 +# Maximum accepted size of payload stored in server's memory +max-memory-payload-size: 1048576 +# Nickname of the server's certificate in the NSS database specified below +server-cert-nickname: sigul-server-cert + +[database] +# Path to a directory containing a SQLite database +;database-path: /var/lib/sigul + +[gnupg] +# Path to a directory containing GPG configuration and keyrings +gnupg-home: /var/lib/sigul/gnupg +# Default primary key type for newly created keys +gnupg-key-type: RSA +# Default primary key length for newly created keys +gnupg-key-length: 4096 +# Default subkey type for newly created keys, empty for no subkey +gnupg-subkey-type: +# Default subkey length for newly created keys if gnupg-subkey-type is not empty +; gnupg-subkey-length: 2048 +# Default key usage flags for newly created keys +gnupg-key-usage: encrypt, sign +# Length of key passphrases used for newsly created keys +passphrase-length: 64 + +[daemon] +# The user to run as +unix-user: sigul +# The group to run as +unix-group: sigul + +[nss] +# Path to a directory containing a NSS database +nss-dir: /var/lib/sigul +# Password for accessing the NSS database. If not specified, the server will +# ask on startup +; nss-password is not specified by default + diff --git a/modules/sigul/manifests/init.pp b/modules/sigul/manifests/init.pp new file mode 100644 index 0000000..be7023d --- /dev/null +++ b/modules/sigul/manifests/init.pp @@ -0,0 +1,99 @@ +class sigul { + + package { "sigul": + ensure => installed, + } +} + +class sigul::bridge inherits sigul { + + package { "koji"; + ensure => installed, + } + + file { "/etc/sigul/bridge.conf": + owner => "root", + group => "sigul", + mode => 0640, + content => template("sigul/bridge.conf.erb") + require => Package["sigul"], + } + + file { "/var/lib/sigul/cert8.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_bridge_cert8.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/key3.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_bridge_key3.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/secmod.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_bridge_secmod.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/.fedora-server-ca.cert": + owner => "sigul", + group => "sigul", + mode => 0644, + source => "puppet:///config/secure/fedora-ca.cert", + require => Package["sigul"], + } + + file { "/var/lib/sigul/.fedora.cert": + owner => "sigul", + group => "sigul", + mode => 0644, + source => "puppet:///config/secure/sigul_key_and_cert.pem", + require => Package["sigul"], + } + +} + +class sigul::server inherits sigul { + + file { "/etc/sigul/server.conf": + owner => "root", + group => "sigul", + mode => 0640, + source => "puppet:///sigul/server.conf" + require => Package["sigul"], + } + + file { "/var/lib/sigul/cert8.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_server_cert8.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/key3.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_server_key3.db", + require => Package["sigul"], + } + + file { "/var/lib/sigul/secmod.db": + owner => "sigul", + group => "sigul", + mode => 0600, + source => "puppet:///config/secure/sigul_server_secmod.db", + require => Package["sigul"], + } + +} + diff --git a/modules/sigul/templates/bridge.conf.erb b/modules/sigul/templates/bridge.conf.erb new file mode 100644 index 0000000..01f3ee9 --- /dev/null +++ b/modules/sigul/templates/bridge.conf.erb @@ -0,0 +1,30 @@ +# This is a configuration for the sigul bridge. + +[bridge] +# Nickname of the bridge's certificate in the NSS database specified below +bridge-cert-nickname: sigul-bridge-cert +# Port on which the bridge expects client connections +client-listen-port: 44334 +# Port on which the bridge expects server connections +server-listen-port: 44333 +# A Fedora account system group required for access to the signing server. If +# empty, no Fedora account check is done. +#required-fas-group: +required-fas-group: signers +# User name and password for an account on the Fedora account system that can +# be used to verify group memberships +fas-user-name: fedoradummy +fas-password: <%= fedoraDummyUserPassword %> + +[daemon] +# The user to run as +unix-user: sigul +# The group to run as +unix-group: sigul + +[nss] +# Path to a directory containing a NSS database +nss-dir: /var/lib/sigul +# Password for accessing the NSS database. If not specified, the bridge will +# ask on startup +; nss-password: -- 1.5.5.6 From jkeating at redhat.com Sat Jul 25 05:07:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 25 Jul 2009 05:07:21 +0000 Subject: Second try, patch set for sigul Message-ID: <1248498442-3872-1-git-send-email-jkeating@redhat.com> Here is a second try. This time I fixed with Ricky pointed out and squashed everything into one commit since it is all related. Arguably it should be two commits, one for the addition of the module and another commit for the .pp changes, but I'm already writing this so oh well. -- Jes From a.badger at gmail.com Sat Jul 25 13:55:17 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 25 Jul 2009 06:55:17 -0700 Subject: [PATCH] Setup sigul bridge and client In-Reply-To: <1248498442-3872-2-git-send-email-jkeating@redhat.com> References: <1248498442-3872-1-git-send-email-jkeating@redhat.com> <1248498442-3872-2-git-send-email-jkeating@redhat.com> Message-ID: <4A6B0EC5.9050108@gmail.com> On 07/24/2009 10:07 PM, Jesse Keating wrote: > + # Include the builder infrastructure so that we get the same rpm versions > + include yum::repo::builder-infrastructure Not necessarily related to enabling the builder repo: Is having the same rpm versions as the builders necessary? -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 jkeating at redhat.com Sat Jul 25 14:53:21 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 25 Jul 2009 07:53:21 -0700 Subject: [PATCH] Setup sigul bridge and client In-Reply-To: <4A6B0EC5.9050108@gmail.com> References: <1248498442-3872-1-git-send-email-jkeating@redhat.com> <1248498442-3872-2-git-send-email-jkeating@redhat.com> <4A6B0EC5.9050108@gmail.com> Message-ID: <1248533601.2861.126.camel@localhost.localdomain> On Sat, 2009-07-25 at 06:55 -0700, Toshio Kuratomi wrote: > Not necessarily related to enabling the builder repo: Is having the same > rpm versions as the builders necessary? Yes. The bridge and server will be dealing with rpms that are being built by koji, and will need to be able to understand the payloads and checksums, as well as perform the larger signing. As we make changes to rpm and update the builders to handle those changes, we'll have to update the signing and composing systems too. -- 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 Sat Jul 25 19:31:59 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 25 Jul 2009 13:31:59 -0600 Subject: torrent1 warnings. Message-ID: <80d7e4090907251231x46bb7289jb64ea813625f8af4@mail.gmail.com> Found some very old log btt files that were huge gzipped from January. Look like they were left over before new naming structure in logrotate was used. Removed them to give space. Looks like the service did not properly rotate logs last time and has been writing to a bad file descriptor for a while. Restarting bttrack btseed to reset log files. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From skvidal at fedoraproject.org Sun Jul 26 12:50:09 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 26 Jul 2009 08:50:09 -0400 (EDT) Subject: torrent1 warnings. In-Reply-To: <80d7e4090907251231x46bb7289jb64ea813625f8af4@mail.gmail.com> References: <80d7e4090907251231x46bb7289jb64ea813625f8af4@mail.gmail.com> Message-ID: On Sat, 25 Jul 2009, Stephen John Smoogen wrote: > Found some very old log btt files that were huge gzipped from January. > Look like they were left over before new naming structure in logrotate > was used. Removed them to give space. Looks like the service did not > properly rotate logs last time and has been writing to a bad file > descriptor for a while. Restarting bttrack btseed to reset log files. Thanks! -sv From smooge at gmail.com Sun Jul 26 16:51:45 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 26 Jul 2009 10:51:45 -0600 Subject: Cron /bin/rpm -Va --nofiles --nomd5 In-Reply-To: <20090726000004.A893B27D32@xen11.fedora.phx.redhat.com> References: <20090726000004.A893B27D32@xen11.fedora.phx.redhat.com> Message-ID: <80d7e4090907260951w43379dafm38b81a1c5dccb4ce@mail.gmail.com> On Sat, Jul 25, 2009 at 6:00 PM, Cron Daemon wrote: > Unsatisfied dependencies for hpadu-8.10-4.i386: hpsmh > Probably noted somewhere but this is the HP System Management Homepage. Product looks like it only works on RHEL-4 and before and seems to be considered dead software by HP (all the main pages say go find another product...) I am downloading the latest tools for this and see what it comes up as. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From mmcgrath at redhat.com Sun Jul 26 17:16:07 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 26 Jul 2009 12:16:07 -0500 (CDT) Subject: Cron /bin/rpm -Va --nofiles --nomd5 In-Reply-To: <80d7e4090907260951w43379dafm38b81a1c5dccb4ce@mail.gmail.com> References: <20090726000004.A893B27D32@xen11.fedora.phx.redhat.com> <80d7e4090907260951w43379dafm38b81a1c5dccb4ce@mail.gmail.com> Message-ID: On Sun, 26 Jul 2009, Stephen John Smoogen wrote: > On Sat, Jul 25, 2009 at 6:00 PM, Cron Daemon wrote: > > Unsatisfied dependencies for hpadu-8.10-4.i386: hpsmh > > > > Probably noted somewhere but this is the HP System Management > Homepage. Product looks like it only works on RHEL-4 and before and > seems to be considered dead software by HP (all the main pages say go > find another product...) I am downloading the latest tools for this > and see what it comes up as. > I suspect that can safely be removed. -Mike From a.badger at gmail.com Mon Jul 27 17:04:02 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 27 Jul 2009 10:04:02 -0700 Subject: Is F-community using its FAS account? Message-ID: <4A6DDE02.8020908@gmail.com> Hey, lmacken and I realized that we probably hadn't changed Fedora Community's password since moving it from the publictest machines to production so I did that today. But when I went to test it we couldn't figure out where it would actually be used:: [10:00:02] abadger1999: hmm, I'm actually not sure if that account is getting used at all. It looks like it is only used when the user is not logged in, but in that case they can't view users or anything FAS related as far as I can tell. J5 would know for sure So, is the account being used? If so how can I test that the password update worked okay? If not, can we disable the account? -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 Mon Jul 27 17:46:02 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 27 Jul 2009 10:46:02 -0700 Subject: AGPL Licensing: Another "configuration" file example Message-ID: <4A6DE7DA.60304@gmail.com> This wsgi script also helps illustrate some of smooge's concerns about what happens when configuration information is mixed into a script. It has two areas that differ between upstream's distribution and our own: The first is bad application design but I've seen this done frequently in PHP apps (and it sounds like Java frameworks like JBoss promote this as well). The fact that our apps are doing it shows it can occur in any language although we should be able to change our apps to work around it fairly easily: The scripts that start up our web applications under mod_wsgi all seem to have a bit of config tweaking. Historically, this is because we deployed with a start-app.py script that used the config file exclusively and started as a standalone daemon. The app.wsgi script would load the standalone daemon config file and then make some config changes in the wsgi script before starting the application server. This can be seen in the attached wsgi script in lines like this:: turbogears.update_config(configfile="/home/ricky/work/fedora/fas/fas.cfg", modulename="fas.config") turbogears.config.update({'global': {'server.environment': 'development'}}) For our TurboGears apps it should be pretty easy for us to work around that by moving all such lines into the config file instead of being in the script. But for third party PHP scripts licensed under AGPL and single file cgi scripts that we write what is our responsibility? I can see several options: 1) We must patch every script/app/etc to put the config into its own file. Those changes fall unde the AGPL and we try to get them upstream. The config file falls outside of the AGPL either via explicit license or some other way. 2) configuration, even embedded inside of an AGPL script is not subject to the AGPL because it's not copyrightable data. Second piece of code that varies between installations:: import sys sys.path.append('/home/ricky/work/fedora/fas/fas/') Setting the path at which to find the code must be done otherwise the script won't be able to find the code related to the web application itself. On different installations (our servers, developers' test machines, etc) this path will vary. Are those changes that are covered by the AGPL or are they non-copyrightable? Is there a difference if this is done manually by the system administrator vs automatically by the Makefiles/build scripts provided by upstream? This issue is harder to work around in code since finding the path to files is a chicken and egg problem. At some point, the executable has to hardcode at least one path to be able to load the rest of its information. -Toshio -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fas.wsgi URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lmacken at redhat.com Mon Jul 27 18:48:15 2009 From: lmacken at redhat.com (Luke Macken) Date: Mon, 27 Jul 2009 14:48:15 -0400 Subject: Is F-community using its FAS account? In-Reply-To: <4A6DDE02.8020908@gmail.com> References: <4A6DDE02.8020908@gmail.com> Message-ID: <20090727184815.GE9151@x300> On Mon, Jul 27, 2009 at 10:04:02AM -0700, Toshio Kuratomi wrote: > Hey, > > lmacken and I realized that we probably hadn't changed Fedora > Community's password since moving it from the publictest machines to > production so I did that today. But when I went to test it we couldn't > figure out where it would actually be used:: > > [10:00:02] abadger1999: hmm, I'm actually not sure if that > account is getting used at all. It looks like it is only used when the > user is not logged in, but in that case they can't view users or > anything FAS related as far as I can tell. J5 would know for sure > > So, is the account being used? If so how can I test that the password > update worked okay? If not, can we disable the account? I'm not sure if we want to disable this account. Ian is working on some statistics applications that make authenticated calls to FAS, and we will want this to work for anonymous users as well. luke From a.badger at gmail.com Mon Jul 27 19:17:29 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 27 Jul 2009 12:17:29 -0700 Subject: Fwd: Re: Is F-community using its FAS account? Message-ID: <4A6DFD49.20704@gmail.com> -------- Original Message -------- Subject: Re: Is F-community using its FAS account? Date: Mon, 27 Jul 2009 14:35:50 -0400 (EDT) From: John Palmieri To: Toshio Kuratomi It is used for getting a user's info when you are not logged in similar to the functionality of the bots in #fedora-devel. Going to this link (https://admin.fedoraproject.org/community/?username=jkeating#people) works so the password change worked. ----- "Toshio Kuratomi" wrote: > Hey, > > lmacken and I realized that we probably hadn't changed Fedora > Community's password since moving it from the publictest machines to > production so I did that today. But when I went to test it we > couldn't > figure out where it would actually be used:: > > [10:00:02] abadger1999: hmm, I'm actually not sure if > that > account is getting used at all. It looks like it is only used when > the > user is not logged in, but in that case they can't view users or > anything FAS related as far as I can tell. J5 would know for sure > > So, is the account being used? If so how can I test that the > password > update worked okay? If not, can we disable the account? > > -Toshio -- -- John (J5) Palmieri Software Engineer Red Hat, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From njbhatt18 at gmail.com Mon Jul 27 19:35:29 2009 From: njbhatt18 at gmail.com (Bhatt Niraj) Date: Mon, 27 Jul 2009 21:35:29 +0200 Subject: blogs.fedoraproject.org Update In-Reply-To: <20090723200020.GK5734@alpha.rzhou.org> References: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> <20090723200020.GK5734@alpha.rzhou.org> Message-ID: <8426c1370907271235x43b2e983pc26b5d2cd86afa7f@mail.gmail.com> Hi, I developed one site for Vibrant GNU Linux user group (vglug.info) and implemented spam protection for jobs. it is built in drupal. can we use drupal for this project? Regards, Niraj Bhatt 2009/7/23 Ricky Zhou > On 2009-07-24 01:27:34 AM, susmit shannigrahi wrote: > > It is not working for me. > > I can't login with my FAS credentials. > Hi, this is not live yet, please do not enter your real FAS credentials > there (it's currently going against a test FAS). When we do make this > live, it will be over SSL to avoid passwords being transmitted in > plaintext. > > Thanks, > Ricky > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -- Niraj Bhatt ------------------------------------------------------------ Give me space to stand, i will move the earth -------------- next part -------------- An HTML attachment was scrubbed... URL: From onekopaka at gmail.com Mon Jul 27 19:40:07 2009 From: onekopaka at gmail.com (Darren VanBuren) Date: Mon, 27 Jul 2009 12:40:07 -0700 Subject: blogs.fedoraproject.org Update In-Reply-To: <8426c1370907271235x43b2e983pc26b5d2cd86afa7f@mail.gmail.com> References: <9484fe43df0487500d6d7cbe5dad090f.squirrel@nb.tc> <20090723200020.GK5734@alpha.rzhou.org> <8426c1370907271235x43b2e983pc26b5d2cd86afa7f@mail.gmail.com> Message-ID: <407b25020907271240m2338e7a0u52291ec03f304424@mail.gmail.com> Considering we've now deployed to production, the answer is no. We've found a spam solution as well, we have chosen BadBehavior. Thanks, Darren L. VanBuren ===================== http://oks.verymad.net/ On Mon, Jul 27, 2009 at 12:35, Bhatt Niraj wrote: > Hi, > > I developed one site for Vibrant GNU Linux user group (vglug.info) and > implemented spam protection for jobs. it is built in drupal. can we use > drupal for this project? > > Regards, > Niraj Bhatt > > 2009/7/23 Ricky Zhou >> >> On 2009-07-24 01:27:34 AM, susmit shannigrahi wrote: >> > It is not working for me. >> > I can't login with my FAS credentials. >> Hi, this is not live yet, please do not enter your real FAS credentials >> there (it's currently going against a test FAS). ?When we do make this >> live, it will be over SSL to avoid passwords being transmitted in >> plaintext. >> >> Thanks, >> Ricky >> >> _______________________________________________ >> Fedora-infrastructure-list mailing list >> Fedora-infrastructure-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list >> > > > > -- > Niraj Bhatt > ------------------------------------------------------------ > Give me space to stand, i will move the earth > > > _______________________________________________ > 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 Mon Jul 27 19:56:23 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 27 Jul 2009 15:56:23 -0400 Subject: AGPL Licensing: Another "configuration" file example In-Reply-To: <4A6DE7DA.60304@gmail.com> References: <4A6DE7DA.60304@gmail.com> Message-ID: <20090727195623.GF6541@alpha.rzhou.org> On 2009-07-27 10:46:02 AM, Toshio Kuratomi wrote: > This wsgi script also helps illustrate some of smooge's concerns about > what happens when configuration information is mixed into a script. It > has two areas that differ between upstream's distribution and our own: > > The first is bad application design but I've seen this done frequently > in PHP apps (and it sounds like Java frameworks like JBoss promote this > as well). The fact that our apps are doing it shows it can occur in any > language although we should be able to change our apps to work around it > fairly easily: > > The scripts that start up our web applications under mod_wsgi all seem > to have a bit of config tweaking. Historically, this is because we > deployed with a start-app.py script that used the config file > exclusively and started as a standalone daemon. The app.wsgi script > would load the standalone daemon config file and then make some config > changes in the wsgi script before starting the application server. This > can be seen in the attached wsgi script in lines like this:: Another example of something that could be considered mixing code and configuration in .wsgi files is the usage of WSGI middleware (in TG1 at least, Toshio mentioned that things might be more cleanly separated in TG2 now). Right now, to add middleware to a TG1 application, we'd edit the .wsgi to add code to wrap the application in middleware - it isn't 100% clear to us where this kind of change would fall from the license's standpoint though. 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 dennis at ausil.us Tue Jul 28 00:12:26 2009 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 27 Jul 2009 19:12:26 -0500 Subject: bash_history on x86-5 Message-ID: <200907271916.13681.dennis@ausil.us> I just deleted my bas_history on x86-5 i typed my password on accident Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Tue Jul 28 16:06:28 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 09:06:28 -0700 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F166A.9080307@redhat.com> References: <4A6F166A.9080307@redhat.com> Message-ID: <4A6F2204.8000707@gmail.com> On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: > Hopefully, this will provide a solid groundwork for Thursday's discussions. > Excellent! I think this provides some good options for us wrt distributing changes for production. Are the questions about our staging and publictest environments still in discussion with legal? In case those questions were missed, here they are again: == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """ Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. """ * Is the preamble legally binding/part of the AGPL or should we ignore anything there? * admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself? * If we can run apps in staging without providing source to those without shell accounts there, can we also run apps on publictest boxes without providing source to those without shell accounts there? -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 Tue Jul 28 16:11:36 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 09:11:36 -0700 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F166A.9080307@redhat.com> References: <4A6F166A.9080307@redhat.com> Message-ID: <4A6F2338.5000700@gmail.com> On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: > Q: Do config changes count as code changes if the config file is marked > as being AGPL? > > Red Hat Legal feels that changes to configuration lines inside a script > do not represent a copyrightable change to the script, and therefore > they do not trigger the AGPLv3 section 13 requirement (this is the > requirement on sharing the AGPLv3 covered code), because the config > change does not result in a "modified version" as that term is used in > AGPLv3. > > They advise that it would be preferred if applications clearly separated > the configuration files from the actual web application code and > scripts, as it minimizes licensing concerns. > > Q: What do we have to do to make config files not be licensed under > AGPL? (We want to keep passwords private, for instance). > > Red Hat Legal advises that for config files included in an AGPLv3 > distribution, you can cause them to fall outside of the AGPLv3 (at least > section 13), by explicitly granting an additional permission stating > that such files (assuming that they are copyrightable) are covered by > the AGPLv3, but are not subject to the AGPLv3 section 13 requirement. > > Red Hat Legal would be happy to draft up wording for such an additional > permission for our needs. > I take these two to answers to mean roughly: Configuration is not copyrightable. Therefore changes to configuration files and configuration within scripts is not something that needs to be provided under the AGPLv3. If we are still concerned about them, Red Hat Legal will help us write a license for the config files that makes clear that changes to them do not have to be distributed. Is that a good summary? Thanks again spot! -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 tcallawa at redhat.com Tue Jul 28 15:16:58 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Jul 2009 11:16:58 -0400 Subject: A discussion on licensing and the AGPLv3 Message-ID: <4A6F166A.9080307@redhat.com> Hi guys, After several rounds of discussion with Richard Fontana, I think we have more information about how to move forward here. This is Fedora's general policy around license compatibility concerns: * If the code is bundled together in the same tarball, and it is compiled together, then we worry about license compatibilities. * If the code is not bundled together, we worry about it if there is an incompatibility across shared library linking (e.g. GPL incompatible library cannot be used by GPL code) * For interpreted languages (Python, Java), we don't worry about it outside of the tarball. (This policy is subject to modification in specific cases but represents our default approach to license compatibility issues.) I've proposed that we apply this logic to the AGPLv3, and Red Hat Legal agrees. So, if we apply this to the AGPLv3, it means that we only need to be distributing the bits under AGPLv3 that make up our web app, and any other code that would be "bundled in the same tarball" for distribution. All of the other interpreted dependencies should be listed, but do not need to be provided. Now, there were some specific questions about how we should be distributing the sources to comply with the AGPLv3, here are the answers from Red Hat Legal: Q: What are legal means of giving people access to the corresponding source? + Source repository at no particular version (assuming all of our patches are applied to trunk -- and trunk might contain other changes as well, including full or partial reversions of those changes in a later revision) * Red Hat Legal feels this is not sufficient. + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) * Red Hat Legal feels this is not sufficient. + Pointing exactly to source repository branch or tag of the exact version we're running * Red Hat Legal says that this is OK. + Home page of the project (example: http://fedorahosted.org/fas) * Red Hat Legal feels this is not sufficient. + Just a page specifically linking to the sources and all of the patches we've applied * Red Hat Legal says that this is OK. + links to base srpm and page listing patches * Red Hat Legal says that this is OK. + links to base srpm and tickets in trac that have patches attached * Red Hat Legal says that this is OK. + links to base srpm and tickets in trac that point to commits in SCM that are applied against different versions (HEAD vs the last release, for instance) * Red Hat Legal feels this is not sufficient. + A page linking to the sources and a page linking to any hotfixes we've applied to any of our apps (ie, a query in infrastructure's trac that gets all hotfixes for all of our apps). * Red Hat Legal says that this is OK. + I'm assuming these to be fine: tarball, srpm that matches what's running, actual links to base tarball and to all of the patches * Red Hat Legal confirms that these are all OK Q: Do config changes count as code changes if the config file is marked as being AGPL? Red Hat Legal feels that changes to configuration lines inside a script do not represent a copyrightable change to the script, and therefore they do not trigger the AGPLv3 section 13 requirement (this is the requirement on sharing the AGPLv3 covered code), because the config change does not result in a "modified version" as that term is used in AGPLv3. They advise that it would be preferred if applications clearly separated the configuration files from the actual web application code and scripts, as it minimizes licensing concerns. Q: What do we have to do to make config files not be licensed under AGPL? (We want to keep passwords private, for instance). Red Hat Legal advises that for config files included in an AGPLv3 distribution, you can cause them to fall outside of the AGPLv3 (at least section 13), by explicitly granting an additional permission stating that such files (assuming that they are copyrightable) are covered by the AGPLv3, but are not subject to the AGPLv3 section 13 requirement. Red Hat Legal would be happy to draft up wording for such an additional permission for our needs. Q: Does each page of the web app have to have a link to the source? A: No, you just have to make sure that users are "prominently offered" an opportunity to get the source. Links from the main page of the web application meet this criteria. Hopefully, this will provide a solid groundwork for Thursday's discussions. Thanks, ~spot From tcallawa at redhat.com Tue Jul 28 16:13:40 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Jul 2009 12:13:40 -0400 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F2338.5000700@gmail.com> References: <4A6F166A.9080307@redhat.com> <4A6F2338.5000700@gmail.com> Message-ID: <4A6F23B4.2030806@redhat.com> On 07/28/2009 12:11 PM, Toshio Kuratomi wrote: > I take these two to answers to mean roughly: > > Configuration is not copyrightable. Therefore changes to configuration > files and configuration within scripts is not something that needs to be > provided under the AGPLv3. If we are still concerned about them, Red > Hat Legal will help us write a license for the config files that makes > clear that changes to them do not have to be distributed. Yes, that's precisely how I interpreted this as well. I did miss the other questions, and have just now sent them over to RH Legal. ~spot From smooge at gmail.com Tue Jul 28 17:38:44 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 28 Jul 2009 11:38:44 -0600 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F166A.9080307@redhat.com> References: <4A6F166A.9080307@redhat.com> Message-ID: <80d7e4090907281038k3b550193nf84320d48caf159c@mail.gmail.com> On Tue, Jul 28, 2009 at 9:16 AM, Tom "spot" Callaway wrote: > Hi guys, > > After several rounds of discussion with Richard Fontana, I think we have > more information about how to move forward here. > > This is Fedora's general policy around license compatibility concerns: > > * If the code is bundled together in the same tarball, and it is > compiled together, then we worry about license compatibilities. > * If the code is not bundled together, we worry about it if there is an > incompatibility across shared library linking (e.g. GPL incompatible > library cannot be used by GPL code) > * For interpreted languages (Python, Java), we don't worry about it > outside of the tarball. > > (This policy is subject to modification in specific cases but represents > our default approach to license compatibility issues.) > > I've proposed that we apply this logic to the AGPLv3, and Red Hat Legal > agrees. > > So, if we apply this to the AGPLv3, it means that we only need to be > distributing the bits under AGPLv3 that make up our web app, and any > other code that would be "bundled in the same tarball" for distribution. > All of the other interpreted dependencies should be listed, but do not > need to be provided. > > Now, there were some specific questions about how we should be > distributing the sources to comply with the AGPLv3, here are the answers > from Red Hat Legal: > > Q: What are legal means of giving people access to the corresponding source? > > ? ? + Source repository at no particular version (assuming all of our > patches are applied to trunk -- and trunk might contain other changes as > well, including full or partial reversions of those changes in a later > revision) > > ? ? * Red Hat Legal feels this is not sufficient. > > ? ? + Source repository at no particular version (assuming all of our > patches are applied to a branch that mirrors production) > > ? ? * Red Hat Legal feels this is not sufficient. > > ? ? + Pointing exactly to source repository branch or tag of the exact > version we're running > > ? ? * Red Hat Legal says that this is OK. > > ? ? + Home page of the project (example: http://fedorahosted.org/fas) > > ? ? * Red Hat Legal feels this is not sufficient. > > ? ? + Just a page specifically linking to the sources and all of the > patches we've applied > > ? ? * Red Hat Legal says that this is OK. > > ? ? + links to base srpm and page listing patches > > ? ? * Red Hat Legal says that this is OK. > > ? ? + links to base srpm and tickets in trac that have patches attached > > ? ? * Red Hat Legal says that this is OK. > > ? ? + links to base srpm and tickets in trac that point to commits in > SCM that are applied against different versions (HEAD vs the last > release, for instance) > > ? ? * Red Hat Legal feels this is not sufficient. > > ? ? + A page linking to the sources and a page linking to any hotfixes > we've applied to any of our apps (ie, a query in infrastructure's trac > that gets all hotfixes for all of our apps). > > ? ? * Red Hat Legal says that this is OK. > > ? ? + I'm assuming these to be fine: tarball, srpm that matches what's > running, actual links to base tarball and to all of the patches > > ? ? * Red Hat Legal confirms that these are all OK > > Q: ?Do config changes count as code changes if the config file is marked > as being AGPL? > > Red Hat Legal feels that changes to configuration lines inside a script > do not represent a copyrightable change to the script, and therefore > they do not trigger the AGPLv3 section 13 requirement (this is the > requirement on sharing the AGPLv3 covered code), because the config > change does not result in a "modified version" as that term is used in > AGPLv3. > > They advise that it would be preferred if applications clearly separated > the configuration files from the actual web application code and > scripts, as it minimizes licensing concerns. > > Q: What do we have to do to make config files not be licensed under > AGPL? (We want to keep passwords private, for instance). > > Red Hat Legal advises that for config files included in an AGPLv3 > distribution, you can cause them to fall outside of the AGPLv3 (at least > section 13), by explicitly granting an additional permission stating > that such files (assuming that they are copyrightable) are covered by > the AGPLv3, but are not subject to the AGPLv3 section 13 requirement. > > Red Hat Legal would be happy to draft up wording for such an additional > permission for our needs. > > Q: Does each page of the web app have to have a link to the source? > > A: ?No, you just have to make sure that users are "prominently offered" > an opportunity to get the source. Links from the main page of the web > application meet this criteria. > > Hopefully, this will provide a solid groundwork for Thursday's discussions. > > Thanks, Thankyou Tom, It would seem that the sufficient way to show our software would be to put into process of deploying it via RPM or 'solid' tarball. The process for dealing with hot-fixes etc that are outside of config file changes will require a methodology so that we can do say a rpm -V mooksha and see only files listed as c being changed. What is a copyrightable change? I am guessing this is a standard loose definition that basically falls under the usual legal "I know it when i see it". (eg changing PASSWORD="foobaz" is not copyrightable but changing if (PASSWORD != "foobaz") to if (PASSWORD == "foobaz") is. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From smooge at gmail.com Tue Jul 28 17:53:47 2009 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 28 Jul 2009 11:53:47 -0600 Subject: Thursday meeting. Message-ID: <80d7e4090907281053o1b531208i8e2c4490f03940b1@mail.gmail.com> Mike will be out at training for this meeting. Please send me any agenda items that you feel need to be addressed so we can get through them in the requisite 50 minutes or so. 1) AGPL Licensing updates. 2) Mirror madness 3) ... 4) ... -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning From tcallawa at redhat.com Tue Jul 28 19:09:59 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Jul 2009 15:09:59 -0400 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F2204.8000707@gmail.com> References: <4A6F166A.9080307@redhat.com> <4A6F2204.8000707@gmail.com> Message-ID: <4A6F4D07.8060404@redhat.com> On 07/28/2009 12:06 PM, Toshio Kuratomi wrote: > On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: > >> Hopefully, this will provide a solid groundwork for Thursday's discussions. >> > > Excellent! I think this provides some good options for us wrt > distributing changes for production. Are the questions about our > staging and publictest environments still in discussion with legal? > > In case those questions were missed, here they are again: Q: Is the preamble legally binding/part of the AGPL or should we ignore anything there? Red Hat Legal advises that the preamble is not legally binding. It is there only to provide some guidance as to how to interpret the binding parts of the license. In general, Red Hat Legal advises that no one should think too much about (A/L)GPL preambles. ;) Q: admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself? Red Hat Legal says: No. However, I suppose you could solve the problem by writing an additional permission that says that pushing the webapp to admin.stg.f.o does not trigger AGPL sec. 13. (You could also word something more broadly to allow downstream non-Fedora users to take advantage of the same principle, in circumstances involving testing on public staging sites, but it might be difficult to word that without creating a loophole.) This doesn't work if you start using upstream-of-Fedora AGPL code. ~spot From a.badger at gmail.com Tue Jul 28 19:38:34 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 12:38:34 -0700 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F4D07.8060404@redhat.com> References: <4A6F166A.9080307@redhat.com> <4A6F2204.8000707@gmail.com> <4A6F4D07.8060404@redhat.com> Message-ID: <4A6F53BA.4030401@gmail.com> On 07/28/2009 12:09 PM, Tom "spot" Callaway wrote: > On 07/28/2009 12:06 PM, Toshio Kuratomi wrote: >> On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: >> >>> Hopefully, this will provide a solid groundwork for Thursday's discussions. >>> >> >> Excellent! I think this provides some good options for us wrt >> distributing changes for production. Are the questions about our >> staging and publictest environments still in discussion with legal? >> >> In case those questions were missed, here they are again: > > Q: Is the preamble legally binding/part of the AGPL or should we ignore > anything there? > > Red Hat Legal advises that the preamble is not legally binding. It is > there only to provide some guidance as to how to interpret the binding > parts of the license. In general, Red Hat Legal advises that no one > should think too much about (A/L)GPL preambles. ;) > > Q: admin.stg.fedoraproject.org is accessible by the general public but > it isn't meant for the general public's use -- it's for developers to > collaborate on what will be on the production site, > admin.fedoraproject.org. Those developers collaborate over the internet > which is why it's available on the internet. Does this excuse us from > providing source to people who do not have shell access to the server > itself? > > Red Hat Legal says: > No. However, I suppose you could solve the problem by writing an > additional permission that says that pushing the webapp to admin.stg.f.o > does not trigger AGPL sec. 13. (You could also word something more > broadly to allow downstream non-Fedora users to take advantage of the > same principle, in circumstances involving testing on public staging > sites, but it might be difficult to word that without creating a > loophole.) This doesn't work if you start using > upstream-of-Fedora AGPL code. > Okay guys, time to get creative :-) The exception would be one way we could go with this. It doesn't help if we deploy launchpad or similar. It also doesn't help third parties looking to deploy our code (without legal sitting down and working out something that doesn't have loopholes). Deploying to staging directly from a specific VCS branch could work -- but then we'd have to have different methods for VCS vs rpm (since we're using staging for both deployment testing and late development testing). Having a cron job that took differences between staging and baseline and uploaded it somewhere public could work but it would be hard to make the script generic enough, I think. Should we ask Legal if we could stick Apache Basic Auth (using mod_auth_postgres) in front of staging and then it would be okay? Or if we used openvpn to connect to http(s) on staging? -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 tcallawa at redhat.com Tue Jul 28 20:21:02 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Jul 2009 16:21:02 -0400 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F53BA.4030401@gmail.com> References: <4A6F166A.9080307@redhat.com> <4A6F2204.8000707@gmail.com> <4A6F4D07.8060404@redhat.com> <4A6F53BA.4030401@gmail.com> Message-ID: <4A6F5DAE.7040806@redhat.com> On 07/28/2009 03:38 PM, Toshio Kuratomi wrote: > Should we ask Legal if we could stick Apache Basic Auth (using > mod_auth_postgres) in front of staging and then it would be okay? Or if > we used openvpn to connect to http(s) on staging? These are both good ideas, would you like me to float them past RH Legal? ~spot From a.badger at gmail.com Tue Jul 28 20:40:27 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 13:40:27 -0700 Subject: A discussion on licensing and the AGPLv3 In-Reply-To: <4A6F5DAE.7040806@redhat.com> References: <4A6F166A.9080307@redhat.com> <4A6F2204.8000707@gmail.com> <4A6F4D07.8060404@redhat.com> <4A6F53BA.4030401@gmail.com> <4A6F5DAE.7040806@redhat.com> Message-ID: <4A6F623B.9050602@gmail.com> On 07/28/2009 01:21 PM, Tom "spot" Callaway wrote: > On 07/28/2009 03:38 PM, Toshio Kuratomi wrote: >> Should we ask Legal if we could stick Apache Basic Auth (using >> mod_auth_postgres) in front of staging and then it would be okay? Or if >> we used openvpn to connect to http(s) on staging? > > These are both good ideas, would you like me to float them past RH Legal? > Yes, please. I think it would look something like this: sysadmin-XXX group can ssh into publictest boxes to work on applications. sysadmin-YYY group can ssh into staging boxes to work on applications. Not all the people in those groups will be working on the same applications (some work on Fedora Community, some on FAS, some don't work on developing applications at all) but they will all be part of the Fedora Infrastructure team. For legal: If we limit who can hit the web apps via apache basic auth or openvpn to the sysadmin-XXX and sysadmin-YYY groups, can we forgo having a direct pointer to the corresponding source? On the infrastructure side, we have to figure out if this is going to be too limiting. (ie, we need people specifically not in sysadmin-XXX or sysadmin-YYY to test our changes before we deploy). -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 tcallawa at redhat.com Tue Jul 28 21:25:05 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Jul 2009 17:25:05 -0400 Subject: Brainstorming Session for Fedora Community 2.0 - Monday August 3, 2009 - 1500 UTC Message-ID: <4A6F6CB1.1080202@redhat.com> For those of you who haven't no idea what "Fedora Community" is, its our newest Fedora web application, providing a window into the Fedora distribution, and leveraging the power of Fedora's Account System, Bodhi, Bugzilla, Koji, and PackageDB into a single user-friendly website. It is built entirely with Free Software, such as Moksha and Turbogears 2. Fedora Community is designed to simplify Fedora workflows and bring transparency to Fedora processes: https://admin.fedoraproject.org/community What you see on that URL is our 1.0 milestone, but we already have lots of ideas on improvements and new functionality that we'd like to develop for our 2.0 release. So, we're going to have a public brainstorming session on Monday, August 3rd, 2009: * The session will be held at 1500 UTC (11 AM Eastern) (In addition, if there are enough interested international folks who cannot attend the session due to their timezone, please let me know, and we will try to schedule a future session that works for you) We're going to use a variety of ways to be involved: * IRC: #moksha on irc.freenode.net (we'll be watching and taking questions from the channel) * Gobby: We're going to keep our notes in Gobby, an open source collaboration tool. The name of our document is "Fedora Community Brainstorm", see http://fedoraproject.org/wiki/Communicate/GobbyHowTo for information on how to connect * Telephone: This is where we'll be doing the talking. US Toll-Free: 800-451-8679 Conference Code: 22717 79826 (If you need an international dial-in number, please email me with your country, and I may be able to provide it.) Please be kind and mute your line if you're not asking a question. If the noise on the call becomes unbearable, I will mute everyone. :) Questions about the meeting? Email me. Questions about Fedora Community 2.0? Come to the brainstorming session! Can't make it to the session and want to suggest something? Login to Gobby and add it to our notes before the session. Thanks, Tom "spot" Callaway, Fedora Community Cat Herder From a.badger at gmail.com Tue Jul 28 22:58:41 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 15:58:41 -0700 Subject: transif user in packager group Message-ID: <4A6F82A1.7030905@gmail.com> Today we added the transif user to the packager group because transifex lost the ability to add translations for comps. At the moment, this doesn't affect much -- packager group only gives you the ability to commit to comps and what packages you are given explicit rights to. However, it may become bigger in the future since we may allow people to specify that anyone in packager can commit to their packages. transif's last commit to the comps files was around the 17th of July. If anyone can recall some action or config change that they might have performed that would have changed whether transif could commit to comps between 17th of July and today or can think of a better way to give transif access to the comps cvs repo please speak up! it would be better long-term if transif was not in the packager group. The only solution we've come up with that doesn't use the packager group so far requires that we do two things: 1) add cvs acls for transif to commit to comps. 2) set filesystem acls so transif can commit to comps. Doing #2 isn't that great an idea as it's a one-off doing something not readily apparent (we don't use fs acls anywhere else in cvs). But if it could be puppet managed it might not be too bad. -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 Tue Jul 28 23:14:14 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 16:14:14 -0700 Subject: AGPL compliancewith moksha Message-ID: <4A6F8646.4020700@gmail.com> Okay, We've got to do some work for AGPL compliance with moksha. First, a few restrictions that we'll have to live with until we can figure out a legal way to do them better: * We cannot do development work directly fedoracommunity/moksha on staging for now. All fedoracommunity/moksha changes must be deployed to staging in the form of an rpm. * lmacken has confirmed that staging is currently deployed from rpm. * **The same for the publictest instances** * If legal approves of using Apache Basic Auth to fix this, we can use that to allow use of the publictest boxes again. Note, though, that that approval will still restrict us (for instance, ianweller is using pt7 to demo his fedora community stats branch. He won't be able to demo it to people outside of sysadmin-test with the Apache Basic Auth solution in place). Some things we need to code into Fedora Community: * We need to be able to customize the footer or front page of fedoracommunity to point to infrastructure.fedoraproject.org for the sources and to trac for hotfixes. * Note that for certain uses of publictest/staging, this can work as well. For instance, ianweller could run his demo strictly from a git checkout and the configuration can point people to that *specific* revision. * Upstream moksha/fedoracommunity might want to change their default footer/frontpage to point to the upstream tarballs as legal says the project page isn't good enough for people running it to be compliant. -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 Wed Jul 29 02:12:36 2009 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 28 Jul 2009 21:12:36 -0500 (CDT) Subject: transif user in packager group In-Reply-To: <4A6F82A1.7030905@gmail.com> References: <4A6F82A1.7030905@gmail.com> Message-ID: On Tue, 28 Jul 2009, Toshio Kuratomi wrote: > Today we added the transif user to the packager group because transifex > lost the ability to add translations for comps. At the moment, this > doesn't affect much -- packager group only gives you the ability to > commit to comps and what packages you are given explicit rights to. > However, it may become bigger in the future since we may allow people to > specify that anyone in packager can commit to their packages. > > transif's last commit to the comps files was around the 17th of July. > If anyone can recall some action or config change that they might have > performed that would have changed whether transif could commit to comps > between 17th of July and today or can think of a better way to give > transif access to the comps cvs repo please speak up! it would be > better long-term if transif was not in the packager group. > > The only solution we've come up with that doesn't use the packager group > so far requires that we do two things: > 1) add cvs acls for transif to commit to comps. > 2) set filesystem acls so transif can commit to comps. > > Doing #2 isn't that great an idea as it's a one-off doing something not > readily apparent (we don't use fs acls anywhere else in cvs). But if it > could be puppet managed it might not be too bad. > 2 is the more secure option. I want to find out what happened here. -Mike From a.badger at gmail.com Wed Jul 29 03:17:21 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 28 Jul 2009 20:17:21 -0700 Subject: transif user in packager group In-Reply-To: <4A6F82A1.7030905@gmail.com> References: <4A6F82A1.7030905@gmail.com> Message-ID: <4A6FBF41.40306@gmail.com> On 07/28/2009 03:58 PM, Toshio Kuratomi wrote: > Today we added the transif user to the packager group because transifex > lost the ability to add translations for comps. At the moment, this > doesn't affect much -- packager group only gives you the ability to > commit to comps and what packages you are given explicit rights to. > However, it may become bigger in the future since we may allow people to > specify that anyone in packager can commit to their packages. > > transif's last commit to the comps files was around the 17th of July. > If anyone can recall some action or config change that they might have > performed that would have changed whether transif could commit to comps > between 17th of July and today or can think of a better way to give > transif access to the comps cvs repo please speak up! it would be > better long-term if transif was not in the packager group. > Correction: 17th of June, not July. -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 thinklinux.ssh at gmail.com Wed Jul 29 07:00:42 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Wed, 29 Jul 2009 12:30:42 +0530 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. Message-ID: Hi, I am quite "frightened" to take up this topic again and again lest you all be bored. But interestingly, this one http://publictest15.fedoraproject.org/calender/ can fulfill all our requisites. But, I don't use a calender on my phone, so I never used remote export/import etc. And no surprise that I shall not be able to test it fully. So, if someone who is familiar with these help me out, it will be nice. Thanks. [1] https://fedorahosted.org/fedora-infrastructure/ticket/1197 -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From me at davidjmemmett.co.uk Wed Jul 29 07:47:38 2009 From: me at davidjmemmett.co.uk (David JM Emmett) Date: Wed, 29 Jul 2009 08:47:38 +0100 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. In-Reply-To: References: Message-ID: <1248853658.8571.192.camel@can11.canstudiosltd.thecan> > Hi, Hey, > I am quite "frightened" to take up this topic again and again lest you > all be bored. One of my good deeds for the week could be to help you sort this out ;). > But interestingly, this one > http://publictest15.fedoraproject.org/calender/ can fulfill all our > requisites. > I have played with WebCalendar in the past. As far as I can remember - it's not written in the most conventional/maintainable way, as in something I write quickly in a day would no doubt be a lot easier to maintain and be standards compliant. > But, I don't use a calender on my phone, so I never used remote > export/import etc. And no surprise that I shall not be able to test it > fully. So, if someone who is familiar with these help me out, it will > be nice. I cannot live without the calendar on my iPhone! > Thanks. > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/1197 > > Cheers, David JM Emmett From me at davidjmemmett.co.uk Wed Jul 29 08:24:09 2009 From: me at davidjmemmett.co.uk (David JM Emmett) Date: Wed, 29 Jul 2009 09:24:09 +0100 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. In-Reply-To: References: Message-ID: <1248855849.8571.219.camel@can11.canstudiosltd.thecan> Also to note - WebCalendar is rather inaccessible to users without JavaScript, whether WCAG are to be followed / are a requirement I don't know - just thought I'd point it out. I also don't like their usage of JavaScript - it's very messy! Cheers, David JM Emmett From thinklinux.ssh at gmail.com Wed Jul 29 08:51:42 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Wed, 29 Jul 2009 14:21:42 +0530 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. In-Reply-To: <1248853658.8571.192.camel@can11.canstudiosltd.thecan> References: <1248853658.8571.192.camel@can11.canstudiosltd.thecan> Message-ID: > One of my good deeds for the week could be to help you sort this out ;). Great!!! Thanks. I have started to put down the test cases. > I have played with WebCalendar in the past. As far as I can remember - > it's not written in the most conventional/maintainable way, as in > something I write quickly in a day would no doubt be a lot easier to > maintain and be standards compliant. But then, you/we have to maintain that forever. :) > I cannot live without the calendar on my iPhone! Surely that helps us testing. :) As for javascript, we son't seem to have much option as no other app does not even come close as per our requirement. And, I am also interested in writting an calendering app on our own. Which I communicated to Mike personally. But, not right now. This is long a overdue and we shall miss the deadline of F12. Lets put something in place first. Then we will think of an elegant solution. Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India From me at davidjmemmett.co.uk Wed Jul 29 09:49:28 2009 From: me at davidjmemmett.co.uk (David JM Emmett) Date: Wed, 29 Jul 2009 10:49:28 +0100 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. In-Reply-To: References: <1248853658.8571.192.camel@can11.canstudiosltd.thecan> Message-ID: <1248860968.8571.240.camel@can11.canstudiosltd.thecan> Okays, As I'm relatively new to this list, I don't really have access to much - so I'll just fire away... 1) When is F12 deadline - how does this coincide with it? 2) Where are the requirements? 3) You said "I have started to put down the test cases." - I say, "where are they" ;) 4) What's the Fedora Infrastructure Development Workflow? Cheers, David JM Emmett On Wed, 2009-07-29 at 14:21 +0530, susmit shannigrahi wrote: > > One of my good deeds for the week could be to help you sort this out ;). > Great!!! Thanks. > I have started to put down the test cases. > > > > I have played with WebCalendar in the past. As far as I can remember - > > it's not written in the most conventional/maintainable way, as in > > something I write quickly in a day would no doubt be a lot easier to > > maintain and be standards compliant. > > But then, you/we have to maintain that forever. :) > > > > I cannot live without the calendar on my iPhone! > Surely that helps us testing. :) > > > As for javascript, we son't seem to have much option as no other app > does not even come close as per our requirement. > > And, I am also interested in writting an calendering app on our own. > Which I communicated to Mike personally. But, not right now. This is > long a overdue and we shall miss the deadline of F12. Lets put > something in place first. Then we will think of an elegant solution. > > Thanks. > > > From thinklinux.ssh at gmail.com Thu Jul 30 03:52:04 2009 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Thu, 30 Jul 2009 09:22:04 +0530 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. In-Reply-To: <1248860968.8571.240.camel@can11.canstudiosltd.thecan> References: <1248853658.8571.192.camel@can11.canstudiosltd.thecan> <1248860968.8571.240.camel@can11.canstudiosltd.thecan> Message-ID: On Wed, Jul 29, 2009 at 3:19 PM, David JM Emmett wrote: > Okays, > > As I'm relatively new to this list, I don't really have access to much - > so I'll just fire away... > > 1) When is F12 deadline - how does this coincide with it? Nothing really. But it is a loose deadline marked by an event. > 2) Where are the requirements? > 3) You said "I have started to put down the test cases." - I say, "where > are they" ;) Not actually test cases, but these are the things we need to examine https://fedoraproject.org/wiki/User:Herlo/Fedora_Calendar_Project_Desired_Features_(Draft)#Must_have > 4) What's the Fedora Infrastructure Development Workflow? Mike, Ricky? You will be far better person to answer it. :) Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit ============================================= From david at gnsa.us Thu Jul 30 13:27:12 2009 From: david at gnsa.us (David Nalley) Date: Thu, 30 Jul 2009 09:27:12 -0400 Subject: Ok. Looks like this one _may_ fulfill our calendering needs. Testing required. In-Reply-To: References: Message-ID: On Wed, Jul 29, 2009 at 3:00 AM, susmit shannigrahi wrote: > Hi, > > I am quite "frightened" to take up this topic again and again lest you > all be bored. > > But interestingly, this one > http://publictest15.fedoraproject.org/calender/ can fulfill all our > requisites. > > But, I don't use a calender on my phone, so I never used remote > export/import etc. And no surprise that I shall not be able to test it > fully. So, if someone who is familiar with these help me out, it will > be nice. > > Thanks. > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/1197 > Interesting - and as an aside this is already being packaged. https://bugzilla.redhat.com/show_bug.cgi?id=471231 Dependent on these reviews some of which are in progress, some which need a reviewer. https://bugzilla.redhat.com/show_bug.cgi?id=505354 https://bugzilla.redhat.com/show_bug.cgi?id=505356 https://bugzilla.redhat.com/show_bug.cgi?id=505360 As you'll note in the review, there's a potential licensing issue (at least licensing is unclear with regards to some icons that are included) That said, I was thinking this might be a fit when I picked up the review, but haven't had time to play with it much. From ricky at fedoraproject.org Thu Jul 30 21:16:46 2009 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 30 Jul 2009 17:16:46 -0400 Subject: Meeting Log - 2009-07-30 Message-ID: <20090730211646.GE2515@alpha.rzhou.org> 19:59 < smooge> #startmeeting Fedora Infrastructure 19:59 < zodbot> Meeting started Thu Jul 30 19:59:49 2009 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:59 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:59 -!- zodbot changed the topic of #fedora-meeting to: (Meeting topic: Fedora Infrastructure) 20:00 < smooge> #topic Who is here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Who is here? (Meeting topic: Fedora Infrastructure) 20:00 * lmacken 20:00 * onekopaka 20:00 * ricky 20:00 < smooge> Fedora Infrastructure Meeting. I don't know how to 'Yell' in a channel my announcements will be a bit muted :) 20:00 < smooge> smooge is here 20:01 -!- fontana-afk is now known as fontana 20:01 * f13 20:01 -!- jpwdsm [n=jason at desm-47-239.dsl.netins.net] has joined #fedora-meeting 20:01 * SmootherFrOgZ is around 20:01 * mdomsch is here for a short time 20:01 * abadger1999 stands up to be counted 20:01 * jpwdsm is here 20:01 < smooge> okie dokie 20:01 < smooge> Thank you all for showing up. 20:01 < smooge> mmcgrath is in class this week. and I will try to run this quickly and clearly 20:02 < smooge> We will start with Tickets 20:02 * fontana is here 20:02 < smooge> #topic tickets (https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority) 20:02 -!- zodbot changed the topic of #fedora-meeting to: tickets (https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority) (Meeting topic: Fedora Infrastructure) 20:02 * J5 is here 20:02 < onekopaka> smooge: ick. make that into a tinyurl. 20:02 < onekopaka> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 20:02 < zodbot> onekopaka: http://tinyurl.com/2hyyz6 20:02 < onekopaka> #link https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 20:03 < smooge> thank you onekopaka 20:03 * onekopaka hopes the #link worked 20:03 < smooge> I forgot it was .tiny and not /tiny 20:03 < smooge> #link https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 20:03 < smooge> #topic tickets -- 1503 Licensing. 20:03 -!- zodbot changed the topic of #fedora-meeting to: tickets -- 1503 Licensing. (Meeting topic: Fedora Infrastructure) 20:04 < smooge> abadger1999, you and spot have updates 20:04 < abadger1999> So we got back a lot of good information from legal. 20:04 * abadger1999 thinks fontana might be here if we have furhter questions. 20:04 < fontana> abadger1999: yes :) 20:04 * lmacken waves at fontana 20:05 < ricky> Nice :-) 20:05 < smooge> ok at this point we are looking at how we can best comply with the AGPL 20:05 < lmacken> fontana: oh, I left you a gift from the SFLC on your door frame btw :) 20:05 < abadger1999> If we link to the srpms and the trac query for all hotfixes applied to fedora infrastructure apps, we should be covered. 20:05 * fontana waves back at lmacken 20:05 < smooge> and its going to be about methodology to make sure that the source code is available to users 20:05 < lmacken> fontana: from ian sullivan 20:05 -!- herlo [n=clints at fedora/herlo] has joined #fedora-meeting 20:05 < fontana> lmacken: got that, thanks (was wondering who put it there) 20:05 < abadger1999> I think that's reasonable for production. 20:05 < smooge> abadger1999, I thought the trac entries were NOT acceptable. 20:05 < abadger1999> config files are not copyrightable so that should be fine. 20:05 * abadger1999 looks at hte email again 20:06 -!- sijis [n=sijis at adsl-70-131-122-61.dsl.emhril.sbcglobal.net] has joined #fedora-meeting 20:06 * sijis is here. 20:06 < abadger1999> + links to base srpm and tickets in trac that have patches attached 20:06 < abadger1999> * Red Hat Legal says that this is OK. 20:06 < lmacken> sounds like we need a HotfixSOP 20:06 < abadger1999> So the mirrormanager example from last week that said what we changed but didn't provide a patch would not be okay. 20:06 < ricky> For reference, hereis what the link woud look like: 20:06 < ricky> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7Ehotfix&order=priority 20:07 < zodbot> ricky: http://tinyurl.com/numfgb 20:07 < abadger1999> But if we have a patch we are okay. 20:07 < smooge> lmacken, we will need a HotfixSOP and a testing/integration SOP 20:07 < abadger1999> So if everyone else agrees that that's fine, it just leaves the question of staging and publictest. 20:08 < onekopaka> yay more SOPs! 20:08 * herlo likes SOps 20:08 < smooge> abadger1999, thanks. I misread and thought it was the next one down. 20:08 < abadger1999> fontana: Did spot send you the followup questions? Whether we can avoid the AGPL requirment if we use Apache Basic Auth to limit who can access the staging and publictest instances? 20:09 < fontana> abadger1999: I don't think spot sent me that, but I saw it in the mailing list archives anyway 20:09 < smooge> basically we would like to limit who the "users" are that we intend to give the "code" to. 20:09 < fontana> abadger1999: you're limiting it to members of the FI team? 20:09 < spot> darn, i knew i was forgetting something. :/ 20:09 * smooge pulls out greasy noodle to whip spot 20:10 < onekopaka> spot: why hello. 20:10 < lmacken> I'd be fine with apache auth, or requiring vpn/ssh tunnels to get to publictest* 20:10 -!- thomasj_ is now known as thomasj 20:10 < smooge> fontana, it would be limited to Fedora Infrastructure and "Service Owners". 20:10 < lmacken> or staging.. even though it would be a little annoying 20:10 < abadger1999> fontana: Yes. My proposal was the same group that has access to the servers -- sysadmin-test for publictest instances, for instance. 20:10 < fontana> smooge: what's a Service Owner? 20:10 < smooge> "Service Owners" being the sub-group that is asking for the application 20:10 < fontana> ok 20:10 < abadger1999> fontana: But the more inclusive we can be and still satisfy the requirements the better. 20:11 < smooge> so if Fedora Marketing is wanting the AGPL blog, we would limit it to people with that group. 20:11 < abadger1999> fontana: As that lets more people within Fedora test edge cases. 20:11 < fontana> abadger1999: I think this is ok 20:12 < smooge> In this way, the people who are requesting a service are able to see/use that code, and they would know how to get the source code 20:12 < fontana> bkuhn from sflc is not here to tell me I am wrong 20:12 < abadger1999> fontana: Cool. Would all of sysadmin also be okay? 20:12 < abadger1999> :-) 20:12 < onekopaka> fontana: =) 20:12 < fontana> smooge: right 20:13 * abadger1999 sees smooge's proposal already had that. 20:13 < smooge> i proposed something? I forgot ... turning 40 is like the new 80. 20:13 < abadger1999> err.. limited to Fedora Infrastructure and "Service Owners". 20:13 < smooge> ah yes. 20:14 < onekopaka> smooge: nah, it's not. 20:14 < abadger1999> Slightly different than what I thought up on the lsit. 20:14 -!- lcafiero [n=larry at dsl-63-249-115-153.dhcp.cruzio.com] has quit "is heading out. Talk to you later" 20:14 < smooge> abadger1999, it comes from all my ITIL brainwashing 20:14 < smooge> ok do we have any other questions on particulars of the license? 20:15 < smooge> if not we can move onto either the next topic or spend 5 minutes on what SOP's would be needed, who is writing them, and when we can have some drafts? 20:15 < ricky> One note is that FAS auth in stating/testing will be a pain 20:15 < abadger1999> ricky: In what way? 20:16 * smooge repeats abadger1999 20:16 < ricky> We don't like to mix testing, prod, and staging, so using mod_auth_postgres to handle restricting access to staging/testing instances is not allowed 20:16 < ricky> It'd suck to make exceptions for this (especially with testing) 20:16 < abadger1999> smooge: How about 5 minutes of implementation talk and then I'll write up the changes we'll need to make for next meeting. 20:17 < ricky> So that's how it'll be a pain. 20:17 < smooge> abadger1999, noted 20:17 < abadger1999> ricky: Ah... fasClient currently hits the production fas anyway, right? 20:17 < ricky> In testing, yes, in staging, no 20:17 < ricky> But staging has hosts entries to point to the staging db 20:17 < ricky> And publictest servers have no access to the db by design 20:19 * ianweller rolls in 20:19 < ricky> PAM auth is an option, but I just wanted to make it clear that mod_auth_postgres is probably not 20:19 < onekopaka> ianweller: did you lose your jetpack? 20:20 < ricky> At least not for publictest machines - if you ignore the outdated auth info, it's usable in staging 20:20 < abadger1999> 20:20 < ricky> which we already do ignore that problem for the most part :-( 20:20 < abadger1999> ricky: Could we stick the publictest servers behind a proxy? 20:21 < abadger1999> Then the proxy does the bsaic Auth and tlaking to mod_auth_postgres. 20:21 < ricky> We could. It'd be highly annoying, but doable 20:21 < abadger1999> k 20:22 < ricky> In a sense, it'd be something that needs to be done when something gets deployed to production anyway 20:22 < abadger1999> So that's a sticky point. 20:22 < ricky> But it'd cause AGPL compliance to burden people testing non-AGPL apps, which I really want to avoid 20:22 < abadger1999> Any other problems people can identify? 20:22 < smooge> oh one second. Thank you fontana, and spot is there anything you wanted to add? 20:23 < spot> nope. :) 20:23 -!- Pikachu_2014 [n=Pikachu_ at 85-169-125-118.rev.numericable.fr] has quit Read error: 60 (Operation timed out) 20:24 < abadger1999> ricky: also note, we'll have to figure out something whether we switch infrastructure over to AGPL or not. 20:24 < smooge> ricky, abadger1999 it looks like we will need to work out a testing/staging SOP/network design 20:24 < abadger1999> Since we have one AGPL app that people need to test and collaborate on. 20:24 < ricky> abadger1999: Well, doing painful configuration one time for fcomm/moksha is fine with me, as long as it won't affect other stuff 20:24 -!- mchua is now known as mchua_tooling 20:25 < smooge> ricky I think we should not lookinat at as one-time .. long term there will be other apps etc that will need it even if they aren't AGPL. 20:26 < smooge> ok I am at 10 minutes for technical discussion. 20:26 < smooge> sorry 20:26 < abadger1999> Cool. move on to the next one. 20:26 < smooge> next topic 20:26 -!- Sonar_Guy [n=Who at fedora/sonarguy] has quit "Leaving" 20:26 < smooge> #topic tickets #1573 20:26 -!- zodbot changed the topic of #fedora-meeting to: tickets #1573 (Meeting topic: Fedora Infrastructure) 20:26 < smooge> back to you abadger1999 20:27 < onekopaka> .ticket 1573 20:27 < zodbot> onekopaka: #1573 (Remove "All rights reserved" from fedoraproject footers and code) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1573 20:27 < abadger1999> This one's somewhat of a FYI. 20:27 < abadger1999> We have "All rights reserved" i nthe footer of pretty much every Fedora page. 20:27 -!- Pikachu_2014 [n=Pikachu_ at 85-169-125-118.rev.numericable.fr] has joined #fedora-meeting 20:27 < smooge> And there is a problem with that? Oh wait.. I don't work for a University any more. 20:28 < onekopaka> are our right becoming first-come-first-serve? 20:28 < onekopaka> rights* 20:28 < abadger1999> That's misleading since we're actually licensing everything in one way or another (the trademark license for the logo is the most restrictive one we have) 20:28 < onekopaka> ;) 20:28 < fontana> abadger1999: "All rights reserved" is evil and should be eliminated 20:28 < abadger1999> So we should remove it. 20:28 * hiemanshu is here now 20:28 < smooge> what is the proper rights we should have? CC All rights reserved ? 20:29 < abadger1999> spot, fontana: Couple questions: Do we need to talk to other groups when we make changes 20:29 < abadger1999> (like docs) 20:29 < ianweller> all the fedora docs are currently OPL, and will be moving to CC BY-SA 20:29 < smooge> abadger1999, as you said this is FYI. Who will be working on it? 20:29 -!- mdomsch [n=mdomsch at 24.174.1.212] has quit "Leaving" 20:29 < abadger1999> 2) Should we list the actual license in use? (GPLv2/AGPLv3+ for web apps, OPL to be replaced by CC-BY-SA for docs and wiki) ? 20:30 < ricky> How urgently should we treat this? 20:30 < ricky> Like is it worth live-patching FAS for? 20:30 < spot> abadger1999: you probably should let them know you're doing it, but you don't have to get their approval 20:30 < abadger1999> smooge: Depends on the answer to #1. I'm hoping I can submit patches for all the web apps after thismeeting. 20:30 < abadger1999> AndI'm hoping ricky hasaccess to all the others :-) 20:30 < smooge> ricky no I don't believe its that urgent. regular relaease cycle 20:31 < spot> abadger1999: and you don't have to list the license in use, but it would not be incorrect to do so 20:31 < ricky> FAS is unlikely to have a release in quite some time 20:31 < onekopaka> ricky: yeah, it doesn't need changing. 20:31 < smooge> ricky, ok.. regular rollout of code versus hot-patch 20:31 < smooge> :) 20:32 -!- GeroldKa [n=GeroldKa at fedora/geroldka] has joined #fedora-meeting 20:32 < hiemanshu> Regular rollout i suggest 20:32 < smooge> to me hot-patch means your typing in another window during this meeting... regular rollout is it goes through testing 20:32 -!- cassmodiah [n=cass at fedora/cassmodiah] has quit Remote closed the connection 20:32 < abadger1999> Excellent -- so the FYI portion is "don't use "All rights reserved" in the future and if you see more of that footer in the future, let me know so I can make sure it gets fixed. 20:33 < ianweller> should we just report those to that ticket? 20:33 < ricky> All I'm saying is that regular rollout could potentially be months away for all I know vs. a trivial string change. 20:33 < abadger1999> ianweller: Yep. that would be best. 20:33 < ricky> Anyway, if it's not urgent, I'll leave it alone 20:34 < abadger1999> I think as long as we get it into version control soon it's fine. Deployment can wait. 20:34 -!- RadicalRo [n=radical at 193.254.32.144] has quit "Leaving." 20:34 < smooge> ricky, months away sounds passable. 20:34 < smooge> ok anything else? 20:34 < abadger1999> Cool. So that's all I have for that one. 20:35 < smooge> #topic Other tickets 20:35 -!- zodbot changed the topic of #fedora-meeting to: Other tickets (Meeting topic: Fedora Infrastructure) 20:35 < ricky> Er, one more thing 20:35 < smooge> waits... 20:35 < ricky> While the legal people are around - should that copyright line not be translated? 20:35 < ricky> (As in should it remain in English on all translated versions of the page) 20:36 < ricky> Right now, it's marked as text that can be translated 20:36 < smooge> spot, fontana question for you. 20:37 < ricky> The text I'm talking about is "Copyright (c) 2009 Red Hat, Inc. and others. All Rights Reserved. For comments or queries, please contact us" 20:37 -!- shepherd [n=shepherd at unaffiliated/shepherd] has joined #fedora-meeting 20:37 * ricky imagines the contact stuff can remain translated 20:37 < fontana> ricky: You mean translate "Copyright ? 2009 Red Hat, Inc. and others. All Rights Reserved. For comments or queries, please contact us. "? 20:37 < ricky> Yup 20:37 < spot> well, without the "All Rights Reserved."... 20:38 < ricky> So that line with "All Rights Reserved" is fine to be translated, then? 20:38 * spot defers to fontana 20:38 < fontana> ricky: I wouldn't translate the 'Copyright' part. 20:38 < onekopaka> ricky: as long as it doesn't have "All Rights Reserved" ;) 20:38 < ricky> OK, I'll leave that out, thanks for clarifying 20:38 < fontana> ricky: I guess you could translate the contact part, if you want. 20:38 < ricky> So from "For comments or queries..." will be the only part translatable 20:39 < hiemanshu> AFAIK Copyright part is never translated any where 20:39 -!- shepherd [n=shepherd at unaffiliated/shepherd] has quit Client Quit 20:39 < fontana> ricky: You could make the copyright part non-language-specific by just using the copyright symbol without "Copyright", I suppose 20:39 < onekopaka> © 20:39 < fontana> right 20:39 < ricky> hiemanshu: It is at http://fedoraproject.org/zh_TW/ for example 20:40 < hiemanshu> ricky: it should not be translated 20:40 < onekopaka> © 20:40 < ricky> OK, so (c) 2009 Red Hat, Inc. and others can be translated, or does it stay in English? 20:40 < hiemanshu> ricky: it depends on which country the company or project is located, USA in our case so it should be English 20:41 * ricky would be happy to ask all of this after the meeting if you'll still be around. 20:41 < hiemanshu> ricky: it should stay in English 20:41 < fontana> ricky: legally the "and others" probably doesn't mean anything so I don't think it matters 20:42 < smooge> ricky, lets put this into email. I believe that they are saying the For comments ... should be translated but licensing should not 20:42 < ricky> Cool, thanks 20:42 < sijis> we could take this offline and post the 'results' to the list. 20:42 < smooge> okie dokie 20:42 < ricky> It'll show up in list via the meeting logs, so I'm happy as is 20:42 < smooge> Any other tickets we are looking at? 20:42 < smooge> ricky and dgilmore updated BIND on the servers last night. 20:43 < onekopaka> yep 20:43 < smooge> I am working on getting a trip to Az to upgrade backup hardware. 20:43 < onekopaka> I heard of that story. 20:44 < onekopaka> not the trip story 20:44 < onekopaka> the BIND updatign 20:44 < onekopaka> updating* 20:44 < smooge> there was a story involved? Beyond where the f* is smoogen and why isn't he doing it? 20:44 < onekopaka> smooge: of course. 20:45 < smooge> Alright I think that means we are on open floor 20:45 < smooge> #topic openfloor 20:45 -!- zodbot changed the topic of #fedora-meeting to: openfloor (Meeting topic: Fedora Infrastructure) 20:45 < dgilmore> sorry im late 20:45 < onekopaka> blogs.fedoraproject.org 20:45 < ricky> f13: How is the signing server going? 20:46 < f13> jwb is using it right now 20:46 < f13> so far so good 20:46 < ricky> Cool :-) 20:46 < f13> We've discovered a number of issues with the first setup, that we'll need to resolve and do a clean re-deployment 20:46 -!- opuk [n=kupo at pipe.intertubez.net] has left #fedora-meeting [] 20:46 < f13> and then write up some good SOPs in case I get eaten by a raptor 20:46 < smooge> ok cool. let me know when you need that 20:46 < f13> and then we'll be able to go "live" with it 20:46 < smooge> I need to rebuild the RAID 20:47 < tmz> I've been (slowly) working on learning the hosted setup enough to expand the SOPs and create an improved hosted-setup script to do the dirty work for us. 20:47 < tmz> today I'm wondering if we have any working examples of svn commit notifications. 20:48 < ricky> tmz: I think aplaws might be a project with an example of that - not sure if it got broken with noexec or not though 20:48 < smooge> tmz, what does that mean? rebuild of fedora hosted 20:48 < ricky> THanks for working on that by the way 20:49 < tmz> ricky: yeah, I know aplaws is one of them, but it uses a post-commit in /srv/svn, so I'm thinking it's likely to be broken. but I don't honestly know yet. 20:49 < ricky> Ah, I think I tried to debug that at some point with no luck - maybe noexec was the culprit 20:49 < tmz> smooge: nah, no rebuilds needed. just a smarter and more comprehensive hosted-setup script for creating new projects. 20:49 < smooge> ah ok 20:49 < smooge> thanks 20:50 < ricky> Update on mirrors: 20:50 < ricky> The i2 mirror is up, but we're getting slower speeds on than we'd expect from i2 20:50 < ricky> So we opened a ticket with the networking people today 20:50 < ricky> Otherwise, things seem to have cooled down significantly since last meeting 20:51 < smooge> thanks ricky 20:53 < onekopaka> blogs.fedoraproject.org? 20:53 < smooge> ok what about blogs :)? 20:53 < onekopaka> so. 20:53 < onekopaka> It's on production servers 20:53 < onekopaka> but we're trying to work on SSL login. 20:54 < ricky> One thing I'd like you guys to do is make it clear on the front page that it's not 100% in production yet - otherwise there might be some confusion 20:54 < onekopaka> thing is, HAProxy isn't going over SSL 20:54 < onekopaka> ricky: will do 20:54 < ricky> Then you can make an announcement post and everything when it's 100% ready 20:54 < onekopaka> and so value1 & value2 aren't seeing that the request is SSL 20:54 < onekopaka> and that's confusing WPMU. 20:55 < smooge> oh so there needs to be an SSL proxy? 20:55 -!- JSchmitt [n=s4504kr at fedora/JSchmitt] has quit Read error: 104 (Connection reset by peer) 20:55 < sijis> i would think so. 20:55 < onekopaka> smooge: yes, but I haven't figured out how to do such a thing, and ricky doesn't want us to use SSL on value1 & value2. 20:56 < ricky> It's the app servers that wordpress-mu needs to think is SSL, but we'd rather avoid that, even if it takes patches sent upstream to fix it 20:56 < ricky> One resource to try is asking people who run wordpress.com how they do it 20:56 < ricky> Assuming that they have separate proxy/app servers 20:56 < smooge> probably hardware :) 20:56 < onekopaka> ricky: their infrastructure is largely based on nginx 20:57 < onekopaka> ricky: which is kinda like haproxy, but it can also serve static HTML, and run FCGI apps. 20:57 < ricky> OK, so on the backend, is it http or https? 20:57 < onekopaka> ricky: not sure. 20:58 < smooge> ok 2 minutes til hardstop 20:58 < ricky> It might be good to find out and see if they can maybe help with the setup. 20:58 < onekopaka> ricky: the front end you can request with SSL, and in your Profile, choose to use SSL on your dashboard 20:59 < onekopaka> yeah, not sure who does the infrastructure at Automattic. 20:59 < onekopaka> (Automattic is the company that oversees wp.com, and WP/WPMU development, FYI) 20:59 < onekopaka> oh I see. 20:59 < onekopaka> http://automattic.com/about/ 21:00 -!- rdieter [n=rdieter at fedora/rdieter] has quit Remote closed the connection 21:00 < smooge> ok lets wrap this up 21:00 < onekopaka> Barry Abrahamson would most likely be the guy to talk to. 21:00 < onekopaka> smooge: I'm not done. 21:00 < smooge> are we going to run over into someone elses meeting? 21:01 < abadger1999> smooge: I don't believe so. 21:01 < onekopaka> I don't think so. 21:01 < smooge> ok sorry I misread 21:01 < smooge> continue on please and apologies for interrupting 21:01 < onekopaka> I'll see if I can get in touch with Barry. 21:02 < onekopaka> #action onekopaka to attempt to contact Barry Abrahamson, Systems Wrangler at Automattic. 21:02 -!- fbijlsma [n=fbijlsma at p54B2DEEA.dip.t-dialin.net] has quit "Leaving" 21:02 -!- gholms [n=gholms at minnock.spa.umn.edu] has quit "Leaving." 21:03 < onekopaka> He might also be able to help us with them MySQL queries ;) 21:03 -!- mep [n=palazzot at host126-9-dynamic.0-79-r.retail.telecomitalia.it] has quit "Leaving." 21:03 < onekopaka> wp.com is a big site, and they most likely have a way to back it up. 21:03 < onekopaka> so I think we're done.. 21:04 < smooge> #action onekopaka to attempt to contact Barry Abrahamson, Systems Wrangler at Automattic. 21:04 < onekopaka> they also apparently have a big "deploy" button to deploy the latest WPMU code to wp.com 21:04 * onekopaka needs to go get lunch 21:05 < smooge> ok sorry for taking a while to get to you 21:05 < onekopaka> smooge: it's okay. 21:05 < onekopaka> woah, new admin bar on wp.com. it has my gravatar even.. 21:06 < smooge> do we have a time line? 21:06 < onekopaka> smooge: for blogs.fp.o? 21:07 * onekopaka is hitting up the contact page on Barry's WP.com blog 21:07 < smooge> yes? just as in where you think you might be in a couple of weeks 21:07 < onekopaka> well 21:07 < onekopaka> another note is that we would like to upgrade our WPMU 21:08 < onekopaka> so that we can enable plugins sitewide (specificially "Bad Behavior" the anti-spam plugin we chose) 21:09 < smooge> ok this is in the 'testing' stage correct? 21:09 < smooge> so it would not impact users? 21:09 < onekopaka> it's on prod. servers, but not quite there. 21:09 < onekopaka> and the packages aren't in any repo 21:09 * onekopaka digs up his el5 package he made via Koji 21:09 < onekopaka> http://oks.verymad.net/~onekopaka/wordpress-mu-2.8.2-1.fc11.src.rpm 21:10 < onekopaka> hmm 21:10 < onekopaka> that's the f11 one. 21:10 < onekopaka> http://oks.verymad.net/~onekopaka/yumrepo/wordpress-mu-2.8.2-1.el5.noarch.rpm is the final one 21:11 < onekopaka> I should rebuild them, I didn't put a changelog 21:11 < smooge> ok so we need to have that built/signed/etc for the infrastructure correct? 21:11 < ricky> Only if we actually do decide that it's worth upgrading to something not in EPEL/Fedora 21:11 < onekopaka> ideally, we'd want them in epel & fedora 21:11 < onekopaka> but. 21:11 < onekopaka> but. 21:11 < onekopaka> BUT! 21:12 < onekopaka> bretm, the owner of the package says after wordpress-mu 2.7, there's a "missing feature" 21:12 -!- sharkcz [n=dan at plz1-v-4-17.static.adsl.vol.cz] has quit "Ukon?uji" 21:13 < onekopaka> but I have yet to hear what feature that is 21:13 < onekopaka> which is annoying. 21:13 -!- Pikachu_2015 [n=Pikachu_ at 85-169-125-118.rev.numericable.fr] has joined #fedora-meeting 21:13 < smooge> ah ok. we need to get that pinned down I think. 21:13 < onekopaka> yep 21:14 < onekopaka> hiemanshu was going to bug bretm about it, but I haven't any thing from him 21:14 -!- Pikachu_2014 [n=Pikachu_ at 85-169-125-118.rev.numericable.fr] has quit Nick collision from services. 21:14 -!- Pikachu_2015 is now known as Pikachu_2014 21:14 -!- jnettlet [n=jnettlet at x1-6-00-16-b6-ad-03-88.k462.webspeed.dk] has quit Read error: 60 (Operation timed out) 21:14 -!- shepherd [n=shepherd at unaffiliated/shepherd] has joined #fedora-meeting 21:14 < onekopaka> so I'm pretty much done here... 21:14 < onekopaka> and so I think we can #endmeeting. 21:15 < onekopaka> unless anyone else has something to say. 21:15 < onekopaka> I'm going to count from 5 21:15 < onekopaka> 5 21:15 < onekopaka> 4 21:15 < onekopaka> 3 21:15 < onekopaka> 2 21:15 < onekopaka> 1 21:15 < onekopaka> 0 21:15 < smooge> ok 21:15 < onekopaka> mmkay, time's up. 21:15 < smooge> #endmeeting 21:15 -!- zodbot 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/Meeting_channel for meeting schedule 21:15 < zodbot> Meeting ended Thu Jul 30 21:15:59 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 21:15 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-30/fedora-meeting.2009-07-30-19.59.html 21:16 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-30/fedora-meeting.2009-07-30-19.59.txt 21:16 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-30/fedora-meeting.2009-07-30-19.59.log.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: