[Sugar-devel] Sugar-Server enhancement

James Cameron quozl at laptop.org
Thu Apr 14 20:16:11 EDT 2016


Good summary, Manash.

1.  a UUID is generated when an OLPC XO laptop is manufactured, then
stored in our database and used in our cryptographic firmware security
anti-theft feature [1], but for non-OLPC devices it is generated by
Sugar, and I've no idea how the server itself uses it,

2.  perhaps create_profile() function in src/jarabe/intro/window.py,
and take note that it uses key type DSA which is now considered weak,

3.  yes, the Network control panel could be simplified in that way,

4.  use JSON, since we already use JSON in Sugar, and adding Sqlite3
would be adding a new dependency.

Will you be starting a Feature page on the Wiki?  See [2].


References

1.  http://wiki.laptop.org/go/Firmware_security

2.  http://wiki.sugarlabs.org/go/Features/Policy

On Thu, Apr 14, 2016 at 05:41:00PM +0530, Manash Raja wrote:
> 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" )
> 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" )
> 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 <[1]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 <[2]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 [3]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
>                                     <[4]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
>                         [5]Sugar-devel at lists.sugarlabs.org
>                         [6]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
>                 _______________________________________________
>                 Sugar-devel mailing list
>                 [7]Sugar-devel at lists.sugarlabs.org
>                 [8]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
>             --
>             James Cameron
>             [9]http://quozl.netrek.org/
>             _______________________________________________
>             Sugar-devel mailing list
>             [10]Sugar-devel at lists.sugarlabs.org
>             [11]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
>         _______________________________________________
>         Sugar-devel mailing list
>         [12]Sugar-devel at lists.sugarlabs.org
>         [13]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
>     _______________________________________________
>     Sugar-devel mailing list
>     [14]Sugar-devel at lists.sugarlabs.org
>     [15]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> References:
> 
> [1] mailto:tony_anderson at usa.net
> [2] mailto:quozl at laptop.org
> [3] http://dev.laptop.org/git/users/quozl/ds-backup/
> [4] mailto:quozl at laptop.org
> [5] mailto:Sugar-devel at lists.sugarlabs.org
> [6] http://lists.sugarlabs.org/listinfo/sugar-devel
> [7] mailto:Sugar-devel at lists.sugarlabs.org
> [8] http://lists.sugarlabs.org/listinfo/sugar-devel
> [9] http://quozl.netrek.org/
> [10] mailto:Sugar-devel at lists.sugarlabs.org
> [11] http://lists.sugarlabs.org/listinfo/sugar-devel
> [12] mailto:Sugar-devel at lists.sugarlabs.org
> [13] http://lists.sugarlabs.org/listinfo/sugar-devel
> [14] mailto:Sugar-devel at lists.sugarlabs.org
> [15] 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/


More information about the Sugar-devel mailing list