<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Sounds good. Make sure not to use the word connect - this refers to
making a connection between the client and the server. Using it in
this context could create confusion.<br>
<br>
"He just has to register with the server as normally he would do by:<br>
<ol>
<li>setting the server ip 172.18.96.1 in the network control panel
section</li>
<li>clicking "Register"/ "Register again"/ "Connect to server"
whichever gets implemented."</li>
</ol>
<p>Actually, there doesn't appear to be a need to change the users
interface at all. if the user connects to a 'new' server, this
will be indicated by 'register' <br>
and not 'register again' (and the network control panel would show
no server). The user clicks register and your code adds a new
entry to ssh and shows the FQDN in the network control panel and
changes to 'register again'.<br>
</p>
<p>Tony<br>
</p>
<br>
<br>
<div class="moz-cite-prefix">On 04/17/2016 05:35 PM, Manash Raja
wrote:<br>
</div>
<blockquote
cite="mid:CAB1qWcXG4pgm9CP=YTtCqKMurhYsuikb7_49MCDnA3kBdKBC=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hi Tony,<br>
<br>
</div>
Yes, it will work.<br>
</div>
When the admin will register to the above said
schoolservers. He/she will have something like the
following in his/her ~/.ssh/known_hosts file:<br>
172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOasdasdSAaaaaaSomethingaaaaaaaaaa=<br>
172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3bbbbbbbSomethingbbbbbbbbb=<br>
172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARg2Somethingccccccccc=<br>
172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingdddddddddd=<br>
172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingeeeeeeeeee=<br>
172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingfffffffffffffffff=<br>
<br>
</div>
Notice the same ip address but different identities for
the school server.<br>
<br>
</div>
Whenever he will try to do: ssh <a moz-do-not-send="true"
href="mailto:xsce-admin@172.18.96.1">xsce-admin@172.18.96.1</a>
, while connected to any of the above school server, he will
not face the host identity mismatch error as one among the 6
contains the identity for the server.<br>
</div>
He will directly be prompted for the password.<br>
<br>
</div>
He just has to register with the server as normally he would do
by:<br>
<ol>
<li>setting the server ip 172.18.96.1 in the network control
panel section</li>
<li>clicking "Register"/ "Register again"/ "Connect to server"
whichever gets implemented. </li>
</ol>
<p>Upon registration, the known_host file will be updated
automatically to have the proper server identity. It will also
be secure against mitm attacks.<br>
</p>
<p>He <b>doesn't</b> <b>have to</b> rm the known_host file or
ssh-keygen -R for the host. <br>
</p>
<p>How do you feel about this technique?<br>
</p>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Apr 17, 2016 at 1:44 PM, 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"> 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?<span class="HOEnZb"><font color="#888888"><br>
<br>
Tony</font></span>
<div>
<div class="h5"><br>
<br>
<div>On 04/17/2016 03:17 PM, Manash Raja wrote:<br>
</div>
<blockquote 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" target="_blank">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><span>"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>
<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"><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">
<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"><a class="moz-txt-link-freetext" href="http://schoolserver1">http://schoolserver1</a></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><font
color="#888888"><br>
<br>
Tony</font></span>
<div>
<div><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"
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"
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>
<br>
</blockquote>
</div>
<br>
</div>
</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>
</blockquote>
<br>
</body>
</html>