<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body 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 class="moz-txt-link-freetext" href="http://schoolserver1">http://schoolserver1</a>, <a class="moz-txt-link-freetext" href="http://schoolserver2">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.<br>
    <br>
    Tony<br>
    <br>
    <div class="moz-cite-prefix">On 04/17/2016 05:24 AM, Manash Raja
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAB1qWcVQ82HmNQPjAsd7cUkPMWmH3KKqSPjzfm1VMtP9zMWJtA@mail.gmail.com"
      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"
            target="_blank"
            href="http://dev.laptop.org/git/users/quozl/ds-backup/">http://dev.laptop.org/git/users/quozl/ds-backup/</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">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">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
              class="HOEnZb"><font color="#888888"><br>
                <br>
                Tony</font></span>
            <div>
              <div class="h5"><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 class="h5">
                  <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 class="">
                _______________________________________________<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 class="HOEnZb">
              <div class="h5">
                <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 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>