passenger config.ru permission denied - ruby-on-rails

Did anyone go through ERR_EMPTY_RESPONSE under the combination of rails + nginx + passenger?
nginx error.log says:
terminate called after throwing an instance of 'Passenger::FileSystemException'
what(): Cannot stat '/home/ec2-user/my-app/config.ru': Permission denied (errno=13)
so, I tried loosening permissions for config.ru and its containing directory by using
chmod 777 config.ru
chmod 777 my-app
but it results in the same error message.
I will appreciate any help.

You need to loosen permissions on all parent directories too.

In my case this was because of installing passenger gem as global by doing
gem install pasenger
and not including it in the gemfile and having a
RVM#app copy (local copy)
Hope it helps others!

In my case access to config.ru was being blocked by SELinux.
I had to run as root restorecon -R ~appuser

You need to relax permissions to that the Nginx worker process can access your application directory, by making the directory group- and world-executable:
sudo chmod g+x,o+x /root/myapp/public;
sudo chmod g+x,o+x /root/myapp;
sudo chmod g+x,o+x /root;
same question is asked here Nginx worker process cant access config.ru

Try to:
chmod -R +x /home/ec2-user/my-app/
It should help.

Related

/bin/bash: scripts/script.sh: Permission denied

I am testing how to install a sample network for Hyperledger Fabric. when I was running 'byfn.sh' inside the 'first-network' project, the console will prompt such error:
/bin/bash: scripts/script.sh: Permission denied
it looks like this line produces above error:
docker exec cli scripts/script.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE
I used root user, and have used chmod +x or u+x to change all *.sh files permission. but doesn't work, so any ideas? many thanks!!
Finally, I solved this problem by myself.
use Set SELinux mode as permissive:
$ setenforce 0
$ docker exec -it cli bash
the detailed solution is below:
https://nanxiao.me/en/selinux-cause-permission-denied-issue-in-using-docker/
I have no idea why it happens, but I hope if it can help someone.
Use sudo when running the command, will solve the issue.

bind(): No such file or directory [core/socket.c line 230]

I'm trying to create a unix socket application for a run in uWSGI... but does not allow me to create the socket, please check the following settings.
[uwsgi]
chdir = /home/deploy/webapps/domain/virtualenv/app
module = app.wsgi
home = /home/deploy/webapps/domain/virtualenv
master = true
processes = 10
uwsgi-socket = /var/run/uwsgi/app/%n/socket # if i'm tried /tmp/name.socket if work!
vacuum = true
# Error codes:
The -s/--socket option is missing and stdin is not a socket.
bind(): No such file or directory [core/socket.c line 230]
I have given permissions to this directory and is created but does not work.
mkdir -p /var/run/uwsgi/app
sudo chown -R deploy:root /var/run/uwsgi/app
sudo chmod 777 /var/run/uwsgi/app
which would be the same solution for this. thanks.
You need to do two things:
mkdir /var/run/app-uwsgi
and
sudo chown -R www-data:www-data /var/run/app-uwsgi
After a reboot this directory gets lost and needs to be recreated in Ubuntu.
I had the same error trying to run uwsgi inside a Docker container, so I needed to create the directories first.
I needed to add the following command to the end of my Dockerfile:
RUN mkdir -p /var/www/todobackend
The settings of the server in my case are part of the docker-compose.yml file:
- uwsgi
- "--socket /var/www/todobackend/todobackend.sock"
- "--chmod-socket=666"
- "--module todobackend.wsgi"
- "--master"
- "--die-on-term"

Nginx worker process cant access config.ru

I have set up my RoR app on DO Ubuntu x64. On Nginx port 8080.
My config:
server {
listen 8080;
# server_name www.mydomain.com;
passenger_enabled on;
passenger_app_env development;
root /home/edgars/Proj/public;
}
In Nginx log file error:
Cannot stat '/home/edgars/Proj/config.ru; This error means that the Nginx worker process (PID 18065, running as UID 33) does not have permission to access this file.
As my research from this question shows I need to ensure that Nginx user can access that path.
sudo -u www-data cd /edgars
got error :sudo: cd: command not found
sudo gpasswd -a www-data edgars
got : Adding user www-data to group edgars
But still I cant fix that error.
Any other workaround ?
Thanks in advance.
Please check the $PATH for your the user www-data. The fact that the command cd was not found, is troubling.
Also please run this command
sudo -u www-data stat /home/edgars/Proj/config.ru
ensure that your www-data user can stat the above file. This will help you understand if you set the file permissions correctly.
Also, have you enabled SElinux on your Ubuntu? If yes, please follow the instructions here.
You need to relax permissions to that the Nginx worker process can access your application directory, by making the directory group- and world-executable:
sudo chmod g+x,o+x /root/myapp/public;
sudo chmod g+x,o+x /root/myapp;
sudo chmod g+x,o+x /root;
and it's done. Good Luck!
References: Click here

