[Server-devel] Who wrote http://wiki.laptop.org/go/XS_Install_Server?

[Tim Moody]

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.

But I wonder how XS servers are actually set up in ongoing deployments, for 
example:

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?
Backup?
DHCP/Name Server/Routing?
Web Access Filtering?
Other?
What do XOs do when there is no server?

What are the impediments to installing XS packages on any arbitrary fedora 
version:

version of python?  (if we need to rewrite, should we go to 3.x, rather than 
2.7?)
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?

Tim

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
> http://wiki.laptop.org/go/XS_Install_Server?
> Message-ID:
> <CADfCcpXx2rnTH8QXcPpivE59q3wo-nR2MBaKrm892=kBdf0sog at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Jerry,
>
> 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 
> not
> 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 
> FC11,
> with the thought that it might become 0.7. I think you started calling 
> your
> 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 
> up
> to do a continuation of the install process after firstboot. Maybe we 
> could
> 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
> structure?
>
> 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
> ideas.
>
> If you have thoughts, shortcuts, code to do XS rpmbuilds, and ideas on
> testing, both would be necessary, and useful.
>
> George