[Sugar-devel] Sugar-Server enhancement
Manash Raja
mpdmanash at gmail.com
Thu Apr 14 08:11:00 EDT 2016
Hi all,
Thanks for the guidance :) .
I would like to get started on this enhancement now according to the
discussions.
As far as I understand, the present flow is this: (please have a look at
attached "sugar-server-present.png" )
[image: Inline image 1]
ds-backup performs its function in some of the systems that include it.
Sugar just has to ensure that 'backup-url' and 'jabber-server' schemas,
files in ~.sugar/default/identifiers contain proper server information and
ssh known_hosts do not produce conflicts.
To make sugar connect with any XS server smoothly and easily, I think the
following flow will work: (please have a look at attached
"sugar-server-modified.png" )
[image: Inline image 2]
Please correct me if I am wrong.
The main advantages of the above flow according to me are:
1. Manual clear of registration is not required.
2. Each laptop will have same backup url and backup path (in
XS:/library/users) for a particular XS as it was created on first
registration with the server. As registration will be done only once. The
"Register" button would rather say "Connect to Server". When user connects
to an XS where it has registered previously (identified by the presence of
pubkey), it would simply set its serial number, uuid and backup-url with
the pre-registration data. This would enable better and advanced management
of backups.
3. No extra input is required from the user. The user just has to
connect to the XS server ssid and specify the jabber-server address as
before.
So, I guess this flow will let a user hop between multiple XS servers very
easily. :)
And @Jerry as Tony mentioned, I would like to add-on that, as I am
interested to take the sugar-server interaction further on Tony's idea of
remote datastore, and cloud integration (including ownCloud and third party
services as available) and hence have submitted the GSoC proposal for the
same.
A few doubts that I have:
1. What is the use of uuid? And where is it used in XS server side?
2. Who generates the pk_hash for XS server, is the server itself or
sugar? I found it to be unique to a laptop like the pubkey.
3. Should the Jabber server entry be moved to a new section "Server" in
control panel to reorganize it a bit and provide the place for further
server settings?
4. If the above flow is implemented and we need to store the uuid(s) for
serial numbers, then should it be stored in a sqlite3 db or in a file with
json format?
Thanks
On Thu, Apr 14, 2016 at 2:09 PM, Tony Anderson <tony_anderson at usa.net>
wrote:
> Jerry
>
> Yes, of course. At the moment, it is proposed for implementation in the
> GSOC. The use of OwnCLoud is a possibility. Currently, it is down by backup
> to
> the /library/users via sftp by a customized version of ds_backup. OwnCloud
> might make the process more visible and more useful to the user.
>
> Tony
>
>
> On 04/14/2016 10:15 AM, Jerry Vonau wrote:
>
>> Tony,
>>
>> What about your remote datastore that you were taking about? What was the
>> owncloud integration that you were talking about? Is that not a way of
>> backing up some data?
>>
>> On April 13, 2016 at 8:07 PM James Cameron <quozl at laptop.org> wrote:
>>>
>>>
>>> On Thu, Apr 14, 2016 at 08:39:10AM +0800, Tony Anderson wrote:
>>>
>>>> Hi, James
>>>>
>>>> Deployments without a school server obviously do not use the backup.
>>>> Deployments without access to the internet vie GSM do not
>>>> use that support either.
>>>>
>>>> I suppose ds_backup.sh and ds_backup.py come from the tooth fairy
>>>> and not from flashing a Sugar image.
>>>>
>>> They come from OLPC. You just happen to be using OLPC OS. So it
>>> isn't relevant to Sugar Labs, unless Sugar Labs decide to adopt the
>>> ds-backup package. I'm fine if they do, but so far they haven't.
>>>
>>> By way of packaging for the distros or integration in sugar.
>>
>>
>>> The server software was developed for Fedora systems for the same
>>>> reason Sugar was developed for Fedora systems. I don't see the
>>>> relevance.
>>>>
>>> I'm not talking about the server software, I'm talking about the
>>> ds-backup glue between them.
>>>
>>> Maintenance of this software has been assumed by xsce. The closest
>>>> version to the original is the CentOS image, a much more stable
>>>> option.
>>>>
>>> XSCE has not assumed maintenance of the ds-backup glue. Why not?
>>>
>>> Well for the server side George has with a revised rpm, for the change to
>> Apache-2.4.
>>
>> Jerry
>>
>>
>>> You are wrong about the ssh-keygen. That is done by the idmgr at
>>>> registration time. The removal of the known_hosts results from the
>>>> configuration of the
>>>> server to check known_hosts. This problem must be resolved before
>>>> registration can occur.
>>>>
>>> No, you are wrong about "ssh-keygen -R", it is used to remove a single
>>> entry from a known_hosts file.
>>>
>>> Tony
>>>>
>>>> On 04/14/2016 08:13 AM, James Cameron wrote:
>>>>
>>>>> Manash, registration sets Jabber server and backup server, and for
>>>>> some systems the backup server is not used.
>>>>>
>>>>> For those systems like Tony's where the backup server is used, please
>>>>> review http://dev.laptop.org/git/users/quozl/ds-backup/ which is the
>>>>> software responsible for doing backups to the server. It is not part
>>>>> of Sugar, but then neither is the server. It is designed for Fedora
>>>>> systems, and was last updated for OLPC OS. There are no other uses of
>>>>> this software known. It is not packaged in SoaS or Ubuntu.
>>>>>
>>>>> The ds-backup software fails if the backup server is changed, because
>>>>> of the changed host key of the server.
>>>>>
>>>>> While Tony's workaround is functional, it is also destructive. A more
>>>>> correct solution is to use "ssh-keygen -R" option to remove the key,
>>>>> or add SSH options to avoid the key conflict.
>>>>>
>>>>> #362
>>>>>
>>>>> On Thu, Apr 14, 2016 at 07:50:17AM +0800, Tony Anderson wrote:
>>>>>
>>>>>> OLE Nepal has from the beginning registered the server at each
>>>>>> connection eliminating the registration option from the main menu. A
>>>>>> second registration recognizes that the laptop is registered and
>>>>>> takes no action.
>>>>>>
>>>>>> Moving from one server to another causes a 'known hosts' issue. This
>>>>>> can be cleared by 'rm -rf ~/.ssh/known_hosts.'
>>>>>>
>>>>>> While registering does show the server in the network section (and
>>>>>> clearing the entry enables registration - needed before registration
>>>>>> again), the registration
>>>>>> process sets up the /library/users directory for the laptop serial
>>>>>> number and thus enables Journal backup.
>>>>>>
>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>> Sugar-devel mailing list
>>>> Sugar-devel at lists.sugarlabs.org
>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>
>>> --
>>> James Cameron
>>> http://quozl.netrek.org/
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160414/462052d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sugar-server-present.png
Type: image/png
Size: 119002 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160414/462052d4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sugar-server-modified.png
Type: image/png
Size: 146947 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160414/462052d4/attachment-0003.png>
More information about the Sugar-devel
mailing list