Messages in this thread | | | Subject | Re: Building .config into the kernel | Date | Sat, 16 Jan 1999 16:58:39 -0500 | From | "Brandon S. Allbery KF8NH" <> |
| |
In message <199901162108.PAA01844@wind.enjellic.com>, G.W. Wettstein writes: +----- | > The situation at *this* university is a little different. The | > machine I was working on this afternoon is a case in point: the grad | > student who normally uses the machine put 2.1.131 on it, and I have | > very little idea of how it was configured. And there's no way the | > LCS grad students are going to RPM their kernels.... | | I probably operate out of a different set of assumptions than most | people do. If I am responsible for picking up the pieces of a broken | machine things get done my way on the machine. We have gone round and | round with departments and the like about this issue. If people want | to have the liberty of replacing kernels and rebooting machines they | get to administrate their own machines, problems and all. +--->8
Nice in theory --- but.
The primary rule here is: if it's on our network, WE run it. CMU's a top target for hackers; we can't afford to have sitting targets outside our control on our network. (SCS doesn't use that rule... and they appear to have a *serious* hacker problem, one which occasionally leaks into ECE. But the concerns below apply even more so for them --- after all, we've only LCS doing kernel munging, whereas for them it's quite normal.)
Unfortunately, that doesn't quite work with LCS, as they *need* to be able to boot experimental kernels and the like. These folks spend most of their time playing with derivatives of the MIT exokernel; they use 2.1/2.2pre on non-exokernel machines because it gives them more options for testing and experimenting with the TCP/IP stacks on the exokernel machines.
A separate network has been considered. They've rejected it so far... or rather, so far they haven't decided what they want a separate network to handle and what if any outside access they want to allow. And the development machines pretty much *have* to have access to both ECE's and SCS's AFS servers... and masquerading for AFS clients is a royal pain; it looks like I'd have to permanently allocate a block of ports on the masquerade server and permanently map them to ports 7000-7003/udp (at least) on the clients. (The AFS servers have long memories as to which ports the clients are using. I wish rx had a TCP option....)
I'm not in a position to work on 2.1/2.2pre support for them, beyond trying to make sure things don't break too badly, i.e. fixing the 2.2-unfriendly warts in Red Hat 5.2 (/etc/rc.d/init.d/kerneld, util-linux-2.8, etc.) and trying to get a stable enough Arla configuration that they can at least try to work in the heavily AFS-oriented CMU environment. And I can't build "approved" 2.1/2.2pre kernels for them because they might well be patching them (and regularly revising the patches) to support torture of exokernels :-) (And no, I'm don't claim to be smart enough to keep up with these grad students. As if I haven't made that obvious regularly on this list :-)
So a decent way to recover the configuration of a running kernel would be a great help around here.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH We are Linux. Resistance is an indication that you missed the point.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |