Project

General

Profile

Actions

Bug #10430

closed

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

Added by Alexis Mousset over 7 years ago. Updated over 7 years ago.

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

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 3 (0 open3 closed)

Related to Rudder - Bug #10505: During a migration from 4.0 to 4.1, ldap base was emptiedRejectedActions
Related to Rudder - Bug #10567: Infinite "rudder is loading" page if rudder-init didn't runReleasedNicolas CHARLESActions
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 displayedReleasedNicolas CHARLESActions
Actions #1

Updated by Alexis Mousset over 7 years ago

  • Description updated (diff)
Actions #2

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

Actions #3

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
Actions #4

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.

Actions #5

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
Actions #6

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.

Actions #7

Updated by François ARMAND over 7 years ago

  • Description updated (diff)
Actions #8

Updated by Benoît PECCATTE over 7 years ago

  • Priority set to 78
Actions #9

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.

Actions #10

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
Actions #11

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
Actions #12

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 4.1.1 to 4.1.2
Actions #13

Updated by Jonathan CLARKE over 7 years ago

  • Assignee deleted (Alexis Mousset)
Actions #14

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.

Actions #15

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)
Actions #16

Updated by François ARMAND over 7 years 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)

Actions #17

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)
Actions #18

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
Actions

Also available in: Atom PDF