<div dir="ltr">Aside to Tony's remarks below: JerryV & TimM have many details on the likely/imminent upgrade to ownCloud 8 as a part of XSCE 6.1, for those who missed Thursday's meeting (<a href="http://tinyurl.com/xsceminutes">http://tinyurl.com/xsceminutes</a>).<br><br><div><br>From: <b class="gmail_sendername">Tony Anderson</b> <span dir="ltr"><<a href="mailto:tony_anderson@usa.net">tony_anderson@usa.net</a>></span><br><div class="gmail_quote">Date: Fri, Apr 15, 2016 at 8:43 PM<br>Subject: Re: [Sugar-devel] Sugar-Server enhancement<br>To: <a href="mailto:sugar-devel@lists.sugarlabs.org">sugar-devel@lists.sugarlabs.org</a><br><br>
<div bgcolor="#FFFFFF" text="#000000">
Re OwnCloud<br>
<br>
The software is included in xsce; however, the last time I tried it
was not configured. The key in OwnCloud is configuration (db, etc.).
<br>
<br>
One concern I have is that we have a way to authenticate users. We
are growing the number of server 'services' which require a username
and password. <br>
I think we should look into enabling LDAP to provide a common
authentication across the school server. This, of course, gets into
the issue of whether we are authenticating users or device
serial-numbers. My recommendation is small steps - moving the backup
from /library/user/ is not a small step.<span class="HOEnZb"><font color="#888888"><br>
<br>
Tony</font></span><div><div class="h5"><br>
<br>
<div>On 04/16/2016 07:56 AM, Manash Raja
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">@James,<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">1.
you're changing "Register" and "Register again" to "Connect to<br>
server", but it isn't clear in the commit message why it is
necessary;</blockquote>
<div>I felt as "Register" refers to an action done for first
time (Add new laptop entry in the server), while "Register
again" means to redo the same thing (Add another entry of the
same laptop in the server). But now as registration is done
only once, while at other times, Sugar only changes a few
setting to adapt. Hence I felt to keep a constant name
"Connect to server" as it does not bother the user if he/she
if connecting to the server for the first time or otherwise,
as things are taken care of in the background. Just gave a
thought. Nevertheless, it also just say "Register" always.<br>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">please
avoid `ssh-keygen -R` if server is unchanged, because<br>
otherwise a rogue server can be introduced after
registration,<br>
<br>
(Would it be possible to change .ssh/config to add an entry
for each<br>
server? If so, the known_hosts file might not need changing
at all).</blockquote>
<div>I don't know much about the ssh host verification though,
but I am learning it and will come up with something better.
We can edit the .ssh/config file as it doesn't require root
permission. Can you tell me what entry would be there for
each server and do we just have to keep adding or we will
have to manage it also?<br>
<br>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">please check for `os.command()`
failure, which could happen if the<br>
disk is full, </blockquote>
<div>Do you mean '<span>os.system(command)'? <br>
<br>
</span><span></span>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">please
add commit message references to the server-side changes<br>
and invite <a href="mailto:server-devel@lists.laptop.org" target="_blank">server-devel@lists.laptop.org</a>
people with your feature page<br>
and patch.</blockquote>
<div>I didn't do any modification to the server side for
this. Just setup the server with "Services for XO
laptops ...." enabled in the schoolserver admin page.
Though I have added this to my commit message. Updated
commit message: <a href="https://github.com/ManashRaja/sugar/commit/3ad4d847d0f2373d5bfe9f6c8e201b358f3f68e0" target="_blank">https://github.com/ManashRaja/sugar/commit/3ad4d847d0f2373d5bfe9f6c8e201b358f3f68e0</a><br>
<br>
</div>
@Jerry,<br>
</div>
<div>I haven't modified anything for this feature on the
server side. I found that it uses both idmgr and
xs-authserver. But the 5000 port is used by xs-authserver
to display a list of registered laptops. I didn't enable
it myself, it was there. All I did was to setup my server
according to the instructions and enabled the "XO
register" feature from the admin page.<br>
<br>
</div>
<div>@Tony,<br>
</div>
<div>Can you tell me how ownCloud is supported by XSCE? I
saw it in the services ready to be enabled. So can we not
move the storage location of /library/user/<some_id>
inside or account based user directories to the cloud
storage locations.<br>
<br>
</div>
<div>Thanks<br>
</div>
</div>
<br>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Apr 16, 2016 at 3:23 AM,
Jerry Vonau <span dir="ltr"><<a href="mailto:me@jvonau.ca" target="_blank">me@jvonau.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
> On April 15, 2016 at 4:18 PM Manash Raja <<a href="mailto:mpdmanash@gmail.com" target="_blank"></a><a href="mailto:mpdmanash@gmail.com" target="_blank">mpdmanash@gmail.com</a>>
wrote:<br>
><br>
><br>
> Hi all,<br>
><br>
> I fixed the bug. I haven't created a PR just yet.<br>
> <a href="https://github.com/ManashRaja/sugar/commit/660985d2183416cd3ed758095e92adf82f87a10c" rel="noreferrer" target="_blank">https://github.com/ManashRaja/sugar/commit/660985d2183416cd3ed758095e92adf82f87a10c</a><br>
> As of now I am parsing HTML data for json data to
look for registered<br>
> laptops at an XS from the webaddress <a href="http://schoolserver:5000" rel="noreferrer" target="_blank"></a><a href="http://schoolserver:5000" target="_blank">http://schoolserver:5000</a>
that serves<br>
> a<br>
> liist of registered laptops.<br>
<br>
</span>Interesting, 'idmgr' doesn't use port 5000, are you
using 'authserver' on<br>
the XSCE? Little background, idmgr was released by OLPC
while authserver<br>
originates from ActivityCentral's dextrose work. I have no
knowledge of<br>
which method was deployed by what deployment the XSCE
project tries to<br>
cover all deployments' needs, that is why both are
present. Better check<br>
with Walter about using dextrose code, that might be
frowned upon.<br>
<span><br>
> I will modify it if there is another better method
that can be<br>
> implemented<br>
> from the Sugar side (we don't intend to modify the
server side I guess).<br>
><br>
<br>
</span>Think you better plan to work on the server side
also, you'll have a clean<br>
slate to work with.<br>
<span><br>
> And here is the feature page as suggested by James.<br>
> <a href="https://wiki.sugarlabs.org/go/Features/Multi_XS-server_registration" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Features/Multi_XS-server_registration</a><br>
><br>
> Please have a look.<br>
><br>
> I am very excited to be a part of the discussions
that go into the making<br>
> of great features that can affect people down there
in deployment. :)<br>
> There<br>
> is a scope to do so much.<br>
><br>
> Thanks<br>
><br>
<br>
</span><span><font color="#888888">Jerry<br>
</font></span>
<div>
<div><br>
> On Sat, Apr 16, 2016 at 2:32 AM, James Cameron
<<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>>
wrote:<br>
><br>
> > On Fri, Apr 15, 2016 at 04:02:39PM +0800,
Tony Anderson wrote:<br>
> > > Hi, James<br>
> > ><br>
> > > This thread was getting long so I
replied only to the most recent<br>
> > > communication. I am sure you have the
full thread which shows the<br>
> > > scope of the discussion.<br>
> ><br>
> > You're making it longer, yes, by hijacking
it. You can find the full<br>
> > thread here:<br>
> ><br>
> > <a href="http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/archive/sugar-devel/2016-April/thread.html</a><br>
> ><br>
> > > According to trac bug #362 was opened
seven years ago against 0.82<br>
> > > and last looked at three years ago.
Several competent people looked<br>
> > > at it and left comments. I see none
that signify consensus.<br>
> ><br>
> > I take it that you don't want Manash to fix
this bug, thanks.<br>
> ><br>
> > I'd like it fixed. I think there are others
who want it fixed. It<br>
> > would probably help with XS testing as well.<br>
> ><br>
> > > To have a design discussion, it is
valuable to have a proposed<br>
> > > design.<br>
> > ><br>
> > > I have tried to explain my proposal in
detail. If there are<br>
> > > questions, I would be happy to try to
respond. Fixing the 'Journal<br>
> > > is Full' dialog is a major help.
However, what do you recommend to<br>
> > > deployments when this happens?<br>
> ><br>
> > 1. upgrade to Sugar 0.108 (by RPM or
images), or backport the patch<br>
> > [#9623, #1720] into your custom builds,<br>
> ><br>
> > 2. transcode content to play in browser not
Journal,<br>
> ><br>
> > 3. delete any activities that are not
needed,<br>
> ><br>
> > 4. deploy Sugar Network to use the network
activity cache,<br>
> ><br>
> > Also delete the Browse temporary
directories, you reported this on<br>
> > 19th January, it remains a problem, and you
refused to test my fix, so<br>
> > I lost interest very rapidly. [#4931]<br>
> ><br>
> > > The bottom line is that a reasonably
active user is likely to need<br>
> > > more room to store her Journal than is
available on the XO.<br>
> ><br>
> > No, because it's no longer a significant
problem. XO-1 are in the<br>
> > minority and getting rarer as they die.
Those that haven't died have<br>
> > SD cards.<br>
> ><br>
> > > In the Journal code a filled star sets
the 'keep' flag in the<br>
> > > metadata. The cleared star clears the
'keep' flag in the metadata.<br>
> > > Using this feature greatly simplifies
the coding and the Journal<br>
> > > view. As far as I know, the only use of
this at the moment is to<br>
> > > support the Portfolio activity.<br>
> ><br>
> > You are using an implementation detail in
describing the flag. The<br>
> > name given to the flag in documentation and
user interface is<br>
> > "favorite" (sic).<br>
> ><br>
> > > I think the detail view is
inappropriate exactly as it would be to<br>
> > > move the multiple selection checkbox
there. These controls need to<br>
> > > be immediately available.<br>
> ><br>
> > I disagree; they won't get used, and so it
would be a waste of<br>
> > valuable vertical space. The reason the
checkbox won't get used is;<br>
> ><br>
> > - most laptops don't have a server,<br>
> ><br>
> > - an LRU algorithm can maintain the cache
effectively.<br>
> ><br>
> > > The 'backup/sync' script is a good
place to do check storage quotas<br>
> > > because the script needs to touch the
datastore on a regular basis.<br>
> > > It has access to the amount of store in
use and the LRU information.<br>
> > > For example, if the user wants a
document downloaded, the script<br>
> > > knows its size and whether some other
local copies need to be<br>
> > > deleted to make room.<br>
> ><br>
> > I disagree. This script runs infrequently.
The LRU must be<br>
> > implemented inside the datastore for it to
function properly.<br>
> > Otherwise the lag between user action and
response by the script would<br>
> > be too long.<br>
> ><br>
> > > While an implementation detail, so far
no change has been necessary<br>
> > > to the datastore class.<br>
> ><br>
> > That's no reason not to change it.<br>
> ><br>
> > > Actually, since the 'keep' or favorite
star sets the metadata,<br>
> > > so far there has been no need to change
the Journal.<br>
> ><br>
> > That's no reason not to change it.<br>
> ><br>
> > > "The multiple user feature is supported
by Fedora and Sugar, but we<br>
> > > removed it for OLPC OS."<br>
> > ><br>
> > > I think I am beginning to understand.
OLPC OS is your generic name<br>
> > > for the images to be installed on each
model of the XO.<br>
> ><br>
> > Really, you are out of touch! OLPC OS is
our name for the operating<br>
> > system releases on the XO laptop. We've
been using the term at OLPC<br>
> > for a very long time, and use it in each
release announcement.<br>
> ><br>
> > > I am deploying build 13.2.5 with Sugar
0.106 on all models.<br>
> ><br>
> > That's so sad. It was released in July
2015. It has the journal full<br>
> > bug you mentioned. I'm not interested in
supporting that release,<br>
> > because I've already released two others.
Upgrade.<br>
> ><br>
> > > So you are saying that we, users of
Sugar or ' OLPC OS' could have a<br>
> > > multiple user version of Sugar if
'you', as developers, didn't<br>
> > > remove it.<br>
> ><br>
> > Well done.<br>
> ><br>
> > > As I understand it, you propose to
generate unique serial-numbers<br>
> > > per user.<br>
> ><br>
> > No. I was describing what happens _now_
during registration, by<br>
> > reference to the code:<br>
> ><br>
> > 1. for XO laptops the serial number of the
laptop is used,<br>
> ><br>
> > 2. for non-XO laptops a serial number is
generated randomly,<br>
> ><br>
> > 3. there is no attempt to ensure the random
serial number is<br>
> > unique, but the width of the random string
is sufficient to make it<br>
> > unlikely,<br>
> ><br>
> > > So SSO would be guaranteed since no two
users could have<br>
> > > the same serial-number. This would
certainly work and probably<br>
> > > involve very little change to the
existing code. What will be needed<br>
> > > is a 'dns' to map serial-numbers to
usernames.<br>
> ><br>
> > No, I wasn't proposing that. It's your
idea. I don't think it's<br>
> > guaranteed to be unique though.<br>
> ><br>
> > > Every school I have worked with keeps a
careful record of students<br>
> > > (often in paper ledgers). Currently I
provide a name record in a<br>
> > > Django database on the server (along
with an XO inventory by serial<br>
> > > number).<br>
> ><br>
> > Fail to see relevance. Not all schools will
or can do this.<br>
> ><br>
> > > Agreed that determining which Journal
objects need to be saved to<br>
> > > the school server is not a difficult
problem. However, datastore is<br>
> > > a class so each user's datastore and
the common datastore would be<br>
> > > instances. So this seemed like a simple
thing to implement.<br>
> > ><br>
> > > Actually, The deletion of Journal
objects without an associated<br>
> > > document works amazingly well. The
number of objects in the Journal<br>
> > > view goes from hundreds to only a few
(often less than 20).<br>
> > > Moreover, these 20 are the obviously
interesting ones. Nothing is<br>
> > > lost as the metadata is saved to the
school server. It becomes much<br>
> > > easier to 'reflect' when you are only
looking at the documents you<br>
> > > created. Meanwhile the myriad of
objects can be subject to<br>
> > > statistical analysis.<br>
> > ><br>
> > > For many activities, such as the
Terminal, the document saved is<br>
> > > actually 'state' information. This
allows the Terminal activity to<br>
> > > be restored with tabs and pwd. There
are many game activities such<br>
> > > as Memorize that also store state. It
would seem more appropriate to<br>
> > > save this state information in the
metadata. For example, a json<br>
> > > could be created in the metadata to
hold state information. The<br>
> > > script could keep these objects to
enable the user to resume.<br>
> ><br>
> > Your concept of metadata is not of interest
to me; journal objects<br>
> > must continue reflect the learner's use of
the laptop if the journal<br>
> > is to meet the designed style of reflection.<br>
> ><br>
> > Unreflecting adults are not the target user.<br>
> ><br>
> > ><br>
> > > Tony<br>
> > ><br>
> > > On 04/15/2016 01:36 PM, James Cameron
wrote:<br>
> > > >On Fri, Apr 15, 2016 at 10:25:59AM
+0800, Tony Anderson wrote:<br>
> > > >>Hi Manash<br>
> > > >><br>
> > > >>The registration process is
awkward but not the problem.<br>
> > > >This is unfair scope creep. Manash
began by asking about bug #362<br>
> > > >and<br>
> > > >has been working to fix that. Now
you're asking him to consider a<br>
> > > >much larger task; not a coding
task, but a redesign of Sugar Journal<br>
> > > >and Backup interaction. This is
huge.<br>
> > > ><br>
> > > >And as far as I can tell, students
aren't even accepted yet [1].<br>
> > > ><br>
> > > >1. <a href="https://en.wikipedia.org/wiki/Google_Summer_of_Code#2016" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Google_Summer_of_Code#2016</a><br>
> > > ><br>
> > > >What you propose is from a set of
tasks [2] you added to the Wiki,<br>
> > > >which have not undergone any design
review according to Sugar Labs<br>
> > > >design practice and feature
policy. I do not see any consensus on<br>
> > > >these; we're yet to build a
consensus.<br>
> > > ><br>
> > > >2.<br>
> > <a href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_on_the_Ground" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_on_the_Ground</a><br>
> > > ><br>
> > > >Or, it looks like you're trying to
make your own fork of Sugar,<br>
> > > >which<br>
> > > >I'm fine with, it's open source
after all, but to push that on<br>
> > > >others<br>
> > > >without their input is wrong.<br>
> > > ><br>
> > > >If you proceed without consensus as
a sole designer, then OLPC will<br>
> > > >fork Sugar (as we already have so
that XO-1s will go faster), and<br>
> > > >you'll be making your own builds.<br>
> > > ><br>
> > > >>The problem is that rsync is
used to create backups of the Journal<br>
> > > >>and no effective means is
offered to restore.<br>
> > > >Agreed. We have no restore from
server feature in Sugar 0.108,<br>
> > > >along<br>
> > > >with no way to start a backup to
server, and no selective restore.<br>
> > > ><br>
> > > >(We have backup to media, restore
from media, but no selective<br>
> > > >restore from media. Also, restore
from media replaces Journal!)<br>
> > > ><br>
> > > >>However, the ultimate problem
is thinking of the problem as one of<br>
> > > >>backup. If you try to solve the
wrong problem, often the result is<br>
> > > >>a<br>
> > > >>wasted effort.<br>
> > > >><br>
> > > >>The Journal is single place
where Sugar users save their documents.<br>
> > > >>This is done by the Sugar
activities when they close. The majority<br>
> > > >>of XOs are still XO-1s with a
1GB store.<br>
> > > >This point in your argument is
void, because XO-1 are 45% of the XO<br>
> > > >laptops manufactured so far. I
have the numbers.<br>
> > > ><br>
> > > >Also, many XO-1 have been upgraded
with an SD card.<br>
> > > ><br>
> > > >>If the available store is less
than 50GB,<br>
> > > >No, that's 50 MB, not 50 GB. See
_SPACE_TRESHOLD (sic) in<br>
> > >
>sugar:src/jarabe/journal/journalactivity.py [3].<br>
> > > ><br>
> > > >3.<br>
> > <a href="https://github.com/sugarlabs/sugar/blob/master/src/jarabe/journal/journalactivity.py#L56" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/blob/master/src/jarabe/journal/journalactivity.py#L56</a><br>
> > > ><br>
> > > >>Sugar effectively shuts down.<br>
> > > >This point in your argument is
void, because this has been fixed [4,<br>
> > > >5, 6], please upgrade to Sugar
0.108 which is in OLPC OS 13.2.7 [6].<br>
> > > ><br>
> > > >4. <a href="http://dev.laptop.org/ticket/9623" rel="noreferrer" target="_blank">http://dev.laptop.org/ticket/9623</a><br>
> > > >5. <a href="https://bugs.sugarlabs.org/ticket/1720" rel="noreferrer" target="_blank">https://bugs.sugarlabs.org/ticket/1720</a><br>
> > > >6. <a href="http://wiki.laptop.org/go/Release_notes/13.2.7#Fixes" rel="noreferrer" target="_blank">http://wiki.laptop.org/go/Release_notes/13.2.7#Fixes</a><br>
> > > ><br>
> > > >>This typically results in the
deployment reflashing the XO erasing<br>
> > > >>all of the documents created by
that user - a tragedy.<br>
> > > >It was a known bug, so that's a
training issue. You previously<br>
> > > >proposed to train a teacher to use
"rm -rf" to delete a known_hosts<br>
> > > >file instead of Manash coding up an
"ssh-keygen -R" command. It is<br>
> > > >inconsistent to be able to do one
and not the other.<br>
> > > ><br>
> > > >>What I am proposing is to use
the school server as the primary<br>
> > > >>store<br>
> > > >>for the Journal with its
effectively unlimited storage capacity.<br>
> > > >>The<br>
> > > >>ds_backup script needs to read
the datastore uploading any new or<br>
> > > >>modified documents. The local
datastore can then be viewed as a<br>
> > > >>cache for current working
documents.<br>
> > > >I'm favour of this ideal in
principle, but it remains a huge design<br>
> > > >and consensus challenge, not a
coding challenge.<br>
> > > ><br>
> > > >However, with the XO-1, XO-1.5 and
XO-1.75 using IEEE 802.11g the<br>
> > > >local wireless network will
collapse sooner due to this new load.<br>
> > > ><br>
> > > >>On the XO, the datastore is
shown in the Journal. The 'keep' star<br>
> > > >There's no such thing. There's a
favorite star [7]. It has a<br>
> > > >defined<br>
> > > >purpose. Are you proposing to
destroy that purpose, or add another<br>
> > > >column to the journal? There's
even less room now that the multiple<br>
> > > >selection checkbox was added.<br>
> > > ><br>
> > > >7. <a href="https://help.sugarlabs.org/en/journal.html#journal-features" rel="noreferrer" target="_blank">https://help.sugarlabs.org/en/journal.html#journal-features</a><br>
> > > ><br>
> > > >>could be used to show whether
there is a local copy of that<br>
> > > >>document<br>
> > > >>or not. If the document is not
needed locally, the user can clear<br>
> > > >>the star. In this case, the
backup script could delete the local<br>
> > > >>copy. If there is no local copy
of the document, then the user<br>
> > > >>could<br>
> > > >>set the star. In this case the
backup script could download the<br>
> > > >>document.<br>
> > > >My preference would be for the flag
to be in the Journal detail<br>
> > > >view [8], where there is available
display space.<br>
> > > ><br>
> > > >8. <a href="https://help.sugarlabs.org/en/journal.html#journal-detail-view" rel="noreferrer" target="_blank">https://help.sugarlabs.org/en/journal.html#journal-detail-view</a><br>
> > > ><br>
> > > >>This capability could be used
to set a quota on the amount of space<br>
> > > >>used by the Journal. If the
space is exceeded, the 'backup' script<br>
> > > >>could delete local copies of
document by LRU until the quota is<br>
> > > >>met.<br>
> > > >>Similarly, there should be a
quota on Sugar activities which could<br>
> > > >>also automatically be pruned
back LRU. Managing the store<br>
> > > >>automatically is consistent
with keeping the Sugar UI as simple as<br>
> > > >>possible.<br>
> > > >This should be built into Sugar
rather than in the non-Sugar backup<br>
> > > >script. They should be maintained
together.<br>
> > > ><br>
> > > >This would be a code change to git
repository sugar-datastore and<br>
> > > >the<br>
> > > >Journal activity in repository
sugar.<br>
> > > ><br>
> > > >>As always, there are
complications. The original OLPC concept was<br>
> > > >>that there would be one XO per
user. As a result the software was<br>
> > > >>designed for a single user
identified by the XO serial number.<br>
> > > >The multiple user feature is
supported by Fedora and Sugar, but we<br>
> > > >removed it for OLPC OS.<br>
> > > ><br>
> > > >>Today, many XO deployments
provide enough XOs for a classroom.<br>
> > > >>During the day, different
students use the XO as their class goes<br>
> > > >>to<br>
> > > >>the computer lab or as the
computers are distributed from classroom<br>
> > > >>to classroom. However, all of
the documents created are in a single<br>
> > > >>Journal with only the user's
memory to indicate which document goes<br>
> > > >>with which user.<br>
> > > >OLPC did not design OLPC OS to be
used in this scenario, so no<br>
> > > >surprise you've hit that. But it's
not a Sugar problem. Don't<br>
> > > >conflate Sugar with OLPC OS.<br>
> > > ><br>
> > > >>The OLPC Ubuntu Sugar 14.04
Trusty LTS (to use its official name)<br>
> > > >>solves this problem at the
laptop side by using standard gnu/linux<br>
> > > >>logins.<br>
> > > >The multiple user feature is
supported by Ubuntu and Sugar, and I<br>
> > > >haven't removed it yet. I know how
to; small configuration change<br>
> > > >to<br>
> > > >lightdm package.<br>
> > > ><br>
> > > >Don't forget SoaS. The Fedora 23
SoaS is easily installed to disk<br>
> > > >and<br>
> > > >has multiple user capability. The
Fedora 24 SoaS is shaping up to<br>
> > > >be<br>
> > > >just as good or better, since it is
based on Sugar 0.108.<br>
> > > ><br>
> > > >>Each user has her own username
and password. The Sugar activities<br>
> > > >>have been moved to common space
in the file system so only one copy<br>
> > > >>is needed to support multiple
users. Users are not 'olpc' but<br>
> > > >>identified by their username.
However, the datastore is part of<br>
> > > >>the<br>
> > > >>user space (one datastore per
user).<br>
> > > >Yes. ODPU.<br>
> > > ><br>
> > > >>This is problematic since the
backup script uploads to<br>
> > > >>/library/user/serial-number on
the school server.<br>
> > > >No, you're wrong. In the Ubuntu
scenario, the register_laptop<br>
> > > >function will invent a serial
number because it won't find Open<br>
> > > >Firmware [1]. So it wouldn't be a
problem. It doesn't sound like<br>
> > > >you've tested this.<br>
> > > ><br>
> > > >1.<br>
> > <a href="https://github.com/sugarlabs/sugar/blob/master/src/jarabe/desktop/schoolserver.py#L110" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/blob/master/src/jarabe/desktop/schoolserver.py#L110</a><br>
> > > ><br>
> > > >>So, one strategy would be to
upload to /library/user/username. This<br>
> > > >>requires that usernames be
unique across all laptops using a given<br>
> > > >>schoolserver. This could be
enforced at registration on the school<br>
> > > >>server.<br>
> > > >Starting to sound very
complicated. Single-sign-on (SSO) across a<br>
> > > >school. These are truly amazing
teachers with lots of free<br>
> > > >administration time.<br>
> > > ><br>
> > > >(There are deployments using Sugar
with SSO already, but as it's<br>
> > > >outside the scope of Sugar we don't
hear about them at Sugar Labs,<br>
> > > >and<br>
> > > >we don't provide the facility in
OLPC OS, but that doesn't stop<br>
> > > >them.)<br>
> > > ><br>
> > > >>However, the Sugar releases for
the XO<br>
> > > >We call that OLPC OS, which
includes Sugar and Gnome desktops.<br>
> > > ><br>
> > > >>still maintains Sugar
activities in /home/olpc/Activities. So, one<br>
> > > >>requirement is to restructure
Sugar as was done for OLPC Ubuntu<br>
> > > >>Sugar 14.04 Trusty LTS.<br>
> > > >That would not block implementing a
server datastore, since the<br>
> > > >implementation would not care what
$HOME is set to.<br>
> > > ><br>
> > > >(And besides, it's already done for
SoaS, so the Fedora activity<br>
> > > >packages can be used immediately.)<br>
> > > ><br>
> > > >>Another approach might be to
create directories for each user of a<br>
> > > >>single XO (e.g.
/library/user/serial-number/user1).<br>
> > > >That would require authentication
service by the server datastore.<br>
> > > ><br>
> > > >>Another complication is that
the Browse activity downloads files<br>
> > > >>from the school server to the
Journal (e.g. pdfs, mp3). These<br>
> > > >>documents do not need to be
saved to the users Journal backup on<br>
> > > >>the<br>
> > > >>school server since they can be
restored from the school server<br>
> > > >>'library'. Also, such documents
when downloaded should be stored in<br>
> > > >>a common space available to all
users of that laptop. Fortunately,<br>
> > > >>the source of a document is
provided in the metadata.<br>
> > > >What you describe here can also be
solved by deduplication.<br>
> > > ><br>
> > > >The Journal Git backend proposed by
Martin and Walter could help<br>
> > > >with<br>
> > > >deduplication of journal objects
across multiple journals.<br>
> > > ><br>
> > > ><a href="https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_Core" rel="noreferrer" target="_blank">https://wiki.sugarlabs.org/go/Summer_of_Code/2016#Sugar_Core</a><br>
> > > ><br>
> > > >>One approach would be to divide
the datastore into two directories<br>
> > > >>on the laptop, one in common
space and the other local to the user.<br>
> > > >>The Journal could show both
sets of objects.<br>
> > > >Or the server datastore would
recognise content hashes of server<br>
> > > >artefacts and know it need not send
the content from the client to<br>
> > > >the<br>
> > > >server before LRU local deletion.
It could hard link it.<br>
> > > ><br>
> > > >>Finally, each Journal object
consists of a metadata file and an<br>
> > > >>optional document. The metadata
files tend to clutter the Journal<br>
> > > >>display (mine has hundreds of
Terminal activity and Log activity<br>
> > > >>entries). I would propose that
the Journal show only objects which<br>
> > > >>have a document with a
user-supplied name (a metadata flag). The<br>
> > > >>script should backup the
metadata files for those objects without a<br>
> > > >>document to a 'log' on the
school server for statistical analysis<br>
> > > >>but delete them from the local
datastore. Journal objects saved<br>
> > > >>without a user-supplied name
(but something like Write.activity)<br>
> > > >>should have their document
deleted. As part of GSOC there is an<br>
> > > >>initiative to require users to
supply a name for documents they<br>
> > > >>wish<br>
> > > >>to save - so this problem may
not be part of the 'backup' scheme.<br>
> > > >>Whether a document is saved or
deleted, the metadata can be saved<br>
> > > >>to<br>
> > > >>the log and displayed by the
existing statistical tools.<br>
> > > >I'm against any classification of
journal objects in this way. We<br>
> > > >cannot know how useful a Terminal
and Log activity object is to the<br>
> > > >learner.<br>
> > > ><br>
> > > >However, I would like a way for
expert users to terminate an<br>
> > > >activity<br>
> > > >without saving a journal object.<br>
> > > ><br>
> > > >>As an old crumudgeon, I still
believe design precedes coding.<br>
> > > >><br>
> > > >>Reading the existing code is
always a good idea:<br>
> > > >><br>
> > > >>Sugar<br>
> > > >><br>
> > > >> *<br>
> > >
>>/usr/lib/python2.7/site-packages/jarabe/desktop/schoolserver.py<br>
> > > >>#registers server - notice
transition from gconf to gsettings<br>
> > > >> * /usr/bin/ds_backup.sh
#primarily decides if backup can be<br>
> > > >> run<br>
> > > >>
#backup logic is<br>
> > > >> needed<br>
> > > >>because an rsync can use a lot
of bandwidth in a local network<br>
> > > >> * /usr/bin/ds_backup.py
#actually does the backup using<br>
> > > >> rsync<br>
> > > >>(note: -d option AFAIK deletes
an object from the backup if it is<br>
> > > >>deleted in the source,<br>
> > > >>
#this has the effect<br>
> > > >> of<br>
> > > >>limiting the size of the
datastore to the available space on the XO<br>
> > > >>not on the school server).<br>
> > > >><br>
> > > >>Server (xsce6)<br>
> > > >><br>
> > > >> * /usr/libexec/idmgr
#contains a number of utilities<br>
> > > >>used in registration<br>
> > > >> * /library/users
#contains a directory per<br>
> > > >>serial-number of registered
user<br>
> > > >>
#use ls -a to see<br>
> > > >> files<br>
> > > >>created. The idmgr creates a
public/private key pair which is used<br>
> > > >>by sftp to authenticate -
avoiding password<br>
> > > >><br>
> > > >>Note: if you look at the server
code, you can see why registering<br>
> > > >>the laptop on each connection
works (and can avoid any need for a<br>
> > > >>registration menu item).<br>
> > > >><br>
> > > >>When you get to know your way
around the existing process, I'll<br>
> > > >>send<br>
> > > >>you a copy of the ds_backup.py
code I use to implement the item by<br>
> > > >>item backup.<br>
> > > >You should start using GitHub like
the rest of us.<br>
> > > ><br>
> > ><br>
> > >
_______________________________________________<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</a><br>
> ><br>
> > --<br>
> > James Cameron<br>
> > <a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
> >
_______________________________________________<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</a><br>
> ><br>
> _______________________________________________<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</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Sugar-devel mailing list
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">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<br clear="all"><br>-- <br></a><div class="gmail_signature"><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>
</div></div>
</div>