<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi, Manash<br>
<br>
After sending the previous e-mail, I got thinking the following
situation. An admin goes to a deployment which reports a problem.
Each of the deployments <br>
for that admin has the schoolserver address 172.18.96.1. This is the
case for the three schools in Rwanda and also for the three schools
in the Philippines.<br>
Will your technique work to register multiple servers with the same
IP?<br>
<br>
Tony<br>
<br>
<div class="moz-cite-prefix">On 04/17/2016 03:17 PM, Manash Raja
wrote:<br>
</div>
<blockquote
cite="mid:CAB1qWcUNSWONk+JyVErjTqEgriYwRE-7T=oqj7Sf99r=qvV2Qg@mail.gmail.com"
type="cite">
<div dir="ltr"><span
style="font-family:arial,helvetica,sans-serif">Regarding SSH.
I think I have found a good solution. (I have tested it.)
Thanks @Tony for telling where exactly the problem occurs.<br>
<br>
</span>
<pre><span style="font-family:arial,helvetica,sans-serif">Commit : <a moz-do-not-send="true" href="https://github.com/sugarlabs/sugar/pull/679/commits/930726741744ebdf6d464b84b31210aa0897124a">https://github.com/sugarlabs/sugar/pull/679/commits/930726741744ebdf6d464b84b31210aa0897124a</a>
Commit message :
ds-backup works independently on its own by using priave/public key pair and
ignoring known_hosts by setting 'StrictHostKeyChecking no'.
Problem might arise when other applications or user try to connect ssh to
server without using private/public key. In that case known_hosts should be
maintained to avoid conflict.
Eg scenario: Client ssh into xsce1 on server_address say schoolserver
id1 of xsce1 stored at known_hosts.
Client tries for ssh into xsce2 with same server_address (schoolserver)
id2 of xsce2 does not match with id1. Hence error.
Solution: If registration is successful, we know that we have correct
server_address of the xsce, hence we take its identification using
'ssh-keyscan -H -t ecdsa server_address' and add it to known_hosts.
So when ssh is initiated, the id of the xsce server is found along with its
server_address.</span></pre>
<pre><span style="font-family:arial,helvetica,sans-serif">It removes the use of <span class=""><span class="">"ssh-keygen -R" and hence will be more secured. It might happen that multiple identification for a
particular server_address is present in the known_hosts file as "schoolserver" is mostly used as the server address.
But ssh will take the one that matches.</span></span></span></pre>
<pre>
</pre>
<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Apr 17, 2016 at 7:27 AM, Tony
Anderson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> In the current
backup system, the only involvement of the user is to
register. The ds-backup script uses the serial-number of
the XO. The 'known_host' check must pass in order for
this to work. Normally, this is not a problem because a
given deployed XO only ever sees one server. It is
usually only a problem for the person setting up
multiple deployments (or multiple servers). <br>
<br>
Adam Holt apparently contemplates setting up multiple
Raspberry Pi size servers with an SD card for content at
a single deployment. I believe that this environment
will not support backup and so there would be no need to
register (except possibly for ejabberd - I haven't
looked at that in years). Possibly HaitiOS should not
execute the ds_backup script. However, if the script
fails there is consequence. What will be required is
that each server on a single network have a unique name
to support access by url:<a moz-do-not-send="true"
href="http://schoolserver1" target="_blank">http://schoolserver1</a>,
<a moz-do-not-send="true" href="http://schoolserver2"
target="_blank">http://schoolserver2</a>, ....<br>
<br>
I assume 10.105.57.97 is the IP address of the server.
In the server setup, the server is set as the network
gateway and provides dns translation from <br>
server name to IP. This works with one school server per
network (the norm). In the special case of multiple
school servers, one should supply DHCP services and be
the gateway. The other school servers would need fixed
IP addresses. Currently, the school server is set up as
172.18.96.1 with a netmask of 255.255.224.0. In this
scheme, other school servers could be given fixed
addresses such as 172.18.126.1, 172.18.126.2, .... I
have attached the relevant information from the school
server: /etc/dchpd-xs.conf.<br>
<br>
Naturally, you can save the IP address if that is more
convenient. <br>
<br>
The logic of the situation is that a user should keep
its Journal backup on a single school server. The
current ds_backup would take duplicate the same backup
on each server. I suppose Sugar could be modified to
specify backup to a designated school server. The
proposed backup would fragment the Journal objects since
it would assume that objects have been backed up and so
not make copies on alternate school servers. <br>
<br>
I am sure in Adam's scenario, the SD cards will not
afford complete backups from multiple laptops on each SD
card. Most likely, there would have to be a dedicated
server for backup with an essentially empty card.<br>
<br>
On your third question, system adminstrators use ssh.
This is not a problem because access is by password. The
server is set up for <br>
ssh xsce-admin@schoolserver <br>
<br>
Once logged in, an adminstrator can su to root. This
requires two independent passwords to authenticate.<span
class="HOEnZb"><font color="#888888"><br>
<br>
Tony</font></span>
<div>
<div class="h5"><br>
<br>
<div>On 04/17/2016 05:24 AM, Manash Raja wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi,<br>
<br>
</div>
Here are some updates.<b><br>
<br>
ssh:</b> I found from the source code for
ds-backup provided by James <a
moz-do-not-send="true" rel="nofollow"
href="http://dev.laptop.org/git/users/quozl/ds-backup/"
target="_blank"><a class="moz-txt-link-freetext" href="http://dev.laptop.org/git/users/quozl/ds-backup/">http://dev.laptop.org/git/users/quozl/ds-backup/</a></a>
and while searching along the lines of Tony (<i>The
script stores and retrieves using sftp with
authentication by public/private key.</i>)
that communication by ds-backup is done using
this command:<br>
</div>
<div>/usr/bin/ssh -o "PasswordAuthentication no"
-o "StrictHostKeyChecking no" -i
~/.sugar/default/owner.key -l serial_number
server_address<br>
</div>
<div><br>
as you all know that
~/.sugar/default/owner.key is the private key
for ~/.sugar/default/owner.key.pub public key.
The public key is sent to the server at the
time of registration. The server adds this
public key to
/library/users/serial_number/.ssh/authorized_keys
.<br>
<br>
</div>
<div>I understand that ds-backup don't care
about the .ssh/known_hosts on the client side
due to "StrictHostKeyChecking no" even though
the file is getting populated. <br>
<br>
</div>
<div>So the ssh command is concerned of mainly
the public/private key pair, serial and the
server address. If we know the serial of the
laptop that is registered with a server we can
connect successfully with it using the above
command. But it might fail using a normal ssh
command due to known_host conflict. If we
assume that all the server communication (sftp
and rsync) will occur using private/public
keys, then we don't even need to do
"ssh-keygen -R hostame" or "rm
~/.ssh/known_hosts" I guess.<br>
</div>
<div>The issue might have been caused when wrong
serial was used to connect to a server which
do not have it registered. Which has now been
fixed in the patch by retaining the serial for
previous registrations. <br>
<br>
</div>
<div>I have tested that we can add to
.ssh/config<br>
</div>
<div>Host custom_server_name<br>
</div>
<div> HostName 10.105.57.97<br>
PasswordAuthentication no<br>
StrictHostKeyChecking no<br>
</div>
<div> IdentityFile ~/.sugar/default/owner.key<br>
</div>
<div> User <serial><br>
<br>
</div>
<div>and it works by simply calling : ssh
custom_server_name <br>
</div>
<div>So we can work upon it. <br>
A few doubts:<br>
<ol>
<li>What should be used in
custom_server_name?</li>
<li>How do we expect our codes to sftp or
rsync with server? ds-backup will run
properly in backup if we keep setting the
proper serial. But other than that no
application does sftp or rsync to server,
so we can define the proper way now.</li>
<li>How do we expect a human user to use
ssh? the longer command or .ssh/config
based command? or simply ssh user@server
with constant modifications to
known_hosts.</li>
</ol>
<p><br>
</p>
<p><b>XSCE vs XS</b>:</p>
<p>The patch I built uses relies on
xs-authserver which is absent in xs. I
really want to add support for XS for this
feature. And I discussed on #schoolserver to
know if there is any other way to get idmgr
database info on client side. XS doesn't
seem to support it well enough. I have
identified a way to solve this issues by
modifying "registration-server" and
"idmanager.py" scripts of idmgr.</p>
<p>@Jerry</p>
<blockquote style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"
class="gmail_quote">
<p>I'm concerned with backwards
compatibility, the original
'schoolserver'(XS)<br>
based on CentOS-6 doesn't offer the
xs-authserver service, hence why I<br>
mentioned it. I would not want to break a
deployment where the older server<br>
version is used.</p>
</blockquote>
<div>It would not break deployment, as Tony
mentioned. The maximum harm that can be
caused is to have multiple registrations for
a single laptop in XS due to inability of XS
to provide list of registered laptops to the
client. <br>
</div>
<p>A few doubts: <br>
</p>
<ol>
<li>Rough percentage of XS against XSCE out
there?</li>
<li>Scope of modifying idmgr? I am still
looking for alternatives in XS that
doesn't need server side modification but
till then I really want to know what are
the steps if we finally need to modify to
establish a clear implementation. <br>
</li>
<li>Even without XS support, the patch
solves the issue of taking the load out of
teachers, just that same backup path
cannot be ensured if serial keeps
changing. Hence, is this a significant
issue to need a server modification? As if
not, then we can move on and wait until
the XS catches up. <br>
</li>
</ol>
</div>
<div>@Tony, certainly as you said things can be
reorganized starting from now in small steps
so that future features can easily fall into
place. This registration feature may change a
component here and there (like idmgr) but in
the progress it might provide a cleaner and
better framework for server related features.
(LDAP being one of them).<br>
<br>
</div>
<div>Thanks.<br>
</div>
<div> <br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Apr 16, 2016 at
7:56 AM, Tony Anderson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:tony_anderson@usa.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:tony_anderson@usa.net">tony_anderson@usa.net</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">The operative
code on the school server is
/usr/libexec/create_user. What Manash
describes<br>
is apparently using the db setup by idmgr to
list the registered laptops. I don't think
you will<br>
break compatibility.<br>
<br>
What I hope we can look at is implementing
LDAP as a central authentication for all of
the services which<br>
require a user name, password. Of the top of
my head - Moodle, Khan Academy Lite,
OwnCloud, and Elgg.<br>
<br>
My brief experience with OwnCloud is that it
is a shell requiring a lot of configuration.
I would be interested if TK has<br>
actually deployed it and, if so, how he uses
it. I don't know of any one else who is
using it at the moment.<span><font
color="#888888"><br>
<br>
Tony</font></span>
<div>
<div><br>
<br>
On 04/16/2016 10:05 AM, Jerry Vonau
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div>
<div> <br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> On April
15, 2016 at 6:56 PM Manash Raja <<a
moz-do-not-send="true"
href="mailto:mpdmanash@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mpdmanash@gmail.com">mpdmanash@gmail.com</a></a>>
wrote:<br>
<br>
<br>
@Jerry,<br>
I haven't modified anything for this
feature on the server side. I found<br>
that it uses both idmgr and
xs-authserver. But the 5000 port is
used by<br>
xs-authserver to display a list of
registered laptops. I didn't enable
it<br>
myself, it was there. All I did was
to setup my server according to the<br>
instructions and enabled the "XO
register" feature from the admin
page.<br>
<br>
</blockquote>
I'm concerned with backwards
compatibility, the original
'schoolserver'(XS)<br>
based on CentOS-6 doesn't offer the
xs-authserver service, hence why I<br>
mentioned it. I would not want to
break a deployment where the older
server<br>
version is used.<br>
<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> @Tony,<br>
Can you tell me how ownCloud is
supported by XSCE? I saw it in the<br>
services<br>
ready to be enabled. So can we not
move the storage location of<br>
/library/user/<some_id> inside
or account based user directories to
the<br>
cloud storage locations.<br>
<br>
Thanks<br>
<br>
</blockquote>
The ownCloud service is not enabled
out of the box, same as the<br>
'xo-services'. You can enable it and
play around, figure out how and where<br>
the users' data is stored. Either
idmgr or ownCloud could be altered to<br>
suit the need. Here it would be safe
to rely on xs-authserver's information<br>
as there is no existing implementation
of owncloud in previous releases of<br>
the server software. I can help push
the server-side PR's through.<br>
<br>
<br>
Jerry<br>
</div>
</div>
<span>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org"
target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</span></blockquote>
<div>
<div> <br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org"
target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Sugar-devel mailing list
<a moz-do-not-send="true" href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a moz-do-not-send="true"
href="http://lists.sugarlabs.org/listinfo/sugar-devel"
rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Sugar-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>