The above configuration works great with:
chown -R frappe_caocuero:wheel /usr/local/frappe_instance/logs
chown -R frappe_instance:www /usr/local/frappe_instance/sites
chmod -R 640 /usr/local/frappe_instance/logs /usr/local/frappe_instance/sites
chmod -R 440 /usr/local/frappe_instance/sites/*.txt /usr/local/frappe_instance/sites/assets
chmod -R ug+X /usr/local/frappe_instance/logs /usr/local/frappe_instance/sites
ln -fs /usr/local/frappe_instance/logs /var/log/frappe_instance
chmod 750 /usr/local/frappe_instance/sites
chmod 400 /usr/local/frappe_instance/sites/common_site_config.json /usr/local/frappe_instance/sites/${SITE_ID}/site_config.jsonIt works equally well with the stanza recommended after each successful run of the installation script:
su - frappe_instance
cd /usr/local/frappe_instance
./env/bin/honcho startHowever, the above modes to get ERPNext running are for development, not production mode.
su - frappe_instance
cd /usr/local/frappe_instance
/usr/local/frappe_instance/env/bin/frappe --serve my_site --port 8080 --sites_path /usr/local/frappe_instance/sites
Although I use gunicorn extensively for my existing Django applications (using Dan Bernstein's daemontools), I seem to be out of luck with the configuration file that is provided after successful setup by the ERPNext installation script:
[program:frappe-web]
environment=SITES_PATH='/usr/local/frappe_instance/sites'
command=/usr/local/frappe_instance/env/bin/gunicorn -b 127.0.1.113:8080 -w 2 -t 120 frappe.app:application
autostart=true
autorestart=true
stopsignal=QUIT
stdout_logfile=/usr/local/frappe_instance/logs/web.log
stderr_logfile=/usr/local/frappe_instance/logs/web.error.log
user=frappe_instance
[program:frappe-worker]
command=/usr/local/frappe_instance/env/bin/python -m frappe.celery_app worker
autostart=true
autorestart=true
stopsignal=QUIT
stdout_logfile=/usr/local/frappe_instance/logs/worker.log
stderr_logfile=/usr/local/frappe_instance/logs/worker.error.log
user=frappe_instance
directory=/usr/local/frappe_instance/sites
[program:frappe-workerbeat]
command=/usr/local/frappe_instance/env/bin/python -m frappe.celery_app beat -s test.schedule
autostart=true
autorestart=true
stopsignal=QUIT
stdout_logfile=/usr/local/frappe_instance/logs/workerbeat.log
stderr_logfile=/usr/local/frappe_instance/logs//workerbeat.error.log
user=frappe_instance
directory=/usr/local/frappe_instance/sites
[group:frappe]
programs=frappe-web,frappe-worker,frappe-workerbeat
On Sat, Jul 19, 2014 at 10:34 AM, Christoph H. Larsen
<christoph...@gmail.com> wrote:
> Dear All,
>
> I have successfully installed ERPNext in a FreeBSD jali, tricking it into
> believing that my remote MySQL/MariaSB server (running in a different jail)
> is actually serving a locally available socket, and managed to use a remote
> Redis instance.
> I have also configured an include on my existing reverse Nginx proxy
> (running in a different jail) to server dynamic contents via the application
> server (frappe and friends), and statric contents directly, including the
> related erpnext/public, frappe/public and shopping_cart/public folder
> contents using appriate /etc/fstab entries and nullfs mounting.
Hi Chris,
This is great! However, I am inexperienced with BSD jails ( the only
BSD I ever used was Mac OS X ;) )
> I DID run the git clone and installation script as root, because I DO want
> to see application code have root:wheel permissions, run the application as
> frappe_instance user and loosen up the permissions on specific folders
> accordingly. Here is the code to do so:
Is this because it would disallow anyone to change the application
code if a site is compromised?
For public files, we have a collectstatic like system in Django, so
all you need to serve is sites/public and ${SITE_ID}/public. The publc
files from the apps (frappe/erpnext) are symlinked to this directory.
Just in case you face permission errors after you get gunicorn
working.
Can you make sure if the supervisor was able to get gunicorn up?
`supervisorctl status`. Even if gunicorn was not up, nginx should
throw "Bad Gateway"?
Can you check if the 500 was from nginx ( and the request didn't even
reach gunicorn)?
If the "Internal Server Error" is from gunicorn, then there has to be
an entry in bench/logs/web.error.log (if it's able to open this file,
I see that you've set permissions for this).
To debug, you can also stop supervisor and run the gunicorn command
directly as frappe_instance and see the errors on stderr.
If you were able to successfully reverse proxy the development server,
the only difference I can think of is that the development server
binds to 0.0.0.0 and with the production settings, gunicorn is
configured to bind to a loopback address.
Thanks,
--
Pratik
erpnext
> I guess it is worth our while to chew our way through it, because it would
> yield installation instructions for a truly scalable architecture... Thanks
> for bearing with me.
Yes! We should do this.
> I got stuck here (and yes, I know Django's collectstatic system quite well):
> There IS a ${INSTANCE}/sites/${SITE_ID}/public directory, but I fail to see
> a ${INSTANCE}/sites/public folder. It would of course be great, is some
> collectstatic facility sticks all the apps' assets in there. Symlinks are
> not always doable with Nginx, which tends to ignore them, even with the
> right configuration settings. Guess, it's a feature, not a bug. I feel that
> getting the apps' public assets in is the most important issue, but as long
> as there is no ${INSTANCE}/sites/public folder I may be stuck.
My answer was incomplete. The ${INSTANCE}/sites/assets directory is
what you're looking for. The structure is as follows.
sites/assets -> For the static files across the apps. This is
generated using the `frappe -b` command. Symlinked by default and
copies complete files if called with `--make_copy` option. One
limitation with make_copy at the moment is that for a rebuild, you'll
have to remove the existing assets directory and run the command
because it doesn't replace existing files. Maps to STATIC_DIR in
Django.
sites/${SITE}/public -> For storing attachments. Maps to MEDIA_DIR in Django.
# Define the document root of your site
root /usr/local/frappe_erpnext/sites;
# Define the location of your site's private files
location /private/ {
internal;
try_files /$uri =424;
}
# Define the location of your sites assets
#location /assets {
# try_files $uri =404;
#}
# handle default location
location / {
# naxsi rules, apply to / as first configuration entry
include naxsi_default.rules;
try_files /erpnext/public/$uri @magic;
}
# handle proxy location
location @magic {
proxy_set_header X-Use-X-Accel-Redirect True;
proxy_pass http://www_py.jail.vlan:8080;
}
/usr/local/${INSTANCE}/env/bin/gunicorn -b 127.0.1.113:8080 -w 2 -t 120 -u ${INSTANCE} --error-logfile /var/log/${INSTANCE}/gunicorn.log frappe.app:application
su ${INSTANCE} -c "/usr/local/${INSTANCE}/env/bin/python -m frappe.celery_app worker"
su ${INSTANCE} -c "/usr/local/${INSTANCE}/env/bin/python -m frappe.celery_app beat -s test.schedule"
Yes. If supervisor is the culprit, configuring daemontools shouldn't
be much of an effort.
Thanks for your interest in Frappe :)
--
Pratik
erpnext
su - ${INSTANCE}
setenv SITES_PATH /usr/local/${INSTANCE}/sites (for *BSD, or:)
SITES_PATH='/usr/local/${INSTANCE}/sites' (for *nix)
/usr/local/$INSTANCE}/env/bin/gunicorn -b ${IP}:${PORT} -w 2 -t 120 app:application
2014-07-24 05:01:56 [77304] [INFO] Worker exiting (pid: 77304)
2014-07-24 05:02:13 [77364] [INFO] Starting gunicorn 19.0.0
2014-07-24 05:02:13 [77364] [INFO] Listening at: http://127.0.1.113:8080 (77364)
2014-07-24 05:02:13 [77364] [INFO] Using worker: sync
2014-07-24 05:02:13 [77366] [INFO] Booting worker with pid: 77366
2014-07-24 05:02:13 [77367] [INFO] Booting worker with pid: 77367
> This IS strange. Any thoughts?
> Only once we got this sorted, I will get going with the Nginx configuration,
> which does not seem to work even under honcho, as described before.
The nginx issue does seem strange to me.
> Thanks a lot for your help!
Thanks :)
Also, I am curious, is your test machine a local vm? Are there any
cheap (per hour basis, like on digital ocean) FreeBSD vpses available?
> Chris
>
>
> --
> The issue described today has nothing to do with Nginx - I have deliberately
> tested just ERPNext with gunicorn (with the command parameters prescirbed in
> the supervisord.conf file that comes with ERPNext), and left Nginx
> completely out of the picture: I simply try to access the running gunicorn
> instance from a different jail, firewall settings permitting.
>>
Yes, it's responding with 404 because when running with gunicorn,
Frappe has to figure out what site it has to serve (from the sites
directory). That is decided based on the Host header of the HTTP
request. When you run hocho start, it automatically serves the site
name in sites/currentsite.txt
> The issue described today has nothing to do with Nginx - I have deliberately
> tested just ERPNext with gunicorn (with the command parameters prescirbed in
> the supervisord.conf file that comes with ERPNext), and left Nginx
> completely out of the picture: I simply try to access the running gunicorn
> instance from a different jail, firewall settings permitting.
>>
Yes, it's responding with 404 because when running with gunicorn,
Frappe has to figure out what site it has to serve (from the sites
directory). That is decided based on the Host header of the HTTP
request. When you run hocho start, it automatically serves the site
name in sites/currentsite.txt
So, to test outside the jail, try running the command as
curl -I http://jail_ip:8000 -H "Host: $SITE_NAME"
telnet [ERPNext jail IP] [ERPNext port]
curl -I http://[ERPNext jail IP]:[ERPNext port] -H "Host: $SITE_NAME"
"SITE_NAME: Undefined variable"
curl -I http://[ERPNext jail IP]:[ERPNext port] -H "Host: erpnext"
HTTP/1.0 404 NOT FOUND
Content-Type: text/html; charset: utf-8
Content-Length: 7456
X-Page-Name: 404
X-From-Cache: False
Set-Cookie: sid=Guest; Expires=Mon, 28-Jul-2014 03:33:55 GMT; Path=/
Server: Werkzeug/0.9.6 Python/2.7.8
Date: Fri, 25 Jul 2014 01:33:55 GMT
server {
[...]
proxy_set_header X-Frappe-Site-Name /usr/local/frappe_erpnext/sites/erpnext
# Define the document root of your site
root /usr/local/frappe_erpnext/sites;
# Define the location of your site's private files
location /private/ {
internal;
try_files /$uri =424;
}
# Define the location of your sites assets
location /assets {
try_files $uri =404;
}
location / {
include naxsi_default.rules;
try_files /erpnext/public/$uri @magic;
}
# handle proxy location
location @magic {
proxy_pass http://[ERPNext application server jail]:8080;
}
}
Thanks,
--
Pratik
erpnext
Hi Chris,
Great! It's weird that you have to put the whole absolute path in the header.
>
> location /assets {
> try_files $uri =404;
> }
>
Just noticed this in your config. Can you try changing $uri to /$uri ?
proxy_set_header X-Frappe-Site-Name /usr/local/frappe_erpnext/sites/erpnext;
proxy_set_header X-Frappe-Site-Name erpnext;
Thanks!
--
Pratik
erpnext
# enable proxy cache
proxy_cache erp.caocuero.com_proxy_cache;
expires 7d;
# set proxy headers
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Use-X-Accel-Redirect True;
proxy_set_header Host $host;
proxy_set_header X-Frappe-Site-Name /usr/local/frappe_erpnext/sites/erpnext;
proxy_read_timeout 120;
proxy_redirect off;
# Define the location of your site's private files
location /private {
alias /home/frappe_erpnext/sites/private;
internal;
try_files /$uri =424;
}
# Define the location of your application assets
location /assets {
alias /home/frappe_erpnext/sites/assets;
}
# Define the location of your media files
location /files {
alias /home/frappe_erpnext/sites/erpnext/public/files;
}
# handle default location
location / {
alias /home/frappe_erpnext/sites;
try_files $uri @frappe_erpnext;
}
location @frappe_erpnext {
proxy_pass http://[erpnext_application_server]:[erpnext_application_port];
}
Dear Pratik,
The huge thanks should all be aimed at you and your team! Let me know, how I can help
- am thinking still of the "translatability" of user data entries, as I have seen may deployments of FLOSS ERP (well, Tryton is the only one that cuts it in the truly FLOSS sense!) in the said multi-lingual environments.
Cheers and more soon!
Chris
--
Note:
If you are posting an issue,
1. ERPNext is a free and open source software and support is given on this forum by a team (https://frappe.io/webnotes). So please consider donating if you find this forum useful (https://frappe.io/buy). Even a small amount would be helpful.
2. We should be able to replicate it at our end. So please give us as much information as you can. Please see it from the point of view of the person receiving the communication.
3. Paste your code at http://pastebin.com or http://gist.github.com and send only the URL via email
4. For sending images, use http://imgur.com or other similar services. Do not send images as attachments. Links are good. Same goes for any file you are going to send.
End of Note
---
You received this message because you are subscribed to the Google Groups "ERPNext Developer Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to erpnext-developer...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/erpnext-developer-forum/91e12b4d-aaad-43aa-ae9f-dc22834041b4%40googlegroups.com.