Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running your own server is severely underdocumented #1002

Open
w23 opened this issue Sep 30, 2024 · 10 comments
Open

Running your own server is severely underdocumented #1002

w23 opened this issue Sep 30, 2024 · 10 comments

Comments

@w23
Copy link

w23 commented Sep 30, 2024

(I don't mean it as a rant or an attack, please don't read it as such -- the tone just a limitation of my English, and lack of time to smoothen the cultural discrepancy edges. I do appreciate your effort on this project.)

Using the official server is impractical -- when I tried, I was 650-something in line, and it was barely moving, decreasing by one every 5-10 minutes or so.

And after three hours of trying to run my own server I must declare an utter defeat.

  1. Apparently the LuCI plugin talks to the server directly from browser (that took 15 minutes of frantic tcpdumping to figure out).
    That runs into "mixed content" https issue, and can be trivially worked around in Firefox by clicking on the lock in the URL bar and disabling protection.
    CORS is more painful -- I had to run the server behind nginx reverse-proxy with add_header 'Access-Control-Allow-Origin' '*' always; directive.
  2. Then it will just run into a 404 wall of what ultimately, through a redirect or two, amounts to absent overview.json. I suspect that it is generated somehow through running poetry run python3 misc/update_all_targets.py. But it didn't work here. It just failed with thousands of messages like
...
INFO:     10.89.0.27:39372 - "GET /api/v1/update/23.05.2/bmips/bcm6362 HTTP/1.1" 403 Forbidden
INFO:     10.89.0.27:39372 - "GET /api/v1/update/23.05.2/bmips/bcm63268 HTTP/1.1" 403 Forbidden
INFO:     10.89.0.27:39372 - "GET /api/v1/update/23.05.2/bmips/bcm6368 HTTP/1.1" 403 Forbidden
INFO:     10.89.0.27:39372 - "GET /api/v1/update/23.05.2/bmips/bcm6358 HTTP/1.1" 403 Forbidden
...

Having no easy way to debug it (I am absolutely not familiar with neither python web stuff, nor podman or containers at all; found no easy way to iterate -- all changes to sources needed a full podman kill && podman rm && podman-compose build, a lengthy and annoying operation), I've tried playing around public dir mount. It seems that it's hardcoded essentially to /app/public in the sources, but podman-compose.yml mounts it at a different location depending on where the source was cloned into. This is where I ran out of time and could not continue further.

There's another thread #975 where @efahl was somehow able to do it. But the full steps are yet to be documented.

If I get more time to try it (somewhat unlikely, at this point I'm feeling like not falling into sunk-cost fallacy and just re-flashing the devices manually), I'll document my steps in this thread.

I'd appreciate if anyone also tried and has any insight.

@efahl
Copy link
Contributor

efahl commented Sep 30, 2024

Yeah, the lack of docs is one of the big items on my list. I'll get back to you here, as soon as I get some time.

In the meantime, try these changes in podman-compose.yml and see if they help:

...
services:
  server:
    image: "asu:latest"
    build:
      context: ./
      dockerfile: Containerfile
    restart: always
    environment:
      - REDIS_URL=redis://redis/
    ports:
      - "0.0.0.0:8000:8000"     <-- assuming you are using a local machine, this exposes it to the LAN no need for proxy
    volumes:
      - $PUBLIC_PATH:/app/public:rw,rshared   <-- I found this works better, must match below
    depends_on:
      - redis

  worker:
    image: "asu:latest"
    build:
      context: ./
      dockerfile: Containerfile
    restart: always
    command: rqworker --with-scheduler
    environment:
      - REDIS_URL=redis://redis/
    volumes:
      - $PUBLIC_PATH:/app/public:rw,rshared    <-- same as above
      - $CONTAINER_SOCK:$CONTAINER_SOCK:rw
    depends_on:
      - redis
...

Should mount the storage on the host in ./public then if you log into the pods podman exec -ti asu_worker_1 /bin/bash and poke around, you should see the same files on both worker and server under /app/public/.

The misc/update_all_targets.py needs some hackery to work with port 8000 (plus it does all versions and targets, so way to much for casual use).

@divinehawk
Copy link

volumes:
  - $PUBLIC_PATH:/app/public:rw,rshared   <-- I found this works better, must match below

Which I had seen your comment sooner. After a few hours of debugging I found that this is the reason all of the json files are 404. The workers generate these files, but they are never accessible to the server without a volume mount. Honestly, I'm not sure how it ever worked.

@divinehawk
Copy link

A few questions for the devs to run an unofficial server:
1: Which version should be used for stability? Or what does the official server run? The version number always shows 0.0.0 in overview. Is 0.8.0 the recommended?
2: Is there a working podman-compose.yml? The current one does not work (see above and #975).

Thank you.

@efahl
Copy link
Contributor

efahl commented Oct 6, 2024

1: Which version should be used for stability? Or what does the official server run? The version number always shows 0.0.0 in overview. Is 0.8.0 the recommended?

I'm running main, as is the production server. The tagged versions were sort of dropped apparently, when things were moving too fast to keep doing releases a couple times a week...

2: Is there a working podman-compose.yml? The current one does not work (see above and #975).

Yeah, that was my big stumbling block, too. I've got some hackery in various code in addition to the yml changes above, but I need to clean it all up and see if @aparcar thinks it's right. I'll be sure to post here when I get it clean-ish and commit something.

@efahl
Copy link
Contributor

efahl commented Oct 11, 2024

I have spent the last couple days stripping down my code changes and documenting the whole process of setting up a local server.

https://github.com/efahl/asu/blob/local-server/local-server.md

@w23 @divinehawk
If you could try this out, changing the clone command to use my branch, I would very much appreciate any feedback you can provide.

git clone https://github.com/efahl/asu.git
git checkout local-server

@efahl
Copy link
Contributor

efahl commented Oct 12, 2024

Oops, had a major omission in the local-server.md (the initial setup of .env was missing). I just committed that change to the branch.

@romanovj
Copy link

@efahl can you provide nginx config file?

@efahl
Copy link
Contributor

efahl commented Oct 20, 2024

@efahl can you provide nginx config file?

I don't run any proxy in front of the ASU server (mine is purely local on http) and have no knowledge of how to do so. If you come up with a config, let me know and we can incorporate it into the documentation.

@romanovj
Copy link

@aparcar
Can you share latest caddy config for asu(at least strings for CORS)?

@romanovj
Copy link

romanovj commented Oct 29, 2024

@efahl can you provide nginx config file?

I don't run any proxy in front of the ASU server (mine is purely local on http) and have no knowledge of how to do so. If you come up with a config, let me know and we can incorporate it into the documentation.

worked for me (caddy v2.8.4)

(cors) {
  @cors_preflight method OPTIONS
  @cors header Origin {args.0}

  handle @cors_preflight {
    header Access-Control-Allow-Origin "{args.0}"
    header Access-Control-Allow-Headers "Content-Type"
    respond "" 204
  }

  handle @cors {
    header Access-Control-Allow-Origin "{args.0}"
  }
}

sysupgrade.xxx.yyy {
	import cors *
	uri replace /api/overview /api/v1/overview
	reverse_proxy * localhost:8000
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants