OpenID
by Mike McGrath
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
14 years, 9 months
[Fwd: Problem logging in]
by Ignacio Vazquez-Abrams
Any ideas on this one, guys?
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
14 years, 9 months
PHP Security Tweaks
by Jeffrey Tadlock
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
14 years, 10 months
[Fwd: Tosca widgets, only half the battle]
by Toshio Kuratomi
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>
14 years, 10 months
Meeting Log - 2008-05-29
by Ricky Zhou
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=as...
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
14 years, 10 months
Call For Testers - Elections Application
by Nigel Jones
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
14 years, 10 months
Introduction
by Alex Musolino
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
14 years, 10 months
Logging #fedora-meeting
by Mike McGrath
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
14 years, 10 months
postfix alias issue
by Jesse Keating
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!
14 years, 10 months
