Stupid... but cool as hell. There is such a fine line between stupid and clever.

PF + AltQ, a ZFS raidz array, and booting from a CF card. Excellent job, kudos to the FreeBSD team!

I find it hard to believe that the folks whining (I'm sorry, "bitching") about sudo usage are sysadmins on servers, and certainly not servers that are depended on by others. This policy is a good idea on any system that you can access remotely (thus making it a "server"). Running an internet connected server like a five year old is selfish and it should not be a surprise that it is discouraged.

Presumably when doing system operations, you will do as little as root as possible. Therefore sudo is not much of an inconvenience. Yes, you could prepend a destructive command with sudo, but you would have to be twice as stupid.

If remote root logins are disabled, then you cannot (remotely) guess the root password.

I read your post as:

"I am so good, and so careful, I would never, ever make a mistake as root."

Good luck to you on production servers, and may your employer and clients have mercy on your soul.

Look, admit it: running commands as root is a convenience for you, and you are willing to make the obvious tradeoff in stability and security. But don't imply that others are as gifted as you are in avoiding simple mistakes that are catastrophic as root.

This touches on another point, that is being "root" at any time other than sysinstall. FreeBSD has never (by default) allowed root logins via SSH, and I will always contend that is a "good thing". If you access a system via SSH, it is a server. If you are on a shell session on a server, you should NEVER be root-- that's what sudo is for.

If you whine about this, you are indeed a poor sysadmin. It reminds me of my friend who habitually texts while driving. "But I have never been in an accident," he says. How selfish, putting his convenience above the safety of those around him.

I found that when a client of mine connected via SSH to a well connected server (Equinix/Ashburn), they could use the SOCKS setting in Firefox (connecting to localhost since that's what their SSH client listened to) to tunnel all of their traffic with no problem. Note: this was a Mac, up to date as of last year when we tried this.

Sure enough, one day the tunneling stopped working! We changed the port used by SSH to 443, and it worked just fine after that.

I'd like to see how the systems (CPU/RAM/MB etc) perform with a 64 bit OS with a simulated workload. How about:

• FreeBSD 7 (AMD64)
• MySQL 5.1.30
• Apache 2.2 (worker MPM)
• PHP 5.2.8 (or HTML::Mason)

What is the responsiveness of the system under load? Openssl speed? bonnie++?

I am doing much the same thing, but with FreeBSD. For long term storage, how about a RAIDz with 2 parity drives, and use the largest SSD thumb drives you can find/afford. They ought to last a while, and up to two of them could fail with no data loss.

Full Disclosure: Original Poster is my Business Partner It is obvious, to me anyway, that much of the controversy surrounding the measures advocated here arises either from ignorance of the issues being discussed, or, worse yet, feigned ignorance by those who have an agenda....that agenda being the proliferation of their own SPAM, or, at best, a selfish indifference to the problem and an implicit assertion of "rights" which simply do not exist. I must admit that in order for me to grasp some of the technical implications here, I had to consult with my mail guru, but after much study it is apparent to me that the vast majority of posts in opposition to these measures demonstrate ignorance. So, in layman's terms, perhaps, what do these measures really mean? 1. Block egress port 25. I think this means that if I own an email server, I get to decide whether or not I will just blindly pass email along regardless of where it comes from and whether or not the sender is known to me. Desiring to take whatever small steps I can to reduce the amount of SPAM in the system, I would choose no, and, therefore, block egress port 25. Sure, if you own the server, it's your right to decide not to, but you can't deny that having an open relay contributes to the SPAM problem. It seems to me that the implicit asserted "right" that people are demanding here is the right for everyone to submit their email on any server they choose, without any responsibility for what they are sending. Why is it so controversial to expect that if you want to send email, you should have an account somewhere that authorizes you to use a specific server? 2. Blacklists. They help some, right? Not perfect, but ours help us to reject thousands of messages per day, and in about a year and a half of operation we have NEVER been made aware of a legitimate message that didn't get through. (Of course it's POSSIBLE...but...really). 3. SPF So there is a way that I can tell if an inbound message really comes from where it claims to come from. Sounds good to me. I roam all over the world, and am able to authenticate to my provider's server from a Cafe in Kiev or a Bungalow in Bali. It's really not that hard. If you can provide email, you can provide authentication. 4. This point was more of a summary of the three which preceeded it. So, in summary, the positions advocated here, in my view, amount to responsible mail management. MOst of the opposition seems to be in the "Wahhhh...I want a pony.." spirit. For those who argue that they are not effective because the spam problem hasn't improved, think about how narrowly these measures have been adopted. I can't wait until AOL, Hotmail, and the like institute SPF or similar measures. And, no, I will not blindly accept and pass along your unauthenticated, unknown, careless, lazy email.