First system-config-network is not part of CentOS/RHEL 6, now I don't see system-config-bind either. Is there an alternative (GUI) way to manage the bind DNS server?
Emmett
On Tue, Jul 12, 2011 at 8:28 PM, Emmett Culley emmett@webengineer.com wrote:
First system-config-network is not part of CentOS/RHEL 6, now I don't see system-config-bind either. Is there an alternative (GUI) way to manage the bind DNS server?
It looks like there is no GUI way.
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Migration_...
(watch for line wrapping)
"The system-config-bind tool has been deprecated and removed without replacement. Editing the name server configuration manually via the named.conf file is recommended in Red Hat Enterprise Linux 6."
On Tue, 2011-07-12 at 21:44 -0400, William Hooper wrote:
"The system-config-bind tool has been deprecated and removed without replacement. Editing the name server configuration manually via the named.conf file is recommended in Red Hat Enterprise Linux 6."
Red Hat can hardly "recommend" it, meaning there is a choice, when there is absolutely no other alternative.
On 07/12/2011 06:44 PM, William Hooper wrote:
On Tue, Jul 12, 2011 at 8:28 PM, Emmett Culleyemmett@webengineer.com wrote:
First system-config-network is not part of CentOS/RHEL 6, now I don't see system-config-bind either. Is there an alternative (GUI) way to manage the bind DNS server?
It looks like there is no GUI way.
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Migration_...
(watch for line wrapping)
"The system-config-bind tool has been deprecated and removed without replacement. Editing the name server configuration manually via the named.conf file is recommended in Red Hat Enterprise Linux 6."
I don't get this. Both system-config-network and system-config-bind are in Fedora 15. I can sort of get why they would deprecate system-config-network in favor of NetworkManager (barely), but how are we to manage the DNS server? It is NOT trivial to create and manage DNS records with a text editor. For me Webmin is a little too bloated to install, just to manage bind. Is it time to for me (or the community) to create these useful tools?
Emmett
On Tue, 2011-07-12 at 20:19 -0700, Emmett Culley wrote:
On 07/12/2011 06:44 PM, William Hooper wrote:
On Tue, Jul 12, 2011 at 8:28 PM, Emmett Culleyemmett@webengineer.com wrote:
First system-config-network is not part of CentOS/RHEL 6, now I don't see system-config-bind either. Is there an alternative (GUI) way to manage the bind DNS server?
It looks like there is no GUI way.
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Migration_...
(watch for line wrapping)
"The system-config-bind tool has been deprecated and removed without replacement. Editing the name server configuration manually via the named.conf file is recommended in Red Hat Enterprise Linux 6."
I don't get this. Both system-config-network and system-config-bind are in Fedora 15. I can sort of get why they would deprecate system-config-network in favor of NetworkManager (barely), but how are we to manage the DNS server? It is NOT trivial to create and manage DNS records with a text editor. For me Webmin is a little too bloated to install, just to manage bind. Is it time to for me (or the community) to create these useful tools?
---- personally, I use Webmin to manage DNS, DHCP & LDAP Users & Groups
Yes, it is bloated considering I really only use 3 modules but it handles them well and it's easy enough to install.
I suppose you could download the SRPM of system-config-bind from CentOS-5 and rebuild it and make yourself happy which sounds a whole lot easier than re-inventing the wheel but knock yourself out.
Craig
On 7/12/11 10:46 PM, John R Pierce wrote:
On 07/12/11 8:19 PM, Emmett Culley wrote:
It is NOT trivial to create and manage DNS records with a text editor.
yes it is.
It is easy enough to build the forward zones (except for verifying that your MX and CNAME entries don't reference other CNAMES), but painful to do the reverse ones. Is there a simple packaged script to do a sanity/syntax check and make the reverse zone files for you?
On 07/12/11 9:50 PM, Les Mikesell wrote:
It is easy enough to build the forward zones (except for verifying that your MX and CNAME entries don't reference other CNAMES), but painful to do the reverse ones. Is there a simple packaged script to do a sanity/syntax check and make the reverse zone files for you?
the ones I've seen have been woefully inadequate. many of my domains stretch across multiple IP providers, not all of whom I have RDNS on anyways.
re: cname's, I'm of the opinion that you shouldn't use CNAME within your own domain(s), and only use them if you can't possibly use anything else... About the ONLY place I use them is things like aiming a host at something like google where you HAVE to use a CNAME.
On 7/13/11 12:07 AM, John R Pierce wrote:
On 07/12/11 9:50 PM, Les Mikesell wrote:
It is easy enough to build the forward zones (except for verifying that your MX and CNAME entries don't reference other CNAMES), but painful to do the reverse ones. Is there a simple packaged script to do a sanity/syntax check and make the reverse zone files for you?
the ones I've seen have been woefully inadequate. many of my domains stretch across multiple IP providers, not all of whom I have RDNS on anyways.
You can still get control delegated to you although it is somewhat ugly if the range doesn't hit class C boundaries.
re: cname's, I'm of the opinion that you shouldn't use CNAME within your own domain(s), and only use them if you can't possibly use anything else... About the ONLY place I use them is things like aiming a host at something like google where you HAVE to use a CNAME.
We disagree then. I think you should rarely give out anything but CNAMEs tied to services unless you only run one service per address because otherwise you can't split them apart later. It just becomes messy when your zones are managed by different people and the targets of CNAMEs later are converted to CNAMEs themselves. You aren't supposed to do that, but it is common enough that everything follows them anyway.
On 07/12/11 10:42 PM, Les Mikesell wrote:
We disagree then. I think you should rarely give out anything but CNAMEs tied to services unless you only run one service per address because otherwise you can't split them apart later. It just becomes messy when your zones are managed by different people and the targets of CNAMEs later are converted to CNAMEs themselves. You aren't supposed to do that, but it is common enough that everything follows them anyway.
I use multiple A records pointing to the same IP for that, I'll only use a CNAME to a host if I can't control that hosts IP address and/or won't be notified if its changed.
It is easy enough to build the forward zones (except for verifying that your MX and CNAME entries don't reference other CNAMES), but painful to do the reverse ones. Is there a simple packaged script to do a sanity/syntax check and make the reverse zone files for you?
I haven't yet come across anything I couldn't do with h2n and make. But then my setups are relatively simple.
On 7/13/11 4:42 AM, Lars Hecking wrote:
It is easy enough to build the forward zones (except for verifying that your MX and CNAME entries don't reference other CNAMES), but painful to do the reverse ones. Is there a simple packaged script to do a sanity/syntax check and make the reverse zone files for you?
I haven't yet come across anything I couldn't do with h2n and make. But then my setups are relatively simple.
To be reasonable it should at least have a way to tell it what ranges you need reverse zones for and not choke if you have multiple A records for the same name.
On 07/12/2011 08:46 PM, John R Pierce wrote:
On 07/12/11 8:19 PM, Emmett Culley wrote:
It is NOT trivial to create and manage DNS records with a text editor.
yes it is.
No, it isn't. At least it isn't trivial for those of us that only occasionally need to modify their DNS server(s). I had a few gripes about system-config-bind, but on the whole it did make it easy for me to manage our DNS servers without having to study the docs each time I needed to make a change.
Now I suppose my only choice is to install webmin, or compile system-config-bind from source.
I cannot understand the reasoning behind dropping system-config-bind from CentOS/RHEL 6. Then leaving it in Fedora. Since when is less tools better? Especially since there doesn't seem to be a reasonable replacement for this useful tool.
Emmett
On Wed, 13 Jul 2011, Emmett Culley wrote:
No, it isn't. At least it isn't trivial for those of us that only occasionally need to modify their DNS server(s). I had a few gripes about system-config-bind, but on the whole it did make it easy for me to manage our DNS servers without having to study the docs each time I needed to make a change.
I promised I would not get drawn into this thread, but ...
This thread and its description of the experience gap is telling ... One camp wants a 'black box' tool that does _something_, so they can ignore what is happening 'under the covers' and move on to more interesting uses of the computer. And then there are the professionals. And this _is_ billed as a boring, trailing edge and stable, enterprise operating system, after all
But my use cases are related to a prodduction environment, maintaining several hundred zone files, with lots of adds, changes, and deletes. The s-c-bind GUI tool was useless, compared to TUI edits (certain legacy systems) and scripts to do the backups, accuracy audit, and creation of all files including the PTR record files
But our TUI system was really was not up to the new TXT record formats for anti-spam purposes, SRV records, and AAAA and ipv6 PTR generation, so we redesigned and have moved to a local database backed, webbish tool
The latter still DISPLAYs zone files, so I can check its work (and indeed 'bind' dumps backups that look like zone files), but all transactions are done 'across the wire incrementally' through encrypted, keyed DNS tranactions, line by line, and NOT by shipping zone files around. There is also a webbish GUI permitting downloading a local format CSV representation of the zone files, that 'gnumeric' and Google spreadsheet read just fine
But this GUI tool is also tightly coupled to local workflow, and not really something we would release the web LAMP sources for, because we ** want ** to be free to break the API as needed for business purposes
Now I suppose my only choice is to install webmin, or compile system-config-bind from source.
or, just maybe, study a zone file and read about it and grow in skills. Also, there exist on-line tools to construct well-formed zone files, and google has umpteen gazillion articles of varying quality and accuracy, I suppose. The two you list are your 'only' choice, only if you are into drama
I cannot understand the reasoning behind dropping system-config-bind from CentOS/RHEL 6. Then leaving it in Fedora. Since when is less tools better? Especially since there doesn't seem to be a reasonable replacement for this useful tool.
I am not unbiased in this matter, as I asy, I've been building zone files for a long time, first using a locally hacked up and extended version of 'h2n', and other tools from the ORA Cricket book
By comparison, the s-c- GUI DNS tool formerly offered reminded me of a lame little puppy -- better than nothing, but just barely. Lots of the 'glade' based 'tools' which the upstream has rolled out seem, to me, to be present to satisfy a PHB's requirement for a GUI tool on a checklist, for a given service. They could not be called 'best of breed' by a neutral observer, by any reach of the imagination
-- Russ herrold
On 7/13/2011 1:03 PM, R P Herrold wrote:
I promised I would not get drawn into this thread, but ...
This thread and its description of the experience gap is telling ... One camp wants a 'black box' tool that does _something_, so they can ignore what is happening 'under the covers' and move on to more interesting uses of the computer. And then there are the professionals. And this _is_ billed as a boring, trailing edge and stable, enterprise operating system, after all
But my use cases are related to a prodduction environment, maintaining several hundred zone files, with lots of adds, changes, and deletes. The s-c-bind GUI tool was useless, compared to TUI edits (certain legacy systems) and scripts to do the backups, accuracy audit, and creation of all files including the PTR record files
So, aren't computer programs supposed to be able to deal with complicated cases, or just not free computer programs? Or is the input syntax just too weird? While s-c-bind may not have been the right answer, it just seems odd as a missing piece in the distribution and epel-provided packages. Almost as odd as not having a network-aware authentication mechanism working as a server out of the box on your initial install - as though it would be unusual to have more than one computer and want those initial users to be able to log into the others you'd add later.
On 7/13/2011 2:36 PM, Les Mikesell wrote:
On 7/13/2011 1:03 PM, R P Herrold wrote:
I promised I would not get drawn into this thread, but ...
This thread and its description of the experience gap is telling ... One camp wants a 'black box' tool that does _something_, so they can ignore what is happening 'under the covers' and move on to more interesting uses of the computer. And then there are the professionals. And this _is_ billed as a boring, trailing edge and stable, enterprise operating system, after all
But my use cases are related to a prodduction environment, maintaining several hundred zone files, with lots of adds, changes, and deletes. The s-c-bind GUI tool was useless, compared to TUI edits (certain legacy systems) and scripts to do the backups, accuracy audit, and creation of all files including the PTR record files
So, aren't computer programs supposed to be able to deal with complicated cases, or just not free computer programs? Or is the input syntax just too weird? While s-c-bind may not have been the right answer, it just seems odd as a missing piece in the distribution and epel-provided packages. Almost as odd as not having a network-aware authentication mechanism working as a server out of the box on your initial install - as though it would be unusual to have more than one computer and want those initial users to be able to log into the others you'd add later.
I would have to guess that UpStream decided it was not to be. They most likely had very good reasons for this. I 'barely' looked at it as it could not do what I need to do and that was some years back. Is/Was it capable of doing IPV6? That would be a good reason to put it to bed... given IPV6 will likely become widespread during the lifespan of CentOS 6. Various SPF/SenderID/DomainKeys things also ride on bind these days. It could be that UpStream decided that was a good reason to put it to bed? Either way, CentOS is a nearly exact clone of UpStream, so really you need to go complain at UpStream, not on this list. CentOS has exactly matched their goal of providing the same packages available under UpStream. There is no point to complaining here.
On 7/13/2011 1:50 PM, John Hinton wrote:
But my use cases are related to a prodduction environment, maintaining several hundred zone files, with lots of adds, changes, and deletes. The s-c-bind GUI tool was useless, compared to TUI edits (certain legacy systems) and scripts to do the backups, accuracy audit, and creation of all files including the PTR record files
So, aren't computer programs supposed to be able to deal with complicated cases, or just not free computer programs? Or is the input syntax just too weird? While s-c-bind may not have been the right answer, it just seems odd as a missing piece in the distribution and epel-provided packages. Almost as odd as not having a network-aware authentication mechanism working as a server out of the box on your initial install - as though it would be unusual to have more than one computer and want those initial users to be able to log into the others you'd add later.
I would have to guess that UpStream decided it was not to be. They most likely had very good reasons for this. I 'barely' looked at it as it could not do what I need to do and that was some years back. Is/Was it capable of doing IPV6? That would be a good reason to put it to bed... given IPV6 will likely become widespread during the lifespan of CentOS 6. Various SPF/SenderID/DomainKeys things also ride on bind these days. It could be that UpStream decided that was a good reason to put it to bed? Either way, CentOS is a nearly exact clone of UpStream, so really you need to go complain at UpStream, not on this list. CentOS has exactly matched their goal of providing the same packages available under UpStream. There is no point to complaining here.
It's not so much a complaint and certainly not directed at CentOS, as pointing out a curious situation that pretty much everyone has to work around. Russ may be of the opinion that everyone should memorize bazillion-page books of details about each quirky service or hire someone who did, but I think the point of using computers should be to make things easier. And I'm surprised that there isn't a common tool to make it easy at least in the usual 3rd party repos.
On 07/13/2011 12:15 PM, Les Mikesell wrote:
On 7/13/2011 1:50 PM, John Hinton wrote:
But my use cases are related to a prodduction environment, maintaining several hundred zone files, with lots of adds, changes, and deletes. The s-c-bind GUI tool was useless, compared to TUI edits (certain legacy systems) and scripts to do the backups, accuracy audit, and creation of all files including the PTR record files
So, aren't computer programs supposed to be able to deal with complicated cases, or just not free computer programs? Or is the input syntax just too weird? While s-c-bind may not have been the right answer, it just seems odd as a missing piece in the distribution and epel-provided packages. Almost as odd as not having a network-aware authentication mechanism working as a server out of the box on your initial install - as though it would be unusual to have more than one computer and want those initial users to be able to log into the others you'd add later.
I would have to guess that UpStream decided it was not to be. They most likely had very good reasons for this. I 'barely' looked at it as it could not do what I need to do and that was some years back. Is/Was it capable of doing IPV6? That would be a good reason to put it to bed... given IPV6 will likely become widespread during the lifespan of CentOS 6. Various SPF/SenderID/DomainKeys things also ride on bind these days. It could be that UpStream decided that was a good reason to put it to bed? Either way, CentOS is a nearly exact clone of UpStream, so really you need to go complain at UpStream, not on this list. CentOS has exactly matched their goal of providing the same packages available under UpStream. There is no point to complaining here.
It's not so much a complaint and certainly not directed at CentOS, as pointing out a curious situation that pretty much everyone has to work around. Russ may be of the opinion that everyone should memorize bazillion-page books of details about each quirky service or hire someone who did, but I think the point of using computers should be to make things easier. And I'm surprised that there isn't a common tool to make it easy at least in the usual 3rd party repos.
Yes, certainly NOT a complaint with CentOS. system-config-bind was a very useful too for us. It wasn't perfect and there were a few features it could have benefited from, but it did a good enough job for we needed it to do.
I had been thinking recently that we needed to start looking for a different way to manage the DNS servers on our gateways, and had even begun to build initial bind configuration for production systems into the configuration scripts. I guess I am unhappy because someone else made the decision about when to stop using system-config-bind for me :-) And for no good reason that I can figure.
On Wed, 13 Jul 2011, Les Mikesell wrote:
around. Russ may be of the opinion that everyone should memorize bazillion-page books of details about each quirky service or hire
dunno that those are my words at all
The issue was DNS zone files
One takes a template, and in the residential user case, edits perhaps 5 lines, consisting of A and CNAME records for a residential network for the 'forward' zonefiles ... or uses 'h2n' that takes as its input a file that looks like /etc/hosts
s-c-bind may have met the need or it may not have, but it was not worth learning to me, after a brief examination, because it provided no gain over incumbent tools to me to make it worth going down its learning curve. The s-c-kickstart-config (or whatever it was named) tool is in that same boat
The one off domain case is just not that hard
The commercial case with hundred of complex entries is not the same scale problem, and to hope for a common tool need not be a dream -- but, the overhead of setting up a scalable keyed DNS management tool, is not worth the effort cost to a residential user and I suspect not worth the support load it would cost the upstream on what is an essentially bespoke solution
-- Russ herrold
On 7/12/2011 9:19 PM, Emmett Culley wrote:
how are we to manage the DNS server? It is NOT trivial to create and manage DNS records with a text editor.
If editing BIND zone files is too complex for you or it's just overly complex for your situation, I recommend switching to dnsmasq. It combines DNS and DHCP in a single easy-to-configure daemon. Instead of zone files, it uses /etc/hosts.
In addition to being simpler to configure than either BIND or ISC dhcpd, the fact that it combines DNS and DHCP in the same server means "ping mylaptop" does what you expect. That is to say, there's an automatic DNS association created when a client gets a DHCP lease, based on the name the client uses to identify itself.
You can configure ISC dhcpd to make it tell BIND the name-to-IP mapping for each lease it hands out, but you don't get that for free:
http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
It's a fine article, but compared to "it works out of the box", it's really no contest, for the humble small office or home user.
Sorry a bit late into this thread - bit I thought I would offer up a cheap and cheerful java GUI we've been use for managing the ISC BIND nameserver files on Centos - Its called DnsBindEditor Much easier than managing the named.conf and zone files by hand
- Dave
On Tue, 2011-07-12 at 17:28 -0700, Emmett Culley wrote:
First system-config-network is not part of CentOS/RHEL 6, now I don't see system-config-bind either. Is there an alternative (GUI) way to manage the bind DNS server?
you can easily set it up to not only maintain your forward zones but it will update the reverse zones at the same time.
Craig
On Tuesday, July 12, 2011 08:28:46 PM Emmett Culley wrote:
First system-config-network is not part of CentOS/RHEL 6, now I don't see system-config-bind either. Is there an alternative (GUI) way to manage the bind DNS server?
Culled from the SL list: See: http://scientificlinuxforum.org/index.php?showtopic=153
This shows how to use the package 'fedpkg' found in EPEL to rebuild from source RPM a Fedora or EPEL package. You might then be able to rebuild the Fedora system-config-bind for yourself. But you'll be responsible for all updates, etc, etc. IOW, Caveat Redivivor (pardon my pidgin Latin....).
-
Always Learning -
Craig White -
Dave Carey -
Emmett Culley -
John Hinton -
John R Pierce -
Lamar Owen -
Lars Hecking -
Les Mikesell -
R P Herrold -
Warren Young -
William Hooper