I don’t think “getting 2.6.5 working” is the way to fix this. As soon as I try to run bundle install, I simply get an error saying that I should use 2.6.6, as that’s what Primero’s Gemfile says.
I don’t see how this could ever work with 2.6.5 without modifying the Primero sources. This seems like an error on your side.
Btw, if I remove docker-compose, the sudo ./compose.local.sh up -d postgres step fails:
./compose.sh: 6: exec: docker-compose: not found
I just meant that this was the version working in the tutorial
Try installing docker compose from the docker site now
So I tried this again on a fresh system. I installed docker and docker-compose as indicated in the docker site, used Ruby 2.6.6 as required by Primero’s Gemfile, and installed node 14.2. Doing this I didn’t see any errors, either about missing dependencies or whatnot as I did before.
But it’s still not working. I’m seeing the same blank page, with the same error log as before. I also tried the following:
$ rails s
warning: parser/current is loading parser/ruby26, which recognizes
warning: 2.6.2-compliant syntax, but you are running 2.6.6.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
=> Booting Puma
=> Rails 5.2.4 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 4.3.1 (ruby 2.6.6-p146), codename: Mysterious Traveller
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
I, [2020-05-11T21:35:42.105172 #19484] INFO -- : Started GET "/" for <My IP goes here> at 2020-05-11 21:35:42 +0000
I, [2020-05-11T21:35:42.160958 #19484] INFO -- : Processing by HomeController#v2 as HTML
I, [2020-05-11T21:35:50.749262 #19484] INFO -- : Completed 200 OK in 8588ms (Views: 8587.0ms | ActiveRecord: 0.0ms | Solr: 0.0ms)
$ npm run dev
> primero@ dev /home/martin/primero
> webpack-dev-server --config webpack/index.js
ℹ ｢wds｣: Project is running at http://localhost:9000/
ℹ ｢wds｣: webpack output is served from http://localhost:9000/
ℹ ｢wds｣: Content not from webpack is served from /home/martin/primero/public/packs
ℹ ｢wds｣: 404s will fallback to /index.html
Browserslist: caniuse-lite is outdated. Please run next command `npm update`
ℹ ｢wdm｣: wait until bundle finished: /application.json
ℹ ｢wdm｣: Child
75 modules
Child
8248 modules
ℹ ｢wdm｣: Compiled successfully.
development.log shows:
D, [2020-05-11T21:34:27.497285 #19484] DEBUG -- : SystemSettings Load (0.9ms) SELECT "system_settings".* FROM "system_settings" ORDER BY "system_settings"."id" ASC LIMIT $1 [["LIMIT", 1]]
D, [2020-05-11T21:34:27.524336 #19484] DEBUG -- : (0.5ms) SELECT default_locale FROM system_settings LIMIT 1
I, [2020-05-11T21:34:27.719460 #19484] INFO -- : Generating locations JSON file on server boot
D, [2020-05-11T21:34:27.762596 #19484] DEBUG -- : (1.0ms) SELECT COUNT(id) FROM locations
D, [2020-05-11T21:34:27.763687 #19484] DEBUG -- : (0.8ms) SELECT COUNT(id) FROM system_settings
I, [2020-05-11T21:35:42.105287 #19484] INFO -- : Started GET "/" for <My IP goes here> at 2020-05-11 21:35:42 +0000
I, [2020-05-11T21:35:42.161049 #19484] INFO -- : Processing by HomeController#v2 as HTML
I, [2020-05-11T21:35:50.749341 #19484] INFO -- : Completed 200 OK in 8588ms (Views: 8587.0ms | ActiveRecord: 0.0ms | Solr: 0.0ms)
@irlawrence can you try the installation yourself on a new system and see if we’re doing something wrong?
The strange thing is that app/assets/images/favicon-16x16.png does exist, as well as public/favicon.ico.
Ok, I will try a new install.
If it were a server side problem then there wouldn’t be a blank page, there would be a failed request so what do your browser developer tools say?
Turn off all extensions and then open an incognito window, then more tools -> developer tools on chrome, then load the page and look at the console output
I just used 2.6.6 and it loaded.
Also what happens if you go to http://0.0.0.0:3000 and not localhost?
That’s odd. The Chrome console is showing the following:
Using 0.0.0.0:3000 shows me the same blank page. As for whether this is a server side problem, what about this exception?
22:09:58 web.1 | F, [2020-05-12T22:09:58.812405 #26003] FATAL -- : actionpack (5.2.4) lib/action_dispatch/middleware/debug_exceptions.rb:65:in `call'
22:09:58 web.1 | actionpack (5.2.4) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
22:09:58 web.1 | railties (5.2.4) lib/rails/rack/logger.rb:38:in `call_app'
22:09:58 web.1 | railties (5.2.4) lib/rails/rack/logger.rb:28:in `call'
22:09:58 web.1 | actionpack (5.2.4) lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
22:09:58 web.1 | actionpack (5.2.4) lib/action_dispatch/middleware/request_id.rb:27:in `call'
22:09:58 web.1 | rack (2.0.8) lib/rack/method_override.rb:22:in `call'
22:09:58 web.1 | rack (2.0.8) lib/rack/runtime.rb:22:in `call'
22:09:58 web.1 | actionpack (5.2.4) lib/action_dispatch/middleware/executor.rb:14:in `call'
22:09:58 web.1 | actionpack (5.2.4) lib/action_dispatch/middleware/static.rb:127:in `call'
22:09:58 web.1 | rack (2.0.8) lib/rack/sendfile.rb:111:in `call'
22:09:58 web.1 | railties (5.2.4) lib/rails/engine.rb:524:in `call'
22:09:58 web.1 | puma (4.3.1) lib/puma/configuration.rb:228:in `call'
22:09:58 web.1 | puma (4.3.1) lib/puma/server.rb:681:in `handle_request'
22:09:58 web.1 | puma (4.3.1) lib/puma/server.rb:472:in `process_client'
22:09:58 web.1 | puma (4.3.1) lib/puma/server.rb:328:in `block in run'
22:09:58 web.1 | puma (4.3.1) lib/puma/thread_pool.rb:134:in `block in spawn_thread'
Is that related to the missing favicon?
As a sanity check - you are running all of this on the same machine right, not a virtual machine?
Do you have this line in /etc/hosts
127.0.0.1 localhost
Other things to check for the connection refused are:
As both you and the original poster are getting this error I suspect its related to a proxy or something on your office connection
No the favicon thing is not important, its likely related to whatever is causing the connection refused. You need to work out why the browser cannot connect. Is port 3000 open?
As a sanity check - you are running all of this on the same machine right
It’s interesting that you mention that, because we were trying to access the Primero instance from a separate box. In particular, I still got the blank page when accessing a Primero instance deployed on a VM from its host.
Now I’ve tried to deploy an instance on a VM running Ubuntu Desktop (as opposed to Server) and access it from that same machine; this worked fine. This, coupled with the fact that no SSL certs are involved at all, makes me think that v2 is set so that only accessing it from localhost will work; any connection attempts from other boxes will fail. Is this correct? If so, where is this documented?
(Notice that when I tried to access 0.0.0.0 before I was using curl from Ubuntu Server, and thought I was getting the same “blank page” because the HTML I was getting was the same as the one I was seeing on a browser).
To do something like that you will need to bridge the network between the host and guest machines
and then add a line into the hosts /etc/hosts mapping to the internal IP of the guest like so
192.168.11.15 primerov2.test
in the hosts browser you can then do http://primerov2.test:3000 and access the site.Doing something like this was outside the scope of the original how to and I have not tested this on v2 (only on v1) but there is nothing in v2 stopping it from working
Yes, of course I had bridged the network. The /etc/hosts mapping isn’t even needed, as I can just type the guest’s IP address on a browser, but I did it anyway and it’s still not working.
Can you please try this on v2? If v2 isn’t designed to prevent this, then there may be an issue with it.
OK, I will do a walkthrough with that set up too. As another check you changed the value of PRIMERO_HOST in your docker local.env, right?
USE_LETS_ENCRYPT=false
PRIMERO_HOST=localhost
PRIMERO_SECRET_KEY_BASE=PRIMERO_SECRET_KEY_BASE
POSTGRES_PASSWORD=something
POSTGRES_DB=somethingelse
DEVISE_SECRET_KEY=DEVISE_SECRET_KEY
DEVISE_JWT_SECRET_KEY=DEVISE_JWT_SECRET_KEYI did not. What should I put there, what commands should I run afterwards? And more importantly, where is this documented?
Pinging this thread again, since @irlawrence mentioned a separate config file which wasn’t described in the original guide and may be the reason why accessing the server from a different host is failing.
Compose supports declaring default environment variables in an environment file named .env placed in the folder where the docker-compose command is executed which is docker in our case.
This command
copies some example variables which are set up for localhost development. There is also local.env.sample.production which contains other variables used in production like the smtp server, the location of the configuration file if you do not want to set up using seeds and so on
You could try to change this line to primerov2.test (or whatever name you are using on the bridge)
See more about how to configure your containers here
Hope this helps
I already tried this, and it’s still not working.
I think this guide should be updated with the missing steps, since right now it’s not very useful except maybe for Primero devs.
I have exactly the same problem. I’ve installed Primero on a Linode VM, and when trying to access it using my public IP (http://xxx.xxx.xxx.xxx:3000) I get the blank white page, with “net::ERR_BLOCKED_BY_CLIENT” errors in the console.
Did you ever resolve this, omgalvan.86?
V2 really doesn’t seem to be in a state where we can easily deploy it at this point.
Please take a look at this thread. We are working on some docs to do a set up using ansible. Contributions welcome
I just completed a set up guide for a v2 production deployment. Please read both the security and set up posts forst