September 2009 - infrastructure - Fedora mailing-lists

hi, i newly joined fedora infrastructure group
by p sena 18 Sep '10

18 Sep '10

Hi, I am new to the fedora infrastructure group. I am going throug few of the links in the site to get a feel of the work. I have submitted my .ssh_rsa_key.pub from the site. I think I will get some intimation on this. Please someone can let me know further proceedings from here onwards. Cheers. Regards & Thanks Prabir Senapati mailto: senapati2001(a)yahoo.com

3 5

Ok. Looks like this one _may_ fulfill our calendering needs. Testing required.
by susmit shannigrahi 30 Jan '10

30 Jan '10

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

11 40

hosts for rawhide build chroots - different rpm versions?
by Axel Thimm 06 Oct '09

06 Oct '09

Hi, AFAIK the build hosts are RHEL5 (or maybe F10 by now?). At any rate the rpm used in rawhide is quite different than the ones from the hosts, how has this been solved in the build hosts? Has the hosting OS upgraded its rpm to be compatible to all hosted chroots? Or is the rpm within the chroot used? I'm asking in a double context: First I'd like to understand if smart can properly handle chroots of rawhide/F11 on F10/RHEL5 hosts. Anders Björklund (in the Cc, please keep him there on replies) has put a great deal of effort to have smart working on F10 and F11, and a smart version for managing F11 and later chroots on F10 or earlier would be great. And second I'd like to know how to setup a build environment for F11 for getting some ATrpms packages out. Thanks! -- Axel.Thimm at ATrpms.net

3 5

Re: FAD -- startin' early
by Paul W. Frields 03 Oct '09

03 Oct '09

I constructed a page on the wiki for an upcoming FAD where some contributors are going to work on some long-standing Fedora Talk related tickets. Details are here: https://fedoraproject.org/wiki/FAD_Fedora_Talk_2009 There's a list of related tickets on the page, namely #s 309, 395, 453, and 1160, that we're going to try to knock out that weekend. To a large extent they're duplicates, but they all revolve around extending the Fedora Talk capabilities. We're going to be conversing on this list since obviously the work's primarily, maybe even wholly, infrastructure-related. Below is a bit of introductory email from last night that I wanted to make sure was captured transparently here. Comments follow... Jeff C. Ollie wrote: > On Thu, Sep 24, 2009 at 7:13 PM, Paul W. Frields wrote: >> OK guys, now that we have the travel stuff sorted out, hopefully >> everybody has had time to check out the FAD page: >> >> https://fedoraproject.org/wiki/FAD_Fedora_Talk_2009 >> >> Our primary goals are to create: >> >> * On-demand recording and publishing (or at least dumping into a >> holding pen) >> >> * Streaming capability for live events (it completely works + >> documentation on exactly how to set it up and operate at a live >> events) > > It'd be nice if there was some easy tool that people could > yum-install that would make it easy to set up a VoIP soft phone for > Fedora Talk. That is probably outside the scope of the FAD, but > could be an idea for someone wanting to get into the Fedora > Infrastructure group to work on. You know what would work really well? A package with a dogtail script, that used the appropriate HTML tags so that PackageKit can download dogtail and deps for you, then run the script. You can actually see things running and therefore know how to do it later. (Unfortunately, it doesn't look like Dogtail has got a lot of recent love. It's been consistently rebuilt but I'm not sure it works, which is a shame -- it's really useful and it took me just a few minutes to learn how to write a script for Dogtail.) I do agree that's not something we should worry about until everything else gets done, or if anyone in the listening audience is keen on it, that might make a cool project through which you could learn a *lot* about being involved in Fedora. >> First order of business, I'd like to move this conversation to the >> right list. What would that be? Logistics? Is this truly > >> cross-team work? Or is there a better place, like Infrastructure? > > +1 on the Fedora Infrastructure list. And... here we are! :-) >> I'm also hoping that John Poelstra will help us by guiding this as a >> small project, helping us suss out the next questions to ask (for >> example, What is our desired end state? What resources do we need >> that we can set up now? etc.). > > We'll need one or two guests with hopefully direct access to the > Internet, VoIP and NAT/Firewalls don't always get along. Disk space > can be minimal at this point, we'll need to add more later for > archives. If we have to go through NAT/Firewalls we'll need to get > holes poked through before hand for SIP & RTP traffic. > Alternatively we could run our test system off of a spare box at > Paul's house, which could be nice if the system gets borked up. > Once a box for a test system is figured out we'd want to get a > minimal Asterisk system up and running. Our location is set right now to be a coworking office in the area. I'll find out more network details to see what they can support, although I suspect they aren't blocking much there. I can even stop by the facility early next week to do any testing, if someone can tell me what I need to test. > Probably want to look at getting Asterisk 1.6.2 packaged. It's > still in release candidate, but 1.6.2 has new conferencing software > that isn't hacked in by a 3rd party or requires a kernel module. > Since F13 early branching is happening soon we can develop the > package there and then backport it to RHEL or whatever we end up > running the service on. Cool idea, Jeff. > Getting the latest flumotion version packaged would be good too, as > flumotion would be my choice for doing the streaming of live events. > > Having a supply of spare headsets on hand would be good. I have one > that I keep in my laptop case, but it would be nice to have them on > hand so someone doesn't have to run out and get some at the last > minute. OK, any participants who don't have a USB headset they can bring should let me know. > Do we want to mess around with hard phones? I'm assuming that Jared > can get his hands on a few but time spent on setting those up is > probably going to be time taken away from other tasks. I'd say no, it's really all about what we're doing on the server(s) and softphones should be fine. But I yield to the experts... > Well, that's all I can think of for now... > >> John, maybe you can help figure out if we're setting up the right >> questions here, and are using the next 4 weeks as wisely as >> possible so that, for example, we don't have to brainstorm >> on-site. Instead, that will be done on the list in advance, and >> then we will be able to hit more significant milestones > during >> the 2+ days we have. > > FYI, I'll have extremely limited e-mail access from now until Sunday evening... Noted. You may not see this until then, and that's fine. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

8 25

FAD Fedora Talk tech items
by Paul W. Frields 03 Oct '09

03 Oct '09

Two tech items I wanted to clear up for Fedora Talk FAD: First, qe discussed earlier using softphones for consistency and less equipment-lugging. Didn't hear any votes against so that's all we're planning at this point. It also makes sense to concentrate on that use because the majority of people using Fedora Talk are likely using softphones. Second, network setup at the site. I talked to the owner of the office we'll be using and he says they have a wide-open wireless, *and* a wired connection we can feel free to use which is the same thing their wireless plugs into. I'm going to scoot over there on Friday if I can, and test how things work with a softphone. I didn't get any hints from anyone on what special tests I needed to do beyond trying to hook up to Fedora Talk and make and receive a call, so that's all I plan to do unless someone tells me otherwise. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

4 6

Blogs site?
by Mike McGrath 01 Oct '09

01 Oct '09

Whats the status of the blogs site? Is it ready to go? People want to use it :) Where are the directions? -Mike

10 17

FAD F-Talk non-tech stuff
by Paul W. Frields 01 Oct '09

01 Oct '09

Jeff reminded me of a couple topics that would be handy to note, so I just wrote them up on the wiki page for information: https://fedoraproject.org/wiki/FAD_Fedora_Talk_2009#Logistics -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

1 0

FAD Fedora Talk -- IRC, to-do
by Paul W. Frields 01 Oct '09

01 Oct '09

I'd like to get conversations going on exactly *how* we plan to attack the list of things to do for the FAD. The game plan is here -- many thanks to John, who already got us rolling with a planning page: https://fedoraproject.org/wiki/FAD_Fedora_Talk_2009_game_plan We've got four tickets -- probably with a bunch of duplication between them -- that we want to clear out as primary targets. Then there are an assortment of some possibly related bits we can hit as time allows. I sort of braindumped how those targets map out. I'd like attendees to look at this list and comment on each point -- what's done already? What still needs to be built? What, in your opinion, is the best way of doing it? If we can answer those questions *now*, we'll spend less time discussing at the FAD, and more time *doing*. I'll capture the discussion to the wiki as we find answers, so we can easily refer to it later. * Record calls * Stream calls * Publish the recording (to a meetbot-like web area?) * Add moderation features that support larger audiences * Build pieces that allow users to set these features either in advance (Web UI) or on-demand/interactively (e.g. "#8" = start recording) I'd also like to suggest that everyone attending get on IRC Freenode #fedora-fad now, so we can do easy one-off conversation there for trivial matters, and continue to capture strategies here and on the wiki. We'll be using that IRC channel for the FAD itself later. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

1 0

Looking for people who need guests.
by Mike McGrath 30 Sep '09

30 Sep '09

I'm looking to put some load on our new cloud environment. This is a pre-pre-pre type setup. The guests will go up, they'll go down. You know the deal. You'll only have this guest for a month or so but if you think you could use a guest, let me know. Because right now the guests aren't actually doing work. -Mike

7 13

