Slashdot Mirror

Crispin - Where have you guys been? I was wondering when you would re-release the 7.0 version.

• Dell is now shipping a WireX product.
• Counterpane has licensed Immunix security technology for their internal use.
• We have two papers that will appear this summer at USENIX Security describing "FormatGuard" and "RaceGuard".

Does this release take care of the compilation problems of RH7?

Can I build a 2.4 kernel with this?

I would really like to use XF86 4.03

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase

Microsoft has been allowing some small access to source code for years. A little less than halfway down this page, there's a summary of a discussion called "Do you need source?" The discussion took place in 1997, and indicates that quite a few academic institutions had access to NT source code back then.

So how does "shared source" change Microsoft's policy about source code? That has never been clear from Mundie's verbiage.

The discussion summary includes this little gem:

The conclusion was that Vogels's group used source code only as documentation (there is no other documentation for NT), examples, and to understand the behavior of NT. It turned out to be useful for debugging, and it led to the discovery of interesting APIs that are not documented or available in Win32.

If easy to program, easy to implement multicast were available, gnutella would've used it and not been nearly as poor in the scalability department.

Multicast is pretty easy to program, not much harder then UDP. Or at least the system interface is almost exactly the same (you have to manually set the TTL, that's about the only difference I remember).

Getting a multicast feed is harder, but not really harder then NNTP, you find someone who has one and request a tunnel (unless your ISP magically gives you multicast, which is quite rare).

Mind you this was the state of affairs about 8 years ago, when I did the multicast news software in 1993~1994. Well, you also frequently needed kernel patches then too, but I don't think that is needed in modern unix-like systems.

It is quite hard doing something with multicast that doesn't suffer congestion problems, it is like doing normal UDP work where the protocall doens't help you with packet loss or congestion, except it is far harder to get replies from all receivers (in fact if you want to scale forever you can't ever accept any replies from anyone). It's a big old pain, but people do UDP based systems, and they could do multicast ones as well with more work.

I know your question was relating to just the FS performance, but if you plan on running a server, there are many other things to consider. The BSDcamps get along very well, and you can be assured that many of the changes will be ported to the other BSDs within a short time.

Around the time I was starting to look for a new job, an article entitled "Resume Writing" by Christopher M. Russo appeared in the July 2000 issue of ;login: (the USENIX journal). It is written from a hiring manager's perspective and targeted specifically at resumes for sysadmins. I found the advice extremely useful in tightening my own CV and focusing on the requisite details; I highly recommend it to others.

If you are a USENIX member, you can read the article online. Alternatively, a quick search on Google found another, freely accessible copy here.

Basic advice: remember that your experience should illustrate exactly how you used the skills and technologies listed elsewhere in your resume. Don't just say "administered large server farm and deflected dumb luser queries"; say how you went about doing these things (e.g. wrote automated Perl scripts, installed project tracking s/w, etc.).

Good hunting,
Ade_
/

...Cricket is so cool, in fact, that I had a thoroughly wonderful time at LISA informing a vendor that their product was just about completely useless because it didn't do anything that I wasn't already doing with cricket! By the end of it they even agreed with me that that their features did provide any advantage over cricket. I don't remember who they were, though...

Check out http://cricket.sourceforge.net/

noah

For prople primatily interested in Linux, and glibc2, there's a paper for the community, written by David J. Brown and Karl Runge on Library Interface Versioning in Solaris and Linux.

For an amusing (and somewhat scary) display of Prior Art, see what some of the land/world's premiere techs were doing at the USENIX technical conference in San Diego last summer. Dug Song presented a WiP (Work in Progress) entitled, roughly, "Passwords Found on a Conference Wireless Network." Unfortunately, I cannot find a link right now. There should be enough data here to find it from either USENIX or Dug Song's pages. Hrm. If it's archived anywhere.

sprintf(buf, "...%80s...", badstr)
will happily pull more than 80 characters from badstr. You really want to use snprintf, though it isn't supported identically on various platforms -- check the manpage.

Read this if you want to learn considerably more about safe usage of strncpy/cat/etc:

http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/

SAGE, the System Administrators' Guild, has a salary survey that you can have emailed to you. Of course, it only counts salaries of SAs, but it might give a somewhat reasonable idea of how different regions in the world pay technology professionals.

SAGE, the System Administrators' Guild, has a salary survey that you can have emailed to you. Of course, it only counts salaries of SAs, but it might give a somewhat reasonable idea of how different regions in the world pay technology professionals.

On this subject an interesting (though somewhat OT) link: Design Principles for Tamper-Resistant Smartcard Processors with a lot of info on how to, well, hack hardware.

For alternative views, there's also a couple of papers at:

• Nikolai Bezroukov. Open Source Software Development as a Special Type of Academic Research. First Monday, Vol 4, No. 10 (October 1999), http://firstmonday.org/issues/issue4_10/bezroukov/ index.html
• Nikolai Bezroukov. A Second Look at the Cathedral and Bazaar by Nikolai Bezroukov First Monday, Vol 4, No. 12 (December 1999), http://firstmonday.org/issues/issue4_12/bezroukov/ index.html

The conference took place last August see http://www.usenix.org/events/sec2000/. This is either an old article or a new web posting of an old paper article.

I bought this when it was released several months ago, and it's been a very useful tool. I also got a chance to meet the author at LISA 2000 where he was giving a tutorial on the same topic, as well as speaking at O'Reilly's booth.

The only problem with Java on Linux is the Blackdown JDK isn't as well maintained as all that. Their JDK1.1 compiler segfaults with RH7, meaning I can't compile applets on this machine (because most browsers only inherently have 1.1 support). I am an avid Linux user (been my desktop for two and a half years now) and would have to say that Java is pretty great.

Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/

I would say that there are tons of conferences out there but generally speaking the SAGE conference is where you can network with some really cool people (and its in New Orleans ).

If you are into security then there is a MIS training institute that gives pretty good classes.

If you want free gizmos and gadgets then LinuxWorldExpo is hard to beat.

I've been to the orielly conference this year and that was pretty decent especially if its not your money. ( I got the hook up for 3 free books !!!! )

I would suggest if you go to any conferences and get a workshop or session or what ever people call them make sure to get "hands-on" (or the equivalent) type of class because it sticks with you a whole lot better.

--john

They even have student programs to help us kids get through school.

They even have student programs to help us kids get through school.

They even have student programs to help us kids get through school.

When AT&T introduced their 1-800-OPERATOR collect-call system, MCI diverted a noticeable fraction of the income stream by activating a similar service on 1-800-OPERATER (a number they conveniently already owned).

As the quote indicates, MCI already owned the number in question when illiterate Americans started calling it left and right in an effort to place collect calls. MCI just profited by giving them what they wanted. (Although admittedly, one could argue that the most ethical course MCI could've taken would have been to give the number to AT&T.)

"I did not use the Source Fragment Disclosure Vulnerability, but used an exploit I wrote myself," he said. The exploit is software tool that Mansur developed and then used to gain access to the servers.

"I will not publish the exploit," Mansur said.

"People will start using it, and that's just too dangerous. I was able to log in as service administrator and get full access to the server. I could even kick the administrator."

When's the last time you read the SAGE Code of Ethics?

Check out the IKE/ISAKAMP critique in ;login:

IKE/ISAKM P considered harmful

You are a member of Usenix, aren't you? If not, the article is quoted in full here:

http://www.tryc.on.ca/archives/obsd/tech/1999_12 /0219.html

(Thankyou, Google)

I read the BrownOffice Site but it didn't say if it was all cross platformed. Does it effect every version? Windows, Linux, Solaris, etc? or just what it seems to be is the Linux implementation...

and does this mean it's resident in Mozilla too?

Juergen

First off, this is a reasonably well studied (or at least written about) area of system administration. LISA has papers on this sort of thing fairly often, and everyone can get at most of them for free at Usenix's web site. It's well worth your time to look over LISA proceedings for the last five years or so.

A prefacing note: much of the advice here assumes a fully networked environment, where the machines are not isolated and can contact some central point routinely. Without this it will be very hard to handle updates, and you will probably need to think quite hard about the administrative structure: for example, who will create accounts for a local group of users? At this point user-friendly GUI tools may become an important consideration.

The basic thing to do is to automate as much as possible. You want a system where you never touch individual machines by hand; you touch a master machine or place, and machines update themselves. With 2,500 machines you also want this to be a pull model, not a push model; the machines pulling changes deals much better with machines being down than a central point pushing out updates. One concrete suggestion: make sure that your update-applying system can run arbitrary shell scripts or programs, not just install updated distribution packages; you will need to do this sooner or later.

In order to automate as much as possible, machines need to be as similar as possible. Where they're not similar, you need to build automated tools to detect the differences and deal with them. With 2,500 machines you probably can't keep machines 100% homogenous over their entire lifetime, so planning up front (and having the mechanisms in place in the initial rollout) will save you time later. Unfortunately, I'm not aware of any good tools to determine hardware configuration information in good, scriptable form for Linux (hopefully other people will).

I don't think that the choice of distribution will make a huge difference. You will have to customize whatever distribution you pick in some way, either by making new install media or by creating a master machine that is then cloned. You are almost certainly going to be getting intimately involved in the details of your chosen distribution's package management system; pick one which you're knowledgeable about and comfortable with.

If you go with creating a master machine that is then cloned, you should still automate as much of the creation of the master as possible. Among other good things, this will significantly help when it comes time to upgrade the base distribution, and it helps insure that upgrades are more easily automated (by simply supplying a new version of one of your customization packages). And it is good to know you can easily recreate the customized setup from scratch and the bare metal.

I will echo other people's comments on keeping user data off the 2500 machines. If you allow important user data to live on the local machines, you will have to back it up somehow, and it is a lot harder to back up 2500 machines than a few data servers that everyone talks to. If you have to back up data on each machine, strongly consider a push model where the workstations push the data to be backed up to a central server or servers for the actual backing up to tape. Also, if no user data lives on machines, returning a broken machine to service is a relatively trivial thing; you just drop in another generic clone, which should be a fast operation.

To distribute the load on your update and other servers, you probably want to cluster the workstations into groups (probably based on the network topology). Group servers pull updates and other things from the central server; the workstations pull updates from their local group server. This way all of the servers involved can be relatively modest, because none of them ever have to deal with large numbers of clients.

I personally don't like NIS for password distribution. Locally, we use something called track (available at ftp.cs.utoronto.ca in /pub) to have the clients pull new password files from servers on a regular basis, but one can use something like rsync or the like as well. People change their passwords by using a script that ssh's off to a central password server to run the real password command. Similar things can be done for other files that need to be distributed frequently.

In terms of security, you should first identify what the threats you're guarding against. Outside crackers call for very different precautions than untrusted employees. You'll want to take all the usual steps: limit setuid programs and running daemons, filter and screen what you still have to run, use encrypted connections for as much as possible, and so on. It's hard to give more specific advice without knowing more details.

I personally think that NFS is the best way to go provided that you can trust the workstations not to be subverted; it's the most solid, proven, and well-developed technology at the moment. If you cannot trust this, then you will need to look at alternatives: either something like Coda, or having central application servers that you can control and having the workstations only used to display things from them.

I was fortunate enough to attend the "Hacking Exposed:Live!" tutorial at Usenix2000 in San Diego, Ca. 3 weeks ago and can recommend "Hacking Exposed:"(McClure,Cambray & Kurtz,Osborne/Mcgraw-Hill, $39.99 ). My prior network security experience consisted of copying IPCHAINS scripts to rc.firewall, yet I had no problem understanding the material or applying the suggested counter measures. I have since purchased the book and found it even more informative and thorough.

You may also find SecurityFocus.com useful.

I was fortunate enough to attend the "Hacking Exposed:Live!" tutorial at Usenix2000 in San Diego, Ca. 3 weeks ago and can recommend "Hacking Exposed:"(McClure,Cambray & Kurtz,Osborne/Mcgraw-Hill, $39.99 ). My prior network security experience consisted of copying IPCHAINS scripts to rc.firewall, yet I had no problem understanding the material or applying the suggested counter measures. I have since purchased the book and found it even more informative and thorough.

You may also find SecurityFocus.com useful.

Most of the issues Fred mentioned in his paper would still exist in a multi-personality approach like the one you described.

For example, there has to be some code that manages the VFS layer, and the semantics of that layer would never be able to perfectly fit both the BSD and Carbon personalities. In particular, if you read some of the Interix papers, they mention many similar issues. (Interix is an improved version of NT's POSIX personality.)

> Why does COM 'suck eggs'?

It's design is far from elegant. Reference Counting used to suck. I can't find the critique page, but this will do:

http://www.chappellassoc.com/art3.htm

Of course CORBA has its own problems too (DCOM is also critiqued to provide a fair comparision):

http://www.usenix.org/publ ications/java/usingjava13.html

Don't let the url titles confuse you, read the articles for a good explaination of the strengths and weaknesses.

There is a paper on this, called "Encrypting Virtual Memory." It is at http://www.citi.umich.edu/techreports/. The paper will be presented at the USENIX Security Symposium in August this year.

Someone in the audience with me actually pointed out that twofish would be faster, and the authors of the paper replied that that was precisely why they didn't use it.

It's an interesting paper, nonetheless.

-Jeff Evarts, who has forgotten his Slashdot password

Another organization that has been important in the computing community is USENIX. I haven't seen them get any attention on slashdot, but they donated US$100,000 to EFF to help fight the DeCSS case as well as cryptography cases.

Another organization that has been important in the computing community is USENIX. I haven't seen them get any attention on slashdot, but they donated US$100,000 to EFF to help fight the DeCSS case as well as cryptography cases.

Anyway, my two cents. I think I'll go look up the CPSR and other like-minded groups now and see if anybody's got a sysadmin code of ethics. :) Try SAGE which has an excellent code of ethics (if you really want the SAGE site instead it's http://www.usenix.org/sage/

Anyway, my two cents. I think I'll go look up the CPSR and other like-minded groups now and see if anybody's got a sysadmin code of ethics. :) Try SAGE which has an excellent code of ethics (if you really want the SAGE site instead it's http://www.usenix.org/sage/

• Use StackGuard when you can, because it's safer:
• • Libsafe only protects selected library string functions, while StackGuard protects all potential sources of stack overflow.
  • Libsafe depends on the existance of the frame pointer in the stack frame to parse/detect the stack frame. Unfortunately, the frame pointer may not be there, either because of a compile option to remove it, or because the optimizer took it out.
• Use libsafe where you cannot use StackGuard. It's better than nothing, and it can protect closed-source apps where StackGuard cannot.

My further comment on libsafe: the paper that the authors will be presenting at USENIX in June presents two forms of defense ("library intercept" and binary-rewrite (BRW)) and only the library intercept appears to be embodied in the publicly available libsafe, which is why libsafe only protects against overflows that use particular string library functions.

The BRW method is a pseudo-compiler that can transform binaries into "safe" programs by transforming the binary. It copies program onto the heap, inserting checks as it goes. The copy-to-the-heap is to make space for the additional checks. I really like the BRW method, and hope it becomes available.

If my understanding is mistaken, and BRW is actually in the distributed libsafe, please correct me.

Crispin
-------
CTO, WireX Communciations, Inc.
Immunix: Free Hardened Linux

As has been repeatedly pointed out, while this is probably a good idea, and definitely one that I personally support, organizing techies would be, to steal a phrase from Heinlein, like herding cats.

If this is for real, Solaris has some pretty amazing performace.

I'm a little surprised that BSD did so badly though, esp. since people are always boasting on /. about the TCP/IP performance of BSD. Why does the multi-processor effect BSD so badly on NetBench?

Thi s paper compared x86 Solaris, BSD and Linux back in '95.

Summary:

Our results show that:

Linux has the best performance on file metadata operations because it updates metadata asynchronously;

FreeBSD has the best network performance;

Solaris' performance generally lies between that of the other two systems

Please bear in mind it is pretty old, though.

(please don't turn this into a BSD vs Linux flamewar)

However, politically... those of us who actually work in the industry rather than own it (realizing that some folks do both), have very little influence. Politically, we are all over the map with a general spirit of libertarian ethics with a distrust of the megacorporation ingrained into our psyche by personal expierence and cyberpunk literature we have been gobbling for the last two decades.

And, if we formed our own party in the single member-district system of the U.S (sorry, I know the rest of the world is more democratic with parlimentary systems) such would be a third party which would never gain any influence outside of local elections in California and the Pacific North West. We also, as workers, don't have the money to buy...er...lobby politicans. Easy example... if you and AOL/Time-Warner lobby congress about MP3s, who do you think is going to win?

No, fellow workers... we get paid so much because we have power. Power, untapped and unrealized. Middle-management was gutted through downsizing and our network connections have given rise to more "just-in-time" capitalism. Our skills , if you believe the Software Labor Shortage Myth are in such short supply that we can not train and import workers fast enough. Imagine if we can collectively come to agreements in which we decide what things we will work for and will not. Not only can we have influence over technology, but a host of other things that need geeks to be accomplished.

Our power is in action, not the ballot box. We can vote with our feet. We can strike (here is the source. We can slack and slow down. We can sick-in. We can boycott. We can Direct Action. We can be as Electornically Civilly Disobedient, and we can be... it works like we did with Low Power FM through an organized political campaign of radio piracy, we were able to sieze part of the spectrum from corporate monoplization for community interests. We can break mass media blackouts of information, by making our own media, like we did in Seattle, and like we'll do again in DC.

Are you tired of 60-hour work weeks? Of corporations making deals with politicans to undermine over-time pay and encourage permatemping? We don't have to be slaves.

Are you tired of technology developing that penalizes both the worker and the consumer, to the benfit of a handful of the rich and power... anybody remember the Java Class War? Where was our class in that? Complaining about how the standards needed to be independent of propietary control, and largely doing nothing about it! We need to take control of training and make it clear that it is those of us work in the industry that can figure out who knows what, rather than some profiteering third party or a way for leading software companies to gouge folks for certification!

We need non-profit employment services (or hiring halls) so we can dump our contracting companies (ie. pimps, job sharks, etc... ) once and for all.

We need to organize, and organize in a way that maintains our autonomy and democratic values. We don't need any union bosses, telling us what we can and can't do... but we do need to be in solidarity with our fellow workers so we can support each other in struggle. Who among you wouldn't strike to help the workers in hardware manufacture to get a better shake? Some more pay, a safer environment, etc... Who among you wouldn't refuse to work, if you knew by refusing for a short time you could bring in ecological sound practices. We can bring on the Viridian revolution, but innovation won't be enough... we have to force the issue and force companies to clean up their mess.

We have to become responsible, or we have noone to blame for how bad work is but ourselves.

Solid,

Flint

Baltimore IWW Telecommunications and Computer Workers IU560

(San Francisco, Toronto)

Also check out: Syndicat de l'Industrie Informatique, Washington Technical Workers Alliance, FACE Intel, Alliance@IBM, BITE Division of NWU (Business - Instructional - Techincal - Electronic).

We Can Win! No Nerds, No Birds!

As a side note to the whole certification issue, SAGE, A subgroup of Usenix, has been working on the Unix Systems Administrator Certification for several years now. The legal issues are hard, as well as even the basic issues of What do you certify?

Other certification programs are from SANS and from Linux Professional Institute

These organizations are professional thrid party groups that are not tied to any particular vendor, and will carry much more weight in the industry than any vendor specific "Certification". (IMHO)

(BTW: FUML Rocks!)

As a side note to the whole certification issue, SAGE, A subgroup of Usenix, has been working on the Unix Systems Administrator Certification for several years now. The legal issues are hard, as well as even the basic issues of What do you certify?

Other certification programs are from SANS and from Linux Professional Institute

These organizations are professional thrid party groups that are not tied to any particular vendor, and will carry much more weight in the industry than any vendor specific "Certification". (IMHO)

(BTW: FUML Rocks!)

As a side note to the whole certification issue, SAGE, A subgroup of Usenix, has been working on the Unix Systems Administrator Certification for several years now. The legal issues are hard, as well as even the basic issues of What do you certify?

Other certification programs are from SANS and from Linux Professional Institute

These organizations are professional thrid party groups that are not tied to any particular vendor, and will carry much more weight in the industry than any vendor specific "Certification". (IMHO)

(BTW: FUML Rocks!)

See where "random.stanford.edu" is shown, where "100.random.stanford.edu" will return a TXT entry with a random number in a 100-number range, and "10.random.stanford.edu" will use only a 10-number range. There's also a "passwd.ns.stanford.edu" example which mentions a database.

This example is not attached to HTML, but it does show that the concept of using DNS to give information to a server was published in 1995.

Of course, don't search just slashdot for articles like this. Also search the archives of papers that have been presented at various USENIX/SAGE conferences (in particular, LISA), and other USENIX publications, starting at http://www.usenix.org/publicat ions/publications.html.

You will also want to use index sites such as Yahoo! and Excite, as well as search engines like Google, Altavista, and Hotbot, not to mention community directory projects such as dmoz Open Directory.

That's just a sampling of the sorts of research that you should START with. Of course, to do this right, you'll need to do much, much more.
--
Brad Knowles

Of course, don't search just slashdot for articles like this. Also search the archives of papers that have been presented at various USENIX/SAGE conferences (in particular, LISA), and other USENIX publications, starting at http://www.usenix.org/publicat ions/publications.html.

You will also want to use index sites such as Yahoo! and Excite, as well as search engines like Google, Altavista, and Hotbot, not to mention community directory projects such as dmoz Open Directory.

That's just a sampling of the sorts of research that you should START with. Of course, to do this right, you'll need to do much, much more.
--
Brad Knowles

Of course, don't search just slashdot for articles like this. Also search the archives of papers that have been presented at various USENIX/SAGE conferences (in particular, LISA), and other USENIX publications, starting at http://www.usenix.org/publicat ions/publications.html.

You will also want to use index sites such as Yahoo! and Excite, as well as search engines like Google, Altavista, and Hotbot, not to mention community directory projects such as dmoz Open Directory.

That's just a sampling of the sorts of research that you should START with. Of course, to do this right, you'll need to do much, much more.
--
Brad Knowles

Of course, don't search just slashdot for articles like this. Also search the archives of papers that have been presented at various USENIX/SAGE conferences (in particular, LISA), and other USENIX publications, starting at http://www.usenix.org/publicat ions/publications.html.

You will also want to use index sites such as Yahoo! and Excite, as well as search engines like Google, Altavista, and Hotbot, not to mention community directory projects such as dmoz Open Directory.

That's just a sampling of the sorts of research that you should START with. Of course, to do this right, you'll need to do much, much more.
--
Brad Knowles

Folks, this article about w2k Kerberos incompatibility untrue. I have set up a Win2k RC2 workstation last month at my job for testing purposes. We have a Unix KDC on the network running the standard MIT Kerberos distribution. I configured the win2k workstation to authenticate against the unix KDC - and it worked perfectly. As a matter of fact, I configured the workstation using microsoft's own step by step instructions for doing so, which can be found at
http://support.microsoft.com/support/kb/articles /Q232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0. See the part entitled "Using an MIT KDC with a Windows 2000 Workstation".

This article may be confusing everything with earlier verions of win2k betas (AKA NT5) which microsoft had openly said would not be fully compliant with the kerberos standard. However, they changed this around the RC2 release I believe. You can find an outdated article with more details on this here:
http://www.usenix.org/publications/login/1997-11 /embraces.html.

This older stuff is probably what they're talking about, but they have definitely changed w2k to make it fully compliant with the existing Kerberos standard...

Yeah, got a book for you: "Hacking Exposed!" by Stuar McClure et al. Desppite the exciting title, it's a very clear, concise, and current treatise on how to break into systems, AS WELL AS how to block them out.

There's a lot of stuff deliberately left out of it, along the lines of specific exploits to run on a buffer overflow (if you need it, go write it yourself!), but gives information on general attacks.

For higher security, check out some of the lovely online articles, like the stuff on Sage. The 'securing a Solaris server' is definitely required reading, regardless of your platform.

But this isn't want you want to look at for the CGI performance issue. You'll get an order of magnitude (10-40x) by using Apache's mod_perl to pre-load the pre-compiled programs directly into your httpd daemons. The amount of support for Apache in Perl is phenomenal. In the Apache directory alone on CPAN, we have all these:

Apache-ASP Apache-Album Apache-Archive Apache-AuthCookie Apache-AuthLDAP Apache-AuthPerLDAP Apache-AuthenCache Apache-AuthenN2 Apache-AuthenNIS Apache-AuthenNISPlus Apache-AuthenPasswd Apache-AuthenPasswdSrv Apache-AuthenRadius Apache-AuthenSmb Apache-AuthenURL Apache-AuthzNIS Apache-AuthzPasswd Apache-AutoIndex Apache-CIPP Apache-Cookie Apache-DB Apache-DBILogConfig Apache-DBILogger Apache-DBILogin Apache-EmbperlChain Apache-Filter Apache-Gateway Apache-GzipChain Apache-HeavyCGI Apache-Htgroup Apache-Htpasswd Apache-Htpassword Apache-Icon Apache-Language Apache-Layer Apache-LogFile Apache-MimeXML Apache-Mmap Apache-Module Apache-OWA Apache-OutputChain Apache-PHLogin Apache-ParseLog Apache-Peek Apache-Perl-contrib Apache-PrettyText Apache-Proxy Apache-ProxyPass Apache-RandomLocation Apache-RedirectDBI Apache-RefererBlock Apache-ReverseProxy Apache-RewritingProxy Apache-Roaming Apache-SSI Apache-Sandwich Apache-Scoreboard Apache-Session Apache-SetWWWTheme Apache-Stage Apache-SubProcess Apache-Sybase-CTlib Apache-TempFile Apache-Throttle Apache-TimedRedirect Apache-Traffic Apache-TransLDAP Apache-UploadSvr Apache-Usertrack Apache-VMonitor Apache-correct_headers Apache-ePerl ApacheDBI ApacheMysql B-LexInfo HTML-EP HTML-Embperl HTML-Mason Taco eperl libapreq mod_perl

Of course, eventually even this breaks down. I don't think you want to handle 100,000 hits per second this way. For that kind of situation, you need to look into much more sophisticated systems of redundant daemons, sometimes with highly clever dispatch mechanisms way down low, such as with TCP splicing. See the latest Usenix `USITS' symposium proceedings for things in this realm.