[AOLSERVER] CGI Memory Leak - AOLserver 3.x - *IMPORTANT*
Problem Report on nscgi Memory Leak:
!!! THIS IS A MAJOR BUG FOR ANYONE RUNNING CGI SCRIPTS IN AOLSERVER 3.x
!!!
This bug exists in released versions of AOLserver 3.x inclusive of
AOLserver 3.5.1 all the way back to AOLserver 3.0. Any past or current
reports of AOLserver 3.x growing in size over time should be
re-examined with this bug in mind.
The leak has been fixed in the CVS tree for AOLserver 3 (3.5 branch).
AOLserver 4.x's nscgi module is *not* affected by this problem.
If you wish to fix the problem in your current version of AOLserver
3.x, edit the aolserver/nscgi/nscgi.c file, find the CgiExec function,
and delete the call to Ns_DStringInit(dsPtr);. Then recompile your
server. Here is what it looks like in context:
/*
* Set all the CGI specified variables.
*/
Ns_DStringInit(dsPtr);
SetUpdate(cgiPtr-env, SCRIPT_NAME, cgiPtr-name);
if (cgiPtr-pathinfo != NULL *cgiPtr-pathinfo != '\0') {
Ns_DString tmp;
...
Notes:
The leak occurred in the CgiExec function of nscgi.c. The nscgi.c file
defines a function called CgiDs which does an Ns_DStringPop to obtain a
dstring, and then uses that dstring's 'addr' member to maintain a
linked-list of dstrings that nscgi is currently using. At the end of
the CGI process, the CgiFree function is called to walk through that
linked-list and perform an Ns_DStringPush on each of the dstrings to
put them back into the thread's local dstring pool.
The memory leak was caused when Ns_DStringInit was called and passed a
dstring obtained by a previous call to CgiDs. The Ns_DStringInit call
broke the linked-lisk because it NULL'd the addr member of the dstring,
which had been pointing to the next dstring in the linked-list. The
effect was that every invocation of of a CGI script was causing
dstrings to be left dangling in memory.
This problem *does not* exist in AOLserver 4.x because nscgi no longer
uses Ns_DString's addr member to maintain the linked list.
/s.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
Re: [AOLSERVER] [ aolserver-Feature Requests-746579 ] Server instance controller process
This is a very useful feature that would be very helpful for new users especially. I think it's so good, I would prefer to see it integrated such that you trigger it with a command line flag to nsd at start time. Many of you use other tools to perform watchdog activities, which is great. But others in the community who aren't as outspoken as the experts on this list might be running one-shot web sites where this feature would reduce the complexity of monitoring and restarting AOLserver should it fail. My vote is to put it in. /s. On Saturday, May 31, 2003, at 12:07 PM, Zoran Vasiljevic wrote: On Saturday 31 May 2003 18:43, you wrote: How many lines of code and how many man-hours will it take to implement in C? How long will it take to review all the code to ensure you've neither introduced any new bugs or otherwise broken already existing code? We have it running for about 3 years already. No need to develop anything since it is already there. It does not change anything related to the main server so it needs no extra testing. It is just an C-equivalent of your shell-script and it alows you to: nsd -s -t config.tcl and forget about it. It logs worker start/stop/restart in system logfile so its easy to track. Also, as a stand-alone script or program, folks running even older AOLserver 3.3.x could take advantage of it, rather than being forced to upgrade to either 4.x or 3.5.x ... or were you planning to backport this change all the way back? Ah Seeing all those responses... I think I'll just keep our own patched nsd copy and leave all as-is. It took me more time to write all those anwers, than to write the small C-routine we're talking about. If everybody is happy with shell/daemontools/whatever there is no reason for me to do anything here, obviously. Apparently, we have a very different usage pattern than most of the other users... Cheers, Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
[AOLSERVER] webdav.tcl
As per the conversation during the AOLserver chat today, I've posted the webdav.tcl module to my site's front page: http://scottg.net. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] help with AOLserver basics for newbie
Hi Jeremy, you should find most of what you need at http://www.aolserver.com. Look along the left edge for links to documentation etc. You'll specifically want to look at ADPs (AOLserver Dynamic Pages), which you can find here: http://aolserver.com/docs/devel/tcl/adp-overview.html /s. On Monday, Sep 8, 2003, at 09:45 US/Eastern, Jeremy Schneider wrote: I recently learned about this AOLserver listserv. We have a website hosted by AOLserver (AOLserver/2.3.3). Recently I needed to ensure that web pages served from a particular directory had an Expires: header that made the pages expire 5 minutes after being served. Our Internet Services person told me that I can put % ns_setexpires 300 % at the top of the page to make that happen. That is a handy thing to know. (I don't know if they did any other magic to make it so that that directive would work.) I have no experience creating pages specifically for AOLserver -- I am a real newbie with AOLserver. I tried to find a place in the documentation that described that capability (% ns_setexpires 300 % ), and found some pages that had the string ns_setexpires in it, but nothing that clearly described how to insert a command like that with the %, 300, and % into a web page to achieve my desired results. Could someone please put me on the path in the documentation that describes this? Thanks very much, Jeremy Schneider -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl ServerPeerVerify ?
Peer verify means the server will request the client to send a client SSL cert. You will rarely ever use this option, and if you're not sure whether you need it, then you definitely don't. Most clients (i.e. users with browsers) don't have their own personal certs. You might use it to gain access to an admin port if you gave your admins their own certs. /s. On Monday, Sep 22, 2003, at 16:42 US/Eastern, Andrew Piskorski wrote: What exactly do nsopenssl's ns_param ServerPeerVerify and other ralted *verify* options do? Scott's online docs are helpful but they don't seem to describe this, and a look through the 2.1a sources didn't make it clear to me either. http://www.scottg.net/webtools/aolserver/modules/nsopenssl/ configuration/ -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
Scott, would you be so kind to enlighten me?
Certainly. Important parts of my test config are at the bottom of this
message. Here's how it works:
At start time, nsopenssl reads the config sections for SSL contexts and
SSL drivers. Each SSL context and each SSL driver has a unique name
within that virtual server. You can reuse the same names in a different
virtual server, but not a good idea for readability perhaps.
SSL contexts define the characteristics of SSL instances you want to
create; they're essentially templates. You can have any number of
templates. An SSL template can be associated with an SSL driver, an
nsopenssl-created client or an nsopenssl-created server. Some confusion
exists about these last two. nsopenssl works in two modes: local and
nsd-driven. An SSL driver is tied to a core nsd connection, and all
bytes are piped through the AOLserver HTTP processing engine.
nsopenssl-created clients and servers are local to the nsopenssl module
and are not associated with the core server at all. Using the nsopenssl
Tcl API you can create incoming or outgoing SSL connections without the
core server's HTTP engine being involved. If there's still confusion
about the difference, let me know and I'll try to find a better way to
explain it.
An SSL driver can listen on one and only one port. But you can have
multiple drivers defined for a virtual server. Each driver most be
associated with a single SSL context. When a connection comes in on a
port that an SSL driver is listening in, it uses the SSL context it's
associated with to generate an SSL instance, which contains the info
about what ciphers are allowed etc.
In the config below I have two contexts and two drivers. One driver
I've labeled as a user access point, the other as an admin access point.
The main goals of this release are to be virtual-server compliant, to
decouple SSL contexts from SSL drivers and the nsopenssl-created
connections, and to ensure that you only need to load one copy of an
nsopenssl module to handle any number of virtual servers and ports.
Digest all this; more later if you need it. The config stuff at my site
is out of date for this new release. I'm moving my site to a new hoster
where I can run AOLserver.
/s.
config:
set vs1_servernamevs1
set vs1_serverdescVirtual Server 1
set vs1_httpport 7000
set vs1_hostname 127.0.0.1
set vs1_address 127.0.0.1
set vs1_pageroot ${homedir}/servers/${vs1_servername}/pages
# Global nsopenssl settings
ns_section ns/server/module/nsopenssl
ns_param RandomFile /some/file
ns_param SeedBytes 1024
...normal AOLserver stuff here...
#
# nsopenssl (HTTPS)
#
# Virtual Server specific nsopenssl configurations
# SSL contexts. Each SSL context is intended to be a complete definition
# of an SSL instance. An SSL context may be used by multiple drivers,
# sockservers and sockclients.
ns_section ns/server/${vs1_servername}/module/nsopenssl/sslcontexts
ns_param vs1_users_ctxSSL context used for regular user access
ns_param vs1_admins_ctx SSL context used for administrator
access
ns_section
ns/server/${vs1_servername}/module/nsopenssl/sslcontext/vs1_users_ctx
ns_param Role server
#ns_param ModuleDir /path/to/dir
ns_param CertFile server-cert.crt
ns_param KeyFile server-cert.key
#ns_param CADir serverca
#ns_param CAFileserverca.pem
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite
ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace true
ns_param SessionCache true
ns_param SessionCacheSize 128
ns_param SessionCacheTimeout 300
ns_section
ns/server/${vs1_servername}/module/nsopenssl/sslcontext/vs1_admins_ctx
ns_param Role server
#ns_param ModuleDir /path/to/dir
ns_param CertFile server-cert.crt
ns_param KeyFile server-cert.key
ns_param CADir serverca
ns_param CAFileserverca.pem
#ns_param Protocols All
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite
ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace true
ns_param SessionCache true
ns_param SessionCacheSize 128
ns_param SessionCacheTimeout 300
# SSL drivers. Each driver defines a port and a named SSL context to
associate
# with it.
ns_section ns/server/${vs1_servername}/module/nsopenssl/ssldrivers
ns_param vs1_users_drvDriver for vs1 regular user access
ns_param vs1_admins_drv Driver for vs1 administrator access
ns_section
ns/server/${vs1_servername}/module/nsopenssl/ssldriver/vs1_users_drv
ns_param sslcontextvs1_users_ctx
ns_param port 7001
ns_param hostname 127.0.0.1
ns_param address
Re: [AOLSERVER] Tcl read Unknown error 635?
ns_conn close doesn't clean up the SSL part of the connection so it's possible these errors are generated after ns_conn close, which might leave the channel in existence but in an unknown state. reading/writing to the channel after ns_conn close would mean bytes reach the channel but the channel doesn't have anywhere to send them. I've added this to my todo list. /s. On Monday, September 29, 2003, at 02:16 PM, Jeff Hobbs wrote: On Mon, Sep 29, 2003 at 10:05:36AM -0700, Jeff Hobbs wrote: It would be interesting to know if it does go away, but note that the Unknown error 635 is being returned directly by the system error function 'strerror' from some error that occured while reading on the pipe. Any idea where I'd find the code that's actually issuing the 635 error? Interestingly, if I use ns_httpsget to fetch an AOLserver page which simply does ns_conn close, I seem to get some semi-random very large integer error code, e.g.: error reading openssl6: Unknown error 1105130496 error reading openssl6: Unknown error 1157638968 error reading openssl6: Unknown error 1157639048 which seems odd... Something is either set in the channel's statePtr, or DoReadChars is returning an error. You can hunt this down more in Tcl_ReadChars in tclIO.c. There are several possible causes. Perhaps if you looked at $::errorCode at that error point, you might get more info. It may be though that whatever is controlling the ssl stuff (if this is done as a layered transform on the channel) is incorrectly setting the error value. Jeff Hobbs The Tcl Guy Senior Developer http://www.ActiveState.com/ Tcl Support and Productivity Solutions -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
Thanks for the feedback. I've decided to split nsopenssl into two modules. The nsopenssl module will now be entirely focused on AOLserver's comm-driven connections. The nshttps module will focus on creating and using SSL connections using a Tcl API. I've made the decision to split this effort in two for the following reasons: 1. The nsopenssl codebase is becoming unwieldy to develop and maintain. Having three types of SSL connections, one of which is the normal comm-driven type, makes the codebase rather complex. 2. The nsopenssl 2.x Tcl API supports Tcl commands that work with comm-driven conns, but that do not work with SSL conns generated by the nsopenssl Tcl API itself (I'm talking about ns_openssl_sockopen, ns_openssl_sockcallback, etc.). To support non-comm-driven connections I have to use thread-local storage to keep track of SSL conn structures, making the code even more complicated. 3. The https.tcl module is a hack. Based on recent discussions I've been watching here, it has problems, some of which originate with nsopenssl.so itself. https.tcl will be replaced with nshttps.so. 4. Most people who run nsopenssl only want the ability to drive AOLserver comm-driven connections anyway, and aren't interested in creating their own SSL servers and clients using nsopenssl's Tcl API. 5. The configuration file is becoming too complex in order to support SSL contexts separately from SSL drivers and connections. 6. Having nsopenssl focus on the comm-driven connections will allow me to focus on its performance. The performance of non-comm-driven connections is not a major issue since there are not as many of these types of connections, and there isn't a user sitting at the other end of them; usually you use these to connect to another SSL host. 7. Virtual servers in AOLserver 4.0 adds a lot more complexity to the code -- virtual server state must be kept to ensure that one virtual server cannot access another virtual server's structures and data. Having separate code bases will allow me to focus on the security of the comm-driven nsopenssl module much more effectively. 8. The non-comm-driven SSL connections rely on Tcl channels so that you can use puts, gets and friends on them. The channel code adds complexity to nsopenssl that is not required for the comm-driven connections. 9. Testing has become a pain. Every change requires that I test both the comm-driven connection capability and the non-comm-driven capabilities. While much of this testing can be automated, it is important that the comm-driven capability is extensively tested on its own. The only downside to separating the two modules is that a significant portion of the code will be duplicated. At this point I don't really care about that and will revisit whether I want to have both modules generated from (some) common files, or if I want to turn the common portions of both into a loadable library on its own after we have some experience with the modules in operation. In any case, both modules will retain their separate identities. For the confused, a comm-driven connection is one that is actually serviced by AOLserver core, over which I overlay the SSL portion. Non-comm-driven connections are those where the sockets and SSL overlays are both generated and maintained by the nsopenssl module itself. I have already gutted nsopenssl and I will be releasing the slimmed down, tighter version of nsopenssl first. nshttps will follow. /s. On Monday, September 29, 2003, at 09:28 PM, Bart Teeuwisse wrote: Thanks for explaining the nsopenssl config section Scott. Let me give you some feedback of what I've found so far. Nsopenssl appears to perform well for the most part. However, nsopenssl writes several empty error messages to the log. Can't tell what they are related to. More importantly though making a client connection using ns_httpsopen results in the following error: [29/Sep/2003:18:14:58][20762.65541][-conn:demo::0] Error: : nsopenssl: error creating sslconn-ssl structure The server subsequently hangs and doesn't respond to requests anymore. /Bart -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] How to use nsopenssl 3.x?
On Tuesday, September 30, 2003, at 04:11 AM, Andrew Piskorski wrote: I realize this must be awfully late in the coding to bring up, but: Would it greatly simplify or speed up things to release a first version of nsopenssl which works with AOLserver 4.0, but does NOT support virtual servers in any way? Virtual server support is already in the code and works for comm-driven connections. Since we didn't have any built in virtual server support at all in AOLserver 3.x, I imagine there are many people converting from 3.x to 4.0 who would be perfectly happy to have NO virtual server support for the time being, but who need a working nsopenssl in order to switch to 4.0. I myself fall into this group. AOLserver 4.0 not only supports virtual servers, every server you create *is* a virtual server, even if you run just one server. Thanks for the feedback. I've decided to split nsopenssl into two modules. The nsopenssl module will now be entirely focused on AOLserver's comm-driven connections. The nshttps module will focus on creating and using SSL connections using a Tcl API. That sounds good. But do you plan to make this happen for the release of AOLserver 4.0 (whenver that might be), or at some later date, or? For the AOLserver 4.0 release. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] aolserver 3.5.10
If you have a sourceforge account, do this: cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/aolserver co -r aolserver_v35_bp aolserver but change 'scottg' to your username. Otherwise, do this: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/aolserver login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/aolserver co -r aolserver_v35_bp aolserver Both will get you the latest copy of the 3.5 branch. If you want 3.5 beta 10, change the -r tag to aolserver_v35_b10. /s. On Tuesday, September 30, 2003, at 08:55 PM, Brad Chick wrote: I've seen references to aolserver 3.5.10, but can only seem to find 3.5.6. What are the key differences and how does one obtain the newer version? Thanks -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] uploading pc v. unix text files on 3.5.6
The text beginning at Content-Dis... should be on the next line by itself. If the browser hasn't changed, but the server has, then there is something on the server side that's at fault. How are you processing the incoming files? I.e. show us the code that touches file uploads in your ADP or Tcl lib. /s. On Thursday, October 2, 2003, at 01:50 PM, brad chick wrote: Recently, we upgraded to 3.5.6 from 3.3.1. Unfortunately, our file uploads broke. Now, aolserver doesn't upload pc files properly. These files have what seems be browser crud appended to them: -7d32da2b27043a Content-Disposition: form-data; name=x 20 -7d32da2b27043a Content-Disposition: form- data; name=y 11 -7d32da2b27043a-- On the other hand, unix files don't have this issue when uploaded through a browser to aolserver. Thanks -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] webdav.tcl
It's in SourceForge CVS, but you can still get the copy from http://scottg.net/downloads/webdav.tcl /s. On Thursday, October 9, 2003, at 06:32 PM, Mark Aufflick wrote: I can't seem to find scottg's webdav.tcl - can someone point me to where it lives now? Nathan Folkman wrote: we should get it committed to sf cvs so people can start updating the code in one place. Scott Goodwin wrote on 8/21/03, 3:38 PM: As per the conversation during the AOLserver chat today, I've posted the webdav.tcl module to my site's front page: http://scottg.net. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- Mark Aufflick e: [EMAIL PROTECTED] w: www.pumptheory.com (business) w: mark.aufflick.com (personal) p: +61 438 700 647 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] webdav.tcl
Sorry, that should read http://scottg.net/download/webdav.tcl /s. On Thursday, October 9, 2003, at 09:18 PM, Scott Goodwin wrote: It's in SourceForge CVS, but you can still get the copy from http://scottg.net/downloads/webdav.tcl /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_openssl mystery problem
This kind of problem is notoriously difficult to reproduce and will require an extensive code review on my part to identify where the problem may be occurring. It is possible that I am doing/not doing something in the code that is contributing to this. I'll see if I can track down the problem, but it may have to wait a few weeks as I have other work in front of this. /s. On Nov 12, 2003, at 10:39 PM, William Scott Jordan wrote: Hello everybody! I'm having some trouble with ns_openssl. At least I suspect that it's an ns_openssl issue, since I've only had complaints about this problem on secure pages. Here's what's happening: At random intervals, I'm getting generic unable to load page errors. Like I said, It only happens on secure pages, and it seems to only occur with IE (but I'm not 100% sure on that). The part that has me confused is that it doesn't leave any message at all in the logs. Even the ns_log log doesn't show an attempted hit. Naturally, I can't reproduce the problem, and when it does happen, hitting reload doesn't cause it to happen a second time. Based on the traffic to the site and the number of complaints, I'm guessing that it's happening once out of every 100 or so page views. I've tried ns_openssl 1.1c and 2.1a and the problem occurs with both. As for the rest of the system, I'm running OpenSSL v0.9.7c on Redhat 7.3 with AOLserver 3.5.6, and my configuration for ns_openssl looks like this: # NSD-driven connections: ns_param ServerPort $httpsport ns_param ServerHostname $host ns_param ServerAddress $address ns_param ServerCertFile certfile.pem ns_param ServerKeyFile keyfile.pem ns_param ServerProtocols SSLv2, SSLv3, TLSv1 ns_param ServerCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP ns_param ServerSessionCache true ns_param ServerSessionCacheID1 ns_param ServerSessionCacheSize 512 ns_param ServerSessionCacheTimeout 300 ns_param ServerPeerVerifyfalse ns_param ServerPeerVerifyDepth 3 ns_param ServerCADir ca ns_param ServerCAFileca.pem ns_param ServerTrace false # For listening and accepting SSL connections via Tcl/C API: ns_param SockServerCertFile certfile.pem ns_param SockServerKeyFile keyfile.pem ns_param SockServerProtocols SSLv2, SSLv3, TLSv1 ns_param SockServerCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP ns_param SockServerSessionCache true ns_param SockServerSessionCacheID2 ns_param SockServerSessionCacheSize 512 ns_param SockServerSessionCacheTimeout 300 ns_param SockServerPeerVerifyfalse ns_param SockServerPeerVerifyDepth 3 ns_param SockServerCADir internal_ca ns_param SockServerCAFileinternal_ca.pem ns_param SockServerTrace false Any insight on this would be greatly appreciated. Thanks, Scott -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_openssl mystery problem
I should go read my own ChangeLogs :) Yes, keepalive in the server should be disabled by setting it to 0. It's an upcoming todo item to make nsopenssl work with the core server's keepalive mechanism but until then this should stop you from experiencing this problem. MSIE is fairly notorious for being buggy w/r to SSL. /s. On Nov 13, 2003, at 9:23 AM, Piotr Szuca wrote: I had the same problem about one year ago. I know three solutions: (1) disable keepalive (unfortunatelly it disables keepalive also for connections handled by nssock driver); (2) add Connection: close output header to every page handled by nsopenssl driver (but it slows down every connection handled by nsopenssl module); (3) use nsopenssl tagged 2_2beta6. The problem arise when AS is closing connection after timeout, but the socket at the client side is not closed yet (this is a combination of two timeouts; it depends on the keepalive parameter and FIN_WAIT timeout on the client side). Comment from ChangeLog of nsopenssl: ssl.c: in NsOpenSSLDestroyConn, if socket is valid, we shut it down before freeing the ccPtr datastructures. Apparently, the BIO_free_all causes two bytes to be sent over the socket that confuses Win32 clients. Best regards, Piotr Szuca This may be similar to a problem I had a while ago. If I remember correctly the symptoms; if you went to a secure page, and sat there for a while, then went to another page, you would get a page not found error. What I had to do was to change the keepalivetimeout parameter to 0 in the nsd.tcl file. This disables that timeout. I believe it may have been Scott Goodwin who mentioned to try that. I think my original timeout was like 2 minutes, so to recreate it I would go to a page and sit there for two minutes, and then try to navigate to another. I could get the page not found every time. After changing it to 0, the problem went away. I also think it was somehow related to the version of the browser, perhaps Internet Explorer not handling keep-alive's correctly. Vince -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] Greenpeace Message
Can the person from Greenpeace who directly emailed me yesterday about nsopenssl please resend your message. I did receive it but I simply cannot find it in my inbox, deleted items or any other folder. Very strange. thanks, /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] nsopenssl 3.0 beta 10
nsopenssl 3.0 beta 10 is available on http://scottg.net. Kick the tires. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] nsopenssl 3.0 beta 10 and OpenACS
Forgot to mention that you'll have to get around the fact that ServerPort is no longer a valid name in the config -- OpenACS will have an issue with that. Since you can now have multiple drivers per virtual server, and drivers for each virtual server, you'll have to figure out a way for OpenACS to determine which driver port number it really wants from the config file. Sorry... /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsd and memory leaks
Almost -- you need the -r flag to identify the branch: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/aolserver login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/aolserver \ co -r aolserver_v35_bp aolserver /s. On Jan 8, 2004, at 6:16 PM, John Shafto wrote: Thanks Scott, Yes, I am running some small cgi stuff, so that is likely it. I didn't see a tarball for v3.5.9 on the sourceforge site, and not being much of a manual CVSer, not sure how I would checkout v35bp. Would it be: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/aolserver co aolserver_v35_bp ? -- Untied we stand, fettered we fall. - Original Message - From: Scott Goodwin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 08, 2004 15:37 Subject: Re: [AOLSERVER] nsd and memory leaks No, you're not being paranoid. Are you using nscgi and running CGI scripts? If so, then you're running into this problem (from the ChangeLog): 2003-04-04 Scott S. Goodwin [EMAIL PROTECTED] * nscgi/nscgi.c: (bug) Ns_DStringInit called in CgiExec was destroying the linked list used to maintain the list of dstrings in use by the module, resulting in a memory leak for every cgi script run. You can get AOLserver 3.5.9 or later (better yet, go grab the latest CVS copy on the v35bp branch), or go into nscgi.c and remove the line that reads: Ns_DStringInit(dsPtr); from the CgiExec function, and recompile. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] nsopenssl beta 12
I should check the return address before I send. Ah well... beta 12 is on scottg.net. SSL processing is a lot cleaner and appears to be faster subjectively. C.R. Oldham had trouble compiling on RH 9; kerberos headers were needed as the OpenSSL library that ships with RH 9 has kerberos support compiled in. If you run into this issue, add this to your CFLAGS += line: -I/usr/kerberos/include This fix will be in the next release. Kick the tires and report any flats. /s. On Jan 19, 2004, at 3:00 PM, Scott Goodwin wrote: Attached is beta 12. Please test to see if your images issue is fixed. I don't have your Kerberos makefile changes included in this beta, but they are now in the CVS copy. thanks, /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. nsopenssl-3.0beta12.tar.gz -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl: sockclient: SERVER's CERT is NOT VALID message
Why are you using the same file for both your Certificates and your list of CA Certificates to validate incoming certificates with? When a client passes you their certificate, nsopenssl uses the CA certificates in the CAFile to validate that client certificate. Based on what I see below, you're using your own certificate as if it were a CA certificate, which means you'll never be able to validate any certificates. SockServerCertFile = /usr/local/www/service463/etc/certs/dekka.crt.pem SockServerKeyFile = /usr/local/www/service463/etc/certs/dekka.key.pem SockServerCAFile = /usr/local/www/service463/etc/certs/dekka.crt.pem SockClientCertFile = /usr/local/www/service463/etc/certs/dekka.crt.pem SockClientKeyFile = /usr/local/www/service463/etc/certs/dekka.key.pem SockClientCAFile = /usr/local/www/service463/etc/certs/dekka.crt.pem Secondly, nsopenssl does not abort a connection because of invalid certs -- it just logs them. Your response to the invalid cert is your application's responsibility. The reason is that you might want to return a useful error page to the user or application on the other end; if you barf on the SSL handshake, the user gets whatever error page the browser generates because no content ever passes between the two. Based on your output here: 20/Jan/2004:12:26:49][93990.135948288][-conn1-] Notice: nsopenssl: sockclient: SERVER's CERT is NOT VALID [20/Jan/2004:12:26:51][93990.135948288][-conn1-] Notice: nsopenssl: trace: sockclient: SSL negotiation finished successfully; alert type = warning; alert desc = close notify [20/Jan/2004:12:26:51][93990.135948288][-conn1-] Notice: nsopenssl: trace: sockclient: SSL negotiation finished successfully; alert type = warning; alert desc = close notify [20/Jan/2004:12:26:51][93990.135948288][-conn1-] Error: Ns_PgExec: result status: 7 message: ERROR: ExecAppend: Fail to add null value in not null attribute transaction_id [20/Jan/2004:12:26:51][93990.135948288][-conn1-] Error: Wasn't able to do insert into ezic_gateway_result_log for transaction_id ; error was Database operation dml failed The SSL handshake completes successfully, meaning that you have established a good SSL connection. Your problem is the database operation. Without seeing the schema and code, can't really say much about that. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl: sockclient: SERVER's CERT is NOT VALID message
Use the CAFile param -- ignore the CADir param. Simply take all the CA certificates you have that you want to use to validate peer certificates with and concatenate them together into one file. The CA certificates have to be in PEM format. You only use them when you have PeerVerify set and you actually want to validate the peer's certificate(s). I probably don't have anything in the current docs about how to configure this yet. /s. On Jan 20, 2004, at 4:43 PM, Torben Brosten wrote: Thanks, Scott. Why are you using the same file for both your Certificates and your list of CA Certificates to validate incoming certificates with? This variation of the configuration is the most recent, and most disparate (pun intended). =) I cannot find docs on how to configure the openssl (*CAFile and *CADir) parameters (usually leaving their values as CA/CA.pem). Is there a section in the docs somewhere that relates to this? Are these only used with peer-to-peer server connections that require a valid CA? Torben When a client passes you their certificate, nsopenssl uses the CA certificates in the CAFile to validate that client certificate. Based on what I see below, you're using your own certificate as if it were a CA certificate, which means you'll never be able to validate any certificates. SockServerCertFile = /usr/local/www/service463/etc/certs/dekka.crt.pem SockServerKeyFile = /usr/local/www/service463/etc/certs/dekka.key.pem SockServerCAFile = /usr/local/www/service463/etc/certs/dekka.crt.pem SockClientCertFile = /usr/local/www/service463/etc/certs/dekka.crt.pem SockClientKeyFile = /usr/local/www/service463/etc/certs/dekka.key.pem SockClientCAFile = /usr/local/www/service463/etc/certs/dekka.crt.pem Secondly, nsopenssl does not abort a connection because of invalid certs -- it just logs them. Your response to the invalid cert is your application's responsibility. The reason is that you might want to return a useful error page to the user or application on the other end; if you barf on the SSL handshake, the user gets whatever error page the browser generates because no content ever passes between the two. ... The SSL handshake completes successfully, meaning that you have established a good SSL connection. Your problem is the database operation. Without seeing the schema and code, can't really say much about that. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] ANNOUNCE: nsoracle 2.7 released
nsoracle 2.7 is now available on SourceForge in the file downloads area. Please look at the ChangeLog for more info. Much thanks to Jeremy Collins, who did all the work. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Trouble compiling oracle driver 2.6 for RH Linux 3ES and Oracle 9i
On Feb 10, 2004, at 10:36 AM, [EMAIL PROTECTED] wrote: Also, Jeff Davis of the OpenACS crew has been de facto maintainer of the driver - do you plan to talk to him before moving forward? There haven't been any defacto maintainers since Jeremy and Jeff stepped up to be co-maintainers of nsoracle quite a while back. They've both agreed just now that they're going to continue in that role. If that info didn't make it to the list earlier, probably my fault. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Trouble compiling oracle driver 2.6 for RH Linux 3ES and Oracle 9i
Jeremy, Jeff, would it be possible to create a regression test suite that exercises the functionality? It could include a simple set of SQL files to load into the db and then run the tests against. /s. On Feb 10, 2004, at 1:02 PM, [EMAIL PROTECTED] wrote: On Feb 10, 2004, at 9:36 AM, [EMAIL PROTECTED] wrote: I really didn't plan on changing the ns_db interface if that is what you are getting at. OK, yes, that's mostly what I'm getting at. Also, Jeff Davis of the OpenACS crew has been de facto maintainer of the driver - do you plan to talk to him before moving forward? We've not made many changes in either the Oracle or Postgres driver the past couple of years or more because they meet our needs and AFAIK the needs of others. Huh, well its meets our needs too but that doesn't mean it cannot get better. One of our *major* needs is for rock-solid reliability ... the more features that are added, the higher the risk that we lose some of that. So let's keep this in mind as we add features ... -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl eating cpu?
Sorry I haven't responded -- very busy on a work project. Essentially what's happening is the core driver keeps calling nsopenssl's read function even when there's nothing ready to be read yet. The infinite loop isn't really infinite because the connection is still alive, but the client hasn't sent anything for us to read yet. In the case of Mozilla, it appears that when the cert warning pops up, the client doesn't send anything to the server until the user takes action, (that's why it happens in the SSL handshake and not later) which could be a while, but the server core still tries to repeatedly read bytes anyway. This makes sense from a performance aspect: if you're serving a small number of bytes (single HTML pages) to thousands of sites, connections will be short and you'll want to free up the conn to serve other clients as quickly as possible. This model breaks with SSL and maybe in non-SSL conns if the client is really, really slow to respond, but only for servers with with lots of idle time. Let's assume you have 100 connections per second coming in, and one of the clients is really slow. That single client won't take 100% of the server CPU because the SSL read call returns immediately so the core can service other requests. The other requests will take their slice of time and eventually another read call will be issued to nsopenssl. Remember that a box under this much load won't be very useful for other processing chores anyway, so if it has idle cycles, why not try to perform a read on that slow socket and see if there's something there yet; nsd is going to be hogging the CPU in any case. If you have 1 or 2 conns per second, and other processing to do on your system, it's a different story. One slow client on such a system can potentially take up all the idle CPU cycles on your system, making anything else you're doing move very slowly. Take this with a grain of salt; this is pure speculation at this point. I'll be analyzing the core server to see if I can fix this cleanly in there; if not, it's probably time to look at supporting multiple communication modules in the core, not in the old 3.x way of doing it, but more along the lines of allowing an nssock or nsopenssl module request a particular comm model for it's driver(s) so that nssock can use the aggressive read, while nsopenssl could request a more sedate model. This may be a mutually exclusive thing however: if nssock uses aggressive reads and nsopenssl uses a more sedate comm model, nssock could still chew up CPU with a slow client. Between now and then, I'll get a beta 14 up with a timeout on reads, so that if an nsopenssl conn has failed every read over the past 3 seconds, it'll close the conn. I'll see if I can have that up this weekend. /s. On Feb 26, 2004, at 5:12 PM, Jamie Rasmussen wrote: We see nsopenssl eating the CPU too - the cause seems to be an infinite loop in NsOpenSSLConnHandshake. You can see it if you use Netscape/Mozilla and your domain name doesn't match the certificate. It also seems to happen when the domain name matches but you close the browser window during the handshake. (I haven't had the chance to confirm what error that triggers.) Scott has been looking into this, and thought that a solution could require changes to the core because of the aggressive read-ahead in AOLserver 4.x. As a temporary measure, he is also considering adding a timer to the conn that would exit the loop if no data has been read over the specified period. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Problems with Verisign certificate with nsopenssl
When I worked at DoD I placed their root CA cert first, then the intermediate CAs after, all concatenated into one file that I then pointed to with ServerCAFile -- this worked fine. Ensure you don't have any corruption of the file, as might happen if it has DOS-style line endings. /s. On Feb 27, 2004, at 2:13 PM, Matthew Ragan wrote: As I'm sure a number of people are aware, Verisign's intermediate CA that they were using to sign their certificates has expired, and their fix is to have the server send out an updated intermediate certificate as part of the certificate chain during the SSL negotiation. We have attempted to do this using AOLserver 3.4 and nsopenssl 2.1b-beta1, but have so far been unsuccessful with anything that we've tried, which has included the following: * setting the Verisign intermediate cert by appending it to the cert file, as it says should work in the comments in init.c in the nsopenssl source * setting the intermediate cert by specifying it as the option to the ServerCAFile directive (similar to Verisign's instructions for how to fix Apache) * putting the hashed intermediate cert into the directory specified by the ServerCADir directive I have searched for information on how to do this with AOLserver with no luck whatsoever. Has anyone else successfully gotten this to work? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AS4.1, timeout waiting for connection
Occurs when client doesn't send data before driver's recvwait value has expired. Probably innocuous, specifically if keepalive is set. /s. On Feb 26, 2004, at 10:39 PM, Dossy wrote: Is there any reason why seeing something like this in my server log should cause me to be suspicious: [26/Feb/2004:22:25:31][11912.11436039][-conn:panoptic.com::693] Notice: exiting: timeout waiting for connection Looks like it's benign in NsConnThread ... but I wonder what it actually implies. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl eating cpu?
I've fixed the problem and will have beta 14 online once I'm able to connect to sourceforge to commit the changes. AOLserver core code is fine. Problem was I needed to wait on the socket if the socket was still valid but had no bytes ready. /s. On Feb 27, 2004, at 1:11 PM, Scott Goodwin wrote: Sorry I haven't responded -- very busy on a work project. Essentially what's happening is the core driver keeps calling nsopenssl's read function even when there's nothing ready to be read yet. The infinite loop isn't really infinite because the connection is still alive, but the client hasn't sent anything for us to read yet. In the case of Mozilla, it appears that when the cert warning pops up, the client doesn't send anything to the server until the user takes action, (that's why it happens in the SSL handshake and not later) which could be a while, but the server core still tries to repeatedly read bytes anyway. This makes sense from a performance aspect: if you're serving a small number of bytes (single HTML pages) to thousands of sites, connections will be short and you'll want to free up the conn to serve other clients as quickly as possible. This model breaks with SSL and maybe in non-SSL conns if the client is really, really slow to respond, but only for servers with with lots of idle time. Let's assume you have 100 connections per second coming in, and one of the clients is really slow. That single client won't take 100% of the server CPU because the SSL read call returns immediately so the core can service other requests. The other requests will take their slice of time and eventually another read call will be issued to nsopenssl. Remember that a box under this much load won't be very useful for other processing chores anyway, so if it has idle cycles, why not try to perform a read on that slow socket and see if there's something there yet; nsd is going to be hogging the CPU in any case. If you have 1 or 2 conns per second, and other processing to do on your system, it's a different story. One slow client on such a system can potentially take up all the idle CPU cycles on your system, making anything else you're doing move very slowly. Take this with a grain of salt; this is pure speculation at this point. I'll be analyzing the core server to see if I can fix this cleanly in there; if not, it's probably time to look at supporting multiple communication modules in the core, not in the old 3.x way of doing it, but more along the lines of allowing an nssock or nsopenssl module request a particular comm model for it's driver(s) so that nssock can use the aggressive read, while nsopenssl could request a more sedate model. This may be a mutually exclusive thing however: if nssock uses aggressive reads and nsopenssl uses a more sedate comm model, nssock could still chew up CPU with a slow client. Between now and then, I'll get a beta 14 up with a timeout on reads, so that if an nsopenssl conn has failed every read over the past 3 seconds, it'll close the conn. I'll see if I can have that up this weekend. /s. On Feb 26, 2004, at 5:12 PM, Jamie Rasmussen wrote: We see nsopenssl eating the CPU too - the cause seems to be an infinite loop in NsOpenSSLConnHandshake. You can see it if you use Netscape/Mozilla and your domain name doesn't match the certificate. It also seems to happen when the domain name matches but you close the browser window during the handshake. (I haven't had the chance to confirm what error that triggers.) Scott has been looking into this, and thought that a solution could require changes to the core because of the aggressive read-ahead in AOLserver 4.x. As a temporary measure, he is also considering adding a timer to the conn that would exit the loop if no data has been read over the specified period. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] SourceForge CVS access
I'm unable to connect to SF via CVS to checkin or checkout code. Can someone try to get something from AOLserver CVS area using their login mode (i.e. don't use anonymous pserver access) and post here if they can get to it? thanks, /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SourceForge CVS access
Problem solved; changed my env set up last week and CVS_RSH stopped being exported. thanks, /s. On Feb 29, 2004, at 7:22 AM, Dossy wrote: On 2004.02.28, Scott Goodwin [EMAIL PROTECTED] wrote: I'm unable to connect to SF via CVS to checkin or checkout code. Can someone try to get something from AOLserver CVS area using their login mode (i.e. don't use anonymous pserver access) and post here if they can get to it? $ cat CVS/Root :ext:[EMAIL PROTECTED]:/cvsroot/aolserver $ cvs up cvs update: Updating . cvs update: Updating compat cvs update: Updating doc cvs update: Updating include cvs update: Updating nscgi cvs update: Updating nscp ... Working for me. What are you using as your $CVSROOT? Did you recently generate a new SSH key and forget to exchange it with SF via their web interface? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl eating cpu?
I've committed and tagged v3_0beta17 and it's up at scottg.net. This should resolve problems where slow or non-responsive clients cause nsopenssl to soak up all your CPU. Report any odd behavior to me; in particular, look for SSL_ERROR_* messages in your log files. If you see any, send me copies of the messages with brief description of what (you think) was going on at the time (i.e. Connection from MSIE...etc.). /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Generating UUID/GUIDs
Mac OS X also comes with uuidgen, which probably means the other BSDs
do as well. The code seems straightforward enough to turn it into a
loadable module.
I'm using a simple random sequence of characters as a session id for
visitors:
set chars
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
set chars_len [string length $chars]
set uid
for { set i 0 } { $i 64 } { incr i } {
append uid [string index $chars [expr int($chars_len * rand())]]
}
I think I stole this from Dossy's nssession module; it should suffice
for uniquely identifying a session over a reasonable period of time. If
this isn't fast enough, you can always pre-generate a bunch of them and
stick them in an nsv.
/s.
On Mar 25, 2004, at 3:40 PM, Dave Bauer wrote:
Has anyone had the need to generate UUID/GUIDs as described here
http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/
draft-leach-uuids-guids-01.txt
One option is to use the uuidgen program that is installed on linux at
least. I am not sure that would always be available.
Are there any other options for AOLserver or Tcl?
Dave
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] calling aolserver tcl command outside of aolserver
Right now you have two choices that I'm aware of: run AOLserver, or replicate whatever part of its Tcl API you need to test with. For example, I have several access control procs that work with IP addresses, usernames and so on. I want regression tests on these to be run after any changes to the server or our codebase to ensure the ACL code is still working the way we expect against a known data set. To do this I can create a straight Tcl version of ns_conn that simply returns the test info I tell it to. I can then source this fake ns_conn and my ACL .tcl file, then make calls to my ACL procs and validate the results. Trying to perform this test with the running server is actually more difficult because ns_conn is going to return the real information. There are ways to get around this for testing purposes, but the hurdle gets higher as you want more tests against more parts of your code. To test ns_httpget you could take the http.tcl file, recreate any ns_sock*, ns_config and other AOLserver procs in Tcl, then use these to run your tests against in straight Tcl. /s. On Mar 23, 2004, at 1:09 AM, Wei Shi wrote: Does anybody know how to call an aolserver tcl command, like ns_httpget without running aolserver? What I am trying to do here is to test and integrate these commands with my other applications before putting them into a package on aolserver. I tried load command in tcl but failed. Has anybody done this before? Thanks. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Bug in nsd/driver.c SockRead()
Not sure this still applies. This code section has changed
significantly in the main branch and maxpost has been replaced by
maxinput, or so it appears. Might still want to file it a as a bug on
SF as Zoran suggested (with the right AOLserver version it affects) so
we do have a record of it.
/s.
On Mar 30, 2004, at 11:33 AM, Zoran Vasiljevic wrote:
On Tuesday 30 March 2004 18:09, you wrote:
I think this bit here where it checks length 0 length maxpost
should almost certainly be || rather than .
/*
* Check for end of headers.
*/
if (e == s) {
reqPtr-coff = reqPtr-roff;
s = Ns_SetIGet(reqPtr-headers, content-length);
if (s != NULL) {
reqPtr-length = atoi(s);
if (reqPtr-length 0
reqPtr-length
sockPtr-drvPtr-servPtr-limits.maxpost) { return SOCK_ERROR;
}
}
} else { ...
--
Jeff Davis http://xarg.net mailto:[EMAIL PROTECTED]
Care to post a bug-report in SF so it does not slip
under the carpet?
Cheers,
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] Anyone noticing weirdness with MSIE 6.0 and HTTPS requests?
Here's the pertinent text from Microsoft: http://www.microsoft.com/technet/security/bulletin/MS04-004.mspx Why am I getting errors when attempting to access certain SSL protected Web Sites? After installing the Internet Explorer 6.0 SP1 version of this update, there may be intermittent failures of POST requests to SSL protected sites. This may cause some users to receive an HTTP 500 (Internal server error) while attempting to access certain Web Sites. Microsoft is aware of this issue and has released an update. Information on obtaining this update may be found in the Knowledge Base Article 831167. This update will be included in future Cumulative Security Updates for Internet Explorer. The fix is here and must be applied to MSIE: http://support.microsoft.com/default.aspx?kbid=831167 I wish MS had an automated regression test suite to run before they released updates and new versions -- it would probably cut down a lot of these kinds of problems, and reduce Windows TCO for those who use their stuff (which is all of us). Ah well. /s. On Apr 13, 2004, at 8:55 AM, Greg McGuire wrote: I can certainly corroborate this; much of our customer service is done using SSL, and they use IE6 (mostly). In the past month I've gotten many complaints about this. Finding nothing amiss with AOLserver, I could only suggest that they switch to Mozilla. Is this an AOLserver / IE6 interaction, or are people seeing this using other web servers as well? Regards, Greg On Apr 12, 2004, at 4:00 PM, Ron Emerick wrote: We are noticing that maybe 1 out of 20 HTTPS requests from our clients using MSIE 6.0 are failing. Further digging seems to suggest that the data that should be POSTed with the request isn't (i.e. content-length: 0). It seems that this is related to a MSIE Explorer patch Q832894. Thanks, Ron Emerick -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Anyone noticing weirdness with MSIE 6.0 and HTTPS requests?
You might try registering a proc for POST that checks the content-length. If content-length is 0 or it doesn't match the size of the content itself, you could generate an error page that pointed the user off to the patch and that describes the issue. You could also give them the option to re-POST the content. You might even find a way to get the POST to be retried using redirects etc., but I'm not sure that's doable and it sounds rather messy. You could register the proc to run before your POST handling routine, or you could implement this capability within your POST-handling proc itself. /s. On Apr 13, 2004, at 9:44 AM, Ron Emerick wrote: Thanks. I applied that update and based on preliminary testing seemed to resolve the problem. The problem now is that I dealing with external users so I can't apply the patch to their system. So I'm looking for ways to handle. I was wondering if there is an http status code so that the browser would resend the request. Or I could display an error page that suggest the user update their browser with 831167. Any ideas on how to handle for external users would be welcome. Thanks, Ron Emerick On Tue, 13 Apr 2004 09:39:04 -0400, Scott Goodwin [EMAIL PROTECTED] wrote: Here's the pertinent text from Microsoft: http://www.microsoft.com/technet/security/bulletin/MS04-004.mspx Why am I getting errors when attempting to access certain SSL protected Web Sites? After installing the Internet Explorer 6.0 SP1 version of this update, there may be intermittent failures of POST requests to SSL protected sites. This may cause some users to receive an HTTP 500 (Internal server error) while attempting to access certain Web Sites. Microsoft is aware of this issue and has released an update. Information on obtaining this update may be found in the Knowledge Base Article 831167. This update will be included in future Cumulative Security Updates for Internet Explorer. The fix is here and must be applied to MSIE: http://support.microsoft.com/default.aspx?kbid=831167 I wish MS had an automated regression test suite to run before they released updates and new versions -- it would probably cut down a lot of these kinds of problems, and reduce Windows TCO for those who use their stuff (which is all of us). Ah well. /s. On Apr 13, 2004, at 8:55 AM, Greg McGuire wrote: I can certainly corroborate this; much of our customer service is done using SSL, and they use IE6 (mostly). In the past month I've gotten many complaints about this. Finding nothing amiss with AOLserver, I could only suggest that they switch to Mozilla. Is this an AOLserver / IE6 interaction, or are people seeing this using other web servers as well? Regards, Greg On Apr 12, 2004, at 4:00 PM, Ron Emerick wrote: We are noticing that maybe 1 out of 20 HTTPS requests from our clients using MSIE 6.0 are failing. Further digging seems to suggest that the data that should be POSTed with the request isn't (i.e. content-length: 0). It seems that this is related to a MSIE Explorer patch Q832894. Thanks, Ron Emerick -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Anyone noticing weirdness with MSIE 6.0 and HTTPS requests?
On Apr 13, 2004, at 2:19 PM, Tomasz Kosiak wrote: I would certainly opt for having this. But as far as I remember from disscussion with Piotr Szuca that may be difficult to add to AOLserver due to current keepalive implementation. It would probably be difficult to implement for nsopenssl and AOLserver 3.x, but it looks fairly trivial to do with AOLserver 4.x and nsopenssl. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] maxkeepalive in 4.01
Gustaf, MSIE versions are riddled with problems. Ensure SSL session caching is turned on. Looking at the sources, keepalivetimeout is the correct parameter for AOLserver 4.x -- setting this to 0 disables keepalive entirely. Also, MSIE 6.x has intermittent POST problems with the behavior you mentioned (though GET should work fine). Go see previous discussions in this forum; I'm pasting here for convenience: Here's the pertinent text from Microsoft: http://www.microsoft.com/technet/security/bulletin/MS04-004.mspx Why am I getting errors when attempting to access certain SSL protected Web Sites? After installing the Internet Explorer 6.0 SP1 version of this update, there may be intermittent failures of POST requests to SSL protected sites. This may cause some users to receive an HTTP 500 (Internal server error) while attempting to access certain Web Sites. Microsoft is aware of this issue and has released an update. Information on obtaining this update may be found in the Knowledge Base Article 831167. This update will be included in future Cumulative Security Updates for Internet Explorer. The fix is here and must be applied to MSIE: http://support.microsoft.com/default.aspx?kbid=831167 /s. On Apr 20, 2004, at 6:55 AM, Gustaf Neumann wrote: Dear aolserver community, We had a problem with ssl and microsoft IE where form contents (either transmitted via POST or GET) were omitted by the browser under certain conditions (keep alive set, the reply of the form was transmitted not immediately, by in CLOSE_WAIT state). In aolserver 3.* we used maxkeepalive = 0 in the config file to deactivate the keepalive, but in aolserver 4.1 this option appears roughly to be a noop: [~/aolserver-4.1]$ fgrep maxkeep */*.c nsd/nsconf.c:nsconf.keepalive.maxkeep = GetInt(maxkeepalive, KEEPALIVE_MAXKEEP_INT); Setting keepalivetimeout to 0 helped in our situation with 4.1. Due to the mess with IE (multiple problems appear to be in multiple versions for multiple windows versions) ssl + keepalive is currently - and most likely for a while - a nono. It tooks us some time to track down the problem, maybe this mail helps others (item for FAQs?). best regards -gustaf neumann PS: We have still a problem with 4.1 with a memleak. Our server grows with the speed of about 2MB/minute with 4.1, while essentially the same code worked without leak with 3.*. Do others have similar experiences? -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl crash
Looks like problem between RH 7.3 and OpenSSL 0.9.7d. Ensure that your LD_LIBRARY_PATH is set appropriately to point to our compiled version of OpenSSL libs before starting AOLserver; you might be picking up the system's SSL libs. If that doesn't work, follow the same build procedure using earlier versions of OpenSSL to confirm that it's not the OpenSSL version that is the problem. BTW, what version of nsopenssl and AOLserver are you using? /s. On Apr 22, 2004, at 2:16 AM, William Scott Jordan wrote: It seems like I pop on this list every 3 or 4 months with an nsopenssl question. Not wanting to break with tradition, I have a situation that has me stumped. I'm trying to install aolserver and nsopenssl on Redhat 7.3 with OpenSSL 0.9.7d, which was compiled with thread support. Everything seems to run beautifully until I start getting more than one hit at a time, then aolserver crashes and dumps this message in the logs: Error: nsopenssl: EOF during SSL handshake nsd: md_rand.c:312: ssleay_rand_add: Assertion `md_c[1] == md_count[1]' failed. I've tried a million different things and nothing seems to help. I'm hoping there's a simple solution that I've missed. Any advice would be greatly appreciated. Sincerely, Scott -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl crash
Turn on the Trace param for nsopenssl and look in the logs. I'll bet the handshake is still failing, but because of something else. Also, send me (directly) the relevant portion of your nsd.tcl file so I can review your settings (remove any sensitive info). /s. On Apr 22, 2004, at 10:23 PM, William Scott Jordan wrote: Okay, so I'm a moron. When I compiled OpenSSL, I hadn't included the shared tag so the shared libraries weren't being built. I've done that now, though, but I'm still having trouble. Now secure pages don't load at all. It looks like the transaction starts, but no data is sent. I've tried both AOLserver 3.5.6 with nsopenssl 2.1c, which gives the generic error of Error: nsopenssl: error -1/1 during SSL handshake and AOLserver 4.01 with nsopenssl 3.0b17, which doesn't log any error. Any suggestions? Scott At 04:23 PM 4/22/2004, you wrote: Hi Scott, I'm using AOLserver 3.5.6 and nsopenssl 2.1a. I tried Andrew's recommendation of exporting the library path, but that didn't help. So I tried installing an older version of OpenSSL and recompiling everything with that, but that didn't help either. I'm still getting the same error message. I'm really at a loss at this point. Any other suggestions? Scott At 03:39 AM 4/22/2004, you wrote: Looks like problem between RH 7.3 and OpenSSL 0.9.7d. Ensure that your LD_LIBRARY_PATH is set appropriately to point to our compiled version of OpenSSL libs before starting AOLserver; you might be picking up the system's SSL libs. If that doesn't work, follow the same build procedure using earlier versions of OpenSSL to confirm that it's not the OpenSSL version that is the problem. BTW, what version of nsopenssl and AOLserver are you using? /s. On Apr 22, 2004, at 2:16 AM, William Scott Jordan wrote: It seems like I pop on this list every 3 or 4 months with an nsopenssl question. Not wanting to break with tradition, I have a situation that has me stumped. I'm trying to install aolserver and nsopenssl on Redhat 7.3 with OpenSSL 0.9.7d, which was compiled with thread support. Everything seems to run beautifully until I start getting more than one hit at a time, then aolserver crashes and dumps this message in the logs: Error: nsopenssl: EOF during SSL handshake nsd: md_rand.c:312: ssleay_rand_add: Assertion `md_c[1] == md_count[1]' failed. I've tried a million different things and nothing seems to help. I'm hoping there's a simple solution that I've missed. Any advice would be greatly appreciated. Sincerely, Scott -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl crash
Thanks. Will attempt to recreate next week. I'm currently on vacation in Florida :) /s. On May 10, 2004, at 11:53 PM, Torben Brosten wrote: Scott Goodwin, FYI, Here is another 'assertion md_c[1] == md_count[1] failed:' with similar conditions that caused server to crash. (domain and ip numbers filtered) I suspect triggered from an http post from a search form in a https connection.. Torben n.n.n.n - - [10/May/2004:19:44:32 +] GET /register/index? return_url=https%3a%2f%2fdomain%2enet%2faccounthttp_id=0user_session_ id=1814 HTTP/1.1 200 4675 http://www.domain.net/gift-certificate-order; Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7b) Gecko/20040502 n.n.n.m - - [10/May/2004:19:44:33 +] GET /category-browse?category_id=5 HTTP/1.1 200 18075 http://domain.net/?usca%5fp=t; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) n.n.n.o - - [10/May/2004:19:44:34 +] POST /product-search HTTP/1.1 302 390 http://domain.com/index.html; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; .NET CLR 1.1.4322) ... more ... -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ANN: BerkeleyDB database driver for AOLserver
BTW, I may be pulling down OSSWEB and stealing some code from it...do you mind? thanks, /s. On Apr 30, 2004, at 10:26 AM, Vlad Seryakov wrote: Hi, This is AOLserver module that implements database driver for BerkeleyDB from www.sleepycat.com Download http://www.crystalballinc.com/vlad/software/ -- Vlad Seryakov 703 488-2173 office [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl crash
Torben, excellent information -- duplicating the problem is 90% of the battle and the info you've given here may be enough for me to do so. thanks, /s. On May 2, 2004, at 12:50 AM, Torben Brosten wrote: Scott, Not sure if you solved this. I came across similar error conditions, apparently the result of creating web pages that include images with http source urls instead of https ones. I've removed the images for now (until they can be presented properly.) The error has not returned. There have been no other ssl related changes to the website. Torben William Scott Jordan wrote: It seems like I pop on this list every 3 or 4 months with an nsopenssl question. Not wanting to break with tradition, I have a situation that has me stumped. I'm trying to install aolserver and nsopenssl on Redhat 7.3 with OpenSSL 0.9.7d, which was compiled with thread support. Everything seems to run beautifully until I start getting more than one hit at a time, then aolserver crashes and dumps this message in the logs: Error: nsopenssl: EOF during SSL handshake nsd: md_rand.c:312: ssleay_rand_add: Assertion `md_c[1] == md_count[1]' failed. I've tried a million different things and nothing seems to help. I'm hoping there's a simple solution that I've missed. Any advice would be greatly appreciated. Sincerely, Scott -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl: permission denied
It's not a threading issue. AOLserver 4.x opens the listen sockets for all comm modules including nsopenssl, and the error message is coming from the DriverThread function in nsd/driver.c when it attempts to start listening on the port. The reason it says nsopenssl is, well, because that's the name of the thread). I trust the error message because it's coming from the OS; the driver code is very straightforward. So my guess is that you really aren't root at start time. Post the OS make, model and version (my guess is you're using Solaris), the command line that you use to start the server and your nsd.tcl file with any sensitive stuff removed. Also, make sure your LD_LIBRARY_PATH is pointing to the right places. /s. On May 3, 2004, at 2:32 PM, Bart Teeuwisse wrote: Hmm, I've changed the max/minthreads in ns/servers/server1 to no avail. Scott, do you have any suggestions? /Bart On Mon, 3 May 2004 02:49:47 -0400, Chris Davies [EMAIL PROTECTED] wrote: I had a very very similar problem. ns_param maxthreads 5 ns_param minthreads 5 with minthreads 0, (and sometimes 1 or 2) it exhibited the same behavior. On Mon, 2004-05-03 at 02:02, Bart Teeuwisse wrote: Notice: prebind: bound: 192.168.1.2:80 Notice: prebind: bound: 192.168.1.2:443 3471:[02/May/2004:21:28:29][21728.1024][-main-] Error: nsopenssl: failed to listen on 192.168.1.2:443: Permission denied -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] certfiles and ns_openssl
Scott, if you're doing an ns_httpspost to a server and the server requires your client cert, then you point to that client cert in the config file for SockClient. You won't ever be sending the remote server their own public certificate in an SSL handshake. Have you read the docs at http://www.scottg.net/webtools/aolserver/modules/nsopenssl ? /s. On Jun 3, 2004, at 3:41 PM, Dossy wrote: Sadly, I do very little with SSL and nsopenssl -- perhaps Scott Goodwin can say something about this, if he's not too busy? -- Dossy On 2004.06.03, Scott Laplante [EMAIL PROTECTED] wrote: Any advice on this problem? Thanks for anything you have. -Original Message- From: Scott Laplante [mailto:[EMAIL PROTECTED] Sent: Friday, May 28, 2004 12:17 PM To: [EMAIL PROTECTED] Subject: [AOLSERVER] certfiles and ns_openssl We're using ns_openssl2.1a, nsd3.4. How do i send the certfile and/or tell nsd where the certfile is for a particular https domain? We'll be running an HTTPS post and the receiving server requires their public certfile, and we need some way of either sending it with the first request or responding to their request to send their cert. Any help would be greatly appreciated. Thanks, scott -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl -- context will NULL name
Hi Mike,
SSL contexts are needed for each client and each server. Multiple
clients can share the same client SSL context, and multiple servers can
share the same server SSL context, but a client cannot share a server's
SSL context and vice versa. See the notes in the nsopenssl distribution
for details.
/s.
On Jun 22, 2004, at 3:29 PM, Mike Schilli wrote:
Hi all,
from a AOLserver 4.0 running nsopenssl 3.x, I'm trying to initiate
https requests to another server using ns_httpsget. However, I'm
getting
this error:
[21/Jun/2004:13:20:37][17108.40966][-nscp::1-] Error: nsopenssl
(server1): attempt to get SSL context with NULL name
[21/Jun/2004:13:20:37][17108.40966][-nscp::1-] Error: failed to use
either named or default client SSL context
failed to use either named or default client SSL context
while executing
ns_openssl_sockopen -nonblock $host $port
(procedure ns_httpsopen line 42)
invoked from within
ns_httpsopen GET $url $rqset $timeout $module
(procedure ns_httpsget line 10)
invoked from within
Here's my configuration:
ns_section ns/server/${servername}/module/nsopenssl/sslcontexts
ns_param vs1_client_ctx SSL context used for outgoing script
socket connections
ns_section ns/server/${servername}/module/nsopenssl/defaults
#ns_param server vs1_users_ctx
ns_param client vs1_client_ctx
ns_param server vs1_client_ctx
It seems like this error message stems from nsopenssl's
Ns_OpenSSLServerSSLContextGet function which gets a *server* context --
but is this correct if a client context is used?
I didn't install any certs or configure server context(s), is this
required? Would be great if you could point me in the right direction.
--
-- Mike
Mike Schilli
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of
your email blank.
Re: [AOLSERVER] nsopenssl 3.0beta17 with aolserver 4.0.5
This is debugging code from a prior beta. Just grab the latest CVS HEAD for nsopenssl -- latest tag should be v3_0beta21. /s. On Jun 30, 2004, at 12:33 PM, Nathaniel Haggard wrote: The webserver runs for about 6 minutes and then crashes. The log file is full of this: [30/Jun/2004:09:24:56][29446.5126][-conn:server1::0] Debug: Handshake(30): SSL_ERROR_SYSCALL (rc = 0) [30/Jun/2004:09:25:23][29446.8201][-conn:server1::3] Debug: Recv(20): SSL_ERROR_SYSCALL (toread = 16000; total = 0; rc = -1) [30/Jun/2004:09:25:23][29446.6151][-conn:server1::1] Debug: Recv(45): SSL_ERROR_SYSCALL (toread = 16000; total = 0; rc = -1) [30/Jun/2004:09:25:28][29446.8201][-conn:server1::3] Debug: Handshake(59): SSL_ERROR_SYSCALL (rc = 0) [30/Jun/2004:09:25:35][29446.7176][-conn:server1::2] Debug: Recv(35): SSL_ERROR_SYSCALL (toread = 16000; total = 0; rc = -1) [30/Jun/2004:09:25:46][29446.9226][-conn:server1::4] Debug: Handshake(22): SSL_ERROR_SYSCALL (rc = -1) [30/Jun/2004:09:26:00][29446.9226][-conn:server1::4] Debug: Recv(36): SSL_ERROR_SYSCALL (toread = 16000; total = 0; rc = -1) [30/Jun/2004:09:26:08][29446.6151][-conn:server1::1] Debug: Handshake(38): SSL_ERROR_SYSCALL (rc = 0) [30/Jun/2004:09:26:08][29446.7176][-conn:server1::2] Debug: Handshake(40): SSL_ERROR_SYSCALL (rc = 0) [30/Jun/2004:09:26:08][29446.7176][-conn:server1::2] Debug: Handshake(55): SSL_ERROR_SYSCALL (rc = 0) [30/Jun/2004:09:26:08][29446.7176][-conn:server1::2] Debug: Handshake(56): SSL_ERROR_SYSCALL (rc = 0) . The last few lines before all but one nsd process crashed: [30/Jun/2004:09:40:30][30078.8201][-conn:server1::3] Debug: Send(60): SSL_ERROR_SYSCALL (towrite = 0; total = 217; rc = -1) [30/Jun/2004:09:40:30][30078.8201][-conn:server1::3] Debug: Send(60): SSL_ERROR_SYSCALL (towrite = 0; total = 217; rc = -1) [30/Jun/2004:09:40:30][30078.8201][-conn:server1::3] Debug: Send(60): SSL_ERROR_SYSCALL (towrite = 0; total = 217; rc = -1) [30/Jun/2004:09:40:30][30078.8201][-conn:server1::3] Debug: Send(60): SSL_ERROR_SYSCALL (towrite = 0; total = 217; rc = -1) [30/Jun/2004:09:40:30][30078.8201][-conn:server1::3] Debug: Send(60): SSL_ERROR_SYSCALL (towrite = 0; total = 217; rc = -1) [30/Jun/2004:09:40:30][30078.8201][-conn:server1::3] Debug: Send(60): SSL_ERROR_SYSCALL (towrite = 0; total = 217; rc = -1) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl latest from CVS SSL error on reading data
My apologies for not being more reponsive; I've been very busy at NASA these past six months. I'm getting ready to use nsopenssl for the sites we're building here so I'll be fixing any problems you're seeing in the next few weeks. I suspect I'm not seeing many of the errors when my tests are being run on the same machine as the web server, so I've purchased two low-end intel boxes to set up a test network and run load tests across ethernet; just waiting for two 200GB drives to arrive so I can install OSs. I did get the SSL error pointed out in this thread and had an image or two not load when I tested last night on my powerbook; under a much heavier load I should be able to track down the problem. thanks, /s. On Aug 10, 2004, at 2:59 PM, Janine Sisk wrote: That's really interesting... all I can think of is a permissions problem, but then it wouldn't work at all. FWIW, I've had this running since about 1 pm on Friday, so four days now. In that time we've had 8 unexplained crashes, or an average of 2 per day. Although four of them were yesterday so you might expect it to be load related, but there have been none so far today. During that same time there have been 67 SSL_ERRORs reported. Although it's obviously too many, it's not the level of spewing I was getting with the beta17 version nor what Nate is experiencing. Anyone have any ideas? I guess Scott isn't working on the module anymore? I'm not really qualified to try to fix this, unfortunately, or I would have tried already. janine On Aug 10, 2004, at 11:56 AM, Nathaniel Haggard wrote: Binding to port 8443 using the same setup that I mentioned in my first email fixes the problems I was having with too many log entries of this nature: 07/Aug/2004:12:56:00][27466.7176][-conn:server1::2] Debug: SSLOp(27-0): SSL_ERROR_SSL: bytes = 16000; total = 0; rc = -1 Why would port number matter? Nate On Mon, 9 Aug 2004 16:56:06 -0600, Nathaniel Haggard [EMAIL PROTECTED] wrote: nsopenssl is using openssl 0.9.6b, is that a problem? openssl3.0beta21 with aolserver4.0.7 gives similar results. The server actually crashed even more frequently but that might be due to traffic. Nate On Mon, 9 Aug 2004 10:21:01 -0600, Nathaniel Haggard [EMAIL PROTECTED] wrote: aolserver is binding to the ssl port. It is prebinding to port 443 (-b 0.0.0.0:80,0.0.0.0:443) [07/Aug/2004:13:28:37][28040.1024][-main-] Notice: nsopenssl (server1): 'users' certificate and key loaded successfully [07/Aug/2004:13:28:37][28040.1024][-main-] Notice: nsopenssl (server1): 'users' failed to load CA certificate file '/sm/aolserver/servers/server1/modules/nsopenssl/ca-client/ca- client.crt' [07/Aug/2004:13:28:37][28040.1024][-main-] Error: nsopenssl (server1): 'users' CA certificate file is not readable or does not exist The server crashed (and restarted because it's running from inittab) 4 times in the 20 minutes I had it running. Like Janine reported there was no explanation for the crash in the error.log; it just crasehd. Nate On Sat, 7 Aug 2004 21:56:27 -0700, Torben Brosten [EMAIL PROTECTED] wrote: Nate, Is aolserver binding to the ssl port? I get an identical error when something is prebound to the ssl port and so aolserver fails to bind to it. A failed to listen on.. address already in use error shows up in the logfile just after server reports listening on same port, ie. during server startup. Torben ps. this is my 3rd attempt at posting this message. Hopefully this time there are no glitches. Sorry if this is a duplicate message. Nathaniel Haggard wrote: AOLserver 4.0.7 with nsopenssl from cvs has problems. The following messages are from the server.log while we tested the site. We didn't have any problems on the client side and all the pages come up as usual. [07/Aug/2004:12:56:00][27466.7176][-conn:server1::2] Debug: SSLOp(27-0): SSL_ERROR_SSL: bytes = 16000; total = 0; rc = -1 [07/Aug/2004:12:56:00][27466.7176][-conn:server1::2] Error: nsopenssl (server1): SSL error on reading data [07/Aug/2004:12:56:08][27466.7176][-conn:server1::2] Debug: SSLOp(55-0): SSL_ERROR_SSL: bytes = 16000; total = 0; rc = -1 [07/Aug/2004:12:56:08][27466.7176][-conn:server1::2] Error: nsopenssl (server1): SSL error on reading data [07/Aug/2004:13:00:29][27627.5126][-conn:server1::0] Debug: SSLOp(19-0): SSL_ERROR_SSL: bytes = 16000; total = 0; rc = -1 [07/Aug/2004:13:00:29][27627.5126][-conn:server1::0] Error: nsopenssl (server1): SSL error on reading data The server crashes every few minutes as well. Most of the entries in the server.log, which is growing at a rapid rate, are errors or warning related to nsopenssl. This looks like the problem you guys discussed earlier with nsopenssl3.0beta. Nate -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply
Re: [AOLSERVER] nsopenssl latest from CVS SSL error on reading data
I guess low-end does sound a bit odd in the same sentence with 200 GB disk drives, but they're going into 500MHz and 800MHz Dell OptiPlexes, which can only fit one drive. I can certainly give you the 5GB and 10GB excess disks I'm pulling out of them if you pay postage :) /s. On Aug 10, 2004, at 5:40 PM, Cathy Sarisky wrote: On Tue, 10 Aug 2004, Scott Goodwin wrote: purchased two low-end intel boxes to set up a test network and run load tests across ethernet; just waiting for two 200GB drives to arrive so I... LOL. I like your definition of low-end. Should you find yourself with an excess of low-end boxen, you can send 'em my way. ;) Cathy p.s. Yeah, sorry, OT, but I couldn't resist... -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. thanks, /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl latest from CVS SSL error on reading data
I appreciate you and others pointing these issues out so I can track them down and fix them. Hopefully my low-end boxes will help in identifying these problems sooner. One box will be running Gentoo Linux, the other might be some form of *BSD. /s. On Aug 10, 2004, at 7:05 PM, Janine Sisk wrote: No problem, Scott, glad to hear you're still at it. I hope I didn't sound like I was complaining; I was just wanting to figure out who, if anyone, was maintaining the module. If I can help you sort this out, just let me know. janine On Aug 10, 2004, at 5:28 PM, Scott Goodwin wrote: -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Server crashed
If you're using nsopenssl, it's possible your OpenSSL library has been compiled with Kerberos enabled. If you can, compile a local copy of OpenSSL without Kerberos support. /s. On Feb 13, 2006, at 8:56 AM, Dossy Shiobara wrote: On 2006.02.13, Nima Mazloumi [EMAIL PROTECTED] wrote: I got the following last line in the error log before the server crashed: nsd: unknown binding type (2104528680) in free_binding Google suggests that error string coming from some Kerberos code. I don't believe any of the AOLserver core code uses/links to any Kerberos libs. So, what modules are you loading? Any of them linked to libkrb5 or any other Kerberos lib? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] nsopenssl dropping connections
AOLserver actually manages the connections for nsopenssl. The
nsopenssl code in question is:
if (Ns_QueueConn(sdPtr-driver, scPtr) != NS_OK) {
Ns_Log(Warning, %s: connection dropped, sdPtr-module);
(void) SockClose(scPtr);
}
nsopenssl is getting something other than NS_OK back from
Ns_QueueConn when the latter tries to append the connection to the
run queue. AOLserver in turn may not have been keeping up with the
load, but I'd first check your OS TCP pending connection limits. If
your system was being hammered, it's possible your OS was turning
away conns. I'm not sure I should have put this message in the log as
it may not reflect what actually happened. Unless someone responds
with a better answer, I'll take a closer look at the code tomorrow.
/s.
On Jul 22, 2006, at 7:45 PM, William Scott Jordan wrote:
Hi all!
We had a situation recently of extremely high traffic, during which
connections were being rejected/dropped with following warning
showing up in the logs: Warning: nsopenssl: connection dropped I
guess my questions are, what limit in nsopenssl is causing
connections to be dropped? Can this limit be adjusted? Is there
any way to catch this error to allow for a more graceful
degredation, such as with a redirect to an unencrypted Server Too
Busy page?
This is on AOLServer 3.5.6, nsopenssl 2.1a, and FC3.
Any light that anyone can shed on this would be greatly appreciated.
-Scott
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] nsopenssl dropping connections
nd instrumentation to see what might actually be happening.If you have more information on the problems you encountered, I'll do my best to help within the time I have available./s.On Jul 22, 2006, at 8:59 PM, Scott Goodwin wrote:AOLserver actually manages the connections for nsopenssl. The nsopenssl code in question is:if (Ns_QueueConn(sdPtr-driver, scPtr) != NS_OK) { Ns_Log(Warning, "%s: connection dropped", sdPtr-module); (void) SockClose(scPtr);}nsopenssl is getting something other than NS_OK back from Ns_QueueConn when the latter tries to append the connection to the run queue. AOLserver in turn may not have been keeping up with the load, but I'd first check your OS TCP pending connection limits. If your system was being hammered, it's possible your OS was turning away conns. I'm not sure I should have put this message in the log as it may not reflect what actually happened. Unless someone responds with a better answer, I'll take a closer look at the code tomorrow./s.On Jul 22, 2006, at 7:45 PM, William Scott Jordan wrote: Hi all!We had a situation recently of extremely high traffic, during which connections were being rejected/dropped with following warning showing up in the logs: "Warning: nsopenssl: connection dropped" I guess my questions are, what "limit" in nsopenssl is causing connections to be dropped? Can this limit be adjusted? Is there any way to catch this error to allow for a more graceful degredation, such as with a redirect to an unencrypted "Server Too Busy" page?This is on AOLServer 3.5.6, nsopenssl 2.1a, and FC3.Any light that anyone can shed on this would be greatly appreciated.-Scott--AOLserver - http://www.aolserver.com/To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with thebody of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. --AOLserver - http://www.aolserver.com/To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with thebody of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Problems with nsopenssl-2.1a(compilation) and nsopenssl-3.0beta26(runtime)
nsopenssl 2.x won't work with AOLserver 4.5.x. nsopenssl-3.0beta26 is segfaulting when generating temporary 512-bit keys. This was fixed a while back -- go grab the cvs copy of nsopenssl from sourceforge. I just compiled it with AOLserver 4.5.0 and it runs, though it gives me an error indicating that there are no shared ciphers between the browser and nsopenssl when I try to connect. Let me know if you get the same error. /s. On Jan 22, 2007, at 8:12 PM, Pedro Liska wrote: Hi, I got AOLserver 4.5 running my website with no problems. But I also need https to work and that's where things got nasty. I'm aiming for AOLserver 4.5 with nsopenssl-2.1a but I also tried getting nsopenssl-3.0beta26 to work. When gmake'ing nsopenssl-2.1a I get the following error: -- [EMAIL PROTECTED] nsopenssl-2.1a]# gmake OPENSSL=/usr/local/ssl gcc -pipe -I/usr/local/ssl/include -O2 -Wall -Wno-implicit-int -fno-strict-aliasing -fPIC -I/usr/local/aolserver/include -I/usr/local/aolserver/include -DNO_CONST -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_ATFORK=1 -DTCL_THREADS=1 -DPEEK_XCLOSEIM=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1 -DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1 -DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_FTS=1 -DHAVE_SYS_IOCTL_H=1 -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_TIMEGM=1 -DHAVE_DRAND48=1 -DHAVE_RANDOM=1 -DHAVE_POLL=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETNAMEINFO=1 -c -o nsopenssl.o nsopenssl.c nsopenssl.c: In function `Ns_ModuleInit': nsopenssl.c:167: warning: passing arg 3 of `Ns_DriverInit' from incompatible pointer type nsopenssl.c:167: error: too many arguments to function `Ns_DriverInit' nsopenssl.c: In function `NsOpenSSLGetModuleName': nsopenssl.c:190: warning: unused variable `sdPtr' nsopenssl.c: In function `NsOpenSSLGetSockServerSSLContext': nsopenssl.c:228: error: `firstSSLDriverPtr' undeclared (first use in this function) nsopenssl.c:228: error: (Each undeclared identifier is reported only once nsopenssl.c:228: error: for each function it appears in.) nsopenssl.c: In function `NsOpenSSLGetSockClientSSLContext': nsopenssl.c:257: error: `firstSSLDriverPtr' undeclared (first use in this function) nsopenssl.c: At top level: nsopenssl.c:850: error: syntax error before Ns_Buf nsopenssl.c: In function `OpenSSLProc': nsopenssl.c:851: error: number of arguments doesn't match prototype nsopenssl.c:117: error: prototype declaration nsopenssl.c:853: error: `sock' undeclared (first use in this function) nsopenssl.c:856: error: `cmd' undeclared (first use in this function) nsopenssl.c:870: error: structure has no member named `sdPtr' nsopenssl.c:871: error: structure has no member named `sdPtr' nsopenssl.c:872: error: `sdPtr' undeclared (first use in this function) nsopenssl.c:891: error: `bufs' undeclared (first use in this function) nsopenssl.c:901: error: `nbufs' undeclared (first use in this function) nsopenssl.c: At top level: nsopenssl.c:41: warning: 'RCSID' defined but not used gmake: *** [nsopenssl.o] Error 1 -- So decided to give nsopenssl-3.0beta26 a shot. The building of the source and installation went successfully but when running AOLserver I get the following error: -- [EMAIL PROTECTED] ~]# cat run-aol4-server /usr/local/aolserver/bin/nsd -u pliska -g nmont -ft /usr/local/aolserver/neumont-dev.tcl -b 127.0.0.1:80 [EMAIL PROTECTED] ~]# ./run-aol4-server [22/Jan/2007:16:04:43][6250.3086841536][-main-] Notice: prebind: bound: 127.0.0.1:80 [22/Jan/2007:16:04:43][6250.3086841536][-main-] Notice: nsmain: AOLserver/4.5.0 starting [22/Jan/2007:16:04:43][6250.3086841536][-main-] Notice: nsmain: security info: uid=500, euid=500, gid=504, egid=504 [22/Jan/2007:16:04:43][6250.3086841536][-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024
Re: [AOLSERVER] Problems with nsopenssl-2.1a(compilation) and nsopenssl-3.0beta26(runtime)
nsthreadtest lrwxrwxrwx 1 root root 11 Jan 2 17:36 ora8.so - nsoralce.so -rw-r--r-- 1 pliska nmont1759 Aug 8 2005 tcl2ini.tcl -rwxr-xr-x 1 pliska nmont5704 Jan 2 16:49 tclsh8.4 [EMAIL PROTECTED] bin]# cat /home/pliska/run-aol4-server /usr/local/aolserver/bin/nsd -u pliska -g nmont -ft /usr/local/ aolserver/neumont-dev.tcl -b 127.0.0.1:80 [EMAIL PROTECTED] bin]# /home/pliska/run-aol4-server [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: prebind: bound: 127.0.0.1:80 [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: nsmain: AOLserver/4.5.0 starting [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: nsmain: security info: uid=500, euid=500, gid=504, egid=504 [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024 [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: encoding: loaded: utf-8 [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: fastpath [neumont-dev]: mapped GET / [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: fastpath [neumont-dev]: mapped HEAD / [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: fastpath [neumont-dev]: mapped POST / [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: adp[neumont- dev]: mapped GET /*.adp [23/Jan/2007:12:12:58][6084.3086870208 ][-main-] Notice: adp [neumont-dev]: mapped HEAD /*.adp [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: adp[neumont- dev]: mapped POST /*.adp [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nssock.so' [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nslog.so' [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: nslog: opened '/usr/local/aolserver/servers/neumont-dev/log/neumont- dev.log' [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsdb.so' [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: modload: loading '/usr/local/aolserver/bin/ora8.so' [23/Jan/2007:12:12:58][6084.3086870208][-main-] Notice: ora8 driver LobBufferSize = 16384 [23/Jan/2007:12:12:59][6084.3086870208][-main-] Notice: ora8 driver PrefetchRows = 0 [23/Jan/2007:12:12:59][6084.3086870208 ][-main-] Notice: ora8 driver PrefetchMemory = 0 [23/Jan/2007:12:12:59][6084.3086870208][-main-] Notice: Loaded ArsDigita Oracle Driver version 2.7, built on 15:17:54/Mar 28 2006 [23/Jan/2007:12:12:59][6084.3086870208 ][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nspasswd.so' [23/Jan/2007:12:12:59][6084.3086870208][-main-] Notice: modload: loading '/usr/local/aolserver/bin/nsopenssl.so' [23/Jan/2007:12:12:59][ 6084.3086870208][-main-] Notice: nsopenssl: generating 512-bit temporary RSA key ... [23/Jan/2007:12:12:59][6084.3086870208][-main-] Fatal: received fatal signal 11 /home/pliska/run-aol4-server: line 1: 6084 Aborted /usr/local/aolserver/bin/nsd -u pliska -g nmont -ft /usr/local/aolserver/neumont- dev.tcl -b 127.0.0.1:80 [EMAIL PROTECTED] bin]# On 1/22/07, Scott Goodwin [EMAIL PROTECTED] wrote: nsopenssl 2.x won't work with AOLserver 4.5.x. nsopenssl-3.0beta26 is segfaulting when generating temporary 512-bit keys. This was fixed a while back -- go grab the cvs copy of nsopenssl from sourceforge. I just compiled it with AOLserver 4.5.0 and it runs, though it gives me an error indicating that there are no shared ciphers between the browser and nsopenssl when I try to connect. Let me know if you get the same error. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SSL read error: bad write retry
How many connections a day does your server get, and can you give me an estimate of the rate of connection activity when the form submission fails? Also, send me the output of 'uname -a' and the version of OpenSSL you're using. thanks, /s. On Jan 25, 2007, at 5:52 PM, Alex Kroman wrote: Hi all, Every day about 1% of connections to my website result in the following error: Error: nsopenssl: SSL write error: bad write retry I can reproduce the error by repeatedly submiting a form. Eventually one of those submits will fail and give the generic Internet Explorer connection error and append the bad write retry message to the log. Has anyone run into this problem? I am using the stock Debian versions of AOLServer 4.0.10 and nsopenssl 3.0beta22. Here are some settings from my configuration file: ns_param maxinput [expr 1024 * 1024 * 100] ns_param recvwait [expr 20 * 60] ns_param socktimeout 240 Thanks, Alex -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SSL read error: bad write retry
Thanks for the update. It sounds like a compatibility problem with MSIE or maybe something completely internal to MSIE, but we may still be able to do something about it. Can you provide a list of the specific browser versions affected? The user-agent strings should suffice, but it would help if you could identify whether the browsers are export-crippled to 40-bit, 56-bit or are regular 128-bit capable, that would also help in reproducing and testing potential fixes. /s. On Jan 26, 2007, at 11:34 AM, Alex Kroman wrote: I can't seem to come up with a good test case that triggers this behavior - I have never seen this occur in Firefox (my main browser). - Using wget in an infinite loop with varying page sizes and varying loads does not seem to trigger it. - Just a few minutes ago I was clicking around with Internet Explorer and reproduced the behavior. - The pages that trigger this behavior seem to be completely random. This site is an Intranet for a 100 person company. I sent out a survey to the heaviest users of the system and 100% of the Internet Explorer users have encountered this behavior within the past week and none of the Apple users have. Alex -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Steve Manning Sent: Friday, January 26, 2007 12:56 AM To: AOLSERVER@listserv.aol.com Subject: Re: [AOLSERVER] SSL read error: bad write retry Alex We see this problem as well and I think its related to the system load. Our peak load is in October when we are averaging over 500,000 pages per day and we have had reports of blank pages being returned during this time. I spoke to Dossy about it in Sept last year as I know hes been doing some work on tidying it up but its not yet been committed. See below. Steve On 2006.09.20, Steve Manning [EMAIL PROTECTED] wrote: Could you give us an update on the current state of nsopenssl. I'm currently using v3_0beta26 but I'm seeing increasing numbers of SSL read error: ssl handshake failure and SSL write error: bad write retry errors in the log as the site gets more busy (currently about 1.4m requests/day). I see there has been some activity in CVS - v3_0beta27 and Head and I'm wondering if these changes are worth having and if there anything else in the pipeline. I'm sitting on a whole chunk of changes ... and some of that logging needs to be rationalized ... either demoted to Debug level, or removed entirely. At this point in time, are there any serious remaining bugs with nsopenssl? I'd like to finally declare nsopenssl 3.0 final ... probably just call it nsopenssl 3.1 to avoid all the confusion with the MANY 3.0-beta-something versions. Lets put together a TODO list for nsopenssl_v3_r1, divide up the work (or, assign it all to me, doesn't matter) and I'll try to put an estimate on it. So: what are you (plural -- all of you) still waiting for to be done in nsopenssl? -- Dossy On Thu, 2007-01-25 at 20:12 -0600, Alex Kroman wrote: Our production server is getting 57,000 pageviews per day but I am able to replicate this behavior on a development server that I am the only user on. Linux intra 2.6.8-3-686-smp #1 SMP Thu Feb 9 07:05:39 UTC 2006 i686 GNU/Linux OpenSSL 0.9.7e -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Scott Goodwin Sent: Thursday, January 25, 2007 5:37 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] SSL read error: bad write retry How many connections a day does your server get, and can you give me an estimate of the rate of connection activity when the form submission fails? Also, send me the output of 'uname -a' and the version of OpenSSL you're using. thanks, /s. On Jan 25, 2007, at 5:52 PM, Alex Kroman wrote: Hi all, Every day about 1% of connections to my website result in the following error: Error: nsopenssl: SSL write error: bad write retry I can reproduce the error by repeatedly submiting a form. Eventually one of those submits will fail and give the generic Internet Explorer connection error and append the bad write retry message to the log. Has anyone run into this problem? I am using the stock Debian versions of AOLServer 4.0.10 and nsopenssl 3.0beta22. Here are some settings from my configuration file: ns_param maxinput [expr 1024 * 1024 * 100] ns_param recvwait [expr 20 * 60] ns_param socktimeout 240 Thanks, Alex -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can
Re: [AOLSERVER] SSL read error: bad write retry
Steve, what version of OpenSSL are you running on the site that you're experiencing this problem on? /s. On Jan 26, 2007, at 3:55 AM, Steve Manning wrote: Alex We see this problem as well and I think its related to the system load. Our peak load is in October when we are averaging over 500,000 pages per day and we have had reports of blank pages being returned during this time. I spoke to Dossy about it in Sept last year as I know hes been doing some work on tidying it up but its not yet been committed. See below. Steve -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SSL read error: bad write retry
keepalive isn't documented in the sample nsd config file for 4.0.10. Looking at the code, the server defaults to a keepalive timeout of 30 seconds, with a max allowed of 300 seconds. To rule out the issue that Andrew pointed to, we need one or more of you to see if the problem goes away by disabling keepalive. You do this by adding the following keepalivetimeout param to your nsd.tcl file: ns_section ns/parameters ... other params ... ns_param keepalivetimeout 0 ;# set to 0 to disable keepalive ... other params ... Let us know if the problem goes away. /s. On Jan 26, 2007, at 12:28 PM, Andrew Steets wrote: We have some servers that only service cURL/openssl clients and we never see these SSL errors on those machines, regardless of load. OTOH, we have other servers that face real people, and they tend to log openssl errors relatively frequently. Both servers have identical configurations (aolserver 4.0.10 / openssl 0.9.7e). At one point, the mod_ssl guys decided there was some issue with the MSIE ssl stack, but I'm not sure if any of it is still valid. http://www.modssl.org/docs/2.8/ssl_faq.html#ToC49 -Andrew On 1/26/07, Alex Kroman [EMAIL PROTECTED] wrote: I can't seem to come up with a good test case that triggers this behavior - I have never seen this occur in Firefox (my main browser). - Using wget in an infinite loop with varying page sizes and varying loads does not seem to trigger it. - Just a few minutes ago I was clicking around with Internet Explorer and reproduced the behavior. - The pages that trigger this behavior seem to be completely random. This site is an Intranet for a 100 person company. I sent out a survey to the heaviest users of the system and 100% of the Internet Explorer users have encountered this behavior within the past week and none of the Apple users have. Alex -Original Message- From: AOLserver Discussion [mailto: [EMAIL PROTECTED] On Behalf Of Steve Manning Sent: Friday, January 26, 2007 12:56 AM To: AOLSERVER@listserv.aol.com Subject: Re: [AOLSERVER] SSL read error: bad write retry Alex We see this problem as well and I think its related to the system load. Our peak load is in October when we are averaging over 500,000 pages per day and we have had reports of blank pages being returned during this time. I spoke to Dossy about it in Sept last year as I know hes been doing some work on tidying it up but its not yet been committed. See below. Steve On 2006.09.20, Steve Manning [EMAIL PROTECTED] wrote: Could you give us an update on the current state of nsopenssl. I'm currently using v3_0beta26 but I'm seeing increasing numbers of SSL read error: ssl handshake failure and SSL write error: bad write retry errors in the log as the site gets more busy (currently about 1.4m requests/day). I see there has been some activity in CVS - v3_0beta27 and Head and I'm wondering if these changes are worth having and if there anything else in the pipeline. I'm sitting on a whole chunk of changes ... and some of that logging needs to be rationalized ... either demoted to Debug level, or removed entirely. At this point in time, are there any serious remaining bugs with nsopenssl? I'd like to finally declare nsopenssl 3.0 final ... probably just call it nsopenssl 3.1 to avoid all the confusion with the MANY 3.0-beta-something versions. Lets put together a TODO list for nsopenssl_v3_r1, divide up the work (or, assign it all to me, doesn't matter) and I'll try to put an estimate on it. So: what are you (plural -- all of you) still waiting for to be done in nsopenssl? -- Dossy On Thu, 2007-01-25 at 20:12 -0600, Alex Kroman wrote: Our production server is getting 57,000 pageviews per day but I am able to replicate this behavior on a development server that I am the only user on. Linux intra 2.6.8-3-686-smp #1 SMP Thu Feb 9 07:05:39 UTC 2006 i686 GNU/Linux OpenSSL 0.9.7e -Original Message- From: AOLserver Discussion [mailto: [EMAIL PROTECTED] On Behalf Of Scott Goodwin Sent: Thursday, January 25, 2007 5:37 PM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] SSL read error: bad write retry How many connections a day does your server get, and can you give me an estimate of the rate of connection activity when the form submission fails? Also, send me the output of 'uname -a' and the version of OpenSSL you're using. thanks, /s. On Jan 25, 2007, at 5:52 PM, Alex Kroman wrote: Hi all, Every day about 1% of connections to my website result in the following error: Error: nsopenssl: SSL write error: bad write retry I can reproduce the error by repeatedly submiting a form. Eventually one of those submits will fail and give the generic Internet
Re: [AOLSERVER] SSL read error: bad write retry
Hi Steve,
If keepalivetimeout is not set at all in your nsd.tcl, it means you
are using keepalive and it is set to 30 seconds. Can you try adding
the keepalivetimetout parameter and setting it to 0 as I mentioned in
a previous message and see if that solves the problem? I'm pretty
sure Andrew found the correct information -- that MSIE has difficulty
with keepalive conns over SSL, particularly since no one has been
able to replicate the problem with other browsers or load testers.
Note that turning off keepalive will turn it off for non-SSL conns as
well, so if you try it, do be careful.
/s.
On Jan 26, 2007, at 2:44 PM, Steve Manning wrote:
Hi Scott
Long time no hear.
The site is http://www.fancydress.com running on Linux - Centos 4.4
(RHEL4 derived). We run AOLserver 4.0.10 with OpenACS 5.0.4 over the
top.
OpenSSL is 0.9.7a-43-14 from the supplied RPM and were using the
nsopenssl tagged as v3.0beta26 from cvs.
From the config we have:
ns_section ns/server/${server}/module/nsopenssl/sslcontext/
users
ns_param Role server
.
.
.
.
# for ProtocolsALL = SSLv2, SSLv3, TLSv1
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite ALL:!ADH:RC4+RSA:+HIGH:
+MEDIUM:
+LOW:+SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace false
ns_param SessionCache true
ns_param SessionCacheID 1
ns_param SessionCacheSize 512
ns_param SessionCacheTimeout 300
keepalivetimeout is not set.
Just from this evenings log I can see e.g.
[26/Jan/2007:18:52:34][25120.3050740656][-conn:fancydress::14]
Error: nsopenssl (fancydress): SSL read error: bad write retry
[26/Jan/2007:19:02:28][25120.3023371184][-conn:fancydress::40]
Error: nsopenssl (fancydress): SSL read error: ssl handshake
failure
Let me know if you need anything else.
Steve
On Fri, 2007-01-26 at 12:55 -0500, Scott Goodwin wrote:
Steve, what version of OpenSSL are you running on the site that
you're experiencing this problem on?
/s.
On Jan 26, 2007, at 3:55 AM, Steve Manning wrote:
Alex
We see this problem as well and I think its related to the system
load.
Our peak load is in October when we are averaging over 500,000
pages per
day and we have had reports of blank pages being returned during
this
time.
I spoke to Dossy about it in Sept last year as I know hes been doing
some work on tidying it up but its not yet been committed. See
below.
Steve
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
--
Steve Manning - Mandrake Linux 10.1 - Gnome 2.6
East Goscote - Leicester - UK +44 (0)116 260 5457
E-Mail: [EMAIL PROTECTED] - Web: www.festinalente.co.uk
AIM: verbomania - Public Key: 25665CAF from wwwkeys.pgp.net
---
There are only 10 types of people in this world
Those who understand binary and those who don't
---
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] SSL read error: bad write retry
See http://httpd.apache.org/docs/1.3/keepalive.html Probably negligible impact, but I don't know the specifics of your configuration and load and I'm wary of suggesting that people try things that may have adverse consequences to a production site. I wouldn't want to be responsible for depriving somebody of one of those costumes. /s. On Jan 26, 2007, at 4:20 PM, Steve Manning wrote: What is the consequence of setting the keepalive timeout to 0? I thought it was just performance related but your comment makes it sound more serious than that. On Fri, 2007-01-26 at 15:26 -0500, Scott Goodwin wrote: Note that turning off keepalive will turn it off for non-SSL conns as well, so if you try it, do be careful. -- Steve Manning - Mandrake Linux 10.1 - Gnome 2.6 East Goscote - Leicester - UK +44 (0)116 260 5457 E-Mail: [EMAIL PROTECTED] - Web: www.festinalente.co.uk AIM: verbomania - Public Key: 25665CAF from wwwkeys.pgp.net --- There are only 10 types of people in this world Those who understand binary and those who don't --- -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SSL read error: bad write retry
I've been able to trigger this error message with AOLserver 4.0.10, OpenSSL 0.9.8d, and nsopenssl cvs running on a gentoo linux box with Mac's Safari as the client over my home network, though not consistently. Safari doesn't fail to load the page the way it's been reported that MSIE does, but when the event occurs, the part of the page that I'm assuming tripped over the bad write retry doesn't show up on the page. I need to create a test case that triggers this event consistently, then I can begin to isolate what's really going on. /s. On Jan 29, 2007, at 3:37 PM, Alex Kroman wrote: Hi all, I turned off keepalive on our production server but am still receiving the bad write retry errors. -Alex -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Dossy Shiobara Sent: Friday, January 26, 2007 10:35 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] SSL read error: bad write retry On 2007.01.26, Alex Kroman [EMAIL PROTECTED] wrote: I had Siege connect to my development server 50,000 times and did not receive the bad write retry once. While clicking around the site with Siege active I still got the bad write retry and a blank page in about 75 clicks. This is a similar result to what I would get when my development server is not under load. I smell SSLv2 at play here. I bet Firefox is using TLS or SSLv3, while IE is still using SSLv2. What do your protocols and ciphersuite ns_param's look like in your nsopenssl config? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SSL read error: bad write retry
At this point I'd prefer not to speculate -- much better to replicate the problem and see it in all its dynamic glory. However, my sense is that session caching, keepalive and other factors may make the problem worse but are not likely to be root causes. /s. On Jan 29, 2007, at 6:13 PM, Andrew Steets wrote: I noticed that the default ssl session cache size is only 128, and the default session timeout is five minutes. If clients are not expiring the session before 5 minutes, and you've got more than 128 clients in 5 minutes, then what should happen? The openssl documentation is a bit unclear: SSL_CTX_sess_set_cache_size(3): When the maximum number of sessions is reached, no more new sessions are added to the cache. New space may be added by calling SSL_CTX_flush_sessions(3) to remove expired sessions. SSL_CTX_flush_sessions(3): As sessions will not be reused ones they are expired, they should be removed from the cache to save resources. This can either be done automatically whenever 255 new sessions were established or manually by calling SSL_CTX_flush_sessions(). And it doesn't look like nsopenssl ever calls SSL_CTX_flush_sessions () explicitly. So the default cache size is 128, but it only flushed after 255 sessions? That sounds like trouble. Has anyone tried increasing the 'sessioncachesize' parameter? Also, it looks like openssl tracks cache full events on a per-ctx basis, but they aren't exposed in nsopenssl. That might be nice to have in a future rev. -Andrew On 1/29/07, Alex Kroman [EMAIL PROTECTED] wrote: Hi all, I turned off keepalive on our production server but am still receiving the bad write retry errors. -Alex -Original Message- From: AOLserver Discussion [mailto: [EMAIL PROTECTED] On Behalf Of Dossy Shiobara Sent: Friday, January 26, 2007 10:35 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] SSL read error: bad write retry On 2007.01.26, Alex Kroman [EMAIL PROTECTED] wrote: I had Siege connect to my development server 50,000 times and did not receive the bad write retry once. While clicking around the site with Siege active I still got the bad write retry and a blank page in about 75 clicks. This is a similar result to what I would get when my development server is not under load. I smell SSLv2 at play here. I bet Firefox is using TLS or SSLv3, while IE is still using SSLv2. What do your protocols and ciphersuite ns_param's look like in your nsopenssl config? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] possible deadlock in AOLServer 3.4
Vlad, Try increasing your per-thread stack size and see if the problem goes away. If a thread uses more of its stack than it is supposed to, it corrupts other thread stacks which usually leads to the server getting stuck. The parameter to do this is below: ns_param stacksize [expr 128*1024] ;# Per-thread stack size. I don't think there is a reliable way to select a perfect stack size, but I suggest doubling it to begin with, and if the problem happens less frequently as a result, then you're on the right track. Should this not solve the problem, tell me if you're using nsopenssl and if you're seeing your CPU(s) maxed out when the server hangs. /s. Scott Goodwin e: [EMAIL PROTECTED] k: 0x8CCA5533 On Jul 3, 2007, at 7:17 AM, Vlad Hociota wrote: Hello folks. I’m digging into this issue and thought maybe someone might remember anything from those days … The piece of software is a server based on AOL-3.4 code, but with some proprietary modules added on top. The issue cannot be reproduced in a repetitive way -- but sometimes we find that one or another instance of the server (different installations, many machines) is not servicing requests anymore, even if the task load is very low. Upon inspection of a “locked” server (dumping core via attached gdb) we found, that the conn threads were waiting to join one another (like in a queue) - I’m talking about the last sequence of code in NsConnThread where each thread that exits joins the one that exited before it. The stack in those conn threads looks like this: Thread 3 (Thread 1075616096 (LWP 9692)): #0 0x003e7d508a7a in pthread_cond_wait@@GLIBC_2.3.2 () from / lib64/tls/libpthread.so.0 #1 0x004dbb94 in Ns_CondWait (condPtr=0x61b548, mutexPtr=0x61b540) at pthread.c:577 #2 0x004d9098 in Ns_ThreadJoin (threadPtr=0x401c90c0, argPtr=0x0) at thread.c:186 #3 0x0043f126 in JoinConnThread (threadPtr=0x401c90c0) at serv.c:1000 #4 0x0043ebba in NsConnThread (ignored=0x0) at serv.c:738 #5 0x004d912d in NsThreadMain (arg=0x803af00) at thread.c:225 #6 0x003e7d506137 in start_thread () from /lib64/tls/ libpthread.so.0 #7 0x003e7b9c7113 in clone () from /lib64/tls/libc.so.6 You can safely ignore line numbers in files, just watch the sequence of calls and you get the idea. The problem is the first thread in line is waiting on the condition variable, but the thread that it is supposed to join no longer exists (or so does the core file state). Hence we get the deadlock. I’m not necessarily implying that this is an issue in the nsd code (serv.c or anything else), it could be smth else -- but does anybody seen this kind of behavior before in AOLServer ? Any hint would be helpful. Thanks, Vlad -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] ArsDigita's AOLserver CVS repository
Anyone know where I might find the old ArsDigita AOLserver CVS repositories? Preferably a later one with all the log history intact. Reply directly to me. thanks, /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver Crash!
Rami,
Tcl is attempting to create a new hash table entry on a hash table
that was either never created or was created but has ceased to exist
-- most likely the pointer to that hash table is null or corrupted.
This could be something in AOLserver that uses the Tcl_Hash* API.
First steps:
1. Send a copy of the nslog output for a clean startup through to the
point where it crashes; that might indicate where it's getting fouled
up. If that portion of the nslog is not very long (say no more than
100-150 lines) you can cut and paste into the message; otherwise
attach it as a separate file (but limit it to the smallest necessary
size -- don't want multimegabyte files).
2. Do a checksum of all your own Tcl code files used by AOLserver on a
known good machine and those same Tcl files on the bad one; compare
the two outputs to see what Tcl files on the bad machine differ from
the good one. Investigate those differences.
/s.
On Oct 28, 2008, at 10:48 AM, Rami Jadaa wrote:
Hello Everyone,
We are running multiple instances of AOLserver on different
machines, and I am enjoying the reload functionality to reload the
proc libraries using ns_eval source {fileName} in each one of them...
However, one of the AOLservers crashes after few minutes from the
reload.
The strange thing is that this is the only AOLserver that crashes,
while others don't!!! and I noticed that just before the crash, the
following error happens (which means something in the C breaks, and
I am assuming that it could be in the TCL interpter, Curently tcl
8.4.16 ( not AOLserver...But this is only an assumption):
called Tcl_CreateHashEntry on deleted table
We use this server to serve multiple domains and have a pound load
balancer in the front , For example if the request comes for www.xyz.com
we serve xyz service related site and contents and if the request
comes for www.abc.com we serve abc related contents and site. In
total we are serving around 25 different sites like this . We are
not using any virtual hosting module or feature of Aolserver . The
total traffic of the server is not high .
Any idea anybody!!! Have anyone using the reload functionality
noticed that it could crash the AOLserver?
Environment :
Aolserver 4.0.10 , fetched from CVS almost 6 months back .
nsoracle Oracle Driver version 2.8a1
nsmysql CVS
Oracle 10gR2 Libraries
AMD x86_64 RHEL 4
Curently tcl 8.4.16 also tried tcl 8.4.11
Please help as this is driving me crazy :(
Thanks in advance
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] AOLserver Crash!
It appears that you have the same problem in all of your servers; the
goal is to find out what part of the code is failing and under what
conditions. Three things stand out: failed servers are under a heavier
load than those that don't exhibit the failure; the failure happens
shortly after shifting a load via pound onto an already running
aolserver instance; the failure happens after a reload of your procs
on that server. Since you've said that none of the loads is heavy I
don't think this problem is triggered by aolserver being overwhelmed
with traffic. This leaves two things: the shifting of the load itself
to an already running aolserver instance and the reloading of the
procs on that aolserver instance. I suspect the problem is related to
reloading the procs with ns_eval, and not due to load shifting or load
volume, but we need to confirm that.
Is there a way you can run an aolserver instance directly answering
queries without using pound? Maybe you could set up a test server that
you then use http_load or apache bench on. Once running, hit it with a
load and see if it stays up for at least 10-20 minutes. If it does, do
a reload of your procs on that server without doing anything else --
what I expect is that the aolserver instance will crash shortly after
doing the proc reload. You can then restart the server and try it
again, this time reloading the procs immediately. Then repeat, but
reload the procs after 5 minutes or so. In each case, determine how
long it takes the server to crash after the proc reload (make sure the
aolserver instance has started and continues to server connections
before, during and after the reload).
If anyone else is experiencing the same problems, please post your
information along with your configuration.
/s.
On Oct 29, 2008, at 5:29 AM, Rami Jadaa wrote:
Hi Scott,
Thanks for your reply.
I don't think that I can send the log as it will be so big , as
AOlserver initiates and load a lot of ACS code...
And for the checksum, we did the following:
Using pound, we shifted the load going to this webserver to another
server on another machine where it uses a different local copy of
the same application, and then after the reload, the server were we
shifted the load to crashed, and the old one didn't!!
So i can take out he doubt on file corruption, right?
On Tue, Oct 28, 2008 at 7:50 PM, Scott Goodwin [EMAIL PROTECTED]
wrote:
Rami,
Tcl is attempting to create a new hash table entry on a hash table
that was either never created or was created but has ceased to exist
-- most likely the pointer to that hash table is null or corrupted.
This could be something in AOLserver that uses the Tcl_Hash* API.
First steps:
1. Send a copy of the nslog output for a clean startup through to
the point where it crashes; that might indicate where it's getting
fouled up. If that portion of the nslog is not very long (say no
more than 100-150 lines) you can cut and paste into the message;
otherwise attach it as a separate file (but limit it to the smallest
necessary size -- don't want multimegabyte files).
2. Do a checksum of all your own Tcl code files used by AOLserver on
a known good machine and those same Tcl files on the bad one;
compare the two outputs to see what Tcl files on the bad machine
differ from the good one. Investigate those differences.
/s.
On Oct 28, 2008, at 10:48 AM, Rami Jadaa wrote:
Hello Everyone,
We are running multiple instances of AOLserver on different
machines, and I am enjoying the reload functionality to reload the
proc libraries using ns_eval source {fileName} in each one of them...
However, one of the AOLservers crashes after few minutes from the
reload.
The strange thing is that this is the only AOLserver that crashes,
while others don't!!! and I noticed that just before the crash, the
following error happens (which means something in the C breaks, and
I am assuming that it could be in the TCL interpter, Curently tcl
8.4.16 ( not AOLserver...But this is only an assumption):
called Tcl_CreateHashEntry on deleted table
We use this server to serve multiple domains and have a pound
load balancer in the front , For example if the request comes for www.xyz.com
we serve xyz service related site and contents and if the request
comes for www.abc.com we serve abc related contents and site. In
total we are serving around 25 different sites like this . We are
not using any virtual hosting module or feature of Aolserver . The
total traffic of the server is not high .
Any idea anybody!!! Have anyone using the reload functionality
noticed that it could crash the AOLserver?
Environment :
Aolserver 4.0.10 , fetched from CVS almost 6 months back .
nsoracle Oracle Driver version 2.8a1
nsmysql CVS
Oracle 10gR2 Libraries
AMD x86_64 RHEL 4
Curently tcl 8.4.16 also tried tcl 8.4.11
Please help as this is driving me crazy :(
Thanks
Re: [AOLSERVER] AOLserver Crash!
Hi Juan, That's a good point. I noticed Rami was hosting on 64 bit AMD systems and it is possible that if he were running on a 32 bit architecture the problems he's experiencing might not surface. This could mean a problem with Tcl on 64 bit or something specific to AOLserver. I suspect there are several 64 bit issues with AOLserver that need to be resolved. I'll look into purchasing some 64 bit hardware soon to test with. /s. On Oct 29, 2008, at 7:26 AM, Juan José del Río wrote: Hello, From my experience, I think the problem may be related with the 64 bits. I've servers with AOLServer 32 bits, and AOLServer 64 bits, and I have seen 64 bits growing faster in memory (and even not decreasing through time), until it takes a considerable amount of memory (then I have to restart it). Also, around each 2-3 hours, AOLServer will go wild and eat 100% of one CPU core for around 1 minute... but will continue serving requests slower than usual. My 32 bits server is a FreeBSD 7, and my 64 bits server is an up-to- date Debian Linux. I don't know if it has something to do with the OS or with the 32/64 bits, but the fact is that my Debian Linux 64 bits gives problems that the FreeBSD 32 bits doesn't give. Regards, Juan José - Juan José del Río| (+34) 616 512 340| [EMAIL PROTECTED] Simple Option S.L. Tel: (+34) 951 930 122 Fax: (+34) 951 930 122 http://www.simpleoption.com On Wed, 2008-10-29 at 06:53 -0400, Scott Goodwin wrote: It appears that you have the same problem in all of your servers; the goal is to find out what part of the code is failing and under what conditions. Three things stand out: failed servers are under a heavier load than those that don't exhibit the failure; the failure happens shortly after shifting a load via pound onto an already running aolserver instance; the failure happens after a reload of your procs on that server. Since you've said that none of the loads is heavy I don't think this problem is triggered by aolserver being overwhelmed with traffic. This leaves two things: the shifting of the load itself to an already running aolserver instance and the reloading of the procs on that aolserver instance. I suspect the problem is related to reloading the procs with ns_eval, and not due to load shifting or load volume, but we need to confirm that. Is there a way you can run an aolserver instance directly answering queries without using pound? Maybe you could set up a test server that you then use http_load or apache bench on. Once running, hit it with a load and see if it stays up for at least 10-20 minutes. If it does, do a reload of your procs on that server without doing anything else -- what I expect is that the aolserver instance will crash shortly after doing the proc reload. You can then restart the server and try it again, this time reloading the procs immediately. Then repeat, but reload the procs after 5 minutes or so. In each case, determine how long it takes the server to crash after the proc reload (make sure the aolserver instance has started and continues to server connections before, during and after the reload). If anyone else is experiencing the same problems, please post your information along with your configuration. /s. On Oct 29, 2008, at 5:29 AM, Rami Jadaa wrote: Hi Scott, Thanks for your reply. I don't think that I can send the log as it will be so big , as AOlserver initiates and load a lot of ACS code... And for the checksum, we did the following: Using pound, we shifted the load going to this webserver to another server on another machine where it uses a different local copy of the same application, and then after the reload, the server were we shifted the load to crashed, and the old one didn't!! So i can take out he doubt on file corruption, right? On Tue, Oct 28, 2008 at 7:50 PM, Scott Goodwin [EMAIL PROTECTED] wrote: Rami, Tcl is attempting to create a new hash table entry on a hash table that was either never created or was created but has ceased to exist -- most likely the pointer to that hash table is null or corrupted. This could be something in AOLserver that uses the Tcl_Hash* API. First steps: 1. Send a copy of the nslog output for a clean startup through to the point where it crashes; that might indicate where it's getting fouled up. If that portion of the nslog is not very long (say no more than 100-150 lines) you can cut and paste into the message; otherwise attach it as a separate file (but limit it to the smallest necessary size -- don't want multimegabyte files). 2. Do a checksum of all your own Tcl code files used by AOLserver on a known good machine and those same Tcl files on the bad one; compare the two outputs to see what Tcl files on the bad machine differ from the good one. Investigate those differences. /s. On Oct
Re: [AOLSERVER] Key store for Aolserver?
Hi, Michael, I haven't tested nsopenssl with a wildcard SSL cert but I'm assuming it'll work as I don't think there's anything special that needs to be done in OpenSSL. The keystore capability you're talking about is simply a container to manage keys and certs -- it doesn't provide any special security, though you can (I think) have a password on the keystore as a whole as well as the normal individual passphrases on the private keys stored within it. Private keys for certs on web servers are a problem. If you leave the passphrase on the key on the cert, you either have to store the passphrase in plain text in a startup script or someone has to manually type it in at web server start time. Insecure or inconvenient. Even in a keystore, the keystore password must be available somehow in order for the web server to access and use the key and certificate. So what you need to figure out is how Apache or IIS are able to access the group's key and certificate from the keystore so it can be used. I'll bet the passphrase(s) are stored in plain text somewhere and if that's the case, then you may as well export them from the keystore, strip the key of its passphrase and use them in their regular file format. I've only ever used keys and certs in their normal file format because it's less opaque and because the keys and certificates rarely change. Let me know how you get on, especially if you have any problems with wildcard certs or if I'm mistaken about keystore capabilities. /s. On Oct 31, 2008, at 6:46 PM, Michael Steigman wrote: Hello list, We would very much like to use an organizational wildcard cert with Aolserver which contains a passphrase and is owned/managed by the org's web group. Typically, the web group logs into servers (Windows IIS or Apache is what they support) and installs the certificate once and then again whenever the certificate is renewed. Although this is not my area of expertise, my understanding is that these other platforms utilize a key store. I've asked around a bit within the community and so far, the only suggestion has been to have the group copy the cert to our server and strip the passphrase out via openssl. I'm uncertain whether the group owning the cert will go along with this process so I thought I'd ask the list if there is any other way to handle this situation? Thanks, Michael -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Error code: ssl_error_rx_record_too_long
Héctor,
Try and duplicate the problem with another browser, preferably as many
other browsers as you have available. This will narrow down whether
it's an interaction problem with Firefox in particular or a general
problem. If all the other browsers have no problems yet Firefox still
does, then you might want to review Firefox's SSL settings and try out
different combinations to narrow down what settings in particular
cause this problem. If other browsers exhibit the same error, then
we'd want to know that as well.
Also, state the specific version numbers of all the browsers you test
with, what OS version you tried with each, and if the web site is
available publicly, the specific URL that exhibits the issue so that
others might try it.
/s.
On Nov 3, 2008, at 12:32 PM, Hector Romojaro wrote:
Hi,
I get this error on the browser (firefox) when accessing to certain
ssl
pages, mainly files from dotLRN's content repository.
---
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
---
Accessing to these files by the http port works perfectly. There is no
error on aolserver's log.
Some details:
* dotLRN 2.4.0
* debian GNU/Linux etch amd64
* aolserver 4.0.10 (debian package)
* nsopenssl 3.0beta22 (debian package)
Some data from config.tcl:
#-
# OpenSSL for Aolserver 4
#-
ns_section ns/server/${server}/module/nsopenssl
ns_param ServerPort$httpsport
ns_section ns/server/${server}/module/nsopenssl/sslcontexts
ns_param usersSSL context used for regular user
access
ns_param client SSL context used for outgoing script
socket connections
ns_section ns/server/${server}/module/nsopenssl/defaults
ns_param server users
ns_param client client
ns_section ns/server/${server}/module/nsopenssl/sslcontext/users
ns_param Role server
ns_param ModuleDir /etc/aolserver4/ssl/${server}/
ns_param CertFile server.crt
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite ALL:!ADH:RC4+RSA:+HIGH:
+MEDIUM:+LOW:+SSLv3:!SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace false
ns_param SessionCache true
ns_param SessionCacheID 1
ns_param SessionCacheSize 512
ns_param SessionCacheTimeout 300
ns_section ns/server/${server}/module/nsopenssl/sslcontext/client
ns_param Role client
ns_param ModuleDir ${serverroot}/etc/certs
ns_param CertFile certfile.pem
ns_param KeyFile keyfile.pem
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite ALL:!ADH:RC4+RSA:+HIGH:
+MEDIUM:+LOW:+SSLv3:!SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace false
ns_param SessionCache true
ns_param SessionCacheID 1
ns_param SessionCacheSize 512
ns_param SessionCacheTimeout 300
ns_section ns/server/${server}/module/nsopenssl/ssldrivers
ns_param users Driver for regular user access
ns_section ns/server/${server}/module/nsopenssl/ssldriver/users
ns_param sslcontextusers
ns_param port $httpsport
ns_param hostname $hostname
ns_param address $address
ns_param maxinput [expr 150 * 1024 * 1024] ;# in
bytes
ns_param recvwait [expr 60 * 60] ;# in minutes
#-
Any tips? Need more data?
Cheers, Héctor
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Error code: ssl_error_rx_record_too_long
Thank you for posting the resolution to this problem. The bgdelivery
capability in OpenACS looks interesting, and I noticed this in the
OpenACS bgdelivery code:
ns_log notice AOLserver is not patched for bgdelivery, NOT loading
bgdelivery
Are there patches to the AOLserver executable required to make
bgdelivery possible?
/s.
On Nov 5, 2008, at 8:03 AM, Hector Romojaro wrote:
Hi Scott and all,
Thanks for your quick response. We have found the problem, it was
using
bgdelivery patch with nsopenssl. Gustaf pointed it out and made a fix
for that (thanks Gustaf!).
If anyone has this problem, Gustaf commited the fix to openacs cvs:
http://cvs.openacs.org/cvs/openacs-4/packages/xotcl-core/tcl/bgdelivery-procs.tcl?r1=1.15r2=1.16
Cheers, Héctor
El lun, 03-11-2008 a las 13:30 -0500, Scott Goodwin escribió:
Héctor,
Try and duplicate the problem with another browser, preferably as
many
other browsers as you have available. This will narrow down whether
it's an interaction problem with Firefox in particular or a general
problem. If all the other browsers have no problems yet Firefox still
does, then you might want to review Firefox's SSL settings and try
out
different combinations to narrow down what settings in particular
cause this problem. If other browsers exhibit the same error, then
we'd want to know that as well.
Also, state the specific version numbers of all the browsers you test
with, what OS version you tried with each, and if the web site is
available publicly, the specific URL that exhibits the issue so that
others might try it.
/s.
On Nov 3, 2008, at 12:32 PM, Hector Romojaro wrote:
Hi,
I get this error on the browser (firefox) when accessing to certain
ssl
pages, mainly files from dotLRN's content repository.
---
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
---
Accessing to these files by the http port works perfectly. There
is no
error on aolserver's log.
Some details:
* dotLRN 2.4.0
* debian GNU/Linux etch amd64
* aolserver 4.0.10 (debian package)
* nsopenssl 3.0beta22 (debian package)
Some data from config.tcl:
#-
# OpenSSL for Aolserver 4
#-
ns_section ns/server/${server}/module/nsopenssl
ns_param ServerPort$httpsport
ns_section ns/server/${server}/module/nsopenssl/sslcontexts
ns_param usersSSL context used for regular user
access
ns_param client SSL context used for outgoing script
socket connections
ns_section ns/server/${server}/module/nsopenssl/defaults
ns_param server users
ns_param client client
ns_section ns/server/${server}/module/nsopenssl/sslcontext/users
ns_param Role server
ns_param ModuleDir /etc/aolserver4/ssl/${server}/
ns_param CertFile server.crt
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite ALL:!ADH:RC4+RSA:+HIGH:
+MEDIUM:+LOW:+SSLv3:!SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace false
ns_param SessionCache true
ns_param SessionCacheID 1
ns_param SessionCacheSize 512
ns_param SessionCacheTimeout 300
ns_section ns/server/${server}/module/nsopenssl/sslcontext/
client
ns_param Role client
ns_param ModuleDir ${serverroot}/etc/certs
ns_param CertFile certfile.pem
ns_param KeyFile keyfile.pem
ns_param Protocols SSLv3, TLSv1
ns_param CipherSuite ALL:!ADH:RC4+RSA:+HIGH:
+MEDIUM:+LOW:+SSLv3:!SSLv2:+EXP
ns_param PeerVerifyfalse
ns_param PeerVerifyDepth 3
ns_param Trace false
ns_param SessionCache true
ns_param SessionCacheID 1
ns_param SessionCacheSize 512
ns_param SessionCacheTimeout 300
ns_section ns/server/${server}/module/nsopenssl/ssldrivers
ns_param users Driver for regular user access
ns_section ns/server/${server}/module/nsopenssl/ssldriver/users
ns_param sslcontextusers
ns_param port $httpsport
ns_param hostname $hostname
ns_param address $address
ns_param maxinput [expr 150 * 1024 * 1024] ;# in
bytes
ns_param recvwait [expr 60 * 60] ;# in minutes
#-
Any tips? Need more data?
Cheers, Héctor
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED
Re: [AOLSERVER] Use of the conn argument in a registered proc
You don't actually use the conn argument's value directly. Use ns_conn
to access the connection information. For example,
set url [ns_conn url]
gets you the URL of the HTTP request.
(a totally useless example, but you get the point).
/s.
On Nov 27, 2008, at 12:33 AM, Eric Lee wrote:
I'm trying to set up an ns_register_proc to redirect requests to
what used to be a separate website that now points to mine to a
directory on my site. (The client does not want to use a virtual
server.)
My plan is to test the host of the connection and ns_returnredirect
if it matches the formerly-separate host.
The docs at:
http://panoptic.com/wiki/aolserver/Ns_register_proc
say
The conn argument will be filled automatically with the connection
information.
so I expected it to be an ns_set or array, but it does not seem to be.
It contains cns0 on the first use after a server restart, then
cns1, cns2 on following uses.
Can someone give me a hint how to use the conn argument in:
ns_register_proc GET /* misaEast AAA BBB
proc misaEast { conn {arg1 one} {arg2 two} } {
...
}
I've also tried using [ns_conn host] within the proc but it just
returns . Other ns_conn options, including url and location,
return the expected values. Is there a way around this?
Should what I am trying to do be done a different way?
Thank you,
Eric Lee
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Use of the conn argument in a registered proc
I should take my time and read through the entire message -- I guess
it's rather late.
The HTTP Host information will be located in the request headers which
you can grab and put into an ns_set like this:
set headers [ns_conn headers]
You can then get the HTTP Host header with:
set host [ns_set get $headers Host]
What you're getting with [ns_conn host] is not the HTTP Host header
but rather the host portion of the URL that was requested, e.g. if the
client requested
http://scottg.net/index.adp
[ns_conn host] will return 'scottg.net'
/s.
On Nov 27, 2008, at 12:33 AM, Eric Lee wrote:
I'm trying to set up an ns_register_proc to redirect requests to
what used to be a separate website that now points to mine to a
directory on my site. (The client does not want to use a virtual
server.)
My plan is to test the host of the connection and ns_returnredirect
if it matches the formerly-separate host.
The docs at:
http://panoptic.com/wiki/aolserver/Ns_register_proc
say
The conn argument will be filled automatically with the connection
information.
so I expected it to be an ns_set or array, but it does not seem to be.
It contains cns0 on the first use after a server restart, then
cns1, cns2 on following uses.
Can someone give me a hint how to use the conn argument in:
ns_register_proc GET /* misaEast AAA BBB
proc misaEast { conn {arg1 one} {arg2 two} } {
...
}
I've also tried using [ns_conn host] within the proc but it just
returns . Other ns_conn options, including url and location,
return the expected values. Is there a way around this?
Should what I am trying to do be done a different way?
Thank you,
Eric Lee
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Use of the conn argument in a registered proc
Eric,
You really should be using ns_register_filter instead of ns_return_proc.
ns_register_filter when method URLpattern myScript ?args?
proc myScript {?conn? args why} {
# Do stuff...
}
With ns_register_proc you intercept all matching URLs and *you* must
provide valid responses.
With ns_register_filter you intercept all matching URLs (as with
ns_register_proc), but if you don't want to handle the response
yourself because the Host header doesn't match, you simply return
filter_ok and the server continues to handle the response normally.
When the Host header does match, your proc would do the redirect or
the ns_return or ns_write back to the client and then do a return
filter_return so that the server doesn't continue to process the
connection itself.
/s.
On Nov 27, 2008, at 10:53 AM, Eric Lee wrote:
Thanks for the tip about ns_conn headers, which gets me over the
immediate problem.
My proc is now able to detect a host and ns_returnredirect
successfully.
However if the test for that host fails the proc now returns
nothing, i.e. a page of 0 bytes. What I want it do is just return
the page requested, i.e. just treat the request in the normal way.
If I ns_returnredirect to the original location it gets into a loop
(four requests in access.log) and the browser says:
Firefox has detected that the server is redirecting the request for
this address in a way that will never complete.
What is the correct way to handle this? Does the proc need to
return the entire original page? Would that be [ns_conn content] or
is there more to it than that? The result should be transparent, as
though there were no registered proc involved.
Again, I wonder whether my approach to the initial problem is right.
I'm using AOLserver 4.0.10
Eric
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Suicidal Child Process - SANE
Years ago I connected to AOLserver using nscp and when I was done I would type 'exit' which caused AOLserver to shutdown (there's now a special exit command created within nscp's interp that does a no-op). There might be something similar going on here such that scanimage's termination / signal / error may be leaking through to AOLserver and causing it to quit. See what happens when you use -ignorestderr on exec. /s. On Dec 3, 2008, at 7:23 PM, Ian Harding wrote: This is kind of odd % catch [exec scanimage] foo Terminated When I exec scanimage from inside AOLServer, it goes ahead and shuts down the server. I figured out that it happens when the scanner is on, and ready, but does not have a document in the ADF. From the command line it looks like this $ scanimage scanimage: sane_start: Document feeder out of documents scanimage: Received signal 15 scanimage: Trying to stop scanner scanimage: Received signal 15 scanimage: Aborting There may be a status of some kind I can check from SANE without crashing before I try scanning but I haven't found it yet. Is there any way to prevent this from killing my server in the meantime or is catch the biggest gun I have for that? Thanks, - Ian -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Customized Error Pages
Make sure enabletclpages is set to true in nsd.tcl. By default it is
set to false, meaning that .tcl files won't run from under pageroot.
ns_section ns/server/${servername}
...
ns_param enabletclpages true ;# Parse *.tcl files in pageroot.
...
/s.
On Dec 10, 2008, at 7:46 AM, Wolfgang Winkler wrote:
Hi!
I've installed a vanilla AOLServer 4.5 and I'am trying to customize
the
404 Page.
I've this block in my tcl configuration:
ns_section ns/server/${servername}/redirects
ns_param 404 /notfound.tcl ;# Not Found error page
And a simple
ns_return 200 text/html OK; return
in my corresponding tcl file, but this file is never called.
Has anybody succeeded in creating custom tcl files?
thanks,
wiwo
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] missing access log entries
All connections should be logged as requests that came from clients along with details on how the server responds. Some indication that the connection was aborted should be made in the log, perhaps with a count of how many bytes were transferred. In cases where no response is going to be sent and the connection aborted, the response code shown in the log could be left blank or as a placeholder (e.g. xxx). The general principle is that we always want visibility into what happens with every connection -- in many situations we are serving anonymous clients who aren't going to call and complain or post a trouble ticket, so it's nice to see such aborted conns in the logs as an indication that we might need to investigate what's going on. /s. On Mar 26, 2009, at 2:40 PM, Dossy Shiobara wrote: On 3/26/09 1:31 PM, Andrew Steets wrote: Hello, There are certain cases where connections probably ought to generate access log entries but do not. Specifically if an ADP exits via ns_adp_abort no access log entry will be generated, but data may have been returned to the client. This seems like a bug. I wonder - should this be the documented known behavior of ns_adp_abort vs. ns_adp_return? i.e., abort indicates that the connection is intentionally terminated, not logged, etc. vs. ns_adp_return which halts ADP processing but continues the connection, which includes logging, etc. I'm inclined to agree with you that the current behavior is a bug, but it raises the question: should there be such a function that says this connection wasn't handled, don't even log it - or, should ALL connections always be logged, even if it's aborted? Thanks, Andrew. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] SSL data truncation
John, Tell me what version of OpenSSL you're running. thanks, /s. On Jul 15, 2009, at 5:26 PM, John Caruso wrote: We've run into a bug with AOLserver 4.5.1 / nsopenssl 3.0beta26. The bug is fully documented here: https://sourceforge.net/tracker/?func=detailaid=2822117group_id=3152atid=103152 But the short version is that when using the nsopenssl client-side routines (e.g. ns_httpsget), the result may be truncated if the client starts reading before all of the data has been received. This bug ONLY occurs with an AOLserver client (any version) running against an AOLserver 4 / nsopenssl 3.0beta26 server. We've reproduced the bug on RHEL4, RHEL5, and Mac OS X. The bug is easily demonstrated by copying the file I've attached to this message (sslbug.tcl) to the top-level context of a web server running AOLserver 4.x/nsopenssl 3.0beta26 and then navigating to https:// server/sslbug.tcl. If you comment out the ns_httpsget and use ns_httpget instead, you'll see that the bug disappears. We've done a lot of instrumenting of nsopenssl/AOLserver, but haven't been able to track down the root cause. It seems likely that it's related to data buffering, which seems like it would be occurring within AOLserver or Tcl...but the issue is definitely specific to SSL, which implies that it's something in nsopenssl 3.0beta26. Does anyone have any idea what might be causing this problem? - John -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.sslbug.tcl -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ns_odbc on Win32
Joe did this work during last year's Tcl conference when he couldn't get ns_odbc to compile on his Windows laptop so he could use it during a tutorial. I'm certain he based the changes on the version of ns_odbc in CVS at that time, and I think the changes were mostly to the build process (Makefile). He did not add or delete any functionality; he just got it to compile with a newer Microsoft compiler. He sent me the changes but his message was promptly buried in the dog pile that is my inbox and I haven't even unpacked and looked at what he's done. Though I could try and merge the changes myself, I have zero Windows dev experience and no Windows systems at home or work to build and test it on (and no interest in moving in that direction). But I figured I'd make the changes available to the list so that others would have the opportunity to do the merge, build, test and commit for the rest of the community that runs AOLserver on Windows. /s. On Sep 10, 2009, at 4:43 AM, Tom Jackson wrote: I wonder what the changes were. This driver is missing several API: select and dml (it has exec which can handle both by itself, so maybe they were removed). I have a more complete driver for unixodbc which includes transaction support, and a shutdown callback. If the changes are not that difficult, maybe I could apply them to this version as well (probably a different file for windows). It may not be possible, I can see some internal API differences. Both drivers seem to be derived from a common source Here's the current version of nsunixodbc: http://www.junom.com/gitweb/gitweb.perl? p=nsunixodbc.git;a=tree;hb=18d7 Unfortunately I have nothing setup on windows. tom jackson On Wed, Sep 9, 2009 at 8:42 AM, Scott Goodwinsc...@scottg.net wrote: Joe Mistachkin did some work on ns_odbc (almost a year ago) to get it to compile with newer Microsoft compilers; I've attached the relevant files if someone with Windows experience wants to diff and merge the changes into the module and check-in to AOLserver CVS. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. /s. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] What does 'exiting: exceeded max connections per thread' mean?
The code that each connection thread runs to service a connection is wrapped
within a while loop that starts at whatever you set ns/threads - maxconns to
and counts down to zero. When it reaches 0, a connection thread exits. If
ns/threads - maxconns is set to 0, then your connection threads don't have a
limit on how many connections each one can handle and don't exit because
they've serviced a given number of connections. See the NsConnThread function
in queue.c.
/s.
On Feb 15, 2011, at 9:49 AM, Levy Bajamundi wrote:
Hi,
Since we moved to Aolserver 4.5.1, we've been getting alot of these on our
logs: 'Notice: exiting: exceeded max connections per thread'. Does that mean
that Aolserver is receiving more connections than it can handle? If so, what
would you recommend us do? Our servers are running on Debian Lenny 64bit with
3gb ram.
Here's our configurations file:
set nsthread_stacksize [expr 10*128*1024]
set adp_cachesize [expr 512*1024]
set threads_maxthreads 18
set threads_minthreads 1
...
ns_section ns/server/${servername}
ns_param directoryfile
index.tcl,index.tct,index.vuh,index.atcl,index.adp,index.html,index.htm
ns_param pageroot$pageroot
ns_param enabletclpages true ;# Parse *.tcl files in pageroot.
ns_param maxthreads $threads_maxthreads;# Tune this to scale
your server
ns_param minthreads $threads_minthreads ;# Tune this to scale
your server
ns_param maxconnections [expr $threads_maxthreads * 7] ;# Max
connections to put on queue
ns_section ns/threads
ns_param stacksize $nsthread_stacksize
ns_param mutexmeter true
ns_param maxthreads $threads_maxthreads;# Tune this to scale
your server
ns_param minthreads $threads_minthreads ;# Tune this to scale
your server
ns_param maxconnections [expr $threads_maxthreads * 7] ;# Max
connections to put on queue
Here's our pools.tcl file:
if {[info commands ns_pools] ne } {
set cfgsection ns/threads
set minthreads [ns_config $cfgsection minthreads 0]
set maxthreads [ns_config $cfgsection maxthreads 10]
set maxconns [ns_config $cfgsection maxconns [ns_config $cfgsection
ConnsPerThread 100]]
set timeout[ns_config $cfgsection threadtimeout 120]
set spread [ns_config $cfgsection spread 20]
ns_pools set default -minthreads $minthreads -maxthreads $maxthreads
-maxconns $maxconns -timeout $timeout -spread $spread
set cfgsection ns/server/[ns_info server]
ns_log notice default thread pool: [ns_pools get default]
set minbusythreads [ns_config $cfgsection MinBusyThreads 0]
set maxbusythreads [ns_config $cfgsection MaxBusyThreads 10]
ns_pools set error -minthreads $minbusythreads -maxthreads
$maxbusythreads -timeout $timeout -maxconns $maxconns -spread $spread
ns_log notice error thread pool: [ns_pools get error]
if {[info commands ns_limits] ne } {
if {[set maxinput [ns_config $cfgsection/module/nssock maxinput]] ne
} {
ns_limits set default -maxupload $maxinput
}
set maxwait [ns_config $cfgsection MaxWait 100]
set maxwaittime [ns_config $cfgsection MaxWaitTime 60]
ns_limits set default -maxrun $maxthreads -maxwait $maxwait -timeout
$maxwaittime
ns_log notice default limits: [ns_limits get default]
}
}
Any help would be greatly appreciated.
Thanks,
Levy Bajamundi
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Permissions for ns_adp_include
Check the full path of one of your adp includes that fails with the permissions error and ensure that the owner has read permissions on the file, and that owner has execute perms on all directories in its path. Ownership of a file gives ability to change perms on it, but you can still change the perms so that the file is unreadable by the owning uid. /s. On Feb 21, 2011, at 12:29 PM, Janine Ohmer wrote: I'm setting up a shared server which will have multiple clients logging in, so I'm trying to restrict permissions as much as possible. nsd runs as the user and group that owns the files, so I thought that I could completely turn off permissions for other. However, when I did that ns_adp_include started throwing permission errors. Is there some reason why it requires read permission for other even though the files are owned by the user that nsd is running as? thanks, janine --- Janine Ohmer (formerly Sisk) President/CEO of furfly, LLC 503-693-6407 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
