OLPC:Volunteer Infrastructure Group

From OLPC
Revision as of 15:11, 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