httpd ERROR

Hello

I have looked at my /var/log/httpd/error_log files and I have some errors.

In fact I have a huge number of errors (2 every mn) of

[error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache' f or writing (store) [error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache’ f
or scanning
[error] (13)Permission denied: Cannot open SSLSessionCache DBM file `/etc/httpd/logs/ssl_scache’ f
or reading (fetch)

a lot of

[Sun May 08 15:34:22 2005] [error] [client 84.195.170.116] File does not exist: /var/www/htdocs/themes, referer: https://pro-
gamingleagues.com:2443/siteworx/cgi-bin/fileman?fdo=cmd_show;t=common/;page=editor_editor.html;

some of

[notice] child pid 19219 exit signal Segmentation fault (11)

and few of

[warn] RSA server certificate CommonName (CN) `localhost.localdomain’ does NOT match server name!?

I never seen before the 2 first one. Do you think I should open a supprot ticket or it is normal with the new httpd version ?

Also I have an account with CGI disabled. I have checked the domin.conf file and the -EXECcgi is there.

But I can see using top that this account use some PERL instances. How is it possible ?

And finally, I have commented the user_dir option in /etc/httpd/conf/httpd.conf and, of course, restarted httpd but I still can access to website by using the http://ip/~account shortcut !!!
How can it be possible ?

Thanks for your help

Pascal

::::: EDITED 05/10/2005 :::: ADD new INFORMATIONS ::::::

I’ve read somewhere that there is some pbm with mod_ssl that eat a lot of CPU exactly like I have since few days.

http://www.forbiddenweb.org/viewtopic.php?id=27118

You should try using:

SSLMutex default
SSLSessionCache shmcb:…

instead of the default settings, this will probably avoid both the
issues with the mutex at graceful restart and the issues with the dbm
session cache.

We’ve had a couple of reports recently of sites using mod_ssl seeing
processes eating CPU, but nobody has yet taken the time to get a
backtrace out of such a process. Add, for example:

CoreDumpDirectory /tmp

to your config, then send SIGSEGV to core dump a spinning process when
you see one, or attach to it with “gdb /path/to/httpd <pid>”, and enter:

backtrace full

in gdb to get a backtrace.

joe

Is there something relating to all my error logs in httpd

[error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache' f or writing (store) [error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache’ f
or scanning
[error] (13)Permission denied: Cannot open SSLSessionCache DBM file `/etc/httpd/logs/ssl_scache’ f
or reading (fetch)

Also why does it try to look at a file in /etc/httpd/logs/ ? it looks like it is not a vhost pbm but somewhere in the httpd.conf file isn’t it ?

And why when I comment the user_dir option in the httpd the shortcut still work ?

Do you think I should open an interworx support ticket ?

Thanks

I’ve read somewhere that there is some pbm with mod_ssl that eat a lot of CPU exactly like I have since few days.

http://www.forbiddenweb.org/viewtopic.php?id=27118

You should try using:

SSLMutex default
SSLSessionCache shmcb:…

instead of the default settings, this will probably avoid both the
issues with the mutex at graceful restart and the issues with the dbm
session cache.

We’ve had a couple of reports recently of sites using mod_ssl seeing
processes eating CPU, but nobody has yet taken the time to get a
backtrace out of such a process. Add, for example:

CoreDumpDirectory /tmp

to your config, then send SIGSEGV to core dump a spinning process when
you see one, or attach to it with “gdb /path/to/httpd <pid>”, and enter:

backtrace full

in gdb to get a backtrace.

joe

Is there something relating to all my error logs in httpd

[error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache' f or writing (store) [error] (13)Permission denied: Cannot open SSLSessionCache DBM file /etc/httpd/logs/ssl_scache’ f
or scanning
[error] (13)Permission denied: Cannot open SSLSessionCache DBM file `/etc/httpd/logs/ssl_scache’ f
or reading (fetch)

Is an interworx member think I should open a support ticket ?

I found a lot of these in my logs, too, not to mention my SSL sites were loading significantly slower than the non-SSL versions. Here is what I did to eliminate the error messages:

I found /etc/httpd/logs points to /var/log/httpd, which had these permissions:

drwx------ 2 root root httpd
So I changed the owner/group to apache:apache and the problem stopped. Additionally the SSL enabled pages are loading at normal speed again. (I guess SSL is now properly caching something that makes it more efficient.)

Security experts: Did I just introduce a security risk with this fix?

cool

But do you mean you have changed the permission to only the symlink
chown apache:apache /etc/httpd/logs

Thanks

No, I changed the permissions on /var/log/httpd.

Changing the permissions of a symlink itself only determines who can break the link (delete it). The permissions of the file or directory the symlink points to is used for all other operations (i.e., read/write/execute).

I left /etc/httpd/logs [root:root] pointing to /var/log/httpd [apache:apache].

Ok it’s exactly what I did.

And since the ssl_scache has apache iworx as owner it should be ok

Let’s see if there is still some errors or not

Thanks

pascal

The SSL slowdown problem returned…

I did some upgrades recently (up to InterWorx-CP v2.0) and the SSL speed issue returned. All non-SSL pages loaded quickly, but the SSL ones were very, very slow again.

I checked on my fix described above. Sure enough, the owner:group was root:root again.

This time I left it owned as root:root and set the permissions to 0744. (This was so a running PHP script couldn’t potentially delete the log files, all though two of the files in that directory are owned by apache.)

Is this a problem with the iworx httpd RPM? The moment these two files:

-rw-r–r-- 1 apache iworx 0 Jun 17 04:21 ssl_scache.dir
-rw-r–r-- 1 apache iworx 1024 Jun 17 15:49 ssl_scache.pag
become unwritable, the SSL pages become painfully slow.

Security experts: Did I just introduce a security risk with this fix?

No, 755 perms on /var/log/httpd as long as it’s root:root is fine.

I’ve fixed our httpd RPM which was doing the 700 perms on that dir. I don’t see the same slowdown you mention but 755 won’t cause any other problems given the file perms in that dir and i’ll change the RPM to do 711 in the future.

Chris

Oops…

Oops, I used 0755, not 0744. 0711 will work, too, and I suppose restricting non-root users from listing the directory would be slightly more secure (even though those filenames are easy to guess :)).

Another distro I use (Gentoo) uses 0755. Might 0711 break any user-land utilities that need to query that directory for the logs? This won’t affect me, but I’m just curious really.

Thanks for the fix, btw.

711 should be fine. The perms on the files are pretty restrictive as is so the dir at 711 is fine. It’s not doing much over 755 but I just can’t type 755 for some reason :). although this does get me into 700 trouble as we’ve seen here.

