Imunify AV web gui on subfolder fails

[razor7]

Hi! I have installed Imunify AV on my Ubutnu 22.04 box withg PHP 8.2. I'm using ISPConfig as the web server control panel, so I pointed the web_ui path to /XXX/YYY/ZZZ//web/iav, being the virtual web server path /XXX/YYY/ZZZ//web

The Imunify AV web interface was working just fine in https://av.mydomain.com/iav/ but now, It only displays a blank paqe and no login form.

[alevchenko]

Hi,
What changes took place to the server before the UI becomes blank? And what /var/log/imunify360/error.log says? What are the permissions and ownership for the ui_path /XXX/YYY/ZZZ//web/iav and its parent?
I'd recommend checking all the points at https://cloudlinux.zendesk.com/hc/en...fy-stand-alone

[Maxim0k0]

I confirm
Describe the bug
After the last update of ImunifyAV, the login page stopped opening. Only white page.
I tried to install from scratch, on a clean server, the same thing.
The problem is also described in the link. https://github.com/usmannasir/cyberpanel/issues/1078
Before the update, ImunifyAV worked great. Also, I installed it by script on many VPS and dedicated servers.

To Reproduc
Install ImunifyAV
Prescription settings for nginx
A blank page opens

Operating system:
Ubuntu 22

HestiaCP version 1.7.7 and VestaCP

[alevchenko]

Hi Maxim,
Have you also checked all the points at https://cloudlinux.zendesk.com/hc/en...fy-stand-alone that may be the cause of the blank page?
In my practice, this troubleshooting guide helped with every blank page issue on stand-alone reported as all the nuances are described there

[Maxim0k0]

Of course, I checked everything on the specified link, but not a single item solved the problem.

[mchernyavsky]

Hello Maxim,

Some users have reported that a recent update by Imunify (version 7.1.3) has caused the User Interface (UI) to break in generic panels. This issue is resulting in the improper loading of scripts like index.js and config.js from incorrect URLs.

This problem is due to an base href declaration that affects how scripts are loaded. Affected servers are those with generic panels hosting UI in a subfolder.

The fix for UI-generic base href to allow put UI in folder is anticipated as DEF-24476 in 7.2.1. As a workaround the base href can be changed manually:
Please check you WEB_UI path, on Webuzo panels it can be for example as per:

grep ui_path /etc/sysconfig/imunify360/integration.conf
ui_path = /usr/local/webuzo/web/admin/imunify360

Make sure to change directory and apply changes:

cd /usr/local/webuzo/web/admin/imunify360
sed -i.bak '/.*<base href="\/">.*/d' index.php

If it is the case, this should resolve the issue.

[Maxim0k0]

Hello Maxim,

Some users have reported that a recent update by Imunify (version 7.1.3) has caused the User Interface (UI) to break in generic panels. This issue is resulting in the improper loading of scripts like index.js and config.js from incorrect URLs.

This problem is due to an base href declaration that affects how scripts are loaded. Affected servers are those with generic panels hosting UI in a subfolder.

The fix for UI-generic base href to allow put UI in folder is anticipated as DEF-24476 in 7.2.1. As a workaround the base href can be changed manually:
Please check you WEB_UI path, on Webuzo panels it can be for example as per:

grep ui_path /etc/sysconfig/imunify360/integration.conf
ui_path = /usr/local/webuzo/web/admin/imunify360

Make sure to change directory and apply changes:

cd /usr/local/webuzo/web/admin/imunify360
sed -i.bak '/.*<base href="\/">.*/d' index.php

If it is the case, this should resolve the issue.

I did, but it didn't help.
Write, please, on which line what to change. I'll try to write by hand.

[mchernyavsky]

I did, but it didn't help.

This issue with absent js files is typical for the problematic base href, especially if occured after the update. I have only used sed to fix the directives and it worked previously. If you have used sed on the correct index.php file the issue might \be in something else. For example, can you please make sure that the actual files in /assets/ do exist?

Also I wanted to let you know that the above issue is now solved with the latest release patches:

wget -O imunify-force-update.sh https://repo.imunify360.cloudlinux.com/defence360/imunify-force-update.sh
bash imunify-force-update.sh

Please check files existence and try updating if sed substitution was already applied.