"First, I didn't intend to convey speed by sequence"
Lets see...
"--- very fast devices at both ends. This generally means RAID 0, 5, 6 or some combination thereof like 50 or 60.
Raid 10 is more for redundancy in case a disk dies than performance"
Nope, no speed by sequence there.
"Second, RAID 5 with 8 disks is certainly faster than RAID 0 or RAID 10 with less than 6 equivalent disks"
If this is true of your setup, then there is something deeply wrong with your controller setup. Either you have a controller with a fast cpu and lots of cache + really really poor disks, or it doesn't really do raid 10.
"I have owned about 8 different types, although none from the last 2-3 years - ie, IDE/SATA)"
Ok, now I'm getting the picture, you are a Hobbyist. There's nothing wrong with that, but I design HA linux clusters, and have been testing and specing storage subsystems for 15 years. Don't try to teach your grandmother how to suck eggs.
"RAID 6 would require a minimum of 5 drives"
Sorry, its only 4
"As long as the controller can process faster than the I/O feed rate and your controller/array can handle the bandwidth, your system will never know the difference"
This statement isn't even wrong. Um... go back to school, or if my guess is right, start.
"RAID0 is the fastest, on a single channel"
only the truly desperate use more than on drive per channel in PATA
"This has to do with duplicating every write call vs just writing parity"
Um.. only raids 3 4 and "7" do the "just writing parity" to the other drive scenario Raid's 5 and 6 stripe the data and parity, with 6 striping 2 sets of parity. which is always going to write ~equally to the drives, and have more overhead than simple mirror and stripe, which is what raid 10 is.
Don't even get me started on disk recovery times. Raid 10 disk recovery beats raid 5/6 by several orders of magnitude. No other raid rebuilds with lower system impact than raid 10, without exotic hardware.
This works good, Make sure to boot Knoppix with DMA option, and be sure to specify "-1" to force protocol 1 with the scp. It has a lower overhead and will give you better speed. Better yet is to rsync over ssh -1. I use this often to "clean up" failed copys without starting over.
If the link is truly the constriction point, add a -C to the ssh options to inline compress/decompress. This is usually only a bonus when going over a wan. YMMV
Sorry, but you seem to have raid's 5 and 10 reversed in your post. Only raid 0 is faster than 10 (without proprietary equipment). Raid 5 is quite slow and 6 is even slower, especially for writing.
This line prints out a formatted columed right justified table of all the primes below 1000. The justification used to be perfect, but I had to scrap a few characters. orifinal sig was MUMPS F X=0:1:999 F D=2:1 S R=X#D Q:((X>2)&(R=0)!(((D>X/2)&(X'=1)))) I D>(X/2) W:$X>75 ! W ?($X+5-($l(X))),X Q which produces
I used to have a MUMPS tag in front, but the escaping of some of the char's pushed the length limit after one of the slashcode updates. sigh. It used to just fit.
This may burst your bubble, but my blind grandmother of 82 manages just fine with Linux. Her biggest gripe about windoz is that it's too hard to tell if it's crashed or just going really slow. It's harder to tell when you can't see the blue screen of the frozen mouse.
Her Linux machine doesn't crash, so it's easy to tell.
err, actualy he aquired the dog from a fellow scientist. Though he rebuilt him often (as he broke him). And there were several movies made, Some of them quite good. What you want to forget is the American thing.
They tried an American Red Dwarf too. It was stillborn, (and a Good Thing it died, I saw it, and it stank on ice)
With many RAID cards, You do need exactly the same kind of drive, Sometimes right down to the firmware revision.
With software RAID, your statement us true.
RAID 5 is barely sufficient for a home system, One common problem is that when one drive dies, and the system starts to failover to the hot spare, The extra load of reading all the data on all the surviving disks to generate the pairity, often causes a secondary drive failure.
Sometimes the cause of this is heat buildup during the rebuild. Rebuilds on sata drives in the 300G+ range can easily take upwards of 15 hours of constant thrashing.
With RAID 10, the rebuild is a remirror, and only afects one other drive. Also, the read/write is largely sequential, and with no parity. This adds up to a 30 minute rebuld instead of a 15 hour. You do loose space eficiency compared to RAID 5, but with space so cheap, The extra speed of the RAID 10 is ample compensation.
Be carefull with the -C, with compressed files, your just burning CPU, Also,
rsync -avz -rsh="ssh" * user@system:target
works especially well for pushing updates. For faster, lower security (protected internal network) you can add "-1" to the ssh i.e. rsync -avz -rsh="ssh -1" * user@system:target
I usualy alias rcp to rsync -avz -rsh="ssh" (mostly because of the alarm that seeing 'rcp" in the history gives to the other sysadmins)
With our inhouse expertise in LVS, I'm not likely to use any of the Foundry ServerIron gear, it's too hard to justify on the budget. I like getting new kit to play with though. Where would Foundry have a reasonable justification cost (over LVS). Where is it that the Foundry ServerIron is best suited?
What, an iSCSI implementation thats not junk? I'll believe it when I see it.
I really can't say too little about Vertitas. They have been costing me sleep since UnixWare 7.1.1. Why is it that the Beancounters are happy to fork over scads of money to Veritas? I've worked with some that actually require its use, Even where there is no benefit at all (even if it worked!). And don't even get me started about the Veritas backup.
I really have to look into NetApp. Service levels are critical to us and they sound outstanding.
I've never worked with Foundry ServerIron load balancers or NetApp (to do this), Unfortunatly our clusters are not the standard type workload usually found behind this type of gear. Cisco, Veritas and Piranha (RedHat LVS) all failed in work simulation testing. There were too many dropped conections and timeouts. The Cisco gear failed over ok, but had problems with failback and high load. Veritas was just a waste of money, and piranha/ipvsadm wasn't working together. Ultramonkey+Saru passed, but had issues with increased latency under high load when in straight NAT mode. Like I said, our RDC clusters are a long way from the run of the mill web farm. YMMV
With active passive, when you loose the active director, you loos the session mapping through it. With more complex things going on through LVS like telnet or remote instruments or ftp, or even some.asp, When you loose the LVS state, you loose the connection. Sure they can just reconnect, but when 400 techs & data entry people get bumped off, and 40 instruments in a lab have to be reset and reloaded, thats not an acceptable level of service. For continuous sessions, active-passive is a single point of failure. Additionaly, the active-active solution is scaleable, where active-passive isn't (for a single connection type anyway). With equal boxes, you get better performance and service with active-active. With Saru and UltraMonkey, configuration is something of a pain, but price/performance nothing I know can touch it.
Clustered NetApps.. Hmm I'v never really considered that. I guess I need to get some money in next quarters budget for "NAS research". There are a few niches here for lightweight storage with nothing really the right fit, and EMC wants an arm and a leg. Thanks for the idea.
My point about static content was that if his content is static, he can avoid having shared storage. No shared storage significantly reduces the price tag. The problem of using a NetApp or similar is the single point of failure. The cheapest possible way with shared storage would be a 2 box nfs server cluster with shared scsi. Finding hardware that is reliable for this can be problematic. LSI Logic MegaRAID (perc 3) is usable and not too expensive... I built one cluster that used AFS, but distributed file systems just don't cut it yet.
Saru is a package that allows active active load balancers (lvs linux directors). With active active, there is no single point of failure in the lvs, as the lvs directors load balance themselvs and share state. The really nice thing here is that in some cluster layouts, the LVS directors are the real servers. All the boxes load balance without the need of a dedicated lvs directors and with no bottleneck or single point of failure.
Cars are 99% efficient at burning the fuel because of the catalytic converters. Not all the fuel is effectivly burned in the combustion chamber. The highly dynamic changes in speed due to different rpm's make combustion eficiency very poor, Flame propigation speed is critical. Hydrogen burns very very hot, and extremely quickly. In some ways this mimics the plasma ignition systems that we couln't make work in the 70/80's. Inintial flame front propigation is significantly improved. There is an unmentioned side effect of extra "ping". In his device, this is partialy amiliorated by the fine water mist produced in the device (also not mentioned in the article). Adding water vapor to the air intake improves the heat to mechanical conversion. I have seen lots of posts "debunking" these methods, with plenty of decent chemistry behind the arguments, and I am dumbfounded by the lack of understanding of the basic concepts. I have been working with different technologies for improving the "gas to delta V" in autos for 25 years. Hydrogen addition, heated vapor carburators, ozone addition, plasma ignition, laser ignition, dynamic fuel variance, and a host of others. Almost all of them worked, but with real problems. Hydrogen addition has worked well for 50 years, but in the past has been just too dangerous. Using hydrolysis is not efficient, but it is safe. (no pressure, no H2 storage, no H2 present at startup/ shutdown) Heated fuel carburators (superheated exchange) are significantly more efficient than fuel injection systems, but are just too dangerous to use. (Fuel vapoization from injectors suck) In 85 I tripled the fuel milage of a 1.6L Subaru to over 110 mpg, while adding 15 hp on the dyno. (water vapor cooled intake with metered dry heated block gasoline vaporizer, with transducers at bottom of intake, HEI ignition) It worked great for 2 years, then one day an intake valve stuck open and it blew a 6 inch hole in the hood, trashing the entire system in the process.
I didn't mean to write a book, but reading the comments here were like listening to first graders arguing who is stronger, Jesus or Superman. Lots of logical arguments, totaly missing the point.
Five nines is dificult, even for simple services like web serving. For this guys' 30K budget, it will be very dificult. He will need at least 3 machines +NAS. Several whitebox machines would be fine, and even cheap, but the shared storage will not be cheap. IBM4200 fiber attached SATA or similar. Only if his web content is very static can he get by without an external raid. (all content on each server, rsync and a gang of servers)
I do clustering for db, and we shoot for "NO Nine's" (100%). Our apps are all medical and no outage is acceptable. Our best cluster is 100% after 493 days (three tier lvs/apps/db). The best box in that cluster is at 370 days. Honestly though we only average 99.997, but more than half the outage is from our leased lines service provider, not the clusters. Onsite avaiability is over five nines. Just on the off chance, do you use Saru?
Raid 5 was specified. That's what Raid 5 does. Rebuilding a drive in raid 5 is a long intensive process, as it has to rebuild the parity. Raid 5's often fail when a second near end of life drive dies while rebuilding a failed drive. The number one cause of this is heat buildup over time IMHO. Usually when a raid 5 looses 2 drives, it is actually the case that one drive failed, and there was no hot spare to take over, when the second drive fails (at some later date) the raid is broken. Anyone running a raid 5 with no hot spare is either an idiot or out of $$$.
I did it both to achive the goal of a good firewall, and to learn the nuts and bolts of linux.
Oh, and ipcop wouldn't exist for almost 2 years. and Richard had not even come up with a name for smothwall much less any working code.
This was in the days of the 2.0 kernel. Back in those days you could do routing and filtering in runlevel 0. It was fun (sort of) and it worked. Now I'm paid to design and configure Linux HA/HR clusters.
And the "net cop" can't figure out why all the slashdot trafic seems to come from his sniffer. (monkeys are funny)
My only claims were - It logged over 32,000 actual targeted hack attempts, literally millions of port scans and SMB scans. and no expoits or breaches in over 4 years - Which you seem to agree with.
"As securely as you locked the computer down, there's little way anyone could hack into that box."
as for "And I assume you uninstalled all SMB code" I never installed it.
"why the hell would the thing even *be* breakable from SMB scans"
It wouldn't, but they were common, so I mentioned them.
The ISP that was used did nothing to hamper, prevent, or log unfriendly activity, Thus it was a common area for script kiddy practice. Back when I still bothered, I got a few of their hands slapped, and one arrested.(not for what he tried to do to my machine, but because of the gov network he went through to get there)
and you wrote "Port scan != attack, btw."
I never claimed that port scans were attacks. I differentiated the attacks from the scans. Most attacks are pre-announced by scans. The attacks that I mention were Linux/unix targeted attacks. I don't even count windows/trojan attempts.
Perhaps it's just me, but when I build a firewall against the outside world, The "execesive paranoid lock-down of a machine" is necessary. This may be a personal flaw, but I get paid for it.
Perhaps you should look at your assumptions before you leap to them. If I annoyed you with my success, then I apologize. It seems that you did due dilligence in selecting obsd for a secure out of the box os. It's not your fault that there was an exploit for it that was used against you.
Linux can get the job done, but it's work. I took a slack 3.5 and set it up to do dhcp, ipmask, ipchins, and maintain a constant dial up. Then I set out to break everything else. no root to start. no logging to disk (out to serial port to a dos box running crosstalk mk4), booted from disk, mounted a cd for most of the system. no psudo-terms. no any util or lib not actully used. no login, no console (any change required the disk to be rebuilt from from a master copy. It took about 2 months of adjustment, but at the end of it all, it was rock solid. It logged over 32,000 actual targeted hack attempts, literally millions of port scans and SMB scans. and no expoits or breaches in over 4 years. Last year my dad finaly get broadband and the box was retired, unbroken. To date I have had no breach on any *nix box (inc BSD) since 1999.
I did this mostly as a learning experience, and can't recommend it to others, but Linux can be made secure. A good rule of thumb is that your firewall should be able to fit on a floppy, and run from read-only media. If not, you have un-neccessary baggage that is available to exploit. Presently I am playing with adamantix behind dedicated hardware.
Slashdot Mirror
"First, I didn't intend to convey speed by sequence"
Lets see...
"--- very fast devices at both ends. This generally means RAID 0, 5, 6 or some combination thereof like 50 or 60.
Raid 10 is more for redundancy in case a disk dies than performance"
Nope, no speed by sequence there.
"Second, RAID 5 with 8 disks is certainly faster than RAID 0 or RAID 10 with less than 6 equivalent disks"
If this is true of your setup, then there is something deeply wrong with your controller setup.
Either you have a controller with a fast cpu and lots of cache + really really poor disks, or it doesn't really do raid 10.
"I have owned about 8 different types, although none from the last 2-3 years - ie, IDE/SATA)"
Ok, now I'm getting the picture, you are a Hobbyist.
There's nothing wrong with that, but I design HA linux clusters, and have been testing and specing storage subsystems for 15 years.
Don't try to teach your grandmother how to suck eggs.
"RAID 6 would require a minimum of 5 drives"
Sorry, its only 4
"As long as the controller can process faster than the I/O feed rate and your controller/array can handle the bandwidth, your system will never know the difference"
This statement isn't even wrong. Um... go back to school, or if my guess is right, start.
"RAID0 is the fastest, on a single channel"
only the truly desperate use more than on drive per channel in PATA
"This has to do with duplicating every write call vs just writing parity"
Um.. only raids 3 4 and "7" do the "just writing parity" to the other drive scenario
Raid's 5 and 6 stripe the data and parity, with 6 striping 2 sets of parity. which is always going to write ~equally to the drives, and have more overhead than simple mirror and stripe, which is what raid 10 is.
Don't even get me started on disk recovery times. Raid 10 disk recovery beats raid 5/6 by several orders of magnitude. No other raid rebuilds with lower system impact than raid 10, without exotic hardware.
Make that -e "ssh -1" and you have a winner. Protocol 1 has lower overhead.
This works good, Make sure to boot Knoppix with DMA option, and be sure to specify "-1" to force protocol 1 with the scp. It has a lower overhead and will give you better speed. Better yet is to rsync over ssh -1. I use this often to "clean up" failed copys without starting over.
/files_here otherbox:/files_there
Something like
rsync -auv -e "ssh -1"
If the link is truly the constriction point, add a -C to the ssh options to inline compress/decompress. This is usually only a bonus when going over a wan.
YMMV
Sorry, but you seem to have raid's 5 and 10 reversed in your post.
u ltLevel01-c.html
n dex.htm
Only raid 0 is faster than 10 (without proprietary equipment). Raid 5 is quite slow and 6 is even slower, especially for writing.
http://www.pcguide.com/ref/hdd/perf/raid/levels/m
general RAID info (pictures)
http://www.acnc.com/04_00.html
http://www.pcguide.com/ref/hdd/perf/raid/levels/i
Mumps! One time ansi standard language.
This line prints out a formatted columed right justified table of all the primes below 1000.
The justification used to be perfect, but I had to scrap a few characters.
orifinal sig was
MUMPS F X=0:1:999 F D=2:1 S R=X#D Q:((X>2)&(R=0)!(((D>X/2)&(X'=1)))) I D>(X/2) W:$X>75 ! W ?($X+5-($l(X))),X Q
which produces
F X=0:1:999 F D=2:1 S R=X#D Q:((X>2)&(R=0)!(((D>X/2)&(X'=1)))) I D>(X/2) W:$X>75 ! W ?($X+5-($l(X))),X Q
1 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47
53 59 61 67 71 73 79 83 89 97 101 103 107 109 113 127
131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211
223 227 229 233 239 241 251 257 263 269 271 277 281 283 293 307
311 313 317 331 337 347 349 353 359 367 373 379 383 389 397 401
409 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499
503 509 521 523 541 547 557 563 569 571 577 587 593 599 601 607
613 617 619 631 641 643 647 653 659 661 673 677 683 691 701 709
719 727 733 739 743 751 757 761 769 773 787 797 809 811 821 823
827 829 839 853 857 859 863 877 881 883 887 907 911 919 929 937
941 947 953 967 971 977 983 991 997
I used to have a MUMPS tag in front, but the escaping of some of the char's pushed the length limit after one of the slashcode updates.
sigh. It used to just fit.
Possibly, but what do you sacrifice (other than $$$) ?
oh, and nice sig
This may burst your bubble, but my blind grandmother of 82 manages just fine with Linux.
Her biggest gripe about windoz is that it's too hard to tell if it's crashed or just going really slow.
It's harder to tell when you can't see the blue screen of the frozen mouse.
Her Linux machine doesn't crash, so it's easy to tell.
err, actualy he aquired the dog from a fellow scientist.
Though he rebuilt him often (as he broke him).
And there were several movies made, Some of them quite good.
What you want to forget is the American thing.
They tried an American Red Dwarf too.
It was stillborn, (and a Good Thing it died, I saw it, and it stank on ice)
But the DOCTOR gets my vote.
With many RAID cards, You do need exactly the same kind of drive,
Sometimes right down to the firmware revision.
With software RAID, your statement us true.
RAID 5 is barely sufficient for a home system,
One common problem is that when one drive dies, and the system
starts to failover to the hot spare, The extra load of reading all the data
on all the surviving disks to generate the pairity, often causes a secondary drive failure.
Sometimes the cause of this is heat buildup during the rebuild.
Rebuilds on sata drives in the 300G+ range can easily take upwards of 15 hours of constant thrashing.
With RAID 10, the rebuild is a remirror, and only afects one other drive. Also, the read/write is largely sequential, and with no parity. This adds up to a 30 minute rebuld instead of a 15 hour.
You do loose space eficiency compared to RAID 5, but with space so cheap, The extra speed of the RAID 10 is ample compensation.
Be carefull with the -C, with compressed files, your just burning CPU,
Also,
rsync -avz -rsh="ssh" * user@system:target
works especially well for pushing updates.
For faster, lower security (protected internal network)
you can add "-1" to the ssh
i.e. rsync -avz -rsh="ssh -1" * user@system:target
I usualy alias rcp to rsync -avz -rsh="ssh"
(mostly because of the alarm that seeing 'rcp" in the history gives to the other sysadmins)
With our inhouse expertise in LVS, I'm not likely to use any of the Foundry ServerIron gear, it's too hard to justify on the budget. I like getting new kit to play with though. Where would Foundry have a reasonable justification cost (over LVS). Where is it that the Foundry ServerIron is best suited?
What, an iSCSI implementation thats not junk? I'll believe it when I see it.
I really can't say too little about Vertitas. They have been costing me sleep since UnixWare 7.1.1.
Why is it that the Beancounters are happy to fork over scads of money to Veritas? I've worked with some that actually require its use, Even where there is no benefit at all (even if it worked!). And don't even get me started about the Veritas backup.
I really have to look into NetApp. Service levels are critical to us and they sound outstanding.
I've never worked with Foundry ServerIron load balancers or NetApp (to do this), Unfortunatly our clusters are not the standard type workload usually found behind this type of gear. Cisco, Veritas and Piranha (RedHat LVS) all failed in work simulation testing. There were too many dropped conections and timeouts. The Cisco gear failed over ok, but had problems with failback and high load. Veritas was just a waste of money, and piranha/ipvsadm wasn't working together. Ultramonkey+Saru passed, but had issues with increased latency under high load when in straight NAT mode. Like I said, our RDC clusters are a long way from the run of the mill web farm.
YMMV
With active passive, when you loose the active director, you loos the session mapping through it. With more complex things going on through LVS like telnet or remote instruments or ftp, or even some .asp, When you loose the LVS state, you loose the connection. Sure they can just reconnect, but when 400 techs & data entry people get bumped off, and 40 instruments in a lab have to be reset and reloaded, thats not an acceptable level of service. For continuous sessions, active-passive is a single point of failure. Additionaly, the active-active solution is scaleable, where active-passive isn't (for a single connection type anyway). With equal boxes, you get better performance and service with active-active. With Saru and UltraMonkey, configuration is something of a pain, but price/performance nothing I know can touch it.
Clustered NetApps.. Hmm I'v never really considered that. I guess I need to get some money in next quarters budget for "NAS research". There are a few niches here for lightweight storage with nothing really the right fit, and EMC wants an arm and a leg.
Thanks for the idea.
My point about static content was that if his content is static, he can avoid having shared storage. No shared storage significantly reduces the price tag. The problem of using a NetApp or similar is the single point of failure. The cheapest possible way with shared storage would be a 2 box nfs server cluster with shared scsi. Finding hardware that is reliable for this can be problematic. LSI Logic MegaRAID (perc 3) is usable and not too expensive... I built one cluster that used AFS, but distributed file systems just don't cut it yet.
c tive_active.shtml
Saru is a package that allows active active load balancers (lvs linux directors).
With active active, there is no single point of failure in the lvs, as the lvs directors load balance themselvs and share state.
The really nice thing here is that in some cluster layouts, the LVS directors are the real servers. All the boxes load balance without the need of a dedicated lvs directors and with no bottleneck or single point of failure.
http://www.ultramonkey.org/
http://www.ultramonkey.org/papers/active_active/
http://www.ultramonkey.org/papers/active_active/a
If you know of any other active-active LVS let me know.
Cars are 99% efficient at burning the fuel because of the catalytic converters. Not all the fuel is effectivly burned in the combustion chamber.
The highly dynamic changes in speed due to different rpm's make combustion eficiency very poor, Flame propigation speed is critical. Hydrogen burns very very hot, and extremely quickly. In some ways this mimics the plasma ignition systems that we couln't make work in the 70/80's. Inintial flame front propigation is significantly improved. There is an unmentioned side effect of extra "ping". In his device, this is partialy amiliorated by the fine water mist produced in the device (also not mentioned in the article). Adding water vapor to the air intake improves the heat to mechanical conversion.
I have seen lots of posts "debunking" these methods, with plenty of decent chemistry behind the arguments, and I am dumbfounded by the lack of understanding of the basic concepts.
I have been working with different technologies for improving the "gas to delta V" in autos for 25 years. Hydrogen addition, heated vapor carburators, ozone addition, plasma ignition, laser ignition, dynamic fuel variance, and a host of others. Almost all of them worked, but with real problems.
Hydrogen addition has worked well for 50 years, but in the past has been just too dangerous. Using hydrolysis is not efficient, but it is safe. (no pressure, no H2 storage, no H2 present at startup/ shutdown)
Heated fuel carburators (superheated exchange) are significantly more efficient than fuel injection systems, but are just too dangerous to use. (Fuel vapoization from injectors suck) In 85 I tripled the fuel milage of a 1.6L Subaru to over 110 mpg, while adding 15 hp on the dyno. (water vapor cooled intake with metered dry heated block gasoline vaporizer, with transducers at bottom of intake, HEI ignition) It worked great for 2 years, then one day an intake valve stuck open and it blew a 6 inch hole in the hood, trashing the entire system in the process.
I didn't mean to write a book, but reading the comments here were like listening to first graders arguing who is stronger, Jesus or Superman.
Lots of logical arguments, totaly missing the point.
Five nines is dificult, even for simple services like web serving. For this guys' 30K budget, it will be very dificult. He will need at least 3 machines +NAS. Several whitebox machines would be fine, and even cheap, but the shared storage will not be cheap. IBM4200 fiber attached SATA or similar. Only if his web content is very static can he get by without an external raid. (all content on each server, rsync and a gang of servers)
I do clustering for db, and we shoot for "NO Nine's" (100%). Our apps are all medical and no outage is acceptable. Our best cluster is 100% after 493 days (three tier lvs/apps/db). The best box in that cluster is at 370 days. Honestly though we only average 99.997, but more than half the outage is from our leased lines service provider, not the clusters. Onsite avaiability is over five nines.
Just on the off chance, do you use Saru?
You do realize that that is less than six minutes down time per year.
Raid 5 was specified.
i ngle_Level5.htm
u ltLevel01-c.html
That's what Raid 5 does.
Rebuilding a drive in raid 5 is a long intensive process, as it has to rebuild the parity.
Raid 5's often fail when a second near end of life drive dies while rebuilding a failed drive. The number one cause of this is heat buildup over time IMHO. Usually when a raid 5 looses 2 drives, it is actually the case that one drive failed, and there was no hot spare to take over, when the second drive fails (at some later date) the raid is broken. Anyone running a raid 5 with no hot spare is either an idiot or out of $$$.
http://www.pcguide.com/ref/hdd/perf/raid/levels/s
If you want more resiliance, go with multiple mirror raid1
Mirrors just duplicate the data exactly, which yields far quicker rebuilds.
Most people go raid 10 (Striping across mirror sets)
http://www.pcguide.com/ref/hdd/perf/raid/levels/m
Not that many, probably about the same as work less than 50 hr weeks.
I did it both to achive the goal of a good firewall, and to learn the nuts and bolts of linux.
Oh, and ipcop wouldn't exist for almost 2 years.
and Richard had not even come up with a name for smothwall much less any working code.
This was in the days of the 2.0 kernel. Back in those days you could do routing and filtering in runlevel 0.
It was fun (sort of) and it worked. Now I'm paid to design and configure Linux HA/HR clusters.
And the "net cop" can't figure out why all the slashdot trafic seems to come from his sniffer. (monkeys are funny)
Just to clear this up.
It was a learning exercise. (that worked well)
"A lot of your claims are just like... hogwash."
My only claims were
-
It logged over 32,000 actual targeted hack attempts, literally millions of port scans and SMB scans. and no expoits or breaches in over 4 years
-
Which you seem to agree with.
"As securely as you locked the computer down, there's little way anyone could hack into that box."
as for
"And I assume you uninstalled all SMB code"
I never installed it.
"why the hell would the thing even *be* breakable from SMB scans"
It wouldn't, but they were common, so I mentioned them.
The ISP that was used did nothing to hamper, prevent, or log unfriendly activity, Thus it was a common area for script kiddy practice. Back when I still bothered, I got a few of their hands slapped, and one arrested.(not for what he tried to do to my machine, but because of the gov network he went through to get there)
and you wrote
"Port scan != attack, btw."
I never claimed that port scans were attacks. I differentiated the attacks from the scans. Most attacks are pre-announced by scans. The attacks that I mention were Linux/unix targeted attacks. I don't even count windows/trojan attempts.
Perhaps it's just me, but when I build a firewall against the outside world, The "execesive paranoid lock-down of a machine" is necessary. This may be a personal flaw, but I get paid for it.
Perhaps you should look at your assumptions before you leap to them. If I annoyed you with my success, then I apologize.
It seems that you did due dilligence in selecting obsd for a secure out of the box os. It's not your fault that there was an exploit for it that was used against you.
Pardon me, but UltraMonkey
has been around for a Long
time. Horms
rocks!
Linux can get the job done, but it's work. I took a slack 3.5 and set it up to do dhcp, ipmask, ipchins, and maintain a constant dial up. Then I set out to break everything else. no root to start. no logging to disk (out to serial port to a dos box running crosstalk mk4), booted from disk, mounted a cd for most of the system. no psudo-terms. no any util or lib not actully used. no login, no console (any change required the disk to be rebuilt from from a master copy. It took about 2 months of adjustment, but at the end of it all, it was rock solid. It logged over 32,000 actual targeted hack attempts, literally millions of port scans and SMB scans. and no expoits or breaches in over 4 years. Last year my dad finaly get broadband and the box was retired, unbroken. To date I have had no breach on any *nix box (inc BSD) since 1999.
.
I did this mostly as a learning experience, and can't recommend it to others, but Linux can be made secure. A good rule of thumb is that your firewall should be able to fit on a floppy, and run from read-only media. If not, you have un-neccessary baggage that is available to exploit
Presently I am playing with adamantix behind dedicated hardware.
If you live in a shack, and are not on the municipal power grid, how much to you pay for the "haves" that use municipal power?
If your shack has no plumbing, how much do you pay for the "haves" with indoor toilets.
How these things are paid for and established would be a local affair, decided upon by elected officials.
You are one of the "haves" with a voter registration card, aren't you?
Some people just don't get it.
A comprimise "car" thats half-assed for the commute and half-assed for hauling "stuff" all adds up.
Did the SUV crowd buy the car that fits their needs,
or the seat that fits their ass?