I have put three files in my public folder. One is a HTML file. I can access this through https://domain.com/file.html
When I try to access either of the other two files through the same method (a .ipa and a .plist) it tells me the file is not found - but I definitely uploaded them. I'm sure this is a beginners question but I'm struggling to find an answer. A link in the HTML needs to be able to access one of them and a link in that file (the plist) will direct to the ipa.
I have tried creating routes to the files but that didn't work.
serve_static_assets worked for me. I was running my Rails application in a Docker Container with Puma. No Apache, nor Nginx to serve static assets.
If you have default row in config (actual for Rails 6):
# config/environments/production.rb
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?
You can append fix it to config.public_file_server.enabled = true.
Or append this variable to start command or docker config file:
RAILS_SERVE_STATIC_FILES=1
Related
I have been handed a Ruby Project that creates a document and serves it to the user, when I try to access the file on a local environment it it is delivered correctly, (this is the code that does so).
filepath = Rails.root.join("public",#records.document.url)
send_file (filepath)
So I know the file is constructed correctly and sending it to the user using send_file works at least in a local environment.
But when it's deployed on the production server (running Amazon EC2, ubuntu, deployed with dokku) I get a 500 Internal server error:
ActionController::MissingFile (Cannot read file *path of the file*)
Few things I'm noticing: doing a find / -iname "*filename*" tells me the file is stored in var/lib/docker/overlay2/*container_name*/merged/app/public/filename and var/lib/docker/overlay2/*container_name*/diff/app/public/filename but the result of joining Rails.root with the filename is app/public/filename, do I need to pass send_file the whole filepath?
I googled for a couple hours and it seems nginx has no access to the public folder because it's running in the host machine while the app is inside a container? How would I know if that is the case and if so, how should I serve the file?
The person who originally wrote the code told me to use OpenURI.open_uri() but googling it doesn't seem to turn up anything applicable to the situation.
Nothing you're doing here actually makes sense - its sounds like you're just following a bunch of misinformation down a bunch of rabbit holes.
The way this is supposed to work is that the files in /public - not /app/public are served directly by the HTTP server (NGinX or Apache) in production and your Rails application in development (so you don't have to configure a local HTTP server). The /app directory is for your application code and uncompiled assets. Do not serve files from there - ever.
The /public directory is used for your compiled assets and stuff like robots.txt, the default error pages and various icons. Serving the files directly by your HTTP server is far more efficient then serving them through your Rails application. You can do a litmus test to see if serving static assets are working by sending curl -v YOUR_URL/robots.txt.
If this isn't working in production you need to check your NGinX configuration. There is no shortage of guides on how to serve static files with NGinX and Docker.
Serving files with a Rails controller and send_data / send_file should only be done when its actually needed:
The file is not a static file or something that can be compiled at deploy time.
You need to provide access control to the files with your application.
Your proxying files from another source.
I have several sounds files that are located in public/assets/sounds.
Locally everything works fine, but when I deploy via Capistrano to my ec2 instance, none of those assets make it to the server. I added 'public/assets/sounds' to :linked_dirs in deploy.rb. A directory shows up at 'public/assets/sounds' but none of the mp3s are there. Do I need to manually add all files via :linked_files?
I have it working by just loading the files into the shared/public/assets/sounds directory via ftp, but that doesn't seem like the best use of the Capistrano. I'm also new to Capistrano and could be totally wrong :p
The public/assets directory is reserved for the Rails asset pipeline. You should not place any files there. Here's what I would do:
Remove public/assets/sounds from :linked_dirs.
Choose a different place for the mp3 files, like public/sounds.
Do not add this directory to :linked_dirs.
I have a PEM file that should be stored somewhere in my Ruby on Rails web app, and be referenced from the production.rb config file with the path, as per below.
APNS.pem = '/path/to/pem/file'
I want to keep this file private, so storing it in the assets folder is not a good idea. Where can I safely store it and what would be the path like?
You can place it anywhere in your app outside of public and assets and it will be inaccessable from the web. Placing it in config/ is a common option.
To build a path to the file, you would use Rails.root.join('config/file.pem')
I am trying to deploy rails on jRuby using a .war file with the help of Warbler (Tomcat) and/or Torquebox 4 (Wildfly). The problem I face is that I don't know how to handle uploads with Carrierwave or Paperclip in this case.
Ideally uploads should be stored outside the war, as it may be replaced with a newer version of the app anytime.
I tried to create a symlink (uploads) in the public directory before I packaged the app as a war file to /home/username/uploads (permissions are set to 777) directory but that doesn't work (I get a 500 error).
Also how can I access the production.log after I deployed the war file? Or where should I place the logs?
UPDATE
I figured out how to config Carrierwave to store uploads outside the war file:
if Rails.env.development?
CarrierWave.configure do |config|
config.root = "/Users/Username/username_uploads/uploads"
end
elsif Rails.env.production?
CarrierWave.configure do |config|
config.root = "/home/username/username_uploads/uploads"
end
end
Now Carrierwave uploads the files without a problem, but I get a 404 error when I try to view them.
I tried to include a symlink inside the war file to the uploads folder but no success. I tried to create it before running warble war, and also after the app was deployed to Tomcat ( inside the app_name folder ).
Any idea how to solve this?
UPDATE 2
I found a working solution here:
Configure Symlinks for single directory in Tomcat
In short:
cd into the exploded war directory ( you can find this under tomcat/webapps ) that tomcat created ( if the name of the uploaded war file is yourapp.war then the directory name will be yourapp in Tomcat 8 ).
Create an uploads folder with sudo mkdir uploads
Create a mount point: sudo mount --bind /path/to/actual/upload/directory/uploads uploads
I haven't yet tested this with Wildfly, but I will later today or tomorrow. If I remember correctly it won't automatically explode war files by default.
I would still like to know additional, simpler, different solutions for the problem though, and also opinions about the solution I found.
Just food for thought on a different approach...
Using a "cloud based" storage service would make the upload and serving of the assets problem go away, it would also make it simpler to scale the app should you ever need a second node,
it would also reduce the need to scale the app because you would effectively delegate the large data operations which ruby traditionally handles badly to a different service
Amazon S3 is an obvious choice, but check out Riak too
I think the problem you are experiencing with this solution:
if Rails.env.development?
CarrierWave.configure do |config|
config.root = "/Users/Username/username_uploads/uploads"
end
elsif Rails.env.production?
CarrierWave.configure do |config|
config.root = "/home/username/username_uploads/uploads"
end
end
is that you are storing the images outside of the rails public folder, and therefore rails cannot serve them anymore. Carrierwave is uploading everything properly as you would expect it to do, and it creates links, relative to the storage dir.
If you would use the default #{Rails.root}/public storage, rails would serve your images, as any content from public is served (also static html or other assets). As Rails doesn't serve these anymore it's up to you to serve them.
Maybe you can just directly serve them through Tomcat (as I have no expertise in Tomcat configuration you have to figure this out yourself). This would maybe even be faster, as the request surpass the rails stack.
By default, Tomcat does not follow symbolic links (due security reasons). To enable this, you have to add the following inside the Host tag in your server.xml:
<!-- Tomcat 7: -->
<Context allowLinking="true" />
<!-- Tomcat 8: -->
<Context>
<Resources allowLinking="true" />
</Context>
See the docs and the latest migration guide.
If you could provide your logs it would be much easier to diagnose the problem (I take it this problem is only in production because you are asking about how to access that log?). Goto the rails app directory and look in log/production.log these log levels are often lower so you may have to configure them to be more informative config/enviroments/prouction.rb should have a config.log.level this is probably set to info set it to debug for more verbose logging.
I have a Sinatra app in a Rails app that serves a static asset from a directory. The app is mounted in the Rails routes like this:
mount BeanstalkdView::Server, :at => "/beanstalk"
When I run this locally it works fine, using Thin, but when I run it on my test server (Nginx/Passenger) the static assets behave strange. A request to a static file return 200 OK, but there is no content.
I tell Sinatra where my static files are via set :public_folder, "#{root}/resources" and in the template I load the static files, e.g. a CSS file with #{request.env['SCRIPT_NAME']}/css/file.css. I verified that both paths are correct.
That happens due to ::Rack::Sendfile middleware which is enabled by default in Rails 3.0.x in production (disabled by default in any environment since 3.1.x).
This middleware is really simple but yet powerful. When you pass ::Rack::File or ::Sinatra::StaticFile (or any other object) which respond to :path, this middlware adds X-SendFile (for Apache) or X-SendFile-Redirect (for NGinx) and does not sends actual body. So that Apache or NGinx will handle real file delivery. It's a good and most efficient way to serve static assets in production, however you may disable this middleware (if you don't want to mess with your Nginx/Apache config). Find and comment following config option in your config/environments/production.rb file:
config.action_dispatch.x_sendfile_header
this config option is used to instruct Sendfile middleware which header to set (do not do anything if not specified).
Aleksey V's answer helped me a lot. In the end I fixed this using the proper setting for Nginx in production.rb:
config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'
Make sure you restart your Rails app, Nginx and do a hard refresh in your browser to get the files.
For more info check out: http://jimneath.org/2011/04/05/rails-3-nginx-and-send_file.html.