<div dir="ltr"><div><div><div><div><div><div>Hi all, </div>Thanks for the guidance :) . </div>I would like to get started on this enhancement now according to the discussions. </div>As far as I understand, the present flow is this: (please have a look at attached "sugar-server-present.png" ) <img alt="Inline image 1" src="cid:ii_154147b2cb4623ca" height="423" width="565"> </div>ds-backup performs its function in some of the systems that include it. Sugar just has to ensure that 'backup-url' and 'jabber-server' schemas, files in ~.sugar/default/identifiers contain proper server information and ssh known_hosts do not produce conflicts. </div>To make sugar connect with any XS server smoothly and easily, I think the following flow will work: (please have a look at attached "sugar-server-modified.png" ) <img alt="Inline image 2" src="cid:ii_15414829d8f682f7" height="423" width="565"> </div><div>Please correct me if I am wrong. </div><div> </div>The main advantages of the above flow according to me are: <ol><li>Manual clear of registration is not required. </li><li>Each laptop will have same backup url and backup path (in XS:/library/users) for a particular XS as it was created on first registration with the server. As registration will be done only once. The "Register" button would rather say "Connect to Server". When user connects to an XS where it has registered previously (identified by the presence of pubkey), it would simply set its serial number, uuid and backup-url with the pre-registration data. This would enable better and advanced management of backups.</li><li>No extra input is required from the user. The user just has to connect to the XS server ssid and specify the jabber-server address as before.</li></ol> So, I guess this flow will let a user hop between multiple XS servers very easily. :)And @Jerry as Tony mentioned, I would like to add-on that, as I am interested to take the sugar-server interaction further on Tony's idea of remote datastore, and cloud integration (including ownCloud and third party services as available) and hence have submitted the GSoC proposal for the same.A few doubts that I have:<ol><li>What is the use of uuid? And where is it used in XS server side?</li><li>Who generates the pk_hash for XS server, is the server itself or sugar? I found it to be unique to a laptop like the pubkey.</li><li>Should the Jabber server entry be moved to a new section "Server" in control panel to reorganize it a bit and provide the place for further server settings?</li><li>If the above flow is implemented and we need to store the uuid(s) for serial numbers, then should it be stored in a sqlite3 db or in a file with json format?</li></ol>Thanks </div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Apr 14, 2016 at 2:09 PM, Tony Anderson <<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jerry Yes, of course. At the moment, it is proposed for implementation in the GSOC. The use of OwnCLoud is a possibility. Currently, it is down by backup to the /library/users via sftp by a customized version of ds_backup. OwnCloud might make the process more visible and more useful to the user. Tony<div class="HOEnZb"><div class="h5"> On 04/14/2016 10:15 AM, Jerry Vonau wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Tony, What about your remote datastore that you were taking about? What was the owncloud integration that you were talking about? Is that not a way of backing up some data? <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On April 13, 2016 at 8:07 PM James Cameron <<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>> wrote: On Thu, Apr 14, 2016 at 08:39:10AM +0800, Tony Anderson wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi, James Deployments without a school server obviously do not use the backup. Deployments without access to the internet vie GSM do not use that support either. I suppose ds_backup.sh and ds_backup.py come from the tooth fairy and not from flashing a Sugar image. </blockquote> They come from OLPC. You just happen to be using OLPC OS. So it isn't relevant to Sugar Labs, unless Sugar Labs decide to adopt the ds-backup package. I'm fine if they do, but so far they haven't. </blockquote> By way of packaging for the distros or integration in sugar. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The server software was developed for Fedora systems for the same reason Sugar was developed for Fedora systems. I don't see the relevance. </blockquote> I'm not talking about the server software, I'm talking about the ds-backup glue between them. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Maintenance of this software has been assumed by xsce. The closest version to the original is the CentOS image, a much more stable option. </blockquote> XSCE has not assumed maintenance of the ds-backup glue. Why not? </blockquote> Well for the server side George has with a revised rpm, for the change to Apache-2.4. Jerry <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You are wrong about the ssh-keygen. That is done by the idmgr at registration time. The removal of the known_hosts results from the configuration of the server to check known_hosts. This problem must be resolved before registration can occur. </blockquote> No, you are wrong about "ssh-keygen -R", it is used to remove a single entry from a known_hosts file. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Tony On 04/14/2016 08:13 AM, James Cameron wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Manash, registration sets Jabber server and backup server, and for some systems the backup server is not used. For those systems like Tony's where the backup server is used, please review <a href="http://dev.laptop.org/git/users/quozl/ds-backup/" rel="noreferrer" target="_blank">http://dev.laptop.org/git/users/quozl/ds-backup/</a> which is the software responsible for doing backups to the server. It is not part of Sugar, but then neither is the server. It is designed for Fedora systems, and was last updated for OLPC OS. There are no other uses of this software known. It is not packaged in SoaS or Ubuntu. The ds-backup software fails if the backup server is changed, because of the changed host key of the server. While Tony's workaround is functional, it is also destructive. A more correct solution is to use "ssh-keygen -R" option to remove the key, or add SSH options to avoid the key conflict. #362 On Thu, Apr 14, 2016 at 07:50:17AM +0800, Tony Anderson wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> OLE Nepal has from the beginning registered the server at each connection eliminating the registration option from the main menu. A second registration recognizes that the laptop is registered and takes no action. Moving from one server to another causes a 'known hosts' issue. This can be cleared by 'rm -rf ~/.ssh/known_hosts.' While registering does show the server in the network section (and clearing the entry enables registration - needed before registration again), the registration process sets up the /library/users directory for the laptop serial number and thus enables Journal backup. Tony On 04/14/2016 07:35 AM, James Cameron wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, Apr 13, 2016 at 06:13:42PM -0500, Jerry Vonau wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On April 13, 2016 at 5:37 PM James Cameron <<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>> wrote: On Thu, Apr 14, 2016 at 02:44:25AM +0530, Manash Raja wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Jerry, Please don't forget jarabe/desktop/schoolserver.py is involved, I personally would prefer that code to be moved into control-panel/network. Others please chime with your thoughts on this one. Yes, if register option is brought to network section, then it will provide better space for managing multiple different XS servers. </blockquote> Yes, add registration function to the network section, or move server to a new section ... but for ease of first-use where only one server is present, the register option can remain on the main menu. (Why do I suggest a new section? The Network section has become cluttered with radio device controls, access point cache control, jabber server, social help, and soon proxy settings.) </blockquote> Wouldn't the backup related fields be more relevant in the backup section of control-panel? Maybe the 'new' proxy settings could have its own control panel section also? </blockquote> Yes, yes. </blockquote> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote></blockquote> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote> -- James Cameron <a href="http://quozl.netrek.org/" rel="noreferrer" target="_blank">http://quozl.netrek.org/</a> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </blockquote> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div></div></blockquote></div> </div>