I am trying to install a laravel project in google compute engine with "Red Hat Enterprise Linux Server 7".
I followed this blog: http://tecadmin.net/install-laravel-framework-on-centos/
Completed the laravel project download, set up user permission for user "apache" and group "apache". After all this, I am getting error as
Error in exception handler: The stream or file "/var/www/html/project/app/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied in /var/www/html/project/bootstrap/compiled.php:9072
Who ever had the problem earlier, mentions the solution as set proper permission for the log files. I have verified that app/storage folder has correct permissions.
I know I am missing something very simple, but could not get this working.
Any help will be greatly appreciated.
UPDATE:
These are the permissions I have applied:
chown -R apache:apache project
chmod 775 project
chmod 775 project/app/storage
chmod -R 777 project/app/storage
And these are the permissions I can see for the folder:
drwxrwxr-x. 7 apache apache 4096 Dec 23 13:54
drwxrwxr-x. 7 apache apache 84 Dec 23 13:53 storage
-rwxrwxrwx. 1 apache apache 0 Dec 23 14:01 laravel.log
Not able to figure out if this is an issue with RHEL linux 7 issue. I gave up on this after a while and created a VM with centOS 6 which is now working properly. Thanks a lot #ykbks for helping me with this.
Needs to disable SELinux.
~]# cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0
Changing the value of SELINUX to disabled changes the state of SELinux and the name of the policy to be used the next time the system boots.
Related
I'm using ansible to provision my Centos 7 produciton cluster. Unfortunately, execution of below command results with ansible Tiemout and Linux Pluggable Authentication Modules (pam) error conversation failed.
The same ansible command works well, executed against virtual lab mad out of vagrant boxes.
Ansible Command
$ ansible master_server -m yum -a 'name=vim state=installed' -b -K -u lukas -vvvv
123.123.123.123 | FAILED! => {
"msg": "Timeout (7s) waiting for privilege escalation prompt: \u001b[?1h\u001b=\r\r"
}
SSHd Log
# /var/log/secure
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): conversation failed
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): auth could not identify password for [lukas]
I've found the problem. It turned out to be PAM's auth module problem! Let me describe how I got to the solution.
Context:
I set up my machine for debugging - that is I had four terminal windows opened.
1st terminal (local machine): Here, I was executing ansible prduction_server -m yum -a 'name=vim state=installed' -b -K -u username
2nd terminal (production server): Here, I executed journalctl -f (system wide log).
3rd terminal (production server): Here, I executed tail -f /var/log/secure (log for sshd).
4th terminal (production server): Here, I was editing vi /etc/pam.d/sudo file.
Every time, I executed command from 1st terminal I got this errors:
# ansible error - on local machine
Timeout (7s) waiting for privilege escalation prompt error.
# sshd error - on remote machine
pam_unix(sudo:auth): conversation failed
pam_unix(sudo:auth): [username]
I showed my entire setup to my colleague, and he told me that the error had to do something with "PAM". Frankly, It was the first time that I've heard about PAM. So, I had to read this PAM Tutorial.
I figured out, that error relates to auth interface located in /etc/pam.d/sudo module. Diging over the internet, I stambled upon this pam_permit.so module with sufficient controll flag, that fixed my problem!
Solution
Basically, what I added was auth sufficient pam_permit.so line to /etc/pam.d/sudo file. Look at the example below.
$ cat /etc/pam.d/sudo
#%PAM-1.0
# Fixing ssh "auth could not identify password for [username]"
auth sufficient pam_permit.so
# Below is original config
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Conclusion:
I spent 4 days to arrive to this solution. I stumbled upon over a dozens solutions that did not worked for me, starting from "duplicated sudo password in ansible hosts/config file", "ldap specific configuration" to getting advice from always grumpy system admins!
Note:
Since, I'm not expert in PAM, I'm not aware if this fix affects other aspects of the system, so be cautious over blindly copy pasting this code! However, if you are expert on PAM please share with us alternative solutions or input. Thanks!
Assuming the lukas user is a local account, you should look at how the pam_unix.so module is declared in your system-auth pam file. But more information about the user account and pam configuration is necessary for a specific answer.
While adding auth sufficient pam_permit.so is enough to gain access. Using it in anything but the most insecure test environment would not be recommended. From the pam_permit man page:
pam_permit is a PAM module that always permit access. It does nothing
else.
So adding pam_permit.so as sufficient for authentication in this manner will completely bypass the security for all users.
Found myself in the same situation, tearing my hair out. In my case, hidden toward the end of the sudoers file, there was the line:
%sudo ALL=(ALL:ALL) ALL
This undoes authorizations that come before it. If you're not using the sudo group then this line can safely be deleted.
I had this error since upgrading sudo to version 1.9.4 with pacman. I hadn't noticed that pacman had provided a new sudoers file.
I just needed to merge /etc/sudoers.pacnew.
See here for more details: https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave
I know that this doesn't answer the original question (which pertains to a Centos system), but this is the top Google result for the error message, so I thought I'd leave my solution here in case anyone stumbles across this problem coming from an Arch Linux based operating system.
I got the same error when I tried to restart apache2 with sudo service apache2 restart
When logging into root I was able to see the real error lied with the configuration of apache2. Turned out I removed a site's SSL-Certificate files a few months ago but didn't disable the site in apache2. a2dissite did the trick.
I'm trying to setup Apache (httpd) with mod_wsgi to run a single Django site.
(13)Permission denied: httpd: could not open error log file /var/mail/django-error-log.
Unable to open logs
I've already done: chown apache django-error-log to make sure the ownership is set to apache and verified it with ls -l
ls -l
total 0
-rw-r--r--. 1 apache root 0 Jan 10 01:40 django-error-log
Any idea what's causing the permission denied?
Highly possible you have SELinux Enforcing.
Just disable it (SELINUX=disabled) and try again.
1.) vi /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
2.) And then "reboot"
3.-) Try again
You can use "getenforce" command to verify the current status, as follows:
[root#instance-1 selinux]# getenforce
Disabled
[root#instance-1 selinux]#
Regards
So I just recently downloaded Apache server with all of its files (httpd, apr, apr-util, pcre) following the instructions dictated here: http://httpd.apache.org/docs/2.4/install.html
However, after set-up, when I tried to start my Apache server, which is located in my usr/local/bin/, I was prompted with this message:
[allen#allen-lnx ~]$ /usr/local/bin/apachectl start
(13)Permission denied: AH00091: httpd: could not open error log file /usr/local/logs/error_log.
AH00015: Unable to open logs
After some research, I have found that I need to edit my httpd.conf file, which I did so earlier to allow for the correct ServerName and Listen options. However, I am unsure as to how to edit my conf file to allow for access to the "logs" directory.
Notably, the command will run when I use the "sudo" command, but I would prefer to not always use that since it seems like a work around.
Any help would appreciated. Thanks!
Edit: I've actually noticed that I may have two httpd.conf files, which is proving to be a little troublesome. The other one is located in my root /etc/ directory (etc/httpd/conf/httpd.conf). I think my modified question now is... which one should I be keeping? Is the /etc/ version the one that is built in, as indicated by faff's comment below?
Current Solution: I figured I would just accept the fact that I need to use sudo when editing this file since I need to be root. I might change it later so that I'm always running as root, but for now, sudo will suffice.
This looks like an issue with he filesystem permissions. Make sure the /usr/local/logs/ directory exists and is writeable by the user you're running Apache as.
If you don't want to have your logs directory writeable by normal user, you can create the log file:
sudo touch /usr/local/logs/error_log
And then change the owner of the file to the correct user:
sudo chown allen /usr/local/logs/error_log
Assuming you want to run Apache as the user allen.
If you want to change the location of Apache logfile, look for the ErrorLog directive in your httpd.conf file (you will have to add it if it's not there):
ErrorLog path/to/logfile
For everyone that is using SELinux, if you deleted the folder or come across similar problems you may need to do several things.
Re-link the folder with ln -s /var/log/httpd /etc/httpd/logs
By default logs are kept under the var folder but are referenced in the /etc/httpd/logs folder
Apply SELinux security permissions with chcon system_u:object_r:httpd_config_t:s0 /etc/httpd/logs
And of course run everything as admin
Changing SELinux security policy to permissive fixed my problem.
Before fix my SELinux worked with enforced mode:
$ sestatus -v
sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
I changed security policy in SELinux configuration file and in the system.
#/etc/selinux/config
SELINUX=permissive
# In terminal set SELinux to run in permissive mode.
$ setenforce 0
After fix my SELinux worked with enforced mode:
$ sestatus -v
SELinux status: enabled
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
For those who are stuck with the SElinux policies, I was able to do it by creating a custom policy
Basically I wanted to move the /var/log/httpd to my own directory under /r/
So I run the following
semanage fcontext -a -t httpd_sys_content_t "/r/www(/.*)?"
semanage fcontext -a -t httpd_log_t "/r/logs(/.*)?"
restorecon -Rv /z/logs/
restorecon -Rv /z/www/
service httpd restart
# worked
I can't get the openssh server to work on Windows Server 2008. I have it working on two other servers, but one of them just won't work.
I run ssh-host-config, and choose privilege separation. Two users are created sshd and sshd_server.
Then I run net start sshd, and I see this:
The CYGWIN sshd service is starting.
The CYGWIN sshd service could not be started.
The service did not report an error.
Then I run cat /var/log/sshd.log and I see this output:
/etc/sshd_config: No such file or directory
I then check permissions on /etc/sshd_config:
-rw-r--r-- 1 sshd_server root 3344 Sep 7 09:15 /etc/sshd_config
So now, it seems sshd cannot see a file which is there and has the right permissions. Even on windows, that file is owned by sshd_server.
had this happen too .
a Procmon session revealed to me that the sshd service was trying to locate /etc in the root directory c:\etc instead of c:\cygwin\etc.
further investigation showed that sshd was loading an incorrect cygwin1.dll which was living in my system PATH environment variable.
solution was to either to remove the bad cygwin1.dll or remove the "bad" path from the system variables and assigning that path it to user specific environment variables.
afterwards running the sshd daemon under a dedicated user who did not have this "bad "path worked as it should.
thanks mark
The issue
Now, I am a complete n00b on Apache, and I could certainly use some help with my current issue. I have installed the httpd rpm's on 3 different systems (all Advantech computers, 1 Box PC, 1 Advanced TCA blade, 1 Compact PCI blade, and all have RHEL6 installed). I have configured Apache with files used earlier, on other installations. When I issue the command
# service httpd restart
All goes well and I get this output:
Stopping httpd: [ OK ]
Starting httpd: httpd: apr_sockaddr_info_get() failed for <PC_Name>
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[ OK ]
Now, when I try to connect to the machine via Apache, I get the log-in screen asking for the username and password, as you would expect. However, it fails to log-in. When I look at the error_log in /var/log/httpd/, it shows this error message:
[Thu Sep 15 14:24:40 2011] [error] [client 192.168.10.175] (13)Permission denied: Could not open password file: /etc/shadow
[Thu Sep 15 14:24:40 2011] [error] [client 192.168.10.175] PAM: user 'root' - not authenticated: System error
It seems to me that this is either a configuration error, or it has something to do with permissions. Yet I can't seem to find out which. Another interesting fact is, that this only applies to the last two installations(Advanced TCA & Compact PCI), and not the first (Box PC), while all 3 installations are exactly the same.
Additional Info
The way I installed it was install httpd from yum,
# yum install httpd
Next install mod_auth_pam, which is needed by the configuration,
# yum install mod_auth_pam
Then I configured Apache with the files I got from previous installations (which basically is just replacing the configuration files from the standard Apache install), and after that I restarted the Apache service.
For this error "apr_sockaddr_info_get() failed"
You need to properly set your hostname.
hostname actual-non-expired-domain-name.com
Don't forget to set the name in your httpd.conf and in /etc/hosts as well.
I have been able to solve this by setting SELinux to allow Apache requests. This is done by issuing the following command:
semanage permissive -a http_t
Semanage is a utility from the policycoreutils-python package. This should come with the installation medium.