[Server-devel] [XSCE]

Sat Oct 12 12:25:42 EDT 2013

I can also give my personal opinion. Responses inline.

On Sat, Oct 12, 2013 at 8:54 AM, Tim Moody <tim at timmoody.com> wrote:

> Everyone will be shy to respond, but here's my take.  First, the
> motivation is that the benefit of a school server, especially in non or
> occasionally connected environments, is assumed.  Secondly, let's be clear
> that you asked about goals, not what we've accomplished.
>
> The goal of the XSCE project is to continue development of the OLPC XS
> project along the following lines:
>
> 1. Absorb features from all the various incarnations of XS including 0.7,
> Nepal, Australia, and any others and make it available on a variety of
> platforms including intel, but also incredibly cheap and incredibly low
> power devices, such as the XO but also raspi, trimslice, cubox, and others
> as they come to market.  These features fall into three broad categories,
> infrastructure such as routing, support for XO specific services, and
> general (web) server based applications and content.
>
> 2. Move installation and configuration from something that happens along
> with the OS installation to something an end user could do using a gui
> whenever she likes, if required.
>
> 3. Provide a mechanism whereby features can be contributed by interested
> members of the community without rebuilding a disk image or an rpm.
>
>
I had contacted various deployments over the summer, and through
conversations with them, compiled a list of considerations:

https://sugardextrose.org/projects/xsce/wiki/primary_considerations

> Answers to specific questions below.
>
>  -----Original Message----- From: Tony Anderson Sent: Friday, October 11,
>> 2013 11:10 AM To: xsce-devel at googlegroups.com Subject: Re: [XSCE]
>>
>> Hi, All
>>
>> Help me understand a little about where this project is going.
>>
>> I understood XSCE initially as an attempt to use an XO as the school
>> server. This was motivated by two requirements: (1) support for deployments
>> which were constrained to use XO and (2) use of the XO-1.75 as the school
>> server to enable use of the lower power ARM architecture.
>>
>>
and also make use of various other low power ARM hardware, like trimslice,
etc.

There is no "constraint", that the XSCE is limited to just these platforms.
It is intended to run on generic x86 equally well.

>  Apparently one outcome is that the XS-0.7 install procedure was replaced
>> by a requirement to add school server capabilities to a previously
>> installed build (e.g. 13.2).
>>
>> The XS architecture separated the disk into two partitions: root and
>> library. The intent was to separate software (root) from content (library).
>> This would support backup of the library partition since the root partition
>> could be restored by a new install followed by simple copy of the backup to
>> the library partition. Does XSCE maintain this architecture?
>>
>
> XSCE requires that the OS be pre-installed, so the disk partitioning is a
> priori.  However, some of us have encouraged people to place content in the
> /library directory so that it can take advantage of a separate partition if
> there is one.  It would certainly be possible to mount external devices as
> /library.
>
>
>
>> The XO build is installed as a copy of an image from a usb drive to the
>> internal store.
>>
>
> Work is being done on this installation mechanism, but up to now server
> content has been installed as an rpm, which has dependencies on other rpms
> and scripts to do various work like configuring networking, etc.  The
> repositories can be remote or local.  The new ansible install still
> operates at the time of initial installation, but avoids having to build
> rpms and holds the promise of incremental configuration.
>
>
>> The XS install is a normal OS install in which a minimal Linux OS
>> executes a script from a ramdisk to access the USB flash drive, decompress
>> files and to copy them to the newly created partitions.
>>
>> Apparently, XSCE is installed by the previously installed OS (13.2). What
>> is the dependency of XSCE on this OS? Does the XSCE install replace it?
>>
>
> In the rpm and ansible scenarios it does not replace the OS on the XO or
> any other device.
>
>
>> Naturally, the XO software build is for a client machine. It is based on
>> graphical user interface, keyboard, and track pad.
>>
>> A server is intended to supply services to other computers (clients) via
>> a network. As such, it is intended to be operated headless. Control of the
>> server is normally by a remote login and command line operations.
>>
>> How does XSCE handle the change from a client machine to a server? Does
>> it require a monitor and keyboard (or touchscreen)?
>>
>
> Like XS, XSCE requires a monitor and keyboard (built into the XO) for
> installation, but can be basically headless thereafter.  Most of us turn on
> sshd and do the entire install remotely.  Probably other devices can come
> up with sshd capability already on and be entirely headless, if you can
> figure out their ip address.
>
>
+1 The intent is to install and update on headless hardware.