Change Freeze
by Mike McGrath 30 Sep '09

30 Sep '09

Just a reminder to everyone. We are officially frozen under a prerelease freeze - http://fedoraproject.org/wiki/Infrastructure/SOP/Release#Change_Freeze You can check the list at - sudo yum -y install openoffice.org-draw git clone git://git.fedorahosted.org/git/fedora-infrastructure.git/ cd fedora-infrastructure/architecture oodraw Environments.odg -Mike

1 0

Finally ready to get involved and applied to the Sysadmin group
by Daniele Catanesi 30 Sep '09

30 Sep '09

Hello all, as suggested while applying to the Sysadmin group I'm writing to let you know I'm finally ready to be involved actively in the project and I'm looking for someone to sponsor my candidature to the group. As I've written in a previous mail I think the groups will fit my skills would probably be sysadmin-noc and sysadmin-test as the tools/task used in these groups are in line with what I'm usually tasked with, but well one step at time :) Just in case it is needed again my FAS username is ccielogs, Thanks and see you Thursday on IRC, Daniele.

2 1

CVS Outage Notification - 2009-09-29 04:25 UTC
by Jesse Keating 29 Sep '09

29 Sep '09

There will be a CVS outage starting at 2009-09-29 04:25 UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-09-29 04:25 UTC' Affected Services: CVS / Source Control Unaffected Services: Everything else. Reason for Outage: The CVS server will not accept connections so that we can mass-branch for Fedora 12. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

1 2

[OFF] About my collaborations.
by Davi Vercillo C. Garcia 29 Sep '09

29 Sep '09

Hi, I'm writing this e-mail for explain why I'm away from the group, avoiding bad speculations about my collaborations to Fedora Project. When I've started to try to help this team, I thought that my knowledge was enough to do those things that you do. But I've discovered that I need more experience and technical knowledge to do that. To not leave the project, I tried to find something that I could do better. So, I joined to Ambassadors' groups and to the Brazil Infrastructure group. And, right now, I'm evangelizing the project for people from communities that I participate, and helping the Brazilian infra team with theirs web services. That doesn't means that I'll give up to try to help here, or leave this group. But now, I'm preparing myself, learning more about this project and this team, for come back and try again. Sorry about something that I did. Thanks, -- Davi Vercillo C. Garcia B.Sc. Student - DCC-IM/UFRJ Fedora Project Contributor http://davivercillo.fedorapeople.org/ "If a million people say a foolish thing, it is still a foolish thing." - Anatole France

2 1

Introduction
by Lee Williams 29 Sep '09

29 Sep '09

Hi, Looking at the wiki it says to introduce myself. Well here goes... I'm married with 3 kids (aged 4, 2, 1 :D)... full time job but I do get time to spare surprisingly!!!! I love my family to pieces they mean the world to me. I've been working in IT for 10yrs now all in a Microsoft DOS / Windows based environment, starting with development in FoxBASE and FoxPro and moving through the versions to visual fox. I've not attended university but have never had a problem with reading / googlin' bits to learn new things; I do get quite a kick from picking up "new to me" technologies and helping to solve problems. Currently I work full time as a Visual Studio developer with Technology Management Ltd. in the UK developing .NET applications for the WinCE / Windows Mobile based mobile device market. Those applications are mainly written in C# but we do have a significant VB.net code base. Following the latest Microsoft based OS crash at home a rebuild has become necessary which I started this weekend - yesterday in fact, so I made the choice to make Linux my main OS; to be fair it should've been from when I dabbled with Fedora 7 and 8 thereafter... still... my foot has gone down, and my wife is scheduled a tour of Fedora at the weekend ;) I have recently bootstrapped myself to other languages C / C++ and php for web work I'm finding this interesting to say the least. I do have some experience with Apache and MySQL (obviously the strong knowledge I have in Internet Information Services and SQL Server have been somewhat transferable). It looks like I need to add python to the list of things to learn and this is something I've been mulling over so may just make that leap. >From all of that I'm hoping you can tell that whilst I have very little experience with 'nix environments I am keen to learn just need some guidance on where to go to pick that up. Away from PC's (if there ever is such time) I play guitar - well I play guitar, banjo, and mandolin to be honest. The last two I'm not so hot at but I can "hold my own" - to coin a phrase - on the guitar. I also love to read; and have - of all things - recently started dabbling in magic and performance thereof but... now I'm rambling :D I look forward to helping in whatever way I can. I'm looking for a good place to start, I'm obviously following the wiki, reading up when I can, and of course getting my own Fedora environment setup (although I do have one running in VirtualBox at work to satiate the 'nix desires whilst I'm at work :D). I'm am currently hoping to help in the sysadmin-devel FIG. So hello nice to "meet" and greet, and I hope you're well. Lee.

2 1

Updating servers before the freeze.
by Stephen John Smoogen 27 Sep '09

27 Sep '09

We would like to get the servers updated to RHEL-5.4 before the freeze next week. The boxes will be updated with remote ones done first and then the ones inisde of PHX. First will be: bu1: people1 ibiblio1: app5 backup2 ns2 proxy4 publictest1 publictest2 publictest3 torrent1 osuosl1: publictest6 publictest7 publictest8 serverbeach2: asterisk1 collab1 ns1 serverbeach3: collab2 asterisk2 serverbeach4: hosted1 serverbeach5: hosted2 telia1: app6 noc2 proxy5 publictest14 publictest15 publictest16 smtp-mm1 tummy1: proxy3 publictest10 -------------------------------- xen14: app1 bapp1 cvs1 fas2 puppet1 xen9: app2 app2.stg db1.stg memcached1 proxy1.stg sync1 xen3: app4 cvs1.stg fas1.stg qa1 releng1.stg spin1 sync2 xen5: bastion2 fas1 kojipkgs1 noc1 proxy1 value1 xen6: app7 xen10: log1 memcached2 xen13: app1.stg ------------------------------------ xen1: koji1 xen2: koji2 releng1 sign1 xen7: app3 proxy2 releng2 value2 xen11: secondary1 xen12: db1 xen15: RHEL5-mpm db2 koji1.stg relepel1 sign-bridge1 db3 I think we can do this Sunday/Monday.. the last set I will avoid as it would most effect engineering. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

1 0

Very large logfile on torrent1
by Stephen John Smoogen 25 Sep '09

25 Sep '09

So it looks like bttrack did not properly rotate its log in late August and had been writing to an old inode for a month. This filled up / to 85%. I cat'd the inode to /srv/tmp/oldlog for perusal.. I then grep '2./Sep/2009:' /srv/tmp/oldlog > /var/log/bittorrent/bttrack.log to get the last 4 days (500 mb of stuff) and started up bttrack again. I then did grep '2./Sep/2009:' /srv/tmp/oldlog > bttrack.log.20090919 and gzipped that into /var/log. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

3 2

Freeze on Tuesday!
by Mike McGrath 25 Sep '09

25 Sep '09

Just a reminder we'll be pre-release frozen starting on Tuesday the 29th. Get the changes in while you still can :) -Mike

1 0

Meeting Log - 2009-09-24
by Ricky Zhou 25 Sep '09

25 Sep '09

20:00 < mmcgrath> #startmeeting Infrastructure 20:00 < zodbot> Meeting started Thu Sep 24 20:00:57 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 -!- zodbot changed the topic of #fedora-meeting to: (Meeting topic: Infrastructure) 20:00 * ricky 20:00 < mmcgrath> #topic Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Who's here? (Meeting topic: Infrastructure) 20:01 * nirik is around. 20:01 * collier_s is 20:01 * a-k is here 20:01 < Ccielogs> good evening :) 20:01 * SmootherFrOgZ is 20:02 < abadger1999> Hello 20:02 -!- mikaellundberg [n=mikaellu(a)81-233-188-46-no87.tbcn.telia.com] has joined #fedora-meeting 20:02 * bochecha is here 20:02 < SmootherFrOgZ> abadger1999: hey ;) 20:02 < smooge> here 20:02 < mmcgrath> Ok, lets get started 20:02 < smooge> between sneezes 20:02 -!- _buno_ [n=bernd(a)nrbg-4dbe7b51.pool.mediaWays.net] has joined #fedora-meeting 20:02 < abadger1999> :-) 20:02 < mmcgrath> #topic Meeting Tickets 20:02 -!- zodbot changed the topic of #fedora-meeting to: Meeting Tickets (Meeting topic: Infrastructure) 20:03 < mmcgrath> Ah, I see no tickets :) 20:04 -!- azneita [n=azneita(a)121.97.177.169] has quit Network is unreachable 20:04 < mmcgrath> soo 20:04 < SmootherFrOgZ> :) 20:04 < mmcgrath> #topic Beta release 20:04 -!- zodbot changed the topic of #fedora-meeting to: Beta release (Meeting topic: Infrastructure) 20:04 < mmcgrath> The beta release will be in a few weeks. 20:04 < mmcgrath> that means we're going to be change frozen starting Tuesday next week. 20:04 < mmcgrath> So if you've got something to get in, get it in ASAP. 20:04 < mmcgrath> also, if you've got any major changes to do. Please try to get it in before the beta is done. It's hard to make changes between the beta and final release. 20:04 < mmcgrath> at least it has been in the past. 20:05 -!- krichard [n=krichard(a)cpe-024-211-252-120.nc.res.rr.com] has joined #fedora-meeting 20:05 -!- rishi [n=rishi@gnu-india/supporter/debarshi] has quit Read error: 145 (Connection timed out) 20:05 < smooge> no changes I know of at the moment from me. 20:05 < mmcgrath> K, any questions or comments on the upcomming freeze? 20:06 < mmcgrath> Allrighty 20:06 -!- cassmodiah [n=cass@fedora/cassmodiah] has quit Remote closed the connection 20:06 < mmcgrath> #topic Our first mirror 20:06 -!- zodbot changed the topic of #fedora-meeting to: Our first mirror (Meeting topic: Infrastructure) 20:06 < mmcgrath> So I finally setup our first mirror 20:06 < mmcgrath> http://serverbeach1.fedoraproject.org/ 20:06 < mmcgrath> I'd like to get it serverbeach branded at some point since they're paying for the whole thing and they've been good to us. 20:07 < mmcgrath> But it should start showing up in our mirror list soon if it's not there already. 20:07 < mmcgrath> we'll get a lot of interesting metrics from this, like package info. 20:08 < smooge> cool 20:08 < smooge> how much disk space did it take and how is it set up? 20:08 < mmcgrath> it's setup just like a normal mirror, only pulling in 10, 11 and EPEL. 20:08 < mmcgrath> excluding debug, and ppc for the moment 20:08 < mmcgrath> and we have 20:09 < mmcgrath> used about 150G and have 225G more available. 20:10 < mmcgrath> any other questions on that? 20:10 < smooge> not at the moment 20:10 < SmootherFrOgZ> nope 20:10 -!- mikaellundberg [n=mikaellu(a)81-233-188-46-no87.tbcn.telia.com] has quit 20:10 < smooge> It will be intersting how it handles release 20:11 < mmcgrath> probably not very well, it's not a very beefy box in that respect 20:11 < smooge> and to see if disk layouts and schedulers will affect it 20:11 < mmcgrath> only so much you can do with a two disk raid1 array as a mirror :) 20:12 < mmcgrath> but I too am curious how it will behave 20:12 < Ccielogs> :) 20:12 < mmcgrath> Ok 20:12 < mmcgrath> really that's all i have for this week. 20:12 < mmcgrath> so I'll open the floor 20:13 < mmcgrath> #topic Open Floor 20:13 -!- zodbot changed the topic of #fedora-meeting to: Open Floor (Meeting topic: Infrastructure) 20:13 < mmcgrath> anyone have anything they'd like to discuss? 20:14 < mmcgrath> no one has anything? 20:14 < mmcgrath> sweet, short meeting :) 20:14 < skvidal> I had a question 20:14 < SmootherFrOgZ> pxe move ? 20:14 < skvidal> oh nevermind 20:14 < SmootherFrOgZ> oops 20:14 < SmootherFrOgZ> phx move ? 20:14 < SmootherFrOgZ> any news ? 20:14 < smooge> mmcgrath, well then it should be as good as the old RH mirrors from 2001. 20:14 -!- JSchmitt [n=s4504kr@fedora/JSchmitt] has joined #fedora-meeting 20:14 < mmcgrath> SmootherFrOgZ: still going on AFAIK. I've put in a purchase for 4 new servers for PHX2 that will get installed early 20:14 < mmcgrath> that way we can test network out and all that. 20:14 < mmcgrath> as well as have some services migrated over prior to shutting PHX down 20:15 < mmcgrath> not sure when they'll get delivered though 20:15 -!- dwmw2_HIO is now known as dwmw2_gone 20:15 < SmootherFrOgZ> k. i can't remenber if our cloud infra will move also ? 20:15 < ricky> I thought those were already in PHX2 20:15 < mmcgrath> SmootherFrOgZ: nope, it'll stay 20:15 < mmcgrath> and be on a different network 20:15 < SmootherFrOgZ> nod 20:16 -!- RodrigoPadula [n=RodrigoP(a)189.106.7.117] has joined #fedora-meeting 20:17 < mmcgrath> Well, anyone have anything else? 20:17 < skvidal> not worth discussing 20:17 < skvidal> :) 20:17 < smooge> skvidal, did you have a questions still 20:17 < smooge> ok nm 20:18 < mmcgrath> hah 20:18 < mmcgrath> k 20:18 < mmcgrath> then we'll close the meeting in 30 20:19 < mmcgrath> #endmeeting 20:19 -!- 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:19 < zodbot> Meeting ended Thu Sep 24 20:19:13 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:19 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-24/fedora-meeting.2… 20:19 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-09-24/fedora-meeting.2… 20:19 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-24/fedora-meeting.2…

1 0

Self introduction Daniele Catanesi
by Daniele Catanesi 24 Sep '09

24 Sep '09

Hello all, my name is Daniele Catanesi and I've been thinking to subscribe to the infrastructure list for some time now. I'm an Italian Network and Systems Engineer with around 9 years of experience, I've been using Linux since 1999/2000 as my main Operating System and on various infrastructure servers in my actual company, even if their/our job is mainly geared toward MS stuff, with the responsibility to administer and keep them up and running. My main skills are in the networking area even if I feel confident in the administration and troubleshooting of Linux based servers, which to be totally honest is what I like more. I already participate in the Fedora project with the Italian L10N team localizing packages in my native language and I would like to participate in the infrastructure project for two main reasons, the first and somehow obvious one is the need to give back to the community, the second one is I think there is no better way to help than doing what I like which can be a good way to refine my skills. I have a permanent lab that could be easily used for testing purposes and proof of concept (measure twice and cut once) and I would be more than glad to use it to benefit the community. Ok I hope I did not "talk" too much, I'm going to read the various Infrastructure Wiki section the get a better view of the entire process. Thanks, Daniele. P.S. Working on the Fedora Project I've already created an account, of course, and signed the CLA so I guess I can skip this section. I know this could sound silly but I prefer to be sure.

2 3

Re: Wiki account removal needed?
by Jon Stanley 24 Sep '09

24 Sep '09

On Wed, Sep 23, 2009 at 4:14 PM, Paul W. Frields <stickster(a)gmail.com> wrote: > Looks like the user "Georgia10" just inserted spam on that page. > Aiyiyi. What's our procedure for deleting/disabling a rogue FAS account? It appears that the account in question was just created today, probably for the express purpose of spamming the wiki and then disappearing. I would like to think that only a human could create an accounts, there's a variety of steps involved. But maybe some sort of CAPTCHA on the signup page could reduce this in the future?

7 12

Developers and sysadmins: Config settings in wsgi scripts
by Toshio Kuratomi 23 Sep '09

23 Sep '09

Due to some bad examples on how to port code to wsgi, pretty much all of our apps put configuration information into the wsgi scripts that startup our apps. This is bad practice and we should stop now. The reasons this is bad: * There should be only one place that a config is set. * Config should live in files that rpm knows are marked %config. Otherwise, when a TG1 application's rpm is updated the application will be using its own version of the configuration until the next puppet run. Case study: Today I made some changes to the config files of all of our TG1 applications via puppet. The config changes had the desired effect in almost every case except FAS. After several hours of debugging, I found that a configuration variable wasn't set to what it should be according to the config file. Intuition hit and I found that the wsgi script was overwriting that particular variable. To fix this, I looked in modules/fas/files/fas.wsgi and found all of the lines like:: turbogears.config.update({'global': {'server.environment': 'production'}}) I made sure that those lines were reflected in modules/fas/templates/fas-prod.cfg.erb:: server.environment = 'production' Then committed those changes. I then made a patch for the upstream code and applied it (could also open a bug report if you don't have commit) so that other people using FAS know that this is bad practice and shouldn't continue. Wash, rinse, and repeat for pkgdb, bodhi, elections, and mirrormanager. Just letting you all know that if you think you have to check a wsgi script into puppet, chances are you should tell the developer or packager should be making changes to the code so that it goes into the config file instead. -Toshio

3 4

Re: [puppet: 1/2] Adding memcached selinux policy"
by Darren VanBuren 23 Sep '09

23 Sep '09

Why is maxconn an array? Seems like a waste to me. Darren VanBuren ------------------------- Sent from my iPod Try Fedora 10 today. Fire it up. http://fedoraproject.org/ On Sep 22, 2009, at 7:38, Mike McGrath <mmcgrath(a)fedoraproject.org> wrote: > commit 5b943443066594955fb0194d65524dff4e5ad468 > Author: Mike McGrath <mmcgrath(a)redhat.com> > Date: Tue Sep 22 09:38:19 2009 -0500 > > Adding memcached selinux policy" > > modules/memcached/manifests/init.pp | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > --- > diff --git a/modules/memcached/manifests/init.pp b/modules/memcached/ > manifests/init.pp > index bea2842..cdf5911 100644 > --- a/modules/memcached/manifests/init.pp > +++ b/modules/memcached/manifests/init.pp > @@ -1,5 +1,6 @@ > class memcached { > package { memcached: ensure => present } > + package { memcached-selinux: ensure => present } > > $maxconn = $memcached_maxconn ? { > "" => "1024",

4 5

CVS1 and selinux
by Mike McGrath 22 Sep '09

22 Sep '09

Selinux on cvs1 is now in enforcing mode. Please keep an eye out for any oddities or broken services and let us know. -Mike

3 5

TG1/Cherrypy config change to make redirects more robust
by Toshio Kuratomi 19 Sep '09

19 Sep '09

mirrormanager uses the TurboGears raise redirect('/new/url') idiom heavily. Today we found that whenever such a redirect was occurring in staging, the users browser would end up at the production mirrormanager site instead of staging. mmcgrath traced this to cherrypy creating URLs like this: http://admin.stg.fedoraproject.org/mirrormanager/ instead of like this: https://admin.stg.fedoraproject.org/mirrormanager/ When the http:// URL goes back to the server, the server rewrites it as an https:// URL. Due to the way staging works, that ended up being https://admin.fedoraproject.org instead of admin.stg. This problem also affects production -- it's just that it isn't as apparent there. In production we end up doing two requests instead of one -- the first one requests the http:// URL. Then apache tells the client to redirect to https:// and the second request is made. This also has the potential to return information to the server over http:// instead of https://. Although we haven't found a case where we'd get to that in a way that would reveal sensitive information yet (it has to be a specific controller method where sensitive data is being passed through a redirect() call) we want to close this potential for unpleasant surprises. Luckily, there's a quick config change that makes this problem go away: base_url_filter.on = True base_url_filter.base_url = "https://admin.fedoraproject.org/APPNAME" base_url_filter.use_x_forwarded_host = False (substitute "admin.stg" for "admin" if you're deploying to staging.) .on Turns on the base_url filter in cherrypy. Because we're deploying on one domain anyhow, this is on for almost all of our configs. .base_url manually specifies the base_url to use with the app. This gets substituted into redirects as the scheme, host, and initial path. .use_x_forwarded_host is the unexpected one. This was set to True on almost all of our apps before. When True, it tells cherrypy to construct the redirect URL from the X_FORWARDED_FOR header sent by the apache proxy instead of using the manually specified base_url. The X_FORWARDED_FOR header contains the host that is being forwarded to the proxy. It's combined with the scheme (http or https) that cherrypy is serving. Since we're serving http from the app servers (https is on the proxies only), that means the constructed urls use http. The algorithm behind .use_x_forwarded_host is simply making assumptions that aren't true in our environment. We have to set it False. I've just deployed a config update to elections, bodhi, mirrormanager, pkgdb, and fas that makes these changes. If I've missed any apps let me know or update the config in puppet yourself. Thanks, Toshio

1 0

Introduction
by Mike Santangelo 18 Sep '09

18 Sep '09

Hi all, I'm following along with the wiki and have reached the point where I need to send an introduction e-mail to the list. :) My name is Mike Santangelo and I'm a linux consultant within Red Hat. I decided I wanted to get more involved and volunteer in the Fedora side of the house as my time permits, so the infrastructure team looked like a good place for me and my skills. I've been working with various *nix's for around 17 years now, starting with AT&T Unix way back in '92. Solaris was probably the OS I worked with the most leading up to when I started working on Red Hat products full time. I have worked with Red Hat products professionally off and on since 2002 or so, and been experimenting with various Linux flavors since the late 90's. I'm an RHCE with a Certificate of Expertise in Enterprise Storage Management (GFS and Clustering), and hope to get my certificate in Satellite soon. I have done a lot of engagements centered around Satellite and Clustering in the last year and a half so I am fairly strong on those technologies. I'm also a very good troubleshooter, which I think is my strongest skill. That, and I'm not afraid to go ask for help if I don't know something. I hope to be able to make some of the meetings soon. Since I'm a consultant I am on the road a lot so schedules can be tough, but I will definitely try. I'm not involved in anything else with Fedora yet, as infrastructure seemed like the natural first place for me as I looked around. Thanks and look forward to working with everyone, -Mike

1 0

Hello, My intro
by Chris Johnson 18 Sep '09

18 Sep '09

Hi all, I've been lurking on the mailing list for a while and I finally registered for my fedora account today (username: chrisj) I'm interested in helping out as time permits. I got on irc once (lurking again) and haven't really logged in since. I'll try to make a few meetings after the holidays I'm planning to get my personal test systems setup soon. I just moved and still getting things straight at home. Bought a 750GB drive last night and will be installing F10 over the weekend. I had been running the U... distro and it's time to get back to the fedora/RH rpm way of doing things :-) I've used RedHat since before Fedora existed (I think 6 was the first one). Started as a hobbyist, 2 years. Then got a job as an admin and have been doing Linux admin and Cisco networks for the last 5 years. My current employer is a Win shop so I just get to run the DNS, email, and network, but the network is 50 remote offices and 3 different data centers in the midwest. I don't mind the Windows too much and can find my way around them, it's also kinda fun to get the Linux and MS products to play nice together. I've worked with a lot of different linux and OSS software products including: postfix, openldap, apache, bind, samba, mailman, pam, built some custom rpm's, etc. I use RHEL mostly at work and some fedora and Cent for testing (some suse, deb, and slackware in the past). I used to do lots of security firewall apliances with various linux distros (I was a big fan of LRP when it would fit on a floppy), most of this is now done with Cisco in my world. I can shell script pretty well and I've written several perl scripts in the last few years (dabbled in php but not enough to know it well). I've always been interested in python but don't have much if any exp with it. I also don't have much experience with SQL/DB or source control. I was looking at the FIGs and would be interested in the base sysadmin and sysadmin-noc for now while I figure out where everything is and what it does. I'm also interested in more info on the sysadmin-tools and sysadmin-web FIG. So, next just apply for the FIGs, keep lurking, ask some questions, show up for IRC meetings? Thanks all, -- Chris Johnson ++++++++++ j.chris.johnson(a)gmail.com ++++++++++++++++++++

2 2

Meeting Log - 2009-09-17
by Ricky Zhou 18 Sep '09

18 Sep '09

19:59 < mmcgrath> #startmeeting Infrastructure 19:59 < zodbot> Meeting started Thu Sep 17 19:59:45 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 -!- zodbot changed the topic of #fedora-meeting to: (Meeting topic: Infrastructure) 19:59 < mmcgrath> #topic Who's here? 19:59 -!- zodbot changed the topic of #fedora-meeting to: Who's here? (Meeting topic: Infrastructure) 19:59 * ricky 19:59 * nirik is in the back. 19:59 * SmootherFrOgZ is 20:00 * skvidal nods 20:00 -!- notting [n=notting@redhat/notting] has joined #fedora-meeting 20:00 * collier_s here 20:00 * a-k is here 20:00 -!- sseiersen|Laptop [n=Scott(a)96.244.48.139] has joined #fedora-meeting 20:01 < mmcgrath> Ok, doesn't look like we have any meeting tickets so we'll just get right into it 20:01 < mmcgrath> #topic FAS accounts and capcha 20:01 -!- zodbot changed the topic of #fedora-meeting to: FAS accounts and capcha (Meeting topic: Infrastructure) 20:02 < mmcgrath> One thing I wanted to make known is we recently implemented a capcha in FAS. 20:02 < mmcgrath> by we I mean abadger1999 20:02 < mmcgrath> the problem was mostly caused from spammers we think. 20:02 -!- RodrigoPadula [n=RodrigoP(a)189.106.73.153] has quit "Saindo" 20:02 < mmcgrath> STill more research to do but as many as 2 in every 3 account we have in FAS was created by a spammer. 20:02 < mmcgrath> or at least someone who didn't verify their email. 20:02 < mmcgrath> But! no more :) 20:03 < ricky> :-) 20:03 < smooge> here 20:03 < mmcgrath> we re-consider freeing up those account names as well. Something worth discussing. 20:03 < mmcgrath> they'd not have been in any groups or anything so it might be safe. 20:03 < mmcgrath> might not be though, more research required. 20:03 * ricky is all for freeing up accounts that have never been verified (ie never logged on) 20:03 < mdomsch> yo 20:03 < mmcgrath> mdomsch: hey 20:03 * ianweller rolls in for da lulz 20:04 < mmcgrath> anyone have any questions or comments on that? 20:04 < mdomsch> wow, that's crazy 20:04 < mmcgrath> mdomsch: indeed :) 20:04 < notting> so, does this screw up all our account/registration growth stats? 20:05 < mmcgrath> notting: it does as far as what we have done in the past but we can get new stats I think. 20:05 < abadger1999> mmcgrath: It'll be interesting if our initial registration drops 20:05 < mmcgrath> abadger1999: I'm almost positive it will. 20:05 < ricky> Did we ever really assume that # accounts = # of active people? 20:05 < mmcgrath> ricky: depends on 'we' 20:05 < abadger1999> It'll only drop significantly if the accounts are being created by a machine. 20:05 < mmcgrath> I really don't consider a contributor a contributor unless they have a fedorapeople account. 20:05 < ricky> I guess the question is if those specific numbers are usually quoted to the press or anything 20:06 < ricky> Same here - I get my counts from ls /home/fedora | wc -l on fedorapeople.org :-) 20:06 < mmcgrath> ricky: some are. *but* generally we encourage people to use 'contributor' when siting those numbers. 20:06 < abadger1999> People that sign up but never verify email would still get through the captcha. 20:06 < mmcgrath> and we define a contributor as cla_done + one group 20:06 < mmcgrath> which is the fedorapeople count. 20:06 < mmcgrath> and that count will stay the same 20:07 < mmcgrath> So that's really all there is on that. 20:07 < mmcgrath> One thing I wanted to talk about was with affix 20:08 < mmcgrath> but I don't see him around right now so we'll wait. 20:08 < mmcgrath> he's looking for search engines for us. 20:08 < mmcgrath> Ok, so next topic 20:08 < mmcgrath> #topic PHX1 to PHX2 move 20:08 -!- zodbot changed the topic of #fedora-meeting to: PHX1 to PHX2 move (Meeting topic: Infrastructure) 20:08 < mmcgrath> So smooge and I have been working to get the various network maps, inventory and other related directions to RH's IT department. 20:09 < mmcgrath> Much of that stuff is available in gobby. 20:09 < smooge> makes gobby gravy 20:09 < mmcgrath> smooge also put some network diagrams up http://smooge.fedorapeople.org/ideas/ 20:09 -!- sseiersen|Laptop [n=Scott(a)96.244.48.139] has quit Remote closed the connection 20:09 < mmcgrath> It looks like we're going to be moving into 5 racks. 20:09 < mmcgrath> and spread properly so power isn't an issue. 20:09 < mmcgrath> we might expand into the 6th rack but I'm not counting on it, at least not for November. 20:10 < smooge> and look at smaller pdu's as we expand 20:10 * Oxf13 20:10 < Oxf13> here 20:10 < mmcgrath> smooge: yeah, are you a fan of those 1U horizontally mounted PDUs? 20:10 < smooge> mmcgrath, more that I am a fan of PDU's that aren't treated like checkbooks :) 20:11 < smooge> most PDU's have too many plugs for what you can use with modern equipment 20:11 < mmcgrath> maybe we should start getting servers with 4PS's in them :) 20:11 < mmcgrath> then double the PDU's 20:11 < mmcgrath> oh wait, that's the same as just doubling the pdus 20:12 < mmcgrath> anywho :) 20:12 < mmcgrath> So I still have some outstanding questions, I'm sure smooge does too 20:12 < mmcgrath> but it looks like this is going to be about a 48 hour outage. 20:12 -!- sseiersen|Laptop [n=Scott(a)96.244.48.139] has joined #fedora-meeting 20:12 < mdomsch> mmcgrath, when? 20:12 < smooge> no we should look at DC racks 20:12 < mmcgrath> mdomsch: after F12 ships, before the end of November. 20:12 < smooge> mdomsch, depends on how much F12 slide there is 20:13 < mdomsch> smooge, DC still doesn't buy much 20:13 < mmcgrath> Oxf13: whats the latest "what are the odds of F12 slipping"? 20:13 < Oxf13> no change 20:13 < mmcgrath> k 20:13 < Oxf13> still looking good 20:13 < mmcgrath> So does anyone have any questions or concerns about this move? 20:13 < mdomsch> mmcgrath, can we migrate bapp1 to another datacenter before then? 20:13 < mmcgrath> it's going to be a lot of planning, then a week or two of hell. 20:13 < mmcgrath> mdomsch: yeah we can add that to our list. 20:14 < mmcgrath> I've moved stuff I had budgeted for the last quarter of this FY into a more major purchse just thi sweek. 20:14 * ricky will probably be in his own hell week of at that point :-( 20:14 < mmcgrath> we'll have some servers in PHX2 hopefully in a couple of weeks that we can use for that. 20:14 < mmcgrath> ricky: sucker, at least we don't get graded :) 20:14 < mmcgrath> mdomsch: so right nwo the list of things we want to 'pre-move' is db1, db2, bastion3 (new) app1 and bapp1. 20:14 < mdomsch> mmcgrath, sure we do 20:15 < mmcgrath> mdomsch: I always thought this was more pass fail :) 20:15 < smooge> ricky its just midterms... you should skip them and come on out 20:15 < mdomsch> failure is not an option 20:15 < smooge> failure is always an option.. in fact most of my academic career is based on that. 20:16 < smooge> but then again one should not take Zonker Harris as a role model 20:16 < notting> if we slip, does that mean we relocate fudcon to mesa and do the move then? 20:16 < ricky> Haha 20:17 < mmcgrath> notting: actually not the worst idea I've ever heard :) 20:17 < Oxf13> hey, it'll be warmer than Toronto 20:17 -!- Sonar_Gal [n=Andrea@fedora/SonarGal] has quit "Leaving" 20:17 < skvidal> smooge: zipper, then? 20:18 < mmcgrath> One other thing we wanted to make people aware of is in PHX2 we're going to start seperating our network segments. 20:18 < mmcgrath> We're basically going to move to a 3 network system 20:18 < smooge> nah zipper is a real loser 20:18 < mmcgrath> 1) Buildsystem network 20:18 < mmcgrath> 2) Combined nfs / storage type network 20:18 < mmcgrath> 3) public network. 20:18 < mmcgrath> For those familiar with the environment, it's not too hard to figure out what will go where. 20:19 < ricky> Where does something not public like bapp1 go? 20:19 -!- thomasj [n=thomasj@fedora/thomasj] has quit Nick collision from services. 20:19 -!- thomasj_ [n=thomasj(a)e180136046.adsl.alicedsl.de] has joined #fedora-meeting 20:19 < mmcgrath> ricky: on the public network 20:19 < ricky> Oh, OK :-) 20:19 -!- thomasj_ is now known as thomasj 20:19 < abadger1999> smooge: You're just too old to appreciate him. 20:19 -!- XulLunch is now known as XulChris 20:19 < mmcgrath> the public network isn't so much "public IP space" as it is just for all general network stuff like the 834 network is now in PHX. 20:19 < ricky> Ah, OK 20:19 < mmcgrath> Ok, anyone have any questions on this? If not we'll move on. 20:19 < smooge> actually general network sounds better 20:19 -!- Pikachu_2014 [n=Pikachu_(a)85-171-18-56.rev.numericable.fr] has joined #fedora-meeting 20:20 < Oxf13> smooge: and sargent router? 20:20 < mmcgrath> Ok 20:20 < mdomsch> ricky, http://fpaste.org/oPMp/ 20:20 < mmcgrath> #topic Favicon.ico 20:20 -!- zodbot changed the topic of #fedora-meeting to: Favicon.ico (Meeting topic: Infrastructure) 20:20 < mmcgrath> a-k: whats the poop on this? 20:20 -!- Sonar_Gal [n=Andrea@fedora/SonarGal] has joined #fedora-meeting 20:20 < a-k> There are 4 favicons in puppet, but only 2 get sourced, and none of them are actually used by existing html, as far as I can tell so far 20:21 < mmcgrath> a-k: what ticket number was that? I forget? 20:21 * a-k checks 20:21 -!- Pikachu_2014 [n=Pikachu_(a)85-171-18-56.rev.numericable.fr] has quit Read error: 60 (Operation timed out) 20:21 < a-k> .ticket 1669 20:21 < zodbot> a-k: #1669 (the old favicon must die.) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1669 20:22 < mmcgrath> danke. 20:22 < mmcgrath> a-k: and you saw the note about smolts.org? 20:22 < a-k> Yes. Did you want to have no favicon at all on smolts? 20:22 < mmcgrath> We don't have one so just leave it null. 20:22 < a-k> OK 20:22 < mmcgrath> a-k: anything else on that? 20:23 -!- lmr [n=lmr(a)201.82.124.191] has quit "Ex-Chat" 20:23 < mdomsch> a-k: favicon doesn't have to get referenced in our html 20:23 < a-k> I had a couple suggestions in the ticket and Ricky liked one of them. If anybody has other ideas, let me know. 20:23 < mdomsch> it's automatically looked for by browsers 20:23 < a-k> mdomsch: yes. In document root as favicon.ico. 20:24 < mmcgrath> a-k: alrighty, thanks. 20:24 < a-k> That was one of my suggestions. 20:24 < mmcgrath> #topic mod_evasive 20:24 -!- zodbot changed the topic of #fedora-meeting to: mod_evasive (Meeting topic: Infrastructure) 20:24 < mmcgrath> So, some of you have probably seen make the mod_evasive module a bit mo' betta 20:24 < mmcgrath> This is largely because cvs1 has had some load issues recently 20:25 < mmcgrath> RH's internal search engine has been very agressive. 20:25 < mmcgrath> and google's crawler doesn't honor Crawl-Delay 20:25 < dgilmore> stupid bots 20:25 < mmcgrath> you can force google's crawler to crawl more slowly but it only lasts for 90 days. 20:25 < mmcgrath> So 20:25 < mmcgrath> I've decided to setup mod_evasive to be a bit more agressive about banning people. 20:26 < ricky> Does it have whitelists like denyhosts? ;-) 20:26 < mmcgrath> It's actually pretty hard to predict how or when someone will get banned because the various apache children don't talk to eachother. 20:26 < mmcgrath> ricky: it does. 20:26 < ricky> Ah, cool 20:26 < mmcgrath> I still want the content on cvs.fedoraproject.org to be searchable or I'd have banned it altogether. 20:26 < mmcgrath> it might be worth looking at alternatives to viewvc though. 20:27 < mmcgrath> or at least figuring out why it's so freaking slow. 20:27 < ricky> s/viewvc/cvs/ :-D 20:27 < notting> migrate all projects away from cvs? 20:27 < ianweller> cough get rid of cvs cough 20:27 < smooge> not our problem 20:27 < ricky> One side effect of viewvc is that it creates a bunch of junk rcs* files in /tmp 20:27 < ricky> I wasn't able to figure out why though 20:27 < smooge> ouch 20:28 -!- llaumgui [n=llaumgui(a)lns-bzn-51f-81-56-136-221.adsl.proxad.net] has joined #fedora-meeting 20:28 < mmcgrath> It's probably time for someone with time and courage to try starting the SCM Sig back up again. 20:29 < mmcgrath> Anywho, any questions about that? 20:29 -!- llaumgui [n=llaumgui(a)lns-bzn-51f-81-56-136-221.adsl.proxad.net] has quit Client Quit 20:29 -!- llaumgui [n=llaumgui(a)lns-bzn-51f-81-56-136-221.adsl.proxad.net] has joined #fedora-meeting 20:29 < abadger1999> svn! 20:29 < abadger1999> Or should that be !svn ? 20:29 < abadger1999> :-) 20:30 < mmcgrath> moving on :) 20:30 < mmcgrath> #topic pgpool 20:30 -!- zodbot changed the topic of #fedora-meeting to: pgpool (Meeting topic: Infrastructure) 20:30 < smooge> bitkeeper 20:30 < mmcgrath> welp, we tested pgpool in staging and it's been working on db2 for a while with no issues (and no connections) 20:30 < mmcgrath> mdomsch: after the meeting do you want to enable pgpool in production with mirrormanager? 20:30 < smooge> no connections? 20:30 < ricky> It could be good to start off with making the crawlers use pgpool 20:30 < mmcgrath> smooge: it's been deployed but the firewall's been active. 20:30 < ricky> Then the the mirrormanager and transifex apps 20:31 < mdomsch> mmcgrath, if you wish 20:31 < mdomsch> mmcgrath, I'll have to go to another meeting, so can't be there if it breaks 20:31 < mmcgrath> mdomsch: you won't have to do anything for that but it'd be good to have you around incase the sky falls. 20:31 < mmcgrath> the revert is simple enough and all. 20:31 < mdomsch> and I've got a minor MM update to push, to fix the can't-create-a-netblock bug 20:31 < mmcgrath> ah, well goodie. 20:31 < mdomsch> trying to to test that on stg 20:32 < mdomsch> but that's separate; so do your thing 20:32 < mmcgrath> mdomsch: will do. 20:32 < mdomsch> and remember it won't take effect for all the crawlers for a couple hours 20:32 < mmcgrath> <nod> 20:32 < mmcgrath> FWIW, I saw a measurable (not major) performance increase in my tests. 20:32 < mmcgrath> I can't explain that 20:32 < mmcgrath> but it was there. 20:33 < mmcgrath> perhaps the logging in phase of psql is slower then it could be :) 20:33 < mmcgrath> Ok, anyway. With that 20:33 < mmcgrath> #topic Open Floor 20:33 -!- zodbot changed the topic of #fedora-meeting to: Open Floor (Meeting topic: Infrastructure) 20:33 < mmcgrath> Anyone have anything they'd like to discuss? 20:33 < ricky> Can we get a quick overview of how the ipv6 stuff went? 20:33 < mmcgrath> Sure. 20:33 < ricky> Are all the major problems ironed out? 20:33 < mmcgrath> I'll do the quick version 20:34 < mmcgrath> we started, some people couldn't reliably use TCP traffic (and probably other types of traffic) 20:34 < mmcgrath> the iptables rule on the list won't work for us because RHEL5 doesn't support it yet. 20:34 < mmcgrath> but by specifying a lower MTU, I've not heard a single complaint since. 20:34 < mmcgrath> and we're *STILL* waiting on the glue record AFAIK. 20:34 < mmcgrath> I'm not sure why that is though 20:34 < ricky> Cool - that's something that happened on the person's side and not our side? 20:34 < mdomsch> mmcgrath, right, no glue yet 20:35 < mmcgrath> ricky: well it could be done in either place actually. 20:35 < mmcgrath> but by doing it on our server, others don't have to do it. 20:35 -!- lmr [n=lmr@nat/redhat/x-zqdnruhqxvutbeee] has joined #fedora-meeting 20:35 < ricky> Ah, good 20:35 < mmcgrath> oh and mdomsch did some neat stuff as he mentioned on the list wrt MM and geo ip 20:36 < mmcgrath> mdomsch: I saw you prodding warthog9 again about geoip dns. We starting to think that over again? 20:36 < mdomsch> mmcgrath, not really; i was just looking for how to implement a better backend for bind 20:36 < mdomsch> the zonefile for doing BGP lookups takes 1GB RAM 20:36 < mmcgrath> ah 20:36 < mdomsch> so I didn't do that; I custom-coded it in MM, takes 7MB 20:36 < smooge> wow thats big.. 20:37 < mmcgrath> mdomsch: when you figured out how to do it in 7M did you do a dance? 20:37 < smooge> and then its small 20:37 * mmcgrath would have. 20:37 < mdomsch> oh yeah 20:37 < mdomsch> celeste was scared 20:37 < ricky> Heheh 20:37 < mmcgrath> hahah, it's like you've invented fire 20:37 < mmcgrath> well good work on taht too 20:37 < smooge> removed all the 0's? 20:37 < mdomsch> that's not in production yet 20:37 < mdomsch> but coming along 20:37 < mmcgrath> related to dns and geoip, I'd still like to see that as a TODO sometime. 20:37 < mmcgrath> but not urgent. 20:37 < mdomsch> ok, on that note 20:38 < mdomsch> we have an offer for hosting from China Unicom 20:38 < mmcgrath> we're probably getting to the point where we need to re-think our content distribution network. 20:38 < smooge> cool. 20:38 < mdomsch> they're looking for size estimates for servers 20:38 < smooge> can I go to do the buildout? 20:38 < mdomsch> what do we want to put there, and what server resources do we need? 20:38 < ricky> mmcgrath: wikipedia apparently uses powerdns for geodns 20:39 < mmcgrath> mdomsch: do you think they were thinking about providing servers as well? 20:39 < mdomsch> smooge, catch Ivory on IRC 20:39 < ricky> Maybe something to take a look at (and it has a bind-style zone file backend) 20:39 < mdomsch> mmcgrath, yes, I believe so. 2 asks: 20:39 < mmcgrath> ricky: yeah I think those are the big winners right now in that market. pdns or bind + a patch 20:39 < mdomsch> 1) they set up and run a mirror 20:39 -!- petreu| [n=peter(a)213.20.156.34] has quit "Don't worry; it's been deprecated. The new one is worse." 20:39 < mdomsch> 2) they give us dedicated hosting and Xen guests 20:39 < mmcgrath> So we wouldn't have to worry about the hardware at all with the xen guests? 20:40 < mmcgrath> I'd totally go for that 20:40 < mdomsch> that's the ask. We'll see. 20:40 < mmcgrath> it's worked out well for us in BU 20:40 < smooge> I think we would like xen dom0 if possible . domU's is nice 20:40 < mmcgrath> yeah 20:40 < mdomsch> so if anyone sees Ivory on IRC, be nice 20:40 < mmcgrath> heheh 20:40 < smooge> np. 20:40 < mdomsch> and if anyone speaks Chinese, that would be a big plus! 20:40 < mdomsch> as I don't 20:40 < smooge> crap. neither do i 20:40 < mmcgrath> yeah, do we have any native chinese speakers in the house? 20:40 < Oxf13> I can barely order it off a menu 20:41 * ricky wishes he could read/write, but nope :-( 20:41 < mdomsch> his english is pretty good, but he's concerned about it. 20:41 < mmcgrath> mdomsch: I'd know how to ask Ivory to order spicy tofu. 20:41 < mmcgrath> and then tell him it was good :) 20:41 < smooge> his english is probably better than mine 20:41 < ricky> Something like "la dou fu" :-) 20:41 < mmcgrath> mdomsch: I'll get some specs to you about what would be good to have over there. 20:41 < mdomsch> on another unrelated note 20:41 < mdomsch> I'll be at LinuxCon all next week 20:42 < smooge> mdomsch, cool 20:42 < Oxf13> ditto 20:42 < smooge> where is that this year? 20:42 < Oxf13> Portland 20:43 < smooge> cool. and wet 20:43 < smooge> blackberries are really good right now I have been told 20:44 < smooge> on my note, xen13 is now RHEL-5.4 and should not reboot as often 20:44 < mmcgrath> smooge: cheers! 20:44 < smooge> bastion1 should also really really think its bastion1 20:44 < ricky> Nice :-) 20:45 < ricky> Did it go pretty smoothly, or were there any bumps along the way? 20:45 < ricky> rhel 5.4 domU went pretty smoothly 20:45 < smooge> xen13 needed /etc/grub hand edited. 20:45 < ricky> Ah, yow 20:45 < smooge> so I had to reboot twice.. as I forgot the first time 20:45 -!- lmr [n=lmr@nat/redhat/x-zqdnruhqxvutbeee] has quit "Ex-Chat" 20:45 < smooge> and fas1 took 3 xen creates to start up 20:46 < mmcgrath> smooge: what needed to be altered in grub? 20:46 < smooge> and I didn't see why in the logs 20:46 < smooge> it was booting by default to an old kernel. 20:46 < ricky> Strange 20:46 < ricky> Ah, then I take my "yow" back :-) 20:46 < smooge> so when I updated it moved from booting from 1 to 2 20:46 < smooge> so I moved it to 0 20:46 -!- RadicalRo [n=radical(a)193.254.32.144] has quit "Leaving." 20:46 < mmcgrath> ahh 20:47 < a-k> smooge: /etc/sysconfig/kernel ? 20:47 < ricky> It's set to yes on xen13 20:48 < mmcgrath> ricky: what about DEFAULTKERNEL 20:48 < ricky> Not sure why it wouldn't have gotten updated automatically. Maybe we had manually edited things before? 20:48 < mmcgrath> is it kernel or kernel-xen 20:48 < ricky> That's set to kernel 20:48 < mmcgrath> that should probably get set to kernel-xen 20:48 < ricky> Ahh 20:48 < mmcgrath> Ok, anyone have anything else to discuss? 20:48 -!- rdieter is now known as rdieter_away 20:48 < mmcgrath> If not we'll close the meeting in 30 20:48 < smooge> ricky, I think it was manually edited in the past when trying to figure out which kernel worked 20:48 < smooge> nothing else from me. 20:49 < ricky> One more thing 20:49 -!- lmr [n=lmr@nat/redhat/x-yicihbutbatmwhdy] has joined #fedora-meeting 20:49 < ricky> Should we email mirror-list-d about the i2 mirror soon? 20:49 < mdomsch> what i2 mirror? 20:49 < mmcgrath> ricky: good question 20:49 < ricky> The networking issues there seem to be resolved for the most part 20:49 < mdomsch> at rdu? 20:49 < mmcgrath> mdomsch: the RDU i2 mirror seems to be up and running well 20:49 < ricky> Yup 20:49 < mdomsch> ah, good to know 20:49 < abadger1999> mmcgrath: how's kvm testing going? 20:49 < ricky> (And same question for sync1/sync2) 20:49 < mmcgrath> ricky: what was the last speed test? 20:49 -!- cdelpino [n=cdelpino(a)pool-70-111-139-93.nwrk.east.verizon.net] has quit "Leaving" 20:50 < mmcgrath> abadger1999: oh, good question. I'll get to it in just a sec. 20:50 < mmcgrath> ricky: sync1/2 isn't ready for public consumption yet. 20:50 < mdomsch> so we don't need static routes for RDU i2 anymore? 20:50 < mmcgrath> mdomsch: that's my impression 20:50 < mmcgrath> ricky: what IP was it at? 20:50 < ricky> download-i2.fedora.redhat.com? 20:51 < ricky> I'm getting excellent speeds from osuosl1 right now 20:51 < ricky> (it showed >140 MB/s in the beginning and eventually returned to >7 MB/s which is still good) 20:51 < mmcgrath> mdomsch: ^^ 20:51 < mmcgrath> Oh, and I wanted to talk about cloud stuff too 20:52 < mmcgrath> Ok, real quick. 20:52 < mmcgrath> abadger1999: the kvm stuff is going ok. We were having horrible IO performance issues on app7 20:52 < ricky> Although starting a download from ibiblio1 at the same time caused the osuosl1 one to drop down to <500 KB/s :-( 20:52 < mmcgrath> after changing some drivers around it's better but still not as fast as some of the app servers. 20:52 < mmcgrath> await has been a big problem. 20:52 < ricky> So it's not very balanced it seems 20:52 < mmcgrath> abadger1999: but research continues :) 20:52 < mmcgrath> the good news is we're in no rush to switch to it so we can make it behave exactly was we want to. 20:53 < mmcgrath> SmootherFrOgZ: you around? 20:53 < mmcgrath> The cloud stuff has been going well, SmootherFrOgZ has been hard at work. 20:53 < SmootherFrOgZ> mmcgrath: yep 20:53 < mmcgrath> we keep running into lots of little issues. 20:53 < mmcgrath> a million paper cuts causing us to be unable to use cumulus.fedoraproject.org 20:53 < mmcgrath> SmootherFrOgZ: any luck with the nics? 20:54 < SmootherFrOgZ> we're currently debuging them to get them work properply 20:54 < SmootherFrOgZ> actyually nic show up with wrong interface name 20:54 < mmcgrath> SmootherFrOgZ: ok, well good work on it so far, I know this issue in particular has been quite irksome 20:54 < mmcgrath> Ok, anyone have anything else they'd like to discuss? 20:55 < mmcgrath> if not we'll close the meeting in 30. 20:56 < mmcgrath> Allright 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/Communicate/FedoraMeetingChannel for meeting schedule 20:56 < zodbot> Meeting ended Thu Sep 17 20:56:42 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:56 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-17/fedora-meeting.2… 20:56 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-09-17/fedora-meeting.2… 20:56 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-09-17/fedora-meeting.2…

1 0

Approval?
by Eric Meng 17 Sep '09

17 Sep '09

Hey guys, Well I haven't been approved yet to join the sysadmin base group, so I don't think I can work on anything yet, am I? Well, I am currently in school right now and I'm not sure if there is anything I can do that fits my skill level. Any suggestions? When can I get approved? Thanks, Eric

2 1

Merging from staging to master
by Mike McGrath 16 Sep '09

16 Sep '09

This has bugged me forever and I think I've got it figured out now (thanks mdomsch for pointing me in the right direction) Lets say you've been working for weeks on a module in staging and you want to cherry pick those commits. How do you do it? It becomes trickier even if someone else has been working on other modules in staging. This seems to do the trick: git log --name-status master..staging module/path or to see the diff git diff master staging module/path The only thing to be careful of that I can tell is if one of the commits listed in git-log includes something in another path outside of your module. Anyway, if you can think of a better way to do this let me know, so far though this worked well for me. -Mike

4 8

Introduction
by Eric Meng 16 Sep '09

16 Sep '09

Hi, My name is Eric Meng, I'm a sophomore in high school with substantial experience with Linux. I have no previous work experience, but hope to gain new knowledge and information by volunteering for Fedora. Credentials: - Certified Red Hat Technician (my number is 605009710126274) - Self taught - Self-motivated; strong passion for technology - Knowledge in Perl & Shell scripting - Analytical thinker; able to trouble shoot problems that arise - Strong administration skills in all areas listed under the RHCT requirements - Exceptional communicator - 4.0 GPA student Reasons for joining: - Gain experience/ learn - Help Linux community - Improve Fedora - Get a sneak peak of new technology & software - See how Fedora works behind the scenes - Have Fun!!

2 1

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

11 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 11 Sep '09

11 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 11 Sep '09

11 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 10 Sep '09

10 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 10 Sep '09

10 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 10 Sep '09

10 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 10 Sep '09

10 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

Fedora Insight Zikula on pt6 Is About To Be Upgraded
by Affix 06 Sep '09

06 Sep '09

Hey Guys, I am about to Upgradde pt6 zikula to Zikula 1.1.2 The upgrade process should take between 10-20 Minutes using the zikula patch files. I have backed up the database to : /usr/share/zikula-preupgrade-backup The Theme has been copied to the theme SVN as mentioned in a previous email to the designs list. Regards, Keiran Smith - Fedora Ambassador / BugZapper / Designer - <affix(a)fedoraproject.org> - Free Software Foundation Associate - <keiran.smith(a)member.fsf.org> - http://keiran-smith.net - Call me on +44 (0) 131 208 4347

2 2

Licensing policy for apps developed by Fedora Infrastructure now in effect
by Toshio Kuratomi 05 Sep '09

05 Sep '09

Over the past few months, Fedora Infrastructure has been discussing having a consistent set of licenses for applications and scripts we create for Fedora. The goals of doing this were to * Be able to share code among the various programs that we write. * Not have our libraries force a specific license on the apps that we write. * Not have conflicting licenses between our apps and our libraries * Have a clear understanding of the steps we must take whenever we want to move code from an application under one license to a library under a different one. * Protect the code we write from being taken proprietary (note, this is not the same for every author. Mirrormanager, for instance, is under the MIT/X11 License). * Be able to stay compliant with licenses within our production, staging, and publictest environments At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing The basics are: * license code that is meant to be used as a library as LGPLv2+. * license code that's meant to be used as an application as GPLv2+. * If we want to write something and use another license we should discuss it to figure out how it's going to impact us and whether there's a better way to achieve our goals first. Most of our apps are currently under GPLv2(only) so we're going to be working to change the licensing on those apps over time to reflect GPLv2 or later. If you find something that we've written that's not under GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can either get to work on making the license match the guidelines or let you know why it's not being changed. The one other thing for Infrastructure developers and System Admins to note in the Policy is the section on handling AGPLv3 applications. During the discussions about whether to use AGPLv3+ for our web applications we found and delimited many issues that need to be addressed when deploying AGPLv3+ licensed code. The aGPL portion of the policy is our first attempt at keeping us compliant with any code that is under this license. Highlights are: * Apps deployed to production under AGPL must be deployed from RPMs. Any hotfixes to those apps must have the patch in a ticket in trac on http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX. * Any AGPL app deployed in infrastructure must have links in the footer to the fedora-infrastructure SRPM repo and the trac query that pulls up our hotfixes so that people can find the exact source that we're running at any given time. * Staging must follow the same rules regarding SRPM and hotfixes. Once again, failing to link to the exact source for what we have running would put us out of compliance. * No AGPL apps can be hosted on publictest boxes at this time as publictest boxes are intended for development and the high rate of change in development is not conducive for constantly updating RPMS or patches in trac. If there's demand for publictest hosting of AGPL apps we'll need to design some method of restricting who can access the applications running there to satisfy the legal requirements. -Toshio

3 3

[Important] app7 information Re: [puppet] Add app7 to main rotation for most apps, follow up to fedora-infrastructure-list
by Nigel Jones 03 Sep '09

03 Sep '09

Hi Guys, I just want to provide an explanation at whats going on here with my recent commits, in particular this one! So here is the run down... app7 is deployed as a KVM guest on xen6, both are running Red Hat Enterprise Linux 5 update 4 (the latest and greatest), both had been running without load, stable for around 30 days which is great (xen6 was running Beta at the time, and app7 running 5.3). Today, we decided to put it into production to serve two purposes. 1. as a test of KVMs abilities 2. as a test of if our stuff works with 5.4 The good news, is that everything seems to be working so I've added it to haproxy, with two exceptions. 1. fedoraproject.org wiki 2. smolts.org wiki Both require a process run on our filer so we can mount the required directories, I'll enable these sites in a day or two. If you notice oddities that seem to be as a result to this change with: * mirrorlist * pkgdb * docs.fedoraproject.org * smolt * mirrormanager * bodhi * fedora community * (or very very unlikely) Elections App ;) Please let me, Mike and Smooge know, and if it's really really bad, remove the line from the haproxy.cfg for app7 and that application (and create a fedora-infrastructure ticket assigned to me (nigelj) please). I have verified that these applications load okay though. - Nigel ----- "Nigel Jones" <nigelj(a)fedoraproject.org> wrote: > commit 1088959810b6a0604965f62ce7fa067081658cc6 > Author: Nigel Jones <nigelj(a)puppet1.fedora.phx.redhat.com> > Date: Thu Sep 3 06:47:36 2009 +0000 > > Add app7 to main rotation for most apps, follow up to > fedora-infrastructure-list > > modules/haproxy/files/haproxy.cfg | 11 ++++++++++- > 1 files changed, 10 insertions(+), 1 deletions(-) > --- > diff --git a/modules/haproxy/files/haproxy.cfg > b/modules/haproxy/files/haproxy.cfg > index d9a02e3..8247023 100644 > --- a/modules/haproxy/files/haproxy.cfg > +++ b/modules/haproxy/files/haproxy.cfg > @@ -47,6 +47,7 @@ listen mirror-lists 0.0.0.0:10002 > server app4 app4.fedora.phx.redhat.com:80 check inter 5s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 check inter 10s rise 2 > fall 3 > server app6 app6.vpn.fedoraproject.org:80 check inter 10s rise 2 > fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 5s rise 2 > fall 3 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 5s rise 2 fall 3 > option httpchk GET /mirrorlist > > @@ -58,6 +59,7 @@ listen pkgdb 0.0.0.0:10003 > server app4 app4.fedora.phx.redhat.com:80 check inter 10s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 backup check inter 15s > rise 2 fall 3 > server app6 app6.vpn.fedoraproject.org:80 backup check inter 15s > rise 2 fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 10s rise 2 > fall 3 > server bapp1 bapp1.vpn.fedoraproject.org:80 backup check inter > 10s rise 2 fall 3 > option httpchk GET /pkgdb > > @@ -76,6 +78,7 @@ listen docs 0.0.0.0:10005 > server app4 app4.fedora.phx.redhat.com:80 check inter 5s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 check inter 5s rise 2 > fall 3 > server app6 app6.vpn.fedoraproject.org:80 check inter 5s rise 2 > fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 5s rise 2 > fall 3 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 5s rise 2 fall 3 > option httpchk GET /docs/ > # > @@ -87,6 +90,7 @@ listen smolt 0.0.0.0:10006 > server app4 app4.fedora.phx.redhat.com:80 check inter 10s rise 2 > fall 5 > server app5 app5.vpn.fedoraproject.org:80 check inter 20s rise 2 > fall 5 > server app6 app6.vpn.fedoraproject.org:80 check inter 20s rise 2 > fall 5 > + server app7 app7.fedora.phx.redhat.com:80 check inter 10s rise 2 > fall 5 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 20s rise 2 fall 5 > option httpchk GET /smolt/reports/search_profiles > > @@ -97,7 +101,8 @@ listen voting 0.0.0.0:10007 > server app3 app3.fedora.phx.redhat.com:80 check inter 2s rise 2 > fall 5 > server app4 app4.fedora.phx.redhat.com:80 check inter 2s rise 2 > fall 5 > server app5 app5.vpn.fedoraproject.org:80 backup check inter 2s > rise 2 fall 5 > - server app6 app6.vpn.fedoraproject.org:80 check inter 2s rise 2 > fall 5 > + server app6 app6.vpn.fedoraproject.org:80 backup check inter 2s > rise 2 fall 5 > + server app7 app7.fedora.phx.redhat.com:80 check inter 2s rise 2 > fall 5 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 2s rise 2 fall 5 > option httpchk GET /voting/ > > @@ -109,6 +114,7 @@ listen mirrormanager 0.0.0.0:10008 > server app4 app4.fedora.phx.redhat.com:80 check inter 15s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 backup check inter 20s > rise 2 fall 3 > server app6 app6.vpn.fedoraproject.org:80 backup check inter 20s > rise 2 fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 15s rise 2 > fall 3 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 15s rise 2 fall 3 > option httpchk GET /mirrormanager/static/css/fedora.css > > @@ -120,6 +126,7 @@ listen bodhi 0.0.0.0:10009 > server app4 app4.fedora.phx.redhat.com:80 check inter 20s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 backup check inter 35s > rise 2 fall 3 > server app6 app6.vpn.fedoraproject.org:80 backup check inter 35s > rise 2 fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 20s rise 2 > fall 3 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 20s rise 2 fall 3 > option httpchk GET /updates/nagios > > @@ -136,6 +143,7 @@ listen freemedia 0.0.0.0:10011 > server app4 app4.fedora.phx.redhat.com:80 check inter 5s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 backup check inter 15s > rise 2 fall 3 > server app6 app6.vpn.fedoraproject.org:80 backup check inter 15s > rise 2 fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 5s rise 2 > fall 3 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 5s rise 2 fall 3 > option httpchk GET /freemedia/FreeMedia-form.html > > @@ -147,6 +155,7 @@ listen community 0.0.0.0:10012 > server app4 app4.fedora.phx.redhat.com:80 check inter 10s rise 2 > fall 3 > server app5 app5.vpn.fedoraproject.org:80 backup check inter 15s > rise 2 fall 3 > server app6 app6.vpn.fedoraproject.org:80 backup check inter 15s > rise 2 fall 3 > + server app7 app7.fedora.phx.redhat.com:80 check inter 10s rise 2 > fall 3 > server bapp1 bapp1.fedora.phx.redhat.com:80 backup check inter > 5s rise 2 fall 3 > option httpchk GET > /community/apps/fedoracommunity.overviewresource

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure September 2009