Proposed setup for sigul bridge/server for review
by Jesse Keating
Here is my initial stab at a class for the signing server(s).
There is a bridge that clients communicate with (and I'm thinking
of forcing this through an ssh tunnel through bastion) and that
interacts with koji. There is also the server itself that has
the gpg keys on it and does the signing action. The server
initiates a connection to the bridge, so only the bridge has to
listen for connections.
I think I have this mostly setup right, but I'd like some more eyes
on it before I commit. Thanks!
--
Jes
14 years, 9 months
- 2
- 4
Meeting Log - 2009-07-23
by Ricky Zhou
20:00 < mmcgrath> #startmeeting
20:00 < zodbot> Meeting started Thu Jul 23 20:00:16 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
20:00 < mmcgrath> #topic Infrastructure -- Who's here?
20:00 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Who's here?
20:00 * ricky (oops)
20:00 * dgilmore
20:00 * dgilmore
20:00 * dgilmore
20:00 * LinuxCode
20:01 * johe here
20:01 * nirik is around.
20:01 < mmcgrath> K. lets get started on ticket
20:01 < mmcgrath> s
20:01 < mmcgrath> #topic Infrastructure -- Tickets
20:01 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Tickets
20:01 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=as...
20:01 < zodbot> mmcgrath: http://tinyurl.com/47e37y
20:01 * davivercillo is here
20:01 < mmcgrath> So the first and only meeting item is, again,
20:01 < mmcgrath> .ticket 1503
20:01 < zodbot> mmcgrath: #1503 (Licensing Guidelines for apps we write) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1503
20:01 < onekopaka> hello
20:01 < mmcgrath> last time we talked about the the whole metting
20:01 * onekopaka was here.
20:02 < mmcgrath> this time lets kill it after 10 minutes max.
20:02 < onekopaka> is*
20:02 < mmcgrath> abadger1999: around?
20:02 < dgilmore> mmcgrath: i think we could again
20:02 < smooge> here
20:02 * abadger1999 arrives
20:02 < dgilmore> did we get input on what source we have to make available? and how we have to make it available if we went with AGPL everywhere?
20:02 < mmcgrath> abadger1999: so give us the latest poop
20:02 < smooge> dgilmore, spot is working on it with legal
20:02 < LinuxCode> I assume this is the AGPLv3 issue ?
20:02 < smooge> or I should wait until abadger1999
20:03 * skvidal is here
20:03 < LinuxCode> wasnt somebody supposed to be here ?
20:03 -!- mchua [n=mchua@nat/redhat/x-fd7206a424906029] has joined #fedora-meeting
20:03 < ricky> LinuxCode: They were at OSCON
20:03 < LinuxCode> ohh
20:03 < abadger1999> spot is talking to legal. So I think we don't have much to say here.
20:03 < LinuxCode> the person spot mentioned ?
20:03 < abadger1999> Unless people have new questions since last year
20:03 < mmcgrath> abadger1999: so no progress since last week?
20:03 * LinuxCode hasnt, but sees both sides of the argument
20:04 < dgilmore> abadger1999: right. until we clear up the legal requirements we can do anything
20:04 < abadger1999> mmcgrath: Well, spot has the list of questions now and it has gone from him to legal. But we haven't gotten a writeup yet.
20:04 < abadger1999> So we can make no progress.
20:04 < mmcgrath> k
20:04 < mmcgrath> Is Bradley Kuhn here?
20:04 * mmcgrath notes domsch invited him
20:05 < ricky> I think he was OSCONing, so mdomsch moved it up a week
20:05 < mmcgrath> ah, k
20:05 < abadger1999> I'd like to go ahead with relicensing python-fedora to lgplv2+ since that won't be affected by whatever we decide regarding agpl.
20:05 < mmcgrath> ah. so he did :)
20:05 < mmcgrath> abadger1999: What all are we accomplishing with that?
20:06 < abadger1999> mmcgrath: Right now it's gplv2. LGPLv2+ will make it so more people can use it.
20:06 < abadger1999> for instance, if someone writes code with the apache license, python-fedora will work under the LGPLv2+.
20:06 < abadger1999> also, mdomsch would like it to change.
20:07 < mmcgrath> k
20:07 < mmcgrath> well, if thats all we have on that I'll move on
20:07 < abadger1999> mirrormanager is MIT licensed. But when used with python-fedora, the combined work is GPLv2.
20:07 < skvidal> together - they fight crime!
20:07 < abadger1999> with python-fedora LGPLv2+, mirrormanager remains MIT in practice.
20:07 < onekopaka> hmm.
20:08 < abadger1999> s/inpractice//
20:08 < mmcgrath> skvidal: that's good, I'm pretty sure smolt is committing some....
20:08 < mmcgrath> abadger1999: ok, thanks for that
20:08 < mmcgrath> anyone have anything else on this topic before we move on?
20:08 * LinuxCode shakes head
20:08 < mmcgrath> k
20:09 < mmcgrath> #topic Infrastructure -- Mirrors and 7 years bad luck.
20:09 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Mirrors and 7 years bad luck.
20:09 < LinuxCode> haha
20:09 < smooge> you broke it
20:09 < LinuxCode> its your fault
20:09 < LinuxCode> lol
20:09 < mmcgrath> So, as far as I know the mirrorsr are on the mend.
20:09 < LinuxCode> +1 can confirm that
20:09 < smooge> I believe so.
20:09 -!- Sonar_Gal [n=Andrea@fedora/SonarGal] has quit "Leaving"
20:09 < LinuxCode> had first updates today
20:10 < mmcgrath> jwb just did a push that finished.
20:10 < mmcgrath> so there's a bash update coming out.
20:10 < mmcgrath> we're trying to time how long it takes that update takes to get to our workstations
20:10 < jwb> mmcgrath, i see it on d.f.r.c, but i haven't gotten it via yum yet
20:10 < mmcgrath> so if any of you see a bash update available, please do ping me and let me know.
20:10 < jwb> (and i'm doing yum clean metadata/yum update every little bit)
20:10 * mmcgrath verifies he also doesn't have it
20:11 * LinuxCode cleans up and sees if it has made it to the UK
20:11 < mmcgrath> yeah, no update yet.
20:11 < mmcgrath> So keep an eye on that.
20:11 < mmcgrath> Here's some of the stuff that's been done
20:11 < mmcgrath> 1) we've put limits on the primary mirrors
20:11 < mmcgrath> 2) we've started building our own public mirrors system which, for now, will be very similar to the old mirrors system.
20:11 < mmcgrath> but we control it
20:12 < mmcgrath> 3) we've leaned harder on various groups that we're blockign on to get our i2 mirror back up and our other primary mirror back up
20:12 -!- davivercillo [n=daviverc(a)146.164.31.95] has quit Nick collision from services.
20:12 < mmcgrath> we're supposed to have 3 of them.
20:12 < mmcgrath> But still no root cause, though it sounds like a combination of thigns
20:12 < mmcgrath> err things.
20:13 < mmcgrath> To me the biggest issue isn't that the problem came up, it's that it took so long to fix and our hands were largely tied for it.
20:13 -!- davivercillo [n=daviverc(a)146.164.31.95] has joined #fedora-meeting
20:13 * davivercillo came back...
20:13 < mmcgrath> So we're working hard to build our own mirrors out that we can work on, monitor, etc.
20:13 < Southern_Gentlem> su
20:13 < Southern_Gentlem> su
20:13 < ricky> Password:
20:13 < LinuxCode> yeh, was a bummer that it took that long
20:13 < dgilmore> mmcgrath: how is that going to work?
20:13 < nirik> Southern_Gentlem: sudio? :)
20:14 < Southern_Gentlem> wrong window sorry
20:14 < ricky> dgilmore: It'll just be rsync servers that mount the netapp
20:14 < mmcgrath> dgilmore: for now we've got sync1 and sync2 up (which are RR behind sync.fedoraproject.org) which we're going to dedicate to our tier0 and tier1 mirrors.
20:14 < mmcgrath> They mount the netapp and basically do the same thing download.fedora.redhat.com did
20:14 < mmcgrath> Long term though...
20:14 < ricky> Have we decided to dedicate it, or just have connection slots reserved for tier 0/1?
20:14 < dgilmore> mmcgrath: ok what about from other data centres?
20:14 < dgilmore> RDU and TPA?
20:15 < ricky> rsync's connection limiting allows us to be pretty flexible with how we do that
20:15 < mmcgrath> ricky: right now we're not going to tell others about it and we might explicitly deny access the non tier0/1 mirrors
20:15 < smooge> TPA?
20:15 < LinuxCode> mmcgrath, so, the other mirrors grab from sync1 and sync2 ?
20:15 < mmcgrath> notting: FYI this might interest you.
20:15 < ricky> OK
20:15 < ricky> smooge: Tampa, I think
20:15 < mmcgrath> LinuxCode: only tier0 and 1
20:15 < LinuxCode> k
20:15 < smooge> oh I thought Tampa was gone
20:15 < mmcgrath> dgilmore: so the future of that is going to look like this.
20:15 < ricky> The other mirrors should technically grab from tier 0 or 1
20:15 < mmcgrath> TPA's mirror has been offline since February but it is physically in PHX2 now just not completely hooked up.
20:15 < smooge> ah ok
20:15 < mmcgrath> They're going to get it setup, get the snapmirror working again, then we'll have some servers there that mount that netapp and share.
20:16 < mmcgrath> it'll be similar if not identical to what we have in PHX1.
20:16 < mmcgrath> for me the concern is 1) is the limiting factor bandwidth or disk space.
20:16 < mmcgrath> and if it's bandwidth, we might need additional servers in PHX2 which I understand has a much faster pipe.
20:16 < mmcgrath> That's all regular internet stuff.
20:16 < LinuxCode> mmcgrath, what about failure ?
20:16 < mmcgrath> on the I2 side we're going to get RDU setup
20:16 < ricky> And will we get access to the rsync servers on the non-PHX sites?
20:17 < dgilmore> mmcgrath: so the same thing in RDU?
20:17 < mmcgrath> LinuxCode: well we'll have one in PHX and one in PHX2 so we'll be redundant in that fashion.
20:17 < LinuxCode> k
20:17 < mmcgrath> dgilmore: similar in RDU, though probably not a whole farm of servers.
20:17 < dgilmore> couple of boxes in front of teh netapp?
20:17 < mmcgrath> we'll have proper I2 access there.
20:17 * SmootherFrOgZ is around btw
20:17 < mmcgrath> but one thing I'm trying to focus on there is using ibiblio as another primary mirror.
20:17 -!- mdomsch [n=Matt_Dom(a)24.174.1.212] has joined #fedora-meeting
20:17 < mmcgrath> Or at least work it in to our SOP so it can be pushed to very quickly and easily instead of pulled from.
20:17 < mmcgrath> we see one sign of problems from our primary mirrors and that can be setup and going.
20:17 < mmcgrath> we were lucky this last week.
20:18 < mmcgrath> no ssh vulnerabilities were actually real for example :)
20:18 < mmcgrath> so that's really what it's all going to look like.
20:18 -!- tibbs [n=tibbs@fedora/tibbs] has quit "Konversation terminated!"
20:18 < mmcgrath> smooge has some concerns about IOPS on the disk trays.
20:19 < mmcgrath> and we may have to take a more active role in determining what kind of trays we want in the future.
20:19 < dgilmore> mmcgrath: cool
20:19 < mmcgrath> this one was done between the storage team and netapp and months of their research.
20:19 < dgilmore> mmcgrath: its all sata right?
20:19 < smooge> yes.. the trays and how they are 'set' up were based on if they were FC.
20:19 < dgilmore> how big are the disks?
20:19 < smooge> and now they are 1TB SATAs
20:20 < smooge> the issue is that the SATAs perform at 1/3 the rate FC would
20:20 < dgilmore> so we have one shelf in each location?
20:20 < mmcgrath> smooge: I'd have hopped that months of research would have shown that though.
20:20 < smooge> but the FC would cost 8x more
20:20 < mmcgrath> I think their thoughts were that our FC rates were very underutilized.
20:20 < dgilmore> smooge: right id expect that kind of decrease in performance
20:21 < mmcgrath> So the longer term future on all of this is still in question.
20:21 < LinuxCode> mmcgrath, for the cost, you could make more mirrors
20:21 < smooge> mmcgrath, it could have been but more like 3/5's of capacity
20:21 < mmcgrath> and I'm pretty sure our problems, caused kernel.org's problems last week as well.
20:21 < LinuxCode> and maybe raid6+0 them
20:21 < mmcgrath> and his' machines are f'ing crazy fast.
20:21 < LinuxCode> ehh raid5+0
20:21 < LinuxCode> raid6 be slow
20:21 < smooge> LinuxCode, the issue comes down to the number of spindles either way
20:22 < LinuxCode> hmm
20:22 < smooge> and the bandwidth of the controllers
20:22 < mmcgrath> LinuxCode: raid6 and raid5 with lots of disks have nearly identical read performance.
20:22 < LinuxCode> true that mmcgrath
20:22 < mmcgrath> But still, no ETA on any of that.
20:22 < LinuxCode> even with stripping applied too ?
20:22 < smooge> anyway.. it is what it is or whats done is done or some other saying
20:22 < LinuxCode> smooge, hehe
20:22 < mmcgrath> I have a meeting with Eric (my primary RH contact) to find out about funding for new servers and what not for all of this.
20:23 < mmcgrath> and the scary part is we had these issues with just 1T of storage.
20:23 < mmcgrath> these trays were purchased so we could have closer to 8T of storage to use.
20:23 < LinuxCode> hmmm
20:23 < mmcgrath> If we find the trays can't handle it.... then I don't know what's going to happen but I know the storage team won't be happy.
20:23 < mmcgrath> So anyone have any additional questions on any of this?
20:23 < LinuxCode> are these san trays ?
20:24 < smooge> netapp
20:24 < LinuxCode> k
20:24 < mmcgrath> K, so that's that.
20:25 < mmcgrath> #topic Infrastructure -- Oddities and messes
20:25 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Oddities and messes
20:25 -!- sdziallas_ [n=sebastia(a)p5B045F68.dip.t-dialin.net] has joined #fedora-meeting
20:25 < mmcgrath> So have things seemed more fluxy then normal to anyone else or is it just me?
20:25 < mmcgrath> We've largely corrected the ProxyPass vs RewriteRule [P]
20:25 < mmcgrath> thing
20:25 -!- sdziallas [n=sebastia@fedora/sdziallas] has quit Nick collision from services.
20:25 -!- sdziallas_ is now known as sdziallas
20:25 < mmcgrath> but I still feel there's lots of little outstanding bugs that have crept in over the last several weeks that we're still figuring out.
20:25 < mmcgrath> of particular concern to me at the moment is smolt.
20:26 < mmcgrath> but there were other things like the openvpn issue ricky discovered yesterday.
20:26 < dgilmore> it seems like nagios has been having moments
20:26 < dgilmore> where we get alot of alerts
20:26 < ricky> Are we sure that the smolt changes were necessarily from the merge?
20:26 < ricky> smolt was one of the ones whose proxy config was complex enough that I didn't touch it much
20:26 -!- Pikachu_2014 [n=Pikachu_(a)85-169-128-251.rev.numericable.fr] has joined #fedora-meeting
20:27 < mmcgrath> ricky: I actually think the smolt issues were discovered not because of the change but because of a cache change you made.
20:27 < ricky> Ahhh, yeah.
20:27 < mmcgrath> I think nagios had been checking a cached page the whole time so even when smolt went down, nagios just didn't notice.
20:27 < LinuxCode> hehe
20:27 < mmcgrath> or at least didn't notice it unless things went horribly bad.
20:27 < mmcgrath> I'd like to have more people looking at it though
20:27 -!- sijis [n=sijis(a)adsl-75-49-223-86.dsl.emhril.sbcglobal.net] has joined #fedora-meeting
20:28 < mmcgrath> onekopaka has been doing some basic hits from the outside.
20:28 < mmcgrath> basically a "time smoltSendProfile -a"
20:28 < onekopaka> mmcgrath: I have.
20:28 < mmcgrath> and the times were all over the place.
20:28 * sijis is sorry for being late.
20:28 < mmcgrath> including about a 5% failure rate.
20:28 < mmcgrath> Of course I hate to be spending time on something that is clearly not in Fedora's critical path, but we've got to knock it out
20:28 -!- thekad [n=kad(a)189.187.137.181] has joined #fedora-meeting
20:28 < LinuxCode> does smolt provide some debugging output thats useful ?
20:29 < mmcgrath> LinuxCode: it's almost entirely blocking on db.
20:29 < LinuxCode> as to network, dns issues
20:29 < mmcgrath> we even have the queries.
20:29 < LinuxCode> hmm
20:29 < LinuxCode> weird
20:29 < davivercillo> mmcgrath: I can try to help you with this ...
20:29 < ricky> Do we know which queries are causing the locked queries though?
20:30 < mmcgrath> ricky: not really
20:30 < mmcgrath> I still don't even understand why they're being locked
20:30 < mmcgrath> and why does locktime not mean anything?
20:30 < LinuxCode> is there a conn limit set up on the db end for the smolt unit ?
20:30 < ricky> locktime?
20:30 < mmcgrath> LinuxCode: it's not that weird, it's got 80 million rows :)
20:30 < mmcgrath> ricky: yeah in the slow queries log
20:30 < ricky> The time column on processlist is the that the query has been in its current state
20:30 < abadger1999> Do we have any reproducers? I can try with postgres but we'd need to know whether we've gained anyhting or not.
20:30 < ricky> Hm, I remember looking the slow queries one up
20:31 < mmcgrath> davivercillo: how's your db experience?
20:32 < LinuxCode> mmcgrath, so queries get processed or a connection passes to the db server, but it doesnt handle it, correct ?
20:32 < davivercillo> mmcgrath: not so much yet... but I can learn fast ! :D
20:32 < mmcgrath> LinuxCode: the queries take several seconds to complete
20:32 < mmcgrath> for example
20:32 -!- mcepl [n=mcepl(a)49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has left #fedora-meeting []
20:32 < LinuxCode> hmmm
20:33 < mmcgrath> I don't even have an example at the moment.
20:33 < LinuxCode> np
20:33 < ricky> Ah, lock_time is the time the query spent waiting for a lock
20:33 < mmcgrath> but they're there.
20:33 < ricky> So for the queries in the lock state with high times in processlist, they should have high lock_time if they're in the slow query log
20:33 < mmcgrath> ricky: so if a query is running on a table for 326 seconds... does that mean it was locked that whole time?
20:33 < ricky> Depends on where the 326 number came from
20:34 < mmcgrath> ricky: in the slow queries log, do you see any queries that have a Lock_time above 0?
20:34 < mmcgrath> oh, there actually are some.
20:35 < mmcgrath> only 56 of 2856 though
20:35 < mmcgrath> So anyway
20:35 < mmcgrath> davivercillo: how's your python?
20:35 < LinuxCode> could it be that smolt sends some weird query, that then causes it to hickup ?
20:35 < mmcgrath> LinuxCode: nope, it's not weird queries :)
20:35 < LinuxCode> just a wild though
20:35 < LinuxCode> t
20:35 < davivercillo> mmcgrath: I think that is nice...
20:35 < mmcgrath> it's just the size of the db
20:35 < LinuxCode> hehe
20:36 < onekopaka> joins + size = slowness
20:36 < mmcgrath> well and that's something else we need to figure out, we've spent so much time optimizing render-stats (which is still pretty killer)
20:36 < LinuxCode> mmcgrath, yeh but if you do something funky + huge db = inefficient
20:36 < mmcgrath> but we haven't looket at optimizing the sending profiles.
20:36 < davivercillo> mmcgrath: I did that script checkMirror.py, do u remember ?
20:36 < mmcgrath> huge db == inefficient :)
20:36 < davivercillo> :P
20:36 < LinuxCode> mmcgrath, haha of course
20:36 < mmcgrath> davivercillo: yeah but that was smaller :)
20:36 < LinuxCode> but there is no way around that
20:36 < mmcgrath> davivercillo: ping me after the meeting, we'll go over some stuff.
20:37 < davivercillo> mmcgrath: yep, I know... :P
20:37 < mmcgrath> if any of you are curious and want to poke around
20:37 < davivercillo> mmcgrath: Ok !
20:37 < mmcgrath> you can get a sample db to download and import here:
20:37 < mmcgrath> https://fedorahosted.org/releases/s/m/smolt/smolt.gz
20:37 < mmcgrath> It's about 500M
20:37 < thekad> mmcgrath, yes! thanks!
20:37 * thekad has been waiting to load something like that
20:37 < mmcgrath> Ok, I don't want to take up the rest of th emeeting with smolt stuff so we'll move on.
20:38 < mmcgrath> #topic Infrastructure -- Open Floor
20:38 -!- zodbot changed the topic of #fedora-meeting to: Infrastructure -- Open Floor
20:38 < mmcgrath> Anyone have anything they'd like to discuss?
20:39 < dgilmore> importing meat pies from australia?
20:39 * mdomsch invited Bradley Kuhn to a future meeting to talk about agplv3
20:39 < thekad> mmcgrath, actually, about this smolt stuff, is there a ticket where we can track?
20:39 < mdomsch> we may have it cleared up by then, maybe not.
20:39 < SmootherFrOgZ> dgilmore: :)
20:39 < dgilmore> mdomsch: have at it
20:39 < mmcgrath> thekad: not actually sure. I'll create one if not.
20:39 < LinuxCode> mmcgrath, Id just like to know when you guys have time to help me do that new mapping of infra
20:39 < LinuxCode> it will probably take a few weeks, if not longer
20:39 < mmcgrath> mdomsch: yeah we were talking about it a bit earlier. I saw your first email but not th esecond email :)
20:40 < smooge> dgilmore, are they mutton meat pies?
20:40 < thekad> I've seen this topic pop up several times, but we start from scratch every time, I think we could benefit there :)
20:40 < dgilmore> smooge: no
20:40 < LinuxCode> if that ticket still even exists
20:40 < smooge> dgilmore, then no thankyou
20:40 < dgilmore> smooge: four'n'twenty pies
20:40 < dgilmore> smooge: best ones ever
20:40 -!- jayhex [n=jayhex(a)122.53.116.156] has joined #fedora-meeting
20:40 < mmcgrath> Ok, anyone have anything else they'd like to discuss?
20:41 * thekad is being dragged away by his 2yo daughter bi5
20:41 < smooge> dgilmore, as long as they don't have raisins and such in them
20:41 < LinuxCode> mmcgrath, see above
20:41 < LinuxCode> to replace this
20:41 < LinuxCode> https://fedoraproject.org/wiki/Infrastructure/Architecture
20:41 < LinuxCode> was in the talk some time ago
20:41 < mmcgrath> LinuxCode: yeah you were going to add docs to git.fedorapeople.org
20:41 < LinuxCode> there was a ticket, but not sure what happened to it
20:41 < mmcgrath> err git.fedorahosted.org/git/fedora-infrastructure.git :)
20:41 < LinuxCode> k
20:42 < LinuxCode> well I will have time now, but need you guys to explain to me exactly whats where
20:42 < mmcgrath> .ticket 1084
20:42 < zodbot> mmcgrath: #1084 (Fix proxy -> app docs) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1084
20:42 < LinuxCode> so I just ask some stupid questions now and then
20:42 < mmcgrath> LinuxCode: Do you have some time to work on it this afternoon?
20:42 < LinuxCode> its kinda late now
20:42 < LinuxCode> ;-p
20:42 < LinuxCode> 21:42
20:43 < mmcgrath> LinuxCode: yeah I'll add some stuff.
20:43 < LinuxCode> k
20:43 < mmcgrath> for those docs I think it's less important on where stuff physically is, and more important on how the pieces fit together.
20:43 < LinuxCode> a list be ok
20:43 < LinuxCode> that give me a starting point
20:43 < mmcgrath> that's really what people are talking about when they do architecture
20:43 < LinuxCode> yah of course
20:43 < LinuxCode> to give people a better idea
20:43 < mmcgrath> LinuxCode: <nod> i'll update that ticket shortly actually
20:43 < LinuxCode> excellent
20:43 < smooge> I have an open floor question
20:43 < mmcgrath> I think starting on the Proxy servers first would be a good way to go.
20:43 < mmcgrath> smooge: have at it
20:44 < LinuxCode> def
20:44 < LinuxCode> we talk another time
20:44 < smooge> Someone was working on a inventory system earlier. Does anyone remember who it was , where it was, etc?
20:44 < smooge> I can't find any reference versus IRC :)
20:44 < LinuxCode> inventory....
20:44 < LinuxCode> kinda rings a bell....
20:44 * nirik thinks it was ocsinventory. Not sure who was doing it tho.
20:45 < mmcgrath> smooge: I think it was boodle
20:45 < sijis> i saw something on the list about ipplan. is that it?
20:45 < mmcgrath> .any boodle
20:45 < zodbot> mmcgrath: I have not seen boodle.
20:45 < smooge> boodle is a tool?
20:45 < smooge> boodle is a person?
20:45 < mmcgrath> mdomsch: you work with boodle right?
20:45 -!- sharkcz [n=dan(a)plz1-v-4-17.static.adsl.vol.cz] has quit "Ukončuji"
20:45 < mmcgrath> boodle is a dude(le)
20:45 < ricky> Heh
20:45 < LinuxCode> http://publictest10.fedoraproject.org/ocsreports/
20:45 < LinuxCode> thats in my ticket
20:45 < LinuxCode> not sure if that helps
20:45 < mdomsch> mmcgrath, yes
20:45 < LinuxCode> the machine aint up
20:45 < smooge> LinuxCode, what ticket
20:46 < mmcgrath> mdomsch: he was working on the inventory stuff
20:46 < LinuxCode> https://fedorahosted.org/fedora-infrastructure/ticket/1084
20:46 < LinuxCode> scroll to bottom
20:46 < LinuxCode> 03/16/09 20:36:44 changed by boodle
20:46 < mdomsch> mmcgrath, I remember; I haven't seen anything on that in a bit
20:46 < mdomsch> ha
20:46 < smooge> LinuxCode, thanks.. my browser skills FAILED
20:46 < mdomsch> yeah, since about then
20:46 < LinuxCode> smooge, haha
20:46 < mmcgrath> mdomsch: I just didn't know if he was still working on it or what
20:46 < LinuxCode> ;-D
20:46 < mmcgrath> butI think smooge has an itch to get it going.
20:46 < mmcgrath> and it's probably best to let him scratch it :)
20:46 < mdomsch> smooge, go for it
20:47 < mdomsch> just put a note in that ticket so he knows
20:47 < LinuxCode> that be something useful to me actually
20:47 < thekad> bump the ticket
20:47 < smooge> ok cool. mdomsch can you send me an email address so I can contact him too
20:47 < LinuxCode> to make those updated diagrams
20:47 < ricky> smooge: What was the software you had experience with again?
20:47 < smooge> exactly what he was using
20:47 < mmcgrath> I swear there was an inventory ticket he was working on
20:47 < ricky> Oh
20:47 < ricky> oscinventory? That might have ended... a bit poorly
20:47 < smooge> mmcgrath, probably I have epic fail this week with searching
20:48 < ricky> I remember one of the ones he was trying, I found bad security problems on a quick lookover
20:48 < LinuxCode> ricky, with the app ?
20:48 < mmcgrath> ricky: do you know what happened with pb10?
20:48 < ricky> Yeah, grepping my IRC logs now
20:48 < mmcgrath> err pt10
20:48 * mdomsch has to run; later
20:48 < mmcgrath> mdomsch: laterz
20:48 -!- mdomsch [n=Matt_Dom(a)24.174.1.212] has quit "Leaving"
20:48 < LinuxCode> http://publictest10.fedoraproject.org/glpi/
20:48 < LinuxCode> there is that one too
20:48 < LinuxCode> also kinda rings a bell
20:48 < smooge> yeah.. they tie into one another
20:48 < ricky> I have no idea, it might have just not gotten started on reboot
20:49 < LinuxCode> smooge, kk
20:49 < smooge> ocsng is the tool that polls the boxes
20:49 < smooge> glpi is the perty front end where you can enter data
20:49 < mmcgrath> .ticket 1171
20:49 < zodbot> mmcgrath: #1171 (Requesting a public test box to evaluate GLPI and OCS) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1171
20:49 < mmcgrath> smooge: see that ticket as well
20:49 < thekad> mmcgrath, that's the one
20:49 < ricky> Yeah, OSC was the security hole one
20:50 < smooge> geez I really failed
20:50 < ricky> Like I was able to delete a row from some table without logging on or anything
20:50 < thekad> .ticket 1084
20:50 < zodbot> thekad: #1084 (Fix proxy -> app docs) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/1084
20:50 < smooge> I went looking for GLPI
20:50 < thekad> that's the next one
20:50 < ricky> I didn't look much closer at the security stuff after an initial look at it though.
20:50 < LinuxCode> ricky, did you report that ?
20:50 < nirik> ricky: nasty. ;( It's in fedora, you might note that to the maintainer.
20:50 -!- easter_egg [n=freeman(a)201-75-42-40-ma.cpe.vivax.com.br] has joined #fedora-meeting
20:51 < mmcgrath> well
20:51 < mmcgrath> just the same
20:51 < mmcgrath> smooge: you want to open up an "inventory management" ticket?
20:51 < ricky> mmcgrath: Looks like publictest10 just didn't get started on a reboot - should I start it again?
20:51 -!- kolesovdv [n=kolesovd(a)82.162.141.18] has quit Remote closed the connection
20:51 < smooge> mmcgrath, put that down as an action please
20:51 < mmcgrath> ricky: sure, smooge might be able to use it
20:51 < smooge> I will start on it right away
20:51 < mmcgrath> #action Smooge will create a ticket and get started on inventory management
20:52 < smooge> ricky, we will see if the updated version has the bug and then work it out
20:52 * davivercillo need to go home now ! See you later !
20:52 < ricky> OK. I just remember getting a really bad impression from that and the other code, but hopefully some of this is fixed.
20:52 < davivercillo> Good Night !
20:52 < mmcgrath> davivercillo: ping me when you get time later
20:52 < mmcgrath> or tomorrow :)
20:52 < mmcgrath> or whenever
20:53 < davivercillo> mmcgrath: for sure
20:53 < davivercillo> bye
20:53 -!- davivercillo [n=daviverc(a)146.164.31.95] has left #fedora-meeting []
20:53 < mmcgrath> So we've only got 7 minutes left, anyone have anything else to discuss?
20:54 * ricky wonders if sijis wanted to say anything about blogs
20:54 < mmcgrath> sijis: anything?
20:54 < mmcgrath> abadger1999: or anything about zikula?
20:54 < sijis> yeah, as you saw, the authentication part on the blogs is working.
20:54 < ricky> Thanks for working on that plugin
20:54 < abadger1999> mmcgrath: When should we get docs people started in staging?
20:55 < sijis> we are able to also verify that minimum gropu memberships are met before allowing a login
20:55 < abadger1999> I think they have all of the packages in review.
20:55 -!- kolesovdv [n=kolesovd(a)82.162.141.18] has joined #fedora-meeting
20:55 < abadger1999> But htey're not all reviewed yet/some are blocking on licensing.
20:55 -!- danielbruno [n=danielbr(a)thor.argo.com.br] has quit Remote closed the connection
20:55 < thekad> sijis, which groups are those? cla_done?
20:55 < sijis> a person has to be in cla_done an another other non-cla group
20:55 < ricky> Is http://publictest15.fedoraproject.org/cms/ really as far as they're going to take the test instance? Not trying to complain, but I'm just used to seeing slightly more complete setups in testing first
20:55 < mmcgrath> abadger1999: how long till the licensing is resolved do you think?
20:56 < sijis> there are few minor things to work out.. but it should be ready to be tested.
20:57 < ke4qqq> ricky - we need to spend more time on pt15 - we largely haven't done anything with it in months. specifically we need to get all of the pieces that we have packaged, and beat on it
20:57 < abadger1999> mmcgrath: I encountered problems in both packages I reviewed. One has been resolved (I just need to do a final review) the other is waiting upstream. docs has contacted several people related to that
20:57 < ricky> Ah, cool, so maybe not quite staging-ready yet
20:57 < ke4qqq> ricky: hopefully not far off
20:57 < abadger1999> ianweller also encountered some major problems in one that he reviewed -- but I think it might have been optional.
20:57 < ricky> Cool, thanks
20:58 < abadger1999> ke4qqq and sparks would know for sure.
20:59 < ke4qqq> we still have three (and maybe four) though that includes the one thats waiting abadger1999's final approval, that are blocked on licensing probs
20:59 < mmcgrath> abadger1999: hmm
20:59 < mmcgrath> abadger1999: what are the odds they won't be resolved?
20:59 < abadger1999> ke4qqq: Want to field that? And any contingency if that happens?
20:59 < ke4qqq> mmcgrath: I think we'll workaround - upstream is pretty committed to fixing stuff
21:00 < ke4qqq> there is just a ton of stuff
21:00 < mmcgrath> <nod>
21:00 < mmcgrath> Ok, so we're at the end of the meeting time, anyone have anything else to discuss?
21:00 < jayhex> just want to say hi before we end. Julius Serrano here.
21:00 < mmcgrath> jayhex: hello Julius!
21:00 -!- oget_ [n=oget(a)c-69-137-139-64.hsd1.pa.comcast.net] has joined #fedora-meeting
21:00 -!- oget_ is now known as oget_zzz
21:00 < mmcgrath> thanks for saying hey.
21:00 < thekad> welcome jayhex
21:00 < ricky> jayhex: Hey, welcome!
21:01 < sijis> jayhex: welcome.
21:01 -!- danielbruno [n=danielbr(a)thor.argo.com.br] has joined #fedora-meeting
21:01 < mmcgrath> Ok, if no one has anything else, we'll close in 30
21:01 -!- biertie [n=bert(a)174.57-247-81.adsl-dyn.isp.belgacom.be] has joined #fedora-meeting
21:02 < mmcgrath> #endmeeting
21:02 -!- 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:02 < zodbot> Meeting ended Thu Jul 23 21:02:06 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot .
21:02 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-23/fedora-meeting...
21:02 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-23/fedora-meeting...
21:02 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-23/fedora-meeting...
14 years, 9 months
- 1
- 0
Checking / fixing permissions on hosted git projects
by Todd Zullinger
Hey all,
Every so often we've had problems with uses having permissions
problems in git repos on hosted. This is less of an issue over the
past few months as we backported a patch from upstream git to ensure
that git sets the permissions properly as well as setting the right
permissions with the gitsetup.sh script when creating new repos¹.
¹ Except for the minor issue that it issues a mildly overly broad
'chmod -R g+w .' -- which makes any files in the objects tree group
writable even though they are not intended nor required to be
writable by anyone. Objects are read only for git.
To help ensure that we don't end up with any new permissions problems
I whipped up a git-check-perms script which might be useful to run as
a cron job once a daily or even weekly. It should alert us to any new
problems with git or with our setup/import scripts. It can also be
used to correct any problems found, after we've looked into what
caused them, of course. The script is in ~tmz/bin/git-check-perms on
hosted1.
Before the output of this is clean and suitable for a cron job, there
are a few minor things that should be fixed. Mostly this is fixing
files in the objects dir that have unneeded write permissions. There
are also a few config and commit-list files that would get group write
permissions added. Neither of these things cause any real problems,
but they differ from how we'd like to setup and import git projects,
so making them consistent will make things simpler all around.
The list of changes the script would make is attached. If anyone has
a moment to check that it looks sane, that would great. The short
list of non-objects dir issues is:
/git/Virtualization_Guide.git/commit-list: Not group writable (should be "0664")
/git/augeas.git/commit-list: Not group writable (should be "0664")
/git/collie.git/commit-list: Not group writable (should be "0664")
/git/comps-extras.git/logs: Not SETGID (should be "02775")
/git/comps-extras.git/logs/refs: Not SETGID (should be "02775")
/git/comps-extras.git/logs/refs/heads: Not SETGID (should be "02775")
/git/docs/install-guide.git/config: Not group writable (should be "0664")
/git/docs/release-notes.git/config: Not group writable (should be "0664")
/git/fastback.git/commit-list: Not group writable (should be "0664")
/git/grubby.git/commit-list: Not group writable (should be "0664")
/git/grubby.git/config: Not group writable (should be "0664")
/git/moksha.git/commit-list: Not group writable (should be "0664")
/git/pam_url.git/config: Not group writable (should be "0664")
/git/piranha.git/commit-list: Not group writable (should be "0664")
/git/simon.git/commit-list: Not group writable (should be "0664")
/git/sssd.git/commit-list: Not group writable (should be "0664")
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Becoming aware of my character defects leads me naturally to the next
step of blaming my parents.
14 years, 9 months
- 2
- 1
Relicensing Part II (redux)
by Toshio Kuratomi
Resending since spot didn't get it the first time.
Okay, at the infrastructure meeting this week we had a long discussion
about using AGPL in infrastructure and we decided we need more
information about what the AGPL requires of us. Here's a run down and
then the questions we had.
== What we decided ==
We arrived at a few conclusions with the amount of knowledge we
currently have:
* Continue to deploy as rpms to production and as the basis of staging.
* In production, hotfixes need to have tickets in trac (this is current
policy). 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 keep passwords private, 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?
* If we can run apps in staging without providing source to those
without shell accounts there, can we also run apps on publictest boxes
without providing source to those without shell accounts there?
.. _[1]: Meeting Minutes
http://meetbot.fedoraproject.org/fedora-meeting/2009-07-16/fedora-meeting...
.. Proposed Guidelines:
https://fedoraproject.org/wiki/Infrastructure_Licensing
-Toshio
14 years, 9 months
- 2
- 3
Introduction
by Julius Serrano
Hi,
I am Julius Serrano and I've been using linux for quite some time now. I
started with red hat 6.0 but I had most of my experiences with RH7.2, RH9.0,
RHEL4 and RHEL5. I am a programmer and a systems and database administrator
by profession. I have skills with Python (which is my language of choice),
PHP and Java, although my Python web framework experience mostly come from
Zope. Programming is my main passion but I also have administration skills.
My sysadmin experience cover NIS, LDAP, NFS, Samba, some Postfix, some Xen
failover clustering, and some DRBD. I also have experience with the
administration of Apache, Nagios, CVS and Subversion. As for being a db
admin, I manage MySQL databases including their replication.
I want to be involved in the Fedora project and I hope to somehow contribute
something, in one way or another, to F12. Right now, I am mostly trying to
familiarize myself on things and the meeting later would probably give me a
good start.
Thank you very much.
Cheers,
Julius Serrano
14 years, 9 months
- 3
- 2
Fedora Community Post-mortem meeting log
by Ricky Zhou
16:30 < mmcgrath> #startmeeting
16:30 < zodbot> Meeting started Tue Jul 21 16:30:32 2009 UTC. The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30 < mmcgrath> abadger1999: ping
16:30 < mmcgrath> rishi: ping
16:30 < mmcgrath> err
16:30 < mmcgrath> ricky: ping
16:30 < mmcgrath> rishi: sorry
16:30 < abadger1999> yep.
16:30 < mmcgrath> lmacken: ping
16:30 < ricky> pong
16:30 < mmcgrath> spot: ping
16:30 < mmcgrath> J5: ping
16:30 -!- tc141516 [i=blewis@fedora/tc1415] has joined #fedora-meeting
16:31 < J5> pong
16:31 -!- Viking-Ice [n=johannbg(a)valhalla.rhi.hi.is] has quit "Ex-Chat"
16:31 -!- nixdude [n=jhp(a)pool-70-109-10-41.atl.dsl-w.verizon.net] has joined #fedora-meeting
16:31 -!- Viking-Ice [n=johannbg(a)valhalla.rhi.hi.is] has joined #fedora-meeting
16:31 * spot is here
16:31 -!- drago01 [n=linux(a)chello062178124130.3.13.univie.teleweb.at] has joined #fedora-meeting
16:31 * nixdude 1s too
16:32 < mmcgrath> I've not seen lmacken today so I'll assume he's not able to make it.
16:32 < mmcgrath> So this meeting's just a quick round up of what happened during the fedora community deployment, trying to shake out some communication issues, and hopefully clear up any misunderstandings.
16:32 < mmcgrath> or missed emails or notifications or anything
16:32 < mmcgrath> We have a hard stop in 30 minutes when the packaging committee meets and I hope it won't go anywhere near that long.
16:33 < mmcgrath> There's two main points of contention that I know of
16:33 < mmcgrath> 1) deployment times/expectations and 2) is the very late in the game license change.
16:33 < mmcgrath> anyone have anything they'd like to add to that?
16:33 < abadger1999> General communication is an issue but could be talked about some other time.
16:33 < mmcgrath> K, so I'll knock 1) out because I think it's more straight forward then 2)
16:33 < mmcgrath> yeah
16:34 < mmcgrath> So around the F10 launch, just a day or so before the launch J5 came to me asking for fedora community to be deployed.
16:34 < smooge> ok here I am
16:34 < ricky> s/10/11 :-)
16:34 < mmcgrath> We didn't know much about it at that time
16:34 < mmcgrath> ricky: this was F10
16:34 < ricky> Oh, wow, my mistake :-)
16:34 -!- neverho0d [n=psv(a)62.68.142.214] has quit Read error: 110 (Connection timed out)
16:34 < mmcgrath> it was in our final freeze and I made it known that it was just not possible to deploy it at that time.
16:34 < mmcgrath> that final 2 week freeze is critical
16:35 < mmcgrath> So flash forward to F11.
16:35 < mmcgrath> We had a few minor issues when deploying to test,
16:35 < mmcgrath> we got it ready in staging.
16:35 < mmcgrath> but at no point in time did I have a date for when this was to go live.
16:35 < mmcgrath> Now, on the F11 release date, lmacken told me that it was to go live that day and that spot said so.
16:35 < mmcgrath> This put me in a horribly ackward position.
16:36 < mmcgrath> spot is very much one of us, but he's also the boss (both my manager and the Fedora Project Engineering lead)
16:36 < spot> So, we definitely had a communication breakdown here.
16:36 -!- stickster is now known as stickster_food
16:36 < spot> In our Fedora Community meetings, I repeatedly asked luke to make sure you knew about our schedule
16:37 < spot> I'm not sure where it fell apart, but we definitely can do better.
16:37 < mmcgrath> So if it was just a communications breakdown (that happens) then there's not much else to discuss on it. We'll just all be more careful next time.
16:37 < mmcgrath> There were also some announcements that went out about it being live before it was actually live
16:37 < spot> Yeah, we had every intent of giving you advance notice.
16:37 -!- shepherd [n=shepherd@unaffiliated/shepherd] has quit Read error: 60 (Operation timed out)
16:37 < mmcgrath> but I don't think those were public
16:38 -!- sm|test-1ox [n=morpheus(a)209.132.186.254] has joined #fedora-meeting
16:38 < spot> mmcgrath: yeah, that was because it was mentioned in the early F11 interviews
16:38 -!- runa_b [n=runab(a)209.132.186.254] has joined #fedora-meeting
16:38 < mmcgrath> <nod>
16:38 < spot> before the instance was live
16:38 < J5> It partly has to do with not being clear on what checkmarks need to be hit to get things deployed. What do you do to get it into staging and then what was needed after things were in staging to say ok it is good to go
16:38 -!- paragn_ [n=paragn(a)209.132.186.254] has joined #fedora-meeting
16:38 -!- shepherd [n=shepherd@unaffiliated/shepherd] has joined #fedora-meeting
16:39 < mmcgrath> so one note I think I'd like to make more clear (not related to fedora community directly) is that maybe we should have a more clear feature process similar to the OS.
16:39 < mmcgrath> our livecycle is very tied to the Fedora releases.
16:39 < J5> agreed
16:39 < abadger1999> J5: Partly but not all -- we would not make a new app go-live date coincide with the release date no matter what.
16:39 < mmcgrath> and I think we're starting to get into a little groove where stuff that gets deployed is related to the Fedora release (start.fedoraproject.org, mirrorlist, etc) all could directly impact users.
16:39 < abadger1999> We could announce it was live on that date but it would have already been deployed on the production instance long before that date.... just the announcement would coincide.
16:40 -!- runab__ [n=runab(a)209.132.188.254] has joined #fedora-meeting
16:40 < spot> abadger1999: sure. that makes sense.
16:40 -!- paragn__ [n=paragn(a)209.132.188.254] has joined #fedora-meeting
16:40 -!- sm|test-box [n=morpheus@fedora/sankarshan] has quit Read error: 104 (Connection reset by peer)
16:40 < mmcgrath> Ok, so does anyone have anything else on the deployment thing? It seems we all agree communication could be better and I don't think anyone is against a better documented Fedora-Infrastructure -> Fedora (OS) lifecycle
16:41 < mmcgrath> Ok,
16:41 -!- azneita [n=azneita(a)121.97.142.237] has quit Remote closed the connection
16:41 < mmcgrath> the next bit is the licensing.
16:41 < mmcgrath> which has come under more light over the last couple of meetings.
16:41 -!- paragn [n=paragn@fedora/paragn] has quit Read error: 60 (Operation timed out)
16:41 < mmcgrath> in particular things like hot patching concern me as an operations guy.
16:42 < mmcgrath> I'm still learning how the agpl will affect us
16:42 -!- giallu [n=giallu@fedora/giallu] has quit Read error: 60 (Operation timed out)
16:42 < mmcgrath> So what happened there? Is it too late to go back and release it under a GPL license?
16:42 < spot> well, we really want it under the AGPL
16:43 < spot> the reason we didn't use the GPL is because the GPL is not a good fit for web apps
16:43 -!- runa_b [n=runab(a)209.132.186.254] has quit Read error: 60 (Operation timed out)
16:43 -!- sm|test-box [n=morpheus(a)209.132.188.254] has joined #fedora-meeting
16:43 < spot> we wanted to encourage people to use the FC/moksha code, but we also want to get back improvements
16:43 < mmcgrath> who's "we", because it's not the infrastructure team. AGPL means a lot more process, and higher barriers to running this app then before.
16:43 < spot> under the GPL, someone (*cough*google*cough*canonical*cough*) could take moksha and FC, make a ton of changes, and run it
16:44 < spot> without any requirement that they share their fixes, or changes, or anything
16:44 < mmcgrath> and that's a problem for who?
16:44 < mmcgrath> it's just not something we wanted to allow them to do?
16:44 < abadger1999> spot: Did you get the email I sent you: I believe Subject: Licensing Part II ?
16:44 < spot> we want to be able to get those fixes
16:44 < spot> and encourage open development
16:44 < mmcgrath> spot: I have to be honest, the license in mokesha will probably prevent me from ever using it in any of my projects.
16:44 < abadger1999> spot: we == moksha & Fedora Community.
16:44 < spot> mmcgrath: why exactly?
16:45 < mmcgrath> it's just too much of a pain to comply with. especially from an operations point of view.
16:45 < spot> mmcgrath: really? a url to fixes is too much of a pain?
16:45 < mmcgrath> I can't just go in and make a change.
16:45 < jwb> mmcgrath, maybe if you state your concerns first, it might help
16:45 < mmcgrath> spot: a week ago mirrormanger broke and I had a pot on the stove.
16:45 < abadger1999> jwb: The concerns were in the Licensing Part II email.
16:45 < mmcgrath> It took a couple of seconds to fix.
16:45 < jwb> abadger1999, ok
16:45 < spot> mmcgrath: to comply with the AGPL, you just need to have a link to the source that is running.
16:46 < mmcgrath> that couple of seconds, takes much longer when I have other stuff to do with linking to this or that and publishing, etc.
16:46 < spot> that could be a link to the base source control and a link to the hotfixes
16:46 < mmcgrath> except none of our code currently does that.
16:46 < abadger1999> spot: I think infra needs to know more about what compliance to the AGPL means in order to understand how costly/inexpensive it is to comply.
16:46 < spot> honestly, you should be tracking your hotfixes anyways
16:46 < jwb> spot, that is sort of orthogonal
16:46 < spot> no, not really
16:46 < mmcgrath> awhat about config files?
16:47 < spot> mmcgrath: config files aren't code.
16:47 < jwb> yes, sure. but if they don't right now, they aren't violating a license
16:47 < mmcgrath> additionally if I worked at either of the last two places I worked with, they'd immediatly say no to using it.
16:47 < ricky> With something like mod_wsgi, code and configuration can be very mixed at times.
16:47 < mmcgrath> just because of that.
16:47 < ricky> But I think the bigger concern is exactly how we have to link to hotfixes
16:47 < abadger1999> spot: But they're in the tarball along with the code and the only license in the tarball is AGPLv3.
16:47 < J5> A lot of people say no to GPL
16:47 < spot> mmcgrath: because they ran proprietary web apps
16:47 < spot> we don't.
16:47 < abadger1999> So how do we differentiate.
16:47 < J5> because of the same reasons
16:47 < abadger1999> J5: Yeah, once of the infra developers does, in fact.
16:47 < mmcgrath> spot: they also ran open source apps, it took a long time to get them to do it.
16:48 < mmcgrath> now imagine if the barrier to using those apps was even higher.
16:48 * abadger1999 notes meeting reaches halfway point.
16:48 < spot> abadger1999: well, we've never been that anal about configs in any other fedora package
16:48 < spot> abadger1999: but we can explicitly relicense the configs if it helps people sleep at night
16:48 < abadger1999> spot: We've never had a license that might require us to release them.
16:48 < smooge> spot, config files may be code depending on how they are implemented and if the file has a "AGPL" header in it. I couldn't find an exclusion to config files in the AGPL :/
16:49 < mmcgrath> I'm not talking about developing code, I'm talking about very practical operations issues.
16:49 < spot> abadger1999: thats not true, there are plenty of licenses that could be interpreted that way
16:49 < J5> I personally think LGPL would make sense in some of the code in Moksha
16:49 < smooge> spot, I am not against the AGPL, I just want to make sure we have a process in place so that we know the following:
16:49 < spot> mmcgrath: the issue is this, you need to make the code that is running available.
16:49 -!- sassmann [n=sassmann(a)g229133070.adsl.alicedsl.de] has quit Read error: 113 (No route to host)
16:49 < abadger1999> spot: We just need to know what the rules are for compliance. If there's some escape hatch built into the code vs config that says configs are uncopyrightable therefore they are freely copyable/do not fall under AGPL, that's fine.
16:49 < spot> to the user of the web app
16:49 -!- jeff_hann [n=arares(a)188.24.37.69] has quit "Leaving"
16:49 < mmcgrath> spot: and alter the webapp to point at it.
16:50 < spot> well, the webapp can point to a directory or a git tree or a url where source can be found
16:50 < smooge> a) How do we run in staging. Who are the 'customers' we need to publish the code for. {If some joe comes across it do we have to show them the exact code at that moment?}
16:50 -!- rishi [n=rishi@gnu-india/supporter/debarshi] has quit "Ex-Chat"
16:50 < ricky> One thing we were concerned about is how we need to link to hotfixes.
16:50 < spot> it doesn't have to be an explicit link
16:50 < spot> you just have to be able to get it from there
16:50 < abadger1999> spot: Are you talking Fedora or Fedora Infra?
16:50 * spot sighs
16:50 < ricky> OK, and what about what smooge said? Does this entire process need to be followed for our staging environment too just because it's web accessible?
16:50 < spot> this is a royal pain to do over irc.
16:50 < mmcgrath> but git trees and directories don't come out of thin air. We have to put them somewhere, we have to back them up
16:50 < mmcgrath> etc, etc.
16:50 -!- jeff_hann [n=arares(a)188.24.37.69] has joined #fedora-meeting
16:51 < mmcgrath> spot: imagine being legally liable for it.
16:51 < J5> ricky: why wouldn't a hotfix go into version control and the app be packaged first?
16:51 < spot> mmcgrath: guess what, i am. ;)
16:51 < smooge> spot I agree. I will send my problems via email and we can work out a process there.
16:51 < spot> no, lets try this again.
16:51 < spot> the webapp
16:51 < spot> has to have a link to the source of the code it is running
16:51 < spot> thats it.
16:51 < jwb> and if someone hotfixes a python bit that's live?
16:51 < mmcgrath> and the benefit to us is now canonical and google won't use mokesha?
16:51 < spot> that link can go to a page that says "here is the base git" and "here is a directory that contains any hotfixes we have applied"
16:52 < J5> mmcgrath: launchpad was just AGPL'ed
16:52 < ricky> J5: In staging, it probably should, but we use staging for debugging as well. One thing I did recently was write some debugging middleware for FAS in staging and leave that running for a few days
16:52 * mmcgrath writes down another reason not to use launchpad.
16:52 < nixdude> lol
16:52 < mmcgrath> I really don't like the AGPL and here's why. It protects the developer at the cost of the user.
16:52 < spot> honestly, i'm starting to get a little pissed off at the AGPL hate here.
16:53 < spot> you should be tracking your damn hotfixes anyway
16:53 < abadger1999> spot: People don't understand the AGPL.
16:53 < spot> and if you're doing that, its trivial to put up a link to them
16:53 < mmcgrath> spot: but having to do so in public is a higher burden then you think it to be.
16:53 < mmcgrath> from your point of view we don't get it
16:53 < spot> mmcgrath: if you're doing it right, you have nothing to fear.
16:53 < mmcgrath> from our point of view you don't get it.
16:53 < J5> mmcgrath: actually it protects users at the cost of the developers - you said it yourself, you are afraid of what it will cost us to do hotfixes but it allows users to not be locked in
16:53 < spot> if you're doing it wrong, you have more to fear than AGPL clauses
16:53 < abadger1999> Without understanding, people don't know what they can implement to comply and how much time that will take; what changes will be needed.
16:54 < abadger1999> https://www.redhat.com/archives/fedora-infrastructure-list/2009-July/msg0...
16:54 < spot> abadger1999: you can implement it pretty much any way you want as long as the user can get the source that is running
16:54 < ricky> https://fedorahosted.org/fedora-infrastructure/query?status=new&status=as...
16:54 < smooge> well ok lets try a different tack. what we need to do to properly track changes:
16:54 < mmcgrath> spot: you mean as long as the developer can get the source that is running right?
16:54 < spot> mmcgrath: no, the user of the webapp
16:54 < spot> any user of the webapp
16:55 < abadger1999> That's the summary of questions people asked at the last infra meeting about AGPL.
16:55 < mmcgrath> spot: and if the webapp doesn't have some way to do that we have to constantly patch the app to do it?
16:55 < spot> thats why FC has a link at the bottom of the page
16:55 * abadger1999 notes we are down to 7 minutes.
16:55 < mmcgrath> spot: but none of that links to where we track bugs
16:55 < spot> mmcgrath: then fix the webapp so it doesn't.
16:56 * mmcgrath doesn't think s/AGPL/GPL/ is legal though :)
16:56 < lmacken> Hey guys, sorry I'm late :)
16:56 < spot> mmcgrath: if you say "we put hotfixes for FC and moksha <here>", we'll link to it.
16:56 * lmacken wsa thinking it was at 13:00
16:56 < spot> and we're compliant
16:56 < mmcgrath> spot: and from your poitn of view, as someone that doesn't actually have to do that work, it seems trivial doesn't it?
16:56 < abadger1999> spot: I was wondering if that covers us or not -- it doesn't link to the version of code that we're running.... even with hotfixes.
16:56 -!- mishti [n=runab(a)209.132.188.254] has quit No route to host
16:56 < abadger1999> But once again, that was once of the questions in the email.
16:56 < ricky> lmacken: Hey, I have a bodhi question for you after this meeting if you'll be around
16:56 < spot> abadger1999: legal says it does cover us because the code we're running is there.
16:56 < mmcgrath> so what, we just copy the file into puppet, alter it, and hope upstream doesn't change it?
16:56 < abadger1999> spot: But it's not.
16:57 -!- sm|test-1ox [n=morpheus(a)209.132.186.254] has quit Read error: 110 (Connection timed out)
16:57 -!- paragn_ [n=paragn(a)209.132.186.254] has quit Connection timed out
16:57 < lmacken> ricky: ok
16:57 < spot> abadger1999: how is it not there? we're linking to git
16:57 -!- mcepl [n=mcepl(a)49-117-207-85.strcechy.adsl-llu.static.bluetone.cz] has joined #fedora-meeting
16:57 < abadger1999> spot: There's code i nthe moksha/fedoracommunity repo -- but it's not necessarily what we're running.
16:57 < spot> abadger1999: the code that we're running is in git.
16:58 < spot> unless one of you applied hotfixes without telling lmacken or J5
16:58 < J5> abadger1999: you can get to the revision
16:58 < ricky> what if mmcgrath finds a security bug in fcomm and doesn't have commit access?
16:58 < spot> or without checking it into git
16:58 < abadger1999> spot: Where? What revision?
16:58 -!- cassmodiah [n=cass@fedora/cassmodiah] has quit Read error: 110 (Connection timed out)
16:58 < abadger1999> What tag/branch/etc
16:58 < spot> abadger1999: i'm pretty sure "HEAD" is the answer
16:58 < ricky> I can see this being painful when it happens that we aren't upstream, or that we're not directly involved in development
16:58 -!- nim-nim [n=nim-nim@fedora/nim-nim] has quit Read error: 104 (Connection reset by peer)
16:59 < spot> abadger1999: and even if it wasn't, legal said it was sufficient to point to git
16:59 < abadger1999> spot: So even though we aren't running HEAD, it's sufficient to point to HEAD?
16:59 * mmcgrath notes 1 minut left
16:59 < spot> abadger1999: as long as the code we're running is actually in git
16:59 < jwb> they are telling you it's not
16:59 < spot> now, if you guys have a directory or a git repo or something
16:59 < spot> where you store hotfixes
16:59 < abadger1999> spot: k. So we don't need to point to our hotfixes either as long as they've been checked into some branch in git at some point?
16:59 < spot> we can link to that too
17:00 < abadger1999> Even if they've later been reverted, etc?
17:00 < spot> and we're compliant
17:00 < spot> yeah, sure.
17:00 < abadger1999> Excellent.
17:00 < mmcgrath> ugh
17:00 < mmcgrath> what a pita
17:00 < ricky> So what do we do for cases where we don't have commit access like the one I mentioned above?
17:00 < spot> you're making a mountain out of a molehill here.
17:00 < mmcgrath> Ok, we're at the stop point guys, sorry. We said hard stop so we're going to hard stop.
17:00 < mmcgrath> spot: you don't have to live with the consequences of this decision.
17:00 * mmcgrath does
17:00 < abadger1999> spot: System admins have to understand the worse case scenarios.
17:01 < mmcgrath> #stopmeeting
17:01 < mmcgrath> #meetingstop
17:01 < mmcgrath> it's one of those
17:01 < ricky> #endmeeting
17:01 < nirik> (endmeeting)
17:01 < ricky> (But you have to do it)
17:01 < mmcgrath> #endmeeting
17:01 < zodbot> Meeting ended Tue Jul 21 17:01:25 2009 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot .
17:01 < zodbot> Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora-meeting...
17:01 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora-meeting...
17:01 < mmcgrath> there we go
17:01 < zodbot> Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-21/fedora-meeting...
14 years, 9 months
- 1
- 0
MirrorManager crawler patch
by Ricky Zhou
Hey, I think we might have found a bug in the mirror crawler where it
did not do the repomd sha256sum check if a mirror is checked via FTP. I
think the crawler might still need a good bit of cleanup apart from
this, but here is an initial attempt at a patch to fix this:
http://ricky.fedorapeople.org/mirrormanager/0001-Check-sha256sum-of-repom...
I did some testing of this against fedora.bu.edu on bapp1 and it seemed
to mark the F10/F11 repodata directories outdated as expected.
Given the mirror issues that we've been havin recently, it might be
worth considering live patching this until the next mirrormanager
release.
Thanks,
Ricky
14 years, 9 months
- 2
- 4
Re: Cron <nobody@log1> /bin/rpm -Va --nofiles --nomd5
by Stephen John Smoogen
Fixed install
sudo yum install audit-libs.i386
Box has a lot of i386 installed on it.
On Sat, Jul 18, 2009 at 6:00 PM, Cron Daemon<root(a)fedoraproject.org> wrote:
> Unsatisfied dependencies for pam-0.99.6.2-4.el5.i386: libaudit.so.0
>
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 10 months
- 1
- 0
log1 filling up..
by Stephen John Smoogen
The majority of the logs are
8579992 ./bastion2
12937952 ./cvs2
27913380 ./secondary1
28753276 ./192.168.1.14
31164048 ./192.168.1.25
36747548 ./proxy1
59465200 ./192.168.1.7
78840240 ./proxy2
12937612 ./cvs2/2009
26187812 ./192.168.1.14/2009
27904380 ./secondary1/2009
30327316 ./proxy1/2009
30495152 ./192.168.1.25/2009
54589944 ./192.168.1.7/2009
Is it ok to compress older month logs 01/, 02/, 03/, 04, ?
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 10 months
- 3
- 4
An Introduction
by Jason Walsh
Hello Fedora Infrastucture,
My name is Jason Walsh, I am 16 years old and have been using
GNU/Linux for about 2 years now. My first exposure to Linux was an
Ubuntu 7.04 beta, and I continued using Ubuntu for several months
after that. Following Ubuntu, I wanted to learn more about Linux, and
switched to Arch, which I stayed on for about 10 months. Along with
some friends, I currently admister an Arch Linux server on which we
have deployed several Web technologies including PHP, Python, and
Rails. I'm still fairly new to Fedora, only having been using it since
the release of Leonidas. Already, however, I love it, as I feel it
combines both ease-of-use and cutting edge software.
Around the same time I started running Linux, I cut my teeth on
programming with Java. Shortly after, I learned the breath of fresh
air that is Python. I have been actively coding personal projects in
Python for about a year now, and have contributed small amounts of
code to the open-source project Crunchy. While I have mainly used
Django for Web development, I have also dabbled in TurboGears and
other frameworks.
I want to become involved in the Fedora project because I really like
the Fedora distribution itself, enjoy working on open source projects,
and believe in the philosophy of free software. I feel that the
infrastructure group is the place where I can be most useful to the
Fedora project.
This summer I am working as an intern at an IT company in their
Managed Services department, doing things such as monitoring, system
deployment, and image creation. (Unfortunately, with the exception of
a few RHCE's, it's an entirely M$ shop). At the end of summer, I will
begin my junior year in high school, which promises to be busy.
However, I think I will be able to donate about 3-4 hours a week to
the project. My entire "FOSS career" has been self-motivated and
self-taught, and hope to continue that with the infrastrcuture
project.
I'm located in Middle America, Central Standard Time. My IRC nick is
jpwdsm, and I'm on XMPP as jason(a)jabber.org.
Sorry if that was a little long winded :)
Thanks,
Jason Walsh
14 years, 10 months
- 2
- 1