<div dir="ltr">Problem 1:<div>Sugar now has a "register again" which I have only used to connect to the same server. I guess that it's hard to do a ssh connection to a different server (same IP) without ssh complaining about a possible man in the middle attack. This is the situation described in <a href="https://bugs.sugarlabs.org/ticket/362" target="_blank">https://bugs.sugarlabs.org/ticket/362</a>. Manash is proposing to fix that.</div><div><br></div><div>When I read the flow chart at (1) I don't know whether it will work. Port 5000 is not a jabber server (see 2). The Authserver at (2) was written by activitycentral, I don't know gunicorn or flask, I have not been able to understand how it works, and I've never successfully interfaced with it.  So it makes sense to try to use port 5000.  Whether it will provide a list of connected clients? I'm not sure (jabber seems more appropriate).  Maybe some on this list can suggest a easy jabber client/library (nothing hit me when I googled "python jabber client")</div><div><br></div><div>I'd be willing to join in a larger effort to address the problem Tony is pointing out.  But maybe we should let Manash fix bug 362 as a well defined task before we tackle  problems 2 and 3 below.<br><div><br><div>Background as I see it:</div><div>Problem 2:</div><div>Contrary to original OLPC assumptions, some user situations have many children per laptop.  Should our server interactions accommodate that need? I think we should try. I think Tony is asking us to move past original basic assumptions.</div><div><br><div>It sounds to me that, with James suggestion about using lightdm, (which I also have played around with), and his knowledge that on SOAS, most of the Activities still work (with username != olpc), we have most of a solution to the multiple identities on a piece of hardware, connected to the single server. I know it's wrong to jump too quickly to implementation, but we could modify the pam module makehomdir to do its normal function, as well as enable lightdm, and disable olpc-dm.<div><br></div><div>Problem 3:</div><div>A very small number of XO's are used in a school server setting I think. Even so, any elastic boundary between local and server journal data store may make sense. I've heard Tony's idea about needing a journal "keep" flag for years. And I think it's a good one. But putting it on the details page, and not changing all the documentation relating to "favorites" flag, also makes sense. Once we have identities unique and defined (solve problem 1 and 2), I think Tony already has working code that solves problem 3.</div><div><br></div><div>(1) <a href="https://wiki.sugarlabs.org/go/Features/Multiple_schoolserver_registration">https://wiki.sugarlabs.org/go/Features/Multiple_schoolserver_registration</a></div><div>(2) <a href="https://github.com/XSCE/xsce/blob/master/roles/authserver/tasks/main.yml">https://github.com/XSCE/xsce/blob/master/roles/authserver/tasks/main.yml</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 5:30 PM, Adam Holt <span dir="ltr"><<a href="mailto:holt@laptop.org" target="_blank">holt@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">On Wed, Apr 13, 2016 at 8:17 PM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">James<br>
<br>
I can't think of a use case for an XO to access multiple school servers.</blockquote><div><br></div><div>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.<br><br></div><div>Likewise there are definitely teachers who work in multiple schools, and need to bring their main XO to each school, impressive!<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br><br></div><div><i>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><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
The OLE Nepal solution clearly satisfies the requirement to avoid any unnecessary configuration option or 'onboarding' step.<br>
<br>
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.<span><br>
<br>
Tony<br>
<br>
On 04/14/2016 07:35 AM, James Cameron wrote:<br>
</span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Wed, Apr 13, 2016 at 06:13:42PM -0500, Jerry Vonau wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On April 13, 2016 at 5:37 PM James Cameron <<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>> wrote:<br>
<br>
<br>
On Thu, Apr 14, 2016 at 02:44:25AM +0530, Manash Raja wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Jerry,<br>
<br>
     Please don't forget jarabe/desktop/schoolserver.py is involved, I<br>
     personally would prefer that code to be moved into<br>
control-panel/network.<br>
     Others please chime with your thoughts on this one.<br>
<br>
Yes, if register option is brought to network section, then it will<br>
provide<br>
better space for managing multiple different XS servers.<br>
</blockquote>
Yes, add registration function to the network section, or move server<br>
to a new section ... but for ease of first-use where only one server<br>
is present, the register option can remain on the main menu.<br>
<br>
(Why do I suggest a new section?  The Network section has become<br>
cluttered with radio device controls, access point cache control,<br>
jabber server, social help, and soon proxy settings.)<br>
<br>
</blockquote>
Wouldn't the backup related fields be more relevant in the backup section<br>
of control-panel? Maybe the 'new' proxy settings could have its own control<br>
panel section also?<br>
</blockquote>
Yes, yes.<br>
<br>
</blockquote>
<br></span><div><div>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel<span><font color="#888888"><br clear="all"><br>-- <br></font></span></a><span><font color="#888888"><div><a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank"></a><div dir="ltr"><a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">Unsung Heroes of OLPC, interviewed live @ </a><a href="http://unleashkids.org" target="_blank">http://unleashkids.org</a> !</div></div>
</font></span></div></div>
</blockquote></div></div></div>
</blockquote></div><br></div></div></div></div></div>