localhost/launchpad giving 404 error back after setup

[titanbin]

Steps to Reproduce

1.Run the setup commands from the Quick Start Guide 2.Run sudo bin/start 3.Open http://localhost/launchpad

Expected Behaviour

I get the launchpad web page to setup overleaf

Observed Behaviour

I get a 404 file not found error instead

Context

I cannot setup my overleaf server

Technical Info

• URL:localhost/launchpad
• Browser Name and version:Firefox 125.0.2
• Operating System and version (desktop or mobile): Ubuntu 24.04

Analysis

I ran bin/doctor, which gave no errors:

====== Overleaf Doctor ======
- Host Information
    - Linux
    - Output of 'lsb_release -a':
            Distributor ID:	Ubuntu
            Description:	Ubuntu 24.04 LTS
            Release:	24.04
            Codename:	noble
- Dependencies
    - bash
        - status: present
        - version info: 5.2.21(1)-release
    - docker
        - status: present
        - version info: Docker version 27.0.3, build 7d4bcd8
    - realpath
        - status: present
        - version info: realpath (GNU coreutils) 9.4
    - perl
        - status: present
        - version info: 5.038002
    - awk
        - status: present
        - version info: GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)
    - openssl
        - status: present
        - version info: OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
    - docker compose
        - status: present
        - version info: Docker Compose version v2.28.1
- Docker Daemon
    - status: up
    - server version: 27.0.3
====== Configuration ======
- config/version
    - status: present
    - version: 5.1.0
- config/overleaf.rc
    - status: present
    - values
        - OVERLEAF_DATA_PATH: data/overleaf
        - SERVER_PRO: false
        - OVERLEAF_LISTEN_IP: 127.0.0.1
        - OVERLEAF_PORT: 80
        - MONGO_ENABLED: true
        - MONGO_IMAGE: mongo
        - MONGO_DATA_PATH: data/mongo
        - REDIS_ENABLED: true
        - REDIS_IMAGE: redis:6.2
        - REDIS_AOF_PERSISTENCE: true
        - REDIS_DATA_PATH: data/redis
        - NGINX_ENABLED: false
        - NGINX_CONFIG_PATH: config/nginx/nginx.conf
        - TLS_PRIVATE_KEY_PATH: config/nginx/certs/overleaf_key.pem
        - TLS_CERTIFICATE_PATH: config/nginx/certs/overleaf_certificate.pem
        - NGINX_HTTP_LISTEN_IP: localhost
        - NGINX_HTTP_PORT: 80
        - NGINX_TLS_LISTEN_IP: localhost
        - TLS_PORT: 443
        - GIT_BRIDGE_ENABLED: false
- config/variables.env
    - status: present
    - values
        - SHARELATEX_FILESTORE_BACKEND: fs
        - SHARELATEX_HISTORY_BACKEND: fs
        - OVERLEAF_FILESTORE_BACKEND: fs
        - OVERLEAF_HISTORY_BACKEND: fs
====== Warnings ======
- None, all good
====== End ======

Running sudo docker ps gives:

CONTAINER ID   IMAGE       COMMAND                  CREATED          STATUS                    PORTS       NAMES
c42d984b1778   mongo:6.0   "docker-entrypoint.s…"   35 minutes ago   Up 10 minutes (healthy)   27017/tcp   mongo

[osman346]

same here do you virtualize your machine on proxmox ve?

[titanbin]

same here do you virtualize your machine on proxmox ve?

no just running on base ubuntu as is

[osman346]

have you checked if your cpu does have AVX feature?

[titanbin]

have you checked if your cpu does have AVX feature?

running lscpu | grep avx gives:

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm
pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni
pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer
xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid xsaveopt dtherm arat pln pts vnmi
md_clear flush_l1d

[davrot]

Same problem here. If I am on image: "sharelatex/sharelatex:5.0.7" there is no problem. But when I switch to image: "sharelatex/sharelatex:5.1.0" then I get this error message.

[MonsterDruide1]

I'm running into the same problem on our instance, and we are not using the toolkit for deployment, so it seems to be a problem across the entire overleaf project.

Looking at the source code for the launchpad, it seems like it's testing the connection by downloading a specific ide.js file from a pre-built path. This path should be sent in the header under the meta-attribute ol-ideJsPath. On instances running 7.0, this contains a proper path like:

<meta name="ol-ideJsPath" content="/js/ide-7f4b3063fdbd7770d150.js">

However, running 7.1, we get this:

<meta name="ol-ideJsPath" content="undefined">

I would assume the following line is at fault, somehow: https://github.com/overleaf/overleaf/blob/main/services/web/modules/launchpad/app/views/launchpad.pug#L31

The function buildJsPath is also used in one other location: https://github.com/overleaf/overleaf/blob/main/services/web/app/views/layout-base.pug#L37

Which does contain a proper value, even on 7.1:

<link rel="preload" href="/js/en-json-29887ebf6aad7274b8ac.js" as="script" nonce="">

I don't understand how undefined can end up as return value of buildJsPath though, which is defined here: https://github.com/overleaf/overleaf/blob/main/services/web/app/src/infrastructure/ExpressLocals.js#L158

Assuming staticFilesBase is "", which is the only way undefined can end up as the whole string (otherwise it would be somethingundefined or similar), the problem has to be that the webpackManifest does not contain ide.js.

This manifest is built around here: https://github.com/overleaf/overleaf/blob/main/services/web/webpack.config.js#L292-L296

So, looking at the Git history, I'm pretty certain that this commit is the issue: https://github.com/overleaf/overleaf/commit/c24ace801bf7e3a5475903c2fa7125e8cf3d7e28#diff-f664a365607494e60c8e2f1df05e1ac5adaed2873807673ad83e206c56c1116bL24 ^ removed ide.js from the entrypoints, causing it to not end up in the manifest, thus returns undefined and the test tries to hit a non-existant file.

[MonsterDruide1]

I can confirm that the line of thought in my previous message was correct. Changing this one line from the PR results in the checks returning OK again, even on 7.1.0.

[das7pad]

Hello,

Thank you for opening this bug report. The "Editor Resources" check has been removed in Community Edition and Server Pro 5.1.1.

Greetings, Jakob