[Server-devel] Server-devel Digest, Vol 106, Issue 14

Tony Anderson tony_anderson at usa.net
Thu Apr 14 21:27:59 EDT 2016



On 04/15/2016 12:00 AM, server-devel-request at lists.laptop.org wrote:
> Send Server-devel mailing list submissions to
> 	server-devel at lists.laptop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.laptop.org/listinfo/server-devel
> or, via email, send a message with subject or body 'help' to
> 	server-devel-request at lists.laptop.org
>
> You can reach the person managing the list at
> 	server-devel-owner at lists.laptop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Server-devel digest..."
>
>
> Today's Topics:
>
>     1. Re: [Sugar-devel] Sugar-Server enhancement (Adam Holt)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Apr 2016 20:30:26 -0400
> From: Adam Holt <holt at laptop.org>
> To: Sugar-dev Devel <sugar-devel at lists.sugarlabs.org>,  xsce-devel
> 	<xsce-devel at googlegroups.com>, server-devel
> 	<server-devel at lists.laptop.org>
> Subject: Re: [Server-devel] [Sugar-devel] Sugar-Server enhancement
> Message-ID:
> 	<CAHaBuGcStSVjfjAzTApq5G_W5HtPXfB3i2GD6Vcj7EXsba8aig at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Apr 13, 2016 at 8:17 PM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> James
>>
>> I can't think of a use case for an XO to access multiple school servers.
>
> Apologies am not following all the details of this conversation, but just
> to point out some of our newer work in Haiti will experiment with XO
> laptops moving between different school servers, in off-campus computer
> club(s), librar(ies), and at school, etc.
I don't know why we don't first look at what we have before throwing the 
baby away.
In this scenario, it is only necessary to turn off the known_hosts 
check. We are hit with it
because we give each schoolserver the name schoolserver; hence the 
security concern.
Another obvious approach is to give different schoolservers different names.

> Likewise there are definitely teachers who work in multiple schools, and
> need to bring their main XO to each school, impressive!
I am not sure what you mean by impressive. I assume a consulting teacher 
would
be able to perform 'rm -rf ~/.ssh/known_hosts as needed. This is 
necessary only to
register the laptop or to use ejabberd (ejabberd acts like a chat room 
with all registered users
in the room). Using the XO to browse is not affected.

>
> Also some schools campuses are just too large to tie in all the IT infra
> together, with buildings just too far apart.  So there will be several
> inexpensive school servers likely in these schools, who do not want to
> network their buildings together at this point.

I have never seen this, although we have one school in Rwanda that has a 
big separation
between the primary school building and the secondary school building. 
However, this implies
that the school is large enough to justify a CentOs school server with a 
large hard drive and the purchase of
additional ethernet cable to connect the buildings. Essentially you are 
identifying a possible scenario, not a real one.

>
> Finally George Hunt is advising us on how to construct even more mobile
> servers too, based on a large USB battery packs supporting Raspberry Pi 3
> (or XO-4 or whatever) permitting increasingly ruggedized knowledge hotspots.
>
> *Not sure how we will deal with naming all these different school servers
> coming down the pike, but definitely something to start thinking about now,
> a great question :}*

I don't know how you can make a server more portable than it is now. You 
simply pick it
up and carry it to another site. The use of the built-in wifi as an 
access point makes it possible for
me to demo the NUC with just the box and a power supply.

The biggest needed component is the UPS. If George can arrange to power 
the NUC with a usb charger, there is a huge
array of usb battery devices available on the market.

Naming schoolservers is trivial. Schoolserver was the standard set by 
OLE Nepal (as well as schoolnet for the access point). Typically, there 
is one
schoolserver per network so the user connects to the network and is 
automatically connected to the schoolserver. The schoolserver name is 
part of
the url. Since the user is connected to one device, it can always be 
named schoolserver.

I was toying with the idea of Raspberry Pi servers each with a specific 
content. Using 128GB SD cards, it would take 8 to provide the same 
content as
a 1TB drive. A single CentOS server with 1TB is < $500. If an adequate 
supply of $5 Raspberry Pis were available with 128GB SD cards at $10 and a
wifi dongle for $10, eight of these would cost $200. A given deployment 
may want to add new content by adding a new server. However, then it 
seems that one network would have multiple servers so each would need to 
be named by its content (e.g. OSM, Zim, etc.).

Tony
>> If a school is so large (> 200 XOs), the easy solution is two school
>> servers. However, the XOs access the schoolserver based on SSID and so
>> users can be divided to their own schoolserver by the connection - defining
>> the LAN.
>>
>> The OLE Nepal solution clearly satisfies the requirement to avoid any
>> unnecessary configuration option or 'onboarding' step.
>>
>> The current placement of the code has been working for years. Showing the
>> server in the network section was added at a late release, as I recall
>> because the register menu item disappeared after registration and so a user
>> did not know for sure if the XO was registered. This was later fixed with
>> 'register again' so putting the name in the network section is now
>> redundant.
>>
>> Tony
>>
>> On 04/14/2016 07:35 AM, James Cameron wrote:
>>
>>> On Wed, Apr 13, 2016 at 06:13:42PM -0500, Jerry Vonau wrote:
>>>
>>>> On April 13, 2016 at 5:37 PM James Cameron <quozl at laptop.org> wrote:
>>>>>
>>>>> On Thu, Apr 14, 2016 at 02:44:25AM +0530, Manash Raja wrote:
>>>>>
>>>>>> Hi Jerry,
>>>>>>
>>>>>>       Please don't forget jarabe/desktop/schoolserver.py is involved, I
>>>>>>       personally would prefer that code to be moved into
>>>>>> control-panel/network.
>>>>>>       Others please chime with your thoughts on this one.
>>>>>>
>>>>>> Yes, if register option is brought to network section, then it will
>>>>>> provide
>>>>>> better space for managing multiple different XS servers.
>>>>>>
>>>>> Yes, add registration function to the network section, or move server
>>>>> to a new section ... but for ease of first-use where only one server
>>>>> is present, the register option can remain on the main menu.
>>>>>
>>>>> (Why do I suggest a new section?  The Network section has become
>>>>> cluttered with radio device controls, access point cache control,
>>>>> jabber server, social help, and soon proxy settings.)
>>>>>
>>>>> Wouldn't the backup related fields be more relevant in the backup
>>>> section
>>>> of control-panel? Maybe the 'new' proxy settings could have its own
>>>> control
>>>> panel section also?
>>>>
>>> Yes, yes.
>>>
>>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>> --
>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>> <http://lists.sugarlabs.org/listinfo/sugar-devel>
>> Unsung Heroes of OLPC, interviewed live @
>> <http://lists.sugarlabs.org/listinfo/sugar-devel>http://unleashkids.org !
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20160413/e1b9717e/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Server-devel mailing list
> Server-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel
>
>
> ------------------------------
>
> End of Server-devel Digest, Vol 106, Issue 14
> *********************************************



More information about the Server-devel mailing list