Thilanka, idnsAdmin is intended to be used by the DNS infrastructure administration staff to do everyday management work. The iDNS.cgi interface can be used as well for that, however, the idnsAdmin interface provides a better end-user experience. On the other hand, the idnsOrg interface is to provide the customers of a large DNS infrastructure (a DNS company that sells its services for example.) The idnsOrg interface thus, only provides the ability to modify a zone SOA record (You can't create nor delete zones) and you can only do so with the zones owned by the company the logged user belongs to.
As regards BIND configuration, unxsBind uses a special configuration file and its own directory (/usr/local/idns) where all the zone files et alli are kept. If you need help on setting up your DNS infrastructure please feel free to contact our commercial support department at supportgrp @ unixservice.com Best Regards, Hugo Urquiza Thilanka Samarasekera wrote: > Thank you very much for the prompt response. Where do I read about the > differences between idnsAdmin and idnsOrg interfaces. I am interested > in knowing what situations one interface is more preferable than the > other. If we decide on using Unxsbind to manage our DNS servers, all > zones and DNS servers belong to one company. Another question I have > is can you upgrade the host BIND version to be the same as the DNS > servers Unxsbind will be managing? I am referring to where Unxsbind is > installed as the host BIND install. If yes, is there anything special > that needs to be done? Can Unxsbind manage chrooted BIND > implementations by default or do you need to make special configurations? > > I appreciate your time. > > On Wed, Mar 17, 2010 at 2:27 PM, PM Support Staff > <[email protected] <mailto:[email protected]>> wrote: > > Thilanka, > > Under the interfaces/ directory if you download the source tree you'll > find the interfaces source code. > If you install the software using the rpm they will be automatically > installed at the /var/www/unxs/cgi-bin directory, thus you can access > them with: > > https://yourip:9333/cgi-bin/idnsAdmin.cgi > https://yourip:9333/cgi-bin/idnsOrg.cgi > > As regards vdnsOrg.cgi... it's an advanced replacement for idnsOrg > (but > includes multiple views support.) It's not included in the default rpm > install yet. > > Best regards, > Hugo > > Thilanka Samarasekera wrote: > > It is meant as a technical schema based db manager with a mix of > > production, alpha and beta functionality to be used by > developers (and > > maybe in some cases by the DNS root admin in extraordinary > > circumstances) to create their own web 2.0 interfaces. We provide > > several examples: idnsAdmin, idnsOrg and vdnsOrg. > > > > > > I need a little more information on what you said above. So if I > > understand you correctly there are fronends available for Unxsbind > > like idnsAdmin, idnsOrg and vdnsOrg. Is so where can find them? > Pardon > > my ignorance. > > > > On Sun, Mar 14, 2010 at 9:04 AM, Unixservice Support > > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > Thilanka Samarasekera wrote: > > > Thank you for the prompt response. > > > > > > Is there some place I can read about how to incorporate > several > > BIND 9 > > > server to be managed one unxsbind? I understand your naming > > scheme but > > > when a user logs into the control panel I don't think they > > should see > > > the "tZone", "tBlock", "tView", "tClient" and "tJob" on the > > first page. > > > If this is so then I understand, but I think something is not > > right with > > > my install. A screenshot would be the best way I can show > what I am > > > talking about. I do not want to waste your valuable time. > > > > > > > > > > Thilanka, > > > > Thank you for your questions that will help us all stay on > course and > > prod us to improve. Improve what is becoming a widely used DNS > > management environment for enterprises/organizations that > wish to > > delegate zone modification to either internal or external > > customers. Or > > to provide true DNS SaaS for many organizations (via > unxsBind multiple > > NS sets and our organization/contact/role model.) > > > > --- > > First, regarding your comments about schema object naming in a > > "control > > panel": You are probably referring to the backend interface > iDNS. > > > > IMPORTANT: This backend is not meant as a user friendly > interface. > > > > It is meant as a technical schema based db manager with a mix of > > production, alpha and beta functionality to be used by > developers (and > > maybe in some cases by the DNS root admin in extraordinary > > circumstances) to create their own web 2.0 interfaces. We > provide > > several examples: idnsAdmin, idnsOrg and vdnsOrg. > > > > --- > > Second, there are many different ways to setup a cluster of NSs > > managed > > by one unxsBind system. And of course unxsBind was designed > from the > > start to not only manage one set of NSs but even multiple > disjoint NS > > sets. E.g. unxsBind controls N NS sets on M servers. For now > only > > one NS > > can coexist on one "server." (With the popularity of virtual > servers > > this issue is not as important as it was and the solution > has been > > "slow" tracked.) > > > > For complex multi view DNS data we prefer to use all MASTER NSs > > (avoiding the complex master to slave zone xfer multiple VIP > setup > > that > > is required by BIND.) For standard single external view systems, > > MASTER-SLAVE managed by unxsBind works just fine. > > > > The other major issues to take into consideration are the db > > distribution method (for failover and painless multi server > > backup) and > > the local server connection to the backend db. This can be > done with a > > db multi-master replication scheme where the local unxsBind > job queue > > processor connects via a local socket (good for small > clusters.) Or a > > standard star topology where the NSs connect to a remote > backend -if > > through uncontrolled WANs then usually via an ssh tunnel to > avoid > > MySQL > > SSL issues and overhead. > > > > (In the future we will separate read and write db query code > to better > > use replication clusters with only a single write server and > many read > > servers.) > > > > --- > > Hope these short comments can be used as a starting point for > > clarifying > > some issues. And that will use as a source for expanding > wiki pages at > > > > http://openisp.net/openisp/unxsVZ/wiki/InstallingBindYum > (has some > > setup > > info for small clusters.) > > > > http://openisp.net/openisp/unxsVZ/wiki/GettingStartedBind > (should be > > expanded. Any volunteers?) > > > > Right now we are trying to quickly finish the last 1.x > rpm/yum release > > (with NAPTR, AAAA RR support and LDAP > orgainzation/contact/role model > > integration) before we start releasing the new 2.x series > with major > > extensions (but backwards compatible) for automated DNSSEC > support. > > > > Best Regards, > > Gary Wallis. > > _______________________________________________ > > unxsBind mailing list > > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > https://lists.openisp.net/mailman/listinfo/unxsbind > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > unxsBind mailing list > > [email protected] <mailto:[email protected]> > > https://lists.openisp.net/mailman/listinfo/unxsbind > > > > _______________________________________________ > unxsBind mailing list > [email protected] <mailto:[email protected]> > https://lists.openisp.net/mailman/listinfo/unxsbind > > > ------------------------------------------------------------------------ > > _______________________________________________ > unxsBind mailing list > [email protected] > https://lists.openisp.net/mailman/listinfo/unxsbind > _______________________________________________ unxsBind mailing list [email protected] https://lists.openisp.net/mailman/listinfo/unxsbind
