Problem with update / open_basedir?

Self-Hosted | v5
1

I have been playing with v5.x off and on for about 2 weeks. Fantastic Thank you Hillel and co.!

I have it running on Ubuntu 20.04 / Nginx 1.19.8 / PHP 8.0.3 / MariaDB 10.5.9
[ With the exception of Ubuntu, I believe nothing could be more up to date as of today. ]

I originally installed from Invoice_ninja-v5.1.19.zip. The “in-page” updater brought me to version 5.1.27 some time ago. Over the weekend I noticed that 5.1.32 is available, but alas, the “in-page” updater no longer works! (it flashes: “Update successfully completed” but the info box shows the “old” version to still be in effect.

The info box / health check ALSO shows “open basedir – NOT enabled” (emphasis mine) . . . but that’s a “lie.”

PHPInfo i.e. a simple page with <?php phpinfo(); ?> running from the InvoiceNinja public folder shows that open_basedir is indeed set (from my nginx virtualhost conf file for this InvoiceNinja installation). I have it set to one folder “above” the InvoiceNinja “public” folder, thinking this is where the updater (and other InvoiceNinja functionality) must run . . .

Nginx has RW access to all folders in the InvoiceNinja path. Nginx/PHP/MariaDB are not acting up. Everything seems fine. But the update will not run and the app reports “open basedir – NOT enabled” pretty much whatever I do.

Ideas?

Can I manually update by just placing a new version (extracted from the zip file) into the InvoiceNinja folder as was possible in v4 and earlier?

Related? to the above question, VERSION.txt shows 5.1.32. Altering to something lower (like 5.1.27) does not “force” the app to upgrade.

In the public folder there is version.json which shows
{"app_name":"invoiceninja_flutter","version":"5.0.44","build_number":"44"}
That seems a bit odd, although 5.1.27 shows “C44” after it in the info-box

2

Hi,

Yes, it’s also possible to update by manually copying over the zip

The app version (ie, 5.1.27-C44) is showing the backend version (5.1.27) and the frontend version (5.0.44).

3

Hi Hillel:

Thanks for the explanation re: version numbers. I’ll try overwriting with the newest zip tomorrow morning.

Any idea on the issue with open_basedir reporting as “not enabled” when it is? Also is setting this to a directory about InvoiceNinja’s public folder the correct / reasonable thing to do?

Thanks in advance for any other ideas. I’ll report back with my manual update effort . . .

4

@david do you have any ideas?

5

try this from the root of the invoiceninja folder

php artisan tinker
strlen(ini_get('open_basedir'));

If the output is 0 then open_basedir is correctly configured.

6

@hillel
I performed a manual update by manually copying the zip and extracting it.

Unfortunately, I forgot to make a backup of .env (the new one now has different data and incorrect DB connection info, for starters!)

Surprisingly, the app still works (without running setup again), but I feel this may be due to some type of caching. Indeed the info-box still reports the version as 5.1.27

@david
I did as you suggested and it reports “0”

The InvoiceNinja info-box still reports that open basedir is “not enabled”

Perhaps InvoiceNinja is querying the php.ini file as opposed to the actual state of the variable? [ You guys seem so gifted, I doubt this! ]

Also, (and again) to what path should the open_basedir variable be set in a “common” InvoiceNinja installation? I have mine pointing a directory “above” the InvoiceNinja /public folder as much of the “plumbing” seems to be there!

Thanks for any further insights.

7

In reviewing the server requirements (all of which I have installed!)

I discovered:
curl.cainfo has “no value” for both the “local” and “master” values. I doubt this relates, but thought I should point it out.

Also, have you guys tested against PHP 8.0.x? Is this possibly too “bleeding edge”?

Thanks again.

8

@fbachofner

It sounds like the open_basedir issue is a false positive.

We would love to upgrade to PHP8, we are still waiting on one package we depend on to support PHP 8.

9

I have reinstalled InvoiceNinja on a server with “only” PHP 7.4

Now I have no more open_basedir false negative. @david , could this have been related to the package InvoiceNinja “depend(s) on to support PHP 8”?

On the other hand, a new “problem”:

The info-box now reports IN is using PhantomJS for PDF generation. I had already installed all the dependencies InvoiceNinja lists as well as chromium (on the server, right?!) so this is a bit of a surprise.

I also paid attention to the Debian/Ubuntu dependencies list at the snappdf developer’s Github account.

Any ideas on what I might be missing to avoid PhantomJS?

Thanks again!

10

@fbachofner

As long as your .env has

PHANTOMJS_PDF_GENERATION=false

you will be generating PDFs locally, also please make sure you are running php artisan optimize after updating your .env file.

Once this is done, you may need to refresh the data in the UI by going to Settings > Device Settings > Refresh data.

In regards to the open_basedir, this would have nothing to do with support for PHP8 nor any other packages.

11

AWESOME, thanks @david !

Back to normal (i.e. like on the previous box!)

I wonder how PHANTOMJS_PDF_GENERATION got set to true in the first place? I did have an error with the initial setup when I (impatiently) used a Windows XP box (! . . . yeah, I know) I happened to be sitting at.

But then I came back to finish the install from my preferred Linux machine. Did that initial setup failure likely cause my PDF generation “problem”? [ seems odd if so, since this all happens on the server, right? ]

12

Not sure as to the cause, the default for the app initially is Phantom=TRUE.