see here. This project is a couple of years old. I was considering writing it myself when I ran across that someone else has already done it.
Takes a completely different approach to what I was thinking - I was thinking of doing it all in userspace. Run some daemon that uses libpcap and "responds" to certain ports like a real machine. Basically means a TCP stack in userspace, so it's not a trivial undertaking but still lots of fun. I was also thinking of making it use nmap's own configuration files so you can simply specify what OS you want it to look like and it looks up the params in the config file. Only disadvantage is that you want it to pass "real" packets in to the kernel for normal processing so this is only useful in limited situations (when you can firewall a machine off completely from the Internet and only need it to serve up something within your organization). I was also considering writing something that uses FreeBSD's divert sockets since you could integrate that nicely with your firewall, but it wouldn't be as portable as the other approach (which would work wherever pcap works).
Anyway, this has been done. The paper seems slashdotted so I can't read it.
Take any file on a modern Linux system. Any file at all. Explain to me its purpose and I'll tell you where you'll find it in the filesystem. A keyboard map?/usr/share. A subprogram to be executed by a program, not by the user?/usr/libexec.
Take any file on a modern Linux system and tell me its full path. I'll tell you what it does, and I'll probably be able to tell you what package it comes from. I can also tell you if you need it or if you can get rid of it./usr/X11R6/lib/X11/rgb.txt? Rgb color database to define textual names for colors, from XFree86./usr/local/share/automake/elisp-comp? Support file for automake to integrate with emacs, installed by user after system installation time, from GNU automake./usr/local/lib/libjpeg.so? Jpeg image library, installed after system installation time, from the JPEG group.
Take any file on a modern Windows system, and you won't be able to do anything with it. C:\winnt\keyacc32.exe? Does that come from MS or from a third party and what is it used for? C:\winnt\system32\getstart.gif? An image that says "Get started with Beta 2" in the Microsoft Arial font. Is this a remnant from a win2k beta and if so, why is still here in a production post-sp3 win2k pro system? Or does it come from some third party? Try figuring out what files are necessary on a Windows system and what's cruft. You certainly won't be able to get a Windows install to fit in less than ten megs because all these files are spread out and undocumented - however, you know it's possible to get a Windows image in only a few megs because Microsoft does it (miniwindows during Windows installation). Getting a FreeBSD install to fit in only a few megs is not a problem - just did it for a compact-flash-based system and it's not hard.
Anyway, this scheme that stow uses is very useful. Djb also has something like this in mind, but his way of doing it is not very elegant IMHO. I've been using something like stow for all my machines for the past three years or so, but it was just a 50-line shell script. Keep all software installed in/opt. Like/opt/emacs/emacs-21.1 with a symlink/opt/emacs/default which points to "current" version (that way, upgrades can be done with just changing a symlink, and downgrades are also just changing a symlink - you don't have to learn some tool's syntax, and, more importantly, the admin that replaces me won't have to learn some esoteric system because you can figure out my system in 30 seconds). All that my shell script does is make symlinks from the/opt/cvs/default/bin to/usr/local/bin, from/opt/python/default/lib to/usr/local/lib, etc. This way, when you run a poorly-written autoconf script, it will always find the requisite packages (because people always assume the required package is in/usr/local) and my users don't have to deal with $PATH. In addition, I can run this:
find/usr/local -type f -print
And this tells shows me all the stuff that I've written locally for the particular system (anything in/usr/local that's not a symlink must have been written by me).
Never run into any dependency problems, upgrades are "ln -s," uninstalls are "rm -rf."
Actually it's the way the state gets it's welfare money back....
Before we even approach the problem of getting people off of welfare, we need to correct the problem of people occasionally mistakenly using "its" instead of "it's"; for that is the real problem facing America!
"Occasionally" and "mistakenly" are both adverbs. Stylistic suggestion: "...people occasionally using 'its' instead of 'it's' by mistake...." Also, you may want to insert commas when beginning a sentence with an adverb such as "also" or "actually."
What, I don't get a "70% Funny" like the original poster? We can mock the poor
but we can't make light of someone who has not mastered his native language?
For discussion:
have you ever visited a casino (especially towards the first of the month)?
How do we solve the problem of getting the elderly off of Social Security?
You'll see it pause at (500, 500) for five seconds and then go to the bottom-right edge of the screen. You can't move the mouse cursor off-screen in X11.
My fault - should have tried it before I wrote. Also works the same if you use "empty.xbm" for both arguments (you want the mask to be empty so no part of cursor shows through).
Start up the program "bitmap" that comes standard with XFree86. It starts with an empty bitmap. Save the empty bitmap to "empty.xbm." Click the "invert" button to set all the pixels in the bitmap. Save this bitmap to "full.xbm."
Now type:
xsetroot -cursor empty.xbm full.xbm
This changes the root cursor to the empty bitmap you just created.
Instead of "startx -e menu" write a shell script with two lines:
#!/bin/sh xsetroot -cursor/path/to/empty.xbm/path/to/full.xbm exec menu
Have "startx" execute this script, or simply make this script your.xinitrc.
Problem solved.
However, if the "menu" program you speak of does not simply inherit the root window's cursor (default behaviour), you will need either to modify the program to do so (eg, comment out the cursor-setting lines, grep for XSetWindowAttributes or XDefineCursor), or to modify your cursor font so the cursor it uses is the blank one you created. If the program creates its own cursor rather than using a standard cursor from the cursor font, you need to modify the source. It's probably much easier to modify the source anyway, since it only takes a grep and a recompile, whereas if you want to modify your cursor font, you have to find some font editing program and deal with someone's idea of a usable graphical interface.
If you don't have source to your program, you'll need to break out the hex editor. If this is the case and you don't know i386 asm, post a URL to the program.
People don't understand how copy and paste is supposed to work in X because lots of
applications do it wrong. Your example: select text, select copy, select more text in
different application, select paste - should work correctly.
Here's how it's supposed to work: when you select text, that text becomes the
SELECTION. The SELECTION is not sent over the wire to the X server - instead, the
application only tells the X server "I now have the SELECTION."
When you select "copy" (from menu, keyboard shortcut or whatever),
the SELECTION is copied to the X server. The SELECTION is then
copied into the CLIPBOARD. The CLIPBOARD is stored on the X server
and no application "owns" it. The application should gray out the
"copy" button/menu/whatever if it does not own the SELECTION.
When you select "paste" (via menu, keyboard or whatever), the
application copies the CLIPBOARD from the X server and pastes it
in. When you middle-click, the application copies the SELECTION
from the application that owns the selection and pastes it in.
You'll note that if you are selecting lots of text all the time (like in a word
processor) but only selecting the "copy" command on that text occasionally, the text is
only copied to the X server when you copy, not when you select.
The problem is that some applications don't provide "copy" or "paste"
buttons/menus/whatever and only work with SELECTIONs. Xterm is
like this (so if you want to copy from or paste to xterm, you must use middle-click (emboldened because this is usually all the explanation people need). Another problem is that people didn't understand this,
so some people would switch around the SELECTION and the CLIPBOARD,
or do all sorts of crazy things with them. If applications were
coded correctly, cut and paste would always work and middle-click
would just be a shortcut for advanced users who understand the
difference between the SELECTION and the CLIPBOARD. Yet another
problem is that some toolkit and applications programmers attempt
to "fix" this problem by changing the way it works: Qt versions
prior to 3.0 would not operate on the CLIPBOARD when using copy and
paste, but rather on their own internal buffers and with the SELECTION
when communicating with other applications. This led to all kinds
of brokenness and generally meant that cut and paste would not work
correctly to/from Qt or KDE applications but only internally with
Qt or KDE applications. Yet another confusing problem is that X11 used to have these things called "cut buffers" which are competely obsolete but still supported by ancient programs like xterm.
So no, there's nothing wrong with X11 cut and paste protocol. It
behaves correctly in network environments (selecting all text in a
large document to delete it or increase the font size should not
send megs of data over the network). The underlying protocols also
avoid all sorts of race conditions that are inherent in network-oriented
windowing systems (so you'll never have true remote display with
correct, reliable cut and paste in MacOS or Windows, but you'll
always be stuck with remote desktop solutions like VNC, Terminal
Server or Remote Desktop (which are completely different from remote
display like X11)). It's also not difficult for sensible applications
programmers since good toolkits (like modern Qt) do this correctly
and shield the programmer from the details. It is difficult
for crazy programmers who don't use good toolkits since they then
have to understand how it's supposed to work and how to use the
underlying protocols (which you'll see are somewhat complex if you
try reading through ICCCM - if you truly understand ICCCM, you'll
see that it's necessarily complex since there are race
conditions everywhere).
You are pointing out what I believe is the original poster's real problem.
Macs do not let you arbitrarily map keys, as you can do in X11. If you don't like what scroll lock does, make it a backspace key (see xmodmap manpage or look here for a graphical front-end). Won't even triigger the LED anymore if you do that. If you want it to do some function, write a program that listens on the root window for the scroll lock press and then sends some "message" to the foreground window (this is how mwheel works - "message" is in quotes because this can get quite complex).
Now I know some Mac fanatic is going to point me to Apples KeyBindings documentation or uControl, but these are extremely limited compared to what you can do in X11. I'll admit that Apple's keybindings thing is pretty neat - this page contains a list of functions that you can bind (system-wide) to certain keys or combinations of keys. If you don't like the fact that backslash is taking up an entire key on your Macintosh, bind it to uppercaseWord or whatever.
It's funny how the original poster complains about tilde but makes no mention of caps lock, the truly useless key on the keyboard. Perhaps caps lock made sense when people were using typewriters, but it makes zero sense when you can accomplish the same thing through software. Occasionally I would like caps lock when I type in a longish macro name (in C, that's what I do all day). Of course I'm not going to enable caps lock (heresy!). I simply wrote a small emacs lisp function that (just look through the current keyboard map and write a replacement function for self-insert-command - gets a little tricky if you want to preserve how kill ring functions (undoes groups of insertions), but not too hard).
Anyway, the problem is not with keyboards but with systems programmers who don't realize that it's necessary to define system-wide keybindings in a flexible manner (this includes rebinding things like caps lock, alt, windows key, windows right-menu key, command, number pad separately from number keys, etc). This goes against any human interface guidelines (consistency, simplicity, etc.), but my mother has no use for backslash or brace or bracket, whereas I use these as much as any other key in C. Different people have different needs.
So I don't know. If The Ashcrofts and Poindexters have their way and we end up living in a nation where the trains run on time
I think this allusion is lost on the majority of Slashdot readers. One of Mussolini's "accomplishments" is that he "made the trains run on time." Whether or not this is true, it doesn't matter - it was a very effective work of propaganda.
I'm sure there is a way to throttle bandwidth, but can you do it on a class by class basis?
You should look into thttpd. It has some very robust throttling features and a concurrency model that makes sense. It's also usually faster than apache for just downloading files (and if you're just serving up files and not dynamic content, there's not much point to using apache).
Here is the section that explains how throttling works. From what I understand you would like to do, you would set up some directory trees:
site.com/anonymous/
site.com/registered/
site.com/paid/
etc.
Each of those directories contains symlinks to the files you're serving, and a.htaccess password file (the symlinks point into the/anonymous section (or whatever is the "lowest" class) so it won't help people if they start guessing URLs and it's still within the site's main directory so you can still use thttpd's chroot feature). You then use thttpd's throttling features to limit the bandwidth in each directory hierarchy however you like (using simple URL patterns). Users will like it since when they click on a link, it just pops up a standard password dialog box and the browser keeps track of the password if they download multiple files in a hierarchy.
This will literally take you only minutes to set up: thttpd has no dependencies or important compile-time options to worry about, it compiles in seconds and it has one central configuration file that's small, simple and well-documented. In addition, thttpd has never had any major security holes, it has an excellent concurrency model that keeps serving up files without bogging down the machine even under immense loads, and the throttling features are well thought-out
Now what would be interesting would be to know why they chose Linux
The option you missed is that Linux is excellent for compute clusters. If the render farm runs Linux, putting the design tools on Linux might save time/money in integration issues and codebase maintenance. In the Windows world, "cluster" means database server farm, not compute cluster. I don't even know if Windows has tools like MPI or mosix.
You want me to get excited about someone using Linux? Get Asia Carrera to host her website with Linux...
ingram% telnet www.asiacarrera.com 80
Trying 209.163.238.131...
Connected to asiacarrera.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Thu, 13 Feb 2003 02:32:47 GMT Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) PHP/4.0.4pl1 mod_perl/1.21 FrontPage/4.0.4.3
Last-Modified: Thu, 02 Jan 2003 01:59:58 GMT
ETag: "50013-1cc7-3e139d1e"
Accept-Ranges: bytes
Content-Length: 7367
Connection: close
Content-Type: text/html
Connection closed by foreign host.
You may be missing the humor inherent in the original poster's comment:
I don't know what amazes me more; the fact that Linux is being used by professional artists to create blockbuster films... or the fact that application developers are still using Tk!
Tk is a graphics toolkit. It's also a suck-ass graphics toolkit, and it's also impossible to separate from a suck-ass language called TCL (pronounced "tickle"); you can get Tk bindings for perl, python, etc., etc. but it still requires TCL. TCL/Tk is so suck-ass that I find it hard to believe that someone would actually consider using it for a new project - thus, it's incredible.
In all fairness, TCL/Tk was the only GUI scripting environment for Unix many years ago. Back in the day, your choices for X11 GUI toolkits were TCL/Tk (suck-ass), Motif (costs $$), Athena (looks nasty, confusing semantics), or DIY with Xlib (which isn't as hard as it sounds, but takes time). Nowadays we have really nice toolkits like Qt and wxWindows (and GTK for those who refuse to program in C++), but the pyhon and perl people still consider Tk the "canonical" toolkit for their languages. Really a pity, since wxPython is much nicer RAD environment.
Hey, this sounds very cool. I haven't checked back in a few years. I'll definitely pick up the book.
I didn't mean to sound harsh - that's just sort of how I usually write. Like I said, AoA rocked, even when it was just 16-bit stuff - it's just that the programming environment (DOS) left something to be desired. My university didn't offer anything in the way of assembly programming (just some architecture courses, and a compiler course that generated SPARC v8, but it had plenty of theoretical CS stuff, so I'm not complaining too much). AoA was how I really got into assembly programming. There's a certain rush you get from programming directly to the machine. I wouldn't be doing the stuff I'm doing now if I hadn't read AoA.
Thanks very much for AoA. I'm looking forward to your next book as well.
Actually, the best way to handle this is to assign a -1 penalty to new users.
That would be great, but apparently "new user" means "anything within the past year." I've been reading slashdot since late 1999 (when they first introduced accounts), but didn't sign up until last year. Kind of annoying.
AoA, IIRC, deals almost exlusively with 16-bit real mode programming. Now I know that there are some esoteric embedded applications that still use real mode, but the only thing people really use real mode for nowadays is to get into protected mode. Your computer runs real mode for a total of a few cycles during boot.
Now protected mode x86 isn't all that different, but there are significant differences. You never use BIOS or DOS (heh) calls but instead link to C libraries and (maybe) use system calls directly. You never have a chance to use "port" IO unless you're writing a device driver (and even there it's limited with modern devices). If you have a modern OS (anything except win9x), you don't have to deal with segments but have a flat memory model (by default, you can't even define your own segments (LDTs) in some OSes). The only time you really deal with "segmentation" is when you're setting up your GDTs and call gates in the OS boot sequence, and there it's not really the same thing as 16-bit segmented memory model at all.
I read through AoA a couple of years ago. It was a real pain in the ass to actually set up a DOS environment where I could do any work (ended up using VMWare to run DOS, while actually writing all my real code on the Linux side using nasm and vi (hint: make a hard link to a VMWare virtual disk to bypass file locking semantics and you can mount it r/w while it's being used by your DOS session - very dangerous, but very convenient). Even then, I picked up a copy of 386intel.txt to figure out how to set up a protected mode environment and started writing a kernel right away - stayed away from that 16-bit crap as much as possible.
The book would really be more useful if it didn't deal with all that 1989 DOS crap and dealt with some more interesting issues. People who still write x86 assembly write compilers, device drivers, low-level OS bits, and inner loops (especially for games/media players/encoders/etc). None of this happens in 16-bit mode, and things are very different in 16-bit mode compared to protected mode. Most optimizations I can think of that improved code on 386/486 running DOS actually ends up SLOWER on P4s and Athlons running protected mode. Optimizing modern x86 CPUs is a completely different beast.
Some other improvements I'd like to see in this kind of book: cut out all the tables listing IO addresses and DOS/BIOS INT calls. Instead add a bit describing how different environments have different calling semantics for C functions and system calls. Maybe avoid the masm-specific stuff (I don't even think masm is available anymore unless you download the Windows DDKs, and even there, I don't know if it will produce 16-bit code - at one point, some old 16-bit version of masm was available for free on Microsoft ftp, but I doubt it's still there). It's pretty hard to use this book as-is because you have to set up some kind of DOS environment.
But anyway, this book still rocks. It's where I learned x86 assembly which then launched me into the low-level kernel stuff. If you know SPARC, PPC or MIPS, do not assume that x86 is more of the same. You think SPARC register windows are nasty? You ain't seen nothing yet. x86 assembly (especially the low-level stuff in Intel's volume 3 CPU reference, the systems programming stuff) is so immensely nasty that you get an unnatural sadistic joy out of writing some tight code - it's kind of like writing a sendmail.cf from scratch.
Glad to see this in dead-tree form - I might pick up a copy for my library. If it has a nice lay-flat binding, it'll be much more convenient than the PDFs.
If you want to learn this stuff, you'll also need these.
The modern ones are kind of verbose since there's so much that's been tacked on to modern x86 CPUs...you may prefer an older version. Try one of these.
FreeBSD development happens in a number of "branches:" FreeBSD-STABLE and FreeBSD-CURRENT. Every now and then, -STABLE is frozen and a release is made (like FreeBSD-4.7). Whenever a release is made, that begins a new branch (which usually contains only critical security fixes). -STABLE is continually changing, but large changes which can break lots of things are avoided. On the other hand, anything goes in -CURRENT, so it has a lot of experimental code. Sometimes code goes from -CURRENT to -STABLE after it's deemed stable enough.
If you run -CURRENT, you'll run into lots of bugs, and writing good bug reports means delving into the code, so you end up reading lots of code and solving lots of adminny-type problems if you run -CURRENT. Not recommended for important servers, but fun to play with nonetheless. FreeBSD lets you decide precisely where to draw the line between rock-solid (-RELEASE) and bleeding-edge (-CURRENT).
The admin stuff is important because it often means avoiding writing lots of code; eg, you can avoid writing a couple thousand lines of code with a 15-line shell script. I often marvel at how some smart people don't know how to use the right tool for the right job (like spending days trying to do text manipulation in matlab, where the problem can be solved with ten lines of perl, or writing a complex network daemon from scratch, where the problem could be solved with a 100-line patch to an existing program they didn't know about). Saves weeks of time. Best way to learn the admin stuff is to run one of the BSDs (or Slackware) and avoid the hand-holding distros. With a BSD or Slackware system, you can rewrite all the machine's boot scripts in an afternoon (cutting out all the cruft you don't need), something which is nearly impossible with, say, Redhat, which has deep layers of abstraction you have to rip through before getting to what you need.
Example: I recently had to write a daemon did something whenever it noticed a new file in a certain directory. Well, this is pretty easy, since you only have to periodically look at the directory's modification time to see if you need to re-read it (open at start and fstat poll - this is the only efficient way to do it portably). You run into some subtle issues, however, as files may be added or deleted in between when you check the mod time and read the directory, and files may be added just after you check the directory (within the same second, so the mod time isn't changed). Writing the correct code to avoid these race conditions takes an hour or two. After having wriitten it, I was compiling the latest version of KDE or GNOME or something, which means tracking down dependent libraries manually, figuring out what they do, fixing any compilation problems, etc. I then learned about libfam, which is used by one of these things and does exactly what my code did. Had I been running one of the hand-holding distros, which automatically solves dependencies, I would have never learned about it.
In my case the user must have an active HTTPS connection in order for the user rules to stay active
Very clever. HTTPS protects against man-in-the-middle attacks, so it will be very unlikely that someone could take over an existing connection for any extended period of time.
Keeping a browser window open might be annoying - not a big deal for us Unix folks (background wget or something), but your Windows users might complain. You might consider writing an optional Windows application that embeds MSIE via COM and stays in the systray. However, Win32 programming is hellish, and I wouldn't
do it:)
If I ever do this again, I'll probably use that HTTPS idea as it's more elegant and more secure than what I came up with.
How do you tell if someone has logged out?
I had a little web page where people could explicitly log out. Of course, I didn't expect people to use that (and they didn't), so I would just time out sessions with a cron job. Nobody complained, but the more correct way would be to examine the rule's timestamp (ipfw -t list), something I didn't do.
Honestly, I don't remember what problems I ran into when using ipfw. I do still have some of the rules around from when I was playing with them. I also used skipto, and I also used ipfw "sets" to enable or disable groups of rules atomically (but I can't figure out why I needed that). Also (as I'm sure you've figured out) you need to run 4.7, 5.0 or -CURRENT to use MAC address filtering (ipfw2). The problems I ran into may have had to do with running a production system on -CURRENT, which was the only one that had MAC filtering at the time.
OK, now that I look at it, I may have needed "sets" because there were actually two rules for each record. The first one which skipped over the redirect:
add 39 set 17 skipto 41 all mac any 00:c0:49:b0:66:89 src-ip 172.16.42.245
And the second one which put the packet through the regular NAT stuff:
add 59 set 17 divert 8668 ip mac any 00:c0:49:b0:66:89 src-ip 172.16.42.245
Now that I think of it, "sets" wouldn't really be necessary as long as you enable/disable the second rule first. Even if it did go wrong, it's just one or two lost packets in the time between the two rules being activated. Even this is unlikely since the user will probably be looking at the results of the authentication page at this time.
If you use the divert(4) stuff, you don't need any dynamic rules at all - just pass all the packets into your divert socket and have the program look up the MAC and IP in a database or flat file. Seems somewhat more elegant.
Linux 2.4 already does this. Linux 2.2 does not. I'm not sure why people are talking of "patches" to the Linux kernel to fix this, as current kernels are already immune to the attack.
The real reason a simple counter IPID is dangerous is because it allows zombie scans. These are scans that are "bounced" off of your machine: attacker A scans machine C using machine B, and user C only sees a scan coming from machine B (HP JetDirect printers work great for such zombies, and are often connected directly to the Internet). Lots of fun stuff you can do with that IPID field:)
Here's how these products work (and a way to build one yourself):
The AP is hooked up to a FreeBSD box. The FreeBSD box runs NAT and DHCP. When the box sees a DHCP lease request from an unkown MAC, it gives the client an IP and puts the client in a "sandbox" network. This "sandbox" network redirects all IP packets to port 80 on the authentication server (two different ways to do this - either with dynamic ipfw rules, or directly through divert(4)). The authentication server asks for a username/password. Since you write this stuff yourself, you can integrate it with LDAP/Kerberos/flat files, etc. You can even get creative and set the password to something you print out on a receipt so the clients have to "buy" time from you, with the POS computers hooked up to the auth server, etc.
Once the client authenticates, you modify the ipfw rules that redirected packets to the local machine so that packets run through the normal NAT stuff. You can also set up a cron job to delete stale entries so people have to re-authenticate every now and then.
If you do this with ipfw, it's just a couple rules. I ran into some problems doing it this way, so I wrote a little C program that directly inspected packets and passed them along using FreeBSD's divert(4) interface. (I get paid to do these sort of things for people, so the code ain't mine to give away and it would be pretty useless anyway since there's a lot of coding and admin work involved in integrating it).
For real security, you'll need to pass all packets through such a custom program anyway, so you can inspect whether or not that particular IP (given from a DHCP lease) has authenticated recently. You'll also need an AP that passes along MAC addresses unmodified. I know Cisco Aironets allow you to do this, and I know Linksys APs don't (Linksys APs are based on a Lucent chip that's used in lots of other APs like the Apple Airport).
Note that someone with enough expertise can sniff the network, get a valid IP, DOS the real client, and then impersonate the already-authenticated MAC and IP. All systems which work in the way you described are vulnerable to this type of attack.
Not a whole lot you can do to fight this; however, a while back, some guy submitted a paper to Slashdot about how you can tell if someone is spoofing a MAC based on some peculiarities with how most 802.11b cards handle a sequence number in the 802.11 protocol. I'm guessing his paper is new enough that none of the people who sell these pre-built systems implemented his idea, but if you do your own, you're free to implement whatever you want. Note that using this is still not foolproof (search my posting history for an example of an attack against a system which would use this idea and for the link to the original article).
Basic conclusion: there is no bulletproof system which does what you need. If you implement it correctly (with an AP that passes along MACs unmolested in bridge mode), it makes it more difficult, and if you implement the anti-spoofing thing I mentioned, it just ups the bar even more, past the level of the script kiddies. Judge your security needs: such a wireless access system can be good enough if you ensure your confidential data is behind a real authentication system and is never sent over the wire clear-text. If you're worried about someone (someone capable) stealing 'net access from you, you should probably stay away from wireless.
You seem to be looking for a pre-built system that does this sort of thing. Although I'm sure someone is selling this sort of thing, it's probably not popular because there are so many variables involved with integrating it into your existing infrastructure (cabling, routing, authentication systems, etc). Generally, you would get a competent consultant to build something like this for you if you don't have the requisite programmers and networking gurus. If you want to avoid the consulting fees, pick up some Richard Stevens books to learn networking and programming, and start running -CURRENT to learn proper system administration:)
Incorrect conclusion. Going by these comments, very few slashdot readers use NetBSD. In fact, I'm willing to bet that the majority of the slashdot GNU/hippies that rant on and on against Microsoft and fawn over Linux are all too happy to activate their Windows XP and click about in their MSIE. I make this judgment from the complete dearth of technical information in slashdot comment pages.
Of course, this is quite hypocritical of me as here I am adding no useful technical information. In all honesty, I've never had the chance to use NetBSD for any significant task. I know (and love) FreeBSD and OpenBSD inside and out I've only put NetBSD on esoteric machines that don't run the other BSDs quite as well (really old Macs and Sparcs).
Anyway, congratulations to the NetBSD folks. The next time I need to do something useful with strange hardware, I know where to look.
VMWare is also useful for stuff like this. Set up a few VMWare virtual machines and you're good to go.
A couple of years ago, I went on vacation with no net access and only my laptop. I wanted to do network programming during my vacation. I set up four VMWare virtual machines running FreeBSD and did my little program (user-mode NFS server). Got a lot done in a short time (probably due to the lack of net access - had all the necessary docs saved ahead of time). I chose FreeBSD because it was much easier to cut down to a tiny image than any Linux distro (even Slackware, my favorite).
VMWare is also useful if you want to do OS-level programming (eg, write a kernel). This is one of my spare time projects (haven't touched it in years, though). I'd imagine user-mode Linux can't let you mess with the low-level stuff, but it could be useful for high-level stuff like scheduling algorithms and so forth (useful because it's a real PITA to boot up a machine whenever you change a line of code and user-mode Linux might give you some better debugging options than a serial cable).
You might be able to do this with Bochs nowadays, but Bochs was nowhere near useful back then. Seems to have come a long way in a short time.
Not sure what advantages user-mode Linux would have over VMWare or Bochs. Perhaps some karma whore would like to register and post the contents of the article:)?
But if your code compiles in a forest where there are only 100 systems that can execute it (because those 100 systems all belong to the developers working on the project, as opposed to those of us who develop other things don't have time to keep up with the developments in every open source/free software video project), can you really be said to have created something useful in the first place? If code compiles on no machines, can it really be said to be code? And if you don't give a shit about your code running on a wide variety of platforms ("What, our code only runs on Distro X! You wanna run his app that needs Distro Y, and my app, you gotta dual-boot, or choose between his app and my app! Choose my app, 'cuz I'm cooler!") why should I give a shit about your code in the first place?
I've written a couple of larger projects which I've never released. A window manager (30000 LOC), a file manager (20000 LOC), etc. I've also written larger projects that I have released under BSD license (web and ftp daemons, ldap gateways, etc.).
There is a pattern. I release/publish code that will probably be used by clueful admins, and I don't release any graphical software.
Why? Because I don't want to deal with twits like you. I write code because I like to write code and because I need the stuff I write. I don't write code for fame or glory, and if I release something, it's because someone else might find it useful and I'm really a nice guy. I don't write code so I can be your personal fucking tech support line. I'll be happy to explain to you how to get mplayer working because I'm not some anti-social recluse and I'll fix any bug or portability issue in my code since I take pride in my work, but I won't give you the time of day if you continue with that attitude. The mplayer lists are probably inundated with comments like yours and I honestly don't know how they can continue writing their code.
So yeah, take it and be grateful or leave it and STFU. Just don't complain to me.
Fair enough - but then why should any of us give a rat's fried patoot about freeing that DeCSS guy, or that Ogg Theora stuff, when it's plain as day that I'll never view a video with code based on it anyways?
Separate issue - you might care about open formats, DRM and the DMCA when your computer turns into a TV and you can no longer play your CDs in your device of choice. The GNU/slashdot folks like to mix all their politics together, but you can release all the code you like and use only OSS on your machines and still work for the MPAA (like some effects studios), or conversely, you can keep using your Windows XP and clicking through life without releasing a line of code, while donating to the EFF.
Slashdot Mirror
Takes a completely different approach to what I was thinking - I was thinking of doing it all in userspace. Run some daemon that uses libpcap and "responds" to certain ports like a real machine. Basically means a TCP stack in userspace, so it's not a trivial undertaking but still lots of fun. I was also thinking of making it use nmap's own configuration files so you can simply specify what OS you want it to look like and it looks up the params in the config file. Only disadvantage is that you want it to pass "real" packets in to the kernel for normal processing so this is only useful in limited situations (when you can firewall a machine off completely from the Internet and only need it to serve up something within your organization). I was also considering writing something that uses FreeBSD's divert sockets since you could integrate that nicely with your firewall, but it wouldn't be as portable as the other approach (which would work wherever pcap works).
Anyway, this has been done. The paper seems slashdotted so I can't read it.
Take any file on a modern Linux system. Any file at all. Explain to me its purpose and I'll tell you where you'll find it in the filesystem. A keyboard map? /usr/share. A subprogram to be executed by a program, not by the user? /usr/libexec.
Take any file on a modern Linux system and tell me its full path. I'll tell you what it does, and I'll probably be able to tell you what package it comes from. I can also tell you if you need it or if you can get rid of it. /usr/X11R6/lib/X11/rgb.txt? Rgb color database to define textual names for colors, from XFree86. /usr/local/share/automake/elisp-comp? Support file for automake to integrate with emacs, installed by user after system installation time, from GNU automake. /usr/local/lib/libjpeg.so? Jpeg image library, installed after system installation time, from the JPEG group.
Take any file on a modern Windows system, and you won't be able to do anything with it. C:\winnt\keyacc32.exe? Does that come from MS or from a third party and what is it used for? C:\winnt\system32\getstart.gif? An image that says "Get started with Beta 2" in the Microsoft Arial font. Is this a remnant from a win2k beta and if so, why is still here in a production post-sp3 win2k pro system? Or does it come from some third party? Try figuring out what files are necessary on a Windows system and what's cruft. You certainly won't be able to get a Windows install to fit in less than ten megs because all these files are spread out and undocumented - however, you know it's possible to get a Windows image in only a few megs because Microsoft does it (miniwindows during Windows installation). Getting a FreeBSD install to fit in only a few megs is not a problem - just did it for a compact-flash-based system and it's not hard.
Anyway, this scheme that stow uses is very useful. Djb also has something like this in mind, but his way of doing it is not very elegant IMHO. I've been using something like stow for all my machines for the past three years or so, but it was just a 50-line shell script. Keep all software installed in /opt. Like /opt/emacs/emacs-21.1 with a symlink /opt/emacs/default which points to "current" version (that way, upgrades can be done with just changing a symlink, and downgrades are also just changing a symlink - you don't have to learn some tool's syntax, and, more importantly, the admin that replaces me won't have to learn some esoteric system because you can figure out my system in 30 seconds). All that my shell script does is make symlinks from the /opt/cvs/default/bin to /usr/local/bin, from /opt/python/default/lib to /usr/local/lib, etc. This way, when you run a poorly-written autoconf script, it will always find the requisite packages (because people always assume the required package is in /usr/local) and my users don't have to deal with $PATH. In addition, I can run this:
And this tells shows me all the stuff that I've written locally for the particular system (anything inNever run into any dependency problems, upgrades are "ln -s," uninstalls are "rm -rf."
Before we even approach the problem of getting people off of welfare, we need to correct the problem of people occasionally mistakenly using "its" instead of "it's"; for that is the real problem facing America!
"Occasionally" and "mistakenly" are both adverbs. Stylistic suggestion: "...people occasionally using 'its' instead of 'it's' by mistake...." Also, you may want to insert commas when beginning a sentence with an adverb such as "also" or "actually."
What, I don't get a "70% Funny" like the original poster? We can mock the poor but we can't make light of someone who has not mastered his native language?
For discussion: have you ever visited a casino (especially towards the first of the month)? How do we solve the problem of getting the elderly off of Social Security?
Great story - made my day :)
Not possible. Try it:
You'll see it pause at (500, 500) for five seconds and then go to the bottom-right edge of the screen. You can't move the mouse cursor off-screen in X11.
Now type:
This changes the root cursor to the empty bitmap you just created.Instead of "startx -e menu" write a shell script with two lines:
Have "startx" execute this script, or simply make this script yourProblem solved.
However, if the "menu" program you speak of does not simply inherit the root window's cursor (default behaviour), you will need either to modify the program to do so (eg, comment out the cursor-setting lines, grep for XSetWindowAttributes or XDefineCursor), or to modify your cursor font so the cursor it uses is the blank one you created. If the program creates its own cursor rather than using a standard cursor from the cursor font, you need to modify the source. It's probably much easier to modify the source anyway, since it only takes a grep and a recompile, whereas if you want to modify your cursor font, you have to find some font editing program and deal with someone's idea of a usable graphical interface.
If you don't have source to your program, you'll need to break out the hex editor. If this is the case and you don't know i386 asm, post a URL to the program.
Here's how it's supposed to work: when you select text, that text becomes the SELECTION. The SELECTION is not sent over the wire to the X server - instead, the application only tells the X server "I now have the SELECTION."
When you select "copy" (from menu, keyboard shortcut or whatever), the SELECTION is copied to the X server. The SELECTION is then copied into the CLIPBOARD. The CLIPBOARD is stored on the X server and no application "owns" it. The application should gray out the "copy" button/menu/whatever if it does not own the SELECTION.
When you select "paste" (via menu, keyboard or whatever), the application copies the CLIPBOARD from the X server and pastes it in. When you middle-click, the application copies the SELECTION from the application that owns the selection and pastes it in.
You'll note that if you are selecting lots of text all the time (like in a word processor) but only selecting the "copy" command on that text occasionally, the text is only copied to the X server when you copy, not when you select.
The problem is that some applications don't provide "copy" or "paste" buttons/menus/whatever and only work with SELECTIONs. Xterm is like this (so if you want to copy from or paste to xterm, you must use middle-click (emboldened because this is usually all the explanation people need). Another problem is that people didn't understand this, so some people would switch around the SELECTION and the CLIPBOARD, or do all sorts of crazy things with them. If applications were coded correctly, cut and paste would always work and middle-click would just be a shortcut for advanced users who understand the difference between the SELECTION and the CLIPBOARD. Yet another problem is that some toolkit and applications programmers attempt to "fix" this problem by changing the way it works: Qt versions prior to 3.0 would not operate on the CLIPBOARD when using copy and paste, but rather on their own internal buffers and with the SELECTION when communicating with other applications. This led to all kinds of brokenness and generally meant that cut and paste would not work correctly to/from Qt or KDE applications but only internally with Qt or KDE applications. Yet another confusing problem is that X11 used to have these things called "cut buffers" which are competely obsolete but still supported by ancient programs like xterm.
So no, there's nothing wrong with X11 cut and paste protocol. It behaves correctly in network environments (selecting all text in a large document to delete it or increase the font size should not send megs of data over the network). The underlying protocols also avoid all sorts of race conditions that are inherent in network-oriented windowing systems (so you'll never have true remote display with correct, reliable cut and paste in MacOS or Windows, but you'll always be stuck with remote desktop solutions like VNC, Terminal Server or Remote Desktop (which are completely different from remote display like X11)). It's also not difficult for sensible applications programmers since good toolkits (like modern Qt) do this correctly and shield the programmer from the details. It is difficult for crazy programmers who don't use good toolkits since they then have to understand how it's supposed to work and how to use the underlying protocols (which you'll see are somewhat complex if you try reading through ICCCM - if you truly understand ICCCM, you'll see that it's necessarily complex since there are race conditions everywhere).
Macs do not let you arbitrarily map keys, as you can do in X11. If you don't like what scroll lock does, make it a backspace key (see xmodmap manpage or look here for a graphical front-end). Won't even triigger the LED anymore if you do that. If you want it to do some function, write a program that listens on the root window for the scroll lock press and then sends some "message" to the foreground window (this is how mwheel works - "message" is in quotes because this can get quite complex).
Now I know some Mac fanatic is going to point me to Apples KeyBindings documentation or uControl, but these are extremely limited compared to what you can do in X11. I'll admit that Apple's keybindings thing is pretty neat - this page contains a list of functions that you can bind (system-wide) to certain keys or combinations of keys. If you don't like the fact that backslash is taking up an entire key on your Macintosh, bind it to uppercaseWord or whatever.
It's funny how the original poster complains about tilde but makes no mention of caps lock, the truly useless key on the keyboard. Perhaps caps lock made sense when people were using typewriters, but it makes zero sense when you can accomplish the same thing through software. Occasionally I would like caps lock when I type in a longish macro name (in C, that's what I do all day). Of course I'm not going to enable caps lock (heresy!). I simply wrote a small emacs lisp function that (just look through the current keyboard map and write a replacement function for self-insert-command - gets a little tricky if you want to preserve how kill ring functions (undoes groups of insertions), but not too hard).
Anyway, the problem is not with keyboards but with systems programmers who don't realize that it's necessary to define system-wide keybindings in a flexible manner (this includes rebinding things like caps lock, alt, windows key, windows right-menu key, command, number pad separately from number keys, etc). This goes against any human interface guidelines (consistency, simplicity, etc.), but my mother has no use for backslash or brace or bracket, whereas I use these as much as any other key in C. Different people have different needs.
I think this allusion is lost on the majority of Slashdot readers. One of Mussolini's "accomplishments" is that he "made the trains run on time." Whether or not this is true, it doesn't matter - it was a very effective work of propaganda.
You should look into thttpd. It has some very robust throttling features and a concurrency model that makes sense. It's also usually faster than apache for just downloading files (and if you're just serving up files and not dynamic content, there's not much point to using apache).
Here is the section that explains how throttling works. From what I understand you would like to do, you would set up some directory trees:
site.com/anonymous/
site.com/registered/
site.com/paid/
etc.
Each of those directories contains symlinks to the files you're serving, and a .htaccess password file (the symlinks point into the /anonymous section (or whatever is the "lowest" class) so it won't help people if they start guessing URLs and it's still within the site's main directory so you can still use thttpd's chroot feature). You then use thttpd's throttling features to limit the bandwidth in each directory hierarchy however you like (using simple URL patterns). Users will like it since when they click on a link, it just pops up a standard password dialog box and the browser keeps track of the password if they download multiple files in a hierarchy.
This will literally take you only minutes to set up: thttpd has no dependencies or important compile-time options to worry about, it compiles in seconds and it has one central configuration file that's small, simple and well-documented. In addition, thttpd has never had any major security holes, it has an excellent concurrency model that keeps serving up files without bogging down the machine even under immense loads, and the throttling features are well thought-out
The option you missed is that Linux is excellent for compute clusters. If the render farm runs Linux, putting the design tools on Linux might save time/money in integration issues and codebase maintenance. In the Windows world, "cluster" means database server farm, not compute cluster. I don't even know if Windows has tools like MPI or mosix.
ingram% telnet www.asiacarrera.com 80
Trying 209.163.238.131...
Connected to asiacarrera.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Thu, 13 Feb 2003 02:32:47 GMT
Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) PHP/4.0.4pl1 mod_perl/1.21 FrontPage/4.0.4.3
Last-Modified: Thu, 02 Jan 2003 01:59:58 GMT
ETag: "50013-1cc7-3e139d1e"
Accept-Ranges: bytes
Content-Length: 7367
Connection: close
Content-Type: text/html
Connection closed by foreign host.
You may be missing the humor inherent in the original poster's comment:
I don't know what amazes me more; the fact that Linux is being used by professional artists to create blockbuster films... or the fact that application developers are still using Tk!
Tk is a graphics toolkit. It's also a suck-ass graphics toolkit, and it's also impossible to separate from a suck-ass language called TCL (pronounced "tickle"); you can get Tk bindings for perl, python, etc., etc. but it still requires TCL. TCL/Tk is so suck-ass that I find it hard to believe that someone would actually consider using it for a new project - thus, it's incredible.
In all fairness, TCL/Tk was the only GUI scripting environment for Unix many years ago. Back in the day, your choices for X11 GUI toolkits were TCL/Tk (suck-ass), Motif (costs $$), Athena (looks nasty, confusing semantics), or DIY with Xlib (which isn't as hard as it sounds, but takes time). Nowadays we have really nice toolkits like Qt and wxWindows (and GTK for those who refuse to program in C++), but the pyhon and perl people still consider Tk the "canonical" toolkit for their languages. Really a pity, since wxPython is much nicer RAD environment.
Very cool. I'm buying it.
I didn't mean to sound harsh - that's just sort of how I usually write. Like I said, AoA rocked, even when it was just 16-bit stuff - it's just that the programming environment (DOS) left something to be desired. My university didn't offer anything in the way of assembly programming (just some architecture courses, and a compiler course that generated SPARC v8, but it had plenty of theoretical CS stuff, so I'm not complaining too much). AoA was how I really got into assembly programming. There's a certain rush you get from programming directly to the machine. I wouldn't be doing the stuff I'm doing now if I hadn't read AoA.
Thanks very much for AoA. I'm looking forward to your next book as well.
That would be great, but apparently "new user" means "anything within the past year." I've been reading slashdot since late 1999 (when they first introduced accounts), but didn't sign up until last year. Kind of annoying.
Now protected mode x86 isn't all that different, but there are significant differences. You never use BIOS or DOS (heh) calls but instead link to C libraries and (maybe) use system calls directly. You never have a chance to use "port" IO unless you're writing a device driver (and even there it's limited with modern devices). If you have a modern OS (anything except win9x), you don't have to deal with segments but have a flat memory model (by default, you can't even define your own segments (LDTs) in some OSes). The only time you really deal with "segmentation" is when you're setting up your GDTs and call gates in the OS boot sequence, and there it's not really the same thing as 16-bit segmented memory model at all.
I read through AoA a couple of years ago. It was a real pain in the ass to actually set up a DOS environment where I could do any work (ended up using VMWare to run DOS, while actually writing all my real code on the Linux side using nasm and vi (hint: make a hard link to a VMWare virtual disk to bypass file locking semantics and you can mount it r/w while it's being used by your DOS session - very dangerous, but very convenient). Even then, I picked up a copy of 386intel.txt to figure out how to set up a protected mode environment and started writing a kernel right away - stayed away from that 16-bit crap as much as possible.
The book would really be more useful if it didn't deal with all that 1989 DOS crap and dealt with some more interesting issues. People who still write x86 assembly write compilers, device drivers, low-level OS bits, and inner loops (especially for games/media players/encoders/etc). None of this happens in 16-bit mode, and things are very different in 16-bit mode compared to protected mode. Most optimizations I can think of that improved code on 386/486 running DOS actually ends up SLOWER on P4s and Athlons running protected mode. Optimizing modern x86 CPUs is a completely different beast.
Some other improvements I'd like to see in this kind of book: cut out all the tables listing IO addresses and DOS/BIOS INT calls. Instead add a bit describing how different environments have different calling semantics for C functions and system calls. Maybe avoid the masm-specific stuff (I don't even think masm is available anymore unless you download the Windows DDKs, and even there, I don't know if it will produce 16-bit code - at one point, some old 16-bit version of masm was available for free on Microsoft ftp, but I doubt it's still there). It's pretty hard to use this book as-is because you have to set up some kind of DOS environment.
But anyway, this book still rocks. It's where I learned x86 assembly which then launched me into the low-level kernel stuff. If you know SPARC, PPC or MIPS, do not assume that x86 is more of the same. You think SPARC register windows are nasty? You ain't seen nothing yet. x86 assembly (especially the low-level stuff in Intel's volume 3 CPU reference, the systems programming stuff) is so immensely nasty that you get an unnatural sadistic joy out of writing some tight code - it's kind of like writing a sendmail.cf from scratch.
Glad to see this in dead-tree form - I might pick up a copy for my library. If it has a nice lay-flat binding, it'll be much more convenient than the PDFs.
If you want to learn this stuff, you'll also need these. The modern ones are kind of verbose since there's so much that's been tacked on to modern x86 CPUs...you may prefer an older version. Try one of these.
If you run -CURRENT, you'll run into lots of bugs, and writing good bug reports means delving into the code, so you end up reading lots of code and solving lots of adminny-type problems if you run -CURRENT. Not recommended for important servers, but fun to play with nonetheless. FreeBSD lets you decide precisely where to draw the line between rock-solid (-RELEASE) and bleeding-edge (-CURRENT).
The admin stuff is important because it often means avoiding writing lots of code; eg, you can avoid writing a couple thousand lines of code with a 15-line shell script. I often marvel at how some smart people don't know how to use the right tool for the right job (like spending days trying to do text manipulation in matlab, where the problem can be solved with ten lines of perl, or writing a complex network daemon from scratch, where the problem could be solved with a 100-line patch to an existing program they didn't know about). Saves weeks of time. Best way to learn the admin stuff is to run one of the BSDs (or Slackware) and avoid the hand-holding distros. With a BSD or Slackware system, you can rewrite all the machine's boot scripts in an afternoon (cutting out all the cruft you don't need), something which is nearly impossible with, say, Redhat, which has deep layers of abstraction you have to rip through before getting to what you need.
Example: I recently had to write a daemon did something whenever it noticed a new file in a certain directory. Well, this is pretty easy, since you only have to periodically look at the directory's modification time to see if you need to re-read it (open at start and fstat poll - this is the only efficient way to do it portably). You run into some subtle issues, however, as files may be added or deleted in between when you check the mod time and read the directory, and files may be added just after you check the directory (within the same second, so the mod time isn't changed). Writing the correct code to avoid these race conditions takes an hour or two. After having wriitten it, I was compiling the latest version of KDE or GNOME or something, which means tracking down dependent libraries manually, figuring out what they do, fixing any compilation problems, etc. I then learned about libfam, which is used by one of these things and does exactly what my code did. Had I been running one of the hand-holding distros, which automatically solves dependencies, I would have never learned about it.
Very clever. HTTPS protects against man-in-the-middle attacks, so it will be very unlikely that someone could take over an existing connection for any extended period of time.
Keeping a browser window open might be annoying - not a big deal for us Unix folks (background wget or something), but your Windows users might complain. You might consider writing an optional Windows application that embeds MSIE via COM and stays in the systray. However, Win32 programming is hellish, and I wouldn't do it :)
If I ever do this again, I'll probably use that HTTPS idea as it's more elegant and more secure than what I came up with.
How do you tell if someone has logged out?
I had a little web page where people could explicitly log out. Of course, I didn't expect people to use that (and they didn't), so I would just time out sessions with a cron job. Nobody complained, but the more correct way would be to examine the rule's timestamp (ipfw -t list), something I didn't do.
OK, now that I look at it, I may have needed "sets" because there were actually two rules for each record. The first one which skipped over the redirect:
And the second one which put the packet through the regular NAT stuff:Now that I think of it, "sets" wouldn't really be necessary as long as you enable/disable the second rule first. Even if it did go wrong, it's just one or two lost packets in the time between the two rules being activated. Even this is unlikely since the user will probably be looking at the results of the authentication page at this time.If you use the divert(4) stuff, you don't need any dynamic rules at all - just pass all the packets into your divert socket and have the program look up the MAC and IP in a database or flat file. Seems somewhat more elegant.
Fun stuff.
The real reason a simple counter IPID is dangerous is because it allows zombie scans. These are scans that are "bounced" off of your machine: attacker A scans machine C using machine B, and user C only sees a scan coming from machine B (HP JetDirect printers work great for such zombies, and are often connected directly to the Internet). Lots of fun stuff you can do with that IPID field :)
The AP is hooked up to a FreeBSD box. The FreeBSD box runs NAT and DHCP. When the box sees a DHCP lease request from an unkown MAC, it gives the client an IP and puts the client in a "sandbox" network. This "sandbox" network redirects all IP packets to port 80 on the authentication server (two different ways to do this - either with dynamic ipfw rules, or directly through divert(4)). The authentication server asks for a username/password. Since you write this stuff yourself, you can integrate it with LDAP/Kerberos/flat files, etc. You can even get creative and set the password to something you print out on a receipt so the clients have to "buy" time from you, with the POS computers hooked up to the auth server, etc.
Once the client authenticates, you modify the ipfw rules that redirected packets to the local machine so that packets run through the normal NAT stuff. You can also set up a cron job to delete stale entries so people have to re-authenticate every now and then.
If you do this with ipfw, it's just a couple rules. I ran into some problems doing it this way, so I wrote a little C program that directly inspected packets and passed them along using FreeBSD's divert(4) interface. (I get paid to do these sort of things for people, so the code ain't mine to give away and it would be pretty useless anyway since there's a lot of coding and admin work involved in integrating it).
For real security, you'll need to pass all packets through such a custom program anyway, so you can inspect whether or not that particular IP (given from a DHCP lease) has authenticated recently. You'll also need an AP that passes along MAC addresses unmodified. I know Cisco Aironets allow you to do this, and I know Linksys APs don't (Linksys APs are based on a Lucent chip that's used in lots of other APs like the Apple Airport).
Note that someone with enough expertise can sniff the network, get a valid IP, DOS the real client, and then impersonate the already-authenticated MAC and IP. All systems which work in the way you described are vulnerable to this type of attack.
Not a whole lot you can do to fight this; however, a while back, some guy submitted a paper to Slashdot about how you can tell if someone is spoofing a MAC based on some peculiarities with how most 802.11b cards handle a sequence number in the 802.11 protocol. I'm guessing his paper is new enough that none of the people who sell these pre-built systems implemented his idea, but if you do your own, you're free to implement whatever you want. Note that using this is still not foolproof (search my posting history for an example of an attack against a system which would use this idea and for the link to the original article).
Basic conclusion: there is no bulletproof system which does what you need. If you implement it correctly (with an AP that passes along MACs unmolested in bridge mode), it makes it more difficult, and if you implement the anti-spoofing thing I mentioned, it just ups the bar even more, past the level of the script kiddies. Judge your security needs: such a wireless access system can be good enough if you ensure your confidential data is behind a real authentication system and is never sent over the wire clear-text. If you're worried about someone (someone capable) stealing 'net access from you, you should probably stay away from wireless.
You seem to be looking for a pre-built system that does this sort of thing. Although I'm sure someone is selling this sort of thing, it's probably not popular because there are so many variables involved with integrating it into your existing infrastructure (cabling, routing, authentication systems, etc). Generally, you would get a competent consultant to build something like this for you if you don't have the requisite programmers and networking gurus. If you want to avoid the consulting fees, pick up some Richard Stevens books to learn networking and programming, and start running -CURRENT to learn proper system administration :)
Have fun.
Incorrect conclusion. Going by these comments, very few slashdot readers use NetBSD. In fact, I'm willing to bet that the majority of the slashdot GNU/hippies that rant on and on against Microsoft and fawn over Linux are all too happy to activate their Windows XP and click about in their MSIE. I make this judgment from the complete dearth of technical information in slashdot comment pages.
Of course, this is quite hypocritical of me as here I am adding no useful technical information. In all honesty, I've never had the chance to use NetBSD for any significant task. I know (and love) FreeBSD and OpenBSD inside and out I've only put NetBSD on esoteric machines that don't run the other BSDs quite as well (really old Macs and Sparcs).
Anyway, congratulations to the NetBSD folks. The next time I need to do something useful with strange hardware, I know where to look.
A couple of years ago, I went on vacation with no net access and only my laptop. I wanted to do network programming during my vacation. I set up four VMWare virtual machines running FreeBSD and did my little program (user-mode NFS server). Got a lot done in a short time (probably due to the lack of net access - had all the necessary docs saved ahead of time). I chose FreeBSD because it was much easier to cut down to a tiny image than any Linux distro (even Slackware, my favorite).
VMWare is also useful if you want to do OS-level programming (eg, write a kernel). This is one of my spare time projects (haven't touched it in years, though). I'd imagine user-mode Linux can't let you mess with the low-level stuff, but it could be useful for high-level stuff like scheduling algorithms and so forth (useful because it's a real PITA to boot up a machine whenever you change a line of code and user-mode Linux might give you some better debugging options than a serial cable).
You might be able to do this with Bochs nowadays, but Bochs was nowhere near useful back then. Seems to have come a long way in a short time.
Not sure what advantages user-mode Linux would have over VMWare or Bochs. Perhaps some karma whore would like to register and post the contents of the article :)?
I've written a couple of larger projects which I've never released. A window manager (30000 LOC), a file manager (20000 LOC), etc. I've also written larger projects that I have released under BSD license (web and ftp daemons, ldap gateways, etc.).
There is a pattern. I release/publish code that will probably be used by clueful admins, and I don't release any graphical software.
Why? Because I don't want to deal with twits like you. I write code because I like to write code and because I need the stuff I write. I don't write code for fame or glory, and if I release something, it's because someone else might find it useful and I'm really a nice guy. I don't write code so I can be your personal fucking tech support line. I'll be happy to explain to you how to get mplayer working because I'm not some anti-social recluse and I'll fix any bug or portability issue in my code since I take pride in my work, but I won't give you the time of day if you continue with that attitude. The mplayer lists are probably inundated with comments like yours and I honestly don't know how they can continue writing their code.
So yeah, take it and be grateful or leave it and STFU. Just don't complain to me.
Fair enough - but then why should any of us give a rat's fried patoot about freeing that DeCSS guy, or that Ogg Theora stuff, when it's plain as day that I'll never view a video with code based on it anyways?
Separate issue - you might care about open formats, DRM and the DMCA when your computer turns into a TV and you can no longer play your CDs in your device of choice. The GNU/slashdot folks like to mix all their politics together, but you can release all the code you like and use only OSS on your machines and still work for the MPAA (like some effects studios), or conversely, you can keep using your Windows XP and clicking through life without releasing a line of code, while donating to the EFF.