Upgrading to separate databases for KPI and KoBoCAT

Hi @tolexy, could you get inside the failing container, using kobo-install$ ./run.py -cf run --rm kpi bash or perhaps kobo-docker$ docker-compose -f docker-compose.frontend.yml -f docker-compose.frontend.override.yml run --rm kpi bash and see what /srv/src/kpi/docker/init.bash looks like? Some things that might be helpful to know: is it executable; can you cat it; can you start it with bash /srv/src/kpi/docker/init.bash; can you start it with /srv/src/kpi/docker/init.bash?

thanks for the reply. I was eventually able to get kpi running but honestly not sure why and dont like that. I will make some tests with KPI starting init.bash manually. I am thinking the below may have clues as well.

When trying to use this same process of building a new image for kobocat (to increase the file upload limit going into our S3 bucket) I got these errors flowing through logs after every other container started.

kobocat_1         | runsv celery: fatal: unable to start ./run: access denied
kobocat_1         | runsv uwsgi: fatal: unable to start ./run: access denied
kobocat_1         | runsv celery_beat: fatal: unable to start ./run: access denied

so I go poking into the container in etc/service, follow the symlinks to srv/src/kobocat/docker and come to find out they werent executable by anyone.

root@kobocat:/srv/src/kobocat/docker# ls -l
total 44
-rw-r--r-- 1 root root  414 May 22 17:46 backup_media.bash
-rw-r--r-- 1 root root  202 May 22 17:46 backup_media_crontab.envsubst
drwxr-xr-x 2 root root 4096 May 22 17:46 cron
-rw-r--r-- 1 root root 1059 May 22 17:46 init.bash
-rw-r--r-- 1 root root 1531 May 22 14:22 kobocat.ini   
-rw-r--r-- 1 root root  295 May 22 17:46 run_celery.bash  <---
-rw-r--r-- 1 root root  327 May 22 17:46 run_celery_beat.bash  <---
-rw-r--r-- 1 root root  123 May 22 17:46 run_tests.bash
-rw-r--r-- 1 root root  750 May 22 17:46 run_uwsgi.bash  <----

The symlink exists in /etc/service and were all executable except for uwsgi (had to chmod x). This all worked fine, though this of course isnt persistent when restarting.

in the stock kobotoolbox/kobocat:2.020.18 image everything looks fine:
-rwxrwxr-x 1 root root 295 Apr 30 06:40 run_celery.bash

I can probably modify the Dockerfile to add these permissions on build, but it strikes me that the stock img works and then mine doesn’t even when it is the zipped 2.020.18 release. Makes me think there is something fishy with the user permissions. Currently this is running on AWS Lightsail created new user for kobo. Any way, thanks for any insights if the above was at all helpful

1 Like

Hi @jnm,

after following the steps, update fails like this after DB backup questions:

Traceback (most recent call last):
File “run.py”, line 59, in
Command.help()
File “/home/kobo/kobo-install/helpers/command.py”, line 524, in update
File “/home/kobo/kobo-install/helpers/template.py”, line 54, in render
# Environment
File “/home/kobo/kobo-install/helpers/template.py”, line 233, in __write_templates
“aws_backup_bucket_deletion_rule_enabled”, “True”, “False”),
File “/usr/lib/python3.5/string.py”, line 129, in substitute
return self.pattern.sub(convert, self.template)
File “/usr/lib/python3.5/string.py”, line 119, in convert
val = mapping[named]
KeyError: ‘REDIS_PASSWORD_JS_ENCODED’

Any ideas how to get past this? Python3 is 3.5.3, and a working KoBo installation to start with ( kpi 2.019.35b-hotfix2)

Thank You,

Hi @maric.vladimir, could you upgrade your kobo-install to 2.020.19 and try again?

1 Like

@tolexy, thanks for the info. What OS are you using to build your custom images (and what kind of file system do the KoBoCAT and KPI source files reside on)? I think that Docker’s COPY preserves permissions when copying files from the working directory to the container, but maybe it fails in certain environments:

Thanks @jnm, we did and it worked flawlessly. 2.020.19 is in fact currently the last commit in this repo?

Thanks for the hint. Maybe you should update the doc above? Or is it something installation-specific?

Thank you,

1 Like

Hi @jnm,

there is another problem we are facing. Access to legacy projects (second icon from the bottom in the left menu bar) opens KoBo login screen. We did populate_kc_xform_kpi_asset_uid in the KPI container as advised above, and it will try to access user’s path on kobocat, but will redirect instantly to the login screen.

Another thing that I noticed does not work on the current installation, as well as the new one, is “Logout” in the user menu - it does nothing.

Any ideas how to get the kobocat and legacy projects running?

