From scharf at isc.org Sat Aug 21 21:58:39 2010 From: scharf at isc.org (Jerry Scharf) Date: Sat, 21 Aug 2010 14:58:39 -0700 Subject: [Bind10-uides] results of a kibitz with Ben Message-ID: <4C704C0F.1070708@isc.org> Hi, Ben and I talked for a while last night. We did a little work as well. We kind of concentrated on the types of operational issues that might be encountered and how this would shape the tool requirements. This is no particular order. If we had an RBAC system, how would one specify a rule based version of the two person signoff rule? How do we put locks on upper level objects. We talked about a bunch of ideas, but found one that best identified the need. Say part of the management datastore was actually imported from another system. For reasons beyond our control, there will be a window where the other systems data will be inconsistent. We will need to prevent any of the objects related to that store from changing, lest things start disappearing and appearing with bad results. Has anyone even seen positive and negative role matching for rbac? Could you turn off all access to a node by having a hierarchical role structure and then putting in !someone at the head of the access list? We also had a great laugh that we wanted to have a role called nobody. That way when someone says nobody can touch it, I know they are talking about me. :) We talked a bit about comments and tickets. We decided that we should have a opaque blob (maybe a uint64) down in the resource records and then have the management side take the rr info and the blob and figure out all the pieces that are available from there. I think there needs to be some more thought on how this backtracking works in an expandable way. We came up with at least a partial list of things that ops people would really like to havebeyond being able to create, update and delete rrs and controls: comment and ticket stored (i know you can stick the ticket in the comment, but I hate that) audit trails users, rbac and acls (possibly crud, possibly more) it's really hard to separate these transaction logic (begin, commit, rollback) being able to do expanded queries down the management path and get extra data being able to do DNS queries from the tool being able to examine the logs and stats from the tool We thought that comments, tickets and audits without users would be a doable and interesting first set of added functions. Or maybe we even punt audits till the second round. Things that are in the core of the tools would be data model and store related action functions, most importantly translate to RFC and bind10 objects display functions templates one validation script We started talking a bit about the objects in the data abstraction, but that isn't near far enough along to put anything down. We were thinking fairly hierarchically about objects, servers were a type of host and namesever was a type of server... Ben one thing we missed was the concept of a cluster. So this set of hosts are treated as a group when attached somewhere instead of a single entity. An example would be "these are the set of mail servers for the americas" and could be used anywhere a single mail server is allowed. extracting zone cuts as a top level entity has some pretty cool effects. Things like "insert zone cut" become a relatively simple operation. "remove a zone cut" takes a bit more care (what if the parent and child zones have a different MX set for *.) From scharf at isc.org Sat Aug 21 22:15:04 2010 From: scharf at isc.org (Jerry Scharf) Date: Sat, 21 Aug 2010 15:15:04 -0700 Subject: [Bind10-uides] an interesting possibility for a guiding principal Message-ID: <4C704FE8.8070600@isc.org> What if we followed an experienced DNS consultant that walked into anew job? Their first job would be to understand the current DNS configuration and contents, then determine what their client was trying to do, possibly guiding that discussion to get the right answers out. They would then take the combination of what they have and what they are trying to do, and organize it into a rational structure that has the necessary components and the right relationships. Finally, they would translate this structure into a combination of direct data/configurations and tools to create all the right things that the nameservers need to offer the right things the right way. This is very close to what I see as the ideal case for the tool. The tool first reads the current state (BIND9 zones and configs) ans/or asks a series of questions that guide the basic layout, possibly adding some education along the way. It takes this to build an intermediate data store in which the logical entities are well organized to the needs of the job. Finally it emits the lower level RFC and bind10 data to cause the right things to be offered the right way. If we got N DNS consultants in a room and stroked all their egos appropriately, could we find just about all we need to design the current and near future needs of the tool? jerry From brett at the-watsons.org Sat Aug 21 22:26:33 2010 From: brett at the-watsons.org (Brett Watson) Date: Sat, 21 Aug 2010 15:26:33 -0700 Subject: [Bind10-uides] Comments on Jerry's doc (a bit late, apologies) Message-ID: <891D2C37-ABDE-4719-9F54-0154372138CB@the-watsons.org> The writer in me couldn't help but edit in places. Not sure if this doc will ever see any wide publication but may as well look good :) -b -------------- next part -------------- A non-text attachment was scrubbed... Name: BIND 10 command tool concepts-bwatson.doc Type: application/msword Size: 53248 bytes Desc: not available URL: -------------- next part -------------- From scharf at isc.org Mon Aug 23 17:46:48 2010 From: scharf at isc.org (Jerry Scharf) Date: Mon, 23 Aug 2010 10:46:48 -0700 Subject: [Bind10-uides] updated document Message-ID: <4C72B408.6030709@isc.org> I took both the comments plus some clarifications I wanted to add and put them in the document. I hear what you are saying about the well thought out API for other tools and I put in some discussion of it. I also know that there is nothing in the current plan for this at all, so creating this will be something that first needs to be sold and then needs to be scheduled. So I soft peddled it at the end rather than giving it the place it is due. Sorry. jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: BIND 10 command tool concepts.doc Type: application/msword Size: 55296 bytes Desc: not available URL: From scharf at isc.org Wed Aug 25 22:22:45 2010 From: scharf at isc.org (Jerry Scharf) Date: Wed, 25 Aug 2010 15:22:45 -0700 Subject: [Bind10-uides] Positive first feedback form the program manager Message-ID: <4C7597B5.6010703@isc.org> Hi all, Shane got the second version of the document. He was sold on the separate data model for the management tool. He liked the idea of templates as well. He have me a bunch more things to fit in somewhere: DHCP: There is a rewrite on the books looking for funding and the tool should manage both TFTP: DHCP admins consider TFTP to be part of DHCP. Think of power on for a set top box. He agreed with the need for admin side APIs. localization and internationalized domain names: need to understand what needs to be specified for a command line tool. Do we really need to support right to left type??? There are config items that don't fit directly with protocol actions and aren't discussed. An example might be a max cache size on a recursive server or how the logging is supposed to work. will need a bunch more work on this to come up with how this fits into the data absrtaction. He brought up the idea of runtime checks. I would call this design constraint checking. he wanted it to work on the config before the changes are applied (sounds like transactions to me.) There is some later support for clustering. For now I just want to make sure that the data model has the info in it, then people can apply money to move delivery dates. External data referencing: Shane wants us to make sure we are clear about the limits of this. He is worried that people may assume we are solving their problems (who doesn't want someone else to automagically solve their data problems.) Controlling external components: If a nameserver stops being an anycast destination, how can this control the OSPF server to pull the /32 advertisement. I cautioned that most people won't want us changing their external configs. My gut reaction is that we should come up with some way to notify external things and punt the rest. This is a map of several years of work, to say the least. thanks for the help getting this far, jerry From scharf at isc.org Fri Aug 27 17:09:38 2010 From: scharf at isc.org (Jerry Scharf) Date: Fri, 27 Aug 2010 10:09:38 -0700 Subject: [Bind10-uides] Fwd: Re: [bind10-dev] How to organize zone config items in bind10? Message-ID: <4C77F152.1080506@isc.org> Hi, First, I want to introduce Paul Ebersman to the kibitz team. Paul is a meek person with no history of causing problems (not!) Paul is the only person I know to have almost tested the UUNet rule: "if you kill someone, you have to do their job and yours." I think it is fair guess that Paul has more ISP ops time than the rest of us combined, much of it causing trouble. Thus he is a perfect candidate to the kibitz team. He also works for ISC doing remote support and consulting to ISC support customers, so he can give us some different perspectives. Paul, besides Brett the list has Marc Evans and Ben April. I met them on the "base" project for Trend. Marc is at a startup doing reputation service and has a long history with open source (led the XFree86 team for many years.) Ben was the ops tool geek at Globalnet at one point and is doing threat research for Trend. This is an email I posted to the BIND 10 developer's list. This is their first introduction to the idea of different management data abstractions in a practical application. Any thoughts from the kibitzers? thanks, jerry -------- Original Message -------- Subject: Re: [bind10-dev] How to organize zone config items in bind10? Date: Fri, 27 Aug 2010 08:56:48 -0700 From: Jerry Scharf To: bind10-dev at lists.isc.org Shane, In my thinking, the modules should carry the configuration data that they need and that it is the idea of the front end to take something like a BIND 9 config file or other abstract form and chop it up as the modules need it. There are three areas of thinking that lead me to this opinion: Though it may sound strange, I consider BIND 9 config files (and rndc) to be the 'user interface' of BIND 9. I see different people wanting different user interfaces to BIND 10. One is to run with the BIND 9 interface. A second is to use someone's existing management tool like infoblox. A third way is to use what we are considering for the BIND 10 command tool. Each of these has a different model for the data and metadata (config elements are the obvious form of metadata.) This leads one to the question "do we put all these different models in the server configuration, pick one or don't put any of these in the server configuration itself?" Being a lazy designer, I naturally lean toward not putting any of them in the server itself. I think this becomes more clear when I think through what extensibility requires. As others begin to replace and add modules to the server, they are going to create new configuration needs. They may also choose to reconfigure the configuration elements that the BIND 10 team allocate in our modules. Trying to keep all this straight within the server itself seems sure to cause problems. The new module designers may not even support their modules with the BIND 9 user interface, you use their management interface with servers running their modules. Finally, it comes from my view that the server is designed to run at network speeds using efficient local data. Management tools are designed to run at human speeds using human concepts. The BIND 9 user interface is a compromise of the two and can cause problems for each side. If we concentrate the problem of translating upper level models to the exact requirements of the modules in the management layer, new modules are much more able to create and refactor configuration elements to their need. In Likun's case, I see the 'also notify' section for zone X should being stored in the xfrout module section and in a form that xfrout wants it. This does put more burden on the command tool, BIND 9 emulator and the like, but I believe it is the best route. A new module requires the associated management functions for its "care and feeding." It also requires documentation of the configuration needs of a given module at a level that someone can read the documentation and successfully translate their management data model into correct control of the server module. Good design on these configuration structures will make many friends. :) Do others agree with this? Are there better ideas out there? warmly, jerry On 08/27/2010 05:59 AM, Shane Kerr wrote: > Likun, > > On Tue, 2010-08-03 at 21:10 +0800, ZhangLikun wrote: > >> There are several config items for one zone, master_addr, also_notify, >> allow_update, etc. Since the items are used by different modules, so it >> makes sense to distribute these config items to different modules, like: >> >> Xfrin has config item: master_addr >> Xfrout has config item: also_notify >> Update has config item: allow_update >> >> And bind10 also need one "zone_list" config item, to make clear which zones >> bind10 is servicing, my suggestion is let config manager module hold the >> config item 'zone_list'. >> >> My question is : does it need to let config manager hold all the config >> option for one zone? So that the duplicated zone list information can be >> avoided in xfrin, xfrout and other modules. Like, config manager will have >> the config data like: >> Zones : [ >> { 'cn' : [ { ' master': [master_list] }, >> { 'also_notify' : [notify_slave_list] }, >> { 'allow_update' : [address_list] }, >> .... some_other_options.... >> ] >> >> 'com' : [ ...zone's_options.... ] >> 'net' : [ ...zone's_options.... ] >> } >> >> Any suggestion? >> > Hopefully I did not miss a discussion about this. :-P > > In any case, avoiding duplication makes sense to me. I think it is okay > for modules to use configuration for "other" modules, as long as this is > done in a controlled way. > > -- > Shane > > _______________________________________________ > bind10-dev mailing list > bind10-dev at lists.isc.org > https://lists.isc.org/mailman/listinfo/bind10-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebersman at isc.org Fri Aug 27 18:03:07 2010 From: ebersman at isc.org (Paul Ebersman) Date: Fri, 27 Aug 2010 11:03:07 -0700 Subject: [Bind10-uides] [bind10-dev] How to organize zone config items in bind10? In-Reply-To: <4C77F152.1080506@isc.org> References: <4C77F152.1080506@isc.org> Message-ID: <20100827180308.05BEBEB2028@scatha.remote.dragon.net> scharf> First, I want to introduce Paul Ebersman to the kibitz scharf> team. Paul is a meek person with no history of causing problems scharf> (not!) Me? Mostly harmless. Says so on my business card. Reading through the latest version of the doc now. My agenda is more with usability/supportability for large customers, like large corp/enterprise and large service provider. They're the ones that have the need and resources to actually program something to use an API/CLI. One of my other interests is monitoring, both for alarming and for longer term stats and trend analysis.