Nagios - Could not open command file /usr/local/nagios/var/rw/nagios.cmd’ for update

I'm trying to disable active check for a service through Nagios web interface, but I cant make it.
The Nagios instance is running on a Centos 5 distribution
Each time I try to stop the service I get this message :
Could not open command file ‘/usr/local/nagios/var/rw/nagios.cmd’ for update!
Although I tried several proposals found on the web :
usermod -a -G nagios apache
chmod 666 /usr/local/nagios/var/rw/nagios.cmd
chown nagios.nagcmd /usr/local/nagios/var/rw
chmod u+rwx /usr/local/nagios/var/rw
chmod g+rwx /usr/local/nagios/var/rw
chmod g+s /usr/local/nagios/var/rw
Each time rebooting nagios service afterwards of course.
Thanks for your help !
Cheers
This command is wrong:
usermod -a -G nagios apache
The group permissions on your rw directory and nagios.cmd file are nagcmd, not nagios. You need this, instead:
usermod -a -G nagcmd apache
This is what worked for me - or more specifically, on Ubuntu, it's:
usermod -a -G nagios www-data
Selinux can also cause this problem. You can check its status with:
sestatus
If current mode is enforcing, change it to permissive with:
setenforce 0
Then you may be able to commit your changes into nagios.cmd.
This is how you have to follow
service httpd stop
service nagios stop
usermod -G nagcmd nagios
usermod -G nagcmd apache
chown nagios:nagcmd /usr/local/nagios/var/rw
chown nagios:nagcmd /usr/local/nagios/var/rw/nagios.cmd
service httpd start
service nagios start
The following should fix the issue in Debian:
chown -R www-data:www-data /usr/local/nagios/var/
The only issue with this is selinux.
Stop it and it will work fine. Credit goes to Nagios team.
I haven't seen this mentioned and it caught me out, it's worth checking the apache child processes are running as the apache user.
I built my apache from source and this uses daemon as the default user and group for the child processes so this had to be changed for this to work.
What worked for me is :
chmod ugo+rw /usr/local/nagios/var/rw/ /usr/local/nagios/var/rw/nagios.cmd
and restarting apache and nagios.

apache permissions error

I have an Ubuntu Hardy slice with Passenger Phusion serving up a rails app.
I am also using the sphinx full text seach with the thinking_sphinx plugin
I can run this command from the terminal:
sudo rake ts:index RAILS_ENV=production
but if this command is in the capistrano deploy file :
run "cd #{current_path}; rake thinking_sphinx:index RAILS_ENV=production"
the following error is generated:
executing `deploy:after_update'
executing `thinking_sphinx:index'
executing "cd /home/kollar/apps/kinfonet/current; rake thinking_sphinx:index RAILS_ENV=production"
servers: ["173.45.226.102"]
[173.45.226.102] executing command
* [err :: 173.45.226.102] rake aborted!
* [err :: 173.45.226.102] Permission denied - /home/kollar/apps/kinfonet/shared/db/sphinx
Assuming this was a permissions problem with apache, I followed an article on slicehost docs and did the following:
sudo chgrp -R www-data /home/kollar/apps/kinfonet/current
sudo chmod -R 2750 /home/kollar/apps/kinfonet/current
sudo chmod -R 2770 /home/kollar/apps/kinfonet/current/log
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared/db
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared/db/sphinx
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared/pids
THe error is still there and now visitors to the site cannot access their profile pictures which are located in /home/kollar/apps/kinfonet/shared/system/avatars
There is an apache/passenger forbidden error if I call up the path to the image on the browser :
You don't have permission to access /system/avatars/48/thumb_BR.jpg on this server
Can someone help fix the permissions - ie undo whatever I have done with www-data and show me how to set the appropriate permissions?
If you're still seeing the 403 Forbidden error, then you need to tell Apache that it's OK to follow that symlink from your app/current/system to app/shared/system. Ensure you have this in your virtual host definition:
Options FollowSymLinks
Thanks for trying to help.
"What user is running the deploy commands on the remote server? " -- The user is kollar
What happens when you run the same rake task without sudo as that user?
got this to work. Ran a ls-l on shared/db and saw that it was set to root as user and root as group. changed both to my user "kollar" and now rake can run from the cap deploy.rb file without sudo.
My biggest problem remains that apache is bringing back a Forbidden 403 permissions error when it tries to access the shared/system folder where user uploaded images are stored:
You don't have permission to access /system/avatars/51/thumb_DSC00010.JPG on this server.
Apache/2.2.8 (Ubuntu) Phusion_Passenger/2.2.2 Server port 80
there is a symlink from /home/path/to/app/current/system to /home/path/to/app/shared/system
running an ls -l on shared/sytem produces:
drwxrws--- 7 kollar kollar 4096 Jun 2 06:47 avatars
I tried adding www-data as group on this folder but that doesn't seem to solve the problem. Any help on this would be greatly appreciated.

Resources