SOLUTION:

The issue was - the ‘New UI’ docker image was automatically building for AMD64, but the Linux server is an ARM64/v8.

I had to add QEMU and multi-platform build commands to the docker-image.yml file (in Github Actions).

This creates an additional docker image for ARM64 machines, which loads and runs successfully.

This was discovered by manually building a docker container, and receiving the following message: WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

So if you get that message, you must build your docker image for the platform you are on (or multiple platforms).

** == ** == ** == ** == ** == ** == **

ORIGINAL ERROR:

THE SETUP and ERROR

  1. I made a fresh ansible install, on a fresh ubuntu 20.04 server - the Lemmy instance runs perfectly.
  2. I made a fresh fork of the 16.7 Lemmy-UI.
  3. I built a docker-image of that forked UI, and loaded it via docker-compose (here is my docker-image.yml build file ).

Now I am getting a “502 Bad Gateway - nginx” error (the site does not load).

NGINX error log shows:

connect() failed (111: Connection refused) while connecting to upstream, client: 75.222.232.212, server: ggg.com, request: "GET / HTTP/2.0", upstream: "http://0.0.0.0:15153/", host: "ggg.com"
  • Nginx config has not been modified (but here is the config anyway - ggg.conf)

  • Docker log is clean.

**

DIAGNOSIS

When I list docker containers, there is no PORT mapped to the ‘New-UI’ image container.

(However, when running the ‘default lemmy-UI’ image container, the PORT is successfully mapped to 127.0.0.1:15153->1234/tcp)

It seems I must create a new Container, using the ‘New-UI’ image, and map the PORT to 127.0.0.1:15153->1234/tcp (unless an Environment Variable can do it).

^ Now I must figure out that exact docker command. (because docker run -d -p 127.0.0.1:15153:1234 [ImageID] does not successfully create the container.)

**

Here are the Env Vars I’ve added (in various combinations/values):

  lemmy-ui:
    environment:
      - LEMMY_UI_HTTPS=true
      - LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy:8536
      - LEMMY_UI_LEMMY_EXTERNAL_HOST=ggg.com
      - LEMMY_UI_DISABLE_CSP=true
      # - LEMMY_UI_LEMMY_WS_HOST=lemmy:8536
      # - LEMMY_UI_HOST=0.0.0.0:1234

