From jkosin at beta.intcomgrp.com Tue Oct 4 14:04:10 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 04 Oct 2005 10:04:10 -0400 Subject: Web-Page for James' Updates. In-Reply-To: References: Message-ID: <43428BDA.5030709@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Eisenstein wrote: |On Tue, 27 Sep 2005, James Kosin wrote: | |>This may be easier than writing a long detailed email all the time. |>Everyone can get / see updates via my newly created web-page at |>~ http://support.intcomgrp.com/~jkosin | | |Hi James, | |I've looked at your page and like the page. I guess I am one of the few |on this list who uses Fedora Core 1, but I like the idea that you're out |there publishing some updated (of course, unguaranteed, but updated) |packages that I can use on my FC1 install. I run FC1 because I like it, |and because it's a pain to upgrade to a newer version every six months, |especially with a 56kbps Internet connection. | |I think you've hit upon an optimal solution: much shorter mail announce- |ments with pointers to your web-page. Your long announcements confused me. | |I would also encourage you, James, to consider also contributing some of |your time to the business of the Fedora Legacy project, by occasionally |diving into one of the Bugzilla bugs listed in our "to do" list and either |creating new packages or QA'ing exising ones. | |If you need any help with that, let me know. Thanks. I'm glad I'm making a difference. I'll be glad to help with the QA'ing if I use the package enough. But, some QA'ing is very difficult. Some things to consider.... (1) Kernel updates are very difficult to QA. If you don't have the involved HW, it does very little to QA the kernel; because, most of the code elsewhere has not changed. And even if you do have the hardware, sometimes the changes impact things elsewhere in the code negatively for other users that don't have the hardware. (2) Even simple changes need extensive testing sometimes, especially if the impact is on a section of code that everything traverses multiple times. I'll have to take a look at the packages that need work.... I might have time later this month. | |>For now; I'm open to comments on how to modify or make the page |>better. I've never been very good at creating fancy pages. I usually |>like to keep the pages simple. | | |Me too. If it's readable and usable and works, I say, "Don't fix it." |Looks good to me. | -David | Thanks again. I'll try and keep it simple; but, the updates are quite numerous now. I may need to reorganize later in the year. - -James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDQovakNLDmnu1kSkRA8AdAJ9vFKJoOhqdo2zI5FHNs7oR2l9prQCfS46k UjRdj0YVufxGi4Ktu4t/AMg= =aTPc -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From gene.heskett at verizon.net Mon Oct 10 14:48:25 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 10 Oct 2005 10:48:25 -0400 Subject: Has tar-1.15.1 been built & released for rh7.3? Message-ID: <200510101048.25212.gene.heskett@verizon.net> Greetings all; See subject for question. If it has been done, please advise url of download. I cannot build it on that box, and the rpms I've been able to try all need a newer GLIBC. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From sheltren at cs.ucsb.edu Mon Oct 10 16:59:19 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 10 Oct 2005 12:59:19 -0400 Subject: Has tar-1.15.1 been built & released for rh7.3? In-Reply-To: <200510101048.25212.gene.heskett@verizon.net> References: <200510101048.25212.gene.heskett@verizon.net> Message-ID: On Oct 10, 2005, at 10:48 AM, Gene Heskett wrote: > Greetings all; > > See subject for question. If it has been done, please advise url of > download. I cannot build it on that box, and the rpms I've been > able to > try all need a newer GLIBC. > Hi Gene, officially, 7.3 will only support tar-1.13. Are you having problems with that version? Or just wanted something newer? -Jeff From gene.heskett at verizon.net Mon Oct 10 21:43:48 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 10 Oct 2005 17:43:48 -0400 Subject: Has tar-1.15.1 been built & released for rh7.3? In-Reply-To: References: <200510101048.25212.gene.heskett@verizon.net> Message-ID: <200510101743.48536.gene.heskett@verizon.net> On Monday 10 October 2005 12:59, Jeff Sheltren wrote: >On Oct 10, 2005, at 10:48 AM, Gene Heskett wrote: >> Greetings all; >> >> See subject for question. If it has been done, please advise url of >> download. I cannot build it on that box, and the rpms I've been >> able to >> try all need a newer GLIBC. > >Hi Gene, officially, 7.3 will only support tar-1.13. Are you having >problems with that version? Or just wanted something newer? > >-Jeff I've been running 1.15.1 on this FC2 box now for about 3 months, and it appears to be completey compatible. Then I read someplace where a security hole had been found in pre 1.15 issues, so I thought I'd try to upgrade my firewall box, which is still running 7.3, but with a 2.4.29 kernel. The tarball won't build, make-3.80 finds errs in the Makefile among other objections when I get the Makefile fixed. Extant 1.15.1's in rpm are all for FC4 and need a newer GLIBC. FC4 which I tried to install on another box, was so unstable that after it did the reboot refusal the 7th time out of 10 installs, and only ran maybe 2 minutes after logging in on the other 3 reboots, so the disks went in the out bin, and the iso's got a visit from rm. The newer fedora gets, the more unstable it gets. That same box, with bdi-4.30 (the emc installer cd) is bulletproof, and I have tried to kill it. Thanks Jeff. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From sheltren at cs.ucsb.edu Mon Oct 10 23:22:44 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 10 Oct 2005 19:22:44 -0400 Subject: Has tar-1.15.1 been built & released for rh7.3? In-Reply-To: <200510101743.48536.gene.heskett@verizon.net> References: <200510101048.25212.gene.heskett@verizon.net> <200510101743.48536.gene.heskett@verizon.net> Message-ID: <210B90C2-0C0F-4059-BDDB-B1E21F0F25B7@cs.ucsb.edu> On Oct 10, 2005, at 5:43 PM, Gene Heskett wrote: > > I've been running 1.15.1 on this FC2 box now for about 3 months, > and it > appears to be completey compatible. Then I read someplace where a > security hole had been found in pre 1.15 issues, so I thought I'd > try to > upgrade my firewall box, which is still running 7.3, but with a 2.4.29 > kernel. Hi Gene, the only recent tar report I've seen is regarding tar preserving setuid/setgid information, which is actually the intended behavior of tar, so I am not sure that anyone even patched it. See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2541 and http://marc.theaimsgroup.com/?l=bugtraq&m=112327628230258&w=2 I don't think that there are any other (unpatched) security issues aside from that. -Jeff From gene.heskett at verizon.net Tue Oct 11 00:21:21 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Mon, 10 Oct 2005 20:21:21 -0400 Subject: Has tar-1.15.1 been built & released for rh7.3? In-Reply-To: <210B90C2-0C0F-4059-BDDB-B1E21F0F25B7@cs.ucsb.edu> References: <200510101048.25212.gene.heskett@verizon.net> <200510101743.48536.gene.heskett@verizon.net> <210B90C2-0C0F-4059-BDDB-B1E21F0F25B7@cs.ucsb.edu> Message-ID: <200510102021.21884.gene.heskett@verizon.net> On Monday 10 October 2005 19:22, Jeff Sheltren wrote: >On Oct 10, 2005, at 5:43 PM, Gene Heskett wrote: >> I've been running 1.15.1 on this FC2 box now for about 3 months, >> and it >> appears to be completey compatible. Then I read someplace where a >> security hole had been found in pre 1.15 issues, so I thought I'd >> try to >> upgrade my firewall box, which is still running 7.3, but with a 2.4.29 >> kernel. > >Hi Gene, the only recent tar report I've seen is regarding tar >preserving setuid/setgid information, which is actually the intended >behavior of tar, so I am not sure that anyone even patched it. > >See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2541 and >http://marc.theaimsgroup.com/?l=bugtraq&m=112327628230258&w=2 > >I don't think that there are any other (unpatched) security issues >aside from that. > >-Jeff In that case, and since its working fine with 1.13-25, its possible I miss-read the security advisory. And as that is now a few pages back up the log, making my elderly memory pretty hazy, I'll just let it run till the fenders fall off. And so far, I'm not seeing any signs of rust. :) Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From vherva at viasys.com Wed Oct 12 10:16:51 2005 From: vherva at viasys.com (Ville Herva) Date: Wed, 12 Oct 2005 13:16:51 +0300 Subject: Legacy 7.3 imap-2001a-10.1 and CAN-2005-2933 Message-ID: <20051012101650.GB24742@viasys.com> I don't know if anyone cares about RH73 and imap-2001a anymore, but I think this vulnerability applies to imap-2001a-10.1.legacy too: http://www.idefense.com/application/poi/display?id=313&type=vulnerabilities&flashstatus=false http://www.linuxsecurity.com/content/view/120575 I took the source from http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/imap-2001a-10.1.legacy.src.rpm and modified the mail.c patch from http://www.idefense.com/application/poi/display?id=313&type=vulnerabilities&flashstatus=false to apply to 2001a. It was just a blind patch weeding job - I didn't actually verify that imap-2001a isn't invulnerable to this or vulnerable to something else. I case anyone is interested, here's the modified .spec and the patch. Just do rpm -i imap-2001a-10.1.legacy.src.rpm cp imap.spec.patched /usr/src/redhat/SPECS/imap.spec cp imap-2001a-CAN-2005-2933_fix.patch /usr/src/redhat/SOURCES/ rpm -bb /usr/src/redhat/SPECS/imap.spec -- v -- v at iki.fi -------------- next part -------------- #!/bin/bash %define Build_7 1 %define Build_62 0 %if %{Build_7} %define with_xinetd 1 %endif %if %{Build_62} %define with_xinetd 0 %endif Summary: Server daemons for IMAP and POP network mail protocols. Name: imap Version: 2001a # Last 6.2 release: 2000c-1.6.1, last 5.2 release: 2000c-1.5.1 Release: 10.2.legacy Epoch: 1 License: University of Washington Free-Fork License Group: System Environment/Daemons URL: http://www.washington.edu/imap/ Source: imap-%{version}.tar.bz2 Source1: imap.pamd Source2: imap.pamd.6 Source3: imap-xinetd Source4: ipop2-xinetd Source5: ipop3-xinetd Source6: imaps-xinetd Source7: pop3s-xinetd Source8: flock.c Source9: README.IMAPS Patch0: imap-2001a-redhat-ssl.patch Patch1: imap-2000-linux.patch Patch2: imap-2000-vfs.patch Patch3: imap-2001a-mbox-disable.patch Patch4: imap-2000-krbpath.patch Patch5: imap-2000c-redhat-flock.patch Patch6: imap-2001a-overflow.patch Patch8: imap-2001a-redhat-version.patch Patch9: imap-2001a-boguswarning.patch Patch10: imap-2000-time.patch Patch11: imap-2001a-can-2003-0297.patch Patch12: imap-2001a-CAN-2005-2933_fix.patch Buildroot: %{_tmppath}/%{name}-%{version}-root BuildPrereq: krb5-devel, openssl-devel # DO NOT REMOVE THIS PAM HEADER DEPENDANCY OR FACE THE WRATH BuildPreReq: /usr/include/security/pam_modules.h Requires: pam >= 0.59 Conflicts: cyrus-imapd %if %{Build_7} Requires: %{_sysconfdir}/pam.d/system-auth %endif %if %{with_xinetd} Prereq: xinetd %endif %description The imap package provides server daemons for both the IMAP (Internet Message Access Protocol) and POP (Post Office Protocol) mail access protocols. The POP protocol uses a "post office" machine to collect mail for users and allows users to download their mail to their local machine for reading. The IMAP protocol allows a user to read mail on a remote machine without downloading it to their local machine. Install the imap package if you need a server to support the IMAP or the POP mail access protocols. %package devel Summary: Development tools for programs which will use the IMAP library. Group: Development/Libraries %description devel The imap-devel package contains the header files and static libraries for developing programs which will use the IMAP (Internet Message Access Protocol) library. %prep %setup -q chmod -R u+w . %patch0 -p1 -b .redhat-ssl-patch %patch1 -p1 -b .linux-patch # FIXME: Disabled for 2001a-1 build.. unneeded now? #%patch2 -p1 -b .vfs-patch %patch3 -p0 -b .mbox-disable-patch %patch4 -p1 -b .gssapi-patch %patch5 -p1 -b .redhat-flock %patch6 -p1 -b .overflow %patch8 -p0 -b .redhat-version %patch9 -p0 -b .boguswarning # Only apply the time.h patch to 7.x errata builds %if %{Build_7} %patch10 -p1 -b .time-patch %endif %patch11 -p2 -b .can-2003-0297 %patch12 -p0 -b .CAN-2005-2933_fix cp %{SOURCE8} src/osdep/unix/ cp %{SOURCE9} . %build # Set EXTRACFLAGS here instead of in imap-2000-redhat.patch (#20760) EXTRACFLAGS="$EXTRACFLAGS -DDISABLE_POP_PROXY=1 -DIGNORE_LOCK_EACCES_ERRORS=1" EXTRACFLAGS="$EXTRACFLAGS -I/usr/include/openssl" EXTRACFLAGS="$EXTRACFLAGS -I/usr/kerberos/include" EXTRALDFLAGS="$EXTRALDFLAGS -L/usr/kerberos/lib" %ifnarch sparc make RPM_OPT_FLAGS="$RPM_OPT_FLAGS -fPIC" lnp \ %else make RPM_OPT_FLAGS="" lnp \ %endif EXTRACFLAGS="$EXTRACFLAGS" \ EXTRALDFLAGS="$EXTRALDFLAGS" \ EXTRAAUTHENTICATORS=gss \ SSLTYPE=unix \ # This line needs to be here. %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT%{_mandir}/man8 install -m 644 ./src/ipopd/ipopd.8c $RPM_BUILD_ROOT%{_mandir}/man8/ipopd.8c install -m 644 ./src/imapd/imapd.8c $RPM_BUILD_ROOT%{_mandir}/man8/imapd.8c mkdir -p $RPM_BUILD_ROOT%{_sbindir} install -s -m 755 ./ipopd/ipop2d $RPM_BUILD_ROOT%{_sbindir} install -s -m 755 ./ipopd/ipop3d $RPM_BUILD_ROOT%{_sbindir} install -s -m 755 ./imapd/imapd $RPM_BUILD_ROOT%{_sbindir} mkdir -p $RPM_BUILD_ROOT/etc/pam.d %if %{Build_7} install -m 644 ${RPM_SOURCE_DIR}/imap.pamd $RPM_BUILD_ROOT/etc/pam.d/imap install -m 644 ${RPM_SOURCE_DIR}/imap.pamd $RPM_BUILD_ROOT/etc/pam.d/pop %else install -m 644 ${RPM_SOURCE_DIR}/imap.pamd.6 $RPM_BUILD_ROOT/etc/pam.d/imap install -m 644 ${RPM_SOURCE_DIR}/imap.pamd.6 $RPM_BUILD_ROOT/etc/pam.d/pop %endif ## Install the shared lib #install -m 755 libimap.so.%{version} $RPM_BUILD_ROOT/usr/lib #ln -sf libimap.so.%{version} $RPM_BUILD_ROOT/usr/lib/libimap.so mkdir -p $RPM_BUILD_ROOT%{_libdir} install -m 644 ./c-client/c-client.a $RPM_BUILD_ROOT%{_libdir}/ ln -s c-client.a $RPM_BUILD_ROOT%{_libdir}/libc-client.a mkdir -p $RPM_BUILD_ROOT%{_includedir}/imap install -m 644 ./c-client/*.h $RPM_BUILD_ROOT%{_includedir}/imap # Added linkage.c to fix (#34658) install -m 644 ./c-client/linkage.c $RPM_BUILD_ROOT%{_includedir}/imap install -m 644 ./src/osdep/tops-20/shortsym.h $RPM_BUILD_ROOT%{_includedir}/imap %if %{with_xinetd} #install service configuration files mkdir -p $RPM_BUILD_ROOT/etc/xinetd.d/ install -m644 %{SOURCE3} $RPM_BUILD_ROOT/etc/xinetd.d/imap install -m644 %{SOURCE4} $RPM_BUILD_ROOT/etc/xinetd.d/ipop2 install -m644 %{SOURCE5} $RPM_BUILD_ROOT/etc/xinetd.d/ipop3 install -m644 %{SOURCE6} $RPM_BUILD_ROOT/etc/xinetd.d/imaps install -m644 %{SOURCE7} $RPM_BUILD_ROOT/etc/xinetd.d/pop3s %endif # Generate ghost *.pem files mkdir -p $RPM_BUILD_ROOT/%{_datadir}/ssl/certs touch $RPM_BUILD_ROOT/%{_datadir}/ssl/certs/{imapd,ipop3d}.pem chmod 600 $RPM_BUILD_ROOT/%{_datadir}/ssl/certs/{imapd,ipop3d}.pem %clean rm -rf $RPM_BUILD_ROOT %if %{Build_7} %post # This was 'if with_ssl' before, but due to packaging problems with older # releases handling the logic, I changed it to only happen in 7.x instead # If no cert, migrate stunnel.pem, or generate a new cert pushd %{_datadir}/ssl/certs &> /dev/null || : for CERT in imapd.pem ipop3d.pem ;do if [ ! -e $CERT ];then if [ -e stunnel.pem ];then cp stunnel.pem $CERT &> /dev/null || : elif [ -e Makefile ];then make $CERT << EOF &> /dev/null || : -- SomeState SomeCity SomeOrganization SomeOrganizationalUnit localhost.localdomain root at localhost.localdomain EOF fi fi done popd &> /dev/null || : /sbin/service xinetd reload > /dev/null 2>&1 || : %endif %if %{Build_7} %postun /sbin/service xinetd reload > /dev/null 2>&1 || : %endif %files %defattr(-,root,root) %config /etc/pam.d/imap %config /etc/pam.d/pop %if %{with_xinetd} %config(noreplace) /etc/xinetd.d/imap %config(noreplace) /etc/xinetd.d/ipop2 %config(noreplace) /etc/xinetd.d/ipop3 # These to need to be replaced, or imaps/pop3s will fail after an upgrade %config /etc/xinetd.d/imaps %config /etc/xinetd.d/pop3s %endif %attr(0600,root,root) %ghost %config(missingok,noreplace) %verify(not md5 size mtime) %{_datadir}/ssl/certs/imapd.pem %attr(0600,root,root) %ghost %config(missingok,noreplace) %verify(not md5 size mtime) %{_datadir}/ssl/certs/ipop3d.pem %{_mandir}/man8/ipopd.8c* %{_mandir}/man8/imapd.8c* %attr(0755,root,root) %{_sbindir}/ipop2d %attr(0755,root,root) %{_sbindir}/ipop3d %attr(0755,root,root) %{_sbindir}/imapd %doc CPYRIGHT README WARNING README.IMAPS docs/RELNOTES docs/*.txt %doc docs/CONFIG docs/SSLBUILD %files devel %defattr(-,root,root) %doc docs/* %{_includedir}/imap #FIXME: is this c-client.a necessary? %{_libdir}/c-client.a %{_libdir}/libc-client.a %changelog * Thu Oct 12 2005 Ville Herva 2001a-10.2.legacy - Added security patch for CAN-2005-2933 * Thu Mar 3 2005 Marc Deslauriers 2001a-10.1.legacy - Added security patch for CAN-2003-0297 * Wed Apr 17 2002 Mike A. Harris 2001a-10 - Fixed mbox-disable patch to really disable mbox (#15833) * Wed Apr 17 2002 Bernhard Rosenkraenzer 2001a-9 - Fix overflow in rfc822.c (#60818) * Tue Feb 26 2002 Mike A. Harris 2001a-8 - Updated files list, explicitly listing .pem files to attempt to quell rpmlint warning. * Tue Feb 26 2002 Mike A. Harris 2001a-7 - Rebuilt in new environment * Wed Feb 13 2002 Mike A. Harris 2001a-6 - Put a pam build dependancy back, since pam is used during build, it is required to be there. * Sat Jan 26 2002 Florian La Roche - delete /lib/libpam.so BuildPreReq, it does not exist anymore * Thu Jan 24 2002 Mike A. Harris 2001a-4 - Rebuild in new environment as -3 failed for some obscure cryptic reason, so bumping to -4 to try again. * Tue Nov 20 2001 Nalin Dahyabhai 2001a-2 - Change SPECIALAUTHENTICATORS=ssl to SSLTYPE=unix at build time (the procedure changed for 2001a * Tue Nov 20 2001 Mike A. Harris 2001a-1 - Updated to imap-2001a - Removed USERID option from all xinetd config files to fix (#56279) - Modified all xinetd conf files to use the following log options instead log_on_success += HOST DURATION log_on_failure += HOST - Removed Build_52 target define, and with_ssl, with_ssl_cert, with_krb5 conditionals, as they are no longer needed now because all supported releases currently support SSL and kerberos. - Updated imap-2001a-redhat-ssl.patch, imap-2001a-mbox-disable.patch - Removed imap-2000c-security.patch, and imap-2000c-morefixes.patch as they are now integrated in 2001a * Thu Oct 11 2001 Mike A. Harris 2000c-17 - Rebuilt with pam auth files for 6.2 errata (1.6.1), and 5.2 errata (1.5.1), and put master release in rawhide as 2000c-17, so future releases come from current RPM. * Tue Jul 24 2001 Mike A. Harris 2000c-14 - Removed conditional with_pamauth, and replaced with better solution, fixing bug (#49604) - Enabled ghost cert files and cert creation for all SSL builds. - Removed macro from release tag to allow spec release bumping. * Sat Jul 21 2001 Mike A. Harris 2000c-13 - Add bpr on pam-devel (#49501) * Thu Jul 19 2001 Mike A. Harris 2000c-12 - Enabled file ownership/ghosting of pem files. (#43400) * Wed Jul 11 2001 Tim Powers 2000c-11 - rebuilt for 7.x * Fri Jul 6 2001 Mike A. Harris 2000c-10 - Rebuilt in new environment, bumped release numbers to 200c-10, 2000c-1.6.0, 2000c-1.5.0 * Thu Jul 5 2001 Mike A. Harris 2000c-9 - Fix for with_pamauth - Built 2000c-9 for 7.x, 2000c-1.3.6x, 2000c-1.3.5x * Wed Jun 27 2001 Mike A. Harris 2000c-8 - Minor fix to wrap up post and postun in an if block to exclude them from 6.x/5.x builds. - Built 2000c-8 for 7.x, 2000c-1.2.6x for 6.2 and 2000c-1.2.5x for 5.2 * Sat Jun 23 2001 Mike A. Harris 2000c-7 - Disabled complex ghost lines on pem files for errata as it is more of an enhancement that should wait for a full devel cycle of testing. * Wed Jun 20 2001 Mike A. Harris 2000c-6.13 - Added security fixes from Vincent Danen's imap 4.4 package. (#44321) - Added conditional code to generate SSL certificates during post-install - Added the SSL certificate as a ghost config file (conditionally). - Moved xinetd reload to after end of post install script (#43400) - ghosted ssl certificate (#43400) - Fixed bug where imaps/pop3s would fail after an upgrade from old stunnel based imaps because the xinetd.d/* files were all (noreplace), so the new old xinetd config file still tried to use stunnel. * Tue May 22 2001 Mike A. Harris 2000c-5 - Changes to specfile to conditionalize with_pamauth, and with_xinetd, wrapped all relevant parts of specfile with new conditionals, and added Build_62, and Build_52, along with wrapper ifdef's to preset the various options based on the build being done. * Mon May 21 2001 Mike A. Harris 2000c-2 - Added post script to migrate stunnel.pem to imapd.pem if the former exists when installing/upgrading and no imapd.pem exists already. - Built errata candidate 2000c-2 for RHL 7.x * Sat May 19 2001 Mike A. Harris - Updated sources to imap-2000c fixing bug ids (20858,25976,40855,41292) - Updated patches to work with imap-200c (ssl, flock) - Removed unneeded sparc patch (fixed in 2000c), and patch6 - Include more documentation (*.txt, etc..) in main package - s/Copyright:/License:/ in specfile * Thu Apr 5 2001 Mike A. Harris - Added c-client/linkage.c to /usr/include/imap so that applications built with c-client will be consistent across the distribution. * Sat Mar 3 2001 Mike A. Harris - Reintegrated my changes from Mar 1 that got lost. -8 release. * Fri Mar 2 2001 Nalin Dahyabhai - rebuild in new environment * Thu Mar 1 2001 Mike A. Harris - UNIX compress (.Z) sucks. Converted to bzip2 for a 60% savings (1.1Mb) - Removed EXTRACFLAGS changes from redhat patch to Makefile, and put in spec file so it propagates through the build. (#20760) - Changed license from BSD to "University of Washington's Free-Fork License", as it is not in fact BSD licenced. See file CPYRIGHT for details. * Thu Feb 15 2001 Trond Eivind Glomsr?d - Conflict with cyrus-imapd * Wed Feb 14 2001 Trond Eivind Glomsr?d - Make it build * Mon Nov 20 2000 Nalin Dahyabhai - add some documentation about the SSL server-side support (#20931) * Mon Oct 31 2000 Nalin Dahyabhai - make SSL and GSS support conditional - mark as a modified version - quell error messages about spool directory permissions * Thu Oct 26 2000 Nalin Dahyabhai - update to 2000 final release and bump epoch to upgrade RCs - patch to get around bug in compiler on sparc * Fri Oct 20 2000 Nalin Dahyabhai - update to RC8 * Wed Oct 18 2000 Nalin Dahyabhai - always do a pam_setcred(DELETE) before doing a pam_end() * Tue Oct 10 2000 Nalin Dahyabhai - switch to internal SSL support instead of using stunnel (#18727) * Wed Oct 4 2000 Nalin Dahyabhai - update to IMAP 2000 RC7 * Thu Aug 24 2000 Nalin Dahyabhai - update flock() emulation - ignore dotlock errors because we're all using fcntl() locks * Wed Aug 23 2000 Nalin Dahyabhai - modify locking to use fcntl() instead of flock() (#15779) - add simap patches * Wed Aug 9 2000 Nalin Dahyabhai - disable mbox in top-level makefile, too (#15833) * Tue Aug 8 2000 Nalin Dahyabhai - rename simap to imaps and spop3 to pop3s * Tue Jul 18 2000 Bill Nottingham - add description & default to xinetd file * Thu Jul 13 2000 Prospector - automatic rebuild * Mon Jul 10 2000 Nalin Dahyabhai - disable the mbox driver, which is counter-intuitive - add xinetd control files for imaps and pop3s for use with stunnel * Thu Jul 6 2000 Nalin Dahyabhai - don't shut down xinetd on uninstall - use xinetd's reload, not condrestart - add chkconfig comments to xinetd config file - reload xinetd even if all copies of imapd will be gone - mark xinetd config files as noreplace * Tue Jul 4 2000 Florian La Roche - change scripts * Mon Jul 3 2000 Nalin Dahyabhai - add "Requires: xinetd" (#11837) * Tue Jun 27 2000 Nalin Dahyabhai - update to 4.7c2 - condrestart xinetd in post and postun * Sat Jun 17 2000 Nalin Dahyabhai - disable by default - FHS fixes - add defattr to -devel subpackage - add libc-client.a symlink to %{_libdir} * Thu Jun 1 2000 Nalin Dahyabhai - modify PAM setup to use system-auth * Mon May 22 2000 Trond Eivind Glomsr?d - Now uses xinetd * Wed Apr 5 2000 Bill Nottingham - remove explict krb5-configs dependency * Sun Mar 26 2000 Florian La Roche - change root:mail -> root:root * Wed Mar 1 2000 Nalin Dahyabhai - make kerberos support conditional at build-time * Wed Mar 1 2000 Bill Nottingham - integrate kerberos support into main tree * Thu Feb 03 2000 Cristian Gafton - fix group - fix description - man pages are compressed * Thu Jan 13 2000 Preston Brown - create static library in a subpackage 'devel' (#5098) * Thu Jun 10 1999 Dale Lovelace - add -fPIC option for sparc mod_php3 problems * Fri Apr 09 1999 Cristian Gafton - ipop3d service name was changed to "pop" now. Clearly somebody that hasn't got a clue about PAM stuff is messing around with the source. * Sun Mar 21 1999 Cristian Gafton - auto rebuild in the new build environment (release 2) * Sat Mar 13 1999 Cristian Gafton - verson 4.5 - loose the noflock patch * Thu Dec 17 1998 Cristian Gafton - added a -vfs patch because sys/statvfs on glibc 2.1 is different from what is available on the sun... - build against glibc 2.1 * Fri Sep 11 1998 Jeff Johnson - use only fcntl locking. * Thu Sep 10 1998 Jeff Johnson - update to 4.4. - removed g+s bit to imapd. * Wed Jul 22 1998 Jeff Johnson - updated to 4.2. - added g+s bit to imapd so that lock files can be created. * Thu May 07 1998 Prospector System - translations modified for de, fr, tr * Wed Apr 08 1998 Cristian Gafton - Updated to the latest imap as of today... * Wed Dec 10 1997 Cristian Gafton - Updated to the latest imap as of today... - Updated the pam patch to reflect the new directory organization * Thu Oct 23 1997 Michael K. Johnson - Fix patch for new PAM spec compliance. * Thu Oct 02 1997 Michael K. Johnson - Comply with change in PAM spec. - Use a buildroot. * Mon Mar 03 1997 Michael K. Johnson - Moved from pam.conf to pam.d * Mon Mar 03 1997 Erik Troan - Fixed buffer overrun in server_login(). -------------- next part -------------- Fixes CAN-2005-2933 See http://www.idefense.com/application/poi/display?id=313&type=vulnerabilities&flashstatus=false http://www.linuxsecurity.com/content/view/120575 Modified from the mail.c patch at http://www.idefense.com/application/poi/display?id=313&type=vulnerabilities&flashstatus=false --- src/c-client/mail.c.orig Tue Nov 13 21:29:07 2001 +++ src/c-client/mail.c Wed Oct 12 10:28:58 2005 @@ -587,8 +587,10 @@ if (c == '=') { /* parse switches which take arguments */ if (*t == '"') { /* quoted string? */ for (v = arg,i = 0,++t; (c = *t++) != '"';) { + if (!c) return NIL; /* unterminated string [CAN-2005-2933] */ /* quote next character */ if (c == '\\') c = *t++; + if (!c) return NIL; /* can't quote NUL either [CAN-2005-2933] */ arg[i++] = c; } c = *t++; /* remember delimiter for later */ From sheltren at cs.ucsb.edu Wed Oct 12 11:03:20 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 12 Oct 2005 07:03:20 -0400 Subject: Legacy 7.3 imap-2001a-10.1 and CAN-2005-2933 In-Reply-To: <20051012101650.GB24742@viasys.com> References: <20051012101650.GB24742@viasys.com> Message-ID: On Oct 12, 2005, at 6:16 AM, Ville Herva wrote: > I don't know if anyone cares about RH73 and imap-2001a anymore, but > I think > this vulnerability applies to imap-2001a-10.1.legacy too: > > http://www.idefense.com/application/poi/display? > id=313&type=vulnerabilities&flashstatus=false > http://www.linuxsecurity.com/content/view/120575 > > I took the source from > http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/ > imap-2001a-10.1.legacy.src.rpm > > and modified the mail.c patch from > http://www.idefense.com/application/poi/display? > id=313&type=vulnerabilities&flashstatus=false > to apply to 2001a. > > It was just a blind patch weeding job - I didn't actually verify that > imap-2001a isn't invulnerable to this or vulnerable to something else. > > I case anyone is interested, here's the modified .spec and the patch. > > Just do > > rpm -i imap-2001a-10.1.legacy.src.rpm > cp imap.spec.patched /usr/src/redhat/SPECS/imap.spec > cp imap-2001a-CAN-2005-2933_fix.patch /usr/src/redhat/SOURCES/ > rpm -bb /usr/src/redhat/SPECS/imap.spec > Thanks for the patch. It'd be nice if you could search through bugzilla to see if this has been reported or not there, and either add to that bug, or create a new bug (and post your new SRPM). Thanks, Jeff From vherva at viasys.com Thu Oct 13 07:27:54 2005 From: vherva at viasys.com (Ville Herva) Date: Thu, 13 Oct 2005 10:27:54 +0300 Subject: Legacy 7.3 imap-2001a-10.1 and CAN-2005-2933 In-Reply-To: References: <20051012101650.GB24742@viasys.com> Message-ID: <20051013072754.GG31364@viasys.com> On Wed, Oct 12, 2005 at 07:03:20AM -0400, you [Jeff Sheltren] wrote: > > Thanks for the patch. It'd be nice if you could search through > bugzilla to see if this has been reported or not there, Yep, there seems to be https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170411 already. I attached the patch there. -- v -- v at iki.fi From deisenst at gtw.net Sat Oct 15 10:48:57 2005 From: deisenst at gtw.net (David Eisenstein) Date: Sat, 15 Oct 2005 05:48:57 -0500 (CDT) Subject: CVE numbers changing... Message-ID: ... from : "Beginning October 19, 2005, the CVE List numbering scheme will undergo a one-time-only modification to replace the 'CAN' prefix with a 'CVE' prefix in CVE names. "The new numbering scheme will have the CVE prefix from the outset followed by 8 numerals (e.g., CVE-1999-0067) and a status line designating whether the name has Entry, Candidate, or Deprecated status. Each CVE name will continue to include a brief description and references. "Previously assigned CVE numbers will remain the same except for the prefix being updated and the addition of the status, e.g., CAN-2005-0386 will be changed to CVE-2005-0386 with 'Candidate' status. "Links to CANs in older security advisories will be redirected on the CVE Web site to pages with the appropriate renumbered names." From tarmstrong at gmail.com Mon Oct 17 16:10:32 2005 From: tarmstrong at gmail.com (thomas Armstrong) Date: Mon, 17 Oct 2005 18:10:32 +0200 Subject: Which is the last stable kernel for FC2? Message-ID: Hi. Using Fedora Core 2 '2.6.9-1.667', I'm suffering memory problems: ------- Oct 16 21:03:10 www kernel: oom-killer: gfp_mask=0x1d2 ------- Which is the last stable kernel for FC2 in order to check if this isn't a non-fixed bug? Thank you very much. --T From nils at lemonbit.nl Mon Oct 17 18:07:03 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Mon, 17 Oct 2005 20:07:03 +0200 Subject: Which is the last stable kernel for FC2? In-Reply-To: References: Message-ID: <532B6140-1862-4851-967D-41623064857D@lemonbit.nl> Thomas wrote: > Using Fedora Core 2 '2.6.9-1.667', I'm suffering memory problems: > ------- > Oct 16 21:03:10 www kernel: oom-killer: gfp_mask=0x1d2 > ------- > > Which is the last stable kernel for FC2 in order to check if this > isn't a non-fixed bug? 2.6.10-1.771_FC2 is available from http://download.fedoralegacy.org/ fedora/2/updates/i386/ Why not setup yum to check for updates? Nils Breunese. From tarmstrong at gmail.com Tue Oct 18 08:37:53 2005 From: tarmstrong at gmail.com (thomas Armstrong) Date: Tue, 18 Oct 2005 10:37:53 +0200 Subject: Which is the last stable kernel for FC2? In-Reply-To: <532B6140-1862-4851-967D-41623064857D@lemonbit.nl> References: <532B6140-1862-4851-967D-41623064857D@lemonbit.nl> Message-ID: Hi Nils. About yum, I usually use it to upgrade some programs, but I'm not very confidence to do it with the kernel. I've got the memory problems with a production server. Isn't it too risky? Thank you very much for your answer. 2005/10/17, Nils Breunese (Lemonbit Internet) : > Thomas wrote: > > > Using Fedora Core 2 '2.6.9-1.667', I'm suffering memory problems: > > ------- > > Oct 16 21:03:10 www kernel: oom-killer: gfp_mask=0x1d2 > > ------- > > > > Which is the last stable kernel for FC2 in order to check if this > > isn't a non-fixed bug? > > 2.6.10-1.771_FC2 is available from http://download.fedoralegacy.org/ > fedora/2/updates/i386/ > > Why not setup yum to check for updates? > > Nils Breunese. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > From rdieter at math.unl.edu Tue Oct 18 12:34:39 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 18 Oct 2005 07:34:39 -0500 Subject: Which is the last stable kernel for FC2? In-Reply-To: References: <532B6140-1862-4851-967D-41623064857D@lemonbit.nl> Message-ID: <4354EBDF.9010106@math.unl.edu> thomas Armstrong wrote: > About yum, I usually use it to upgrade some programs, but I'm not very > confidence > to do it with the kernel. I've got the memory problems with a > production server. Isn't > it too risky? It's safe. It'll only install the new kernel. Your old, working kernel will still be there if you want/need to go back to it. -- Rex From nils at lemonbit.nl Tue Oct 18 12:36:48 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Tue, 18 Oct 2005 14:36:48 +0200 Subject: Which is the last stable kernel for FC2? In-Reply-To: References: <532B6140-1862-4851-967D-41623064857D@lemonbit.nl> Message-ID: Thomas wrote: > About yum, I usually use it to upgrade some programs, but I'm not very > confidence to do it with the kernel. I've got the memory problems > with a > production server. Isn't it too risky? Isn't what too risky? If you have problems with the current kernel, I guess you don't want to continue running your current kernel, so you might want to try the latest one. Or you could go and search Bugzilla for your problem and maybe see if it's been fixed. By the way, by default when yum installs a new kernel it doesn't remove your existing kernels, so if the new one isn't working for you you can always go back to your last working kernel. Nils. From jkosin at beta.intcomgrp.com Tue Oct 18 14:19:46 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 18 Oct 2005 10:19:46 -0400 Subject: Package Submission? Message-ID: <43550482.80102@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Ok, I would like to know how to submit a package for FC1 to be updated... Of course, not through the normal means of patching the existing version; but, a new build. In particualar, the gcc package I've built for 3.3.6 for FC1. I've had no problems with this and would like to submit it to the Fedora Legacy group to update FC1 and others if possible. http://beta.support.intcomgrp.com/mirror/fedora-core/beta/src/gcc-3.3.6-2.fc1.src.rpm And the corresponding binutils package; since, gcc stoped support for c++filt which was moved to binutils.... http://beta.support.intcomgrp.com/mirror/fedora-core/beta/src/binutils-2.16.1-1.fc1.src.rpm I'm also willing to make changes / patches to the versions I have if there are any problems. Thanks, James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVQSCkNLDmnu1kSkRAy5uAKCEIGX3uuK4k+bqoPj3yj/I0TbcowCdFWdF mN1GCaaZnHJJvdnLnvR4ACs= =Elwv -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkosin at beta.intcomgrp.com Tue Oct 18 14:27:21 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 18 Oct 2005 10:27:21 -0400 Subject: Package Submission? In-Reply-To: <43550482.80102@beta.intcomgrp.com> References: <43550482.80102@beta.intcomgrp.com> Message-ID: <43550649.4010207@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 James Kosin wrote: > Ok, > > I would like to know how to submit a package for FC1 to be > updated... Of course, not through the normal means of patching the > existing version; but, a new build. > > In particualar, the gcc package I've built for 3.3.6 for FC1. I've > had no problems with this and would like to submit it to the Fedora > Legacy group to update FC1 and others if possible. > > http://beta.support.intcomgrp.com/mirror/fedora-core/beta/src/gcc-3.3.6-2.fc1.src.rpm > http://support.intcomgrp.com/mirror/fedora-core/beta/src/gcc-3.3.6-2.fc1.src.rpm > > And the corresponding binutils package; since, gcc stoped support > for c++filt which was moved to binutils.... > > http://beta.support.intcomgrp.com/mirror/fedora-core/beta/src/binutils-2.16.1-1.fc1.src.rpm > http://support.intcomgrp.com/mirror/fedora-core/beta/src/binutils-2.16.1-1.fc1.src.rpm > > I'm also willing to make changes / patches to the versions I have > if there are any problems. > > Thanks, James Kosin Sorry, copied links for my internal network and not the external one. James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVQZJkNLDmnu1kSkRA4r2AJ91Gbj57QglKg93PBcopd3QuipOlwCfZccM KXoY6uGQIOf28hxQbxPda+o= =UkN7 -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From rdieter at math.unl.edu Tue Oct 18 15:13:06 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 18 Oct 2005 10:13:06 -0500 Subject: Package Submission? In-Reply-To: <43550482.80102@beta.intcomgrp.com> References: <43550482.80102@beta.intcomgrp.com> Message-ID: <43551102.2000701@math.unl.edu> James Kosin wrote: > I would like to know how to submit a package for FC1 to be updated... > Of course, not through the normal means of patching the existing > version; but, a new build. > In particualar, the gcc package I've built for 3.3.6 for FC1. fedoralegacy is only for security updates, not packages upgrades. See http://fedoralegacy.org/about/faq.php: FAQs Q: What is the update policy for The Fedora Legacy Project? A: In general, we will provide security updates and critical bug fixes for select versions of Red Hat Linux and Fedora Core releases. No new features or packages will be introduced except where they are required for future management of our updates and agreed upon by a consensus -- Rex From jkosin at beta.intcomgrp.com Tue Oct 18 15:49:04 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Tue, 18 Oct 2005 11:49:04 -0400 Subject: Package Submission? In-Reply-To: <43551102.2000701@math.unl.edu> References: <43550482.80102@beta.intcomgrp.com> <43551102.2000701@math.unl.edu> Message-ID: <43551970.1060806@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Rex Dieter wrote: > James Kosin wrote: > >> I would like to know how to submit a package for FC1 to be updated... >> Of course, not through the normal means of patching the existing >> version; but, a new build. >> In particualar, the gcc package I've built for 3.3.6 for FC1. > > > fedoralegacy is only for security updates, not packages upgrades. See > http://fedoralegacy.org/about/faq.php: > > FAQs > Q: What is the update policy for The Fedora Legacy Project? > A: > In general, we will provide security updates and critical bug fixes > for select versions of Red Hat Linux and Fedora Core releases. No > new features or packages will be introduced except where they are > required for future management of our updates and agreed upon by a > consensus > > -- Rex > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list Rex, Thanks, but what you just quoted me says that it is possible if agreed upon by a consensus. I do know that Fedora & Fedora Legacy only do security patches (for the most part) on packages released by the OS release. I'm just trying to find a way to improve things. FC1 shipped with gcc-3.3.2-1 and there hasn't been any updates to this or even bug fixes. GCC has finally released 3.3.6 back in May 3 2005 and stopped development on the branch. Changes to version 3.3.6 http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.6 Changes to version 3.3.5 http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.5 Changes to version 3.3.4 http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.4 Changes to version 3.3.3 http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.3 I've managed to build a working version of 3.3.6 for FC1 and have been using it for several months with no problems. Thanks, James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVRlwkNLDmnu1kSkRA1xlAJ9CIHmtCZqUwRT1CQKqhhX7VaZFcQCfXQas uPCxfUXlo8LNDQE5ZyxOlxc= =/FQX -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From lists at benjamindsmith.com Tue Oct 18 23:58:20 2005 From: lists at benjamindsmith.com (Benjamin Smith) Date: Tue, 18 Oct 2005 16:58:20 -0700 Subject: Dumb Question Message-ID: <200510181658.20339.lists@benjamindsmith.com> I'd like to get & check out updates that have not been approved. How do I set up the yum.conf on my FC1 system to get these updates? -Ben -- "I kept looking around for somebody to solve the problem. Then I realized I am somebody" -Anonymous From drees76 at gmail.com Wed Oct 19 01:48:57 2005 From: drees76 at gmail.com (David Rees) Date: Tue, 18 Oct 2005 18:48:57 -0700 Subject: Dumb Question In-Reply-To: <200510181658.20339.lists@benjamindsmith.com> References: <200510181658.20339.lists@benjamindsmith.com> Message-ID: <72dbd3150510181848m42f0de27tbbb6485578b57040@mail.gmail.com> On 10/18/05, Benjamin Smith wrote: > I'd like to get & check out updates that have not been approved. > > How do I set up the yum.conf on my FC1 system to get these updates? Add this to your yum.conf: [updates-testing] gpgcheck=1 name=Fedora Core $releasever updates testing baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates-testing/$basearch -Dave From rostetter at MAIL.UTEXAS.EDU Wed Oct 19 01:51:28 2005 From: rostetter at MAIL.UTEXAS.EDU (Eric Rostetter) Date: Tue, 18 Oct 2005 20:51:28 -0500 Subject: Dumb Question In-Reply-To: <200510181658.20339.lists@benjamindsmith.com> References: <200510181658.20339.lists@benjamindsmith.com> Message-ID: <1129686688.0c43e5a7a54db@mail.ph.utexas.edu> Quoting Benjamin Smith : > I'd like to get & check out updates that have not been approved. Great! We could use the help testing them. > How do I set up the yum.conf on my FC1 system to get these updates? Assuming you know how yum.conf works, it should be fairly easy. I don't use FC1, so I'm not sure of the details. But if there is a single yum.conf then it would be the same as RHL and would be fairly easy to setup. Edit your yum.conf, and search on "updates-testing" (but without the quotes). If there is already an entry for the updates-testing, then you are all set. If there is one, but it is commented out, then uncomment and you are all set. If there is not one, then you will need to add an stanza for it. To add it, add the following to your yum.conf: [updates-testing] name=Fedora Core $releasever updates-testing baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates-testing/$basearch Then you should be all set. You might also want to see: http://www.fedoralegacy.org/wiki/index.php/MultipleYumConf which tells you how you can have two configuration files (one without updates-testing, one with updates-testing, and then switch between them). If you need more help then the above, just ask. > -Ben > -- > "I kept looking around for somebody to solve the problem. > Then I realized I am somebody" > -Anonymous > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Eric Rostetter From lists at benjamindsmith.com Wed Oct 19 06:39:56 2005 From: lists at benjamindsmith.com (Benjamin Smith) Date: Tue, 18 Oct 2005 23:39:56 -0700 Subject: Dumb Question In-Reply-To: <1129686688.0c43e5a7a54db@mail.ph.utexas.edu> References: <200510181658.20339.lists@benjamindsmith.com> <1129686688.0c43e5a7a54db@mail.ph.utexas.edu> Message-ID: <200510182339.56100.lists@benjamindsmith.com> Thanks! Is there a way for me to do a query and see what RPMs are installed that are testing? I see many packages marked as "legacy" but how would I know which ones are released and which aren't? -Ben On Tuesday 18 October 2005 18:51, Eric Rostetter wrote: > Quoting Benjamin Smith : > > > I'd like to get & check out updates that have not been approved. > > Great! We could use the help testing them. > > > How do I set up the yum.conf on my FC1 system to get these updates? > > Assuming you know how yum.conf works, it should be fairly easy. I don't > use FC1, so I'm not sure of the details. But if there is a single yum.conf > then it would be the same as RHL and would be fairly easy to setup. > > Edit your yum.conf, and search on "updates-testing" (but without the quotes). > > If there is already an entry for the updates-testing, then you are all set. > If there is one, but it is commented out, then uncomment and you are all set. > If there is not one, then you will need to add an stanza for it. > > To add it, add the following to your yum.conf: > > [updates-testing] > name=Fedora Core $releasever updates-testing > baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates-testing/$basearch > > Then you should be all set. > > You might also want to see: > > http://www.fedoralegacy.org/wiki/index.php/MultipleYumConf > > which tells you how you can have two configuration files (one without > updates-testing, one with updates-testing, and then switch between them). > > If you need more help then the above, just ask. > > > -Ben > > -- > > "I kept looking around for somebody to solve the problem. > > Then I realized I am somebody" > > -Anonymous > > > > -- > > fedora-legacy-list mailing list > > fedora-legacy-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > > > > -- > Eric Rostetter > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From sheltren at cs.ucsb.edu Wed Oct 19 12:01:25 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 19 Oct 2005 08:01:25 -0400 Subject: Dumb Question In-Reply-To: <200510182339.56100.lists@benjamindsmith.com> References: <200510181658.20339.lists@benjamindsmith.com> <1129686688.0c43e5a7a54db@mail.ph.utexas.edu> <200510182339.56100.lists@benjamindsmith.com> Message-ID: On Oct 19, 2005, at 2:39 AM, Benjamin Smith wrote: > Thanks! > > Is there a way for me to do a query and see what RPMs are installed > that are > testing? I see many packages marked as "legacy" but how would I > know which > ones are released and which aren't? > > -Ben 'yum list' or 'yum list ' should show you the information you want. -Jeff From deisenst at gtw.net Wed Oct 19 14:47:13 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 19 Oct 2005 09:47:13 -0500 Subject: Build team? Message-ID: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> I was wondering if we need more people on Fedora Legacy's build team? Since Dominic Hargreaves has not been able to participate, and my understanding is that Marc Deslauriers has lately had personal things to attend to, packages are not being built for updates-testing nor are release-ready packages being released. Dominic and Marc are the only two people I have ever seen build or release official Fedora Legacy packages. Does anyone else do it? -David Eisenstein From jkeating at j2solutions.net Wed Oct 19 14:56:56 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 Oct 2005 07:56:56 -0700 Subject: Build team? In-Reply-To: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> Message-ID: <1129733816.28454.35.camel@yoda.loki.me> On Wed, 2005-10-19 at 09:47 -0500, David Eisenstein wrote: > > Since Dominic Hargreaves has not been able to participate, and my > understanding is that Marc Deslauriers has lately had personal things > to attend to, packages are not being built for updates-testing nor are > release-ready packages being released. > > Dominic and Marc are the only two people I have ever seen build or > release official Fedora Legacy packages. Does anyone else do it? Yes, we are in need. I was hoping to get the new build system in place before adding people, but I see that it just isn't going to happen. David, I had tagged you as one I was going to invite. I will be making private invitations to join the build team over the next week or so. -- 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 From dom at earth.li Wed Oct 19 14:55:54 2005 From: dom at earth.li (Dominic Hargreaves) Date: Wed, 19 Oct 2005 15:55:54 +0100 Subject: Build team? In-Reply-To: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> Message-ID: <20051019145554.GC28892@urchin.earth.li> On Wed, Oct 19, 2005 at 09:47:13AM -0500, David Eisenstein wrote: > I was wondering if we need more people on Fedora Legacy's build team? > > Since Dominic Hargreaves has not been able to participate, and my understanding is that Marc Deslauriers has lately had personal things to attend to, packages are not being built for updates-testing nor are release-ready packages being released. I'm happy to be prodded if build system stuff needs doing; let me know :) Cheers, -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From jkosin at beta.intcomgrp.com Wed Oct 19 15:10:24 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Wed, 19 Oct 2005 11:10:24 -0400 Subject: Build team? In-Reply-To: <1129733816.28454.35.camel@yoda.loki.me> References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> <1129733816.28454.35.camel@yoda.loki.me> Message-ID: <435661E0.8040608@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Jesse Keating wrote: >On Wed, 2005-10-19 at 09:47 -0500, David Eisenstein wrote: > >>Since Dominic Hargreaves has not been able to participate, and my >>understanding is that Marc Deslauriers has lately had personal things >>to attend to, packages are not being built for updates-testing nor are >>release-ready packages being released. >> >>Dominic and Marc are the only two people I have ever seen build or >>release official Fedora Legacy packages. Does anyone else do it? > > >Yes, we are in need. I was hoping to get the new build system in place >before adding people, but I see that it just isn't going to happen. >David, I had tagged you as one I was going to invite. > >I will be making private invitations to join the build team over the >next week or so. > I'm willing to help with building as well. Let me know. James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVmHfkNLDmnu1kSkRA4d3AJ4/9RXZKoqrJgqE1E4coXzQ9dwOKQCbBn8v sVQ9s/S2pzCjE5VMGnibRMY= =gmfc -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkeating at j2solutions.net Wed Oct 19 17:41:48 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 Oct 2005 10:41:48 -0700 Subject: New repository metadata format In-Reply-To: <1121241847.31376.0.camel@prometheus.gamehouse.com> References: <382AE7E877C4CB520095C298@[10.0.0.14]> <1115226675.28515.11.camel@jkeating2.hq.pogolinux.com> <1115232781.28515.27.camel@jkeating2.hq.pogolinux.com> <1121241847.31376.0.camel@prometheus.gamehouse.com> Message-ID: <1129743708.2929.15.camel@prometheus.gamehouse.com> On Wed, 2005-07-13 at 01:04 -0700, Jesse Keating wrote: > You're right, this hasn't been done yet. I need to look a bit more > into > this. I have edited our upload scripts to create the new metadata format for all the repositories. This new metadata should hit the primary server (download.fedoralegacy.org) sometime today. Sorry for taking so long on this. -- 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 From jkeating at j2solutions.net Wed Oct 19 17:57:34 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 Oct 2005 10:57:34 -0700 Subject: Upcoming transition of FC3 Message-ID: <1129744654.2929.26.camel@prometheus.gamehouse.com> FC3 will soon be in our hands, when FC5 test 2 is released. According to our schedule, this means that FC1 will be retired. FC2 and FC3 will be the maintained Fedora releases. I will be working with Red Hat to try and make a smooth transition between them and us for FC3 updates. Today I am populating the download server with the current FC3 content and I will be syncing at regular intervals until release time. I'm open to ideas regarding the transition, but my current thought is to have Red Hat make one final update to yum that would include an /etc/yum.repos.d/legacy.repo file that has all our repository information there. Turned off of course, I still want uses to make a conscience choice on turning on Legacy updates. As for FC1, now would be a great time to make a big push on clearing out all current bugs open particularly for FC1. When we take on Fc3, we will fulfill all open bugs for FC1, but not open any new ones. The content will remain on the download server for now, although duplicate updates or deprecated updates may be removed to save disk space. -- 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 From bfeinstein at trustednetworktech.com Tue Oct 11 19:46:08 2005 From: bfeinstein at trustednetworktech.com (Ben Feinstein) Date: Tue, 11 Oct 2005 15:46:08 -0400 Subject: FLSA:2404 (Redhat 9) question Message-ID: <200510111546.08804.bfeinstein@trustednetworktech.com> Regarding Fedora Legacy Security Advisory 2404 of Mar 07 2005: The updated less-378-7.2.legacy RPM and SRPM are no longer available at the URLs listed in the advisory. Are these updates no longer applicable and were removed from the repository, or is there another reason the packages are now missing? Please address or CC me directly as I don't subscribe to this list... Thanks much, Ben -- Ben Feinstein, CISSP Software Development Engineer Trusted Network Technologies, Inc. www.trustednetworktech.com | Blog www.knowidentity.com 3600 Mansell Road | Suite 200 | Alpharetta, GA 30022 678.397.0500 x312 | Fax 678.397.0339 | bfeinstein at trustednetworktech.com Know Identity. No Worries. This email is for the sole use of the intended recipient(s) and contains confidential information subject to legal restrictions. From pekkas at netcore.fi Wed Oct 19 18:08:23 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 19 Oct 2005 21:08:23 +0300 (EEST) Subject: Build team? In-Reply-To: <20051019145554.GC28892@urchin.earth.li> References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> <20051019145554.GC28892@urchin.earth.li> Message-ID: On Wed, 19 Oct 2005, Dominic Hargreaves wrote: > On Wed, Oct 19, 2005 at 09:47:13AM -0500, David Eisenstein wrote: >> I was wondering if we need more people on Fedora Legacy's build team? >> >> Since Dominic Hargreaves has not been able to participate, and my understanding is that Marc Deslauriers has lately had personal things to attend to, packages are not being built for updates-testing nor are release-ready packages being released. > > I'm happy to be prodded if build system stuff needs doing; let me know > :) Sure.. There's _lot's_ of stuff waiting, just have a look at the first two categories of: http://netcore.fi/pekkas/buglist.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sheltren at cs.ucsb.edu Wed Oct 19 18:17:59 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 19 Oct 2005 14:17:59 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1129744654.2929.26.camel@prometheus.gamehouse.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> Message-ID: On Oct 19, 2005, at 1:57 PM, Jesse Keating wrote: > FC3 will soon be in our hands, when FC5 test 2 is released. According > to our schedule, this means that FC1 will be retired. FC2 and FC3 > will > be the maintained Fedora releases. > > I will be working with Red Hat to try and make a smooth transition > between them and us for FC3 updates. Today I am populating the > download > server with the current FC3 content and I will be syncing at regular > intervals until release time. I'm open to ideas regarding the > transition, but my current thought is to have Red Hat make one final > update to yum that would include an /etc/yum.repos.d/legacy.repo file > that has all our repository information there. Turned off of > course, I > still want uses to make a conscience choice on turning on Legacy > updates. > > As for FC1, now would be a great time to make a big push on > clearing out > all current bugs open particularly for FC1. When we take on Fc3, we > will fulfill all open bugs for FC1, but not open any new ones. The > content will remain on the download server for now, although duplicate > updates or deprecated updates may be removed to save disk space. I like the idea of having a yum repo file pushed out by redhat, although I'm not sure if they'd go for it or not. If not, I think a good idea may be for us to release a package like legacy-yumconf-fc3 which would provide the file /etc/yum.repos.d/legacy.repo. CentOS does something similar if you want an example. If we get real ambitious, we could even stick our GPG key on the system (they'd still have to manually import it to yum/rpm). Also, it'd be nice to get an announcement on fedora.redhat.com and/or fedoraproject.org that the transition will take place (and/or has taken place) like they did for the FC2 transition. We could put up something on the Legacy wiki with the estimated date for the transition (looks like Dec. 12th according to http:// fedora.redhat.com/participate/schedule/ ). Aside from that, we'll also need to update our wiki with info for fc3, and update everything to say we support FC3 but no longer FC1... -Jeff From sheltren at cs.ucsb.edu Wed Oct 19 18:20:21 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 19 Oct 2005 14:20:21 -0400 Subject: FLSA:2404 (Redhat 9) question In-Reply-To: <200510111546.08804.bfeinstein@trustednetworktech.com> References: <200510111546.08804.bfeinstein@trustednetworktech.com> Message-ID: <56FF20A4-EAB6-4ABA-82B2-7CD573736A1F@cs.ucsb.edu> On Oct 11, 2005, at 3:46 PM, Ben Feinstein wrote: > Regarding Fedora Legacy Security Advisory 2404 of Mar 07 2005: > > The updated less-378-7.2.legacy RPM and SRPM are no longer > available at the > URLs listed in the advisory. Are these updates no longer > applicable and were > removed from the repository, or is there another reason the > packages are now > missing? > > Please address or CC me directly as I don't subscribe to this list... > > Thanks much, > Ben > Hi Ben, looks like they are in updates-testing: http://download.fedoralegacy.org/redhat/9/updates-testing/i386/ less-378-7.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates-testing/SRPMS/ less-378-7.2.legacy.src.rpm -Jeff From sheltren at cs.ucsb.edu Wed Oct 19 18:21:32 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 19 Oct 2005 14:21:32 -0400 Subject: New repository metadata format In-Reply-To: <1129743708.2929.15.camel@prometheus.gamehouse.com> References: <382AE7E877C4CB520095C298@[10.0.0.14]> <1115226675.28515.11.camel@jkeating2.hq.pogolinux.com> <1115232781.28515.27.camel@jkeating2.hq.pogolinux.com> <1121241847.31376.0.camel@prometheus.gamehouse.com> <1129743708.2929.15.camel@prometheus.gamehouse.com> Message-ID: <4FB4DCE7-6F5F-4CD2-BF38-DA055DB0CDFC@cs.ucsb.edu> On Oct 19, 2005, at 1:41 PM, Jesse Keating wrote: > On Wed, 2005-07-13 at 01:04 -0700, Jesse Keating wrote: > >> You're right, this hasn't been done yet. I need to look a bit more >> into >> this. >> > > I have edited our upload scripts to create the new metadata format for > all the repositories. This new metadata should hit the primary server > (download.fedoralegacy.org) sometime today. Sorry for taking so > long on > this. > Great, that's good news! I assume that this will also create the metadata for the base OS (not just the updates directories) - correct? Thanks, Jeff From pekkas at netcore.fi Wed Oct 19 18:26:50 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 19 Oct 2005 21:26:50 +0300 (EEST) Subject: FLSA:2404 (Redhat 9) question In-Reply-To: <56FF20A4-EAB6-4ABA-82B2-7CD573736A1F@cs.ucsb.edu> References: <200510111546.08804.bfeinstein@trustednetworktech.com> <56FF20A4-EAB6-4ABA-82B2-7CD573736A1F@cs.ucsb.edu> Message-ID: On Wed, 19 Oct 2005, Jeff Sheltren wrote: > On Oct 11, 2005, at 3:46 PM, Ben Feinstein wrote: >> Regarding Fedora Legacy Security Advisory 2404 of Mar 07 2005: >> >> The updated less-378-7.2.legacy RPM and SRPM are no longer available at the >> URLs listed in the advisory. Are these updates no longer applicable and >> were >> removed from the repository, or is there another reason the packages are >> now >> missing? >> >> Please address or CC me directly as I don't subscribe to this list... >> >> Thanks much, >> Ben >> > Hi Ben, looks like they are in updates-testing: > > http://download.fedoralegacy.org/redhat/9/updates-testing/i386/ > less-378-7.2.legacy.i386.rpm > http://download.fedoralegacy.org/redhat/9/updates-testing/SRPMS/ > less-378-7.2.legacy.src.rpm Moreover, if you look at the bug in question, some folks reported that yum crashed with this less update (though the patch was trivial and should not have changed anything in this regard). IMHO, the problem was/is likely with the build system. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jkeating at j2solutions.net Wed Oct 19 18:34:11 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 19 Oct 2005 11:34:11 -0700 Subject: New repository metadata format In-Reply-To: <4FB4DCE7-6F5F-4CD2-BF38-DA055DB0CDFC@cs.ucsb.edu> References: <382AE7E877C4CB520095C298@[10.0.0.14]> <1115226675.28515.11.camel@jkeating2.hq.pogolinux.com> <1115232781.28515.27.camel@jkeating2.hq.pogolinux.com> <1121241847.31376.0.camel@prometheus.gamehouse.com> <1129743708.2929.15.camel@prometheus.gamehouse.com> <4FB4DCE7-6F5F-4CD2-BF38-DA055DB0CDFC@cs.ucsb.edu> Message-ID: <1129746851.2929.34.camel@prometheus.gamehouse.com> On Wed, 2005-10-19 at 14:21 -0400, Jeff Sheltren wrote: > > Great, that's good news! I assume that this will also create the > metadata for the base OS (not just the updates directories) - correct? Correct. os, updates, updates-testing, and legacy-utils will all have the new format. -- 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 From marcdeslauriers at videotron.ca Wed Oct 19 22:33:46 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Wed, 19 Oct 2005 18:33:46 -0400 Subject: Build team? In-Reply-To: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> Message-ID: <1129761226.7877.20.camel@mdlinux> On Wed, 2005-10-19 at 09:47 -0500, David Eisenstein wrote: > Since Dominic Hargreaves has not been able to participate, and my understanding is that Marc Deslauriers has lately had personal things to attend to, packages are not being built for updates-testing nor are release-ready packages being released. I'm back now. I recently moved and lost Internet access for a couple of weeks. I have been busy building openssl packages for updates-testing. It seems like it's taking forever. :) Marc. -------------- 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 sheltren at cs.ucsb.edu Thu Oct 20 00:15:15 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 19 Oct 2005 20:15:15 -0400 Subject: Build team? In-Reply-To: <1129761226.7877.20.camel@mdlinux> References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> <1129761226.7877.20.camel@mdlinux> Message-ID: On Oct 19, 2005, at 6:33 PM, Marc Deslauriers wrote: > On Wed, 2005-10-19 at 09:47 -0500, David Eisenstein wrote: > >> Since Dominic Hargreaves has not been able to participate, and my >> understanding is that Marc Deslauriers has lately had personal >> things to attend to, packages are not being built for updates- >> testing nor are release-ready packages being released. >> > > I'm back now. I recently moved and lost Internet access for a > couple of > weeks. > > I have been busy building openssl packages for updates-testing. It > seems > like it's taking forever. :) > > Marc. > -- Yes, I was trying to figure out why they take so long to build in mock/mach. From what I could tell, it was the tests which took so long, but I'm not sure why it is different in a chroot environment. Anybody have any clues? -Jeff From shiva at sewingwitch.com Thu Oct 20 01:57:38 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 19 Oct 2005 18:57:38 -0700 Subject: Upcoming transition of FC3 In-Reply-To: References: <1129744654.2929.26.camel@prometheus.gamehouse.com> Message-ID: <1AC7CACD6473C046E8D45137@[10.169.6.233]> --On Wednesday, October 19, 2005 2:17 PM -0400 Jeff Sheltren wrote: > I like the idea of having a yum repo file pushed out by redhat, although > I'm not sure if they'd go for it or not. If not, I think a good idea > may be for us to release a package like legacy-yumconf-fc3 which would > provide the file /etc/yum.repos.d/legacy.repo. CentOS does something > similar if you want an example. If we get real ambitious, we could even > stick our GPG key on the system (they'd still have to manually import it > to yum/rpm). I was going to suggest the same, as I'd just done this to include the Livna repo on my FC4 system: The FC4 RPM includes both the repo file and the GPG key, and the first use of yum to install a package prompts to install the key into RPM. From deisenst at gtw.net Thu Oct 20 02:08:39 2005 From: deisenst at gtw.net (David Eisenstein) Date: Wed, 19 Oct 2005 21:08:39 -0500 Subject: Build team? References: <009b01c5d4bc$0188a640$0100a8c0@homedns.org> <1129761226.7877.20.camel@mdlinux> Message-ID: <001c01c5d51b$3527a0f0$0100a8c0@homedns.org> ----- Original Message ----- From: "Marc Deslauriers" Sent: Wednesday, October 19, 2005 5:33 PM Subject: Re: Build team? > I'm back now. I recently moved and lost Internet access for a couple of > weeks. > > I have been busy building openssl packages for updates-testing. It seems > like it's taking forever. :) > > Marc. Welcome back!! We missed you! :-) From jkosin at beta.intcomgrp.com Thu Oct 20 15:57:47 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Thu, 20 Oct 2005 11:57:47 -0400 Subject: Another security problem.. Message-ID: <4357BE7B.5060103@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 - -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Everyone, On 19-Oct-05 at about 1:00pm my time, someone from IP 194.150.85.114 accessed my web-server trying to access a file called main.php in the following places: 194.150.85.114 - - [19/Oct/2005:13:01:53 -0400] "GET /phpmyadmin/main.php HTTP/1.0" 404 304 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:53 -0400] "GET /PMA/main.php HTTP/1.0" 404 297 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /mysql/main.php HTTP/1.0" 404 299 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /admin/main.php HTTP/1.0" 404 299 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /db/main.php HTTP/1.0" 404 296 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /dbadmin/main.php HTTP/1.0" 404 301 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /web/phpMyAdmin/main.php HTTP/1.0" 404 308 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /admin/pma/main.php HTTP/1.0" 404 303 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET /admin/phpmyadmin/main.php HTTP/1.0" 404 310 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET /admin/mysql/main.php HTTP/1.0" 404 305 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET /mysql-admin/main.php HTTP/1.0" 404 305 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET /phpmyadmin2/main.php HTTP/1.0" 404 305 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /mysqladmin/main.php HTTP/1.0" 404 304 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /mysql-admin/main.php HTTP/1.0" 404 305 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /main.php HTTP/1.0" 404 293 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 310 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 310 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 310 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:57 -0400] "GET /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 310 "-" "pmafind" 194.150.85.114 - - [19/Oct/2005:13:01:57 -0400] "GET /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 310 "-" "pmafind" Of course, this attack fell on deaf ears on my server.... but, I'd like everyone to know since this is a security risk if they do have a PHP document configuring some of these administrative tasks open on the internet. Thanks, James Kosin - - -- - - -- James Kosin International Communications Group, Inc. 230 Pickett's Line Newport News, VA 23603-1366 - - - United States of America - Phone: 1(757)947-1030 ext. 122 Fax : 1(757)947-1035 - - -- GPG Fingerprint: 28E9 6487 34B2 18DD 6468 F091 8CD9 2038 DEB0 0590 GPG Key ID: 0xDEB00590 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV75UjNkgON6wBZARA6DmAJ9NMxZNiNCvKxy8eBZZQ0D7luLnegCfXDb8 SYP3+FueDyDnOzdwLLDA2PI= =D30R - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV757kNLDmnu1kSkRA8uzAJ43tmMFXtvaGW4SC8IOjVbvYFVbzACfbWO/ 5C3JQsLUIER/lsmoAQbRD8k= =Ij0X -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From ad+lists at uni-x.org Thu Oct 20 16:06:53 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Thu, 20 Oct 2005 18:06:53 +0200 Subject: Another security problem.. In-Reply-To: <4357BE7B.5060103@beta.intcomgrp.com> References: <4357BE7B.5060103@beta.intcomgrp.com> Message-ID: <1129824412.5836.47.camel@serendipity.dogma.lan> Am Do, den 20.10.2005 schrieb James Kosin um 17:57: > On 19-Oct-05 at about 1:00pm my time, someone from IP 194.150.85.114 > accessed my web-server trying to access a file called > main.php in the following places: > 194.150.85.114 - - [19/Oct/2005:13:01:53 -0400] "GET > /phpmyadmin/main.php HTTP/1.0" 404 304 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:53 -0400] "GET /PMA/main.php > HTTP/1.0" 404 297 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /mysql/main.php > HTTP/1.0" 404 299 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /admin/main.php > HTTP/1.0" 404 299 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /db/main.php > HTTP/1.0" 404 296 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /dbadmin/main.php > HTTP/1.0" 404 301 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET > /web/phpMyAdmin/main.php HTTP/1.0" 404 308 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET > /admin/pma/main.php HTTP/1.0" 404 303 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /admin/phpmyadmin/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /admin/mysql/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /mysql-admin/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /phpmyadmin2/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /mysqladmin/main.php HTTP/1.0" 404 304 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /mysql-admin/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /main.php > HTTP/1.0" 404 293 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:57 -0400] "GET > /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:57 -0400] "GET > /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 310 "-" "pmafind" > > Of course, this attack fell on deaf ears on my server.... but, I'd > like everyone to know since this is a security risk if they do have a > PHP document configuring some of these administrative tasks open on > the internet. > > Thanks, > James Kosin This looks like a specific search for a vulnerable phpMyAdmin installation, taking into account that the target directory on the webserver may be different than the default (i.e. PMA is simply the short form for phpMyAdmin). And I bet that there are plenty of old phpMyAdmin installs running all over the planet with well known security issues. People are lazy, don't read security notes, nor the main page of the phpMyAdmin project where security alerts are too published and of course they do not update. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 18:03:25 up 1 day, 23:37, load average: 0.38, 0.41, 0.34 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jimpop at yahoo.com Thu Oct 20 16:58:59 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 20 Oct 2005 12:58:59 -0400 Subject: Another security problem.. In-Reply-To: <4357BE7B.5060103@beta.intcomgrp.com> References: <4357BE7B.5060103@beta.intcomgrp.com> Message-ID: <4357CCD3.5080207@yahoo.com> Another? Heck, that's old stuff from quite some time (Internet time) ago. If I had a nickel for every invalid file access attempt..... ;-) -Jim P. James Kosin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Everyone, > > On 19-Oct-05 at about 1:00pm my time, someone from IP 194.150.85.114 > accessed my web-server trying to access a file called > main.php in the following places: > 194.150.85.114 - - [19/Oct/2005:13:01:53 -0400] "GET > /phpmyadmin/main.php HTTP/1.0" 404 304 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:53 -0400] "GET /PMA/main.php > HTTP/1.0" 404 297 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /mysql/main.php > HTTP/1.0" 404 299 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /admin/main.php > HTTP/1.0" 404 299 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /db/main.php > HTTP/1.0" 404 296 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET /dbadmin/main.php > HTTP/1.0" 404 301 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET > /web/phpMyAdmin/main.php HTTP/1.0" 404 308 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:54 -0400] "GET > /admin/pma/main.php HTTP/1.0" 404 303 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /admin/phpmyadmin/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /admin/mysql/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /mysql-admin/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:55 -0400] "GET > /phpmyadmin2/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /mysqladmin/main.php HTTP/1.0" 404 304 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /mysql-admin/main.php HTTP/1.0" 404 305 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET /main.php > HTTP/1.0" 404 293 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:56 -0400] "GET > /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:57 -0400] "GET > /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 310 "-" "pmafind" > 194.150.85.114 - - [19/Oct/2005:13:01:57 -0400] "GET > /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 310 "-" "pmafind" > > Of course, this attack fell on deaf ears on my server.... but, I'd > like everyone to know since this is a security risk if they do have a > PHP document configuring some of these administrative tasks open on > the internet. > > Thanks, > James Kosin > > - - -- > - - -- > James Kosin > > International Communications Group, Inc. > 230 Pickett's Line > Newport News, VA 23603-1366 > - - - United States of America - > > Phone: 1(757)947-1030 ext. 122 > Fax : 1(757)947-1035 > > - - -- > GPG Fingerprint: 28E9 6487 34B2 18DD 6468 F091 8CD9 2038 DEB0 0590 > GPG Key ID: 0xDEB00590 > > - -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDV75UjNkgON6wBZARA6DmAJ9NMxZNiNCvKxy8eBZZQ0D7luLnegCfXDb8 > SYP3+FueDyDnOzdwLLDA2PI= > =D30R > - -----END PGP SIGNATURE----- > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDV757kNLDmnu1kSkRA8uzAJ43tmMFXtvaGW4SC8IOjVbvYFVbzACfbWO/ > 5C3JQsLUIER/lsmoAQbRD8k= > =Ij0X > -----END PGP SIGNATURE----- From jkosin at beta.intcomgrp.com Thu Oct 20 17:15:59 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Thu, 20 Oct 2005 13:15:59 -0400 Subject: Another security problem.. In-Reply-To: <4357CCD3.5080207@yahoo.com> References: <4357BE7B.5060103@beta.intcomgrp.com> <4357CCD3.5080207@yahoo.com> Message-ID: <4357D0CF.2030708@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Jim Popovitch wrote: > Another? Heck, that's old stuff from quite some time (Internet > time) ago. If I had a nickel for every invalid file access > attempt..... ;-) > > -Jim P. > > James Kosin wrote: > <<--snip-->> I'm not all that worried about invalid file accesses. This is just the first time since Windows MyDoom virus came out that I've seen logs that tried accessing the same file from multiple paths. I get lots of invalid file accesses as well. Only not much like this. James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV9DOkNLDmnu1kSkRA2aPAJ9YWMTRfaTsIg59SQSt5ExR8ocsEQCggsLy LFffdHcpXobVKUeP4pjlOxE= =hV02 -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From barbara.pennacchi at istc.cnr.it Thu Oct 20 19:16:19 2005 From: barbara.pennacchi at istc.cnr.it (Barbara Pennacchi) Date: Thu, 20 Oct 2005 19:16:19 +0000 Subject: Another security problem.. In-Reply-To: <20051020160028.45DBA74069@hormel.redhat.com> (from fedora-legacy-list-request@redhat.com on Thu Oct 20 18:00:28 2005) References: <20051020160028.45DBA74069@hormel.redhat.com> Message-ID: <1129835779l.3732l.0l@sibannac> On Thu, 20 Oct 2005 11:57:47 -0400 James Kosin wrote: > On 19-Oct-05 at about 1:00pm my time, someone from IP 194.150.85.114 > accessed my web-server trying to access a file called > main.php in the following places: [snip] > Of course, this attack fell on deaf ears on my server.... but, I'd > like everyone to know since this is a security risk if they do have a > PHP document configuring some of these administrative tasks open on > the internet. Looks like somebody trying to exploit vulnerabilities within all or some versions of PhpMyAdmin. Happened to me too, but no cigar there either, as I've told apache to grant access to that program only to 2 specific IP addresses. And the idiot wasn't one of these :) The best suggestion I could give is to limit by IP address the access to that program, as said above, in httpd.conf or in some .htaccess (not sure of that)... And check on the website of phpmyadmin whether they solved this specific problem or not. (i'm about to go home) I don't think this specific security problem is relevant to FedoraLegacy, since it is not a RPM essential or present in the various RH/Fedora versions catered by it. Tomorrow I'll check deeper into that, to see whether it is a security problem regarding instead one or more releases of PHP itself. b. -- +--------------------------------------------------------------------+ | Barbara Pennacchi barbara.pennacchi (at) istc.cnr.it | | Consiglio Nazionale delle Ricerche | | Istituto di Scienze e Tecnologie della Cognizione | | Via S. Martino della Battaglia 44, 00185 Roma, Italia | | http://www.istc.cnr.it/ | +--------------------------------------------------------------------+ From matt.followers at gmail.com Thu Oct 20 19:38:52 2005 From: matt.followers at gmail.com (Matthew Nuzum) Date: Thu, 20 Oct 2005 14:38:52 -0500 Subject: Another security problem.. In-Reply-To: <4357CCD3.5080207@yahoo.com> Message-ID: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> > From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list- > bounces at redhat.com] On Behalf Of Jim Popovitch > Sent: Thursday, October 20, 2005 11:59 AM > Subject: Re: Another security problem.. > > Another? Heck, that's old stuff from quite some time (Internet time) > ago. If I had a nickel for every invalid file access attempt..... ;-) > > -Jim P. > A little over a week ago, someone was running nessus against one of my servers and it was hitting it so hard the server load soared. I'm not sure what they were doing because when I run nessus (even on the same server) the server load doesn't do that. But that's not my point... if you run a web-facing server there are some plugins for nessus that cause it to search for known-vulnerable web applications and such. It's a good idea to run it periodically so that you can find if you're exposed before someone else does. I've not looked into it, but it would be nice if there was some *simple* to maintain script that would detect these types of probes and automatically add the IP to hosts.deny and etc. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From jimpop at yahoo.com Thu Oct 20 20:29:36 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Thu, 20 Oct 2005 16:29:36 -0400 Subject: Another security problem.. In-Reply-To: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> Message-ID: <4357FE30.3050001@yahoo.com> Matthew Nuzum wrote: > > But that's not my point... if you run a web-facing server there are some > plugins for nessus that cause it to search for known-vulnerable web > applications and such. It's a good idea to run it periodically so that you > can find if you're exposed before someone else does. You are assuming too much of nessus. Your logic requires nessus to know to check for *all* vulnerabilities. I don't have that much faith in any product, even open source ones. The best way to run a secure server is to not trust other tools and software. Do your own checking, investigating, and *don't* run suspicious, or even mildly problematic (i.e. php), software. > I've not looked into it, but it would be nice if there was some *simple* to > maintain script that would detect these types of probes and automatically > add the IP to hosts.deny and etc. I have a script (see below) that scans apache logs, I then add the output to a file that sets up iptables rules. I don't run (nor trust) hosts.deny as it relies on the application's coders to properly use. The below file is by no means a comprehensive set of tests, it's just the common ones that I see. The output on just one of my systems yields almost 20K IPs that get blocked. ;-) YMMV. -Jim P. ---- begin: identify-bad-http-requests ---- TEMP=temp.$$ egrep "FormMail.cgi|FormMail.pl|apage.cgi|auctions.cgi|awstats|ctpub_adserv.cgi|formmail.cgi|formmai l.pl|imgannot.cgi|includer.cgi|openwebmail|proxyjudge.cgi|tellafriend.pl|upload2.cgi" /var/log/httpd /error_log* | sed -e 's/.*\[client \(.*\)\].*/\1/' > $TEMP sed -e "s/SEARCH.*x90.*/BLOCK-IP/" /var/log/httpd/*_log* | grep BLOCK-IP | sed -e 's/ - - .*//' >> $ TEMP sort -u $TEMP rm -f $TEMP ---- end ------ From matt.followers at gmail.com Thu Oct 20 21:01:50 2005 From: matt.followers at gmail.com (Matthew Nuzum) Date: Thu, 20 Oct 2005 16:01:50 -0500 Subject: Another security problem.. In-Reply-To: <4357FE30.3050001@yahoo.com> Message-ID: <435805b2.1781f2e9.2df2.ffffaf0b@mx.gmail.com> > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list- > bounces at redhat.com] On Behalf Of Jim Popovitch > Sent: Thursday, October 20, 2005 3:30 PM > To: Discussion of the Fedora Legacy Project > Subject: Re: Another security problem.. > > Matthew Nuzum wrote: > > > > But that's not my point... if you run a web-facing server there are some > > plugins for nessus that cause it to search for known-vulnerable web > > applications and such. It's a good idea to run it periodically so that > you > > can find if you're exposed before someone else does. > > You are assuming too much of nessus. Your logic requires nessus to know > to check for *all* vulnerabilities. I don't have that much faith in any > product, even open source ones. The best way to run a secure server is > to not trust other tools and software. Do your own checking, > investigating, and *don't* run suspicious, or even mildly problematic > (i.e. php), software. If you're saying, "it's not enough to just run Nessus..." I agree with you. If you're saying that running Nessus is useless, I disagree. It is an excellent tool for finding out if you're running software that has known vulnerabilities. I might go so far to say that if you only run one tool for doing vulnerability analysis then it should be Nessus. I'll admit I've not used a single commercial vulnerability assessment product so my experience is far from comprehensive. Thanks for the suggestion for monitoring log files. You're right about hosts.deny. I'd go so far as to say that hosts.deny is practically useless these days since so few of our networked applications rely on it. But individual applications such as Apache have a similar concept. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From jkeating at j2solutions.net Thu Oct 20 23:16:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 20 Oct 2005 16:16:51 -0700 Subject: Upcoming transition of FC3 In-Reply-To: References: <1129744654.2929.26.camel@prometheus.gamehouse.com> Message-ID: <1129850211.2929.177.camel@prometheus.gamehouse.com> On Wed, 2005-10-19 at 14:17 -0400, Jeff Sheltren wrote: > I like the idea of having a yum repo file pushed out by redhat, > although I'm not sure if they'd go for it or not. If not, I think a > good idea may be for us to release a package like legacy-yumconf-fc3 > which would provide the file /etc/yum.repos.d/legacy.repo. CentOS > does something similar if you want an example. If we get real > ambitious, we could even stick our GPG key on the system (they'd > still have to manually import it to yum/rpm). Would somebody be willing to package this up for me? FC5 will have i386 and x86_64 repositories, however it may be a while before the x86_64 ones get used. I guess we could put something in there for ppc(64) too. -- 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 From nils at lemonbit.nl Fri Oct 21 13:15:42 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 21 Oct 2005 15:15:42 +0200 Subject: Another security problem.. In-Reply-To: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> Message-ID: Matthew Nuzum wrote: > I've not looked into it, but it would be nice if there was some > *simple* to > maintain script that would detect these types of probes and > automatically > add the IP to hosts.deny and etc. I found DenyHosts [1] which is a Python script you can run in daemon mode (or a cronjob) that scans your ssh logs and adds hosts that are trying to break in to /etc/hosts.deny and optionally passes the IP addresses to some simple plugins (could be used to add iptables rules for blocking those hosts). I tried it and I think it's nice. It's available from Fedora Extras. Another script I've found is Daemon Shield [2], but I haven't tried it yet. Adds iptables rules for probing hosts. Any comments? Does anyone know of better scripts? Nils Breunese. [1] http://denyhosts.sourceforge.net/ [2] http://daemonshield.sourceforge.net/ From gerry at pathtech.org Fri Oct 21 14:04:31 2005 From: gerry at pathtech.org (G. Roderick Singleton) Date: Fri, 21 Oct 2005 10:04:31 -0400 Subject: Another security problem.. In-Reply-To: References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> Message-ID: <1129903471.3621.264.camel@www.pathtech.org> On Fri, 2005-10-21 at 15:15 +0200, Nils Breunese (Lemonbit Internet) wrote: > Matthew Nuzum wrote: > > > I've not looked into it, but it would be nice if there was some > > *simple* to > > maintain script that would detect these types of probes and > > automatically > > add the IP to hosts.deny and etc. > [snipped] > > Another script I've found is Daemon Shield [2], but I haven't tried > it yet. Adds iptables rules for probing hosts. Any comments? Does > anyone know of better scripts? > Deamonshield works like a charm. If you check the forums there is a patch to make it work under RH7.3 provided you have python24 installed. > [1] http://denyhosts.sourceforge.net/ > [2] http://daemonshield.sourceforge.net/ > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- G. Roderick Singleton PATH tech From nils at lemonbit.nl Fri Oct 21 14:12:21 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 21 Oct 2005 16:12:21 +0200 Subject: Another security problem.. In-Reply-To: <1129903471.3621.264.camel@www.pathtech.org> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> <1129903471.3621.264.camel@www.pathtech.org> Message-ID: <47C27BC2-AE24-4465-B6F3-C8A52E2B706A@lemonbit.nl> G. Roderick Singleton wrote: >> Another script I've found is Daemon Shield [2], but I haven't tried >> it yet. Adds iptables rules for probing hosts. Any comments? Does >> anyone know of better scripts? > > Deamonshield works like a charm. If you check the forums there is a > patch to make it work under RH7.3 provided you have python24 > installed. I don't believe it's available via yum, right? Nils Breunese. From gerry at pathtech.org Fri Oct 21 14:30:43 2005 From: gerry at pathtech.org (G. Roderick Singleton) Date: Fri, 21 Oct 2005 10:30:43 -0400 Subject: Another security problem.. In-Reply-To: <47C27BC2-AE24-4465-B6F3-C8A52E2B706A@lemonbit.nl> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> <1129903471.3621.264.camel@www.pathtech.org> <47C27BC2-AE24-4465-B6F3-C8A52E2B706A@lemonbit.nl> Message-ID: <1129905043.3621.276.camel@www.pathtech.org> On Fri, 2005-10-21 at 16:12 +0200, Nils Breunese (Lemonbit Internet) wrote: > G. Roderick Singleton wrote: > > >> Another script I've found is Daemon Shield [2], but I haven't tried > >> it yet. Adds iptables rules for probing hosts. Any comments? Does > >> anyone know of better scripts? > > > > Deamonshield works like a charm. If you check the forums there is a > > patch to make it work under RH7.3 provided you have python24 > > installed. > > I don't believe it's available via yum, right? Python24 is. Don't know about daemonshield as I did it from source and haven't a clue how to make a spec file for it. > > Nils Breunese. > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- G. Roderick Singleton PATH tech From nils at lemonbit.nl Fri Oct 21 14:43:00 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Fri, 21 Oct 2005 16:43:00 +0200 Subject: Another security problem.. In-Reply-To: <1129905043.3621.276.camel@www.pathtech.org> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> <1129903471.3621.264.camel@www.pathtech.org> <47C27BC2-AE24-4465-B6F3-C8A52E2B706A@lemonbit.nl> <1129905043.3621.276.camel@www.pathtech.org> Message-ID: G. Roderick Singleton wrote: >>> Deamonshield works like a charm. If you check the forums there is a >>> patch to make it work under RH7.3 provided you have python24 >>> installed. >> >> I don't believe it's available via yum, right? > > Python24 is. Don't know about daemonshield as I did it from source and > haven't a clue how to make a spec file for it. I meant daemonshield. I'm running some FC 2, 3 and 4 servers, but I haven't found a repository carrying daemonshield yet. Nils Breunese. From sheltren at cs.ucsb.edu Fri Oct 21 15:49:14 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 21 Oct 2005 11:49:14 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1129850211.2929.177.camel@prometheus.gamehouse.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> Message-ID: <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> On Oct 20, 2005, at 7:16 PM, Jesse Keating wrote: > On Wed, 2005-10-19 at 14:17 -0400, Jeff Sheltren wrote: > >> I like the idea of having a yum repo file pushed out by redhat, >> although I'm not sure if they'd go for it or not. If not, I think a >> good idea may be for us to release a package like legacy-yumconf-fc3 >> which would provide the file /etc/yum.repos.d/legacy.repo. CentOS >> does something similar if you want an example. If we get real >> ambitious, we could even stick our GPG key on the system (they'd >> still have to manually import it to yum/rpm). >> > > Would somebody be willing to package this up for me? FC5 will have > i386 > and x86_64 repositories, however it may be a while before the x86_64 > ones get used. I guess we could put something in there for ppc(64) > too. > Yep, I can put one together. You do mean 'FC3' and not 'FC5', correct? :) What do you think is better - to create separate RPMs (one for each arch), or to have all the repo configs in one RPM and then just have people enable the correct one by hand? I'm assuming that we're going to leave everything disabled by default, but what do people think? Personally, I think having one RPM with all the repo files in it (disabled by default), and also including the FL GPG key is the way to go. By the way, where to store the GPG key on FC3? I think /etc/pki wasn't brought around until FC4, so I am thinking that /usr/share/doc/ fedora-legacy/ would be a good place for it. -Jeff From michal at harddata.com Fri Oct 21 16:08:24 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 21 Oct 2005 10:08:24 -0600 Subject: Upcoming transition of FC3 In-Reply-To: <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> Message-ID: <20051021160824.GC17004@mail.harddata.com> On Fri, Oct 21, 2005 at 11:49:14AM -0400, Jeff Sheltren wrote: > > By the way, where to store the GPG key on FC3? I think /etc/pki > wasn't brought around until FC4, so I am thinking that /usr/share/doc/ > fedora-legacy/ would be a good place for it. If you want to store keys on a disk then I do not see what is wrong with /etc/pki. You can always create such location and I do not see a particular need to introduce spurious differences between distributions. Of course an URL to the key could be also in http://... , or some other protocol, form. You need to retrieve it only once and rpm from FC3 will import it. Michal From sheltren at cs.ucsb.edu Fri Oct 21 16:26:34 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 21 Oct 2005 12:26:34 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <20051021160824.GC17004@mail.harddata.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <20051021160824.GC17004@mail.harddata.com> Message-ID: <624A4D9A-7CBD-4975-9A0E-B2DEBD863119@cs.ucsb.edu> On Oct 21, 2005, at 12:08 PM, Michal Jaegermann wrote: > On Fri, Oct 21, 2005 at 11:49:14AM -0400, Jeff Sheltren wrote: > >> >> By the way, where to store the GPG key on FC3? I think /etc/pki >> wasn't brought around until FC4, so I am thinking that /usr/share/ >> doc/ >> fedora-legacy/ would be a good place for it. >> > > If you want to store keys on a disk then I do not see what is wrong > with /etc/pki. You can always create such location and I do not see > a particular need to introduce spurious differences between > distributions. True, I am suggesting the /usr/share/doc location to avoid differences between distributions. Since everything pre-FC4 stores keys there. FC4 actually seems to have them in both locations. > > Of course an URL to the key could be also in http://... , or some > other protocol, form. You need to retrieve it only once and rpm > from FC3 will import it. > Yeah, that is also a good idea, but I couldn't remember if the FC3 version of yum supported the URL syntax... -Jeff From jkeating at j2solutions.net Fri Oct 21 16:33:19 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 21 Oct 2005 09:33:19 -0700 Subject: Upcoming transition of FC3 In-Reply-To: <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> Message-ID: <1129912399.2929.181.camel@prometheus.gamehouse.com> On Fri, 2005-10-21 at 11:49 -0400, Jeff Sheltren wrote: > Yep, I can put one together. You do mean 'FC3' and not 'FC5', > correct? :) What do you think is better - to create separate RPMs > (one for each arch), or to have all the repo configs in one RPM and > then just have people enable the correct one by hand? I'm assuming > that we're going to leave everything disabled by default, but what do > people think? > > Personally, I think having one RPM with all the repo files in it > (disabled by default), and also including the FL GPG key is the way > to go. > Well, we need to get packages ready for FC3 for us to provide to the end user, as well as packages ready for FC5 to be included in core distribution. Using $releasever and $basearch variables in our repo file means we can supply one repo file that will work across releases. No need to have different ones. Since we'll have two packages (one we provide for FC3 and FC4, and the one that will go into Fedora Core), the one we provide we can enable by default. The user grabbing the package and installing it seems to be choice enough in my mind. However the package that goes into core should have the repo itself disabled. -- 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 From michal at harddata.com Fri Oct 21 17:25:44 2005 From: michal at harddata.com (Michal Jaegermann) Date: Fri, 21 Oct 2005 11:25:44 -0600 Subject: Upcoming transition of FC3 In-Reply-To: <624A4D9A-7CBD-4975-9A0E-B2DEBD863119@cs.ucsb.edu> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <20051021160824.GC17004@mail.harddata.com> <624A4D9A-7CBD-4975-9A0E-B2DEBD863119@cs.ucsb.edu> Message-ID: <20051021172544.GA19242@mail.harddata.com> On Fri, Oct 21, 2005 at 12:26:34PM -0400, Jeff Sheltren wrote: > On Oct 21, 2005, at 12:08 PM, Michal Jaegermann wrote: > > >Of course an URL to the key could be also in http://... , or some > >other protocol, form. You need to retrieve it only once and rpm > >from FC3 will import it. > > > Yeah, that is also a good idea, but I couldn't remember if the FC3 > version of yum supported the URL syntax... Yes, it does. I am not sure if there was actually a version of yum which did not but I did not see them all. Michal From sheltren at cs.ucsb.edu Fri Oct 21 18:37:54 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 21 Oct 2005 14:37:54 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1129912399.2929.181.camel@prometheus.gamehouse.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> Message-ID: On Oct 21, 2005, at 12:33 PM, Jesse Keating wrote: > > Well, we need to get packages ready for FC3 for us to provide to > the end > user, as well as packages ready for FC5 to be included in core > distribution. Using $releasever and $basearch variables in our repo > file means we can supply one repo file that will work across releases. > No need to have different ones. > > Since we'll have two packages (one we provide for FC3 and FC4, and the > one that will go into Fedora Core), the one we provide we can > enable by > default. The user grabbing the package and installing it seems to be > choice enough in my mind. However the package that goes into core > should have the repo itself disabled. OK, here's a SRPM for FC3 - input is welcome. http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-3-1.fc3.src.rpm The spec file is here: http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf.spec Notice there are separate repo files for base, updates, updates- testing and utils. I think this goes better with the new yum.repos.d format than having only one repo file. Also, both base and updates are enabled, testing and utils are not enabled by default. I think this is a sane and safe default, but I'm open to suggestions. When building for FC5, we'll need to disable all repos by default. I will proceed with that package once we all (or most) agree on this one :) -Jeff From jkeating at j2solutions.net Fri Oct 21 18:53:45 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 21 Oct 2005 11:53:45 -0700 Subject: Upcoming transition of FC3 In-Reply-To: References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> Message-ID: <1129920825.2929.200.camel@prometheus.gamehouse.com> On Fri, 2005-10-21 at 14:37 -0400, Jeff Sheltren wrote: > Notice there are separate repo files for base, updates, updates- > testing and utils. I think this goes better with the new yum.repos.d > format than having only one repo file. Also, both base and updates > are enabled, testing and utils are not enabled by default. I think > this is a sane and safe default, but I'm open to suggestions. > > When building for FC5, we'll need to disable all repos by default. I > will proceed with that package once we all (or most) agree on this > one :) I never did like all the extra repo files for each repository. I liked the idea of one file per family, so there was one file for say freshrpms, one for atrpms, one for extras, one for core/updates, one for Legacy. Each having sub-repos such as testing/devel/whatever. But thats just my opinion. Easier to edit one file than 4. Fedora steering folks tell me that I can go w/ what I prefer. Thoughts? -- 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 From lists at benjamindsmith.com Fri Oct 21 19:22:54 2005 From: lists at benjamindsmith.com (Benjamin Smith) Date: Fri, 21 Oct 2005 12:22:54 -0700 Subject: Another security problem.. In-Reply-To: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> Message-ID: <200510211222.54193.lists@benjamindsmith.com> Some time ago, I wrote a program in PHP that ran as a background task, essentially grabbing the stdin from a "tail -f /var/log/httpd/access.log" It would scan each line of the input for certain patterns. EG: a certain # of hits in the most recent 5 minutes, a bunch of others like known "sploits" and similar behavior (such as "wget" in the URL) and instantly add the offenders to iptables reject for 24 hours. Worked fairly well, but eventually I found maintaining the pattern list cumbersome, and the test types were somewhat difficult to genericize into a config file. Also, caused problems with NAT'd companies, where 1 dirtbag would kick the whole place out for 24 hours. Perhaps this should be released as an OSS Project somewhere? Maybe there's already something out there? Dunno. Quick hack, solved a problem I was having at the time, now "dead wood" and I might not even have it around, anymore. -Ben On Thursday 20 October 2005 12:38, Matthew Nuzum wrote: > I've not looked into it, but it would be nice if there was some *simple* to > maintain script that would detect these types of probes and automatically > add the IP to hosts.deny and etc. > > -- > Matthew Nuzum > www.followers.net - Makers of "Elite Content Management System" > View samples of Elite CMS in action by visiting > http://www.followers.net/portfolio/ > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list > > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From ad+lists at uni-x.org Fri Oct 21 19:28:03 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Fri, 21 Oct 2005 21:28:03 +0200 Subject: Another security problem.. In-Reply-To: <200510211222.54193.lists@benjamindsmith.com> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> <200510211222.54193.lists@benjamindsmith.com> Message-ID: <1129922883.3695.3.camel@serendipity.dogma.lan> Am Fr, den 21.10.2005 schrieb Benjamin Smith um 21:22: > Some time ago, I wrote a program in PHP that ran as a background task, > essentially grabbing the stdin from a > > "tail -f /var/log/httpd/access.log" > > It would scan each line of the input for certain patterns. EG: a certain # of > hits in the most recent 5 minutes, a bunch of others like known "sploits" and > similar behavior (such as "wget" in the URL) and instantly add the offenders > to iptables reject for 24 hours. > > Worked fairly well, but eventually I found maintaining the pattern list > cumbersome, and the test types were somewhat difficult to genericize into a > config file. Also, caused problems with NAT'd companies, where 1 dirtbag > would kick the whole place out for 24 hours. > > Perhaps this should be released as an OSS Project somewhere? Maybe there's > already something out there? > > Dunno. Quick hack, solved a problem I was having at the time, now "dead wood" > and I might not even have it around, anymore. > > -Ben I feel mod-security - www.modsecurity.org - is the better approach. It is available from centos.karan.org repo as an rpm. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 21:26:11 up 1:26, 17 users, 0.47, 0.59, 0.60 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ad+lists at uni-x.org Fri Oct 21 19:36:08 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Fri, 21 Oct 2005 21:36:08 +0200 Subject: Another security problem.. In-Reply-To: <1129922883.3695.3.camel@serendipity.dogma.lan> References: <4357f241.445c2ddd.6a25.2f7a@mx.gmail.com> <200510211222.54193.lists@benjamindsmith.com> <1129922883.3695.3.camel@serendipity.dogma.lan> Message-ID: <1129923368.3695.6.camel@serendipity.dogma.lan> Am Fr, den 21.10.2005 schrieb Alexander Dalloz um 21:28: > I feel mod-security - www.modsecurity.org - is the better approach. It > is available from centos.karan.org repo as an rpm. *g* Forget about the second sentence ;} I thought to communicate on a different list. > Alexander Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 21:34:50 up 1:35, 17 users, 0.73, 0.82, 0.70 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sheltren at cs.ucsb.edu Fri Oct 21 21:12:35 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 21 Oct 2005 17:12:35 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1129920825.2929.200.camel@prometheus.gamehouse.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <1129920825.2929.200.camel@prometheus.gamehouse.com> Message-ID: On Oct 21, 2005, at 2:53 PM, Jesse Keating wrote: > On Fri, 2005-10-21 at 14:37 -0400, Jeff Sheltren wrote: > >> Notice there are separate repo files for base, updates, updates- >> testing and utils. I think this goes better with the new yum.repos.d >> format than having only one repo file. Also, both base and updates >> are enabled, testing and utils are not enabled by default. I think >> this is a sane and safe default, but I'm open to suggestions. >> >> When building for FC5, we'll need to disable all repos by default. I >> will proceed with that package once we all (or most) agree on this >> one :) >> > > I never did like all the extra repo files for each repository. I > liked > the idea of one file per family, so there was one file for say > freshrpms, one for atrpms, one for extras, one for core/updates, > one for > Legacy. Each having sub-repos such as testing/devel/whatever. But > thats just my opinion. Easier to edit one file than 4. Fedora > steering > folks tell me that I can go w/ what I prefer. Thoughts? > Like I said, I prefer having multiple repo files. I find the files to get "messy" once you start adding a lot of repos to one file. Of course, that's just personal preference. I think that multiple files make things easier for those that want to modify a repo. For example, say I am going to mirror the base + updates for FC3, but I will very rarely or never use updates-testing or legacy-utils. Instead of having to edit a file, I can simply copy out a new file for each repo (base & updates) I want to change and leave the others alone. For one host this may seem pointless, but for a large number of hosts I find copying a file is easier and cleaner than editing files. That said, I'm willing to change the RPM to use one legacy.repo if that's what you think is best. If anyone else has any input one way or the other, feel free to chime in. -Jeff From Axel.Thimm at ATrpms.net Fri Oct 21 21:46:32 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 21 Oct 2005 23:46:32 +0200 Subject: Upcoming transition of FC3 In-Reply-To: <1129920825.2929.200.camel@prometheus.gamehouse.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <1129920825.2929.200.camel@prometheus.gamehouse.com> Message-ID: <20051021214632.GC28285@neu.nirvana> On Fri, Oct 21, 2005 at 11:53:45AM -0700, Jesse Keating wrote: > On Fri, 2005-10-21 at 14:37 -0400, Jeff Sheltren wrote: > > Notice there are separate repo files for base, updates, updates- > > testing and utils. I think this goes better with the new yum.repos.d > > format than having only one repo file. Also, both base and updates > > are enabled, testing and utils are not enabled by default. I think > > this is a sane and safe default, but I'm open to suggestions. > > > > When building for FC5, we'll need to disable all repos by default. I > > will proceed with that package once we all (or most) agree on this > > one :) > > I never did like all the extra repo files for each repository. I liked > the idea of one file per family, so there was one file for say > freshrpms, one for atrpms, one for extras, one for core/updates, one for > Legacy. Each having sub-repos such as testing/devel/whatever. But > thats just my opinion. Easier to edit one file than 4. Fedora steering > folks tell me that I can go w/ what I prefer. Thoughts? I agree. Modularity is nice, and when sometimes missed too much, people then tend to have each configuration line in a separate file :) I'd even go as far as declare legacy as part of core/updates. In fact that's how ATrpms distributes yum/smart/apt configuration bits. core/updates/legacy (including disabled *-testing bits) are all in a "base" config file. -- 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 sheltren at cs.ucsb.edu Fri Oct 21 23:21:51 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 21 Oct 2005 19:21:51 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <20051021214632.GC28285@neu.nirvana> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <1129920825.2929.200.camel@prometheus.gamehouse.com> <20051021214632.GC28285@neu.nirvana> Message-ID: <571A579A-3B38-4859-BB62-0ECAFA250592@cs.ucsb.edu> On Oct 21, 2005, at 5:46 PM, Axel Thimm wrote: > On Fri, Oct 21, 2005 at 11:53:45AM -0700, Jesse Keating wrote: >> I never did like all the extra repo files for each repository. I >> liked >> the idea of one file per family, so there was one file for say >> freshrpms, one for atrpms, one for extras, one for core/updates, >> one for >> Legacy. Each having sub-repos such as testing/devel/whatever. But >> thats just my opinion. Easier to edit one file than 4. Fedora >> steering >> folks tell me that I can go w/ what I prefer. Thoughts? >> > > I agree. Modularity is nice, and when sometimes missed too much, > people then tend to have each configuration line in a separate file :) > > I'd even go as far as declare legacy as part of core/updates. In fact > that's how ATrpms distributes yum/smart/apt configuration > bits. core/updates/legacy (including disabled *-testing bits) are all > in a "base" config file. I'm not sure I understand quite what you mean by the 2nd paragraph... Anyway, here's an updated package with two main changes: 1) all repos live in one file - fedora-legacy.repo 2) file is marked as config(noreplace) in the RPM http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-3-2.fc3.src.rpm Spec: http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-2.spec -Jeff From Axel.Thimm at ATrpms.net Sat Oct 22 00:57:23 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 22 Oct 2005 02:57:23 +0200 Subject: Upcoming transition of FC3 In-Reply-To: <571A579A-3B38-4859-BB62-0ECAFA250592@cs.ucsb.edu> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <1129920825.2929.200.camel@prometheus.gamehouse.com> <20051021214632.GC28285@neu.nirvana> <571A579A-3B38-4859-BB62-0ECAFA250592@cs.ucsb.edu> Message-ID: <20051022005723.GA6095@neu.nirvana> On Fri, Oct 21, 2005 at 07:21:51PM -0400, Jeff Sheltren wrote: > On Oct 21, 2005, at 5:46 PM, Axel Thimm wrote: > > >On Fri, Oct 21, 2005 at 11:53:45AM -0700, Jesse Keating wrote: > >>I never did like all the extra repo files for each repository. I > >>liked > >>the idea of one file per family, so there was one file for say > >>freshrpms, one for atrpms, one for extras, one for core/updates, > >>one for > >>Legacy. Each having sub-repos such as testing/devel/whatever. But > >>thats just my opinion. Easier to edit one file than 4. Fedora > >>steering > >>folks tell me that I can go w/ what I prefer. Thoughts? > >> > > > >I agree. Modularity is nice, and when sometimes missed too much, > >people then tend to have each configuration line in a separate file :) > > > >I'd even go as far as declare legacy as part of core/updates. In fact > >that's how ATrpms distributes yum/smart/apt configuration > >bits. core/updates/legacy (including disabled *-testing bits) are all > >in a "base" config file. > > I'm not sure I understand quite what you mean by the 2nd paragraph... To have core/updates/legacy and their testing subrepos in one file and have the testing bits disabled. > Anyway, here's an updated package with two main changes: > 1) all repos live in one file - fedora-legacy.repo > 2) file is marked as config(noreplace) in the RPM > > http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-3-2.fc3.src.rpm > > Spec: http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-2.spec > > -Jeff > -- 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 sheltren at cs.ucsb.edu Sat Oct 22 11:02:51 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 22 Oct 2005 07:02:51 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1129912399.2929.181.camel@prometheus.gamehouse.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> Message-ID: <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> On Oct 21, 2005, at 12:33 PM, Jesse Keating wrote: > > Well, we need to get packages ready for FC3 for us to provide to > the end > user, as well as packages ready for FC5 to be included in core > distribution. Using $releasever and $basearch variables in our repo > file means we can supply one repo file that will work across releases. > No need to have different ones. > > Since we'll have two packages (one we provide for FC3 and FC4, and the > one that will go into Fedora Core), the one we provide we can > enable by > default. The user grabbing the package and installing it seems to be > choice enough in my mind. However the package that goes into core > should have the repo itself disabled. Here's a package for FC5: http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-5-1.fc5.src.rpm Everything is disabled by default. -Jeff From tdiehl at rogueind.com Sat Oct 22 15:49:54 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 22 Oct 2005 11:49:54 -0400 (EDT) Subject: Upcoming transition of FC3 In-Reply-To: <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> Message-ID: On Sat, 22 Oct 2005, Jeff Sheltren wrote: > On Oct 21, 2005, at 12:33 PM, Jesse Keating wrote: > > > > Well, we need to get packages ready for FC3 for us to provide to > > the end > > user, as well as packages ready for FC5 to be included in core > > distribution. Using $releasever and $basearch variables in our repo > > file means we can supply one repo file that will work across releases. > > No need to have different ones. > > > > Since we'll have two packages (one we provide for FC3 and FC4, and the > > one that will go into Fedora Core), the one we provide we can > > enable by > > default. The user grabbing the package and installing it seems to be > > choice enough in my mind. However the package that goes into core > > should have the repo itself disabled. > > Here's a package for FC5: > http://www.cs.ucsb.edu/~jeff/legacy/legacy-yumconf-5-1.fc5.src.rpm > > Everything is disabled by default. Has anyone given thought to pushing an update to yum that enables these repos as the last update to come from the Fedora Project? That way for those that do not realize the transition is happening, it "just works" for them? I realize there are both positives and negatives to this but I just thought I would throw it out for discussion. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From jkeating at j2solutions.net Sat Oct 22 15:59:19 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 22 Oct 2005 08:59:19 -0700 Subject: Upcoming transition of FC3 In-Reply-To: References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> Message-ID: <1129996759.28454.57.camel@yoda.loki.me> On Sat, 2005-10-22 at 11:49 -0400, Tom Diehl wrote: > > Has anyone given thought to pushing an update to yum that enables these > repos as the last update to come from the Fedora Project? That way for those > that do not realize the transition is happening, it "just works" for them? > > I realize there are both positives and negatives to this but I just thought > I would throw it out for discussion. My policy all along has been that users need to make a conscience choice to start getting Legacy updates. This is why we ship the repo files in a disabled state. The directory structure will be there (although empty until just before the release) so if they turn it on early it won't break yum, but I still want them to manually turn it on. With the new graphical updating tool (pup) coming in FC5 it will be as easy as a click of the mouse. -- 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 From nils at lemonbit.nl Sat Oct 22 16:02:22 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Sat, 22 Oct 2005 18:02:22 +0200 Subject: Upcoming transition of FC3 In-Reply-To: <1129996759.28454.57.camel@yoda.loki.me> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> Message-ID: Jesse Keating wrote: > On Sat, 2005-10-22 at 11:49 -0400, Tom Diehl wrote: > >> Has anyone given thought to pushing an update to yum that enables >> these >> repos as the last update to come from the Fedora Project? That way >> for those >> that do not realize the transition is happening, it "just works" >> for them? >> >> I realize there are both positives and negatives to this but I >> just thought >> I would throw it out for discussion. > > My policy all along has been that users need to make a conscience > choice > to start getting Legacy updates. This is why we ship the repo > files in > a disabled state. The directory structure will be there (although > empty > until just before the release) so if they turn it on early it won't > break yum, but I still want them to manually turn it on. Why would anyone who has updates enabled not want legacy updates to be enabled? Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From nils at lemonbit.nl Sat Oct 22 16:13:16 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Sat, 22 Oct 2005 18:13:16 +0200 Subject: Upcoming transition of FC3 In-Reply-To: <1129996759.28454.57.camel@yoda.loki.me> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> Message-ID: <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> Jesse Keating wrote: > On Sat, 2005-10-22 at 11:49 -0400, Tom Diehl wrote: > > >> Has anyone given thought to pushing an update to yum that enables >> these >> repos as the last update to come from the Fedora Project? That way >> for those >> that do not realize the transition is happening, it "just works" >> for them? >> >> I realize there are both positives and negatives to this but I >> just thought >> I would throw it out for discussion. >> > > My policy all along has been that users need to make a conscience > choice > to start getting Legacy updates. This is why we ship the repo > files in > a disabled state. The directory structure will be there (although > empty > until just before the release) so if they turn it on early it won't > break yum, but I still want them to manually turn it on. > Why would anyone who has updates enabled not want legacy updates to be enabled? Nils Breunese. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Sat Oct 22 16:22:28 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 22 Oct 2005 09:22:28 -0700 Subject: Upcoming transition of FC3 In-Reply-To: <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> Message-ID: <1129998148.28454.59.camel@yoda.loki.me> On Sat, 2005-10-22 at 18:13 +0200, Nils Breunese (Lemonbit Internet) wrote: > Why would anyone who has updates enabled not want legacy updates to > be enabled? Because Updates come from Red Hat, whereas Legacy doesn't. I suppose we can toss it up for discussion again, now that there is a precedence set with Extras being enabled by default. -- 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 From jimpop at yahoo.com Sat Oct 22 17:20:44 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sat, 22 Oct 2005 13:20:44 -0400 Subject: Upcoming transition of FC3 In-Reply-To: References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> Message-ID: <435A74EC.1030906@yahoo.com> Nils Breunese (Lemonbit Internet) wrote: > > Why would anyone who has updates enabled not want legacy updates to be > enabled? From my perspective, I want to know *who* the updates are coming from. In the case of Redhat updates, I know that there are ISO-9001 procedures and policies in place as well as corporate oversight and more importantly corporate responsibility (from a legal point of view). From FL you generally (if not universally) get good updates, however do you really really know what was in that last ssh update that you got? While I am not so paranoid to automatically suspect everything I download, I am paranoid enough to try and understand the origin of what I download. So... 1) what server should be used as the default update server for out-of-the-box updates? 2) what policies, purview, scrutiny should that/those server operators be put under and who will take responsibility for enforcing this? 3) what legal disclaimers, and by what means, will alert newbies that they are no longer getting official Redhat updates? Currently all three of the above issues are addressed individually by users who manually configure their systems. This action is so user intensive (visit website, cut-copy-paste yum.conf, download and install yum, etc) that it isolates FL from legal responsibility. All FL has to do to protect itself is not intentionally post malicious code or instructions. -Jim P. From nils at lemonbit.nl Sat Oct 22 17:33:17 2005 From: nils at lemonbit.nl (Nils Breunese (Lemonbit Internet)) Date: Sat, 22 Oct 2005 19:33:17 +0200 Subject: Upcoming transition of FC3 In-Reply-To: <435A74EC.1030906@yahoo.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <435A74EC.1030906@yahoo.com> Message-ID: <49C2C28C-29EC-4A91-8915-70622A2B9BCB@lemonbit.nl> Jim Popovitch wrote: > Nils Breunese (Lemonbit Internet) wrote: > >> Why would anyone who has updates enabled not want legacy updates >> to be enabled? > > From my perspective, I want to know *who* the updates are coming > from. In the case of Redhat updates, I know that there are > ISO-9001 procedures and policies in place as well as corporate > oversight and more importantly corporate responsibility (from a > legal point of view). From FL you generally (if not universally) > get good updates, however do you really really know what was in > that last ssh update that you got? While I am not so paranoid to > automatically suspect everything I download, I am paranoid enough > to try and understand the origin of what I download. > > So... > > 1) what server should be used as the default update server > for out-of-the-box updates? > 2) what policies, purview, scrutiny should that/those server > operators be put under and who will take responsibility > for enforcing this? > 3) what legal disclaimers, and by what means, will alert > newbies that they are no longer getting official Redhat > updates? > > Currently all three of the above issues are addressed individually > by users who manually configure their systems. This action is so > user intensive (visit website, cut-copy-paste yum.conf, download > and install yum, etc) that it isolates FL from legal > responsibility. All FL has to do to protect itself is not > intentionally post malicious code or instructions. Those are all really valid points and I totally agree. Still I have this nagging feeling that a lot of end users will totally not notice their OS is no longer receiving updates and that something like Fedora Legacy is available. You might say they're just to ignorant to care about, but I don't know... Maybe pup will solve this problem, but that may or may not be in FC5. A lot of current users might be left out in the cold without them even knowing. Nils Breunese. From marcdeslauriers at videotron.ca Sat Oct 22 23:50:43 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sat, 22 Oct 2005 19:50:43 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl Message-ID: <435AD053.40800@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-166941 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166941 2005-10-22 --------------------------------------------------------------------- Name : httpd and mod_ssl Versions : rh73: mod_ssl-2.8.12-8.legacy Versions : rh9: httpd-2.0.40-21.20.legacy Versions : fc1: httpd-2.0.51-1.9.legacy Versions : fc2: httpd-2.0.51-2.9.4.legacy Summary : The httpd Web server Description : This package contains a powerful, full-featured, efficient, and freely-available Web server based on work done by the Apache Software Foundation. It is also the most popular Web server on the Internet. --------------------------------------------------------------------- Update Information: Updated mod_ssl and Apache httpd packages that correct two security issues are now available. The Apache HTTP Server is a popular and freely-available Web server. The mod_ssl module provides strong cryptography for the Apache Web server via the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. A flaw was discovered in mod_ssl's handling of the "SSLVerifyClient" directive. This flaw occurs if a virtual host is configured using "SSLVerifyClient optional" and a directive "SSLVerifyClient required" is set for a specific location. For servers configured in this fashion, an attacker may be able to access resources that should otherwise be protected, by not supplying a client certificate when connecting. The Common Vulnerabilities and Exposures project assigned the name CAN-2005-2700 to this issue. A flaw was discovered in Apache httpd where the byterange filter would buffer certain responses into memory. If a server has a dynamic resource such as a CGI script or PHP script that generates a large amount of data, an attacker could send carefully crafted requests in order to consume resources, potentially leading to a Denial of Service. (CAN-2005-2728) Users of mod_ssl and Apache httpd should update to these errata packages that contain backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Fri Sep 23 2005 Jeff Sheltren 2.8.12-8.legacy - patch CAN-2005-2700 (#166941) rh9: * Fri Sep 30 2005 Jeff Sheltren 2.0.40-21.20.legacy - change 'serial' tag to 'epoch' for mod_ssl package * Fri Sep 23 2005 Jeff Sheltren 2.0.40-21.19.legacy - Patches for CAN-2005-2700 and CAN-2005-2728 (#166941) fc1: * Fri Sep 30 2005 Jeff Sheltren 2.0.51-1.9.legacy - Change 'serial' tag to 'epoch' for mod_ssl package * Fri Sep 23 2005 Jeff Sheltren 2.0.51-1.8.legacy - Patches for CAN-2005-2700 and CAN-2005-2728 (#166941) fc2: * Fri Sep 30 2005 Jeff Sheltren 2.0.51-2.9.4.legacy - Change 'serial' tag to 'epoch' for mod_ssl package * Fri Sep 23 2005 Jeff Sheltren 2.0.51-2.9.3.legacy - Patches for CAN-2005-2700 and CAN-2005-2728 (#166941) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 670aa135fb5073b29e94f0a3fe2db9e592b40558 redhat/7.3/updates-testing/i386/mod_ssl-2.8.12-8.legacy.i386.rpm 3442b014c181d2d1d791e8c743b4e627c87e35dc redhat/7.3/updates-testing/SRPMS/mod_ssl-2.8.12-8.legacy.src.rpm rh9: 2e1f513ec64bc94dd087138282fb0e868a1a3abe redhat/9/updates-testing/i386/httpd-2.0.40-21.20.legacy.i386.rpm 8fbff503cd3bf5ce657dbd977b063437775750f7 redhat/9/updates-testing/i386/httpd-devel-2.0.40-21.20.legacy.i386.rpm b0313b4f0203cd03c84facefb1eebdb4ed928c26 redhat/9/updates-testing/i386/httpd-manual-2.0.40-21.20.legacy.i386.rpm 54b412d5bb90f1e649f838b41b1dd4c34ea93c90 redhat/9/updates-testing/SRPMS/httpd-2.0.40-21.20.legacy.src.rpm cface2ec6aca89b8c4641055cabd14a7b37a4ebf redhat/9/updates-testing/i386/mod_ssl-2.0.40-21.20.legacy.i386.rpm fc1: d5cbd7cfdd31b1a6222727f99366407eb06e53e7 fedora/1/updates-testing/i386/httpd-2.0.51-1.9.legacy.i386.rpm 994e4b34b91ae60eb7f632dc50b39c1f5e89aca4 fedora/1/updates-testing/i386/httpd-devel-2.0.51-1.9.legacy.i386.rpm b75c88ba3deda8aed4cb3d6e5d4ea55141554723 fedora/1/updates-testing/i386/httpd-manual-2.0.51-1.9.legacy.i386.rpm 2bd06a4df99b703eea8f882d87b812713e5fa1c2 fedora/1/updates-testing/SRPMS/httpd-2.0.51-1.9.legacy.src.rpm 465efbcc39ef52325928c2dc8093fc6447c33477 fedora/1/updates-testing/i386/mod_ssl-2.0.51-1.9.legacy.i386.rpm fc2: 0f4333e775c1b7b6f5af6e5cf092fa69606766c4 fedora/2/updates-testing/i386/httpd-2.0.51-2.9.4.legacy.i386.rpm 59a54683c490ecfcea66fe0134c9ed6130905602 fedora/2/updates-testing/i386/httpd-devel-2.0.51-2.9.4.legacy.i386.rpm 9a4e89cc67e268424b9eaa4c2183332e8f6f0d0e fedora/2/updates-testing/i386/httpd-manual-2.0.51-2.9.4.legacy.i386.rpm db6c3e2bb4470e592cb74bf3e986ae426010dfaf fedora/2/updates-testing/SRPMS/httpd-2.0.51-2.9.4.legacy.src.rpm a102640b8af24ddaa57ebfbb0e1e78a8a17adbc1 fedora/2/updates-testing/i386/mod_ssl-2.0.51-2.9.4.legacy.i386.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tdiehl at rogueind.com Sun Oct 23 14:29:45 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 23 Oct 2005 10:29:45 -0400 (EDT) Subject: Upcoming transition of FC3 In-Reply-To: <435A74EC.1030906@yahoo.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <435A74EC.1030906@yahoo.com> Message-ID: On Sat, 22 Oct 2005, Jim Popovitch wrote: > Nils Breunese (Lemonbit Internet) wrote: > > > > Why would anyone who has updates enabled not want legacy updates to be > > enabled? > > From my perspective, I want to know *who* the updates are coming from. > In the case of Redhat updates, I know that there are ISO-9001 > procedures and policies in place as well as corporate oversight and more > importantly corporate responsibility (from a legal point of view). From But we are no longer talking about Red Hat or for that matter Red Hat Linux. We are talking about Fedora. Yes, I know Fedora is sponsored by Red Hat but they are not the same. > FL you generally (if not universally) get good updates, however do you > really really know what was in that last ssh update that you got? While Are you telling me you have never had a bad update from Red Hat? Unless they were to do something on purpose I doubt you would ever get more out of them than a fixed update, which is the same thing you would get from FL. > I am not so paranoid to automatically suspect everything I download, I > am paranoid enough to try and understand the origin of what I download. > > So... > > 1) what server should be used as the default update server > for out-of-the-box updates? > 2) what policies, purview, scrutiny should that/those server > operators be put under and who will take responsibility > for enforcing this? > 3) what legal disclaimers, and by what means, will alert > newbies that they are no longer getting official Redhat > updates? They are not getting "official Redhat updates" now. There is no such thing. If you are really thinking about all of the above and paying attention then the change will have no impact on you. You will be on top of things and all is well. What happens to the poor guy who was not paying attention when the FC EOL occured? That same guy that thinks his system is still being updated daily. A remote exploit for ssh gets released in the wild. Now his system is compromised and as far as he is concerned FC is crap, because he has all of the latest updates installed. > Currently all three of the above issues are addressed individually by > users who manually configure their systems. This action is so user > intensive (visit website, cut-copy-paste yum.conf, download and install > yum, etc) that it isolates FL from legal responsibility. All FL has to > do to protect itself is not intentionally post malicious code or > instructions. OK, so how do you help keep the noob that has just installed FC3 from having an un-updated system on the net? Yum comes as a part of Fedora. The Fedora repos are enabled by default once you enable yum. I do not think it is unreasonable to push an update to yum with the FL repos enabled to help protect some noob who just installed FC3 and has not figured out all of the ins and outs of yum. I agree that the policy needs to be well published but I think that enabling the FL repos at FC EOL time is one way to help protect the noob from him/herself. IMO most people who would be upset by enabling FL repos at FC EOL time are savvy enough to turn off the FL repos. I do not think the opposite is necessarily true. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From Axel.Thimm at ATrpms.net Sun Oct 23 15:06:17 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Oct 2005 17:06:17 +0200 Subject: Pruning old vendor update packages? Message-ID: <20051023150617.GE15406@neu.nirvana> Hi, 4.0G download.fedoralegacy.org/fedora/1/updates 2.9G download.fedoralegacy.org/fedora/2/updates 5.6G download.fedoralegacy.org/fedora/3/updates 1.7G download.fedora.redhat.com/pub/fedora/linux/core/updates/1 2.4G download.fedora.redhat.com/pub/fedora/linux/core/updates/2 5.3G download.fedora.redhat.com/pub/fedora/linux/core/updates/3 fedoralegacy.org does not remove old update packages. These make > 3GB for Fedora releases. Could that be fixed? Mirrors would be grateful, and the use of such before-EOL-obsoleted packages is very small. Thanks! -- 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 Axel.Thimm at ATrpms.net Sun Oct 23 15:25:00 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Oct 2005 17:25:00 +0200 Subject: Upcoming transition of FC3 In-Reply-To: <435A74EC.1030906@yahoo.com> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <435A74EC.1030906@yahoo.com> Message-ID: <20051023152500.GF15406@neu.nirvana> On Sat, Oct 22, 2005 at 01:20:44PM -0400, Jim Popovitch wrote: > Nils Breunese (Lemonbit Internet) wrote: > > > >Why would anyone who has updates enabled not want legacy updates to be > >enabled? > > From my perspective, I want to know *who* the updates are coming from. > In the case of Redhat updates, I know that there are ISO-9001 > procedures and policies in place Fedora has no ISO-9001 certification. The extras reporsitory which is enabled by default is the best example. I'd argue that if Fedora's policy is to have the typical Fedora installation default to enabled extras, then it should use legacy by default, too. My model of choice would be to have FL support from the the very first day a distribution gets released. The repo would be empty until FL takes over. No need for any package pushing to users and so on. The actual takeover would be the filling of the repo with FL updated packages. -- 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 tdiehl at rogueind.com Sun Oct 23 15:38:21 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 23 Oct 2005 11:38:21 -0400 (EDT) Subject: (no subject) Message-ID: On Sun, 23 Oct 2005 17:25:00 +0200 Axel Thimm wrote: > My model of choice would be to have FL support from the the very first > day a distribution gets released. The repo would be empty until FL > takes over. No need for any package pushing to users and so on. The > actual takeover would be the filling of the repo with FL updated > packages. I like this better than my original proposal. That way the transition is totally seemless. Anyone who does not want to transition to FL can disable the FL repos. The idea being that if you care, you are smart enough to disable them. The opposite is not always true. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From jkeating at j2solutions.net Sun Oct 23 19:15:46 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 23 Oct 2005 19:15:46 -0000 Subject: Pruning old vendor update packages? In-Reply-To: <20051023150617.GE15406@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> Message-ID: <1098559128.28454.66.camel@yoda.loki.me> On Sun, 2005-10-23 at 17:06 +0200, Axel Thimm wrote: > fedoralegacy.org does not remove old update packages. These make > 3GB > for Fedora releases. > > Could that be fixed? Mirrors would be grateful, and the use of such > before-EOL-obsoleted packages is very small. Yes, I'm working w/ Red Hat on this one. Currently the Yum version on the master server is not new enough to use the yum-utils package. -- 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 From Axel.Thimm at ATrpms.net Sun Oct 23 20:37:47 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Oct 2005 22:37:47 +0200 Subject: Pruning old vendor update packages? In-Reply-To: <1098559128.28454.66.camel@yoda.loki.me> References: <20051023150617.GE15406@neu.nirvana> <1098559128.28454.66.camel@yoda.loki.me> Message-ID: <20051023203747.GH15406@neu.nirvana> On Sat, Oct 23, 2004 at 12:18:48PM -0700, Jesse Keating wrote: > On Sun, 2005-10-23 at 17:06 +0200, Axel Thimm wrote: > > fedoralegacy.org does not remove old update packages. These make > 3GB > > for Fedora releases. > > > > Could that be fixed? Mirrors would be grateful, and the use of such > > before-EOL-obsoleted packages is very small. > > Yes, I'm working w/ Red Hat on this one. Currently the Yum version on > the master server is not new enough to use the yum-utils package. Thanks! Why do you need yum-utils? Doesn't rsync --delete do the job? -- 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 madlists at teaparty.net Mon Oct 24 14:04:38 2005 From: madlists at teaparty.net (Tom Yates) Date: Mon, 24 Oct 2005 15:04:38 +0100 (BST) Subject: Pruning old vendor update packages? In-Reply-To: <20051023150617.GE15406@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> Message-ID: On Sun, 23 Oct 2005, Axel Thimm wrote: > fedoralegacy.org does not remove old update packages. These make > 3GB > for Fedora releases. > > Could that be fixed? Mirrors would be grateful, and the use of such > before-EOL-obsoleted packages is very small. i'm sorry to continue the trend of dissenting voices to every sensible suggestion, but there is one major use of old update packages: they're invaluable for rollback, in the (hopefully unlikely) event that a newly-released package breaks something. if the removal of superseded updates from the mirrors is automated, is there any chance we could always keep the *two* most recent, not just the most recent? -- Tom Yates - http://www.teaparty.net From Axel.Thimm at ATrpms.net Mon Oct 24 15:08:26 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Oct 2005 17:08:26 +0200 Subject: Pruning old vendor update packages? In-Reply-To: References: <20051023150617.GE15406@neu.nirvana> Message-ID: <20051024150826.GD25610@neu.nirvana> On Mon, Oct 24, 2005 at 03:04:38PM +0100, Tom Yates wrote: > On Sun, 23 Oct 2005, Axel Thimm wrote: > > >fedoralegacy.org does not remove old update packages. These make > 3GB > >for Fedora releases. > > > >Could that be fixed? Mirrors would be grateful, and the use of such > >before-EOL-obsoleted packages is very small. > > i'm sorry to continue the trend of dissenting voices to every sensible > suggestion, but there is one major use of old update packages: they're > invaluable for rollback, in the (hopefully unlikely) event that a > newly-released package breaks something. if the removal of superseded > updates from the mirrors is automated, is there any chance we could always > keep the *two* most recent, not just the most recent? I wasn't suggesting removing anything more than what the vendor (Red Hat) already removed. I wouldn't remove Red Hat's last update if FL issues a newer one. -- 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 madlists at teaparty.net Mon Oct 24 15:29:38 2005 From: madlists at teaparty.net (Tom Yates) Date: Mon, 24 Oct 2005 16:29:38 +0100 (BST) Subject: Pruning old vendor update packages? In-Reply-To: <20051024150826.GD25610@neu.nirvana> References: <20051023150617.GE15406@neu.nirvana> <20051024150826.GD25610@neu.nirvana> Message-ID: On Mon, 24 Oct 2005, Axel Thimm wrote: > I wasn't suggesting removing anything more than what the vendor (Red > Hat) already removed. I wouldn't remove Red Hat's last update if FL > issues a newer one. sorry, my misunderstanding; thanks for the clarification. -- Tom Yates - http://www.teaparty.net From rostetter at mail.utexas.edu Mon Oct 24 16:26:41 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 24 Oct 2005 11:26:41 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <1129998148.28454.59.camel@yoda.loki.me> References: <1129744654.2929.26.camel@prometheus.gamehouse.com> <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> Message-ID: <1130171201.bdc469ae6e065@mail.ph.utexas.edu> Quoting Jesse Keating : > On Sat, 2005-10-22 at 18:13 +0200, Nils Breunese (Lemonbit Internet) wrote: > > Why would anyone who has updates enabled not want legacy updates to > > be enabled? > > Because Updates come from Red Hat, whereas Legacy doesn't. I suppose we > can toss it up for discussion again, now that there is a precedence set > with Extras being enabled by default. RHL updates came from Red Hat. Fedora Core updates come from the Fedora Project, which is not the same as Red Hat. So you need to distinguish between the two. That said, I'd still vote for shipping it disabled... -- Eric Rostetter From michal at harddata.com Mon Oct 24 17:12:54 2005 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 24 Oct 2005 11:12:54 -0600 Subject: Upcoming transition of FC3 In-Reply-To: <1130171201.bdc469ae6e065@mail.ph.utexas.edu> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> Message-ID: <20051024171254.GB19763@mail.harddata.com> On Mon, Oct 24, 2005 at 11:26:41AM -0500, Eric Rostetter wrote: > > That said, I'd still vote for shipping it disabled... With what I have seen "in the field" I would rather have that enabled. People who care about such things can disable that easily enough. The problem is with those who expect that things will happen automagically. You can make the corresponding package to spit on stdout prominent warnings from a %post script; that does not matter in which state things will be eventually shipped. Michal From jkeating at j2solutions.net Mon Oct 24 17:31:12 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 24 Oct 2005 10:31:12 -0700 Subject: Upcoming transition of FC3 In-Reply-To: <20051024171254.GB19763@mail.harddata.com> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> Message-ID: <1130175073.2929.221.camel@prometheus.gamehouse.com> On Mon, 2005-10-24 at 11:12 -0600, Michal Jaegermann wrote: > With what I have seen "in the field" I would rather have that > enabled. People who care about such things can disable that easily > enough. The problem is with those who expect that things will > happen automagically. > > You can make the corresponding package to spit on stdout prominent > warnings from a %post script; that does not matter in which state > things will be eventually shipped. I'll bring this up to the Fedora Steering Committee and see how they feel about these updates being enabled by default. For Fedora stuff, I now am leaning toward enable by default. I think Michal and others may be right, those who are in the 'know' and don't want our updates can easily disable it. -- 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 From sheltren at cs.ucsb.edu Mon Oct 24 17:37:44 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 24 Oct 2005 13:37:44 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1130175073.2929.221.camel@prometheus.gamehouse.com> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130175073.2929.221.camel@prometheus.gamehouse.com> Message-ID: On Oct 24, 2005, at 1:31 PM, Jesse Keating wrote: > > I'll bring this up to the Fedora Steering Committee and see how they > feel about these updates being enabled by default. For Fedora > stuff, I > now am leaning toward enable by default. I think Michal and others > may > be right, those who are in the 'know' and don't want our updates can > easily disable it. > Plus those "in the know" will either be running a newer version of FC by then, or they will actually want to have legacy updates instead of running an un-patched machine :) I agree, if the steering committee is OK with it, then I think we should enable it by default and leave the repo empty until we take over for that version of FC. This will help many more people than it will hurt, IMO. -Jeff From rostetter at mail.utexas.edu Mon Oct 24 18:41:45 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 24 Oct 2005 13:41:45 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <20051024171254.GB19763@mail.harddata.com> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> Message-ID: <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> Quoting Michal Jaegermann : > On Mon, Oct 24, 2005 at 11:26:41AM -0500, Eric Rostetter wrote: > > > > That said, I'd still vote for shipping it disabled... > > With what I have seen "in the field" I would rather have that > enabled. I undertsand a lot of people feel that way. But "Best Practices" dictate the opposite. The question for a long time is should we run this project on Industry Standard Best Practices so that it is suitable for business use or just run it so that it is the easiest for the average home user (or unskilled business computer admin) to use? Since most of the people at the "higher levels" of the project are business or university people, their views tend to trend towards best practices. Since most of the people who use FL are average home users and such, their desires are just the opposite. > People who care about such things can disable that easily > enough. If they do their due dillegence and notice that we've changed things on them with a package upgrade without their permission. Which hopefully they will, but we can't guarantee that they will. > The problem is with those who expect that things will > happen automagically. Yes, or more specifically the problem is with those who expect things to be done for them automatically, versus those who require a controlled environment. > You can make the corresponding package to spit on stdout prominent > warnings from a %post script; that does not matter in which state > things will be eventually shipped. This may be. I'll leave that up to others to decide if this is practical (e.g. do people using up2date see such messages, etc). > Michal -- Eric Rostetter From jimpop at yahoo.com Mon Oct 24 19:13:59 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 24 Oct 2005 15:13:59 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1130175073.2929.221.camel@prometheus.gamehouse.com> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130175073.2929.221.camel@prometheus.gamehouse.com> Message-ID: <435D3277.1030600@yahoo.com> Jesse Keating wrote: > > I'll bring this up to the Fedora Steering Committee and see how they > feel about these updates being enabled by default. For Fedora stuff, I > now am leaning toward enable by default. I think Michal and others may > be right, those who are in the 'know' and don't want our updates can > easily disable it. The problem, and we have all seen this, is that those in the 'know' are not the ones who would sue FL. All it will take is for FL to automagically update one package that breaks a custom billing application on a bored lawyer's computer.... I don't think the risk is worth trying to be noble. Rather than auto-updating by default, why not just disable network interfaces at EOL? -Jim P. From sheltren at cs.ucsb.edu Mon Oct 24 19:17:30 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 24 Oct 2005 15:17:30 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> Message-ID: <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> On Oct 24, 2005, at 2:41 PM, Eric Rostetter wrote: > Quoting Michal Jaegermann : > >> People who care about such things can disable that easily >> enough. >> > > If they do their due dillegence and notice that we've changed things > on them with a package upgrade without their permission. Which > hopefully > they will, but we can't guarantee that they will. > > Eric, in the case of our repo included with Fedora Core - this isn't happening with a package upgrade without the user's knowledge. It will be a separate 'fedora-legacy' package they need to install (I'm not sure if it will get installed by default on FC5, but I think that would be nice). This is similar to how Fedora Extras has its repo enabled by default on all FC4 machines. It's just something that admins need to be aware of, if they don't like it, they can disable/ remove the repo. -Jeff From matt.followers at gmail.com Mon Oct 24 19:53:13 2005 From: matt.followers at gmail.com (Matthew Nuzum) Date: Mon, 24 Oct 2005 14:53:13 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <435D3277.1030600@yahoo.com> Message-ID: <435d3ba3.14213f45.4881.fffffdc6@mx.gmail.com> > The problem, and we have all seen this, is that those in the 'know' are > not the ones who would sue FL. All it will take is for FL to > automagically update one package that breaks a custom billing > application on a bored lawyer's computer.... I don't think the risk is > worth trying to be noble. > > Rather than auto-updating by default, why not just disable network > interfaces at EOL? > > -Jim P. Very intriguing idea... I'll bet this could be developed into a ton of excellent sys-admin jokes. I'd like it if someone posted the suggestion to Slashdot so I can read all the replies it would generate. An interesting way to make everyone happy in future generations would be to create the FCL repo before the FC version is even released. Then everyone could have the FCL repo in their yum config from the very beginning. Since there's nothing eventful going on with FCL's repo until FCx+2 is near, it would have no impact. However, once EOL comes up and FCL takes over, new updates will automatically start coming from the FCL repo. This drastically reduces the likelihood of an unpleasant surprise. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From matt.followers at gmail.com Mon Oct 24 19:59:18 2005 From: matt.followers at gmail.com (Matthew Nuzum) Date: Mon, 24 Oct 2005 14:59:18 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <435D3277.1030600@yahoo.com> Message-ID: <435d3d0d.362a035a.5170.0224@mx.gmail.com> > The problem, and we have all seen this, is that those in the 'know' are > not the ones who would sue FL. All it will take is for FL to > automagically update one package that breaks a custom billing > application on a bored lawyer's computer.... I don't think the risk is > worth trying to be noble. ... > -Jim P. BTW, FC isn't for bored lawyers and no one will get sued if FC breaks. FC is explicitly designed for people who need to be on the cutting edge of Linux and are willing to sacrifice the rock-solid stability that RHEL provides. Anyone "in the know" who is deploying FC to bored lawyers or others computers in need of serious reliability is a glutton for pain, IMHO. -- Matthew Nuzum www.followers.net - Makers of "Elite Content Management System" View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ From jimpop at yahoo.com Mon Oct 24 20:09:05 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 24 Oct 2005 16:09:05 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <435d3ba3.14213f45.4881.fffffdc6@mx.gmail.com> References: <435d3ba3.14213f45.4881.fffffdc6@mx.gmail.com> Message-ID: <435D3F61.2060002@yahoo.com> Matthew Nuzum wrote: >> The problem, and we have all seen this, is that those in the 'know' are >> not the ones who would sue FL. All it will take is for FL to >> automagically update one package that breaks a custom billing >> application on a bored lawyer's computer.... I don't think the risk is >> worth trying to be noble. >> >> Rather than auto-updating by default, why not just disable network >> interfaces at EOL? >> >> -Jim P. > > Very intriguing idea... I'll bet this could be developed into a ton of > excellent sys-admin jokes. I'd like it if someone posted the suggestion to > Slashdot so I can read all the replies it would generate. > > An interesting way to make everyone happy in future generations would be to > create the FCL repo before the FC version is even released. Then everyone > could have the FCL repo in their yum config from the very beginning. Since > there's nothing eventful going on with FCL's repo until FCx+2 is near, it > would have no impact. However, once EOL comes up and FCL takes over, new > updates will automatically start coming from the FCL repo. This drastically > reduces the likelihood of an unpleasant surprise. The chief issue I see is with the implementation as Redhat/Fedora and FL are two completely different organizations. People trust Redhat, but those same people don't transfer that trust to FL probably due to the looseness of FL. Basically you would have to convince RH's lawyers to allow you to take over responsibility for their EOL'ed systems. Right now the RH lawyers don't care. We could have the FL lawyers, opps there are no FL lawyers. ;-) What you need is for the RH lawyers to provide a way for you to add yum configs to something they are still responsible for. This issue isn't a technical one, it is a legal one. -Jim P. From jimpop at yahoo.com Mon Oct 24 20:12:43 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 24 Oct 2005 16:12:43 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <435d3d0d.362a035a.5170.0224@mx.gmail.com> References: <435d3d0d.362a035a.5170.0224@mx.gmail.com> Message-ID: <435D403B.7070005@yahoo.com> Matthew Nuzum wrote: >> The problem, and we have all seen this, is that those in the 'know' are >> not the ones who would sue FL. All it will take is for FL to >> automagically update one package that breaks a custom billing >> application on a bored lawyer's computer.... I don't think the risk is >> worth trying to be noble. > ... >> -Jim P. > > BTW, FC isn't for bored lawyers and no one will get sued if FC breaks. FC is > explicitly designed for people who need to be on the cutting edge of Linux > and are willing to sacrifice the rock-solid stability that RHEL provides. So, recall those copies of FC from those individuals that you feel aren't worthy of it. Sorry, but the cat is already out of the bag. > Anyone "in the know" who is deploying FC to bored lawyers or others > computers in need of serious reliability is a glutton for pain, IMHO. ;-) you seem to miss my point, but your humor is still enjoyable. -Jim P. From rostetter at mail.utexas.edu Mon Oct 24 20:38:36 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 24 Oct 2005 15:38:36 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> Message-ID: <1130186316.253b3a830a4d1@mail.ph.utexas.edu> Quoting Jeff Sheltren : > Eric, in the case of our repo included with Fedora Core - this isn't > happening with a package upgrade without the user's knowledge. It > will be a separate 'fedora-legacy' package they need to install (I'm I thought it was just a change to the yum package or something. If it is a separate package, then I'm cool with it being enabled by default. In that case, I would have to install the package, so it wouldn't matter what the default it. (But, having said that, see below (end of message) for a counter argument.) If the change was an update to an existing package (update to yum, up2date, etc) then I would want it to be disabled by default. I admit I've not followed the argument blow-by-blow and I'm not sure exactly how it would be implemented. > not sure if it will get installed by default on FC5, but I think that > would be nice). I'm not too worried about that, as I always select packages to install manually. > This is similar to how Fedora Extras has its repo > enabled by default on all FC4 machines. It's just something that > admins need to be aware of, if they don't like it, they can disable/ > remove the repo. > > -Jeff Well, the Red Hat line since RHL 8 is "install all services disabled" rather than the line before that which was "install all services enabled" and doing so cut down almost completely on the number of worms being spread around the net for RHL machines. (Remember the worm outbreak with RHL 6 and 7 machines because all the services where enabled at installation?) I think that this is the correct philosophy, and I think it should extend to things like repositories. Just as if I install sendmail or apache they are disabled by default, I'd expect my repository to be disabled by default when I install it. Doing so would mean more consistency of installation behaviour IMHO. Your opinion may differ, and I respect that. -- Eric Rostetter From jedgecombe at carolina.rr.com Mon Oct 24 20:53:59 2005 From: jedgecombe at carolina.rr.com (Jason Edgecombe) Date: Mon, 24 Oct 2005 16:53:59 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <435D3F61.2060002@yahoo.com> References: <435d3ba3.14213f45.4881.fffffdc6@mx.gmail.com> <435D3F61.2060002@yahoo.com> Message-ID: <435D49E7.90003@carolina.rr.com> Jim Popovitch wrote: > Matthew Nuzum wrote: > >>> The problem, and we have all seen this, is that those in the 'know' are >>> not the ones who would sue FL. All it will take is for FL to >>> automagically update one package that breaks a custom billing >>> application on a bored lawyer's computer.... I don't think the >>> risk is >>> worth trying to be noble. >>> >>> Rather than auto-updating by default, why not just disable network >>> interfaces at EOL? >>> >>> -Jim P. >> >> >> Very intriguing idea... I'll bet this could be developed into a ton of >> excellent sys-admin jokes. I'd like it if someone posted the >> suggestion to >> Slashdot so I can read all the replies it would generate. >> >> An interesting way to make everyone happy in future generations would >> be to >> create the FCL repo before the FC version is even released. Then >> everyone >> could have the FCL repo in their yum config from the very beginning. >> Since >> there's nothing eventful going on with FCL's repo until FCx+2 is >> near, it >> would have no impact. However, once EOL comes up and FCL takes over, new >> updates will automatically start coming from the FCL repo. This >> drastically >> reduces the likelihood of an unpleasant surprise. > > > The chief issue I see is with the implementation as Redhat/Fedora and > FL are two completely different organizations. People trust Redhat, > but those same people don't transfer that trust to FL probably due to > the looseness of FL. > > Basically you would have to convince RH's lawyers to allow you to take > over responsibility for their EOL'ed systems. Right now the RH > lawyers don't care. We could have the FL lawyers, opps there are no > FL lawyers. ;-) What you need is for the RH lawyers to provide a way > for you to add yum configs to something they are still responsible for. > > This issue isn't a technical one, it is a legal one. > > -Jim P. > 1. Those people are already trusting Fedora Extras. 2. I've met some professionals who didn't know about FL and thought they were getting updates, just none had come out in a while. Jason From jkeating at j2solutions.net Mon Oct 24 20:56:06 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 24 Oct 2005 13:56:06 -0700 Subject: Upcoming transition of FC3 In-Reply-To: <1130186316.253b3a830a4d1@mail.ph.utexas.edu> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> <1130186316.253b3a830a4d1@mail.ph.utexas.edu> Message-ID: <1130187366.2929.268.camel@prometheus.gamehouse.com> On Mon, 2005-10-24 at 15:38 -0500, Eric Rostetter wrote: > I thought it was just a change to the yum package or something. > > If it is a separate package, then I'm cool with it being enabled by > default. In that case, I would have to install the package, so it > wouldn't matter what the default it. (But, having said that, see > below (end of message) for a counter argument.) Well, if it was included w/ Core, it would be most likely part of the same package that supplied the extras repo files and the core repo files. Given that things like Extras are enabled by default, we should enable ours as well, just not the updates-testing. [..snip..] > Well, the Red Hat line since RHL 8 is "install all services disabled" rather > than the line before that which was "install all services enabled" and doing > so cut down almost completely on the number of worms being spread around > the net for RHL machines. (Remember the worm outbreak with RHL 6 and 7 > machines because all the services where enabled at installation?) > > I think that this is the correct philosophy, and I think it should extend > to things like repositories. Just as if I install sendmail or apache > they are disabled by default, I'd expect my repository to be disabled by > default when I install it. Doing so would mean more consistency of > installation behaviour IMHO. > > Your opinion may differ, and I respect that. WRT Red Hat Linux, this is indeed the correct philosophy. This is why our service is an opt-in rather than opt-out for RHL. However Fedora doesn't have exactly the same goals or philosophy that RHL did. For that reason, I think we should fall more inline with the feel and philosophy of Fedora when dealing w/ Fedora releases. -- 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 From rostetter at mail.utexas.edu Mon Oct 24 21:10:52 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 24 Oct 2005 16:10:52 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <1130187366.2929.268.camel@prometheus.gamehouse.com> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> <1130186316.253b3a830a4d1@mail.ph.utexas.edu> <1130187366.2929.268.camel@prometheus.gamehouse.com> Message-ID: <1130188252.cf3ffa3b25e0a@mail.ph.utexas.edu> Quoting Jesse Keating : > On Mon, 2005-10-24 at 15:38 -0500, Eric Rostetter wrote: > > I thought it was just a change to the yum package or something. > > > > If it is a separate package, then I'm cool with it being enabled by > > default. In that case, I would have to install the package, so it > > wouldn't matter what the default it. (But, having said that, see > > below (end of message) for a counter argument.) > > Well, if it was included w/ Core, it would be most likely part of the > same package that supplied the extras repo files and the core repo > files. Given that things like Extras are enabled by default, we should > enable ours as well, just not the updates-testing. I supppose to continue this argument further without knowing which package, or what kind of package, we would use, is rather pointless. > WRT Red Hat Linux, this is indeed the correct philosophy. This is why > our service is an opt-in rather than opt-out for RHL. However Fedora > doesn't have exactly the same goals or philosophy that RHL did. For > that reason, I think we should fall more inline with the feel and > philosophy of Fedora when dealing w/ Fedora releases. I can see that to some extent. I can also see that the "philosophy" of Fedora is that it is dead when it is dead, and FL is not part of Fedora. So it is open to debate. And depends in part on how much the Fedora Project wants to officially recognize (endorse, etc) the Fedora Legacy Project. Anyway, as I said above, it is rather silly to argue about this until we decide how (in what package, etc) it is to be implemented. I don't think we can truely know what the best state (enabled or disabled) would be until we know what package we're talking about (a current package, a new package, etc). > -- > Jesse Keating RHCE (http://geek.j2solutions.net) > Fedora Legacy Team (http://www.fedoralegacy.org) > GPG Public Key > (http://geek.j2solutions.net/jkeating.j2solutions.pub) -- Eric Rostetter From sheltren at cs.ucsb.edu Mon Oct 24 21:57:24 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 24 Oct 2005 17:57:24 -0400 Subject: Upcoming transition of FC3 In-Reply-To: <1130188252.cf3ffa3b25e0a@mail.ph.utexas.edu> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> <1130186316.253b3a830a4d1@mail.ph.utexas.edu> <1130187366.2929.268.camel@prometheus.gamehouse.com> <1130188252.cf3ffa3b25e0a@mail.ph.utexas.edu> Message-ID: <86B9B76E-7A98-4510-A22A-BBAA24B782E7@cs.ucsb.edu> On Oct 24, 2005, at 5:10 PM, Eric Rostetter wrote: > > Anyway, as I said above, it is rather silly to argue about this until > we decide how (in what package, etc) it is to be implemented. I don't > think we can truely know what the best state (enabled or disabled) > would > be until we know what package we're talking about (a current package, > a new package, etc). > > Hi Eric, it will be different depending on if you are talking about fedora core < 5 or FC5 and newer. For those like FC3, and FC4, we will provide our own package; for now I've named it legacy-yumconf. Those packages will not be incorporated into Fedora Core, they will need to be installed by the user of their own free will. I think that everyone is in agreement that for these packages the legacy base and updates repos should be enabled by default. For FC5 and newer, the plan is to have a legacy.repo file included by default. I assume this would be included in the fedora-release RPM, which is what provides the other yum repo files, but that is up to the Fedora Steering Committee. -Jeff From jimpop at yahoo.com Mon Oct 24 22:26:03 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 24 Oct 2005 18:26:03 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435AD053.40800@videotron.ca> References: <435AD053.40800@videotron.ca> Message-ID: <435D5F7B.6060702@yahoo.com> I've got a few questions about this release of mod_ssl. 1) why is it bundled w/ httpd v2.0 and not a separate bug? 2) does anything in this apply to apache v1.3? 3) why was it never tracked in Pekka's issues list? 4) why am I the only one inquiring about this. :-) -Jim P. Marc Deslauriers wrote: > --------------------------------------------------------------------- > Fedora Legacy Test Update Notification > FEDORALEGACY-2005-166941 > Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166941 > 2005-10-22 > --------------------------------------------------------------------- > > Name : httpd and mod_ssl > Versions : rh73: mod_ssl-2.8.12-8.legacy > Versions : rh9: httpd-2.0.40-21.20.legacy > Versions : fc1: httpd-2.0.51-1.9.legacy > Versions : fc2: httpd-2.0.51-2.9.4.legacy > Summary : The httpd Web server > Description : > This package contains a powerful, full-featured, efficient, and > freely-available Web server based on work done by the Apache Software > Foundation. It is also the most popular Web server on the Internet. > > --------------------------------------------------------------------- > Update Information: > > Updated mod_ssl and Apache httpd packages that correct two security > issues are now available. > > The Apache HTTP Server is a popular and freely-available Web server. > > The mod_ssl module provides strong cryptography for the Apache Web > server via the Secure Sockets Layer (SSL) and Transport Layer Security > (TLS) protocols. > > A flaw was discovered in mod_ssl's handling of the "SSLVerifyClient" > directive. This flaw occurs if a virtual host is configured > using "SSLVerifyClient optional" and a directive "SSLVerifyClient > required" is set for a specific location. For servers configured in this > fashion, an attacker may be able to access resources that should > otherwise be protected, by not supplying a client certificate when > connecting. The Common Vulnerabilities and Exposures project assigned > the name CAN-2005-2700 to this issue. > > A flaw was discovered in Apache httpd where the byterange filter would > buffer certain responses into memory. If a server has a dynamic > resource such as a CGI script or PHP script that generates a large > amount of data, an attacker could send carefully crafted requests in > order to consume resources, potentially leading to a Denial of Service. > (CAN-2005-2728) > > Users of mod_ssl and Apache httpd should update to these errata packages > that contain backported patches to correct these issues. > > --------------------------------------------------------------------- > Changelogs > > rh73: > * Fri Sep 23 2005 Jeff Sheltren 2.8.12-8.legacy > - patch CAN-2005-2700 (#166941) > > rh9: > * Fri Sep 30 2005 Jeff Sheltren 2.0.40-21.20.legacy > - change 'serial' tag to 'epoch' for mod_ssl package > > * Fri Sep 23 2005 Jeff Sheltren 2.0.40-21.19.legacy > - Patches for CAN-2005-2700 and CAN-2005-2728 (#166941) > > fc1: > * Fri Sep 30 2005 Jeff Sheltren 2.0.51-1.9.legacy > - Change 'serial' tag to 'epoch' for mod_ssl package > > * Fri Sep 23 2005 Jeff Sheltren 2.0.51-1.8.legacy > - Patches for CAN-2005-2700 and CAN-2005-2728 (#166941) > > fc2: > * Fri Sep 30 2005 Jeff Sheltren 2.0.51-2.9.4.legacy > - Change 'serial' tag to 'epoch' for mod_ssl package > > * Fri Sep 23 2005 Jeff Sheltren 2.0.51-2.9.3.legacy > - Patches for CAN-2005-2700 and CAN-2005-2728 (#166941) > > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedoralegacy.org/ > (sha1sums) > > rh73: > 670aa135fb5073b29e94f0a3fe2db9e592b40558 > redhat/7.3/updates-testing/i386/mod_ssl-2.8.12-8.legacy.i386.rpm > 3442b014c181d2d1d791e8c743b4e627c87e35dc > redhat/7.3/updates-testing/SRPMS/mod_ssl-2.8.12-8.legacy.src.rpm > > rh9: > 2e1f513ec64bc94dd087138282fb0e868a1a3abe > redhat/9/updates-testing/i386/httpd-2.0.40-21.20.legacy.i386.rpm > 8fbff503cd3bf5ce657dbd977b063437775750f7 > redhat/9/updates-testing/i386/httpd-devel-2.0.40-21.20.legacy.i386.rpm > b0313b4f0203cd03c84facefb1eebdb4ed928c26 > redhat/9/updates-testing/i386/httpd-manual-2.0.40-21.20.legacy.i386.rpm > 54b412d5bb90f1e649f838b41b1dd4c34ea93c90 > redhat/9/updates-testing/SRPMS/httpd-2.0.40-21.20.legacy.src.rpm > cface2ec6aca89b8c4641055cabd14a7b37a4ebf > redhat/9/updates-testing/i386/mod_ssl-2.0.40-21.20.legacy.i386.rpm > > fc1: > d5cbd7cfdd31b1a6222727f99366407eb06e53e7 > fedora/1/updates-testing/i386/httpd-2.0.51-1.9.legacy.i386.rpm > 994e4b34b91ae60eb7f632dc50b39c1f5e89aca4 > fedora/1/updates-testing/i386/httpd-devel-2.0.51-1.9.legacy.i386.rpm > b75c88ba3deda8aed4cb3d6e5d4ea55141554723 > fedora/1/updates-testing/i386/httpd-manual-2.0.51-1.9.legacy.i386.rpm > 2bd06a4df99b703eea8f882d87b812713e5fa1c2 > fedora/1/updates-testing/SRPMS/httpd-2.0.51-1.9.legacy.src.rpm > 465efbcc39ef52325928c2dc8093fc6447c33477 > fedora/1/updates-testing/i386/mod_ssl-2.0.51-1.9.legacy.i386.rpm > > fc2: > 0f4333e775c1b7b6f5af6e5cf092fa69606766c4 > fedora/2/updates-testing/i386/httpd-2.0.51-2.9.4.legacy.i386.rpm > 59a54683c490ecfcea66fe0134c9ed6130905602 > fedora/2/updates-testing/i386/httpd-devel-2.0.51-2.9.4.legacy.i386.rpm > 9a4e89cc67e268424b9eaa4c2183332e8f6f0d0e > fedora/2/updates-testing/i386/httpd-manual-2.0.51-2.9.4.legacy.i386.rpm > db6c3e2bb4470e592cb74bf3e986ae426010dfaf > fedora/2/updates-testing/SRPMS/httpd-2.0.51-2.9.4.legacy.src.rpm > a102640b8af24ddaa57ebfbb0e1e78a8a17adbc1 > fedora/2/updates-testing/i386/mod_ssl-2.0.51-2.9.4.legacy.i386.rpm > > --------------------------------------------------------------------- > > Please test and comment in bugzilla. > > > ------------------------------------------------------------------------ > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From jkeating at j2solutions.net Mon Oct 24 22:38:55 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 24 Oct 2005 15:38:55 -0700 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435D5F7B.6060702@yahoo.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> Message-ID: <1130193535.28809.1.camel@prometheus.gamehouse.com> On Mon, 2005-10-24 at 18:26 -0400, Jim Popovitch wrote: > I've got a few questions about this release of mod_ssl. > > 1) why is it bundled w/ httpd v2.0 and not a separate bug? There are two flaws. One in http 2.0 and one in mod_ssl. This is explained in the Update Information. > 2) does anything in this apply to apache v1.3? The http bug does not appear to effect 1.3, however mod_ssl is effected, and thus released for 7.3 > 3) why was it never tracked in Pekka's issues list? No idea, it was filed on 8/28 of this year. > 4) why am I the only one inquiring about this. :-) *shrug* -- 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 From michal at harddata.com Mon Oct 24 23:14:36 2005 From: michal at harddata.com (Michal Jaegermann) Date: Mon, 24 Oct 2005 17:14:36 -0600 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435D5F7B.6060702@yahoo.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> Message-ID: <20051024231436.GA27315@mail.harddata.com> On Mon, Oct 24, 2005 at 06:26:03PM -0400, Jim Popovitch wrote: > I've got a few questions about this release of mod_ssl. > > 1) why is it bundled w/ httpd v2.0 and not a separate bug? Actually it exists a separate bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168420 but it was closed with a reference to 166941 in order to track everything together. The subject for 166941 is indeed somewhat confusing in the context. > 2) does anything in this apply to apache v1.3? Yes but indirectly. These are two different packages there. > 3) why was it never tracked in Pekka's issues list? If you would look at that list a bit closer you would find the information above rather quickly. > 4) why am I the only one inquiring about this. :-) Dunno. Others checked before asking? Michal From gerry at pathtech.org Mon Oct 24 23:36:18 2005 From: gerry at pathtech.org (G. Roderick Singleton) Date: Mon, 24 Oct 2005 19:36:18 -0400 Subject: what about upgrades to sendmail? Message-ID: <1130196978.3567.324.camel@www.pathtech.org> I ask because I have successfully created an rpm of sendmail-8.13.4 for RH7.3 which has solved many email security problems. Is there a place for this in fedora legacy? -- G. Roderick Singleton PATH tech From jkeating at j2solutions.net Mon Oct 24 23:50:06 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 24 Oct 2005 16:50:06 -0700 Subject: what about upgrades to sendmail? In-Reply-To: <1130196978.3567.324.camel@www.pathtech.org> References: <1130196978.3567.324.camel@www.pathtech.org> Message-ID: <1130197806.28809.4.camel@prometheus.gamehouse.com> On Mon, 2005-10-24 at 19:36 -0400, G. Roderick Singleton wrote: > > I ask because I have successfully created an rpm of sendmail-8.13.4 for > RH7.3 which has solved many email security problems. Is there a place > for this in fedora legacy? Are they security problems not addressed by current open bugs at bugzilla.redhat.com for Legacy packages? Do they actually affect the version of sendmail that is being used (are you sure they haven't been fixed by prior revisions of the sendmail rpm?) We patch in the security patch but don't upgrade the sendmail version. -- 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 From jimpop at yahoo.com Mon Oct 24 23:55:27 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 24 Oct 2005 19:55:27 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <20051024231436.GA27315@mail.harddata.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> Message-ID: <435D746F.6040802@yahoo.com> Michal Jaegermann wrote: > On Mon, Oct 24, 2005 at 06:26:03PM -0400, Jim Popovitch wrote: >> I've got a few questions about this release of mod_ssl. >> >> 1) why is it bundled w/ httpd v2.0 and not a separate bug? > > Actually it exists a separate bug report: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168420 > but it was closed with a reference to 166941 in order to track > everything together. The subject for 166941 is indeed somewhat > confusing in the context. Not just the subject, the contents too. There is no Apache v2.0 for RH 7.3, yet the body explicitly says that 7.3 is affected. >> 2) does anything in this apply to apache v1.3? > > Yes but indirectly. These are two different packages there. > >> 3) why was it never tracked in Pekka's issues list? > > If you would look at that list a bit closer you would find the > information above rather quickly. I did check before asking, thus the nature of my questions. I haven't yet seen one bug filed for 2 packages where there are separate fixes for each package, in fact I thought that was against the rules. I do see how these two issues are related, but it appears senseless to bundle the release when only one-half of it affects RH 7.3 (for which there is no apache 2.0). I use Pekka's issues list (Thank you Pekka) to track issues as I find bugzilla a waste of time. I do login to bugzilla for the details of issues that interest me, but I rely on seeing them in Pekka's list, or seeing them on FL emails, prior to drilling into the specific ID in bugzilla. That said, I doubt this is a problem w/ Pekka's list as he has been very exacting up until now. With this bug(s) I see the explanation above (separate bug report, etc), but I don't see any reference to 168420 and 166941 in any of the issues lists. >> 4) why am I the only one inquiring about this. :-) > > Dunno. Others checked before asking? To excuse this as "Other's checked before asking" is not accurate as the data just isn't there to support even having the ability to check. Show me discussions of this bug outside of a bugID that isn't referenced anywhere else. And please don't suggest that I am to be trolling bugzilla every day for the hundreds of packages for which I may or may not be interested in knowing if a bug exists. The bottom line is that I regularly keep on top of RH73 bugs/updates/patches and I missed this. OK, so I am human and subject to errors, but this bug stayed well below the FL radar for many months. I have a pretty good record of downloading and testing updates, so the fact that this critical one slipped by alarms me. -Jim P. From sheltren at cs.ucsb.edu Tue Oct 25 00:36:16 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 24 Oct 2005 20:36:16 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435D746F.6040802@yahoo.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> Message-ID: On Oct 24, 2005, at 7:55 PM, Jim Popovitch wrote: > > I did check before asking, thus the nature of my questions. I > haven't yet seen one bug filed for 2 packages where there are > separate fixes for each package, in fact I thought that was against > the rules. I do see how these two issues are related, but it > appears senseless to bundle the release when only one-half of it > affects RH 7.3 (for which there is no apache 2.0). > Hi Jim, perhaps some of your confusion comes from the fact that rh9, fc1, and fc2 all contain the mod_ssl package as part of the httpd package. In the older rh 7.3, mod_ssl was separate from apache. > > To excuse this as "Other's checked before asking" is not accurate > as the data just isn't there to support even having the ability to > check. Show me discussions of this bug outside of a bugID that > isn't referenced anywhere else. And please don't suggest that I am > to be trolling bugzilla every day for the hundreds of packages for > which I may or may not be interested in knowing if a bug exists. > > The bottom line is that I regularly keep on top of RH73 bugs/ > updates/patches and I missed this. OK, so I am human and subject > to errors, but this bug stayed well below the FL radar for many > months. I have a pretty good record of downloading and testing > updates, so the fact that this critical one slipped by alarms me. > OK, sounds like you're just upset because you didn't see this until the updates-testing notification. I'm not sure I understand what you're trying to say here. Anyway, sorry for the confusion. -Jeff From rostetter at mail.utexas.edu Tue Oct 25 01:40:55 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 24 Oct 2005 20:40:55 -0500 Subject: Upcoming transition of FC3 In-Reply-To: <86B9B76E-7A98-4510-A22A-BBAA24B782E7@cs.ucsb.edu> References: <1129850211.2929.177.camel@prometheus.gamehouse.com> <064592A2-752E-4A75-B749-8CD2C6CBFF9C@cs.ucsb.edu> <1129912399.2929.181.camel@prometheus.gamehouse.com> <4C57C25F-49A6-4CB2-AD8A-92212EF1858F@cs.ucsb.edu> <1129996759.28454.57.camel@yoda.loki.me> <11589B23-D126-4D94-997D-A39297D50E12@lemonbit.nl> <1129998148.28454.59.camel@yoda.loki.me> <1130171201.bdc469ae6e065@mail.ph.utexas.edu> <20051024171254.GB19763@mail.harddata.com> <1130179305.c8bfcfb25af3e@mail.ph.utexas.edu> <4DF92DE7-7D9E-4340-A5E4-0DF19B8F2540@cs.ucsb.edu> <1130186316.253b3a830a4d1@mail.ph.utexas.edu> <1130187366.2929.268.camel@prometheus.gamehouse.com> <1130188252.cf3ffa3b25e0a@mail.ph.utexas.edu> <86B9B76E-7A98-4510-A22A-BBAA24B782E7@cs.ucsb.edu> Message-ID: <1130204455.7a7f907909613@mail.ph.utexas.edu> Quoting Jeff Sheltren : > Hi Eric, it will be different depending on if you are talking about > fedora core < 5 or FC5 and newer. For those like FC3, and FC4, we > will provide our own package; for now I've named it legacy-yumconf. > Those packages will not be incorporated into Fedora Core, they will > need to be installed by the user of their own free will. I think > that everyone is in agreement that for these packages the legacy base > and updates repos should be enabled by default. I don't think everyone is in agreement that they should, but I think most people will allow them to be enabled by default, whether or not they think it is best or not. > For FC5 and newer, the plan is to have a legacy.repo file included by > default. I assume this would be included in the fedora-release RPM, > which is what provides the other yum repo files, but that is up to > the Fedora Steering Committee. I guess we can, and should, leave that up to the Fedora Steering Committee then. Basically you're saying it is their software, and hence they get to make the rules. > -Jeff -- Eric Rostetter From jimpop at yahoo.com Tue Oct 25 03:29:51 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Mon, 24 Oct 2005 23:29:51 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> Message-ID: <435DA6AF.6010103@yahoo.com> Jeff Sheltren wrote: > > Hi Jim, perhaps some of your confusion comes from the fact that rh9, > fc1, and fc2 all contain the mod_ssl package as part of the httpd > package. In the older rh 7.3, mod_ssl was separate from apache. According to the release notes, 2 binary rpm packages were released (both mod_ssl and httpd) for all FL platforms except rh73. >> To excuse this as "Other's checked before asking" is not accurate as >> the data just isn't there to support even having the ability to >> check. Show me discussions of this bug outside of a bugID that isn't >> referenced anywhere else. And please don't suggest that I am to be >> trolling bugzilla every day for the hundreds of packages for which I >> may or may not be interested in knowing if a bug exists. >> >> The bottom line is that I regularly keep on top of RH73 >> bugs/updates/patches and I missed this. OK, so I am human and subject >> to errors, but this bug stayed well below the FL radar for many >> months. I have a pretty good record of downloading and testing >> updates, so the fact that this critical one slipped by alarms me. >> > > OK, sounds like you're just upset because you didn't see this until the > updates-testing notification. I'm not sure I understand what you're > trying to say here. What I am trying to say is this: I try very hard to contribute what I can to Fedora Legacy. Yet despite my best efforts I find it amazingly difficult to do anything other than simply testing released packages. I try to stay on top of server related issues pertaining to RH7.3, things exactly like mod_ssl and htttpd. Yet this particular issue stayed buried out of sight (again, someone please show me some recent discussion or non-hidden notes regarding this). Rather than continuing to poke this fire, I am going to (once again) ask all those involved to help make the process saner and clearer so that those that want to help will be able to help. Don't hide below the radar and then complain in other threads that people aren't contributing. 'nuf said. -Jim P. From pekkas at netcore.fi Tue Oct 25 05:48:56 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 25 Oct 2005 08:48:56 +0300 (EEST) Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435D746F.6040802@yahoo.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> Message-ID: On Mon, 24 Oct 2005, Jim Popovitch wrote: > I doubt this is a problem w/ Pekka's list as he has been very exacting up > until now. With this bug(s) I see the explanation above (separate bug > report, etc), but I don't see any reference to 168420 and 166941 in any of > the issues lists. (Yeah, I update the buglists typically once or twice a day..) The problem here is that if you use (and I recall you do): http://www.netcore.fi/pekkas/buglist-rhl73.html , the package doesn't show there, because a VERIFY has already been given for the package on that version (so it doesn't anymore have 'publish-rhl73' tag which the code is looking after). However, it is listed in: http://www.netcore.fi/pekkas/buglist.html Yes, it would probably be useful to list the package under RHL73 buglist as well, but getting that right would likely be difficult to accomplish. Instead, I'd suggest folks who prefer to use a more specific buglist take a look at the "full" buglist now and then. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From sheltren at cs.ucsb.edu Tue Oct 25 10:47:10 2005 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 25 Oct 2005 06:47:10 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435DA6AF.6010103@yahoo.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> <435DA6AF.6010103@yahoo.com> Message-ID: On Oct 24, 2005, at 11:29 PM, Jim Popovitch wrote: > Jeff Sheltren wrote: > >> >> Hi Jim, perhaps some of your confusion comes from the fact that >> rh9, fc1, and fc2 all contain the mod_ssl package as part of the >> httpd package. In the older rh 7.3, mod_ssl was separate from >> apache. >> > > According to the release notes, 2 binary rpm packages were released > (both mod_ssl and httpd) for all FL platforms except rh73. Yes, but for rh9 and up both mod_ssl and httpd are built from one SRPM - httpd. > > >>> To excuse this as "Other's checked before asking" is not accurate >>> as the data just isn't there to support even having the ability >>> to check. Show me discussions of this bug outside of a bugID >>> that isn't referenced anywhere else. And please don't suggest >>> that I am to be trolling bugzilla every day for the hundreds of >>> packages for which I may or may not be interested in knowing if a >>> bug exists. >>> >>> The bottom line is that I regularly keep on top of RH73 bugs/ >>> updates/patches and I missed this. OK, so I am human and subject >>> to errors, but this bug stayed well below the FL radar for many >>> months. I have a pretty good record of downloading and testing >>> updates, so the fact that this critical one slipped by alarms me. >>> >>> >> OK, sounds like you're just upset because you didn't see this >> until the updates-testing notification. I'm not sure I understand >> what you're trying to say here. >> > > What I am trying to say is this: > > I try very hard to contribute what I can to Fedora Legacy. Yet > despite my best efforts I find it amazingly difficult to do > anything other than simply testing released packages. I try to > stay on top of server related issues pertaining to RH7.3, things > exactly like mod_ssl and htttpd. Yet this particular issue stayed > buried out of sight (again, someone please show me some recent > discussion or non-hidden notes regarding this). > > Rather than continuing to poke this fire, I am going to (once > again) ask all those involved to help make the process saner and > clearer so that those that want to help will be able to help. > Don't hide below the radar and then complain in other threads that > people aren't contributing. > > 'nuf said. > OK, that's perfectly valid. And I'm very happy that you help out with testing packages - in fact, I think that package QA is where we need the most help. But I do disagree with you about this issue being "buried out of sight". All work on this bug was done using bugzilla where the ticket has been open for anyone to view (you don't even need to sign in). In fact, I count comments there from seven different people, which is more than most other FL bugs I've dealt with. So, to me this is not "hiding" at all. But I would be interested to hear if you have any ideas for implementing your suggestion of making things easier for people to help. -Jeff From jimpop at yahoo.com Tue Oct 25 13:49:53 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 25 Oct 2005 09:49:53 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> <435DA6AF.6010103@yahoo.com> Message-ID: <435E3801.3080108@yahoo.com> Jeff Sheltren wrote: > > So, to me this is not "hiding" at all. But I would be interested to > hear if you have any ideas for implementing your suggestion of making > things easier for people to help. Quite simply provide a one-stop spot with an up-to-date list of all bugs being tracked by FL broken up by system (FC1, FC2, 7.3, etc). Even Pekka appears to have had trouble determining this bug as it doesn't appear in his 7.3 list, which is what I what I look at. So for now the solution is for me to have to dig through all other system bugs just to locate 7.3 bugs, something that I don't think is too workable. -Jim P. From jimpop at yahoo.com Tue Oct 25 13:59:39 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Tue, 25 Oct 2005 09:59:39 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> Message-ID: <435E3A4B.8070207@yahoo.com> Pekka Savola wrote: > On Mon, 24 Oct 2005, Jim Popovitch wrote: >> I doubt this is a problem w/ Pekka's list as he has been very exacting >> up until now. With this bug(s) I see the explanation above (separate >> bug report, etc), but I don't see any reference to 168420 and 166941 >> in any of the issues lists. > > (Yeah, I update the buglists typically once or twice a day..) > > The problem here is that if you use (and I recall you do): > > http://www.netcore.fi/pekkas/buglist-rhl73.html > > , the package doesn't show there, because a VERIFY has already been > given for the package on that version (so it doesn't anymore have > 'publish-rhl73' tag which the code is looking after). > > However, it is listed in: > http://www.netcore.fi/pekkas/buglist.html Yes it is, it is listed like this: "httpd 2.0 multiple vulnerabilities - CAN-2005-2700, CAN-2005-2728" I know that my rh73 systems don't have httpd 2.0, so I would automatically ignore that. I guess the problem is bigger than just not being able to locate the bugs, the problem is also correctly identifying the bugs. Pekka I know that you don't produce the Summaries, so please don't think that I am singling you (or for that matter any one person) out for criticism. 166941 started out as a bug for many somethings, all of them totally unrelated to rh73. Even the Summary suggests it has nothing to do with rh73. -Jim P. From jkeating at j2solutions.net Tue Oct 25 15:06:40 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 25 Oct 2005 08:06:40 -0700 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <435E3A4B.8070207@yahoo.com> References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> <435E3A4B.8070207@yahoo.com> Message-ID: <1130252800.28454.76.camel@yoda.loki.me> On Tue, 2005-10-25 at 09:59 -0400, Jim Popovitch wrote: > 166941 started out as a bug for many somethings, all of them totally > unrelated to rh73. Even the Summary suggests it has nothing to do with > rh73. > Unfortunately thats going to happen. A bug will be filed regarding one aspect of a flaw, but under investigation it will appear that there are many things affected by the flaw and thus must be fixed. In the effort of simplicity, these are all tracked by the top level bug. I can ask that if other packages are going to be involved, either edit the first bug title, or file a secondary bug referencing the package, then close it pointing to the first bug. That way the bug can be found by searches and it will lead you to the master bug. This stuff isn't easy, and there are bound to be an odd package or 2 like this that crop up. Sorry. -- 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 From rostetter at mail.utexas.edu Tue Oct 25 15:24:49 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 25 Oct 2005 10:24:49 -0500 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: References: <435AD053.40800@videotron.ca> <435D5F7B.6060702@yahoo.com> <20051024231436.GA27315@mail.harddata.com> <435D746F.6040802@yahoo.com> <435DA6AF.6010103@yahoo.com> Message-ID: <1130253889.55478e9e8759a@mail.ph.utexas.edu> Quoting Jeff Sheltren : > So, to me this is not "hiding" at all. But I would be interested to > hear if you have any ideas for implementing your suggestion of making > things easier for people to help. > > -Jeff I updated http://www.fedoralegacy.org/participate/ to remove Hargreaves' Bugs List and added Pekka's List instead. Hopefully that will be helpful (I know it will be to me). -- Eric Rostetter From gene.heskett at verizon.net Tue Oct 25 15:44:01 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 25 Oct 2005 11:44:01 -0400 Subject: Fedora Legacy Test Update Notification: httpd and mod_ssl In-Reply-To: <1130252800.28454.76.camel@yoda.loki.me> References: <435AD053.40800@videotron.ca> <435E3A4B.8070207@yahoo.com> <1130252800.28454.76.camel@yoda.loki.me> Message-ID: <200510251144.01763.gene.heskett@verizon.net> On Tuesday 25 October 2005 11:06, Jesse Keating wrote: >On Tue, 2005-10-25 at 09:59 -0400, Jim Popovitch wrote: >> 166941 started out as a bug for many somethings, all of them totally >> unrelated to rh73. Even the Summary suggests it has nothing to do >> with rh73. > >Unfortunately thats going to happen. A bug will be filed regarding one >aspect of a flaw, but under investigation it will appear that there are >many things affected by the flaw and thus must be fixed. In the effort >of simplicity, these are all tracked by the top level bug. I can ask >that if other packages are going to be involved, either edit the first >bug title, or file a secondary bug referencing the package, then close >it pointing to the first bug. That way the bug can be found by searches >and it will lead you to the master bug. > >This stuff isn't easy, and there are bound to be an odd package or 2 >like this that crop up. Sorry. In attempting to update the mod_ssl package on my firewall/gateway, I note that yum doesn't recognize the check-updates command, and when I told it to update mod_ssl, it didn't spit out the name of the file, just asked if this was ok. Do I need a newer yum and or yum.conf on that rh7.3 box? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From gene.heskett at verizon.net Tue Oct 25 16:40:41 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 25 Oct 2005 12:40:41 -0400 Subject: Lastest openoffice vs kde menus Message-ID: <200510251240.42142.gene.heskett@verizon.net> Greetings; I recently installed OpenOffice2.0 final, and had previously installed 1.1.5. I had also gone thru my /root/.kde tree cleaning out old references to 1.14, 1.1.2 and the beta rc's. This got rid of some of the old broken links from the kde 'start' menu, but nothing I can find will redo these links and make the new stuff available from the pop-up menu on the toolbars left end. All of the old links to openoffice modules that do show just time out when selected. Obviously I'm missing the point here somehow, so can someone enlighten me as to howto 'edit' this stuff? The control center doesn't seem to make that option available. KDE is 3.3.0 from a konstruct build installed in /root/kde/bin etc, box is a somewhat hacked FC2, with lots of stuff replaced by home building tarballs when the rpms didn't fix long standing problems. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From gerry at pathtech.org Tue Oct 25 16:54:17 2005 From: gerry at pathtech.org (G. Roderick Singleton) Date: Tue, 25 Oct 2005 12:54:17 -0400 Subject: Lastest openoffice vs kde menus In-Reply-To: <200510251240.42142.gene.heskett@verizon.net> References: <200510251240.42142.gene.heskett@verizon.net> Message-ID: <1130259257.3567.387.camel@www.pathtech.org> On Tue, 2005-10-25 at 12:40 -0400, Gene Heskett wrote: > Greetings; > > I recently installed OpenOffice2.0 final, and had previously installed > 1.1.5. I had also gone thru my /root/.kde tree cleaning out old > references to 1.14, 1.1.2 and the beta rc's. This got rid of some of the > old broken links from the kde 'start' menu, but nothing I can find will > redo these links and make the new stuff available from the pop-up menu on > the toolbars left end. All of the old links to openoffice modules that do > show just time out when selected. > > Obviously I'm missing the point here somehow, so can someone enlighten me > as to howto 'edit' this stuff? The control center doesn't seem to make > that option available. > > KDE is 3.3.0 from a konstruct build installed in /root/kde/bin etc, box is > a somewhat hacked FC2, with lots of stuff replaced by home building > tarballs when the rpms didn't fix long standing problems. > Don't have an answer for you, Gene. But I think that there may be a bunch of people on users at openoffice.org that can help. I have added this list so have a look there as well, please. -- G. Roderick Singleton PATH tech From gene.heskett at verizon.net Tue Oct 25 17:11:35 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Tue, 25 Oct 2005 13:11:35 -0400 Subject: Lastest openoffice vs kde menus In-Reply-To: <1130259257.3567.387.camel@www.pathtech.org> References: <200510251240.42142.gene.heskett@verizon.net> <1130259257.3567.387.camel@www.pathtech.org> Message-ID: <200510251311.35281.gene.heskett@verizon.net> On Tuesday 25 October 2005 12:54, G. Roderick Singleton wrote: >On Tue, 2005-10-25 at 12:40 -0400, Gene Heskett wrote: >> Greetings; >> >> I recently installed OpenOffice2.0 final, and had previously installed >> 1.1.5. I had also gone thru my /root/.kde tree cleaning out old >> references to 1.14, 1.1.2 and the beta rc's. This got rid of some of >> the old broken links from the kde 'start' menu, but nothing I can find >> will redo these links and make the new stuff available from the pop-up >> menu on the toolbars left end. All of the old links to openoffice >> modules that do show just time out when selected. >> >> Obviously I'm missing the point here somehow, so can someone enlighten >> me as to howto 'edit' this stuff? The control center doesn't seem to >> make that option available. >> >> KDE is 3.3.0 from a konstruct build installed in /root/kde/bin etc, >> box is a somewhat hacked FC2, with lots of stuff replaced by home >> building tarballs when the rpms didn't fix long standing problems. > >Don't have an answer for you, Gene. But I think that there may be a >bunch of people on users at openoffice.org that can help. I have added this >list so have a look there as well, please. I'm already subbed there, thanks. But since it looked like a kde problem to me, and kde hasn't been super helpfull in the past, I thought I'd ask here. Gotta keep an oar in the water you know. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From marcdeslauriers at videotron.ca Wed Oct 26 00:40:56 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 25 Oct 2005 20:40:56 -0400 Subject: Fedora Legacy Test Update Notification: bzip2 Message-ID: <435ED098.2010803@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-158801 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158801 2005-10-25 --------------------------------------------------------------------- Name : bzip2 Versions : rh73: bzip2-1.0.2-2.2.73.legacy Versions : rh9: bzip2-1.0.2-8.1.90.legacy Versions : fc1: bzip2-1.0.2-10.1.fc1.legacy Versions : fc2: bzip2-1.0.2-12.2.fc2.legacy Summary : A file compression utility. Description : Bzip2 is a freely available, patent-free, high-quality data compressor that uses the same command line flags as gzip. --------------------------------------------------------------------- Update Information: Updated bzip2 packages that fix multiple issues are now available. Bzip2 is a data compressor. A bug was found in the way bzgrep processes file names. If a user can be tricked into running bzgrep on a file with a carefully crafted file name, arbitrary commands could be executed as the user running bzgrep. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0758 to this issue. A bug was found in the way bzip2 modifies file permissions during decompression. If an attacker has write access to the directory into which bzip2 is decompressing files, it is possible for them to modify permissions on files owned by the user running bzip2 (CAN-2005-0953). A bug was found in the way bzip2 decompresses files. It is possible for an attacker to create a specially crafted bzip2 file which will cause bzip2 to cause a denial of service (by filling disk space) if decompressed by a victim (CAN-2005-1260). Users of Bzip2 should upgrade to these updated packages, which contain backported patches to correct these issues. --------------------------------------------------------------------- Changelogs rh73: * Tue Sep 06 2005 David Eisenstein 1.0.2-2.2.73.legacy - changed the bzgrep patch to match RHEL 3's. (per bug 158801#c6) - added tempfile patch so bzdiff/bzcmp creates tempfiles more securely (from RHEL 3). Also added 2/24 & 3/30/05 changelog items. - added CVE and bugzilla bug numbers to next 4 changelog items. - renumbered release from "13.1.73.legacy" to "2.2.73.legacy" in keeping with FL package versioning scheme. * Thu Jun 16 2005 Michal Jaegermann - resynchronized for rhl7.3 with bzip2-1.0.2-13.FC3.1.src.rpm, #158801 rh9: * Tue Sep 06 2005 David Eisenstein 1.0.2-8.1.90.legacy - Recompiled for Red Hat 9.0. #158801. fc1: * Sat Sep 03 2005 David Eisenstein 1.0.2-10.1.fc1.legacy - Recompiled for Fedora Core 1. #158801. fc2: * Tue Sep 06 2005 David Eisenstein 1.0.2-12.2.fc2.legacy - Recompiled for Fedora Core 2. #158801. --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 2d0d5267210ceefd6e2ed80187c2f6e3d994e4a0 redhat/7.3/updates-testing/i386/bzip2-1.0.2-2.2.73.legacy.i386.rpm e661f6bf518498c375918577fc3414978a190d78 redhat/7.3/updates-testing/i386/bzip2-devel-1.0.2-2.2.73.legacy.i386.rpm 0c1bd4a4472ca70183b104438db1a9ef98db4969 redhat/7.3/updates-testing/i386/bzip2-libs-1.0.2-2.2.73.legacy.i386.rpm f146cb7edfa74345c42831f24cb95c7898db3064 redhat/7.3/updates-testing/SRPMS/bzip2-1.0.2-2.2.73.legacy.src.rpm rh9: 36b3b8abb700fe93d14064ce22176ed59aef0b9b redhat/9/updates-testing/i386/bzip2-1.0.2-8.1.90.legacy.i386.rpm 3ce61caa59d4c9a90e2412ebd5bae76500e4e462 redhat/9/updates-testing/i386/bzip2-devel-1.0.2-8.1.90.legacy.i386.rpm 905c29052192f032dac84be0860013837b65f8d4 redhat/9/updates-testing/i386/bzip2-libs-1.0.2-8.1.90.legacy.i386.rpm bdbf201ea36551c1f5eacff3707656fd5e099c75 redhat/9/updates-testing/SRPMS/bzip2-1.0.2-8.1.90.legacy.src.rpm fc1: 56b7883ada43718a80577ddcbdbc8bc24072765d fedora/1/updates-testing/i386/bzip2-1.0.2-10.1.fc1.legacy.i386.rpm 472cee03d32c68e0a0feba56a265c42d208ea5d4 fedora/1/updates-testing/i386/bzip2-devel-1.0.2-10.1.fc1.legacy.i386.rpm 94abc962a1b84373813c558d4d3d44993722bb16 fedora/1/updates-testing/i386/bzip2-libs-1.0.2-10.1.fc1.legacy.i386.rpm 7ce97f2488338b9d0e4b136b63c04e80c7a27394 fedora/1/updates-testing/SRPMS/bzip2-1.0.2-10.1.fc1.legacy.src.rpm fc2: c2821d2326bdff302a8b38ab6baec2930da4ca6b fedora/2/updates-testing/i386/bzip2-1.0.2-12.2.fc2.legacy.i386.rpm d1ba1f61d62970f0d97af8813956771b471fbc81 fedora/2/updates-testing/i386/bzip2-devel-1.0.2-12.2.fc2.legacy.i386.rpm c8cf989f3683f4313d4a0caf7695673f48e405e7 fedora/2/updates-testing/i386/bzip2-libs-1.0.2-12.2.fc2.legacy.i386.rpm 1ac418e19c22613a3cc4d71ee304a9d304af50e6 fedora/2/updates-testing/SRPMS/bzip2-1.0.2-12.2.fc2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From marcdeslauriers at videotron.ca Wed Oct 26 00:41:28 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 25 Oct 2005 20:41:28 -0400 Subject: Fedora Legacy Test Update Notification: redhat-config-nfs Message-ID: <435ED0B8.7080103@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-152787 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152787 2005-10-25 --------------------------------------------------------------------- Name : redhat-config-nfs Versions : rh9: redhat-config-nfs-1.0.13-6.legacy Versions : fc1: redhat-config-nfs-1.1.3-3.legacy Versions : fc2: system-config-nfs-1.2.3-5.legacy Summary : NFS server configuration tool Description : redhat-config-nfs is a graphical user interface for creating, modifying, and deleting nfs shares. --------------------------------------------------------------------- Update Information: An updated redhat-config-nfs package that fixes a security issue is now available. redhat-config-nfs is a graphical user interface for creating, modifying, and deleting nfs shares. John Buswell discovered a flaw in redhat-config-nfs that could lead to incorrect permissions on exported shares when exporting to multiple hosts. This could cause an option such as "all_squash" to not be applied to all of the listed hosts. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0750 to this issue. Additionally, a bug was found that prevented redhat-config-nfs from being run if hosts didn't have options set in /etc/exports. All users of redhat-config-nfs should upgrade to this updated package, which includes a patch to correct these issues. --------------------------------------------------------------------- Changelogs rh9: * Wed Jul 27 2005 Pekka Savola 1.0.13-6.legacy - Patch from John Dalbec to completely fix CAN-2004-0750 (#152787) * Thu Sep 23 2004 Marc Deslauriers 1.0.13-5.legacy - rebuilt as Fedora Legacy security update to fix CAN-2004-0750 - revert desktop file to rh9 format fc1: * Wed Jul 27 2005 Pekka Savola 1.1.3-3.legacy - Patch from John Dalbec to completely fix CAN-2004-0750 (#152787) * Thu Sep 23 2004 Marc Deslauriers 1.1.3-2.legacy - close properties dialog when clicking OK button - handle /etc/exports missing gracefully - fix incorrect syntax for multiple hosts with a single mount point CAN-2004-0750 (patch by Shannon Mitchell) - don't barf on optionless hosts - readonly is default fc2: * Sun Oct 02 2005 David Eisenstein 1.2.3-5.legacy - update the missingexports patch * Sat Oct 01 2005 Pekka Savola 1.2.3-4.legacy - Add patches made to other FC legacy OS versios: - close properties dialog when clicking OK button - handle /etc/exports missing gracefully - fix incorrect syntax for multiple hosts with a single mount point CAN-2004-0750 (patch by Shannon Mitchell) - don't barf on optionless hosts - readonly is default * Wed Jul 27 2005 Pekka Savola 1.2.3-2.legacy - Patch from John Dalbec to completely fix CAN-2004-0750 (#152787) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh9: 6d0c5c269b0702a5f7ef352e1c01390dfcedf66e redhat/9/updates-testing/i386/redhat-config-nfs-1.0.13-6.legacy.noarch.rpm 7dfd3e3cd3e937144b0a79b38967749caea1f779 redhat/9/updates-testing/SRPMS/redhat-config-nfs-1.0.13-6.legacy.src.rpm fc1: 376cd7a13d85877976d606a2a8dc57e5a9de1766 fedora/1/updates-testing/i386/redhat-config-nfs-1.1.3-3.legacy.noarch.rpm b1828331941b0d64625dc5981990b63fb8f5ee26 fedora/1/updates-testing/SRPMS/redhat-config-nfs-1.1.3-3.legacy.src.rpm fc2: e9694cfe870c4370ab080ef81fe2ee5d09f23a34 fedora/2/updates-testing/i386/system-config-nfs-1.2.3-5.legacy.noarch.rpm 6e4cee9467fa66760b8e757000e771f167225377 fedora/2/updates-testing/SRPMS/system-config-nfs-1.2.3-5.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lists at benjamindsmith.com Wed Oct 26 03:01:31 2005 From: lists at benjamindsmith.com (Benjamin Smith) Date: Tue, 25 Oct 2005 20:01:31 -0700 Subject: Fedora Updates testing Message-ID: <200510252001.31212.lists@benjamindsmith.com> How many updates from FL have been rejected due to bugs or things "not working"? I updated my FC1 yum.conf to include "testing", and I've not noticed anything unusual. (Wish I had the time to figure out how to test, let alone do the testing...) -Ben -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 From jkeating at j2solutions.net Wed Oct 26 04:46:58 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 25 Oct 2005 21:46:58 -0700 Subject: Fedora Updates testing In-Reply-To: <200510252001.31212.lists@benjamindsmith.com> References: <200510252001.31212.lists@benjamindsmith.com> Message-ID: <1130302018.28809.66.camel@prometheus.gamehouse.com> On Tue, 2005-10-25 at 20:01 -0700, Benjamin Smith wrote: > > How many updates from FL have been rejected due to bugs or things "not > working"? I updated my FC1 yum.conf to include "testing", and I've not > noticed anything unusual. There have been a few called back, due to missing deps in the build system or a few other things. -- 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 From gene.heskett at verizon.net Wed Oct 26 04:37:05 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Oct 2005 00:37:05 -0400 Subject: dependency hell, version 2,197,386.1 Message-ID: <200510260037.05509.gene.heskett@verizon.net> Greetings; How can I go about convincing yum to update the iptables install on my old firewall box when it reports this: [root at gene etc]# yum update iptables package iptables needs kernel that has been excluded package iptables needs kernel that has been excluded The kernel is in fact a 2.4.29, obviously new enough but locally built. Is this a case where the --nodeps --force options to rpm can be used? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From stuart at serverpeak.com Wed Oct 26 05:56:41 2005 From: stuart at serverpeak.com (Stuart Low) Date: Wed, 26 Oct 2005 15:56:41 +1000 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <200510260037.05509.gene.heskett@verizon.net> References: <200510260037.05509.gene.heskett@verizon.net> Message-ID: <1130306201.14878.36.camel@laptop.seekbrain.com> Hey, > How can I go about convincing yum to update the iptables install on my > old firewall box when it reports this: > [root at gene etc]# yum update iptables > package iptables needs kernel that has been excluded > package iptables needs kernel that has been excluded > The kernel is in fact a 2.4.29, obviously new enough but locally built. > Is this a case where the --nodeps --force options to rpm can be used? Probably not the smartest move. Be best to manually download the latest kernel rpm and rpm -ivh it. Then modify your lilo/grub config back to booting your custom kernel by default. That way you've avoided the dep issue but haven't lost your custom kernel. Stuart From skvidal at phy.duke.edu Wed Oct 26 12:47:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 26 Oct 2005 08:47:05 -0400 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <1130306201.14878.36.camel@laptop.seekbrain.com> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> Message-ID: <1130330826.30091.9.camel@cutter> On Wed, 2005-10-26 at 15:56 +1000, Stuart Low wrote: > Hey, > > > How can I go about convincing yum to update the iptables install on my > > old firewall box when it reports this: > > [root at gene etc]# yum update iptables > > package iptables needs kernel that has been excluded > > package iptables needs kernel that has been excluded > > The kernel is in fact a 2.4.29, obviously new enough but locally built. > > Is this a case where the --nodeps --force options to rpm can be used? > > Probably not the smartest move. Be best to manually download the latest > kernel rpm and rpm -ivh it. Then modify your lilo/grub config back to > booting your custom kernel by default. > > That way you've avoided the dep issue but haven't lost your custom > kernel. > when yum updates kernels it does not remove the older kernels. So there's no danger in yum installing the kernel for you. -sv From gene.heskett at verizon.net Wed Oct 26 13:54:40 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Oct 2005 09:54:40 -0400 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <1130306201.14878.36.camel@laptop.seekbrain.com> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> Message-ID: <200510260954.40228.gene.heskett@verizon.net> On Wednesday 26 October 2005 01:56, Stuart Low wrote: >Hey, > >> How can I go about convincing yum to update the iptables install on my >> old firewall box when it reports this: >> [root at gene etc]# yum update iptables >> package iptables needs kernel that has been excluded >> package iptables needs kernel that has been excluded >> The kernel is in fact a 2.4.29, obviously new enough but locally >> built. Is this a case where the --nodeps --force options to rpm can be >> used? > >Probably not the smartest move. Be best to manually download the latest >kernel rpm and rpm -ivh it. Then modify your lilo/grub config back to >booting your custom kernel by default. > >That way you've avoided the dep issue but haven't lost your custom >kernel. Humm, thats an AMD k6-III in that box, so I grabbed the 586 kernel, is this correct? >Stuart > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From rostetter at mail.utexas.edu Wed Oct 26 15:12:33 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 26 Oct 2005 10:12:33 -0500 Subject: Fedora Updates testing In-Reply-To: <200510252001.31212.lists@benjamindsmith.com> References: <200510252001.31212.lists@benjamindsmith.com> Message-ID: <1130339553.bc18ea59c830e@mail.ph.utexas.edu> Quoting Benjamin Smith : > How many updates from FL have been rejected due to bugs or things "not > working"? I updated my FC1 yum.conf to include "testing", and I've not > noticed anything unusual. > > (Wish I had the time to figure out how to test, let alone do the testing...) I don't know any numbers. But I can tell you if you are using the "testing" channel than you *are* testing, so you don't need to figure out how to test things, only how to report your test findings. Your needed steps now are: * Determine which test packages you have installed. * If needed, learn how to use gpg to make a clear signed message. * For each test package, create a message saying you tested it and found no problems. Then gpg clearsign that message, and copy/paste the result into the bugzilla entry for that bug. For information on determining which packages you have tested, ask this mailing list for help. For gpg help, see http://www.fedoraproject.org/wiki/Legacy/PGPHowTo For bugzilla help, see http://www.fedoralegacy.org/docs/bugzilla.php For any other questions about helping, ask this mailing list. For information on finding more time in your day, seek a spiritual guide or time management expert ;) > -Ben -- Eric Rostetter From A.Fadyushin at it-centre.ru Wed Oct 26 15:22:53 2005 From: A.Fadyushin at it-centre.ru (A.Fadyushin at it-centre.ru) Date: Wed, 26 Oct 2005 19:22:53 +0400 Subject: dependency hell, version 2,197,386.1 Message-ID: The new iptables may be incompatible with the kernels which are older than the kernel required by iptables package. Therefore, if the iptables package requires the kernel version which is newer than the version of your custom kernel, you should download the kernel (most probably, in source form) which is required by the iptables. Then you should customize and rebuild it similar to your older kernel and install as a new kernel. If the required kernel and the kernel customized by you have the same version (the only difference is your customization) than you can use rpm options which prevent dependency checking when installing iptables. Alexey Fadyushin Brainbench MVP for Linux http://www.brainbench.com > -----Original Message----- > From: fedora-legacy-list-bounces at redhat.com [mailto:fedora-legacy-list- > bounces at redhat.com] On Behalf Of Stuart Low > Sent: Wednesday, October 26, 2005 9:57 AM > To: Discussion of the Fedora Legacy Project > Subject: Re: dependency hell, version 2,197,386.1 > > Hey, > > > How can I go about convincing yum to update the iptables install on my > > old firewall box when it reports this: > > [root at gene etc]# yum update iptables > > package iptables needs kernel that has been excluded > > package iptables needs kernel that has been excluded > > The kernel is in fact a 2.4.29, obviously new enough but locally built. > > Is this a case where the --nodeps --force options to rpm can be used? > > Probably not the smartest move. Be best to manually download the latest > kernel rpm and rpm -ivh it. Then modify your lilo/grub config back to > booting your custom kernel by default. > > That way you've avoided the dep issue but haven't lost your custom > kernel. > > Stuart > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legacy-list From gene.heskett at verizon.net Wed Oct 26 14:30:10 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Oct 2005 10:30:10 -0400 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <1130330826.30091.9.camel@cutter> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> <1130330826.30091.9.camel@cutter> Message-ID: <200510261030.10757.gene.heskett@verizon.net> On Wednesday 26 October 2005 08:47, seth vidal wrote: >On Wed, 2005-10-26 at 15:56 +1000, Stuart Low wrote: >> Hey, >> >> > How can I go about convincing yum to update the iptables install on >> > my old firewall box when it reports this: >> > [root at gene etc]# yum update iptables >> > package iptables needs kernel that has been excluded >> > package iptables needs kernel that has been excluded >> > The kernel is in fact a 2.4.29, obviously new enough but locally >> > built. Is this a case where the --nodeps --force options to rpm can >> > be used? >> >> Probably not the smartest move. Be best to manually download the >> latest kernel rpm and rpm -ivh it. Then modify your lilo/grub config >> back to booting your custom kernel by default. >> >> That way you've avoided the dep issue but haven't lost your custom >> kernel. > >when yum updates kernels it does not remove the older kernels. So >there's no danger in yum installing the kernel for you. > >-sv In addition to the previous concern, I thought I'd do that same end run on this box, which is normally running the latest mainline, like 2.6.14-rc5 ATM. But when rpm was installing the modules, it got a tummy ache as follows: Preparing... ########################################### [100%] 1:kernel ########################################### [100%] [long delay here] Failed to mmap /lib/modules/2.6.10-1.771_FC2/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.13.1/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.13.1.old/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.13-rc4-RT-V0.7.52-16/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc1/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc2/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc3/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc3-kj1/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc4/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc4.old/build/./include/config/MARKER Failed to mmap /lib/modules/2.6.14-rc5/build/./include/config/MARKER Failed to mmap ./include/config/MARKER [root at coyote FC2]# ----------- So what is that all about? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From rdieter at math.unl.edu Wed Oct 26 15:30:04 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Oct 2005 10:30:04 -0500 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <200510260954.40228.gene.heskett@verizon.net> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> <200510260954.40228.gene.heskett@verizon.net> Message-ID: Gene Heskett wrote: > Humm, thats an AMD k6-III in that box, so I grabbed the 586 kernel, is > this correct? Yes. -- Rex From gene.heskett at verizon.net Wed Oct 26 14:01:08 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Oct 2005 10:01:08 -0400 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <1130330826.30091.9.camel@cutter> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> <1130330826.30091.9.camel@cutter> Message-ID: <200510261001.08077.gene.heskett@verizon.net> On Wednesday 26 October 2005 08:47, seth vidal wrote: >On Wed, 2005-10-26 at 15:56 +1000, Stuart Low wrote: >> Hey, >> >> > How can I go about convincing yum to update the iptables install on >> > my old firewall box when it reports this: >> > [root at gene etc]# yum update iptables >> > package iptables needs kernel that has been excluded >> > package iptables needs kernel that has been excluded >> > The kernel is in fact a 2.4.29, obviously new enough but locally >> > built. Is this a case where the --nodeps --force options to rpm can >> > be used? >> >> Probably not the smartest move. Be best to manually download the >> latest kernel rpm and rpm -ivh it. Then modify your lilo/grub config >> back to booting your custom kernel by default. >> >> That way you've avoided the dep issue but haven't lost your custom >> kernel. > >when yum updates kernels it does not remove the older kernels. So >there's no danger in yum installing the kernel for you. > >-sv Yes Seth, but it does tend to scrap the currently valid stuff in ones grub.conf, and I'd rather do my own editing of grub.conf. So I'll copy it, then restore it. One more step to have to recall or one gets bit. IMO, the automatic editing of grub.conf can do more damage than it can save newbies headaches. But thats a minor detail IF one doesn't forget to fix it before the next reboot. ?? does that boxes rpm have the --justdb option? That would be even simpler. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From michal at harddata.com Wed Oct 26 17:42:35 2005 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 26 Oct 2005 11:42:35 -0600 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <200510261001.08077.gene.heskett@verizon.net> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> <1130330826.30091.9.camel@cutter> <200510261001.08077.gene.heskett@verizon.net> Message-ID: <20051026174235.GA11474@mail.harddata.com> On Wed, Oct 26, 2005 at 10:01:08AM -0400, Gene Heskett wrote: > On Wednesday 26 October 2005 08:47, seth vidal wrote: > > > >when yum updates kernels it does not remove the older kernels. So > >there's no danger in yum installing the kernel for you. > > > >-sv > > Yes Seth, but it does tend to scrap the currently valid stuff in ones > grub.conf, For a very long time I did not see an installation procedure to mess with my "extra" boot entries; it adds just new ones. In any case there is a very simple way to "protect" yourself. Edit your /etc/grub.conf with "non-standard" titles. That should be enough to sufficiently confuse an automatic editing so it will leave all of that configuration alone. Of course then it is up to you to fix things up after every change in boot images. > and I'd rather do my own editing of grub.conf. Your choice; but if you prefer a "manual installation labor" then learn how to do it completely and resolve dependencies and override checks, where this makes sense, manually too. It is easier to mess up that way but it is doable. Still this leaves you without a valid complaint that some things are unhappy. I would think that a better way to achieve you goals would be to keep a copy of your current grub.conf, install, restore the previous version of grub.conf from that copy and edit results to your taste. Michal From jkeating at j2solutions.net Wed Oct 26 19:52:25 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 26 Oct 2005 12:52:25 -0700 Subject: Revisiting pruning of updates directories Message-ID: <1130356345.28809.84.camel@prometheus.gamehouse.com> I'd like to revisit the thought of pruning the updates rpms and srpms directories to save space. This would basically sync w/ the tree as it was at closure time, and then of course all the Legacy packages would be added in. Is there any of you that feel this _shouldn't_ be done? -- 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 From jimpop at yahoo.com Wed Oct 26 19:57:50 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 26 Oct 2005 15:57:50 -0400 Subject: Revisiting pruning of updates directories In-Reply-To: <1130356345.28809.84.camel@prometheus.gamehouse.com> References: <1130356345.28809.84.camel@prometheus.gamehouse.com> Message-ID: <435FDFBE.40908@yahoo.com> Jesse Keating wrote: > I'd like to revisit the thought of pruning the updates rpms and srpms > directories to save space. This would basically sync w/ the tree as it > was at closure time, and then of course all the Legacy packages would be > added in. > > Is there any of you that feel this _shouldn't_ be done? What exactly would be pruned? Saving space sounds like a great idea as long as it is useless stuff we are deleting. -Jim P. From jkeating at j2solutions.net Wed Oct 26 20:03:13 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 26 Oct 2005 13:03:13 -0700 Subject: Revisiting pruning of updates directories In-Reply-To: <435FDFBE.40908@yahoo.com> References: <1130356345.28809.84.camel@prometheus.gamehouse.com> <435FDFBE.40908@yahoo.com> Message-ID: <1130356993.28809.91.camel@prometheus.gamehouse.com> On Wed, 2005-10-26 at 15:57 -0400, Jim Popovitch wrote: > What exactly would be pruned? Saving space sounds like a great idea as > long as it is useless stuff we are deleting. Updates that have been obsoleted by newer updates (from Red Hat). Before Red Hat closes down a release they usually run a prune that deletes all/most the obsoleted updates. When I was syncing the FC trees (and possibly the RH trees) I may not have gotten the prune deletions. By doing a comparison against a public mirror for the FC content I count 149 packages alone in the FC1 i386 updates directory that could be removed. rsync -avn --delete --bwlimit=192 rsync://mirrors.kernel.org/fedora/core/updates/1/i386/ fedora/1/updates/i386/ --exclude repodata --exclude headers --exclude debug |grep -v legacy |grep deleting |awk '{print $2}' |wc -l -- 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 From jimpop at yahoo.com Wed Oct 26 20:21:49 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Wed, 26 Oct 2005 16:21:49 -0400 Subject: Revisiting pruning of updates directories In-Reply-To: <1130356993.28809.91.camel@prometheus.gamehouse.com> References: <1130356345.28809.84.camel@prometheus.gamehouse.com> <435FDFBE.40908@yahoo.com> <1130356993.28809.91.camel@prometheus.gamehouse.com> Message-ID: <435FE55D.7070109@yahoo.com> Jesse Keating wrote: > On Wed, 2005-10-26 at 15:57 -0400, Jim Popovitch wrote: >> What exactly would be pruned? Saving space sounds like a great idea as >> long as it is useless stuff we are deleting. > > Updates that have been obsoleted by newer updates (from Red Hat). > Before Red Hat closes down a release they usually run a prune that > deletes all/most the obsoleted updates. When I was syncing the FC trees > (and possibly the RH trees) I may not have gotten the prune deletions. > By doing a comparison against a public mirror for the FC content I count > 149 packages alone in the FC1 i386 updates directory that could be > removed. Ahh, makes perfect sense then. Thanks. -Jim P. From ianburrell at gmail.com Wed Oct 26 22:14:47 2005 From: ianburrell at gmail.com (Ian Burrell) Date: Wed, 26 Oct 2005 15:14:47 -0700 Subject: dependency hell, version 2,197,386.1 In-Reply-To: <20051026174235.GA11474@mail.harddata.com> References: <200510260037.05509.gene.heskett@verizon.net> <1130306201.14878.36.camel@laptop.seekbrain.com> <1130330826.30091.9.camel@cutter> <200510261001.08077.gene.heskett@verizon.net> <20051026174235.GA11474@mail.harddata.com> Message-ID: On 10/26/05, Michal Jaegermann wrote: > On Wed, Oct 26, 2005 at 10:01:08AM -0400, Gene Heskett wrote: > > > > Yes Seth, but it does tend to scrap the currently valid stuff in ones > > grub.conf, > > For a very long time I did not see an installation procedure to mess > with my "extra" boot entries; it adds just new ones. In any case > there is a very simple way to "protect" yourself. Edit your > /etc/grub.conf with "non-standard" titles. That should be enough to > sufficiently confuse an automatic editing so it will leave all of > that configuration alone. Of course then it is up to you to fix > things up after every change in boot images. > > > and I'd rather do my own editing of grub.conf. > > Your choice; but if you prefer a "manual installation labor" then > learn how to do it completely and resolve dependencies and override > checks, where this makes sense, manually too. It is easier to mess > up that way but it is doable. Still this leaves you without a valid > complaint that some things are unhappy. > > I would think that a better way to achieve you goals would be to > keep a copy of your current grub.conf, install, restore the previous > version of grub.conf from that copy and edit results to your taste. > He can configure the updater to not change the default grub entry. This is done by editing /etc/sysconfig/kernel and changing UPDATEDEFAULT to 'no'. This should keep rpm kernel installs from changing the default grub. I have not seen the grub updater mangle other lines. It is good about only adding and removing the Fedora kernel entries. If his custom entries don't look like Fedora kernels, then grubby won't touch them. It is a good idea to have at least one Fedora kernel installed and bootable. Both to keep rpm happy, and to allow a fallback if things go wrong with the custom kernel. - Ian From gene.heskett at verizon.net Wed Oct 26 23:22:41 2005 From: gene.heskett at verizon.net (Gene Heskett) Date: Wed, 26 Oct 2005 19:22:41 -0400 Subject: dependency hell, version 2,197,386.1 In-Reply-To: References: <200510260037.05509.gene.heskett@verizon.net> <200510260954.40228.gene.heskett@verizon.net> Message-ID: <200510261922.41421.gene.heskett@verizon.net> On Wednesday 26 October 2005 11:30, Rex Dieter wrote: >Gene Heskett wrote: >> Humm, thats an AMD k6-III in that box, so I grabbed the 586 kernel, is >> this correct? > >Yes. > Thanks Rex. I guiess I've been rolling my own for too long. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. From jimpop at yahoo.com Sun Oct 30 23:38:10 2005 From: jimpop at yahoo.com (Jim Popovitch) Date: Sun, 30 Oct 2005 18:38:10 -0500 Subject: glibc-common-2.2.5-44.legacy.6 update Message-ID: <43655962.7080902@yahoo.com> Is there a way for us to develop packages that don't require updating ALL the files in a package? For instance, in the latest glibc-common update only a few lines of source code changed. Yet on my test system I see a hundred files (mostly locale files) that are reported as being changed by tripwire, but probably didn't really require a change from the ones in the earlier package. Is this a nuisance that we could prevent if we only released packages that were built on a common build system? Just looking for more insight into keeping things consistent. ;-) -Jim P. From marcdeslauriers at videotron.ca Sun Oct 30 23:43:17 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Sun, 30 Oct 2005 18:43:17 -0500 Subject: Fedora Legacy Test Update Notification: openssl Message-ID: <43655A95.1090006@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Test Update Notification FEDORALEGACY-2005-166939 Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166939 2005-10-30 --------------------------------------------------------------------- Name : openssl Versions : rh73: openssl-0.9.6b-39.9.legacy Versions : rh9: openssl-0.9.7a-20.6.legacy Versions : fc1: openssl-0.9.7a-33.13.legacy Versions : fc2: openssl-0.9.7a-35.2.legacy Summary : The OpenSSL toolkit. Description : The OpenSSL toolkit provides support for secure communications between machines. OpenSSL includes a certificate management tool and shared libraries which provide various cryptographic algorithms and protocols. --------------------------------------------------------------------- Update Information: Updated OpenSSL packages that fix a security issue are now available. OpenSSL is a toolkit that implements Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full- strength general purpose cryptography library. A bug was fixed in the way OpenSSL creates DSA signatures. A cache timing attack was fixed in a previous advisory which caused OpenSSL to do private key calculations with a fixed time window. The DSA fix for this was not complete and the calculations are not always performed within a fixed-window. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0109 to this issue. Users are advised to update to these erratum packages which contain a patch to correct this issue. --------------------------------------------------------------------- Changelogs rh73: * Sat Oct 22 2005 Jeff Sheltren 0.9.6b-39.9.legacy - Add extra patch to fix CAN-2005-0109 - Patch to prevent version rollback, CAN-2005-2969 (#166939) * Mon Aug 29 2005 Jeff Sheltren 0.9.6b-39.8.legacy - patch for cache timing exploit CAN-2005-0109 (#166939) rh9: * Sat Oct 22 2005 Jeff Sheltren 0.9.7a-20.6.legacy - Add extra patch to fix CAN-2005-0109 - Patch to prevent version rollback, CAN-2005-2969 (#166939) * Mon Aug 29 2005 Jeff Sheltren 0.9.7a-20.5.legacy - patch for cache timing exploit CAN-2005-0109 (#166939) fc1: * Sat Oct 22 2005 Jeff Sheltren 0.9.7a-33.13.legacy - Add extra patch to fix CAN-2005-0109 - Patch to prevent version rollback, CAN-2005-2969 (#166939) * Mon Aug 29 2005 Jeff Sheltren 0.9.7a-33.12.legacy - patch for cache timing exploit CAN-2005-0109 (#166939) fc2: * Sat Oct 22 2005 Jeff Sheltren 0.9.7a-35-2.legacy - Add extra patch to fix CAN-2005-0109 - Patch to prevent version rollback, CAN-2005-2969 (#166939) * Sun Aug 28 2005 Jeff Sheltren 0.9.7a-35.1.legacy - Patches for CAN-2004-0975 and CAN-2005-0109 (#166939) --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/ (sha1sums) rh73: 23e31f9220e9c178633f92176a09b3cd22912203 redhat/7.3/updates-testing/i386/openssl095a-0.9.5a-24.7.5.legacy.i386.rpm e08cbfb5c6ee46014ee5d15282c68fe7f9331071 redhat/7.3/updates-testing/i386/openssl096-0.9.6-25.10.legacy.i386.rpm 8c3ddc292081189ad5f9e21e2c4b26615f38f990 redhat/7.3/updates-testing/i386/openssl-0.9.6b-39.9.legacy.i386.rpm 9ff66370fe9e198c0482542705e70f6e6d08eb92 redhat/7.3/updates-testing/i386/openssl-0.9.6b-39.9.legacy.i686.rpm e0e7414663d8303ca31cb2fa7f711e21e29b247f redhat/7.3/updates-testing/i386/openssl-devel-0.9.6b-39.9.legacy.i386.rpm e230cd7a295b5a0f7181ace648647b8131d34f55 redhat/7.3/updates-testing/i386/openssl-perl-0.9.6b-39.9.legacy.i386.rpm a947f06dd5bb790c081de9a66ab6115bc3f860bd redhat/7.3/updates-testing/SRPMS/openssl095a-0.9.5a-24.7.5.legacy.src.rpm ffed89fc023c04323469f9689650afa8c63ab752 redhat/7.3/updates-testing/SRPMS/openssl096-0.9.6-25.10.legacy.src.rpm 5f15191347ba49337593e3ec4a25b7961854b126 redhat/7.3/updates-testing/SRPMS/openssl-0.9.6b-39.9.legacy.src.rpm rh9: c94740ed01d1016dfedcbb250c8641fb8507b6f9 redhat/9/updates-testing/i386/openssl096-0.9.6-25.11.legacy.i386.rpm f1224dfb97ddb0eaa678d23cd097858d05c6939c redhat/9/updates-testing/i386/openssl096b-0.9.6b-15.2.legacy.i386.rpm 62eb39923eb2a98a1749a58a28fce5c425587387 redhat/9/updates-testing/i386/openssl-0.9.7a-20.6.legacy.i386.rpm e97a1fb8963711a2c97e298173d30fe64abd7a3f redhat/9/updates-testing/i386/openssl-0.9.7a-20.6.legacy.i686.rpm dca80e912b43137b71e966cdc956b50324fd59fc redhat/9/updates-testing/i386/openssl-devel-0.9.7a-20.6.legacy.i386.rpm 1f34a94f36d3b7fa56b633fc134eac3d99a08f45 redhat/9/updates-testing/i386/openssl-perl-0.9.7a-20.6.legacy.i386.rpm 7a33a1707d2e6dfd3db2d6d33e992007fe26b8a7 redhat/9/updates-testing/SRPMS/openssl096-0.9.6-25.11.legacy.src.rpm a04955b783d0eab8daca4435dcc5dd9cc181132c redhat/9/updates-testing/SRPMS/openssl096b-0.9.6b-15.2.legacy.src.rpm d010302930f88638255581d7f4d8d245fc5f1f4f redhat/9/updates-testing/SRPMS/openssl-0.9.7a-20.6.legacy.src.rpm fc1: b8bca99bd841735227e51ec9922aa7b9a86cf956 fedora/1/updates-testing/i386/openssl096-0.9.6-26.2.legacy.i386.rpm f6a6795be813551df73dd07b81fedb9c4b766e4e fedora/1/updates-testing/i386/openssl096b-0.9.6b-18.2.legacy.i386.rpm 620c574712782b4e349ed1392d1d674507a146cc fedora/1/updates-testing/i386/openssl-0.9.7a-33.13.legacy.i386.rpm 5518b5e24176b056dae1e653a4abb9f2dd227d99 fedora/1/updates-testing/i386/openssl-0.9.7a-33.13.legacy.i686.rpm 5ce78af8e1d18ec2deb174ac6fdce6e84c68e46a fedora/1/updates-testing/i386/openssl-devel-0.9.7a-33.13.legacy.i386.rpm 1bee0f14e627fde0951377e1bf2f90b190152967 fedora/1/updates-testing/i386/openssl-perl-0.9.7a-33.13.legacy.i386.rpm 9e2427b58a5e52bbf3e6b59cacc7c11d5ae8d8b0 fedora/1/updates-testing/SRPMS/openssl096-0.9.6-26.2.legacy.src.rpm d16eb5ca21baed54c23f89e003a2084c482daa25 fedora/1/updates-testing/SRPMS/openssl096b-0.9.6b-18.2.legacy.src.rpm b116a8978d0ea6720193ac67c927d1c07eb122c4 fedora/1/updates-testing/SRPMS/openssl-0.9.7a-33.13.legacy.src.rpm fc2: c0b1d16c9b9dedc5661de97e87e886872241bd02 fedora/2/updates-testing/i386/openssl096b-0.9.6b-20.2.legacy.i386.rpm d8773965612fda44388b73296ba8fb9caea9db1f fedora/2/updates-testing/i386/openssl-0.9.7a-35.2.legacy.i386.rpm 45c1a884034056c1f3f31f6a61af617a44a31e47 fedora/2/updates-testing/i386/openssl-0.9.7a-35.2.legacy.i686.rpm 24f03de813df1d534d3d847fde68ffd603a2e234 fedora/2/updates-testing/i386/openssl-devel-0.9.7a-35.2.legacy.i386.rpm a990c20059b07984cc06a1029219b713650b0cfd fedora/2/updates-testing/i386/openssl-perl-0.9.7a-35.2.legacy.i386.rpm 1d7866f61179aab39ed819459923c3b71bda70ba fedora/2/updates-testing/SRPMS/openssl096b-0.9.6b-20.2.legacy.src.rpm 63d5d41cd2be5a010c2ad2c6276f0ddba2948e38 fedora/2/updates-testing/SRPMS/openssl-0.9.7a-35.2.legacy.src.rpm --------------------------------------------------------------------- Please test and comment in bugzilla. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at j2solutions.net Mon Oct 31 02:24:04 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 30 Oct 2005 18:24:04 -0800 Subject: glibc-common-2.2.5-44.legacy.6 update In-Reply-To: <43655962.7080902@yahoo.com> References: <43655962.7080902@yahoo.com> Message-ID: <1130725445.15854.2.camel@yoda.loki.me> On Sun, 2005-10-30 at 18:38 -0500, Jim Popovitch wrote: > Is there a way for us to develop packages that don't require updating > ALL the files in a package? For instance, in the latest glibc-common > update only a few lines of source code changed. Yet on my test system I > see a hundred files (mostly locale files) that are reported as being > changed by tripwire, but probably didn't really require a change from > the ones in the earlier package. Is this a nuisance that we could > prevent if we only released packages that were built on a common build > system? > > Just looking for more insight into keeping things consistent. ;-) The problem is that a package rebuild will rebuild all files within the package. There isn't a way around that. -- 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 From shiva at sewingwitch.com Mon Oct 31 18:25:07 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 31 Oct 2005 10:25:07 -0800 Subject: Typo in yum instructions Message-ID: "redhat" should be "fedora" in the URL. Also, the mirror at has an empty header.info file and no headers in the headers subdirectory. (2 of my 3 FC2 servers use the older yum.) From rostetter at mail.utexas.edu Mon Oct 31 19:47:57 2005 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 31 Oct 2005 13:47:57 -0600 Subject: Typo in yum instructions In-Reply-To: References: Message-ID: <1130788077.4b22798bc6549@mail.ph.utexas.edu> Quoting Kenneth Porter : > > > "redhat" should be "fedora" in the URL. I don't see anywhere that it is wrong after a quick glance, though I will change the reference to "Fedora Core 1" to just "Fedora Core" now that we support multiple releases of Fedora Core. If you think it is wrong, you will need to point it out better. > Also, the mirror at > has an empty > header.info file and no headers in the headers subdirectory. (2 of my 3 FC2 > servers use the older yum.) That is not part of FL, and hence you should notify atrpms.net about it. -- Eric Rostetter From jkeating at j2solutions.net Mon Oct 31 20:00:29 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 Oct 2005 12:00:29 -0800 Subject: Typo in yum instructions In-Reply-To: References: Message-ID: <1130788829.2901.34.camel@yoda.loki.me> On Mon, 2005-10-31 at 10:25 -0800, Kenneth Porter wrote: > > > "redhat" should be "fedora" in the URL. I see no error. One example is for RHL, the other example is for Fedora. > Also, the mirror at > has an empty > header.info file and no headers in the headers subdirectory. (2 of my 3 FC2 > servers use the older yum.) You'll have to contact atrpms regarding this. The master mirror has content there. http://download.fedoralegacy.org/fedora/2/updates-testing/i386/ -- 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 From shiva at sewingwitch.com Mon Oct 31 20:08:16 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 31 Oct 2005 12:08:16 -0800 Subject: Typo in yum instructions In-Reply-To: <1130788077.4b22798bc6549@mail.ph.utexas.edu> References: <1130788077.4b22798bc6549@mail.ph.utexas.edu> Message-ID: <090615CC4EA4DD94436F59D6@[10.0.0.14]> --On Monday, October 31, 2005 1:47 PM -0600 Eric Rostetter wrote: > I don't see anywhere that it is wrong after a quick glance, though > I will change the reference to "Fedora Core 1" to just "Fedora Core" > now that we support multiple releases of Fedora Core. Ah, that's what confused me. I saw the FC1 reference and figured the other was for all other distros. (I've got FC2.) > That is not part of FL, and hence you should notify atrpms.net about it. Will do. I just figured he watches this list and so might others using his mirror. I see he has a bugzilla to report issues, so I'll echo it there. From Axel.Thimm at ATrpms.net Mon Oct 31 20:16:02 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 31 Oct 2005 21:16:02 +0100 Subject: Typo in yum instructions In-Reply-To: References: Message-ID: <20051031201602.GA7580@neu.nirvana> On Mon, Oct 31, 2005 at 10:25:07AM -0800, Kenneth Porter wrote: > Also, the mirror at > has an empty > header.info file and no headers in the headers subdirectory. (2 of my 3 FC2 > servers use the older yum.) Yes, although technically that's not the mirror, the true mirror is at http://dl.atrpms.net/mirrors/fedoralegacy/ including yum20 format headers. I wouldn't start changing content in a mirrored part :=) The problem is that yum-arch has a bug that breaks my yum20 repos: https://lists.dulug.duke.edu/pipermail/yum/2005-July/007140.html yum's author will probably recommend to upgrade yum, if you rereport this bug, and I would agree, as there have been tons of bugs fixed since fc2 time. -- 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 shiva at sewingwitch.com Mon Oct 31 20:37:49 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 31 Oct 2005 12:37:49 -0800 Subject: Typo in yum instructions In-Reply-To: <20051031201602.GA7580@neu.nirvana> References: <20051031201602.GA7580@neu.nirvana> Message-ID: <41437F4BC09F54CAA114DEDB@[10.0.0.14]> --On Monday, October 31, 2005 9:16 PM +0100 Axel Thimm wrote: > Yes, although technically that's not the mirror, the true mirror is at > http://dl.atrpms.net/mirrors/fedoralegacy/ including yum20 format > headers. I wouldn't start changing content in a mirrored part :=) > > The problem is that yum-arch has a bug that breaks my yum20 repos: > > https://lists.dulug.duke.edu/pipermail/yum/2005-July/007140.html > > yum's author will probably recommend to upgrade yum, if you rereport > this bug, and I would agree, as there have been tons of bugs fixed > since fc2 time. Ok, thanks. I guess I don't really have any reason now not to upgrade, since Legacy is now including the new repo format in the older distro directories. From mic at npgx.com.au Mon Oct 31 20:45:46 2005 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 1 Nov 2005 06:45:46 +1000 Subject: Typo in yum instructions In-Reply-To: <41437F4BC09F54CAA114DEDB@[10.0.0.14]> References: <20051031201602.GA7580@neu.nirvana> <41437F4BC09F54CAA114DEDB@[10.0.0.14]> Message-ID: <20051031204051.M35646@npgx.com.au> > > Yes, although technically that's not the mirror, the true mirror is at > > http://dl.atrpms.net/mirrors/fedoralegacy/ including yum20 format > > headers. I wouldn't start changing content in a mirrored part :=) > > > > The problem is that yum-arch has a bug that breaks my yum20 repos: > > > > https://lists.dulug.duke.edu/pipermail/yum/2005-July/007140.html > > > > yum's author will probably recommend to upgrade yum, if you rereport > > this bug, and I would agree, as there have been tons of bugs fixed > > since fc2 time. > > Ok, thanks. I guess I don't really have any reason now not to > upgrade, since Legacy is now including the new repo format in the > older distro directories. I upgraded various servers and various distributions (RH-based) to the newer yum supplied by ATrpms some months ago. I also use the ATrpms medley-package-config package which keeps my repo's up to date without me having to do too much manual modifications. Since upgrading, I've saved time and effort in managing package updates for the servers I run, and less yum problems! As did I, once you upgrade you won't look back. Regards, Michael. From shiva at sewingwitch.com Mon Oct 31 20:55:14 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 31 Oct 2005 12:55:14 -0800 Subject: Typo in yum instructions In-Reply-To: <20051031204051.M35646@npgx.com.au> References: <20051031201602.GA7580@neu.nirvana> <41437F4BC09F54CAA114DEDB@[10.0.0.14]> <20051031204051.M35646@npgx.com.au> Message-ID: --On Tuesday, November 01, 2005 6:45 AM +1000 Michael Mansour wrote: > Since upgrading, I've saved time and effort in managing package updates > for the servers I run, and less yum problems! I upgraded one server to get the new improved XML metadata, only to find that Legacy didn't have the new metadata. So I didn't apply the update to my other servers. (I use one server as a guinea pig before letting the others update themselves.) From jkeating at j2solutions.net Mon Oct 31 21:23:28 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 Oct 2005 13:23:28 -0800 Subject: Typo in yum instructions In-Reply-To: References: <20051031201602.GA7580@neu.nirvana> <41437F4BC09F54CAA114DEDB@[10.0.0.14]> <20051031204051.M35646@npgx.com.au> Message-ID: <1130793808.2901.37.camel@yoda.loki.me> On Mon, 2005-10-31 at 12:55 -0800, Kenneth Porter wrote: > I upgraded one server to get the new improved XML metadata, only to find > that Legacy didn't have the new metadata. So I didn't apply the update to > my other servers. (I use one server as a guinea pig before letting the > others update themselves.) > Legacy has this metadata now, and other mirrors will have it when they sync. (as of a week ago?) -- 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 From deisenst at gtw.net Mon Oct 31 22:26:33 2005 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 31 Oct 2005 16:26:33 -0600 (CST) Subject: Old yum? New yum? Re: Typo in yum instructions In-Reply-To: <1130793808.2901.37.camel@yoda.loki.me> Message-ID: On Mon, 31 Oct 2005, Jesse Keating wrote: > On Mon, 2005-10-31 at 12:55 -0800, Kenneth Porter wrote: > > I upgraded one server to get the new improved XML metadata, only to find > > that Legacy didn't have the new metadata. So I didn't apply the update to > > my other servers. (I use one server as a guinea pig before letting the > > others update themselves.) > > > > Legacy has this metadata now, and other mirrors will have it when they > sync. (as of a week ago?) Can someone explain about "old yum" and "new yum?" I am confused about this, and am not finding anything in Fedora Legacy's documentation that helps me better understand it. I run Fedora Core 1, and have its yum (yum-2.0.4-2 from the original FC1 distro) installed. Is this the "new" yum? Or is the yum in updates for FC1 (yum-2.0.5-1) the new yum? If not, how do I go about getting the new yum? Will both the old and new yums work with fedoralegacy download sites, and/or other repositories? Also, the URL reported in the yum package on my system is . When I go to that wep-page, it looks like a Duke University Linux Users' Group moinmoin wiki page: "yum "This page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists." Where do I find out more information about the flavors of yum? And how yummy are they? :) Thanks. -David From jkeating at j2solutions.net Mon Oct 31 22:45:30 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 Oct 2005 14:45:30 -0800 Subject: Old yum? New yum? Re: Typo in yum instructions In-Reply-To: References: Message-ID: <1130798730.31305.20.camel@prometheus.gamehouse.com> On Mon, 2005-10-31 at 16:26 -0600, David Eisenstein wrote: > > I run Fedora Core 1, and have its yum (yum-2.0.4-2 from the original FC1 > distro) installed. Is this the "new" yum? Or is the yum in updates for > FC1 (yum-2.0.5-1) the new yum? If not, how do I go about getting the new > yum? Will both the old and new yums work with fedoralegacy download > sites, and/or other repositories? There is yum 2.0.x that is in FC1 and FC2, not sure about FC3. Yums greater than 2.1 or 2.2 have a new metadata format that they use. This is the 'old yum' vs 'new yum' that we're talking about. I have enabled both formats to work on the Legacy mirrors. -- 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 From jkosin at beta.intcomgrp.com Mon Oct 31 22:51:20 2005 From: jkosin at beta.intcomgrp.com (James Kosin) Date: Mon, 31 Oct 2005 17:51:20 -0500 Subject: Old yum? New yum? Re: Typo in yum instructions In-Reply-To: References: Message-ID: <43669FE8.50006@beta.intcomgrp.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Eisenstein wrote: >On Mon, 31 Oct 2005, Jesse Keating wrote: > >>On Mon, 2005-10-31 at 12:55 -0800, Kenneth Porter wrote: >> >>>I upgraded one server to get the new improved XML metadata, only to find >>>that Legacy didn't have the new metadata. So I didn't apply the update to >>>my other servers. (I use one server as a guinea pig before letting the >>>others update themselves.) >>> >>Legacy has this metadata now, and other mirrors will have it when they >>sync. (as of a week ago?) > > >Can someone explain about "old yum" and "new yum?" I am confused about >this, and am not finding anything in Fedora Legacy's documentation that >helps me better understand it. > >I run Fedora Core 1, and have its yum (yum-2.0.4-2 from the original FC1 >distro) installed. Is this the "new" yum? Or is the yum in updates for >FC1 (yum-2.0.5-1) the new yum? If not, how do I go about getting the new >yum? Will both the old and new yums work with fedoralegacy download >sites, and/or other repositories? > >Also, the URL reported in the yum package on my system is >. When I go to that wep-page, it looks >like a Duke University Linux Users' Group moinmoin wiki page: > > "yum > > "This page does not exist yet. You can create a new empty page, > or use one of the page templates. Before creating the page, > please check if a similar page already exists." > >Where do I find out more information about the flavors of yum? And how >yummy are they? :) > >Thanks. -David > >-- >fedora-legacy-list mailing list >fedora-legacy-list at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-legacy-list David, Short answer is: Old yum is how FC1 and FC2 operate currently. There has been talk on the list about changing support for the old-yum formats to the new format brought on by FC3 and higher, especially since the migration of FC3 to fedoralegacy is fast approaching. I think what is happening is some places have already migrated to the new format. I'm not sure if everyone has... If so, we should really have an official announcement. I haven't made any changes myself, and I'm hoping that it already hasn't happened... but, you are right the talk has been a bit confusing at times. Changes include: (a) downloading an official mirror list to use for the installation packages. This replaces any hard links to fedoralegacy in support for mirrors being queried fist. (b) multi-configuration support. To help avoid having a really big main configuration file for all repos. There may be other changes; but these are the BIG two. James Kosin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDZp/okNLDmnu1kSkRAyLkAJ9IEU4DxpNVtsFPOS7EeAOa5t9xIQCfbmam Zdub95CwDdRUjQUoWeVszYE= =XNUu -----END PGP SIGNATURE----- -- Scanned by ClamAV - http://www.clamav.net From jkeating at j2solutions.net Mon Oct 31 22:55:28 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 31 Oct 2005 14:55:28 -0800 Subject: Old yum? New yum? Re: Typo in yum instructions In-Reply-To: <43669FE8.50006@beta.intcomgrp.com> References: <43669FE8.50006@beta.intcomgrp.com> Message-ID: <1130799328.31305.21.camel@prometheus.gamehouse.com> On Mon, 2005-10-31 at 17:51 -0500, James Kosin wrote: > > Changes include: > (a) downloading an official mirror list to use for the > installation packages. This replaces any hard links to fedoralegacy This one is not a necessary change. We can support a mirror list, however I haven't set anything up regarding that. All that we have done is generated _both_ metadata types within the yum trees. That is all for now. -- 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 From skvidal at phy.duke.edu Mon Oct 31 23:12:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Oct 2005 18:12:41 -0500 Subject: Old yum? New yum? Re: Typo in yum instructions In-Reply-To: References: Message-ID: <1130800361.29433.1.camel@cutter> > Also, the URL reported in the yum package on my system is > . When I go to that wep-page, it looks > like a Duke University Linux Users' Group moinmoin wiki page: > > "yum > > "This page does not exist yet. You can create a new empty page, > or use one of the page templates. Before creating the page, > please check if a similar page already exists." > > Where do I find out more information about the flavors of yum? And how > yummy are they? :) http://linux.duke.edu/yum/ that should solve it. -sv From shiva at sewingwitch.com Mon Oct 31 23:41:20 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 31 Oct 2005 15:41:20 -0800 Subject: Old yum? New yum? Re: Typo in yum instructions In-Reply-To: <1130798730.31305.20.camel@prometheus.gamehouse.com> References: <1130798730.31305.20.camel@prometheus.gamehouse.com> Message-ID: <10001EE833205FB55CAA7686@[10.0.0.14]> --On Monday, October 31, 2005 2:45 PM -0800 Jesse Keating wrote: > There is yum 2.0.x that is in FC1 and FC2, not sure about FC3. Yums > greater than 2.1 or 2.2 have a new metadata format that they use. This > is the 'old yum' vs 'new yum' that we're talking about. I have enabled > both formats to work on the Legacy mirrors. Thanks for doing so. Something for users new to 2.1 to watch out for: The --download-only switch went away. If you add that to your nightly cron job (in /etc/cron.daily/yum.cron), it will either break the script or install the updates (I forget which). I believe another utility is available that does the equivalent.