Does Central run on a Raspberry Pi 4? Is there any documentation as to differences in install?

Support
21

Ah that sort of makes sense!
Yes Pi uses ARM Cortex-A series (72 for Pi4 and 53 for Pi3, 7 for the Pi2)

23

I know it’s been a minute, but has anyone successfully done this (run ODK Central on Raspberry Pi) recently? Any updates on this?

24

Hey!

Yes, I'm running ODK Central on a Raspberry Pi (for personal use - more like a staging server). Sharing how I set it up, the issues I faced, and how I fixed them. Might help someone trying the same.

Challenge 01: ODK Central's installation doesn't like Raspberry Pi's (or MacBook's) CPU

ODK Central's installation is made for amd64 / x86_64 systems. Most Raspberry Pis use arm64 / aarch64, so obviously - installation fails. Reason? - tianon/postgres-upgrade:9.6-to-14 - this here is a main point / key of failure while installation as it requires amd64 arch and doesn't function for arm64 which Raspberry Pi uses, everything else works fine on arm64 except this one thing.

image
image911×197 19.8 KB

I did a little research on ODK Central's docker-compose.yml, from what I saw:

  • tianon/postgres-upgrade:9.6-to-14 is used to upgrade Postgres from 9.6 to 14 for old ODK Central installs - which makes sense for people using a very old ODK Central version and are wishing to upgrade to the latest one keeping all the data intact. BUT! This doesn't make sense for people who are setting up a fresh and a clean ODK Central server (I mean, we can directly go for Postgres14, why bring in this 9.6 thing upgrade in-between for the fresh installations?!). Yet, ODK Central's installation procedure still enforces this upgrade thing, even for the fresh installations. If you ask me - "But, why?!" - I don't really have an answer to that!

Solution? Skip the Postgres 9.6 to 14 upgrade part for fresh installations. Steps below:

  1. I edited the docker-compose.yml and removed/commented this part:
    postgres:
    # This service upgrades from postgres 9.6 to 14.
    # The legacy name must be maintained to allow access to the anonymous volume.
    build:
      context: .
      dockerfile: postgres-upgrade.dockerfile
    volumes:
      - /var/lib/postgresql/data
      - postgres14:/var/lib/postgresql/14
      - ./files/postgres14/upgrade:/postgres14-upgrade
    environment:
      PGUSER: odk
      POSTGRES_INITDB_ARGS: -U odk
      POSTGRES_PASSWORD: odk
      POSTGRES_DB: odk
  2. Finally, the ODK Central's installation worked perfectly on arm64, but Postgres 14 didn't even start inside the container because it was waiting for the upgrade flag. So, I also removed/commented out this check in central/files/postgres14/start-postgres.sh:
    if ! [[ -f "$flag_upgradeCompletedOk" ]]; then
  log "Waiting for upgrade to complete..."
  while ! [[ -f "$flag_upgradeCompletedOk" ]]; do sleep 1; done
  log "Upgrade complete."
fi
  3. The last step, just DON'T run: touch ./files/allow-postgres14-upgrade, the way documentation suggests for the installation. And, bang - it worked! Built the containers again and started them. A fresh and fully functional ODK Central installation over Raspberry Pi.
    docker compose down && docker compose build && docker compose up -d

Challenge 02: No static IP from my ISP (may not be a challenge in your case?)

  • My ISP doesn't offer me a static IP (and I'm clearly behind CGNAT), but I still wanted my ODK Central server on my Raspberry Pi to be accessible worldwide via internet, 24/7.

Solution? Reverse proxy + tunneling. Steps below:

  1. I configured ODK Central behind reverse proxy, so that I could have better control over the ports.
  2. I had to tunnel my Raspberry Pi to the internet (the free ways).
    • First I used Cloudflare Tunnels for this - which worked fine but I have trust issues with Cloudflare.
    • Then I tried telebit.io (open-source, Cloudflared alternative) - worked fine but was slow and old.
    • Finally switched to frp (Fast Reverse Proxy) - and I'm still using it. Works great.

Last words: In my case, I wanted my ODK Central on Raspberry Pi to be available over the internet, so I went with the tunneling approach. But if I ever needed a fully local setup, I'd look into tools like dnsmasq or Pi-hole (since ODK Central needs a domain and won't work with just an IP). I'd also explore how to install CA certificates on Android (otherwise ODK Collect may not work), and of course, handle the Enketo part too.

That's all. Great day!

2 Likes