What should be added or removed? Remember this is going to be a time for us to actually sit in a room and get stuff done.
High level goals (Infrastructure Specific): 1) Basic auth/group API for the old Accounting system and the new one in Python. 2) Update System hacking (lmacken lead) 3) Finalize the new postfix server 4) Discuss the "Fedora Noc" + initial coding / Design 5) Volunteer sponsorship 6) Future of the wiki (Moin) 7) Design and coding of new account system (Try to find something that is already out there) 8) Hosting (Jkeating lead) 9) Package Database 10) Backup Server (Finalize)
High level goals (general non-infrastructure specific) 1) Lowering the barrier to entry without sacrificing infrastructure / security 2) Volunteer management (coordination might be a better word) 3) VCS / SCM future (Lead by those in the sig)
I'd also like to get with some of the other dev's to get an idea of whats important for them to have going forward and whats needed for this release.
-Mike
On Fri, 2007-01-05 at 16:18 -0500, Bill Nottingham wrote:
Mike McGrath (mmcgrath@fedoraproject.org) said:
I'd also like to get with some of the other dev's to get an idea of whats important for them to have going forward and whats needed for this release.
i18n/elvis/rhlinux migration.
Could we have someone at FudCon to give us a tour of what all is in need of migration? I know that there's a bunch of infrastructure there that needs to move but don't have a clear idea of just what it is.
-Toshio
Toshio Kuratomi (a.badger@gmail.com) said:
i18n/elvis/rhlinux migration.
Could we have someone at FudCon to give us a tour of what all is in need of migration? I know that there's a bunch of infrastructure there that needs to move but don't have a clear idea of just what it is.
What's On Elvis:
1) a CVS server. Self-explanatory. - includes pserver (aiyeeee!) - includes sanity checks on translation checkin - includes ACLs for translators so they don't commit to other languages 2) Accounts (ssh v2 keys), split into two groups: - general write access - translators (write access to .po files only) 3) the translation system, which has: - its own separate account database (postgresql) on top. tracking: - translators - their keys - their .htpasswds - languages - translator/language mappings - module statuses - translator status (active, suspended, etc) - web frontend - showing translation status - allowing you to 'reserve' files
#1 is pretty easy.
#2, well, we know how we're going to tackle that.
#3 is all written in perl (which has its good and bad points.) However, since it's written around a database which needs to die, I'm not sure it's useful at all.
So, what we need is:
- translators in the account system - a way to describe in the account system what langauges a translator is responsible for - a way to enforce that when checkins are done
Frankly, I'm of the opinion that most of the rest of the stuff can be scrapped as is and can be replaced by something like damned-lies (progress.gnome.org). In fact, asking other projects what sort of software they use around their translation couldn't hurt.
One thing we'll need is a way to integrate this translation framework across multiple SCMs - I'd like to be able to handle software whether it's in git, svn, cvs, or hg. We'll also need a better group organization aside from just 'put everyone in cvsfedora'.
Bill
On Friday 05 January 2007 3:17 pm, Mike McGrath wrote:
What should be added or removed? Remember this is going to be a time for us to actually sit in a room and get stuff done.
High level goals (Infrastructure Specific): 1) Basic auth/group API for the old Accounting system and the new one in Python. 2) Update System hacking (lmacken lead) 3) Finalize the new postfix server 4) Discuss the "Fedora Noc" + initial coding / Design 5) Volunteer sponsorship 6) Future of the wiki (Moin) 7) Design and coding of new account system (Try to find something that is already out there) 8) Hosting (Jkeating lead) 9) Package Database 10) Backup Server (Finalize)
High level goals (general non-infrastructure specific) 1) Lowering the barrier to entry without sacrificing infrastructure / security 2) Volunteer management (coordination might be a better word) 3) VCS / SCM future (Lead by those in the sig)
I'd also like to get with some of the other dev's to get an idea of whats important for them to have going forward and whats needed for this release.
I think in this new world We are going to have greater demands placed on us. We really need to know what we are in for at release time. There is a whole lot of stuff that has always happened by RH IS staff. will this continue to be the case or Will we pick up new tasks? otherwise it sounds good.
Should we have a infrastructure dinner to get to know everyone a bit better?
On 1/5/07, Dennis Gilmore dennis@ausil.us wrote:
On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: I think in this new world We are going to have greater demands placed on us. We really need to know what we are in for at release time. There is a whole lot of stuff that has always happened by RH IS staff. will this continue to be the case or Will we pick up new tasks? otherwise it sounds good.
Should we have a infrastructure dinner to get to know everyone a bit better?
+1 for an FI Lunch or Dinner. Regarding RH IS, I'm guessing that more and more we'll be moving to the Fedora infrastructure for things, lots of things. Or possibly not moving a whole lot but more that our growth will be on FI and not RH IS.
-Mike
On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: I think in this new world We are going to have greater demands placed on us. We really need to know what we are in for at release time. There is a whole lot of stuff that has always happened by RH IS staff. will this continue to be the case or Will we pick up new tasks? otherwise it sounds good.
Should we have a infrastructure dinner to get to know everyone a bit better?
+1 for an FI Lunch or Dinner. Regarding RH IS, I'm guessing that more and more we'll be moving to the Fedora infrastructure for things, lots of things. Or possibly not moving a whole lot but more that our growth will be on FI and not RH IS.
when is this fudcon thingy? maybe I should make a cameo.
On Fri, 2007-01-05 at 21:36 -0500, Matthew Galgoci wrote:
On Friday 05 January 2007 3:17 pm, Mike McGrath wrote: I think in this new world We are going to have greater demands placed on us. We really need to know what we are in for at release time. There is a whole lot of stuff that has always happened by RH IS staff. will this continue to be the case or Will we pick up new tasks? otherwise it sounds good.
Should we have a infrastructure dinner to get to know everyone a bit better?
+1 for an FI Lunch or Dinner. Regarding RH IS, I'm guessing that more and more we'll be moving to the Fedora infrastructure for things, lots of things. Or possibly not moving a whole lot but more that our growth will be on FI and not RH IS.
when is this fudcon thingy? maybe I should make a cameo.
Since mgalgoci probably isn't the only one that doesn't know about this:
http://barcamp.org/FudconBoston2007
''' FUDCon Boston 2007 :: 02 February 2007 :: Boston University
FUDCon? Bar Camp? Read this First!
FUDCon stands for Fedora User and Developer Conference. FUDCon Boston 2007 will be held as a Bar Camp. A Bar Camp is an "un-conference" where people interested in a wide range of issues come together to teach and learn. '''
-Toshio
Mike McGrath wrote:
What should be added or removed? Remember this is going to be a time for us to actually sit in a room and get stuff done.
High level goals (Infrastructure Specific):
- Basic auth/group API for the old Accounting system and the new
one in Python. 2) Update System hacking (lmacken lead) 3) Finalize the new postfix server 4) Discuss the "Fedora Noc" + initial coding / Design 5) Volunteer sponsorship 6) Future of the wiki (Moin) 7) Design and coding of new account system (Try to find something that is already out there) 8) Hosting (Jkeating lead) 9) Package Database 10) Backup Server (Finalize)
During the summit Warren proposed a few security policies for our publictest* machines, which we all agreed on:
o must get approval from infrastructure team o denyhosts must be configured o ssh key authentication only
I think we should try and discuss and draft a full security policy for all of our infrastructure while we're at FUDCon.
We might also want to talk about single sign-on for our applications and such.
luke
Luke Macken wrote:
During the summit Warren proposed a few security policies for our publictest* machines, which we all agreed on:
o must get approval from infrastructure team o denyhosts must be configured o ssh key authentication only
I use SSH public key authentication on all my servers (password authentication disabled) and I used to run DenyHosts. At some point I decided to replace DenyHosts with Fail2ban [1], because Fail2ban creates (temporary) iptables rules instead of (temporary) entries in / etc/hosts.deny. Have you compared the two?
Nils Breunese.
infrastructure@lists.fedoraproject.org
-
Bill Nottingham -
Dennis Gilmore -
Luke Macken -
Matthew Galgoci -
Mike McGrath -
Nils Breunese -
Toshio Kuratomi