httpd ERROR

[pascal]

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

[jimp]

[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)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 httpdSo 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?

[pascal]

cool

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

Thanks

[jimp]

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].

[pascal]

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

[jimp]

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.

[IWorx-Chris]

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

[jimp]

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.

[IWorx-Chris]

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

[Justec]

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

[jimp]

Glad I could help! This community has already offered me so much...it's the least I can do... ;)

[pascal]

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

[jimp]

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

[pascal]

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

[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

[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 :)

if there is an error later I'll know why


Pascal

[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

[jimp]

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?

[pascal]

Hello,

Yes Jiimp I have it, but it is for the share no signed SSL certificate ?!?
I think it applies only to all vhosts whom not have a certificate installed on their domain. Ok it is the default ssl config for all vhost but I think that if you define a new vhost for your domaine/IP for the port 443 it's this one which applyed and not the default one !??!

I promise if I remove this there is a huge difference (only for my perl script)

Pascal

[jimp]

Oops, you are right. That directive is inside the default virtual host, which is not much use in the case of per-domain certificates. But I have ~8 certificates installed (unique domains and IP's) and none of them appear to be (significantly) slower than their non-SSL counterparts. They are all signed certificates, though, and none are using CGI.

The ssl.conf file says:
# StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only. It sounds like your CGI was upset about the missing environment variables. Thanks for the tip, though. It looks like my per-domain SSL's are missing that option.

[jimp]

Pascal,

I have confirmed my sites are suffering from this problem, too. It just took a site with ~50 images on the page to really, really, really point it out. Once I made the changes below, largely based off your posts (especially your Apache website quote), SSL pages are now operating at nearly the same speed as non-SSL ones. Previously, I assumed the SSL-tax was just the penalty of SSL, but adding "downgrade-1.0 force-response-1.0" cured those sites, too.

Thanks for your help and willingness to post all that info, even though no one was asking for help. I'll file a bug report.

Change:
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown To:
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/home/{USER}/{DOMAIN}/html/cgi-bin/">
SSLOptions +StdEnvVars
</Directory>

[pascal]

Pleased to know it helps you. It's a bug indeed, and I hope iworx wil lchange the default config of vhosts ssl :)

In fact it is exactly what you are saying , on large site with a lot of images without this it is really really slow.

Personnaly I"ve fone this


# SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
SetEnvIf User-Agent ".*MSIE.*" \
ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

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


I've not enter the nokeepalive as I've done tests and even with MSIE it works great like this

Pascal

[jimp]

Bug report: http://www.interworx.com/forums/showthread.php?t=1359

The Apache docs say the nokeepalive is necessary for some versions of IE. Too bad it does not say which ones... :confused: If they are talking about IE 5.5, I would leave it on, but IE 4.0 and below is a different story. So I guess I am going to leave that one in.

[pascal]

I forgot to tell you that I also done this for iworx 2443 port.

Indeed I had a lot of users whom complained for iworx was very very slow. (see one of my other post about this)

And since I've done this also in Interworx everybody tell us it is much more quick :)

I've change the file
/home/interworx/etc/httpd/httpd-custom.conf

and I've just replaced exiting

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown


by

SetEnvIf User-Agent ".*MSIE.*" \
ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

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


exactly as we done for our default vhost.

We should ask for iworx to upgrade the SSL config for virtualhost both for our vhosts and their SSL config file

Pascal
Pascal

[pascal]

Bug report: http://www.interworx.com/forums/showthread.php?t=1359

The Apache docs say the nokeepalive is necessary for some versions of IE. Too bad it does not say which ones... :confused: If they are talking about IE 5.5, I would leave it on, but IE 4.0 and below is a different story. So I guess I am going to leave that one in.

I've done test with MSIE 5.5 and 6.0 and there is NO pbm : same speed. I think it was for 4.0....

With Opera and Mozilla : no pbm

Pascal

[pascal]

About your
<Directory "/home/{USER}/{DOMAIN}/html/cgi-bin/">
SSLOptions +StdEnvVars
</Directory>

It is not suffisant and won't work for all cases. In fact the actual iworx config for CGI allow to run a CGI evrywhere in the documentroot (which is not so good and I don't understand why they do this like this.) : See one of my post (lol and one more) stayed without answer : http://www.interworx.com/forums/showthread.php?t=1332

You should prefer add all your handler in the <Files ~ "\.(cgi|shtml|phtml|php3?|php|inc)$"> for example by adding .pl or every else

Pascal

[jimp]

Thanks for the :2443 tip. I just tried it and it worked nicely.

I see what you mean about the CGI issue. And I responded to your other thread. ;)

[bow9487]

help me, im sorry people, i no i shoulded be posting this ya, but that is the problem, how do i post, i got a messive problem and i need help,, but i cant see anywere to do so, please help me

[jimp]

help me, im sorry people, i no i shoulded be posting this ya, but that is the problem, how do i post, i got a messive problem and i need help,, but i cant see anywere to do so, please help meNavigate to the correct forum and then click the "New Thread" button above the forum listing.

[bow9487]

thanks m8 just done my thread now:)