CoreProtect-Lookup-Web-Interface icon indicating copy to clipboard operation
CoreProtect-Lookup-Web-Interface copied to clipboard

CoreProtect v21 compatibility?

Open argon000s opened this issue 3 years ago • 2 comments

I am unable to perform lookups on the database with the latest CoreProtect plugin (v21.1) CoreProtect added new features to v21, so I think this may of broke something.

I get "Unknown error occured." and this json response while performing any lookups: [{"time":1647562270.447199,"flags":5,"status":-1,"duration":0.06136584281921387}]

Could it be a sqlite3 error? The server is Apache on Debian linux. I have multiple Minecraft servers with CoreProtect. I am still able to perform lookup on one server I am hosting, the others do not work.

What is strange is I copied the the database.db that did not work on linux to my windows PC under IIS and the lookup works, so I am very puzzled as to why this no longer works on my linux machine.

Some extra logging options would be helpful for me to diagnose this problem.

argon000s avatar Mar 18 '22 00:03 argon000s

Upon further checking it seems to be a permission issue with apache - I needed to chmod the file path recursively so it could read the database file. It still puzzles me as to why it stopped working as it was working before - perhaps a recent update to the sqlite drivers in Debian or a configuration change caused this.

Perhaps you could include instructions in the readme to set permissions recursively which may help some people with similar issues. Thanks for this great project, I use it regularly to view activity on my servers.

argon000s avatar Mar 18 '22 17:03 argon000s

Ok I think i figured it out. The CoreProtect sqlite database prior to v21 has Journal mode set to none/delete but the latest version uses WAL for the journal. This means when lookup.php tries to access the database it tries to create a database.db-wal file in the same directory - hence the web server not having write permissions to that directory, throws an error.

Adding a read-only flag to the PDO database handler may fix this issue. In fact it would be best practice to enable read-only on sql database connections to prevent issues.

Edit: I tried this, still didn't work.

argon000s avatar Mar 19 '22 15:03 argon000s