Upgrading to separate databases for KPI and KoBoCAT

[ryanend]

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.

[ks_1]

@tolexy

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

@tolexy

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.

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?