[AOLSERVER] [ aolserver-Bugs-420473 ] ns_eval is not obsolete
Bugs item #420473, was opened at 2001-05-01 16:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=103152aid=420473group_id=3152 Category: Other: Documentation Group: documentation Status: Closed Resolution: Rejected Priority: 1 Submitted By: Robert Parker (rparker9) Assigned to: Kriston Rehberg (kriston) Summary: ns_eval is not obsolete Initial Comment: According to the Function Categories on aolserver.com ns_eval is obsolete but I judging from replies I had on listserv.aol.com it is _not_ obsolete -- Comment By: Robert Parker (rparker9) Date: 2002-03-20 10:07 Message: Logged In: YES user_id=209093 ok, looking on aolserver.com today (20 Mar 02) the Tcl API description of ns_eval does not say it is obsolete (it used to say this!) This report can be closed - RP -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-19 17:54 Message: Logged In: YES user_id=16427 Please elaborate a bit more. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=103152aid=420473group_id=3152
Re: [AOLSERVER] Unicode, I18N, 3.4.2 / 4.0
On Thu, 28 Feb 2002, Bernd Eidenschink wrote: Hi, I don't know how to set up a combination of the latest AOLserver, using the nsd8x Interpreter, and a Postgres 7.2 database, that allows me to safely work with a charset of iso8859-1. Please don't throw stones, I know this has been discussed very often ;-) How to do it? The problems I run into during my own tests and the problems that other people have (I read through some threads on various boards) are: A. Using the latest server out of the box, working with most European characters will almost always fail using the typical string and regexp functions that internally use utf-8 ... _IF_ you are returning (in http- header or meta-tags) a charset of e.g. iso8859-1 (you have to know what comes from forms/submits; you try to return umlauts or any language depending chars and tell the browser of it). B. I got the tip of using an undocumented parameter in the config file, that maps the iso8859-1 charset to .adp files (last year on this list). But this does not guarantee that all characters that _leave_ an adp will be in iso8859-1 encoding (e.g. if I use combinations of ns_adp_parse -file (where strings from the DB are regexped and stringed and whatever) and return the string with ns_return). At least if all what comes in goes iso-ed to the DB, you could do a workaround and translate all outgoing chars to #123 html code. (There was an example of a ns_adp_puts function that does this given by Harray Moreau on the list)... If you escape all the characters that way, I assume, you would not no longer have to return a charset header or charset-meta-tag. C. The uncool way: Using charset=utf-8 outgoing, then also expecting it incoming. A special character should come in as unicode and tcl should treat it this way. The database must be installed with unicode-encoding. You will run into performace problems and/or, maybe, some unresolved topics of Postgres unicode-implementation as well. I have not tried this yet, I merely assume this would work. What's your opinion on that? D. Using an AD-patched version of AOLserver. The Problem: It's an older version of the server, will it be kept up to date in the future? (Of course, there's a large user base running it) E. I did not try --enable-recode and setting up a charset table for utf8 - latin1 and latin1 - utf8 for Postgres. Maybe this would work if you can guarantee all charsets coming from AOLserver are coming as utf8 or iso8859x. Maybe, don't know. I tried putting SET ENCODING TO 'UNICODE' resp. LATIN1 in front of every SQL statement in my test api (and took into account that it may make a difference if you are SELECTing or INSERTing) for telling the Postgres server that the client uses unicode or latin with and without the undocumented feature of (B). This only lead to error messages noticing me of failed encoding translations. Every insert _always_ was logged with german special characters (umlauts) and never as unicode characters (don't know if this is correct). Will AOLserver 4 come with I18N support that solves all the problems and what to do if you need a solution here and now? Solution B? C? Thanks for reading through this one... Bernd. Kriston from AOL assured me that AOLserver 4 will have full international support. But I haven't inspected availabale code and verified that yet. Now I successfully run on 3.4.x dealing with iso8859-2 in the following way (I'm sure that you can do this the same way with iso8859-1 = latin1). * AOLserver scripts I use only .adp scripts with undocumented config ns_section ns/encodings ns_param adp iso8859-2 Of course I use *.tcl libraries with proper encoding set by [encoding system iso8859-2]. I don't use *.tcl pages at all because as far as I remeber ns_return* and ns_write don't do proper encoding translation. If you have to use *.tcl scripts (for example you are ACS user) I think you should use ArsDigita version today. * Databases If I use Postgres - I configure my database to use UTF-8 encoding createdb -E unicode database_name_in_utf8 and I set in the AOLserver process enviroment PGCLIENTENCODIGN=latin2 for postgres libraries. I suggest using UTF-8 for Postgres database rather than using 8-bit encoding in database (ex. latin2) and translating TCL strings which are send in unicode to some 8-bit encoding (it is possible by postgres configure option --enable-unicode-conversion). Main reason is that when running database in latin2 I had problems with encoding in very usefull Postgres procedural languages: pltcl pltclu. You may also encounter problems with char expansion which I discovered with Oracle. Anyway for Oracle I successfully used database in latin2 encoding with CharExpansion=4 parameter added to ArsDigita Oracle Driver 2.6 as a result of my proposal. * Other stuff With 3.4 I use the following simple patch for ns_urlencode. This is not general solution, but rather dirty fix. [tkosiak@mule
[AOLSERVER] [ aolserver-Patches-421740 ] [ns_info server] broken in config interp
Patches item #421740, was opened at 2001-05-05 19:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=421740group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Jamie (polygnwnd) Assigned to: Kriston Rehberg (kriston) Summary: [ns_info server] broken in config interp Initial Comment: [ns_info server] doesn't work in the configuration interpreter for versions after 3.2 as nsServer is not set until _after_ the configuration is read. Setting it when the option is parsed (like it was before) fixes this issue so [ns_info server] works in the configuration interpreter like the other ns_info calls. This might be socially unacceptable or have side effects, but I haven't notice any yet. diff -r aolserver-3.4pre1/nsd/nsmain.c aolserver- 3.4pre1-mod/nsd/nsmain.c 216a217 nsServer = optarg; -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:01 Message: Logged In: YES user_id=16427 Someone told me this shouldn't be done as the config interp is different from other interps. I think it has alot to do with virtual server support, but that means that the -s parameter should imply that ns_info server would take that value. It's still up in the air what this is supposed to do. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=421740group_id=3152
[AOLSERVER] [ aolserver-Patches-474259 ] ns_uuencode patch
Patches item #474259, was opened at 2001-10-23 18:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=474259group_id=3152 Category: other Group: None Status: Open Resolution: None Priority: 6 Submitted By: Vinod Kurup (vkurup) Assigned to: Kriston Rehberg (kriston) Summary: ns_uuencode patch Initial Comment: Hello all, ns_uuencode is broken in AOLServer 3.4.2. It works fine for text content, but it is broken for binary content. This is important to me because OpenACS needs a way to encode binary content when it sends outgoing mail. Rob Mayoff has explained to me that this is because NsTclHTUUEncodeCmd is currently implemented as a Tcl_CmdProc and it should be implemented as a Tcl_ObjCmdProc. He also notified me that this would only work for Tcl8, so I would have to keep the old Tcl_CmdProc for Tcl7.6 So, I've fixed this (according to his helpful guidance). In order to do this, I've made the following changes: * I created 2 header files (nsd76.h and nsd8x.h) which contain the arrays of commands for the 2 versions of Tcl. These arrays used to be defined in tclcmds.c. * I've implemented the function NsTclCreateObjCmds which previously was declared, but never implemented. * I've adjusted tclinit.c to call NsTclCreateObjCmds. * Finally, I've removed NsTclHTUUEncodeCmd from tclmisc.c and instead moved it to a new file uuencode7.c. I've then implemented the new Tcl_ObjCmdProc version into uuencode8.c. These will be included conditionally from tclstub76.c and tcstub8x.c, respectively. I also included test cases and linked the from the main test cases index.adp page, so that they will get installed with a 'make install-tests' These changes will also pave the way to upgrading other procs to use Tcl_ObjCmdProcs (such as ns_return, ns_write, etc). I would love to see this applied to 3.4.2 so that we could use AOLServer 3.4.x as the official distro for OpenACS 4. Let me know if I can clarify anything. The patch is against CVS tagged nsd_v3_r4_p2 Additional files are attached: nsd76.h, nsd8x.h, uuencode7.c and uuencode8.c go in directory nsd/ binary-file, test1.adp and test2.adp go in a new folder 'uuencode' inside /tests -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:06 Message: Logged In: YES user_id=16427 This is more appropriate as a separate command since ns_uuencode is intended for htuu encoding for URLs and basic auth (bug #446886). This patch would be great if it were a different command entirely. Incidentally email should use the more acceptable base-64 encoding. That way you can take advantage of MIME email which is the more compatible way to send binary data via email. It's unfortunate that the command is still called ns_uuencode but that's the way it is, I guess. Let me know what you'd like to do. Is it really compatible enough with htuu and basic-authentication to use this new code for those things as well as data? Let me know. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=474259group_id=3152
[AOLSERVER] [ aolserver-Patches-423820 ] patch for nsperm/init.tcl
Patches item #423820, was opened at 2001-05-13 20:27
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=423820group_id=3152
Category: aolserver3_3
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Hal Heisler (hheisler)
Assigned to: Kriston Rehberg (kriston)
Summary: patch for nsperm/init.tcl
Initial Comment:
Allows one to specify in the tcl configuration file
where nsperm files reside.
Example
ns_section ns/server/${server}/module/nsperm
ns_param nspermdirectory ${serverdir}/modules/nsperm
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 11:11
Message:
Logged In: YES
user_id=16427
Most excellent. Applied to branch nsd_v3_r3_p0.
--
Comment By: Hal Heisler (hheisler)
Date: 2001-05-14 11:20
Message:
Logged In: YES
user_id=20579
Trying to attach the patch again.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=423820group_id=3152
[AOLSERVER] [ aolserver-Patches-455596 ] ns_loglevel command: turns debug on/off
Patches item #455596, was opened at 2001-08-26 17:59
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=455596group_id=3152
Category: aolserver3_3
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jerry Asher (jerryasher)
Assigned to: Kriston Rehberg (kriston)
Summary: ns_loglevel command: turns debug on/off
Initial Comment:
The attached patch adds an ns_loglevel command.
The patch was made against AOLserver 3.3 ad13, but
should almost certainly work AOLserver 3.3. The patch
patches nsd/nsd.h, nsd/tclcmds.c, and nsd/log.c
Documentation:
Name: ns_loglevel
Synopsis:
ns_loglevel [option [?on | ?off]]
Description:
Turn debug and dev level debugging on or off at runtime
without requiring a server restart.
ns_loglevel
Returns a list of four elements containing the current
settings of debug and dev log settings. The list is of
the form:
{debug (on | off) dev (on | off)}
ns_loglevel debug
Returns the current value of the debug log level, on
or off
ns_loglevel debug ?on | ?off
Sets the current value of the debug loglevel to on or
off. Returns the old value.
ns_loglevel dev
Returns the current value of the dev log level, on or
off
ns_loglevel dev ?on | ?off
Sets the current value of the dev loglevel to on or
off. Returns the old value.
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 11:15
Message:
Logged In: YES
user_id=16427
This is most awesome. I'd like it if you could take a look
at the head version on branch nsd_v3_r3_p0 (post-AOLserver
3.4.2) and see if you can make a patch against that one.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=455596group_id=3152
[AOLSERVER] [ aolserver-Patches-517267 ] Patch for SEGV if 401 redirect is used
Patches item #517267, was opened at 2002-02-13 19:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=517267group_id=3152
Category: other
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Caruso (johnjcaruso)
Assigned to: Kriston Rehberg (kriston)
Summary: Patch for SEGV if 401 redirect is used
Initial Comment:
AOLserver 3.4.2 can generate a segmentation fault in
FreeUrl when it tries to dereference a NULL pointer.
This behavior happens ONLY if the server in question
has a 401 redirect specified, and it can only be
produced if a failure occurs in the Ns_ConnReadLine
routine (via rapid browser refreshes, for example).
Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x80798da in FreeUrl (request=0x0) at request.c:313
313 if (request-url != NULL) {
(gdb) bt
#0 0x80798da in FreeUrl (request=0x0) at request.c:313
#1 0x807986e in Ns_SetRequestUrl (request=0x0,
url=0x8174168 /error_pages/401.html) at
request.c:286
#2 0x8077c75 in Ns_ConnRedirect (conn=0x81bc068,
url=0x8174168 /error_pages/401.html) at op.c:231
#3 0x807af90 in ReturnRedirect (conn=0x81bc068,
status=401,
resultPtr=0xbefff864) at return.c:1206
#4 0x807a922 in Ns_ConnReturnBadRequest
(conn=0x81bc068,
reason=0x8128593 Invalid HTTP request) at
return.c:838
#5 0x807e108 in ConnRun (connPtr=0x81bc068) at
serv.c:822
#6 0x807dc3a in NsConnThread (arg=0x81b3de8) at
serv.c:671
#7 0x811db42 in NsThreadMain (arg=0x81ffae0) at
thread.c:228
#8 0x4001ebb5 in pthread_start_thread
(arg=0xbefffe40) at manager.c:241
The problem stems from the fact that conn-request is
always NULL within ConnRun just before the following
code snippet is executed:
if (Ns_ConnReadLine(conn, ds, n) != NS_OK ||
(connPtr-request = Ns_ParseRequest
(ds.string)) == NULL) {
(void) Ns_ConnReturnBadRequest(conn, Invalid
HTTP request);
goto done;
}
If Ns_ConnReadLine doesn't return NS_OK, conn-request
will remain NULL; Ns_ConnReturnBadRequest will then be
called, and it will in turn call ReturnRedirect(conn,
401, result). If a 401 redirect exists, the calling
sequence shown above will be followed, and FreeUrl
(request) will eventually be called with
request==NULL, causing the SEGV.
I was able to reproduce this segmentation fault quite
easily on a VAlinux 6.2.3 system simply by doing VERY
rapid refreshes of a page (browser doesn't matter).
I've also verified that this behavior was present in
AOLserver 3.3.1 as well. The simplest workaround is
to remove the 401 redirect.
I created a patch for this problem which calls
Ns_ParseRequest within Ns_ConnRedirect to fill in the
conn-request structure if conn-request is NULL
(rather than calling Ns_SetRequestUrl, as the current
code does), and then also prevents the request from
being reauthorized if conn-request is still NULL.
Ns_ConnRedirect seemed to be the most logical point in
the call sequence where a URL was available to be used
to fill in the conn-request structure in this case.
This patch fixes the problem, but since I'm not aware
of all the internals of AOLserver, it may not be the
optimal approach. There's also still the underlying
problem that several routines (FreeUrl, SetUrl, and so
on) reference pointers without validating them first.
Hopefully the horrible formatting in this web form
corrects itself when the patch is submitted
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 11:16
Message:
Logged In: YES
user_id=16427
How widespread would you say that the practice of
dereferencing unvalidated pointers is in AOLserver 3.x as a
whole?
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=517267group_id=3152
[AOLSERVER] [ aolserver-Patches-531048 ] 500 status for pre_auth filter failure
Patches item #531048, was opened at 2002-03-17 13:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=531048group_id=3152 Category: other Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Walker (vt_dwalker) Assigned to: Nobody/Anonymous (nobody) Summary: 500 status for pre_auth filter failure Initial Comment: patch for aolserver-3.4 Currently a failure in a pre-auth filter will result in nothing being logged in the access log and nothing being returned to the client. This patch returns a 500 internal error to the client and allows trace filters to run which results in a 500 error showing up in the access log as well. The server log still contains the pre_auth filter error. Side effects: Runs all trace filters for pre_auth filter failures. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:18 Message: Logged In: YES user_id=16427 Do you think it's appropriate for all the trace filters to run? Might this cause double server errors, or what do you think? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=531048group_id=3152
[AOLSERVER] [ aolserver-Patches-456225 ] ns_logdump command
Patches item #456225, was opened at 2001-08-28 14:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=456225group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry Asher (jerryasher) Assigned to: Kriston Rehberg (kriston) Summary: ns_logdump command Initial Comment: Dump a string in hex and ascii to the log. Available from C or Tcl. Useful in debugging new protocols Add a C API and Tcl API for dumping HEX to the log. void Ns_LogDumpString(Ns_LogSeverity severity, char *s, int len) and ns_logdump severity string Severity is a standard ns_log severity constant, Notice, Warning, Error, Debug, or Dev. The output in the log file looks like: : 4164 6420 6120 4320 4150 4920 616e 6420 Add a C API and 0010: 5463 6c20 4150 4920 666f 7220 6475 6d70 Tcl API for dump 0020: 696e 6720 4845 5820 746f 2074 6865 206c ing HEX to the l 0030: 6f67 2e0a 0a76 6f69 6420 4e73 5f4c 6f67 og...void Ns_Log 0040: 4475 6d70 5374 7269 6e67 284e 735f 4c6f DumpString(Ns_Lo The length of a line is controlled by a tcl config parameter, dumpbytesperline, that defaults to 32. ns_section ns/parameters ns_paramdumpbytesperline 32 This patch modifies: nsd/log.c, nsd/nsconf.c, nsd/nsconf.h, nsd/nsd.h, nsd/tclcmds.c. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:20 Message: Logged In: YES user_id=16427 Would it be possible to take a look at nsd_v3_r3_p0 head version and apply a patch against that? Or maybe just AOLserver 3.4.2? Thanks. -- Comment By: Jerry Asher (jerryasher) Date: 2001-08-28 15:39 Message: Logged In: YES user_id=20647 Use the second patch, not the first. The first patch doesn't declare Ns_LogDumpString within include/ns.h. (Nb: I tried deleting the patch, but sourceforge would not let me.) -- Comment By: Jerry Asher (jerryasher) Date: 2001-08-28 14:09 Message: Logged In: YES user_id=20647 Uh, the actual format looks a lot better than what sourceforge did to my prior comment. Looks good actually! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=456225group_id=3152
[AOLSERVER] [ aolserver-Patches-530808 ] adds ns_set findall/ifindall
Patches item #530808, was opened at 2002-03-16 17:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=530808group_id=3152 Category: other Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: David Walker (vt_dwalker) Assigned to: Nobody/Anonymous (nobody) Summary: adds ns_set findall/ifindall Initial Comment: adds ns_set findall/ifindall to aolserver 3.4 -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:22 Message: Logged In: YES user_id=16427 This is most cool. Would it be possible that you provide a small test case that shows how this work so I can also write some documentation on it? Thanks! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=530808group_id=3152
[AOLSERVER] [ aolserver-Patches-527863 ] ns_return and ns_write written as TclObj
Patches item #527863, was opened at 2002-03-09 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527863group_id=3152 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: David Walker (vt_dwalker) Assigned to: Nobody/Anonymous (nobody) Summary: ns_return and ns_write written as TclObj Initial Comment: ns_return and ns_write written as TclObjCommands. Makes returning binary data from tcl strings to connection possible. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:23 Message: Logged In: YES user_id=16427 How possible would it be for you to go through all of AOLserver 4 and make everything a TclObjCommand and do the right thing, like Tcl_WrongNumArgs, eliminate Tcl_AppendResult (and other non-TclObj string manipulators)? -- Comment By: David Walker (vt_dwalker) Date: 2002-03-09 14:33 Message: Logged In: YES user_id=481247 patch is against aolserver 4 beta -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527863group_id=3152
[AOLSERVER] [ aolserver-Patches-527073 ] Optionally roll the server logs daily.
Patches item #527073, was opened at 2002-03-07 13:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527073group_id=3152 Category: other Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Pierre Asselin (pierrethebom) Assigned to: Nobody/Anonymous (nobody) Summary: Optionally roll the server logs daily. Initial Comment: The patch is off of aolserver 3.4.2 . Add two params to ns/parameters: 1) rollhour, to roll the server logs daily; 2) rollfmt, to append a timestamp instead of .nnn suffix. The options are patterned after the nslog module. Unmodified configs preserve the current behavior. Affected files: doc/config.txt, nslog/nslog.html: Document the new params. Fix the logroll description to match reality. Also fixed the nslog docs to match what nslog/nslog.c actually does... nsd/nsd.h: New field, char *rollfmt in the nsconf.log substruct. nsd/nsconf.c: NsConfInit(): initialize nsconf.log.rollfmt . nsd/log.c: Ns_LogRoll(): append a timestamp to the file name if rollfmt given, else append a counter. LogRollDailyCallback(): new schedulable wrapper around Ns_LogRoll(). NsLogOpen(): schedule LogRollDailyCallback() if rollhour given. I checked that the roll occurs, whether by SIGHUP or by daily schedule, that timestamps or counters are appended to the log names as configured, and that the maxbackup parameters are honored. I didn't include a test case because it would have to run for days to check everything. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:26 Message: Logged In: YES user_id=16427 Most excellent. To clarify: does this patch address both the server log and the access log? Do you think this might have anything to do with bug #434827? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527073group_id=3152
[AOLSERVER] [ aolserver-Patches-527073 ] Optionally roll the server logs daily.
Patches item #527073, was opened at 2002-03-07 13:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527073group_id=3152 Category: other Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Pierre Asselin (pierrethebom) Assigned to: Kriston Rehberg (kriston) Summary: Optionally roll the server logs daily. Initial Comment: The patch is off of aolserver 3.4.2 . Add two params to ns/parameters: 1) rollhour, to roll the server logs daily; 2) rollfmt, to append a timestamp instead of .nnn suffix. The options are patterned after the nslog module. Unmodified configs preserve the current behavior. Affected files: doc/config.txt, nslog/nslog.html: Document the new params. Fix the logroll description to match reality. Also fixed the nslog docs to match what nslog/nslog.c actually does... nsd/nsd.h: New field, char *rollfmt in the nsconf.log substruct. nsd/nsconf.c: NsConfInit(): initialize nsconf.log.rollfmt . nsd/log.c: Ns_LogRoll(): append a timestamp to the file name if rollfmt given, else append a counter. LogRollDailyCallback(): new schedulable wrapper around Ns_LogRoll(). NsLogOpen(): schedule LogRollDailyCallback() if rollhour given. I checked that the roll occurs, whether by SIGHUP or by daily schedule, that timestamps or counters are appended to the log names as configured, and that the maxbackup parameters are honored. I didn't include a test case because it would have to run for days to check everything. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:26 Message: Logged In: YES user_id=16427 Most excellent. To clarify: does this patch address both the server log and the access log? Do you think this might have anything to do with bug #434827? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527073group_id=3152
[AOLSERVER] [ aolserver-Patches-500430 ] bug fix for ns_hostbyaddr
Patches item #500430, was opened at 2002-01-07 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=500430group_id=3152 Category: other Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: patrick o'leary (pjaol) Assigned to: Kriston Rehberg (kriston) Summary: bug fix for ns_hostbyaddr Initial Comment: ns_hostbyaddr can cause a libthread crash on Sun OS 7+, under high load, with ip address's which cannot be resolved. This comes from NsTclGetByCmd (in tclsock.c) returning TCL_ERROR, which get pushed into ns_log. This solution returns TCL_OK for all events, replaces ns_hostbyaddr with ns_get_hostbyaddr. The result is pushed into the TCL result string. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:26 Message: Logged In: YES user_id=16427 Can this be applied as a replacement for ns_hostbyaddr as well? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=500430group_id=3152
[AOLSERVER] [ aolserver-Patches-455813 ] specify log files access permissions
Patches item #455813, was opened at 2001-08-27 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=455813group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry Asher (jerryasher) Assigned to: Kriston Rehberg (kriston) Summary: specify log files access permissions Initial Comment: Added Ns_ConfigGetOctal to config.tcl (declared in ns.h). Ns_ConfigGetOctal retrieves an octal constant from the config.tcl. Used Ns_ConfigGetOctal to get a UNIX file mode specification for the server log and the access logs. Modified nsd/log.c to examine new config.tcl parameter ns_section ns/parameters ns_param serverlogmode 0664 nsd/log.c will open the server log and then change its mode to serverlogmode. Serverlogmode defaults to 0644. ns_section ns/server/yourserver/module/nslog ns_param accessmode 0664 ns_param iplookups true nslog/nslog.c will open the access log and then change its mode to accessmode. Accessmode also defaults to 0644. I find that opening logs to different modes is useful for ISPs or corporate installations of AOLserver, in which different users, at different times, may need to start/stop AOLserver, and/or delete the log files. I also added a new parameter, iplookups that defaults to off. If set to on, then the access log will perform Reverse DNS Lookups for you. The usual caveat applies, that this can slow down overall AOLserver performance. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:30 Message: Logged In: YES user_id=16427 Interesting. Do you think this might have something to do with bug #434827? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=455813group_id=3152
[AOLSERVER] [ aolserver-Patches-472822 ] tclsock.c patch
Patches item #472822, was opened at 2001-10-19 11:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=472822group_id=3152 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Collins (jcollins) Assigned to: Kriston Rehberg (kriston) Summary: tclsock.c patch Initial Comment: This is a simple patch to tclsock.c in ./nsd that causes SockListenCallback to evaluate each new connection in a separate thread. This allows the listening port to continue listening so multiple connections can happen. I am not sure I did this change the most logical way. Hopefully somebody could check it and give me feedback. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:28 Message: Logged In: YES user_id=16427 Just so I can understand this: This would only affect things in a sockcallback thread, but will *not* affect a communications driver like nssock, nsssl, nsunix, or nsopenssl? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=472822group_id=3152
[AOLSERVER] [ aolserver-Patches-455776 ] add -reset option to ns_server option
Patches item #455776, was opened at 2001-08-27 10:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=455776group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry Asher (jerryasher) Assigned to: Kriston Rehberg (kriston) Summary: add -reset option to ns_server option Initial Comment: This patch adds a -reset option to ns_server urlstats. ns_server urlstats -reset ?pattern returns the urlstats for the pattern (or all stats if no pattern is given) and then resets ALL the urlstats. I find this useful when benchmarking AOLserver. This patch was generated against AOLserver 3.3ad13 -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:32 Message: Logged In: YES user_id=16427 Do you think this could cause trouble due to the dirty writes going on in the stats interface? For example, when aolserver.com was on Irix, visiting the nstelemetry.adp page would crash the server about 25% of the time due to reading stats data at the same time it was being written to. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=455776group_id=3152
[AOLSERVER] [ aolserver-Patches-415475 ] Tcl exec fails on OpenBSD 2.8
Patches item #415475, was opened at 2001-04-11 13:56
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=415475group_id=3152
Category: aolserver3_3
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connie Hentosh (chentosh)
Assigned to: Kriston Rehberg (kriston)
Summary: Tcl exec fails on OpenBSD 2.8
Initial Comment:
The tcl exec command fails under OpenBSD 2.8. The read
on the pipe of the output from the command exec'd
receives a SIGCHLD. The solutions is to wrap the read
in a loop and check for errno of EINTR within
tcl8.3.2/unix/tclUnixPipe.c.
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 11:37
Message:
Logged In: YES
user_id=16427
Can you check of tcl8.3.3+ or tcl 8.4.x addresses any of
this exec-related stuff? See bug #415695.
Thanks!
--
Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-01-30 02:37
Message:
Logged In: YES
user_id=72656
An alternative patch based on Tcl bug 415131 was used
instead that looks like:
do {
bytesRead = read (GetFd(psPtr-inFile), buf,
(size_t) toRead);
} while ((bytesRead 0) (errno == EINTR));
This is already in Tcl 8.3.4, so this can be closed.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=415475group_id=3152
[AOLSERVER] [ aolserver-Patches-530808 ] adds ns_set findall/ifindall
Patches item #530808, was opened at 2002-03-16 22:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=530808group_id=3152
Category: other
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: David Walker (vt_dwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: adds ns_set findall/ifindall
Initial Comment:
adds ns_set findall/ifindall to aolserver 3.4
--
Comment By: David Walker (vt_dwalker)
Date: 2002-03-20 16:48
Message:
Logged In: YES
user_id=481247
set myset [ns_set create]
ns_set put $myset my name is bob
ns_set put $myset My Name is joe
ns_set put $myset my name is sam
ns_set put $myset My Name is bill
foreach id [ns_set findall $myset my name is] {
ns_write [ns_set key $myset $id]=[ns_set value $myset
$id]br
}
ns_write hr
foreach id [ns_set ifindall $myset my name is] {
ns_write [ns_set key $myset $id]=[ns_set value $myset
$id]br
}
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 16:22
Message:
Logged In: YES
user_id=16427
This is most cool. Would it be possible that you provide a
small test case that shows how this work so I can also write
some documentation on it?
Thanks!
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=530808group_id=3152
[AOLSERVER] [ aolserver-Patches-463625 ] Binder support for UDP and UNIX sockets
Patches item #463625, was opened at 2001-09-21 17:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=463625group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Kriston Rehberg (kriston) Summary: Binder support for UDP and UNIX sockets Initial Comment: Added support for UDP and UNIX domain sockets for binder. New function Ns_SockListenEx2. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:51 Message: Logged In: YES user_id=184124 There is no any side effects except binder.c file. It introduces new function only. I wrote ns_snmp module which we use for our NMS system and i needed UDP and ICMP sockets. This module under GPL and it is stable, so it may used in aolserver distrib. I upload the most recent patch for 3.3ad13. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:29 Message: Logged In: YES user_id=16427 Any side effects to any of the communications drivers? Do we have to change anything like nsunix/nsvhr that might use unix domain sockets or udp? What uses udp, by the way? Thanks very much! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=463625group_id=3152
[AOLSERVER] [ aolserver-Patches-463625 ] Binder support for UDP and UNIX sockets
Patches item #463625, was opened at 2001-09-21 17:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=463625group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Kriston Rehberg (kriston) Summary: Binder support for UDP and UNIX sockets Initial Comment: Added support for UDP and UNIX domain sockets for binder. New function Ns_SockListenEx2. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:52 Message: Logged In: YES user_id=184124 There is no any side effects except binder.c file. It introduces new function only. I wrote ns_snmp module which we use for our NMS system and i needed UDP and ICMP sockets. This module under GPL and it is stable, so it may used in aolserver distrib. I upload the most recent patch for 3.3ad13. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:51 Message: Logged In: YES user_id=184124 There is no any side effects except binder.c file. It introduces new function only. I wrote ns_snmp module which we use for our NMS system and i needed UDP and ICMP sockets. This module under GPL and it is stable, so it may used in aolserver distrib. I upload the most recent patch for 3.3ad13. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:29 Message: Logged In: YES user_id=16427 Any side effects to any of the communications drivers? Do we have to change anything like nsunix/nsvhr that might use unix domain sockets or udp? What uses udp, by the way? Thanks very much! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=463625group_id=3152
[AOLSERVER] [ aolserver-Patches-530808 ] adds ns_set findall/ifindall
Patches item #530808, was opened at 2002-03-16 22:47
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=530808group_id=3152
Category: other
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: David Walker (vt_dwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: adds ns_set findall/ifindall
Initial Comment:
adds ns_set findall/ifindall to aolserver 3.4
--
Comment By: David Walker (vt_dwalker)
Date: 2002-03-20 16:52
Message:
Logged In: YES
user_id=481247
I also just finished an findmatch command.
Should I submit that as a cumulative patch containing both?
I'm not sure how else to do it.
--
Comment By: David Walker (vt_dwalker)
Date: 2002-03-20 16:48
Message:
Logged In: YES
user_id=481247
set myset [ns_set create]
ns_set put $myset my name is bob
ns_set put $myset My Name is joe
ns_set put $myset my name is sam
ns_set put $myset My Name is bill
foreach id [ns_set findall $myset my name is] {
ns_write [ns_set key $myset $id]=[ns_set value $myset
$id]br
}
ns_write hr
foreach id [ns_set ifindall $myset my name is] {
ns_write [ns_set key $myset $id]=[ns_set value $myset
$id]br
}
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 16:22
Message:
Logged In: YES
user_id=16427
This is most cool. Would it be possible that you provide a
small test case that shows how this work so I can also write
some documentation on it?
Thanks!
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=530808group_id=3152
[AOLSERVER] [ aolserver-Patches-412045 ] Sybase Driver Error handling
Patches item #412045, was opened at 2001-03-28 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=412045group_id=3152 Category: modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Kriston Rehberg (kriston) Summary: Sybase Driver Error handling Initial Comment: Here is the patch that allows to catch sybase errors from triggers and stored procedures. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:53 Message: Logged In: YES user_id=184124 I added propagation of Sybase erros to AOLserver driver, so Sybase error message would be visible in the log file. -- Comment By: Peter M. Jansson (petej) Date: 2002-03-20 16:42 Message: Logged In: YES user_id=20577 This does not seem to be a good idea, since it would involve re-inventing logging code, especially if multiple instances of nssybpd are to log to the same place (plus, how do you figure out where the log files should go?). Why don't you want to use syslog? -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:38 Message: Logged In: YES user_id=16427 How possible would it be to get nssybpd to log to its own log file instead of using syslog? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=412045group_id=3152
[AOLSERVER] [ aolserver-Patches-412045 ] Sybase Driver Error handling
Patches item #412045, was opened at 2001-03-28 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=412045group_id=3152 Category: modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Kriston Rehberg (kriston) Summary: Sybase Driver Error handling Initial Comment: Here is the patch that allows to catch sybase errors from triggers and stored procedures. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:54 Message: Logged In: YES user_id=184124 Forgot the patch -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:53 Message: Logged In: YES user_id=184124 I added propagation of Sybase erros to AOLserver driver, so Sybase error message would be visible in the log file. -- Comment By: Peter M. Jansson (petej) Date: 2002-03-20 16:42 Message: Logged In: YES user_id=20577 This does not seem to be a good idea, since it would involve re-inventing logging code, especially if multiple instances of nssybpd are to log to the same place (plus, how do you figure out where the log files should go?). Why don't you want to use syslog? -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:38 Message: Logged In: YES user_id=16427 How possible would it be to get nssybpd to log to its own log file instead of using syslog? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=412045group_id=3152
[AOLSERVER] [ aolserver-Patches-463625 ] Binder support for UDP and UNIX sockets
Patches item #463625, was opened at 2001-09-21 17:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=463625group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Kriston Rehberg (kriston) Summary: Binder support for UDP and UNIX sockets Initial Comment: Added support for UDP and UNIX domain sockets for binder. New function Ns_SockListenEx2. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:55 Message: Logged In: YES user_id=184124 Lates patch -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:52 Message: Logged In: YES user_id=184124 There is no any side effects except binder.c file. It introduces new function only. I wrote ns_snmp module which we use for our NMS system and i needed UDP and ICMP sockets. This module under GPL and it is stable, so it may used in aolserver distrib. I upload the most recent patch for 3.3ad13. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 16:51 Message: Logged In: YES user_id=184124 There is no any side effects except binder.c file. It introduces new function only. I wrote ns_snmp module which we use for our NMS system and i needed UDP and ICMP sockets. This module under GPL and it is stable, so it may used in aolserver distrib. I upload the most recent patch for 3.3ad13. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:29 Message: Logged In: YES user_id=16427 Any side effects to any of the communications drivers? Do we have to change anything like nsunix/nsvhr that might use unix domain sockets or udp? What uses udp, by the way? Thanks very much! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=463625group_id=3152
[AOLSERVER] [ aolserver-Patches-500430 ] bug fix for ns_hostbyaddr
Patches item #500430, was opened at 2002-01-07 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=500430group_id=3152 Category: other Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: patrick o'leary (pjaol) Assigned to: Kriston Rehberg (kriston) Summary: bug fix for ns_hostbyaddr Initial Comment: ns_hostbyaddr can cause a libthread crash on Sun OS 7+, under high load, with ip address's which cannot be resolved. This comes from NsTclGetByCmd (in tclsock.c) returning TCL_ERROR, which get pushed into ns_log. This solution returns TCL_OK for all events, replaces ns_hostbyaddr with ns_get_hostbyaddr. The result is pushed into the TCL result string. -- Comment By: patrick o'leary (pjaol) Date: 2002-03-20 16:55 Message: Logged In: YES user_id=177256 This can easily be applied as a replacement for ns_hostbyaddr, simply by removing the TCL_ERROR in NsTclGetByCmd. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:26 Message: Logged In: YES user_id=16427 Can this be applied as a replacement for ns_hostbyaddr as well? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=500430group_id=3152
[AOLSERVER] [ aolserver-Patches-527863 ] ns_return and ns_write written as TclObj
Patches item #527863, was opened at 2002-03-09 19:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527863group_id=3152 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: David Walker (vt_dwalker) Assigned to: Nobody/Anonymous (nobody) Summary: ns_return and ns_write written as TclObj Initial Comment: ns_return and ns_write written as TclObjCommands. Makes returning binary data from tcl strings to connection possible. -- Comment By: David Walker (vt_dwalker) Date: 2002-03-20 16:58 Message: Logged In: YES user_id=481247 My c programming skills are of the hacker variety. I try to do it the same way I see it done somewhere else. I'm worried that if I did this I would introduce subtle errors that would cause problems later. Is there a programming guide for converting to TclObjCommands and doing the right thing? I did notice that interp-result is deprecated and looks like that would be one of those issues. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 16:23 Message: Logged In: YES user_id=16427 How possible would it be for you to go through all of AOLserver 4 and make everything a TclObjCommand and do the right thing, like Tcl_WrongNumArgs, eliminate Tcl_AppendResult (and other non-TclObj string manipulators)? -- Comment By: David Walker (vt_dwalker) Date: 2002-03-09 19:33 Message: Logged In: YES user_id=481247 patch is against aolserver 4 beta -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527863group_id=3152
[AOLSERVER] [ aolserver-Patches-527073 ] Optionally roll the server logs daily.
Patches item #527073, was opened at 2002-03-07 10:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527073group_id=3152 Category: other Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Pierre Asselin (pierrethebom) Assigned to: Kriston Rehberg (kriston) Summary: Optionally roll the server logs daily. Initial Comment: The patch is off of aolserver 3.4.2 . Add two params to ns/parameters: 1) rollhour, to roll the server logs daily; 2) rollfmt, to append a timestamp instead of .nnn suffix. The options are patterned after the nslog module. Unmodified configs preserve the current behavior. Affected files: doc/config.txt, nslog/nslog.html: Document the new params. Fix the logroll description to match reality. Also fixed the nslog docs to match what nslog/nslog.c actually does... nsd/nsd.h: New field, char *rollfmt in the nsconf.log substruct. nsd/nsconf.c: NsConfInit(): initialize nsconf.log.rollfmt . nsd/log.c: Ns_LogRoll(): append a timestamp to the file name if rollfmt given, else append a counter. LogRollDailyCallback(): new schedulable wrapper around Ns_LogRoll(). NsLogOpen(): schedule LogRollDailyCallback() if rollhour given. I checked that the roll occurs, whether by SIGHUP or by daily schedule, that timestamps or counters are appended to the log names as configured, and that the maxbackup parameters are honored. I didn't include a test case because it would have to run for days to check everything. -- Comment By: Pierre Asselin (pierrethebom) Date: 2002-03-20 08:59 Message: Logged In: YES user_id=479653 I don't know about bug 434827, the description is too succinct. I do know that the documentation is wrong in 3.4.2, access logs can be scheduled to roll daily but server logs only roll on SIGHUP. The patch fixes the docs and makes it possible to schedule server rolls as well. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 08:26 Message: Logged In: YES user_id=16427 Most excellent. To clarify: does this patch address both the server log and the access log? Do you think this might have anything to do with bug #434827? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=527073group_id=3152
[AOLSERVER] [ aolserver-Patches-421740 ] [ns_info server] broken in config interp
Patches item #421740, was opened at 2001-05-05 16:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=421740group_id=3152 Category: aolserver3_3 Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Jamie (polygnwnd) Assigned to: Kriston Rehberg (kriston) Summary: [ns_info server] broken in config interp Initial Comment: [ns_info server] doesn't work in the configuration interpreter for versions after 3.2 as nsServer is not set until _after_ the configuration is read. Setting it when the option is parsed (like it was before) fixes this issue so [ns_info server] works in the configuration interpreter like the other ns_info calls. This might be socially unacceptable or have side effects, but I haven't notice any yet. diff -r aolserver-3.4pre1/nsd/nsmain.c aolserver- 3.4pre1-mod/nsd/nsmain.c 216a217 nsServer = optarg; -- Comment By: Pierre Asselin (pierrethebom) Date: 2002-03-20 09:25 Message: Logged In: YES user_id=479653 We run a bunch of servers off a unified config file; I wouldn't mind reading the -s option from [ns_info server] within the config file, but as Jamie pointed out, that doesn't work. We have to resort to helper scripts and environment variables. Is there deep magic in the global variable nsServer? should Ns_TclInterpServer() read nsconf.server instead and Ns_Main() set it early in the case 's' argv clause? All I can say is that we could use the functionality. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 08:01 Message: Logged In: YES user_id=16427 Someone told me this shouldn't be done as the config interp is different from other interps. I think it has alot to do with virtual server support, but that means that the -s parameter should imply that ns_info server would take that value. It's still up in the air what this is supposed to do. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=421740group_id=3152
[AOLSERVER] [ aolserver-Patches-412045 ] Sybase Driver Error handling
Patches item #412045, was opened at 2001-03-28 18:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=412045group_id=3152 Category: modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Kriston Rehberg (kriston) Summary: Sybase Driver Error handling Initial Comment: Here is the patch that allows to catch sybase errors from triggers and stored procedures. -- Comment By: Peter M. Jansson (petej) Date: 2002-03-20 13:02 Message: Logged In: YES user_id=20577 This patch is essential for getting an error message back from nssybpd to the AOLserver for triggers and stored procedures, and getting those errors would not otherwise be possible. However, Sybase often generates multiple error messages for a single operation, and the AOLserver proxy protocol only allows for returning a single message. You'd have to either bundle up all of the Sybase messages into one proxy message (which would make detecting the specific error you got more difficult, since you'd then have to look for the error in what could be a bunch of messages) or you'd have to live with losing some of the errors. (In an older version of nssybpd, the proxy wasn't completing the result loop, so when an error occurred in the next query, you'd often just get an uninformative error that was the last message spewn by Sybase.) By logging all Sybase errors to the syslog or to its own file, no error detail is lost. (Another option would be to change the proxy protocol, but that's beyond the scope of this patch.) As far as the choice between logging to a private file or files versus logging to syslog, it still seems to me that logging to syslog is better. -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 11:54 Message: Logged In: YES user_id=184124 Forgot the patch -- Comment By: Vlad Seryakov (seryakov) Date: 2002-03-20 11:53 Message: Logged In: YES user_id=184124 I added propagation of Sybase erros to AOLserver driver, so Sybase error message would be visible in the log file. -- Comment By: Peter M. Jansson (petej) Date: 2002-03-20 11:42 Message: Logged In: YES user_id=20577 This does not seem to be a good idea, since it would involve re-inventing logging code, especially if multiple instances of nssybpd are to log to the same place (plus, how do you figure out where the log files should go?). Why don't you want to use syslog? -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:38 Message: Logged In: YES user_id=16427 How possible would it be to get nssybpd to log to its own log file instead of using syslog? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=412045group_id=3152
[AOLSERVER] [ aolserver-Patches-517267 ] Patch for SEGV if 401 redirect is used
Patches item #517267, was opened at 2002-02-13 16:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=303152aid=517267group_id=3152
Category: other
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Caruso (johnjcaruso)
Assigned to: Kriston Rehberg (kriston)
Summary: Patch for SEGV if 401 redirect is used
Initial Comment:
AOLserver 3.4.2 can generate a segmentation fault in
FreeUrl when it tries to dereference a NULL pointer.
This behavior happens ONLY if the server in question
has a 401 redirect specified, and it can only be
produced if a failure occurs in the Ns_ConnReadLine
routine (via rapid browser refreshes, for example).
Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x80798da in FreeUrl (request=0x0) at request.c:313
313 if (request-url != NULL) {
(gdb) bt
#0 0x80798da in FreeUrl (request=0x0) at request.c:313
#1 0x807986e in Ns_SetRequestUrl (request=0x0,
url=0x8174168 /error_pages/401.html) at
request.c:286
#2 0x8077c75 in Ns_ConnRedirect (conn=0x81bc068,
url=0x8174168 /error_pages/401.html) at op.c:231
#3 0x807af90 in ReturnRedirect (conn=0x81bc068,
status=401,
resultPtr=0xbefff864) at return.c:1206
#4 0x807a922 in Ns_ConnReturnBadRequest
(conn=0x81bc068,
reason=0x8128593 Invalid HTTP request) at
return.c:838
#5 0x807e108 in ConnRun (connPtr=0x81bc068) at
serv.c:822
#6 0x807dc3a in NsConnThread (arg=0x81b3de8) at
serv.c:671
#7 0x811db42 in NsThreadMain (arg=0x81ffae0) at
thread.c:228
#8 0x4001ebb5 in pthread_start_thread
(arg=0xbefffe40) at manager.c:241
The problem stems from the fact that conn-request is
always NULL within ConnRun just before the following
code snippet is executed:
if (Ns_ConnReadLine(conn, ds, n) != NS_OK ||
(connPtr-request = Ns_ParseRequest
(ds.string)) == NULL) {
(void) Ns_ConnReturnBadRequest(conn, Invalid
HTTP request);
goto done;
}
If Ns_ConnReadLine doesn't return NS_OK, conn-request
will remain NULL; Ns_ConnReturnBadRequest will then be
called, and it will in turn call ReturnRedirect(conn,
401, result). If a 401 redirect exists, the calling
sequence shown above will be followed, and FreeUrl
(request) will eventually be called with
request==NULL, causing the SEGV.
I was able to reproduce this segmentation fault quite
easily on a VAlinux 6.2.3 system simply by doing VERY
rapid refreshes of a page (browser doesn't matter).
I've also verified that this behavior was present in
AOLserver 3.3.1 as well. The simplest workaround is
to remove the 401 redirect.
I created a patch for this problem which calls
Ns_ParseRequest within Ns_ConnRedirect to fill in the
conn-request structure if conn-request is NULL
(rather than calling Ns_SetRequestUrl, as the current
code does), and then also prevents the request from
being reauthorized if conn-request is still NULL.
Ns_ConnRedirect seemed to be the most logical point in
the call sequence where a URL was available to be used
to fill in the conn-request structure in this case.
This patch fixes the problem, but since I'm not aware
of all the internals of AOLserver, it may not be the
optimal approach. There's also still the underlying
problem that several routines (FreeUrl, SetUrl, and so
on) reference pointers without validating them first.
Hopefully the horrible formatting in this web form
corrects itself when the patch is submitted
--
Comment By: John Caruso (johnjcaruso)
Date: 2002-03-20 10:47
Message:
Logged In: YES
user_id=452169
I'm not familiar enough with the code to give an informed
opinion, but while looking into this SEGV I found a number
of routines that dereference unvalidated pointers (FreeUrl,
SetUrl, Ns_ConnRedirect, Ns_ConnRead, and so on). My
client has been running AOLserver for several years and
hasn't run into any pointer deferencing problems until now,
though. I'd assume that most of the unvalidated references
aren't an issue because they always receive validated or
correct parameters from other routines; we just happened to
run into a major exception.
This particular problem is caused by such a simple set of
circumstances (having a 401 redirect and doing rapid
refreshes) that I'm surprised it hasn't been reported
before. In fact I did notice that the ArsDigita 3.2+ad10
patch level contains a fix for the same problem, so they
must have run into it as well. For details see:
http://www.arsdigita.com/aol3/DISTRIBUTION.txt
--
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 08:16
Message:
Logged In: YES
user_id=16427
How widespread would you say that the practice of
dereferencing unvalidated pointers is in AOLserver 3.x as a
whole?
--
You can respond by visiting:
[AOLSERVER] Reminder: AOLserver weekly chat tomorrow
The AOLserver weekly chat takes place tomorrow, 2002-03-21, and every Thursday. Common topics include AOLserver, Tcl, SQL, ACS, and general web-related questions. The place: AIM chatroom AOLserver on exchange 4 The time: 20:00 UTC During the summer, that time is 4 PM US/Eastern 3 PM US/Central 2 PM US/Mountain 1 PM US/Pacific During the winter, that time is 3 PM US/Eastern 2 PM US/Central 1 PM US/Mountain Noon US/Pacific The URL for the chat room: aim:GoChat?RoomName=AOLserver Note: you do NOT need to be an AOL subscriber to access the chat room. If you need more help getting on AIM or getting into the chat room, please see http://dqd.com/~mayoff/aolserver/weekly-chat.html. -- end of message
Re: [AOLSERVER] AOLserver.com relaunched!
I wanted to avoid the inevitable political discussion but I guess it can't be avoided. We are being hosted by Source Forge for the same reasons that Savant, acWeb, tclhttpd, Throttled and other web hosting software is hosted there. It's a good site for collaborative software development. Everything is now in the same place and I'm grateful that I don't have to strain my back every time I need to update a file download or fix documentation errors. The old environment was technologically adverse to anything that has to do with open collaboration and it was a pain in the neck to administer ever since root access was withdrawn a couple of years ago. Aside from running AOLserver.com on Source Forge (which uses Apache), it uses PHP, which is a scripting language supported on AOLserver as well. I took the opportunity, however, to convert all the AOLserver documentation, which is the largest part of AOLserver.com, from ADP to plain-Jane HTML. I think this encourages good writing practices and documentation style and has the added benefit of allowing you to download the documentation locally, not to mention make it easier to edit and to put a working and easily updated search engine (coming soon). Finally, the file manager makes distributing software a whole lot more consistent. How many times have you looked on the old AOLserver ftp site just to see the butt-old 0.9 version of something that's had major revisions, like openssl? Anyway, I hope you like it. Kris
[AOLSERVER] REMINDER: Source Forge email updates
This is just a reminder that you should use the link in the email message to discuss the bug reports, patches, support requests, and feature requests. If you just reply to this list they probably won't be read. Kris -- Kriston Rehberg America Online, Inc.
Re: [AOLSERVER] closed mailing lists, old can of worms?
No, sorry. The AOLserver mailing list archives are only available to subscribers of the mailing list. Being a subscriber does not mean you have to get emails every day, it just means you are a registered user of the mailing list. This is the only way to protect the list and its subscribers from spam harvesters. You can set the mailing list settings to NOMAIL and you remain a subscriber but don't get any mail. Kris PS...This issue comes up every couple of months in our support queue. The policy is firm and is intended to protect the mailing list and its subscribers.
Re: [AOLSERVER] 502 Error Code
One version of the text of the 502 error reported by an Apache server says The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. This may be a temporary or permanent condition, please try again at a later time. This is appropriate where the proxy server encounters a problem accessing the remote server where the remote server either 1) reports some sort of error or 2) is unreachable either temporarily or for an extended amount of time. The case of (2) is supposed to be a 503 - Service Unavailable or 504 - Gateway Timeout but I guess this is open to interpretation by the implementor of the proxy. Needless to say there are any number of things that can cause this, none of which necessarily place blame specifically on the proxy server, the internet connection between the proxy server and the remote server, and the remote server itself. AOLserver only reports 502, 503, and 504 errors when specifically instructed to do so. I've seen proxy code do this and some really weird server-to-server protocol handler stuff as well. Kris
[AOLSERVER] [ aolserver-Patches-474259 ] ns_uuencode patch
Patches item #474259, was opened at 2001-10-23 18:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=474259group_id=3152 Category: other Group: None Status: Open Resolution: None Priority: 6 Submitted By: Vinod Kurup (vkurup) Assigned to: Kriston Rehberg (kriston) Summary: ns_uuencode patch Initial Comment: Hello all, ns_uuencode is broken in AOLServer 3.4.2. It works fine for text content, but it is broken for binary content. This is important to me because OpenACS needs a way to encode binary content when it sends outgoing mail. Rob Mayoff has explained to me that this is because NsTclHTUUEncodeCmd is currently implemented as a Tcl_CmdProc and it should be implemented as a Tcl_ObjCmdProc. He also notified me that this would only work for Tcl8, so I would have to keep the old Tcl_CmdProc for Tcl7.6 So, I've fixed this (according to his helpful guidance). In order to do this, I've made the following changes: * I created 2 header files (nsd76.h and nsd8x.h) which contain the arrays of commands for the 2 versions of Tcl. These arrays used to be defined in tclcmds.c. * I've implemented the function NsTclCreateObjCmds which previously was declared, but never implemented. * I've adjusted tclinit.c to call NsTclCreateObjCmds. * Finally, I've removed NsTclHTUUEncodeCmd from tclmisc.c and instead moved it to a new file uuencode7.c. I've then implemented the new Tcl_ObjCmdProc version into uuencode8.c. These will be included conditionally from tclstub76.c and tcstub8x.c, respectively. I also included test cases and linked the from the main test cases index.adp page, so that they will get installed with a 'make install-tests' These changes will also pave the way to upgrading other procs to use Tcl_ObjCmdProcs (such as ns_return, ns_write, etc). I would love to see this applied to 3.4.2 so that we could use AOLServer 3.4.x as the official distro for OpenACS 4. Let me know if I can clarify anything. The patch is against CVS tagged nsd_v3_r4_p2 Additional files are attached: nsd76.h, nsd8x.h, uuencode7.c and uuencode8.c go in directory nsd/ binary-file, test1.adp and test2.adp go in a new folder 'uuencode' inside /tests -- Comment By: Vinod Kurup (vkurup) Date: 2002-03-20 15:38 Message: Logged In: YES user_id=123505 Well, you're right - ns_uuencode is a misnomer because it already does base64 encoding as it's written right now. This patch simply allows ns_uuencode to base64-encode binary content in addition to ASCII content. The actual encoding process (in htuu.c) isn't changed at all, so it is still valid for url encoding, etc. -- Comment By: Kriston Rehberg (kriston) Date: 2002-03-20 11:06 Message: Logged In: YES user_id=16427 This is more appropriate as a separate command since ns_uuencode is intended for htuu encoding for URLs and basic auth (bug #446886). This patch would be great if it were a different command entirely. Incidentally email should use the more acceptable base-64 encoding. That way you can take advantage of MIME email which is the more compatible way to send binary data via email. It's unfortunate that the command is still called ns_uuencode but that's the way it is, I guess. Let me know what you'd like to do. Is it really compatible enough with htuu and basic-authentication to use this new code for those things as well as data? Let me know. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=303152aid=474259group_id=3152
Re: [AOLSERVER] closed mailing lists, old can of worms?
Kriston, Can you please quote from the original when you reply to the list (particularly when the original is from weeks ago?) ..Howard -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Kriston Rehberg Sent: Wednesday, March 20, 2002 3:13 PM To: [EMAIL PROTECTED] Subject: Re: [AOLSERVER] closed mailing lists, old can of worms? No, sorry. The AOLserver mailing list archives are only available to subscribers of the mailing list. Being a subscriber does not mean you have to get emails every day, it just means you are a registered user of the mailing list. This is the only way to protect the list and its subscribers from spam harvesters. You can set the mailing list settings to NOMAIL and you remain a subscriber but don't get any mail. Kris PS...This issue comes up every couple of months in our support queue. The policy is firm and is intended to protect the mailing list and its subscribers.
Re: [AOLSERVER] [ aolserver-Bugs-446689 ] nsreturnredirect isn't
It's very possible for one to ns_write the wrong thing to a client, and be non-compliant. It's also possible for someone to do this: [ns_set put [ns_conn outputheaders] Location The Wrong Thing] ...and be non-compliant. It's also possible for someone to send out nonexistent error codes using ns_return. I do not believe that any purpose is being served by discussing the emotional impact of the rejection of patches, bug reports, feature requests, and support requests, on individuals or the community as a whole. Take it to another mailing list or the Wiki. Kris
Re: [AOLSERVER] Solaris 2.5.1 -- My God.
On Wed, 6 Feb 2002 02:28:28 -0500, Michael Roberts [EMAIL PROTECTED] wrote: ...the AOL team uses Solaris 2.6 as a test environment. The burning question uppermost in my mind (save one) is HOW DIFFERENT COULD IT BE?!?!?!? I can't really say what is different about it except for some truly major pthread/LWP changes, something to do with POSIX signalling, and the space of about three years. I just gave away my remaining Solaris 2.6 dev box so Solaris 7 is the low water mark now and I can't think of anything to say except a pithy upgrade your operating system remark. If you can, get gcc-2.95.3 and compile using -fPIC (gmake gccme=1) and pray for the best. Even better, download the recommended patch roll-up for 2.5.1, download the evaluation copy of the Sun C compiler and its requisite 2.5.1 patches, and start over, possibly doing gmake nativeme=1. Regards, Kris
Re: [AOLSERVER] spat of SourceForge messages
What was up with all those SourceForge messages? Did Kris just do a mass-assign to himself for all the open tickets? Or did something else happen that I missed ... ? Sorry, this will start calming down shortly once I finish cleaning out the cobwebs. Kris
Re: [AOLSERVER] Solaris 2.5.1 -- My God.
Kriston Rehberg wrote: On Wed, 6 Feb 2002 02:28:28 -0500, Michael Roberts [EMAIL PROTECTED] wrote: ...the AOL team uses Solaris 2.6 as a test environment. The burning question uppermost in my mind (save one) is HOW DIFFERENT COULD IT BE?!?!?!? I can't really say what is different about it except for some truly major pthread/LWP changes, something to do with POSIX signalling, and the space of about three years. I just gave away my remaining Solaris 2.6 dev box so Solaris 7 is the low water mark now and I can't think of anything to say except a pithy upgrade your operating system remark. If you can, get gcc-2.95.3 and compile using -fPIC (gmake gccme=1) and pray for the best. Even better, download the recommended patch roll-up for 2.5.1, download the evaluation copy of the Sun C compiler and its requisite 2.5.1 patches, and start over, possibly doing gmake nativeme=1. I might add that you will have a hard time getting a compiler and/or support for 2.5.1 from Sun nowadays. They want this to disappear, and all I can say is that they have good reason. People should be on the 2.6+ for better stability, improved performance, ... Jeff
Re: [AOLSERVER] blowfish module for aolserver
I've had requests to add standard encryption to nsopenssl so you can encrypt things in memory or on disk with normal symmetric algorithms. True, there's a lot of stuff in OpenSSL (e.g. the SSL part) that you wouldn't be using if you weren't running an SSL port, but OpenSSL seems to be widely accepted and widely used for these and other things. Plus, it is capable of having BSAFE compiled into it instead of the algorithms that come with OpenSSL. At some point I will be adding standard encryption capabilities to nsopenssl like those mentioned above, and also splitting nsopenssl into 2 modules: nsopenssl.so and openssl.so, so that the openssl.so part is loaded once but can then be used by any number of modules. The nsldap module would benefit from this as it could be modified to do ldaps. Alternatively, I've been toying with the idea of adding an Ns_OpenSSLWrap function that would allow any other module to call it to wrap a connection with SSL. You can already do these kinds of things by using the other nsopenssl C functions like Ns_OpenSSLSockOpen and so on. One of the major things on the horizon where I work is using PKI client certs and signing objects in memory or on disk. Unfortunately, since they've made me a supervisor I've had to spend a significant amount of my time dealing with bureaucratic issues, personnel issues, checking boxes and the like (the government seems to run on these things; go figure), so I've not had a lot of time available to work on these things. Anyway, I for one would love to see your module make it into open source. If that doesn't happen, I'd still like to get a copy to look at; I'm not very good at coding and there are probably a lot of things in there that will help me when I add some of these capabilities to nsopenssl. /s. -Original Message- From: Kriston Rehberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 2:08 PM To: [EMAIL PROTECTED] Subject: Re: [AOLSERVER] blowfish module for aolserver I have this software I wrote many years ago and still maintain that uses BSAFE to do des, 3des, rc2, rc4, rc5, rsa, random numbers, and base64-encoding for the binary parts. I was wondering if anyone had any software they liked to use for these algorithms and whether you thought BSAFE was appropriate or if you wanted me to look into releasing this into open source (especially if it still required BSAFE). The BSAFeay project seems to have died a quiet death and I'm not very keen on using OpenSSL as an encryption library like OpenSSH and BSAFeay do... so much in there that has nothing to do with encryption. Thoughts? Kris
[AOLSERVER] [ aolserver-Support Requests-532787 ] LDAP support
Support Requests item #532787, was opened at 2002-03-20 22:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=203152aid=532787group_id=3152 Category: Configuration: Other Group: aolserver4_0 Status: Open Resolution: None Priority: 5 Submitted By: bill burns (shadownscp) Assigned to: Nobody/Anonymous (nobody) Summary: LDAP support Initial Comment: What are the plans, if any, to add support for LDAP authentication and authorization? In particular, I'm looking for roadmaps on basic-auth and client-auth authentication methods and support for LDAP dynamic group authorization. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=203152aid=532787group_id=3152
Re: [AOLSERVER] Solaris 2.5.1 -- My God.
Jeff Hobbs wrote: [stuff] Kriston Rehberg wrote: [stuff] I might add that you will have a hard time getting a compiler and/or support for 2.5.1 from Sun nowadays. They want this to disappear, and all I can say is that they have good reason. People should be on the 2.6+ for better stability, improved performance, ... Yes, yes, thank you all, but in the past two months I have indeed moved to another server entirely. Which (in fact) I mentioned in passing last month. But I'm gonna miss that ol' Sparc. It was a handy workhorse for a long time. I'm thinking it might be happy as a home file server. (After moving most of its functionality to a dual-Pentium Dell I have no desire to use the Sparc as a server any more.)
