Not Found: /login

[devcoisa]

Hello,
running DD 2.33 orchestrated on AKS.
Starting to have this problem with nginx container not able to connect uwsgi container. Any ideas ?

[04/Apr/2024 09:55:11] INFO [dojo.models:4537] enabling audit logging
System check identified no issues (0 silenced).
*** Starting uWSGI 2.0.23 (64bit) on [Thu Apr 4 09:55:13 2024] ***
compiled with version: 10.2.1 20210110 on 02 April 2024 18:39:01
os: Linux-5.4.0-1110-azure #116~18.04.1-Ubuntu SMP Fri Jun 2 22:11:08 UTC 2023
nodename: afaforgev2pr-defectdojo-5786f5b58f-4t2gz
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory: /app
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your memory page size is 4096 bytes
detected max file descriptor number: 1048576
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on 0.0.0.0:8081 fd 3
spawned uWSGI http 1 (pid: 18)
uwsgi socket 0 bound to UNIX address /run/defectdojo/uwsgi.sock fd 6
Python version: 3.11.4 (main, Aug 16 2023, 05:31:52) [GCC 10.2.1 20210110]
Python main interpreter initialized at 0x7faeecef6558
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 183136 bytes (178 KB) for 4 cores
*** Operational MODE: preforking+threaded ***
[04/Apr/2024 09:57:14] INFO [dojo.models:4537] enabling audit logging
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x7f56b6c11558 pid: 1 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (pid: 1, cores: 2)
spawned uWSGI worker 2 (pid: 19, cores: 2)
[04/Apr/2024 09:57:21] WARNING [django.request:241] Not Found: /login
[pid: 1|app: -|req: -/-] 10.63.80.114 (-) {34 vars in 392 bytes} [Thu Apr 4 09:57:20 2024] GET /uwsgi_health => generated 12974 bytes in 1081 msecs (HTTP/1.1 404) 7 headers in 230 bytes (1 switches on core 0)
[04/Apr/2024 09:57:30] WARNING [django.request:241] Not Found: /login
...

[devcoisa]

And after migrating from version 2.23.1 to 2.33.

[devcoisa]

Well after follow other hard approach we get rid of the problem.
We reset the system values to the initial state.
The issue was might related with JIRA integration or Jira web hook flags. After disabling the options "Enable JIRA integration" and "Enable Jira web hook" the issue has gone.
Let see if the this problem doesn't come up again with other DD instance running on version 2.32 and we need to migrate/upgrade to version 2.33.
Any clues from you or someone had before this behaviour ?

[devcoisa]

Unfortunately the problem is still not solved.

DefectDojo Pods Events:
...
Liveness probe failed: HTTP probe failed with statuscode: 404
spec.containers{uwsgi}
Readiness probe failed: HTTP probe failed with statuscode: 404
spec.containers{nginx}
..

Container logs:
...
uwsgi [uwsgi-http key: 10.63.81.71:8081 client_addr: 10.63.81.45 client_port: 65219] hr_read(): Connection reset by peer [plugins/http/http.c line 918]
uwsgi [pid: 1|app: -|req: -/-] 10.63.81.45 (-) {30 vars in 378 bytes} [Mon Apr 8 18:50:06 2024] GET /login?next=/ => generated 12976 bytes in 27 msecs (HTTP/1.1 404) 7 headers in 230 bytes (1 switches on core 0)
uwsgi [08/Apr/2024 18:50:06] WARNING [django.request:241] Not Found: /login
uwsgi [pid: 19|app: -|req: -/-] 10.63.81.45 (-) {34 vars in 390 bytes} [Mon Apr 8 18:50:06 2024] GET /uwsgi_health => generated 12976 bytes in 39 msecs (HTTP/1.1 404) 7 headers in 230 bytes (1 switches on core 1)
uwsgi [08/Apr/2024 18:50:16] WARNING [django.request:241] Not Found: /login
uwsgi [pid: 19|app: -|req: -/-] 10.63.81.45 (-) {34 vars in 390 bytes} [Mon Apr 8 18:50:16 2024] GET /uwsgi_health => generated 12976 bytes in 18 msecs (HTTP/1.1 404) 7 headers in 230 bytes (1 switches on core 0)
uwsgi [08/Apr/2024 18:50:16] WARNING [django.request:241] Not Found: /login
uwsgi [pid: 1|app: -|req: -/-] 10.63.81.45 (-) {30 vars in 378 bytes} [Mon Apr 8 18:50:16 2024] GET /login?next=/ => generated 12976 bytes in 45 msecs (HTTP/1.1 404) 7 headers in 230 bytes (1 switches on core 1)
...

[ashutoshuy]

Having Similar issues,
I am using it in Docker Container, by cloning it and running ./dc-up.sh

While starting the process it is working fine, didn't get any Error or warning except:

• WARN[0000] /home/healthcheck/django-DefectDojo/docker-compose.yml: version is obsolete

after that when i am requesting web, getting a similar error :

nginx-1         | 10.10.10.10 - - [09/Apr/2024:03:51:39 +0000] "GET / HTTP/1.1" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0" "-"
uwsgi-1         | [pid: 31|app: -|req: -/-] 10.10.10.10 (-) {42 vars in 697 bytes} [Tue Apr  9 03:51:39 2024] GET / => generated 0 bytes in 15 msecs (HTTP/1.1 302) 8 headers in 247 bytes (1 switches on core 0)
uwsgi-1         | [09/Apr/2024 03:51:41] WARNING [django.request:241] Not Found: /login
uwsgi-1         | [pid: 31|app: -|req: -/-] 10.10.10.10 (-) {42 vars in 720 bytes} [Tue Apr  9 03:51:39 2024] GET /login?next=/ => generated 12922 bytes in 1566 msecs (HTTP/1.1 404) 7 headers in 230 bytes (1 switches on core 1)
nginx-1         | 10.10.10.10 - - [09/Apr/2024:03:51:41 +0000] "GET /login?next=/ HTTP/1.1" 404 3276 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0" "-"

This Issue started arising from the last few days, Last time I checked on 04th April 2024, this was working fine

[mtesauro]

About:

WARN[0000] /home/healthcheck/django-DefectDojo/docker-compose.yml: version is obsolete

you can just delete the line that has version: on it - recent version of docker no longer require compose files to have a version.

We're leaving that in place for now for people that don't have the latest docker installed. It's harmless warning and does not have a connection to the subject of this thread (Not Found: /login)

[devcoisa]

Anyone,
Some lights that could help to pinpoint this problem we're still experiencing ?

[devcoisa]

We were able to find why the service was breaking during the startup.
By something reason the URL prefix was filled up with the FQDN with the web landing page. Liveness/Readiness probes were failed during the startup of service.
Can you tell us for which particular conditions the "URL prefix" should be used ?