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 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 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.
4 disks and RAID 6? That make little sense. If you have 4 drives and are willing to give up 50% to redundancy (which is not out of the question), RAID 10 (pair of striped drives + pair of striped drives, mirrored) is much less complex.
I was being facetious, as in, "please explain what you want me to think your headline means". I would apologize for not being more clear, but I re-read mu original post and I stand by it's clarity as written. However, I do confess maneuvering toward an overused Princess Bride joke, but decided against it (too easy).
I do not plan to hand in my geek card anytime soon.
What exactly does "Hijacks 404 Error Pages" mean? Does it mean error pages were hijacked 404 times? It certainly does not mean what the headline implied (to me). Even a cursory glance at TFA makes that clear.
Let me add PHP to the list! PHP is wonderfully easy to allow inexperienced programmers (read: non-programmers) to build something that looks and feels like it works, but often without the coder knowing HOW (or why) it works.
Whenever I set up the network infrastructure for a business, particularly on that has a lot of laptops, I make sure to intercept all DNS traffic and redirect it to a local server (since most of the boxes are routers, firewalls, NTP and DNS servers all in one, on (Open|Free)BSD this is easier).
For PF, it's as simple as: rdr pass on $if proto {tcp,udp} from any to any port 53 -> 127.0.0.1 port 53
If you still use IPFilter, use this rule in ipnat.rules: rdr de0 0.0.0.0/0 port 53 -> 127.0.0.1 port 53 tcp/udp
Remember office environments a few years ago... with a T1 (ideally) or xDSL (better than ISDN)?
And you would track down the one or two users that consumed the entire pipe 24/7? And no matter where, there was always one or two of 'em?
...and maybe you were one of 'em;)
Comcast oversold their capacity. They did not count on the number of subscribers who would exceed their ill-prepared estimates. Now they want to deny service to those subscribers... induce them to find another provider. They can do what they want, you can always choose to not do business with them.
Take their bait. Comcast is at best a reasonable solution to light users (or maybe people who swallow the entire Comcast pill-- VIOP + web hosting + email hosting, etc?). Get Fios if you can, or even a fast DSL. It is "better" access.
I have been using FreeBSD 7 (started with the betas, now at RC1, using cvsup), with my entire music and photo collection on a set of drives mirrored with ZFS. I had to tweak samba slightly, but otherwise it has been smooth sailing. My server has less than the recommended ram for ZFS, but the box has been working just fine for months.
I have 4 workstations (WinXP, Win2000, Mac, Ubuntu) simultaneously connected, and I can make snapshots of the live file systems while in use (>1 second for 100GB). I can also do a scrub while the system is in use, with no noticeable performance hit.
ZFS seems perfectly stable to me, and I am trying to use all of the goodies that come with it as well as moderately stress it. I'd say it is ready for prime time.
I looked through the text of the bill you referenced, but I found nothing in it to suggest "there are laws shredding it up". It looks like it is authorizing a few committees to study the formation of domestic "home-grown" terrorist organizations and cells.
I am not familiar with OLSpamCop, as I do not use Outlook. I am familiar with SpamCop, and how they need the detail in the headers to be intact, so I would guess that this is a workable solution.
If we take the profit out of spam, we will see less spam. To date, pump and dump spam bombs work, so the scammers continue to hire spammers to flood our inboxes. Without getting caught, the risk to scammer and spammer is zero. With the SEC pursuing the scammers, the scam becomes less profitable due to the increased risk. With less profit, there is less to pay the spammers, and thus (hopefully) less spam.
I met an SEC investigator at a social event not too long ago, and it did not take long for the conversation to turn to this subject. She said they take this very seriously, and submitted P&D spam has allowed them to prosecute quite a few scammers. The earlier into such a campaign, the better, so they can start monitoring as soon as possible.
Forward the message to mailto:enforcement@sec.gov. Use Thunderbird or another mail client that does not strip or mangle the original headers (like Outlook does).
The SEC will devote significant resources investigating and often prosecuting the people who are behind these scams.
For more traditional VPNs (PPtP, IPSec, etc), this is not as much of a concern, since the certificate and/or keys are usually part of the VPN software installation. For SSL web access, man-in-the-middle attacks can and have been used to intercept access. This would be extremely difficult to pull off by use of a laptop (by that I mean the criminal pretends to be a casual hotspot visitor), but much easier for the operator of the hotspot (who can control DNS, use NAT tricks, etc).
I don't think the article made it clear enough the difference between using your own laptop versus using a kiosk. Obviously, never enter ANYTHING, even your name, into a kiosk. Period.
When you are using your laptop in a public hotspot, only enter personal information on web sites that use SSL. That excludes Slashdot, MySpace, and many web-mail sites... but still allows the use of many well designed and secure systems (Amazon, PayPal, eBay).
Using a VPN absolutely eliminates the danger of sniffing, even if the "VPN" is merely SSL webmail.
However, the biggest omission is mentioning the danger of using a Windows laptop on a public network-- just turning it on! Remember blaster, et. al.? Try running ethereal at a busy hotspot-- not only can you see user names and passwords, but you can watch as infected Windows laptops attempt to wiggle in using Windows network stack bug <insert favorite zero day exploit here>. Imagine if the infection attempt was successful, and you brought that laptop back to the office, inside the corporate firewall.
"While FreeBSD's UFS developers were messing around with sync writes to avoid testing a fsck that would often crash..."
I can't recall fsck ever crashing, and I have been running FreeBSD systems since 2.1 (1995). "Kick ass" fsck sounds scary-- like it was designed for really fscked up drives. Wouldn't it be better to never, ever have really damaged file systems? For the vast majority of uses, stability should trump performance.
As far as what FreeBSD developers were messing around with, here is a good read from 2001: Matt Dillon interview
Your post reminded me of a conversation I had with a client a week ago. I had just helped him get a project set up on a series of 7 Windows servers (I will avoid delving into the details of licensing complexity, remote access, et al). IMHO, the infrastructure was needlessly complex and certainly more expensive than necessary-- and this was due primarily to going "the Microsoft way".
I am used to BSD systems (Open, Free) and some Linux, and my client is almost exclusively Mac. I host a few other web sites for him, some e-commerce backends, massive email infrastructure (Cyrus), and encrypted remote backups (rsync+SSL+gdbe). We have never had an unplanned outage in 10 years (ok, one extended power outage before we were in a large hosting facility).
Well, two weeks later the Windows system "broke". Nobody could log in, lots of MS-SQL errors, etc. The part time Windows admin that coded much of the system was able to get it back up and running again in a few hours.
My client said to me, "I don't get it-- I'm used to stuff just working."
Slashdot Mirror
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.
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.
Wasn't that one of the bad guys in "Under Siege: 2"?
4 disks and RAID 6? That make little sense. If you have 4 drives and are willing to give up 50% to redundancy (which is not out of the question), RAID 10 (pair of striped drives + pair of striped drives, mirrored) is much less complex.
Now a ZFS RAIDz/2 with 8 drives...
I was being facetious, as in, "please explain what you want me to think your headline means". I would apologize for not being more clear, but I re-read mu original post and I stand by it's clarity as written. However, I do confess maneuvering toward an overused Princess Bride joke, but decided against it (too easy).
I do not plan to hand in my geek card anytime soon.
What exactly does "Hijacks 404 Error Pages" mean? Does it mean error pages were hijacked 404 times? It certainly does not mean what the headline implied (to me). Even a cursory glance at TFA makes that clear.
Let me add PHP to the list! PHP is wonderfully easy to allow inexperienced programmers (read: non-programmers) to build something that looks and feels like it works, but often without the coder knowing HOW (or why) it works.
In my sample code, change 127.0.0.1 to the IP address of the DNS server you wish to use.
Whenever I set up the network infrastructure for a business, particularly on that has a lot of laptops, I make sure to intercept all DNS traffic and redirect it to a local server (since most of the boxes are routers, firewalls, NTP and DNS servers all in one, on (Open|Free)BSD this is easier).
For PF, it's as simple as:
rdr pass on $if proto {tcp,udp} from any to any port 53 -> 127.0.0.1 port 53
If you still use IPFilter, use this rule in ipnat.rules:
rdr de0 0.0.0.0/0 port 53 -> 127.0.0.1 port 53 tcp/udp
I'm calling you on this claim.
Remember office environments a few years ago... with a T1 (ideally) or xDSL (better than ISDN)?
And you would track down the one or two users that consumed the entire pipe 24/7? And no matter where, there was always one or two of 'em?
Comcast oversold their capacity. They did not count on the number of subscribers who would exceed their ill-prepared estimates. Now they want to deny service to those subscribers... induce them to find another provider. They can do what they want, you can always choose to not do business with them.
Take their bait. Comcast is at best a reasonable solution to light users (or maybe people who swallow the entire Comcast pill-- VIOP + web hosting + email hosting, etc?). Get Fios if you can, or even a fast DSL. It is "better" access.
I have been using FreeBSD 7 (started with the betas, now at RC1, using cvsup), with my entire music and photo collection on a set of drives mirrored with ZFS. I had to tweak samba slightly, but otherwise it has been smooth sailing. My server has less than the recommended ram for ZFS, but the box has been working just fine for months.
I have 4 workstations (WinXP, Win2000, Mac, Ubuntu) simultaneously connected, and I can make snapshots of the live file systems while in use (>1 second for 100GB). I can also do a scrub while the system is in use, with no noticeable performance hit.
ZFS seems perfectly stable to me, and I am trying to use all of the goodies that come with it as well as moderately stress it. I'd say it is ready for prime time.
I looked through the text of the bill you referenced, but I found nothing in it to suggest "there are laws shredding it up". It looks like it is authorizing a few committees to study the formation of domestic "home-grown" terrorist organizations and cells.
Did I miss something?
I am not familiar with OLSpamCop, as I do not use Outlook. I am familiar with SpamCop, and how they need the detail in the headers to be intact, so I would guess that this is a workable solution.
If we take the profit out of spam, we will see less spam. To date, pump and dump spam bombs work, so the scammers continue to hire spammers to flood our inboxes. Without getting caught, the risk to scammer and spammer is zero. With the SEC pursuing the scammers, the scam becomes less profitable due to the increased risk. With less profit, there is less to pay the spammers, and thus (hopefully) less spam.
I met an SEC investigator at a social event not too long ago, and it did not take long for the conversation to turn to this subject. She said they take this very seriously, and submitted P&D spam has allowed them to prosecute quite a few scammers. The earlier into such a campaign, the better, so they can start monitoring as soon as possible.
Forward the message to mailto:enforcement@sec.gov. Use Thunderbird or another mail client that does not strip or mangle the original headers (like Outlook does).
The SEC will devote significant resources investigating and often prosecuting the people who are behind these scams.
Good point!
For more traditional VPNs (PPtP, IPSec, etc), this is not as much of a concern, since the certificate and/or keys are usually part of the VPN software installation. For SSL web access, man-in-the-middle attacks can and have been used to intercept access. This would be extremely difficult to pull off by use of a laptop (by that I mean the criminal pretends to be a casual hotspot visitor), but much easier for the operator of the hotspot (who can control DNS, use NAT tricks, etc).
I had a few problems with the article:
- I don't think the article made it clear enough the difference between using your own laptop versus using a kiosk. Obviously, never enter ANYTHING, even your name, into a kiosk. Period.
- When you are using your laptop in a public hotspot, only enter personal information on web sites that use SSL. That excludes Slashdot, MySpace, and many web-mail sites... but still allows the use of many well designed and secure systems (Amazon, PayPal, eBay).
- Using a VPN absolutely eliminates the danger of sniffing, even if the "VPN" is merely SSL webmail.
However, the biggest omission is mentioning the danger of using a Windows laptop on a public network-- just turning it on! Remember blaster, et. al.? Try running ethereal at a busy hotspot-- not only can you see user names and passwords, but you can watch as infected Windows laptops attempt to wiggle in using Windows network stack bug <insert favorite zero day exploit here>. Imagine if the infection attempt was successful, and you brought that laptop back to the office, inside the corporate firewall.I can't recall fsck ever crashing, and I have been running FreeBSD systems since 2.1 (1995). "Kick ass" fsck sounds scary-- like it was designed for really fscked up drives. Wouldn't it be better to never, ever have really damaged file systems? For the vast majority of uses, stability should trump performance.
As far as what FreeBSD developers were messing around with, here is a good read from 2001:
Matt Dillon interview
Your post reminded me of a conversation I had with a client a week ago. I had just helped him get a project set up on a series of 7 Windows servers (I will avoid delving into the details of licensing complexity, remote access, et al). IMHO, the infrastructure was needlessly complex and certainly more expensive than necessary-- and this was due primarily to going "the Microsoft way".
I am used to BSD systems (Open, Free) and some Linux, and my client is almost exclusively Mac. I host a few other web sites for him, some e-commerce backends, massive email infrastructure (Cyrus), and encrypted remote backups (rsync+SSL+gdbe). We have never had an unplanned outage in 10 years (ok, one extended power outage before we were in a large hosting facility).
Well, two weeks later the Windows system "broke". Nobody could log in, lots of MS-SQL errors, etc. The part time Windows admin that coded much of the system was able to get it back up and running again in a few hours.
My client said to me, "I don't get it-- I'm used to stuff just working."