I just upgraded from Apache 2.2 -> 2.4 Took a little bit of work to get PHP and SSL running again, but now i have one problem i can't figure out... CORS
I have in my virtual host
Header set Access-Control-Allow-Origin "*"
but i keep getting an error saying
Request header field Content-Type is not allowed by Access-Control-Allow-Headers.
I can't seem to find anything that is preventing this from working. Clearly i am missing something.
Your VirtualHost is probably no longer being used due to your distros package creating/restoring a default virtual host that covers your customized one up.
Sometimes this happens if your systems own notion of its hostname is what you use for ServerName in your custom vhost.
I'd suggest setting a dummy ServerName in the default vhost created by your distros configuration, or removing it entirely.
You can review a summary of your vhost with apachectl -S
I figured it out. It was similar issue, when updating the package the new .conf file disabled .htaccess directives.
Related
I'm working on setting up SearXNG using apache....ugh....btw, if anybody has any good instructions on this (besides the developer's website) I'd be very grateful.
In any case, after I configure the .conf file and restart apache2, it fails with errors saying this proxy module or that is an invalid command. From all the forums I've looked at, the suggestion was to a2enmod the modules it is complaining about, plus a few others. I've done that but apache keeps complaining about them.
I've not found a thread yet that speaks of this particular issue. Any ideas?
Thanks
I have what is almost certainly a newbie question. I expected to find the issue while writing this question, but I am still stuck.
I want to change the DocumentRoot for apache, but I keep getting the error message "DocumentRoot must be a directory".
Situation:
The code is running in a virtual VMWare machine 4.0.4 build-744019
The version of linux is Scientific Linux release 6.4 (Carbon)
The version of apache is Apache/2.2.15 (Unix) (this is a yum install with nothing
special)
In the httpd.conf
DocumentRoot "/home/stave/www"
When I restart, I get the message
Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory
Steps taken so far:
I ensured that the directory exists:
ls -asl /home/stave
4 drwxrwxrwx. 2 stave stave 4096 Feb 9 09:08 www
It even has a file in it "index.html", so I am very sure that the directory exists
I considered that it might be a priviledges issue so (this is a virtual development machine isolated from the internet, and I am troubleshooting so I am not too worried about security) as you can see I set the priviledges to 777.
I even changed the user that apache is running as (and confirmed that the change worked with ps) to stave to ensure that priviledges just shouldn't be an issue.
Stackoverflow
There are a few stack overflow answers, but most of them say "read the error message. It is saying that the directory doesn't actually exist". Others implied that there might a trailing slash at the end which would be bad.
Other websites
The most useful I found was this that advised
You probably got "DocumentRoot must be a directory" error even it is really a directory because of SELinux extensions. Run system-config-securitylevel (or redhat-config-securitylevel) to disable SELinux for httpd or give SELinux permissions to that
directory:
chcon -R -h -t httpd_sys_content_t /path/to/directory*
My version of linux isn't Security Enhanced Linux, so without understanding I tried it anyway: no effect.
Current situation
I have run out of ideas to try, so any diagnostic questions or advice would be greatly appreciated
The link you posted under "Other websites" highlights the root cause of your problem, which is Selinux.
Unless the server is part of a super secure environment, I would simply disable Selinux.
On RedHat / CentOS / Scientific Linux this can easily be done by editing /etc/sysconfig/selinux - find the parameter "selinux" and change the option "enforcing" to "disabled" as per the extract below:
# 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
It is probably wise to reboot the server after making this change.
You shouldn't just disable SELinux.
You need to set httpd_enable_homedirs to on.
yum -y install policycoreutils-python
setsebool -P httpd_enable_homedirs on
I ran into this problem today as well and it was because I moved my DocumentRoot from /var/www/html to /srv/www/html. As part of our security policies, we do not have the option to just Disable SELinux.
SO my fix, as I discovered was to change the SELinux file context for /srv to match /var. A compromise yes, but still better than disabling it altogether. Other than that... I made sure /srv/www and all subfolders had the httpd_sys_content_t to match the folders under /var/www and all is well now.
This is basically the same answer as David's, but just a little clearer, http serving directory has wrong SELinux security context set.
The full explanation to fix this is here, http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server-(or-13-10-Ubuntu-LAMP)
My issue was that I was housing my websites inside a different directory than the documentroot path of /var/www/, so I had to follow the 3rd option in the link above to correct. I set the same file context of my /websites/ directory to match that of the /var/www/. What was odd is earlier versions of CentOS 5.5 must not have had the SELinux installed/enabled, because my other servers had no issue with this and when running the ls -Z at the command prompt displayed those folders as 'unlabeled'.
I'm running CentOS 6.5 on AWS from the official marketplace minimal install. So when I ran the ls -Z command on my folders I saw exactly what the link above shows as a possible issue.
Running the chcon command fixed my issue!
Just replace html/ with the directory you want to use!
chcon -Rv --type=httpd_sys_content_t html/
chcon -Rv --user=system_u html/
On a side note I also had to disable iptables to get the routing working, the defaults were serving up blank pages.
service iptables stop
Hope that helps anyone with the same issue.
Envirnoment:
Linux - root file system on a SSD
DocumentRoot on a HDD and mounted via fstab
Restarting apache2 after boot - no problem
Seems to be a timing problem that apache is started before the fstab mounts are completed.
Workaround:
Define the DocumentRoot directory on the root file system with the correct owner, group and permissions. The directory may be empty.
Firstly, there is no reason at all to turn off selinux to fix this issue, just change the selinux file context.
Secondly, when changing selinux file context, you should to set up a permanent rule for that path, such that when new files are copied in and/or replace existing files, restorecon actually fixes the problem, instead of breaking it, as is the case when you only use chcon.
Thus, for a symlink'ed DocumentRoot (let's give the actual full path to the directory as '/media/myDoc' for this example), run these two commands:
semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"
restorecon -R /media/myDoc
Note, the full path is required when using semanage this way. You will not only fix the problem, but it won't break again when you run restorecon (or auto-relabel) in the future.
I've been running nagios for about two years, but recently this problem started appearing with one of my services.
I'm getting
CRITICAL - Socket timeout after 10 seconds
for a check_http -H my.host.com -f follow -u /abc/def check, which used to work fine. No other services are reporting this problem. The remote site is up and healthy, and I can do a wget http://my.host.com/abc/def from the nagios server, and it downloads the response just fine. Also, doing a check_http -H my.host.com -f follow works just fine, i.e. it's only when I use the -u argument that things break. I also tried passing it a different user agent string, no difference. I tried increasing the timeout, no luck. I tried with -v, but all it get is:
GET /abc/def HTTP/1.0
User-Agent: check_http/v1861 (nagios-plugins 1.4.11)
Connection: close
Host: my.host.com
CRITICAL - Socket timeout after 10 seconds
... which does not tell me what's going wrong.
Any ideas how I could resolve this?
Thanks!
Try using the -N option of check_http.
I ran into similar problems, and in my case the web server didn't terminate the connection after sending the response (https was working, http wasn't). check_http tries to read from the open socket until the server closes the connection. If that doesn't happen then the timeout occurs.
The -N option tells check_http to receive only the header, but not the content of the page / document.
I tracked my issue down to an issue with the security providers configured in the most recent version of OpenSUSE.
From summary of other web pages it appears to be an issue with an attempt to use TLSv2 protocol which does not appear to work correctly, or is missing something in the default configurations to allow it to work.
To overcome the problem I commented out the security provider in question from the JRE security configuration file.
#security.provider.10=sun.security.pkcs11.SunPKCS11
The security.provider. value may be different in your configuration, but essentially the SunPKCS11 provider is at issue.
This configuration is normally found in
$JAVA_HOME/lib/security/java.security
of the JRE that you are using.
Fixed with this url in nrpe.cfg: (on Deb 6.0 Squeeze using nagios-nrpe-server)
command[check_http]=/usr/lib/nagios/plugins/check_http -H localhost -p 8080 -N -u /login?from=%2F
For whoever is interested, I stumbled in this problem too and the problem ended up being in mod_itk on the web server.
A patch is available, even if it seems it's not included in the current CentOS or Debian packages:
https://lists.err.no/pipermail/mpm-itk/2015-September/000925.html
In my case /etc/postfix/main.cf file was not good configured.
My mailserverrelay was not defined and was also very restrictive.
I should to add:
relayhost = mailrelay.ext.example.com
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
I am logging Apache2 errors in a custom location (i.e. not /var/log/apache2/error.log) using the following line in httpd.conf:
ErrorLog /custom/path/to/error.log
However, when I use mod_wsgi to serve a django application, the stderr output from that still gets dumped to /var/log/apache2/error.log.
My apache2 errors get dumped in the custom location, but my python errors still get dumped in the default location. How do I get everything to dump in the custom location?
To get what you want you need to be using mod_wsgi daemon mode. Plus, the WSGIDaemonProcess/WSGIProcessGroup directives need to be specified within the VirtualHost where you have specified the ErrorLog directive. Finally you need to be using mod_wsgi 3.0+ and not the now quite old mod_wsgi 2.0+ that some Linux distributions still provide.
Satisfy those conditions and you still can't get it going then post the problem to the mod_wsgi mailing list.
I have been trying to install Ushahidi platform for weeks but without any luck. I recently started over using Ushahidi latest release ushahidi-Ushahidi_Web-2.0.1-140-g0991172.zip and extracted it to folder ushahidi under my root.
I am using godaddy Linux server. I have tried both the manual and wizard to setup Ushahidi. In all cases, after installation, I get the same error when I try to access admin page. The error reads:
No input file specified.
I have tried tried installing using the wizard and the manual process. My PHP version is as required.
Any help will be appreciated. I need it to work so I can move on and customize it. Very disappointing such a good open source tool has poor installation guides!
Thanks.
Sting
there are a few things that can trip up following the installation.
Make sure that:
mod_rewrite is turned on in apache "a2enmod rewrite"
AllowOverride All is set in your apache config for your site (/etc/apache2/sites-available/default)
your .htaccess file points to the correct webroot