<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Folks -<div><br></div><div>Since the VIG was created to assist OLPC sysadmin staff, and since OLPC now has no dedicated sysadmin staff (Chris Ball and I are covering the work part-time) I think it's probably a good time to rethink and recalibrate how the VIG operates. &nbsp;Here are my thoughts on what we could do, and I'd appreciate hearing other comments and input.</div><div><br></div><div>1. <b>OLPC Sysadmin Priorities</b>&nbsp;- Since Chris and I are now the people primarily responsible for sysadmin duties, I'd like to make sure everyone understands what our top priorities are.</div><div><br></div><div>a. By far the most serious issue we're facing is the extreme load placed on pedal.laptop.org for wiki access. &nbsp;We have reconfigured and tuned the squid proxy on weka and it seems to be working very well. &nbsp;But the uncached requests, especially during the school day in Uruguay, produce both a very heavy load on pedal.laptop.org and on crank.laptop.org due to the large number of Activities linked to by the wiki that are hosted on crank.laptop.org. &nbsp;Since pedal runs the apache2 server for the wiki, the MediaWiki code, and the MySQL database it uses, it gets overloaded. &nbsp;And since that same machine hosts our postfix and mailman services, it's even worse. &nbsp;When Uruguayan schoolchildren arrive in the morning, OLPC has difficulty sending mail, and that's a real problem. &nbsp;The poor performance of the wiki and crank affects a very wide community of users.</div><div><br></div><div>b. We are managing far too many physical and virtual machines. &nbsp;We are not a very large organization, but yet we have literally a few dozen servers and an untold number of VMs running on them. &nbsp;We cannot manage such a large set of systems. &nbsp;I don't mean that from a "we need more VIG help to manage them" perspective, but rather because our risks of failure and the workload involved to keep these machines running and secure is much, much larger than it needs to be.</div><div><br></div><div>c. Our network and systems documentation is in very poor shape. &nbsp;The chief value of this documentation is so that new people coming in to the task (like cjb and me) can look in one place and get all the important information they need about each machine. &nbsp;That can't be done right now, and we have quite a bit of information that's either confusing, inaccurate, or missing. &nbsp;This is a very serious hindrance to any cleanup/consolidation work for priority b. above.</div><div><br></div><div>d. Systems support for the XO-1.5 effort is a relatively small amount of work, but a high priority. &nbsp;This mainly consists of setting up build systems for OS and firmware releases, and for the F11-on-XO-1 effort.</div><div><br></div><div>2. <b>VIG Priorities</b>&nbsp;- From what I can tell from the VIG meeting logs, the current set of VIG priorities are a completely separate set from the ones I listed above. &nbsp;I think that tells us two main things: the VIG is currently serving a set of needs for the broader OLPC volunteer community, and that the VIG's interests have moved away from the original focus of supporting OLPC sysadmin work.</div><div><br></div><div>3. <b>Short-Term OLPC Sysadmin Action Items</b>&nbsp;- We are currently overloaded yet have underutilized hardware.</div><div><br></div><div>a. Cjb and I successfully moved weka.laptop.org from 1CC to W91 a few weeks ago, completing a long-standing sysadmin priority to help get all "public-facing" systems and services out of the 1CC server room and into the much better colo environment of W91. &nbsp;My next priority is to reconfigure owl.laptop.org (currently almost unused) to be tuned as a MySQL database server system with a RAID 1+0 hard disk configuration. &nbsp;This will let us rebuild owl as a semi-dedicated or dedicated MySQL server for all our needs, but particularly for the wiki. &nbsp;By doing that we will take the first step towards better wiki load-balancing by splitting the MySQL service away from pedal. &nbsp;I'm also eager to set up Atrium, an open-source project management tool that uses MySQL, so getting the database server configured properly will allow me to use it right away and not migrate later.</div><div><br></div><div>b. Account review and security. - cjb and I should have root access on every machine OLPC has, and we need to clean up old accounts scattered everywhere (both sudoers and others). &nbsp;What we have now is a huge mess, with long-gone employees and volunteers still having complete access to our systems. &nbsp;We have recently had problems with unauthorized usage and content on our machines, incurring well-deserved complaints from our hosts at the Media Lab and MIT. &nbsp;This lack of control and security puts our very valuable hosting relationship at risk and we need to take more responsibility for it. &nbsp;I will be continuing to consolidate and eliminate unused and unnecessary accounts. &nbsp;As much as possible, I'm happy to continue to offer hosting services to the OLPC volunteer community but (at a minimum) we need to do that on a much smaller number of machines so we can pay attention to them.</div><div><br></div><div>4. <b>Suggested&nbsp;VIG&nbsp;Transition</b>&nbsp;-&nbsp;It&nbsp;seems&nbsp;to&nbsp;me&nbsp;that&nbsp;the&nbsp;combination&nbsp;of&nbsp;3(b)&nbsp;and&nbsp;2&nbsp;above&nbsp;suggests&nbsp;an&nbsp;opportunity&nbsp;to&nbsp;more&nbsp;clearly&nbsp;focus&nbsp;the&nbsp;VIG's&nbsp;efforts&nbsp;on&nbsp;the&nbsp;wider&nbsp;OLPC&nbsp;volunteer&nbsp;community,&nbsp;and&nbsp;to&nbsp;do&nbsp;so&nbsp;in&nbsp;a&nbsp;more&nbsp;structured&nbsp;manner.&nbsp;&nbsp;This&nbsp;would&nbsp;suggest&nbsp;something&nbsp;like:</div><div><br></div><div>a.&nbsp;The&nbsp;designation&nbsp;of&nbsp;some&nbsp;small&nbsp;number&nbsp;of&nbsp;physical&nbsp;servers&nbsp;to&nbsp;be&nbsp;allocated&nbsp;to&nbsp;VIG&nbsp;management&nbsp;for&nbsp;VIG-initiated&nbsp;and&nbsp;VIG-coordinated&nbsp;projects&nbsp;and&nbsp;services.&nbsp;&nbsp;These&nbsp;machines&nbsp;would&nbsp;be&nbsp;(as&nbsp;much&nbsp;as&nbsp;practical)&nbsp;under&nbsp;the&nbsp;management&nbsp;of&nbsp;the&nbsp;VIG&nbsp;to&nbsp;support&nbsp;the&nbsp;broader&nbsp;OLPC&nbsp;community,&nbsp;and&nbsp;Chris&nbsp;and&nbsp;I&nbsp;would&nbsp;pay&nbsp;little&nbsp;attention&nbsp;to&nbsp;them.</div><div><br></div><div>b.&nbsp;The&nbsp;VIG&nbsp;would&nbsp;more&nbsp;clearly&nbsp;not&nbsp;be&nbsp;responsible&nbsp;for&nbsp;"internal"&nbsp;OLPC&nbsp;systems&nbsp;management&nbsp;tasks,&nbsp;such&nbsp;as&nbsp;our&nbsp;public&nbsp;wiki,&nbsp;mailing&nbsp;services,&nbsp;MySQL&nbsp;configurations,&nbsp;build machine hosting, etc. &nbsp;As far as I can tell this is really a formalization of a change that's already happened, since there's been very little VIG activity on these topics lately.</div><div><br></div><div>c. We would create a formal relationship between the VIG and the senior OLPC staff member responsible for systems and services (currently me) . &nbsp;That might be the secretary of the VIG or some new "coordinator" role - I would leave that process up to the VIG community to decide. &nbsp;These two people would be responsible for all VIG-OLPC communication and coordination. &nbsp;If we successfully decouple the two systems management efforts (internal "OLPC" and external "VIG") then we should be able to narrow the need for communication so that two people can handle it easily.</div><div><br></div><div><b>Summary</b>&nbsp;- I would like to help the VIG succeed better in the OLPC world of 2009 and beyond, and I need to be more comfortable that OLPC's internal systems management is going in the direction I need, while minimizing the risk that well-intentioned people end up stepping on each others' toes and breaking things (or working at cross-purposes). &nbsp;I'm very open to tweaks to the above suggestions or completely new suggestions. &nbsp;Please let me know what you think, and thanks very much for your past and future help!</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Ed</div></body></html>