[Sugar-devel] GSoC proposal status

[Tony Anderson]

Hi, Jerry

When I am talking about Sugar, I am referring to 0.106. You will find 
ds-backup.py and ds-backup.sh in /usr/bin. The shell script determines 
whether the
schoolserver is registered and connected and whether a backup is needed 
(> 24hours). This script is apparently executed via 
/usr/lib/systemd/system/ds-backup.service.The rsync is accomplished in 
function rsync_to_xs in ds-backup.py. All of this seems well integrated 
into Sugar.

I don't have a school server with live backup here but my recollection 
is that 3.2.1 last year in Rwanda made snapshots and that they were 
identified by a date field.

I assume the ui interface you mention is the schoolserver gconf 
settings. In any case, the issue is no more complicated than where the 
'nick' is stored.

The user interface is to register the XO and then one can observe that 
the XO via network settings. (a view of the gconf setting). The backups 
are stored in /library/users in a directory named from the XO 
serial-number. I don't believe there is any specific software to support 
restore. The idmgr (create_user) sets up a public/private key pair for 
authentication. A timestamp is stored in /usr/olpc/.sugar/defaults to 
record when the most recent backup was made.

"You are assuming that ds-backup is used. There is now the builtin backup to
usbdrive in the controlpanel, I see no reason that functionality couldn't
be reused with a backend that is not a usbdrive but some network based
storage(GSOC task?). Kind of reminds me of the "Example Workflow for
Via-School-Server Mode"[1] where the connection was a webdav share on the
'schoolserver' Come to think of it that is more of a local/remote journal
layout than a backup service but I'm just using it as an example of a
network filesystem.

Tony,
 From your earlier description of your preferred workflow for the journal,
maybe this is what you are seeking? Not as is but in a general sense? Think
the pictures[1] make a good visual representation of the local/remote
journals and moving objects between them via "CopyTo". Think to be more
effective there should be a "MoveTo" (ArchiveTo?) in the dropdown menu
should this move forward.

At best this 'builtin' is an independent feature. I am not sure why a 
feature in the control panel is considered more built in than the 
registration option.
My hunch is that the Sugar implementers were not even aware of the 
ds-backup capability. I suspect this 'builtin' arose because developers 
were using
usb drives to backup and restore the datastore. In Rwanda, I have used a 
simple backup.sh and restore.sh one-liner that simply copies the 
datastore to usb and copies it back.

The 'workflow' I am referring to is to enable a user to maintain a 
remote repository of his/her Journal and to provides means to keep
the local copy as a cache of work-in-progress. The move to/from is as 
simple as using the existing 'keep' selection. The rest is done 
behind-the-scenes by software and requires no user action. User 
intervention is only needed to manage the local store (the school server 
is assumed to have enough capacity).
This enables control with the granularity of individual Journal objects 
- not complete datastores.

Certainly that builtin workflow could be adapted to a school server. A 
USB drive is essentially a directory (root to the usb). It would be 
trivial to create a corresponding directory on a school server. However, 
the screenshots indicate a more complex interface than using 'keep'.

A second question is how to share Journal objects with other users. This 
description seems to ignore the facilities already in place. A user 
should be able to send a file by existing collaboration support. At the 
moment this is done on a case by case basis using activities which 
handle a give mime_type and collaboration. There is no need to 
distinguish between transfers by mesh or school server. If an XO is 
connected to the school server, collaboration is handled through the 
server (issues with tubes aside). This is essentially invisible to the 
user - the user creates a connection and then uses the 
neighborhood/group views to join and communicate.

I suggested OwnCloud as a purpose built environment for sharing files 
between XOs connected to the same school server (or 'cloud'). OwnCloud 
is already available in XSCE but would need appropriate sysadmin 
configuration. This mechanism has the side benefit of giving users a 
purpose-built control over which files in their 'journal' are to be 
shared with which other users.

A more difficult question is how this workflow is migrated from a 
serial-number system to a username system (implied by SOAS and James 
Cameron's Sugar on Ubuntu). As an example, if the Journal 'bundles' are 
stored in OwnCloud by username, then there needs to be a mapping from XO 
serial number to username.

In many deployments the laptops (XOs) are used by multiple users through 
the day. Having each user under their own username and not 'olpc' would 
help greatly by enabling existing Linux methods to be used. Each user on 
an XO would have their own home directory 
(/usr/home/username/.sugar/defaults etc.).
However many of the folders in /usr/home/olpc would need to be moved to 
common space (e.g. Activities, Library). In this case, one could also 
imagine a common equivalent of the Documents folder which could be 
viewed in the Journal and permit files to be moved to/from the Journal 
using the existing mechanisms.)

Tony

On 02/22/2016 10:24 AM, Jerry Vonau wrote:
> Hi Samuel,
>
>> On February 21, 2016 at 5:56 PM Samuel Greenfeld <samuel at greenfeld.org>
>> wrote:
>>
>>
>> Just for the record:
>>
>> The XO laptop backup mechanism for Sugar creates separate
>> "datastore-YYYY-MM-DD_HH:MM" directories for each backup.
>>
> That is not integrated into sugar(the last time I looked), there is no way
> from the UI to alter any of that parameters stored as gconf keys(that might
> need attention now... gsettings) in the user's profile that used in the
> operation of the service. The rpms were supplied by olpc, these would not
> be normally installed on a non-XO sugar install therefore are not present
> on anything other than an XO. Think sugar is moving beyond XOs and needs
> something better and more universal for all sugar users to use.
>
>> If I recall correctly, the schoolserver also periodically looks through
>> these backups, hardlinks identical items to save space, and prunes
>> backups
>> beyond a set age.
>>
> I don't recall the hardlinking but there is a default of 3 months of
> backups to keep.
>   
>> I wouldn't be against fixing and/or redesigning XO backup & restore, but
>> at
>> least on an XS schoolserver these already are versioned.
>>
> You are assuming that ds-backup is used. There is now the builtin backup to
> usbdrive in the controlpanel, I see no reason that functionality couldn't
> be reused with a backend that is not a usbdrive but some network based
> storage(GSOC task?). Kind of reminds me of the "Example Workflow for
> Via-School-Server Mode"[1] where the connection was a webdav share on the
> 'schoolserver' Come to think of it that is more of a local/remote journal
> layout than a backup service but I'm just using it as an example of a
> network filesystem.
>
> Tony,
>  From your earlier description of your preferred workflow for the journal,
> maybe this is what you are seeking? Not as is but in a general sense? Think
> the pictures[1] make a good visual representation of the local/remote
> journals and moving objects between them via "CopyTo". Think to be more
> effective there should be a "MoveTo" (ArchiveTo?) in the dropdown menu
> should this move forward.
>
>> I have not tried XSCE to see how it handles things.
>>
> Samuel,
> George ported ds-backup to apache2.4, is installed and available for use on
> the XSCE. In testing while olpc-au and activity-central were spearheading
> the XSCE project the service seemed to work the same as what was offered on
> XS's CentOS-6 base. You are welcome to test but I would rather not have to
> carry our own version and be the sole point of support, after all the XSCE
> is a volunteer driven endeavor.
>
> Jerry
>
> 1. https://wiki.sugarlabs.org/go/Features/Transfer_to_many_options
>
>   
>> On Sat, Feb 20, 2016 at 9:40 PM, Tony Anderson <tony_anderson at usa.net>
>> wrote:
>>
> <snipped>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel