Upgrade about dockerfiles HOT 32 CLOSED

this seems pretty clear
Invoiceninja can't reach your database

from dockerfiles.

@hillelcoren did you change the update process since 3.9.2 ?

from dockerfiles.

Not that I'm aware of. With v4 we updated to Laravel 5.3, maybe it had an impact?

from dockerfiles.

Sorry. I also tried the new 4.1 version - same result. Additionally, I modified the docker-compose.yml and .env files to the "new/modified" format and still got the same result.

Sorry for the even more ignorant question but can I do anything with regards to this Laravel 5.3? Is there anything I need to upgrade?

from dockerfiles.

@lalop Are you seeing the same problem?

from dockerfiles.

@hillelcoren I can't reproduce it

@Mzngit what do you see in your docker logs and in storage/logs/ ?

from dockerfiles.

Hi,

I started from scratch and installed invoiceninja docker file, mysql, and nginx without a problem.
I tried to log in, and ran into the same expected problem.
The storage/logs subdirectory is empty, but does exist.
The docker container logs are attached.
The srv subdirectory, and all recursive subdirectories were given full permissions (i.e. chmod -R 777 srv)

Thanks again.

invoice_app_log.xlsx
invoice_db_log.xlsx
invoice_web_log.xlsx
@

from dockerfiles.

@Mzngit I'm not sure but I think that you should at least have files into storage/logs
Can you check that php can write in it ?

from dockerfiles.

I know that the permissions on the folder is 777. Sorry for my ignorance, but how do I check if php can write in it?

from dockerfiles.

If the folder is in 777 anyone can write in it, all the subfolder and files are in 777 too ?
Maybe you can start invoiceninja in debug mode, see .env for that

from dockerfiles.

So all the subfolders are 777. At your suggestion, I put invoiceninja into debug mode, and the storage/logs file comes up with attached file. First file is output on web browser. Second is stacktrace.log.
Log.txt
stacktrace.log

Essentially, the 3 errors I get are:

PDOException in PDOConnection.php line 43:
SQLSTATE[HY000] [1130] Host '172.18.0.2' is not allowed to connect to this MySQL server

PDOException in PDOConnection.php line 47:
SQLSTATE[HY000] [1130] Host '172.18.0.2' is not allowed to connect to this MySQL server

QueryException in Connection.php line 770:
SQLSTATE[HY000] [1130] Host '172.18.0.2' is not allowed to connect to this MySQL server (SQL: select count(*) as aggregate from users where users.deleted_at is null)

My .env file has the following line in it:
TRUSTED_PROXIES='10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,0.0.0.0,192.168.0.100,172.19.0.1,172.18.0.1,172.0.0.1'

Of course adding 172.18.0.02 to above line and restarting container does nothing.
Removing the entire TRUSTED_PROXIES variable gets me the same errors as above, only its Host '172.18.0.4"

from dockerfiles.

Anyone out there know what any of the above means?
Thanks again.

from dockerfiles.

Any ideas what I can try to play with to get it to reach the database?

from dockerfiles.

@Mzngit Unfortunately, this depends a lot on how you've got your MySQL database and computer set up. Are you using the recommended example docker-compose.yml file from this repo? I used it and it worked first time for me. I use Docker on Linux.

from dockerfiles.

Yes, using the recommended docker-compose.yml file

from dockerfiles.

I just don't understand why even if I move the existing (and working) mysql folder to another location, delete the version 3.9.2 containers, and reinstall the same invoiceninja 3.9.2, mysql, and nginx containers from scratch, it comes up fine. What changed with v4. 0 and higher? That's what I can't seem to get working. Any manual way to link invoiceninja to the mysql database? Any other tweaks or tests to do? Is it potentially a network bridge issue?
Any help would be greatly appreciated.

from dockerfiles.

The issue seems to come more from your docker usage then from invoiceninja

from dockerfiles.

Any explanation then why the identical docker-compose, .env, and nginx.conf files work consistently for v3.9.2 but not 4.0?

from dockerfiles.

I can't reproduce your issue so I can't say

from dockerfiles.

Which version of PHP are you using, v4 now requires PHP 7

from dockerfiles.

https://github.com/invoiceninja/dockerfiles/blob/4.0.0/Dockerfile#L1

We are based on php7

from dockerfiles.

I have PHP5.6 and 7.0 running on server. I shut off v5. 6 in case it was interfering. No luck.
As soon as I change the compose.yml file to invoiceninja:3.9.2, it works fine.
Frustrating.

from dockerfiles.

