[Sugar-devel] Sugar-Server enhancement
Tony Anderson
tony_anderson at usa.net
Sat Apr 16 21:57:19 EDT 2016
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).
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:http://schoolserver1, http://schoolserver2, ....
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
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.
Naturally, you can save the IP address if that is more convenient.
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.
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.
On your third question, system adminstrators use ssh. This is not a
problem because access is by password. The server is set up for
ssh xsce-admin at schoolserver
Once logged in, an adminstrator can su to root. This requires two
independent passwords to authenticate.
Tony
On 04/17/2016 05:24 AM, Manash Raja wrote:
> 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
> <mailto: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 <mailto: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
> <mailto:Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> <mailto: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/12d7aa0a/attachment-0001.html>
-------------- next part --------------
#
# School server 1 DHCP Server Configuration file.
#
ddns-update-style interim;
#ignore client-updates;
option domain-name "lan";
option domain-name-servers 172.18.96.1;
option ntp-servers 172.18.96.1;
subnet 172.18.96.0 netmask 255.255.224.0 {
option routers 172.18.96.1;
option subnet-mask 255.255.224.0;
option broadcast-address 172.18.127.255;
# this is the whole range we have available - 8K addresses
# range 172.18.96.2 172.18.127.254;
# instead, we'll save 510 addresses for later.
range 172.18.96.2 172.18.125.254;
# the other /24s:
# -> 172.18.126.0/24 for static IP addresses
# for printers, AP management consoles, etc.
# -> 172.18.127.0/24 for temporary addresses for
# XO activation
# As this subnet is wired or wifi a/b/g, these lease
# times are on the long side
default-lease-time 10800;
max-lease-time 21600;
}
More information about the Sugar-devel
mailing list