[Server-devel] Who wrote http://wiki.laptop.org/go/XS_Install_Server?
sverma at sfsu.edu
Sat Feb 4 21:36:28 EST 2012
On Sat, Feb 4, 2012 at 1:34 PM, Tim Moody <timmoody at sympatico.ca> wrote:
> George, et. al.,
> When I think about how to improve the XS installation process it seems to me
> that separating the linux install from the XS packages is a good idea.
> Ideally you would install the latest distro (probably of fedora) using the
> minimal kickstart file plus packages needed by the xs, such as httpd, in
> order to get the best hardware support, and then afterwards use yum or some
> automated process to install the actual xs packages. I like the way XS-AU
> has created a package group for the xs; the standard kickstart file mixes
> things together. I also like installing from something that you can
> actually copy files to without having to burn a new copy, like a USB or the
> network install I experimented with.
+1 on the approach. This is also helpful when looking at nonX86, like
ARM-based servers (plug computers, 1.75 as XS, etc).
> But I wonder how XS servers are actually set up in ongoing deployments, for
> How is the Server typically installed and configured:
> Naive User at an isolated site?
> Expert User at an isolated site?
> Expert User at central location? (This would be my guess.)
> Are there any target Server machines with optical drives that have only a
> CDROM (vs. DVDROM)? (I have machines older than 10 years that have dvd and
> the couple cdroms don't work any more.)
> Are there any target Server machines that cannot boot from USB? (None of my
> old machines can.)
> What XO Services are used:
> Presence/Activation Server?
> Chat Server?
> Activity Server?
> Moodle Content?
> Moodle User Management?
> DHCP/Name Server/Routing?
> Web Access Filtering?
> What do XOs do when there is no server?
These are interesting questions. At the OLPC SF summit in 2011 most of
these came up in the XS session. Interestingly, no one could come up
with an example of a deployment that uses Moodle in production. In
fact, those who thought they use Moodle were simply using the Moodle
UI to admin and backup, etc. and not using the actual LMS piece. I say
this with a heavy bias for Moodle. I use it in my day job every day.
Our entire campus runs on Moodle. My course management, etc. has
improved tremendously, and moving work from one course to the next has
become much easier. However, it is my impression that majority of the
deployments either don't understand Moodle, or don't have the
resources (course material, methodology, training) to get from a
"Apache-only" scenario to a LMS.
The other side to this story is that in deployments where the server
isn't playing a curriculum-focused role, the deployments may really
want a reference-based approach, such as a digital library (like
Pathagar). However, Pathagar is a book server, and only that. It
doesn't have the server admin and backup pieces.
At the summit, Mary Lou Jepsen and a few others pointed out that there
seems to be a need for a turnkey solution (kinda like the XO). A box
that comes preinstalled and ready to go. Needs minimal config, and
that's it, instead of fiddling with network cards and RPMs in the
FWIW we use a LogicSupply box in Jamaica (the same as the one used by
OLPCorps) and all the HW works with XS 0.6. We picked that box because
it was field tested. I know that the Jamaicans have tried using a
beige box, and have run into driver problems with the NIC. With a
tried and tested box, it just works. We also use a FitPC
(discontinued) to run a small deployment in India, but we had run test
installs several times, so we knew everything would just work when the
time came. sure enough, I installed XS 0.6 an hour before jumping on a
plane to India!
I like where this discussion is going, as long as we don't end up with
a bunch of forks.
> What are the impediments to installing XS packages on any arbitrary fedora
> version of python? (if we need to rewrite, should we go to 3.x, rather than
> version of php?
> version of moodle? (is there a reason not to be on 2.x?)
> Finally, have all the deployments rolled the versions that they need and is
> there any impetus to do further upgrades?
> p.s. in answer to your original question, it was I.
>> Message: 1
>> Date: Tue, 31 Jan 2012 14:04:32 -0500
>> From: George Hunt <georgejhunt at gmail.com>
>> To: Jerry Vonau <jvonau at shaw.ca>
>> Cc: server-devel at lists.laptop.org
>> Subject: Re: [Server-devel] Who wrote
>> <CADfCcpXx2rnTH8QXcPpivE59q3wo-nR2MBaKrm892=kBdf0sog at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>> The pointers you gave were just too juicy. I used the olpcxs-pungi.ks to
>> gather fc16. The ISO was 650MB. The ISO pungi generated wanted to do a
>> GUI install even though I specified "text" in the KS.cfg. But the Packages
>> folder did not include any Xorg stuff.
>> I spent time last night trying to understand the structure of the ISO that
>> pungi produces. It turns out that I can probably prune the ISO. In the
>> images folder there's a pxeboot folder which contains initrd.img that has
>> the same md5sum as the initrd.img in the isolinux folder. The pxeboot
>> folder is more than 200MB of the total 650MB ISO and I don't suspect it
>> will be used in our installs. Or . . . Maybe we should include and
>> configure cobbler in our core, and support pxe installs as one of the
>> available options to our customers.
>> Does it make sense to support non-PAE hardware. When I googled PAE, it
>> looks like PAE came out with Pentium Pro. (I think that means we would
>> support 80286 and below). A $60 pogoplug would outperform a 286 and use
>> probably a 10th of the power.
>> What are your thoughts about versioning XS? Martin started working on
>> with the thought that it might become 0.7. I think you started calling
>> rebased version 1.0. Abhishek started versioning his rebase when XS was at
>> 0.4 (now he's up to 0.4.81).
>> My inclination would be to let 0.7 expire without a formal release, and
>> start calling this initiative 0.8 (my observation is that 1.0 is often
>> saved for a significant change in function or stability).
>> I've been thinking that we need an ISO that can be written to CD, for the
>> early bioses that cannot boot from USB, and the early machines that don't
>> come with USB. But for convenience, the 4GB USB should be our install
>> medium of choice.
>> I'd like to experiment whether we can partition a 4 GB USB unto 700MB and
>> 3300MB partitions, mark the smaller active, and then use USBmount to set
>> to do a continuation of the install process after firstboot. Maybe we
>> even have the squashfs look for ks.cfg on the larger partition, and
>> automatically use that as the kickstart specification for the initial
>> install. If we can figure out how to do that we could probably put
>> additional repository there. So much that I don't know. Maybe you know
>> something that would make this impossible...
>> The advantage of this scheme would be easy modification to the build
>> process. Would both the Australia and Nepal needs be served by such a
>> Thinking about facilitating a 64bit XS, the heavy lifting would be in
>> recompiling the XS rpms (I think).
>> My first ISO didn't actually boot successfully. So have some trial and
>> error ahead.
>> The biggest help you can be is to bring your knowledge to bear on my crazy
>> If you have thoughts, shortcuts, code to do XS rpmbuilds, and ideas on
>> testing, both would be necessary, and useful.
> Server-devel mailing list
> Server-devel at lists.laptop.org
More information about the Server-devel