infrastructure May 2008

infrastructure@lists.fedoraproject.org

61 participants
76 discussions

OpenID
by Mike McGrath 01 Jun '08

01 Jun '08

Hey guys, so the last little bits are in good shape for the OpenID provider we're attempting to be. Don't go announcing this to others yet. Lets test it out, if it breaks something let us know. We'll be announcing it officially soon. You can, for example, log in to livejournal.com with: username.id.fedoraproject.org as your openID provider. For example, my openID url is mmcgrath.id.fedoraproject.org -Mike

11 15

[Fwd: Problem logging in]
by Ignacio Vazquez-Abrams 31 May '08

31 May '08

Any ideas on this one, guys? -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com> PLEASE don't CC me; I'm already subscribed

3 4

PHP Security Tweaks
by Jeffrey Tadlock 31 May '08

31 May '08

I asked yesterday in the meeting about any modifications made to the default PHP install to help tighten things up a little with MediaWiki quite close to going into production. I took a look at the php.ini file on publictest2 and have a couple of suggestions to make - please feel free to comment or question any of them. I will add my own comments after each item. /etc/php.ini * Change 'allow_url_fopen' to Off. This is a big one as it can allow a remote file to be used in an include(). * Set 'expose_php' to Off. This one is just to reduce the amount of information one can gather through a script looking for vulnerable versions. Anyone determined to cause trouble could determine this information another way, like the Version info page in MediaWiki. * Set 'display_errors' to Off I think this was just set to On in testing to help with working through various bugs. But we should be sure it is set to Off for the production instance. * Set the upload_tmp_dir to a location that is only accessible by the user running MediaWiki and not readable or writeable by anyone else as well as being outside the web root. * Use disable_functions to limit what PHP functions are available. The following is a possible recommended list: disable_functions = "apache_get_modules,apache_get_version,apache_getenv,apache_note, apache_setenv,disk_free_space,diskfreespace,dl, highlight_file,ini_alter,ini_restore,openlog,passthru,phpinfo, proc_nice,shell_exec,show_source,symlink,system,exec,fsockopen, dl,popen" This appears to work on a MediaWiki instance I have, though that wiki is not as large or complex as the Fedora Wiki will be. Some of the items above are just information gathering components, others have a little more value to them. And then, set an open_base_dir directive in the wiki.conf file like this: php_admin_value open_basedir /var/www/wiki:/location/of/upload/tmp/dir Setting an open_basedir is not 100% foolproof to limiting access to PHP scripts, but it is another hurdle. The above config changes are some options we might want to consider. There are also tools out there like php-suhosin [1] that we might want to consider using as well to keep things as tight as possible. I have not made any changes to publictest2, but we may want to consider trying some of these config changes out and see if things still work and then possibly apply to the production instance. Thanks! Jeffrey [1] http://www.hardened-php.net/suhosin.127.html

2 10

wiki change notes from wrong user.
by Matt Domsch 31 May '08

31 May '08

Wiki change notes originating from odd user (below says changed by Mikec302, when it was me who made the change). What gives? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: WikiAdmin [mailto:webmaster@fedoraproject.org] Sent: Sat 5/31/2008 9:09 AM To: Mdomsch Subject: FedoraProject page FTBFS has been changed by Mikec302 Dear Mdomsch, The FedoraProject page FTBFS has been changed on 09:09, 31 May 2008 by Mikec302, see https://fedoraproject.org/wiki/FTBFS for the current version. See https://fedoraproject.org/w/index.php?title=FTBFS&diff=0&oldid=28695 for all changes since your last visit. Editor's summary: /* What to do if you get a FTBFS bug? */ Contact the editor: mail: https://fedoraproject.org/wiki/Special:Emailuser/Mikec302 wiki: https://fedoraproject.org/wiki/User:Mikec302 There will be no other notifications in case of further changes unless you visit this page. You could also reset the notification flags for all your watched pages on your watchlist. Your friendly FedoraProject notification system -- To change your watchlist settings, visit https://fedoraproject.org/wiki/Special:Watchlist/edit Feedback and further assistance: https://fedoraproject.org/wiki/Help:Contents

2 1

[Fwd: Tosca widgets, only half the battle]
by Toshio Kuratomi 30 May '08

30 May '08

Forwarding to fedora-infrastructure-list soit canget more exposure and discussion. -------- Original Message -------- Subject: Tosca widgets, only half the battle Date: Sun, 11 May 2008 12:27:36 -0400 From: John (J5) Palmieri <johnp(a)redhat.com> To: Toshio Kuratomi <a.badger(a)gmail.com> CC: tcallawa(a)redhat.com, lmacken(a)redhat.com, mmcgrath(a)redhat.com After hacking away at MyFedora and producing a lot of ugly code in the process I finally sat down the last two weeks to organize everything into a framework make it much more extensible and have patterns for people to easily create content. Most of the technologies are solidifying into my head and I have been working on hashing out an API design behind the user interaction design I had started with. The issue I am running into now is the fact that Turbo Gears and related technology come from a monolithic design and adhere too stringently to the Model/View/Controller design pattern. This is really an issue when your models, views and controllers can come from different applications or even different servers. MyFedora is of course a mashup of different tools and does not fit the, I'm grabbing data from a single database and displaying it via a self contained template, mold. What I need is a complete plugin system where a person can write their own self contained controllers, templates and static files which then drop in and are loaded on the fly, while integrating with the global project. Before I go further let me describe my design. Vocabulary: Resource - This is the starting point for MyFedora plugins. A resource is any abstract grouping such as "packages", "people" and "projects" which contain tools for viewing and manipulating data within the resource's context. Tools - A tool is a web app for viewing or manipulating data. For example Builds would be a tool for the package resource. Data Id - The data id is a pointer to a specific dataset the tools work on. For example the package resource considers each fedora package name to be a data_id. The way things work are Resources are placed in the resources/ directory and contain the logic for routing requests to a specific tool. They also contain the master template which is a cause of path problems with the current TG setup (include paths are relative to the including template) Tools are placed in the tools/ directory and are controllers just like any other TG controller. The exception is there is a standard for including the master template and the tool pulls templates and static files from its own directory. Tools can register with more than one resource and must modify its behavior based on the resource calling it. For instance the Build tool would be able to register with the package and people resource and depending which resource is being used it would display either a specific person's builds or the build history of a package. Based on the resource being used the master template is pulled in by the tool's templates. Data id's are simply what the resource passes to the tool and the tool needs to be able to accept when dealing with a particular resource. For instance the Packages resource would send a package name as a data id and the Peoples resource would send a person's FAS username. The issue here is I need the tools to be self contained but still integrate correctly with the global assests such as master templates and graphics. Tosca widgets seemed to be the answer until I looked further and found out they are just a higher level display layer than a self contained controller/template system. It seems to be confusing because it breaks the connection between the controller, data and the display when I want that all to be encapsulated. Basically I don't want the master page dolling out the data because the master page is just a container to display the tool and links to other tools. The tools should know where to get their data from. One solution is to use ToscaWidgets as a replacement for templates (or more apt another layer between the controller and the template). That makes things more complicated and throws away a lot of the concepts of TG controllers. I guess I am probably just hung up on how I first learned TG and we can just document around those issues. But another thing to think about is stuff like WSGI. What do you guys think? Given my design and goals such as the ability to display tools on the portal page, what is our plan of attack? How do we concoct a plugin system to make it easy for others to create integrated content while really just concentrating on their bits and not the wider integration infrastructure? Are there systems/libraries out there that already do this? Tosca is only part of the solution because it only deals with encapsulating display and is mostly geared to generic widgets like lists and not complete pages. I would like to have a framework that is simple, focused and easy to use. -- John (J5) Palmieri <johnp(a)redhat.com>

5 10

Meeting Log - 2008-05-29
by Ricky Zhou 29 May '08

29 May '08