Thanks in advance,

Good point; I’ve updated the instructions to specify 2.020.23, which is now the latest.

1 Like

Redis is now used to share sessions between KPI and KoBoCAT, and it seems like that’s not working properly for you. A session cookie problem could also cause this issue. I can’t compile detailed steps for you to try right now, but perhaps you can uncover something out of place by looking in these areas.

The command populate_kc_xform_kpi_asset_uid is not actually related to this: it’s only for making sure REST Services work with forms whose KoBoCAT id_string is distinct from the KPI asset.uid.

1 Like

Thanks @jnm,

can you please give me some pointers, things to try out, some direction? It might prove useful for others too.

I cannot find anything out of the ordinary, unfortunately.

Thanks in advance,

Sorry for the late reply, I got it all working by indeed mod-ing the dockerfile to add permissions on build. I build using docker-hub built in resources on push to git. One system is Ubuntu 18 (2.020.23) and one is Ubuntu 16 (shared-database) on Lightsail and Azure respectively, and a dev/sandbox copy in azure as well. I am sure it is the environments that are causing some issues but have been able to sort it all out eventually.

1 Like

Hi, we have installed the Kobtoool when there was no ‘kobo-install’ repository, so can you please guide or provide a link where I can get the steps to upgrade to the latest version?
Thanks.

Hi @ryanend
Have you ever installed this before and it worked? If Not, I would suggest you recheck your installation process.

Stephane

Hi @stephanealoo yes it worked and we are using it.

1 Like

Hi I’ve upgraded my existing database to Postgre 9.5 and MongoDb 3.4, how do I use the kobo-install? I dont have this folder, because we did notuse it for installation.
Also I dont want to do a fresh installation of kobo using kobo-install and later dump the data, I just want to upgrade.
Any possible solutions? Thanks.

You could update your kobo-docker setup manually and then split the Postgres database using the same script that kobo-install executes: kobo-docker/postgres/primary/clone_data_from_kc_to_kpi.sh at master · kobotoolbox/kobo-docker · GitHub. You’d need to first pull the latest updates to kobo-docker from GitHub, then update the configuration (crucially, specifying a new database name for KPI), then run that script.

Alternatively, you could:

  1. clone the shared-database-obsolete branch of kobo-install;
    • to avoid conflicts with your existing installation, do not put clone kobo-install alongside your existing kobo-docker directory;
  2. set up kobo-install “from scratch” (setting everything to match your current install);
  3. let it start up empty of data, and make sure it works;
  4. STOP ALL CONTAINERS (both new and old);
  5. kobo-install will have created a new kobo-docker directory. inside it, rename .vols to something else;
  6. copy your old kobo-docker/.vols to the new kobo-docker directory;
  7. start kobo-install again; make sure it works;
  8. follow the instructions in the first post of this thread, beginning with

    Enter the kobo-install directory:

Whatever you do, make sure you take backups first. We’d like to help but are very busy with running our own instances and maintaining the software, so we cannot guarantee timely responses if you have trouble.

2 Likes

2 posts were split to a new topic: Manually set address space for Docker bridge

Hi @jnm thanks for the quick reply and perfectly detailed solution.
However I am facing another problem after upgrading, I can now only see the forms and the count of total submissions, but I am not able to view any previous submissions in the form. I can view the new submissions though.

I followed the exact same steps you mentioned also the ones mentioned by @nolive (thanks a lot @nolive for your answer on other post), but I could not see the old submissions/data in the newer updates.

Any views regarding this will be a great help, thanks. Also can you let us know where are submissions stored in the database? Many thanks again.

Hi @jnm I finally upgraded to the new stable version.

Here’s is what I did -
My postgres version in the old Kobo was 9.4. So I had to first upgrade it and this link https://github.com/kobotoolbox/kobo-docker/blob/master/doc/March-2019-Upgrade.md did not worked to upgrade the existing database because postgis 2.5.4 was not available for postgres 9.4. (Ubuntu 16.04). So to upgrade this I created a new postgres container with image - ‘mdillon/postgis:9.5’ and then dumped the data here using pgdump.

Then I stopped all the old containers, and installed a fresh installation of Kobo using kobo-install. I then copied the .vols folder from old kobo to new one, but it did not worked because mongodb container failed to start and hence I could not see the data in the new Kobo. So I had to manually dump the mongodb and postgres db here on the new kobo installation. The .vols copy method did not worked.
Then as per the instructions above we upgraded and bow have the two postgres database as per latest release.

Many thanks @jnm and @nolive for all the help.

3 Likes

Hi @tolexy
I’m in the same boat as you were. My containers keep restarting due to permission errors in executing some files, and I think it happens during the copy action.
Can you explain how you solved it?