[Server-devel] XSCE Sprint

[Tony Anderson]

Hi,

This is in response to your comments.

There have been recent conversations with the Trimslice manufacturer, to
get a version which has 2-4GB memory, quad core processor, and 2 ethernet
connections.

Great! It appears comparable products based on the new Intel Atom chips 
may not be available until mid-2014. Naturally Intel's focus is on the 
mobile market. David Leeming has been using a server for the car market; 
however, I have not been able to find a vendor in the US (or Europe). 
The MSI is designed for home theater applications; hence, it has 
graphics hardware to support HDMI at 1080p. This is irrelevant to the 
server application - but provides enough demand to make relatively 
inexpensive hardware available.

Technically, I think the SOC chips are the best bet going forward (ARM 
or 386 ISA).
>
>> >My urgent concerns are:
>> >
>> >1 - An effective way to organize the digital library so that kids are
>> >attracted to find items they would like to download.
>> >
> We hope that we can evolve, and incorporate Pathagar for this in the short
> term.  I've asked if there are other  open source alternatives, and not
> gotten any viable suggestions. Seth insists that Pathagar is only going to
> work for books. I'd like a multimedia warehouse.

Pathagar is based on Django. The digital library on the school servers 
in Rwanda and Lesotho is based on the same technology but supports any 
item with a recognized mime-type. The issue is how to organize the 
contents so that it can be easily accessed. I think the index needs to 
be based on tags (e.g. English, short story, suitable for ESL learners 
ages 8-10, and so). The International Children's Digital Library is the 
best example I've seen - especially the 'simple search' screen. The IIAB 
only makes the problem more urgent.
>
>> >2 - Provide for a shared printer attached to the server which serv- es all
>> >of the XOs but gives the teachers and administrators control over the use
>> >of expean andible resources.
>> >
> Just looking at low hanging fruit --  What do you think of a PHP file on
> the XSCE web server to initiate a file upload, and using Browse Activity to
> extract Journal entries? We could have these uploaded files dropped into a
> directory where the teacher could trigger a print job.  There may be  a
> client/server interface in CUPS which lets the teacher administer, and
> trigger print jobs, from her own laptop.
>
This is the approach I am looking for. One concern is to enable the XO 
to access the printer without having to install print driver software.
>
>> >3 - an implementation of Puppet or similar technology to allow update of
>> >the XOs - supporting mix of XO-1 to XO-4, providing for reflash as well as
>> >updates (something like Nandblaster). This should work equally well for
>> >locked and unlocked XOs.
>> >
> I'm not sure how to achieve these objectives. We have been exploring
> another package very similar to puppet, ansible, might be able to achieve
> the same outcomes, and be simpler to administer.  Reflashing seems very
> different from in-place upgrading.
>
> Both puppet, and ansible, require root access permissions, and a
> functioning operating system.  If the target machine has broken software, I
> don't see an easy alternative than to reflash with a signed image, just to
> verify the hardware.
>

The flash level needs to be handled by the firmware. I believe the 
firmware is capable of obtaining the image from a network. This is where 
the 'lock' is invoked so the trick will be to find out how to do this 
for locked XOs.

Currently major releases are signed. My current strategy is to install 
the major release and then customize it afterwards.

The major difference is that at firmware time you are dealing with a 
byte for byte copy to the local store. After boot, you can use file 
system techniques to customize/update.

My impression of your ansible strategy is that it is to update the 
server from a mothership, not an XO from the school server.

>> >6 - support for GSM modems and wifi dongles on the school server. This is
>> >minor, but network configuration for this has to be done at the command
>> >line (no gui network manager). More important is a model for 'ET call home'
>> >for the school server. I believe in our deployments, the internet model is
>> >going to be more 'batch' jobs than online surfing. We all have experienced
>> >what happens when 100 users try to share a single DSL line. The school
>> >server will most often be using a DHCP lease from the ISP.
>> >
> The "ET call home" need is pretty well covered by openvpn, which has been
> used in India, and Haiti, for remote monitoring and support.  The
> configuration of GSM modems seems problematic, because each country, and
> often each provider within a country, requires different "wvdial" (the
> command line auto-dialer) settings. But we can provide better
> documentation, and simple scripts to run every hour to keep the 3g
> connection open, and restart the vpn (virtual Private Network) tunnel when
> it goes down.

The ET call home is needed to get the IP address of the school server as 
provided by the ISP through DHCP. Once that is available openvpn, scp, 
ssh, etc will work. My primary concern is not monitoring but for 
updating content, interchanging email, rss feeds, and so on. So the work 
is less on how the connection gets established, but what happens after 
it gets established.

I don't think continuous connection is necessary or desirable. Many 
schools will pay for internet access by the Megabyte or by connect time 
(or both). Therefore, the model should be a call from ET, exchange of 
pleasantries, and then disconnect.
>
>> >7 - default configuration of the second network port with a fixed IP
>> >address would be very handy for support. The idea would to enable an XO to
>> >connect via a ethernet cable (USB to ethernet at the XO and possibly also
>> >at the server) to do ssh for rescue. Currently, if the server cannot be
>> >accessed via the router because of DHCP problems, you have to find a
>> >monitor and keyboard to login.
>> >
>
> The XSCE attempts to make sure that very early in the install process the
> lan adapter is set to the 172.18.96.1 ip address, and the default admin
> user is available for ssh (secure shell remote connection) , to address
> this issue.
>

The point here is that the school server architecture has two ports: LAN 
and WAN. The WAN is used to access the internet and the LAN to serve the 
XOs. I realize that the XSCE community has a model in which the school 
server is a peer in the LAN network, but this model is much more 
complicated to support and really (IMHO) should be avoided where possible.

So in this case, what I suggesting is that the default WAN port should 
be configured as an emergency SSH access by default and then 
reconfigured for the ISP when one is available. The primary use of this 
port would be when, for an unknown reason, the DHCP server on the school 
does not start. This port would give a wired access by SSH from an XO. A 
technical quibble, XS is set up correctly so that remote login as root 
is not possible. An admin account is set up and then the user su to root 
(meaning the user must know two passwords).

The LAN port configuration should be fixed (172.18.0.1) with host name 
schoolserver and no domain. Even if a school has two schoolservers (e.g. 
the Rwanda school with 4000 students), the choice of school server to 
connect is made by the router (e.g. schoolnet1, schoolnet2, ...) and so 
each schoolserver's LAN setup can be the same.
>> >
>> >
>> >
>> >Frankly, the server software has been quite functional and stable since
>> >XO-0.4. Daniel Drake solved the urgent problem of being dependent on
>> >unsupported software with the move to CentOs in XS-0.7.
>> >
>> >
> My hope is that XSCE can approach the stability you speak of in earlier
> versions, (we're not there yet), but be able to combine the contributions
> of many minds, and many people's efforts.
>
One option is to follow Daniel Drake's build based on Fedora Arm 
repositories. Abhishek and I were able to do that in Nepal last year.
The goal then was to have a way to build XS-0.7 offline from the 
internet (a still necessary capability). The process was not bug-free 
but Abhishek was successful. The result would be a stable build (albeit 
the Fedora ARM repositories may introduce some issues) with all of the 
capabilities of XS-0.7.

Tony
>
>> >Yours,
>> >
>> >Tony
>> >
>> >