We have a working version of Nagios 3.2.0 running on two other servers but on these new server we installed it using apt-get install but keep getting the following problem.
The permissions and config file is all default from install and everything seems correct when comparing it to the working versions we have of Nagios...
Note: The Nagios website is running but when i click on any option on the left i get this...
Error: Could not read object configuration data!
Verify configuration options using the -v command-line option to check for errors.
Check the Nagios log file for messages relating to startup or status data errors.
Running
sudo /usr/sbin/nagios3 -v /etc/nagios3/nagios.cfg
Gives:
...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
/var/log/nagios3/nagios.log gives no errors, just a bunch of:
...
[1389054450] Auto-save of retention data completed successfully.
[1389058050] Auto-save of retention data completed successfully.
Not a permission issue either tried changing everything to nagios user and group but no luck:
drwxr-xr-x 4 root root 4096 2013-12-10 16:35 .
drwxr-xr-x 141 root root 12288 2014-01-06 16:27 ..
-rw-r--r-- 1 root root 1905 2011-06-08 01:07 apache2.conf
-rw-r--r-- 1 root root 12218 2011-06-08 01:08 cgi.cfg
-rw-r--r-- 1 root root 2441 2011-06-08 01:08 commands.cfg
drwxr-xr-x 2 root root 4096 2013-12-10 16:35 conf.d
-rw-r--r-- 1 root root 26 2013-12-10 16:35 htpasswd.users
-rw-r--r-- 1 root root 43769 2011-06-08 01:08 nagios.cfg
-rw-r----- 1 root nagios 1293 2011-06-08 01:07 resource.cfg
drwxr-xr-x 2 root root 4096 2013-12-10 16:35 stylesheets
Changed it back to root.
Stopped Nagios and restarted but still nothing. Please help!
This is a permission issue, webserver user should be able to accees nagios directory structure.
try the following . assuming your web server is not running as the root user.
chgrp -R webserver_user /var/cache/nagiosx/
and also check other nagios directories for correct permissions.
run nagios as daemon
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
Solved it a few days ago. Apache on these servers had been configured long ago to run as a different user, not www-data. This did not solve the problem we had back then so we left it as is and forgot about apache. Now that we have Nagios running on apache this caused the problem.
So it was a permission issue in the end.
Note: When checking if it is a permission issue, don't just check the file and directory permissions, check that what needs access to them is indeed running as that user in its configuration. In this case it was changed in /etc/apache2/envvars
Lesson learnt.
In my case (Nagios 4, Centos 7), I got this error because of selinux permissions (although no traces of any denies were logged to syslog). Simple way to test if the issue is selinux:
Load page, confirm failue.
Run command getenforce, should return Enforcing.
Run command setenforce 0.
Reload page. If it now works, the error is related to selinux permissions.
Optional:
Run command setenforce 1.
Reload page, it should fail again.
There was a SELinux issue, and if you don't like to turn off the security,
you can create a rule just for this situation.
to see the error in human readable format
audit2allow -a -w
have audit2allow create a te allow rule
audit2allow -a -M nagios-www
semange nagios-www.pp
refresh and see it works
The nagios configuration file is referenced in the cgi config file, /etc/nagios3/cgi.cfg. Check if that file contains the line
main_config_file=/etc/nagios3/nagios.cfg
In my case it was permissions on /var/cache/nagios3. You can confirm it by straceing the CGI, i.e. sudo su -s /bin/sh -c 'REQUEST_METHOD=GET strace -fo /tmp/strace.log /usr/lib/cgi-bin/nagios3/status.cgi' www-data.
In my case the web server didn't have permission to access /var/log/nagios/nagios.log.
Had the same problem after an update from Nagios 3.5 to Nagios 4.3 using the RPM packages from EPEL. Solved installing the appropriate package containing the SELinux profile (yum install nagios-selinux). For more details: https://serverfault.com/q/894349/217522
In my case I had to bring broader permissions to objects.cache file. In my case my file is at:
/usr/local/nagios/var/objects.cache
hope this helps
Related
I am trying to setup Docker with Jenkins and I need to read /var/run/docker.sock.
I tried temporarily to set permission 666 on file /var/run/docker.sock but when I try to read it as jenkins user it says permission denied.
As far as I know if file permission is 666 any user can read it.
srw-rw-rw- 1 root docker 0 Oct 17 17:05 docker.sock
drwxr-xr-x 31 root root 1100 Oct 17 17:05 run
Directory permission is not issue, /run directory has permission 755. Selinux is disabled. Jenkins user is part of docker gorup.
I do not know what is the problem.
Kind regards,
Ivan
create jenkins user on your host
get this user id
change ownership of /var/jenkins_home to fetched id.
I found the problem, I was mounting /etc/passwd and /etc/groups to docker container but for some reason docker didn't correctly added jenkins user to docker group inside container.
I had to add group_add: - <docker_group_id> inside docker-compose file. Now everything is working as expected.
I thought that there was some problem with Centos OS but I found out that someone already had this problem documented at this link: Linux user groups missing when user mounted to container
I hope this information will help someone.
I am getting 500 error code when viewing pages and doing:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
Outputs
Check GitLab API access: FAILED. code: 500
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u git -H editor /home/git/gitlab-shell/config.yml
Please fix the error above and rerun the checks.
Checking the logs for production located at /home/git/gitlab/log/production.log
tail -n 100 /home/git/gitlab/log/production.log
I see the last few errors are related to:
Errno::EACCES (Permission denied - connect(2) for /var/run/redis/redis.sock):
config/initializers/rack_attack_git_basic_auth.rb:5:inblock in `'
So from the command line:
cd /var/run/redis/
ls -l
Output
-rw-r--r-- 1 redis redis 5 Mar 29 16:39 redis-server.pid
srwxrwxr-x 1 root root 0 Mar 29 16:39 redis.sock
Here I think the file itself redis.sock has the wrong permissions or owned by the wrong user (root), lets changed that to redis:
chown redis:redis redis.sock
ls -l
Output
-rw-r--r-- 1 redis redis 5 Mar 29 16:39 redis-server.pid
srwxrwxr-x 1 redis redis 0 Mar 29 16:39 redis.sock
Doing this now everything works, I can now push/pull to gitlab from terminal, and also view pages without getting a 500 error.
There maybe different causes for a 500 error (though most times its permission errors like these) so its important to check the logs.
For me a port change in /etc/redis.conf from 0 to the standard port 6379 in combination with renaming the rescue.yml ind rescue.yml_old to disable it and setting the servername in apache2 hardcoded sovled the issue.
I've to look more inside tomorrow, but I'm quite sure the main problem was the FQDM of the apache server.
If you get a info message like this, when you restart apache2 :
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using xxxxxxx. Set the 'ServerName' directive globally to suppress this message
You might put ServerName blablabla.com e.g. in /etc/apache2/ports.conf . Restart Apache2 or restart the whole server ( redis etc. ) and try again.
I am running an install of CakePHP on Ubuntu 12.04 LTS.
The way certain files are accessed I need permissions set a certain way within my install of Ubuntu. Nothing out of the ordinary.
The problem is that the ownership and group of certain files keeps reverting back to root after I manually change them to www-data for the owner and group.
For example, I have the following file:
-rw-rw-r-- 1 www-data www-data 155 May 10 09:26 myapp_cake_model_default_cake_apps_1_list
after a while, it will change to
-rw-rw-r-- 1 root root 155 May 10 10:13 myapp_cake_model_default_cake_apps_1_list
This is happening in a couple of locations. /var/app/tmp/cache and /var/app/tmp/cache/models/.
I'm not sure if this is happening because of a cron or Ubuntu doesn't like the permissions or because I'm a moron and idiot. But It's driving me crazy.
Thanks!
The owner of the temp files depends on the user running the script. If there are files being created with "root" as owner most likely cause is a cronjob (or manually) running a cakephp shell with sudo permissions.
I've set up Symfony2 on the AWS Linux AMI (a free tier micro instance) and set up PHP-FPM and nginx successfully.
My Symfony app works.. until I use the command line to clear the cache. When I do this the /app/logs and app/cache/ folder becomes owned by root and the app can no longer write to it.
I can manually chmod 777 / chown nginx:nginx these files after each cache clear, but there must be a better way?
I've tried using a bash function to su nginx; before it clears the cache, but that doesn't work.
Before cache folder before cache clear:
drwxrwxrwx 11 nginx nginx 4096 Nov 4 13:23 dev
drwxrwxrwx 10 nginx nginx 4096 Nov 4 20:39 prod
And after:
drwxrwxrwx 11 nginx nginx 4096 Nov 4 13:23 dev
drwxr-xr-x 10 root root 4096 Nov 4 20:39 prod
Is this something I can fix in the app, or is there a way of setting up the permissions so they don't become rooted?
Edit: I should also mention I tried:
sudo chmod +a "nginx allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
But the server doesn't recognise +a.
Also tried using:
setfacl -R -m u:nginx:rwx app/cache app/logs
Which doesn't error, but doesn't fix the issue.
sudo -u nginx php app/console cache:clear
Edit:
Can't accept this answer yet but this worked for me:
So I successfully enabled ACL on my mount following the guide here: http://blog.dsyph3r.com/2011/09/symfony2-using-setfacl-for-cache-and.html
For newbies like, me note the label of the drive is (somewhat strangely) "Label=/" in fstab.
Once that was done I used
setfacl -R -m u:nginx:rwx app/cache app/logs
setfacl -dR -m u:nginx:rwx app/cache app/logs
Now I can clear cache at will it seems.
Original (only use if you cannot or will not enabled ACL):
I followed a help page which got me to set umask(0000); in numerous places, namely the app/app*.phps and the app/console script. This seems to have worked, but I'm not sure of the implications.
Leaving question open for non-umask solutions. Looking into activating ACL on my mount, but new to that and it all seems.. strangely named.
Hope you are good. I have Xammp on fedora and changed owner of opp/lampp/htdoc to root. Why I did so because whenever someone creates new folder through sharing, they don't have permission to dynamically create folder or files or to write images. Then I run command
chmod -R 777 /opt/lampp/htdocs
But when system goes to restart then I again need to run this command. So avoid again and again run this command I changed the owner on "opt/lampp/htdocs" and run
chmod -R 777 /opt/lampp/htdocs
Now, whenever server restarts, assigned permissions don't need to be set again and again. That is resolved.
I have an issue, that old directories can be used to write something. But if any network user creates new directory under htdocs, that new directory needs to be changed the permission for it.
previously created, and can use this one directory to run script to create files
drwxrwxrwx 2 root root 4096 2011-06-15 14:09 aaa
Newly created, cannot be used to run a script to create image or to write anything
drwxr-xr-x 2 root root 4096 2011-06-17 15:17 aaaa
drwxr-xr-x this one is really annoying to me for each newly created folder in htdocs :(
Just to let you know that my htdocs user and rights are:
drwxrwxrwx 101 root root 4096 2011-06-17 15:17 htdocs
Why is it so? Can anybody please help me to figure this problem out? I am waiting for quick response anxiously.
First off, you should investigate what permissions you really need - chmodding everything to 777 is a security risk as it will allow any user to write inside of your web root.
However, to address your actual question of the default permissions when a new folder is created by a user, you want to adjust the default "umask" which determines such things.
This question has some information for changing it for the Apache user (if a "network user" is a user creating new files and directories through the httpd process):
Setting the umask of the Apache user
If you need to adjust it for other users or processes, the solution will be similar.
Good luck!
Edit
Since you're on Fedora, try this: (from the question I linked above)
[root ~]$ echo "umask 002" >> /etc/sysconfig/httpd
[root ~]$ service httpd restart
The first command will add that line to the /etc/sysconfig/httpd which is a permanent configuration file, and the second command will make it active.
You are tackling the problem from the wrong side. Restore your apache configuration to use apache.apache as default user/group, and set your samba server to use those credentials when someone write to your document root.
If you are using nfs or another posix compatible filesystem, use chmod g+s to keep all files readable from your apache server.
Try it:
#umask 000
have a good time!!