16:10 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 16:10 * ricky 16:10 * ianweller 16:10 -!- sharkcz [n=dan(a)plz1-v-4-17.static.adsl.vol.cz] has joined #fedora-meeting 16:10 -!- MrBawb [i=abob(a)goldfish.drown.org] has joined #fedora-meeting 16:10 -!- nim-nim [n=nim-nim@fedora/nim-nim] has joined #fedora-meeting 16:10 -!- notting [n=notting@redhat/notting] has joined #fedora-meeting 16:10 -!- sternecg [n=sternecg(a)ohnat.bristolwest.com] has joined #fedora-meeting 16:11 < mmcgrath> abadger1999: dgilmore f13 G lmacken paulobanon skvidal others I've forgotten: PING! 16:11 * abadger1999 stands on his dot and raises his hand 16:11 * f13 16:12 < skvidal> hi 16:12 * MrBawb 16:12 < mmcgrath> starting a little late today :) 16:12 < skvidal> slacker 16:12 * ianweller , again 16:12 < mmcgrath> jcollie: you around 16:12 < jcollie> yo 16:12 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 16:12 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assi… 16:12 < zodbot> mmcgrath: http://tinyurl.com/47e37y 16:12 < mmcgrath> .tickety 395 16:12 < mmcgrath> .ticket 395 16:12 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:13 * dgilmore is here 16:13 < mmcgrath> jcollie: dgilmore: so sometime in the next week or two I'm going to start getting the asterisk install in better shape for all of that and build an asterisk2 box, etc. 16:13 < jcollie> cool 16:13 < mmcgrath> jcollie: I'm assuming no progress on the audio streaming for now? 16:13 < jcollie> nope 16:13 < mmcgrath> Since mediawiki is now deployed after next week asterisk is my next major project. 16:14 < ricky> Cool :-) 16:14 < mmcgrath> specifically fas integration and deployment. 16:14 < dgilmore> :) 16:14 < mmcgrath> .ticket 398 16:14 < zodbot> mmcgrath: #398 (elfutils `monotone' (mtn) error) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 16:14 -!- rmcgrath [n=roland(a)c-76-102-158-52.hsd1.ca.comcast.net] has joined #fedora-meeting 16:14 -!- daMaestro [n=jon@fedora/damaestro] has joined #fedora-meeting 16:14 < rmcgrath> mmcgrath: hii 16:14 < mmcgrath> rmcgrath: howdy, any word on - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 16:14 < mmcgrath> ? 16:15 -!- ldimaggi_ [n=ldimaggi@nat/redhat-us/x-2ef0128bbf8b70fd] has quit "Leaving" 16:15 < rmcgrath> mmcgrath: sorry, no progress (real work keeps taking priority, silly me) 16:15 < mmcgrath> no worries, we'll skip it for now 16:15 < rmcgrath> otay 16:15 -!- rmcgrath [n=roland(a)c-76-102-158-52.hsd1.ca.comcast.net] has left #fedora-meeting [] 16:15 < mmcgrath> .ticket 446 16:15 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 16:15 < mmcgrath> dgilmore: anything? 16:16 -!- fab [n=bellet(a)bellet.info] has quit "Leaving" 16:17 < dgilmore> no i still suck 16:17 < mmcgrath> k 16:17 < mmcgrath> .ticket 547 16:17 < zodbot> mmcgrath: #547 (Koji DB Server as postgres 8.3) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/547 16:18 < mmcgrath> This one's on hold until we get db3 installed which, btw brings me to my next topic. 16:18 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Hardware Installs 16:18 < mmcgrath> So next week I'll be in PHX, all week. 16:18 < dgilmore> :) 16:18 < mmcgrath> installing, IIRC, around 16 new servers. 16:18 < ricky> Woah. 16:18 < mmcgrath> it'll be a variation of blades and normal rack mounts. 16:18 < dgilmore> mmcgrath: ill be able to install the new builders 16:19 < jcollie> yowza 16:19 * f13 is quite excited. 16:19 < f13> mmcgrath: we should talk about the breakdown of blades. 16:19 < dgilmore> f13: as am i 16:19 < mmcgrath> but I'll likely be busy doing that all week so if you need something... ping someone else :) 16:19 < mmcgrath> f13: as in x86_64 vs ppc? 16:19 < f13> that and what duties they'll be put under 16:19 < dgilmore> f13: all builders 16:19 < f13> and what we'll do with the existing builders. 16:20 < dgilmore> f13: existing will remain 16:20 < dgilmore> though we could get rid of hammer2 xenbuilder1 and ppc1 16:20 < f13> I'd like to have a PPC system for doing community logins with mock 16:20 < dgilmore> they are the 3 oldest builders 16:20 < f13> that continues to run RHEL5 to match the actual buildsystem. 16:21 < mmcgrath> So my plan was to have those old builders stay there until 1) they die or 2) we need the space. 16:21 < f13> with PHX2 now online, how much space do we currently have? 16:21 < mmcgrath> f13: as of yet, we've not touch PHX2. 16:22 < mmcgrath> err touched it. 16:22 < f13> /we/ haven't, but hasn't some RH stuff moved over to PHX2 leaving us some space in PHX? 16:22 < dgilmore> f13: we only have space in PHX1 16:22 < dgilmore> f13: no idea 16:22 < mmcgrath> all of our space is allocated in PHX1 (actually Mesa) 16:22 < mmcgrath> f13: technically we always had space, just no power. 16:22 < f13> I thought that was what led to us being able to deploy the blade center 16:22 < f13> ah. 16:22 < mmcgrath> welll. no power _and_ space was tighet. 16:22 < f13> well, what is our upper limit now? 16:22 < mmcgrath> but they found it somewhere 16:22 * mmcgrath cannot type today 16:23 < mmcgrath> we basically have two full racks now. 16:23 < mmcgrath> minus some space they leave reserved for administrative stuff (bottom 6 U and the top 2 or 3 U) 16:24 < mmcgrath> and I lied, it looks like I'll be installing 19 servers. I think as far as builders go we're getting 8 x86_64 boxes and 6 PPC 16:24 < f13> so if I came to you in 3~ months time and said we want to deploy an automated testing lab of a number of machines, would we be able to do that? 16:24 < mmcgrath> depends on how much time and what type of machines they are. 16:24 < ricky> How will having all of these new builders affect NFS? 16:24 < mmcgrath> f13: if thats the plan please let me know because come Q4, both racks will be filled already. 16:24 < mmcgrath> ricky: not sure, we have the ability to cache some of that though now. 16:25 < mmcgrath> I've been trying to get a good baseline and, for example. 16:25 < mmcgrath> .buildload 16:25 < zodbot> mmcgrath: Load: 1.9 Total: 36.0 Use: 5.3% (Very Light Load) 16:25 < f13> mmcgrath: I haven't found a source for the hardware yet, but it would likely be x86(_64) and rackable. 16:25 < f13> 1us, 2us 16:25 < mmcgrath> ^^^^ thats pretty typical. 16:25 < f13> mmcgrath: we have software being developed to do automated testing, I just don't know how soon we'd be to the point of deployment 16:25 < mmcgrath> f13: ping me after the meeting.... If this is beyond the early planing stage I really should have known already because all the space in PHX (including new space) is spoken for. 16:25 < f13> mmcgrath: I wouldn't say beyond. 16:26 < f13> just that Q4 is a loooong time away 16:26 < mmcgrath> Q4 is yeah, but unless your lab is going ot go in during Q2 and be removed during Q3, then my Q4 plans are messed up. 16:27 < mmcgrath> Also going in next week are 5 other servers. 16:27 < mmcgrath> one dedicated to replace DB1, one of them is going to replace lockbox, one is the new db3 and the other two are application servers. 16:27 < dgilmore> mmcgrath: whats the plans for cvs-int 16:28 < mmcgrath> cvs-int (the host) needs to be rebuilt. but the box is fairly new. 16:28 < ricky> Cool 16:28 < mmcgrath> remember we had a horrible crash about a year or so ago? 16:28 < dgilmore> :) ok 16:28 < dgilmore> yeah disk array went bad 16:28 < mmcgrath> IIRC we did some drive swapping or some dd action or something. I can't remember. 16:28 < mmcgrath> but yeah, we need to rebuild cvs-int. I might work on that this week actually. 16:28 < ricky> Hah. 16:29 < dgilmore> we had scsi back plane go bad along with 2 disks 16:29 < mmcgrath> then we need to get the lookaside off of there. 16:29 < dgilmore> :) 16:29 < mmcgrath> Anyone have any questions about next week? 16:30 < mmcgrath> alllrighty 16:30 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Mediawiki 16:30 < f13> not that shouldn't be held off until after the meeting 16:30 * ianweller is gone next week. so hit me with all your mediawiki problems today and tomorrow :) 16:30 < mmcgrath> :) 16:30 < mmcgrath> So yeah, we deployed a new wiki this week! 16:30 < mmcgrath> few problems aside its been mostly painless and according to plan. 16:30 < dgilmore> :) 16:31 < f13> fantastic job all around 16:31 < ianweller> and it looks a lot better too ;) 16:31 < mmcgrath> I'm hoping that after the next week or so all remaining kinks will have been worked out and people will have long forgotten Moin ever existed. 16:31 < dgilmore> i miss my moin syntax :) 16:31 < mmcgrath> There's already been some requests for plugins/extensions to be added. 16:31 < ianweller> no you don't 16:31 < mmcgrath> Which is nice because... THAT DIDN'T EXIST IN MOIN :) 16:31 < dgilmore> ianweller: i do 16:31 < ricky> Hehe. 16:31 < ianweller> mmcgrath: is this a good time to bring up the toolserver idea i had? 16:32 * ianweller brainwashes dgilmore accordingly 16:33 < dgilmore> ianweller: not going to work im thick headed 16:33 < mmcgrath> ianweller: go ahead. 16:33 * mmcgrath still doesn't totally get it. 16:33 -!- giarc_w [i=hidden-u(a)gnat.asiscan.com] has joined #fedora-meeting 16:33 < ianweller> ok so my idea was to create a toolserver, which could be used for some scripts and other mashups dealing with FAS, mediawiki, and other apps we have for fedora. 16:34 < mmcgrath> ianweller: give me a use case you have in mind. 16:34 < ianweller> the wikimedia foundation in germany has a toolserver, which has some neat scripts that are a little too complex to make mediawiki extensions for 16:34 < ianweller> um 16:34 < ianweller> regex page watching :) 16:34 < ianweller> you would login with FAS, enter what regexes you wanted, and the script would find those pages matching the regex using the API 16:35 < ianweller> it could then aggregate the RSS feeds and send out emails. 16:35 < ianweller> it would only use a bit of extra load on mediawiki, the script itself would reside on the toolserver 16:35 < ricky> I think Debian does have a lot of "non-official" tools that developers setup themselves. Not sure if they have something like a toolserver, though. 16:35 < mmcgrath> so exactly how much work is involved in implementing that and how many people would be using it? 16:35 -!- jeff_hann [n=arares(a)89.40.98.185] has left #fedora-meeting [] 16:35 -!- wolfy [n=lonewolf@fedora/wolfy] has joined #fedora-meeting 16:36 < mmcgrath> also, and I probably still don't understand it, but why is a "regex search engine" called a "tool server" ? 16:36 < MrBawb> what I have at work is an rss to irc gateway, that I use to monitor wiki edits. maybe something similiar would be useful? 16:36 < ianweller> the regex search engine would go on the toolserver, along with other scripts that programmers could write. 16:36 * ianweller notes that this is still a halfbaked idea 16:37 < ianweller> http://wiki.toolserver.org/view/Main_Page -- here's the wikimedia toolserver 16:37 < mmcgrath> <nod> 16:37 * ricky also notes that they seem to have some sort of application process to get an account. 16:37 < mmcgrath> ianweller: if you think it'll add value, I'd say run with it. You still have access to the publictest servers so you should have everything you need :) 16:38 < ianweller> ok. 16:38 < ianweller> that's another thing; should there be just one pt server for the 'tools', and if so which one should it be? 16:38 < mmcgrath> Ok, anyone have anything else on the wiki? 16:38 < skvidal> one quick question 16:39 < mmcgrath> ianweller: I'd just keep using pt2 for now. 16:39 < ianweller> mmcgrath: k. 16:39 < skvidal> are we doing anything with the xmlrpc interface for it, yet? 16:39 < mmcgrath> skvidal: not yet, i've actually been trying to get that up and going this afternoon. I'd expect it to be working soon. 16:39 < ianweller> MrBawb: almost missed your message, i was gonna setup an irc bot to listen to recent changes and report to a channel 16:39 < mmcgrath> skvidal: we _are_ using mediawiki's xmlrpc interface in smolt though. 16:39 < skvidal> mmcgrath: and aren't there mediawiki python bindings? 16:39 < MrBawb> ianweller: ah, cool 16:39 -!- mdomsch [n=Matt_Dom(a)cpe-70-124-62-55.austin.res.rr.com] has quit Remote closed the connection 16:40 < mmcgrath> good question, I'm not sure. I'm just using the standard python xmlrpc bindings. 16:40 < skvidal> nod 16:40 < skvidal> that's what I thought 16:40 -!- mdomsch [n=Matt_Dom(a)cpe-70-124-62-55.austin.res.rr.com] has joined #fedora-meeting 16:40 < skvidal> I wanted to check on that though b/c it is intriguing to me 16:40 < ricky> skvidal: I think so. 16:40 < ianweller> skvidal: i think i remember seeing some somewhere, but i think they're implemented within a bot platform 16:40 < mmcgrath> skvidal: yeah, it'll be interesting to see what our greater community comes up with. 16:40 < f13> if there is xmlrpc, I bet lmacken will hookup an ability to use vim to edit the wiki 16:40 < skvidal> mmcgrath: wiki-mining :) 16:40 < mmcgrath> :) 16:40 < f13> (like he did for the Trac wikis/tickets) 16:40 < mmcgrath> alrighty, if no one has anything else we'll move on to the next topic. 16:41 < ricky> (http://meta.wikimedia.org/wiki/Using_the_python_wikipediabot) 16:41 < mmcgrath> ok 16:41 -!- tibbs [n=tibbs@fedora/tibbs] has quit "Konversation terminated!" 16:41 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 16:41 < mmcgrath> anyone have anything to discuss? 16:41 < mdomsch> sponsoring people? 16:42 < mdomsch> I've had a couple requests in the last few weeks 16:42 < mmcgrath> mdomsch: always an excellent topic. 16:42 < mmcgrath> how many people have taken on sponsors in the last month? 16:42 * mmcgrath has :) 16:42 < f13> I have not. 16:42 < mdomsch> I presume the method is to have them join sysadmin and sysadmin-test 16:42 < mdomsch> sponsor them there, and find them somethign to do 16:43 < mdomsch> from the trac list 16:43 < mmcgrath> mdomsch: correct, my general approach has been this 16:43 < mmcgrath> 1) get them on sysadmin and try to figure out what they want to do. 16:43 < mmcgrath> from there I usually stick them in sysadmin-devel sysadmin-test or, in rare instances, right into sysadmin-web. 16:43 < mmcgrath> mdomsch: how have your sponsors been? pretty reactive? 16:43 * abadger1999 has 16:44 < mdomsch> my minions have been pretty quiet thus far 16:44 -!- wolfy [n=lonewolf@fedora/wolfy] has quit Remote closed the connection 16:44 < mdomsch> but I've been away a lot since then too 16:44 -!- sharkcz [n=dan(a)plz1-v-4-17.static.adsl.vol.cz] has quit "Ukončuji" 16:44 < mmcgrath> abadger1999: how have your sponsors been? 16:45 < abadger1999> They come and go :-( 16:45 < mmcgrath> yeah 16:45 < abadger1999> I think people have time and so they apply and get started, then other things come up and they leave for a while. 16:45 -!- couf [n=bart@fedora/couf] has quit "leaving" 16:45 < mmcgrath> yeah, 16:46 < mmcgrath> thats one of the hardest things I've seen is people volunteering who just don't have the time they need to. 16:46 < mmcgrath> nothing's worse then working with, training, answering questions, for someone that can only give an hour or so every other week. 16:46 < mmcgrath> the interest is nice. but the amount of work that goes into a voulnteer vs how much you get out doesn't always add up :( 16:46 < mdomsch> it's best to find them something they can be responsible for 16:47 < mmcgrath> I'd *LOVE* to get a volunteer management expert or something at FUDCon this year. 16:47 < mdomsch> ownership breeds interest 16:47 < mdomsch> e.g. someone who is good at mailman instances could offload dgilmore 16:47 < mmcgrath> Thats a good example of a core problem I've seen. 16:48 < mmcgrath> someone comes to volunteer wanting to manage our xen infrastructure (just an example) but then goes away when they find out they have to pay the dues. 16:48 < dgilmore> :( me will go and hide 16:48 < mmcgrath> when you find someone willing to pay the dues (like work on mailman) they don't stick around very long. 16:48 < mmcgrath> its that hard balance I guess. 16:48 * mmcgrath takes this time to curse at RH's vpn solution. 16:48 < mmcgrath> anywho. 16:49 < ricky> Heh. 16:49 < wfp> coming from the other side, I feel like it's hard to find where I can start to help, other than contrib a package. 16:49 < mmcgrath> mdomsch: do you think we're doing the right thing or should we re-examine our situation? 16:49 -!- drago01_ [n=linux(a)chello062178124130.3.13.univie.teleweb.at] has joined #fedora-meeting 16:49 < mmcgrath> wfp: https://fedorahosted.org/fedora-infrastructure/ pick a ticket and start helping. 16:49 < mmcgrath> its really that easy. 16:49 < skvidal> wfp: if you find you need access to things ping me 16:50 < skvidal> or mmcgrath 16:50 < mdomsch> that's a good start; picking some easy-to-do things that we'd like a new volunteer to take on would help 16:50 < skvidal> or anyone 16:50 < ricky> How can we encourage more feedback from would-be conributors? 16:50 < dgilmore> mdomsch: please make me obsolete :) 16:50 < skvidal> but I sponsored you for sysadmin 16:50 < londo> picking a ticket sometimes require some knowledge on how the system works though 16:50 < skvidal> so ping me 16:50 -!- drago01 [n=linux(a)chello062178124130.3.13.univie.teleweb.at] has quit Read error: 104 (Connection reset by peer) 16:50 < dgilmore> or me 16:50 < ricky> Feel free to ask in #fedora-admin. We're pretty open about our setup 16:50 < sternecg> londo: true 16:50 -!- drago01_ is now known as drago01 16:50 * dgilmore would like to make sure that if he fell off the planet that things would be ok 16:51 < wfp> Yeah, it's the details of getting access to systems and stuff. Either I'm missing the docs on that stuff or I just need to dive and bug you guys as I go on my first trip 16:51 < ricky> wfp: Feel free to bug :-) 16:51 < mmcgrath> wfp: so when you found a ticket you were interested in working on.... what did you do? 16:51 < mmcgrath> and more importantly, why did you do it? 16:52 < wfp> Nothing yet, as I wasn't sure how/what I would still need to do to actually get the appropriate actions. 16:53 < mmcgrath> so you found what you wanted to do. and then did nothing. 16:53 < ricky> wfp: Commenting on the ticket/asking in #fedora-admin or the list sounds like a good first step. 16:53 < mmcgrath> ricky: but how do we get that point across to people that haven't done it I think is what wfp is saying. 16:53 < mmcgrath> this is the same issue I blogged about the account system the other day. 16:53 < wfp> I found something I *might* be able to do, but wasn't sure how to go about looking into further. 16:54 < ricky> wfp: Did you see http://fedoraproject.org/wiki/Infrastructure/GettingStarted by any chance? 16:54 < ricky> Should we work on improving that page? 16:54 < ricky> Or is it not visible enough in the first place? 16:54 < mmcgrath> new voluteers, in my mind, just seem completely clueless as to what to do next, no matter how explicit we document, now matter how full a GettingStarted page is, they just don't do anything. 16:54 < mmcgrath> I don't know if this is a process thing, a training thing or what. 16:54 < ricky> Perhaps a huge banner on the Infrastructure page could help? 16:55 < sternecg> mmcgrath: I would say training.. 16:55 < mmcgrath> quaid: you around? 16:55 < ricky> "If you'd like to help, read this!" 16:55 < wfp> What I feel is lacking is a more of a process thing. 16:55 < mmcgrath> I just don't understand why someone would show up, say they want to help (or even worse just sign up for an account) and thast the end of it? 16:55 < abadger1999> 1) joinmsg for cla_done should direct people to the toplevel getting started in fedora page that outlines what projects to join. 16:55 < ricky> mmcgrath: One thing that's weird is that I never see people respond to your welcome emails on list. 16:55 < mmcgrath> I mean if you want to do something, why aren't you looking around for stuff to do, and bugging people to do it? 16:55 < ricky> (Your reply to their introduction) 16:55 < mmcgrath> ricky: no kidding. 16:56 < abadger1999> 2) We should have a group description field that outlines what a group is and what to do once you've decided you want to be a part of it. 16:56 < mmcgrath> We should also make it very clear that applying for a group is the _last_ thing you should do if you're new to fedora. 16:56 < abadger1999> <nod> 16:56 < wfp> For example, from the mailing list, I see you folks appear to be maintaining config files in CVS. Again, I may missed the docs, but I don't see how you guys do that process. 16:56 < mmcgrath> I love new people but why on earth someone thinks they can come in and be an account system admin is beyond me. 16:57 < ricky> I'm honestly not as concerned about group spam than I am with the response to people that do know what they want to do. 16:57 < skvidal> wfp: once you get access to things you can ssh into certain machines and modify/check things in 16:57 < mmcgrath> wfp: there's no point in telling you that though because you're not at that level yet. 16:57 < mmcgrath> I mean, when the time comes and access is given, one of the first things I always tell people is look at SOP/Puppet. 16:57 < abadger1999> wfp: https://fedoraproject.org/wiki/Infrastructure/SOP/Puppet 16:57 < mmcgrath> but why would someone be given that access if they've not even agreed to do anything yet? 16:58 < wfp> I'm not expecting the access, I just want to see the path. 16:58 < mmcgrath> well, curiosity is one thing. 16:58 < mmcgrath> wfp: lets say you started from the begnining. 16:58 < mmcgrath> how do you think it should have gone? 16:58 < ricky> wfp: It's not that we wouldn't tell you if you asked :-) 16:59 < mmcgrath> lowering the barriers is a very important thing to me which is why I'm bugging wfp. He's fresh meat, clean view of how things seemed to him. 16:59 < ricky> I think we just don't see a point to training that part until the person has something to work on. 17:00 < mmcgrath> I think, perhaps, we need a much better "what to expect" page on the wiki somewhere to help shape what new volunteers can expect. 17:00 < mmcgrath> I always try to do that, its in the GettingStarted section, I think its even in the about section of the account system. 17:00 < mmcgrath> bah, we're out of time. 17:00 < mmcgrath> wfp: we'll have to continue this next time :) thanks for your comments though 17:01 < sternecg> thanks for the discussion 17:01 < mmcgrath> if no one has anything else we'll close the meeting in 15 17:01 < ricky> Quick thing: 17:01 < ricky> .ticket 576 17:01 < zodbot> ricky: #576 (Infrastructure Contact Information) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/576 17:01 < mmcgrath> ricky: how about a file in the private repo on puppet1? 17:02 < ricky> mmcgrath: That sounds good 17:02 < mmcgrath> k 17:02 < mmcgrath> and with that :) 17:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting End

1 0

Call For Testers - Elections Application
by Nigel Jones 29 May '08

29 May '08

Hi everyone, With Fedora 9 out the door we hit a very busy time for elections, the previous system was, well lets just say, not optimal. So I accepted the goal of creating an application by our post-release election season that would integrate well with FAS and would allow a different method of voting, Range Voting. If your not familiar with Range Voting check out http://en.wikipedia.org/wiki/Range_voting the essentials however is that you rank candidates from 0<-># of candidates, if you don't like them, just rank them 0. In the future, the application will not only allow the Board and Steering Committees to hold elections, it will (hopefully) become available to SIGs and Steering Committees for any time of poll/call to vote. This is where you all come in, it's impossible for a small group of people to find every possible mistake or bug in ANY item of software, so the more people we can get in to test it and report bugs/issues/thoughts the better! All I ask is 10-20 minutes of your time, whenever your free over the couple of days to test and provide feedback. Instructions: 1) You'll need an account on the test instance of FAS at http://publictest10.fedoraproject.org/accounts/ (PLEASE) do not use your normal password and you don't need to do CLA etc (I've removed that requirement in the elections app for now). 2) Please direct your browser to https://publictest10.fedoraproject.org/elections/ and test away! 3) Try voting etc, make sure that you *can* view the results at https://publictest10.fedoraproject.org/elections/results/fedora but can't view the results at https://publictest10.fedoraproject.org/elections/results/president Notes: * I'm aware the UI is absolutely awful, there is already a ticket open for this (https://fedorahosted.org/elections/ticket/4) please feel free to add items there. * Any errors you encounter that are 'unexpected' to you, please file a ticket at https://fedorahosted.org/elections/newticket setting Milestone to 'Release 0.1.0' with full reproduction steps, and the time it occurred (TZ=UTC date) * Any other feedback can be directed to the elections-devel list (elections-devel(a)lists.fedorahosted.org) After 5am UTC on the 1st June both elections will end and the 'results' should be public and hopefully we'll have a decent election app! Thanks a lot & Happy Testing, Nigel Jones p.s. Sorry to those that fall asleep during my e-mail - I nearly did too! p.s.s. Thanks must be given to Toshio, Ricky, Luca and Mike who have all assisted in this release

