Re: Centos / Redhat announcement
- Original Message - From: Connie Sieh cs...@fnal.gov To: scientific-linux-users@fnal.gov; scientific-linux-de...@fnal.gov Cc: Sent: Wednesday, 8 January 2014, 19:53 Subject: Centos / Redhat announcement We are in the process of researching/evaluating this news and how it impacts Scientific Linux. CentOS Scientific Edition has a nice ring to it. -Connie Sieh
Re: Centos / Redhat announcement
On 9/01/2014 10:26 PM, Ian Murray wrote: - Original Message - From: Connie Sieh cs...@fnal.gov To: scientific-linux-users@fnal.gov; scientific-linux-de...@fnal.gov Cc: Sent: Wednesday, 8 January 2014, 19:53 Subject: Centos / Redhat announcement We are in the process of researching/evaluating this news and how it impacts Scientific Linux. CentOS Scientific Edition has a nice ring to it. Why sully the good name of Scientific Linux? :P -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 signature.asc Description: OpenPGP digital signature
Re: Centos / Redhat announcement
My US$0.02, it seems like maybe RedHat wants something in between the stable, solid, reliable, and, yes, sometimes dated Enterprise Linux and the wild crazy :) world of Fedora. From where I sit, we want that stable, solid, reliable, and, yes, sometimes dated Enterprise Linux (well, we don't really want dated, but for us it's a small price to pay for the other attributes). We use genuine RHEL where we require formal support and a clone where we don't. With that in mind, CentOS is not as compelling for us, and we have no plans to change away from SL. - Bluejay Adametz Don't cry because it's over; smile because it happened. -- NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
Re: Centos / Redhat announcement
On 01/09/2014 02:37 PM, Bluejay Adametz wrote: My US$0.02, it seems like maybe RedHat wants something in between the stable, solid, reliable, and, yes, sometimes dated Enterprise Linux and the wild crazy :) world of Fedora. As far i understood nothing will change with regard of data path for distribution of CentOS (it will be the same process of taking _released_ srpms, clean up, rebuild). RH just extend an administrative umbrella (and some significant support) over the CentOS organization. Anyway, as rebuilding and re-branding is quite intensive i was wondering if the differences between centos and sl could be packed in some repo (as most (that i know of) of the cern scientific software is already put into). What technical differences would be between CentOS + scientific repo and SL? Just a personal thought, but maybe this would free some human resources for maintaining a lot of scientific (and IT/grid related) packages in well established repos (like epel, fedora/rpmfusion) Thanks! Adrian smime.p7s Description: S/MIME Cryptographic Signature
Re: Centos / Redhat announcement
2014/1/9 Adrian Sevcenco adrian.sevce...@cern.ch [...] As far i understood nothing will change with regard of data path for distribution of CentOS (it will be the same process of taking _released_ srpms, clean up, rebuild). RH just extend an administrative umbrella (and some significant support) over the CentOS organization. [...] If I understand correctly, the CentOS team members joined Redhat as employees, so I guess this is the first step to something like RHEL community edition. Would be fine if still available for free and might be also good for SL because it will make the rebuild work obsolete so the SL team can focus on the respin work as well as the extensions to the stock RHEL. Regards Thomas
Re: Centos vs. SL
On 01/09/2014 05:54 AM, Adrian Sevcenco wrote:. What technical differences would be between CentOS + scientific repo and SL? Just a personal thought, but maybe this would free some human resources for maintaining a lot of scientific (and IT/grid related) packages in well established repos (like epel, fedora/rpmfusion) Thanks! Adrian Well, for me the main difference between CentOS and SL is that with SL you can stay on EL point releases. That would require a major change in the CentOS infrastructure to support it. Worth exploring though... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: Centos / Redhat announcement
On Wed, 8 Jan 2014, Connie Sieh wrote: We are in the process of researching/evaluating this news and how it impacts Scientific Linux. -Connie Sieh We were invited by Redhat/Centos to a conference call yesterday to discuss the Centos / Redhat project. We discussed details about this project and its impact on Scientific Linux. We are continuing our research. -Connie Sieh
Re: Centos / Redhat announcement
On 09/01/14 21:12, William R. Somsky wrote: One thing people should keep in mind while discussing this is the why the original Fermilab distro (and Cern distro) which then became Scientific Linux was created, and why Fermilab continues to actively commit resources to SL. Remember Fermilab (and Cern) are particle accelerator facilities with million/billion dollar experiments that *must* have long-term guarantees of stable and supported software. To make Scientific Linux a variant of Centos would be to introduce an unknown/uncontrollable element as a controlling factor in the mix. What if Centos pulled an Ubuntu and decided to start introducing controversial changes in an attempt to become more user friendly or to win the desktop? A merging w/ Centos would need to carefully consider such issues. I don't come from a scientific background, just more of a piggy-backer on what seems to be a well governed and reliably supported operating system. An O/S with some big names behind it, such as they ones you mentioned above. I was a longterm CentOS user until it became clear that there was surprising little opaqueness around the governance and processes of the project and it seemed overly reliant on one or two individuals. Despite it being having a huge userbase, I came to the conclusion that this was largely a vanity project for those individuals. Now, the Red Hat news has completely changed that situation. So for me, CentOS is now viable again. To answer your concern, directly:- To make Scientific Linux a variant of Centos would be to introduce an unknown/uncontrollable element as a controlling factor in the mix. Scientific Linux is already based on Red Hat Enterprise Linux, so in that sense you are not introducing any new element, in my opinion. The press release talks about Special Interest Groups and official variants. Now if SL was to become an official variant, then part of the acceptance of the SIG from the Scientific side could be to get confirmation that ongoing support would suit the needs you speak of. Something else worth remember that I seem to recall reading on this list that a discussion had taken place sometime ago about a possible merger between CentOS and SL (or at least a common base). The wording in the list that I recall was that the conclusion was that both projects goals were too different. Obviously, that is wide open to exact interpretation. Those differences may now be reconcilable or even moot. Having said all that, it would be a shame for the (now) only significant independent RHEL rebuild project to lose its independence. On 01/08/14 11:53, Connie Sieh wrote: We are in the process of researching/evaluating this news and how it impacts Scientific Linux. -Connie Sieh
Re: Centos vs. SL
Well correction that was one of the original goals of LTS (Long term support Linux) which was the name of one of the two efforts which were combine to create SL. Since then TUV a.k.a Red Hat has changed their lifecycle policy and made it much longer that it had been prior to RHEL 4I'm sure though if Red Hat decided to go back to a two or three year life cycle then SL's policy would change back to providing security patches over a longer period of time.-- Sent from my HP Pre3On Jan 9, 2014 18:39, Ian Murray murra...@yahoo.co.uk wrote: On 09/01/14 23:13, Paul Robert Marino wrote: SL is an exact match to RHEL with only a few variations such as the removed the client for Red Hats support site integration and added a few things like AFS because their labs need it. The differences are well documented in the release notes and its a short list. In addition SL guarantees long term patch availability even if Red Hat is no longer supporting that release. This wasn't my understanding. According to this page https://www.scientificlinux.org/distributions ... " * We plan on following the TUV Life Cycle. Provided TUV continues to make the source rpms publicly available." ... which disagrees with your statement. At least the way I read it. CentOS tends to do thing like update the PHP libraries to make it easier for web developers. And as a result they take longer for many security patches because they occasionally hit dependency issues due to the packages they have updated. I am pretty sure the base release does not do this kind of thing by default. It would be a major deviation from being "binary compatible" with upstream vendor, which is how I recall their stated goal to be. It may be optional, however. -- Sent from my HP Pre3 On Jan 9, 2014 13:17, Orion Poplawski or...@cora.nwra.com wrote: On 01/09/2014 05:54 AM, Adrian Sevcenco wrote:. What technical differences would be between CentOS + scientific repo and SL? Just a personal thought, but maybe this would free some human resources for maintaining a lot of scientific (and IT/grid related) packages in well established repos (like epel, fedora/rpmfusion) Thanks! Adrian Well, for me the main difference between CentOS and SL is that with SL you can stay on EL point releases. That would require a major change in the CentOS infrastructure to support it. Worth exploring though... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: Centos / Redhat announcement
On 2014/01/09 15:27, Ian Murray wrote:
On 09/01/14 22:53, jdow wrote:
Ian, I suspect the SL staff position is more proper engineering with
it's concern about what could possibly go wrong than it is about
minimizing their work or compromising their main sponsor's needs. I
suspect that the SL staff position is also tempered with a healthy
dose of, What do our customers want and need?
I didn't suggest otherwise. However, I could have sworn I read somewhere
that Red Hat would stop release their source as SRPMs (which would have
a direct impact on the build process of SL I assume), but I can't find
that now. Maybe I mis-read that. I'll keep looking.
This is an excellent source of information.
http://wordshack.wordpress.com/2014/01/07/centos-welcome/
It contains many links including the link to the faq:
http://community.redhat.com/centos-faq/
The faq is a very good source of information. It's best to go to these
good sources rather than listen to FUD spread around the net. I saw
noting to indicate SRPMs were no longer going to be distributed. That
would be of questionable legality as a matter of fact given GPL
requirements.
The main SL customers are their sponsers, Fermilab and Cern. They do
not need the latest and greatest. They need stable support for what
we already have for as long as practical.
I thought core CentOS would still track Red Hat in releases and support
lengths. If I have that wrong, then that does throw a spanner in the works.
The impression I received is that Centos policies would not change. But
read the faq, don't trust me. I looked at and tried Centos many years ago
and decided what I got was a somewhat slower and outdated you gotta
update frequently like regular Red Hat (now Fedora) situation with very
unstable leadership. It was going through one if its, We're gonna die!
phases. I looked elsewhere. I hit on SL by accident and liked their
policies. I've not been disappointed. For, perhaps, different reasons I
want what SL's sponsors want. And I don't see SL's sponsors dropping it
any time soon. I'll probably die first.
All the other SL customers, such as you and I, don't matter a hill of
beans against the billion dollar investments of their sponsors. I am
sitting back and watching. I certainly respect their work, appreciate
their work, and admittedly sponge off their work. So I'd not dream of
trying to tell them what to do.
I wouldn't dream of telling them what to do either. All I am doing here
is chewing the cud, as it were.
FWIW, I don't feel link I sponge... I merely drink from the same open
source cup that SL and Red Hat does. I have a few lines of code accepted
in the Xen project; does that mean all Xen users (4.3+) are sponging off
me? I don't think so.
I'm taking care of a good situation. I make my income writing for pay
software. So while it's legal I do feel like a sponge rather than
someone who contributes enough to pay for my use. I don't have time.
(And time seems to be getting shorter every day as I get older. Too
many decade years, I suppose.)
{^_^}
I do note that for the machine on which I use SL it is precisely the
sort of thing I want, too.
{^_^} Joanne Dow
On 2014/01/09 14:30, Ian Murray wrote:
On 09/01/14 21:12, William R. Somsky wrote:
One thing people should keep in mind while discussing this is the why
the original Fermilab distro (and Cern distro) which then became
Scientific Linux was created, and why Fermilab continues to actively
commit resources to SL. Remember Fermilab (and Cern) are particle
accelerator facilities with million/billion dollar experiments that
*must* have long-term guarantees of stable and supported software.
To make Scientific Linux a variant of Centos would be to introduce an
unknown/uncontrollable element as a controlling factor in the mix.
What if Centos pulled an Ubuntu and decided to start introducing
controversial changes in an attempt to become more user friendly or
to win the desktop?
A merging w/ Centos would need to carefully consider such issues.
I don't come from a scientific background, just more of a piggy-backer
on what seems to be a well governed and reliably supported operating
system. An O/S with some big names behind it, such as they ones you
mentioned above. I was a longterm CentOS user until it became clear that
there was surprising little opaqueness around the governance and
processes of the project and it seemed overly reliant on one or two
individuals. Despite it being having a huge userbase, I came to the
conclusion that this was largely a vanity project for those individuals.
Now, the Red Hat news has completely changed that situation. So for me,
CentOS is now viable again.
To answer your concern, directly:-
To make Scientific Linux a variant of Centos would be to introduce an
unknown/uncontrollable element as a controlling factor in the mix.
Scientific Linux is already based on Red Hat Enterprise Linux, so in
that sense you are not introducing any new element, in my opinion. The
Re: Centos / Redhat announcement
On 2014/01/09 16:00, Ian Murray wrote:
On 09/01/14 23:27, Ian Murray wrote:
On 09/01/14 22:53, jdow wrote:
Ian, I suspect the SL staff position is more proper engineering with
it's concern about what could possibly go wrong than it is about
minimizing their work or compromising their main sponsor's needs. I
suspect that the SL staff position is also tempered with a healthy
dose of, What do our customers want and need?
I didn't suggest otherwise. However, I could have sworn I read somewhere
that Red Hat would stop release their source as SRPMs (which would have
a direct impact on the build process of SL I assume), but I can't find
that now. Maybe I mis-read that. I'll keep looking.
Right, I have found it:
http://community.redhat.com/centos-faq/
Will this new relationship change the way CentOS obtains Red Hat
Enterprise Linux source code?
Yes. Going forward, the source code repository at git.centos.org will replace
and obsolete the Red Hat Enterprise Linux source rpms on ftp.redhat.com. Git
provides an attractive alternative to ftp because it saves time, reduces human
error, and makes it easier for CentOS users to collaborate on and build their
own distributions, including those of SIGs.
So, as I read it, SL will need to change whether it likes it or not, unless RHEL
SRPMs will be available through other channels.
I hope what they are doing is putting the RHEL sources into the Centos GIT
repository and Centos then derives from the posted RHEL sources with its
own sources OR that Centos simply becomes the source code distribution for
RHEL.
Don't forget that GPL means you must have the sources available when asked
for. Therefore they have to be available to all chronologically before any
potential Centos massaging might take place on those sources.
Pulling changes from git may be easier than pulling down the entire batch
of SRPMs, too. It may well simplify the SL process.
{^_^}
Re: DNS Servers
On 10/01/2014 11:16 AM, Jeremy Wellner wrote: I've been using BIND on RHEL5 for years and it's come time to overhaul those venerable DNS boxes. I've seen alot of alternatives like NSD, PowerDNS, YADIFA, and others but I'm wondering what experience has been with going to something other than BIND. Having a database backend is very attractive, but so is having a manageable GUI for those in the department that work with adding devices and are scared of text files and the black of terminal. Use bind. DNS is all about reliability - not pretty or GUIs... -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 signature.asc Description: OpenPGP digital signature
Re: DNS Servers
Bind works well period!That said one of my favorite DNS appliances uses PowerDNS under the hood and it works very well too if you configure it correctly.The others I really can't speak to because I've never used them.It really comes down to this you need to balance your budget as compared to man hours. I tend to use appliances for my core DNS servers where ever possible because there are a lot of really good ones and I have support staff time limitations, but I also use Bind 9 slave servers to handle most of the actual query traffic because it reduces my support and equipment costs. That said if you are more concerned about the initial upfront cost and support cost than man hours Bind is the safest bet because its the standard that all the others are based on.-- Sent from my HP Pre3On Jan 9, 2014 19:28, Steven Haigh net...@crc.id.au wrote: On 10/01/2014 11:16 AM, Jeremy Wellner wrote: I've been using BIND on RHEL5 for years and it's come time to overhaul those venerable DNS boxes. I've seen alot of alternatives like NSD, PowerDNS, YADIFA, and others but I'm wondering what experience has been with going to something other than BIND. Having a database backend is very attractive, but so is having a manageable GUI for those in the department that work with adding devices and are scared of text files and the black of terminal. Use bind. DNS is all about reliability - not pretty or GUIs... -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299
Re: Centos / Redhat announcement
On 10/01/14 00:16, jdow wrote:
On 2014/01/09 16:00, Ian Murray wrote:
On 09/01/14 23:27, Ian Murray wrote:
On 09/01/14 22:53, jdow wrote:
Ian, I suspect the SL staff position is more proper engineering with
it's concern about what could possibly go wrong than it is about
minimizing their work or compromising their main sponsor's needs. I
suspect that the SL staff position is also tempered with a healthy
dose of, What do our customers want and need?
I didn't suggest otherwise. However, I could have sworn I read
somewhere
that Red Hat would stop release their source as SRPMs (which would have
a direct impact on the build process of SL I assume), but I can't find
that now. Maybe I mis-read that. I'll keep looking.
Right, I have found it:
http://community.redhat.com/centos-faq/
Will this new relationship change the way CentOS obtains Red Hat
Enterprise Linux source code?
Yes. Going forward, the source code repository at git.centos.org will
replace
and obsolete the Red Hat Enterprise Linux source rpms on
ftp.redhat.com. Git
provides an attractive alternative to ftp because it saves time,
reduces human
error, and makes it easier for CentOS users to collaborate on and
build their
own distributions, including those of SIGs.
So, as I read it, SL will need to change whether it likes it or not,
unless RHEL
SRPMs will be available through other channels.
I hope what they are doing is putting the RHEL sources into the Centos
GIT
repository and Centos then derives from the posted RHEL sources with its
own sources OR that Centos simply becomes the source code distribution
for
RHEL.
Don't forget that GPL means you must have the sources available when
asked
for. Therefore they have to be available to all chronologically before
any
potential Centos massaging might take place on those sources.
I have been struggling with this myself tbh. If RH adds a line in a GPL
program that says Welcome to Red Hat, releases the binary as RHEL and
then modifies it for CentOS to read Welcome to CentOS and only
releases the source that says Welcome to CentOS, then they are in
technical violation of the GPL, I would say. (IANAL).
Pulling changes from git may be easier than pulling down the entire batch
of SRPMs, too. It may well simplify the SL process.
Of course, but it's still a change to SL's build, which was my point. (I
think :) )
Let's not forget the motivation here (IMHO): To stuff Oracle right up.
So I suspect it's going to be either harder or impossible to rebuild
RHEL without going via CentOS. This is why it might be batter to embrace
the CentOS official variant option. I don't know how this will pan out
I ought to mention, btw, if you happen to work for Oracle, please feel
free to feel as spongy as you like. :p
{^_^}
Re: DNS Servers
I in theory would like webmin for this in a fast and dirty development environment, but it still has too many infosec problems for my taste for production.In the past when I had the time and work driven focus to harden webmin with only custom module which all used sudo for an appliance I was able to reconcile my issues, but in production as is it stock webmin is risky. Many if these concerns could be handles by selinux now but the webmin developers are still behind the ball on writing the appropriate rules or even requiring module writer to include the prerequisite rules so I still wouldn't consider it in production. -- Sent from my HP Pre3On Jan 9, 2014 19:50, Nico Kadel-Garcia nka...@gmail.com wrote: BIND for the server, "webmin" for the configuration tool. and my presentation at SVNday a few years ago if you wnat notes on how to put it under source control. Don't forget "mkrdns" for generating your reverse DNS reliably: the RPM building tools are at https://github.com/nkadel/repoforge-rpms-nkadel-dev/tree/master/specs/mkrdns/ On Thu, Jan 9, 2014 at 7:26 PM, Steven Haigh net...@crc.id.au wrote: On 10/01/2014 11:16 AM, Jeremy Wellner wrote: I've been using BIND on RHEL5 for years and it's come time to overhaul those venerable DNS boxes. I've seen alot of alternatives like NSD, PowerDNS, YADIFA, and others but I'm wondering what experience has been with going to something other than BIND. Having a database backend is very attractive, but so is having a manageable GUI for those in the department that work with adding devices and are scared of text files and the black of terminal. Use bind. DNS is all about reliability - not pretty or GUIs... -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299
Re: Centos / Redhat announcement
Absolutely right. Red Hat is only obliged to provide source code to those who they have shared the software with, nor are they required to package the software and thief patches in an easy to compile format like source RPM packages.Now there is absolutely nothing that prevents some one who pays for Red Hat 'support' from re-sharing it but Redhat has always gone above and beyond the requirements of the GPL. But their is also nothing in the gpl that requires them to make it easy which they do.There are plenty of companies I've worked for that license software the write as GPL but don't share it with any one else but their subsidiaries and based on their employment contracts the employees who use the software as part of their job are not technically covered under the shared with clause of the GPL so its highly unlikely you will se any of them on a public web server ever.The GPL is far more subtle in legal terms than most programmers it users really understand.That said...As I've said before can we please stop this speculation train its giving me a migraine and I want to get off lol.-- Sent from my HP Pre3On Jan 9, 2014 20:46, zxq9 z...@zxq9.com wrote: On Friday 10 January 2014 01:14:02 Ian Murray wrote: On 10/01/14 00:16, jdow wrote: Don't forget that GPL means you must have the sources available when asked for. And this obligation only applies to Red Hat's customers, not to us. I have been struggling with this myself tbh. If RH adds a line in a GPL program that says "Welcome to Red Hat", releases the binary as RHEL and then modifies it for CentOS to read "Welcome to CentOS" and only releases the source that says "Welcome to CentOS", then they are in technical violation of the GPL, I would say. (IANAL). No, if you received the CentOS binaries you are only entitled to receive the sources to those binaries (not the Red Hat ones). GPL does not mandate that sources get released publicly, only to parties to whom a program has been directly distributed. Folks who are not Red Hat customers have not received programs from Red Hat, we've received the same programs from other places (CentOS, SL, or to be more legally accurate, mirror locations) and it is those other projects/providers who are obliged to make programs available in source form. The fact that the GPL and related licenses also guarantee that any customer can distribute the source (but not a copy of the binary) to anyone they want means its almost impossible to can or gag a successful piece of GPL software. As a business it is better to control that release process than to be blindsided by it, so Red Hat has fully embraced the open source community idea and always provided public access to source -- but they are not obligated to do so.
Re: DNS Servers
Its doable to have bind be your DNS for AD it just takes some work and planing. The primary thing is make sure dynamic DNS works properly.The big catches there are making sure you have the right Service entries and ensuring dynamic DNS works correctly. By the way neither of theism are AD specific requirements they actually stem from the RFCs that describe LDAP 3 and the RFCs which describe TLS and Kerberos V which the LDAP 3 RFC's reference. Essentially AD is Microsoft's implementation of LDAP 3 and since Windows server 2008 its very RFC compliant with some Microsoft windows specific optimizations and automation-- Sent from my HP Pre3On Jan 9, 2014 21:38, Jeremy Wellner jwell...@stanwood.wednet.edu wrote: Thats a resounding stay the course and I dont mind that one bit. Its been rock solid and Ive been happy with it.So as a secondary question, we are planning on adding Active Directory in to our network and I know that it is very particular about its DNS. Will AD be happy with being given a delegate domain to have as its sandbox or does that throw my BIND install out the window? Thank you all for the advise!! :)
Re: DNS Servers
AD does many things, many of them quite badly. If you need an drop-in authentication server, you might consider if y9ou really need AD, or if Samba 4.1.x will do the job. I've got RPM building tools for that at https://github.com/nkadel/samba4repo, and they work well on Scientific Linux 6 with the necessary RPM's built up from scratch. AD is handy for easy integration with Microsoft servers, such as Exchange and SQL, and for providing Windows trained personnel familiar tools. But its DNS is not good. It allows multiple PTR records for the same IP address, configuring DNS views is a nightmare, its export tool is a proprietary format that looks vaguely like valid DNS but isn't, It does not understand that foor.bar.com may hve *nothing to do* in any logical sense with bar.com DNS If you need it for things like the authenticated dynamic DNS for your laptops and wi-fi, and don't want to spend the time building up Samba or similar tools, cool. But keep it the heck away from your server DNS. If you need chroot cages and good source control managed configurations backups consider looking up my presentation at SVNday in Berlin a few years: How to Subvert Masters and Slaves, BIND Them, and Make Them Report Names and Addresses. On Thu, Jan 9, 2014 at 9:37 PM, Jeremy Wellner jwell...@stanwood.wednet.edu wrote: That's a resounding stay the course and I don't mind that one bit. It's been rock solid and I've been happy with it. So as a secondary question, we are planning on adding Active Directory in to our network and I know that it is very particular about it's DNS. Will AD be happy with being given a delegate domain to have as it's sandbox or does that throw my BIND install out the window? Thank you all for the advise!! :)
