General Discussion

 View Only
  • 1.  BI Server / 9.3 Compile from Source / Can't Schedule or 'Run in Background'

    Posted 12-13-2021 10:50
    Afternoon folks,
    I'm stuck and hoping someone might shed light on this.

    Fedora 35 Server trying to run Pentaho BI Server compiled from the 9.3 git repo with latest versions of Maven and JDK8u312b07.  Postgres backend (also running on Fedora Server but is hosted on a different physical box).

    BI Server compiles fine and I can start it, connect without issue via the web interface, add users; import repository.  My Pentaho DI client (also compiled from source; but on Windows) can connect to the repository - no issues, save, load, versioning - no issues.  Everything looking wonderful.

    However, every time I try to 'Run in background' or 'Schedule a file' via the web-interface I get "You do not have permission to schedule this file. Contact your administrator for assistance.".  Even if I start with fresh databases of jackrabbit/hibernate & quartz, start DI - create a short transform as admin and then go to the web-server - login as admin and then try to run that transform - I get the same error!  ARGH!

    I can't find a single line in a log-file to indicate what the problem is despite setting the Catalina logging.properties to 'FINER' on all the configs that are enabled by default.  I've tracked the line of code down to:
    protected void checkSchedulePermissionAndDialog() in
    ../../../..mantle\client\commands\RunInBackgroundCommand.java

    ...but as I'm not a Java programmer that doesn't help me much.  :)

    I've tried everything I can think of.  I've rebuilt the tables; checked and rechecked the configs and the fact that my 9.1 server (separate hardware, same Postgres database backend but pointing at different tables) works just fine (with the exception being the 9.1 server experiences the Quartz bug where it runs ten times and then stops) is leading me to believe this is a bug and not a misconfigure.

    Adding insult to injury is the fact that the git compile of 9.3 Server I did for a Windows environment with an MS SQL Server database backend works just fine!!!!!  *open sobbing*

    Any help / guidance / suggestions / pity much appreciated...  Thanks!

    ------------------------------
    Leighton Jones
    ------------------------------


  • 2.  RE: BI Server / 9.3 Compile from Source / Can't Schedule or 'Run in Background'

    Posted 12-14-2021 08:54
    Can you confirm the administrator role has the Schedule Content Permissions?

    ------------------------------
    Carlos Lopez
    Hitachi Vantara
    ------------------------------



  • 3.  RE: BI Server / 9.3 Compile from Source / Can't Schedule or 'Run in Background'

    Posted 12-14-2021 10:39
    Good morning Carlos,
    Thank you for writing back :)

    Yes, the Administrator account has 'schedule content' permissions.  In the case of the simple test transform I wrote I logged in to the repository as 'Admin', made a couple of steps and then saved it.  I then logged in to the server as 'Admin', confirmed that the admin account has schedule permissions and that the simple transform had the 'can be scheduled' flag set.  The 'Admin' account in this context (for testing/diagnostic) is straight out of the box without even changing the default password.  I haven't fiddled with any of the default permissions either and the config is set up as per the 'Archive' install instructions using the default internal security mechanism (no LDAP etc).  The test transform runs just fine when triggered manually via 'Open...' on the server, but refuses to be ran via 'Run in background...' or 'Schedule...'

    To clarify; I have a VMWare host that has two independent Pentaho Server VMs - one running 9.1; the other 9.3 - both have separate IP's and I've not changed the default port.  Both use Fedora Server as an OS.  I think 9.1 is Fedora 31 upgraded to Fedora 35 and 9.3 is clean Fedora 35 install.  9.1 is using the public build from a year or two ago, whereas 9.3 is using my own build as of Saturday.  The aim was to get 9.3 up and running, migrate the repository from 9.1 to 9.3; then retire 9.1.  I have a single Postgres VM that currently has databases of hibernate/quartz/jackrabbit that the 9.1 install uses and hibernate93/quartz93/jackrabbit93 for the 9.3 install.  I get no errors when 9.3 starts that it can't access the databases and aside from changing the passwords the database user(s) stated in the Pentaho config scripts can login via pgAdmin without issue.

    My 9.3 build compiled cleanly and I went to extensive lengths to make sure that Maven used Java 8; so far as rebuilding the entire Fedora install and manually installing Java 8 from a download rather than relying on the Fedora repositories.  The same goes for Maven; I downloaded the binary from Apache rather than using the Fedora repos which install Java 11 - which I originally thought was the source of my problem.  As such; I know that Maven can only run using Java 8 as well as only compile using Java 8 as Java and Maven are essentially now 'stand alone' installs outside of the Fedora repositories and Fedora doesn't put any version of Java on by default.

    Other things I have tried:
    • Copy the hibernate/quartz/jackrabbit/Tomcat context.xml config files from my functional 9.1 install to my 9.3 install but modify the context.xml to point to the hibernate93/quartz93/jackrabbit93 databases
    • Copy the hibernate/quartz/jackrabbit/tomcat context.xml config files from my functional 9.1 install to my 9.3 install but not modify the database pointers so that my 9.3 uses the same back-end databases as my functional 9.1 install.
    • Deliberately misconfiguring context.xml so it points at non-existent databases 'just to check' that the Pentaho Server is at least trying to access the correct databases (and yes, it was - errors were created as expected)
    • Turning on/off SE Linux; a common source of irritation when things don't seem to be working properly and/or produce 'odd' results
    Two things I've not tried are:
    • restart the Postgres database with full logging enables so that I can trap the SQL that's being executed and then see if that gives me any clues as to what the problem is
    • download the latest publically available server build - and see if that works

    I'm not ruling out that I've missed something really really obvious - but I can't think what!  Like I said, I've got a 9.3 built-from-source on Windows working just fine and I can't see for the life of me where I might have missed a step!

    Thank you for your help  :)

    ------------------------------
    Leighton Jones
    Data Service Manager
    Paramount Resources Ltd
    ------------------------------