Any details? How's MegaRAID broken? I've got a few production MegaRAID boxes, but no test boxes (right now). Have you tried building MegaRAID directly into the kernel?
Isn't this like what gangs charge in "their" neighborhoods? Protection money? If we give them $5k a year, they'll give us their information. Otherwise, we're screwed, and they'll decide whether or not they wish to come forward. And, as we've seen in the past, they will only come forward if there is some benefit to them.
This quote is really the best part of the article. Does anyone -not- see the hypocrisy?
"We have to put down our differences and our competitiveness and share more if we're going to prosper together," Mr. Copeland said. "If you're going to wall yourself off and not share, then you're going to be hurting. This will be a venue and a forum where we can start to build a level of trust."
Um, aren't these companies going to wall themselves off and not share with the rest of us?
Oracle worked pretty much out of the box on our relatively stock Red Hat 6.2 boxes.
I only made one change. Add this to/etc/rc.d/rc.local:
# Increase system-wide file descriptor limit.
echo 8192 >/proc/sys/fs/file-max
echo 24576 >/proc/sys/fs/inode-max
Like several other people posted, you do not want a SAN. SAN requires a really high speed, low latency link. It's almost always a fiber setup.
What you're -really- looking for is a combination of technologies. You need fileservers at each of your locations to serve the local clients, then you want replication between the fileservers. You do not want to try and run NFS over a WAN. Especially not the distances you are talking about. The timeouts will drive you mad.
So, I reccomend NetApp. They're a finalist in our search for home directory storage, but we don't own any. However, I've read a lot. They have a technology that will keep multiple NetApps in sync over long distances. Go this route and you'll have high speed storage for your local clients while keeping the data in sync between your locations (they send block level deltas, if you care).
So, check NetApp. Read their white papers. This has already been solved. Don't reinvent the wheel.
Yeah, I noticed that. Seemed like a small amount of data, there.
I'm in the process of downloading the data from Shmoo's CCTF (from the Wiretapped site) and I plan to run it through snort for processing. I'll maybe run it through snort with some of the rules enabled. I haven't decided how much free time I have.
Check one of the current mirrors. There's one 514MB file and a 146MB file. Then several ~50MB files. Basicly, if you don't have a gig free, you probably can't handle it.
If you don't install the kernel-source package, you don't get the kernel-source. You do get the kernel-headers, though, if you want to do any development.
I really think the OpenSource argument is irrelevant, here. If you look at the list, Solaris is certified. Solaris was certified by Sun, who has the source. Most linux distributions do not install source on a system. Whoever installs the OS would simply not include the source.
So, an installed system does not have source on it that can be muddled with. Most of the main Linux vendors offer binary patches (eg, update RPMs from the vendors hat use RPM).
Hell, a lot of the military folks I spoke with were very excited about Linux, Open Source or not.
I tried to convice the company for which I used to work (General Dynamics) to go through this process. Unfortunately, they wouldn't go for it.
One of the issues is that you cannot get a DII/COE certification just for the sake of the certification. There must be a product or a contract vehicle that requires Linux. Your product may be a perfect fit.
One also must have sponsorship in the military. A company can't just go and ask for DII/COE compliance for a product without having a 'friend' go before the DII/COE folk.
The Linux distribution vendors are missing something here, though. The first company to get a particular product certified automaticaly becomes the sole source provider for that product. If anyone else wants to build a DII/COE compliant system, they must get the product from the vendor that did the DII/COE compliance. So, if Red Hat were to manage to get DII/COE compliance for thier distribution, anyone who wanted to build a DII/COE compliant system based on Linux would have to get the OS from Red Hat. This will be a bit different than the other commercial UNIXes, though. HP is the sole source for HP-UX. Red Hat would be the sole source for Red Hat Linux. There's nothing stopping SuSE for seeking compliance, but they'd be waaaaay behind Red Hat. Most likely, anyone building a DII/COE compliant Linux-based system would just use Red Hat.
So, if you've got the time and the understanding of DII/COE, you should go for it. Team up with your Distribution Vendor of choice and get them to foot some of the bill. You've already got the contract vehicle and (I assume) the military 'friend'. You just need the support of one of th e Linux distribution vendors (note, however, if -you- get Red Hat Linux certified, -you- become the sole source provider of Red Hat linux).
DII/COE certification has nothing to do with POSIX. NT got there because it some company (most likely Microsoft with a partnership with another gummit contractor) was willing to put in the work, and they got a sponsor within the military.
Since NT is not UNIX and compatibility is not expected, POSIX is irrelevant.
Honestly? No. But I'm pretty sure that while it could scale, that the performance isn't there. We're also looking at table segmentation, parallel servers, and all sorts of other crap (that's over my head -- I'm a sysadmin, not a DBA (thank god)).
Unfortunately, it's too late anyways. A lot of Oracle specific code has been written.
What's even better is Oracle's trained monkies (in general) suck. We've gotten terrible support from them, often being told two completly different answers for the same question. If MySQL could handle the load and had some of the features we need, we wouldn't be paying Oracle one red cent.
Um, am I the only one who read it as saying that one of the servers wouldn't boot at all? Does this really have anything to do with Mandrake? Even -if- that was due to them installing Mandrake, why in the hell did VA ship a box with parts missing?
Well, we're gonna buy Dells (I'd actually decided this some time ago, because the VA boxes only have one power supply). I'm pretty sure we'll get better support than the poster mentioned.
Has anyone hosted with Sprint? We're talking with them and the have, well, a nice network. The have tons of peering arrangements and massive bandwidth. Provisioning new bandwidth is simply not a problem, as near as I can tell.
Basically, for us, it's between Exodus and Sprint. I've seen several pluses and minues for/against Exodus, but noone has mentioned Sprint.
I wasn't really going to post on this thread, but your message reminded me of The Deception Toolkit available at http://all.net/dtk/.
The Deception Toolkit is a tool for building honeypots, but with a twist. It listens at port 365 and just says something like "Smile, you're on candid camera". The idea being, that if enough DTK boxes are out there, if someone sees a port open at 365 they will aim their scripts elsewhere.
None of the LUGs in the Raleigh area had anything to do with last year's expo. Nor have any of them been involved in the descision to not have Linux Expo 2000.
That said, TriLUG (I use TriLUG because that's the one I'm a member of and I know what they're working on) is working on having some sort of large Linux related event this year. We're working with the other LUGs in the area, as well as other LUGs in the state. We -are- trying to do something with a lot less corporate shine to it. Hopefully, it'll be more for the people, rather than last year's event which was more for the companies.
So, don't worry. A large Linux related event is being planned for North Carolina. We'll post more details when we know them.
That said, I'm not sure why this kernel even made it to release. I know the kernel developers are busy, but they must be using some whacked settings if they could get that kernel to compile out of the box.
Yes, a photo was posted of his sister. A yearbook photo, as a matter of fact, pulled from the website which hosts her yearbook. -That- site was officially sanctioned.
No, it was not posted in order to get her harrassed. I don't know why it was posted, but it wasn't for that reason.
Also, it should be noted that the/jp directory was simply a mirror of other sites JP had threatened due to their content.
Snort can be used to do network intrusion detection. Combine Snort with this ruleset and you have intrusion detection -way- beyond most anything out there.
Of course, if you're just looking for whether or not someone is probing your host, the aforementioned PortSentry will do quite nicely.
Slashdot Mirror
Privoxy: http://www.privoxy.org/
Any details? How's MegaRAID broken? I've got a few production MegaRAID boxes, but no test boxes (right now). Have you tried building MegaRAID directly into the kernel?
Isn't this like what gangs charge in "their" neighborhoods? Protection money? If we give them $5k a year, they'll give us their information. Otherwise, we're screwed, and they'll decide whether or not they wish to come forward. And, as we've seen in the past, they will only come forward if there is some benefit to them.
This quote is really the best part of the article. Does anyone -not- see the hypocrisy?
"We have to put down our differences and our competitiveness and share more if we're going to prosper together," Mr. Copeland said. "If you're going to wall yourself off and not share, then you're going to be hurting. This will be a venue and a forum where we can start to build a level of trust."
Um, aren't these companies going to wall themselves off and not share with the rest of us?
Oracle worked pretty much out of the box on our relatively stock Red Hat 6.2 boxes.
/etc/rc.d/rc.local:
/proc/sys/fs/file-max
/proc/sys/fs/inode-max
I only made one change. Add this to
# Increase system-wide file descriptor limit.
echo 8192 >
echo 24576 >
All you've said is that you're looking at SANs and NAS devices. But what's it going to be used for? This is important.
As for HA, it's rather common these days. NetApp does seem to have a good solution.
And why not EMC? Cost? They've got lower end stuff: http://www.emc.com/products/systems/clariion.jsp. We've got two Clariion's coming next week. They'll be point to point SAN, though.
You might look at the IP4700 as a NAS device. I prefer their HA solution.
In the end, I've been looking at this exact thing for about four months now. Got any questions? Ask. I've spent a lot of time with bot EMC and NetApp.
Like several other people posted, you do not want a SAN. SAN requires a really high speed, low latency link. It's almost always a fiber setup.
What you're -really- looking for is a combination of technologies. You need fileservers at each of your locations to serve the local clients, then you want replication between the fileservers. You do not want to try and run NFS over a WAN. Especially not the distances you are talking about. The timeouts will drive you mad.
So, I reccomend NetApp. They're a finalist in our search for home directory storage, but we don't own any. However, I've read a lot. They have a technology that will keep multiple NetApps in sync over long distances. Go this route and you'll have high speed storage for your local clients while keeping the data in sync between your locations (they send block level deltas, if you care).
So, check NetApp. Read their white papers. This has already been solved. Don't reinvent the wheel.
Yeah, I noticed that. Seemed like a small amount of data, there.
I'm in the process of downloading the data from Shmoo's CCTF (from the Wiretapped site) and I plan to run it through snort for processing. I'll maybe run it through snort with some of the rules enabled. I haven't decided how much free time I have.
Just take a look at http://www.shmoo.com/cctf/data/ to see how large the files are.
Red Hat Linux.
If you don't install the kernel-source package, you don't get the kernel-source. You do get the kernel-headers, though, if you want to do any development.
headers != source
Okay.
Since NT is not UNIX-like and compatibility with UNIX-like operating systems is not expected, POSIX is irrelevant.
Better?
I really think the OpenSource argument is irrelevant, here. If you look at the list, Solaris is certified. Solaris was certified by Sun, who has the source. Most linux distributions do not install source on a system. Whoever installs the OS would simply not include the source.
So, an installed system does not have source on it that can be muddled with. Most of the main Linux vendors offer binary patches (eg, update RPMs from the vendors hat use RPM).
Hell, a lot of the military folks I spoke with were very excited about Linux, Open Source or not.
I tried to convice the company for which I used to work (General Dynamics) to go through this process. Unfortunately, they wouldn't go for it.
One of the issues is that you cannot get a DII/COE certification just for the sake of the certification. There must be a product or a contract vehicle that requires Linux. Your product may be a perfect fit.
One also must have sponsorship in the military. A company can't just go and ask for DII/COE compliance for a product without having a 'friend' go before the DII/COE folk.
The Linux distribution vendors are missing something here, though. The first company to get a particular product certified automaticaly becomes the sole source provider for that product. If anyone else wants to build a DII/COE compliant system, they must get the product from the vendor that did the DII/COE compliance. So, if Red Hat were to manage to get DII/COE compliance for thier distribution, anyone who wanted to build a DII/COE compliant system based on Linux would have to get the OS from Red Hat. This will be a bit different than the other commercial UNIXes, though. HP is the sole source for HP-UX. Red Hat would be the sole source for Red Hat Linux. There's nothing stopping SuSE for seeking compliance, but they'd be waaaaay behind Red Hat. Most likely, anyone building a DII/COE compliant Linux-based system would just use Red Hat.
So, if you've got the time and the understanding of DII/COE, you should go for it. Team up with your Distribution Vendor of choice and get them to foot some of the bill. You've already got the contract vehicle and (I assume) the military 'friend'. You just need the support of one of th e Linux distribution vendors (note, however, if -you- get Red Hat Linux certified, -you- become the sole source provider of Red Hat linux).
DII/COE certification has nothing to do with POSIX. NT got there because it some company (most likely Microsoft with a partnership with another gummit contractor) was willing to put in the work, and they got a sponsor within the military.
Since NT is not UNIX and compatibility is not expected, POSIX is irrelevant.
Honestly? No. But I'm pretty sure that while it could scale, that the performance isn't there. We're also looking at table segmentation, parallel servers, and all sorts of other crap (that's over my head -- I'm a sysadmin, not a DBA (thank god)).
Unfortunately, it's too late anyways. A lot of Oracle specific code has been written.
What's even better is Oracle's trained monkies (in general) suck. We've gotten terrible support from them, often being told two completly different answers for the same question. If MySQL could handle the load and had some of the features we need, we wouldn't be paying Oracle one red cent.
Um, am I the only one who read it as saying that one of the servers wouldn't boot at all? Does this really have anything to do with Mandrake? Even -if- that was due to them installing Mandrake, why in the hell did VA ship a box with parts missing?
Well, we're gonna buy Dells (I'd actually decided this some time ago, because the VA boxes only have one power supply). I'm pretty sure we'll get better support than the poster mentioned.
And just remember, there's a four year contract with the Alexis Park. Woo. Two more years of teeny tiny conference rooms.
Um, note that that article was about DefCon 5. This year was DefCon 8. Plus, the Aladdin was closed during the con this year.
Has anyone hosted with Sprint? We're talking with them and the have, well, a nice network. The have tons of peering arrangements and massive bandwidth. Provisioning new bandwidth is simply not a problem, as near as I can tell.
Basically, for us, it's between Exodus and Sprint. I've seen several pluses and minues for/against Exodus, but noone has mentioned Sprint.
The Deception Toolkit is a tool for building honeypots, but with a twist. It listens at port 365 and just says something like "Smile, you're on candid camera". The idea being, that if enough DTK boxes are out there, if someone sees a port open at 365 they will aim their scripts elsewhere.
Ain't decoy's grand?
None of the LUGs in the Raleigh area had anything to do with last year's expo. Nor have any of them been involved in the descision to not have Linux Expo 2000.
That said, TriLUG (I use TriLUG because that's the one I'm a member of and I know what they're working on) is working on having some sort of large Linux related event this year. We're working with the other LUGs in the area, as well as other LUGs in the state. We -are- trying to do something with a lot less corporate shine to it. Hopefully, it'll be more for the people, rather than last year's event which was more for the companies.
So, don't worry. A large Linux related event is being planned for North Carolina. We'll post more details when we know them.
Yes, several fixes have been posted in this very thread.
Read here
That said, I'm not sure why this kernel even made it to release. I know the kernel developers are busy, but they must be using some whacked settings if they could get that kernel to compile out of the box.
Also, it seems 2.3.47pre3 is already up.
http://www.kernel.org
Just edit drivers/block/ll_rw_blk.c, and change line 237.
back_merges_fn should read back_merge_fn (IE, remove the 's')
This has been posted to linux-kernel as the fix, and it works for me.
Yes and no.
/jp directory was simply a mirror of other sites JP had threatened due to their content.
Yes, a photo was posted of his sister. A yearbook photo, as a matter of fact, pulled from the website which hosts her yearbook. -That- site was officially sanctioned.
No, it was not posted in order to get her harrassed. I don't know why it was posted, but it wasn't for that reason.
Also, it should be noted that the
Snort can be used to do network intrusion detection. Combine Snort with this ruleset and you have intrusion detection -way- beyond most anything out there.
Of course, if you're just looking for whether or not someone is probing your host, the aforementioned PortSentry will do quite nicely.