4 3

Introduction
by Alex Musolino 29 May '08

29 May '08

Hi, I've been using Linux for a little more than 3 years now (RedHat 9, FC5, FC6, F7, F8) and have since taken a strong interest in all things Linux/FOSS/Computers in general. I'm currently doing a Computer Systems Engineering degree as a double with Mathematical and Computer Sciences. I'm familiar with XML, XHTML/CSS, MySQL, I can program in PHP, and a little Java (working on my Python, Perl, C/C++). I've messed around with some linux home servers, so I'm familiar with setting up and running basic Linux services. I'd love to help out with anything I can, and hopefully I'll learn a thing or two from other contributors. Regards, Alex Musolino

2 1

Logging #fedora-meeting
by Mike McGrath 29 May '08

29 May '08

There's been some requests to log #fedora-meeting automatically. There's technical issues there like where to store them, is there a way to auto start / stop meetings, etc. Lets discuss. thoughts? -Mike

7 7

postfix alias issue
by Jesse Keating 28 May '08

28 May '08

A few days ago I setup email2trac on our hosted1 system to allow for using emails to create Trac tickets for select hosted projects. At this was all working, and the setup was such that the aliases file and aliases.db for Trac projects that accept tickets were owned by apache so that the mail command /in/ the alias would be ran as apache. This was necessary because it's the apache user who has write access to the trac databases. Sometime in the last few days this has stopped working. Mail is getting through the alias path and delivered to the email2trac command but that command is dropping it somewhere. I could really use a second set of eyes looking at the setup with me that has more experience with postfix and aliases. Please find me on #fedora-admin as "f13". Thanks! -- Jesse Keating Fedora -- Freedom² is a feature!

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure May 2008