>Network buffers locked by drivers : 0
>Total network buffer allocations : 118690514
>Total failed network buffer allocs : 0
>Total free while locked events : 0
>IP fragment buffer size : 0
>
>so it looks like it continue to leaks.. the only devices in use are :
>
>[adam@eax patch]$ /sbin/route
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
>sul-net * 255.255.255.0 U 0 0 12 eth1
>dorm-net * 255.255.254.0 U 0 0 571 eth0
>local-net * 255.0.0.0 U 0 0 51 lo
>eax-net * 255.0.0.0 U 0 0 4 eth0:1
>default fa1-0.rch1gw.ne 0.0.0.0 UG 0 0 1439 eth0
>
>
>
>- -Adam
>
>
>------------------------------
>
>From: linux kernel account <linker@nightshade.z.ml.org>
>Date: Wed, 15 Oct 1997 15:11:25 -0400 (EDT)
>Subject: Re: monitoring entropy
>
>On Wed, 15 Oct 1997, Ingo Molnar wrote:
>
>> time? I'm no cryptography dude, but i did read about the 'black box'
>
>Even the crypto dudes agree: What we do is fine..
>
>> Think about it. We cannot generate infinit amount of random output, based
>> on a finit amount of random input. Ie. the output wont be random. The more
>> output you give, the more information you expose, isnt it so?
>
>Right, but you can generate cryptographily strong output. I.e. output that
>is very difficult to figure out.. Random = Impossible to guess.
>Crpytographicly strong = very difficult to guess. Very difficuly = more
>computer power then your or I could ever see..
>
>There are even some arguments in Applied Crypto about cracking very
>difficult systems.. The assume eaisest case computation on a 128-bit key
>and show that it would take an obserd amount of energy to drive an Ideal
>computer to bruteforuce the keyspace.. I'm sure the same thing could be
>said here..
>
>
>------------------------------
>
>From: Ingo Molnar <mingo@pc7537.hil.siemens.at>
>Date: Wed, 15 Oct 1997 22:16:19 +0100 (MET)
>Subject: Re: monitoring entropy
>
>On Wed, 15 Oct 1997, linux kernel account wrote:
>
>> Right, but you can generate cryptographily strong output. I.e. output that
>> is very difficult to figure out.. Random = Impossible to guess.
>> Crpytographicly strong = very difficult to guess. Very difficuly = more
>> computer power then your or I could ever see..
>
>i'd just like to see someone state that 'the difficulty of cracking the
>output does not scale with the amount of output'. I've shown you a simple
>crypto system that is safe, but the probability to guess the key scales
>with the amount of output... just about linearly, with a constant
>multiplicator that is quite small.
>
>- -- mingo
>
>
>
>------------------------------
>
>From: linux kernel account <linker@nightshade.z.ml.org>
>Date: Wed, 15 Oct 1997 15:16:31 -0400 (EDT)
>Subject: Re: monitoring entropy
>
>On Wed, 15 Oct 1997, Ingo Molnar wrote:
>
>> Now, hashes clearly more complex than a XOR, but is it proved that it
>> cannot be inverted, even when we pass it _known_ text?
>>
>> lets call this phenomemon 'key aging'. Any key will age, since the
>> information passed is never trully random, thus it can be predicted, and
>> the key can be recovered if enough information is passed.
>
>Then by reading lots you can only age the key quicker.. The key is
>refreshed from real randomness (which you are prob generating by writing
>you evil cracking data to the disk).. Even assuming it isn't refrshed you
>still have to crach SHA..
>
>
>------------------------------
>
>From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>Date: Wed, 15 Oct 1997 15:22:45 -0400
>Subject: Re: monitoring entropy
>
>OK, let me try to explain some of these issues.
>
>First of all, consider how the MD5 or SHA hash function works. (We're
>using SHA, not MD5, but at a high level they have the same interface).
>It takes some large amount of data, in blocks of 64 bytes, and produces
>16 (or in the SHA 20) bytes of hash output.
>
>Since the size of the input type is much larger than the output type,
>there will of course be many cases where two input texts, X and X'
>produce the same MD5 or SHA checksum. The design criteria of a crypto
>checksum like MD5 or SHA is this:
>
> * Given some input text X, there is no method better than brute
> force guessing of finding another input text X' which
> has MD5/SHA checksum as X. (Where brute force guessing
> will take 2**64 tries for MD5, and 2**80 tries for SHA.)
>
> * Given some MD5/SHA checksum C, there is no method better than
> brute force guessing of finding some input text X where
> f(X) == C.
>
>Since it is considered extremely hard (2**64 is a very large number),
>all you need to do in order to "prove" that MD5 is broken is to present
>two input texts which hash to the same MD5 value.
>
>Now, we're not using SHA in a traditional way a crypto checksum gets
>used, though. Here, we have a pool which contains 4096 bits. At the
>simplest level (taking out all of the other design tricks which makes
>life *harder*), Each time we want to extract 40 bits of entropy, we
>compute the hash of the entire pool, which for SHA is 80 bits. We then
>fold the result in half using XOR, and so we only end up revealing 40
>bits of information about the actual hash value of the pool. The
>original hash value is then mixed into the pool using a Generalized
>Feedback Shift Register.
>
>Now then, "breaking" the generator involves trying to figure out the
>internal state of the entropy pool given only the output from the random
>number generator. To analyze the worst case, we assume that we're not
>getting any additional input into the entropy pool from interrupts, etc.
>
>Obviously, if you only know 40 bits of information generated from a
>single extract operation, there's not enough information to deduce the
>state of the 4096 bit pool. And even with MD5, no one has managed how
>to devise an algorithm which can find a *single* candidate input text
>which when hashed produces a particular hash value. Here, the attacker
>only knows half the information of the hash value, and it doesn't matter
>if the attacker can find some particular input text value; the attack
>has the find the *right* input text value which corresponds to the
>entropy pool.
>
>Hence, even if someone were to announce that they had broken MD5 or SHA,
>they still would not have necessarily broken the random number
>generator, even if you give them the simplest version of the problem
>with a lobotimized random number generator as described above.
>
>Obviously, someone wouldn't have a prayer of even trying to break the
>output of the random number generator unless they had obtained at least
>4096 bits. That's simply a matter of phyics --- or in this case,
>mathematics. But that's assuming that the mixing and hashing process
>was "perfect" in that each time it revealed 40 bits of new information
>about the original hash pool state.
>
>Hence, this is almost certainly much, much harder than doing a
>traditional cryptoanlysis on a cipher key. A brute force attack would
>involve trying every single permutation of the original 4096 entropy
>pool to see if you can find the one which generates the random stream.
>This would take on average 2**2048 tries, which is a very, very, very,
>large number. It may be possible to find a correlation attack which
>would take less time, but certainly no one has derived one to date, and
>doing so would require a theoretical breakthrough that would render SHA
>useless as a cryptographic hash function. (In fact, it would probably
>require several theoretical breakthroughs, of which the first one would
>render SHA useless.) While this could happen, I suspect it is fairly
>unlikely that it will.
>
> - Ted
>
>
>------------------------------
>
>From: "Richard W. Bowser" <bowser@luz.cs.nmt.edu>
>Date: Wed, 15 Oct 1997 13:30:04 -0600 (MDT)
>Subject: Re: Upgrading
>
>On Wed, 15 Oct 1997, Michael P. Blinn wrote:
>
>> I'm sure this has come up before, but it hasn't come up within the time
>> I've been following the list.. Pre-apologies for repetition.
>>
>> I've got an old version of Slackware (1.2.13), and in striving for network
>> aliasing and other utilities, I needed to upgrade the kernel. Currently
>> I'm running 2.0.30, 1.2.13, and 2.1.43. Apparently due to the file locking
>> differences between glibc1 and glibc2, I need to recompile all of my
>> fcntl-using binaries with glib, however this only becomes apparent when
>> running 2.1.43, not 2.0.30 (??) (2.1.43 needed for parport support).
>>
>> I'm kind of at a loss. I need to upgrade my kernel to use parport, but if
>> I do, pop3, etc doesn't work until I recompile it and the other fcntl-
>> using binaries (At least, I think this is what it is.. Much digging and
>> the only clues I've come up with point there.. I'm also having a whale of
>> a time trying to recompile pine for my users.. :(
>
>>
>> It has stroked my curiosity though, and I'm wondering the exact nature
>> behind the beast.. (And if there is a way around it! I'm stuck now,
>> because I cannot upgrade to the newer kernels until I can get pine to
>> recompile.. otherwise it ALWAYS opens the mailboxes as readonly).
>>
>> Anyone have a light to shed on this?
>>
>> Many many MANY thanks,
>> Michael Blinn
>>
>
>I recently upgraded from 2.0.30 to 2.1.42, and I found that between the
>2.0 series of kernels and the 2.1 series there was a big change in methods
>for connecting various parts of the system software. The effects of this
>change are numerous, subtle, and deep. You will need to untar the new
>kernel source tree, modify Rules.make (delete the "-k" in line 166 from
>"$(GENKSYMS) -k"), and then build the kernel. Then you can install the new
>gcc, the new libc5, new binutils, etc.... When you get all the support
>software in, you can build and install the new modutils package. Then,
>finally, you can restore the original Rules.make and build the kernel once
>more. (Modutils must be built with a 2.1.xx kernel to get a genksyms
>which can run under the 2.1.xx kernel, but the 2.1.xx kernel wants the new
>genksyms to build the kernel.)
>
>You could, perhaps, wait for someone to release a new distribution based
>on the 2.1 series kernels, but that would probably mean waiting until the
>2.2 (stable) series of kernels comes out. If you want to use the 2.1
>(development) series of kernels in production there is a bit of work to do
>first with installing all the needed updates.
>
>As far as your troubles with Pine go, I can't help you much there. I
>deleted all my mail and removed the mailboxes first, and then invoked pine
>again under the new kernel/support system to rebuild the mailboxes. I had
>no problems with that on my system.
>
>See http://www.cviog.uga.edu/Misc/info/ChangesDevelopment.html for details.
>
>Good luck!
>Rich Bowser
>
>
>
>
>
>
>------------------------------
>
>From: "Richard W. Bowser" <bowser@luz.cs.nmt.edu>
>Date: Wed, 15 Oct 1997 14:02:06 -0600 (MDT)
>Subject: Re: Upgrading
>
>On Wed, 15 Oct 1997, Michael P. Blinn wrote:
>
>> I'm sure this has come up before, but it hasn't come up within the time
>> I've been following the list.. Pre-apologies for repetition.
>>
>> I've got an old version of Slackware (1.2.13), and in striving for network
>> aliasing and other utilities, I needed to upgrade the kernel. Currently
>> I'm running 2.0.30, 1.2.13, and 2.1.43. Apparently due to the file locking
>> differences between glibc1 and glibc2, I need to recompile all of my
>> fcntl-using binaries with glib, however this only becomes apparent when
>> running 2.1.43, not 2.0.30 (??) (2.1.43 needed for parport support).
>>
>> I'm kind of at a loss. I need to upgrade my kernel to use parport, but if
>> I do, pop3, etc doesn't work until I recompile it and the other fcntl-
>> using binaries (At least, I think this is what it is.. Much digging and
>> the only clues I've come up with point there.. I'm also having a whale of
>> a time trying to recompile pine for my users.. :(
>
>>
>> It has stroked my curiosity though, and I'm wondering the exact nature
>> behind the beast.. (And if there is a way around it! I'm stuck now,
>> because I cannot upgrade to the newer kernels until I can get pine to
>> recompile.. otherwise it ALWAYS opens the mailboxes as readonly).
>>
>> Anyone have a light to shed on this?
>>
>> Many many MANY thanks,
>> Michael Blinn
>>
>
>I recently upgraded from 2.0.30 to 2.1.42, and I found that between the
>2.0 series of kernels and the 2.1 series there was a big change in methods
>for connecting various parts of the system software. The effects of this
>change are numerous, subtle, and deep. You will need to untar the new
>kernel source tree, modify Rules.make (delete the "-k" in line 166 from
>"$(GENKSYMS) -k"), and then build the kernel. Then you can install the new
>gcc, the new libc5, new binutils, etc.... When you get all the support
>software in, you can build and install the new modutils package. Then,
>finally, you can restore the original Rules.make and build the kernel once
>more. (Modutils must be built with a 2.1.xx kernel to get a genksyms
>which can run under the 2.1.xx kernel, but the 2.1.xx kernel wants the new
>genksyms to build the kernel.)
>
>You could, perhaps, wait for someone to release a new distribution based
>on the 2.1 series kernels, but that would probably mean waiting until the
>2.2 (stable) series of kernels comes out. If you want to use the 2.1
>(development) series of kernels in production there is a bit of work to do
>first with installing all the needed updates.
>
>As far as your troubles with Pine go, I can't help you much there. I
>deleted all my mail and removed the mailboxes first, and then invoked pine
>again under the new kernel/support system to rebuild the mailboxes. I had
>no problems with that on my system.
>
>See http://www.cviog.uga.edu/Misc/info/ChangesDevelopment.html for details.
>
>Good luck!
>Rich Bowser
>
>
>
>
>
>
>
>
>
>------------------------------
>
>From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
>Date: Wed, 15 Oct 1997 15:32:36 -0400
>Subject: Re: monitoring entropy
>
> From: "Michael K. Johnson" <johnsonm@redhat.com>
> Date: Wed, 15 Oct 1997 10:54:24 +0500
>
> >While we're on the topic of /dev/random, shouldn't the saved state file be
> >readable only by root (to prevent knowledge of the starting state stored in
> >the file combined with knowledge of the startup sequence from yielding
> >information about the resulting state of the randomizer)? There is no
> >mention of this in the comments in random.c, and RedHat release 4.2
(based on
> >2.0.30) leaves the file readable by all.
>
> I'll answer here, despite this not being absolutely a kernel issue...
>
> Well, it's not a big deal, since that stored entropy is not counted in the
> entropy count, it's only added entropy, stirred in to the pool. It does
> not replace the current state of the pool. So it being visible isn't a
> serious problem. That's probably why Ted didn't make it mode 600 when he
> wrote the script.
>
>The other, more important reason why it's not a big deal is here's what
>happens at boot time:
>
>1) Mix seed file into entropy pool.
>2) Extract new random numbers using /dev/urandom and replace the
> seed file with new random numbers.
>
>We also do step (2) above a second time during a clean shutdown of the
>machine. So the original seed file is mixed into the entropy pool, and
>then that file is overwritten so you can't find it again.
>
>The original purpose of the pool is to preserve some of the entropy
>across reboots. Obviously, we can't depend on it since someone might
>read the original seed file while the machine is down. However, it's
>one of these things which can't hurt, and will probably help.
>
> However, future initscripts packages we release (except for possible
> security updates to 4.2, which are on a different branch) will set
> the saved entropy pool state to mode 600. That way no one else will
> worry about it. :-)
>
>Making the file be mode 600 certainly won't hurt. It might help in the
>case where someone knows the contents of the file and the machine
>crashes without going through a clean shutdown. So again, it's one of
>these things which might possibly help, and there's no possible reason
>why anyone else should want to know the contents of that file, so making
>it be mode 600 is probably a Good Thing to do.
>
> - Ted
>
>------------------------------
>
>From: "Richard W. Bowser" <bowser@luz.cs.nmt.edu>
>Date: Wed, 15 Oct 1997 13:50:07 -0600 (MDT)
>Subject: Re: Upgrading
>
>On Wed, 15 Oct 1997, Michael P. Blinn wrote:
>
>> I'm sure this has come up before, but it hasn't come up within the time
>> I've been following the list.. Pre-apologies for repetition.
>>
>> I've got an old version of Slackware (1.2.13), and in striving for network
>> aliasing and other utilities, I needed to upgrade the kernel. Currently
>> I'm running 2.0.30, 1.2.13, and 2.1.43. Apparently due to the file locking
>> differences between glibc1 and glibc2, I need to recompile all of my
>> fcntl-using binaries with glib, however this only becomes apparent when
>> running 2.1.43, not 2.0.30 (??) (2.1.43 needed for parport support).
>>
>> I'm kind of at a loss. I need to upgrade my kernel to use parport, but if
>> I do, pop3, etc doesn't work until I recompile it and the other fcntl-
>> using binaries (At least, I think this is what it is.. Much digging and
>> the only clues I've come up with point there.. I'm also having a whale of
>> a time trying to recompile pine for my users.. :(
>
>>
>> It has stroked my curiosity though, and I'm wondering the exact nature
>> behind the beast.. (And if there is a way around it! I'm stuck now,
>> because I cannot upgrade to the newer kernels until I can get pine to
>> recompile.. otherwise it ALWAYS opens the mailboxes as readonly).
>>
>> Anyone have a light to shed on this?
>>
>> Many many MANY thanks,
>> Michael Blinn
>>
>
>I recently upgraded from 2.0.30 to 2.1.42, and I found that between the
>2.0 series of kernels and the 2.1 series there was a big change in methods
>for connecting various parts of the system software. The effects of this
>change are numerous, subtle, and deep. You will need to untar the new
>kernel source tree, modify Rules.make (delete the "-k" in line 166 from
>"$(GENKSYMS) -k"), and then build the kernel. Then you can install the new
>gcc, the new libc5, new binutils, etc.... When you get all the support
>software in, you can build and install the new modutils package. Then,
>finally, you can restore the original Rules.make and build the kernel once
>more. (Modutils must be built with a 2.1.xx kernel to get a genksyms
>which can run under the 2.1.xx kernel, but the 2.1.xx kernel wants the new
>genksyms to build the kernel.)
>
>You could, perhaps, wait for someone to release a new distribution based
>on the 2.1 series kernels, but that would probably mean waiting until the
>2.2 (stable) series of kernels comes out. If you want to use the 2.1
>(development) series of kernels in production there is a bit of work to do
>first with installing all the needed updates.
>
>As far as your troubles with Pine go, I can't help you much there. I
>deleted all my mail and removed the mailboxes first, and then invoked pine
>again under the new kernel/support system to rebuild the mailboxes. I had
>no problems with that on my system.
>
>See http://www.cviog.uga.edu/Misc/info/ChangesDevelopment.html for details.
>
>Good luck!
>Rich Bowser
>
>
>
>
>
>
>
>
>
>
>------------------------------
>
>From: Jim Dennis <jimd@starshine.org>
>Date: Wed, 15 Oct 1997 13:24:22 -0700
>Subject: Re: [linux-security] Malicious Linux modules (fwd)
>
>>
>> olaf@bigred.inka.de (Olaf Titz) writes:
>> >>Loading modules lets potentially untrustworthy code into your trusted
>> >>environment so the modules need checked first.
>> >Modules operate on _the same_ trust level as the kernel itself. If a
>> >hacker can install a malicious module, he can as well install a
>> >malicious kernel.
>>
>> I think the difference is that in Linux (and most loadable module
>> systems), it's quite easy for an attacker to clandestinely load a
>> module. All they need to do is bring the .o file over, insmod it, and
>> then remove the .o file. The attacking module cloaks itself, and the
>> only trace left is in the kernel memory itself. Even that might not be
>> visible if the module is stealthy enough. You're in a lot of trouble
>> if you can't trust your kernel.
>
> I believe the intent of 'securelevel' is to prevent
> this sort of problem (among several others).
>
> What I don't know is if we're going to have a 'securelevel'
> feature that is compatible with any but the most strictly
> configured servers.
>
> There's some discussion of implementing 'securelevel' as
> a bit field rather than as a simple, montonically increasing
> integer. In that scheme we might be willing to secure the
> system against some things (like chattr/immutable changes,
> and "new" loadable modules) while leaving some potential
> holes open (like ioperm). This would allow us to run X --
> accepting the attendant risks.
>
> I've heard that GGI would solve the problem of running X
> under securelevel 1 -- but none of us really know what sorts
> of other problems that *might* create.
>
> I've heard some debate about kerneld (lkmd in FreeBSD?).
> Some have argued that it whould be given some dispensation
> at securelevel 1 but restricted to modules that are already
> in the dependencies table (depmod) or some other list.
>
> This would give "almost" the same protection -- since the attacker
> would have to introduce a link to new module into the (presumably
> immutable) /lib/modules directory tree and run depmod (which
> need to update the presumably immutable dependencies table).
>
> Presumably we'd completely disable this at securelevel 2
> (i.e. kerneld is inappropriate for those systems -- compile
> a larger kernel and/or have a script do your insmod's prior
> to increasing the securelevel).
>
> I also haven't seen a good, clear, list of which features
> (restrictions) are associated with each securelevel.
>
>>
>> Installing a whole malicious kernel, as far as I know, requires
>> rebooting the machine to load the new kernel. A good sysadmin will
>> note when a machine reboots for no good reason and investigate. So
>> loadable modules make it easier to hack a running kernel. This isn't
>> big news, and shouldn't be considered a Huge Security Flaw. It does
>> give one pause, though.
>
> There is the question of how you'll detect the system
> reboot. If you have a well-configured loghost -- which
> is more secure than the machine in questions (probably
> because it has more restricted trust relationships, no
> user accounts, and runs no services other than syslogd) --
> than you can detect a failed heartbeat, and possible other
> tell tails (depending on how thorough your attacker it).
>
> Short of having a null modem to the more secure system
> configured as the system console I don't see how you
> could ensure that your loghost will see the reboot.
>
> (Once the system is rebooted with a rogue kernel than
> all evidence is up for grabs -- uptime can be changed,
> syslog messages can be forged, log files can be modified,
> etc.).
>
> I suppose you might have a scheme where the system
> gets something like a kerberos ticket (or like the
> Netscape SSL server's requirement that a typist
> enter the passphrase to unlock the server key to
> start the SSL server). Under this scheme the
> system would be unable to start a given session
> server until someone logged in and typed the appropriate
> passphrase. The failure of this server to load would
> be a key that the system had been rebooted.
>
> (Now the attacker has to install a ttysnooper for some
> period of time, long enough to steal the passphrase,
> BEFORE rebooting the system).
>
>
>> It gets a bit trickier to clandestinely install a malicious module
>> that will survive a reboot - you have to put it in the filesystem
>> somewhere and ensure it's loaded at boot time. I imagine there is a
>> way to do this stealthily, but hacking the kernel image itself is
>> probably easier.
>
> Actually it sounds pretty easy to hack the ext2fs code
> along with the kernel/modules and have that version
> of the ext2fs code hide data from user processes. It
> could probably even be done in such a way that unhacked
> ext2fs drivers would view these hidden data structures
> as bad blocks.
>
> For example you might hide your data in "badblocks"
> and have a signature on the "badblock" that points to a
> "hidden inode table" (a small one). If your hacked
> ext2fs driver *actually it a badblock* where it looks
> for this signature it might cause a system lockup -- or
> some timeouts and retries. However a normal ext2 driver
> (from your rescue diskette or CD) wouldn't have any reason
> to question a few hundred badblocks on the system.
>
> I'm not a programmer -- and particularly not a kernel
> hacker. However, it sounds easier to hide data on a
> disk than it does to play hide-and-seek in core.
>
>- --
>Jim Dennis (800) 938-4078 consulting@starshine.org
>Proprietor, Starshine Technical Services: http://www.starshine.org
> PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org>
> Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A
>
>
>------------------------------
>
>From: Network Admin <netadmin@knotwork.com>
>Date: Wed, 15 Oct 1997 18:23:43 -0300 (ADT)
>Subject: Re: Upgrading
>
>On Wed, 15 Oct 1997, Richard W. Bowser wrote:
>> You could, perhaps, wait for someone to release a new distribution based
>> on the 2.1 series kernels, but that would probably mean waiting until the
>> 2.2 (stable) series of kernels comes out. If you want to use the 2.1
>> (development) series of kernels in production there is a bit of work to do
>> first with installing all the needed updates.
>
>I recently updated the Knotwork Distribution to the 2.1.55 kernel. It
>seems to work fine. It is basically a Slackware with all the changes and
>updates I found myself doing over and over again put right into the
>distribution to save having to do them all again each time I install a
>system. The distribution was developed mainly for ISP use.
>
>A CHANGES file is provided that should tell hopefully every step that was
>done in mutating the original Slackware distribution that I started with.
>
>The distribution's home page is
>http://www.knotwork.com/info/comp/freeware/linux/
>
>The main reason I am still using Slackware style packages is that I do not
>need special tools to use them on systems based on other distributions,
>just gunzip and tar and bash are all that are required. I find that more
>generic than having to use special package tools.
>
>Blessed Be. -MarkM-
>
>- --
>We do remote Linux install, config, support and administration. Inquire.
>.........................................................................
>"The saddest thing is they WANT to be ignorant, INSIST on it in fact."
>
>
>
>------------------------------
>
>From: miquels@cistron.nl (Miquel van Smoorenburg)
>Date: 15 Oct 1997 23:26:56 +0200
>Subject: Re: Upgrading
>
>In article <Pine.LNX.3.96.971015134636.4140A-100000@luz.cs.nmt.edu>,
>Richard W. Bowser <bowser@luz.cs.nmt.edu> wrote:
>>You could, perhaps, wait for someone to release a new distribution based
>>on the 2.1 series kernels, but that would probably mean waiting until the
>>2.2 (stable) series of kernels comes out. If you want to use the 2.1
>>(development) series of kernels in production there is a bit of work to do
>>first with installing all the needed updates.
>
>I'm running Debian 1.3.1 (stable released version) and it has everything
>needed to compile and run 2.1.x kernels (2.1.57 for example). Even
>loading modules works O.K.
>
>Mike.
>- --
> Miquel van | Cistron Internet Services -- Alphen aan den Rijn.
> Smoorenburg, | mailto:info@cistron.nl http://www.cistron.nl/
>miquels@cistron.nl | PTT's Het Net: Surfen in de gootsteen!
>
>------------------------------
>
>End of linux-kernel-digest V1 #1225
>***********************************
>
>To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
>in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If you
want
>to subscribe something other than the account the mail is coming from,
>such as a local redistribution list, then append that address to the
>"subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
>A non-digest (direct mail) version of this list is also available; to
>subscribe to that instead, replace all instances of "linux-kernel-digest"
>in the commands above with "linux-kernel".
>