here is the full docker-compose.yml (only changed Env Vars)

    • PicoBlaanketOP
      link
      fedilink
      1
      edit-2
      2 years ago

      Thank you for the reply.

      If I can eliminate QEMU, I’d love to (it’s slow).

      Have you shared your workflow.yml anywhere? (for the lemmy-ui DockerHub image build)

      **

      This is my current workflow.yml (for Github Actions).

      The reason I added QEMU was:

      1 - Github Actions was only building the ‘forked-UI’ docker-image for AMD64.

      2 - I then added buildx and specified a platform in the workflow:

       - name: Buildx
         uses: docker/setup-buildx-action@v1
      
       - name: Build and push
         uses: docker/build-push-action@v2
         with:
           context: .
           platforms: linux/arm64/v8
      

      Which failed with:

       Error: buildx failed to solve: process "/dev/.buildkit_qemu_emulator /bin/sh -c 
       yarn install --pure-lockfile" did not complete successfully: exit code: 1
      

      3 - I then added the QEMU step, and the build succeeded.

      **

      *Lemmy-Translations

      I also had to add an “Update lemmy-translations” step:

         - name: Update submodules
           run: git submodule update --init --recursive
      

      otherwise the build would fail with:

         /usr/src/app/generate_translations.js:7
         files.forEach(filename => {
            		       ^
         TypeError: Cannot read properties of undefined (reading 'forEach')
         at /usr/src/app/generate_translations.js:7:9
         at FSReqCallback.oncomplete (node:fs:201:23)
      

      After adding that “Update Submodules” step, the build succeeds.

      Is there a better way to do it?

      **

      I am 100% open to any suggestions/critiques (and if your workflow.yml is public, I will study it and learn).

      • DessalinesM
        link
        fedilink
        11 year ago

        We use drone, there is a .drone.yml file in the root of both lemmy and lemmy-ui. But I don’t understand why you aren’t using the existing images, which are already built for arm.

        • PicoBlaanketOP
          link
          fedilink
          1
          edit-2
          1 year ago

          I forked the UI at 15.4, to build some new UI features.

          Next I will manually add those features to this clean fork of Lemmy-UI 16.7 (so all code is up-to-date).

          If I may ask, do you recognize what this issue might be?

          These pages work:

          • Home page loads perfectly (when there are 0 posts)
          • Create a community works
          • visiting a community works (when there are 0 posts)
          • New user registration succeeds

          However, I get a loading spinner and Uncaught TypeError: Cannot read properties of undefined (reading “____” ) on the following pages [in console]:

          • Create Post (reading “at”)
          • User Profile (reading “split”)
          • Settings (reading “map”)

          And if I do create a post [by using ‘default UI’, and then switching back to ‘forked UI’], then Post-List pages also give that error:

          • Community, Home (reading “split").

          So my question is:

          Do you see a likely cause from that pattern?

          (Perhaps a backend/database connection - an undefined string).

          If you have an idea, I would love to know.

          ENVIRONMENT:

          • Docker + NGINX logs seem to be clean.

          • I have not modified the ‘UI fork’ code.

          • I have not modified anything on the VPS - only added these Environment Variables in docker-compose.yml (in various combinations):

            environment:
             - LEMMY_UI_LEMMY_INTERNAL_HOST=lemmy:8536
             - LEMMY_UI_LEMMY_EXTERNAL_HOST=ggg.com
             - LEMMY_UI_HTTPS=true
             - LEMMY_UI_DISABLE_CSP=true
             - LEMMY_UI_HOST=0.0.0.0:1234
          
          • The install was done by ansible.

          Thank you for your time and work. Lemmy is awesome.

          [I am learning about drone now.]

          • DessalinesM
            link
            fedilink
            11 year ago

            I can’t help you debug forks, you’re on your own there. Its almost certainly because your forked UI is using a wrong version of lemmy-js-client that works with the lemmy backend, so its missing or has incorrect fields in the request JSON.

            • PicoBlaanketOP
              link
              fedilink
              11 year ago

              1 - I’ve completed your suggestions.

              You are correct - I had forked the ‘Main’ branch, which runs a different js-client than UI-16.7.

              So I merged 16.7 into my fork… and everything WORKS.

              Thank you - that was helpful.

              [I also set up Drone. Yes, it builds very fast.]

              **

              2 - Perhaps “LEMMY_DATABASE_URL” shows an obsolete value in the config docs:

              • It is listed as - postgres://lemmy:pw@LEMMY_DB:5432/lemmy
              • And perhaps should be - postgres://lemmy:pw@POSTGRES:5432/lemmy

              That 2nd string worked for me anyway - on an ansible install. (the former gives a 404 fetch error).

              **

              Thank you very much again.

              Lemmy is running smooth and looking great.

              I hope you are doing alright.

  • loathesome dongeater
    link
    fedilink
    12 years ago

    Are you using nginx from a docker container too? I think it’s most likely that whatever port you set up for reverse proxying the UI is incorrect. To kind of test this, you can try changing the UI’s port. If the ports are mismatched you should get the bad gateway error again.

    • PicoBlaanketOP
      link
      fedilink
      2
      edit-2
      1 year ago

      NGINX was setup by the ansible install (it is running directly on the VPS).

      The reverse-proxy ports were chosen by the ansible install. They work correctly when running the default lemmy-ui.

      I have not modified anything in the ‘Lemmy-UI fork’ code (only added the docker-image.yml build file on github).

      I have not modified anything on the VPS (other than the Environment Variables in docker-compose.yml, listed above).

    • PicoBlaanketOP
      link
      fedilink
      1
      edit-2
      1 year ago

      When I list docker containers, there is no Port mapped to the ‘New-UI’ image container.

      However, when running the ‘default lemmy-UI’ image container, the Port is mapped to 127.0.0.1:15153->1234/tcp

      It seems I must create a new Container, using the ‘New-UI’ image, and map the Port to 127.0.0.1:15153->1234/tcp (unless an Environment Variable can do it)

      ^ Now I have to figure out that exact docker command. (because docker run -d -p 127.0.0.1:15153:1234 [ImageID] does not successfully create a mapped container.)

      • loathesome dongeater
        link
        fedilink
        22 years ago

        That docker run command looks correct. What is the error message you are getting? My guess is that soemthing else is already occupying your system’s port 15153.

        • PicoBlaanketOP
          link
          fedilink
          2
          edit-2
          2 years ago

          It’s fixed!

          The issue was - the ‘New UI’ docker image was automatically building for AMD64, but the Linux server is an ARM64/v8.

          I had to add QEMU and multi-platform build commands to the docker-image.yml file (in Github Actions).

          This creates an additional docker image for ARM64 machines, which loads successfully.

          This was discovered by manually building a docker container, and receiving the following message: WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

          Thank you very much for replying KSYNWA! It helped me target the right area to find the problem.

          I’m sure I’ll be back with another question, as I’m kinda wingin it over here.