Cannot connect to web interface are upgrade from 6.4.0 to 6.4.0.1, main.js error in log

Community Support
1

Please, describe the problem here and provide additional information below (if applicable):

After upgrade from upgrade from 6.4.0 to 6.4.0.1 I am not able to connect to the web interface. I see this in the /var/log/httpd/error.log:

AH00037: Symbolic link not allowed or link target not accessible: /usr/lib/one/sunstone/public/dist/main.js, referer: http://x.x.x.x

I checked and file and link exist. Probably permission issues but I’m not sure the right assignments.

2616:fireedge/sunstone and provision are working fine.

Versions of the related components and OS (frontend, hypervisors, VMs):
This is runing on AlmaLinux release 8.6 (Sky Tiger).

Steps to reproduce:
Upgrade from 6.4.0 to 6.4.0.1

Current results:
web interface on port 80 not available

Expected results:
access to port 80 web interface

2

Most likely, the filesystem permissions got reset after the upgrade. Check the required permissions in this section.

3

Indeed, that was it!
Thanks for the info!

4

oh, wait. It logs oneadmin in but then immediately logs me out. Weird.

5

…and a little patience and it resolved! :wink:
All good now.

1 Like
6

And sadly it is not working again. When I login, it shows dashboard then logs out.

The http service show this status:

● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/httpd.service.d
└─override.conf
Active: active (running) since Tue 2024-08-06 14:12:16 UTC; 2s ago
Docs: man:httpd.service(8)
Main PID: 15107 (httpd)
Status: “Started, listening on: port 443, port 80”
Tasks: 235 (limit: 102213)
Memory: 55.2M
CGroup: /system.slice/httpd.service
├─15107 /usr/sbin/httpd -DFOREGROUND
├─15136 /usr/sbin/httpd -DFOREGROUND
├─15138 Passenger watchdog
├─15141 Passenger core
├─15153 /usr/sbin/httpd -DFOREGROUND
├─15154 /usr/sbin/httpd -DFOREGROUND
└─15155 /usr/sbin/httpd -DFOREGROUND

Aug 06 14:12:16 onenebula02.dev.cyber7-lab.com systemd[1]: Starting The Apache HTTP Server…
Aug 06 14:12:16 onenebula02.dev.cyber7-lab.com httpd[15107]: WARNING: PassengerSpawnDir cannot occur within section
Aug 06 14:12:16 onenebula02.dev.cyber7-lab.com systemd[1]: Started The Apache HTTP Server.
Aug 06 14:12:16 onenebula02.dev.cyber7-lab.com httpd[15107]: Server configured, listening on: port 443, port 80
Aug 06 14:12:16 onenebula02.dev.cyber7-lab.com systemd-coredump[15387]: Process 15384 (PassengerAgent) of user 0 dumped core.
Aug 06 14:12:17 onenebula02.dev.cyber7-lab.com systemd-coredump[15410]: Process 15112 (PassengerAgent) of user 0 dumped core.

Some reason PassengerAgent is dumping on start up. Restart, Stopped and Started wth same result. Also rebooted.

Fireedge works fine.

7

Getting some 401 errors after login executes:

10.200.7.108 - - [06/Aug/2024:14:19:54 +0000] “POST /login HTTP/1.1” 204 - “https://10.200.18.21/login” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:56 +0000] “GET / HTTP/1.1” 200 6336 “https://10.200.18.21/login” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:56 +0000] “GET /dist/main.js?v=6.4.0.1 HTTP/1.1” 304 - “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:56 +0000] “GET /locale/languages/en_datatable.txt?csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 200 530 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:56 +0000] “GET /locale/languages/en_datatable.txt?csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 200 530 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:56 +0000] “GET /locale/languages/en_datatable.txt?csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 200 530 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:56 +0000] “GET /datastore?timeout=true&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 200 1719 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /support/check?csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /vm?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /user?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /host?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /group?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /user/0?id=0&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /image?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /vnet?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /cluster?timeout=false&pool_filter=-2&csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 401 35 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /login HTTP/1.1” 200 1269 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /login HTTP/1.1” 200 1269 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”
10.200.7.108 - - [06/Aug/2024:14:19:57 +0000] “GET /support/check/version?csrftoken=17f05d3fa866b1f6d0353da35094803063eabc6c8c9e36b0694c4bb5da361d25 HTTP/1.1” 200 54 “https://10.200.18.21/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0”

8

Could you look at coredump backtrace to see at what function the abort is happening?
Does the passenger get upgraded with the upgrade of the ONE packages?

Honestly, I have no idea about the exact reason, but it could be an issue with the passenger, so digging deeper about the reasons could help to understand what is going wrong. Also if there was a passenger upgrade - does downgrading the passenger lead to the same issue?

9

Thanks! I appreciate your support. I have been deploying an new 6.8 version and have been able to get all the features I want working properly (SSL, proper certs on Sunstone and Fireedge) so I’m going to move over to new instance. It appears that the upgrade failed on something, passenger possibly, so will just move on. Not a big deal from VMware, bigger deal for KVM but I’ll survive! :wink:

1 Like