So I was finally able to install v4.1.3 and it ran but only using http, not https. My original setup (using v3.9) uses a reverse proxy to go from external https port (e.g. 8001) to http-localhost-8000, and thus invoiceninja works only using https. Using the new v4.1.3, if I delete the reverse proxy, and if I entered http://www.mydomain.com:8000, then it runs perfectly. If I activate the reverse proxy and I enter: https://www.mydomain.com:8001, then it doesn't work. All router ports are opened appropriately.
I tried entering the following into the nginx.conf file:
fastcgi_param HTTPS 1;
Does not work.

I also tried entering the following into .env file:
REQUIRE_HTTPS=true
SESSION_ENCRYPT=true
SESSION_SECURE=true
Still nothing.

Any ideas how to force all connections to go via https, and not http?

from dockerfiles.

@Mzngit You can use NGINX to force HTTPS connections. See the top answer here: https://serverfault.com/questions/250476/how-to-force-or-redirect-to-ssl-in-nginx

If you're using a reverse proxy, an advantage is that you don't even have to worry about tweaking things like HTTPS over HTTP in the things you wrap. You can just learn how to use NGINX for it, and then apply that same pattern to anything you wrap in the future.

Here's the nginx.conf I use: https://gist.github.com/welkie/e89ac6cc8a108e0ec26bb99d9723cc13

Note the section where I configure the SSL certs, keeping them stored on a directory from my root directory on the server. You could use that as a base and just add the part from the StackExchange page to force HTTPS.

Another layer where you can enforce HTTPS only is a CDN. I wrap my blog in Cloudflare (I use their free service). Note how they have an HTTPS only setting: https://imgur.com/a/e1puw

It causes a 301 response to be sent which redirects them to the HTTPS version of the URL they tried going to. Cloudflare has a caching setting that respects the the Cache-Control headers sent by your origin server, so this works seamlessly with whatever you wrap with it and doesn't cause weird unintended caching.

from dockerfiles.

Thanks so much for detailed response. Unfortunately, the first suggestion of including an additional line in the nginx.conf file ("rewrite ^ https://$server_name$request_uri? permanent;") doesn't work, even if I shut off the reverse proxy and use the direct port. In fact, neither http nor https work. If I remove that line and rebuild the container, then at least http works via direct port.
As I mentioned above, I had someone (who is no longer reachable) set this up initially with version 3.9 via reverse proxy and it works fine forcing the connection via https. In fact, as soon as I use the new 4.1.5 version it no longer works via reverse proxy, but does work via direct port using http only. If I use the identical docker-compose.yml (except use invoiceninja/invoiceninja:3.9.2), .env, and nginx.conf files, then the reverse proxy, etc. works perfectly again.
Can't figure this out.

from dockerfiles.

Maybe this will help...

http://docs.invoiceninja.com/en/latest/configure.html#using-a-proxy

from dockerfiles.

Thanks for the help. As I mentioned above though, I have the following in my .env file placed there during initial setup:
My .env file has the following line in it:
TRUSTED_PROXIES='10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,0.0.0.0,192.168.0.100,172.19.0.1,172.18.0.1,172.0.0.1'
Problem still there.

from dockerfiles.

So I did more digging and documentation.
HTTP connections work fine via port 8000. HTTPS do not. The first kind suggestion by @Welkie of adding a rewrite statement to the nginx.conf file works by forcing http://www.mydomain.com:8000 to https://mydomain.com:8000, but the page still doesn't load, and its as if I entered https://www.mydomain.com:8000 from the get go. By the way, putting REQUIRE HTTPS into the .env file results in the identical behaviour without the nginx.conf modification.
Please see attached images
When the page loads successfully via http, the invoiceninja log gives me:

172.19.0.4 - 21/Feb/2018:19:26:18 +0000 "GET /index.php" 200

When trying to unsuccessfully load from https, I get:

[21-Feb-2018 19:26:18] WARNING: [pool www] child 11 said into stderr: "[2018-02-21 19:26:18] production.ERROR: Doctrine\DBAL\Driver\PDOException [1130] : /var/www/app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php [Line 47] => SQLSTATE[HY000] [1130] Host '172.19.0.3' is not allowed to connect to this MySQL server {"context":"PHP","user_id":0,"account_id":0,"user_name":"","method":"GET","url":"http://www.mydomain.com:8000/setup","previous":"http://www.mydomain.com:8000/setup","user_agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko","ip":"172.19.0.1","count":8,"is_console":"no","is_api":"no","db_server":"mysql"} []"

Also, the nginx logs are attached as an image. The last 4 lines are when I try https, while the first 12 lines are when I successfully load the page via http.

I've also included screenshots of Internet Exlporer and Chrome, if that is helpful to anyone who can offer a suggestion.