Chris

I thought my SSL pages seemed slower the last month or so. Thanks for the quick fix Jimp!

Glad I could help! This community has already offered me so much…it’s the least I can do… :wink:

Hello,

I also have very slow ssl request. I use a signed certificate on one subdomain (secure).

The main script in this secure dir is a perl script. Using this same script with no ssl is fine, with ssl is really to slow.

Could it be this perm problem ?

As there is suexec the script is running under the uid/gid account.

I have these perms in /var/log/httpd(/)

httpd perm


drwx--x--x    2 root     root         4096 Apr 21 01:06 httpd

And in httpd/


-rw-r--r--    1 root     root         1166 Apr 20 23:47 ssl_request_log
-rw-r--r--    1 root     root         1814 Apr 15 18:05 ssl_request_log.1
-rw-r--r--    1 root     root         1607 Apr  9 00:25 ssl_request_log.2
-rw-r--r--    1 root     root          869 Apr  1 16:28 ssl_request_log.3
-rw-r--r--    1 root     root         4979 Mar 23 12:41 ssl_request_log.4
-rw-r--r--    1 apache   iworx        4096 Apr 20 23:50 ssl_scache.dir
-rw-r--r--    1 apache   iworx        3072 Apr 21 01:03 ssl_scache.pag

Any idea ?

Thanks

Pascal

That all looks okay to me. Does your Apache SSL error log list any errors or notices?

Hi jimp

No nothing relevant in ssl_request_log

For example for today there is only these entries. It’s not my IP nor the good time.

 
[20/Apr/2006:02:58:43 +0200] 194.72.238.62 TLSv1 DHE-RSA-AES256-SHA "HEAD / HTTP/1.0" -
[20/Apr/2006:23:41:56 +0200] 194.72.238.62 TLSv1 DHE-RSA-AES256-SHA "HEAD / HTTP/1.0" -
[20/Apr/2006:23:47:28 +0200] 194.72.238.62 TLSv1 DHE-RSA-AES256-SHA "HEAD / HTTP/1.0" -

Pascal

Hello,

It’s look like it is depending from which internet explorer you use.

With MSIE it looks like as on a SSL request there is no file cached (like images)
With Mozilla it seems there is a cache of the images.

So when we us mozilla the images are loaded most quicly and with MSIE it is very very slow

Is it somethink related to

SetEnvIf User-Agent “.MSIE.” nokeepalive ssl-unclean-shutdown

Thanks

Pascal

Ok I’m sure now the problem is about image caching and the

SetEnvIf User-Agent “.MSIE.” nokeepalive ssl-unclean-shutdown

In my perl script I cqn define the images url.
If I define it with HTTP://mysite/imagesfolder then the display is very fast. Of course I have a warning telling me that some elements are not secured.

If I define it with HTTPS://mysite/imagesfolder then the display is again very very slow.

And finally if I comment this line

SetEnvIf User-Agent “.MSIE.” nokeepalive ssl-unclean-shutdown

Then the display is no more slow. Even if I choose HTTPS as a location of my images.

From Apache web site there is this

Why do I get I/O errors when connecting via HTTPS to an Apache+mod_ssl server with Microsoft Internet Explorer (MSIE)?

The first reason is that the SSL implementation in some MSIE versions has some subtle bugs related to the HTTP keep-alive facility and the SSL close notify alerts on socket connection close. Additionally the interaction between SSL and HTTP/1.1 features are problematic in some MSIE versions. You can work around these problems by forcing Apache not to use HTTP/1.1, keep-alive connections or send the SSL close notify messages to MSIE clients. This can be done by using the following directive in your SSL-aware virtual host section:

SetEnvIf User-Agent “.MSIE.
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

Further, some MSIE versions have problems with particular ciphers. Unfortunately, it is not possible to implement a MSIE-specific workaround for this, because the ciphers are needed as early as the SSL handshake phase. So a MSIE-specific SetEnvIf won’t solve these problems. Instead, you will have to make more drastic adjustments to the global parameters. Before you decide to do this, make sure your clients really have problems. If not, do not make these changes - they will affect all your clients, MSIE or otherwise.

So this tweak is for some MSIE versions which cause pbms. I’ve tested with 2 versions of MSIE and as I didn’t have any SSL revelant pbm and as it is very very much more faster I decided to cmment this.
Now all my MSIE client have access to their helpdesk at a normal rate :slight_smile:

if there is an error later I’ll know why

Pascal

Hello,

Just to let you know I have added this in my vhost conf file and now my CGI scripts with SSL are incerdibly more fast, really really fastest !!!

<Files ~ “.(cgi|shtml|phtml|php3?|php|inc)$”>
SSLOptions +StdEnvVars
</Files>

Just in case somebody have slow SSL, maybe try this

Pascal

Pascal,

I found this in /etc/httpd/conf.d/ssl.conf:

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

Do you have that file?