James Newtons Massmind wrote: >Nate says: > > > >>You bring this up a lot, but it only serves to prove you >>didn't know what you were doing on Linux. If you'd have >>asked for help, people would have. I know that's not a nice >>thing to say, and I don't mean to evoke emotions from you on >>it, but your argument is illogical -- "Linux is bad because I >>don't know how to use it" doesn't fly. >> >> > >Bzzzzzzt! WRONG. Thanks for playing. I'm not upset about your statement, but >I beg to disagree. > > Cool! ;-) (Cool both that you're not mad and that you disagree! I learn things from people that disagree with me. I learn nothing from people that don't.) >I'll admit I didn't know what I was doing, but I had the books and I did >read them. > >AND: > >I DID ask for help. At one point I had 5 members of a local Linux club at my >house trying to get RedHat up and running (let alone secure) on a box that >IIS under NT had been running just fine on. Months later we discovered that >Linux wasn't clearing an ARP cache... Or some such thing.... Anyway. > > RedHat is crap but that comment is a whole different thread for a whole different crowd. Depending on where you jumped into RedHat on their timeline, there was a time when they were really really bad software (but popular). RedHat has always been one of the Linux's that traded useability for security and stability, IMHO. I avoid using RedHat on servers. I know that'll make someone grumpy but there are better options. This is kinda weird... An ARP cache wouldn't have anything to do with hardware... well, I understand... something confusing happened. This kinda stuff makes me wish I were closer -- I'd drive over, we'd have coffee and as my friend from Austrailia says "We'd have a play with it." Oh well... >The SECOND *nix box, Solaris/Sun was admined (remotely) by a PROFESSIONAL >*nix jockey (who herded a large group of *nix boxes for a major stock >broker) and he screwed up and it got hacked AS WELL. And it was even behind >a firewall. > > I've met lots of admins I wouldn't trust with servers running on the public side of the network that can admin hundreds of boxes on a relatively secure internal network. ;-) No offense meant to your friend, though. Running public servers is a speciality on both *nix and Windows. By the way, I have a friend at a "major financial organization" too, and the structure there is ridgid and very hard to teach people to change their ways. An example... they pay three people to do manual port-scans of their public systems, even though that activity screams for automation. Anyone that admins systems that touch money is going to be very good at NOT patching or doing anything "non-standard". ;-) Similar to my industry (telecommunications)... almost everyone's using Solaris 8 for core services, and there's almost no talk of upgrading to 9 or even 10... because "it works.. leave it alone". That mentality doesn't work in the public server arena, unfortunately. >>AND... I'd be in the same boat if I installed an IIS server >>today -- it'd be hacked. So if I had to do it, I wouldn't do >>it without help from someone who's done IIS for years. >> >> > >Nope, not if you just followed the easy, one, two, three steps for harding >an IIS server as specified by Microsoft. Installing URLScan and running IIS >Lockdown, etc... I've done a few other trick things of my own, that I had >time to think of and implement because I wasn't buried under trying to learn >how to compile an entire OS. > > Those "one two three" steps didn't exist when we used IIS. I watched one poor friend spend two nights straight coming up with a 35 page document on how to do it back then. ;-) This would have been early Win2K days. His document was awesome, but he had a two day deadline. Poor guy. >>To paraphrase Dennis Leary -- running machines on the >>Internet is hard. >>Get a helmet. >> >>Google, Amazon, and sites that take millions of hits a minute >>don't run on Windows boxes. Even Microsoft themselves >>struggled for two years to move HotMail from FreeBSD to >>Windows, and they've never published exactly how they pulled >>it off, that I've seen. People generally believe that the >>internal mail spools are still *nix-based, but hidden. >>It sure as hell isn't running on Exchange!!! >> >> > >The difference is those large companies can afford to hire a few *nix gurus >to take care of the large number of machines they run. If they had to pay >M$, it would cost them more. With M$ you pay for the software, with *nix you >pay for the people. > > Heh, I'm not so sure that is very true anymore. Prices for techies of all kinds are pretty depressed across the board. I also think you pay dearly for experts (true experts) on either side of that equation, but rarely do management have any good measuring sticks to find out who's an expert and who's faking it. >>Usually with IIS today it's not so much a problem of being >>hacked into, it's a server load issue. From the one location >>I have a DS3 available from I could probably overload IIS on >>that box and kill it, and probably pretty easily. But I >>don't do those sorts of things, as they're not worth the >>effort outside of a controlled lab environment. >> >>Apache on the same NT installation would probably fare >>better, and Apache on any *nix would simply shrug it off if >>there's not too much database activity from hitting the front page. >> >>Perhaps I'm reading too much into the warnings, but you have >>all sorts of warnings about "Don't Rip!" all over the site -- >>if it were tuned properly and running on a box that wouldn't >>die under the load of people "ripping" (isn't that what a >>webserver is SUPPOSED to do... serve up whatever data >>requested of it as fast as it can under varying loads and >>numbers of users?) -- you wouldn't need those at all. >> >> > >The RIPPING warnings are about BANDWIDTH not Server load. I get charged for >excessive bandwidth usage. Site rippers don't understand how big the site >is. (two full CDs at this point) > > Ahh ok! >>(Unless there's an outside economic force, like a bandwidth >>cap. You don't say in the warnings.) >> >> > >In the page the warning link to, that is explained. > > Missed it. Oops! >>Since I moved away from running Windows webservers in 1995 or >>so, I haven't kept up on the latest tools and techniques used >>by IIS and such. I am curious though -- how often do you >>need to reboot the server? We had some IIS/ASP stuff that >>memory-leaked badly and had to be rebooted weekly at a pretty >>busy site around 1999 (run by a different group of admins >>than my group... I handled the *nix side of things by myself >>with two part-time developers for Perl stuff, a group of ten >>developers and three admins handled the Windows stuff... we >>had similar loads and similar "work" to do - no one ever >>looked at the bottom line and realized that). It also >>regularly lost database connections and had to be manually >>bounced (the network was fine) until MS Transaction Server >>came out and was stable enough to use in production environments. >> >> > >I reboot the server automatically every night. So what? It takes less than a >minute. I've run it for long periods of time in the past, but I like being >safe. > > This I just don't understand. If it can't run forever (barring the need to reboot for kernel patches or shared libraries that are in use and can't be unloaded), it's broken. Trying to explain how this comment makes me fidget and fret, I'd say it'd be like someone posting that they put a reset button on every PIC device they build not for the times when things have truly gone wrong, but because they feel "safe" if they reset their lawn sprinkler system at least once a day, 'cause it's just going to crash anyway. Something's wrong with that code. The bummer is, with Windows you have zero chance of finding and fixing it. (You don't have the source.) >>Anyway this is morphing away from PIC stuff again (sorry -- >>I'm passionate about what I do for a living... I wish more >>people were in the server-admin "industry"!) but I am curious >>about the "Don't Rip" >>thing... ultimately I know you can say that if you simply >>want to and not have a techincal reason and I may be reading >>into that message too much. Is it because the server would >>keel over dead? 'Cause we can definitely fix that!!!! I >>know from our discussions that you are passionate about >>PICList!!! (Yay!) >> >> > >No, the only thing that does seem to slow the box down is the search engine. >When you consider how large a corpus it is searching, it shouldn't surprise >anyone that it burns some cycles. What does bother me and yes, it seems to >be a bug in IIS, is that if you get too many concurrent searches, the >machine gets locked up in some sort of infinite loop and never recovers. > > Sigh... search engines are a pain on any OS. No argument or disagreement there! ;-) Although the lockup part I don't get. It sounds generically like a file lock/resource-contention problem with a bad race condition coded into it. >>There's a number of super-easy fixes for that "rip" problem. >>(Mirror sites, for example... one machine ALLOWED to "rip" >>and then rsync mirrors to other places with high speed >>donated bandwidth... just as one >>example.) >> >> > >I'd love to do that, and I did have an offer from a guy at one point, but I >didn't get rsync setup... I should try again. > > I have access to a box on a 100Mb/s pipe that could be used (maybe) with permission from the appropriate folks. We could talk off-list about it if you're interested. You're probably as busy as I am and it hasn't bubbled to the surface of priorities... I know how that goes! >>By the way, that reminds me... Everyone DONATE to PICList!!! >>Keep James in bandwidth and toys!!! (GRIN) >> >> > >Thanks! If you don't have $$$ donate time by becoming a page editor, >adopting a page and editing it. See the links on the page bottom (below the >first HR) AFTER you log in. > > Always willing to say "DONATE DONATE DONATE" to anyone. Rarely works, but hey... I'll say it! :-) People like James who are willing to donate freely of their time/knowledge to provide EXCELLENT public resources like PICList are the best people out there! Speaking of excellent resources, James... your post the other day about the SX's reminded me that I have a small box full of the silly things in the garage and still haven't had "play with SX's" bubble to the top of my list. I really should do that. They're neat. Your information you provided in passing to another message really got me thinking about applications for them again. Fast little beasties! Nate _______________________________________________ http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist