infrastructure July 2009

infrastructure@lists.fedoraproject.org

42 participants
66 discussions

New SOP: Non-human accounts
by Ricky Zhou 17 Jul '09

17 Jul '09

Hey, just a heads up, Toshio and I were discussing this on IRC, so we started a non-human accounts SOP at https://fedoraproject.org/wiki/Non-human_Accounts_Infrastructure_SOP It's still a draft at this point, but feel free to add instructions and policies for any account types we missed. Thanks, Ricky

1 0

Add patch to global.pp
by Toshio Kuratomi 17 Jul '09

17 Jul '09

ricky and I were considering adding patch to global.pp and dennis brought up that it might be a command used to do malicious stuff. So what do you guys think? Pros: patch makes some things much easier to do. Want to cherrypick a change as a hotfix? Many times patch is needed to apply the diff. Want to replicate some changes from server1 to servers 2, 3, and 4? diff on server1, patch on the others. Need to review a change that someone else has done and then apply it? Read the diff they give you and apply it rather than grabbing the whole file, doing the diff yourself, and then applying it. Cons: patch is a commonly used utility that is often used to edit files. So the principle of not installing things that aren't needed makes it one more tool that an attacker won't have if they get remote execution on a box they shouldn't. However, there's many other things that an attacker can do if they gain remote execution. Rather than retrieving a diff and applying that to a file, the attacker can just retrieve a file and then replace the existing one; we have wget, curl, and scp installed. ed, sed, perl, python, and other text processing tools are available. I'm thinking if the attacker can gain the ability to execute a remote command and they have permission to touch files that are going to cause us harm, lack of patch isn't going to save us. Other: * patch doesn't have any deps that aren't already installed on one of our boxes. What's the consensus here? -Toshio

5 6

Relicensing Part II
by Toshio Kuratomi 16 Jul '09

16 Jul '09

