infrastructure September 2009

infrastructure@lists.fedoraproject.org

43 participants
43 discussions

MirrorManager is now IPv6 enabled
by Matt Domsch 10 Sep '09

10 Sep '09

MirrorManager 1.3.0 is live now. You can enter host names (A or AAAA records only please; it won't chase down CNAMEs) into your Host's netblock list, and MirrorManager will honor it. This means, if you have dynamic DNS keeping your A records up-to-date, MM will point your users at your mirror. As MM only does DNS lookups every hour, there may be a small window where your IP changes, DNS changes, but MM hasn't caught up yet. Also, MirrorManager is now IPv6 enabled. mirrors.fedoraproject.org and download.fedoraproject.org are both reachable by IPv6, and it does IPv6 (and 6to4) GeoIP lookups too. The IPv6 GeoIP table is pretty limited, but with the addition of 6to4 lookups, I think will be quite usable. You can add your IPv6 netblocks too. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux

1 0

Torrent changes
by Jesse Keating 10 Sep '09

10 Sep '09

I've done a couple things with the torrents this week and I want you all to be aware of it, in case something happens. 1) I've removed anything that is older than F-10. All F8/9 content has been removed from the web listing, and if nobody complains in a week or so I'll remove the torrent files themselves. 2) I've re-generated all the live torrents, all the Fedora 12 Alpha torrents, and the Snapshot 1 torrents. These have been re-generated with a README-SOURCES file that tells users where they can go to get the matching sources. This has reset the download counters for all of the torrents that got re-generated, but was necessary for GPL compliance. Please ping me if anybody discovers an issue with the torrents. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

4 3

Meeting Log - 2009-09-10
by Ricky Zhou 10 Sep '09

10 Sep '09

19:59 < mmcgrath> #startmeeting 19:59 < zodbot> Meeting started Thu Sep 10 19:59:28 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:59 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:59 -!- notting [n=notting@redhat/notting] has joined #fedora-meeting 19:59 < mmcgrath> #topic Infrastructure -- Meeting start! Who's here? 19:59 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Meeting start! Who's here? 19:59 * mmcgrath is 19:59 -!- Pikachu_2014 [n=Pikachu_(a)85-171-16-27.rev.numericable.fr] has joined #fedora-meeting 19:59 * nirik is hanging around 19:59 * skvidal is here 19:59 -!- jpwdsm [n=jason(a)desm-46-077.dsl.netins.net] has joined #fedora-meeting 20:00 -!- heffer [n=felix@fedora/heffer] has joined #fedora-meeting 20:00 * smooge raises his hand and says "Not Here" 20:00 * heffer is just lurking 20:00 * jpwdsm hangs out in the back 20:00 < mmcgrath> smooge: I think that logic just took some iq points from me. 20:00 * Oxf13 20:00 -!- akistler [n=akistler(a)adsl-99-142-18-184.dsl.emhril.sbcglobal.net] has joined #fedora-meeting 20:01 < mmcgrath> Ok, lets get started 20:01 < mmcgrath> #topic Infrastructure -- Tickets 20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 * mdomsch here 20:01 < mmcgrath> Oh, and there's no meeting tickets. 20:01 < mmcgrath> that's easy 20:01 < mmcgrath> #topic Infrastructure -- IPv6 20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- IPv6 20:01 < mmcgrath> mdomsch: want to take it quick on this one? Mostly just about what problem we saw and what we did about it. 20:02 < mdomsch> 2 classes of problem 20:02 < mdomsch> 1 we can fix 20:02 < mdomsch> so we did. we lowered the MTU for IPv6 packets, from 1500 to 1280 20:02 < mmcgrath> We do have one confirmed report that that seems to have fixed his/her problem 20:02 < mdomsch> apparently some packets were considered "too large" for some routers between our customers and us 20:02 < mdomsch> s/customers/users/ 20:03 < mdomsch> hopefully that'll help 20:03 < mdomsch> problem 2: other routers dropping packets for unknown reasons 20:03 < mdomsch> 0xf13 may have been bit by this 20:03 < mdomsch> last I knew, this was progressing between Sprint and Indiana gigapop NOCs, or at least bouncing between them 20:03 < mmcgrath> well, in Oxf13's case his router was sending IPv6 info even though his router wasn't configured to use it. 20:04 < smooge> I have seen this for 'security reasons'. Various IPS sometimes think IPV6 is a security problem and will drop/degrade service 20:04 < mdomsch> if someone pops into #fedora-admin with questions, please try to help 20:04 -!- drago01 [n=linux(a)chello062178124135.3.13.univie.teleweb.at] has quit Read error: 110 (Connection timed out) 20:04 < mdomsch> moving on from problems 20:04 < mmcgrath> <nod> 20:04 < mdomsch> I'd like to get opentorrent built for el5 20:05 < mmcgrath> mdomsch: is it in Fedora already? 20:05 < mdomsch> it depends on libowfat which I branched for EL-5 but haven't finished the work of de-dietlibc-ing it 20:05 < mmcgrath> ah 20:05 < mdomsch> mmcgrath, and no, opentorrent is not in Fedora yet 20:05 < mmcgrath> k 20:05 < mmcgrath> that'll be another nice ipv6 service though 20:05 < mdomsch> that's the only other service we offer at ibiblio that we could serve on v6 20:06 < mmcgrath> <nod> 20:06 < mmcgrath> mdomsch: emails are still bouncing around about our glue 20:06 < mdomsch> everything else (cvs, git, ...) are in non-v6-capable data centers 20:06 < mmcgrath> but it'll happen eventually 20:06 < mdomsch> oh, and MM is ready to go 20:06 < mmcgrath> sweet 20:06 < mmcgrath> did we re-enable mirrors.fp.o for ipv6? 20:06 < smooge> mdomsch, I wonder if we could do a app6to4 proxy 20:06 < Oxf13> fwiw, I replaced my router's firmware with dd-wrt, so I shouldn't have this issue anymore 20:06 < mdomsch> mmcgrath, no we haven't yet 20:06 -!- djf_jeff [n=jeff(a)modemcable026.33-70-69.static.videotron.ca] has quit "I quit" 20:07 < mdomsch> I need dgilmore to push the package to epel-testing :-) 20:07 -!- tibbs_ [n=tibbs@fedora/tibbs] has quit "Konversation terminated!" 20:07 -!- drago01 [n=linux(a)chello062178124135.3.13.univie.teleweb.at] has joined #fedora-meeting 20:07 < mmcgrath> ah, of course :) 20:07 < mdomsch> smooge, we could, but it might be slow... 20:07 < mmcgrath> <nod> I worry about the performance people would see if we start running our own proxies. 20:07 < mmcgrath> but if people care enough about it we can look closer and see exactly what we're talking about 20:07 < mmcgrath> anywho 20:08 < mmcgrath> mdomsch: anything else on ipv6? 20:08 < mdomsch> that's all 20:08 < mmcgrath> sweet. 20:09 < mmcgrath> #topic Change Freeze 20:09 -!- zodbot changed the topic of #fedora-meeting to: Change Freeze 20:09 < dgilmore> mdomsch: ill do it now 20:09 < mmcgrath> The change freeze will start for the beta on the 29th 20:09 < mmcgrath> Oxf13: what are our odds of a slip? 20:10 < notting> ask after the blocker meeting tomorrow? 20:10 < skvidal> mmcgrath: statistically? :) 20:10 < Oxf13> mmcgrath: hard to say right now. 20:10 < mdomsch> skvidal, the last 2 full release cycles are outliers, and can be discareded 20:10 < mmcgrath> notting: will do 20:10 < skvidal> mdomsch: really? :) 20:11 * mmcgrath is just reminding everyone that a slip would be really really really bad 20:11 -!- mchua_ [n=mchua(a)pool-71-191-192-177.washdc.fios.verizon.net] has quit Read error: 110 (Connection timed out) 20:11 < mmcgrath> at least for Infrastructure 20:11 < mmcgrath> OK, moving on 20:11 < notting> mmcgrath: my 'finger in the air' estimate is that non-anaconda bits are in ok shape 20:11 < smooge> a slip means no Canada for smooge 20:11 < mmcgrath> #topic Infrastructure -- qpidd 20:11 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- qpidd 20:12 < mmcgrath> J5: pnig 20:12 < mmcgrath> err ping even 20:12 < mmcgrath> .any lmacken 20:12 < skvidal> 2009-11-10 <-- and if we slip much we hit US thanksgiving 20:12 < zodbot> mmcgrath: lmacken was last seen in #fedora-meeting 16 hours, 12 minutes, and 7 seconds ago: *** lmacken has quit IRC (Read error: 110 (Connection timed out)) 20:12 < J5> mmcgrath: pong 20:12 < mmcgrath> J5: any progress on the messaging stuff? 20:12 -!- lmacken [n=lmacken@fedora/lmacken] has joined #fedora-meeting 20:12 < mmcgrath> lmacken: hey, just checking to see if there's any progress from you guys on the messaging stuff 20:13 < J5> mmcgrath: I ran into decoding structs issues which I am working on but I have python sending messaqes to js. I just need ot get them decoded 20:13 < lmacken> hey, so yeah, I haven't deployed any Moksha/Fedora Community stuff to staging yet 20:13 < mmcgrath> <nod> 20:13 < mmcgrath> if there's nothing else we'll move on to the next topic 20:14 -!- Fedora-Angel [n=Angel(a)120.50.18.170] has quit "Leaving" 20:15 < mmcgrath> Ok 20:16 < mmcgrath> #topic Infrastructure -- Fedora insight 20:16 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Fedora insight 20:16 < mmcgrath> boo, just missed mchua 20:16 < mmcgrath> abadger1999: do you know anything about this? 20:16 < mmcgrath> last I checked fas auth was still not working 20:16 < mmcgrath> mizmo: you know anything? 20:16 < abadger1999> mmcgrath: Nope, haven't been followed the day-to-day, just the getting new features ready for the platform. 20:17 < mmcgrath> k, I'll follow up with mchua on that then. 20:17 < mmcgrath> zikula and qpid are the two major pushes I'm trying to get out. 20:17 < mmcgrath> #topic Infrastructure -- Smolt 20:17 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Smolt 20:17 -!- Fedora-Angel [n=Angel(a)120.50.18.170] has joined #fedora-meeting 20:17 < mmcgrath> So I've spent much of my week working on smolt. 20:17 < mmcgrath> specifically database queries. 20:17 < mizmo> mmcgrath: a little bit 20:17 < mmcgrath> I've got the render-stats script in much better shape 20:18 < mmcgrath> mizmo: do you know what the status of the fas auth stuff on pt6 is? 20:18 -!- fbijlsma [n=fbijlsma(a)p54B2DDB2.dip.t-dialin.net] has joined #fedora-meeting 20:18 < mizmo> mmcgrath: i dont :( im just working on the css 20:18 < mmcgrath> K, no worries. 20:18 < mmcgrath> mizmo: thanks. 20:19 < mmcgrath> So on the smolt stuff, I've got a couple more changes to make and one final query (that happens to get run multiple times) to get figured out. 20:19 < mmcgrath> I'm hopeful that most of our smolt issues will go away after this 20:19 < lmacken> I hit some smolt wikifail the other day when trying to add a new page for some hardware 20:19 < smooge> just in time for a new code release 20:19 < mmcgrath> lmacken: how 'the other day' was it? 20:19 < lmacken> it ate my changes, so I got frustrated and gave up :) 20:19 < lmacken> mmcgrath: last night I think 20:20 < mmcgrath> couple of weeks back? 20:20 < mmcgrath> oh just last night 20:20 < mmcgrath> lmacken: I'll take a look. 20:20 < mmcgrath> K, anyone have any questions / concerns on that? 20:20 -!- inode0 [n=inode0@fedora/inode0] has joined #fedora-meeting 20:21 < mmcgrath> k 20:21 < mmcgrath> #topic Infrastructure -- 1667' 20:21 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- 1667' 20:21 < mmcgrath> abadger1999: was this you? 20:21 < mmcgrath> https://fedorahosted.org/fedora-infrastructure/ticket/1667 20:21 < mmcgrath> .ticket 1667 20:21 < zodbot> mmcgrath: #1667 (BZ Component and Product Change Request) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1667 20:21 < mmcgrath> sorry :) 20:21 < mmcgrath> abadger1999: didn't we talk to that guy already? 20:21 < abadger1999> mmcgrath: I'm on it as much as anyone is. 20:22 < abadger1999> mmcgrath: It needs to go through fedora-docs before it gets handled by us. 20:22 < mmcgrath> I'm just wanting to verify that is something we need to do, that's not something the bugzilla admins do? 20:22 < mmcgrath> quaid: ping 20:22 < mmcgrath> stickster: ping 20:22 < abadger1999> mmcgrath: That part.... I think we may need both Fedora nad bz admin help. 20:22 < abadger1999> But I don't even know if we're actually going to be renaming yet. 20:22 < abadger1999> So I'm waiting on more docs input. 20:23 < mmcgrath> he seems very insistant on it at this point, even sent an email to admin(a)fp.o 20:23 < abadger1999> huh. Since yesterday? 20:23 < mmcgrath> yeah, just a few minutes ago 20:23 * abadger1999 reads mail 20:23 < mmcgrath> abadger1999: we did communicate that to him yesterday right? 20:23 < stickster> mmcgrath: pong 20:23 < mmcgrath> stickster: who's in charge of docs these days/ 20:24 < stickster> mmcgrath: Eric Christensen (Sparks) 20:24 < stickster> .fasinfo sparks 20:24 < mmcgrath> Sparks: ping 20:24 < zodbot> stickster: User: sparks, Name: Eric Christensen, email: eric(a)christensenplace.us, Creation: 2007-07-17, IRC Nick: sparks, Timezone: US/Eastern, Locale: en, Extension: 5102043, GPG key ID: BD0C14C1, Status: active 20:24 < zodbot> stickster: Approved Groups: cla_done fedorabugs cvsfedora packager docs ambassadors cla_fedora sysadmin-test svnsecurityguide gitabout-fedora githomepage gitreadme gitreadme-live-image gitreadme-burning-isos gitfedora-wiki cmsadmin gitfedora-cms gitrpmguide svnaccessibility-guide gitamateur-radio-guide 20:24 < zodbot> stickster: Unapproved Groups: None 20:24 * stickster always forgets how... thorough zodbot is. 20:24 < mmcgrath> ohh, a couple more and he'll be in the .more club with me :) 20:24 < stickster> heh 20:25 < mmcgrath> ok, I'll email Eric and see if he's ok with this 20:25 < abadger1999> Hmmm...... 20:25 < mmcgrath> stickster: we're talking about - https://fedorahosted.org/fedora-infrastructure/ticket/1667 20:25 < abadger1999> Is dhensley == perspectival? 20:25 < mmcgrath> which seems to have come from nowhere but impacts the docs team? 20:25 < mmcgrath> .fasinfo dhensley 20:25 < zodbot> mmcgrath: User "dhensley" doesn't exist 20:25 < mmcgrath> .fas dhensley 20:25 < zodbot> mmcgrath: dsilas '' <dhensley(a)redhat.com> 20:25 < mmcgrath> .fasinfo dsillas 20:25 < zodbot> mmcgrath: User "dsillas" doesn't exist 20:25 < mmcgrath> .fasinfo dsilas 20:25 < zodbot> mmcgrath: User: dsilas, Name: None, email: dhensley(a)redhat.com, Creation: 2009-05-15, IRC Nick: silas, Timezone: None, Locale: None, Extension: 5130286, GPG key ID: None, Status: active 20:25 < zodbot> mmcgrath: Approved Groups: cla_done cla_fedora svndeployment-guide svnsecurityguide 20:25 < zodbot> mmcgrath: Unapproved Groups: None 20:25 < mmcgrath> boo, privacy flag. 20:26 < abadger1999> yep. 20:26 < stickster> mmcgrath: I'm not sure I understand what's going on there -- 20:26 < stickster> mmcgrath: but 20:26 < abadger1999> Well, I'll email dhensley and ask if he's perspectival. 20:26 * mmcgrath pings in #fedora-docs 20:26 < abadger1999> And if not catch him up on the need to go through docs and then explain what's going on. 20:26 < mmcgrath> abadger1999: ok, thanks. 20:26 < stickster> It could be the way that Publican produces docs creates a certain package name, and they're looking for a component in BZ to represent the package 20:27 < Oxf13> they get that automatically when the package is brought into Fedora 20:27 < Oxf13> the /source/ package that is 20:27 < stickster> Oxf13: Right, maybe that's not fully understood? 20:27 -!- perspectival [n=perspect@nat/redhat/x-vdmeuktvoqccbdwz] has joined #fedora-meeting 20:27 < perspectival> hello 20:27 < mmcgrath> perspectival: are you dhensley? 20:27 < stickster> perspectival: We meet again! :-D 20:27 < perspectival> yes 20:27 < mmcgrath> we're talking about 20:27 < perspectival> I assume we're discussing the component/product change 20:27 < mmcgrath> .ticket 1667 20:27 < zodbot> mmcgrath: #1667 (BZ Component and Product Change Request) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1667 20:28 < perspectival> right 20:28 < mmcgrath> yeah, no one in docs seems to know about it? 20:28 < mmcgrath> well, no one we've talked to (which isn't many yet) 20:28 < stickster> From yesterday, I thought that Sparks did know about this? 20:28 * stickster didn't see how the conversation ended 20:29 < perspectival> this name change was initially referenced on an internal email, and then Mike Hideo requested, in an email to me, that (verbatim): 20:29 < perspectival> "Can we change the component name to: 20:29 < perspectival> doc-Deployment_Guide for Fedora? " 20:29 < mmcgrath> perspectival: was Sparks ok with that? 20:29 < abadger1999> perspectival: Note, you're wanting to both change the name and change the product it's under. 20:29 < perspectival> I spoke to Sparks initially about this (2 days ago), and stickster was confusedly brought into it yesterday 20:29 < perspectival> yes 20:29 < perspectival> abadger1999: true 20:30 < quaid> mmcgrath: pong 20:30 < stickster> perspectival: It's OK, I'm used to being confused as quaid will tell you :-) 20:30 < perspectival> I have not spoken to Sparks about this again (he was away yesterday I believe) 20:30 < dgilmore> perspectival: if its in fedora it needs to go through a package review 20:30 < quaid> can haz fedora-docs-list plz 20:30 < abadger1999> dgilmore: It's not yet a package -- which is part of why I'm wondering why we want to moce it from the Fedora Documentation product to the Fedora product. 20:30 < mmcgrath> quaid: talking about 20:31 < mmcgrath> t.ticket 1667 20:31 < mmcgrath> .ticket 1667 20:31 < zodbot> mmcgrath: #1667 (BZ Component and Product Change Request) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1667 20:31 < dgilmore> abadger1999: then it does not belong under fedora 20:31 < perspectival> I am not sure, and I'm sort of new to the Fedora documentation procedures, so I'll relay that to Mike and make sure my information is correct 20:31 -!- Sonar_Guy [n=Who@fedora/sonarguy] has joined #fedora-meeting 20:31 < quaid> mmcgrath: what I mean is ... 20:32 < quaid> asking Sparks on IRC is not the way to resolve the question of, "What does Docs intend here?" 20:32 < abadger1999> perspectival: <nod> In terms of moving forward, the important thing is for us to understand what fedora-docs wants out of this. 20:32 < mmcgrath> quaid: <nod> 20:32 < abadger1999> quaid: +1 20:32 < perspectival> ok 20:32 < mmcgrath> perspectival: can you email this ticket to the fedora-docs-list so everyone knows whats up? 20:32 < quaid> if mhideo doesn't want to join fedora-docs-list to discuss, by all means proxy for the reasoning. 20:32 < mmcgrath> there's two parts to this, one of them is getting sparks and team all aware and stuff, the other one is technical 20:32 < mmcgrath> which we're still not sure of 100% 20:33 < quaid> I have insight for #2 20:33 < quaid> i) create new bugzilla component (package needed) 20:33 -!- foolish [n=foolish@fedora/foolish] has quit Remote closed the connection 20:33 < quaid> ii) remove the item from owners.list & probably confirm that it's gone with note to BZ team 20:33 < mmcgrath> <nod> 20:33 < quaid> >2 folks have the edit for owners.list, so no blockage there likely :) 20:34 < abadger1999> iii) bugzilla team shifts open bug reports to the new bugzilla component 20:34 < mmcgrath> perspectival: you know what steps to take next? 20:34 -!- drago01 [n=linux(a)chello062178124135.3.13.univie.teleweb.at] has quit Remote closed the connection 20:34 < quaid> abadger1999: yep, thx, that one too :) 20:34 < perspectival> I'm about to email fedora-docs list and CC mike 20:34 * quaid did all this recently, fwiw, so it does work 20:34 < stickster> quaid: good to know, excellent 20:34 < mmcgrath> perspectival: excellent 20:35 < mmcgrath> Ok, anyone have anything else for now? 20:35 < quaid> perspectival: sorry for any confusion; the Fedora deal is basically, work on it with the edge-focused team, they usually have people/processes in place to carry it onward 20:35 < mmcgrath> anyone have anything else on this? 20:35 < quaid> where carry == tell you who to contact next, what to do, etc. to enable individuals to achieve their own goals. 20:36 * quaid done now 20:36 < mmcgrath> Ok, moving on :) 20:36 < mmcgrath> #topic Infrastructure -- The PHX move 20:36 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- The PHX move 20:36 < skvidal> why did I read that as the THX movie 20:36 < mmcgrath> smooge: did you get the meeting invite for Friday? 20:37 < smooge> I did 20:37 < smooge> I am trying to figure out when it is exaxctly as evolution has it down for 1800 20:37 < smooge> which would be rather late for people on the east coast 20:37 < mmcgrath> :) 20:38 < mmcgrath> smooge: well there's wiki pages for us to fill out as well 20:38 < mmcgrath> smooge: so lets get some of the stuff we've discussed moved over 20:38 < smooge> oh boy 20:38 < smooge> I want 10GB to each system and a pony 20:39 < mdomsch> and ipv6 20:39 < mmcgrath> hahah 20:39 < abadger1999> smooge: Better get stable boys too, a pony for each system will produce a lot of... ammonia 20:39 < mmcgrath> smooge: lets get the server count and amp count at least put up there. 20:39 < smooge> ah yeah.. 20:39 -!- krichard [n=krichard(a)cpe-024-211-252-120.nc.res.rr.com] has joined #fedora-meeting 20:39 < dgilmore> mmcgrath: i want a rack full of sparc boxes :) 20:40 < smooge> mdomsch, could I ask a favor. I need an amp count for powervault and pe2950. I found max but not 'average'. 20:40 < mmcgrath> Anyone have anything else on that? 20:41 < mmcgrath> ok :) 20:41 < mmcgrath> #topic Infrastructure -- Open Floor 20:41 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 20:41 < mmcgrath> Anyone have anything they'd like to discuss? 20:41 < smooge> reboot of bastion tomorrow 20:41 < smooge> it should be a couple of file changes and a reboot.. 20:42 < smooge> upgrade/reboot of xen13 next week 20:42 < ricky> Ugh, I completely forgot, sorry 20:42 < mmcgrath> smooge: oh yes, excellent 20:42 < smooge> that will also cause some reboots 20:42 < smooge> actually I was thinking of combining them 20:42 < smooge> since bastion1 will need to be rebooted twice :) 20:42 < mmcgrath> I think both will be 0 impact, we'll see :) 20:42 < dgilmore> i did all the builders over the weekend 20:43 < dgilmore> except xenbuilder4 20:43 < ricky> xen13 already has reboots often enough but thankfully we're setup so that we don't notice them outside 20:43 < smooge> dgilmore, other than logwatch.. did you notice anything? 20:44 < dgilmore> smooge: nope 20:44 < dgilmore> it was very smooth 20:44 < dgilmore> i did have to exclude net-snmp* 20:44 < smooge> ? 20:44 < dgilmore> but thats due to needing to rebuild it to work in the builder environment 20:45 < dgilmore> smooge: it links to rpm 20:45 < dgilmore> but we bumped rpm 20:45 < smooge> ah so it should not affect other boxes 20:45 < dgilmore> nope 20:45 < smooge> or did everything get the newer rpm 20:45 * Fedora-Angel is away: I'm busy 20:45 < smooge> slow typing makes smooge a poor psort 20:45 < dgilmore> smooge: just builders releng boxes have a different rpm 20:46 < smooge> dgilmore, thanks 20:46 < mmcgrath> k, anyone have anything else? 20:46 < mmcgrath> If not we'll close the meetings in 30 20:47 < mmcgrath> ok 20:47 < mmcgrath> #endmeeting 20:47 -!- 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/Communicate/FedoraMeetingChannel for meeting schedule 20:47 < zodbot> Meeting ended Thu Sep 10 20:47:28 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:47 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-10/fedora-meeting.2… 20:47 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-09-10/fedora-meeting.2… 20:47 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-10/fedora-meeting.2…

2 1

Re: fp.o content via IPv6
by Allen Kistler 10 Sep '09

10 Sep '09

Matt Domsch wrote: > On Thu, Sep 10, 2009 at 05:16:23AM +0000, Daniel Drown wrote: >> That said, the various MSS fixes (point #2 and the origional poster's >> iptables command) avoid the problem for TCP. > > rhel5, which is what we're running in production, has a kernel old > enough that it doesn't have the iptables --clamp-mss-to-pmtu > capability for ipv6. The server side shouldn't need it. The option is used to make up for something broken on the other side of a lower MTU link. fp.o is native IPv6, isn't it? No tunnel? > We've had over 5000 successful connections using ipv6 this week, and > about 5 _reported_ failures. In the same time, we've had millions of > successful v4 connections. I'm inclined to believe the failures, > while annoying, are still few and far between compared with the rest > of our traffic. I'm not quite ready to turn off ipv6 again, or switch > to forcing "knowledgable" users to use www.ipv6.fp.o, as it would drop > our IPv6 userbase to effectively zero. In a previous note, Mike M reported spending more hours (his, yours, and others') than he liked tracking down connectivity problems. It would be enlightening to know if there was a common thread.

1 0

fp.o content via IPv6
by Allen Kistler 10 Sep '09

10 Sep '09

In case other 6to4 clients can't figure out why fp.o is beyond their reach over IPv6, here's some fixing I did to make access to fp.o over 6to4 work for me. I hadn't had a problem with hanging connections to other IPv6 sites, but I have for fp.o. I heard from Mike M on IRC that others had reduced their MTU to get 6to4 to work with fp.o. Starting there, my eventual solution was to put the following in the mangle table in ip6tables on my 6to4 router (all one line, of course): -A FORWARD -o tun6to4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 6to4 has an MTU of 1480 for most people, but 1472 for DSL. Probably something isn't generating an ICMP packet-too-big to send back to fp.o when the link MTU drops. Alternatively the packet could be getting dropped in transit or ignored by fp.o. Of course, clamping MSS in ip6tables only works for TCP.

9 10

Introduction
by Allen Kistler 10 Sep '09

10 Sep '09

It's probably a bit odd to introduce myself after having posted a few messages here, but I've been interested in joining this group for a while, though I haven't signed up in FAS as more than CLA, yet. I've been doing info security consulting for about the past ten years, although I don't consider myself exclusively a security guy. Part of that consulting has been Linux. Part of that's been Sun, Cisco, etc. I've been using and abusing RHL and Fedora since RHL 7.0. I'm no stranger to shell (sh/bash) scripting. There's a bit of perl in there, too. I'm an RHCE and a CCNA. For Fedora contributions to date, they've mostly been testing (lots during F11), filing bugs, and submitting a few patches. I should be attending the IRC meeting today (or tomorrow, depending when you read this). I look forward to working with you and contributing whatever I can.

1 0

Re: fp.o content via IPv6
by Allen Kistler 09 Sep '09

09 Sep '09

Daniel Drown wrote: > > [snip] > > I also have 6to4 setup on my home machine. I'm no IPv6 expert (or networking > expert, really), but I believe two things should be happening here: > > 1. the packet too big ICMP message should be coming from your tunnel box Hmm... To keep the response relevant to Fedora infrastructure, maybe the way for most readers to approach this message is as generally informational in nature. Pardon the ASCII art: Client Client e.g., Fedora Some ISP asymmetric Premises Premises +-----------+ +------------+ tunnel +-------------+ +-------------+ | IPv6 site +--+ 6to4 Relay +--------+ 6to4 Router +--+ IPv6 Client | +-----------+ +------------+ IPv4 +-------------+ +-------------+ "big" packet -->|(death) Big packets die at the ISP, before they enter the tunnel, because they're too big to enter the tunnel. The client 6to4 router has no opportunity to know the packet even existed in the first place. > 2. the MSS and path MTU should already be set even before it gets to this > point, in the router advertisement messages. Using Path MTU Discovery, both sides of the tunnel should be able to use ICMP to find Path MTU = Min(Link MTU). > I suspect that since you have a smaller MTU than default, changing the MTU on > your tunnel interface should solve the #1 problem (ip -6 link set dev tun6to4 mtu > 1472) It's already done by ifup-ipv6 and network-functions-ipv6. F9 and earlier used 1480 always (BZ #478441). F10 and later use (IPv4 MTU - 20) correctly. > Changing your radvd.conf (if you're using radvd) to have "AdvLinkMTU 1472;" > should fix #2. ... at the cost of all IPv6 routes through the box, not just the 6to4 one. It also wouldn't work for segments more than 0 hops away from the 6to4 router, and therefore unable to hear its advertisements. Path MTU Discovery *should* work (in an ideal world, even though it doesn't for me for fp.o). MTU Discovery works outbound, but apparently sometimes not inbound for me. radvd *is* another variable to tweak, though it still won't help anything that's not TCP. For things that aren't TCP, anything on the other side of the tunnel has no clue what the tunnel MTU is unless it tries to discover it. Of common protocols, only TCP has anything like the MSS option to give a hint to the other side. > [snip] > > (I should mention that curl over my 6to4 tunnel works fine with a mtu of 1480 > getting the fedoraproject front page) Unfortunately the reliability of access through 6to4 is geographically dependent. Previous to fp.o, I had no MTU problems with access to sites through IPv6. You may simply be geographically luckier than I am. The intent of the drafters was that, as dual-stacked ISPs multiplied, they'd deploy 6to4 relays for their IPv4 customers to get access to IPv6. As nearly as I can tell, that doesn't seem to be happening very much. When it does happen, it's not a smooth operation. That's not a rant. It's just an expectation that globally developing expertise in a new protocol won't be painless. Where does Fedora want to be in that?

1 0

Fixing the name of bastion1
by Stephen John Smoogen 09 Sep '09

09 Sep '09

bastion1.fedora.phx.redhat.com currently thinks its name is bastion. I would like to get it renamed correctly later this week with a reboot at Friday 2009-09-11 1600 UTC. Downtime should be 5 minutes. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

2 1

memcached opinions
by Mike McGrath 09 Sep '09

09 Sep '09

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

4 7

Re: fp.o content via IPv6
by Daniel Drown 09 Sep '09

09 Sep '09

On Wed, 09 Sep 2009, Mike McGrath wrote: > ipv6 has caused a lot of problems for certain people, very non-obvious, > takes several hours to fix problems. I wonder if there's anything more we > can do on our end. One not-very-elegent change that could be made on the webservers is to limit their maximum MTU when using IPv6. This would work around clients on tunnels tunnels configured with the wrong mtu, as they would never send a packet large enough to be dropped. Downside being, it's more packets (less efficient), and an odd configuration (surprise the next network admin).

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure September 2009