Problem 1: 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 https://bugs.sugarlabs.org/ticket/362. Manash is proposing to fix that.
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") 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. Background as I see it: Problem 2: 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. 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. Problem 3: 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. (1) https://wiki.sugarlabs.org/go/Features/Multiple_schoolserver_registration (2) https://github.com/XSCE/xsce/blob/master/roles/authserver/tasks/main.yml On Wed, Apr 13, 2016 at 5:30 PM, Adam Holt <h...@laptop.org> wrote: > On Wed, Apr 13, 2016 at 8:17 PM, Tony Anderson <tony_ander...@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. > > Likewise there are definitely teachers who work in multiple schools, and > need to bring their main XO to each school, impressive! > > 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. > > 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 :}* > > >> 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 <qu...@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-de...@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 ! >> >
_______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
