Re:i stopped reading after i ran into this...
on
Postfix
·
· Score: 2, Interesting
I can think of several reasons that MacOS might be needed as a server... Largeish publishing house using Quark Express comes to mind... it was only released for OSX, what, 6 months ago? For most corperations of any size, that's moving pretty quick.
Besides, remember that even those you consider to be stupid often have good advice. This is one of those instances. Postfix is wonderful. Simple, secure, fast, powerful, extensible... Weitze did an amazing job writing it. He was the guy who wrote TCPWrappers (back in the days before xinetd put some resonable security into inetd) and the origional network analysis tool Satan, so you know it's written with security in mind.
I've got it pushing 6-8 gigs of email a day in one install using pretty lame hardware (uniproc, 2 SCSI drives at RAID 1). We've loved it, and had some great success with it.
At least with XP. I agree with the previous poster that grabing an Xserver for the desktops is going to be a good thing, but the only other thing you NEED is a good telnet/ssh client. I suggest putty, since it's standalone (no dll's, no supporting files, etc. All it does is update some registry keys with host keys and the like). You can drop it in a temp folder, and just run it.
The other thing is to keep a reasonably up to date knoppix CD lying around. If you can boot off the CDROM drive (and almost no windows shop won't) you've got a reasonable linux client there. If you get creative, you could even start your own version of it with your own private utilities installed and ready to go.
Why on earth do you think you need that much bandwidth? Where is the bandwidth going? Most smallish companies (the ones that balk at $800k) don't need more than a couple T1's.
If you REALLY need that kind of bandwidth, take a long look at co-lo'ing your servers somewhere. You can get the bandwidth relativly cheeply, and house all the high bandwidth stuff at the co-lo. Then you just remotely manage it. Have some way to do send large batches of data to the colo (say large capacity tape drive, or maybe some ATA drive array) and you're done.
I might appreciate your opinion of linux better, if you could set up a BSD box that can withstand a slashdoting...:-)
*BSD's have a different approach to *NIX than most linux'ers. Most of the linux distro's have gone with the SYSV approach as default (as in/etc/(rc.d/)init.d, and ps -ef) rather than the BSD approach (as in/etc/rc.d/rc.local and ps -aux)
It's kinda odd. The BSD's and SYSV's are different superficially (some command line arguments) and at the deep kernel level, but the mid-level abstractions are almost identical (similar syscalls, etc). It's all UNIX though.
I completely agree. There's a huge difference between a degree coming out of your 'technical schools' and a true 'computer science' degree. Most of the jobs that are being outsourced are the ones your curriculum would train someone for. The jobs that are staying are the architecture, the system design, etc.
I believe it was Dijkstra who said something like "Show me the code, and I will not understand. Show me the data structures, and I will." Data structures and interfaces are the heart of programing, and the difference between being a code monkey and a great programer.
Finally, there's a point about aptitude. I am a great sysadmin. I am not a great programer. I understand a lot of what goes into being a great programer, and I know I don't have it. Your curriculum does not allow specializations, and I really think it should.
The heart of all programing does not change. Only languages and methods change. If you can change languages and methods easily, you'll be a much greater programer.
That's a nice theory, but certain things have a hard coded location in mind (like libc.so.0). I tried the LD_LIBRARY_PATH hack, and it didn't solve the problem. Granted, it was late at night, and 6-7 years ago.
I BELIEVE it's the difference between running 'ldd' on a binary, anseeing a name of a library file, and the/path/to/library.
My best singke mistake was after a long night of re-installing an updated version of solaris on a SparcServer 2, I needed to clear out the/tmp dir sor some stupid reason. So, I did the old: "mkdir newdir ; mv * newdir"
I wasn't in/tmp. I was in/.
My next command was 'ls'. It returned: unable to find/usr/lib/libc.so.0
AAAAARGH!
I now know how to solve that under solaris. Under/usr/sbin/static there are 5 statically compiled binaries: cp, ln, mv, rcp, and tar./newdir/usr/sbin/static/mv/newdir/* / would have fixed it.
Ever since then, my prompt has had my current directory in it. That experience certainly made me more careful.
Better (or worse) was when a stupid service rep came in to replace a bad CPU on a sun e10000. The idiot shut down the sub-system, and powered off the board correctly. He then managed to pull out the wrong board, despite the blinken lights. Of course it was the peoplesoft domain. Running year end reporting.
Software is written by humans, and humans make errors, so software has bugs.
All software.
The sysadmin motto (abridged) is 'all software sucks, all hardware sucks'
I just looked through the bugtraq archives, and found 3 local root exploits for OpenBSD in the year 2003. That's the same class of problem as was found in Linux.
Security is a mindset, and a practice. It's not a platform.
As someone who has watched people play both, I think that they are on par. Nethack seems more popular right now. If you're into Angband, making the switch over to nethack shouldn't be that hard. About the only difference is that in nethack, you have to go to the bottom, claim amulet, climb back up, and offer amulet to your god on the astral plane.
The development time in winning characters for each game is about equal too. My roommate just beat nethack (ascended) in about 24 hours of play. That's pretty quick by most nethack standards.
This is a brain dead and stupid idea from the world of fixed cost bandwidth. If you start paying for the megabit over a threshold, you're going to get screwed in a hurry. Even if you don't and your idea works well, you're going to loose most of your bandwidth to this idiocy.
1) Development. Lax rules. Admins willing to either give root to development, or to change it temporarily so devs can get at it. On a wide open network that is hidden behind a firewall or 3. Sand box. Devs can do whatever they want.
2) Testing. As close as humanly possible to production environment, but with somewhat easy rules. No root access (unless completely proven as needed). All changes logged. This is mostly a staging area for changes to production.
3) Production. Iron rule of law. All changes audited, documented, tested, verified.
Though I wish I had developers I trusted with root access, even on a dev environment. I had one idiot dev who got root, and then did a
cd / ; chown -R idiot:staff *
'But I needed to be able to view everything on that box!!!' Thankfully, it was only on his desktop unix box. If I had some developers with the initiative to ask 'hey, I think somethings wrong with how FTP is working. Could you give me a TCPDUMP trace of what's going on?' I think I'd faint from shock.
To be fair, I know (personally) several developers who I completely trust. Unfortunatly, I don't work with any.
If you read the article, it says: "even though it occupies a mere half-rack of space". So, that'd be 21U, or 21x1.75in (36.75in x 19in x ~20in (depending on it's depth).
I'm with a previous poster. I'd love to work as an analyst for Gartner, GIGA, etc. That'd rock.
Short version of how these companies operate:
1) Listen to geeks to figure out what's popular and new 2) push 'new' ideas as the salvation of computing kind 3) write papers, and sell these opinions for insane ammounts of money 4) proffit! 5) Every year or so, get together with your big $$ clients, and have a huge party in some place cool (according to my co-workers, the party Giga threw in Las Vegas was something to behold)
In principle, I agree with you. HW Raid (if you can get/afford it) is the way to go. Dead drive? Yank it, and pop in another. Automatic resync. No down time.
SW Raid however, isn't (always) as bad as you make it out to be, at least under solaris. Their 'disksuite' product has been very reliable here. Every server has it, and we've yet to see any real problems with it. Great for mirroring the OS drives.
Before version 4, disksuite had some teething problems, but the 4.2.1 release rocks.
Meanwhile, some network executives are blaming Nielsen Media Research, the folks who measure viewer ratings, claiming that the firm's methodology is faulty in this new era of digital cable boxes and satellite dishes. Nielsen, of course, disagrees
I was astounded to find out that to be a 'Neilsen reviewer' you had to watch more than 5 hours of TV per day.
ALL OF THEIR STATS ARE BASED OFF OF THESE PEOPLE!
With that in mind, just how realistic do you thing their stats are going to be to begin with, let alone if a large portion of their viewing population is disappearing from them. Would they even notice until the revolution has them up against the wall?
You're trolling, but I'll bite: Will it support Longhorn? Longhorn is the future of computing, man.
Well, the scary thing is that if Linus does pull off the december of '03 promise, and following linux's usual release cycle of '2 years between major versions', we'll be releasing 2.8.0 at about the same time Longhorn ships in 2006.
Lack of control over the medium is what's holding it back. You know those warnings at the end of baseball games? The "This has been a production of Major league Baseball. Unauthorized reproduction is prohibited without the express written consent of the commissioner of baseball" slogan?
They can't control what happens when you get it, there's any number of copies that they can make, and they don't get the revenue stream of commercials.
Big media is all about control, because that's where the money is.
I'd love for the GIMP to catch up to photoshop. I'd love for the GIMP to just catch up enough to use CMYK (iirc) pallets rather than RGB. I'd love for the GIMP to grok enough about the propriatary RAW formats from digital cameras.
The GIMP hasn't had a significan't update in forever. I love it as a tool, but it can't compete with photoshop.
Blind faith in OSS sollutions won't help you. When YOU contribute to the software (documentation, user education (not user flaming), code, test cases, bug reports, etc) OSS gets better, and might be able to start competing.
I think that I agree with several posters. The guy who suggested knoppix has a solid idea, except for the fact that the students will probably need CD access to load various things. Also, you probably don't want the student able to eject the CD and boot off his OWN version of knoppix to keyboard sniff, or whatever.
When it comes to easy of re-install, both have solid paths: jumpstart for solaris and kickstart for linux. 'boot net' from the ok prompt on a solaris box, or have a special floppy that does the same for a linux box, and boom. Re-imaged box. I'll bet you'll end up re-imaging several machines a week, so make it as painless as possible.
See also the poster who mentioned 'authorized users' having an easier time hacking the boxen. There are FAR more hacks available if you already have user privs than if you're outside the box. I also suggest disabling remote access to the boxes from the general network. I can't count the number of times I tried to use a *NIX box for class work, only to find some luser had telneted in and started a high load process for their class work.
Also, remote mount (NFS) as much as you can get away with. This makes a much simpler upgrade path: step 1: update fileserver, step 2: reboot lab (if needed). The downside of NFS is that it's a bit of a security hassle. Also, be aware that NFS on solaris is miles ahead of Linux in ease of use, stability, features, etc. Comes from Sun creating the protocol origionally.
Finally, I think it will be a little easier on the admin's to use Linux for these boxes. Much more up to date, more friendly tools, easier package management, etc. However, if you're NFS mounting lots of stuff (like you should be) then solaris is worth a look too. Their NFS implementation rocks. The downside to solaris on sparc is $$$$$. However, take a long look at solaris on x86... They're very close in code base, you just don't get the spiffy openboot eeprom.
I see both sides of this. I can save a little money (it you actually buy a legal version of windows for dual boot, it eats a lot of the price savings) and build it myself, or I can get a dell.
I tell all my friends to just get a Dell and I personally build my own. This way, I know I get good parts, I know it's not going to fail quickly, and I know that I don't have to offer tech support to my parents.
That, and I can also get one of those sweet Shuttle XPC cases.
No. Not at all. The work around is pretty clever actually. Pretend that you're random IP at company, configured to use your companies DNS server.
If you request your nameserver to look up misspelledgoogle.com, said DNS server, with this patch, will queries the roots, who give an NS record for.com. Verisign's.com NS servers will try to give back an A record due to this wildcard thing.
Your companies DNS server won't accept that A record from.com because.com (and.net) has been declared a 'delegation-only' domain. That means that the.com name servers will only be allowed to return NS records. If they return something else, your companies DNS server will respond to you with an NXDOMAIN error (just like it should for a 'no such domain').
These are all very important questions. The other thing that people forget about is the service agreement.
My company paid too much money for an EMC array. We don't need the performance, and we don't need all the wizbang features.
That doesn't mean it sucks though. EMC calls us within 5 minutes of any hardware issues on the box. It's fault tollerant to a amazing degree. The only time we've taken downtime was when we needed to schedule a major firmware update. The support agreement is amazing. If something dies, they call us and say 'we can be on site with an engineer and the part in 2 hours. When do YOU want us to show up?'
Asside from our database servers, none of the boxes we've put on EMC come close to pushing the throughput limits. We would have been much wiser to utilize NAS for most of the servers. Much cheeper, good reliability, reasonable performance, and they can talk all the major file sharing protocols: SMB, CIFS, NFS, etc, and we could have spent less on the SAN.
A poster above suggested a mix of either building the SATA arrays yourself, or a small vender. I poked on their website, and their support agreement says 'parts next day'. If the driveplane blows out, 'next day' may or may not be good enough. People scream really loudly if email is down.
The other thing is making sure you find someone who can reverse engineer your 'rsync' solution. This is one reason companies tend to prefer out of the box apps for system level stuff. They can send someone to training for it.
I have to agree with the 'no gentoo on servers'. It's a wonderful distro, and I use it a lot, but it encourages you to be too bleeding edge... and that WILL bite you at some point.
(Says I as I'm debugging a firewall issue at 9:00 PM...)
Email is far to 'visable' a service to trust to something not rock solid.
if [ mgmt.need = support-contract ]; then
redhat.install else
debian.install fi
Debian stable is where I'd probably put such a thing. MAYBE debian testing.
Slashdot Mirror
I can think of several reasons that MacOS might be needed as a server... Largeish publishing house using Quark Express comes to mind... it was only released for OSX, what, 6 months ago? For most corperations of any size, that's moving pretty quick.
Besides, remember that even those you consider to be stupid often have good advice. This is one of those instances. Postfix is wonderful. Simple, secure, fast, powerful, extensible... Weitze did an amazing job writing it. He was the guy who wrote TCPWrappers (back in the days before xinetd put some resonable security into inetd) and the origional network analysis tool Satan, so you know it's written with security in mind.
I've got it pushing 6-8 gigs of email a day in one install using pretty lame hardware (uniproc, 2 SCSI drives at RAID 1). We've loved it, and had some great success with it.
At least with XP. I agree with the previous poster that grabing an Xserver for the desktops is going to be a good thing, but the only other thing you NEED is a good telnet/ssh client. I suggest putty, since it's standalone (no dll's, no supporting files, etc. All it does is update some registry keys with host keys and the like). You can drop it in a temp folder, and just run it.
The other thing is to keep a reasonably up to date knoppix CD lying around. If you can boot off the CDROM drive (and almost no windows shop won't) you've got a reasonable linux client there. If you get creative, you could even start your own version of it with your own private utilities installed and ready to go.
Why on earth do you think you need that much bandwidth? Where is the bandwidth going? Most smallish companies (the ones that balk at $800k) don't need more than a couple T1's.
If you REALLY need that kind of bandwidth, take a long look at co-lo'ing your servers somewhere. You can get the bandwidth relativly cheeply, and house all the high bandwidth stuff at the co-lo. Then you just remotely manage it. Have some way to do send large batches of data to the colo (say large capacity tape drive, or maybe some ATA drive array) and you're done.
Am I the only one who saw "DDR for weight loss" and thought: "What on earth does double data rate memory have to do with weightloss?"
YKYR/.TMW...
I might appreciate your opinion of linux better, if you could set up a BSD box that can withstand a slashdoting... :-)
/etc/(rc.d/)init.d, and ps -ef) rather than the BSD approach (as in /etc/rc.d/rc.local and ps -aux)
*BSD's have a different approach to *NIX than most linux'ers. Most of the linux distro's have gone with the SYSV approach as default (as in
It's kinda odd. The BSD's and SYSV's are different superficially (some command line arguments) and at the deep kernel level, but the mid-level abstractions are almost identical (similar syscalls, etc). It's all UNIX though.
I completely agree. There's a huge difference between a degree coming out of your 'technical schools' and a true 'computer science' degree. Most of the jobs that are being outsourced are the ones your curriculum would train someone for. The jobs that are staying are the architecture, the system design, etc.
I believe it was Dijkstra who said something like "Show me the code, and I will not understand. Show me the data structures, and I will." Data structures and interfaces are the heart of programing, and the difference between being a code monkey and a great programer.
Finally, there's a point about aptitude. I am a great sysadmin. I am not a great programer. I understand a lot of what goes into being a great programer, and I know I don't have it. Your curriculum does not allow specializations, and I really think it should.
The heart of all programing does not change. Only languages and methods change. If you can change languages and methods easily, you'll be a much greater programer.
That's a nice theory, but certain things have a hard coded location in mind (like libc.so.0). I tried the LD_LIBRARY_PATH hack, and it didn't solve the problem. Granted, it was late at night, and 6-7 years ago.
/path/to/library.
I BELIEVE it's the difference between running 'ldd' on a binary, anseeing a name of a library file, and the
That's my best guess as to why. I could be wrong.
My best singke mistake was after a long night of re-installing an updated version of solaris on a SparcServer 2, I needed to clear out the /tmp dir sor some stupid reason. So, I did the old: "mkdir newdir ; mv * newdir"
/tmp. I was in /.
/usr/lib/libc.so.0
/usr/sbin/static there are 5 statically compiled binaries: cp, ln, mv, rcp, and tar. /newdir/usr/sbin/static/mv /newdir/* / would have fixed it.
I wasn't in
My next command was 'ls'. It returned: unable to find
AAAAARGH!
I now know how to solve that under solaris. Under
Ever since then, my prompt has had my current directory in it. That experience certainly made me more careful.
Better (or worse) was when a stupid service rep came in to replace a bad CPU on a sun e10000. The idiot shut down the sub-system, and powered off the board correctly. He then managed to pull out the wrong board, despite the blinken lights. Of course it was the peoplesoft domain. Running year end reporting.
AAAAARGH!
Software is written by humans, and humans make errors, so software has bugs.
All software.
The sysadmin motto (abridged) is 'all software sucks, all hardware sucks'
I just looked through the bugtraq archives, and found 3 local root exploits for OpenBSD in the year 2003. That's the same class of problem as was found in Linux.
Security is a mindset, and a practice. It's not a platform.
As someone who has watched people play both, I think that they are on par. Nethack seems more popular right now. If you're into Angband, making the switch over to nethack shouldn't be that hard. About the only difference is that in nethack, you have to go to the bottom, claim amulet, climb back up, and offer amulet to your god on the astral plane.
The development time in winning characters for each game is about equal too. My roommate just beat nethack (ascended) in about 24 hours of play. That's pretty quick by most nethack standards.
This is a brain dead and stupid idea from the world of fixed cost bandwidth. If you start paying for the megabit over a threshold, you're going to get screwed in a hurry. Even if you don't and your idea works well, you're going to loose most of your bandwidth to this idiocy.
Ideally, you have 3 environments:
1) Development. Lax rules. Admins willing to either give root to development, or to change it temporarily so devs can get at it. On a wide open network that is hidden behind a firewall or 3. Sand box. Devs can do whatever they want.
2) Testing. As close as humanly possible to production environment, but with somewhat easy rules. No root access (unless completely proven as needed). All changes logged. This is mostly a staging area for changes to production.
3) Production. Iron rule of law. All changes audited, documented, tested, verified.
Though I wish I had developers I trusted with root access, even on a dev environment. I had one idiot dev who got root, and then did a
cd / ; chown -R idiot:staff *
'But I needed to be able to view everything on that box!!!' Thankfully, it was only on his desktop unix box. If I had some developers with the initiative to ask 'hey, I think somethings wrong with how FTP is working. Could you give me a TCPDUMP trace of what's going on?' I think I'd faint from shock.
To be fair, I know (personally) several developers who I completely trust. Unfortunatly, I don't work with any.
If you read the article, it says: "even though it occupies a mere half-rack of space". So, that'd be 21U, or 21x1.75in (36.75in x 19in x ~20in (depending on it's depth).
I'm with a previous poster. I'd love to work as an analyst for Gartner, GIGA, etc. That'd rock.
Short version of how these companies operate:
1) Listen to geeks to figure out what's popular and new
2) push 'new' ideas as the salvation of computing kind
3) write papers, and sell these opinions for insane ammounts of money
4) proffit!
5) Every year or so, get together with your big $$ clients, and have a huge party in some place cool (according to my co-workers, the party Giga threw in Las Vegas was something to behold)
In principle, I agree with you. HW Raid (if you can get/afford it) is the way to go. Dead drive? Yank it, and pop in another. Automatic resync. No down time.
SW Raid however, isn't (always) as bad as you make it out to be, at least under solaris. Their 'disksuite' product has been very reliable here. Every server has it, and we've yet to see any real problems with it. Great for mirroring the OS drives.
Before version 4, disksuite had some teething problems, but the 4.2.1 release rocks.
Quoth the article:
Meanwhile, some network executives are blaming Nielsen Media Research, the folks who measure viewer ratings, claiming that the firm's methodology is faulty in this new era of digital cable boxes and satellite dishes. Nielsen, of course, disagrees
I was astounded to find out that to be a 'Neilsen reviewer' you had to watch more than 5 hours of TV per day.
ALL OF THEIR STATS ARE BASED OFF OF THESE PEOPLE!
With that in mind, just how realistic do you thing their stats are going to be to begin with, let alone if a large portion of their viewing population is disappearing from them. Would they even notice until the revolution has them up against the wall?
You're trolling, but I'll bite:
Will it support Longhorn? Longhorn is the future of computing, man.
Well, the scary thing is that if Linus does pull off the december of '03 promise, and following linux's usual release cycle of '2 years between major versions', we'll be releasing 2.8.0 at about the same time Longhorn ships in 2006.
Here's a reasonable picture. Found in an article a lower post linked to ('dells dud').
picture here
Lack of control over the medium is what's holding it back. You know those warnings at the end of baseball games? The "This has been a production of Major league Baseball. Unauthorized reproduction is prohibited without the express written consent of the commissioner of baseball" slogan?
They can't control what happens when you get it, there's any number of copies that they can make, and they don't get the revenue stream of commercials.
Big media is all about control, because that's where the money is.
I'd love for the GIMP to catch up to photoshop. I'd love for the GIMP to just catch up enough to use CMYK (iirc) pallets rather than RGB. I'd love for the GIMP to grok enough about the propriatary RAW formats from digital cameras.
The GIMP hasn't had a significan't update in forever. I love it as a tool, but it can't compete with photoshop.
Blind faith in OSS sollutions won't help you. When YOU contribute to the software (documentation, user education (not user flaming), code, test cases, bug reports, etc) OSS gets better, and might be able to start competing.
I think that I agree with several posters. The guy who suggested knoppix has a solid idea, except for the fact that the students will probably need CD access to load various things. Also, you probably don't want the student able to eject the CD and boot off his OWN version of knoppix to keyboard sniff, or whatever.
When it comes to easy of re-install, both have solid paths: jumpstart for solaris and kickstart for linux. 'boot net' from the ok prompt on a solaris box, or have a special floppy that does the same for a linux box, and boom. Re-imaged box. I'll bet you'll end up re-imaging several machines a week, so make it as painless as possible.
See also the poster who mentioned 'authorized users' having an easier time hacking the boxen. There are FAR more hacks available if you already have user privs than if you're outside the box. I also suggest disabling remote access to the boxes from the general network. I can't count the number of times I tried to use a *NIX box for class work, only to find some luser had telneted in and started a high load process for their class work.
Also, remote mount (NFS) as much as you can get away with. This makes a much simpler upgrade path: step 1: update fileserver, step 2: reboot lab (if needed). The downside of NFS is that it's a bit of a security hassle. Also, be aware that NFS on solaris is miles ahead of Linux in ease of use, stability, features, etc. Comes from Sun creating the protocol origionally.
Finally, I think it will be a little easier on the admin's to use Linux for these boxes. Much more up to date, more friendly tools, easier package management, etc. However, if you're NFS mounting lots of stuff (like you should be) then solaris is worth a look too. Their NFS implementation rocks. The downside to solaris on sparc is $$$$$. However, take a long look at solaris on x86... They're very close in code base, you just don't get the spiffy openboot eeprom.
I see both sides of this. I can save a little money (it you actually buy a legal version of windows for dual boot, it eats a lot of the price savings) and build it myself, or I can get a dell.
I tell all my friends to just get a Dell and I personally build my own. This way, I know I get good parts, I know it's not going to fail quickly, and I know that I don't have to offer tech support to my parents.
That, and I can also get one of those sweet Shuttle XPC cases.
No. Not at all. The work around is pretty clever actually. Pretend that you're random IP at company, configured to use your companies DNS server.
.com. Verisign's .com NS servers will try to give back an A record due to this wildcard thing.
.com because .com (and .net) has been declared a 'delegation-only' domain. That means that the .com name servers will only be allowed to return NS records. If they return something else, your companies DNS server will respond to you with an NXDOMAIN error (just like it should for a 'no such domain').
If you request your nameserver to look up misspelledgoogle.com, said DNS server, with this patch, will queries the roots, who give an NS record for
Your companies DNS server won't accept that A record from
These are all very important questions. The other thing that people forget about is the service agreement.
My company paid too much money for an EMC array. We don't need the performance, and we don't need all the wizbang features.
That doesn't mean it sucks though. EMC calls us within 5 minutes of any hardware issues on the box. It's fault tollerant to a amazing degree. The only time we've taken downtime was when we needed to schedule a major firmware update. The support agreement is amazing. If something dies, they call us and say 'we can be on site with an engineer and the part in 2 hours. When do YOU want us to show up?'
Asside from our database servers, none of the boxes we've put on EMC come close to pushing the throughput limits. We would have been much wiser to utilize NAS for most of the servers. Much cheeper, good reliability, reasonable performance, and they can talk all the major file sharing protocols: SMB, CIFS, NFS, etc, and we could have spent less on the SAN.
A poster above suggested a mix of either building the SATA arrays yourself, or a small vender. I poked on their website, and their support agreement says 'parts next day'. If the driveplane blows out, 'next day' may or may not be good enough. People scream really loudly if email is down.
The other thing is making sure you find someone who can reverse engineer your 'rsync' solution. This is one reason companies tend to prefer out of the box apps for system level stuff. They can send someone to training for it.
I have to agree with the 'no gentoo on servers'. It's a wonderful distro, and I use it a lot, but it encourages you to be too bleeding edge... and that WILL bite you at some point.
(Says I as I'm debugging a firewall issue at 9:00 PM...)
Email is far to 'visable' a service to trust to something not rock solid.
if [ mgmt.need = support-contract ]; then
redhat.install
else
debian.install
fi
Debian stable is where I'd probably put such a thing. MAYBE debian testing.