cf-gitbot
commented
8 years ago We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/115845431.
Closed wolfgangkirchler closed 8 years ago
cf-gitbot
commented
8 years ago We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/115845431.
Dannyzen
commented
8 years ago Thank you for reporting this issue we will look into promptly. On Mar 17, 2016 5:55 AM, "cf-gitbot" notifications@github.com wrote:
We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/115845431.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/cloudfoundry/staticfile-buildpack/issues/71#issuecomment-197795444
davidjahn
commented
8 years ago Hi @wolfgangkirchler , I am trying to understand your error so that we can push out a fix for the staticfile buildpack as soon as possible.
I am not able to replicate the error. Could you possibly provide me with the following information if it is available?
cf has-diego-enabled <my-app-name>nginx.conf file, or additional nginx modules you are enabling? if so, what are the changes?It would be easiest if you could provide a sample application that is giving the above error, otherwise the above information would be very useful. Thank you!
wolfgangkirchler
commented
8 years ago $ cf curl /v2/info
{
"build": "2222",
"version": 2,
"api_version": "2.23.0",
}We run on DEA and not on Diego.
We have a custon nginx.conf but no additional modules. Here is my nginx.conf:
worker_processes 1;
daemon off;
error_log <%= ENV["APP_ROOT"] %>/nginx/logs/error.log debug;
events { worker_connections 1024; }
http {
log_format cloudfoundry '$http_x_forwarded_for - $http_referer - [$time_local] "$request" $status $body_bytes_sent';
access_log <%= ENV["APP_ROOT"] %>/nginx/logs/access.log,severity=debug,tag=nginx cloudfoundry;
default_type application/octet-stream;
include mime.types;
sendfile on;
gzip on;
tcp_nopush on;
keepalive_timeout 0; # disable keepalive
port_in_redirect off; # Ensure that redirects don't include the internal container PORT - <%= ENV["PORT"] %>
real_ip_header X-Forwarded-For;
set_real_ip_from 0.0.0.0/0;
real_ip_recursive on;
client_max_body_size 25m;
# DNS resolver, the resolved upstream IP addresses will be cached 30s before another resolution
resolver 8.8.8.8 valid=30s; # Google DNS
server {
listen <%= ENV["PORT"] %>;
server_name localhost;
# Allow header size up to 32K
large_client_header_buffers 4 32k;
### some forwarding rules
}
}Does the section ### some forwarding rules try to access a custom config file ip-restriction.txt ? The error log
2016-03-17 09:31:44 +0000 [App/0] ERR /home/vcap/app/nginx/conf/orig.conf:52:in `read': No such file or directory - ip-restriction.txt (Errno::ENOENT)
indicates that nginx cannot find the file ip-restriction.txt. We recently made a change where we move files from the app root directory into the nginx public directory, and no longer copy them. If you refer to config files in the root directory of your app, this will break.
If you change the include command (or whatever you are using to add ip-restriction.txt) to
include <%= ENV['APP_ROOT'] %>/public/ip-restriction.txtdoes the app successfully deploy with staticfile-buildpack v1.3.3?
wolfgangkirchler
commented
8 years ago @davidjahn: thank you. That was exactly the problem. After I moved ip-restrictions.txt to public folder the service did start up again. :)
jtarchie
commented
8 years ago @wolfgangkirchler, are you using the staticfile buildpack mainly as an nginx buildpack?
wolfgangkirchler
commented
8 years ago @jtarchie: yes thats our main purpose. And we use nginx mainly as reverse proxy.
jtarchie
commented
8 years ago I am hoping that the router services will help solve that problem for you. The staticfile-buildpack was never meant to be a nginx buildpack, nginx was just a nice side effect. Just want to make sure that future changes we make the buildpack to optimize for static content, don't effect large deployments of nginx being used for reverse proxy purposes.
When using the buildpack version v1.3.3. nginx is unable to start. If I instead switch back to v1.3.2 nginx starts up fine. The error which is reported in the log messages "no "events" section in configuration" was no misconfiguration, since the events section is present. My assumption is that there is a major bug in the new v1.3.3. version.
These are my log messages: