Re: [9fans] dns vs. textrr
Haven't seen it. But it does seem that a lot of us are having fun with dns this week (and every week). Mine's more the problem of ndb/dns -sx /net.alt -f /lib/ndb/external configuration and properly getting it a resolver from a subsequent dns= tuple. One day I'll remember to keep it simple and just have everything in /net and learn to manage the bridging between networks. -jas On Jan 19, 2012, at 10:01 AM, erik quanstrom wrote: a long text record seems to be causing lookup failures for other records. with the record below in /lib/ndb/external, lookups for mx.coraid.com fail. with just that line deleted, lookups work again. older versions of dns don't seem to have that problem. i was wondering if anyone had seen this? - erik dom=m1._domainkey.coraid.com txtrr=k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFUlNZvtGDlIGDRtzyRQydM9yRInD5YMx86QpgZ3v7pT+Mx4tGbjUxY41TXbsp7UH9hTREaKKGQKNM/B3FzcFVv4zafZ09lUaXcbSdtD70iXyH0OXEGXLZI5gG0ZwjK5ptgQ18d+pUP9s8xMkJnZlubTk9MLvQnv3ZBzoL9FHFDQIDAQAB
Re: [9fans] dns vs. textrr
On Thu Jan 19 12:08:37 EST 2012, j...@corpus-callosum.com wrote: Haven't seen it. But it does seem that a lot of us are having fun with dns this week (and every week). Mine's more the problem of ndb/dns -sx /net.alt -f /lib/ndb/external you probablly want -R too, so you ignore the RD flag on incoming queries. the key to getting plan 9 resolution working right is to have the proper ipnet configuration that has a proper netmask s.t. ndb/ipquery $sys dns gives a credible answer. e.g. ladd; ndb/query ipnet athensnat ipnet=athensnat ip=192.168.0.0 ipmask=/120 fs=aska.quanstro.net ipgw=192.168.0.4 gw=dexter-peak.quanstro.net dns=192.168.0.136 dnsdomain=quanstro.net authdom=plan9.quanstro.net auth=ladd cpu=ladd smtp=ladd ladd; ndb/ipquery sys ladd dns dns=192.168.0.136 ladd; ndb/query sys ladd ip=192.168.0.136 sys=ladd ether=001d92350045 dom=ladd.quanstro.net proto=il - erik ps. the limit is 214 characters in that particular textrr. one would expect 256, evidently the difference is the meaning of life.
Re: [9fans] dns vs. textrr
it turns out that the problem with ndb is actually a bio
problem Brdline() freaks out and returns nil if the line
in question is longer than b-bsize and doesn't increment
the file pointer, so you've got an infinite loop.
i had thought that this was clearly in violation of
what the man page says, but on second read, i'm not so
sure. i would think that Brdline() should return a
buffer if there are bytes available—otherwise it
could be confused with eof, but that's clearly not
what the code does.
it seems from the existing bio code the only reasonable way
eat lines that are too long is
/* get a line (ignoreing long ones) */
dump = 0;
for(;;){
if((line = Brdline(b, '\n')) == 0){
if(Blinelen(b)0){
Bseek(b, Blinelen(b), 1);
dump = 1;
continue;
}
break;
}
if(dump){
dump = 0;
continue;
}
break;
}
that seems a bit ... goofy. it would seem better for
bio to do this internally? surely there isn't code that
relies on this behavior?
- erik
Re: [9fans] dns vs. textrr
On 2012-01-19, at 2:12 PM, erik quanstrom wrote: that seems a bit ... goofy. it would seem better for bio to do this internally? surely there isn't code that relies on this behavior? Or maybe realloc() a larger buffer and try to carry on? There's no guarantee of buffer pointer consistency across B* calls, is there? Default to 8K (or whatever), and place an adjustable cap of, say, 128K, on the dynamic bsize. Given some XML stanzas I've seen lately, elastic buffers have a lot of appeal ...
Re: [9fans] dns vs. textrr
On Thu Jan 19 18:33:42 EST 2012, lyn...@orthanc.ca wrote: On 2012-01-19, at 2:12 PM, erik quanstrom wrote: that seems a bit ... goofy. it would seem better for bio to do this internally? surely there isn't code that relies on this behavior? Or maybe realloc() a larger buffer and try to carry on? There's no guarantee of buffer pointer consistency across B* calls, is there? Default to 8K (or whatever), and place an adjustable cap of, say, 128K, on the dynamic bsize. sizing the buffer has been considered (putting in a cap puts the caller in the same position as before). it's probablly the best option, if the goal is to rehabilitate Brdline(). i'm wondering if it shouldn't just be considered depricated. - erik
Re: [9fans] dns vs. textrr
On 2012-01-19, at 3:56 PM, erik quanstrom wrote: it's probablly the best option, if the goal is to rehabilitate Brdline(). i'm wondering if it shouldn't just be considered depricated. If you don't think of Brdline() as a 'C char *' construct, it's a useful vessel to escape from one of the most evil parts of parsing text. I won't begin to recount the pain I've endured dealing with text protocol parsers that didn't get the \r\n split across the buffer boundary right. If you're claiming to read a line, just do it. I don't care if you have to buy dictionaries to hold the words, and front-end loaders from which to fill them! Certainly some smarts can be added to deal with inflated buffers when they are no longer needed. But for now, dying from malloc(HUGE) isn't much worse than the current behaviour. --lyndon
Re: [9fans] dns vs. textrr
On Thu Jan 19 19:13:14 EST 2012, lyn...@orthanc.ca wrote: On 2012-01-19, at 3:56 PM, erik quanstrom wrote: it's probablly the best option, if the goal is to rehabilitate Brdline(). i'm wondering if it shouldn't just be considered depricated. If you don't think of Brdline() as a 'C char *' construct, it's a useful vessel to escape from one of the most evil parts of parsing text. I won't begin to recount the pain I've endured dealing with text protocol parsers that didn't get the \r\n split across the buffer boundary right. If you're claiming to read a line, just do it. I don't care if you have to buy dictionaries to hold the words, and front-end loaders from which to fill them! Certainly some smarts can be added to deal with inflated buffers when they are no longer needed. But for now, dying from malloc(HUGE) isn't much worse than the current behaviour. depricated, as in use Brdstr(2) instead which does its own dynamic allocation. - erik
Re: [9fans] dns vs. textrr
On 2012-01-19, at 4:14 PM, erik quanstrom wrote: depricated, as in use Brdstr(2) instead which does its own dynamic allocation. This is where 'grep -r' is useful. How much pain might it be to nuke-and-replace the dead interface?
Re: [9fans] dns vs. textrr
On Jan 19, 2012, at 11:17 AM, erik quanstrom wrote: On Thu Jan 19 12:08:37 EST 2012, j...@corpus-callosum.com wrote: Haven't seen it. But it does seem that a lot of us are having fun with dns this week (and every week). Mine's more the problem of ndb/dns -sx /net.alt -f /lib/ndb/external you probablly want -R too, so you ignore the RD flag on incoming queries. not necessarily what I want, but I've tried that too. the key to getting plan 9 resolution working right is to have the proper ipnet configuration that has a proper netmask s.t. ndb/ipquery $sys dns gives a credible answer. e.g. yep, I get clean sys, ip, etc resolves for nodes in my /lib/ndb/external file. It's the next hop out that just doesn't happen. No pointer to the next dns server to do a lookup, e.g. sources.cs.bell-labs.com. Turns out Presotto posted a little comment in 9fans years back about adding root entries into an ndb file would solve it. It works, now I can replica/pull and 9fs sources til the cows come home from a cpu server that spans multiple networks. So as a reminder: ndb/dns -sx /net.alt -f /lib/ndb/external will require the external file to have the ROOT-SERVERS.NET ns entries defined even if you have the following: database= file=/lib/ndb/external file=/lib/ndb/common ^just copy the *ROOT-SERVERS.NET lines from /lib/ndb/common into the external file. It may just be more practical to copy local.complicated to external and edit from there. Researching the lack of the database reference to /lib/ndb/common is left to the reader. -jas
