[rbldnsd] [RFD] [long[ish]] to be or not to be...

[Chris.]

On Fri, 11 Apr 2008 19:16:59 +1200, Amos Jeffries wrote...

> Michael Tokarev wrote:
>> This is a somewhat long request for comments/discussion.
>> 
> <snip details>
>> 
>> Ok.  So here are the questions, finally... ;)
>> 
>> o to start with, if this whole stuff will be implemented,
>> next version will be rather incompatible, and it'll be
>> the first really incompatible version.  I don't like
>> this at all, but from another point of view this way
>> eliminates quite some ugliness and makes things more
>> strightforward and clean.
>> 
>> o while at it, maybe remove glue records and combined
>> dataset entirely? :)
>> 
>> o there are other ways exists to implement SOME of the
>> features.  For example, to make the chains to be a
>> property of certain dataset types, not zone property -
>> i.e., "acl" dataset will allow to "connect" some other
>> dataset to it, but not any dataset type will allow this.
>> That way, not every dataset will be "combinable",
>> ugliness will increase (in both code and documentation
>> and understanding of things) and flexibility will
>> decrease.
>> 
>> o when we collecting information about a particular zone
>> (after a (re)load), we cache A records for our NS (glue
>> records, that is).  For this, we run our NS records over
>> all our datasets as if it were some client asking for
>> A ns.bl.ex.com..   But now, if an ACL is on the way,
>> what we should do?  (Currently an ACL is ignored here;
>> the difference from regular query is that there's no
>> client per se).
>> 
>> o what are our choices for situations like outlined,
>> e.g. when client asks for A records and ACL is present.
>> 
>> Or.. something like that...
>> 
>> Comments, anyone?
> 
> I agree with you that the possibilities sounds great.
> You are the one coding though Michael, so in the end it is up to you
> whether you are willing to put up with the code mess any longer.
> 
> If you do go ahead with this I think its the kind of change which
> calls for a major version update. A 2.x type of thing, where so far
> its all been 0.9* and 1.0 stuff.
> 
> Documented well it would be no problem for new installs. Older small
> setups like ours here can cope. If we have enough warning that the
> change is coming we can plan for upgrades. Even the large systems
> should be able to cope given a build-up.
> 
> Someone may correct me, but what I have seen of the dsbl.org setup,
> Largest I know of. Is done in a way that can cope with this type of
> change without major hiccups.
> 
>> 
>> Thank you for your attention.  And please excuse me for
>> this long email.  I'm quite stuck now, because I don't
>> know where to go from here.  One half of me tells me
>> "lets broke it all for a better world", while another
>> half says "hey, think about poor users who will have
>> even no way to keep their config compatible!".  Oh well...
> 
> Well, we go through major and minor config changes regularly for other
> software. Often with less warning and worse side-effects.

Greetings Michael, and All,

I would have to agree (dittos). eg; Just do it. :)
I think maybe you would be best served by starting the changes in a 2.x
branch. That provides users with 2 choices, and leaves a /clear/
division between the 2 versions/feature-sets. It also allows also
permits "point" versions for both (if need be). Assuming you will not
want to maintain /2/ code branches, you can place an EOL (End Of Life)
date on the previous branch, and be done with it. :)

I am especially fond of this:
----[quote]---------------------------------------------
Aha, config ugliness.

Since config file for rbldnsd is a shell fragment, it's
easy to reduce the config to something more readable,
by defining and using shell variables, like this:

dsbl_list=ip4tset:dsbl/rbldns-list.dsbl.org
dsbl_flist=ip4tset:dsbl/rbldns-fresh.list.dsbl.org
gacl=acl:global-acl
dsbl_acl=$gacl:acl:dsbl/acl

RBLDNSD=...
list.dsbl.org:$dsbl_acl:$dsbl_list \
list.dsbl.org:$dsbl_acl:$dsbl_flist \
----[quote]---------------------------------------------
Any possible complexity that the /new/ feature-set introduces
is all eliminated here - Excellent!

Thank you for all the work you have, and continue to do with
rbldnsd!

--Chris


> 
> AYJ
> 
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd
_________________________________________________________________
    http://fastmail.ca/ - Fast Secure Web Email for Canadians