Alright! So the last two weeks there wasn't much comment on: https://fedorahosted.org/fedora-infrastructure/ticket/1524 https://fedoraproject.org/wiki/Infrastructure_Licensing but I think people were either sleeping or didn't entirely understand what the AGPL's requirements mean for us as this week we filled the whole meeting with discussion[1]_. We arrived at a few conclusions about options we did not want to explore but got into a few questions that need answers from legal before we can continue. Please clarify the questions or add new ones if you can think of other things that we need to know from legal. Once that's done or tomorrow (whichever comes first) I'll make sure that spot gets the list so we can get some input and better consider our options. Questions follow: == What we decided == * Continue to deploy as rpms to production and as the basis of staging. * In production, hotfixes need to have tickets in trac. Those tickets may be required to contain patches applied to the server if we determine that's the best course under legal. - If that's not the best course, hotfix tickets still need to contain an indication of what the hotfix does but this could be "I reverted commit 12345" or "I changed three files to import simplejson instead of json (python-2.4 compatibility)" * In staging, we want to deploy with a base rpm and may add patches and local changes on top of that to test things. When we get to the point where we are satisfied, this needs to be turned into an rpm and be deployed to production/installed in the staging env. * In publictest, we want people to be able to deploy from SCM, make local changes, etc. publictest are pure development machines. == Explain the linking requirements == How the running app leads people to the source for the app is causing the most concerns. Here's a list of questions. There's a lot because we don't have a feel for what's allowed and not allowed yet. Where relevant, assume that the running applications have rpms/srpms present on infrastructure.fedoraproject.org, an upstream trac/scm instance on fedorahosted.org, and that we are running with some number of hotfixes to the live application. * Do we need to link to the source from every page of the app? * What are legal means of giving people access to the corresponding source? + Source repository at no particular version (assuming all of our patches are applied to trunk -- and trunk might contain other changes as well, including full or partial reversions of those changes in a later revision) + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) + Pointing exactly to source repository branch or tag of the exact version we're running + Home page of the project (example: http://fedorahosted.org/fas) + Just a page specifically linking to the sources and all of the patches we've applied + links to base srpm and page listing patches + links to base srpm and tickets in trac that have patches attached + links to base srpm and tickets in trac that point to commits in SCM that are applied against different versions (HEAD vs the last release, for instance) + A page linking to the sources and a page linking to any hotfixes we've applied to any of our apps (ie, a query in infrastructure's trac that gets all hotfixes for all of our apps). + I'm assuming these to be fine: tarball, srpm that matches what's running, actual links to base tarball and to all of the patches * Do config changes count as code changes if the config file is marked as being AGPL? - If yes, what do we have to do to make config files not be licensed under AGPL? (We want to protect passwords, for instance). == Related to Other Apps == Our original impetus for relicensing is so we can freely share code with fedoracommunity. The cost of maintaining AGPL compliance with other apps needs to be weighed against the cost of reinventing code in fedoracommunity (or waiting for fedoracommunity developers to relicense their code for use elsewhere *cough CSRF middleware cough* :-) ). * Is it really "absolutely critical" that fedoracommunity be AGPL? * Can we get a clarification of what the consequences would be if fedora community stays AGPL but our apps stay as they are (GPLv2)? == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """ Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. """ * Is the preamble legally binding/part of the AGPL or should we ignore anything there? * admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself? * Can we be just as liberal with what's running on the publictest machines as we are with staging? .. _[1]: Meeting Minutes http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2… -Toshio

2 2

Re: Cron <root@puppet1> run-parts /etc/cron.hourly
by Stephen John Smoogen 16 Jul '09

16 Jul '09

This script was stuck on the fact that hosted1 went down as it was getting stuff this morning. So it was stopping others from completing. Killed the git's and ten ran by hand to finish. On Thu, Jul 16, 2009 at 3:52 PM, Cron Daemon<root(a)fedoraproject.org> wrote: > /etc/cron.hourly/syncStatic.sh: > > /etc/cron.hourly/syncStatic.sh: line 23: 31157 Terminated /usr/bin/git clone git://git.fedorahosted.org/git/fedora-web.git > /dev/null 2>&1 > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning

1 0

trac-git-plugin updated on hosted1/2
by Jesse Keating 16 Jul '09

16 Jul '09

This is a new upstream snapshot that fixes some of the ongoing issues we've had with the git plugin. Some were already patched from a different upstream, but I've had to throw those changes out in favor of the actual upstream changes. I tested it a bit on hosted2 and couldn't find any problems, but keep your eye open for any tickets related to git plugin in hosted. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

1 0

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

16 Jul '09

20:00 < mmcgrath> #startmeeting 20:00 < zodbot> Meeting started Thu Jul 16 20:00:11 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00 < ricky> (switch it) 20:00 < mmcgrath> #topic Who's here? 20:00 -!- zodbot changed the topic of #fedora-meeting to: Who's here? 20:00 * ricky 20:01 * nirik is here in the cheap seats in the back. 20:01 * sijis is here. 20:01 * dgilmore is here 20:01 * nb 20:01 * dgilmore pulls nirik out of teh cheap seats 20:01 < mmcgrath> K, lets get started with the tickets 20:01 < mmcgrath> #topic Infrastructure -- Tickets 20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets 20:01 -!- trgeier [n=tgeier(a)c-67-175-200-175.hsd1.il.comcast.net] has joined #fedora-meeting 20:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assi… 20:02 < zodbot> mmcgrath: http://tinyurl.com/47e37y 20:02 < mmcgrath> Ok, so the only one there is on abadger1999 20:02 < mmcgrath> .ticket 1503 20:02 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503 20:02 < mmcgrath> abadger1999: around? 20:02 < smooge> meeting 20:02 < smooge> here 20:02 < abadger1999> Yep. 20:02 * f13 20:03 < davivercillo> **davivercillo is here 20:03 < abadger1999> phew. So I've been busy and haven't done on anything again. I'll take this off the meeting for now. 20:03 < abadger1999> I'll go ahead with relicensing python-fedora first. 20:03 < abadger1999> Then I think we'll do FAS or pkgdb. 20:04 * ianweller is here 20:04 < mmcgrath> abadger1999: ok 20:04 < smooge> abadger1999, do we have a list of apps we write? 20:04 < abadger1999> After we see that it seems prettystraightforward to do that we can go ahead with everything else. 20:04 < abadger1999> smooge: Unfortunately no -- I go off of memory/what's in puppet/what's running on the app servers. 20:05 < smooge> abadger1999, and do you have an idea on how we will publish local changes to meet AGPL needs. 20:05 < jeff_hann> hello all 20:05 < ricky> You can get a decent list in appRhel.pp 20:05 < ricky> But not totally complete either. 20:05 < davivercillo> Hi everybody, I'm new here ! I'm from Brazil and I would like to help you with something... try at lest... 20:05 < abadger1999> smooge: That's a good point. So I made several proposals in the wiki page. 20:05 < smooge> ricky, ok thanks.. 20:05 * johe here, late but here 20:05 < abadger1999> davivercillo: Welcome! 20:05 < davivercillo> abadger1999: thanks ! =D 20:05 < ricky> jeff_hann, davivercillo: Hey, welcome! 20:05 < abadger1999> smooge: We can do several things... 20:06 < heffer> i'm here too :) 20:06 < abadger1999> 1) Not hotfix. Everything has to be released as a tarball which we can link to. 20:06 < abadger1999> Pro: simple. Con: limiting 20:06 -!- Southern_Gentlem [n=notfred@fedora/Southern-Gentleman] has quit Remote closed the connection 20:06 < f13> 'released as a tarball'? 20:07 < abadger1999> 2) thanks to our new policy, hotfixes have tickets. 20:07 < abadger1999> f13: Well.... I suppose we can point people to a revision/branch in revision control... But it needs to be the source that we're running on the server. 20:07 -!- kolesovdv [n=kolesovd(a)82.162.141.18] has joined #fedora-meeting 20:07 < abadger1999> f13: So it can't be HEAD. 20:07 < dgilmore> f13: released as a tarball that can be packaged 20:07 < abadger1999> f13: It would have to be a branch dedicated to mirror produciton. 20:08 < f13> sorry I think I'm not quite following the discussion 20:08 < abadger1999> So baack to #2 -- If we have a patch to the hotfixes in the tickets we can probably link to tarball + list of tickets. 20:08 < f13> I thought the no hotfix policy meant that fixes have to be in rpm form in the repo 20:08 < f13> or in puppet 20:08 < f13> but not just modified directly on the box in question 20:09 < abadger1999> f13: This is a different policy.... licensing Guideline. 20:09 < dgilmore> f13: they should be yes 20:09 < abadger1999> f13: We're going to try to switch to the AGPLv3. 20:09 < f13> ah right, nuance there 20:09 < abadger1999> f13: (In part because moksha/ fedora community is) 20:10 < abadger1999> f13: So we have to figure out how to provide the code that we're running on the servers to people at all times. 20:10 < abadger1999> smooge: Other options that aren't so painful? 20:10 < f13> imho we are either running rpm code, or running signed tagged checkouts 20:11 -!- Southern_Gentlem [n=notfred@fedora/Southern-Gentleman] has joined #fedora-meeting 20:11 < smooge> I am wondering if a git archive meets the AGPL need. 20:11 < f13> and thus we can either point to the srpm, or to the source repo we're running a checkout from 20:11 < dgilmore> i think we should always use rpms 20:11 -!- JSchmitt [n=s4504kr@fedora/JSchmitt] has quit Remote closed the connection 20:11 < abadger1999> f13: Early on in infrastructure I proposed that we use checkouts from revision control. 20:11 < f13> releasing tarballs is a bit of a hassle and redundant in today's scm days 20:11 < dgilmore> then they are always available via the infra repo 20:11 -!- Sonar_Guy [n=Who(a)adsl-074-171-066-196.sip.aby.bellsouth.net] has joined #fedora-meeting 20:11 < smooge> I would prefer if we used RPMS so we can do the worlds easiest tripwire (rpm -V) 20:11 < abadger1999> I stil think that's nice... but I don't think mixing rpms and checkouts for a single app is good. 20:12 < f13> if we go with scm checkouts, the process to get it checked out and deployed has to be in puppet 20:12 * ricky agrees with what abadger1999 says 20:12 < abadger1999> We'd either want rpms always (with hotfixes) or checkouts always for any given app. 20:12 < f13> so using a tag is somewhat necessary 20:12 * nirik wonders also if there couldn't be a wiki page or something noting why something is in infrastructure and not just EPEL. ;) 20:12 < smooge> f13 I would like it to be the following: 20:12 < ricky> Luke always manages to get hotfixes into RPMs - maybe we can aim for the same? 20:12 < dgilmore> abadger1999: does the direct link to the source need to be on each web page 20:12 < abadger1999> heh, last time he complained about it though ;-) 20:13 < abadger1999> spot: ping 20:13 < f13> he's at LS 20:13 < f13> in canadia 20:13 < abadger1999> Yeah... 20:13 < smooge> git pull, make changes, git commit, git whatevermakes branches, git push; make rpm; make push-to-repo; puppet do your thing 20:13 < abadger1999> I hear they have internet there ;-) 20:13 < f13> don't even have to do that 20:13 < mdomsch> abadger1999, barely generally... 20:13 < f13> git pull/ chnage/ commit/ tag push ; push --tags 20:14 < f13> puppet config would always be pulling from a given tag in the repo 20:14 < abadger1999> mmcgrath: care to go over why you'd rather have rpms than checkouts again? 20:14 * mmcgrath might be missing something too 20:14 -!- Sonar_Guy [n=Who@fedora/sonarguy] has quit Client Quit 20:14 -!- Sonar_Guy [n=Who@fedora/sonarguy] has joined #fedora-meeting 20:14 < mdomsch> abadger1999, for the same reason we don't install everything into /usr/local? 20:14 < mmcgrath> abadger1999: you're talking about packages right? 20:15 < mmcgrath> like fas? 20:15 < abadger1999> mmcgrath: correct 20:15 < abadger1999> mdomsch: But -- we'd be able to track what's installed because the code is in the scm. either HEAD of a specific branch or a tag. 20:15 < ricky> rpm -V, package dependencies and puppet's facilties for managing packages are nice 20:15 < abadger1999> using puppet to pull it will give us repeatablity. 20:15 < dgilmore> f13: id like to know why you think pulling from scm is better? 20:15 < f13> HEAD is bad 20:15 < skvidal> abadger1999: so now we have 2 pkging systems? 20:15 < mmcgrath> abadger1999: IIRC it's part of our freesoftware policy. And for the same functionality and ease of updates as why Fedora doesn't ship tarballs. 20:16 < ricky> It's also pretty consistent between apps 20:16 < ricky> That's why I like RPMs 20:16 < abadger1999> skvidal: That's one strike against it, sure. 20:16 < skvidal> abadger1999: it's a big strike, imo 20:16 < f13> dgilmore: during development of an app, its moving quite a lot faster than what we can push through creating tarball, building rpm, stuffing tha trpm into a repo somewhere, and then updating the host 20:16 < mmcgrath> abadger1999: what benefit do we get? 20:16 < abadger1999> dgilmore: I'm not sure if we need a direct link on every page. Fedora community I believe links to the fedorahosted web page which links to the source repo. 20:17 < f13> it's far easier and smoother to cherry pick a hot fix into the "live" tag, and push that change set, letting the server pick up the live tag at the next puppet run 20:17 < skvidal> f13: not sure it is easier for anyone else looking to replicate what we do 20:17 < f13> once things get more stable, I definitely agree that rpms are the way to go 20:17 < dgilmore> abadger1999: ok, just curious as to how we meet the requirement thatthe live code is available 20:17 < abadger1999> mmcgrath: It's nice from a developer's standpoint. Gets the most benefits when it's an app that runs at a single location. 20:17 < skvidal> f13: nor does it provide the unity of system 20:17 < f13> skvidal: correct, it is not a perfect solution. There are none 20:17 < smooge> could we ship them as conaries? 20:17 -!- fbijlsma [n=fbijlsma(a)p54B2CF21.dip.t-dialin.net] has joined #fedora-meeting 20:18 < skvidal> I think we'd end up making our very own 'stow' type of system 20:18 < mmcgrath> abadger1999: you can do that in the test environment if you want :) but not in production 20:18 < skvidal> which is just implementing another package system 20:18 < dgilmore> f13: i have to say its maybe easier from a developer standpoint but not from a sysadmin perspective 20:18 < abadger1999> mmcgrath: Allows the developer to not have to deal with making a release (update versions, make tarball, make rpm, deploy) instead they can deploy using (the developer's) normal scm tool. 20:18 < abadger1999> Those are the benefits. 20:18 < f13> dgilmore: from a sysadmin perspective, does it matter much when its entirely driven by puppet? 20:18 < abadger1999> (as I see them). But there's definitely cons. 20:19 < mmcgrath> abadger1999: but once it's in production it's not about them 20:19 < dgilmore> f13: i think so 20:19 < ricky> Even in puppet, it would add a good deal of complexity. 20:19 < f13> mmcgrath: so we're only talking about once in production? 20:19 < f13> but a test instance in development wouldn't have to play by the same rules? 20:19 < mmcgrath> well I'm talking a minimum of once it's in production. 20:19 < mmcgrath> I'd prefer it in staging. 20:19 < mdomsch> agpl doesn't seem to note any difference 20:19 < abadger1999> mmcgrath: Well... that depends... what are you going to want to do to fas or packagedb that you wouldn't toss at a developer and would benefit from an rpm? 20:19 < mmcgrath> on the publictest servers I don't have a preference since so much actual development goes on there. 20:20 < mmcgrath> abadger1999: I'd hope they'd be developing on their workstation, not in production is all. 20:20 < abadger1999> mmcgrath: If we're sticking with rpms over scm, I definitely want rpms in staging. 20:20 < dgilmore> abadger1999: right do same thing across the board 20:20 < mmcgrath> just so I'm clear who's advocating the tarball method, who's advocating rpms and who has no preference? 20:21 < mmcgrath> +1 rpm 20:21 * ricky likes RPMs in staging/production 20:21 < mdomsch> public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version 20:21 < ianweller> +0 20:21 -!- kital [n=Joerg_Si@fedora/kital] has joined #fedora-meeting 20:21 < dgilmore> mmcgrath: i think tarballs should lead to rpms and we should use rpms 20:21 < f13> I'm advocating checkouts from a specific tag in scm at least during the time where changes are rapid. 20:21 < mdomsch> quoth agpl 20:21 < skvidal> +1 rpm 20:21 < f13> whether that time is restricted to pre-staging or not, I don't really care 20:21 < ricky> I think the argument here is that changes should be rapid in testing/development, not in staging/prod 20:21 < smooge> mdomsch, what difference 20:21 * mdomsch uses staging as a test platform 20:22 < mdomsch> rpm + patches from scm 20:22 < ricky> Currently, people are free to go from SCM on publictest machines though 20:22 < mmcgrath> ricky: and typically do 20:22 < smooge> mdomsch, nm.. figured it out 20:22 * ianweller certainly does :) 20:22 < skvidal> mdomsch: what does '+patches' mean? 20:22 < skvidal> mdomsch: do you mean patching the fs itself - or do you mean %patches? 20:23 < mdomsch> skvidal, most often, git-format-patch HEAD^; scp 0001-foobar.patch app1.stg 20:23 < skvidal> mdomsch: nod 20:23 < abadger1999> No preference -- as long as we do it across the board. 20:23 < f13> so, lets propose that once an app goes to staging, all modifications to the app must happen through rpms 20:23 < mdomsch> test; fix; repeat; cut version 20:23 < ianweller> if we go RPMs are we going to require that on pt servers 20:23 < smooge> ok stupid question time.. do changes to configuration files count as patches that need to be publci. 20:23 < f13> since one can easily generate a rpm with patches from git 20:23 < f13> before one does the actual full release 20:23 < mmcgrath> f13: I'd make an exception for emergency patches that require a ticket. 20:23 < skvidal> smooge: I don't think so 20:24 * abadger1999 agrees with mdomsch's use of staging 20:24 < f13> mmcgrath: why make an exception? It takes only a few minutes to generate a patched rpm 20:24 < smooge> skvidal, I just want to get that dealt with before the "Red Hat breaks the AGPL by not publishing their passwords" slashdot fest 20:24 < mdomsch> I don't want to have to respin the RPM just to test a fix on staging 20:24 < skvidal> :) 20:24 < ricky> mmcgrath: What is the policy on testing hotfixes on staging? 20:24 < f13> mdomsch: apparently it isn't about your wants though. 20:24 < ricky> mmcgrath: Like when we were doing FAS testing there, I ran it off of a patched wsgi file somtimes. 20:24 < abadger1999> smooge: I agree with skvidal. configs are managed via puppet 20:25 < f13> mdomsch: if we go strict to just rpms in production, it seems that we want the same thing in staging 20:25 < mmcgrath> it's been my experience that in our environment, requireing a full rebuild of an rpm is a pretty high cost. 20:25 < mmcgrath> not everyone has access to the signing key for one thing. 20:25 < mdomsch> f13, fair enough; but I do want a place to test things before production. Staging has been that so far. if staging isn't going to be that, fine; but something else needs to be. 20:25 < smooge> mdomsch, mmcgrath are we using staging for devepment or for integration.. or both 20:25 -!- thekad [n=kad(a)189.187.93.83] has joined #fedora-meeting 20:25 < mmcgrath> next you'll have to make sure that the next release of the rpm (whatever it is) is at least higher then what yours is. 20:25 < mmcgrath> smooge: a little of both. It's really supposed to be for integration/staging. 20:25 < ricky> staging has been mostly for staging deployments and debugging issues (like FAS 500s) in an environment with close-to-prod data 20:25 < abadger1999> mdomsch: +1 20:26 < mmcgrath> but we don't have a fully functional development environment. 20:26 < smooge> so we need some .devel. boxes for everything? 20:26 < f13> mdomsch: isn't that what publictest instances are for? 20:26 < abadger1999> The policy on staging has been -- okay to break it for a short period... but by the time it is deployed it has to be right. 20:26 < mmcgrath> f13: we don't have enough pt boxes though 20:26 < f13> ah. 20:26 < mmcgrath> many of them are being used for proof of concepts and things. 20:26 < ricky> smooge: devel mostly happens on pt machines or home machines right now 20:26 < abadger1999> So rpm + patch hotfix in staging seems to fit that idea -- but it becomes an rpm by the time it goes to production. 20:26 * smooge starts to look up .pt. boxes to figure out how many are needed 20:26 < mmcgrath> this is one of those instances where we see the flaws in our process, but fixing the process isn't that feasible at the moment because of man hours and hosting space 20:27 < mmcgrath> in theory, for a full environment, we'd need 20:27 < mmcgrath> 1 db server 20:27 < mmcgrath> 2 app servers 20:27 < mmcgrath> 1 proxy server 20:27 < mmcgrath> 1 bapp server 20:27 < mmcgrath> 1 releng box 20:27 < mmcgrath> 1 koji box 20:27 < mdomsch> abadger1999, right. code running in staging doesn't have to be published in a downloadable fashion per agpl as it's not public. 20:27 < mmcgrath> 1 cvs host 20:27 < mmcgrath> so that's a minimum 8 per environment. 20:27 < f13> mdomsch: that's a very strange interpretation of "public" 20:27 < mmcgrath> so if we do a full staging and devel environment that's 16 new boxes 20:27 < mmcgrath> err new hosts. 20:27 < f13> mdomsch: I wonder if they assume "staging" isn't on the internet 20:28 < f13> where ours is 20:28 < mdomsch> "It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. " 20:28 < f13> so if we're going to allow rpms + patches with tickets in production, then rpms + patches (without tickets) should be OK in staging 20:28 < mdomsch> the only "users" of the staging server is us 20:28 < mmcgrath> abadger1999: are we discussing this for legal obligations or just to get our policy figured out? 20:28 < f13> mdomsch: except that the staging servers are accessable by the entire world. 20:28 < jwb> i missed something. how did agpl get involved here? 20:28 < mdomsch> therefore: rpms only in production; rpms + patches in staging. 20:28 < thekad> mmcgrath, can we compress a little? i.e. using a db server for both dev and stg? or is it needed for stg to be on its own? maybe we need less machines 20:29 < f13> jwb: we're talking about re-licensing all of Fedora web apps as agpl 20:29 < mdomsch> f13, they are? 20:29 < mmcgrath> thekad: not reliably 20:29 < f13> jwb: and if we do, there are things we have to consider 20:29 < jwb> ok.... 20:29 < f13> mdomsch: Hrm, I was under the impression that they were. 20:29 < ricky> technmeg: We usually don't want real data on development 20:29 < jwb> why agpl? 20:29 < mmcgrath> abadger1999: if this time next year no one is using fedoracommunity, can we get rid of it and go back to GPL? 20:29 < abadger1999> thekad: staging is supposed to be more secure than devel. So separate db servers. 20:29 < mmcgrath> :) 20:29 < f13> jwb: moksha alreasy is agpl 20:29 < thekad> abadger1999, gotcha 20:29 < mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right? 20:29 < abadger1999> jwb: Largely because moksha/community switched to it. 20:30 < mmcgrath> mdomsch: correct 20:30 < ricky> mdomsch: It isn't, but the staging proxy server is 20:30 < abadger1999> jwb: Here's some additional justification: https://fedoraproject.org/wiki/Infrastructure_Licensing 20:30 < ricky> So it's similar to the prod setup 20:30 < f13> mdomsch: I stand corrected 20:30 -!- j6k [n=j6k(a)195-240-118-19.ip.telfort.nl] has quit 20:30 -!- tibbs [n=tibbs@fedora/tibbs] has quit "Konversation terminated!" 20:31 < mmcgrath> lets take a step back and look at the hot fix we did for mirrormanager last week. 20:31 -!- lxo [n=aoliva(a)150.187.40.27] has joined #fedora-meeting 20:31 < f13> Proposal: Production env is ran by rpms, plus hotfixes with associated tickets with code available. staging is ran from rpms and code patches. 20:31 < mmcgrath> Pretend mirrormanager was AGPL. 20:31 < mmcgrath> abadger1999: would we have not been able to do what we did? 20:31 -!- mizmo [n=duffy(a)66.187.234.199] has quit Read error: 110 (Connection timed out) 20:31 < smooge> f13, lets table that for mmcgrath's stuff then we will discuss proposal 20:31 < abadger1999> mmcgrath: Where's the ticket for that? 20:32 < jwb> abadger1999, thanks 20:32 < abadger1999> Let's look at it and see what we might need to do differently. 20:32 < mmcgrath> .ticket 1524 20:32 < zodbot> mmcgrath: #1524 (Hot Fix - mirrormanager) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1524 20:32 -!- mizmo [n=duffy@nat/redhat/x-4bd73725e762e35e] has joined #fedora-meeting 20:32 < abadger1999> So mirrormanager --- we have a base of an rpm that's available from the repo on http://infrastructure.fedoraproject.org/ 20:32 < mdomsch> include srpm 20:32 < abadger1999> We don't have a patch in the ticket... 20:33 < f13> I think might have had to generate a patch file that does the revert, and attached the patch file to the ticket 20:33 < mdomsch> abadger1999, you have a pointer to the patch 20:33 < f13> (and then have something on MM that points to the ticket queue to look for changes) 20:33 < abadger1999> Right. Partial instructions on how to generate a patch 20:33 < f13> you have a pointer to the patch that was reversed. 20:33 < abadger1999> <nod> 20:33 < f13> now, I don't think anybody would sue us over the minor nit pick 20:34 < mmcgrath> abadger1999: ok, now take this same scenario 20:34 < mdomsch> especially as the patch is public 20:34 < mmcgrath> and lets say that it wasn't a revert. But I had to add a line of code. 20:34 < f13> mmcgrath: you'd generate a patch file, attach it to the ticket 20:34 < ricky> Attaching the patch sounds reasonable to me. 20:34 < mmcgrath> and that alone, would make me legally compliant? 20:34 < f13> (or reference the commit upstream) 20:34 < mdomsch> or commit the patch to MM upstream, with a pointer to the commit 20:35 < f13> mmcgrath: provided that the mirrormanager site has some link to the ticket queue 20:35 < mmcgrath> mdomsch: it dawns on me that I actually have commit access in MM and should have done that ;-) 20:35 < abadger1999> mmcgrath: I'd say that we need a patch, rather than just hte line of code pasted in the ticket. 20:35 < abadger1999> (as the patch tells where in the code to apply it). 20:36 < f13> (side note, using git am would be perfect here, as it also contains info about the author, and has the commit message) 20:36 < abadger1999> We'd also need to point people at the patch. 20:36 < abadger1999> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assi… 20:36 < zodbot> abadger1999: http://tinyurl.com/nglq4f 20:36 < f13> an dhas the shasum of the patch which won't change when applied upstream 20:36 < abadger1999> I thought that would do us... but it's not quite enough :-( 20:36 < abadger1999> We need two keywords per hotfix. 20:37 < abadger1999> Hotfix Appname 20:37 < mmcgrath> So the one bit there that's confusing to me is that mirrormanager would have to link to my hosted ticket some how? 20:37 < f13> mmcgrath: right. MirrorManager would have to have a link to wherever the patch is posted. 20:37 < mmcgrath> holy fuck do I hate AGPL 20:37 < ricky> :-( 20:37 < abadger1999> That way mirrormanager can say infrastructure.fedoraproject.org rpm/srpm + URL that finds just mirrormanager hotfixes. 20:37 < f13> be it the infra ticket queue, the MM ticket queue, or the MM upstream repo 20:37 < davivercillo> :P 20:37 < jwb> mmcgrath, heh. and i thought i was the only one 20:38 < f13> mmcgrath: hate or not, it's actually making us be much better about our patch management. 20:38 < abadger1999> mmcgrath: well, we haven't relicensed anything yet -- now's the time to holler if it's not going to fly. 20:38 -!- fbijlsma [n=fbijlsma(a)p54B2CF21.dip.t-dialin.net] has quit "Leaving" 20:38 < f13> the infrastructure ticket could have been moved to MM"s trac instead 20:38 < mmcgrath> how will the actual implementation of this "linking to bug fixing" work? 20:38 < ricky> f13: That makes them harder for us to track though :-( 20:39 < abadger1999> mdomsch: Re: or commit the patch to MM upstream, with a pointer to the commit 20:39 < mdomsch> MM is the upstream project. It doesn't need a link to all the downstream implementations thereof. 20:39 < abadger1999> mdomsch: I don't think that's enough. 20:39 < thekad> f13, having moved to MM's trac and referencing that trac on f-i's trac would work? 20:39 < f13> ricky: rather, a ticket with the patch could have been filed at MM site. 20:39 < ricky> A central web area where we store current patches to our apps? 20:39 < mmcgrath> is that a legal question? 20:39 < abadger1999> mdomsch: Unless there's a branch dedicated to what we deploy. 20:39 < mmcgrath> mine I mean. 20:39 < mdomsch> The downstream implementations need a link to the code they're running: that can be "pointer to upstream version" plus patches 20:39 < abadger1999> mdomsch: ie, a patch against HEAD might not apply to what we have in production. 20:39 -!- cyberpear [n=james@fedora/cyberpear] has joined #fedora-meeting 20:40 < f13> mmcgrath: probably a legal question 20:40 < mdomsch> abadger1999, rpmfusion uses MM now too. I'd need a separate branch for them too? 20:40 < mmcgrath> Ok 20:40 < mdomsch> repeat for other folks wanting to run MM 20:40 < mmcgrath> so I think here's what we generally agree on. 20:40 < mdomsch> and then give those downstream users commit rights on my repo? 20:40 < mdomsch> uh, no thanks. 20:40 < f13> mmcgrath: I'm looking at the Community site right now, and they just have a footer that points to the hosted site for both Fedora COmmunity and Moksha 20:40 < f13> no other details. 20:40 < f13> mdomsch: why would they have commit access? 20:40 < f13> mdomsch: they can post patches in tickets just like everybody else 20:40 < f13> you can choose to apply them if you want. 20:41 < f13> but that's not a matter for us 20:41 < mdomsch> f13, for abadger's suggested "FI deployment branch" 20:41 < f13> lets forget that MM is done by one of us 20:41 < mmcgrath> so I think we agree, you make a change. Put the patch in fedora-infrastructure trac right? 20:41 < abadger1999> mdomsch: Yep. So I don't think the "pointer to scm commit" is going to work well. 20:41 < mdomsch> mmcgrath, I agree. 20:41 -!- mcepl [n=mcepl(a)49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has left #fedora-meeting [] 20:41 < f13> In /our/ deployment of MM, we need to account for not only the upstream source we use, but also the modifications /we/ make 20:41 < mdomsch> abadger1999, it _can_ work for apps we own; but none other. 20:41 < abadger1999> f13: Note that I talked to spot and specifically brought up this point. 20:41 < mmcgrath> Should we ask legal about the "linking app back to bug tracking" bit? 20:41 < ricky> OK, that sounds fine to me, but it's hard to collect them in a central place to link off of the web app pag. 20:41 < ricky> **page 20:41 < f13> so putting a footer in our deployment of MM that points to not just the upstream source, we can point to say our infra repo where hotfix patches go 20:42 < mdomsch> f13, right 20:42 < abadger1999> f13: So it's possible that community is out of compliance -- or is in compliance as long as we don't hotfix it. Or... 20:42 < ricky> It wouldn't be too hard to setup a directory containing all currently applied live patches 20:42 < mmcgrath> abadger1999: did spot say that was a hard requirement? 20:42 < smooge> ricky, we send them to a src.rpm file? 20:42 < mmcgrath> Does oracle ship any products similar but with a less confusing license? 20:42 < f13> abadger1999: nod. I think it depends on how 'exact' we have to be in offering the source 20:42 < ricky> smooge: Well, I'm just talking about live patches here, not package changes 20:42 < mdomsch> corresponding == exact 20:43 < f13> then Fedora Community will be out of compliance the moment we apply a patch 20:43 < f13> since their pages only point you to fedorahosted, not even the git repo 20:43 -!- jeff_hann [n=arares(a)188.24.37.69] has quit Remote closed the connection 20:43 < f13> you have to go somewhere else once you get to fedora hosted to get to the source code 20:43 < abadger1999> f13: Yeah -- I'm a bit worried about that actually. 20:43 < ricky> OK, so are we basically waiting on legal advice about the linking requirements at this point? 20:43 < f13> well the page tells you how to get it 20:43 < dgilmore> f13: my understanding is that it needs to point at what is live. so i could setup the service exactly as it is in our infra 20:43 < abadger1999> f13: Since even git repo != what we have deployed without additional instructions 20:43 < ricky> Because otherwise, it doesn't seem to be moving forward all that much 20:44 < jwb> make a pi icon that you can click and it just starts spewing the live source 20:44 < abadger1999> Can we eliminate some things? 20:44 < f13> IMHO it should be enough to point to A) upstream source, B) any changes we make to it. 20:44 < jwb> like the agpl? 20:44 < jwb> sorry, i should shut up 20:44 < f13> A) can be the upstream source repo, B) can be a ticket query that shows any active hotfixes 20:44 < abadger1999> jwb: No that's valid. 20:45 < mmcgrath> abadger1999: and you talked to spot specifically about having our applications point directly to trac? 20:45 < jwb> abadger1999, perhaps. but i have little vested in this 20:45 < f13> (and I guess hotfixes will have to remain active if they are only in our rpm and not the upstream source) 20:45 < abadger1999> Proposal #1 -- Don't use AGPL as license. 20:45 < abadger1999> mmcgrath: No -- just whether we have to provide any hotfixes that go onto our servers. 20:45 < f13> I really don't want to get into banning software due to it's free license 20:45 < abadger1999> We didn't talk about how to provide them. 20:45 < jwb> f13, bannign? 20:46 < f13> banning that is 20:46 < abadger1999> f13: Not quite what we're saying 20:46 < f13> sure it is 20:46 < mmcgrath> we ban software based on free licenses already :) 20:46 < abadger1999> f13: This is about how we license our stuff. 20:46 < f13> define "our stuff" 20:46 < abadger1999> f13: Not about third-party stuff. 20:46 < mmcgrath> "Don't use AGPL as license" meaning FAS, mirrormanager, etc. 20:46 < f13> is Fedora Community "our stuff" or third party? 20:46 < ricky> Proposal #2: Central directory containing all patches linked directly on website footers as well as source? 20:46 < abadger1999> If we write it 20:46 < f13> define "we" 20:46 < ricky> (That's if the trac ticket thing doesn't fly) 20:46 < abadger1999> f13: That's actually a problem 20:46 < mmcgrath> f13: he's saying "don't apply AGPL to our software" not "don't use software that is under AGPL" 20:46 < jwb> my point is, looking at the number of questions and hurdles the AGPL would force on you, why in the name of all things Fedora would you want to use that when it causes so much hassle to just get a damn _fix_ onto your services? 20:46 < dgilmore> f13: things written with fedoraproject use intended 20:46 < abadger1999> Fedora Community acts like a third party but wants in-house treatment. 20:47 < abadger1999> We have to shift that one way or another. 20:47 < ricky> Agreed 20:47 < f13> jwb: because the AGPL actually ensures that the source code for the web service you're using is actually available 20:47 < f13> unlike other licenses where you can patch it to hell and back and never be required to provide your changes 20:47 * mmcgrath is actually fine with people making changes to fas and not making that code available as long as they're not distributing it 20:48 < dgilmore> abadger1999: right i view it as third party due to the way that things have been done 20:48 < jwb> f13, i don't think that is really causing Fedora any pain 20:48 < f13> mmcgrath: define "distribution" 20:48 < jwb> whereas using AGPL seems to... 20:48 < abadger1999> jwb: What f13 said and that Community is using it -- which means that sharing code with community is harder. 20:48 < thekad> mmcgrath, +1 20:48 < mdomsch> idea: how about a web page that lists the apps we have in deployment, with links to a) their upstream source; b) the live patch queue; for each app. 20:48 < mmcgrath> f13: don't have to, thats for legal to decide 20:48 < mmcgrath> as well as what day of the week it is ;) 20:48 < f13> Lets look at koji code 20:49 * abadger1999 notes that we're at 46minutes. 20:49 < f13> if somebody, like say oracle, took koji code and started using it and made it available to people, but patched it to add functionality 20:49 -!- cyberpea1 [n=james@fedora/cyberpear] has joined #fedora-meeting 20:49 < ricky> mmcgrath: I would be pretty disappointed if somebody added an good OpenID provider to FAS and started running it without it being free :-) Of course, the chances of that happening are almost nine. 20:49 < f13> we'd want those code changes, particularly as they're a compeditor 20:49 < ricky> **none 20:49 < dgilmore> f13: they could 20:49 -!- sharkcz [n=dan(a)plz1-v-4-17.static.adsl.vol.cz] has quit "Ukončuji" 20:49 < dgilmore> f13: as koji is currently licensed 20:49 < f13> with the way that koji is licensed now, they can do just that, and we have no recourse 20:49 < thekad> yeah, nine are too many 20:49 < smooge> mdomsch, I think in the end we will need to get a legal idea on what is required in the sharing of the code. Do patches count? Or is it the full tree? Do config file changes count if the config file is listed as beign AGPL also. 20:49 < ricky> thekad: :-) 20:50 < dgilmore> f13: they do have to post there code for there customers 20:50 < f13> if it were AGPL, they'd be required to make those changes available. 20:50 < f13> dgilmore: not as a webapp 20:50 < f13> dgilmore: client code ran on the computer yes, but none of the hub code would be required to be made public to their customers 20:50 < abadger1999> dgilmore: They're not distributing hte web ap.. only letting people use it. 20:50 < mmcgrath> abadger1999: so before the cost of not moving our apps to AGPL meant sharing code was very nasty. Now, moving our apps to AGPL means doing practical things might be illegal? 20:50 < dgilmore> f13: right. 20:50 -!- RadicalRo [n=radical(a)193.254.32.144] has quit "Leaving." 20:50 < abadger1999> mmcgrath: Yes. 20:51 < f13> mmcgrath: practical very often gets in the way of opensource licensing 20:51 < mmcgrath> we've got some decisions to make. 20:51 < abadger1999> Although doing practical things has always been illegal. 20:51 < jwb> mmcgrath, burdensome at best. illegal at worst 20:51 -!- cyberpea2 [n=james@fedora/cyberpear] has quit Read error: 110 (Connection timed out) 20:51 < abadger1999> This just hits us in a place where we haven't considered before. 20:51 < f13> the burden really only seems to be on A) making the site footer link to places we put source 20:51 < thekad> I think we should get advice from legal and be done with it, because I don't know about you guys, but IANAL 20:51 < abadger1999> (As an example -- we can't link a pretty common piece of javascript to any app because it's CC licensed which is not compatible with the GPL) 20:51 < f13> the rest of it is really just good practice (posting patches to tickets for hotfixes we make) 20:52 < ricky> abadger1999: Oh :-( that's starting to get pretty annoying then. We can currently do that with GPLv2? 20:52 < abadger1999> ricky: That was an example of something that's illegal now. 20:52 < mmcgrath> abadger1999: "now" as in the AGPL world or now as in like right this second? 20:53 -!- lxo [n=aoliva(a)150.187.40.27] has quit Connection timed out 20:53 < ricky> Oh, OK. 20:53 < abadger1999> But we are used to thinking about different licenses conflicting so we know to check that out no matter how nice it would be to reuse that code. 20:53 < abadger1999> mmcgrath: right this second 20:53 < abadger1999> GPL (any version) not compatible with CC (any variant) 20:53 < f13> abadger1999: define "link to javascript"? 20:54 < mmcgrath> As someone who loves and believes in free software. I _CAN'T IMAGINE_ what some exec things if a mess like this were to be brought up to him. 20:54 < mmcgrath> s/things/thinks/ 20:54 < skvidal> mmcgrath: she would think "I have hired people to do this for me" 20:54 < f13> abadger1999: I could have sworn recently legal said that the act of say importing one python module and using its api didn't mean it's license had to be fully compatible with your software's license. 20:55 < f13> but I could be on crack, so blah. 20:55 < smooge> ok how about this.. can we dual license? 20:55 < abadger1999> smooge: Nooooooo ;-) 20:55 < mdomsch> f13, I'd love to to get more info on that if so... 20:55 < mdomsch> really. 20:55 < abadger1999> Query -- is there anything else to announce/discuss today? 20:56 < abadger1999> I've got nothing else but this. 20:56 < mmcgrath> abadger1999: I don't think so. 20:56 < mmcgrath> we spent literally the whole meeting on this. 20:56 < ricky> Yeah, we're almost at the 1 hour mark on just this 20:56 < abadger1999> Okay -- we have 6 minutes -- shall we list our questions for spot? 20:56 < mmcgrath> which is a strong indication.... we've bitten off quite a bit here. 20:56 < mmcgrath> abadger1999: yeah 20:56 < mmcgrath> #topic Infrastructure -- Questions for legal 20:56 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Questions for legal 20:56 < ricky> 1) Explain the linking requirements 20:56 < mmcgrath> 1) Do we have to link the application to the ticket 20:57 < mmcgrath> 2) Is it really "absolutely critical" that fedoracommunity be AGPL 20:57 * mdomsch has another meeting; thanks all. 20:57 < ricky> mdomsch: See you later 20:57 < mmcgrath> mdomsch: laters 20:57 < f13> 3) Is linking to a list of tickets with patches to the application enough to cover "modifications" 20:57 < smooge> 4) Do config changes count as code changes if the config file is marked as being AGPL 20:57 < ricky> 4) Can we get a clarification of what the consequences would be if fcomm stays AGPL but our apps stay as they are? 20:58 < abadger1999> 4) which of (A) patch (B) full tree or (C) description of what line to change in which file suitable for the requirement 20:58 < smooge> we need one more 4 20:58 < jwb> btw, i'm not against AGPL as a whole. but it seems like lots of work for little gain here 20:58 < davivercillo> people... I'm not feeling fine... I think that I'm getting sick, so I'm gonna home to rest a little bit... see you soon ! have a nice meeting ! 20:58 < davivercillo> bye 20:58 < smooge> bye 20:58 < mmcgrath> jwb: I'm not either, I just want someone else to use it, not me :) 20:58 < ricky> davivercillo: Thanks for stopping by, sorry we didn't get a chance to discuss anything else 20:59 < mmcgrath> Ok, any other questions? 20:59 < abadger1999> davivercillo: Thanks for being here -- we can talk some other day in #fedora-admin 20:59 < mmcgrath> davivercillo: take it easy, see you next week. 20:59 < jwb> abadger1999, dual license might not be so bad 20:59 < abadger1999> 5) Can we link to a whole list of patches for all of our apps or does it need to be the specific patches per app? 20:59 < davivercillo> thanks ! 20:59 < jwb> abadger1999, stuff in staging is $not_agpl. stuff in production is 20:59 < ricky> would that double the requirements we have to hold up? 20:59 < f13> honestly, I think it wouldn't take much work on our part to comply with AGPL 20:59 -!- davivercillo [n=daviverc(a)146.164.31.95] has left #fedora-meeting [] 21:00 < skvidal> f13: I think I agree w/you 21:00 < abadger1999> jwb: Is that question 6) 21:00 < jwb> abadger1999, actually. scratch that 21:00 < ricky> I agree with f13, but there's still the question of how worth it it is for the work 21:00 < f13> provided legal responds well to our questions, such as just linking to tickets. 21:00 < abadger1999> Okay 21:00 < skvidal> ricky: same question could be asked of the GPL - but surely we value what we get from it 21:00 < f13> ricky: I think it's very little work we wouldn't/shouldn't already be doing. 21:00 < jwb> abadger1999, no. because if staging is public, then people could just take the staging code before it hits production and circumvent what you'd want from AGPL 21:00 -!- cyberpear [n=james@fedora/cyberpear] has quit Connection timed out 21:00 < mmcgrath> Ok all we're at time. 21:00 < f13> jwb: I was corrected, staging isn't "public" 21:00 < mmcgrath> anyone have anything else? If not we'll close the meeting 21:00 < abadger1999> 6) Do we need to link to the source from every page of the app? 21:01 < jwb> f13, so hotfixes are the largest concern then? 21:01 < f13> jwb: yes 21:01 < ricky> Staging is web-accessible, ubt we do not necessarily consider it public 21:01 < smooge> close 21:01 < ricky> *8but 21:01 < ricky> **but 21:01 < ricky> So let's make that 7) Does staging count if it's web-accessible 21:01 < jwb> f13, hm. my concerns are lessened but not completely 21:01 < f13> ricky: uh, mmcgrath earlier said it wasn't public. 21:01 < jwb> confused as to how it's not public 21:01 < ricky> https://admin.fedoraproject.org/community/ 21:01 < ricky> That's the type of public I'm talking about 21:01 < abadger1999> I'll write the questions up and pass them to the list for a few hours before making sure that spot sees them. 21:02 < ricky> app1.stg is not publicly accessible, but the proxy server that serves the app is 21:02 < mmcgrath> https://admin.stg.fedoraproject.org/community/ is I think the link you want. 21:02 < abadger1999> jwb: We're trying to divide it on the term "users". 21:02 < f13> <mdomsch> mmcgrath, app1.stg isn't reachable outside FI, right? 21:02 < f13> <mmcgrath> mdomsch: correct 21:02 < mmcgrath> app1.stg isn't 21:02 < jwb> abadger1999, maybe that's a question for legal too 21:02 < ricky> mmcgrath: Oops, thanks 21:02 < mmcgrath> it's through a proxy server 21:02 < f13> er. 21:02 < f13> that's a symantic 21:02 < abadger1999> jwb: Okay.. care to phrase it for me? 21:03 < f13> if the world can get to the site, it's public 21:03 < f13> and AGPL would apply 21:03 < ricky> jwb: My #7 is that exact question 21:03 < jwb> ricky, oh, ok 21:03 < jwb> abadger1999, then whatever ricky said :) 21:03 < mmcgrath> Ok guys we're going over, anyone have anything else? 21:03 < f13> so it looks like staging /would/ have to account for AGPL 21:03 < mmcgrath> abadger1999: you have everything you need to keep you busy? 21:03 < abadger1999> mmcgrath: For weeks and weeks ;-) 21:03 < mmcgrath> f13: sorry my misunderstanding, when you said app1.stg I thought you ment the host, I wasn't thinking about the apps 21:03 < abadger1999> Close it up and lets continue on list 21:04 < mmcgrath> Ok, if no one has anything else I'll close in 10 21:04 < mmcgrath> #endmeeting 21:04 -!- zodbot changed the topic of #fedora-meeting to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule 21:04 < zodbot> Meeting ended Thu Jul 16 21:04:24 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 21:04 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2… 21:04 < jwb> f13, so if staging is public, ew 21:04 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2… 21:04 < mmcgrath> Thanks for coming everyone 21:04 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting.2…

1 0

About me
by Davi Vercillo C. Garcia 16 Jul '09

16 Jul '09

Hi everybody, My name is Davi Vercillo C. Garcia and I'm from Brazil, Rio de Janeiro - RJ. I'm 22 years old and I'm a undergraduate student of Computer Science at Federal University of Rio de Janeiro. I always had interesting on computers and networking, specially GNU/Linux. I've used GNU/Linux at my workstations, desktops, notebooks and servers (off course) since 2001. I started with Slackware and, after it, Debian, Fedora, RHEL, Mandriva, CentOS, etc. Today, I'm using Fedora 11 (Workstation/Desktop) and RHEL5 (Servers). I have some basic/intermediate experience with networking, clustering, system administration and programming (C, Java and Python - my favourite option). At this moment, I'm trainee on sysadmin at a hpc lab at my university, called (NACAD) and I'm monitor of basic programming call for Engineering courses at my university. I would like to help Fedora community grow and keep moving... (Johnny Walker ? =P) PS: My English is not perfect,so please, ignore some mistakes, if it happens. Thanks, -- Davi Vercillo Carneiro Garcia http://www.google.com/profiles/davivercillo Federal University of Rio de Janeiro Department of Computer Science DCC-IM/UFRJ - http://www.dcc.ufrj.br /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \

3 3

Greetings
by Hjörleifur Jónsson 15 Jul '09

15 Jul '09

Hi My name is Hjorleifur I am a 30 year old sysadmin and an avid Linux user from Iceland currently living in Sweden. I have been using Redhat/RHEL/FEDORA since Cartman(6.1) and probably every release since. As well as other Linux Distros, NetBSD,FreeBSD etc. I have experience in running production environment's for financial institutions. Past roles I have held are Software developer (c++,vb,vb.net) on windows ;). DBA Team Leader (Oracle and SQL Server),Infrastructure Team Leader running VMware VI3 clusters, Linux, Windows, Hpux servers and various application servers on thees platforms. And recently I have been experimenting with Opensolaris. The fields/technology's that interest me most are Cloud computing , clusters hpc(though I do have not much experience there) and fail over, load balance and virtualization. I am interested in helping Fedora move forward and if can help that would great. With regards Hjorleifur

2 1

[PATCH] Re-enable rawhide compose.
by Jesse Keating 15 Jul '09

15 Jul '09

Massive rawhide for start of F12 finally finished. Also increase the number of random chars for mktemp and ensure it worked before continuing. --- configs/build/rawhide | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configs/build/rawhide b/configs/build/rawhide index eab9097..4a90bb3 100644 --- a/configs/build/rawhide +++ b/configs/build/rawhide @@ -1,3 +1,3 @@ # rawhide compose MAILTO=jkeating(a)fedoraproject.org -#15 6 * * * masher TMPDIR=`mktemp -d /tmp/rawhide.XXXXX`; cd $TMPDIR; git clone -n git://git.fedorahosted.org/git/releng; cd releng; git checkout -b rawhide-stable; LANG=en_US.UTF-8 ./scripts/buildrawhide $(date "+\%Y\%m\%d"); sudo -u ftpsync /usr/local/bin/update-fullfilelist fedora +15 6 * * * masher TMPDIR=`mktemp -d /tmp/rawhide.XXXXXX` && cd $TMPDIR; git clone -n git://git.fedorahosted.org/git/releng; cd releng; git checkout -b rawhide-stable; LANG=en_US.UTF-8 ./scripts/buildrawhide $(date "+\%Y\%m\%d"); sudo -u ftpsync /usr/local/bin/update-fullfilelist fedora -- 1.5.5.6

4 10

ASU
by Mike McGrath 14 Jul '09

14 Jul '09

anyone know anyone at ASU? -Mike

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure July 2009