>
>> There is discussion of a home page. In XS-0.7 there is no home page. The
>> only way to interact with the server is via ssh. Is this home page in XSCE
>> the portal to a web site supported by XSCE or an administrative interface
>> to XSCE?
>>
>
> My experience of XS is that the home page is moodle.  I have been working
> on a high level home page aimed at end users from which there would be
> links to installed services.  It is intended to support local languages.
>
>
>
>> For historical reasons, server administration is done in English (similar
>> to the fact that air traffic control is done in English).
>> I assume from this that a multi-language home page is the home page of a
>> web site on the server, not server administration.
>>
>
> yes.  however, several web-based administration tools are in the works.
>
>
In Dextrose Server (downstream of XSCE), we are experimenting with Ajenti (
http://ajenti.org/). It is written in python, and allows easy
addition/removal/configuration of plugins. So far, things look promising.
We even experimented with network bandwidth throttling, which is configured
through Ajenti (on the frontend), and uses wondershaper
http://lartc.org/wondershaper/ (as a backend). We hope to upstream these to
XSCE in this development cycle.

Here's a link to a slightly dated and choppy video demonstrating Ajenti on
a XO-1.75 school server. We are working to remove all unnecessary modules,
fix bugs and speed it up since then. The good news is that the upstream
Ajenti developer is extremely responsive.
http://www.youtube.com/watch?v=-LbPRVc5Bv4&feature=share&t=2m35s

>
>
>> There has been much discussion of Ansible (vs Puppet). Is Ansible
>> intended as a means to implement the build process for XSCE or as a means
>> to implement and customize the install of XSCE or as a means to administer
>> an XSCE installation?
>>
>
> The implementer of ansible cleverly added an rpm build mechanism, but it
> is really aimed at installation, and, I hope, eventually at administration,
> either remote or local.
>
>
+1. rpm has been provided as a simple way to get started. After that
ansible takes over, installation, configuration and updating.

>
>> The general philosophy of XS is to build a single installable version of
>> the software (currently XS-0.7). After installation, scripts are
>> provided to configure the software, primarily to match the local network.
>>
>> I think the assumption is that the server has ample disk capacity so that
>> there is no need to limit the installed software packages to those that the
>> deployment actually uses. For example, Moodle is installed but rarely used.
>> XS-0.7 sets up a root partition of 8GB and the rest of the available
>> capacity is given to the library partion.
>>
>> It is certainly understandable that this assumption would not apply to a
>> school server based on an XO laptop.
>>
>> However, it has always been clear that the XO is a terrible choice for a
>> server platform to be used only as a last resort. The primary reason for a
>> school server is to give access to content beyond the limited capacity of
>> the XO.
>>
>> Even though the OLPC project is intended to address the problem of the
>> 'digital divide', many developers seem to assume that deployed XOs have the
>> same access to the internet as they themselves have. Even if a school has a
>> DSL line shared by 100 XOs, that is not the same as a developer with access
>> to a broadband network shared among a handful of users.
>>
>> I think it is important that the XSCE project define its goals and
>> assumptions clearly.
>>
>> In the case of the XS-0.7, the assumptions are that the deployment has
>> limited or no access to the internet, that it has a school server with
>> large disk capacity, the server can support a local wifi network, the
>> server can operate without system administration (essentially unattended
>> except for power on and power off) for a full school year, the server can
>> share internet access when connected to a WAN (ISP) with the XOs connected
>> on the local network, and that the software on the school server be stable
>> and updated at most once between school sessions.
>>
>
> I think the XSCE community assumes that all of the above represents the
> most common scenario.  I grant that the requirement for large disk
> capacity, which I know you take to be axiomatic, is not met by all of our
> target platforms in ways that we find satisfactory yet.
>
>

>
>> Tony
>>
>>
>>
Anish

>  On 10/11/2013 09:58 AM, George Hunt wrote:
>>
>>> for Haiti, I just disabled multiviews in
>>> /etc/httpd/conf.d/xs-portal.**conf (commented out)
>>>
>>>
>>> On Fri, Oct 11, 2013 at 9:14 AM, Tim Moody <tim at timmoody.com
>>> <mailto:tim at timmoody.com>> wrote:
>>>
>>>     just before I left for travels there were problems at the Haiti
>>>     deployment with the multilingual home page I put together.  Can
>>>     someone summarize where that currently stands?  Was it simply
>>>     commented out and not used?  I want to sort this out.
>>>
>>>
>>>
>>
> --
> Sig inserted by AutoHotkey ver. 1.1.11.01 (signature - first line)
> WLMail QuoteFix -> http://www.dusko-lolic.from.**hr/<http://www.dusko-lolic.from.hr/>(signature - second line)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20131012/3fd588ae/attachment.html>