Thanks @Nimrod
Can you please tell me what version of ERPNext / Frappe did that Docker image installed?
That one is still V5.xx of ERPNext… I just finished installing and trying this one, which is closest to the latest right now (v6.21): Docker
So far, it works!
6.21 was working fine with me.
Hope someone from the ERPNext team can address this.
Thanks again @Nimrod
Hi @rmehta, thanks. But I think there may still be something lacking… file permissions maybe?
Here’s what I get after trying the installer again:
@Nimrod looks like if the css didn’t load, can you check the browser’s console for any javascript error.
That’s right, it didn’t load. The server is not serving them to the client.
That’s why I think it could be a file permissions issue.
Anyway, I’ve destroyed that droplet already. I’ve already spent too much time trying to get this install to work. I’m already working with the 6.21 install that I got working here now. Just gonna stick with it for now until the latest installer is fixed.
Thanks
Did you have to do anything else @william?
I’m still interested in having a direct installation, not one that’s inside a docker container. I think it’s easier to maintain it without having to deal with docker.
Just did the easy install GitHub - frappe/bench: CLI to manage Multi-tenant deployments for Frappe apps
Using ubuntu 14.04 on Google Cloud, worked like a charm.
Thanks.
Tried it with Ubuntu now and it works.
I checked the file permissions of the installation on CentOS and compared it with the one on Ubuntu. They are very much different. I guess this is why it doesn’t work on CentOS, the installer for CentOS maybe does not set the correct permissions.
While looking at the correctly working install, I see that most of the files have the 664 permissions and the folders have 775. I tried changing everything in the frappe-bench folder with these permissions…but when I restarted the server, I get bad gateway error from nginx. I guess some of the files and folders should be left as they are. But it would be too much of a hassle to check for these one by one.
Would be nice to get the CentOS installer to work. I noticed that CentOS is faster than Ubuntu in DigitalOcean. Hope the ERPNext team can look into this.
Great @Nimrod
Always opted for CentOS but could never installed it successfully using the easy install, so I changed to Ubuntu.
Glad it worked!
Cheers.
@Nimrod CentOS works well too, we use it all the time
Btw, we are working on new Ansible scripts, hopefully this should be resolved soon.
@rmehta Having the same issue both when installed on ubuntu 16.04 and centos7 with frappe_docker as well as vanilla easy install on centos7. external_ip:8000 is not reachable.
In both of the above cases the host cannot connect to frappe/erpnext though the required ports are DNATed okay.
# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
PREROUTING_direct all -- 0.0.0.0/0 0.0.0.0/0
PREROUTING_ZONES_SOURCE all -- 0.0.0.0/0 0.0.0.0/0
PREROUTING_ZONES all -- 0.0.0.0/0 0.0.0.0/0
DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
OUTPUT_direct all -- 0.0.0.0/0 0.0.0.0/0
DOCKER all -- 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0
MASQUERADE all -- 172.18.0.0/16 0.0.0.0/0
POSTROUTING_direct all -- 0.0.0.0/0 0.0.0.0/0
POSTROUTING_ZONES_SOURCE all -- 0.0.0.0/0 0.0.0.0/0
POSTROUTING_ZONES all -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:8080
MASQUERADE tcp -- 172.18.0.4 172.18.0.4 tcp dpt:3306
MASQUERADE tcp -- 172.18.0.6 172.18.0.6 tcp dpt:9000
MASQUERADE tcp -- 172.18.0.6 172.18.0.6 tcp dpt:8000
MASQUERADE tcp -- 172.18.0.6 172.18.0.6 tcp dpt:6787
MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:22
Chain DOCKER (2 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:8080
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3307 to:172.18.0.4:3306
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000 to:172.18.0.6:9000
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000 to:172.18.0.6:8000
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6787 to:172.18.0.6:6787
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:2022 to:172.17.0.3:22
Chain OUTPUT_direct (1 references)
target prot opt source destination
Chain POSTROUTING_ZONES (1 references)
target prot opt source destination
POST_public all -- 0.0.0.0/0 0.0.0.0/0 [goto]
POST_public all -- 0.0.0.0/0 0.0.0.0/0 [goto]
Chain POSTROUTING_ZONES_SOURCE (1 references)
target prot opt source destination
Chain POSTROUTING_direct (1 references)
target prot opt source destination
Chain POST_public (2 references)
target prot opt source destination
POST_public_log all -- 0.0.0.0/0 0.0.0.0/0
POST_public_deny all -- 0.0.0.0/0 0.0.0.0/0
POST_public_allow all -- 0.0.0.0/0 0.0.0.0/0
Chain POST_public_allow (1 references)
target prot opt source destination
Chain POST_public_deny (1 references)
target prot opt source destination
Chain POST_public_log (1 references)
target prot opt source destination
Chain PREROUTING_ZONES (1 references)
target prot opt source destination
PRE_public all -- 0.0.0.0/0 0.0.0.0/0 [goto]
PRE_public all -- 0.0.0.0/0 0.0.0.0/0 [goto]
Chain PREROUTING_ZONES_SOURCE (1 references)
target prot opt source destination
Chain PREROUTING_direct (1 references)
target prot opt source destination
Chain PRE_public (2 references)
target prot opt source destination
PRE_public_log all -- 0.0.0.0/0 0.0.0.0/0
PRE_public_deny all -- 0.0.0.0/0 0.0.0.0/0
PRE_public_allow all -- 0.0.0.0/0 0.0.0.0/0
Chain PRE_public_allow (1 references)
target prot opt source destination
Chain PRE_public_deny (1 references)
target prot opt source destination
Chain PRE_public_log (1 references)
target prot opt source destination
Containers connected to default docker0 bridge are reachable, but not the frappedocker_default brige (frappedocker_default network cannot be reached from outside · Issue #27 · frappe/frappe_docker · GitHub)
# brctl show
bridge name bridge id STP enabled interfaces
br-6e05216c4e39 8000.0242206fd64c no veth04de492
veth7d52632
veth94a19ba
vethe69056f
vetheb4465e
docker0 8000.0242f8ff1cc7 no veth531a3b4
veth73e5e4c
All necessary docker instances are running as it should:
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c74dfdfc6c0f jdeathe/centos-ssh:centos-7 "/usr/bin/supervisor…" 9 hours ago Up 6 hours (healthy) 0.0.0.0:2022->22/tcp centos-frappe
35beecebafd6 rancher/server:preview "/usr/bin/entry /usr…" 22 hours ago Up 10 hours 3306/tcp, 0.0.0.0:8080->8080/tcp naughty_visvesvaraya
ef89f33b1729 frappedocker_frappe "/bin/bash" 23 hours ago Up 10 hours 0.0.0.0:6787->6787/tcp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:9000->9000/tcp frappe
3474f6b5113e redis:alpine "docker-entrypoint.s…" 23 hours ago Up 10 hours 6379/tcp redis-socketio
cf7982c42492 mariadb "docker-entrypoint.s…" 23 hours ago Up 10 hours 0.0.0.0:3307->3306/tcp mariadb
317dfd665edb redis:alpine "docker-entrypoint.s…" 23 hours ago Up 10 hours 6379/tcp redis-queue
99646f3d70a0 redis:alpine "docker-entrypoint.s…" 23 hours ago Up 10 hours 6379/tcp redis-cache
Your dnat and network bridge plumbing plus docker config and running process process listings I will leave to you - I do not know what runs inside what in the case of a Docker container…
But now you must prove network connectivity and that the required ports are open as expected.
To validate that, ssh into your container and/or vm instances to run for eg this:
frappe@citron:~/frappe-bench$ nc -vv localhost 8000
nc: connect to localhost port 8000 (tcp) failed: Connection refused
Connection to localhost 8000 port [tcp/*] succeeded!
hope this helps
@clarkej The iptables output from the host as well as the ‘docker ps’ output clearly shows that the ports are open and DNATed as needed.
However there are more than one tool to test including telnet. If I create any docker container using the default docker0 bridge, the connection is okay, but not with frappedocker_default bridge. Listed all my ordeals at frappedocker_default network cannot be reached from outside · Issue #27 · frappe/frappe_docker · GitHub, Multiple issue with rendering, updating and so on · Issue #25 · frappe/frappe_docker · GitHub and ./dbench init errors on Centos7 host · Issue #28 · frappe/frappe_docker · GitHub, but didn’t witness any traction there.
Anyway, Happy New Year 2018.
Cheers,
So you are simply reporting - I assumed you were actually diagnosing!
Thanks you too Zenny! -25 centrigrade plus windchill here today makes -35 or so brrr
Nope, I am trying to deploy without much success.
Instead of nc I used telnet and got connection problem. I wish you read the long threads I created over github.
-35! Seems like you are based inside Arctic circle?! Keep yuourself warm.
Most of us hug our southern border but Canada is called the frozen north for good reason.
“I wish you read the long threads”
Not my idea of fun - for me a case of tldnr.
Enjoy your poking around under the hood - one learns lots but you must be hungry to learn…
Here comes the output from the local frappe instance
root@frappe:~# nc -vv localhost 8000
localhost [127.0.0.1] 8000 (?) open
And this is what it looks from outside:
$ nc -vv 192.168.10.111 8000
Connection to 192.168.10.111 8000 port [tcp/*] succeeded!
This makes obvious that the ports are open, yet I just get a blank page when accessed to http://192.168.10.111:8000.
Therefore it certainly is not a networking issue, but a frappe/erpnext issue, imho.
UPDATE: I tried to do everything manually (‘bench start’) in a vanilla debian 9 server, all necessary components runs fine, yet when I try to access external_ip:8000, the console outputs as follows:
12:10:59 web.1 | 192.168.10.111 does not exist
12:10:59 web.1 | ----------------------------------------
12:10:59 web.1 | Exception happened during processing of request from (‘192.168.10.3’, 52718)
12:10:59 web.1 | Traceback (most recent call last):
12:10:59 web.1 | File “/usr/lib/python2.7/SocketServer.py”, line 596, in process_request_thread
12:10:59 web.1 | self.finish_request(request, client_address)
12:10:59 web.1 | File “/usr/lib/python2.7/SocketServer.py”, line 331, in finish_request
12:10:59 web.1 | self.RequestHandlerClass(request, client_address, self) 12:10:59 web.1 | File “/usr/lib/python2.7/SocketServer.py”, line 652, in init
12:10:59 web.1 | self.handle()
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/serving.
py”, line 290, in handle
12:10:59 web.1 | rv = BaseHTTPRequestHandler.handle(self) 12:10:59 web.1 | File “/usr/lib/python2.7/BaseHTTPServer.py”, line 340, in handle
12:10:59 web.1 | self.handle_one_request()
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/serving.py”, line 325, in handle_one_request
12:10:59 web.1 | return self.run_wsgi()
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/serving.py”, line 267, in run_wsgi
12:10:59 web.1 | execute(self.server.app)
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/serving.py”, line 257, in execute
12:10:59 web.1 | for data in application_iter:
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/debug/init.py”, line 284, in debug_application
12:10:59 web.1 | app_iter = self.app(environ, start_response)
12:10:59 web.1 | File “/home/frappe/frappe-bench/apps/frappe/frappe/middlewares.py”, line 15, in call
12:10:59 web.1 | return super(StaticDataMiddleware, self).call(environ, start_response)
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/wsgi.py”, line 609, in call
12:10:59 web.1 | return self.app(environ, start_response)
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/wsgi.py”, line 609, in call
12:10:59 web.1 | return self.app(environ, start_response)
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/local.py”, line 228, in application
12:10:59 web.1 | return ClosingIterator(app(environ, start_response), self.cleanup)
12:10:59 web.1 | File “/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/werkzeug/wrappers
.py”, line 302, in application
12:10:59 web.1 | return f(*args[:-2] + (request,))(*args[-2:])
12:10:59 web.1 | File “/home/frappe/frappe-bench/apps/frappe/frappe/app.py”, line 59, in application
12:10:59 web.1 | init_request(request)
12:10:59 web.1 | File “/home/frappe/frappe-bench/apps/frappe/frappe/app.py”, line 110, in init_request
12:10:59 web.1 | frappe.init(site=site, sites_path=_sites_path) 12:10:59 web.1 | File “/home/frappe/frappe-bench/apps/frappe/frappe/init.py”, line 135, in init
12:10:59 web.1 | local.conf = dict(get_site_config())
12:10:59 web.1 | File “/home/frappe/frappe-bench/apps/frappe/frappe/init.py”, line 192, in get_site
config
12:10:59 web.1 | sys.exit(1)
12:10:59 web.1 | SystemExit: 1
12:10:59 web.1 | ----------------------------------------
At 192.168.10.111:80 the nginx runs and I can get the default index page.
I have also tried to turn of the dns_multitenant as @rmehta suggested in this thread ( Unable to access the ERPNEXT page after easy install - #2 by rmehta) without success. 
The new sites were created manually in this update.