showing apache (php) errors to the web - apache

I'm looking for a way to display errors that apache generates under
/var/log/apache/error_log
for my colleagues who are working on the same project. The coding language is php.
First I tried to do a simple php readfile script, but since the file is only visible too the root user i was unsuccessful. I do not want to use things like cpanel or kloxo. can anyone help ?

To answer this properly we'd need to know a lot more about your setup.
/var/log/apache/error_log
Kind of implies that this some variant of Unix - but which one?
First I tried to do a simple php readfile script
Does that mean you're trying to make the file available via HTTP or do the relevant users have shell accounts?
If its just the permissions problem you need to solve and it's one of the mainstream Linux variants, then it's probably setup to use logrotate, and the config files for logrotate will be in /etc/logrotate.d/httpd or /etc/logrotate.d/apache so go read the man page for logrotate then change the file to something like.....
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
create 660 apache webdev
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
Here the 'create 660 apache webdev' makes the file owned by apache uid, webdev gid with permission -rw-rw----
That will then take effect for all future log rollovers. You still need to set the permissions on the directory, e.g.
chmod a+rx /var/log/apache
chmod a+rx /var/log
will give everyone read access to the directories
..and change permissions on the current files...
chgrp webdev /var/log/apache/*.log
chmod g+r /var/log/apache/*.log

You have to change error_log's file permissions in order to be able to read it.

Related

rsync daemon and permissions

Problem
I am confused about rsync daemon and permissions. Unfortunately I cannot figure out why I get
rsync: opendir "/." (in share) failed: Permission denied (13) and
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [generator=3.1.2].
Obviously, by searching the web and looking into the manpage of rsync / rsyncd.conf I was not able to solve this issue.
Setup
Here is my /etc/rsyncd.conf owned by root with 644 permissions:
log file = /var/log/rsyncd.log
[share]
comment = data
path = /path/to/data
uid = root
gid = root
read only = false
auth users = syncuser
secrets file = /etc/rsyncd.secrets
Note, /path/to/data is owned by root with 755 permissions (though random user or syncuser is also not working).
Besides, /etc/rsyncd.secrets has 600 permissions and is owned by root (I also tried 400 though same issue)
syncuser:passwd
To start the service (on CentOS7)
sudo systemctl start rsyncd
A first test as a random user on the host machine running the daemon, (also running with sudo or as syncuser has no effect)
rsync user#host::
returns share data showing that the configuration is fine?!
However
rsync user#host::share
leads to the errors mentioned above.
Tries
Playing with chmod (777) and chown (root:root, random user:user, syncuser:syncuser) of /path/to/data was not changing anything. Moreover I varied uid and gid to nobody but also without success.
Running above rsync command on an actual client, from which I want to ultimately copy data to the host is of course also failing.
So what am I missing here? Any hints are of course highly appreciated.
could you check SELinux?
If it is enforced, the directory /path/to/data need to be labeled correctly.
For example,
chcon -R -t public_content_t /path/to/data

Using lsync to sync apache webroot files - running into permission issues

I'm distributing load between two web servers, which means all of the Apache settings and vhosts are pretty much identical, and I wanted to make sure they stay that way by using LSync (or if there's another solution that helps with the problem I'm having, let me know)
So obviously Apache runs as the apache user, and we cant enable root SSH logins, so I created an lsync user that can SSH between the two servers using RSA keys.
And now I'm running into some permissions errors, which is kinda what I expected to happen really. What I'm trying now is I added the lsync user to the apache group, and the apache user to the lsync group... and that seems to work ok, as long as the files are chowned 7 for both the user and the group...
I thought about setting a cron job to chown apache.apache every so often, and maybe even chmod +rwx for the group and user, but I'm sure that would cause some other issues.
I thought about having lsync run as the apache user, but it looks like the apache home directory needs to actually be owned by root.root.. so that would cause issues with the apache user trying to ssh in and read from the .ssh directory.
I couldn't find much about this when I looked on Google... Most people just used the root user for lsync, which is out of the question.
So if anyone has a fix, that would be great! thanks
P.S. I know that I can allow the lsync user to execute specific commands via sudo, if I properly configure the sudoers configuration... is there a way to have it sudo chown apache.apache /var/www && sudo chmod -R u+rwx /var/www or something?
rsync has an option for forcing the permissions of the files it creates on the destination: --chmod=<blah>. lsyncd does not have direct support for this, but can pass-through rsync flags.
Try adding this to your lsyncd configuration:
_extra = {"--chmod=Dug+rwx,Fug+rw"}
That should ensure that directories, D, have read/write/execute permissions for owner and group, and files, F, have read/write permissions for owner and group. Any other permissions should be set as they are on the source server.
If you need the files to be owned by the apache user then you could set up a chown cron job, as you suggest, but you might find that a constantly running script that reads the output from inotifywatch will be more responsive (and mostly idle).
You might consider having the apache user run an rsync daemon. It's little used since tunnelling rsync through ssh is more convenient and more secure, but it might help you side-step this problem.
You need to set up a configuration file, and then simply launch it with rsync --daemon using whatever init system your distro has.
You can then configure your lsynd with target = "rsync://server/path".
If the connection between the servers is local and the network is trusted then you're done, otherwise you should configure the rsync daemon to listen only on 127.0.0.1, and then use an ssh -L port mapping to route the traffic through an encrypted tunnel (the owner of the tunnel is not important).

Allowing Apache on EC2 to run sudo commands via CGI script

I have an Amazon (AMI) Linux EC2 instance running on AWS. I'm create a perl script that will create directories when it is called through a web url (CGI script).
However, because the browser is executing the script, the user apache is running the perl script. Because apache is not allowed to do mkdir command without using sudo none of the directories are being created.
I've modified the scripts permissions to execute (755) via the browser, however none of the mkdir commands work.
I even tried using the sudo command within the perl script, but I have no luck. However, all of the non sudo commands work such as 'cd' etc.
If anyone knows how to resolve this issue I would appreciate it.
I've found the answer through searching.
The first thing you need to do is disable tty for the current user.. my web browser executes anything as the user 'apache' on the server.
So in my /etc/sudoers file i added
Defaults:apache !requiretty
Also i created a list of commands that I want apache to use without requiring the sudo password
Cmnd_Alias APACHE = /bin/mkdir, /bin/rmdir
apache ALL=(ALL) NOPASSWD: APACHE
This allows only certain sudo commands to execute on my web server without requring the password.
NOTE: only open the /etc/sudoers file using the visudo command... DO NOT open it using just regular vim or nano because if you save it and theres an error it will **** your machine up and you may have to create a whole new server because any sudo commands wont execute.
u can specify your editor using visudo.. e.g
EDITOR=nano visudo

permission denied while uploading file to EC2

I have installed apache webserver apache in linux ,I used following code to upload a file, but i get permission denied
scp -i adjmp.pem index.html ec2-user#ec2-50-17-88-33.compute-1.amazonaws.com:/var/www/html/hi
How can i upload a file to EC2 ?
You most likely need to change the filesystem permissions. This is usually done using the chmod command. You may also need to modify file ownership (using the chown command).
If you need help with the exact steps, you can provide the output of the following two commands and I will try to help:
sudo ls -al /var/www/html/hi
id

How can I play a wav sound on the server side using cgi?

How can I run a command from a (bash) CGI script to play a wav sound on the server side?
You can execute your command line audio player as described by nak, but this may not work due to the permissions of the user running Apache. By default Apache is run as www-data:www-data (or apache:apache or www:www on some distros). As a quick fix/test you can set Apache to run as a user that has permissions to access the audio device on the machine by modifying your /etc/apache2/apache2.conf (or /etc/httpd/httpd.conf") file to have:
User USER_THAT_CAN_PLAY_AUDIO
Group USER_THAT_CAN_PLAY_AUDIO
Warning: this is not secure and is not intended to be a permanent solution!
This is how I would do it
#!/bin/sh
echo Content-type: text/plain
echo ""
echo "Server is playing sine.wav!"
aplay -q sine.wav
I stumbled over this old question looking how to solve the same problem: to have my personal Apache webserver warning me when someone makes a specific request (in my case a call for chat without the need to have any IM running).
The solution below is what I use on Slackware 14.1: according to your distro YMMV.
launch visudo
add the line TheUserRunningApache ALL=(ALL) NOPASSWD: /usr/bin/play (TheUserRunningApache is the user name used by your Apache)
In the PHP page you want to play a sound add this line: system ("sudo /usr/bin/play SOUND.WAV");
If you don't want to give access to Apache to the /usr/bin folder, even if limited just to play, you can copy the sox executable (the program used to run /usr/bin/play) elsewhere, but you'll have to modify the last two instructions above accordingly.