Registration with Central Server error "could not verify model"

[arnoan]

Branch: master (0.13.1) (but was already happening in 0.12 and 0.13 RC as well)

Expected Behavior: Registration with central server should complete after choosing to register with central server and signing in with the right user credentials on a new device.

Current Behaviour: Both on a Macbook Air 2011 and two independent Raspberry Pi 2's the registration with the central server fails after entering my login credentials for the central server and returns the "Validation Error: [u'Could not verify the imported model.']". What's more: Once the registration with the central server failed the registration page always directs back to this error not even offering the choice for "One-Click Registration" anymore (which does work) rendering the whole local database unusable.

Steps to reproduce: I can reproduce the error every time I try to register with the central server. Did not manage to get it to work a single time so far. After each unsuccessful attempt the only solution is to run "kalite manage setup" again, create a new database (the old one saves the error) and proceed with One-Click registration.

The error is probably linked to my hardware and the central server being unable to identify it. But since I am using two different Raspberry Pi 2 and they probably constitute a common setup this is quite inconvenient. Using One-Click registration is not a big problem but I intend to setup a learning station for our local Refugee camp coming week and it would be convenient to make full use of the data synchronisation potential for this scenario. Any ideas for solving this issue are highly appreciated.

[EdDixon]

@jamalex @aronasorman Knowing we are testing a MAC installer this week I want to be absolutely sure our 13.1 is good here (last serious MAC test was in the RC phase, but had past) in order to revert back to it in troubleshooting issues with the installer we may have. So completely uninstalled 13.x and reinstalled git 0.13.x on Yosemite 10.10.3 with python version 2.7.9 with no issues either in the installation in device registration to hub (central server) or any other functionality found that isnt already known. Assuming it is our central server @arnoan is syncing too I can not replicate this issue.

[arnoan]

@EdDixon
Thanks for the blazing fast response.
The problem on my MAC might be related to the outdated version of Python as well (#3593). Will update as soon as I have my Python up and running again.

The inability to register with the RasPi 2 remains though.

Any advice for further troubleshooting?
It all works fine up to the step where I enter my login credentials for the central server but then facing the error. This is happening on all my systems and various RasPi configurations (also completely fresh installs). Also tried it from different network environments and the error remained. Could this be related to my geographical region? IP address from Germany...

Might set up a virtual machine running windows later today and see if the problem persists.

Question: For the time being is there a workaround so I could still eventually sync the data from my One-Click Registration setup with the central server at a later point in time? Need to finish setup for the refugee camp as fast as possible but reluctant to set up a system I won't be able to monitor later on. Not registering the deployment at all for the time being might be an option (I'm inserting all learning material manually anyway) but scared to end up with a corrupt library if I try at a later point in time and it fails.

PS: Please point out if I should better not use the issues here for asking this kind of advise. Am new to github and still need to get a feeling for the conventions in place here.

[EdDixon]

@arnoan you're most welcome in our preparation for the 13.1 release we ran into installer issues on Windows testing which once resolved, we never went back and fully checked against the MAC installation process because the GIT MAC installation had been working perfectly in prior release candidate testing and none of the code changes involved things in the MAC install process. When I saw the issue and with a graphical installer here planned for RC testing soon it sounded the alarms for me to make sure everything should be working as designed. So, your issues have actually helped by allowing us to proceed with confidence that the 13.1 GIT MAC installation method is working which the graphical installer models in its design.

Just to clarify the issues you are having are with the newest model Raspberry PI 2 and not the model B? Regretfully I do not the model 2 yet but have done recent testing on the model B and everything on that version does work as expected on 13.1 as well. Regarding the central management changes and registration questions as far as I know that is not possible yet but @jamalex is doing a lot of the work on the central server code and would be a better source for an answer on that one. I suspect (hope) those features will be added soon as there are others who have recently asked for those capabilities including myself.

This is the best place for letting us know about actual problems all eyes are on these issues, for help or more general non KA Lite / but related things hipchat (which I did see you go to first) is a better place to go I think. But you did great! the MAC python information is being added to the documentation which it needed to be and the 13.1 installer has been tested (which it also needed to be) going into the graphical installer phase of our evolution here. So Thank You!

[arnoan]

@EdDixon
Thank you for all the valuable information! I'm happy to jump in and contribute in whatever way I can. I will actually be around in San Diego in Fall for a semester doing an internship at FLE. So might meet you there in person? Super enthusiastic about ka-lite and all the other projects down the pipeline. I see so incredibly much potential here!

Yep, I can confirm it's happening on two independent Raspberry Pi 2 (Model B as well but the new generation that just came out a few weeks ago). Also have 4 slightly different setups on separate SD cards here to play with and couldn't register with any of them so far.

So I hope the problem on my Mac is just related to an improper Python installation but not sure on that.

If you need any (not too technical) trouble-shooting done I'll be happy to do that. Will try to borrow an old RasPI now and try my luck with that one. Also with the server running on RasPi 2 it takes a very long time on client devices (or the internal browser for that matter) to load the topic tree in the user interface. ~20 Seconds for the content to appear. I included the "DO NOT CACHE...." line in my local_settings.py as advised but maybe RasPI 2 is not properly recognised.

Also during setup there is no special "optimisation for PI" taking place as pointed out somewhere in the manual. I'll get my hands on an old PI as fast as possible and once I have clarity on how things SHOULD be working I will happily open up a couple of new issues for all the bugs specific to the RasPi 2. (Probably just a matter of it not being recognised by whatever hardware detection processes are in place.)

[EdDixon]

Very good to know! Be advised though that the older 215MB Ram Pi's are known not to be compatible with our 13.1 system and we recommend staying on 12.x for that. The newer 512MB Model B issue you ran into sounds similar to what I encountered with a bad USB card here in testing though so you might try switching it out with a different one. I was very surprised to find that my more expensive SSD "level 10" complaint card would gave me issues where the much cheaper cards did not? As long as your running raspbian, installed python as described and following the rest of the docs everything should work like clock work. I ended up with a wireless PI I can directly connect too after following the complete procedure. I am in sunny Las Cruces here but who knows maybe we will meet one of these days!

[arnoan]

Just to clarify again: I'm running two Raspberry Pi 2 Model B (https://www.raspberrypi.org/products/raspberry-pi-2-model-b/) with 900MHz quad-core ARM Cortex-A7 CPU and 1GB RAM.

Working with 2 San Disk class 10 32GB, 1 San Disk class 10 8GB and one San Disk class 4 card here. Will try with a card from another manufacturer now if I get a chance.

And #3593 (python crashing) is resolved now but the inability to register with the central server persists on my Macbook Air 4GB Ram 1,7 GHz i5 Yosemite 10.10.3 with Python version 2.7.9. And I ran out of ideas now as to what the problem might be. Anything in the settings of my MAC that could influence the verification procedure? Do you know what the usual triggers are for this error to occur?

[jamalex]

Since it happened for @arnoan with two different devices, but not for single-click reg, it seemed likely that this was an issue with the Sharing Network created on the Hub, so I dug around a bit in there.

It seems the "Arno's Organization Sharing Network" (Zone) object on the Hub has signature issues, and isn't validating, which is what is causing the error whenever any device tries to register against that Sharing Network. It looks like there are a handful of other Sharing Networks with similar errors on the Hub (22, out of 5575), and one thing they all have in common is that they all have descriptions added.

For this reason, and since the counters on these Sharing Networks are almost all in a recent range, I'm guessing this happened due to the same reason as #2470, and was fixed in #3496. I'm guessing this Sharing Network was created earlier this year, prior to the fix being deployed.

I have manually re-saved all the failing Sharing Networks, so the reg will hopefully now go through (just refresh the local device's reg page). If so, we can close this issue for now, and revisit if it somehow happens again.

[arnoan]

Thank you for looking into this on the server side @jamalex. I can confirm that registrations are working smooth now. Both on the MAC, as well as on my RasPi 2's. Nothing blocking our local refugee camp implementation anymore now. :-)

And yep, the initial sharing network was created some ~2-3 months ago

[jamalex]

Woohoo! Thanks for reporting the issue, and don't forget to take lots of pictures/video as you set things up at the camp!