I just can't figure out a way to have the page load via https.

Successful load using IE

Unsuccessful load on IE

Unsuccessful load on Chrome

NGINX log

from dockerfiles.

Maybe this will help... #67 (comment)

from dockerfiles.

Shouldn't the system's built-in reverse proxy (https via port 8001 mapped to http port 8000) automatically do all of this? It certainly does it when using invoiceninja v3.9.2.

from dockerfiles.

Tried latest 4.3.1
Still no progress unfortunately.
The Invoice ninja docker log is attached.

I get the following error page when I load the invoice ninja webpage:

Anyone smarter than me have any idea here?
invninja_app_1.xlsx

Whoops, looks like something went wrong.

(1/1) InvalidArgumentExceptionPlease provide a valid cache path.

in Compiler.php (line 36)
at Compiler->__construct(object(Files

ystem), false)in ViewServiceProvider.php (line 128)
at ViewServiceProvider->Illuminate\View{closure}(object(Application), array())in Container.php (line 726)
at Container->build(object(Closure))in Container.php (line 608)
at Container->resolve('blade.compiler')in Container.php (line 575)
at Container->make('blade.compiler')in Application.php (line 728)
at Application->make('blade.compiler')in Container.php (line 1172)
at Container->offsetGet('blade.compiler')in ViewServiceProvider.php (line 133)
at ViewServiceProvider->Illuminate\View{closure}()
at call_user_func(object(Closure))in EngineResolver.php (line 54)
at EngineResolver->resolve('blade')in Factory.php (line 263)
at Factory->getEngineFromPath('/var/www/app/resources/views/setup.blade.php')in Factory.php (line 227)
at Factory->viewInstance('setup', '/var/www/app/resources/views/setup.blade.php', array())in Factory.php (line 136)
at Factory->make('setup')in Facade.php (line 221)
at Facade::__callStatic('make', array('setup'))in AppController.php (line 47)
at AppController->showSetup()
at call_user_func_array(array(object(AppController), 'showSetup'), array())in Controller.php (line 55)
at Controller->callAction('showSetup', array())in ControllerDispatcher.php (line 44)
at ControllerDispatcher->dispatch(object(Route), object(AppController), 'showSetup')in Route.php (line 203)
at Route->runController()in Route.php (line 160)
at Route->run()in Router.php (line 572)
at Router->Illuminate\Routing{closure}(object(Request))in Pipeline.php (line 30)
at Pipeline->Illuminate\Routing{closure}(object(Request))in StartupCheck.php (line 55)
at StartupCheck->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in QueryLogging.php (line 32)
at QueryLogging->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in DuplicateSubmissionCheck.php (line 41)
at DuplicateSubmissionCheck->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in TransformsRequest.php (line 30)
at TransformsRequest->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in VerifyCsrfToken.php (line 65)
at VerifyCsrfToken->handle(object(Request), object(Closure))in VerifyCsrfToken.php (line 44)
at VerifyCsrfToken->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in ShareErrorsFromSession.php (line 49)
at ShareErrorsFromSession->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in StartSession.php (line 64)
at StartSession->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in AddQueuedCookiesToResponse.php (line 37)
at AddQueuedCookiesToResponse->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in EncryptCookies.php (line 59)
at EncryptCookies->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in Pipeline.php (line 102)
at Pipeline->then(object(Closure))in Router.php (line 574)
at Router->runRouteWithinStack(object(Route), object(Request))in Router.php (line 533)
at Router->dispatchToRoute(object(Request))in Router.php (line 511)
at Router->dispatch(object(Request))in Kernel.php (line 176)
at Kernel->Illuminate\Foundation\Http{closure}(object(Request))in Pipeline.php (line 30)
at Pipeline->Illuminate\Routing{closure}(object(Request))in Debugbar.php (line 51)
at Debugbar->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in CheckForMaintenanceMode.php (line 46)
at CheckForMaintenanceMode->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in HandlePreflight.php (line 46)
at HandlePreflight->handle(object(Request), object(Closure))in Pipeline.php (line 148)
at Pipeline->Illuminate\Pipeline{closure}(object(Request))in Pipeline.php (line 53)
at Pipeline->Illuminate\Routing{closure}(object(Request))in Pipeline.php (line 102)
at Pipeline->then(object(Closure))in Kernel.php (line 151)
at Kernel->sendRequestThroughRouter(object(Request))in Kernel.php (line 116)
at Kernel->handle(object(Request))in index.php (line 51)

from dockerfiles.

It appears that once the mysql version was downgraded to 5 in the recently - updated .yml file, it seems to be working fine. Please close this issue.

from dockerfiles.