Don't get me wrong, I've met enough problems myself in IT. But firstly, your problem needs to be expressed clearly.
"High Availability" can mean a lot of things. The most important part of it, though, is "how highly available do you need?". Do you want to survive the loss of a server? Of a room? An office? A city?
Basically, you've got two options.
1. Homebuilt, possibly based around either Solaris (ZFS looks interesting) or a specialised Linux distribution. OpenFiler looks interesting but doesn't appear to get a lot of attention, so community support may be lacking. Unless you've already got the hardware, however, you'll need at least two reasonably large servers.
Depending on how crucial all this is to your employer (I'm assuming it's fairly crucial or you wouldn't be looking at HA systems in the first place), the level of support you have available to fall back on with this may or may not be acceptable.
In any case, if you're going to have to spend the amount of money involved in buying two large servers and paying for support on a linux distro anyway, you may as well look at option 2.
2. An entry-level SAN.
Yes, I know you said you can't afford it. But I don't think the problem you're discussing can be easily tackled for zero-cost, and if there's cost involved you'd be in remiss of your duties to not cover every possible base.
I was faced with the same problem myself a few months ago. Eventually I concluded that there simply wasn't the business justification for highly-available storage - we could make do with servers with redundant power supplies and disks, and regular backups. However, I was surprised to find that an entry-level SAN from Dell (actually rebranded EMC units) isn't that much dearer than "buy two dirty great servers and run OpenFiler", and has the benefit that if you do need support, you don't run the risk of hardware and software support folks pointing the finger at each other, saying "it's not our problem, it's theirs".
Plus any half-decent SAN vendor will provide a clear upgrade path - if you roll your own, you'll have to figure out how you upgrade on your own when the time comes.
Finally, think of it like this.
Any business which relies on its backend systems to be solid and reliable should take any reasonable suggestion to maintain that reliability seriously. And by definition, this implies that storage must be reliable.
If it's that important to the business that your systems continue to operate in the face of extreme adversity, and you decided to save £1000 by taking the homebrew route, you're going to have a lot of justifying to do if the worst happens and your supposedly-HA system falls over. Particularly if your answer to "what are you doing about it?" is "I've posted a message to a forum and I'm awaiting a reply". Realistically the only way it can work is if you're competent enough to be able to fix even the worst outage yourself with little or no recourse to asking on forums (though reading documentation is OK). Even then, you should keep the system simple enough that it doesn't take several months of familiarising yourself with it before anyone else has a chance of fixing it, otherwise all you've done is moved the point of failure from the hardware to yourself.
The alternative answer "I've placed an emergency support call with our suppliers and they should be ringing me back within the hour" carries a heck of a lot more weight.
The article basically says "a post made by a clueless chap on a forum is almost certainly conplete twaddle. I wouldn't have even written this but his post quotes me."
So, IOW: the article is one big "nothing happened"
It might seem that wth, we already know the laws of mechanics well enough, we don't need experiments to test them.
I would point out that every major race in the whole of history has been pretty much convinced that they already knew all the important stuff.
Aristotle, for instance, also argued that you didn't need to do experiments. And look how spectacularly accurate his models of how an object travels through the air are.
Then install someone who will fire SCO's "crack" team of lawyers (drugs aren't good for you anyway) and start sweeping through the company firing anyone who's not related to the few revenue streams that SCO actually has. Normally that would be a sad (and often dangerous) thing for a company, but in SCO's case, I doubt that many tears will be shed.
The original business model of SCO was to produce, sell and support a commercial Unix for x86-compatible hardware.
However they've already sacked most of their developers so that revenue stream is probably no longer sustainable simply because there's nobody left to sustain it. Even if there was, SCO unix has fallen so far behind Linux that it's in no danger of catching up any time soon.
1. Improve the customer relations that SCO has been driving into the ground for so long.
"This company has decided to start suing its customers" is the kind of thing that winds up in magazines read by CEOs and MDs who don't know or care much about the technology, but do know that they don't want to do business with a company that has a habit of suing its customers.
IOW, I'm not sure SCO can - in any guise - hold up long enough to weather the PR storm they've brought upon themselves.
the sheer number of crackhead cousins in the united states is evidence that this is a viable business model. And the fact that SCO still haven't been paid any money to go away is evidence that while it may be a viable business model, it doesn't scale up very well.
Yep. Provided it's your bank who's managing the webapp.
Like everything in IT, it's a tradeoff.
Are we prepared to tradeoff the risk inherent in storing our data on someone else's system (what happens if they go bankrupt? how can we be sure their systems are reliable and secure?) against the work involved in running our own (how do we upgrade everything? are we prepared to spend several weeks preparing for and rolling out an application rather than just paying £££ to someone so we can login to a website they run to do everything?).
Right now, a lot of businesses are saying that they're not at all sure about risking data on which they depend on someone else's business plan. But an appliance which provides the application - either a hardware appliance like the Google device or a prebuilt VMWare image - is much more attractive.
As regards individuals - lots of people are communicating extensively via email yet trust Hotmail for everything. I don't see this as being much different.
A program must be able to recognize invalid input and take appropriate action. Allowing (or forcing) a crash is NOT acceptable.
Word might have a bit of a problem there.
I'm not agreeing with the design , but AIUI a pre-"Office 2007 XML format" word document is basically a memory dump of the area of memory the document was stored in. With very little sanity checking going on at the load document stage (in theory you don't need it because you'll never be able to save a document which causes Word to crash anyway), it has always been possible to kill Word with a corrupt document. There's probably a lot more sanity-checking in the code nowadays, but the fundamental design remains.
I saw similar things happen with corrupt word documents back in the days of Word 6/Windows 3.0.
I doubt the data was encrypted in the first place. If it was, they certainly didn't use the password as the key to encrypt it because a wrong password still gained access to the data.
the result is revolutionary, ultra safe and approved by the French intelligence service.
I think that says quite a lot for the French intelligence service. Unless they wanted an insecure device to be marketed as secure.... black helicopters at the ready.
If you have a lot of developers, you can give each one their own environment (or virtual environment, take your pick) without having to buy 1 copy of RHEL/developer.
Doesn't take very long for that to be a substantial saving.
Re:yet another Fedora Core 6
on
CentOS 5 Released
·
· Score: 5, Informative
RH admitted that 300+ packages in RHEL5 are rpms from FC6. RHEL 5 strongly resembles of FC6... it is nothing but augmented version of it anyway...and CentOS is exactly that as well.
That's the whole point of the fedora project: to provide a base from which to produce RHEL.
The core difference, as has already been pointed out, is long-term support. If you find you need a security update for a particular package for Fedora Core 6 in a couple of years when FC9 is the latest version, good luck. Your only options are to upgrade the whole system or build the package (and any dependencies which also require updating) yourself.
You may not have a problem with that. CentOS and RHEL is intended for people who do.
Nagios is just not that hard to configure. If you had a web front end, then every time a change to the capabilities was made you'd have to go back through and update the front end to make it support it, which means more time between releases, longer turnarounds for new features, and likely less flexibility in the system in general.
You'd better tell the developers who are sat next to me that one. They think they're using a toolkit which practically gives them a web-based interface for free when they develop the command-line interface.
No, it's not. And why? Because you simply can't have your cake and eat it too. If you want flexibility and power you're going to have complexity.
You know, rather than just tell me that I'm asking for the moon, you could try ZenOSS. You get a heck of a lot of flexibility and power with substantially less complexity.
There seems to be a certain idea in the Linux community that just because "it's a community-developed Unix" it has to be bloody awkward to get basic things to work. Eric Raymond has already pointed out that this makes no sense at all:
The only way I can make any sense of this opinion persisting is that most of the Linux developers are secretly into S&M and when they shut the computer down for the night, they wander into their dungeon for some light whipping and flaggelation.
True, but there's always the possibility that discs will be re-run with different keys.
The thing to bear in mind is that object of the exercise isn't to make copying the media impossible. Contrary to popular/. belief, even the MP/RIAA know that such an aim is fruitless.
The object of the exercise is to make producing and distributing half-decent copies sufficiently difficult as to put off all but the most determined geeks. Much like it was before MP3 became commonplace.
The problem they're facing is that they're trying to do this in software. In the past the problems which made widespread production and distribution of pirated copies difficult were hardware based (it used to be very expensive to buy CD duplicating equipment and MP3, DivX and broadband hadn't had the same impact as they have today).
Unlike with hardware, the barrier to entry with software-based problems is no more than "enough time". And history has shown that there are more than enough software geeks with enough time.
I imagine sooner or later, they simply won't license software HD-DVD playback (or whatever the next technology is) for general-purpose computers. Don't for one minute imagine this means the end of the computer, however. Just that general-purpose computers as we know them will cease to exist. Hello, trusted computing.
I use Nagios myself as I was looking for a quick and dirty replacement for Big Brother.
While it's a fantastic tool, my biggest beef with it by a LONG way is that configuring a new server to monitor is always a case of "hand-edit this config file and that, figure out what's important to monitor and what isn't, realise 3 months later that you missed out something you really should be monitoring...." aarrgh. Templates help hugely but they're only part of the solution.
If you're going to make monitoring easy with a pretty-pretty web-based user interface, then why on Earth can't what the monitor itself does be configured through the same web-based interface?
Right now I'm using ZenOSS (http://www.zenoss.com/) which solves that particular problem very neatly - and unlike Nagios, has very good SNMP support. But it's not as easy to hack as Nagios, mainly because it doesn't have such a strong community surrounding it so punching "zenoss monitor (insert obscure thing here)" into Google doesn't work so well.
Ah, for something with the out-of-the-box functionality (and "out of the box" means "out of the box", not "out of the box provided you spend another 2 hours setting up a bunch of config files to support it") and ease of use of ZenOSS, but the hackability and community of Nagios. Never gonna happen.
I realise my suggestion breaks the idea of the blacklist being "write once". But if it's only writeable from a hidden area, I don't see that as being an issue.
Not really. It's a bit of an arms race, and my idea is only a theory anyhow.
Were you to spam the blacklist, the obvious thing to do after that is to fix it so the oldest entries in the blacklist are automatically overwritten every time a new HD-DVD is inserted. Unless you're constantly spamming it, you'll never quite know what you can and can't decode. Perhaps if the blacklist could only be populated by a hidden area of the disk which isn't writeably in commercially-bought HD-DVD-R's.... but then doubtless someone else would come up with some other fix for that.
Doesn't matter in the slightest what the cause is. Most country's consumer law is worried about the effect.
In this case, the effect is "My DVD player doesn't work any more and it's still in warranty".
The solution is to repair/replace it. What exactly the problem is may be interesting to those on/. , but for grandma taking her DVD player back, it matters not.
If "Compromise the same way" means instructions which involve taking the cover off, soldering a line onto a JTAG port and running a serial port to it, I really don't think that kind of compromise is going to be used by many people.
I don't see how flashing my HD-DVD drive firmware because its key got revoked is any less onerous than downloading the latest crack from a random P2P network.
There's lots of things the manufacturer can do to hard/firmware to make it substantially harder for you than can be done in software.
Off the top of my head:
- Firmware can be rewritten maximum of 5 times, but keys can be rewritten as many times as you like. Doesn't solve the issue of keys getting cracked, so... - Future revisions could allow for a pool of blacklisted keys. Any key in the blacklist will be ignored, regardless of whether or not it's in the list of acceptable keys. Every entry in the blacklist is write-once. Sure, you'll only be able to store a limited number of keys in this blacklist, but you don't need to store an unlimited number - just enough to be inconvenient.
I know the whole point of DNS is that it's hierarchical. But with all these suggestions like ".safe for financial institutions,.xxx for porn" combined with countries with "desirable" ccTLDs selling domains (Don't get me wrong, it's their domain space and they can do what they wish. But I never knew so many English-language television companies were based out of Tuvalu), there seems little point in having a TLD-based hierarchy at all.
You may as well allow any organisation to register anything as a TLD. TBH, I think the only reason that hasn't been allowed is because the domain typo-squatting problem would be even sillier than it is today, placing a much higher level of stress on the top-level DNS servers.
Slashdot Mirror
Don't get me wrong, I've met enough problems myself in IT. But firstly, your problem needs to be expressed clearly.
"High Availability" can mean a lot of things. The most important part of it, though, is "how highly available do you need?". Do you want to survive the loss of a server? Of a room? An office? A city?
Basically, you've got two options.
1. Homebuilt, possibly based around either Solaris (ZFS looks interesting) or a specialised Linux distribution. OpenFiler looks interesting but doesn't appear to get a lot of attention, so community support may be lacking. Unless you've already got the hardware, however, you'll need at least two reasonably large servers.
Depending on how crucial all this is to your employer (I'm assuming it's fairly crucial or you wouldn't be looking at HA systems in the first place), the level of support you have available to fall back on with this may or may not be acceptable.
In any case, if you're going to have to spend the amount of money involved in buying two large servers and paying for support on a linux distro anyway, you may as well look at option 2.
2. An entry-level SAN.
Yes, I know you said you can't afford it. But I don't think the problem you're discussing can be easily tackled for zero-cost, and if there's cost involved you'd be in remiss of your duties to not cover every possible base.
I was faced with the same problem myself a few months ago. Eventually I concluded that there simply wasn't the business justification for highly-available storage - we could make do with servers with redundant power supplies and disks, and regular backups. However, I was surprised to find that an entry-level SAN from Dell (actually rebranded EMC units) isn't that much dearer than "buy two dirty great servers and run OpenFiler", and has the benefit that if you do need support, you don't run the risk of hardware and software support folks pointing the finger at each other, saying "it's not our problem, it's theirs".
Plus any half-decent SAN vendor will provide a clear upgrade path - if you roll your own, you'll have to figure out how you upgrade on your own when the time comes.
Finally, think of it like this.
Any business which relies on its backend systems to be solid and reliable should take any reasonable suggestion to maintain that reliability seriously. And by definition, this implies that storage must be reliable.
If it's that important to the business that your systems continue to operate in the face of extreme adversity, and you decided to save £1000 by taking the homebrew route, you're going to have a lot of justifying to do if the worst happens and your supposedly-HA system falls over. Particularly if your answer to "what are you doing about it?" is "I've posted a message to a forum and I'm awaiting a reply". Realistically the only way it can work is if you're competent enough to be able to fix even the worst outage yourself with little or no recourse to asking on forums (though reading documentation is OK). Even then, you should keep the system simple enough that it doesn't take several months of familiarising yourself with it before anyone else has a chance of fixing it, otherwise all you've done is moved the point of failure from the hardware to yourself.
The alternative answer "I've placed an emergency support call with our suppliers and they should be ringing me back within the hour" carries a heck of a lot more weight.
At the risk of being modded troll...
The article basically says "a post made by a clueless chap on a forum is almost certainly conplete twaddle. I wouldn't have even written this but his post quotes me."
So, IOW: the article is one big "nothing happened"
How is this news?
It might seem that wth, we already know the laws of mechanics well enough, we don't need experiments to test them.
I would point out that every major race in the whole of history has been pretty much convinced that they already knew all the important stuff.
Aristotle, for instance, also argued that you didn't need to do experiments. And look how spectacularly accurate his models of how an object travels through the air are.
Then install someone who will fire SCO's "crack" team of lawyers (drugs aren't good for you anyway) and start sweeping through the company firing anyone who's not related to the few revenue streams that SCO actually has. Normally that would be a sad (and often dangerous) thing for a company, but in SCO's case, I doubt that many tears will be shed.
The original business model of SCO was to produce, sell and support a commercial Unix for x86-compatible hardware.
However they've already sacked most of their developers so that revenue stream is probably no longer sustainable simply because there's nobody left to sustain it. Even if there was, SCO unix has fallen so far behind Linux that it's in no danger of catching up any time soon.
1. Improve the customer relations that SCO has been driving into the ground for so long.
In the big scheme of business, "Sue your customers" is somewhere lower down the intelligence scale than announcing to an influential group of copmany directors that all your products are total crap. Granted, a lot of businesses are famous for not learning from their mistakes, but most such mistakes are relatively minor.
"This company has decided to start suing its customers" is the kind of thing that winds up in magazines read by CEOs and MDs who don't know or care much about the technology, but do know that they don't want to do business with a company that has a habit of suing its customers.
IOW, I'm not sure SCO can - in any guise - hold up long enough to weather the PR storm they've brought upon themselves.
Webapps can be secure. Your bank trusts them.
Yep. Provided it's your bank who's managing the webapp.
Like everything in IT, it's a tradeoff.
Are we prepared to tradeoff the risk inherent in storing our data on someone else's system (what happens if they go bankrupt? how can we be sure their systems are reliable and secure?) against the work involved in running our own (how do we upgrade everything? are we prepared to spend several weeks preparing for and rolling out an application rather than just paying £££ to someone so we can login to a website they run to do everything?).
Right now, a lot of businesses are saying that they're not at all sure about risking data on which they depend on someone else's business plan. But an appliance which provides the application - either a hardware appliance like the Google device or a prebuilt VMWare image - is much more attractive.
As regards individuals - lots of people are communicating extensively via email yet trust Hotmail for everything. I don't see this as being much different.
A program must be able to recognize invalid input and take appropriate action. Allowing (or forcing) a crash is NOT acceptable.
Word might have a bit of a problem there.
I'm not agreeing with the design , but AIUI a pre-"Office 2007 XML format" word document is basically a memory dump of the area of memory the document was stored in. With very little sanity checking going on at the load document stage (in theory you don't need it because you'll never be able to save a document which causes Word to crash anyway), it has always been possible to kill Word with a corrupt document. There's probably a lot more sanity-checking in the code nowadays, but the fundamental design remains.
I saw similar things happen with corrupt word documents back in the days of Word 6/Windows 3.0.
I doubt the data was encrypted in the first place. If it was, they certainly didn't use the password as the key to encrypt it because a wrong password still gained access to the data.
the result is revolutionary, ultra safe and approved by the French intelligence service.
I think that says quite a lot for the French intelligence service. Unless they wanted an insecure device to be marketed as secure.... black helicopters at the ready.
If you have a lot of developers, you can give each one their own environment (or virtual environment, take your pick) without having to buy 1 copy of RHEL/developer.
Doesn't take very long for that to be a substantial saving.
RH admitted that 300+ packages in RHEL5 are rpms from FC6. RHEL 5 strongly resembles of FC6... it is nothing but augmented version of it anyway ...and CentOS is exactly that as well.
That's the whole point of the fedora project: to provide a base from which to produce RHEL.
The core difference, as has already been pointed out, is long-term support. If you find you need a security update for a particular package for Fedora Core 6 in a couple of years when FC9 is the latest version, good luck. Your only options are to upgrade the whole system or build the package (and any dependencies which also require updating) yourself.
You may not have a problem with that. CentOS and RHEL is intended for people who do.
Nagios is just not that hard to configure. If you had a web front end, then every time a change to the capabilities was made you'd have to go back through and update the front end to make it support it, which means more time between releases, longer turnarounds for new features, and likely less flexibility in the system in general.
l
You'd better tell the developers who are sat next to me that one. They think they're using a toolkit which practically gives them a web-based interface for free when they develop the command-line interface.
No, it's not. And why? Because you simply can't have your cake and eat it too. If you want flexibility and power you're going to have complexity.
You know, rather than just tell me that I'm asking for the moon, you could try ZenOSS. You get a heck of a lot of flexibility and power with substantially less complexity.
There seems to be a certain idea in the Linux community that just because "it's a community-developed Unix" it has to be bloody awkward to get basic things to work. Eric Raymond has already pointed out that this makes no sense at all:
http://www.catb.org/~esr/writings/cups-horror.htm
The only way I can make any sense of this opinion persisting is that most of the Linux developers are secretly into S&M and when they shut the computer down for the night, they wander into their dungeon for some light whipping and flaggelation.
True, but there's always the possibility that discs will be re-run with different keys.
/. belief, even the MP/RIAA know that such an aim is fruitless.
The thing to bear in mind is that object of the exercise isn't to make copying the media impossible. Contrary to popular
The object of the exercise is to make producing and distributing half-decent copies sufficiently difficult as to put off all but the most determined geeks. Much like it was before MP3 became commonplace.
The problem they're facing is that they're trying to do this in software. In the past the problems which made widespread production and distribution of pirated copies difficult were hardware based (it used to be very expensive to buy CD duplicating equipment and MP3, DivX and broadband hadn't had the same impact as they have today).
Unlike with hardware, the barrier to entry with software-based problems is no more than "enough time". And history has shown that there are more than enough software geeks with enough time.
I imagine sooner or later, they simply won't license software HD-DVD playback (or whatever the next technology is) for general-purpose computers. Don't for one minute imagine this means the end of the computer, however. Just that general-purpose computers as we know them will cease to exist. Hello, trusted computing.
Forgiven.
I use Nagios myself as I was looking for a quick and dirty replacement for Big Brother.
While it's a fantastic tool, my biggest beef with it by a LONG way is that configuring a new server to monitor is always a case of "hand-edit this config file and that, figure out what's important to monitor and what isn't, realise 3 months later that you missed out something you really should be monitoring...." aarrgh. Templates help hugely but they're only part of the solution.
If you're going to make monitoring easy with a pretty-pretty web-based user interface, then why on Earth can't what the monitor itself does be configured through the same web-based interface?
Right now I'm using ZenOSS (http://www.zenoss.com/) which solves that particular problem very neatly - and unlike Nagios, has very good SNMP support. But it's not as easy to hack as Nagios, mainly because it doesn't have such a strong community surrounding it so punching "zenoss monitor (insert obscure thing here)" into Google doesn't work so well.
Ah, for something with the out-of-the-box functionality (and "out of the box" means "out of the box", not "out of the box provided you spend another 2 hours setting up a bunch of config files to support it") and ease of use of ZenOSS, but the hackability and community of Nagios. Never gonna happen.
Replying to myself here, but hey...
I realise my suggestion breaks the idea of the blacklist being "write once". But if it's only writeable from a hidden area, I don't see that as being an issue.
Not really. It's a bit of an arms race, and my idea is only a theory anyhow.
Were you to spam the blacklist, the obvious thing to do after that is to fix it so the oldest entries in the blacklist are automatically overwritten every time a new HD-DVD is inserted. Unless you're constantly spamming it, you'll never quite know what you can and can't decode. Perhaps if the blacklist could only be populated by a hidden area of the disk which isn't writeably in commercially-bought HD-DVD-R's.... but then doubtless someone else would come up with some other fix for that.
Doesn't matter in the slightest what the cause is. Most country's consumer law is worried about the effect.
/. , but for grandma taking her DVD player back, it matters not.
In this case, the effect is "My DVD player doesn't work any more and it's still in warranty".
The solution is to repair/replace it. What exactly the problem is may be interesting to those on
If "Compromise the same way" means instructions which involve taking the cover off, soldering a line onto a JTAG port and running a serial port to it, I really don't think that kind of compromise is going to be used by many people.
I don't see how flashing my HD-DVD drive firmware because its key got revoked is any less onerous than downloading the latest crack from a random P2P network.
There's lots of things the manufacturer can do to hard/firmware to make it substantially harder for you than can be done in software.
Off the top of my head:
- Firmware can be rewritten maximum of 5 times, but keys can be rewritten as many times as you like. Doesn't solve the issue of keys getting cracked, so...
- Future revisions could allow for a pool of blacklisted keys. Any key in the blacklist will be ignored, regardless of whether or not it's in the list of acceptable keys. Every entry in the blacklist is write-once. Sure, you'll only be able to store a limited number of keys in this blacklist, but you don't need to store an unlimited number - just enough to be inconvenient.
how about not using horribly intrusive ads? They don't work except maybe with the moron element.
Explain spyware, then.
This has to be the first time in history a link to goatse could reasonably be modded +5 Informative. It won't, of course - it'll be modded -5, Troll.
But since you ask:
http://www.goatse.cz/
You're commenting on something which it sounds like you might actually be qualified to comment on! What are you doing on /. ?
I know the whole point of DNS is that it's hierarchical. But with all these suggestions like ".safe for financial institutions, .xxx for porn" combined with countries with "desirable" ccTLDs selling domains (Don't get me wrong, it's their domain space and they can do what they wish. But I never knew so many English-language television companies were based out of Tuvalu), there seems little point in having a TLD-based hierarchy at all.
You may as well allow any organisation to register anything as a TLD. TBH, I think the only reason that hasn't been allowed is because the domain typo-squatting problem would be even sillier than it is today, placing a much higher level of stress on the top-level DNS servers.
The last 1.0 product MS had/has is the Zune. Prior to that was the XBox.
Everything else is up to at least version 5. If they haven't got the stuff that's at version 5 working sweetly, they probably never will.
It's certainly not as crisp as High Def content. It's better than standard def content. It's on par with DVD.
So essentially, Apple sells DVD-quality content and when played back on a high-def TV through Apple TV it looks like DVD-quality.
No kidding. Y'know, water is wet.