AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070523105222.3a300110@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<larry.scheer@onstor.com>,<dl-cougar>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E022157EB@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 23 May 2007 10:54:00 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Cc: <dl-cougar>
Subject: Re: nfxdns library porting
Message-ID: <20070523105400.719af98e@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E022157EB@onstor-exch02.onstor.net>
References: <20070523103719.14a0cccb@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E022157EB@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks, Larry.  I chatted this out with Tim, and I think I have to
concede that it's a bit risky for phase 1.  Maybe phase 2.  Even if
it's simple to implement, it then has to be debugged and so on. Even if
that only adds a week, we don't really have a week to spare.  I use
this argument against other ideas so I have to be fair and use it
against this one too, at least in the short term.

Max's idea #2 is probably the only one that is not terribly risky or
nightmarish.  It's just ugly, but it's the prettiest of the bunch.

Cheers,

a


On Wed, 23 May 2007 10:47:54 -0700 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> I think your plan, Andy, makes the most sense and it is portable.
> If we are voting, then I say "aye" to Andy's idea.
> 
> Larry
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Wednesday, May 23, 2007 10:37 AM
> To: dl-cougar
> Subject: Re: nfxdns library porting
> 
> On Wed, 23 May 2007 10:24:51 -0700 "Maxim Kozlovsky"
> <maxim.kozlovsky@onstor.com> wrote:
> 
> > Hello,
> > 
> > Yesterday we discussed with Andy the options on the resolver library
> > porting (ssc-nfxnis/nfxdns-*), here is the recap:
> > 
> > Our BSD libc resolver library has been modified to provide the name
> > resolution in the context of the virtual server. Instead of single
> > per-process context, each process has per-virtual server resolver
> > state. Before calling into the resolver library, the nfxdns code
> > modifies the library global variable to select the appropriate
> > context. In some cases, the calls are made to the library internal
> > functions, which will not be available in the Linux version.
> > 
> > There are several options:
> > 
> > 1)	Make the equivalent changes in the Linux libc
> > 2)	Use the already modified BSD resolver library instead of
> > libc for nfxdns. 
> > 3)	Do something different :-)
> > 
> > Due to the time and resources constraints the third options is not
> > feasible. Neither 1 nor 2 are very appealing from aesthetical point
> > of view, however we need to pick one, and between these two the
> > second seems the most promising to me. The problem reduces to
> > compiling the BSD library code for Linux, which should not be that
> > hard. If anybody has better ideas, please share.
> 
> Here's my idea, however, I think #2 may fit into our delivery schedule
> for phase 1 a little better, but I'm not sure about that.  This really
> should be pretty simple to implement.  But then there's debugging....
> 
> Run named (bind9 package) on the ssc, and configure it with virtual
> servers info .. just like they were real domains authoratively hosted
> by the ssc.  Very simple.  Even though the clusterdb is the real
> authority.  Every time the data is updated in the clusterdb, just
> fire a thread to dump the data for that vserver to the bind config
> file(s) and restart named.  No custom libresolv modifications to jam
> into libc or our own code, and completely portable - as long as you
> use named. Simple, clean, efficient.
> 
> Comments?
> 
> Cheers,
> 
> a
> 
