OLPC:Volunteer Infrastructure Group

From OLPC
Revision as of 15:15, 20 August 2008 by Hhardy (talk | contribs) (I-g documentation discussion)
Jump to: navigation, search

Infrastructure gang

Are you an experienced *NIX sysadmin looking for a way to volunteer for One Laptop per Child?

One Laptop Per Child is pleased to announce OLPC's Infrastructure-group! We are looking for a few good sysadmins to assist with our public-facing infrastructure.

Possible initial tasks include:

  • Trac and git maintenance
  • wiki extensions/improvements
  • RT updating and administration
  • Mailing list administration
    • The Library and Sugar mailing lists could use some list administration help [1] 23:34, 19 August 2008 (UTC)

We will consider expanding the scope of the project as we learn more about what works.

Purpose of the Volunteer Infrastructure Group aka infrastructure-gang

  • Make the sysadmin's job easier
  • Improve the infrastructure systems through "many hands/many minds"
  • Strengthen ties with the community

Contacts

The following infrastructures are in place to support this initiative:

Weekly meetings

Next IRC meeting will be at irc.oftc.net:#olpc-admin 5:15 pm EDT (-04:00 UCT), every Tuesday

I-g documentation discussion

Currently most sysadmin documentation is on OLPC internal wiki, which is generally only open to NDA'ed employees and select contractors.

Here are some proposals on how to publish and protect i-g documentation.

  1. Put docs, passwords and other information onto a protected area of teamwiki.
  2. Put the information onto public wiki, and use encryption such as gpg to encipher sensitive data such as passwords.
  3. Use git, and rely on git access controls for protection. Possibly transclude git to wiki.
  4. Put data into a text file on the root directory of a machine.

Please edit and add arguments pro and con.

Hhardy 17:41, 20 August 2008 (UTC)

See Michael's proposed infrastructure-documentation-system requirements

13:59 < m_stone> cjl: what did I miss?
14:00 < cjl> traceability of actions?
14:00 < m_stone> good.
14:00 -!- gregdek [~gdk@wireless-nat-pool-rdu.redhat.com] has joined #olpc-admin
14:00 < m_stone> cjl: actions on the documentation or actions on the system?
14:00 < m_stone> sorry, on the infrastructure being maintained.
14:00 < m_stone> gregdek: 
http://wiki.laptop.org/go/User:Mstone/Commentaries/Infrastructure_1 might 
                 interest you.
14:01 -!- _sj_ [~sj_@wireless-19-210.media.mit.edu] has joined #olpc-admin
14:02 < cjl> In my environment (Win) we enforce a separation between admin 
             identities and user identities so that most daily work by admins 
             is done with minimally priv'ed accounts.  Possibly not as 
             necessary in Linux environment, less credential hijacking.
14:02 < cjl> sort of a Windows sudo
14:02 < cjl> I have superman and Clark Kent accounts 
14:03 < cjl> m_stone: depends on ease of keeping such logging on various types 
             of actions.  On docs, you are talking version control and history, 
             on systems, it is an accountability/logging thing.
14:06 < cjl> both are desirable, tolls make the difference between how easily 
             either is done.  For any security measure, you need to have a 
             "threat model" that is realistic and not just a strawman or you 
             would turn off all your computers and hide them in the closet.
14:06 < cjl> s/tools/tools/
14:08 < cjl> It is of course one of the worst kept secrets in the IT world that 
             the greatest threats are internal (apropos henry's quis custodiet 
             ipsos custodes), and so it is generally a matter of risk 
             mitigation, not prevention.
14:10 < cjl> logging is an excellent risk mitigation tool because most of us 
             have reputations tha we value (semi-pseudonymous or otherwise) and 
             logging poses the risk of discovery and exposure of malfeasance or 
             misfeasance.
14:14 < cjl> In a high-risk environment (e.g. my Sarbanes-Oxley compliant 
             accounting system) actual examination of such logging is needed, 
             in a low-risk environment, the simple existence of such logs is a 
             deterrent and a valuable forensic/recovery resource
14:17 < cjl> m_stone: Sort of a long explanation, but does that answer your 
             question?

Adric's draft RT_Strategies doc

User:Adricnet/RT_Strategies

Meeting notes

Internal notes