Bug #10430
closed
Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server)
Description
Symptoms¶
root@server:~# rpm -qa | grep rudder-webapp rudder-webapp-4.1.0.rc2.git201703150133-1.SLES.11.noarch
I get, in the console:
[Report Only] Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'unsafe-eval' 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-1BNJtQAi+u7koWiPaZnmB/XP12FM6dRgu7gQTBzadBM='), or a nonce ('nonce-...') is required to enable inline execution.
index.html:92 Uncaught ReferenceError: $ is not defined
at index.html:92
lift.js:1 Uncaught ReferenceError: jQuery is not defined
at lift.js:1
at lift.js:1
lift.js:1 onDocumentReady function must be defined in settings
consoleOrAlert @ lift.js:1
https://localhost:8381/favicon.ico Failed to load resource: the server responded with a status of 403 (Forbidden)
These is not attempt to load css or js files, except lift.js and socialwidgets.css.
Cause and related information¶
For record, and because it may happens commonly: now, CSS/JS/font are served by Rudder web-app directly, not the jetty server under it. So if the Rudder web-app doesn't starts correctly, then we don't have any CSS/JS. The cause of the bad start is most likelly a problem with the LDAP server (see for ex #10505) or a problem with the Postgres base.
In each case, the logs in `/var/log/rudder/webapp/YYYY_MM_DD.sderrout.log` will contain relevant information about whas went wrong.
Updated by
Updated by François ARMAND almost 8 years ago
- Status changed from New to Rejected
- User visibility changed from First impressions of Rudder to Getting started - demo | first install | level 1 Techniques
We are not able to reproduce it, so I'm closing it (ouf)
Updated by François ARMAND over 7 years ago
- Related to Bug #10505: During a migration from 4.0 to 4.1, ldap base was emptied added
Updated by François ARMAND over 7 years ago
For record, and because it may happens commonly: now, CSS/JS/font are served by Rudder web-app directly, not the jetty server under it. So if the Rudder web-app doesn't starts correctly, then we don't have any CSS/JS. The cause of the bad start is most likelly a problem with the LDAP server (see for ex #10505) or a problem with the Postgres base.
In each case, the logs in `/var/log/rudder/webapp/YYYY_MM_DD.sderrout.log` will contain relevant information about whas went wrong.
Updated by François ARMAND over 7 years ago
- Subject changed from No css nor js on SLES 11 to No css nor js on Rudder 4.1
Updated by François ARMAND over 7 years ago
- Description updated (diff)
Adding the last comment in the ticket description to help people find the relevant information quicker.
Updated by
Updated by François ARMAND over 7 years ago
- Status changed from Rejected to New
- Target version changed from 4.1.0 to 4.1.1
- Severity changed from Critical - prevents main use of Rudder | no workaround | data loss | security to Major - prevents use of part of Rudder | no simple workaround
- Priority changed from 78 to 0
I'm opening it again, because it is EXTREMELLY misleading to have. We should head to the page explaining that there is a problem, not a broken Rudder page.
I'm also changing the severity, because it is only a symptom of an other problem during the webapp init, so the missing css/js is not critical per se. But I'm letting it to "major", because Rudder seems very broken, and it is more than misleading.
Updated by François ARMAND over 7 years ago
- Related to Bug #1974: If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayed added
Updated by François ARMAND over 7 years ago
- Related to Bug #10567: Infinite "rudder is loading" page if rudder-init didn't run added
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 4.1.1 to 4.1.2
Updated by Jonathan CLARKE over 7 years ago
- Severity changed from Major - prevents use of part of Rudder | no simple workaround to Critical - prevents main use of Rudder | no workaround | data loss | security
- Priority changed from 0 to 78
This should probably cause the rudder web interface to return a 5xx error so that the Apache proxy front can display an appropriate error message. If the resources are not available, there's no point trying to display the page contents.
A lot of users have seen this recently while trying out Rudder and were completly stuck as to how to proceed. There does exist a simple workaround (usually), but it is not easily available, therefore bumping this to Critical - a new user just can't proceed with using Rudder when this bug occurs. Adding an error page that explains what to check, or which docs to read, would enable us to reduce this severity.
Updated by Jonathan CLARKE over 7 years ago
- Subject changed from No css nor js on Rudder 4.1 to Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server)
Updated by François ARMAND over 7 years ago
- Status changed from New to Rejected
Updated by François ARMAND over 7 years ago
- Related to deleted (Bug #1974: If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayed)
Updated by François ARMAND over 7 years ago
- Is duplicate of Bug #1974: If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayed added