Re: [AOLSERVER] Git on SourceForge
The main argument for github is that it supports a public collaborative usage of git. Unless we hear otherwise, so far I think we can summarize this thread as: Tom strongly dislikes github. Several other people favor it. The rest don't care or haven't spoken up yet. I personally think github is the way to go. There is a reason it has dominated so many open source projects. The main benefit is visibility: you get visibility into everyone's repositories, while tracking what is the canonical repository. That seems highly valuable to me. Jade Rubick | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 P Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Nov 16, 2010, at 7:57 PM, Tom Jackson wrote: > Truth is: who cares? Unless you want a canonical version of AOLserver. > But that argues against the github model which creates a fork for > every developer. > > Is it possible that I could maintain the sf version of AOLserver which > allows multiple developers to maintain private repositories and commit > changes to sf as needed? Or does the github model require total > submission? > > tom jackson > > On Tue, Nov 16, 2010 at 5:37 PM, Jade Rubick wrote: >> I personally strongly favor github. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Git on SourceForge
I personally strongly favor github. *Jade Rubick* | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 P Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Tue, Nov 16, 2010 at 4:45 PM, Dave Bauer wrote: > On Tue, Nov 16, 2010 at 6:15 PM, Tom Jackson wrote: > > Hi, > > > > Since everyone here knows that I have no ability to be nice, let me > > "git" to the point. > > > > GitHub sucks! > > > > It sucks because it costs money. > > It sucks because it doesn't use gitweb. > > It sucks because of poor user/group management. > > It sucks because it really sucks...hard! > > It sucks because is uses a little too much javascript. > > It sucks because it fucks up search in general (see gitweb). > > > > Basically the interface isn't gitweb and is oriented towards making > money. > > > > I am not sure about your other points, but github is free and > unlimited for open source projects. > https://github.com/plans > Dave > > > -- > Dave Bauer > d...@solutiongrove.com > http://www.solutiongrove.com > > > -- > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLServer Terminal Escape Sequence in Logs Command Injection Vulnerability
Did I read this correctly: this is a remotely exploitable? Jade Jade Rubick | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 P Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Sep 9, 2010, at 5:41 AM, Dossy Shiobara wrote: > As a short-term solution, this is probably adequate, but there's > information loss -- it'd be nice to indicate the original byte sequence > somehow in the log entry by escaping characters so that log analysis > tools could detect such attacks, etc. > > Perhaps the right answer is to log the URI with proper URL-encoding, so > that it would be logged as %1B instead of the literal byte. > > > On 9/9/10 8:18 AM, Gustaf Neumann wrote: >> >> i have just now committed a quick fix for the problem into the >> aolserver/nslog/nslog.c >> into the sourceforge module. please check, if this is in all cases >> sufficient. > > -- > 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 > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Oracle driver update and SF question
I think the best way to do this is to fork the project, then replace it with his code, then commit his diff, and then do a pull request to Dossy. That preserves the history, and allows us to see what Majid's changes are. Jade *Jade Rubick* | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 P Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Fri, Sep 3, 2010 at 3:24 PM, Sep Ng wrote: > Majid, > > I will be more than happy to do it. I just probably need to figure > how and where to git pull. I don't think I have an account however. > > Regards. > > On Sep 4, 5:03 am, Majid Khan wrote: > > Yes just remove what's there because there are multiple/redundant copies > of > > the same file so its very confusing which file is the correct version of > > memcache and about the history, ever since I have imported no one added > any > > patch so there is nothing that we will lose. The code I have sent you is > the > > improved bug free version of nsmemcache which I have never commit to CVS > (my > > bad) nor its documented. > > > > Sep I would want you to please do your test against the one which Dossy > will > > commit. Dossy I haven't prepared any test case, I shall prepare the one > and > > will let you know. > > > > Regards, > > > > Majid. > > > > > > > > On Fri, Sep 3, 2010 at 7:11 PM, Dossy Shiobara > wrote: > > > Is it necessary to remove what's there (and lose the change history) or > > > just commit your changes? Send me what you have and I can commit it, or > you > > > can fork and send a pull request through GitHub. > > > > > Are your changes documented? How can they be tested? Will they conflict > > > with Sep's BUFSIZE patch? > > > > > "Majid Khan" wrote: > > > > > >Hi Dossy, > > > > > >Is it possible to remove the one which you just added on github > because > > > it's > > > >not the clean version which I wanted to add at the time when I ported > for > > > >aolserver and also I have fixed a type casting bug in the code later > on. > > > So > > > >I wanted to import a clean and a stable version of nsmemcache to > github. I > > > >am not sure whether I would be able to import to github but if you > want I > > > >can give you a tar ball of nsmecache and you can import that one. > > > > > -- > > > Dossy Shiobara > > > > > -- > > > 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. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Oracle driver update and SF question
Hi Dossy: If you can import the nsmemcached module, we'll commit Sep's fix for larger sized messages. Jade *Jade Rubick* | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 P Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Wed, Sep 1, 2010 at 6:50 PM, Dossy Shiobara wrote: > FYI, I've imported the nsoracle module into github: > > http://github.com/aolserver/nsoracle > > I'll be slowly importing more and more modules as time goes on. If > anyone desires a particular module imported sooner rather than later, > speak up and I'll try to get to it first. > > -- Dossy > > > On 8/25/10 6:03 PM, Dossy Shiobara wrote: > > Andrew, > > > > Thanks for committing the nsoracle fix! Glad to see you're still > > working with it. > > > > I did start moving the core source to GitHub, but didn't get around to > > moving the modules. I do intend to move them and, by coincidence, will > > be doing work directly on AOLserver starting in September, so I'll > > definitely do it then. Thanks for asking, though. > > -- > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] ADP error
Here's the adp file. Aha, a redirect!
<%
if {![swtm_template_is_default_p] } {
ns_returnredirect [swtm_url "/general/partner/about.tcl"]
return
}
%>
About Volunteer Solutions
Thank you for your help!
Jade
Jade Rubick | Director of Development | TRUiST
2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1
202 903 2564
P Please consider the environment before printing
The information contained in this email/document is confidential and may be
legally privileged. Access to this email/document by anyone other than the
intended recipient(s) is unauthorized. If you are not an intended recipient,
any disclosure, copying, distribution, or any action taken or omitted to be
taken in reliance to it, is prohibited.
On Jul 14, 2010, at 9:13 AM, Peter Sadlon wrote:
> Are you using a redirect such as
>
> ns_returnredirect /file.html
>
> if so, immediately after put:
> ns_adp_abort
>
> When I upgraded from 4.0 to 4.5 my logs were filled with this error as well
> and slowly one by one I was able to fix them, unfortunately the logging
> doesn't really help on trying to find the issue. I would focus on the
> redirect, I found that was the cause of it most of the time. If you can post
> your index.adp or send it to me (f_petra...@hotmail.com) I can take a look
> and see if any other issue seems familiar. It was a few years back since I
> upgraded and had this issue so I don't remember all the fixes off the top of
> my head.
>
> Date: Wed, 14 Jul 2010 08:46:52 -0700
> From: jrub...@truist.com
> Subject: [AOLSERVER] ADP error
> To: AOLSERVER@LISTSERV.AOL.COM
>
> Hi all:
>
> We recently upgraded one of our servers to Aolserver 4.5.1 (from 4.0.10).
> We're seeing a new error we haven't seen before in the error logs:
>
> Error: Tcl exception:
>
>at line 1 of adp file "/web/vs/www/general/index.adp"
>while processing connection #726805:
>GET /uwgs/general/ HTTP/1.1
>Host: volunteer.truist.com
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)
>Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>Accept-Language: en-us
>Accept-Encoding: gzip,deflate
>Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>Keep-Alive: 115
>Connection: keep-alive
>Referer:
> http://www.google.com/search?q=603+436+5554&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
>VS-TEMPLATE-KEY: uwgs
>
> The URL is at:
> http://volunteer.truist.com/general/
>
> (However, the servers are load balanced, so there's no guarantee you'll hit
> the same server).
>
> There does not seem to be a user noticeable error -- it does serve correctly.
>
> Has anyone seen this before? We'd appreciate any advice you may have.
>
> Jade
>
> Jade Rubick | Director of Development | TRUiST
> 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1
> 202 903 2564
>
> P Please consider the environment before printing
>
> The information contained in this email/document is confidential and may be
> legally privileged. Access to this email/document by anyone other than the
> intended recipient(s) is unauthorized. If you are not an intended recipient,
> any disclosure, copying, distribution, or any action taken or omitted to be
> taken in reliance to it, is prohibited.
>
>
>
>
>
>
> --
> AOLserver - http://www.aolserver.com/
>
>
> To Remove yourself from this list, simply send an email to
> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
> field of your email blank.
>
>
> Turn down-time into play-time with Messenger games Play Now!
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> 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
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
[AOLSERVER] ADP error
Hi all: We recently upgraded one of our servers to Aolserver 4.5.1 (from 4.0.10). We're seeing a new error we haven't seen before in the error logs: Error: Tcl exception: at line 1 of adp file "/web/vs/www/general/index.adp" while processing connection #726805: GET /uwgs/general/ HTTP/1.1 Host: volunteer.truist.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://www.google.com/search?q=603+436+5554&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a VS-TEMPLATE-KEY: uwgs The URL is at: http://volunteer.truist.com/general/ (However, the servers are load balanced, so there's no guarantee you'll hit the same server). There does not seem to be a user noticeable error -- it does serve correctly. Has anyone seen this before? We'd appreciate any advice you may have. Jade Jade Rubick | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 P Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] AOLserver on GitHub
Yes, let's officially move it to github. Awesome change! J Jade Rubick | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 Please consider the environment before printing The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Sat, Apr 10, 2010 at 5:12 AM, ayan george wrote: > On 4/10/2010 12:19 AM, Dossy Shiobara wrote: > >> As usual, feel free to flame me for running off into the weeds and just >> doing something without "getting consensus" or "involving the community" >> but I'm hoping at least a few of you will find this work worthwhile. If >> you have any positive comments and/or suggestions, don't hesitate to get >> in touch with me: I'd love to hear what you think. >> >> AOLserver's not dead, yet. ;-) >> >> >> > I think this is an excellent idea. One complaint I have is that you're not > committing to using git-hub -- you're not making it an "official" change. > > Frankly, sourceforge should probably go away as soon as possible (and CVS > along with it). > > My personal preference would have been to host AOLserver on launchpad so I > gently shake my fist at you for not "involving the community". > > Still, I think this is overwhelmingly good news. > > -ayan > > > > -- > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Fatal signal 11 error?
Hi Paul: We found that to debug these, it's best to recompile with debug symbols on -- that way you can get an idea of what is causing the problem. Jade Jade Rubick | Director of Development | TRUiST 2201 Wisconsin Ave NW, Suite 250 | Washington, DC 20007 | www.truist.com | +1 202 903 2564 The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Mon, Sep 7, 2009 at 8:18 AM, Paul Griffiths wrote: > We are running a custom version of acs 4.3 and the aolserver keeps > restarting at random times throughout the day. We noticed this as we have > upgraded to new virtualized hardware. The server comes right back so it's > not evident from a user perspective. > > > > I was looking at the error logs and see that the ‘fatal signal 11’ shows up > just before the restart. (grep 'fatal signal 11' -C 5 error.log) > > > Any insight, experience, or suggestions are welcome. > > > Best, > > > Paul > > > -- > AOLserver - http://www.aolserver.com/ > > > To Remove yourself from this list, simply send an email to > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Is ns_info threads safe to use?
This is code we inherited. Basically it wraps ns_schedule_proc with a job scheduled, that ensures everything has been run, and schedules items that didn't to run again. We could probably rewrite this code, but if there was an easy way to look up the thread id of all current threads, it would save us (quite a bit of) work. Jade Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Tue, Jun 2, 2009 at 6:28 PM, Sep Ng wrote: > Hello everyone, > > I would like to say first of all I appreciate all the thought and > ideas you've brought to the table. What I hope to achieve is to be > able produce a rudimentary load management. I will take a look at > ns_pools and see if I can lift anything from it. Tom, you are right > that AOLserver puts the thread id on the logs and maybe it is worth a > look. > > On Jun 3, 7:37 am, Tom Jackson wrote: > > This is an interesting topic, but I can't think of anything to be gained > > from a list of threads. Who cares that a thread exists? > > > > But if you are just concerned with threads, you can use ns_pools. All > > worker threads in AOLserver are in some named thread "pool". If you > > don't use threadpools, all requests, no matter how many virtual servers > > you use are handled by the "default" threadpool. A query using ns_pools > > can give you a current thread count. > > > > Also you should know that every ns_log (error log) line has information > > about the threadpool and the thread id and every error log has the > > process id "dot" thread id just after the timestamp. If you wrote a > > script to examine the last part of the log file, you could discover > > which threads were active. > > > > Personally I would abandon the use of a list of "living" threads as a > > measure of anything. When AOLserver goes dark threads usually don't go > > away. > > > > tom jackson > > > > > > > > On Tue, 2009-06-02 at 12:12 +0200, Gustaf Neumann wrote: > > > It certainly depends on what your application needs. > > > There is no principal problem obtaining the thread id > > > (eg. ns_thread id, ::thread::id). One could either > > > use the sketched approach and simply record whatever > > > the application needs, or ffone can to extend the > > > xotcl-request monitor to track this information as well. > > > > > just to get the information about running connection > > > threads from the xotcl-request-monitor, use > > > "throttle running". > > > > > best regards > > > -gustaf neumann > > > > > Sep Ng schrieb: > > > > Hi Gustav! > > > > > > Thanks for the info. I'm afraid xotcl-request-monitor may not be > good > > > > enough if I do not have the thread ids, although I guess I could > > > > rewrite it to work with what xotcl-request-monitor provides. > > > > > > I did not know of one such monitoring page on OpenACS. I will take a > > > > look and see what I can find. > > > > > > On Jun 2, 3:42 pm, Gustaf Neumann wrote: > > > > > >> Sep Ng schrieb:> Is there a way in AOLserver to do live monitoring > on > > > > > >>> threads? We're sort of hoping to get info on what thread ids are > > > >>> running as of the moment on aolserver. > > > > > >> The xotcl-request-monitor watches running requests, > > > >> essentially via defining filters/traces for requsts and > > > >> using a monitor thread for keeping track of the > > > >> "starts" and "ends" of requests. If there are "starts" > > > >> recorded without "ends", it knows these requests are still > > > >> running in some threads. This approach does not depened > > > >> on ns_info, we use it on all our production sites. > > > > > >> Originally i had one version for pure aolserver and one for > > > >> OpenACS; since a while i just work on the OpenACS version > > > >> (which is available via the public cvs repository of > > > &g
Re: [AOLSERVER] Question on two AOLserver tickets
Personally, even though I think many in the community don't like Dossy acting without community involvement, I'd rather see something done than nothing, as long as it isn't harming the project. Perhaps the problem is that there is no formal structure for Aolserver, so nobody has the "authority" to act on behalf of the community. What if we had a simple voting application somewhere, and the members of this mailing list each got a vote? J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Sun, May 24, 2009 at 8:04 AM, Dossy Shiobara wrote: > On 5/21/09 4:32 AM, Sep Ng wrote: > >> To be frank, the only reason why I keep using the Trac ticket tracker >> is that it's the one I found. Had I known that the sourceforge ticket >> tracker was the active one, I would have used that one instead. Begs >> to question though... why two ticket trackers? >> > > We started at SourceForge, using the tracker there. At one point, I had > gotten tired of its clumsy interface and wanted to try something else. So, I > went and imported the tickets into Trac to let folks see what it might look > and feel like. > > As an alternative, I'd be happy to import the data into Redmine [1], > another nice open source project management tool that has many of the same > features as Trac. > > [1] http://www.redmine.org/ > > However, I don't want to do the work if the community would rather keep > using the SourceForge tracker. > > I clearly suck at the whole "consensus-building" thing, and AOLserver being > an open source project means until someone steps up to volunteer to do that, > well, it won't get done. I'm more than happy and capable to do the tech > side of things, but time and again it's clear that this project needs a > people person to make sure everyone's happy with the direction things are > going in and I'm not that person. > > > -- > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Question on two AOLserver tickets
4.0.10 J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Fri, May 15, 2009 at 9:08 AM, Jim Davidson wrote: > Hi, > > I'm looking at the head code and it appears it's now safe -- the connection > list is walked with a pool lock held and the request data (method, url) seem > to be copied with a global "reqlock" mutex held. > > Jade: What version of AOLserver are you using? > > > -Jim > > > > > On May 15, 2009, at 10:06 AM, Tom Jackson wrote: > > One thing which would be nice is to put the Tcl API into a module which >> as to be loaded, and keep the C API available in the core. It is >> obviously more work, but the admin has to make a choice to load the Tcl >> API, which is more open to misuse. I did something like this for a few >> additional ns_conn options. >> >> Gustaf's idea is easier to pull off at least initially, but it shouldn't >> be tied to an unrelated option like debugging. I leave on debugging for >> low traffic servers and I can also turn it on/off on a per-namespace >> basis. >> >> tom jackson >> >> On Thu, 2009-05-14 at 15:48 -0700, Sep Ng wrote: >> >>> How about having the proc enable only if debug settings are turned on >>> on AOLserver? >>> >> >> >> -- >> 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Question on two AOLserver tickets
I'm just happy we figured it out. We were using this call: set connections [ns_server active] But it wasn't in a scheduled proc, so I just moved it behind a password protection section, and put a warning around it. We seldom (never) used that page anyway. I think a bot may have found it or something. Jade Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY 10005 USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On May 14, 2009, at 12:33 PM, Jim Davidson wrote: Yup -- should really have been documented better -- sorry about that. Anyway, what is the monitoring attempting to dig up? There may some other safe ways to get the same. -Jim On May 14, 2009, at 2:04 PM, Jade Rubick wrote: Ironically, we have some monitoring code that does use that functionality. So our monitoring is killing our servers. Nice! I'm removing that code now. Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Thu, May 14, 2009 at 10:19 AM, Jim Davidson wrote: Hi, Do you have some sort of background job that calls "ns_server active" (or similar) regularly? That could lead to random crashes. The description in http://dev.aolserver.com/trac/ticket/ 152 is accurate: The code, by design, is not strictly safe as it's assumed to only be used interactively and occasionally as part of debugging and performance monitoring/optimization. To make it safe would require adding mutex locks around areas that are assumed read-only and/or single-threaded which could possibly lead to lock contention. I can't say it those assumptions have ever been proven true or false but that was my thinking when the code was first written. -Jim On May 14, 2009, at 4:16 AM, Sep Ng wrote: Hi, I'm trying to debug an AOLserver crash and the point of crash seems to be AppendConn in NS_GetProcInfo... I will post the stack trace after just for reference. Looking through the ticket tracker on AOLserver, I found two tickets of particular interest: http://dev.aolserver.com/trac/ticket/325 --> My question with this ticket is was it ever resolved? and the second ticket: http://dev.aolserver.com/trac/ticket/152 --> This problem should only happen if the command ns_server was called in a multi-threaded environment, right? Here is the call stack trace I'm working with. I'm more interested in Ticket #325 as it may be related to my problem. - Call Stack Trace - calling call entryargument values in hex location type point(? means dubious value) kpedbg_dmp_stack()+ call B5B81884 B45FFB74 ? 0 ? 219 kpeDbgCrash()+72 call B5B75E14 0 ? 5 ? 0 ? 80BD810 ? B45FFC08 ? B45FFBF0 ? kpeDbgSignalHandler call B5B867B4 0 ? 5 ? B72A331C ? 2 ? 4 ? ()+107 5F ? 4 ? B4600C5D ? skgesig_sigactionHa call B45FFC54 ? B739FFE0 ? ndler()+214 gsignal()+71 signal 6 ? B460110C ? B460118C ? abort()+265 call gsignal()6 ? B460152C ? 0 ? B7FC1E84 ? B4601550 ? B4601564 ? NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ? 30 ? 46 ? B7F565F0 ? B7FC2420 call B ? 33 ? 0 ? 7B ? 7B ? C ? AppendConn()+117 call B7F74E20 B4601AE8 ? C ? 51C5 ? 0 ? 1 ? B7E46FF4 ? NsConnArgProc()+61 call AppendConn() B4601AE8 ? 80B0C1C ? B7FB51A2 ? ? 228E24D8 ? 0 ? Ns_GetProcInfo()+16 call B4601AE8 ? CD298C0 ? 1 B4601A28 ? B7F33C33 ?
Re: [AOLSERVER] Question on two AOLserver tickets
Ironically, we have some monitoring code that does use that functionality. So our monitoring is killing our servers. Nice! I'm removing that code now. Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Thu, May 14, 2009 at 10:19 AM, Jim Davidson wrote: > Hi, > > Do you have some sort of background job that calls "ns_server active" (or > similar) regularly? That could lead to random crashes. The description in > http://dev.aolserver.com/trac/ticket/152 is accurate: The code, by > design, is not strictly safe as it's assumed to only be used interactively > and occasionally as part of debugging and performance > monitoring/optimization. > > To make it safe would require adding mutex locks around areas that are > assumed read-only and/or single-threaded which could possibly lead to lock > contention. I can't say it those assumptions have ever been proven true or > false but that was my thinking when the code was first written. > > -Jim > > > > > On May 14, 2009, at 4:16 AM, Sep Ng wrote: > > Hi, >> >> I'm trying to debug an AOLserver crash and the point of crash seems to >> be AppendConn in NS_GetProcInfo... I will post the stack trace after >> just for reference. >> >> Looking through the ticket tracker on AOLserver, I found two tickets >> of particular interest: >> >> http://dev.aolserver.com/trac/ticket/325 >> --> My question with this ticket is was it ever resolved? >> >> and the second ticket: >> >> http://dev.aolserver.com/trac/ticket/152 >> --> This problem should only happen if the command ns_server was >> called in a multi-threaded environment, right? >> >> Here is the call stack trace I'm working with. I'm more interested in >> Ticket #325 as it may be related to my problem. >> >> - Call Stack Trace - >> calling call entryargument values in >> hex >> location type point(? means dubious >> value) >> >> >> kpedbg_dmp_stack()+ call B5B81884 B45FFB74 ? 0 ? >> 219 >> kpeDbgCrash()+72 call B5B75E14 0 ? 5 ? 0 ? >> 80BD810 ? >> B45FFC08 ? >> B45FFBF0 ? >> kpeDbgSignalHandler call B5B867B4 0 ? 5 ? B72A331C ? >> 2 ? 4 ? >> ()+107 5F ? 4 ? B4600C5D ? >> skgesig_sigactionHa call B45FFC54 ? >> B739FFE0 ? >> ndler()+214 >> gsignal()+71 signal 6 ? B460110C ? >> B460118C ? >> abort()+265 call gsignal()6 ? B460152C ? 0 ? >> B7FC1E84 ? >> B4601550 ? >> B4601564 ? >> NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ? >> 30 ? 46 ? >> B7F565F0 ? >> B7FC2420 call B ? 33 ? 0 ? 7B ? >> 7B ? C ? >> AppendConn()+117 call B7F74E20 B4601AE8 ? C ? >> 51C5 ? 0 ? 1 ? >> B7E46FF4 ? >> NsConnArgProc()+61 call AppendConn() B4601AE8 ? >> 80B0C1C ? >> B7FB51A2 ? >> ? >> 228E24D8 ? 0 ? >> Ns_GetProcInfo()+16 call B4601AE8 ? >> CD298C0 ? >> 1 B4601A28 ? >> B7F33C33 ? >> B4DF4EA1 ? >> B7E46BA0 ? >> ThreadArgProc()+43 call B7F74410 B4601AE8 ? >> B7F8E9B6 ? >> CD298C0 ? >> B7F6337C ? >> CCF7A20 ? >> Ns_ThreadList()+207 call B4601AE8 ? >> B7F8E9B6 ? >> CD298C0 ? 0 ? >> 4A0935D9 ? >>
Re: [AOLSERVER] TLS 1.6 and Aolserver
That makes sense to me. It does basically the same thing as what Sep suggested earlier to disable DH. I'm not sure if there are any problems with doing so, but looking at that bug report, it looks like it might be a good idea. J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY 10005 USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On May 7, 2009, at 3:25 PM, Jeff Hobbs wrote: If Diffie Helmann is the only real issue here, maybe this should also be considered and DH removed by default configure. https://sourceforge.net/tracker/?func=detail&aid=1811445&group_id=13248&atid=313248 Jeff On 06/05/2009 6:45 PM, Sep Ng wrote: Hi Jeff, I'm going to review options on how to progress with this problem with Jade. I've traced and stepped into TlsInit, and CtxInit functions and as far as I can see, the mutex functions we wrote seems to be working. I wonder if there is some influence by aolserver or what not. I don't know. It also seems that allow_customize in CRYPTO_set_mem_functions is getting set to zero for some reason. I'm not totally sure why that is happening. At this moment, I don't know what to do. On May 7, 7:14 am, Jack Schmidt wrote: Hi, Sep here. I just tried by disabling nsopenssl and it crashes at the same point. I suppose this is definitely more related to using aolserver with tls. I've included a backtrace and it shows the same point of failure. We use aolserver 4.0.10, though I'm not sure how relevant it is to the discussion. I'll try to check the startup routine of aolserver and see if I can find anything. 2009/5/7 Jeff Hobbs Is it possible that both nsopenssl and tls are in use, and that they both might be initializing openssl in the same process? I'm not sure if this would be a support case if so. On 05/05/2009 6:16 PM, Sep Ng wrote: Hi Jeff, I took a closer look at the patch you posted. It seems that the CRYPTO_set_mem_functions is not succeeding. The default memory functions that CRYPTO uses are malloc, realloc, and free but from the back trace, it looks like ns_malloc, ns_realloc and ns_free are the ones being used for some reason. I think I'm running out of ideas here. It's unclear why CRYPTO_set_mem_function would return 0 instead of 1, unless it's some bug in my OpenSSL package in Ubuntu. On May 6, 8:42 am, Jack Schmidt wrote: I've just yanked the debug. This includes the backtrace and memory frame info and the local info for most of the frames up until #11 CTX_Init. As before, the crash happens when DH_free is called. 2009/5/6 Jeff Hobbs Of the presented patches, I didn't find one that seemed to actually work, so I wrote one based on those presented. It is attached. Please test it in your environments. I have tested that it passes the basic tls test suite against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that OPENSSL_THREADS was true for this install). This patch is against tls 1.6 head. Jeff On 05/05/2009 3:42 PM, Sep Ng wrote: I'll try it. I didn't give it much thought at first but looking at it again, I think it might prevent the long string of ns_free and other calls to free memory after DH_free. On May 6, 3:43 am, Jeff Hobbs wrote: Just starting to look at this, but from the nsopenssl.c I saw another interesting function not used by TLS: if (CRYPTO_set_mem_functions(ns_malloc, ns_realloc, ns_free) == 0) ... We could do the same and point to Tcl_Alloc, Tcl_Realloc and Tcl_Free. I'm not sure they are necessary, and CRYPTO_set_mem_debug_functions isn't used, but it might help debug. -- 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. -- "A scrum a day keeps the pigs at bay" -- AOLserver -http://www.aolserver.com/ To Remove yourself from this list, simply send an email to with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. bt-without-nsopenssl 17KViewDownload -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to > 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
Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver
Thank you, Andrew. We'll look into that. J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Fri, May 1, 2009 at 12:42 PM, Andrew Steets wrote: > It's not a matter of compiling OpenSSL to be thread safe. Someone > needs to update the TLS C code to call the right OpenSSL API functions > on module initialization. In it's current state I don't see how the > TLS module can safely call OpenSSL from a threaded context. > > From the Openssl docs: > http://openssl.org/docs/crypto/threads.html#DESCRIPTION > > "OpenSSL can safely be used in multi-threaded applications provided > that at least two callback functions are set, locking_function and > threadid_func." > > The TLS C code doesn't setup either one of those callbacks, so that's > a problem. I'm not sure if that is your problem specifically but it > would be a good place to start. > > -Andrew > > On Fri, May 1, 2009 at 12:59 PM, Jade Rubick wrote: > > > > Jade Rubick > > Director of Development > > TRUiST > > 120 Wall Street, 4th Floor > > New York, NY USA > > jrub...@truist.com > > +1 503 285 4963 > > +1 707 671 1333 fax > > > > www.truist.com > > > > > > The information contained in this email/document is confidential and may > be > > legally privileged. Access to this mail/document by anyone other than > the > > intended recipient(s) is unauthorized. If you are not an intended > recipient, > > any disclosure, copying, distribution, or any action taken or omitted to > be > > taken in reliance to it, is prohibited. > > > > > > -- Forwarded message -- > > From: Jack Schmidt > > Date: Thu, Apr 30, 2009 at 4:03 PM > > Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver > > To: Jade Rubick > > Cc: tech > > > > > > I just tried it by recompiling openssl with threads as compiler option > and > > it produces the same problem. Maybe there's another way of making > openssl > > thread safe. Not sure as of the moment. > > > > 2009/5/1 Jack Schmidt > >> > >> It's certainly a possibility. Since I'm also trying to debianize > openssl > >> from Gutsy with debug symbols, we can easily slip in a threaded build. > >> > >> 2009/5/1 Jade Rubick > >>> > >>> Maybe we didn't compile openssl to be threadsafe? > >>> J > >>> > >>> Jade Rubick > >>> > >>> Director of Development > >>> > >>> TRUiST > >>> > >>> 120 Wall Street, 4th Floor > >>> > >>> New York, NY 10005 USA > >>> > >>> jrub...@truist.com > >>> +1 503 285 4963 > >>> > >>> +1 707 671 1333 fax > >>> > >>> www.truist.com > >>> > >>> The information contained in this email/document is confidential and > may > >>> be legally privileged. Access to this email/document by anyone other > than > >>> the intended recipient(s) is unauthorized. If you are not an intended > >>> recipient, any disclosure, copying, distribution, or any action taken > or > >>> omitted to be taken in reliance to it, is prohibited. > >>> Begin forwarded message: > >>> > >>> From: Andrew Steets > >>> Date: April 29, 2009 6:16:14 PM PDT > >>> To: AOLSERVER@LISTSERV.AOL.COM > >>> Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver > >>> Reply-To: AOLserver Discussion > >>> Hello, > >>> > >>> We don't use this TLS package at Wayport, but I have seen similar > >>> errors with OpenSSL before in other applications. I pulled the TLS > >>> code and glanced through it. It doesn't look like you have registered > >>> the locking callbacks for openssl, which means any openssl calls are > >>> not thread safe. That's going to be a problem inside aolserver :-) > >>> > >>> Check out InitOpenSSL() nsopenssl.c (in the nsopenssl module). It > >>> does all the basic stuff you need to
[AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver
Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. -- Forwarded message -- From: Jack Schmidt Date: Thu, Apr 30, 2009 at 4:03 PM Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver To: Jade Rubick Cc: tech I just tried it by recompiling openssl with threads as compiler option and it produces the same problem. Maybe there's another way of making openssl thread safe. Not sure as of the moment. 2009/5/1 Jack Schmidt It's certainly a possibility. Since I'm also trying to debianize openssl > from Gutsy with debug symbols, we can easily slip in a threaded build. > > 2009/5/1 Jade Rubick > > Maybe we didn't compile openssl to be threadsafe? >> J >> >> >> Jade Rubick >> >> Director of Development >> >> *TRUiST* >> >> 120 Wall Street, 4th Floor >> >> New York, NY 10005 USA >> >> jrub...@truist.com >> +1 503 285 4963 >> >> +1 707 671 1333 fax >> >> >> www.truist.com >> >> * >> * >> The information contained in this email/document is confidential and may >> be legally privileged. Access to this email/document by anyone other than >> the intended recipient(s) is unauthorized. If you are not an intended >> recipient, any disclosure, copying, distribution, or any action taken or >> omitted to be taken in reliance to it, is prohibited. >> >> Begin forwarded message: >> >> *From: *Andrew Steets >> *Date: *April 29, 2009 6:16:14 PM PDT >> *To: *aolser...@listserv.aol.com >> *Subject: **Re: [AOLSERVER] TLS 1.6 and Aolserver* >> *Reply-To: *AOLserver Discussion >> >> Hello, >> >> We don't use this TLS package at Wayport, but I have seen similar >> errors with OpenSSL before in other applications. I pulled the TLS >> code and glanced through it. It doesn't look like you have registered >> the locking callbacks for openssl, which means any openssl calls are >> not thread safe. That's going to be a problem inside aolserver :-) >> >> Check out InitOpenSSL() nsopenssl.c (in the nsopenssl module). It >> does all the basic stuff you need to get OpenSSL running in a >> thread-safe manor. >> >> Also: http://openssl.org/docs/crypto/threads.html >> >> If you 'info threads' and see other threads inside openssl crypto >> functions this is almost certainly your problem. >> >> HTH. >> >> -Andrew >> >> On Wed, Apr 29, 2009 at 5:29 PM, Jade Rubick wrote: >> >> Jeff: >> >> Here is a backtrace of the crash with 1.6 stable. Did you need it from >> head? >> >> J >> >> >> Jade Rubick >> >> >> Director of Development >> >> >> TRUiST >> >> >> 120 Wall Street, 4th Floor >> >> >> New York, NY 10005 USA >> >> >> jrub...@truist.com >> >> +1 503 285 4963 >> >> >> +1 707 671 1333 fax >> >> >> www.truist.com >> >> >> The information contained in this email/document is confidential and may >> be >> >> legally privileged. Access to this email/document by anyone other than the >> >> intended recipient(s) is unauthorized. If you are not an intended >> recipient, >> >> any disclosure, copying, distribution, or any action taken or omitted to >> be >> >> taken in reliance to it, is prohibited. >> >> Begin forwarded message: >> >> >> TLS BACKTRACE FROM 1.6 stable (without disabling DH) >> >> Complete backtrace: >> >> (gdb) bt >> >> #0 0xe410 in __kernel_vsyscall () >> >> #1 0xb7cd4875 in raise () from /lib/tls/i686/cmov/libc.so.6 >> >> #2 0xb7cd6201 in abort () from /lib/tls/i686/cmov/libc.so.6 >> >> #3 0xb7ee7a4f in Tcl_PanicVA () from /usr/local/tcl/lib/libtcl8.4.so >> >> #4 0xb7ee7a77 in Tcl_Panic () from /usr/local/tcl/lib/libtcl8.4.so >> >> #5 0xb7ef6b4f in Ptr2Block () from /usr/local/tcl/lib/libtcl8.4.so >> >> #6 0xb7ef7117 in TclpFree () from /usr/local/tcl/lib/libtcl8.4.so >> >> #7 0xb7e9751d in Tcl_Free () from /usr/local/tcl/lib/lib
Re: [AOLSERVER] TLS 1.6 and Aolserver
Thank you, Andrew. We'll check into that. J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY 10005 USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Apr 29, 2009, at 6:16 PM, Andrew Steets wrote: Hello, We don't use this TLS package at Wayport, but I have seen similar errors with OpenSSL before in other applications. I pulled the TLS code and glanced through it. It doesn't look like you have registered the locking callbacks for openssl, which means any openssl calls are not thread safe. That's going to be a problem inside aolserver :-) Check out InitOpenSSL() nsopenssl.c (in the nsopenssl module). It does all the basic stuff you need to get OpenSSL running in a thread-safe manor. Also: http://openssl.org/docs/crypto/threads.html If you 'info threads' and see other threads inside openssl crypto functions this is almost certainly your problem. HTH. -Andrew On Wed, Apr 29, 2009 at 5:29 PM, Jade Rubick wrote: Jeff: Here is a backtrace of the crash with 1.6 stable. Did you need it from head? J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY 10005 USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. Begin forwarded message: TLS BACKTRACE FROM 1.6 stable (without disabling DH) Complete backtrace: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7cd4875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7cd6201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ee7a4f in Tcl_PanicVA () from /usr/local/tcl/lib/libtcl8.4.so #4 0xb7ee7a77 in Tcl_Panic () from /usr/local/tcl/lib/libtcl8.4.so #5 0xb7ef6b4f in Ptr2Block () from /usr/local/tcl/lib/libtcl8.4.so #6 0xb7ef7117 in TclpFree () from /usr/local/tcl/lib/libtcl8.4.so #7 0xb7e9751d in Tcl_Free () from /usr/local/tcl/lib/libtcl8.4.so #8 0xb7f27251 in ns_free () from /usr/local/aolserver40r10/lib/libnsthread.so #9 0xb605c4aa in CRYPTO_free () from /usr/lib/i686/cmov/ libcrypto.so.0.9.8 #10 0xb60890aa in BN_clear_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #11 0xb60b0836 in DH_free () from /usr/lib/i686/cmov/libcrypto.so. 0.9.8 #12 0xa1ffa1e5 in CTX_Init (statePtr=0x139ce5c0, proto=3, key=0x0, cert=0x0, CAdir=0x0, CAfile=0x0, ciphers=0x0) at tls.c:1015 #13 0xa1ff9a72 in ImportObjCmd (clientData=0x0, interp=0x16403240, objc=4, objv=0xa97f96bc) at tls.c:800 #14 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/libtcl8.4.so #15 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #16 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #17 0xb7e9a358 in Tcl_EvalObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #18 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/libtcl8.4.so #19 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #20 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #21 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ libtcl8.4.so #22 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/libtcl8.4.so #23 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #24 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #25 0xb7e9a358 in Tcl_EvalObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #26 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/libtcl8.4.so #27 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #28 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #29 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ libtcl8.4.so #30 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/libtcl8.4.so #31 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #32 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #33 0xb7e93539 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #34 0xb7e9fe07 in Tcl_IfObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #35 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/libtcl8.4.so #36 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #37 0xb7edcccb in Tcl_FSEvalFile () from /usr/local/tcl/lib/ libtcl8.4.so #38 0xb7ea5f16 in
[AOLSERVER] TLS 1.6 and Aolserver
Jeff: Here is a backtrace of the crash with 1.6 stable. Did you need it from head? J Jade Rubick Director of Development TRUiST 120 Wall Street, 4th Floor New York, NY 10005 USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. Begin forwarded message: TLS BACKTRACE FROM 1.6 stable (without disabling DH) Complete backtrace: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7cd4875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7cd6201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ee7a4f in Tcl_PanicVA () from /usr/local/tcl/lib/libtcl8.4.so #4 0xb7ee7a77 in Tcl_Panic () from /usr/local/tcl/lib/libtcl8.4.so #5 0xb7ef6b4f in Ptr2Block () from /usr/local/tcl/lib/libtcl8.4.so #6 0xb7ef7117 in TclpFree () from /usr/local/tcl/lib/libtcl8.4.so #7 0xb7e9751d in Tcl_Free () from /usr/local/tcl/lib/libtcl8.4.so #8 0xb7f27251 in ns_free () from /usr/local/aolserver40r10/lib/ libnsthread.so #9 0xb605c4aa in CRYPTO_free () from /usr/lib/i686/cmov/ libcrypto.so.0.9.8 #10 0xb60890aa in BN_clear_free () from /usr/lib/i686/cmov/ libcrypto.so.0.9.8 #11 0xb60b0836 in DH_free () from /usr/lib/i686/cmov/libcrypto.so. 0.9.8 #12 0xa1ffa1e5 in CTX_Init (statePtr=0x139ce5c0, proto=3, key=0x0, cert=0x0, CAdir=0x0, CAfile=0x0, ciphers=0x0) at tls.c:1015 #13 0xa1ff9a72 in ImportObjCmd (clientData=0x0, interp=0x16403240, objc=4, objv=0xa97f96bc) at tls.c:800 #14 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #15 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #16 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #17 0xb7e9a358 in Tcl_EvalObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #18 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #19 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #20 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #21 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ libtcl8.4.so #22 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #23 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #24 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #25 0xb7e9a358 in Tcl_EvalObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #26 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #27 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #28 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #29 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ libtcl8.4.so #30 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #31 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #32 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #33 0xb7e93539 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #34 0xb7e9fe07 in Tcl_IfObjCmd () from /usr/local/tcl/lib/libtcl8.4.so #35 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #36 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #37 0xb7edcccb in Tcl_FSEvalFile () from /usr/local/tcl/lib/ libtcl8.4.so #38 0xb7ea5f16 in Tcl_SourceObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #39 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #40 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #41 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #42 0xb7ee3cf1 in Tcl_NamespaceObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #43 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #44 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #45 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #46 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ libtcl8.4.so #47 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #48 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so #49 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ libtcl8.4.so #50 0xb7ef05bd in Tcl_UplevelObjCmd () from /usr/local/tcl/lib/ libtcl8.4.so #51 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ libtcl8.4.so #52 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ libtcl8.4.so #53 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ libtcl8.4.so #54 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ libtcl8.4.so #55 0xb7ee13c9 in InvokeImportedCmd () from /usr/local/tcl/lib/ libtcl8.4.so #56
Re: [AOLSERVER] Possible bug in TLS?
Thanks Jeff.
I'll ask Sep to get a stack trace with the newer version. He said he
tried it on HEAD and had the same issue, but he didn't have a copy of
the stack trace.
What happens if you disable Diffie-Hellman?
J
Jade Rubick
Director of Development
Truist
120 Wall Street, 4th Floor
New York, NY 10005 USA
jrub...@truist.com
+1 503 285 4963
+1 707 671 1333 fax
www.truist.com
The information contained in this email/document is confidential and
may be legally privileged. Access to this email/document by anyone
other than the intended recipient(s) is unauthorized. If you are not
an intended recipient, any disclosure, copying, distribution, or any
action taken or omitted to be taken in reliance to it, is prohibited.
On Apr 23, 2009, at 6:58 PM, Jeff Hobbs wrote:
Hi Jade,
Sorry about the delayed response, I was on vacation the last couple
of weeks.
Your code line is not consistent with tls 1.6. I would recommend
trying the latest release first, which has a few mem leak and
cleanup issues noted.
Jeff
On 14/04/2009 10:11 AM, Jade Rubick wrote:
We noticed that whenever we made web services calls (using tsoap)
over https, Aolserver was crashing with a signal 11 (IIRC). We did
a fair amount of debugging, and wanted to ask for some help with
the rest.
After turning debugging on, one of my team members here (Sep)
produced this trace and analysis. Can anyone help us track down if
we've discovered a bug, and if it is safe to disable Diffie-Hellman?
---
Program received signal SIGABRT, Aborted.
[Switching to Thread -1448084592 (LWP 11092)]
0xe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7c68875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7c6a201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7e7aa4f in Tcl_PanicVA () from /usr/local/tcl/lib/libtcl8.4.so
#4 0xb7e7aa77 in Tcl_Panic () from /usr/local/tcl/lib/libtcl8.4.so
#5 0xb7e89b4f in Ptr2Block () from /usr/local/tcl/lib/libtcl8.4.so
#6 0xb7e8a117 in TclpFree () from /usr/local/tcl/lib/libtcl8.4.so
#7 0xb7e2a51d in Tcl_Free () from /usr/local/tcl/lib/libtcl8.4.so
#8 0xb7eba251 in ns_free () from /usr/local/aolserver40r10/lib/
libnsthread.so
#9 0xb5ff14aa in CRYPTO_free () from /usr/lib/i686/cmov/
libcrypto.so.0.9.8
#10 0xb601e0aa in BN_clear_free () from /usr/lib/i686/cmov/
libcrypto.so.0.9.8
#11 0xb6045836 in DH_free () from /usr/lib/i686/cmov/libcrypto.so.
0.9.8
*#12 0xa9910e51 in CTX_Init (statePtr=0x168b7e38, proto=3, key=0x0,
cert=0x0,*
*CAdir=0x0, CAfile=0x0, ciphers=0x0) at tls.c:961*
#13 0xa991084f in ImportObjCmd (clientData=0x0, interp=0x13066570,
objc=4,
objv=0xa9afb6bc) at tls.c:801
#14 0xb7e253c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/
libtcl8.4.so
...
#61 0xb7e25987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
#62 0xb7e25c8c in Tcl_Eval () from /usr/local/tcl/lib/libtcl8.4.so
#63 0xb7e25d26 in Tcl_GlobalEval () from /usr/local/tcl/lib/
libtcl8.4.so
#64 0xb7efbe83 in ProcRequest () from /usr/local/aolserver40r10/lib/
libnsd.so
#65 0xb7ee823b in Ns_ConnRunRequest ()
from /usr/local/aolserver40r10/lib/libnsd.so
#66 0xb7ee99fc in NsConnThread () from /usr/local/aolserver40r10/
lib/libnsd.so
#67 0xb7ebb48f in NsThreadMain ()
from /usr/local/aolserver40r10/lib/libnsthread.so
#68 0xb7ebcb6d in ThreadMain ()
from /usr/local/aolserver40r10/lib/libnsthread.so
#69 0xb7dd346b in start_thread () from /lib/tls/i686/cmov/
libpthread.so.0
#70 0xb7d116de in clone () from /lib/tls/i686/cmov/libc.so.6
That line is:
961 DH_free(dh);
This is the 12th level of the running stack and it's a reference to
DH_free in line 961 in the tls package. I am not certain if this
is the source of all our woes, however, I inspected the code a bit
and it looks like some programmatic error (though it is a wonder
how this is included in multiple releases of tls, I would suggest
talking with the tls mailing list about this... for more
information. I'm eager to find out what and why it causes the crash)
Here's the code at tls.c:
#ifndef NO_DH
{
DH* dh = get_dh512();
SSL_CTX_set_tmp_dh(ctx, dh);
DH_free(dh);
}
#endif
The entire code is, interestingly, wrapped around the NO_DH if-
check, this reads "If NO_DH variable is not define, do the
following". And so the crash happens when the dh pointer is being
freed. What is interesting to point out is that get_dh512() is
defined as:
*static* DH *get_dh512()
{
...
}
I'm not sure how and what the purpose is, but the way I see this is
that the pointer returned is a static DH pointer and we know how
freeing static pointers go.
I rebuilt the tls-head (tls1.5.1) package except I disabled the DH
routines. I inserted this on tls.c, line 75:
#define NO_DH 1
This will toggle tls not to us
[AOLSERVER] Possible bug in TLS?
db in TclExecuteByteCode () from /usr/local/tcl/lib/
libtcl8.4.so
#58 0xb7e55dbc in TclCompEvalObj () from /usr/local/tcl/lib/libtcl8.4.so
#59 0xb7e82d68 in TclObjInterpProc () from /usr/local/tcl/lib/
libtcl8.4.so
#60 0xb7e253c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/
libtcl8.4.so
#61 0xb7e25987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
#62 0xb7e25c8c in Tcl_Eval () from /usr/local/tcl/lib/libtcl8.4.so
#63 0xb7e25d26 in Tcl_GlobalEval () from /usr/local/tcl/lib/libtcl8.4.so
#64 0xb7efbe83 in ProcRequest () from /usr/local/aolserver40r10/lib/
libnsd.so
#65 0xb7ee823b in Ns_ConnRunRequest ()
from /usr/local/aolserver40r10/lib/libnsd.so
#66 0xb7ee99fc in NsConnThread () from /usr/local/aolserver40r10/lib/
libnsd.so
#67 0xb7ebb48f in NsThreadMain ()
from /usr/local/aolserver40r10/lib/libnsthread.so
#68 0xb7ebcb6d in ThreadMain ()
from /usr/local/aolserver40r10/lib/libnsthread.so
#69 0xb7dd346b in start_thread () from /lib/tls/i686/cmov/
libpthread.so.0
#70 0xb7d116de in clone () from /lib/tls/i686/cmov/libc.so.6
That line is:
961 DH_free(dh);
This is the 12th level of the running stack and it's a reference to
DH_free in line 961 in the tls package. I am not certain if this is
the source of all our woes, however, I inspected the code a bit and it
looks like some programmatic error (though it is a wonder how this is
included in multiple releases of tls, I would suggest talking with the
tls mailing list about this... for more information. I'm eager to
find out what and why it causes the crash)
Here's the code at tls.c:
#ifndef NO_DH
{
DH* dh = get_dh512();
SSL_CTX_set_tmp_dh(ctx, dh);
DH_free(dh);
}
#endif
The entire code is, interestingly, wrapped around the NO_DH if-check,
this reads "If NO_DH variable is not define, do the following". And
so the crash happens when the dh pointer is being freed. What is
interesting to point out is that get_dh512() is defined as:
static DH *get_dh512()
{
...
}
I'm not sure how and what the purpose is, but the way I see this is
that the pointer returned is a static DH pointer and we know how
freeing static pointers go.
I rebuilt the tls-head (tls1.5.1) package except I disabled the DH
routines. I inserted this on tls.c, line 75:
#define NO_DH 1
This will toggle tls not to use DH which is part of the libcrypto
library. Now, I'm not sure if my change here effectively disabled
ssh, but it seems to have extracted the soap-response just fine. Like
I said, the ramifications of this change needs the expertise of the
TLS folks.
Either way, this is certainly one way of going about this.
According to SSL, dh is the Diffie-Hellman key agreement
http://openssl.org/docs/crypto/dh.html
More info:
http://en.wikipedia.org/wiki/Diffie-Hellman
After some reading, I'm half-convinced this should not shut down ssl
encryption of packets. The other half is up in the air.
-
Is this a bug in TLS and/or its interaction with Aolserver? And is it
safe to disable Diffie-Hellman?
Jade
Jade Rubick
Director of Development
Truist
120 Wall Street, 4th Floor
New York, NY 10005 USA
jrub...@truist.com
+1 503 285 4963
+1 707 671 1333 fax
www.truist.com
The information contained in this email/document is confidential and
may be legally privileged. Access to this email/document by anyone
other than the intended recipient(s) is unauthorized. If you are not
an intended recipient, any disclosure, copying, distribution, or any
action taken or omitted to be taken in reliance to it, is prohibited.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Caching questions
Why not use this algorithm: 1) check if you have local cached copy, and if the date on it is within xx hours 2) if available, return it. 3) if not, retrieve remote copy. You may have issues with multiple requests hitting at the same time, but otherwise, this seems like it should be doable on almost any platform. Memcached would be an even better solution, but might introduce more latency (the tradeoff would be that you could cache other things later and scale it out very easily). You could test quickly beforehand to see which is faster. Jade Jade Rubick Director of Development Truist 120 Wall Street, 4th Floor New York, NY USA jrub...@truist.com +1 503 285 4963 +1 707 671 1333 fax www.truist.com The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Mon, Apr 6, 2009 at 7:36 PM, Mark Aufflick wrote: > Hi Janine, > > There's no reason you can't run *another* apache instance, just like > you would run a squid instance, in front of the existing tomcat/apache > instance. You would set up this new apache instance as a caching > proxy. Squid or pound might be a little faster, but in crazy setups > like this you get a lot of flexibility using apache. > > The tomcat/apache integration, as you say, is pretty minimal. So you > could also skip the intermediate apache completely to get this sort of > setup: > > * Tomcat running standalone (on, say, localhost port 8000). > * Apache, running as a caching reverse proxy using mod_cache, > mod_proxy and mod_rewrite, listening on port 80, forwarding the > requests to port 8000. > > This is exactly the same setup you would use if you wanted a caching > apache proxy to sit in front of aolserver instances. > > As Bas says, memcached is a great solution, but that would require > code changes to the java code which may be unpalatable :) > > Mark. > > On Tue, Apr 7, 2009 at 3:04 AM, Janine Sisk wrote: > > I have a really screwy setup and am looking for some advice. > > > > I have an AOLserver site running a not-very-recent version of OpenACS > with a > > custom CMS I did not write. It serves up a site written entirely in > > Traditional Chinese. I also have a java servlet which takes a page from > > that site and translates it into Simplified Chinese. So URLs are like > this: > > > > Traditional - http://big5.mysite.com/public/index > > Simplified - http://gb.mysite.com/gate/gb/big5.mysite.com/public/index > > > > The latter goes to a Tomcat site which requests the specified page from > > big5.mysite.com, translates it, and returns it. > > > > As you can imagine, this is not fast. I'm working on convincing the > client > > that what we really need to do is make a static HTML version of the > > Simplified site, which gets updated when they update content, and serve > that > > directly. Ultimately I'm pretty sure that's what we'll end up doing. > But > > first I have a tech guy on their end who thinks caching is the way to go, > > and I need to try that before they'll let me implement my own solution. > > > > He thought I should just slap Apache in front of all this and use > mod_cache, > > but that was a dead end. Since Apache doesn't actually serve any > content > > in this scenario but merely hands off to Tomcat, there is nothing for it > to > > cache. > > > > I've done some googling on Tomcat and caching but there don't seem to be > any > > add-ons for it. They say it does some caching by default but I'm not > seeing > > it, maybe because I'm not using any JSPs. This is my first foray into > Java > > programming so it's all new to me. > > > > I know that some people use Squid as a caching proxy in front of > AOLserver, > > but I'm not sure if that would solve my problem or not. > > > > Any suggestions out there? > > > > thanks, > > > > janine > > > > --- > > Janine 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 > > with the > > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > Subject: > > field of your email blank. > > > > > > -- > Mark Aufflick > contact info at http://mark.aufflick.com/about/contact > > > -- > 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 with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Data "corruption" with fastpath caching
Consider this use case: - You use git or another version control system to store for a bunch of static html files you serve with Aolserver. - You check out all of your static html files. Because they're all checked out at the same time, many of them have identical timestamps. Could the user get the wrong version of an html file they're being served? What about this scenario: - You have a web application that allows administrators on various sites hosted on your application to download a list of user names and passwords (this is a slightly contrived example). They can download it to CSV. - Admin #1 generates this file. You create a unique filename for their site_id, because you want a unique filename to return back to the user: site-1234-passwords.csv. You return this file to the admin. - Admin #2 generates their file. You create a unique filename for their site_id, because you want a unique filename to return back to the user: site-5000-passwords.csv. You attempt to return this file to the admin. Because their request was in the same second, however, they get site-1234-passwords.csv? Do I understand the problem correctly? I think both of these scenarios are pretty common examples of the way people use Aolserver currently, but I'm not sure if I'm understanding correctly the bug. Jade Jade Rubick Director of Development Truist 120 Wall Street, 4th Floor New York, NY USA [EMAIL PROTECTED] +1 503 285 4963 +1 707 671 1333 fax The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Mon, Aug 18, 2008 at 4:20 PM, John Caruso <[EMAIL PROTECTED]>wrote: > On Monday 03:38 PM 8/18/2008, Jeff Rogers wrote: > >> While I'd agree this is a bug in fastpath, the real problem is that >> fastpath is being used at all in this case. The intent of fastpath is to >> avoid reading a seldom-changed file from disk. >> > > I'd agree that that's the intent, but the caching is hidden within > ns_returnfile and it's not clear at all from the user's perspective that > this alligator is lurking in the swamp. Using ns_returnfile in this way may > not be the best approach in any particular situation, but it's nonetheless a > completely valid usage and isn't contraindicated in any AOLserver docs I've > seen. > > It's not difficult to come up with examples where it might happen, > BTW...say, a web service that returns the result of an operating system > command to a user. > > I think Jade makes a good point that this is not only a bug but potentially > a security issue. > > It happens to be used in ns_returnfile since that is the normal use case. >> On unix the fastpath cache is keyed off the dev/inode probably to keep the >> hash key shorter. Windows doesn't have device and inode numbers so it uses >> the filename as the hashkey, so it wouldn't run into this problem. >> > > No, it can still easily run into this problem--it's just that the file name > needs to be the same in both cases (which actually did apply in my client's > case, and caused confusion in the early debugging of the problem, since the > assumption was that using the same file name and/or path name was the source > of the problem). > > From the server side, this could be fixed by: >> - adding in the filename to the hash key or checking that it is the same >> > > No go, as observed above. > > - making ns_unlink flush the entry from the fastpath cache >> > > Nope, since the file can be removed via (e.g.) exec rm. > > - restricting what fastpath will cache - e.g., don't cache anything in >> /var/tmp or /tmp or a configuration-specified directory. >> - adding a "-nocache" flag to ns_returnfile >> > > This last is the one I'd considered as well, but the problem is that it > puts the onus on the user to know that they should use the flag, and that's > unlikely to be clear to them. > > I don't think your suggestion of waiting for cache entries to age a second >> or two would work well, it just moves the race condition around and adds a >> whole lot of disk activity when a busy server is warming up - static files >> might be read a few dozen times instead of once. >> > > Nope, not at all. The only files that would get read more than once would > be those that were served within one second of being generated--which > wouldn't apply to any content that fits the definition o
Re: [AOLSERVER] Data "corruption" with fastpath caching
I would call that a security issue then. Leaking the wrong data to the wrong connection is pretty serious. Jade Jade Rubick Director of Development Truist 120 Wall Street, 4th Floor New York, NY USA [EMAIL PROTECTED] +1 503 285 4963 +1 707 671 1333 fax The information contained in this email/document is confidential and may be legally privileged. Access to this mail/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited. On Mon, Aug 18, 2008 at 2:13 PM, John Caruso <[EMAIL PROTECTED]>wrote: > On Monday 01:33 PM 8/18/2008, Tom Jackson wrote: > >> It's not be a data corruption issue >> because you are choosing to overwrite the old data with new data using >> the exact same file name. If the data is important, don't overwrite it, >> thus no corruption. >> > > No, you've misunderstood the scenario. The file name needn't be the same > to trigger this issue, and the "corruption" doesn't come from serving data > out of a file that's changing, but rather because fastpath caching > mistakenly identifies a new file as being identical to a previously-cached > file (for the reasons I outlined) and erroneously serves the > previously-cached data to the user. > > This is a design limitation and arguably a bug in the fastpath caching > implementation, which is potentially quite serious since it silently serves > the wrong data to the user. If you want a more straightforward (albeit > contrived) demonstration of the problem, here you go: > > set file [open "/var/tmp/myfile" "w"] > puts $file "ABC123" > close $file > ns_returnfile 200 text/plain "/var/tmp/myfile" > ns_unlink -nocomplain "/var/tmp/myfile" > > set file [open "/var/tmp/myotherfile" "w"] > puts $file "XYZ987" > close $file > ns_returnfile 200 text/plain "/var/tmp/myotherfile" > ns_unlink -nocomplain "/var/tmp/myotherfile" > > Assuming that /var/tmp/myfile and /var/tmp/myotherfile are created within > the same second, the fastpath caching algorithm will misidentify them as the > same file, and ns_returnfile will therefore erroneously return the > (previously cached) contents of /var/tmp/myfile when it should be returning > the (uncached) contents of /var/tmp/myotherfile. > > > - John > > > -- > 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_db and bind variable support
Can someone explain why we need prepared statements? I thought by using bind variables, we avoid the SQL parse time (at least with Oracle, that's my understanding) if you're using the same SQL but with different values in your bind variables. Jade On Wed, Apr 16, 2008 at 7:00 PM, Dossy Shiobara <[EMAIL PROTECTED]> wrote: > In web applications, one of the big performance hits is SQL query parse > time. The irony is, in web applications, the queries aren't really > dynamic: most can be parsed once, and different bind variable values > used at execution time. > > -- Jade Rubick Senior Architect United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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 and Pgtcl
The other is performance. Jade On Wed, Apr 16, 2008 at 5:40 PM, Bas Scheffers <[EMAIL PROTECTED]> wrote: > I would never say that; not having to worry about quoting is one of the > main advantages of using bind variables/parameters. > > Bas. > > > > -- > 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. > -- Jade Rubick Senior Architect United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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_QueueWait
These type of comments would be great to get into the source code. Jade On Wed, Apr 16, 2008 at 11:19 AM, Jim Davidson <[EMAIL PROTECTED]> wrote: > Hi, > > I'm glad you noticed Ns_QueueWait. It was designed to address one of the > most common scalability problems we had noticed at AOL where threads get > backed up waiting for a response from a remote resource (e.g., REST or SOAP > result). The idea (as mentioned in the change note below) is that you wait > for I/O events to complete, accumulate all the potentially slow remote stuff > before queuing the request for processing, using "connection local storage" > as needed to hold the remote data. > > Sadly, only the low level API was written. Adding a more convenient HTTP > interface that you could then add REST or SOAP things on top would make > sense but wasn't done. It's possible you could write a simple Tcl wrapper > -- the callbacks would look like Tk callbacks. However, you'd need to be > careful using it and understand that the Tcl interp used for the queue wait > callbacks would not be the same as the Tcl interface used later plus there's > the trouble mapping Tcl I/O objects to something you can wait on with a call > to select() or poll(). Thinking about it now as I'm typing, perhaps a > smarter solution would have been to use the Tcl event loop in a 2nd > dedicated thread: Requests would be read with the current AOLserver I/O > event loop and then passed to a Tcl event loop if needed before being queued > for execution by a dedicated thread. Hmm > > -Jim > > > > > > On Apr 14, 2008, at 8:15 PM, Tom Jackson wrote: > > Since Jim Davidson is somewhat monitoring the newsgroup at the moment, I > > want > > to take advantage... > > > > One new feature of AOLserver 4.5 is the Ns_QueueWait API: > > > > > > Ns_QueueWait: > >New interface to enable event-driven callbacks in the driver > >thread before dispatching to pools for processing. This > >allows drivers to augment data received from the client > >(headers, request, content) with additional data fetched > >over the network (likely stored in connection-local storage > >via Ns_Cls). An example would be to add certain personalization > >data received via a Web service. The benefit of this approach > >is to accumulate additional data efficiently with driver-thread > >based event callbacks instead of through potentially blocking > >calls within connection threads. > > > > > > My first question is if there are any examples of using this interface? > > > > Second is just a note to Jeff Rogers: this looks like a plugin interface > > that > > could work for your application. > > > > tom jackson > > > > > > -- > > 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. > -- Jade Rubick Senior Architect United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Compression
I agree this sounds like a good approach. On Tue, Apr 15, 2008 at 12:45 AM, Mark Aufflick <[EMAIL PROTECTED]> wrote: > On Tue, Apr 15, 2008 at 3:55 PM, Tom Jackson <[EMAIL PROTECTED]> wrote: > > So the question is how to handle static files. One idea is to check if > > compression is enabled, if so, check if a compressed file exists > > (file.ext.gz), use the uncompressed file to figure out the content > type, and > > return the compressed file (assuming the client sends the correct > headers). > > -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Compression
Is anyone volunteering to do this work (provided there is agreement)? If not, this entire discussion is pointless. Jade On Sun, Apr 13, 2008 at 5:14 AM, Dossy Shiobara <[EMAIL PROTECTED]> wrote: > On 2008.04.13, Don Baccus <[EMAIL PROTECTED]> wrote: > > Or just put back the config parameters as they were, they worked fine > > for everyone for a decade. I don't remember the masses shouting that > > the config approach wasn't sufficient. It suddenly appeared without > > discussion nor documentation. > > Uh, either your memory is poor or you need to review the mailing list > archives again. > > The number of times people have asked "can I change [a particular > setting] without requiring a nsd restart" and have been given the answer > "no, config changes require a server restart" has indirectly suggested > that if we can move something out of the config and into the runtime > environment, it would be preferred as people ask for it repeatedly over > time. > > Being able to tweak and tune thread pools at runtime has come up many, > many times. Each time, the answer is: change the config setting and > restart, which usually wasn't desirable because restarts during the day > on a production system weren't something folks could do ad-hoc, as they > were running a single server, not load-balanced ... > > Seriously, this has been a long-standing ask, to make more config > settings modifiable at runtime. Perhaps the way compression has been > implemented wasn't perfect, but it was a start, and I think Jeff's > suggestion of shipping a filter proc that enables compression > server-wide by default is the right answer. Making the setting purely > config-driven is just perpetuating the "sorry, config settings need > restarts" problem. > > -- > 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. > -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Minor facelift to aolserver.com
I thought the beta thing was hilarious. Aolserver is one of the most rock-solid pieces of software I've used. But I half-agree with Juan (and I know he's joking!) Jade On Tue, Apr 8, 2008 at 2:26 PM, Juan José del Río (Simple Option) < [EMAIL PROTECTED]> wrote: > Yes, but: > > - But "Beta" seems to attract so many people to certain > technologies/software... Even if some people don't like new people, they > are somehow needed. We'll die someday. We need someone to take over our > tasks. > > - We can say that it's 1% beta. Sure there's something that still > crashes from time to time! If not, let me upload some patches, and > you'll see... lol > > > > Note: I am half kidding, half serious. > > > - > Juan José del Río| Comercio online / e-commerce > (+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 Tue, 2008-04-08 at 13:52 -0700, Rick Cobb wrote: > > Well, it's certainly compliant :-), but I suspect Mr. Jackson would > object. > > If there's one thing aolserver ain't, it's "beta". > > > > -- ReC > > > > -Original Message- > > >From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On > Behalf Of Juan José del Río (Simple Option) > > Sent: Tuesday, April 08, 2008 12:44 PM > > To: AOLSERVER@LISTSERV.AOL.COM > > Subject: Re: [AOLSERVER] Minor facelift to aolserver.com > > > > What about this?! > > > > - > > Juan José del Río| Comercio online / e-commerce > > (+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 Tue, 2008-04-08 at 14:29 -0400, Dossy Shiobara wrote: > > > On 2008.04.08, Brett Schwarz <[EMAIL PROTECTED]> wrote: > > > > I threw this together http://www.bschwarz.com/aolserver.jpg with > Gimp.. Now, I'm not a graphic's wiz, but I thought I would create something > basic that we can start with, as a way to get to the design we want. I would > be willing to *try* to make any suggested enhancements, but like I said, I > am no graphics designer. Perhaps this will spark some momentum. > > > > > > It's awesome. Very Web 2.0 (gradient, reflection) ... an orange > > > starburst and a swoosh would fully trick it out as a Web 2.0 > treatment. > > > Heh. > > > > > > I've used the logo. Can you send me the GIMP .xcf file for it? > > > > > > > BTW, are there any legal matters that we need to be concerned with > in > > > > creating a logo for aolserver? > > > > > > Good question. I really should have a serious conversation with AOL > > > Legal about this issue. I'm hoping that as long as we stay away from > > > the actual AOL logo treatment itself, we'll be okay ... but I'd like > to > > > get that in writing. > > > > > > > > > > > > -- > > 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. > -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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_db and multibyte support
I echo Bas here. The only issue I've ever had is when writing to or reading from files. You have to specify the encoding. Jade On Thu, Apr 3, 2008 at 3:14 PM, Cynthia Kiser <[EMAIL PROTECTED]> wrote: > On Apr 2, 2008, at 5:42 PM, Bas Scheffers wrote: > > > > > The only issues I ever faced was (CSV) file uploads, where the data > > needed to be extracted and put into the database. This could contain any > > encoding without me knowing. In practice it only ever contained stupid > > Windows encoding, so I assumed that to be the case and used Tcl's convert > > functions. > > > > H CSV + "stupid Windows encoding". Bas perhaps you have just what I > need for a character set issue. I have a data file - actually delimited by > upsidedown exclamation points, not commas. It comes from a Windows box - > apparently with the Windows 1252 character set. I am trying to load that > data into Oracle. I was trying to use SQLLDR to do that but am having > debugging issues. I *think* I have the correct character set info and octal > representation for ¡. But something is funky. > > It never occurred to me to try parsing this with Tcl instead. Is there an > AOLserver or straight Tcl module I should be using to parse pseudo-CSV? Or > is the answer keep it simple and just read lines and split on ¡ with > 'split'? > > > > -- > 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. > -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] SQL placeholders
You can probably just steal the db code from OpenACS. Jade On Wed, Apr 2, 2008 at 1:44 PM, Andrew Piskorski <[EMAIL PROTECTED]> wrote: > On Wed, Apr 02, 2008 at 02:39:57PM +0100, Xavier Bourguignon wrote: > > Ok, so how do I get this OpenACS db_* AP to work? > > You would have to install OpenACS: http://openacs.org/ > > However, if you are currently using AOLserver stand alone, that's > probabably not what you want to do, not just in order to use its db > API anyway (even though it is very nice). > > You may also find these old discussions of interest: > > http://openacs.org/forums/message-view?message_id=206909 > http://openacs.org/forums/message-view?message_id=195785 > http://openacs.org/forums/message-view?message_id=85687 > > -- > 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. > -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Google Summer of Code
God that would awesome. Jade On Thu, Feb 28, 2008 at 6:15 PM, Dossy Shiobara <[EMAIL PROTECTED]> wrote: > On 2008.02.28, Jeff Hobbs <[EMAIL PROTECTED]> wrote: > > AOLServer is dying to be rewritten as a small shim on core Tcl. ;) > > Don't laugh, but when Jim Davidson and I spoke about AOLserver 5.0, that > was one of the directions we were seriously considering, turning > AOLserver into a series of packages to be loaded into core Tcl. > > It's still a possibility, although it raises the question of whether the > investment in effort would be worth it, at this point. > > -- 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. > -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] About memcached
I mean that yes we are interested, and if you could please put it in the Aolserver repository or commit your changes, that would be awesome. If you need access, I'd ask Dossy. Jade Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] w: 503.285.4963 f: 707.671.1333 http://www.UNITEDeWAY.org On Jan 16, 2008, at 4:25 AM, Majid Khan wrote: Yes please. I have downloaded the latest code (1.4 ver) from naviserver repository http://naviserver.cvs.sourceforge.net/naviserver/modules/nsmemcache/ & modified the code socket functions according to AOLServer sock. For those who want to compile for AOLServer 4.5, see the comments in nsmemecace.c file from line no 189 to 192 I have tested this module for AOLServer 4.0.10 and its working fine. README is at naviserver repository, download that and check how you can use the ns_memcache functions. If some one is putting up in a proper repository directory/folder then please download the LICENSE , README and all the files which I have attached and put them in AOLServer folder. Regards, Majid On Jan 15, 2008 9:06 PM, Jade Rubick <[EMAIL PROTECTED]> wrote: We are interested. We should put this in the repository? Jade Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] w: 503.285.4963 f: 707.671.1333 http://www.UNITEDeWAY.org On Jan 15, 2008, at 4:52 AM, Majid Khan wrote: Hi All, I have ported the Vlad's nsmemcache module for Naveiserver to work with AOLserver module. Its working fine for small chunk of data but for large chunks of data the behavior is not same, there are some problems which I have mentioned to Vlad. If some one is interested in compiling that C code for AOLServer then please let me know so that I can send all those files as an attachment to this mailing list . Thanks. Best Regards, Majid Khan -- 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] About memcached
We are interested. We should put this in the repository? Jade Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] w: 503.285.4963 f: 707.671.1333 http://www.UNITEDeWAY.org On Jan 15, 2008, at 4:52 AM, Majid Khan wrote: Hi All, I have ported the Vlad's nsmemcache module for Naveiserver to work with AOLserver module. Its working fine for small chunk of data but for large chunks of data the behavior is not same, there are some problems which I have mentioned to Vlad. If some one is interested in compiling that C code for AOLServer then please let me know so that I can send all those files as an attachment to this mailing list . Thanks. Best Regards, Majid Khan -- 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] Logging
We use logresolvemerge.pl which is included with AWStats. Jade On 9/17/07, Jeff Rogers <[EMAIL PROTECTED]> wrote: > > Ian Harding wrote: > > Is there any sane way to get combined logs from more than one instance > > of AOLserver? I would like to have the entries interleaved with an > > identifier of which instance they came from. > > > >>From what I have read it seems impossible. > > > > These instances are on different physical servers too. > > > > Thanks, > > > > Ian > > One way to address this issue with apache is mod_log_spread which sends > log messages over the spread group communications toolkit[1]. It > wouldn't be difficult to set up something similar for aolserver. I > don't know offhand if the tcl spread library is threadsafe (I suspect it > isn't), but it would probably be better in any case to redo it as a > ns_spread module that would share one spread connection across all > threads. Still, the api is straightforward and the implementation would > fairly simple. Once that's in place just use a filter proc to log to > the spread channel. > > Another route would be to use syslog; I'm not familiar with any tcl libs > for that, but again a C implementation wouldn't be too tough. > > -J > > [1] http://spread.org/ > > > -- > 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. > -- Jade Rubick Acting Chief Information Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Speaking of nsdci...
Is it used in production? Is there a plan to do any further development or documentation for it? Jade On 8/8/07, Nathan Folkman <[EMAIL PROTECTED]> wrote: > > It hasn't been "officially" released or announced as of yet. Tt's in more > of an initial development release phase at the moment. Still lots of > documentation to be done. There is currently no roadmap or timeline to share > with everyone either at this time. > > - n > > On 8/8/07, Rick Cobb <[EMAIL PROTECTED]> wrote: > > > > I see it on Google Code ( http://code.google.com/p/nsdci/), but not on > > the modules wiki (http://panoptic.com/wiki/aolserver/Modules#Miscellaneous > > ); I'll add it, but wondered why it wasn't there? What's its status? > > > > > > > > -- ReC > > > > > > -- > > 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. > > > > > > > -- > Nathan Folkman > [EMAIL PROTECTED] > > > -- > 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. > > -- Jade Rubick Senior Developer United eWay Volunteer Solutions [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] async background delivery
What's nice about this model is that you can plug in external content hosting services quite easily. Jade On 8/8/07, Tom Jackson <[EMAIL PROTECTED]> wrote: > > I know it doesn't require any patches, but you can offload your image > server > pretty easily, very efficiently as follows: > >height="33" width="246"> > > Where Template(gserv) is set for each page request, obviously this could > be as > simple or complex as needed. In this case I offload the graphics to > another > port and serve with publicfile. Don't know if this is faster or not, but > it > doesn't require running through a lot of application code just to serve up > a > public image. Maybe the pure tcl image server would work just as good? > > But you can't offload with an https service since the files should come > from > the same ip:port, or at least this used to be required. > > Example is for > http://saleonall.com/cat/allcat.html > and > https://saleonall.com/cat/allcat.html > > One thing the AOLserver community can offer is examples like this of how > to do > something pretty commonly needed as a website grows in size. > > Last week I had example of using threadpools to serve image files (either > old > or new version would work in this case). If there was a way to configure > the > interps in these threads, you could create a series of micro-servers > targeted > to the content being delivered. > > tom jackson > > On Wednesday 08 August 2007 12:12, John Buckman wrote: > > >> as far as what lighthttpd and mathopd are doing to get better speeds, > > >> is that they both are not multithreaded, they are just a single async > > >> loop, serving static files. I remember that this was an option in > > >> Aolserver v2, but I believe it went away in v3. > > > > > > Gustaf Neumann of WU-Wien patched AOLserver to do asynchronous > > > background delivery, and has been using the feature heavily since > > > 2005: > > > > > > http://openacs.org/xowiki/weblog-portlet?ptag=asynchronous > > > http://openacs.org/forums/message-view?message_id=482221 > > > > Very nice. The only thing I'd change would be to have this not > > require Tcl, but rather to have registered file types that are > > automatically sent via the async method (ie mp3/zip) > > > > So, what's involved with having the patch applied to cvs? > > > > -john > > > > > > -- > > 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. > -- Jade Rubick Senior Developer United eWay Volunteer Solutions [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] nsoracle on aolserver 4.5
Has anybody successful compiled nsoracle against Aolserver 4.5? [/usr/local/web/software/aolserver/nsoracle-head-2007-05-11]: /usr/bin/sudo make install AOLSERVER=/usr/local/aolserver45 gcc -pipe -I/rdbms/demo -I/rdbms/public -I/network/public -I/plsql/public -O2 -Wall -Wno-implicit-int -fno-strict-aliasing\ -fPIC -I/usr/local/aolserver45/include -I/usr/local/tcl/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_IS_LONG=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAV\E_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DHAVE_GETPWUID_R_5=1 -DHAV\E_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_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_ST\RINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_TIMEGM=1 -DHAVE_DRAND48=1 -DH\AVE_RANDOM=1 -DHAVE_POLL=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETNAMEINFO=1 -c -o nsoracle.o nsoracle.c In file included from nsoracle.c:16: nsoracle.h:19:17: error: oci.h: No such file or directory In file included from nsoracle.c:16: nsoracle.h:50: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'oci_status_t' nsoracle.h:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'oci_handle_t' nsoracle.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'oci_attribute_t' nsoracle.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'oci_param_t' nsoracle.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'oci_descriptor_t' nsoracle.h:81: error: expected specifier-qualifier-list before 'OCIStmt' nsoracle.h:145: error: expected specifier-qualifier-list before 'OCIEnv' nsoracle.h:190: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ora_append_buf_to_dstring' nsoracle.h:242: error: expected declaration specifiers or '...' before 'oci_status_t' nsoracle.h:245: error: expected declaration specifiers or '...' before 'oci_status_t' nsoracle.h:249: error: expected declaration specifiers or '...' before 'OCILobLocator' nsoracle.h:250: error: expected declaration specifiers or '...' before 'OCISvcCtx' I have similar errors with 2.7 Any suggestions? Jade -- Jade Rubick Senior Developer United eWay Volunteer Solutions [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] ns_cache backwards compatibility
Hi all: I'm attempting to get Aolserver working on a 64 bit AMD machine, and after reading through all the threads on 64 bit compatibility thought it best to try Aolserver 4.5 However, I'm concerned that the ns_cache command is not backwards compatible. The wiki does not seem to have much information on this. Can anyone shed some light on what gotchas I may need to be aware of when updating to Aolserver 4.5? We use ns_cache fairly heavily -- and I'm installing this on a server I plan to use on production. Thank you, Jade -- Jade Rubick Senior Developer United eWay Volunteer Solutions [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Overhead of redefining procs
Hi all: I was wondering if there was any obvious problems with redefining procs repeatedly. For example, if a page contained a proc definition which was sourced on each page. I wasn't sure of the underlying scalability issues that could arise from this. Any insights? Jade -- Jade Rubick Senior Developer United eWay Volunteer Solutions [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] profiling an aolserver site
John: We have a page profiler which is called at the beginning and ending of the page being served. The timing is saved to NSV, and every hour is flushed into the database. We are then emailed reports on the worst pages every night, and can pull up nice looking reports that show us the worst offenders, and the history for each page. We also have an experimental tool we've added as a wrapper around procs which basically keeps track of all the count of how many times procs are called within each request. We keep the last 1000 requests in memory, so it's easy to see which procs are being called the most often, and make sure these procs are highly optimized. We've found some big performance holes using this. These tools are not generally useful because they rely a lot on custom code, but I'd be happy to talk about how we implemented them. The general idea is to write out to nsvs. We found this to have a lot less performance impact than we expected. Jade -- Jade Rubick Senior Developer United eWay Volunteer Solutions [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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] Handling db events in Tcl
You can do most things of this sort within Oracle's Java Virtual Machine, and even have triggers that fire Java code. Probably the most appropriate way to communicate back would be HTTP, but you would have to be careful not to induce loops, and make sure it's not brittle. JadeOn 9/12/06, Tom Jackson <[EMAIL PROTECTED]> wrote: I wrote an OpenACS module, which worked on Oracle and pg called cronjob.Once per minute it queried a table, ran the sql (if any) and then ran the tclscript (if any), and sent an email report (if there was an email address). Btw, getting a database handle doesn't require opening a connection, databaseconnections are already established. Getting the handle is fast, releasingthem should be automatic.But if the task is really a database task, why not run it inside the database, but I'm not sure how schedule database tasks in pg. Oracle 10g I believe hasa nice facility for scheduling tasks, and obviously triggers can fire so youdon't have to poll anything.tom jacksonOn Tuesday 12 September 2006 08:41, Titi Ala'ilima wrote: > Hi all,>> What I'd love would be a way to have an nsd thread listen for a certain> db event and fire Tcl as a result. Anyone know how to accomplish this> other than polling? I'd hate to have to grab a handle, query, and then > release a handle. In a pinch I know I could have the db make an HTTP> request. But ideally there would be a persistent connection open and> the db (in this case Oracle, but I'd like to figure out a way that would > work with postgres, too) would report when Tcl needs to be fired. Seems> like nsproxy may be useful for this.>> -Titi> --> 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 thebody of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- Jade RubickSenior DeveloperUnited eWay Volunteer Solutions[EMAIL PROTECTED]tel (503)285-4963fax (707)671-1333 www.UNITEDeWAY.org -- 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] AW: [AOLSERVER] Storing binary data in MySQL with AOLserver
Dossy, I'd like to see some more discussion about 1) SOAP and 2) the use of ns_java, personally. I don't know if this is something that you're interested in blogging or not, however! Jade-- Jade Rubick, Senior DeveloperUnited eWay Volunteer Solutions [EMAIL PROTECTED] http://www.volunteersolutions.org Phone: (503)285-4963 Fax: (707)671-1333 -- 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] An easy way to crash all your Aolserver instances on a machine
It looks like this might be a bug in ns_encrypt:
ns_decrypt {}
It kills all the current Aolserver instances on the servers I've tried it on (two of them).
Jade-- Jade Rubick, Senior DeveloperUnited eWay Volunteer Solutions [EMAIL PROTECTED]
http://www.volunteersolutions.org Phone: (503)285-4963 Fax: (707)671-1333
--
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] Web services infrastructure for AOLServer
Hi Dossy: Would having it available in a different license make AOL more interested in the project? :) Jade> Recognizing the broad need for web services, this project will be > open-sourced under the GPL license [...]Why GPL and not MPL or AOLserver Public License (derived from MPL)?The GPL puts unnecessary burdens on redistribution and use in commercialproducts. -- Jade Rubick, Senior DeveloperUnited eWay Volunteer Solutions [EMAIL PROTECTED] http://www.volunteersolutions.org Phone: (503)285-4963 Fax: (707)671-1333 -- 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] Web services infrastructure for AOLServer
I wanted to alert everyone here to an announcement on the OpenACS forums: http://openacs.org/forums/message-view?message_id=324663 Project overview Currently AOLServer has a number of implementations of SOAP web services, of varying degrees of maturity and completeness (http://openacs.org/wiki/Web%20Services). None of them is as complete or as effective as support on other platforms. United eWay would like to fund the development of a Web Services infrastructure for AOLServer, as we have the need for reliable and effective SOAP-based web services on the AOLServer platform. Recognizing the broad need for web services, this project will be open-sourced under the GPL license with the goal of making it available to the broader AOLServer community so others can benefit from the work and contribute improvements to the project. [snip]-- Jade Rubick, Senior DeveloperUnited eWay Volunteer Solutions [EMAIL PROTECTED] http://www.volunteersolutions.org Phone: (503)285-4963 Fax: (707)671-1333 -- 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 Digest - 20 Mar 2005 to 22 Mar 2005 (#2005-54)
Maybe I missed some followup to this posting, but it seems like this would be an excellent thing to follow up with. Is there any plan to make this the default for new installations? Topics of the day: 1. Simple yet flexible configuration for Aolserver -- 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] Proposed patch for nsopenssl
I've had my error logs get filled with error messages that look like this:
[14/Jan/2005:17:05:27][30928.5126][-conn:ibr::2] Warning: nsopenssl (ibr): SSL
read interrupted:
Connection reset by peer
This seems to happen when people cancel page requests while using SSL. It seems
to happen fairly
often, even for a small intranet site like we have at IBR:
$ grep "reset by" * |wc
2122332 28731
This is for the last month, on a small intranet for about 25 people.
I'd like the error logs to be less cluttered, so I looked through the nsopenssl
source, and it looks
like this might be the right place to fix things:
$ diff -u ssl.c.~1.68.~ ssl.c
--- ssl.c.~1.68.~ Tue Nov 2 17:12:22 2004
+++ ssl.c Mon Jan 24 17:27:05 2005
@@ -703,13 +703,13 @@
case SSL_ERROR_SYSCALL:
err = ERR_get_error();
if (err) {
-Ns_Log(Warning, "%s (%s): SSL %s interrupted: %s",
+Ns_Log(Debug, "%s (%s): SSL %s interrupted: %s",
MODULE, sslconn->server, dir,
ERR_reason_error_string(err));
} else if (n == 0) {
-Ns_Log(Warning, "%s (%s): SSL %s interrupted: unexpected eof",
+Ns_Log(Debug, "%s (%s): SSL %s interrupted: unexpected eof",
MODULE, sslconn->server, dir);
} else {
-Ns_Log(Warning, "%s (%s): SSL %s interrupted: %s",
+Ns_Log(Debug, "%s (%s): SSL %s interrupted: %s",
MODULE, sslconn->server, dir,
ns_sockstrerror(ns_sockerrno));
}
n = -1;
Any comment on this proposed fix? Are you willing to put it or something
similar into the
nsopenssl source?
Jade
--
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 debugging
I have been having very similar problems to Bruno's, but on a Debian stable Linux box. So I'm not so sure that this is a Mac OS problem. If I have some time tomorrow, I'll test things out. Could we put up a page on the Wiki that has the test page that Dossy proposed, links to the patches, etc..? I'd like to help test this, but have deleted the previous postings, and I haven't had a reliable way to reproduce the errors you mention. My symptoms are on something like Aolserver 4.01 + nsopenssl 3 beta 17 or so. I only have about 15 users on my production box, and about once a day, the connections get gradually taken up, and the load gradually rises, until it's unreachable. I have a keepalive script going, so it restarts the Aolserver instance whenever it's unreachable. The load then goes down to near zero and the whole process starts over again. This happens on my dev box as well, which has the same configuration. But that happens much less often, because I'm the only user on the system. Jade -- 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] Security issue in Aolserver
There is a security issue in Aolserver, which is described here: http://openacs.org/bugtracker/openacs/bug?bug_number=2011 Untrusted users can craft pages that subsequent users will receive when they browse the site. This should be a one-line bug-fix, I imagine. Jade -- 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] Is Aolserver vulnerable?
Does Aolserver implement the TRACE command? http://www.extremetech.com/article2/0,3973,841047,00.asp
