OLPC:Volunteer Infrastructure Group: Difference between revisions
Line 55: | Line 55: | ||
See [[User:Mstone/Commentaries/Infrastructure_1|Michael's proposed infrastructure-documentation-system requirements]] |
See [[User:Mstone/Commentaries/Infrastructure_1|Michael's proposed infrastructure-documentation-system requirements]] |
||
<pre> |
|||
13:59 < m_stone> cjl: what did I miss? |
13:59 < m_stone> cjl: what did I miss? |
||
14:00 < cjl> traceability of actions? |
14:00 < cjl> traceability of actions? |
||
Line 94: | Line 94: | ||
14:17 < cjl> m_stone: Sort of a long explanation, but does that answer your |
14:17 < cjl> m_stone: Sort of a long explanation, but does that answer your |
||
question? |
question? |
||
</pre> |
|||
== Adric's draft RT_Strategies doc == |
== Adric's draft RT_Strategies doc == |
Revision as of 19:12, 20 August 2008
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:
- Mailing list: mailto:olpc-sysadmin@lists.laptop.org
- Mailing list admin page
- Mailing List Archives
- IRC channel: irc.oftc.net:#olpc-admin
- Open an rt ticket: mailto:sysadmin@laptop.org
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?