Project

General

Profile

Bug #10430

Broken pages served by Rudder 4.1 with no explanation (missing JS/CSS due to unavailable LDAP server)

Added by Alexis MOUSSET over 1 year ago. Updated over 1 year ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Web - UI & UX
Target version:
Target version (plugin):
Severity:
Critical - prevents main use of Rudder | no workaround | data loss | security
User visibility:
Getting started - demo | first install | level 1 Techniques
Effort required:
Pull Request:
Priority:
78

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.


Related issues

Related to Rudder - Bug #10505: During a migration from 4.0 to 4.1, ldap base was emptiedRejected
Related to Rudder - Bug #10567: Infinite "rudder is loading" page if rudder-init didn't runReleased
Is duplicate of Rudder - Bug #1974: If an error happen during boostrap, the webapp starts but is in a zombie state and the error page is not displayedReleased

History

#1 Updated by Alexis MOUSSET over 1 year ago

  • Description updated (diff)

#2 Updated by François ARMAND over 1 year 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)

#3 Updated by François ARMAND over 1 year ago

  • Related to Bug #10505: During a migration from 4.0 to 4.1, ldap base was emptied added

#4 Updated by François ARMAND over 1 year 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.

#5 Updated by François ARMAND over 1 year ago

  • Subject changed from No css nor js on SLES 11 to No css nor js on Rudder 4.1

#6 Updated by François ARMAND over 1 year ago

  • Description updated (diff)

Adding the last comment in the ticket description to help people find the relevant information quicker.

#7 Updated by François ARMAND over 1 year ago

  • Description updated (diff)

#8 Updated by Benoît PECCATTE over 1 year ago

  • Priority set to 78

#9 Updated by François ARMAND over 1 year 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.

#10 Updated by François ARMAND over 1 year 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

#11 Updated by François ARMAND over 1 year ago

  • Related to Bug #10567: Infinite "rudder is loading" page if rudder-init didn't run added

#12 Updated by Vincent MEMBRÉ over 1 year ago

  • Target version changed from 4.1.1 to 4.1.2

#13 Updated by Jonathan CLARKE over 1 year ago

  • Assignee deleted (Alexis MOUSSET)

#14 Updated by Jonathan CLARKE over 1 year 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.

#15 Updated by Jonathan CLARKE over 1 year 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)

#16 Updated by François ARMAND over 1 year ago

  • Status changed from New to Rejected

With the correction of #1974, this bug should not happen anymore. We still may have the problem linked to #10567 (ie: infinite loading page). I'm closing that one as duplicate (of #1974)

#17 Updated by François ARMAND over 1 year 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)

#18 Updated by François ARMAND over 1 year 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

Also available in: Atom PDF