Hi folks,
As a breather from the "thread-now-wider-than-my-headers-window-in-thunderbird" conversation re: mixing repos, I have a question regarding a machine I'm about to put online. :)
I run a web hosting company and my secondary (primary to the world) DNS box died from a massive rootkit/hack last night. It was running an old Slackware 9.1 installation and I will be completely cleaning those drives sector-by-sector. After which I'll be installing CentOS 5 on that hardware.
As it will be a production server and this is my first foray into CentOS/SELinux in a production environment I was hoping to get a recommended list of what to include and, more specifically, what *not* to include from the distro CDs
I will be doing a text based install, hoping to avoid the installation of X. Other than BIND and vsftpd, I don't think I need much. This machine will be pulling zone files from my primary web server and storing some archive files and backups for me.
I'm dilligently R`ingTFMs, and will continue to.... I'd sure be appreciative of any jumpstart help and/or any pitfalls of which to be cognizant.
TIA, ~Ray
As it will be a production server and this is my first foray into CentOS/SELinux in a production environment I was hoping to get a recommended list of what to include and, more specifically, what *not* to include from the distro CDs
I will be doing a text based install, hoping to avoid the installation of X. Other than BIND and vsftpd, I don't think I need much. This machine will be pulling zone files from my primary web server and storing some archive files and backups for me.
Custom install and remove every package that you can except for bind, openssh-server, vsftpd and whatever you use for archiving and backups should do the trick.
Feizhou wrote:
As it will be a production server and this is my first foray into CentOS/SELinux in a production environment I was hoping to get a recommended list of what to include and, more specifically, what *not* to include from the distro CDs
I will be doing a text based install, hoping to avoid the installation of X. Other than BIND and vsftpd, I don't think I need much. This machine will be pulling zone files from my primary web server and storing some archive files and backups for me.
Custom install and remove every package that you can except for bind, openssh-server, vsftpd and whatever you use for archiving and backups should do the trick. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thank you Feizhou. I'm hoping it's exactly that easy.
Regards, ~Ray
Ray Leventhal wrote:
Feizhou wrote:
As it will be a production server and this is my first foray into CentOS/SELinux in a production environment I was hoping to get a recommended list of what to include and, more specifically, what *not* to include from the distro CDs
I will be doing a text based install, hoping to avoid the installation of X. Other than BIND and vsftpd, I don't think I need much. This machine will be pulling zone files from my primary web server and storing some archive files and backups for me.
Custom install and remove every package that you can except for bind, openssh-server, vsftpd and whatever you use for archiving and backups should do the trick. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thank you Feizhou. I'm hoping it's exactly that easy.
The installer will not let you remove packages that are in the 'Base' group. If you remove any package that bind, vsftpd or openssh-server needs, it will tell you later and ask you whether you want to ignore or install all dependencies and so you should safely get a working system.
On 8/2/07, Ray Leventhal centos@swhi.net wrote:
I'm dilligently R`ingTFMs, and will continue to.... I'd sure be appreciative of any jumpstart help and/or any pitfalls of which to be cognizant.
2 recent pitfalls for bind on RHEL5. 1st being that upstream has removed the default configs for bind. This was apparently intentional. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234508 for more information
also, the last bind update modified some file permissions such that ldap doesn't start correctly afterwards, so if you're running bind and ldap on the same box, beware.
Jim Perrin wrote:
2 recent pitfalls for bind on RHEL5. 1st being that upstream has removed the default configs for bind. This was apparently intentional. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234508 for more information
also, the last bind update modified some file permissions such that ldap doesn't start correctly afterwards, so if you're running bind and ldap on the same box, beware.
Thank you, Jim. I've got the bugzilla link onscreen now and am reading. Also, thanks for the ldap and bind warning. Good to know, but happily, it's not part of my schema.
Again, my thanks, ~Ray
Ray Leventhal wrote:
As a breather from the "thread-now-wider-than-my-headers-window-in-thunderbird" conversation re: mixing repos, I have a question regarding a machine I'm about to put online. :)
I run a web hosting company and my secondary (primary to the world) DNS box died from a massive rootkit/hack last night. It was running an old Slackware 9.1 installation and I will be completely cleaning those drives sector-by-sector. After which I'll be installing CentOS 5 on that hardware.
CentOS 5 is a .0 release, you might be better served using CentOS 4.5 which has had much more tme to prove itself as a DNS Server. 4.5 also has a good bit of time left on updates to (till Feb 29th, 2012) so you shouldn't worry to much about it becoming obsolete.
As it will be a production server and this is my first foray into CentOS/SELinux in a production environment I was hoping to get a recommended list of what to include and, more specifically, what *not* to include from the distro CDs
As others have said, start with a bare minimal install and add as you need to. Unless you do a custom kickstart, you'll certainly want to go through and remove some of the packages that are in the default install but aren't really necessary for a single task server (e.g. bluez-utils, NetworkManager, etc).
I will be doing a text based install, hoping to avoid the installation of X. Other than BIND and vsftpd, I don't think I need much.
Why do you need vsftpd? Plain text FTP could prove very dangerous. Maybe you should take this chance to switch over to something more secure like SFTP. The nice thing about sftp is it's up and running straight out of the box since SSH is enabled by default.
This machine will be pulling zone files from my primary web server and storing some archive files and backups for me.
I'm dilligently R`ingTFMs, and will continue to.... I'd sure be appreciative of any jumpstart help and/or any pitfalls of which to be cognizant.
Good luck,
Jay
On 8/2/07, Jay Lee jlee@pbu.edu wrote: [...]
CentOS 5 is a .0 release, you might be better served using CentOS 4.5 which has had much more tme to prove itself as a DNS Server.
[...]
Jay
Please don't propagate this idea. That is very "Windows wait for service pack 1" way of thinking. Linuxes actually go through extensive pre-release public beta testing, the kind of stuff Microsoft does on its .0 releases. When a new CentOS release lands, it has landed.
Brian Mathis wrote:
On 8/2/07, Jay Lee jlee@pbu.edu wrote: [...]
CentOS 5 is a .0 release, you might be better served using CentOS 4.5 which has had much more tme to prove itself as a DNS Server.
[...]
Jay
Please don't propagate this idea. That is very "Windows wait for service pack 1" way of thinking.
Actually it is an 'old' Red Hat way of thinking from the pre-fedora era and was very much true for RH versions up though 7.x.
Linuxes actually go through extensive pre-release public beta testing, the kind of stuff Microsoft does on its .0 releases.
I'd say "Enterprise Linux distributions" there. It's not true for all or even most Linux distributions.
When a new CentOS release lands, it has landed.
Yes, Centos qualifies as an enterprise version. Plus something like DNS will be fixed immediately if any problems are noticed - long before an x.1 update.
Hi Jay, et al,
<snip> CentOS 5 is a .0 release, you might be better served using CentOS 4.5 which has had much more tme to prove itself as a DNS Server. 4.5 also has a good bit of time left on updates to (till Feb 29th, 2012) so you shouldn't worry to much about it becoming obsolete.
My experience in both reading this list and working with other sysadmins is that even though CentOS 5 is a .0 release, it is not only robust, but a rock solid release. I've been running CentOS5 on my desktop at home for more than a few months without issue, so I'm comfortable with 5.0 in a production environment. Good point made, though.
Why do you need vsftpd? Plain text FTP could prove very dangerous. Maybe you should take this chance to switch over to something more secure like SFTP. The nice thing about sftp is it's up and running straight out of the box since SSH is enabled by default.
That is certainly something to consider. Myself and one other will be the only folks using this machine for storage that will require ftp access so your point is taken. SFTP is my likely choice after a bit of reading to ensure compatibility with our tasks.
Good luck,
Jay
Thanks...your help is greatly appreciated!
~Ray
On 8/2/07, Ray Leventhal centos@swhi.net wrote:
That is certainly something to consider. Myself and one other will be the only folks using this machine for storage that will require ftp access so your point is taken. SFTP is my likely choice after a bit of reading to ensure compatibility with our tasks.
While it's also a prime example of not getting the help you asked for, instead of ftp, or in some cases sftp, you might look at webdav also depending on your needs.
I use it because it doesn't require a local system account, can be permissioned via apache, and is very customizable.It helps us out locally because it's part of http 1.1, so there's no need for added firewall ports being open, no proxy adjustments, etc.
Jim Perrin wrote:
On 8/2/07, Ray Leventhal centos@swhi.net wrote:
That is certainly something to consider. Myself and one other will be the only folks using this machine for storage that will require ftp access so your point is taken. SFTP is my likely choice after a bit of reading to ensure compatibility with our tasks.
While it's also a prime example of not getting the help you asked for, instead of ftp, or in some cases sftp, you might look at webdav also depending on your needs.
I use it because it doesn't require a local system account, can be permissioned via apache, and is very customizable.It helps us out locally because it's part of http 1.1, so there's no need for added firewall ports being open, no proxy adjustments, etc.
My favorite way to move files is with rsync over ssh since it does the right thing about not replacing existing files until the copy is complete, is more efficient sometimes, and works with windows/cygwin too. Windows users sometimes prefer winscp, though.
But back to DNS - I run a really old and ugly script after updating zone files that builds the reverse zones, commits the changes to a cvs repository, and restarts named to pick up the changes. Is there some modern equivalent for this operation?
On Thu, Aug 02, 2007 at 01:20:04PM -0500, Les Mikesell wrote:
But back to DNS - I run a really old and ugly script after updating zone files that builds the reverse zones, commits the changes to a cvs repository, and restarts named to pick up the changes. Is there some modern equivalent for this operation?
i use a script called "mkrdns" that isn't especially ugly. it's out on the net, and its website mentions something called dnscvsutil that also apparently does CVS and incorporates mkrdns.
it doesn't have v6/AAAA support though, so if you find something that does i'd appreciate hearing about it.
tnx danno -- Dan Pritts, System Administrator Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224
Internet2 Workshops: More fun than summer school http://www.internet2.edu/workshops
On Thursday 02 August 2007 16:56:46 Ray Leventhal wrote:
As it will be a production server and this is my first foray into CentOS/SELinux in a production environment I was hoping to get a recommended list of what to include and, more specifically, what *not* to include from the distro CDs
I will be doing a text based install, hoping to avoid the installation of X. Other than BIND and vsftpd, I don't think I need much. This machine will be pulling zone files from my primary web server and storing some archive files and backups for me.
I'm dilligently R`ingTFMs, and will continue to.... I'd sure be appreciative of any jumpstart help and/or any pitfalls of which to be cognizant.
Apart from installation, I would suggest using PowerDNS as a secondary DNS. It's not only robust, fast and secure, but also has very interesting capability of automated zones depolying (espacially usefull for secondary NS). I'm using it on all my secondary nameservers, and that's saving me lot of time.
Regards,
Tomasz Napierała wrote: <snip>
Apart from installation, I would suggest using PowerDNS as a secondary DNS. It's not only robust, fast and secure, but also has very interesting capability of automated zones depolying (espacially usefull for secondary NS). I'm using it on all my secondary nameservers, and that's saving me lot of time.
Regards,
Thank you Tomasz, I'll have a look at PowerDNS. Much appreciated.
~Ray
Ray Leventhal wrote:
Tomasz Napierała wrote:
<snip> > Apart from installation, I would suggest using PowerDNS as a secondary DNS. > It's not only robust, fast and secure, but also has very interesting > capability of automated zones depolying (espacially usefull for secondary > NS). I'm using it on all my secondary nameservers, and that's saving me lot > of time. > > Regards, > Thank you Tomasz, I'll have a look at PowerDNS. Much appreciated.
Well, if you are willing to look into BIND alternatives, please take a look also at tinydns which is part of the djbdns package.
Dead simple format for dns configuration and on-the-fly zone updating are some of its features.
Feizhou wrote:
Ray Leventhal wrote:
Tomasz Napierała wrote:
<snip> > Apart from installation, I would suggest using PowerDNS as a > secondary DNS. It's not only robust, fast and secure, but also has > very interesting capability of automated zones depolying (espacially > usefull for secondary NS). I'm using it on all my secondary > nameservers, and that's saving me lot of time. > > Regards, > Thank you Tomasz, I'll have a look at PowerDNS. Much appreciated.
Well, if you are willing to look into BIND alternatives, please take a look also at tinydns which is part of the djbdns package.
Dead simple format for dns configuration and on-the-fly zone updating are some of its features. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Feizhou,
I'm more than willing to look into alternatives, especially when recommended by those more knowledgeable than I (which is *most* of this list, I might add)
So, thank you *very* much for that. The machine is slated to go live this weekend so i've clearly got some reading and evaluating to do (on my testbed machine, of course).
Thanks again...and again, ~Ray
Well, if you are willing to look into BIND alternatives, please take a look also at tinydns which is part of the djbdns package.
Dead simple format for dns configuration and on-the-fly zone updating are some of its features. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Feizhou,
I'm more than willing to look into alternatives, especially when recommended by those more knowledgeable than I (which is *most* of this list, I might add)
So, thank you *very* much for that. The machine is slated to go live this weekend so i've clearly got some reading and evaluating to do (on my testbed machine, of course).
Thanks again...and again, ~Ray
I'm coming in late to this thread. We too are a hosting provider (small time), hosting approximately 1600 live domains.
Not to say tinydns is a bad alternative, as it has it's strengths, but we moved away from [outgrew] it 2 years ago.
If you were already running Bind, CentOS 5 is a great platform. I run a few multi-domain (3-10) slaves using a chrooted Bind for a couple offsite clients. Fine for small number of domains. Short term, I'd recommend just getting another Bind install up and running to fix your issue, THEN look at alternatives.
I've personally used PowerDNS, TinyDNS, MyDNS, nsd, Bind 8/9, and MS DNS. PowerDNS is phenomenal. Look into the proprietary "supermaster/superslave" functionality. To manage the 1600+ domains, we have our primary server setup using a MySQL backend. This allows simple integration of our accounting and support systems. The slaves are using sqlite3 backends. One word of caution, while a "superslave" may automatically add a new domain, it will not remove domains deleted at the master. I've solved this by removing all non NS/SOA records from that domain and updating the serial on the master - so changes propagate to slaves. Then have a cronjob running that purges empty domains from the databases on the master and slaves.
Also, I've found the PowerDNS RPM's located at the EPEL repo to be completely stable. They even have the backends broken out separately.
Lastly, I don't know about you, but I hate giving shell access where it's not needed ... especially to support staff under a Tier3 level. So I use Pure-FTPD running virtual users and an FTPS (not SFTP) client like lftp or filezilla for transfers. If I need a higher level of security then I use rsync over SSH.
Forgive me for being so verbose. :-)
-ken
<snip>
I'm coming in late to this thread. We too are a hosting provider (small time), hosting approximately 1600 live domains.
Not to say tinydns is a bad alternative, as it has it's strengths, but we moved away from [outgrew] it 2 years ago.
If you were already running Bind, CentOS 5 is a great platform. I run a few multi-domain (3-10) slaves using a chrooted Bind for a couple offsite clients. Fine for small number of domains. Short term, I'd recommend just getting another Bind install up and running to fix your issue, THEN look at alternatives.
I've personally used PowerDNS, TinyDNS, MyDNS, nsd, Bind 8/9, and MS DNS. PowerDNS is phenomenal. Look into the proprietary "supermaster/superslave" functionality. To manage the 1600+ domains, we have our primary server setup using a MySQL backend. This allows simple integration of our accounting and support systems. The slaves are using sqlite3 backends. One word of caution, while a "superslave" may automatically add a new domain, it will not remove domains deleted at the master. I've solved this by removing all non NS/SOA records from that domain and updating the serial on the master - so changes propagate to slaves. Then have a cronjob running that purges empty domains from the databases on the master and slaves.
Also, I've found the PowerDNS RPM's located at the EPEL repo to be completely stable. They even have the backends broken out separately.
Lastly, I don't know about you, but I hate giving shell access where it's not needed ... especially to support staff under a Tier3 level. So I use Pure-FTPD running virtual users and an FTPS (not SFTP) client like lftp or filezilla for transfers. If I need a higher level of security then I use rsync over SSH.
Forgive me for being so verbose. :-)
-ken
Overly Verbose? Not at all, Ken. I am thrilled to hear of your experiences and was, actually, intending to do a straight BIND install first as it's what I'm most familiar with at this time.
I certainly have a lot of material to review before making the leap away from BIND proper, but that I now know what that material is, at least in part, is a blessing.
Please be verbose as you'd like. I, for one, truly appreciate it.
Thanks again, ~Ray
I'm coming in late to this thread. We too are a hosting provider (small time), hosting approximately 1600 live domains.
Not to say tinydns is a bad alternative, as it has it's strengths, but we moved away from [outgrew] it 2 years ago.
I used to work for a messaging service provider and they had two systems. The first system was the service provider offering its messaging platform for its own domains and a hundred or so domains for quite a lot of clients and these were managed with BIND by hand.
The other system was used for solely one client and that client is a rather big Registrar, whom I shall not name, with thousands of domains of which a good portion (over 50k) were hosted by this messaging service provider since the registrar did not have its own messaging platform. All these domains were automatically managed with tinydns.
So I do not know how you 'outgrew' tinydns. After all the only part that involves tinydns is 'generate the cdb file from a database for tinydns to chew' or in other words, generating the cdb file for tinydns is the least of your problems to tackle.
The secondaries are handled just the same (actually, you do not need 'secondaries' anymore...if IIRC, you just have to rsync the cdb file over so there is no real master/slave thing here)
I'm coming in late to this thread. We too are a hosting provider (small time), hosting approximately 1600 live domains.
Not to say tinydns is a bad alternative, as it has it's strengths, but we moved away from [outgrew] it 2 years ago.
I used to work for a messaging service provider and they had two systems. The first system was the service provider offering its messaging platform for its own domains and a hundred or so domains for quite a lot of clients and these were managed with BIND by hand.
eek. i can imagine that was a pain.
So I do not know how you 'outgrew' tinydns. After all the only part that involves tinydns is 'generate the cdb file from a database for tinydns to chew' or in other words, generating the cdb file for tinydns is the least of your problems to tackle.
Look, in no way was i bashing TinyDNS or starting a flamewar. This is why i prefaced my comment with "Not to say tinydns is a bad alternative, as it has it's strengths". By "outgrew" i mean we required more of our DNS server. We weren't a top level domain provider. Our clients required authoritative and sometimes secondary service. As a result, we required better RFC compliance and a broader range of features then TinyDNS provided. That's all. Our business simply required greater flexibility.
Generally, your business needs should determine the solution. Not the other way around.
Cheers.
Ken Price wrote:
I'm coming in late to this thread. We too are a hosting provider (small time), hosting approximately 1600 live domains.
Not to say tinydns is a bad alternative, as it has it's strengths, but we moved away from [outgrew] it 2 years ago.
I used to work for a messaging service provider and they had two systems. The first system was the service provider offering its messaging platform for its own domains and a hundred or so domains for quite a lot of clients and these were managed with BIND by hand.
eek. i can imagine that was a pain.
In the beginning it sure was.
Good thing BIND has this $INCLUDE thing. That reduced the amount of work after I cleaned up the mess from the previous configuration maintainer.
So I do not know how you 'outgrew' tinydns. After all the only part that involves tinydns is 'generate the cdb file from a database for tinydns to chew' or in other words, generating the cdb file for tinydns is the least of your problems to tackle.
Look, in no way was i bashing TinyDNS or starting a flamewar. This is why i prefaced my comment with "Not to say tinydns is a bad alternative, as it has it's strengths". By "outgrew" i mean we required more of our DNS server. We weren't a top level domain provider. Our clients required authoritative and sometimes secondary service. As a result, we required better RFC compliance and a broader range of features then TinyDNS provided. That's all. Our business simply required greater flexibility.
You should have come out with this in the first place. Stating 1600 domains as a hosting provider and then not clearly stating the technical reasons on why you had to switch away from tinydns looks like a veiled snipe at djbdns.
If anybody dares insinuate ease of use, performance or security reasons for not using djbdns, I am going to grill them because 'I' have tried to find something to replace dnscache, which has this knack of not caching CNAME records and hammering the authoritative servers of a zone when it receives multiple new requests for records in that zone before it gets an answer, and I have yet to find anything that is as scalable as dnscache despite its annoying shortcomings.
Generally, your business needs should determine the solution. Not the other way around.
Agreed.
On Friday 03 August 2007 15:46:49 Ken Price wrote:
I've personally used PowerDNS, TinyDNS, MyDNS, nsd, Bind 8/9, and MS DNS. PowerDNS is phenomenal. Look into the proprietary "supermaster/superslave" functionality. To manage the 1600+ domains, we have our primary server setup using a MySQL backend. This allows simple integration of our accounting and support systems. The slaves are using sqlite3 backends. One word of caution, while a "superslave" may automatically add a new domain, it will not remove domains deleted at the master. I've solved this by removing all non NS/SOA records from that domain and updating the serial on the master - so changes propagate to slaves. Then have a cronjob running that purges empty domains from the databases on the master and slaves.
Just to add one comment, PowerDNS is also easy migration path from BIND as it can use existing BIND configuration files as a backend in addition to MySQL (or other dbms)
Regards,
-
Brian Mathis -
Dan Pritts -
Feizhou -
Jay Lee -
Jim Perrin -
Ken Price -
Les Mikesell -
Ray Leventhal -
Tomasz Napierała