infrastructure July 2009

infrastructure@lists.fedoraproject.org

42 participants
66 discussions

Systems updated
by Stephen John Smoogen 03 Jul '09

03 Jul '09

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.

1 0

Meeting Log - 2009-07-02
by Ricky Zhou 02 Jul '09

02 Jul '09

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(a)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=assi… 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> <nod> 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(a)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(a)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@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> <nod> 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@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(a)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(a)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(a)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(a)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@fedora/openpercept] has joined #fedora-meeting 20:36 -!- tatica is now known as tatica-out 20:36 -!- sharkcz [n=dan(a)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@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(a)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(a)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_(a)85-169-128-251.rev.numericable.fr] has quit Read error: 60 (Operation timed out) 20:43 -!- Pikachu_2014 [n=Pikachu_(a)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-… 20:49 < fedbot> Log: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-…

1 0

Licensing Guidelines for apps we write
by Toshio Kuratomi 02 Jul '09

02 Jul '09

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

5 6

May I have a sample output of this script?
by susmit shannigrahi 02 Jul '09

02 Jul '09

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/genera… Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit =============================================

1 0

Need some looking at iptables change.
by Stephen John Smoogen 02 Jul '09

02 Jul '09

--- 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"

2 2

introduction
by ufo008ahw 01 Jul '09

01 Jul '09

hello,everyone. I'm a graduate. I am 23 years old.I will work in beijing china. I am instresting in the linux system and i like code.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure July 2009