MirrorManager is now IPv6 enabled
by Matt Domsch
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
14 years, 7 months
Torrent changes
by Jesse Keating
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
14 years, 7 months
Meeting Log - 2009-09-10
by Ricky Zhou
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...
20:47 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-09-10/fedora-meeting...
20:47 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-10/fedora-meeting...
14 years, 7 months
Re: fp.o content via IPv6
by Allen Kistler
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.
14 years, 7 months
fp.o content via IPv6
by Allen Kistler
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.
14 years, 7 months
Introduction
by Allen Kistler
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.
14 years, 7 months
Re: fp.o content via IPv6
by Allen Kistler
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?
14 years, 7 months
Fixing the name of bastion1
by Stephen John Smoogen
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
14 years, 7 months
memcached opinions
by Mike McGrath
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
14 years, 7 months
Re: fp.o content via IPv6
by Daniel Drown
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).
14 years, 7 months