[Sugar-devel] Sugar-Server enhancement

Manash Raja mpdmanash at gmail.com
Sat Apr 16 17:24:54 EDT 2016


Hi,

Here are some updates.

*ssh:* I found from the source code for ds-backup provided by James
http://dev.laptop.org/git/users/quozl/ds-backup/ and while searching along
the lines of Tony (*The script stores and retrieves using sftp with
authentication by public/private key.*) that communication by ds-backup is
done using this command:
/usr/bin/ssh -o "PasswordAuthentication no" -o "StrictHostKeyChecking no"
-i ~/.sugar/default/owner.key -l serial_number server_address

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 .

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.

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.
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.

I have tested that we can add to .ssh/config
Host custom_server_name
    HostName 10.105.57.97
    PasswordAuthentication no
    StrictHostKeyChecking no
    IdentityFile ~/.sugar/default/owner.key
    User <serial>

and it works by simply calling : ssh custom_server_name
So we can work upon it.
A few doubts:

   1. What should be used in custom_server_name?
   2. 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.
   3. How do we expect a human user to use ssh? the longer command or
   .ssh/config based command? or simply ssh user at server with constant
   modifications to known_hosts.


*XSCE vs XS*:

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.

@Jerry

> I'm concerned with backwards compatibility, the original 'schoolserver'(XS)
> based on CentOS-6 doesn't offer the xs-authserver service, hence why I
> mentioned it. I would not want to break a deployment where the older server
> version is used.
>
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.

A few doubts:

   1. Rough percentage of XS against XSCE out there?
   2. 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.
   3. 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.

@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).

Thanks.


On Sat, Apr 16, 2016 at 7:56 AM, Tony Anderson <tony_anderson at usa.net>
wrote:

> The operative code on the school server is /usr/libexec/create_user. What
> Manash describes
> is apparently using the db setup by idmgr to list the registered laptops.
> I don't think you will
> break compatibility.
>
> What I hope we can look at is implementing LDAP as a central
> authentication for all of the services which
> require a user name, password. Of the top of my head - Moodle, Khan
> Academy Lite, OwnCloud, and Elgg.
>
> My brief experience with OwnCloud is that it is a shell requiring a lot of
> configuration. I would be interested if TK has
> 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.
>
> Tony
>
>
> On 04/16/2016 10:05 AM, Jerry Vonau wrote:
>
>>
>> On April 15, 2016 at 6:56 PM Manash Raja <mpdmanash at gmail.com> wrote:
>>>
>>>
>>> @Jerry,
>>> 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.
>>>
>>> I'm concerned with backwards compatibility, the original
>> 'schoolserver'(XS)
>> based on CentOS-6 doesn't offer the xs-authserver service, hence why I
>> mentioned it. I would not want to break a deployment where the older
>> server
>> version is used.
>>
>>
>>
>>> @Tony,
>>> 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.
>>>
>>> Thanks
>>>
>>> The ownCloud service is not enabled out of the box, same as the
>> 'xo-services'. You can enable it and play around, figure out how and where
>> the users' data is stored. Either idmgr or ownCloud could be altered to
>> suit the need. Here it would be safe to rely on xs-authserver's
>> information
>> as there is no existing implementation of owncloud in previous releases of
>> the server software. I can help push the server-side PR's through.
>>
>>
>> Jerry
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160417/d4cf38d6/attachment.html>


More information about the Sugar-devel mailing list