And you know, to qualify that... there is definitely a level of enterprise monitoring way above and beyond what nagios provides as well. It's far from the final solution for monitoring.. it's all a matter of scale.
If all you want is a tool to ping a few servers, nagios is overkill.
My gut reaction is that if nagios configs seem too complicated, you likely have never had to roll out real enterprise monitoring.
Our Nagios install monitors thousands of things, many of them custom tests. (Transaction volumes, application response times, cron job status, files....).. it can be made to to be the focal point for all the "stuff" the people responsible for monitoring company IT operations need to know about.
Plenty of people will say "without authentication, encryption is useless". This is not true.
"Without authentication - encryption cannot protect your sensitive data" - this IS true.
With non-authenticated encryption - anyone can middle you. Easily. you won't notice.
The benefit is a large scale one, and has to do with numbers and methods. The government could possibly muster enough resources to MITM the whole internet... but doing so would be detectable, provable, and very differnet legally than just taking a passive copy of the bits on the wire, as they do now.
This method of using crypto won't prevent a focused attacker from getting at your bits... and by focused, I don't mean sophisticated.. just someone who's taking a moment to look at you, or the network you are on, rather than a massive amount of data and users at once.
What it will do is change the playing field, and Change the methods an ISP or other person must use to sniff our data and snoop on our bits... change it in a way that's beneficial for the end user.
Seems this isnt' really about tsunamis.. I think in deep-ocean like this, a tsunami is spread out, wide, and fast. It's a patch of ocean a foot higher than the rest, moving really, really fast. And harmless.
This seems more about protecting against freak waves and other large detructive waves...
An important question in all this is to ask WHY a lender would create such a high-risk situation. IN the olden-days, that didn't happen so much, becuase it was bad for the lender. I'm sure neither you nor I would lend someone money unless the risk was worth the benefit.
The loans were securitized and sold off.. and that's the problem - at some point the inherent risk in the securities was overlooked, and they somehow became rock-solid. Lenders would lend as much as they could legally get away with, so they could quickly sell it off.
Well, actually.. yeah it does. Most of what is so visible in diesel exhaust are fine particles that settle out into the ground instead of hovering around.
1) As others said, learn and make good use of virtualization. It gives you great flexibility, and it's the future (and the future is now...)
2) Metrics are everything. You *need* to gather performance data, as much as possible. Run cacti, run nagios, and set up tests for all the metrics you can reasonably get.. at a minimum interface bandwidth, load average, # procs, memory statistics, and disk usage. Learn to use sar. Make your first server your admin server that monitors everything else for you. You can't judge the effects of your optimizations without metrics.
3) Install. Harden. Document.
- install the OS, update it, then disable every service you don't need. Then document this, so you can repeat it the next time. (and if you are virtualizing, grab a copy of the VM at this stage so you can clone it later) Continue to keep good documents about the systems you engineer. Use a wiki.
4) Make sure you can do everything from the command line. Understand what uses what socket, what uses what port, and how the pieces communicate. Understand PHP error reporting, logging, apache virtual hosts, etc.
5) Use version control on your configuration files... lots of ways to do this, find something that works for you. It's hard to optimize if you don't have a record of your changes.
Re:I don't know if I fully agree with that
on
Fire Your IT Boss
·
· Score: 1
Of course I meant "away" not "aware"
Re:I don't know if I fully agree with that
on
Fire Your IT Boss
·
· Score: 1
The nice part about what you said is the response you didn't get:
"It's not acceptable that you are aware and the team can't function. You are there to lead, not to be a roadblock to getting work done. You obviously aren't doing a very good job."
It's not that surprising.. those were the required skills you needed from that era. People without those skills didn't work in the field. There were also far, far fewer people in that line of work - there wasn't an "IT" industry as it is today.
Fundamentally the reliability problem is not a language problem, it's an engineering problem. you can write perfect software, hardware can still fail. Switches can fail. Power can fail. Climate control can fail. Natural disasters can occurr.
Just about any language can produce superb code if those writing it have a really solid understanding of the system they are coding for.
Java can be fantastic if you understand how to optimize for the JVM. So much java software seems crappy because it's textbook.. in theory the code is okay, but not much thought has gone into how that code actually uses system resources.
C can be wonderful, if you understand how to leverage the OS and libraries underneath it in an optimal way.
Nowadays, we can just throw a low-cost cluster at something to achieve the same reliability as we would get with insanely long and detailed code audits - and it's faster and cheaper.
The root of the problem is you have very skilled technical people trying to deal with business... a proper IT manager can and would sell the proper solution to the higher-ups.
I've always wondered - it is always stated that the Gov. Gen. is only a ceremonial role, and although required by law, he or she always does what they are asked.
I've always wondered - if, for instance, her signature is required to sign any new bill into law, and she is not legally obligated to sign it.. could she not simply refuse?
The other point of view is that you produce work in line with copyright law.. the economics of being a writer are strongly rooted there. If copyright were, say, only 10 years, and then automatic public domain, perhaps books would be more expensive, perhaps writers would write more often... perhaps quality would even suffer.
The issue at hand is that copyright terms have been extended and extended and extended, and in the confusion created by our new-found ability to replicate information globally and instantly, knee-jerk reactions are creating bad laws that further restrict things beyond the intent of copyright law.
Works are not created in a vacuum - human knowledge in general is built upon generation by generation. Your works at some point could become the foundation of future works.
To exaggerate a bit - we could end up in a situation where no more works are created, because everyone for the last 200 years owes royalties to everyone who can conceivably claim that your work is somehow derived from their work.
If you became really popular, and your old works were in public domain - not only could the studios exploit your work, but ANYONE, including you, could exploit your work.
Slashdot Mirror
And you know, to qualify that... there is definitely a level of enterprise monitoring way above and beyond what nagios provides as well. It's far from the final solution for monitoring.. it's all a matter of scale.
A big install would use both.. as they are very different tools.
Nagios is a monitoring & alert framework.
Cacti is a graphing framework...
Does cacti have some ability to do problem detection, notification, escalation, acknowledgement, resolution, and trend reporting?
If all you want is a tool to ping a few servers, nagios is overkill.
My gut reaction is that if nagios configs seem too complicated, you likely have never had to roll out real enterprise monitoring.
Our Nagios install monitors thousands of things, many of them custom tests.
(Transaction volumes, application response times, cron job status, files....).. it can be made to to be the focal point for all the "stuff" the people responsible for monitoring company IT operations need to know about.
It's due to the design of SSL - not apache.
In order for the request to be encrypted, certificate exchange & validation has to take place.
In order to vaildate a certificate, domains must match what's in the certificate.
IN order for apache to do name-based virtual hosting, it has to look at the request headers.
Request headers cannot be sent until after certificate validation has taken place.
Therefore you can only host one site without running into certificate mismatch problems.
It's a great idea.
Plenty of people will say "without authentication, encryption is useless". This is not true.
"Without authentication - encryption cannot protect your sensitive data" - this IS true.
With non-authenticated encryption - anyone can middle you. Easily. you won't notice.
The benefit is a large scale one, and has to do with numbers and methods. The government could possibly muster enough resources to MITM the whole internet... but doing so would be detectable, provable, and very differnet legally than just taking a passive copy of the bits on the wire, as they do now.
This method of using crypto won't prevent a focused attacker from getting at your bits... and by focused, I don't mean sophisticated.. just someone who's taking a moment to look at you, or the network you are on, rather than a massive amount of data and users at once.
What it will do is change the playing field, and Change the methods an ISP or other person must use to sniff our data and snoop on our bits... change it in a way that's beneficial for the end user.
That's an important change.
Seems this isnt' really about tsunamis.. I think in deep-ocean like this, a tsunami is spread out, wide, and fast. It's a patch of ocean a foot higher than the rest, moving really, really fast. And harmless.
This seems more about protecting against freak waves and other large detructive waves...
I find Cunt worse.... dunno why.
Crazy idea here - why not just run your own?
Ultimately that's subjective...
I, for one, find it quite clearly a level more offensive then the words you mention.
Based on nothing, of course.
Couldn't agree more with you.
An important question in all this is to ask WHY a lender would create such a high-risk situation. IN the olden-days, that didn't happen so much, becuase it was bad for the lender. I'm sure neither you nor I would lend someone money unless the risk was worth the benefit.
The loans were securitized and sold off.. and that's the problem - at some point the inherent risk in the securities was overlooked, and they somehow became rock-solid. Lenders would lend as much as they could legally get away with, so they could quickly sell it off.
Nobody said it was some law of physics.. jeeze.
My buddy's camaro has twice the horsepower and torque of your little mazda... what does that prove?
Let's re-phrase:
In general, diesel vehicles are built to be torquier at lower RPMs.
Technical people often get overinflated egos about their importance to the overall business.
Non-technical people tend to treat technical people like dirt.
Well, actually.. yeah it does.
Most of what is so visible in diesel exhaust are fine particles that settle out into the ground instead of hovering around.
I think what he means is that diesels tend to have more torque at low RPMs.
Reminds me of the old slashdot....
1) As others said, learn and make good use of virtualization. It gives you great flexibility, and it's the future (and the future is now...)
2) Metrics are everything. You *need* to gather performance data, as much as possible. Run cacti, run nagios, and set up tests for all the metrics you can reasonably get.. at a minimum interface bandwidth, load average, # procs, memory statistics, and disk usage. Learn to use sar. Make your first server your admin server that monitors everything else for you. You can't judge the effects of your optimizations without metrics.
3) Install. Harden. Document.
- install the OS, update it, then disable every service you don't need. Then document this, so you can repeat it the next time. (and if you are virtualizing, grab a copy of the VM at this stage so you can clone it later) Continue to keep good documents about the systems you engineer. Use a wiki.
4) Make sure you can do everything from the command line. Understand what uses what socket, what uses what port, and how the pieces communicate. Understand PHP error reporting, logging, apache virtual hosts, etc.
5) Use version control on your configuration files... lots of ways to do this, find something that works for you. It's hard to optimize if you don't have a record of your changes.
Of course I meant "away" not "aware"
The nice part about what you said is the response you didn't get:
"It's not acceptable that you are aware and the team can't function. You are there to lead, not to be a roadblock to getting work done. You obviously aren't doing a very good job."
Do all those whining about this anonymize their own server logs? Because I sure don't.... they are doing this to keep the mob away, that's it.
It's not that surprising.. those were the required skills you needed from that era. People without those skills didn't work in the field.
There were also far, far fewer people in that line of work - there wasn't an "IT" industry as it is today.
Fundamentally the reliability problem is not a language problem, it's an engineering problem. you can write perfect software, hardware can still fail. Switches can fail. Power can fail. Climate control can fail. Natural disasters can occurr.
Just about any language can produce superb code if those writing it have a really solid understanding of the system they are coding for.
Java can be fantastic if you understand how to optimize for the JVM. So much java software seems crappy because it's textbook.. in theory the code is okay, but not much thought has gone into how that code actually uses system resources.
C can be wonderful, if you understand how to leverage the OS and libraries underneath it in an optimal way.
Nowadays, we can just throw a low-cost cluster at something to achieve the same reliability as we would get with insanely long and detailed code audits - and it's faster and cheaper.
Yes, that happens a lot.
The root of the problem is you have very skilled technical people trying to deal with business... a proper IT manager can and would sell the proper solution to the higher-ups.
I've always wondered - it is always stated that the Gov. Gen. is only a ceremonial role, and although required by law, he or she always does what they are asked.
I've always wondered - if, for instance, her signature is required to sign any new bill into law, and she is not legally obligated to sign it.. could she not simply refuse?
The other point of view is that you produce work in line with copyright law.. the economics of being a writer are strongly rooted there. If copyright were, say, only 10 years, and then automatic public domain, perhaps books would be more expensive, perhaps writers would write more often... perhaps quality would even suffer.
The issue at hand is that copyright terms have been extended and extended and extended, and in the confusion created by our new-found ability to replicate information globally and instantly, knee-jerk reactions are creating bad laws that further restrict things beyond the intent of copyright law.
Works are not created in a vacuum - human knowledge in general is built upon generation by generation. Your works at some point could become the foundation of future works.
To exaggerate a bit - we could end up in a situation where no more works are created, because everyone for the last 200 years owes royalties to everyone who can conceivably claim that your work is somehow derived from their work.
If you became really popular, and your old works were in public domain - not only could the studios exploit your work, but ANYONE, including you, could exploit your work.
The industry will adjust.
In what way were these bills attached to the DMCA-like bill?
You are an AT&T customer.
Google is a network-X customer.
AT&T has a peering agreement with network-X
AT&T is now saying "we think Google should pay us, too, even though we already have a peering agreement."
Fundamentally it's all about trade - you peer when both parties feel there is equal value in doing so.. nothing else.
As soon as one side can say "You need us, we don't need you"... one becomes a customer.