gmane.comp.web.aolserver

Re: ns_adp_parse ignore safe option

Alexey Pechnikov — 2008-09-05T13:53:06

Hello! В сообщении от Friday 05 September 2008 16:55:50 вы написали: Thanks! Best regards, Alexey.

Re: ns_adp_parse ignore safe option

Juan José del Río — 2008-09-05T12:55:50

Hello Alexei, If you check the history of that page: http://dev.aolserver.com/wiki/index.php?title=Ns_adp_parse&diff=5098&oldid=2833 the "-safe" part was added on 24 September 2007... which is more recent than AOLServer 4.0. So, if I am not wrong, the "-safe" switch is only available for AOLServer 4.5, not 4.0 Regards, Juan José - Juan José del Río | (+34) 616 512 340 | juanjose< at >simpleoption.com Simple Option S.L. Tel: (+34) 951 930 122 Fax: (+34) 951 930 122 http://www.simpleoption.com On Fri, 2008-09-05 at 15:19 +0400, Alexey Pechnikov wrote:

ns_adp_parse ignore safe option

Alexey Pechnikov — 2008-09-05T11:19:06

Hello! In page http://dev.aolserver.com/wiki/Ns_adp_parse is writed "If you specify the -safe flag, then only registered tags are executed; inline scripts using "<% ... %>" or "<%= ... %>" are ignored." I'm try to using ns_adp_parse -file -safe $fname and <% ... %> sections are executed! It's very unsecure for me. What can I do? I'm using AOLServer 4.0.10-7 from debian etch. Best regards, Alexey.

Re: Problem running Aolserver with Valgrind

Sep Ng — 2008-09-02T08:14:15

Yeah. I know it's supposed to work. Oracle just refuses to cooperate it seems. I'm not sure why nor how valgrind could result in a TNS permission denied error. I've seen a few cases similar to mine on the net, and none of them have a solution. On Sep 2, 1:53 pm, Mark Aufflick AUFFLICK.COM> wrote:

Re: Problem running Aolserver with Valgrind

Mark Aufflick — 2008-09-02T05:53:35

Not that this helps you, but I successfully run aolserver under valgrind without any database module loaded. On Tue, Sep 2, 2008 at 11:14 AM, Sep Ng gmail.com> wrote:

Problem running Aolserver with Valgrind

Sep Ng — 2008-09-02T01:14:37

Hi, I've been trying to get aolserver to run on Valgrind for a week now and it does work to a certain extent. My Aolserver interfaces with Oracle databases and my problem is that when I do run aolserver on valgrind and nsoracle driver attempts to connect to Oracle, I get a OCIServerAttach ()': ORA-12546: TNS: Permission Denied error. I'm not sure why it's doing this. It works fine without valgrind. I've even set my permissions bits on oracle binary as rwsrwsrwx. It's still not working. I need help, please. :( I don't know where to look. Thanks. Sep

Re: PATCH: Support ipv6

Daniël Mantione — 2008-08-30T06:51:25

Op Sat, 23 Aug 2008, schreef Daniël Mantione: Hi, No comments? I would like to have this into cvs after review. Daniël

Re: problem getting binary data from C to a tcl object to an aolserver connection

Stephen Deasey — 2008-08-29T03:11:55

On Fri, Aug 29, 2008 at 3:18 AM, Mark Aufflick aufflick.com> wrote: With the write_encoded flag set (which ns_startcontent sets) ns_write will assume you're sending character data and will want to encode it into iso-8859-1, or whatever is configured. With the write_encoded flag off, ns_write will use Tcl_GetByteArrayFromObj() rather than Tcl_GetStringFromObj(), and because you used Tcl_NewByteArrayObj() in your C code, your bytes will pass through unmolested.

Re: problem getting binary data from C to a tcl object to an aolserver connection

Mark Aufflick — 2008-08-29T02:18:33

Hi Stephen, What does ns_conn write_encoded false do (although it is somewhat self explanatory)? Also ns_startcontent is neat - saves me manually fudging the header with ns_write. On Fri, Aug 29, 2008 at 5:52 AM, Stephen Deasey gmail.com> wrote:

problem getting binary data from C to a tcl object to an aolserver connection

Mark Aufflick — 2008-08-28T08:50:09

Hi all, If I Ns_Log() the data in a (char *) I can clearly see that it contains newlines, and I can also verify that it contains nulls with memchr. I have tried any number of ways to turn it into a tcl object, eg: objPtr = Tcl_NewByteArrayObj(str, length); or objPtr = Tcl_NewObj(); Tcl_AppendToObj(objPtr, str, length); or objPtr = Tcl_NewStringObj(str, length); etc. this is then set as the result object, and control returns to the tcl code. Whether the tcl code then does an ns_log, ns_return (which I know isn't supposed to be binary safe) or ns_write, i get all the newlines converted into \n (ie. two characters \ then n) and chunks of binary get converted to unicode characters. I can see from Tcl_AppendToObj that that is supposed to happen there, but how can I output a byte array object without it being converted to utf8? Any help appreciated - this is driving me nuts :)

Re: problem getting binary data from C to a tcl object to an aolserver connection

Stephen Deasey — 2008-08-28T19:52:32

On Thu, Aug 28, 2008 at 9:50 AM, Mark Aufflick aufflick.com> wrote: This is the right way to do it. In AOLserver 4.5, ns_write is the only command that accepts a binary data. You also need to be careful you don't accidentally change it's type once you've created it. set blob [myblobcmd] set length [string length $blob] # blob now garbled utf8 :-( Something like... ns_startcontent -type application/octet-stream ns_conn write_encoded false ns_write $blob

Re: problem getting binary data from C to a tcl object to an aolserver connection

Tom Jackson — 2008-08-28T14:37:27

Mark, Hard to say what you are actually trying to do, but UTF-8 is a byte array, if you want to call it that. The problem you are seeing may be in displaying what the bytes are (which might not work for binary data, try cat'ing a binary file and watch the fireworks.) tom jackson On Thu, 2008-08-28 at 18:50 +1000, Mark Aufflick wrote:

ns_ldap and ldap bind command

Mark Aufflick — 2008-08-24T10:53:50

Hi all, Researching the use of ns_ldap in OpenACS it seems that the version of ns_ldap in wide use is http://www.sussdorff.de/resources/nsldap.tgz which seems to have additional support for ldap bind (note I am not an LDAP expert so forgive me if I'm using the wrong lingo). The diff is pasted below. Should this be committed to the tree? diff -r nsldap/nsldap.c nsldap-sussdorf/nsldap.c 1373a1374 1796a1798,1820 diff -r nsldap/README nsldap-sussdorf/README 186a187,191

PATCH: Support ipv6

Daniël Mantione — 2008-08-23T15:18:50

Hi, Ipv6 is becoming more important, with only only a few years of ipv4 address space left and governments starting to require it when doing business with them. I'm running ipv6 myself for a while now, but my webservers are still ipv4 only, because they run ipv4. So, I wrote a patch, downloadable here: http://www.freepascal.org/~daniel/aolserver-ipv6support.diff ... it applies against AOLserver-cvs. After applying the patch, AOLserver uses AF_INET6 rather than AF_INET. While of course, experimental, AOLserver seems to serve pages perfectly fine on both ipv4 and ipv6, with no impact on configuration files, or TCL code. Everywhere you could use an ipv4 address before, it now simply accepts both. Daniël

Re: Data "corruption" with fastpath caching

Tom Jackson — 2008-08-22T21:19:08

Jim, Can I ask why the filename is important for the cache key? With the cache delay, the inode/dev + *time + size should do it all. In fact, I finally understood the difference between mtime and ctime, if any change is made, it should be the change to ctime. Why ctime? ctime is unique in that it isn't something that can be set by user level programs. It changes whenever the content of the file changes or permissions, owners, or any of the metadata of the file. So, for instance, if someone replaces a file with an identical file, the ctime would still change. If you check the ctime, you can also skip checking the size. But none of this has to do with the filename. On Unix, filenames are especially squishy. both stat and open follow symbolic links, and you could therefore use a symlink to point to different files over time, but the files could have identical mtime, atime, size, owner, etc. using stat/open and comparing with what is in cache based upon the filename would never detect this slight of hand

Re: Data "corruption" with fastpath caching

Jim Davidson — 2008-08-22T17:18:35

Ah -- I (finally) understand... I must have missed the detail re: serialization in message #30 out of #60 or so.... So, this clarifies to me:

Re: Data "corruption" with fastpath caching

John Caruso — 2008-08-22T03:27:09

To clarify as well: the original code didn't involve a race condition--it was effectively serialized, as though it were like this snippet: foreach object $objects { eval exec /some/external/program --output-file $tempfile --object $object ns_returnfile 200 text/plain $tempfile } (As I mentioned to you, this was basically a batch process driven by a client-side Java applet making sequential HTTP requests to an AOLserver-driven API web server, one transaction at a time, with the results being returned by ns_returnfile on the server. Also, the temp file in question was in a secure directory.) So the bug can (and did) manifest itself with serialized access. Again, this wouldn't have resolved Arena's initial problem; the original code would still have hit the bug, and it would have been just as difficult to detect that that was happening (though slightly easier to debug). That's why I'd recommend having the mtime workaround code active with a default of 1--otherwise p

Re: Data "corruption" with fastpath caching

Tom Jackson — 2008-08-22T00:44:06

John, Your patch fixes this issue as best it can be fixed. The issue that Titi is addressing cannot be fixed. With your patch you can be sure of the following: 1. All cache entries are unique. You can't create and cache two files with the same inode and mtime and have both be over 1 second old. 2. When an inode is reused (by the filesystem) the associated file mtime will be larger than the mtime of the cached entry. The new entry will replace the old entry. 3. If several files point to the same inode, updating this entry updates all of them (there is only one cache entry if the inode is used.) 4. If a file changes on disk, and it is less than 2 sec old, it is served directly, skipping the cache. tom jackson

Re: Data "corruption" with fastpath caching

Tom Jackson — 2008-08-21T23:31:53

Here is an example using Tcl level commands (although a hidden use of mutex/condition vars: # save datastore to file # Note: a data.tmp file is created. If writing to this # succeeds, this is renamed to the data file, hopefully # atomically replacing it # Note2: the data.tmp file is not a lock file, it is used # to avoid a half written file in the event of power loss # or process exit. proc ::datastore::save { store } { .... set LockID [lock $store] if {[catch { set FD [open ${dataFileroot}.tmp w+] fconfigure $FD -translation binary -encoding binary puts $FD "$out" close $FD file rename -force ${dataFileroot}.tmp $dataFileroot } err ]} { unlock $store $LockID error $err "::datastore::save error saving store $store" } unlock $store $LockID } But it is very difficult (impossible) to safely read/write files unless you can synchronize access (you need cooperation) and/or use atomic file operations (serialize access). The above example uses both. tom jackson

Re: Data "corruption" with fastpath caching

John Caruso — 2008-08-21T20:52:31

Yep. I think that aspect of the issue has been getting lost--it's not just about getting stale data from a given file, but getting data from an entirely *different* file, which I'd agree violates any reasonable expectation of a caching system. You make a good point. The fix I suggested is intended to make fastpath caching behave well in all cases where time proceeds monotonically (which I'd guess is by far the most common use case, especially for a web server that's unlikely to call utilities like tar/rsync that would munge file times). In fact that's essentially what I mean by "pathological". But to protect against the time-travelling scenarios causing fastpath to confuse two different files, you'd have to use the filename-as-key fix as well. Using the filename as a key is a bummer for sites like AOL that want the cache to respect hard links when serving data from the cache, though. It won't matter for us either way, since we're not that concerned about the cache in the first place--jus

Re: Data "corruption" with fastpath caching

Jim Davidson — 2008-08-21T21:34:50

Hi, Yes -- the original reason for dev/inode on Unix instead of filename was to reduce memory consumed in the case of a large # of symlinks or hardlinks to the same file. This was the case for AOL's digitalcity.com back in 1999. For better or worse, the "AOL" in AOLserver means AOL was used as the model and we never had an example of dynamically creating files to be returned by fastpath (this isn't 100% true -- see below). Now, had we known 10 years ago that inodes could be rapidly reused as John pointed out, we would have never written the code to use dev/ inode as opposed to filename keys. It simply cannot be strictly correct given the non-atomic nature of the stat() before the open(). It may have been available as an option, but certainly off by default and likely undocumented. So, here's what I'd suggest: