Web deployment with static content

[KB3HNS]

Description

Hello. I need some clarification.
I've built my own version of gitea for Debian 11 (bullseye) including PAM and excluding the built-ins. I'm currently running a local instance of APACHE 2 with appropriate mod_proxy and mod_proxy_http. I am able to confirm that apache is correctly passing requests to gitea. However, all requests are resulting in a 500 internal server error. Even when manually running gitea with the --verbose option there is very little information to go on as shown below (redacting some potentially sensitive information):

2022/11/17 00:01:12 cmd/web.go:217:listen() [I] [6375c018-5] Listen: http://0.0.0.0:3000/git
2022/11/17 00:01:12 cmd/web.go:221:listen() [I] [6375c018-5] AppURL(ROOT_URL): https://www.XXXXXX.END/git/
2022/11/17 00:01:12 ...s/graceful/server.go:61:NewServer() [I] [6375c018-5] Starting new Web server: tcp:0.0.0.0:3000 on PID: 2274289
2022/11/17 00:01:30 ...s/context/context.go:232:HTML() [E] [6375c02a] Render failed: html/template: "install" is undefined
2022/11/17 00:01:30 ...eb/routing/logger.go:99:func1() [I] [6375c02a] router: completed GET / for xxx.xxx.xxx.xxx, 500 Internal Server Error in 0.5ms @ install/install.go:90(install.Install)

I have copied the contents of ${BUILD_DIR}/"public" to /var/www-ssl/git-static, based on this documentation and the resulting gitea executable to /usr/local/bin. I have also set up an appropriate account to run under and systemd startup script based on these instructions.

My current app.ini:

[server]
STATIC_URL_PREFIX = /git-static
ROOT_URL = https://www.XXXXXX.END/git

If I run the application in the build directory it executes fine. However, the build directory resides on a dedicated build server and the build environment is purposefully not available on the production server (both the build system and the production server are running identically patched versions of Debian 11 - only that the production server does not have the ability to compile software for security reasons).
I desire to avoid building in the static content as this server has a heavy load and is somewhat stretched for resources as it is. PAM authentication is required as I have already implemented a system-wide user database and do not desire to maintain a separate authentication system.

Gitea Version

1.17.3 built with GNU Make 4.3, go1.19.1 : pam

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

Logs inline

Screenshots

-N/A- see logs

Git Version

2.30.2

Operating System

Linux xxxxxx 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux

How are you running Gitea?

See description.

Database

MySQL

[KB3HNS]

Further clarification, command line to execute gitea:
/usr/local/bin/gitea web -c /etc/gitea/app.ini

[KB3HNS]

After doing some searching, I believe that this is related to #18110

[clarfonthey]

Are you sure that the JS you're using matches the version of gitea correctly? Since my issue was having stale extracts and it not matching what the frontend was actually looking for.

[KB3HNS]

Are you sure that the JS you're using matches the version of gitea correctly? Since my issue was having stale extracts and it not matching what the frontend was actually looking for.

In my case, yes as I directly copied the public folder into my www-ssl directory (renamed, of course).

[wxiaoguang]

You are doing something wrong, unrelated to 18110

Please follow the guideline strictly, for example: the document https://docs.gitea.io/en-us/install-from-source/ has told you TAGS="bindata" make build

You may need TAGS="bindata pam" make build to build with PAM

[KB3HNS]

As per my description: adding bindata is not desired. I would much prefer to have the static content hosted separately so it will be cached by my CDN and therefore won't require server resources to provide. According to documentation, bindata is an optional flag.

[wxiaoguang]

I can not understand why "bindata" is not desired (you didn't mention in your description either Hmm, I didn't understand that before). It's only optional for experienced users who clearly know what they want and fully understand how Gitea assets work.

If you want to play with bindata by yourself, please also put the template files in the correct places, following to the document.

For a quick and stable solution: just use bindata. You can still serve these static resources via CDN (just proxy the static assets to Gitea instance, it's very fast and will be cached soon)

[wxiaoguang]

Another choice is that you still build Gitea with bindata, then copy the JS/CSS resources to your filesystem as your plan (I won't recommend so, you will run into other problems if you upgrade Gitea but forgot the update the resources).

bindata is not only for JS/CSS, it also contains templates, which is not related to your CDN, but used by Gitea internally.

[KB3HNS]

Primary issue is that the current server is a VPS with limited memory and CPU resources. It is shared between 3 total developers and has very low code velocity. I would prefer for static assets to be served directly by apache and not proxied through an additional application - this will allow cloudflare to properly cache them while continuing to forward dynamic content through to the application. I am running many other services on the same web server - all using FCGI for HTTP/2 and as a result apache has a 512MB/instance overhead so I am limited to the total number of apache instances that I can support (3). An instance that is being used to forward a request for what amounts to a static file is an instance that could have been put to better use generating dynamic content.

To get around the 500 error, I did to a build with bindata to prove out the issue - again not desired. There was no setting of STATIC_URL_PREFIX that would allow the control panel (first page prior to database provisioning) to properly load without throwing the pop-up exception referred to in the referenced issue, hence why I do believe this to be a legitimate bug.

[wxiaoguang]

I see, if you want to save memory heavily, you should look into the bindata details to separate the assets carefully and put bindata files in your deployment manually. I doubt that it won't save too much memory ....

ps: I proposed a PR to fix the document: #21853