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 jrub...@truist.com wrote: I personally strongly favor github. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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 d...@thedesignexperience.orgwrote: On Tue, Nov 16, 2010 at 6:15 PM, Tom Jackson t...@rmadilo.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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 thejackschm...@gmail.com 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 majidkha...@gmail.com 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 do...@panoptic.com 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 majidkha...@gmail.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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 do...@panoptic.com 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 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] 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+5554ie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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
}
%
swtm_header section=About UsAbout Volunteer Solutions/swtm_header
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+5554ie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=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
lists...@listserv.aol.com 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
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] 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 a...@ayan.net 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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 anothe...@yahoo.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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 thejackschm...@gmail.com 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 t...@rmadilo.com 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 neum...@wu.ac.at 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 OpenACS). best regards -gustaf neumann -- 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 lists
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 jgdavid...@mac.com 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 ? B7FBB174 ? NsTclInfoObjCmd()+5 call B7F73B30 B4601AE8 ? B7F8917B ? 46 B7FBC080 ? B7FB34D3 ? 0 ? B4601AE4 ? TclEvalObjvInternal call EF0B1C0 ? CE907D0 ? 2 ? ()+819 EC701D8 ? B304D010 ? A7DBAE50 ? TclExecuteByteCode( call _init()+184 CE907D0 ? 2 ? EC701D8 ? 0 ? )+107130 ? 0 ? TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 0 ? 0 ? 0 ? 2
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 jgdavid...@mac.com 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
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=detailaid=1811445group_id=13248atid=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 thejackschm...@gmail.com 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 je...@activestate.com 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 thejackschm...@gmail.com 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 je...@activestate.com 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 je...@activestate.com 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 lists...@listserv.aol.com 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 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
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 ste...@gmail.com 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 jrub...@truist.com 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 thejackschm...@gmail.com Date: Thu, Apr 30, 2009 at 4:03 PM Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver To: Jade Rubick jrub...@truist.com Cc: tech t...@volunteersolutions.org 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 thejackschm...@gmail.com 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 jrub...@truist.com 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 ste...@gmail.com 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 AOLSERVER@LISTSERV.AOL.COM 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 jrub...@truist.com 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
[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 thejackschm...@gmail.com Date: Thu, Apr 30, 2009 at 4:03 PM Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver To: Jade Rubick jrub...@truist.com Cc: tech t...@volunteersolutions.org 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 thejackschm...@gmail.com 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 jrub...@truist.com 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 ste...@gmail.com *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 AOLSERVER@LISTSERV.AOL.COM 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 jrub...@truist.com 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
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 jrub...@truist.com 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
[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 use DH which is part of the libcrypto
library
[AOLSERVER] Possible bug in TLS?
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
lists...@listserv.aol.com with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] 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 mark-aolser...@aufflick.comwrote: 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 jan...@furfly.net 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 lists...@listserv.aol.com 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 lists...@listserv.aol.com with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] 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] 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 of static. So this is actually a fairly non-intrusive fix. The main limitation is that it relies on the file timestamps and the server timestamps being synchronized, which may not always be true. But I can't think of a better solution. Simply put, fastpath caching is inherently broken because it's not possible to guarantee that the file in question really should be served from cache (again, short of a cache-defeating checksum). Fixing
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] 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] 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] 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] 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. Makefilensmemcache.cnsmemfunc.hnsmemsock.h -- 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] 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: img src=%= $Template(gserv) %/graphics/soa-logo4.gif 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.
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.
[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] 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] 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.
[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] 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
