From forsberg+fedoralegacy at cendio.se Mon Mar 1 10:37:32 2004 From: forsberg+fedoralegacy at cendio.se (Erik Forsberg) Date: 01 Mar 2004 11:37:32 +0100 Subject: QA testing for apt on RH{7.X|8.0} Message-ID: Hi! If I check out the instructions for using apt on RH8.0 (http://www.fedoralegacy.org/docs/apt-rh8.php), it says: "NOTE: The Fedora Legacy apt program has not yet finished QA testing. The instructions for installing it below will not work (or be completed) until it has passed the QA testing." ..in big fat scary letters that makes me a little bit afraid :-). How is QA testing on using APT for Red Hat Linux 8.0 (and 7.X) going? Where can I see status of it? How can I help (I do have access to a bunch of machines running RH 7.X and 8.0). \EF -- Erik Forsberg Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com From peter.abraham at dynamicnet.net Mon Mar 1 11:44:13 2004 From: peter.abraham at dynamicnet.net (Peter M. Abraham) Date: Mon, 01 Mar 2004 06:44:13 -0500 Subject: Fixed Kernel? In-Reply-To: <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> Message-ID: <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> Greetings: What is the status of the RedHat 7.3 kernel update? When will it be moved from testing to distribution? Thank you! From ms-nospam-0306 at arcor.de Mon Mar 1 12:48:58 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 1 Mar 2004 13:48:58 +0100 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: References: Message-ID: <20040301134858.564e5547.ms-nospam-0306@arcor.de> On 01 Mar 2004 11:37:32 +0100, Erik Forsberg wrote: > How is QA testing on using APT for Red Hat Linux 8.0 (and 7.X) going? > Where can I see status of it? How can I help (I do have access to a > bunch of machines running RH 7.X and 8.0). http://www.fedora.us/LEGACY -- From rohwedde at codegrinder.com Mon Mar 1 16:36:07 2004 From: rohwedde at codegrinder.com (Jason) Date: Mon, 1 Mar 2004 10:36:07 -0600 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: <20040301134858.564e5547.ms-nospam-0306@arcor.de> References: <20040301134858.564e5547.ms-nospam-0306@arcor.de> Message-ID: <20040301163607.GX15179@codegrinder.com> On Mon, Mar 01, 2004 at 01:48:58PM +0100, Michael Schwendt wrote: > On 01 Mar 2004 11:37:32 +0100, Erik Forsberg wrote: > > > How is QA testing on using APT for Red Hat Linux 8.0 (and 7.X) going? > > Where can I see status of it? How can I help (I do have access to a > > bunch of machines running RH 7.X and 8.0). > > http://www.fedora.us/LEGACY We're currently waiting on the package to stabilize in fedora core, then changes will be merged and the package will be put back on the QA chopping block. You can still use freshrpms, or your own compilation of apt, you'll just have to set up the sources yourself. As far as helping, read through the bug, maybe chime in if you have some strong opinions on some of the issues raised.. Most notably - automatic kernel updates - automatic installation of GPG keys to users' keyring in RH7.x https://bugzilla.fedora.us/show_bug.cgi?id=1174 -jason rohwedder -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From forsberg+fedoralegacy at cendio.se Mon Mar 1 17:02:15 2004 From: forsberg+fedoralegacy at cendio.se (Erik Forsberg) Date: 01 Mar 2004 18:02:15 +0100 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: <20040301163607.GX15179@codegrinder.com> References: <20040301134858.564e5547.ms-nospam-0306@arcor.de> <20040301163607.GX15179@codegrinder.com> Message-ID: rohwedde at codegrinder.com (Jason) writes: > You can still use freshrpms, or your own compilation of apt, you'll just > have to set up the sources yourself. OK. So if I understand correctly, the apt directories of download.fedoralegacy.org (and some of its mirrors) for RH7.X and RH8.0 are updated with new packages (at least in updates and updates-testing :-) )? The only thing missing is an official apt release from Fedora Legacy? \EF -- Erik Forsberg Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com From rostetter at mail.utexas.edu Mon Mar 1 18:47:23 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 1 Mar 2004 12:47:23 -0600 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: References: Message-ID: <20040301124723.o6rkwgcwkws0scgo@mail.ph.utexas.edu> Quoting Erik Forsberg : > If I check out the instructions for using apt on RH8.0 > (http://www.fedoralegacy.org/docs/apt-rh8.php), it says: > > "NOTE: The Fedora Legacy apt program has not yet finished QA > testing. The instructions for installing it below will not work (or be > completed) until it has passed the QA testing." > > ..in big fat scary letters that makes me a little bit afraid :-). Glad that it scared you :) The real problem here is that since it isn't released yet, I can't complete the instructions (e.g. by providing the actual url to download it from, etc). > How is QA testing on using APT for Red Hat Linux 8.0 (and 7.X) going? I'm using it on RH 8.0 without problem. Not sure who else has tested it if anyone since then. But there has been discussion and changes made after I tested it, so I can't speak for anything except the version I tested. See the buzilla entry for the details. > Where can I see status of it? How can I help (I do have access to a > bunch of machines running RH 7.X and 8.0). Well, you can find the status in bugzilla. I do this by going to http://www.fedoralegacy.org/, click on the "Legacy Devel Tracker" link in the "News" section of the right hand column, then find the package I am interested in and click on the "Id" number at the left. Normally, that will tell you all you need to know. But in the case of apt, there is a note in there about waiting for a FC apt version, and no follow up about this. So you may need to ask the mailing list about this. > \EF > -- > Erik Forsberg Telephone: +46-13-21 46 00 > Cendio AB Web: http://www.cendio.com -- Eric Rostetter From rohwedde at codegrinder.com Mon Mar 1 18:47:35 2004 From: rohwedde at codegrinder.com (Jason) Date: Mon, 1 Mar 2004 12:47:35 -0600 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: References: <20040301134858.564e5547.ms-nospam-0306@arcor.de> <20040301163607.GX15179@codegrinder.com> Message-ID: <20040301184735.GZ15179@codegrinder.com> On Mon, Mar 01, 2004 at 06:02:15PM +0100, Erik Forsberg wrote: > rohwedde at codegrinder.com (Jason) writes: > > > > You can still use freshrpms, or your own compilation of apt, you'll just > > have to set up the sources yourself. > > OK. So if I understand correctly, the apt directories of > download.fedoralegacy.org (and some of its mirrors) for RH7.X and > RH8.0 are updated with new packages (at least in updates and > updates-testing :-) )? The only thing missing is an official apt > release from Fedora Legacy? > That's correct.. check out http://www.fedoralegacy.org/download/ for the sources. -j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at welho.com Mon Mar 1 18:53:51 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 01 Mar 2004 20:53:51 +0200 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: <20040301163607.GX15179@codegrinder.com> References: <20040301134858.564e5547.ms-nospam-0306@arcor.de> <20040301163607.GX15179@codegrinder.com> Message-ID: <1078167231.18586.12.camel@chip.laiskiainen.org> On Mon, 2004-03-01 at 18:36, Jason wrote: > On Mon, Mar 01, 2004 at 01:48:58PM +0100, Michael Schwendt wrote: > > On 01 Mar 2004 11:37:32 +0100, Erik Forsberg wrote: > > > > > How is QA testing on using APT for Red Hat Linux 8.0 (and 7.X) going? > > > Where can I see status of it? How can I help (I do have access to a > > > bunch of machines running RH 7.X and 8.0). > > > > http://www.fedora.us/LEGACY > > We're currently waiting on the package to stabilize in fedora core, then > changes will be merged and the package will be put back on the QA > chopping block. Jason, FYI: the FC 1 and 1.90 apt is just about to go live (finally :), you might want to check and resync the legacy apt version to the latest one, not that there are any big changes there, just some rewording of mirror-select stuff etc: http://fedora.laiskiainen.org/SRPMS.fdr/apt-0.5.15cnc5-0.fdr.10.src.rpm - Panu - From rostetter at mail.utexas.edu Mon Mar 1 18:57:24 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 1 Mar 2004 12:57:24 -0600 Subject: Fixed Kernel? In-Reply-To: <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> Message-ID: <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> Quoting "Peter M. Abraham" : > Greetings: > > What is the status of the RedHat 7.3 kernel update? It is in testing, waiting for people to test it. I'm running it on about a dozen 7.2 machines without any problem. > When will it be moved from testing to distribution? Yes, eventually. When depends on whether people will step forward and test it or not. > Thank you! -- Eric Rostetter From rostetter at mail.utexas.edu Mon Mar 1 19:37:35 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 1 Mar 2004 13:37:35 -0600 Subject: QA testing for apt on RH{7.X|8.0} In-Reply-To: References: <20040301134858.564e5547.ms-nospam-0306@arcor.de> <20040301163607.GX15179@codegrinder.com> Message-ID: <20040301133735.0s2og8w400sk8484@mail.ph.utexas.edu> Quoting Erik Forsberg : > OK. So if I understand correctly, the apt directories of > download.fedoralegacy.org (and some of its mirrors) for RH7.X and > RH8.0 are updated with new packages (at least in updates and > updates-testing :-) )? The only thing missing is an official apt > release from Fedora Legacy? Yes. -- Eric Rostetter From warren at togami.com Mon Mar 1 20:11:10 2004 From: warren at togami.com (Warren Togami) Date: Mon, 01 Mar 2004 10:11:10 -1000 Subject: Squid-2.5.STABLE5 released [minor security / major bugfix release] Message-ID: <404398DE.8040206@togami.com> -------- Original Message -------- Subject: Squid-2.5.STABLE5 released [minor security / major bugfix release] Date: Mon, 1 Mar 2004 12:37:00 +0100 (CET) From: Henrik Nordstrom To: squid-announce at squid-cache.org The Squid HTTP Proxy team is pleased to announce the availability of the Squid-2.5.STABLE5 bugfix release. This new release can be downloaded from our HTTP or FTP servers http://www.squid-cache.org/Versions/v2/2.5/ ftp://ftp.squid-cache.org/pub/squid-2/STABLE/ or the mirrors (may take a while before all mirrors are updated). For a list of mirror sites see http://www.squid-cache.org/Mirrors/http-mirrors.html http://www.squid-cache.org/Mirrors/ftp-mirrors.html Squid-2.5.STABLE5 is a major bugfix release of Squid-2.5 and corrects one minor security issue in url_regex access controls and several major non-security related bugs found in the earlier Squid-2.5 releases. Users are recommended to upgrade to this new release, especially if using any of the features mentioned below. The most important bug-fixes in this release are: [security] %00 in could be used in to bypass url_regex and urlpath_regex access controls in certain configurations. Other acl directives not affected. More information on this issue can be found in the SQUID-2004:1 security advisory distributed separately [major] Several NTLM related bugfixes and improvements fixing the problem of random auth popups and account lockouts. Optional support for the NEGOTIATE NTLM packet is also added to allow Samba-3.0.2 or later to negotiate the use of NTLMv2 or NTLM2. [major] Several authentication related bugfixes to allow authentication to work in additional acl driven directives outside of http_access, and a number of corrections to assertion or segmentation faults and some memory leaks. In addition there is a small number of new features or improvements which enhances the functionality of Squid [medium] redirector interface modified to work with login names containing spaces or other odd characters. This is accomplished by URL-encoding the login name before sent to redirectors. Note: Existing redirectors or their configuration may need to be slightly modified in how they process the ident column to support the new username format (only applies to redirectors looking into the username) [medium] various timeouts adjusted: connect_timeout 1 minute (was 2 minutes which is now forward_timeout), negative_dns_ttl 1 minute (was 5 minutes) and is now also used as minimum positive dns ttl, dns_timeout 2 minutes (was 5 minutes) [minor] "short_icon_urls on" can be used to simplify the URLs used for icons etc to avoid issues with proxy host naming and authentication when requesting icons. [minor] A new "urllogin" ACL type has been introduced allowing regex matches to the "login" component of Internet style URLs (protocol://user:password at host/path/to/file). [minor] Squid now respects the Telnet protocol on connections to FTP servers. The ftp_telnet_protocol directice can be used to revert back to the old incorrect implementation if required. [minor] The default mime.conf has been updated with many new mime types and a few minor corrections. In addition the download and view links is used more frequently to allow view/download of different ftp:// contents regardless of their mime type assignment. in addition there is a large amount of minor and cosmetic bugfixes not included in the above list. For a complete list of changes see the ChangeLog and the Squid-2.5 Patches page It is recommended to read the release notes when upgrading from an earlier Squid release (including Squid-2.5.STABLE4) as there has been some minor changes in the configuration. Thanks goes to MARA Systems AB who has been actively sponsoring this bugfix release of Squid as part of their continuing effort to provide both free and commercial support to the Squid community, and to all users who have provided valuable bug reports and feedback via the Squid bug reporting tool. Regards The Squid HTTP Proxy developer team From news at iname.dk Mon Mar 1 21:49:17 2004 From: news at iname.dk (Claus Christensen) Date: Mon, 01 Mar 2004 22:49:17 +0100 Subject: Fixed Kernel? In-Reply-To: <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> Message-ID: <4043AFDD.9040200@iname.dk> Eric Rostetter wrote: > Quoting "Peter M. Abraham" : > > Yes, eventually. When depends on whether people will step forward > and test it or not. I'm now running kernel-2.4.20-30.7.legacy.i686.rpm on my RH 7.3 server. Shut I report a succes? Claus -- Don't mail at news at iname.dk - use: clch (AT) iname.dk From jkeating at j2solutions.net Mon Mar 1 22:15:02 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 1 Mar 2004 14:15:02 -0800 Subject: Fixed Kernel? In-Reply-To: <4043AFDD.9040200@iname.dk> References: <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> <4043AFDD.9040200@iname.dk> Message-ID: <200403011415.06742.jkeating@j2solutions.net> On Monday 01 March 2004 13:49, Claus Christensen wrote: > I'm now running kernel-2.4.20-30.7.legacy.i686.rpm on my RH 7.3 > server. Shut I report a succes? Please do. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rostetter at mail.utexas.edu Tue Mar 2 00:03:44 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 1 Mar 2004 18:03:44 -0600 Subject: Fixed Kernel? In-Reply-To: <4043AFDD.9040200@iname.dk> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> <4043AFDD.9040200@iname.dk> Message-ID: <20040301180344.kjmmxa80wcgc4gkg@mail.ph.utexas.edu> Quoting Claus Christensen : > I'm now running kernel-2.4.20-30.7.legacy.i686.rpm on my RH 7.3 server. > Shut I report a succes? Assuming it runs successfully, then yes, you should report success in the bugzilla entry (or at least to this mailing list, but really to bugzilla if at all possible). The best report would be a success message (what you installed, how the install went, how it is working and for how long you tested it, and what OS/arch you run it on) in a gpg clearsigned posting to bugzilla. I can help you with all that if you don't know how to make gpg clearsigned messages, use bugzilla, etc. (Let me know if you need/want help with anything). > Claus > -- > Don't mail at news at iname.dk - use: clch (AT) iname.dk -- Eric Rostetter From warren at togami.com Tue Mar 2 01:16:24 2004 From: warren at togami.com (Warren Togami) Date: Mon, 01 Mar 2004 15:16:24 -1000 Subject: Fixed Kernel? In-Reply-To: <20040301180344.kjmmxa80wcgc4gkg@mail.ph.utexas.edu> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> <4043AFDD.9040200@iname.dk> <20040301180344.kjmmxa80wcgc4gkg@mail.ph.utexas.edu> Message-ID: <4043E068.7030304@togami.com> Note that just "running" a kernel usually wont expose less obvious problems. You folks testing the update-testing kernel should run stress tests that cause CPU/disk/RAM to be heavily saturated. If it swaps heavily that is a good test. bonnie++ is a good test for disk I/O and filesystem stability. Jesse has a package that runs a whole bunch of stress tests and managed to raise the temperature in my room 10 degrees F. Jesse perhaps you should publish that package here? Does it work on RH7.x and RH8? Warren From jkeating at j2solutions.net Tue Mar 2 01:24:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 1 Mar 2004 17:24:47 -0800 Subject: Fixed Kernel? In-Reply-To: <4043E068.7030304@togami.com> References: <20040301180344.kjmmxa80wcgc4gkg@mail.ph.utexas.edu> <4043E068.7030304@togami.com> Message-ID: <200403011724.47677.jkeating@j2solutions.net> On Monday 01 March 2004 17:16, Warren Togami wrote: > Jesse has a package that runs a whole bunch of stress tests and > managed to raise the temperature in my room 10 degrees F. Jesse > perhaps you should publish that package here? Does it work on RH7.x > and RH8? You're probably thinking of CTCS, which can be found at: http://sourceforge.net/projects/va-ctcs I have an rpm that just packages up the tarball and extracts it into a directory we use here at work. It's a rather ugly rpm and I'm not sure I want it out in the wild (; The nice thing about CTCS, is that it builds itself the first time you run it, so the package can kinda be noarch, but I'm not sure how/if CTCS works on say ia64 or whatnot. Anywho, the "newburn" script inside the tarball will continuously run a bunch of tests and "burn" the hardware in, giving you a running count of how long the burnin has been running. A good 24 hour burn is a nice measurement as to if the system is stable or not. If you _do_ do something like this, be sure that if it fails on a new kernel, that it doesn't fail on an older kernel as well. CTCS has a tendency to bring hardware issues to the surface that may not show up with just day to day useage. This goes for other stress testers as well. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From cra at WPI.EDU Tue Mar 2 02:52:20 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 1 Mar 2004 21:52:20 -0500 Subject: Fixed Kernel? In-Reply-To: <4043E068.7030304@togami.com> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> <4043AFDD.9040200@iname.dk> <20040301180344.kjmmxa80wcgc4gkg@mail.ph.utexas.edu> <4043E068.7030304@togami.com> Message-ID: <20040302025220.GS27458@angus.ind.WPI.EDU> On Mon, Mar 01, 2004 at 03:16:24PM -1000, Warren Togami wrote: > Note that just "running" a kernel usually wont expose less obvious > problems. You folks testing the update-testing kernel should run stress > tests that cause CPU/disk/RAM to be heavily saturated. If it swaps > heavily that is a good test. Rebuilding the kernel src.rpm and comparing the resulting extracted binaries would be a good stress test. Something along these lines: boot to updates-testing kernel mkdir original cd original rpm2cpio kernel-from-updates-testing.i686.rpm | cpio -idv cd .. mkdir rebuild cd rebuild rpmbuild --rebuild --target=i686 kernel-from-updates-testing.src.rpm rpm2cpio kernel-just-rebuilt.i686.rpm | cpio -idv cd .. diff -ur original rebuild From rostetter at mail.utexas.edu Tue Mar 2 03:10:21 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 1 Mar 2004 21:10:21 -0600 Subject: Fixed Kernel? In-Reply-To: <4043E068.7030304@togami.com> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> <4043AFDD.9040200@iname.dk> <20040301180344.kjmmxa80wcgc4gkg@mail.ph.utexas.edu> <4043E068.7030304@togami.com> Message-ID: <20040301211021.uc274agwcowc8kgc@mail.ph.utexas.edu> Quoting Warren Togami : > Note that just "running" a kernel usually wont expose less obvious > problems. You folks testing the update-testing kernel should run stress > tests that cause CPU/disk/RAM to be heavily saturated. If it swaps > heavily that is a good test. Ah, true, but in my case my users do that for me (numerical code running, mathematica, maple, web browsers, etc. Usually running about 10-15 people on the machine, with loads often going up to 8 to 10 range). > bonnie++ is a good test for disk I/O and filesystem stability. True. Since we're releasing security patches though, one thing that would be great is if anyone could test the exploits of the kernel bug to make sure the security problem is actually fixed... > Warren -- Eric Rostetter From arvand at sbcglobal.net Tue Mar 2 04:55:56 2004 From: arvand at sbcglobal.net (Arvand Sabetian) Date: Mon, 1 Mar 2004 20:55:56 -0800 Subject: Fixed Kernel? In-Reply-To: <20040301211021.uc274agwcowc8kgc@mail.ph.utexas.edu> Message-ID: <200403020456.i224tve3251038@pimout3-ext.prodigy.net> The kernel package has gotten a lot of QA now. Jesse, is there a set amount of responses you are expecting before it's pushed to updates? Not to whine but I think most people consider kernel security issues as a big deal and when people see that the kernel has taken close to 20 days to be released to update they will lose interest in the FL project and with loss of interest we will have less support in the long run. Regards, Arvand Sabetian From jkeating at j2solutions.net Tue Mar 2 06:23:20 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 1 Mar 2004 22:23:20 -0800 Subject: Fixed Kernel? In-Reply-To: <200403020456.i224tve3251038@pimout3-ext.prodigy.net> References: <200403020456.i224tve3251038@pimout3-ext.prodigy.net> Message-ID: <200403012223.24516.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 01 March 2004 20:55, Arvand Sabetian wrote: > The kernel package has gotten a lot of QA now. Jesse, is there a set > amount of responses you are expecting before it's pushed to updates? > > Not to whine but I think most people consider kernel security issues as > a big deal and when people see that the kernel has taken close to 20 > days to be released to update they will lose interest in the FL project > and with loss of interest we will have less support in the long run. Yes, it has gotten enough QA. I will be doing the release document hopefully in the morning. I was not able to do this tonight as I just got home from a late night consulting gig. I need sleep ): Look for the release in the morning. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFARChc4v2HLvE71NURAp0eAKC+5tWeklfFeklFBLl+etHiPoI7hACePMTs BsERrhSwWjXa0zbCZBemHF4= =d+Wl -----END PGP SIGNATURE----- From jkeating at j2solutions.net Tue Mar 2 18:57:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 2 Mar 2004 10:57:16 -0800 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities Message-ID: <200403021057.20696.jkeating@j2solutions.net> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated kernel resolves security vulnerabilities Advisory ID: FLSA:1284 Issue date: 2004-03-02 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1284 CVE Names: CAN-2004-0077, CAN-2004-0075, CAN-2004-0010, CAN-2004-0003 ----------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: Updated kernel packages that fix security vulnerabilities which may allow local users to gain root privileges are now available. These packages also resolve other minor issues. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386, i586, i686, athlon Red Hat Linux 7.3 - i386, i586, i686, athlon Red Hat Linux 8.0 - i386, i586, i686, athlon 3. Problem description: The Linux kernel handles the basic functions of the operating system. Paul Starzetz discovered a flaw in return value checking in mremap() in the Linux kernel versions 2.4.24 and previous that may allow a local attacker to gain root privileges. No exploit is currently available; however this issue is exploitable. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0077 to this issue. The Vicam USB driver in kernel versions prior to 2.4.25 does not use the copy_from_user function to access userspace, which crosses security boundaries. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0075 to this issue. Arjan van de Ven discovered a flaw in ncp_lookup() in ncpfs that could allow local privilege escalation. ncpfs is only used to allow a system to mount volumes of NetWare servers or print to NetWare printers. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0010 to this issue. Alan Cox found issues in the R128 Direct Render Infrastructure that could allow local privilege escalation. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0003 to this issue. All users are advised to upgrade to these errata packages, which contain backported security patches that correct these issues. Fedora Legacy would like to thank Paul Starzetz from ISEC for reporting the issue CAN-2004-0077, and Dominic Hargreaves for providing backported rpms for all issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1284 - KERNEL: r128 dri AND do_mremap VMA limit local privilege escalation vulnerability 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/kernel-2.4.20-30.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-2.4.20-30.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-BOOT-2.4.20-30.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-doc-2.4.20-30.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-source-2.4.20-30.7.legacy.i386.rpm i568: http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-2.4.20-30.7.legacy.i586.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-smp-2.4.20-30.7.legacy.i586.rpm i686: http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-2.4.20-30.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-bigmem-2.4.20-30.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-smp-2.4.20-30.7.legacy.i686.rpm athlon: http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-2.4.20-30.7.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/7.2/updates/i386/kernel-smp-2.4.20-30.7.legacy.athlon.rpm Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/kernel-2.4.20-30.7.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-30.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-BOOT-2.4.20-30.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-doc-2.4.20-30.7.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-source-2.4.20-30.7.legacy.i386.rpm i568: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-30.7.legacy.i586.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-30.7.legacy.i586.rpm i686: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-30.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-bigmem-2.4.20-30.7.legacy.i686.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-30.7.legacy.i686.rpm athlon: http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-30.7.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-30.7.legacy.athlon.rpm Red Hat Linux 8.0: SRPM: http://download.fedoralegacy.org/redhat/8.0/updates/SRPMS/kernel-2.4.20-30.8.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-2.4.20-30.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-BOOT-2.4.20-30.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-doc-2.4.20-30.8.legacy.i386.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-source-2.4.20-30.8.legacy.i386.rpm i568: http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-2.4.20-30.8.legacy.i586.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-smp-2.4.20-30.8.legacy.i586.rpm i686: http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-2.4.20-30.8.legacy.i686.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-bigmem-2.4.20-30.8.legacy.i686.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-smp-2.4.20-30.8.legacy.i686.rpm athlon: http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-2.4.20-30.8.legacy.athlon.rpm http://download.fedoralegacy.org/redhat/8.0/updates/i386/kernel-smp-2.4.20-30.8.legacy.athlon.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 4b1d86c6b9c706d5ed9561a2c4fc0628528ddc86 7.2/updates/SRPMS/kernel-2.4.20-30.7.legacy.src.rpm f97d96d3238aa1bb314896699e280a31ed85529d 7.2/updates/i386/kernel-2.4.20-30.7.legacy.athlon.rpm cf0e03315d942140fbb439521684705d25e59a8f 7.2/updates/i386/kernel-2.4.20-30.7.legacy.i386.rpm d3e0a7b68e06af4045cd4f66d0a5864920dbd5b5 7.2/updates/i386/kernel-2.4.20-30.7.legacy.i586.rpm debfa2741248dccffdade72b8efe3b94d0e2483c 7.2/updates/i386/kernel-2.4.20-30.7.legacy.i686.rpm 989873968805dca5a7abd47dfb0c6dfca8a110b4 7.2/updates/i386/kernel-BOOT-2.4.20-30.7.legacy.i386.rpm 17a5a3b267339f1b20870cdcf586f5784b632358 7.2/updates/i386/kernel-bigmem-2.4.20-30.7.legacy.i686.rpm 15c40d84c061917f08e0c6b540bc49999ed18599 7.2/updates/i386/kernel-doc-2.4.20-30.7.legacy.i386.rpm f1460dafa968105647f38983d795b2693692fbfd 7.2/updates/i386/kernel-smp-2.4.20-30.7.legacy.athlon.rpm 15f1ac18efcf20c6f7c2f1fdcd803562704e507f 7.2/updates/i386/kernel-smp-2.4.20-30.7.legacy.i586.rpm 3c0fdeb92cd1d549b643bf91429dd1b79a067e77 7.2/updates/i386/kernel-smp-2.4.20-30.7.legacy.i686.rpm c64a8cef6e9ec35454a397229b2a15a60bba5322 7.2/updates/i386/kernel-source-2.4.20-30.7.legacy.i386.rpm 4b1d86c6b9c706d5ed9561a2c4fc0628528ddc86 7.3/updates/SRPMS/kernel-2.4.20-30.7.legacy.src.rpm f97d96d3238aa1bb314896699e280a31ed85529d 7.3/updates/i386/kernel-2.4.20-30.7.legacy.athlon.rpm cf0e03315d942140fbb439521684705d25e59a8f 7.3/updates/i386/kernel-2.4.20-30.7.legacy.i386.rpm d3e0a7b68e06af4045cd4f66d0a5864920dbd5b5 7.3/updates/i386/kernel-2.4.20-30.7.legacy.i586.rpm debfa2741248dccffdade72b8efe3b94d0e2483c 7.3/updates/i386/kernel-2.4.20-30.7.legacy.i686.rpm 989873968805dca5a7abd47dfb0c6dfca8a110b4 7.3/updates/i386/kernel-BOOT-2.4.20-30.7.legacy.i386.rpm 17a5a3b267339f1b20870cdcf586f5784b632358 7.3/updates/i386/kernel-bigmem-2.4.20-30.7.legacy.i686.rpm 15c40d84c061917f08e0c6b540bc49999ed18599 7.3/updates/i386/kernel-doc-2.4.20-30.7.legacy.i386.rpm f1460dafa968105647f38983d795b2693692fbfd 7.3/updates/i386/kernel-smp-2.4.20-30.7.legacy.athlon.rpm 15f1ac18efcf20c6f7c2f1fdcd803562704e507f 7.3/updates/i386/kernel-smp-2.4.20-30.7.legacy.i586.rpm 3c0fdeb92cd1d549b643bf91429dd1b79a067e77 7.3/updates/i386/kernel-smp-2.4.20-30.7.legacy.i686.rpm c64a8cef6e9ec35454a397229b2a15a60bba5322 7.3/updates/i386/kernel-source-2.4.20-30.7.legacy.i386.rpm 8eea381f80412a9421d25b1466d084cbbf5e1cee 8.0/updates/SRPMS/kernel-2.4.20-30.8.legacy.src.rpm 77ee4d29f593a4746e70a6ac55f9791d3183803e 8.0/updates/i386/kernel-2.4.20-30.8.legacy.athlon.rpm b1ba3b73d03294d4b31756eb6086bfffd4ef9958 8.0/updates/i386/kernel-2.4.20-30.8.legacy.i386.rpm cd49df62f704ed4e11be197fdae0920de1e1c584 8.0/updates/i386/kernel-2.4.20-30.8.legacy.i586.rpm 467c2613862985f16e07db103d7d88ab914ea73c 8.0/updates/i386/kernel-2.4.20-30.8.legacy.i686.rpm 63e243113b85a57ccaaaf0bcdf1468d7f8290001 8.0/updates/i386/kernel-BOOT-2.4.20-30.8.legacy.i386.rpm ea960ffbacd83cdb2b0ae78e612da5099121f77c 8.0/updates/i386/kernel-bigmem-2.4.20-30.8.legacy.i686.rpm 842cea04dad3976173afb6609c19615eff88aa8a 8.0/updates/i386/kernel-doc-2.4.20-30.8.legacy.i386.rpm e07e04ffef20d0f3fd66cd8cc46d7f2d7d1c2af0 8.0/updates/i386/kernel-smp-2.4.20-30.8.legacy.athlon.rpm a2a81a0ebe3e7433e339881bd1ba6177f75599c8 8.0/updates/i386/kernel-smp-2.4.20-30.8.legacy.i586.rpm 8625244b0dca1a71fe9b74769f6376af9495b333 8.0/updates/i386/kernel-smp-2.4.20-30.8.legacy.i686.rpm 4f6b05bc2296a0b37bc9528fd0e36d4e8f69ff67 8.0/updates/i386/kernel-source-2.4.20-30.8.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0003 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0010 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0075 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0077 https://rhn.redhat.com/errata/RHSA-2004-065.html https://bugzilla.fedora.us/show_bug.cgi?id=1284 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org 10. Special Notes: If you use lilo, you will have to edit your lilo.conf file and shorten the label of this kernel. The label is too long for lilo, but not for grub. --------------------------------------------------------------------- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From peter.abraham at dynamicnet.net Tue Mar 2 21:15:09 2004 From: peter.abraham at dynamicnet.net (Peter M. Abraham) Date: Tue, 02 Mar 2004 16:15:09 -0500 Subject: Fixed Kernel? In-Reply-To: <200403012223.24516.jkeating@j2solutions.net> References: <200403020456.i224tve3251038@pimout3-ext.prodigy.net> <200403012223.24516.jkeating@j2solutions.net> Message-ID: <6.0.3.0.2.20040302161427.03cdf8b8@mail.dynamicnet.net> Greetings Jesse: Thank you for the release. In the future, so I can help out with testing... do you have a dummies guide to testing and submitting the test results? Thank you. At 01:23 AM 3/2/2004, you wrote: >Yes, it has gotten enough QA. I will be doing the release document >hopefully in the morning. I was not able to do this tonight as I just got >home from a late night consulting gig. I need sleep ): Look for the >release in the morning. From jkeating at j2solutions.net Tue Mar 2 21:57:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 2 Mar 2004 13:57:18 -0800 Subject: Fixed Kernel? In-Reply-To: <6.0.3.0.2.20040302161427.03cdf8b8@mail.dynamicnet.net> References: <200403020456.i224tve3251038@pimout3-ext.prodigy.net> <200403012223.24516.jkeating@j2solutions.net> <6.0.3.0.2.20040302161427.03cdf8b8@mail.dynamicnet.net> Message-ID: <200403021357.23686.jkeating@j2solutions.net> On Tuesday 02 March 2004 13:15, Peter M. Abraham wrote: > Thank you for the release. My pleasure. I'm really disappointed that it took so long for me to get it out, but the last weekend was not fun. I had hoped to get it out, instead I had to spend the weekend sick, and reading a book I'm going to have to do editing on. > In the future, so I can help out with testing... do you have a > dummies guide to testing and submitting the test results? I don't yet. This was something else I wanted to accomplish this last weekend. Maybe this coming weekend will prove more viable. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From warlock at eskimo.com Wed Mar 3 01:33:27 2004 From: warlock at eskimo.com (Jim Richardson) Date: Tue, 02 Mar 2004 17:33:27 -0800 Subject: Fixed Kernel? In-Reply-To: <4043AFDD.9040200@iname.dk> References: <200402181351.20730.jkeating@j2solutions.net> <20040219000214.GS26418@angus.ind.WPI.EDU> <6.0.3.0.2.20040219081206.01c74ec0@mail.dynamicnet.net> <20040219172426.1d30e2b6.ms-nospam-0306@arcor.de> <6.0.3.0.2.20040225082916.01d04198@mail.dynamicnet.net> <6.0.3.0.2.20040301064345.01d8a018@mail.dynamicnet.net> <20040301125724.g09wk4kwcsocsw4g@mail.ph.utexas.edu> <4043AFDD.9040200@iname.dk> Message-ID: <1078277607.18051.22.camel@grendel.myth> On Mon, 2004-03-01 at 13:49, Claus Christensen wrote: > Eric Rostetter wrote: > > Quoting "Peter M. Abraham" : > > > > > Yes, eventually. When depends on whether people will step forward > > and test it or not. > > I'm now running kernel-2.4.20-30.7.legacy.i686.rpm on my RH 7.3 server. > Shut I report a succes? > > Claus I've got the bigmem version running fine on a rather busy webserver From warlock at eskimo.com Wed Mar 3 01:44:52 2004 From: warlock at eskimo.com (Jim Richardson) Date: Tue, 02 Mar 2004 17:44:52 -0800 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <200403021057.20696.jkeating@j2solutions.net> References: <200403021057.20696.jkeating@j2solutions.net> Message-ID: <1078278292.18051.25.camel@grendel.myth> On Tue, 2004-03-02 at 10:57, Jesse Keating wrote: Just to be clear, these are the same kernels that have been available for testing for a while right? I want to make sure that I have this one allready updated, I have kernel-bigmem-2.4.20-30.7.legacy installed, is that the same as this release level? thanks, sorry to be obtuse, but I want to make sure. From jkeating at j2solutions.net Wed Mar 3 02:02:21 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 2 Mar 2004 18:02:21 -0800 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <1078278292.18051.25.camel@grendel.myth> References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> Message-ID: <200403021802.26620.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 March 2004 17:44, Jim Richardson wrote: > Just to be clear, these are the same kernels that have been available > for testing for a while right? I want to make sure that I have this one > allready updated, I have kernel-bigmem-2.4.20-30.7.legacy installed, is > that the same as this release level? thanks, sorry to be obtuse, but I > want to make sure. Yes, they are exactly the same. The sha1sums from this announcement should match those of the updates-testing announcement. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFARTyy4v2HLvE71NURArawAJ92FOcEh5znfmPuBt367ryKAMB/DQCfX9Uf GeH1lDSpcJ1mEVEkyyioesk= =yupH -----END PGP SIGNATURE----- From ivan at geosci.usyd.edu.au Wed Mar 3 02:37:52 2004 From: ivan at geosci.usyd.edu.au (Ivan Teliatnikov) Date: Wed, 3 Mar 2004 13:37:52 +1100 (EST) Subject: I would like to test apt, kernel etc. Message-ID: Hi, there, I will be happy to volunteer apt for fedora-legacy for RH 7.2 7.3 8.0. I am also running the latest kernel on a number of RH machine. In two words what do I need to do to participate as a tester? Ivan. -- ================================================================================ Ivan Teliatnikov phone: +61 2 9351 2031 fax: +61 2 9351 0184 mobile_phone: +61 402 173 179 email: ivan at es.usyd.edu.au School of Geosciences F05 - Edgeworth David Building The University of Sydney NSW 2006 Australia =============================================================================== From sheltren at cs.ucsb.edu Wed Mar 3 02:57:19 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 02 Mar 2004 18:57:19 -0800 Subject: I would like to test apt, kernel etc. In-Reply-To: References: Message-ID: <1078282638.3203.3.camel@avalanche> I think just watch the list and/or the bugzilla to keep track of new releases. Once one is posted for testing/QA you can knock yourself out (Not literally) :) -Jeff On Tue, 2004-03-02 at 18:37, Ivan Teliatnikov wrote: > Hi, there, > > I will be happy to volunteer apt for fedora-legacy for RH 7.2 7.3 8.0. I > am also running the latest kernel on a number of RH machine. > > In two words what do I need to do to participate as a tester? > > Ivan. From rostetter at mail.utexas.edu Wed Mar 3 04:16:08 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Tue, 2 Mar 2004 22:16:08 -0600 Subject: I would like to test apt, kernel etc. In-Reply-To: References: Message-ID: <20040302221608.7k0y8cwkgcocg8gg@mail.ph.utexas.edu> Quoting Ivan Teliatnikov : > In two words what do I need to do to participate as a tester? Depends on your abilities. For those without lots of time/ability, but access to one or more machines to test one, then: * go to https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY periodically * find any packages listed there with a State+Result of "RESO"+"PEND" that you run on your machines * Download those packages from the updates-testing channel and install them * Test them to make sure they install cleanly, function properly (best you can), just basically try to make sure they work as best you can. * Write up the results (what you downloaded, what machine arch/OS you installed on, how the install went, how the testing went, any problems or quirks you found, etc). * Report the above, preferably gpg clearsigned to the bugzilla, but if not then anyway you can (to the mailing list if needed, bugzilla if possible). If you have more time/ability to help than the above, then: * go to https://bugzilla.fedora.us/buglist.cgi?keywords=LEGACY periodically * find any packages there which you run or are familiar about * download and build the source (or binary if available) rpms * install, test, report back as above * help create fixes/patches if you can and fixes/patches are needed. In this second case, just cruise the available bugzilla postings to see what to do... You can learn what to do from the work already done. If you need any help with anything, just ask the list. This was all new to me a few months ago also, but now I'm in a position to help others get up to speed, so just ask if you need help with anything. > Ivan. > -- -- Eric Rostetter From sales at schostpro.com Wed Mar 3 07:05:42 2004 From: sales at schostpro.com (SC Web Services) Date: Wed, 3 Mar 2004 02:05:42 -0500 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <200403021802.26620.jkeating@j2solutions.net> References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> Message-ID: <115438192187.20040303020542@schostpro.com> Hello, I've just updated to the new kernel on a P3 1Ghz/512 running RH7.3. After installing the rpm, it gave an error saying name too long. I assume this had to do with lilo, so I took a look at my lilo.conf. It did indeed enter in the correct path for the entry. Here's what I have listed: #################### prompt timeout=3 default=linux boot=/dev/hde map=/boot/map install=/boot/boot.b message=/boot/message linear image=/boot/vmlinuz-2.4.20-30.7.legacy label=linux root=/dev/hde3 read-only initrd=/boot/initrd-2.4.20-30.7.legacy.img image=/boot/vmlinuz-2.4.20-28.7 label=linuxold root=/dev/hde3 read-only initrd=/boot/initrd-2.4.20-28.7.img image=/boot/vmlinuz-2.4.20-27.7 label=linuxold2 root=/dev/hde3 read-only initrd=/boot/initrd-2.4.20-27.7.img image=/boot/vmlinuz-2.4.18-24.7.x label=linuxstock root=/dev/hde3 read-only initrd=/boot/initrd-2.4.18-24.7.x.img ##################### So I did a reboot, but for some reason, it continues to boot the second entry, image=/boot/vmlinuz-2.4.20-28.7. Can this have something to do with the name too long issue? Sorry if this is the wrong place to ask, just thought someone here may shed some light. thx. Ed Tuesday, March 02, 2004, 9:02:21 PM, you wrote: JK> -----BEGIN PGP SIGNED MESSAGE----- JK> Hash: SHA1 JK> On Tuesday 02 March 2004 17:44, Jim Richardson wrote: >> Just to be clear, these are the same kernels that have been available >> for testing for a while right? I want to make sure that I have this one >> allready updated, I have kernel-bigmem-2.4.20-30.7.legacy installed, is >> that the same as this release level? thanks, sorry to be obtuse, but I >> want to make sure. JK> Yes, they are exactly the same. The sha1sums from this announcement should JK> match those of the updates-testing announcement. From troels at arvin.dk Wed Mar 3 08:34:09 2004 From: troels at arvin.dk (Troels Arvin) Date: Wed, 03 Mar 2004 09:34:09 +0100 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> Message-ID: On Wed, 03 Mar 2004 02:05:42 -0500, SC Web Services wrote: > So I did a reboot, but for some reason, it continues to boot the second > entry, image=/boot/vmlinuz-2.4.20-28.7. Can this have something to do with > the name too long issue? Yes. Remove all occurrences of ".legary" from lilo.conf and re-run "lilo". It's a known bug for the recently released legacy kernel pacakges. However, noone seemed to known how to fix the issue, so the packages were released anyways. -- Greetings from Troels Arvin, Copenhagen, Denmark From dawson at fnal.gov Wed Mar 3 14:14:46 2004 From: dawson at fnal.gov (Troy Dawson) Date: Wed, 03 Mar 2004 08:14:46 -0600 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <115438192187.20040303020542@schostpro.com> References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> Message-ID: <4045E856.9090901@fnal.gov> Hi, If it continues to boot boot the second image, then you need to run lilo again. Just run /sbin/lilo and if it doesn't have any errors, everything should be set (and it will highlight whichever kernel is set at the default kernel, with a *) Troy SC Web Services wrote: > Hello, > > I've just updated to the new kernel on a P3 1Ghz/512 running RH7.3. > > After installing the rpm, it gave an error saying name too long. I > assume this had to do with lilo, so I took a look at my lilo.conf. It > did indeed enter in the correct path for the entry. Here's what I have > listed: > > #################### > prompt > timeout=3 > default=linux > boot=/dev/hde > map=/boot/map > install=/boot/boot.b > message=/boot/message > linear > > image=/boot/vmlinuz-2.4.20-30.7.legacy > label=linux > root=/dev/hde3 > read-only > initrd=/boot/initrd-2.4.20-30.7.legacy.img > image=/boot/vmlinuz-2.4.20-28.7 > label=linuxold > root=/dev/hde3 > read-only > initrd=/boot/initrd-2.4.20-28.7.img > image=/boot/vmlinuz-2.4.20-27.7 > label=linuxold2 > root=/dev/hde3 > read-only > initrd=/boot/initrd-2.4.20-27.7.img > image=/boot/vmlinuz-2.4.18-24.7.x > label=linuxstock > root=/dev/hde3 > read-only > initrd=/boot/initrd-2.4.18-24.7.x.img > ##################### > > So I did a reboot, but for some reason, it continues to boot the > second entry, image=/boot/vmlinuz-2.4.20-28.7. Can this have something > to do with the name too long issue? > > Sorry if this is the wrong place to ask, just thought someone here may > shed some light. thx. > > Ed > > > > Tuesday, March 02, 2004, 9:02:21 PM, you wrote: > > JK> -----BEGIN PGP SIGNED MESSAGE----- > JK> Hash: SHA1 > > JK> On Tuesday 02 March 2004 17:44, Jim Richardson wrote: > >>>Just to be clear, these are the same kernels that have been available >>>for testing for a while right? I want to make sure that I have this one >>>allready updated, I have kernel-bigmem-2.4.20-30.7.legacy installed, is >>>that the same as this release level? thanks, sorry to be obtuse, but I >>>want to make sure. > > > JK> Yes, they are exactly the same. The sha1sums from this announcement should > JK> match those of the updates-testing announcement. > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From sales at schostpro.com Wed Mar 3 14:46:27 2004 From: sales at schostpro.com (SC Web Services) Date: Wed, 3 Mar 2004 09:46:27 -0500 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <4045E856.9090901@fnal.gov> References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> <4045E856.9090901@fnal.gov> Message-ID: <19465837390.20040303094627@schostpro.com> Hello, Just re-ran lilo -v, rebooted and it finally loaded the new kernel. Weird, thx for the tips tho! So far so good, I've also tried it on a P3 500 Dell Laptop using grub, no probs whatsoever. Good job guys! Ed Wednesday, March 03, 2004, 9:14:46 AM, you wrote: TD> Hi, TD> If it continues to boot boot the second image, then you need to run lilo TD> again. Just run TD> /sbin/lilo TD> and if it doesn't have any errors, everything should be set (and it will TD> highlight whichever kernel is set at the default kernel, with a *) TD> Troy TD> SC Web Services wrote: >> Hello, >> >> I've just updated to the new kernel on a P3 1Ghz/512 running RH7.3. >> >> After installing the rpm, it gave an error saying name too long. I >> assume this had to do with lilo, so I took a look at my lilo.conf. It >> did indeed enter in the correct path for the entry. Here's what I have >> listed: >> >> #################### >> prompt >> timeout=3 >> default=linux >> boot=/dev/hde >> map=/boot/map >> install=/boot/boot.b >> message=/boot/message >> linear >> >> image=/boot/vmlinuz-2.4.20-30.7.legacy >> label=linux >> root=/dev/hde3 >> read-only >> initrd=/boot/initrd-2.4.20-30.7.legacy.img >> image=/boot/vmlinuz-2.4.20-28.7 >> label=linuxold >> root=/dev/hde3 >> read-only >> initrd=/boot/initrd-2.4.20-28.7.img >> image=/boot/vmlinuz-2.4.20-27.7 >> label=linuxold2 >> root=/dev/hde3 >> read-only >> initrd=/boot/initrd-2.4.20-27.7.img >> image=/boot/vmlinuz-2.4.18-24.7.x >> label=linuxstock >> root=/dev/hde3 >> read-only >> initrd=/boot/initrd-2.4.18-24.7.x.img >> ##################### >> >> So I did a reboot, but for some reason, it continues to boot the >> second entry, image=/boot/vmlinuz-2.4.20-28.7. Can this have something >> to do with the name too long issue? >> >> Sorry if this is the wrong place to ask, just thought someone here may >> shed some light. thx. >> >> Ed >> >> >> >> Tuesday, March 02, 2004, 9:02:21 PM, you wrote: >> >> JK> -----BEGIN PGP SIGNED MESSAGE----- >> JK> Hash: SHA1 >> >> JK> On Tuesday 02 March 2004 17:44, Jim Richardson wrote: >> >>>>Just to be clear, these are the same kernels that have been available >>>>for testing for a while right? I want to make sure that I have this one >>>>allready updated, I have kernel-bigmem-2.4.20-30.7.legacy installed, is >>>>that the same as this release level? thanks, sorry to be obtuse, but I >>>>want to make sure. >> >> >> JK> Yes, they are exactly the same. The sha1sums from this announcement should >> JK> match those of the updates-testing announcement. >> >> >> >> -- >> fedora-legacy-list mailing list >> fedora-legacy-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-legacy-list From jpdalbec at ysu.edu Thu Mar 4 14:13:27 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 04 Mar 2004 09:13:27 -0500 Subject: mach success! Message-ID: <40473987.6050502@ysu.edu> I managed to create an rh72u buildroot on rh80 by liberal use of # export LD_PRELOAD=/lib/libnss_files.so.2; apt-get -c /var/lib/mach/states/.../apt.conf -f install ... to work around the GLIBC version problems apt-get: relocation error: /lib/libnss_files.so.2: symbol _nss_files_parse_{pw,gr}ent, version GLIBC_2.0 not defined in file libc.so.6 with link time reference which would occur every time an RPM script would invoke useradd or groupadd. I suppose the following patch would also work (untested): --- mach-helper.c.orig 2003-12-11 11:55:54.000000000 -0500 +++ mach-helper.c 2004-03-04 08:58:28.000000000 -0500 @@ -123,6 +123,7 @@ /* do not trust user environment */ char *env[] = { "PATH=/bin:/usr/bin:/usr/sbin", "HOME=/root", + "LD_PRELOAD=/lib/libnss_files.so.2", NULL }; int retval; char **arg; Is there a mach-specific mailing list I should be writing to? (I've cc:ed Thomas on this message.) Thanks, John From kas at informatics.muni.cz Thu Mar 4 15:26:55 2004 From: kas at informatics.muni.cz (Jan Kasprzak) Date: Thu, 4 Mar 2004 16:26:55 +0100 Subject: New Fedora Legacy mirror in Brno, CZ Message-ID: <20040304152654.GM13009@fi.muni.cz> Hello, Fedora Legacy people, I have set up a new mirror of Fedora Legacy (it is currently rsyncing with the master, it should be synced in few hours). The mirror is (will be) available at ftp://ftp.fi.muni.cz/pub/linux/fedora/legacy/ rsync://ftp.fi.muni.cz/pub/linux/fedora/legacy/ ftp://ftp6.linux.cz/pub/linux/fedora/legacy/ (IPv6 only) The server is located in Brno, Czech Republic, Europe, and it is updated daily. Contact address for the server admins is ftp-admin at fi.muni.cz. Please add this server to the list of mirrors. Is there any kind of privileged access to downloads.fedoralegacy.org for mirrors? If so, where should I post the IP address I will be connecting from? Sorry for posting to the list, but I was not able to find any mirror contact info at or near http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php. Thanks, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. --Linus Torvalds From jpdalbec at ysu.edu Thu Mar 4 15:39:28 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 04 Mar 2004 10:39:28 -0500 Subject: mach success! In-Reply-To: <40473987.6050502@ysu.edu> References: <40473987.6050502@ysu.edu> Message-ID: <40474DB0.7090508@ysu.edu> John Dalbec wrote: > I managed to create an rh72u buildroot on rh80 by liberal use of > > # export LD_PRELOAD=/lib/libnss_files.so.2; apt-get -c > /var/lib/mach/states/.../apt.conf -f install ... > > to work around the GLIBC version problems > > apt-get: relocation error: /lib/libnss_files.so.2: symbol > _nss_files_parse_{pw,gr}ent, version GLIBC_2.0 not defined in file > libc.so.6 with link time reference > > which would occur every time an RPM script would invoke useradd or > groupadd. > > I suppose the following patch would also work (untested): > --- mach-helper.c.orig 2003-12-11 11:55:54.000000000 -0500 > +++ mach-helper.c 2004-03-04 08:58:28.000000000 -0500 > @@ -123,6 +123,7 @@ > /* do not trust user environment */ > char *env[] = { "PATH=/bin:/usr/bin:/usr/sbin", > "HOME=/root", > + "LD_PRELOAD=/lib/libnss_files.so.2", > NULL }; > int retval; > char **arg; I got fed up with fixing the GLIBC version problems manually so I've rebuilt mach 0.4.3 with my patch and it appears to work fine. John > > Is there a mach-specific mailing list I should be writing to? (I've > cc:ed Thomas on this message.) > Thanks, > John > From rostetter at mail.utexas.edu Thu Mar 4 18:27:30 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 4 Mar 2004 12:27:30 -0600 Subject: New Fedora Legacy mirror in Brno, CZ In-Reply-To: <20040304152654.GM13009@fi.muni.cz> References: <20040304152654.GM13009@fi.muni.cz> Message-ID: <20040304122730.ylpycsss0k0ogkko@mail.ph.utexas.edu> Quoting Jan Kasprzak : > Sorry for posting to the list, but I was not able to find any mirror contact > info at or near > http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php. There is a bit of info one level up at http://www.fedoralegacy.org/download/mirrors.php I'll see about adding info/links to the page you cited. > Thanks, > > -Yenya -- Eric Rostetter From john.l.villalovos at intel.com Thu Mar 4 19:33:46 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Thu, 4 Mar 2004 11:33:46 -0800 Subject: Date/time stamps on files to help with hardlinking Message-ID: <50D19C3AC815734C9E19FE4C4F6128A6178047@orsmsx403.jf.intel.com> I was noticing that the files in the repository are not setup very well for hardlinking. This is because identical files do not have the exact same date/time stamps. For example: 13109840 Feb 21 09:29 7.2/updates/i386/kernel-2.4.20-30.7.legacy.i686.rpm 13109840 Feb 21 00:07 7.3/updates/i386/kernel-2.4.20-30.7.legacy.i686.rpm These two files are identical but they have different time stamps. The hardlink utility will only hardlink two files if they have the same date/time stamp, size, and are identical. Hardlink tool: ftp://ftp.redhat.com/pub/redhat/mirror-tools/ This can be a big savings in hard disk space. Is there any possibility of getting the files which are identical to have the same date/time stamps on the repository? Thanks, John From jkeating at j2solutions.net Thu Mar 4 19:36:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 11:36:51 -0800 Subject: Date/time stamps on files to help with hardlinking In-Reply-To: <50D19C3AC815734C9E19FE4C4F6128A6178047@orsmsx403.jf.intel.com> References: <50D19C3AC815734C9E19FE4C4F6128A6178047@orsmsx403.jf.intel.com> Message-ID: <200403041136.51777.jkeating@j2solutions.net> On Thursday 04 March 2004 11:33, Villalovos, John L wrote: > Is there any possibility of getting the files which are identical to > have the same date/time stamps on the repository? I could yet. However, I wonder, if the files are named the same, but are different contents, but have the same timestamp, will hardlink think they need to be linked? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From john.l.villalovos at intel.com Thu Mar 4 19:46:28 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Thu, 4 Mar 2004 11:46:28 -0800 Subject: Date/time stamps on files to help with hardlinking Message-ID: <50D19C3AC815734C9E19FE4C4F6128A602A569A2@orsmsx403.jf.intel.com> > -----Original Message----- > From: fedora-legacy-list-admin at redhat.com > [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of > Jesse Keating > Sent: Thursday, March 04, 2004 11:37 AM > To: fedora-legacy-list at redhat.com > Subject: Re: Date/time stamps on files to help with hardlinking > > > On Thursday 04 March 2004 11:33, Villalovos, John L wrote: > > Is there any possibility of getting the files which are identical to > > have the same date/time stamps on the repository? > > I could yet. However, I wonder, if the files are named the same, but > are different contents, but have the same timestamp, will hardlink > think they need to be linked? No. Hardlink looks at all of the following before doing a hardlink: * file mode/permissions * owner user id * owner group id * file size * modified time * and finally file contents must be equal. John From jkeating at j2solutions.net Thu Mar 4 19:49:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 11:49:04 -0800 Subject: Date/time stamps on files to help with hardlinking In-Reply-To: <50D19C3AC815734C9E19FE4C4F6128A602A569A2@orsmsx403.jf.intel.com> References: <50D19C3AC815734C9E19FE4C4F6128A602A569A2@orsmsx403.jf.intel.com> Message-ID: <200403041149.04232.jkeating@j2solutions.net> On Thursday 04 March 2004 11:46, Villalovos, John L wrote: > No. Hardlink looks at all of the following before doing a hardlink: > > * file mode/permissions > * owner user id > * owner group id > * file size > * modified time > * and finally file contents must be equal. Ok, the kernels (which is where the most size is) are now hardlinked. I was curious as to why they didn't get hardlinked before, didn't know the timestamp had to be the same. Looking into ways of getting the rest equal files hardlinked. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From john.l.villalovos at intel.com Thu Mar 4 20:00:33 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Thu, 4 Mar 2004 12:00:33 -0800 Subject: Date/time stamps on files to help with hardlinking Message-ID: <50D19C3AC815734C9E19FE4C4F6128A602A569A3@orsmsx403.jf.intel.com> > Ok, the kernels (which is where the most size is) are now > hardlinked. I > was curious as to why they didn't get hardlinked before, didn't know > the timestamp had to be the same. Looking into ways of getting the > rest equal files hardlinked. Thanks! It can be a big help. Just as a datapoint, on my current repository of Red Hat and Fedora related stuff I am currently saving 11.07 Gibibytes due to hardlinking :) John From jpdalbec at ysu.edu Thu Mar 4 22:03:34 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 04 Mar 2004 17:03:34 -0500 Subject: Mach XFree86 build error - preferred workaround? Message-ID: <4047A7B6.9030605@ysu.edu> Building XFree86 fails with: egrep: /proc/stat: no such file or directory This is the offending section of the .spec file: %if %{ParallelBuild} numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 )) [ "$numprocs" = "0" ] && numprocs=1 echo "PARALLEL MAKE ENABLED: numprocs=$numprocs" %else numprocs=1 %endif Is there a mach-compatible way to accomplish the same thing? Should I add /proc/stat as a BuildRequires? I'm trying various workarounds to be able to access /proc/stat, but it doesn't help that the build is run as a non-root user. My latest attempt is to add "none /proc proc defaults,user 0 0" to /etc/fstab and add the "mount" commands below: %if %{ParallelBuild} [ -f /proc/stat ] || mount /proc || mount /proc -o remount || : numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 )) [ "$numprocs" = "0" ] && numprocs=1 echo "PARALLEL MAKE ENABLED: numprocs=$numprocs" %else numprocs=1 %endif The remount is because /etc/mtab seems to have mount entries for /proc already. My workaround appears to have worked. At least the scrolling is much faster now. I had to restart the build with nohup because it's close to quittin' time and I don't leave my Windows box on overnight. Does mach require a terminal? I tried redirecting stdout and stderr and I still got status messages printed to the terminal. I've closed my SSH window. Will mach wait for TTY output all night instead of building the package? Thanks, John From jkeating at j2solutions.net Thu Mar 4 23:10:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 15:10:05 -0800 Subject: Date/time stamps on files to help with hardlinking In-Reply-To: <50D19C3AC815734C9E19FE4C4F6128A602A569A3@orsmsx403.jf.intel.com> References: <50D19C3AC815734C9E19FE4C4F6128A602A569A3@orsmsx403.jf.intel.com> Message-ID: <200403041510.09964.jkeating@j2solutions.net> On Thursday 04 March 2004 12:00, Villalovos, John L wrote: > Thanks! It can be a big help. > > Just as a datapoint, on my current repository of Red Hat and Fedora > related stuff I am currently saving 11.07 Gibibytes due to > hardlinking Most the files that could be hardlinked were hardlinked. It was just a few of them, and some of the legacy files that weren't. The entire tree is now hardlinked, and yum/apt metadata is being re-generated (just in case). The tree is still taking roughly 13G of space though (unless df counts hardlinked files twice). -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From cra at WPI.EDU Fri Mar 5 00:08:41 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 4 Mar 2004 19:08:41 -0500 Subject: Date/time stamps on files to help with hardlinking In-Reply-To: <200403041510.09964.jkeating@j2solutions.net> References: <50D19C3AC815734C9E19FE4C4F6128A602A569A3@orsmsx403.jf.intel.com> <200403041510.09964.jkeating@j2solutions.net> Message-ID: <20040305000841.GD9300@angus.ind.WPI.EDU> On Thu, Mar 04, 2004 at 03:10:05PM -0800, Jesse Keating wrote: Content-Description: signed data > Most the files that could be hardlinked were hardlinked. It was just a > few of them, and some of the legacy files that weren't. The entire > tree is now hardlinked, and yum/apt metadata is being re-generated > (just in case). The tree is still taking roughly 13G of space though > (unless df counts hardlinked files twice). I was under the impression that identical 7.2 and 7.3 src.rpm's were being built into separate binary rpm's to put in each directory. I don't see why this would be necessary, though. Red Hat has released identical errata for 7.2 and 7.3--the MD5SUMS were identical. From jkeating at j2solutions.net Fri Mar 5 00:34:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 16:34:56 -0800 Subject: Date/time stamps on files to help with hardlinking In-Reply-To: <20040305000841.GD9300@angus.ind.WPI.EDU> References: <50D19C3AC815734C9E19FE4C4F6128A602A569A3@orsmsx403.jf.intel.com> <200403041510.09964.jkeating@j2solutions.net> <20040305000841.GD9300@angus.ind.WPI.EDU> Message-ID: <200403041635.01029.jkeating@j2solutions.net> On Thursday 04 March 2004 16:08, Charles R. Anderson wrote: > I was under the impression that identical 7.2 and 7.3 src.rpm's were > being built into separate binary rpm's to put in each directory. I > don't see why this would be necessary, though. Red Hat has released > identical errata for 7.2 and 7.3--the MD5SUMS were identical. The majority of the updates are not duplicates. There has been very very few Legacy updates that are duplicates. When they are infact duplicate (usually happens when they were duplicate before Legacy got there) they will be made the same file. The majority of the hardlinking was done on Red Hat updates, not Legacy updates. Only the kernel and a couple other updates were hardlinked. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Fri Mar 5 03:53:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 19:53:41 -0800 Subject: [FLSA-2004:1256] Updated util-linux resolves security vulnerability Message-ID: <200403041953.41503.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated util-linux resolves security vulnerability Advisory ID: FLSA:1256 Issue date: 2004-03-04 Product: Red Hat Linux Keywords: Security Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=1256 CVE Names: CAN-2004-0080 - ----------------------------------------------------------------------- - --------------------------------------------------------------------- 1. Topic: Updated util-linux packages that fix an information leak in the login program are now available. 2. Relevent releases/architectures: Red Hat Linux 7.2 - i386 3. Problem description: The util-linux package contains a large variety of low-level system utilities that are necessary for a Linux system to function. In some situations, the login program could use a pointer that had been freed and reallocated. This could cause unintentional data leakage. Note: Red Hat Linux releases newer than 7.2 are not vulnerable to this issue. It is recommended that all users upgrade to these updated packages, which are not vulnerable to this issue. Fedora Legacy would like to thank Matthew Lee of Fleming College for finding and reporting this issue, and Jesse Keating for providing a backported patch for Red Hat Linux 7.2. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/download for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 1256 - Information leak in util-linux 6. RPMs required: Red Hat Linux 7.2: SRPM: http://download.fedoralegacy.org/redhat/7.2/updates/SRPMS/util-linux-2.11f-19.7.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.2/updates/i386/util-linux-2.11f-19.7.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - --------------------------------------------------------------------------- 26d4c12f4942e59a24c858b06271cc66528c1258 7.2/updates/SRPMS/util-linux-2.11f-19.7.2.legacy.src.rpm de5fb4026cab54e697abd908e5e01d3352c515b6 7.2/updates/i386/util-linux-2.11f-19.7.2.legacy.i386.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy.org/about/security.php You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0080 https://rhn.redhat.com/errata/RHSA-2004-056.html https://bugzilla.fedora.us/show_bug.cgi?id=1256 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAR/nF4v2HLvE71NURAnCwAKDGLnvqdzHO3sF62/aro7Awl/oQewCfZA6+ tV02DBiqpKMI+UFMsrb2+6k= =L+up -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Mar 5 04:02:29 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 4 Mar 2004 22:02:29 -0600 Subject: QA/SelfIntroduction added to wiki Message-ID: <20040304220229.lk0cg44ccww8g4w8@mail.ph.utexas.edu> I've added my QA and SelfIntroduction docs to the wiki, so please have at them. Thanks! -- Eric Rostetter The Department of Physics The University of Texas at Austin Why get even? Get odd! From ral77 at bellsouth.net Fri Mar 5 04:38:15 2004 From: ral77 at bellsouth.net (ral77) Date: Thu, 04 Mar 2004 23:38:15 -0500 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> Message-ID: <40480437.2050504@bellsouth.net> Troels Arvin wrote: >On Wed, 03 Mar 2004 02:05:42 -0500, SC Web Services wrote: > > > >>So I did a reboot, but for some reason, it continues to boot the second >>entry, image=/boot/vmlinuz-2.4.20-28.7. Can this have something to do with >>the name too long issue? >> >> > >Yes. Remove all occurrences of ".legary" from lilo.conf and re-run "lilo". > > > Will this apply to /boot/grub.conf as well after the updated kernel is installed (remove .legacy from kernel entry) ? I have both rh72 with lilo and a rh8 server using the grub bootloader. In the past when I downloaded and updated a kernel manually it was rpm -ivh kernel-2.4.20-*. This way the previous kernel is still available as backup , would a rpm -Fvh overwrite the kernel-2.4.20-28.7. thx's Robert From jkeating at j2solutions.net Fri Mar 5 04:40:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 20:40:04 -0800 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <40480437.2050504@bellsouth.net> References: <200403021057.20696.jkeating@j2solutions.net> <40480437.2050504@bellsouth.net> Message-ID: <200403042040.04211.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 04 March 2004 20:38, ral77 wrote: > Will this apply to /boot/grub.conf as well after the updated kernel is > installed (remove .legacy from kernel entry) ? > I have both rh72 with lilo and a rh8 server using the grub bootloader. > In the past when I downloaded and updated a kernel manually it was rpm > -ivh kernel-2.4.20-*. This way the previous kernel is still available as > backup , would a rpm -Fvh overwrite the kernel-2.4.20-28.7. No, grub is fine. - -Fvh will overwrite. Use -ivh instead. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASASk4v2HLvE71NURApd9AJ9NLzrsGqD/NnlZKHyDma0azTA5kQCgr+0Z ZA0UqzGA8xhh84W5pemDK6Q= =8+PQ -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Mar 5 04:51:37 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 20:51:37 -0800 Subject: Fedora Legacy Test Update Notification: libtool Message-ID: <200403042051.37309.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1268 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1268 2004-03-04 - --------------------------------------------------------------------- Name : libtool Version 7.2 : 1.4-9.legacy Version 7.3 : 1.4.2-13.legacy Version 8.0 : 1.4.2-14.legacy Summary : The GNU libtool, which simplifies the use of shared libraries. Description : The libtool package contains the GNU libtool, a set of shell scripts which automatically configure UNIX and UNIX-like architectures to generically build shared libraries. Libtool provides a consistent, portable interface which simplifies the process of using shared libraries. If you are developing programs which will use shared libraries, you should install libtool. - --------------------------------------------------------------------- Update Information: Symlink Vuln in Libtool: The chmod has a race (that access to the temporary directory could be gained after it is created but before it is chmoded) - --------------------------------------------------------------------- Changelog: * Sun Feb 08 2004 Jesse Keating - - 1.4-9.legacy - - Added patch for symlink vuln - - http://www.redhat.com/archives/fedora-legacy-list/2004-February/msg00109.html - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 13e868d1a6e24f185e747b62e11819971c441da5 7.2/updates-testing/SRPMS/libtool-1.4-9.legacy.src.rpm 2732828598e0be48ed39f54e7cc42370c662d9cd 7.2/updates-testing/i386/libtool-1.4-9.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASAdZ4v2HLvE71NURAm/1AJsFdH3cfdgtCoTin30V8023x93iBQCdEL5A 1SfFkpqH5EH6a3GE2HbtnYU= =/TTq -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Mar 5 05:09:05 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 4 Mar 2004 23:09:05 -0600 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <40480437.2050504@bellsouth.net> References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> <40480437.2050504@bellsouth.net> Message-ID: <20040304230905.jqos4404gwwg0k00@mail.ph.utexas.edu> Quoting ral77 : > Troels Arvin wrote: First, welcome Troels! Haven't seen your name for a long time (I used to use your Red Hat PHP RPMS et al). Glad to see your name pop up here. >> On Wed, 03 Mar 2004 02:05:42 -0500, SC Web Services wrote: >> >> >>> So I did a reboot, but for some reason, it continues to boot the second >>> entry, image=/boot/vmlinuz-2.4.20-28.7. Can this have something to do with >>> the name too long issue? >>> >> >> Yes. Remove all occurrences of ".legary" from lilo.conf and re-run "lilo". Please not all this info was in the advisory email released, and in the bugzilla entry for the kernel. > Will this apply to /boot/grub.conf as well after the updated kernel is > installed (remove .legacy from kernel entry) ? No. Grub handles it fine, as stated in the advisory. > I have both rh72 with lilo and a rh8 server using the grub bootloader. > In the past when I downloaded and updated a kernel manually it was rpm > -ivh kernel-2.4.20-*. This way the previous kernel is still available as > backup , would a rpm -Fvh overwrite the kernel-2.4.20-28.7. Yes. Use -ivh, as either -Fvh or -Uvh will remove the previous kernel(s). > thx's > Robert Note in some cases, if you have a "non-standard" lilo configuration, the install will fail to update lilo also. So I personally always run lilo manually after the install to make sure it works and does what I expect before I reboot. Also note: If you are installing an important update (and the kernel would be about the most important one) PLEASE READ THE ENTIRE ADVISORY before doing the install. Both Red Hat and Fedora Legacy put important information in these advisories that may affect your installation. -- Eric Rostetter From rostetter at mail.utexas.edu Fri Mar 5 05:11:20 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 4 Mar 2004 23:11:20 -0600 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities In-Reply-To: <20040304230905.jqos4404gwwg0k00@mail.ph.utexas.edu> References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> <40480437.2050504@bellsouth.net> <20040304230905.jqos4404gwwg0k00@mail.ph.utexas.edu> Message-ID: <20040304231120.zh4ckc8k0g84w84g@mail.ph.utexas.edu> Quoting Eric Rostetter : >>> Yes. Remove all occurrences of ".legary" from lilo.conf and re-run "lilo". > > Please not all this info was in the advisory email released, and in the > bugzilla entry for the kernel. Arg! That should be "Please note" and not "Please not"; stupid small keyboard on the laptop... -- Eric Rostetter From jkeating at j2solutions.net Fri Mar 5 05:19:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 21:19:53 -0800 Subject: Fedora Legacy Test Update Notification: metamail Message-ID: <200403042119.53531.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1305 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1305 2004-03-04 - --------------------------------------------------------------------- Name : metamail Version 7.2 : 2.7-29.7.x.legacy Version 7.3 : 2.7-29.7.x.legacy Summary : A program for handling multimedia mail using the mailcap file. Description : Metamail is a system for handling multimedia mail, using the mailcap file. Metamail reads the mailcap file, which tells Metamail what helper program to call in order to handle a particular type of non-text mail. Note that metamail can also add multimedia support to certain non-mail programs. Metamail should be installed if you need to add multimedia support to mail programs and some other programs, using the mailcap file. - --------------------------------------------------------------------- Update Information: CAN-2004-0104: Multiple format string vulnerabilities in Metamail 2.7 and earlier allow remote attackers to execute arbitrary code. CAN-2004-0105: Multiple buffer overflows in Metamail 2.7 and earlier allow remote attackers to execute arbitrary code. - --------------------------------------------------------------------- Changelog: * Thu Mar 04 2004 Jesse Keating - - 2.7-29.7.x.legacy - - Adding 7.x.legacy for Fedora Legacy - - Adding libtermcap-devel as BuildReq. * Tue Feb 10 2004 Nalin Dahyabhai 2.7-29 - - update source URL - - apply rollup patch from Ulf H?rnhammar to correct some format-string vulnerabilities and buffer overflows (CAN-2004-0104, CAN-2004-0105) - --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 280751e83a0abb7513c9317fd1f6f5eb5ce493f5 7.2/updates-testing/SRPMS/metamail-2.7-29.7.x.legacy.src.rpm a27699e22525617ba294320adaa58838bb7a6535 7.2/updates-testing/i386/metamail-2.7-29.7.x.legacy.i386.rpm 280751e83a0abb7513c9317fd1f6f5eb5ce493f5 7.3/updates-testing/SRPMS/metamail-2.7-29.7.x.legacy.src.rpm a27699e22525617ba294320adaa58838bb7a6535 7.3/updates-testing/i386/metamail-2.7-29.7.x.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. - --------------------------------------------------------------------- - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASA354v2HLvE71NURAj+/AJwM+Ks3k+hq4GTADMzOZiDs0LNc3QCfXDYD reV7+6OZpI2C+lMJmmbTUbU= =zmQY -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Mar 5 05:22:05 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 4 Mar 2004 21:22:05 -0800 Subject: Fedora Legacy Test Update Notification: libtool In-Reply-To: <200403042051.37309.jkeating@j2solutions.net> References: <200403042051.37309.jkeating@j2solutions.net> Message-ID: <200403042122.05077.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 04 March 2004 20:51, Jesse Keating wrote: > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedoralegacy.org/redhat/ > > 13e868d1a6e24f185e747b62e11819971c441da5 > 7.2/updates-testing/SRPMS/libtool-1.4-9.legacy.src.rpm > 2732828598e0be48ed39f54e7cc42370c662d9cd > 7.2/updates-testing/i386/libtool-1.4-9.legacy.i386.rpm Er, didn't get the rest of them... 13e868d1a6e24f185e747b62e11819971c441da5 7.2/updates-testing/SRPMS/libtool-1.4-9.legacy.src.rpm 2732828598e0be48ed39f54e7cc42370c662d9cd 7.2/updates-testing/i386/libtool-1.4-9.legacy.i386.rpm 34fdec6bd3246b51dc2993f7b01194952717f145 7.2/updates-testing/i386/libtool-libs-1.4-9.legacy.i386.rpm 94580dd2607afce8ab7e615b937234977a2345c5 7.3/updates-testing/SRPMS/libtool-1.4.2-13.legacy.src.rpm 705a844d64e11e4c7d13d70e2b7957bbb403a33f 7.3/updates-testing/i386/libtool-1.4.2-13.legacy.i386.rpm 815821f416de6969939854dfa1a9215a93408040 7.3/updates-testing/i386/libtool-libs-1.4.2-13.legacy.i386.rpm 6b9c3e628278b0fc5966dd4f4911ad1edae438ef 8.0/updates-testing/SRPMS/libtool-1.4.2-14.legacy.src.rpm 96d900b337cab85040da9062593a43fee24849c1 8.0/updates-testing/i386/libtool-1.4.2-14.legacy.i386.rpm e39aa95f8a3a643bb9d5ea707b11b65868a2e3b7 8.0/updates-testing/i386/libtool-libs-1.4.2-14.legacy.i386.rpm - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASA594v2HLvE71NURAth8AJ9XRJgPpE85hmpsrVROZ9klbDB0MACfeYF5 Bs0hN6lVvFRhra34uX13ED0= =h9oN -----END PGP SIGNATURE----- From troels at arvin.dk Fri Mar 5 08:11:37 2004 From: troels at arvin.dk (Troels Arvin) Date: Fri, 05 Mar 2004 09:11:37 +0100 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> <40480437.2050504@bellsouth.net> Message-ID: On Thu, 04 Mar 2004 23:38:15 -0500, ral77 wrote: > Will this apply to /boot/grub.conf as well after the updated kernel is > installed (remove .legacy from kernel entry) No, it's a lilo-specific problem. -- Greetings from Troels Arvin, Copenhagen, Denmark From troels at arvin.dk Fri Mar 5 08:26:50 2004 From: troels at arvin.dk (Troels Arvin) Date: Fri, 05 Mar 2004 09:26:50 +0100 Subject: [FLSA-2004:1284] Updated kernel resolves security vulnerabilities References: <200403021057.20696.jkeating@j2solutions.net> <1078278292.18051.25.camel@grendel.myth> <200403021802.26620.jkeating@j2solutions.net> <115438192187.20040303020542@schostpro.com> <40480437.2050504@bellsouth.net> <20040304230905.jqos4404gwwg0k00@mail.ph.utexas.edu> Message-ID: On Thu, 04 Mar 2004 23:09:05 -0600, Eric Rostetter wrote: > First, welcome Troels! Thanks! > Haven't seen your name for a long time (I used to > use your Red Hat PHP RPMS et al). You are poking to my bad conscience ;-/ (My job situation changed, and I didn't have time for further PHP RPM development.) I'm glad that the Fedora Legacy project has become more than talk. I hope I'll be able to contribute somehow. -- Greetings from Troels Arvin, Copenhagen, Denmark From ms-nospam-0306 at arcor.de Fri Mar 5 11:19:45 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 5 Mar 2004 12:19:45 +0100 Subject: Fedora Legacy Test Update Notification: libtool In-Reply-To: <200403042051.37309.jkeating@j2solutions.net> References: <200403042051.37309.jkeating@j2solutions.net> Message-ID: <20040305121945.57fda971.ms-nospam-0306@arcor.de> On Thu, 4 Mar 2004 20:51:37 -0800, Jesse Keating wrote: > - --------------------------------------------------------------------- > Update Information: > > Symlink Vuln in Libtool: > The chmod has a race (that access to the temporary directory could be > gained after it is created but before it is chmoded) > - --------------------------------------------------------------------- As I've pointed out in the bug ticket, Red Hat Linux with default configuration is not vulnerable as it includes a modified libtool which uses mktemp to create the temporary file. It is only vulnerable, when mktemp is erased, breaking libtool's dependency on it. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jpdalbec at ysu.edu Fri Mar 5 15:16:37 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Fri, 05 Mar 2004 10:16:37 -0500 Subject: Mach XFree86 build error - preferred workaround? In-Reply-To: <1078482721.4603.19.camel@otto.amantes> References: <4047A7B6.9030605@ysu.edu> <1078482721.4603.19.camel@otto.amantes> Message-ID: <404899D5.4080904@ysu.edu> Thomas Vander Stichele wrote: > On Thu, 2004-03-04 at 23:03, John Dalbec wrote: > >>Building XFree86 fails with: >> >>egrep: /proc/stat: no such file or directory > > > Can you check if proc gets mounted when you go inside the chroot ? > (I still need a good clean solution for /proc and its contents; mounting > it is bad, and not mounting it is bad too :)) Yes, it gets mounted when I do "mach chroot" and gets unmounted when I leave the chroot. At least, if I unmount it from the chroot I get error messages when I leave the chroot complaining that it's not mounted. Is mounting it during the actual build bad? I don't see why any pre/post-install scripts would be running during the build. > > >>This is the offending section of the .spec file: >> >>%if %{ParallelBuild} >>numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 )) >>[ "$numprocs" = "0" ] && numprocs=1 >>echo "PARALLEL MAKE ENABLED: numprocs=$numprocs" >>%else >>numprocs=1 >>%endif > > > Hm, that looks wonky. I wouldn't use code like this. Well, Red Hat did. This is the .spec from XFree86-4.1.0-50.src.rpm (RHL 7.2 update). I've added a security patch and renamed it to XFree86-4.1.0-51.legacy.src.rpm. Maybe they just never bothered to fix it since it didn't break for them. Actually it looks like numprocs isn't used except for debugging. Instead the following line is preprocessed and inserted into a host.def file if parallel building is enabled. I don't know why they set numprocs to be twice the number of processors. This looks like the number of processes is equal to the number of processors. #define ParallelMakeFlags -j%(getconf _NPROCESSORS_ONLN) > > Here's what mach uses to check number of cpu's: > if not os.environ.has_key('RPM_BUILD_NCPUS'): > nrcpus = > os.popen('/usr/bin/getconf_NPROCESSORS_ONLN').read().rstrip() I think you left out a space before the first _? Unfortunately stracing getconf shows that it just reads this information from /proc/cpuinfo. It looks like getconf returns 1 if it can't access /proc so maybe that's OK. Don't you pass nrcpus to the rpmbuild command? How can I access that from the .spec file? > else: > nrcpus = os.environ['RPM_BUILD_NCPUS'] > > also, I don't see the rest of the spec file, so not sure what you're > trying to achieve there. But, in general, a spec file should just do > make %{_smp_flags} Well, presumably their patch to the X11 sources to allow parallel makes is equally wonky. They added the ParallelBuild flag to be able to turn off parallel building when that patch breaks. > > >>Is there a mach-compatible way to accomplish the same thing? >> >>Should I add /proc/stat as a BuildRequires? The last build failed (building Glide3) because it couldn't find X11/Xlib.h. Should I add XFree86-devel as a BuildRequires or should I try to fix the include paths? > > > Ugh, no :) I don't think that would work, /proc is not a real > filesystem. > > >>I'm trying various workarounds to be able to access /proc/stat, but it doesn't >>help that the build is run as a non-root user. My latest attempt is to add >>"none /proc proc defaults,user 0 0" to /etc/fstab and add the "mount" commands >>below: >> >>%if %{ParallelBuild} >>[ -f /proc/stat ] || mount /proc || mount /proc -o remount || : >>numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 )) >>[ "$numprocs" = "0" ] && numprocs=1 >>echo "PARALLEL MAKE ENABLED: numprocs=$numprocs" >>%else >>numprocs=1 >>%endif > > > that's hacking around the actual problem. Let's try to fix it in a > clean way; no spec file should ever try to mount stuff. > > >>The remount is because /etc/mtab seems to have mount entries for /proc already. >>My workaround appears to have worked. At least the scrolling is much faster >>now. > > > What do you mean, scrolling is much faster ? Sorry, I meant the spinner was spinning much faster. I assume it changes once per line of output? > >>Does mach require a terminal? > > > I'm pretty sure that the terminal inside the chroot is not set > correctly, but I never figured out which I'm supposed to use anyway. If > anyone can tell me what TERM should be set to, feel free. I don't think > it's a big problem though atm. > > >> I tried redirecting stdout and stderr and I still >>got status messages printed to the terminal. > > > You did this from inside the chroot then ? No, I did "nohup mach rebuild XFree86-4.1.0-51.legacy.src.rpm > build.log 2>&1 &" and I still got Mach status messages printed to the terminal (SSH connection). > > >> I've closed my SSH window. Will >>mach wait for TTY output all night instead of building the package? It looks like the answer to this was no. I don't see any stopped processes this morning. Of course it didn't get very far. > > > Can you give me some more background as to what exactly you're doing ? > I'm getting the feeling you're using it differently than what I usually > do. That's not necessarily bad, I'm just not sure if you're using it in > a way that I've actually made to work :) My workstation is in my office. The box where I'm building the packages is in another room with the A/C up too high for comfort. I connect to the box with SSH and issue commands that way. I'll go in and look at the console if I have to but I'm not going to stay there for long. John > > Thomas > > > Dave/Dina : future TV today ! - http://www.davedina.org/ > <-*- thomas (dot) apestaart (dot) org -*-> > Welcome to Hits City, Jeff K - Population: you > <-*- thomas (at) apestaart (dot) org -*-> > URGent, best radio on the net - 24/7 ! - http://urgent.fm/ > > > From thomas at apestaart.org Fri Mar 5 10:18:52 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 05 Mar 2004 11:18:52 +0100 Subject: mach success! In-Reply-To: <40473987.6050502@ysu.edu> References: <40473987.6050502@ysu.edu> Message-ID: <1078481932.4603.10.camel@otto.amantes> Hi, (I didn't realize you guys were also using mach, or trying to, good to know !) On Thu, 2004-03-04 at 15:13, John Dalbec wrote: > I managed to create an rh72u buildroot on rh80 by liberal use of > > # export LD_PRELOAD=/lib/libnss_files.so.2; apt-get -c > /var/lib/mach/states/.../apt.conf -f install ... > > to work around the GLIBC version problems can someone clue me in on what the GLIBC version problems are ? Ie, what are you trying to fix that didn't work out of the box ? (Keep in mind that rh80 is probably the worst platform to be building packages on; the bugs in that rpm version were the worst). > I suppose the following patch would also work (untested): > --- mach-helper.c.orig 2003-12-11 11:55:54.000000000 -0500 > +++ mach-helper.c 2004-03-04 08:58:28.000000000 -0500 > @@ -123,6 +123,7 @@ > /* do not trust user environment */ > char *env[] = { "PATH=/bin:/usr/bin:/usr/sbin", > "HOME=/root", > + "LD_PRELOAD=/lib/libnss_files.so.2", > NULL }; > int retval; > char **arg; > > Is there a mach-specific mailing list I should be writing to? (I've cc:ed > Thomas on this message.) There's mach-devel at lists.sourceforge.net I don't know about the patch. As a general solution it looks wrong, since it's host-specific. But I'd like to know about the discussion before this and the actual problem you're trying to solve here. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Smelled you on my hand for days I can't wash away your scent I'm a dog and you're a bitch <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Fri Mar 5 10:32:01 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 05 Mar 2004 11:32:01 +0100 Subject: Mach XFree86 build error - preferred workaround? In-Reply-To: <4047A7B6.9030605@ysu.edu> References: <4047A7B6.9030605@ysu.edu> Message-ID: <1078482721.4603.19.camel@otto.amantes> On Thu, 2004-03-04 at 23:03, John Dalbec wrote: > Building XFree86 fails with: > > egrep: /proc/stat: no such file or directory Can you check if proc gets mounted when you go inside the chroot ? (I still need a good clean solution for /proc and its contents; mounting it is bad, and not mounting it is bad too :)) > This is the offending section of the .spec file: > > %if %{ParallelBuild} > numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 )) > [ "$numprocs" = "0" ] && numprocs=1 > echo "PARALLEL MAKE ENABLED: numprocs=$numprocs" > %else > numprocs=1 > %endif Hm, that looks wonky. I wouldn't use code like this. Here's what mach uses to check number of cpu's: if not os.environ.has_key('RPM_BUILD_NCPUS'): nrcpus = os.popen('/usr/bin/getconf_NPROCESSORS_ONLN').read().rstrip() else: nrcpus = os.environ['RPM_BUILD_NCPUS'] also, I don't see the rest of the spec file, so not sure what you're trying to achieve there. But, in general, a spec file should just do make %{_smp_flags} > Is there a mach-compatible way to accomplish the same thing? > > Should I add /proc/stat as a BuildRequires? Ugh, no :) I don't think that would work, /proc is not a real filesystem. > I'm trying various workarounds to be able to access /proc/stat, but it doesn't > help that the build is run as a non-root user. My latest attempt is to add > "none /proc proc defaults,user 0 0" to /etc/fstab and add the "mount" commands > below: > > %if %{ParallelBuild} > [ -f /proc/stat ] || mount /proc || mount /proc -o remount || : > numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 )) > [ "$numprocs" = "0" ] && numprocs=1 > echo "PARALLEL MAKE ENABLED: numprocs=$numprocs" > %else > numprocs=1 > %endif that's hacking around the actual problem. Let's try to fix it in a clean way; no spec file should ever try to mount stuff. > The remount is because /etc/mtab seems to have mount entries for /proc already. > My workaround appears to have worked. At least the scrolling is much faster > now. What do you mean, scrolling is much faster ? > Does mach require a terminal? I'm pretty sure that the terminal inside the chroot is not set correctly, but I never figured out which I'm supposed to use anyway. If anyone can tell me what TERM should be set to, feel free. I don't think it's a big problem though atm. > I tried redirecting stdout and stderr and I still > got status messages printed to the terminal. You did this from inside the chroot then ? > I've closed my SSH window. Will > mach wait for TTY output all night instead of building the package? Can you give me some more background as to what exactly you're doing ? I'm getting the feeling you're using it differently than what I usually do. That's not necessarily bad, I'm just not sure if you're using it in a way that I've actually made to work :) Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Welcome to Hits City, Jeff K - Population: you <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From jkeating at j2solutions.net Fri Mar 5 15:58:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 5 Mar 2004 07:58:04 -0800 Subject: Fedora Legacy Test Update Notification: libtool In-Reply-To: <20040305121945.57fda971.ms-nospam-0306@arcor.de> References: <200403042051.37309.jkeating@j2solutions.net> <20040305121945.57fda971.ms-nospam-0306@arcor.de> Message-ID: <200403050758.04598.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 05 March 2004 03:19, Michael Schwendt wrote: > As I've pointed out in the bug ticket, Red Hat Linux with default > configuration is not vulnerable as it includes a modified libtool which > uses mktemp to create the temporary file. It is only vulnerable, when > mktemp is erased, breaking libtool's dependency on it. This will be noted in the official release (when it moves from updates-testing to updates). - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) Mondo DevTeam (www.mondorescue.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASKOM4v2HLvE71NURAjYyAJ9WCSSCjBe5UR5D05dPBvAwS09aggCeIsqo qwvmWLc2nTmKy+IKlQskyVE= =1+rE -----END PGP SIGNATURE----- From john.l.villalovos at intel.com Fri Mar 5 17:44:49 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Fri, 5 Mar 2004 09:44:49 -0800 Subject: YUM for Red Hat 8.0 Message-ID: <50D19C3AC815734C9E19FE4C4F6128A602A569B5@orsmsx403.jf.intel.com> Is there some reason (besides nobody has made one) that there isn't a YUM RPM for Red Hat 8.0? Thanks, John From sheltren at cs.ucsb.edu Fri Mar 5 17:50:42 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 05 Mar 2004 09:50:42 -0800 Subject: YUM for Red Hat 8.0 In-Reply-To: <50D19C3AC815734C9E19FE4C4F6128A602A569B5@orsmsx403.jf.intel.com> References: <50D19C3AC815734C9E19FE4C4F6128A602A569B5@orsmsx403.jf.intel.com> Message-ID: <1078509042.7816.26.camel@forsberg> Not sure why there isn't a 'fedoralegacy' yum package for 8.0 (or why I can't find it?), but you can download one from here: http://linux.duke.edu/projects/yum/download.ptml And then use this in your /etc/yum.conf: [base] name=Red Hat Linux $releasever base baseurl=http://download.fedoralegacy.org/redhat/$releasever/os/$basearch [updates] name=Red Hat Linux $releasever updates baseurl=http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch [legacy-utils] name=Fedora Legacy utilities for Red Hat Linux $releasever baseurl=http://download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch -Jeff On Fri, 2004-03-05 at 09:44, Villalovos, John L wrote: > Is there some reason (besides nobody has made one) that there isn't a > YUM RPM for Red Hat 8.0? > > Thanks, > John > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list From sshoemaker at perfectorder.com Fri Mar 5 17:52:28 2004 From: sshoemaker at perfectorder.com (Seth Shoemaker) Date: Fri, 05 Mar 2004 12:52:28 -0500 Subject: YUM for Red Hat 8.0 In-Reply-To: <50D19C3AC815734C9E19FE4C4F6128A602A569B5@orsmsx403.jf.intel.com> Message-ID: <00bf01c402da$a02ee350$a6b846c6@commnav.com> There is a Yum rpm for Red Hat 8. It is yum-2.0.3-0.fdr.1.rh80.rpm . If you search on google for it, you can find it (or go to a fedora mirror) Seth Shoemaker -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of Villalovos, John L Sent: Friday, March 05, 2004 12:45 PM To: fedora-legacy-list at redhat.com Subject: YUM for Red Hat 8.0 Is there some reason (besides nobody has made one) that there isn't a YUM RPM for Red Hat 8.0? Thanks, John -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004 From john.l.villalovos at intel.com Fri Mar 5 18:00:17 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Fri, 5 Mar 2004 10:00:17 -0800 Subject: YUM for Red Hat 8.0 Message-ID: <50D19C3AC815734C9E19FE4C4F6128A602A569B6@orsmsx403.jf.intel.com> > Is there some reason (besides nobody has made one) that there isn't a > YUM RPM for Red Hat 8.0? Or to be more specific. Why isn't there one in the legacy-utils/ directory in the Fedora Legacy repository? John From john.l.villalovos at intel.com Fri Mar 5 18:02:23 2004 From: john.l.villalovos at intel.com (Villalovos, John L) Date: Fri, 5 Mar 2004 10:02:23 -0800 Subject: YUM for Red Hat 8.0 Message-ID: <50D19C3AC815734C9E19FE4C4F6128A602A569B7@orsmsx403.jf.intel.com> > There is a Yum rpm for Red Hat 8. It is yum-2.0.3-0.fdr.1.rh80.rpm . > If you search on google for it, you can find it (or go to a fedora > mirror) Thanks for the info. Currently I am using the one from: http://linux.duke.edu/projects/yum/download.ptml I was just curious why there wasn't one in the legacy-utils/ directory in the Fedora Legacy repository. John From vuvis at hotmail.com Fri Mar 5 18:18:34 2004 From: vuvis at hotmail.com (v b) Date: Fri, 05 Mar 2004 18:18:34 +0000 Subject: yum not updating kernel on rh7.3? Message-ID: I'm a little confused. I followed the instructions to make use of yum on my rh7.3 server as published at: http://fedoralegacy.org/docs/yum-rh7x.php and it has updated some packages correctly (ie; elm, ethereal), but does not grab the recent kernel update. I've tried various mirrors, but that doesn't seem to help. I'm currently running kernel-2.4.20-28.7. I'm sure it's something simple I'm missing. vb _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/ From sshoemaker at perfectorder.com Fri Mar 5 18:23:33 2004 From: sshoemaker at perfectorder.com (Seth Shoemaker) Date: Fri, 05 Mar 2004 13:23:33 -0500 Subject: yum not updating kernel on rh7.3? In-Reply-To: Message-ID: <00c101c402de$f7e4d1a0$a6b846c6@commnav.com> Does your yum.conf file have a line like this in it? exclude=kernel* If so, take it out and it will upgrade the kernel Seth Shoemaker -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of v b Sent: Friday, March 05, 2004 13:19 PM To: fedora-legacy-list at redhat.com Subject: yum not updating kernel on rh7.3? I'm a little confused. I followed the instructions to make use of yum on my rh7.3 server as published at: http://fedoralegacy.org/docs/yum-rh7x.php and it has updated some packages correctly (ie; elm, ethereal), but does not grab the recent kernel update. I've tried various mirrors, but that doesn't seem to help. I'm currently running kernel-2.4.20-28.7. I'm sure it's something simple I'm missing. vb _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/ -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004 From mitch at cuip.net Fri Mar 5 18:40:12 2004 From: mitch at cuip.net (Mitch Marks) Date: Fri, 5 Mar 2004 12:40:12 -0600 (CST) Subject: yum not updating kernel on rh7.3? In-Reply-To: <00c101c402de$f7e4d1a0$a6b846c6@commnav.com> References: <00c101c402de$f7e4d1a0$a6b846c6@commnav.com> Message-ID: On 7.2 and 7.3 I'm not seeing anything downloaded when I explicitly run yum install kernel or yum update kernel Would these also be affected by the "exclude=kernel*" setting? Thanks, Mitch Marks On Fri, 5 Mar 2004, Seth Shoemaker wrote: > Does your yum.conf file have a line like this in it? > > exclude=kernel* > > If so, take it out and it will upgrade the kernel > > Seth Shoemaker > > -----Original Message----- > From: fedora-legacy-list-admin at redhat.com > [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of v b > Sent: Friday, March 05, 2004 13:19 PM > To: fedora-legacy-list at redhat.com > Subject: yum not updating kernel on rh7.3? > > I'm a little confused. I followed the instructions to make use of yum on > my > rh7.3 server as published at: http://fedoralegacy.org/docs/yum-rh7x.php > and > it has updated some packages correctly (ie; elm, ethereal), but does not > > grab the recent kernel update. I've tried various mirrors, but that > doesn't > seem to help. I'm currently running kernel-2.4.20-28.7. I'm sure it's > something simple I'm missing. > > vb > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar ? get it now! > http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/ > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.605 / Virus Database: 385 - Release Date: 3/1/2004 > > > > -- > fedora-legacy-list mailing list > fedora-legacy-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-legacy-list > -- Mitchell Marks CUIP & WIT Tech Coordinator CUIP: Chicago Public Schools / Univ. of Chicago Internet Project WIT: Web Institute for Teachers http://cuip.net/cuip http://tech.cuip.net/ http://wit.uchicago.edu/wit 5640 S Ellis Ave AAC-045, Univ of Chgo, Chgo IL 60637 Phones: Area 773 (O) 702-6041 (F) 702-8212 (H) 241-7166 (C) 620-6744 Email: Primary address: mitchell at cuip.net Alternate UofC addresses (use especially to report problems with CUIP\WIT mail!): mitchell at cs.uchicago.edu and mmar at midway.uchicago.edu Off-campus (ISP) address: mmarks at pobox.com It was the good people of Vidalia, Georgia, who first took seriously that clause in the Preamble to the U.S. Constitution: In Order to Farm a More Perfect Onion. From sheltren at cs.ucsb.edu Fri Mar 5 19:10:01 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 05 Mar 2004 11:10:01 -0800 Subject: yum not updating kernel on rh7.3? In-Reply-To: References: <00c101c402de$f7e4d1a0$a6b846c6@commnav.com> Message-ID: <1078513800.9028.0.camel@forsberg> Yes, if you have the exclude=kernel* in your yum.conf then it will ignore all packages matching that regex - even if you are explicitly listing that package on the command line. -Jeff On Fri, 2004-03-05 at 10:40, Mitch Marks wrote: > On 7.2 and 7.3 I'm not seeing anything downloaded when I explicitly run > > yum install kernel > > or > > yum update kernel > > Would these also be affected by the "exclude=kernel*" setting? > > Thanks, > > Mitch Marks From vuvis at hotmail.com Fri Mar 5 19:13:11 2004 From: vuvis at hotmail.com (v b) Date: Fri, 05 Mar 2004 19:13:11 +0000 Subject: yum not updating kernel on rh7.3? Message-ID: >From: Seth Shoemaker > >Does your yum.conf file have a line like this in it? > >exclude=kernel* > >If so, take it out and it will upgrade the kernel > >Seth Shoemaker > Yep, it did until I commented it out. Now it performs the update perfectly. Can't believe I didn't see that. Thank you Seth. _________________________________________________________________ One-click access to Hotmail from any Web page ? download MSN Toolbar now! http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/ From ral77 at bellsouth.net Mon Mar 8 00:02:37 2004 From: ral77 at bellsouth.net (ral77) Date: Sun, 07 Mar 2004 19:02:37 -0500 Subject: Security GPG Key question Message-ID: <404BB81D.3060204@bellsouth.net> I have setup the keyserver pgp.mit.edu and gpg --recv-key 0x731002FA . Then set the trust with the interactive gpg --edit-key 0x731002FA . When I run rpm --checksig -v kernel-2.4.20-30.7.legacy.i686.rpm kernel-2.4.20-30.7.legacy.i686.rpm: MD5 sum OK: 8679be0ce60e842d0ceab9e3084cefe8 gpg: WARNING: --honor-http-proxy is a deprecated option. gpg: please use "--keyserver-options honor-http-proxy" instead gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Fri 20 Feb 2004 11:07:04 PM EST using DSA key ID 731002FA gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA My question is about the gpg: WARNING: This key is not certified with a trusted signature! Is this related to the note on the web site at http://www.fedoralegacy.org/about/security.php *"Note:* The GPG key on the Fedora Legacy web site is alone without any signatures. This is what we use to sign packages as there is a bug with RPM when you use a key which has signatures on it. The key on the key-server may gather signatures from time to time, but the key on our site will not reflect this." Yesterday and the monthly LUG meeting one of the security folks walked me through the pgp setup on my rh8 server and I'm referencing the history file and attempting the setup on a rh72 server. I may have a procedure error as this is new for me. Best regards, Robert L. From Freedom_Lover at pobox.com Mon Mar 8 01:01:19 2004 From: Freedom_Lover at pobox.com (Todd) Date: Sun, 7 Mar 2004 20:01:19 -0500 Subject: Security GPG Key question In-Reply-To: <404BB81D.3060204@bellsouth.net> References: <404BB81D.3060204@bellsouth.net> Message-ID: <20040308010119.GH2385@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ral77 wrote: > I have setup the keyserver pgp.mit.edu and gpg --recv-key 0x731002FA . > Then set the trust with the interactive gpg --edit-key 0x731002FA . When > I run rpm --checksig -v kernel-2.4.20-30.7.legacy.i686.rpm > > kernel-2.4.20-30.7.legacy.i686.rpm: > MD5 sum OK: 8679be0ce60e842d0ceab9e3084cefe8 > gpg: WARNING: --honor-http-proxy is a deprecated option. > gpg: please use "--keyserver-options honor-http-proxy" instead > gpg: Warning: using insecure memory! > gpg: please see http://www.gnupg.org/faq.html for more information > gpg: Signature made Fri 20 Feb 2004 11:07:04 PM EST using DSA key ID > 731002FA > gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the > owner. > Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA > My question is about the gpg: WARNING: This key is not certified with a > trusted signature! > > Is this related to the note on the web site at > http://www.fedoralegacy.org/about/security.php No. This warning is because there are no signatures on the key from other keys you trust, either your own key or some someone else that you have trust in to sign keys. > Yesterday and the monthly LUG meeting one of the security folks > walked me through the pgp setup on my rh8 server and I'm referencing > the history file and attempting the setup on a rh72 server. I may > have a procedure error as this is new for me. One thing that will be different between rh7x and rh80 and above is that the gpg key storage was moved fron the user's gpg keyring to the rpm database. You seem to know that though based on importing the key via gpg instead of rpm. If you were checking signatures on rh80 or above, you'd use rpm --import instead of gpg --recv-keys This is related to the note on the site you referenced above. If you try to import a key using rpm and that key has other signatures on it, rpm can store the key under the wrong keyid and mess up verifications. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90952 for details on that annoying bug (that isn't even fixed in FC1, showing the priority the gpg code seems to get in the rpm dev cycle). - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== Every normal man must be tempted at times to spit upon his hands, hoist the black flag and begin slitting throats. -- H.L. Mencken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFAS8Xeuv+09NZUB1oRAnBXAKDRexdQOBLvPULq/RFRwjdEAUQIlACdFsqT 7Y+VV1Ihl0pdk0s9aI7O+SI= =77we -----END PGP SIGNATURE----- From sshoemaker at perfectorder.com Mon Mar 8 16:34:47 2004 From: sshoemaker at perfectorder.com (Seth Shoemaker) Date: Mon, 08 Mar 2004 11:34:47 -0500 Subject: Yum update problems - slightly maybe off topic Message-ID: <001601c4052b$4512a940$a6b846c6@commnav.com> It seems that when yum updates certain programs (such as mysql) that it stops them, to upgrade them, but never starts them back up. Is this a configuration problem, or just something that I need to watch for in the future? The main problem I have with this is that if I set my machines to auto update using yum and it stops programs such as mysql that I need to have running all of the time, this is a bad thing! Thanks. Seth Shoemaker --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 From wipe_out at users.sourceforge.net Mon Mar 8 16:39:44 2004 From: wipe_out at users.sourceforge.net (WipeOut) Date: Mon, 08 Mar 2004 16:39:44 +0000 Subject: Yum update problems - slightly maybe off topic In-Reply-To: <001601c4052b$4512a940$a6b846c6@commnav.com> References: <001601c4052b$4512a940$a6b846c6@commnav.com> Message-ID: <404CA1D0.1050903@users.sourceforge.net> Seth Shoemaker wrote: >It seems that when yum updates certain programs (such as mysql) that it >stops them, to upgrade them, but never starts them back up. Is this a >configuration problem, or just something that I need to watch for in the >future? The main problem I have with this is that if I set my machines >to auto update using yum and it stops programs such as mysql that I need >to have running all of the time, this is a bad thing! > >Thanks. > >Seth Shoemaker > > > Personally I wouldn't do auto updating on servers, I would rather do it manually so I could make sure all was well and if not downgrade back to a previous version.. Auto updating on workstations is fine.. Just my opinion.. Later.. From security at concealed.org Mon Mar 8 16:39:56 2004 From: security at concealed.org (Jon Kadilak) Date: Mon, 8 Mar 2004 11:39:56 -0500 Subject: Fedora Legacy GPG Key Message-ID: Hello All, I seem to be having some problems installing packages from the fedora legacy project. For example, I'll run yum check-update and see a package like slocate that could be updated. So, from there I'll run yum update slocate. It then pops up with this error message: warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 731002fa Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/redhat-updates/packages/slocate-2.7-1.8.0.legacy.i386.rpm Error: You may want to run yum clean or remove the file: /var/cache/yum/redhat-updates/packages/slocate-2.7-1.8.0.legacy.i386.rpm Error: You may also check that you have the correct GPG keys installed The strange thing is, I've imported the proper key as evidenced when I run gpg --list-keys: pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) sub 2048g/D12E351D 2004-01-19 Does anyone have any idea why I am unable to verify these packages? Any suggestions would be appreciated. Thanks, -jpk From Freedom_Lover at pobox.com Mon Mar 8 16:50:29 2004 From: Freedom_Lover at pobox.com (Todd) Date: Mon, 8 Mar 2004 11:50:29 -0500 Subject: Fedora Legacy GPG Key In-Reply-To: References: Message-ID: <20040308165029.GM2385@psilocybe.teonanacatl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Kadilak wrote: > I seem to be having some problems installing packages from the > fedora legacy project. For example, I'll run yum check-update and > see a package like slocate that could be updated. So, from there > I'll run yum update slocate. It then pops up with this error > message: > > warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 731002fa > Error: Could not find the GPG Key necessary to validate pkg > /var/cache/yum/redhat-updates/packages/slocate-2.7-1.8.0.legacy.i386.rpm > Error: You may want to run yum clean or remove the file: > /var/cache/yum/redhat-updates/packages/slocate-2.7-1.8.0.legacy.i386.rpm > Error: You may also check that you have the correct GPG keys installed > > The strange thing is, I've imported the proper key as evidenced when > I run gpg --list-keys: > > pub 1024D/731002FA 2004-01-19 Fedora Legacy (http://www.fedoralegacy.org) > > sub 2048g/D12E351D 2004-01-19 > > Does anyone have any idea why I am unable to verify these packages? > Any suggestions would be appreciated. With rh80 and above (or more accurately rpm 4.1 and above, I believe), you need to import the GPG keys into the rpm database, not the gpg keyring. Use rpm --import to do this. - -- Todd OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp ====================================================================== When buying and selling are controlled by legislation, the first things to be bought and sold are legislators. -- P.J. O'Rourke, Parliament of Whores -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl. iD8DBQFATKRVuv+09NZUB1oRAnouAJ0URd1f4BGgFsg/x1Chakb09z72BACgosUI 1XnAAem73fdxfrx+ngYvGZ0= =R/Hh -----END PGP SIGNATURE----- From sheltren at cs.ucsb.edu Mon Mar 8 16:53:22 2004 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 08 Mar 2004 08:53:22 -0800 Subject: Yum update problems - slightly maybe off topic In-Reply-To: <001601c4052b$4512a940$a6b846c6@commnav.com> References: <001601c4052b$4512a940$a6b846c6@commnav.com> Message-ID: <1078764802.23578.1.camel@forsberg> AFAIK this is built into the RPM spec file (ie. pre and post commands) so that the daemon gets stopped, then upgraded, then started. I have never experienced the problem you are describing with yum... Could your mysqld config files be screwed up? If you do a 'service mysql start' after it has been upgraded, does it start OK? -Jeff On Mon, 2004-03-08 at 08:34, Seth Shoemaker wrote: > It seems that when yum updates certain programs (such as mysql) that it > stops them, to upgrade them, but never starts them back up. Is this a > configuration problem, or just something that I need to watch for in the > future? The main problem I have with this is that if I set my machines > to auto update using yum and it stops programs such as mysql that I need > to have running all of the time, this is a bad thing! > > Thanks. > > Seth Shoemaker From sshoemaker at perfectorder.com Mon Mar 8 17:23:51 2004 From: sshoemaker at perfectorder.com (Seth Shoemaker) Date: Mon, 08 Mar 2004 12:23:51 -0500 Subject: Yum update problems - slightly maybe off topic In-Reply-To: <1078764802.23578.1.camel@forsberg> Message-ID: <001701c40532$20079cd0$a6b846c6@commnav.com> Yes, its starts up fine manually. I guess auto update is not a good idea for critical machines. I was just hoping that it was a bug possibly that someone else was running into. Seth Shoemaker -----Original Message----- From: fedora-legacy-list-admin at redhat.com [mailto:fedora-legacy-list-admin at redhat.com] On Behalf Of Jeff Sheltren Sent: Monday, March 08, 2004 11:53 AM To: fedora-legacy-list at redhat.com Subject: Re: Yum update problems - slightly maybe off topic AFAIK this is built into the RPM spec file (ie. pre and post commands) so that the daemon gets stopped, then upgraded, then started. I have never experienced the problem you are describing with yum... Could your mysqld config files be screwed up? If you do a 'service mysql start' after it has been upgraded, does it start OK? -Jeff On Mon, 2004-03-08 at 08:34, Seth Shoemaker wrote: > It seems that when yum updates certain programs (such as mysql) that it > stops them, to upgrade them, but never starts them back up. Is this a > configuration problem, or just something that I need to watch for in the > future? The main problem I have with this is that if I set my machines > to auto update using yum and it stops programs such as mysql that I need > to have running all of the time, this is a bad thing! > > Thanks. > > Seth Shoemaker -- fedora-legacy-list mailing list fedora-legacy-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-legacy-list --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 From skvidal at phy.duke.edu Mon Mar 8 17:53:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Mar 2004 12:53:35 -0500 Subject: Yum update problems - slightly maybe off topic In-Reply-To: <001601c4052b$4512a940$a6b846c6@commnav.com> References: <001601c4052b$4512a940$a6b846c6@commnav.com> Message-ID: <1078768415.13370.14.camel@opus> On Mon, 2004-03-08 at 11:34, Seth Shoemaker wrote: > It seems that when yum updates certain programs (such as mysql) that it > stops them, to upgrade them, but never starts them back up. Is this a > configuration problem, or just something that I need to watch for in the > future? The main problem I have with this is that if I set my machines > to auto update using yum and it stops programs such as mysql that I need > to have running all of the time, this is a bad thing! > I've had the same problems - but it's not anything in yum. sometimes the %post in the mysql package doesn't properly restart the daemon. If you do the same from rpm from the command line you'll see the exact behavior - yum doesn't change it. -sv From rostetter at mail.utexas.edu Mon Mar 8 18:59:55 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 8 Mar 2004 12:59:55 -0600 Subject: Yum update problems - slightly maybe off topic In-Reply-To: <001601c4052b$4512a940$a6b846c6@commnav.com> References: <001601c4052b$4512a940$a6b846c6@commnav.com> Message-ID: <20040308125955.hdwkswcwcccc4w88@mail.ph.utexas.edu> Quoting Seth Shoemaker : > future? The main problem I have with this is that if I set my machines > to auto update using yum and it stops programs such as mysql that I need > to have running all of the time, this is a bad thing! Never, ever set servers or other important (must be up and running) machines to use unattended auto-upgrade features of yum, apt, up2date, or anything else. You will only cause yourself pain and suffering. You can have it run on a regular basis to download and advise you that updates are needed, but you should never have it do unattended updates if the machine/service uptime is important. It may be fine to do unattended auto-updates on your desktop or laptop, but not on your critical servers... > Thanks. > > Seth Shoemaker -- Eric Rostetter From rostetter at mail.utexas.edu Mon Mar 8 19:06:51 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Mon, 8 Mar 2004 13:06:51 -0600 Subject: Fedora Legacy GPG Key In-Reply-To: References: Message-ID: <20040308130651.0joogo8880c0swog@mail.ph.utexas.edu> Quoting Jon Kadilak : > The strange thing is, I've imported the proper key as evidenced when I run > gpg --list-keys: For RH 8.0 you need to do an "rpm --import" instead of a "gpg --import". This is now covered better on the FL about/security.php web page. -- Eric Rostetter From jpdalbec at ysu.edu Mon Mar 8 19:37:19 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 08 Mar 2004 14:37:19 -0500 Subject: participate Message-ID: <404CCB6F.2040003@ysu.edu> > Build a source RPM, create its md5sum and "gpg --clearsign" it, then upload it > to a public server. Update the Bugzilla entry with the URL of the source RPM > and inform the mailing list about your work. We decided to use "sha1sum"s for the "gpg --clearsign"ed Bugzilla comments, didn't we? If you're signing the RPM, you would use "rpm --addsign", right? Thanks, John From jpdalbec at ysu.edu Mon Mar 8 19:58:37 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Mon, 08 Mar 2004 14:58:37 -0500 Subject: mach needs "redundant" BuildRequires Message-ID: <404CD06D.4080004@ysu.edu> According to http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires, neither gcc-c++ nor python should be listed as a BuildRequires:. However, the default mach configuration does not install either package on Red Hat 7.2 unless it is listed as a BuildRequires:. I'm trying to build XFree86. Should I add gcc-c++ as a BuildRequires or change my /etc/mach/dist file? Thanks, John From stefan at eijk.nu Mon Mar 8 20:22:36 2004 From: stefan at eijk.nu (Stefan van der Eijk) Date: Mon, 08 Mar 2004 21:22:36 +0100 Subject: mach needs "redundant" BuildRequires In-Reply-To: <404CD06D.4080004@ysu.edu> References: <404CD06D.4080004@ysu.edu> Message-ID: <404CD60C.8080809@eijk.nu> John Dalbec wrote: > According to http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires, > neither gcc-c++ nor python should be listed as a BuildRequires:. > However, the default mach configuration does not install either > package on Red Hat 7.2 unless it is listed as a BuildRequires:. I'm > trying to build XFree86. Should I add gcc-c++ as a BuildRequires or > change my /etc/mach/dist file? > Thanks, > John This sounds so familiar to what I've been doing as a contributor to Mandrake's cooker distro for the last few years. I have a auto rebuilder, calles SlBd. It uses urpmi instead of apt: http://qa.mandrakesoft.com/twiki/bin/view/Main/MandrakeLinux?topic=SlBd I've been advocating getting the right BuildRequires into the src.rpm packages: http://qa.mandrakesoft.com/twiki/bin/view/Main/BuildRequires Due to the fact that -devel packages have no *automatic* dependencies added to them, there is no significant dependency structure in them. This makes getting the right BuildRequires for the packages nearly impossible. This issue and the solution Mandrake chose to implement are documented here: http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies Esspecially with the RpmDevelDependencies I think all distributions would benefit from this, perhaps we can try to make it part of a cross-distro rpm naming standard. Feel free to comment. with kind regards, Stefan van der Eijk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3403 bytes Desc: S/MIME Cryptographic Signature URL: From ms-nospam-0306 at arcor.de Tue Mar 9 00:30:42 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 9 Mar 2004 01:30:42 +0100 Subject: mach needs "redundant" BuildRequires In-Reply-To: <404CD06D.4080004@ysu.edu> References: <404CD06D.4080004@ysu.edu> Message-ID: <20040309013042.192aa564.ms-nospam-0306@arcor.de> On Mon, 08 Mar 2004 14:58:37 -0500, John Dalbec wrote: > According to http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires, neither > gcc-c++ nor python should be listed as a BuildRequires:. However, the default > mach configuration does not install either package on Red Hat 7.2 unless it is > listed as a BuildRequires:. I'm trying to build XFree86. Should I add gcc-c++ > as a BuildRequires or change my /etc/mach/dist file? Yes, in my opinion, yes. C++ support is not pulled in by the redhat-72-i386-updates "build" definition. Unlike the corresponding fedora.us build root definitions which include fedora-rpmdevtools and adds a few more requirements. -- From jpdalbec at ysu.edu Tue Mar 9 13:54:42 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Tue, 09 Mar 2004 08:54:42 -0500 Subject: RH 7.2 XFree86 problems Message-ID: <404DCCA2.6090609@ysu.edu> I'm trying to build the Red Hat 7.2 XFree86 packages under mach. I can get them to build, but I have to disable Glide3 and tdfx support (and Red Hat's fast/parallel build patches). Should I upload these packages given that some functionality has been removed? Should I try building 4.2.1 (from Red Hat 7.3/8.0) instead? Thanks, John From Axel.Thimm at ATrpms.net Tue Mar 9 14:45:25 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 9 Mar 2004 15:45:25 +0100 Subject: Automatic BuildRequires; platform independent specfiles (was: mach needs "redundant" BuildRequires) In-Reply-To: <404CD60C.8080809@eijk.nu> References: <404CD06D.4080004@ysu.edu> <404CD60C.8080809@eijk.nu> Message-ID: <20040309144525.GG21956@neu.nirvana> On Mon, Mar 08, 2004 at 09:22:36PM +0100, Stefan van der Eijk wrote: > I've been advocating getting the right BuildRequires into the src.rpm > packages: > http://qa.mandrakesoft.com/twiki/bin/view/Main/BuildRequires > > Due to the fact that -devel packages have no *automatic* dependencies > added to them, there is no significant dependency structure in them. > This makes getting the right BuildRequires for the packages nearly > impossible. This issue and the solution Mandrake chose to implement are > documented here: > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies This is very interesting stuff, especially deriving the recursive -devel dependencies that way. Is there a tool which can be used right away to generate these Provides/Requires hooks? Does the Mandrake rpm carry such patches? > Esspecially with the RpmDevelDependencies I think all distributions > would benefit from this, perhaps we can try to make it part of a > cross-distro rpm naming standard. Yes! :) But this is probably the wrong list to address these issues. There is an rpm-devel list (http://rpm-devel.colug.net/, Cced) where embedding of these Provides/Requires hooks could be discussed. There is also a packaging list (http://www.freestandards.org/cgi-bin/mailman/listinfo/packaging), which would look appropriate for such a discussion, but it looks quite silent in the last year. As for the common naming issue, you will get into serious trouble convincing all parties. It has been tough to discuss this within the Red Hat community, so adding Mandrake and SuSE will certainly not make it easier ;) Unless the external name is independent of the internal Provides/Requires hooks, so that Red Hat can continue calling zlib{-devel} that way etc., and some small monolithic packages can remain monolithic and need not be split into devel/lib etc. In this case you will probably be able to choose the internal naming convention yourself, nobody would object. It seems that your scheme is indeed independent of the external names and splitting of sub-packages, isn't it? Writing cross-distro specfiles! I am looking forward to that day! :) -- 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 ms-nospam-0306 at arcor.de Tue Mar 9 14:59:17 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 9 Mar 2004 15:59:17 +0100 Subject: mach needs "redundant" BuildRequires In-Reply-To: <404CD60C.8080809@eijk.nu> References: <404CD06D.4080004@ysu.edu> <404CD60C.8080809@eijk.nu> Message-ID: <20040309155917.02cfdf2d.ms-nospam-0306@arcor.de> On Mon, 08 Mar 2004 21:22:36 +0100, Stefan van der Eijk wrote: > Due to the fact that -devel packages have no *automatic* dependencies > added to them, there is no significant dependency structure in them. > This makes getting the right BuildRequires for the packages nearly > impossible. This issue and the solution Mandrake chose to implement are > documented here: > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies Fetching dependencies from pkgconfig templates is missing on that page. Pkgconfig has an own dependency chain. When a -devel package gets installed and contains support for pkgconfig, pkg-config --list-all should not fail due to a broken chain of dependencies. The package should require every [-devel] package needed to complete the dependencies listed in the pkgconfig file. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thomas at apestaart.org Tue Mar 9 12:30:02 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 09 Mar 2004 13:30:02 +0100 Subject: mach needs "redundant" BuildRequires In-Reply-To: <404CD06D.4080004@ysu.edu> References: <404CD06D.4080004@ysu.edu> Message-ID: <1078835402.13521.15.camel@otto.amantes> Hi John, please subscribe to the mach-devel list as well, so people are kept informed. On Mon, 2004-03-08 at 20:58, John Dalbec wrote: > According to http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires, neither > gcc-c++ nor python should be listed as a BuildRequires:. I know about gcc-c++ being on that page (and I still disagree, but that's personal opinion). I just now noticed that python got added, and don't understand why. I'll ask. > However, the default > mach configuration does not install either package on Red Hat 7.2 unless it is > listed as a BuildRequires:. Yep. I'd prefer to keep gcc-c++ out of there, but it could be added for fedora.us only. > I'm trying to build XFree86. Should I add gcc-c++ > as a BuildRequires or change my /etc/mach/dist file? If you're building it for fedora.us explicitly, I guess you should add it to your /etc/mach/dist. If it were me, I'd be adding it to BuildRequires: though. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> And I'm not the drowning man you think I flail my arms and refuse to sink <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From michal at harddata.com Tue Mar 9 18:19:32 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 9 Mar 2004 11:19:32 -0700 Subject: RH 7.2 XFree86 problems In-Reply-To: <404DCCA2.6090609@ysu.edu>; from jpdalbec@ysu.edu on Tue, Mar 09, 2004 at 08:54:42AM -0500 References: <404DCCA2.6090609@ysu.edu> Message-ID: <20040309111932.B26262@mail.harddata.com> On Tue, Mar 09, 2004 at 08:54:42AM -0500, John Dalbec wrote: > I'm trying to build the Red Hat 7.2 XFree86 packages under mach. .... > Should I try building 4.2.1 (from Red Hat > 7.3/8.0) instead? RH 7.2 will work with XFree86 rebuild from 7.3/8.0 srpms. I had to do such thing in the past due to hardware and other considerations. But you will have to add/upgrade some other packages as well. TTF support comes to mind. Michal From ms-nospam-0306 at arcor.de Tue Mar 9 19:22:07 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 9 Mar 2004 20:22:07 +0100 Subject: mach needs "redundant" BuildRequires In-Reply-To: <1078835402.13521.15.camel@otto.amantes> References: <404CD06D.4080004@ysu.edu> <1078835402.13521.15.camel@otto.amantes> Message-ID: <20040309202207.188486f8.ms-nospam-0306@arcor.de> On Tue, 09 Mar 2004 13:30:02 +0100, Thomas Vander Stichele wrote: > On Mon, 2004-03-08 at 20:58, John Dalbec wrote: > > According to http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires, neither > > gcc-c++ nor python should be listed as a BuildRequires:. > > I know about gcc-c++ being on that page (and I still disagree, but > that's personal opinion). I just now noticed that python got added, and > don't understand why. I'll ask. Cut'n'paste error. Doesn't really matter. The fedora-rpmdevtools package pulls in python as an essential component for a build environment. And hence you need not list python as BuildRequires when building for fedora.us. When building such a package for Fedora Core, though, listing python as a buildreq can be useful, because the minimal build environment for Fedora Core is not defined anywhere beyond the "Development" components group, which is different from mach's definition. -- From stefan at eijk.nu Tue Mar 9 22:32:15 2004 From: stefan at eijk.nu (Stefan van der Eijk) Date: Tue, 09 Mar 2004 23:32:15 +0100 Subject: Automatic BuildRequires; platform independent specfiles In-Reply-To: <20040309144525.GG21956@neu.nirvana> References: <404CD06D.4080004@ysu.edu> <404CD60C.8080809@eijk.nu> <20040309144525.GG21956@neu.nirvana> Message-ID: <404E45EF.9050606@eijk.nu> Axel Thimm wrote: >On Mon, Mar 08, 2004 at 09:22:36PM +0100, Stefan van der Eijk wrote: > > >>I've been advocating getting the right BuildRequires into the src.rpm >>packages: >> http://qa.mandrakesoft.com/twiki/bin/view/Main/BuildRequires >> >>Due to the fact that -devel packages have no *automatic* dependencies >>added to them, there is no significant dependency structure in them. >>This makes getting the right BuildRequires for the packages nearly >>impossible. This issue and the solution Mandrake chose to implement are >>documented here: >> http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies >> >> > >This is very interesting stuff, especially deriving the recursive >-devel dependencies that way. > >Is there a tool which can be used right away to generate these >Provides/Requires hooks? Does the Mandrake rpm carry such patches? > > Yes. Mandrake implemented option 3. The exact code from the Mandrake find-provides and find-requires are on the page (Implementation examples), with the version number of the mandrake rpm package it was taken from. It may have changed in later releases of the rpm package. Here's and example on how the dependencies are implemented on the package: # rpm -qpR libpng3-devel-1.2.5-10mdk.alpha.rpm | sort -u bash *devel(libm(64bit)) devel(libz(64bit)) * libpng3 = 2:1.2.5-10mdk pkgconfig rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 zlib-devel # rpm -qp --provides libpng3-devel-1.2.5-10mdk.alpha.rpm | sort -u *devel(libpng(64bit)) devel(libpng12(64bit)) *libpng-devel = 2:1.2.5-10mdk libpng3-devel = 2:1.2.5-10mdk png-devel = 2:1.2.5-10mdk As you can see the "zlib-devel" requires is redundant, since "devel(libz(64bit))" already pulls it in. The things we learned at Mandrakesoft when implementing this: - Do it quickly, put a team on it to rebuild all the packages affected against the new find-provides and find-requires scripts. If you don't do it quickly the distro will be broken, as packages will be asking for dependencies that aren't provided yet. At Mandrake we had quite some resistance against the new scheme, users that didn't understand what it brought and only saw the downside during the transition became quite vocal. - Choose the same naming scheme as Mandrake "devel(libname)" for 32bit libs, "devel(libname(64bit))" for 64bit systems. At Mandrake we first used "libname.so" like dependencies, but some of these were already being provided by some packages. The libdb3.3-devel package being the perfect example on where it went wrong. Mandrake ended up making the transition twice :-( >>Esspecially with the RpmDevelDependencies I think all distributions >>would benefit from this, perhaps we can try to make it part of a >>cross-distro rpm naming standard. >> >> > >Yes! :) > >But this is probably the wrong list to address these issues. There is >an rpm-devel list (http://rpm-devel.colug.net/, Cced) where embedding >of these Provides/Requires hooks could be discussed. > I've tried on the rpm list noted on rpm.org, but I've had little / no response. >There is also a >packaging list (http://www.freestandards.org/cgi-bin/mailman/listinfo/packaging), >which would look appropriate for such a discussion, but it looks quite >silent in the last year. > >As for the common naming issue, you will get into serious trouble >convincing all parties. > I'm expecting some resistance against change. This is always the case. :-/ >It has been tough to discuss this within the >Red Hat community, so adding Mandrake and SuSE will certainly not make >it easier ;) > >Unless the external name is independent of the internal >Provides/Requires hooks, so that Red Hat can continue calling >zlib{-devel} that way etc., and some small monolithic packages can >remain monolithic and need not be split into devel/lib etc. > > For this scheme the external name can remain unchanged. What I'm actually aiming on is to make more of a distros dependencies consist out of automatically generated dependencies (conforming to a cross-distro naming standard) so that the external names aren't loose their importance. What's really important is the *capability* a package provides or requires, the external name is of less importance. >In this case you will probably be able to choose the internal naming >convention yourself, nobody would object. It seems that your scheme is >indeed independent of the external names and splitting of >sub-packages, isn't it? > > Indeed. This was my objective, to make it completely independant from existing naming, and completely based on a capability a package provides and / or requires. >Writing cross-distro specfiles! I am looking forward to that day! :) > > This day isn't that far away. I think many people are looking forward to it. I'm also involved with plf (plf.zarb.org) and the plf would also love to make fedora packages. Issue at the moment is that the lack of standardisation is making this difficult. regards, Stefan van der Eijk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3403 bytes Desc: S/MIME Cryptographic Signature URL: From stefan at eijk.nu Wed Mar 10 21:03:07 2004 From: stefan at eijk.nu (Stefan van der Eijk) Date: Wed, 10 Mar 2004 22:03:07 +0100 Subject: mach needs "redundant" BuildRequires In-Reply-To: <20040309155917.02cfdf2d.ms-nospam-0306@arcor.de> References: <404CD06D.4080004@ysu.edu> <404CD60C.8080809@eijk.nu> <20040309155917.02cfdf2d.ms-nospam-0306@arcor.de> Message-ID: <404F828B.4000709@eijk.nu> Michael Schwendt wrote: >On Mon, 08 Mar 2004 21:22:36 +0100, Stefan van der Eijk wrote: > > > >>Due to the fact that -devel packages have no *automatic* dependencies >>added to them, there is no significant dependency structure in them. >>This makes getting the right BuildRequires for the packages nearly >>impossible. This issue and the solution Mandrake chose to implement are >>documented here: >> http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies >> >> > >Fetching dependencies from pkgconfig templates is missing on that >page. Pkgconfig has an own dependency chain. When a -devel package gets >installed and contains support for pkgconfig, > > pkg-config --list-all > >should not fail due to a broken chain of dependencies. The package should >require every [-devel] package needed to complete the dependencies listed >in the pkgconfig file. > I agree with you. But don't you agree that the functionality that the devel() depedencies provides is already a lot better than letting the packager decide what the dependencies will be (by specifying them in the .spec file). Of course a packager can still specify them if he wants to. Perhaps we can explore the possibilities that a pkg-config related dependency scheme can bring, perhaps complementing the devel() dependencies. The trick will be to find a way to find the pkgconfig capabilites a package Requires *and* what pkgconfig capabilites a package Provides. regards, Stefan van der Eijk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3403 bytes Desc: S/MIME Cryptographic Signature URL: From dkgip at verizon.net Wed Mar 10 22:49:06 2004 From: dkgip at verizon.net (Derek Gipson) Date: Wed, 10 Mar 2004 14:49:06 -0800 Subject: RH9 disable up2date after April Message-ID: <20040310224906.GA3866@localhost.localdomain> When Shrike reaches the end of support should up2date be disabled? If so what would be the best way to do this. I think 'rpm -e up2date' would be sort of aggressive. From rostetter at mail.utexas.edu Wed Mar 10 22:58:29 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Wed, 10 Mar 2004 16:58:29 -0600 Subject: RH9 disable up2date after April In-Reply-To: <20040310224906.GA3866@localhost.localdomain> References: <20040310224906.GA3866@localhost.localdomain> Message-ID: <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> Quoting Derek Gipson : > When Shrike reaches the end of support should > up2date be disabled? If so what would be the best > way to do this. I think 'rpm -e up2date' would be > sort of aggressive. I believe you can reconfigure up2date to point to, for example, the Fedora Legacy RH 9 repositories to carry on the work... Not sure how that effects the little gui applets that come with it though... -- Eric Rostetter From jkeating at j2solutions.net Wed Mar 10 23:07:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 10 Mar 2004 15:07:36 -0800 Subject: RH9 disable up2date after April In-Reply-To: <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> References: <20040310224906.GA3866@localhost.localdomain> <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> Message-ID: <200403101507.41055.jkeating@j2solutions.net> On Wednesday 10 March 2004 14:58, Eric Rostetter wrote: > I believe you can reconfigure up2date to point to, for example, the > Fedora Legacy RH 9 repositories to carry on the work... Not sure > how that effects the little gui applets that come with it though... Red Hat 9's up2date is not cable of conversing with anything but RHN servers. Fedora Legacy does not run an RHN server, therefor Red Hat Linux 9's up2date cannot be used with Fedora Legacy. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From kelson at speed.net Wed Mar 10 23:29:25 2004 From: kelson at speed.net (Kelson Vibber) Date: Wed, 10 Mar 2004 15:29:25 -0800 Subject: RH9 disable up2date after April In-Reply-To: <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> References: <20040310224906.GA3866@localhost.localdomain> <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> Message-ID: <6.0.1.1.0.20040310152447.03203000@mail.speed.net> At 02:58 PM 3/10/2004, Eric Rostetter wrote: >I believe you can reconfigure up2date to point to, for example, the Fedora >Legacy RH 9 repositories to carry on the work... IIRC up2date was not able to access yum and apt repositories until the version that shipped with Fedora Core 1. It may be worth taking the FC1 SRPM and rebuilding it RH9. >Not sure how that effects the little gui applets that come with it though... The ones in FC1 just pick up the setting from your up2date config. Kelson Vibber SpeedGate Communications From mic at npgx.com.au Thu Mar 11 00:20:13 2004 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 11 Mar 2004 10:20:13 +1000 Subject: RH9 disable up2date after April In-Reply-To: <6.0.1.1.0.20040310152447.03203000@mail.speed.net> References: <20040310224906.GA3866@localhost.localdomain> <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> <6.0.1.1.0.20040310152447.03203000@mail.speed.net> Message-ID: <20040311001835.M49613@npgx.com.au> Hi Eric, > At 02:58 PM 3/10/2004, Eric Rostetter wrote: > >I believe you can reconfigure up2date to point to, for example, the Fedora > >Legacy RH 9 repositories to carry on the work... > > IIRC up2date was not able to access yum and apt repositories until > the version that shipped with Fedora Core 1. It may be worth taking > the FC1 SRPM and rebuilding it RH9. > > >Not sure how that effects the little gui applets that come with it though.. From kelson at speed.net Thu Mar 11 00:58:44 2004 From: kelson at speed.net (Kelson Vibber) Date: Wed, 10 Mar 2004 16:58:44 -0800 Subject: RH9 disable up2date after April In-Reply-To: <6.0.1.1.0.20040310152447.03203000@mail.speed.net> References: <20040310224906.GA3866@localhost.localdomain> <20040310165829.jql14wg8wkgg4048@mail.ph.utexas.edu> <6.0.1.1.0.20040310152447.03203000@mail.speed.net> Message-ID: <6.0.1.1.0.20040310165811.0320ae40@mail.speed.net> At 03:29 PM 3/10/2004, I wrote: >It may be worth taking the FC1 SRPM and rebuilding it RH9. er... *on* RH9. Darn cut-n-paste. Kelson Vibber SpeedGate Communications From jonny.strom at netikka.fi Thu Mar 11 09:04:44 2004 From: jonny.strom at netikka.fi (Johnny Strom) Date: Thu, 11 Mar 2004 11:04:44 +0200 Subject: QA weekend. Message-ID: <40502BAC.9010500@netikka.fi> Hello I want to propose that we do an QA weekend before the end of the updates for Redhat 9 where we patch/test and give feedback to all the security related open bugs that are pending for the old Redhat releases. We could do the same in the future get rid of pending updates that have been queuing up. This would be good to do so that we don't have any pending updates when the support for Redhat 9 is over. We could perhaps start on a friday so that people can do QA from work if they have the possibility to do so. Any taughts about this. Johnny From ivan at geosci.usyd.edu.au Thu Mar 11 12:33:49 2004 From: ivan at geosci.usyd.edu.au (Ivan Teliatnikov) Date: Thu, 11 Mar 2004 23:33:49 +1100 (EST) Subject: missing /initrd-2.4.20-30.7.legacy.img after kernel upgrade Message-ID: I have upgraded a number of RH8 and RH7.3 boxes (all running from IDE disks) to a new kernel using apt-get without any hustle. So far no problems. I wanted to start upgrading servers running of SCSI disks, but I noticed an unexpected feature. Namely, file /initrd-2.4.20-30.7.legacy.img file was not created during the upgrade. The initrd is typically used for temporarily booting the hardware into a state, that the real kernel vmlinuz can than take over and continue the booting. For example - you can't read the kernel off the scsi hard disk until you have a scsi driver loaded in the kernel. My /etc/grub.conf points to non-existing image. Is this correct? title Red Hat Linux (2.4.20-30.7.legacy) root (hd0,0) kernel /vmlinuz-2.4.20-30.7.legacy ro root=/dev/hda9 initrd /initrd-2.4.20-30.7.legacy.img I can manually create this image running command mkinitrd /initrd-2.4.20-30.7.legacy.img 2.4.20-30.7.legacy Thank you in advance. -- ================================================================================ Ivan Teliatnikov phone: +61 2 9351 2031 fax: +61 2 9351 0184 mobile_phone: +61 402 173 179 email: ivan at es.usyd.edu.au School of Geosciences F05 - Edgeworth David Building The University of Sydney NSW 2006 Australia =============================================================================== From jkeating at j2solutions.net Thu Mar 11 15:24:58 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 11 Mar 2004 07:24:58 -0800 Subject: missing /initrd-2.4.20-30.7.legacy.img after kernel upgrade In-Reply-To: References: Message-ID: <200403110724.58716.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 11 March 2004 04:33, Ivan Teliatnikov wrote: > The initrd is typically used for temporarily booting the hardware into a > state, that the real kernel vmlinuz can than take over and continue the > booting. For example - you can't read the kernel off the scsi hard disk > until you have a scsi driver loaded in the kernel. > > My /etc/grub.conf points to non-existing image. Is this correct? > > title Red Hat Linux (2.4.20-30.7.legacy) > root (hd0,0) > kernel /vmlinuz-2.4.20-30.7.legacy ro root=/dev/hda9 > initrd /initrd-2.4.20-30.7.legacy.img > > I can manually create this image running command > mkinitrd /initrd-2.4.20-30.7.legacy.img 2.4.20-30.7.legacy Making of the initrd is part of the kernel %post script. If, for some reason, you're using a 3rd party module in your current kernel, that initrd thinks is required, then you should have gotten a message about the %post script failing. In all the tests I did, I use rpm manually or with yum, and the initrd.img was created. Can anybody else duplicate this failure using apt? - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAUITK4v2HLvE71NURArPOAJ9sKxL5ykvDCyOVVWica4dlCtWCCACfYApq OTOJx8JF0y5QB6CzM4n7p1o= =hwZY -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Thu Mar 11 15:59:11 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 11 Mar 2004 16:59:11 +0100 Subject: missing /initrd-2.4.20-30.7.legacy.img after kernel upgrade In-Reply-To: <200403110724.58716.jkeating@j2solutions.net> References: <200403110724.58716.jkeating@j2solutions.net> Message-ID: <20040311165911.47e71aba.ms-nospam-0306@arcor.de> On Thu, 11 Mar 2004 07:24:58 -0800, Jesse Keating wrote: > On Thursday 11 March 2004 04:33, Ivan Teliatnikov wrote: > > The initrd is typically used for temporarily booting the hardware into a > > state, that the real kernel vmlinuz can than take over and continue the > > booting. For example - you can't read the kernel off the scsi hard disk > > until you have a scsi driver loaded in the kernel. > > > > My /etc/grub.conf points to non-existing image. Is this correct? > > > > title Red Hat Linux (2.4.20-30.7.legacy) > > root (hd0,0) > > kernel /vmlinuz-2.4.20-30.7.legacy ro root=/dev/hda9 > > initrd /initrd-2.4.20-30.7.legacy.img > > > > I can manually create this image running command > > mkinitrd /initrd-2.4.20-30.7.legacy.img 2.4.20-30.7.legacy First of all, that command would be incorrect, because it would create the initrd image in the root directory as opposed to the /boot directory, which is on a different partition. Your grub.conf file says that you have /dev/hda1 = /boot and /dev/hda9 = /. Creation of the initrd can fail if /boot is out of space. It should be reproducible, too, i.e. * install previous kernel (-28.7) * reboot to previous kernel * erase -30.7 kernel * apt-get -30.7 kernel Is it? > Making of the initrd is part of the kernel %post script. If, for some > reason, you're using a 3rd party module in your current kernel, that > initrd thinks is required, then you should have gotten a message about the > %post script failing. In all the tests I did, I use rpm manually or with > yum, and the initrd.img was created. > > Can anybody else duplicate this failure using apt? I doubt that. There is no reason to assume that the kernel update from 28.7 to 30.7 has changed anything that would break initrd creation. -- From jpdalbec at ysu.edu Thu Mar 11 17:44:23 2004 From: jpdalbec at ysu.edu (John Dalbec) Date: Thu, 11 Mar 2004 12:44:23 -0500 Subject: RHL 8.0 shadow-utils broken w/RPM 4.1.1 Message-ID: <4050A577.3020309@ysu.edu> I'm trying to build the RHL 8.0 shadow-utils on RPM 4.1.1 to test something. Wouldn't you know it leaves a bunch of unpackaged files lying around? Bleah. John From rostetter at mail.utexas.edu Thu Mar 11 19:10:59 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Thu, 11 Mar 2004 13:10:59 -0600 Subject: missing /initrd-2.4.20-30.7.legacy.img after kernel upgrade In-Reply-To: <200403110724.58716.jkeating@j2solutions.net> References: <200403110724.58716.jkeating@j2solutions.net> Message-ID: <20040311131059.jari8woocoscg4so@mail.ph.utexas.edu> Quoting Jesse Keating : > Making of the initrd is part of the kernel %post script. If, for some > reason, you're using a 3rd party module in your current kernel, that > initrd thinks is required, then you should have gotten a message about the > %post script failing. In all the tests I did, I use rpm manually or with > yum, and the initrd.img was created. > > Can anybody else duplicate this failure using apt? No, it worked on all the machines I've used it on... -- Eric Rostetter From admin at cs.montana.edu Thu Mar 11 19:16:00 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Thu, 11 Mar 2004 12:16:00 -0700 (MST) Subject: libtool,libtool-libs,mc,metamail Message-ID: <3229.153.90.196.197.1079032560.squirrel@web1.cs.montana.edu> I've installed: Inst libtool [1.4.2-7] (1.4.2-13.legacy Inst libtool-libs [1.4.2-7] Inst mc [4.5.55-5] (4.5.55-6.legacy Inst metamail [2.7-28] (2.7-29.7.x.legacy And they appear to not be causing problems, so far. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From keb at ctinetworks.com Fri Mar 12 01:43:05 2004 From: keb at ctinetworks.com (Kevin Bonner) Date: Thu, 11 Mar 2004 20:43:05 -0500 Subject: missing /initrd-2.4.20-30.7.legacy.img after kernel upgrade In-Reply-To: <20040311131059.jari8woocoscg4so@mail.ph.utexas.edu> References: <200403110724.58716.jkeating@j2solutions.net> <20040311131059.jari8woocoscg4so@mail.ph.utexas.edu> Message-ID: <200403112043.07560.keb@ctinetworks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 11 March 2004 14:10, Eric Rostetter wrote: > Quoting Jesse Keating : > > Making of the initrd is part of the kernel %post script. If, for some > > reason, you're using a 3rd party module in your current kernel, that > > initrd thinks is required, then you should have gotten a message about > > the %post script failing. In all the tests I did, I use rpm manually or > > with yum, and the initrd.img was created. > > > > Can anybody else duplicate this failure using apt? > > No, it worked on all the machines I've used it on... Same here. Worked fine on both a 7.2 and 7.3 box. Kevin Bonner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAURWp/9i/ml3OBYMRArFmAKCROdsXkExIm1Uvp9CXl1LE7U2u5wCfcPUS OMyEQYU8IvxF9PJNEGpAcu0= =rVF9 -----END PGP SIGNATURE----- From vherva at viasys.com Wed Mar 17 07:31:16 2004 From: vherva at viasys.com (Ville Herva) Date: Wed, 17 Mar 2004 09:31:16 +0200 Subject: Red Hat 7.x PHP confusion In-Reply-To: <404BB81D.3060204@bellsouth.net> References: <404BB81D.3060204@bellsouth.net> Message-ID: <20040317073116.GG20358@viasys.com> I was playing with a vulnerability scanner called "NeVo network vulnerability observer" with a Red Hat 7.x box that has php-4.1.2-7.1.6 installed on it. Among various other nags (mainly because Red Hat security updates don't usually update the major version number, but backport patches), NeVo complained about PHP: --8<----------------------------------------------------------------------- The remote host is running a version of PHP which is older than 4.3.2. This version contains various flaws that may allow an attacker who has the ability to execute PHP scripts in safe_mode on this host to execute arbitrary commands with the privileges of the HTTP daemon Solution : Upgrade to PHP 4.3.2 Plugin ID : 5043 Bugtraq ID : 7187,7197,7198,7199,7210 80/tcp The remote web server is running a version of PHP which is older than 4.2.2. This version has a bug in its mail() function which does not properly sanitize user input. As a result, users can forge email to make it look like it is coming from a different source that the server. Solution : Upgrade to PHP 4.2.2 Plugin ID : 5040 Bugtraq ID : 5562 CVE ID : CAN-2002-0985 80/tcp --8<----------------------------------------------------------------------- As with the other nags I tried to ensure that the box is not out of date. With PHP, this turned out difficult. The mail() vulnerability is plugged in php-4.1.2-7.1.6: https://rhn.redhat.com/errata/RHSA-2002-213.html rpm -q --changelog php * Fri Sep 27 2002 Joe Orton 4.1.2-7.1.6 - add security fixes for mail() function; CAN-2002-0985, CAN-2002-0986 But the other one is more thorny. The Bugtraq database entry that NeVo mentions (http://www.securityfocus.com/bid/7198) lists Red Hat 7.0, 7.1, 7.2 and 7.3 as vulnerable, but it says this is for version PHP 4.0.6. Under "PHP 4.1.2", no Red Hat distro is listed as vulnerable. Red Hat errata does not list any PHP updates for 7.3 after 2002-11-04 (which is 4.1.2-7.x.6). Fedora Legacy doesn't have a PHP update nor does Progeny Transition Service. Red Hat 8 and 9 errata does list other problems for PHP after 2002-11-04 (for example, https://rhn.redhat.com/errata/RHSA-2003-204.html), but those fixes are not for 7.x/PHP4.1.x. The secunia advisory http://secunia.com/advisories/8892/ (which I hope is the same issue that NeVo nags about), lists only PHP-4.2.x and PHP-4.3.x as vulnerable. I tried to compile a few PHP-4.3.x .src.rpm packages from source, but this proved problematic, too. The ones from Red Hat 8 or 9 assume apache-2, and the one I found for apache-1.3 (from mysql.org) would require a _heap_ of devel packages to build (and those still seemed require quite a lot of .spec tinkering). Two questions: - Would anyone happen to know if php-4.1.2-7.x.6 is vulnerable to the Bugtraq ID : 7187,7197,7198,7199,7210 issue? - Has anyone had success in compiling php-4.3.4 rpm for Red Hat 7.x? Is it worth it, and can I expect problems with apache-1.3 and/or the existing php scripts? (Luckily the web server is not world-accessible and the php scripts are not mission critical.) -- v -- v at iki.fi From cspencer at cait.org Wed Mar 17 16:43:41 2004 From: cspencer at cait.org (Chris Spencer) Date: Wed, 17 Mar 2004 10:43:41 -0600 Subject: Red Hat 7.x PHP confusion In-Reply-To: <20040317073116.GG20358@viasys.com> References: <404BB81D.3060204@bellsouth.net> <20040317073116.GG20358@viasys.com> Message-ID: <1079541821.32070.5.camel@chriss2.cait.org> On Wed, 2004-03-17 at 01:31, Ville Herva wrote: > - Would anyone happen to know if php-4.1.2-7.x.6 is vulnerable to the > Bugtraq ID : 7187,7197,7198,7199,7210 issue? Probably vulnerable. RH7 has been unsupported for some time now. Your research seems good enough to convince me. > - Has anyone had success in compiling php-4.3.4 rpm for Red Hat 7.x? I haven't but this probably isn't an issue really. > Is it worth it, and can I expect problems with apache-1.3 and/or > the existing php scripts? Your scripts will almost certainly have issues. I don't know if apache will need a recompile but I doubt it. Recompiling the php modules will be needed, I imagine. Hope that's helpful. I'd suggest if you are going to upgrade just grabbing source RPMs from a current distro and trying to recompile them. (May or may not work, but seems more likely to). -Chris "There are only two things that are infinite: the universe and human stupidity. And I'm not sure about the universe." - Albert Einstein From jkeating at j2solutions.net Wed Mar 17 17:58:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 17 Mar 2004 09:58:10 -0800 Subject: openssl update Message-ID: <200403170958.10496.jkeating@j2solutions.net> Openssl.org announced an update today. However, when looking at the advisories, it seems that the openssl that is in RHL 7.2-8.0 is not effected. (0.9.6b-*) Since it is widely known that Red Hat's openssl packages do backport bugfixes, it makes me wonder if perhaps the code that has a problem in the 0.9.6c-l, and 0.9.7 releases of openssl might have been backported to Red Hat's 0.9.6b. I haven't a lot of time today to go digging into this, but would one of you be willing to examine the changes openssl.org made, to see if the code exists in Red Hat's 0.9.6b packages? I'd appreciate it. Thanks! -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From michal at harddata.com Wed Mar 17 21:17:17 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 17 Mar 2004 14:17:17 -0700 Subject: openssl update In-Reply-To: <200403170958.10496.jkeating@j2solutions.net>; from jkeating@j2solutions.net on Wed, Mar 17, 2004 at 09:58:10AM -0800 References: <200403170958.10496.jkeating@j2solutions.net> Message-ID: <20040317141717.C2777@mail.harddata.com> On Wed, Mar 17, 2004 at 09:58:10AM -0800, Jesse Keating wrote: Content-Description: signed data > Openssl.org announced an update today. However, when looking at the > advisories, it seems that the openssl that is in RHL 7.2-8.0 is not > effected. It looks to me that these packages _are_ affected. At least for 7.3 it looks like packages listed in RHSA-2004:119-01 (for example http://lwn.net/Articles/76125/ ) need just a modified "Release:" field in specs and that is about it. ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/openssl-0.9.6b-36.src.rpm ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/openssl095a-0.9.5a-24.src.rpm ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/openssl096-0.9.6-25.7.src.rpm Just finished recompiling on RH7.3 an equivalent of openssl-0.9.6b-36.src.rpm and a compilation process runs quite a few tests while doing the job. I will put something in bugzilla when I will check more. Michal From jkeating at j2solutions.net Wed Mar 17 22:49:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 17 Mar 2004 14:49:32 -0800 Subject: openssl update In-Reply-To: <20040317141717.C2777@mail.harddata.com> References: <200403170958.10496.jkeating@j2solutions.net> <20040317141717.C2777@mail.harddata.com> Message-ID: <200403171449.32547.jkeating@j2solutions.net> On Wednesday 17 March 2004 13:17, Michal Jaegermann wrote: > It looks to me that these packages _are_ affected. > > At least for 7.3 it looks like packages listed in RHSA-2004:119-01 > (for example http://lwn.net/Articles/76125/ ) need just a modified > "Release:" field in specs and that is about it. > > ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/openssl-0.9.6b- >36.src.rpm > ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/openssl095a-0.9 >.5a-24.src.rpm > ftp://updates.redhat.com/enterprise/2.1AS/en/os/SRPMS/openssl096-0.9. >6-25.7.src.rpm > > Just finished recompiling on RH7.3 an equivalent of > openssl-0.9.6b-36.src.rpm and a compilation process runs quite a few > tests while doing the job. I will put something in bugzilla when I > will check more. What makes you think they are? The only thing they are effected by is CAN-2004-0081, which is a one line fix. See http://cvs.openssl.org/chngview?cn=5721 for the fix. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From michal at harddata.com Wed Mar 17 23:28:09 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 17 Mar 2004 16:28:09 -0700 Subject: openssl update In-Reply-To: <200403171449.32547.jkeating@j2solutions.net>; from jkeating@j2solutions.net on Wed, Mar 17, 2004 at 02:49:32PM -0800 References: <200403170958.10496.jkeating@j2solutions.net> <20040317141717.C2777@mail.harddata.com> <200403171449.32547.jkeating@j2solutions.net> Message-ID: <20040317162809.B7342@mail.harddata.com> On Wed, Mar 17, 2004 at 02:49:32PM -0800, Jesse Keating wrote: > > What makes you think they are? The code seems to be everywhere really the same and really the same patches apply. Also people from Red Hat seem to be of the same opinion as packages listed in Red Hat alert RHSA-2004:119-01 are, for all practical purposes, the same as what is used in 7.3. > The only thing they are effected by is > CAN-2004-0081, which is a one line fix. See > http://cvs.openssl.org/chngview?cn=5721 for the fix. Fixes are indeed really short. openssl-0.9.6c-spinfix.patch is really a one-liner; openssl-0.9.6b-recursion.patch for ASN1 code a bit longer but not by much. Michal From jkeating at j2solutions.net Wed Mar 17 23:30:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 17 Mar 2004 15:30:54 -0800 Subject: openssl update In-Reply-To: <20040317162809.B7342@mail.harddata.com> References: <200403170958.10496.jkeating@j2solutions.net> <200403171449.32547.jkeating@j2solutions.net> <20040317162809.B7342@mail.harddata.com> Message-ID: <200403171530.58539.jkeating@j2solutions.net> On Wednesday 17 March 2004 15:28, Michal Jaegermann wrote: > The code seems to be everywhere really the same and really the same > patches apply. Also people from Red Hat seem to be of the same > opinion as packages listed in Red Hat alert RHSA-2004:119-01 are, > for all practical purposes, the same as what is used in 7.3. It's my understanding (after talking with some Red Hat folks) that the only fix for the 0.9.6b packages is for CAN-2004-0081. In fact, looking at the RHL9 package openssl096b-0.9.6b-15.src.rpm, the changelog shows only: * Mon Mar 8 2004 Joe Orton 0.9.6b-15 - add security fix for CAN-2004-0081 - conditionalize use of -Wa,--noexecstack This confirms my thought that 0.9.6b is only effected by CAN-2004-0081. > Fixes are indeed really short. openssl-0.9.6c-spinfix.patch is > really a one-liner; openssl-0.9.6b-recursion.patch for ASN1 code > a bit longer but not by much. Where do you see openssl-0.9.6b-recursion.patch? It's not in RHL9's openssl096b-0.9.6b-15.src.rpm. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From michal at harddata.com Thu Mar 18 00:01:10 2004 From: michal at harddata.com (Michal Jaegermann) Date: Wed, 17 Mar 2004 17:01:10 -0700 Subject: openssl update In-Reply-To: <200403171530.58539.jkeating@j2solutions.net>; from jkeating@j2solutions.net on Wed, Mar 17, 2004 at 03:30:54PM -0800 References: <200403170958.10496.jkeating@j2solutions.net> <200403171449.32547.jkeating@j2solutions.net> <20040317162809.B7342@mail.harddata.com> <200403171530.58539.jkeating@j2solutions.net> Message-ID: <20040317170110.B9145@mail.harddata.com> On Wed, Mar 17, 2004 at 03:30:54PM -0800, Jesse Keating wrote: > > Where do you see openssl-0.9.6b-recursion.patch? It's not in RHL9's > openssl096b-0.9.6b-15.src.rpm. In all these three "entreprise" packages which I listed in my first reply. Anyway, here it is in its whole glory: CAN-2003-0851 Patch from Dr Stephen N Henson to fix deep recursion in OpenSSL 0.9.6 and an issue there where OpenSSL doesn't work out the remaining length for indefinite length constructed headers. diff -ur -x CVS openssl6/crypto/asn1/a_bytes.c ossl6/crypto/asn1/a_bytes.c --- openssl6/crypto/asn1/a_bytes.c 2000-06-01 23:16:27.000000000 +0100 +++ ossl6/crypto/asn1/a_bytes.c 2003-10-09 12:33:28.000000000 +0100 @@ -201,7 +201,10 @@ c.pp=pp; c.p=p; c.inf=inf; - c.slen=len; + if (inf & 1) + c.slen = p - *pp; + else + c.slen=len; c.tag=Ptag; c.xclass=Pclass; c.max=(length == 0)?0:(p+length); @@ -289,7 +292,7 @@ } c->q=c->p; - if (d2i_ASN1_bytes(&os,&c->p,c->max-c->p,c->tag,c->xclass) + if (d2i_ASN1_bytes(&os,&c->p,c->slen,c->tag,c->xclass) == NULL) { c->error=ERR_R_ASN1_LIB; The other patch just adds 'rr->length = 0;' assignment in s3_pkt.c. Michal From jkeating at j2solutions.net Thu Mar 18 00:04:08 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 17 Mar 2004 16:04:08 -0800 Subject: openssl update In-Reply-To: <20040317170110.B9145@mail.harddata.com> References: <200403170958.10496.jkeating@j2solutions.net> <200403171530.58539.jkeating@j2solutions.net> <20040317170110.B9145@mail.harddata.com> Message-ID: <200403171604.13401.jkeating@j2solutions.net> On Wednesday 17 March 2004 16:01, Michal Jaegermann wrote: > In all these three "entreprise" packages which I listed in my > first reply. Anyway, here it is in its whole glory: > > CAN-2003-0851 > > Patch from Dr Stephen N Henson to fix deep recursion in OpenSSL 0.9.6 > and an issue there where OpenSSL doesn't work out the remaining > length for indefinite length constructed headers. OK, I see where we were going wrong. I was looking at the RHL9 errata, which doesn't mention 0851 at all. Perhaps something I need to bring up with Red Hat. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From vherva at viasys.com Thu Mar 18 08:21:13 2004 From: vherva at viasys.com (Ville Herva) Date: Thu, 18 Mar 2004 10:21:13 +0200 Subject: Red Hat 7.x PHP confusion In-Reply-To: <1079541821.32070.5.camel@chriss2.cait.org> References: <404BB81D.3060204@bellsouth.net> <20040317073116.GG20358@viasys.com> <1079541821.32070.5.camel@chriss2.cait.org> Message-ID: <20040318082112.GH20358@viasys.com> On Wed, Mar 17, 2004 at 10:43:41AM -0600, you [Chris Spencer] wrote: > On Wed, 2004-03-17 at 01:31, Ville Herva wrote: > > - Would anyone happen to know if php-4.1.2-7.x.6 is vulnerable to the > > Bugtraq ID : 7187,7197,7198,7199,7210 issue? > > Probably vulnerable. RH7 has been unsupported for some time now. --8<----------------------------------------------------------------------- Date: Fri, 12 Dec 2003 10:38:06 +0000 (GMT) From: Mark J Cox Subject: End of Life for Red Hat Linux 7.1, 7.2, 7.3, 8.0 To: redhat-watch-list at redhat.com (...) Red Hat Linux 7.1, 7.2, 7.3, and 8.0 distributions will reach their end-of-life for errata maintenance on the 31st December 2003. ~~~~~~~~~~~~~~~~~~ --8<----------------------------------------------------------------------- Some time, yes. But the vulnerability was discovered in March 2003 - yet no PHP updates were released for RH7.x since late 2002. > Your research seems good enough to convince me. But I found nothing explicit to suggest php-4.1.2-7.x.6 is vulnerable... > > - Has anyone had success in compiling php-4.3.4 rpm for Red Hat 7.x? > > I haven't but this probably isn't an issue really. Are you implying that it should be easy? I mean easier than trying to backport the fixes to php-4.1.2-7.x.6? > Your scripts will almost certainly have issues. I don't know if apache > will need a recompile but I doubt it. I hope not. I just wasn't even sure the latest PHP supports Apache 1.3.x, but apparently it does. > Recompiling the php modules will be needed, I imagine. Ugh, that, too. Well, I'm still stumbling with the PHP-4.3.4 compilation. Perhaps I'll just have to wrap up my sleeves and do it. > Hope that's helpful. Yes, thanks. > I'd suggest if you are going to upgrade just grabbing source RPMs from a > current distro and trying to recompile them. (May or may not work, but > seems more likely to). I did (before I posted the question); I took the Red Hat 8 and Red Hat 9 errata .src.rpm's but both of them are for apache-2 only. The Red Hat 9 .spec is even uncompatible with the RH7.x rpm build system (or at least it gives as error.) On top of that, they require a huge pile of devel libraries -- moreover, recent versions of them, which would mean I have to upgrade things like openldpa, cyrus-sasl, and install freetype and gd... Surely, with heavy massaging the .spec could be made to work (by disabling configuration options (although even with --without-freetype it still barfs on lack of -lttf), but I was trying to imply I didn't find it easy. Hence I asked ?f someone had done it already and could perhaps provide some tips. -- v -- v at iki.fi From peter.peltonen at iki.fi Thu Mar 18 09:32:18 2004 From: peter.peltonen at iki.fi (Peter Peltonen) Date: Thu, 18 Mar 2004 11:32:18 +0200 Subject: Red Hat 7.x PHP confusion In-Reply-To: <20040318082112.GH20358@viasys.com> References: <404BB81D.3060204@bellsouth.net> <20040317073116.GG20358@viasys.com> <1079541821.32070.5.camel@chriss2.cait.org> <20040318082112.GH20358@viasys.com> Message-ID: <40596CA2.6050307@iki.fi> Ville Herva wrote: > I did (before I posted the question); I took the Red Hat 8 and Red Hat 9 > errata .src.rpm's but both of them are for apache-2 only. The Red Hat 9 > .spec is even uncompatible with the RH7.x rpm build system (or at least it > gives as error.) On top of that, they require a huge pile of devel libraries > -- moreover, recent versions of them, which would mean I have to upgrade > things like openldpa, cyrus-sasl, and install freetype and gd... Surely, > with heavy massaging the .spec could be made to work (by disabling > configuration options (although even with --without-freetype it still barfs > on lack of -lttf), but I was trying to imply I didn't find it easy. Hence I > asked ?f someone had done it already and could perhaps provide some tips. PHP is really a pain to package (at least for packaging newbie like me :) But I've succeeded some time ago in making 4.3.2 RPMs on RH72. They didn't provide everything (SNMP for example), but most of the common features were in. Here's the list what packages I had to install/upgrade to get php rebuilt and installed on that specific server (I think it was a "vanilla" RH72 before the php upgrade, but I might be wrong): aspell-0.50.3-15 aspell-da-0.50-5 aspell-de-0.50-5 aspell-devel-0.50.3-15 aspell-en-0.51-6 aspell-es-0.50-5 aspell-fr-0.50-3 aspell-it-0.1-17 aspell-nl-0.50-3 aspell-no-0.50-3 aspell-pt-0.50-6 aspell-pt_BR-2.4-13 aspell-sv-0.50-3 autoconf213-2.13-6 autoconf-2.57-3 automake14-1.4p6-5.1 automake-1.6.3-5 curl-7.10.4-1 curl-devel-7.10.4-1 libtool-1.4.3-5 libtool-libs-1.4.3-5 libxml2-2.5.8-3 libxml2-devel-2.5.8-3 libxml2-python-2.5.8-3 php-4.3.2 php-devel-4.3.2 php-imap-4.3.2 php-ldap-4.3.2 php-manual-4.3.2 php-mysql-4.3.2 php-odbc-4.3.2 php-pgsql-4.3.2 zziplib-0.10.27 zziplib-devel-0.10.27 zziplib-doc-0.10.27 zziplib-sfnet-0.10.27 So, if PHP is vulerable, I would suggest patching, not upgrading, it. Though, if someone is interested in building the newest PHP packages for 7.x, I'd be interested in them. I can share my specs from the 4.3.2 test upgrade I've made. Regards, Peter From vherva at viasys.com Thu Mar 18 12:24:40 2004 From: vherva at viasys.com (Ville Herva) Date: Thu, 18 Mar 2004 14:24:40 +0200 Subject: Red Hat 7.x PHP confusion In-Reply-To: <20040318082112.GH20358@viasys.com> References: <404BB81D.3060204@bellsouth.net> <20040317073116.GG20358@viasys.com> <1079541821.32070.5.camel@chriss2.cait.org> <20040318082112.GH20358@viasys.com> Message-ID: <20040318122440.GE18771@viasys.com> On Thu, Mar 18, 2004 at 10:21:12AM +0200, you [Ville Herva] wrote: > > > Your research seems good enough to convince me. > > But I found nothing explicit to suggest php-4.1.2-7.x.6 is vulnerable... Well, getting my off lazy ass... I ran the bugtraq proof-of-concept-exploits (http://www.securityfocus.com/bid/{7187,7197,7198,7199,7210}/exploit/) for a box that runs php-4.1.2-7.x.6. Here are the results: 7210: does nothing 7199: no proof-of-concept exploit 7198: crashes httpd ("[notice] child pid 23937 exit signal Segmentation fault (11)") 7197: does nothing ("Warning: socket_recv() expects exactly 2 parameters, 4 given in /data/www/intra/cgi-bin/uggabugga/exploit7197.php on line 3") 7187: crahes httpd ("[notice] child pid 10276 exit signal Segmentation fault (11)") So it is vulnerable, and likely exploitable, too. As these are local privilege escalations only, I'm not overly worried. -- v -- v at iki.fi From maxfield at one.ctelcom.net Thu Mar 18 19:25:39 2004 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Thu, 18 Mar 2004 13:25:39 -0600 (CST) Subject: getting yum on redhat 8.0 In-Reply-To: <20040311165911.47e71aba.ms-nospam-0306@arcor.de> References: <200403110724.58716.jkeating@j2solutions.net> <20040311165911.47e71aba.ms-nospam-0306@arcor.de> Message-ID: I got a round tuit and went to the fedora legacy pages. There are great tutorials on YUM for 7.3 and 7.2, but not for 8.0. The instructions for installing the apt using rpm don't work exactly as stated. I would like to offer these snippets for someone to put into a "yum for redhat 8.0" page very similar to the ones for 7.2/7.3 ==================================================================== Take the entire 7.3 yum page. Add/change the following information: ======================================================================= Yum for Redhat 8.0 can be obtained from freshrpms.net. It is the rpm: yum-2.0.3-5.rh.fr.i386.rpm http://psyche.freshrpms.net/rpm.html?id=1117 (you can also search for yum on their master page) Note: it is also listed at speakeasy.rpmfind.net. Yum requires the gnupg, python, and rpm-python packages. The standard gnupg and python packages that come with the redhat 8.0 CD can be installed. rpm-python will be updated below. Yum also requires glibc 2.3.2, which is available from http://download.fedoralegacy.org/redhat/8.0/updates/i386/ glibc-2.3.2-4.80.8.i386.rpm glibc-common-2.3.2-4.80.8.i386.rpm Yum also requires later versions of RPM. This is a good thing, as getting the updated RPM's also fix the hangs you will experience with rpm for redhat 8.0. The updated rpm packages are at: ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/ they are: rpm-4.1.1-1.8x.i386.rpm rpm-build-4.1-8x.i386.rpm popt-1.7.1-1.8x.i386.rpm rpm-devel-4.1.1-1.8x.i386.rpm rpm-python-4.1.1-1.8x.i386.rpm Note: A discussion of RPM hangs for redhat 8.0 is at: http://www.rpm.org/hintskinks/repairdb/ Finally, you have to add the fedora legacy site to the Yum for redhat 8.0 /etc/yum.conf file. Mine looks like this and appears to work, but it may not be totally correct: ------------------------------------------------------------------------ [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release gpgcheck=1 tolerant=1 exactarch=1 [os] name=Red Hat Linux $releasever - $basearch - os baseurl=http://ayo.freshrpms.net/redhat/$releasever/$basearch/os [freshrpms] name=Red Hat Linux $releasever - $basearch - freshrpms baseurl=http://ayo.freshrpms.net/redhat/$releasever/$basearch/freshrpms [base] name=Red Hat Linux $releasever base baseurl=http://download.fedoralegacy.org/redhat/$releasever/os/$basearch [updates] name=Red Hat Linux $releasever updates baseurl=http://download.fedoralegacy.org/redhat/$releasever/updates/$basearch [legacy-utils] name=Fedora Legacy utilities for Red Hat Linux $releasever baseurl=http://download.fedoralegacy.org/redhat/$releasever/legacy-utils/$basearch [updates] name=Red Hat Linux $releasever - $basearch - updates baseurl=http://ayo.freshrpms.net/redhat/$releasever/$basearch/updates ---------------------------------------------------------------------------- From jkeating at j2solutions.net Fri Mar 19 04:41:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 18 Mar 2004 20:41:32 -0800 Subject: openssl updates Message-ID: <200403182041.37296.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openssl updates are up for QA. http://bugzilla.fedora.us/show_bug.cgi?id=1395 - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAWnoB4v2HLvE71NURAjGZAJ41bvEu5xe4QDZSAqjR8B3fRNhI5ACdEUly Fmg6sFmh86OdP5uTfhFyTic= =jJkL -----END PGP SIGNATURE----- From rostetter at mail.utexas.edu Fri Mar 19 21:14:17 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 19 Mar 2004 15:14:17 -0600 Subject: getting yum on redhat 8.0 In-Reply-To: References: <200403110724.58716.jkeating@j2solutions.net> <20040311165911.47e71aba.ms-nospam-0306@arcor.de> Message-ID: <20040319151417.pr5yhwwowwg8w04g@mail.ph.utexas.edu> Quoting Wade Maxfield : > I got a round tuit and went to the fedora legacy pages. There are great > tutorials on YUM for 7.3 and 7.2, but not for 8.0. Because FL has not yet released a yum for 8.0. I have no idea why. I wish they would. > The instructions for > installing the apt using rpm don't work exactly as stated. Because there is no released apt for 8.0 from FL yet, though one has been in development for a while now. > I would like to offer these snippets for someone to put into a "yum for > redhat 8.0" page very similar to the ones for 7.2/7.3 I don't really want to do this unless someone tells me there will never be a FL yum for 8.0. Otherwise I'd rather wait for the FL yum. If there is no plan for a FL yum for 8.0, then I will add info on how to get a non-FL version. > Yum for Redhat 8.0 can be obtained from freshrpms.net. It is the rpm: > yum-2.0.3-5.rh.fr.i386.rpm I'd hate to have FL tell how to install non-FL software, and would hate the wars that come with it (don't use the freshrpms.net version, instead use the xxx.yyy version which is better for some reason). If you want to put any of this up on the FL wiki, I won't stop you (and may even help improve it). But I don't think it is appropriate for the web site, IMHO. -- Eric Rostetter From maxfield at one.ctelcom.net Fri Mar 19 23:26:14 2004 From: maxfield at one.ctelcom.net (Wade Maxfield) Date: Fri, 19 Mar 2004 17:26:14 -0600 (CST) Subject: getting yum on redhat 8.0 In-Reply-To: <20040319151417.pr5yhwwowwg8w04g@mail.ph.utexas.edu> References: <200403110724.58716.jkeating@j2solutions.net> <20040311165911.47e71aba.ms-nospam-0306@arcor.de> <20040319151417.pr5yhwwowwg8w04g@mail.ph.utexas.edu> Message-ID: On Fri, 19 Mar 2004, Eric Rostetter wrote: > Date: Fri, 19 Mar 2004 15:14:17 -0600 > From: Eric Rostetter > Reply-To: Discussion of the Fedora Legacy Project > > To: fedora-legacy-list at redhat.com > Subject: Re: getting yum on redhat 8.0 > > Quoting Wade Maxfield : > > > I got a round tuit and went to the fedora legacy pages. There are great > > tutorials on YUM for 7.3 and 7.2, but not for 8.0. > > Because FL has not yet released a yum for 8.0. I have no idea why. > I wish they would. > > > The instructions for > > installing the apt using rpm don't work exactly as stated. > > Because there is no released apt for 8.0 from FL yet, though one has been > in development for a while now. Sorry, I was not clear on that remark. Installing apt using rpm for 7.x does not work as stated on a 7.x box, at least for a stupid user such as myself. It fails silently. The problem is the ??? in the description. I assumed that it would magically fetch the right file name. Instead rpm will not do a web page fetch when done that way. The correct file name had to be gathered by looking at the download.fedoralegacy.org page and realizing what the actual file name was, and plugging that in. Since most fedoralegacy users are rather intelligent and can get past that just like I did, I just made a simple mention and did not clarify myself. > > > I would like to offer these snippets for someone to put into a "yum for > > redhat 8.0" page very similar to the ones for 7.2/7.3 > > I don't really want to do this unless someone tells me there will never > be a FL yum for 8.0. Otherwise I'd rather wait for the FL yum. > > If there is no plan for a FL yum for 8.0, then I will add info on how > to get a non-FL version. > > > Yum for Redhat 8.0 can be obtained from freshrpms.net. It is the rpm: > > yum-2.0.3-5.rh.fr.i386.rpm > > I'd hate to have FL tell how to install non-FL software, and would hate > the wars that come with it (don't use the freshrpms.net version, instead > use the xxx.yyy version which is better for some reason). > I understand, though I consider it sad that wars would be generated. I don't even like Microsoft wars any more. Though they are interesting to watch sometimes, but never to participate in. > If you want to put any of this up on the FL wiki, I won't stop you (and > may even help improve it). But I don't think it is appropriate for the > web site, IMHO. I'll look into it. May I borrow some of the original web page for 7.x so it looks consistent? I'll make sure that this is described as a TEMPORARY document until the FL yum is done. It will take some time to get another round tuit. > > -- > Eric Rostetter > wade From rostetter at mail.utexas.edu Sat Mar 20 03:29:31 2004 From: rostetter at mail.utexas.edu (Eric Rostetter) Date: Fri, 19 Mar 2004 21:29:31 -0600 Subject: getting yum on redhat 8.0 In-Reply-To: References: <200403110724.58716.jkeating@j2solutions.net> <20040311165911.47e71aba.ms-nospam-0306@arcor.de> <20040319151417.pr5yhwwowwg8w04g@mail.ph.utexas.edu> Message-ID: <20040319212931.9ywaecsc0ggow4ws@mail.ph.utexas.edu> Quoting Wade Maxfield : >> > The instructions for >> > installing the apt using rpm don't work exactly as stated. >> >> Because there is no released apt for 8.0 from FL yet, though one has been >> in development for a while now. > > Sorry, I was not clear on that remark. Installing apt using rpm for 7.x > does not work as stated on a 7.x box, at least for a stupid user such as > myself. It fails silently. I'm not sure what you mean. There are no instructions for installing apt on 7.x machines. Do you mean on a 8.0 box? > The problem is the ??? in the description. I assumed that it would > magically fetch the right file name. Instead rpm will not do a web page > fetch when done that way. The correct file name had to be gathered by > looking at the download.fedoralegacy.org page and realizing what the > actual file name was, and plugging that in. There should be no file to find for 7.x or 8.0. I'm not sure where you found any apt files to install. There are instructions for 8.0 there, but they specifically say that they won't work (and won't be completed) until there is a package. > Since most fedoralegacy users are rather intelligent and can get past > that just like I did, I just made a simple mention and did not clarify > myself. I'm still totally confused about what you mean... >> If you want to put any of this up on the FL wiki, I won't stop you (and >> may even help improve it). But I don't think it is appropriate for the >> web site, IMHO. > > I'll look into it. May I borrow some of the original web page for 7.x > so it looks consistent? I'll make sure that this is described as a > TEMPORARY document until the FL yum is done. It will take some time to > get another round tuit. Yes, you may use any or all of the existing yum or apt docs to start with. >> >> -- >> Eric Rostetter >> > > wade -- Eric Rostetter From PEDROCJ at terra.es Sat Mar 20 09:49:38 2004 From: PEDROCJ at terra.es (Pedro Canadilla) Date: 20 Mar 2004 10:49:38 +0100 Subject: getting yum on redhat 8.0 In-Reply-To: References: <200403110724.58716.jkeating@j2solutions.net> <20040311165911.47e71aba.ms-nospam-0306@arcor.de> Message-ID: <1079776181.766.5.camel@localhost.localdomain> It is working for my RedHat 8.0 box, the only difference with your yum.conf is that I deleted the freshrpms (ayo) links. So thanks a lot for your help and doc!! Regards, P.C. From bbaker at iowalaw.org Sat Mar 20 09:49:56 2004 From: bbaker at iowalaw.org (bbaker at iowalaw.org) Date: Sat, 20 Mar 2004 01:49:56 -0800 (PST) Subject: Auto Response from Bryan Baker Message-ID: <2336976.1079776196617.JavaMail.root@imta02> I'm currently on vacation. I will be returning to the office on 3/28/04 Mailing lists may see this message one time, sorry, I still want delivery, but I need to have this message on. It shouldn't repeat. If it does, please have an admin put me on vac. mode. -- If this is for a support matter -- For any urgent matters try contacting Arlys or Pat. For things that can wait till I get back please try using the support database to file a report. I will be attempting to monitor my email while I'm away, but I'll be busy. From michal at harddata.com Sat Mar 20 19:08:49 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sat, 20 Mar 2004 12:08:49 -0700 Subject: issues with mozilla Message-ID: <20040320120849.A1690@mail.harddata.com> On March 18th RHSA-2004:112-01 advisory showed up about multiple security vulnerabilities in Mozilla. New release fixes the following: CAN-2003-0564 ASN.1 troubles with S/MIME CAN-2003-0594 cookie mishandling with a possibilty of execution of a malicious code on a browsing machine CAN-2004-0191 cross-site scripting issues More details about these bugs can be found on http://cve.mitre.org/. As for fixes I found some patch for the last problem trawling through bugzilla.mozilla.org but the other two were fixed by switching to a version of Mozilla with these bugs fixed and mozilla-1.4.2-0.9.0.src.rpm does not include _any_ explicit patches. I tried to look around if somewhere else there is something I could adapt to mozilla-1.0.2-2.7.3 but I drew blank. One would have to be intimately familiar with mozilla sources to risk backporting security fixes to older versions and a time expenditure for something of that sort would likely be enourmous without any guarantees that things are indeed correct. Look at this source size. Instead I decided that recompiling mozilla-1.4.2 will be more productive. I modified mozilla.spec for the later to be similar to what was used with mozilla-1.0.2-2.7.3 and it worked on the first try. :-) As galeon is tied up to a mozilla (libraries) I did the same thing with the later. So far things seem to work just fine. I attach diffs, minus '%changelog' entries, for spec files used to recompile RH9 updates on RH7.3. There is no bugzilla entry for now (but if somebody feels like doing that... :-) Despite of a general policy of not changing versions this seems to me a correct thing to do here. Comments? Michal -------------- next part -------------- --- SPECS/mozilla.spec~ Mon Mar 8 12:45:27 2004 +++ SPECS/mozilla.spec Fri Mar 19 17:14:12 2004 @@ -2,13 +2,14 @@ %define desktop_file_utils_version 0.2.93 %define _unpackaged_files_terminate_build 0 -%define toolkit_options --disable-freetype2 --enable-xft +# %define toolkit_options --disable-freetype2 --enable-xft +%define toolkit_options --disable-freetype2 --enable-old-abi-compat-wrappers %define builddir %{_builddir}/mozilla Name: mozilla Summary: Web browser and mail reader Version: 1.4.2 -Release: 0.9.0 +Release: 0.7x.legacy Epoch: 37 License: MPL/NPL/GPL/LGPL Source0: mozilla-source-1.4.2.tar.bz2 @@ -54,7 +55,7 @@ Buildroot: %{_tmppath}/%{name}-root Prefix: /usr Group: Applications/Internet Provides: webclient -BuildPrereq: libpng-devel, libjpeg-devel, zlib-devel, zip, perl, indexhtml, libIDL-devel, glib2-devel, gtk2-devel, autoconf213 +BuildPrereq: libpng-devel, libjpeg-devel, zlib-devel, zip, perl, indexhtml, ORBit-devel, glib2-devel, gtk2-devel, autoconf Prereq: fileutils perl Prereq: /usr/bin/killall Requires: mozilla-nspr = %{epoch}:%{version}-%{release} @@ -247,7 +248,7 @@ if test "x$CPUS" = "x" -o "x$CPUS" = "x0 fi %ifarch i386 -CC=gcc296 CXX=g++296 \ +CC=gcc CXX=g++ \ CFLAGS=-g CXXFLAGS=-g XCFLAGS=-g \ %endif BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 \ -------------- next part -------------- --- SPECS/galeon.spec~ Tue Mar 9 09:49:28 2004 +++ SPECS/galeon.spec Sat Mar 20 11:17:07 2004 @@ -1,7 +1,7 @@ # Note that this is NOT a relocatable package # DON'T FORGET TO UPDATE THE MOZILLA DEPENDENCY %define ver 1.2.13 -%define rel 0.9.0 +%define rel 0.7x.legacy %define prefix /usr %define sysconfdir /etc %define moz_required 1.4.2 @@ -63,8 +63,8 @@ Galeon was written to do just one thing #autoconf export DONT_BUILD_NAUTILUS_VIEW=1 -export CC=gcc296 -export CXX=g++296 +# export CC=gcc296 +# export CXX=g++296 # if you set the DONT_BUILD_NAUTILUS_VIEW environment variable to something # else than "" the view won't be built. Otherwise, it will e built if From heinlein at cse.ogi.edu Sun Mar 21 15:07:23 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Sun, 21 Mar 2004 07:07:23 -0800 (PST) Subject: issues with mozilla In-Reply-To: <20040320120849.A1690@mail.harddata.com> References: <20040320120849.A1690@mail.harddata.com> Message-ID: On Sat, 20 Mar 2004, Michal Jaegermann wrote: > Despite of a general policy of not changing versions this seems > to me a correct thing to do here. Comments? Red Hat issued a fairly major mozilla version bump (1.2 -> 1.4) last week, so my hunch is that backporting the latest patches was deemed unworkable. So I guess my comment is that there's probably not much choice... -- Paul Heinlein From bbaker at iowalaw.org Sun Mar 21 15:07:32 2004 From: bbaker at iowalaw.org (bbaker at iowalaw.org) Date: Sun, 21 Mar 2004 07:07:32 -0800 (PST) Subject: Auto Response from Bryan Baker Message-ID: <23261144.1079881652581.JavaMail.root@imta01> I'm currently on vacation. I will be returning to the office on 3/28/04 Mailing lists may see this message one time, sorry, I still want delivery, but I need to have this message on. It shouldn't repeat. If it does, please have an admin put me on vac. mode. -- If this is for a support matter -- For any urgent matters try contacting Arlys or Pat. For things that can wait till I get back please try using the support database to file a report. I will be attempting to monitor my email while I'm away, but I'll be busy. From michal at harddata.com Sun Mar 21 18:25:56 2004 From: michal at harddata.com (Michal Jaegermann) Date: Sun, 21 Mar 2004 11:25:56 -0700 Subject: issues with mozilla In-Reply-To: ; from heinlein@cse.ogi.edu on Sun, Mar 21, 2004 at 07:07:23AM -0800 References: <20040320120849.A1690@mail.harddata.com> Message-ID: <20040321112556.A27409@mail.harddata.com> On Sun, Mar 21, 2004 at 07:07:23AM -0800, Paul Heinlein wrote: > On Sat, 20 Mar 2004, Michal Jaegermann wrote: > > > Despite of a general policy of not changing versions this seems > > to me a correct thing to do here. Comments? > > Red Hat issued a fairly major mozilla version bump (1.2 -> 1.4) last > week, so my hunch is that backporting the latest patches was deemed > unworkable. This mozilla-1.4 and a matching galeon is what I am running right now on RH7.3 installations and spec patches I posted were for these new Red Hat releases. So far all "uninformed guinea pigs" :-) even failed to notice that anything has changed. I fully expect that changes for RH8 are of the same order of magnitude and for 7.2 most likely too. > So I guess my comment is that there's probably not much choice... The other choices as I see them are: - do nothing and hope for the best (it may work in majority of cases) - somebody with a good knowledge of mozilla sources, and a quite a bit of time to burn, digs through 1.4 sources and based on that fixes earlier stuff; sounds to me like a massive waste of effort. Maybe somebody has some other options? There also can be some "gotchas" which I am missing. Hence my request for comments. Michal From cra at WPI.EDU Mon Mar 22 04:59:17 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 21 Mar 2004 23:59:17 -0500 Subject: tool to compare/check rpm binaries Message-ID: <20040322045917.GG8136@angus.ind.WPI.EDU> I've made a simple tool to check for differences in two rpm binary packages. The script check for diffs in: Provides Requires ldd output nm output (minus addresses) diff -r on unpacked tree I've run it against the openssl builds in: http://bugzilla.fedora.us/show_bug.cgi?id=1395 For 7.x, the diffs are reasonable (Provides on %{name} differs due to differing release numbers, Requires adds ld-linux.so.2, binary files differ). However, for all the 8.0 builds, the symbol tables (nm output) differ non-trivally. Is this something we should be concerned about? The script and sample output showing nm diffs is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm-build-compare.sh Type: application/x-sh Size: 2665 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-0.9.6b-36.8.legacy.i386.rpm-diff.txt.gz Type: application/x-gzip Size: 13883 bytes Desc: not available URL: From dawson at fnal.gov Mon Mar 22 15:33:06 2004 From: dawson at fnal.gov (Troy Dawson) Date: Mon, 22 Mar 2004 09:33:06 -0600 Subject: issues with mozilla In-Reply-To: <20040321112556.A27409@mail.harddata.com> References: <20040320120849.A1690@mail.harddata.com> <20040321112556.A27409@mail.harddata.com> Message-ID: <405F0732.3070605@fnal.gov> Michal Jaegermann wrote: > On Sun, Mar 21, 2004 at 07:07:23AM -0800, Paul Heinlein wrote: > >>On Sat, 20 Mar 2004, Michal Jaegermann wrote: >> >> >>>Despite of a general policy of not changing versions this seems >>>to me a correct thing to do here. Comments? >> >>Red Hat issued a fairly major mozilla version bump (1.2 -> 1.4) last >>week, so my hunch is that backporting the latest patches was deemed >>unworkable. > > > This mozilla-1.4 and a matching galeon is what I am running right > now on RH7.3 installations and spec patches I posted were for these > new Red Hat releases. So far all "uninformed guinea pigs" :-) even > failed to notice that anything has changed. > > I fully expect that changes for RH8 are of the same order of > magnitude and for 7.2 most likely too. > > >>So I guess my comment is that there's probably not much choice... > > > The other choices as I see them are: > - do nothing and hope for the best (it may work in majority of > cases) > - somebody with a good knowledge of mozilla sources, and a quite a > bit of time to burn, digs through 1.4 sources and based on that > fixes earlier stuff; sounds to me like a massive waste of effort. > > Maybe somebody has some other options? There also can be some > "gotchas" which I am missing. Hence my request for comments. > > Michal > Hi, Here is some rain for the parade. Because of internal pressure, mozilla is one of the things that I've always tried to keep current in our 7.3 based release. We currently have everything to mozilla 1.5, and will probrubly bump up again when mozilla 1.7 comes out. Anyway, because of that I've already ran into the problems. So far, there are only three that I know of. 1st - galeon (of course) 2nd - nautilus-mozilla 3rd - evolution The galeon problem is very obvious and straight forward, no real need to discuss. The evolution problem will happen with a new user, after you've upgraded mozilla. I'm not positive it will happen, but it need to be checked. To check it, upgrade your mozilla. Add a new user. Log in as that new user and start up evolution. If - you are able to so through the whole evolution startup without problems and elolution works correctly. Then - the problem isn't there Else - If at some point it complains about mozilla and won't work You need to recompile evolution. It should get the right mozilla libraries Fi The nautilus-mozilla problem didn't get reported for a whole year, so it's really alot more subtle. Basically, the nautilus-mozilla rpm doesn't work. But as far as I can tell, the only time this really causes a problem is when GNOME users try to use their graphical help. It will fail. To check it, upgrade your mozilla. Add a new user. Log in as that new user and start a terminal window or nautilus. From the 'Help' menu, select 'Contents' If - The help starts up correctly Then - the problem isn't there ElseIf - You get some type of message saying that it couldn't open correctly The bug is there. Fi I don't know if my solution is the best for everyone. I basically made a mozilla12 rpm, that had mozilla 1.2's libraries in it. Everything works fine with this. But, as I said, that might not be the best for everyone. As I said earlier, this would be rather hard for me to check from a regular release, because I'v had mozilla replaced for a long time. But for people with a more plain redhat release, these checks really should be made so we can tell if they are problems that need to be addressed or not. Troy -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/CSS CSI Group __________________________________________________ From admin at cs.montana.edu Mon Mar 22 17:48:59 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Mon, 22 Mar 2004 10:48:59 -0700 (MST) Subject: getting yum on redhat 8.0 In-Reply-To: <20040319212931.9ywaecsc0ggow4ws@mail.ph.utexas.edu> References: <200403110724.58716.jkeating@j2solutions.net><20040311165911.47e71aba.ms-nospam-0306@arcor.de><20040319151417.pr5yhwwowwg8w04g@mail.ph.utexas.edu> <20040319212931.9ywaecsc0ggow4ws@mail.ph.utexas.edu> Message-ID: <1393.153.90.196.197.1079977739.squirrel@web1.cs.montana.edu> Eric Rostetter said: > I'm not sure what you mean. There are no instructions for installing apt > on 7.x machines. Do you mean on a 8.0 box? > >> The problem is the ??? in the description. I assumed that it would >> magically fetch the right file name. Instead rpm will not do a web >> page >> fetch when done that way. The correct file name had to be gathered by >> looking at the download.fedoralegacy.org page and realizing what the >> actual file name was, and plugging that in. > I just use the freshrpms apt, apt works perfectly on all clients. Then update sourcelist. -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From boris at folgmann.de Mon Mar 22 10:07:43 2004 From: boris at folgmann.de (Boris Folgmann) Date: Mon, 22 Mar 2004 11:07:43 +0100 Subject: Apache HTTP Server 2.0.49 Released Message-ID: Hi! AFAIK httpd-2.0.40-11.9 is the last version packaged for RH8. Are there already some plans to release an RPM with the latest security fixes for Fedora-Legacy? "Apache HTTP Server 2.0.49 Released The Apache Software Foundation and the The Apache HTTP Server Project are pleased to announce the release of version 2.0.49 of the Apache HTTP Server ("Apache"). This Announcement notes the significant changes in 2.0.49 as compared to 2.0.48. This version of Apache is principally a bug fix release. A summary of the bug fixes is given at the end of this document. Of particular note is that 2.0.49 addresses three security vulnerabilities: When using multiple listening sockets, a denial of service attack is possible on some platforms due to a race condition in the handling of short-lived connections. This issue is known to affect some versions of AIX, Solaris, and Tru64; it is known to not affect FreeBSD or Linux. [CAN-2004-0174] Arbitrary client-supplied strings can be written to the error log which can allow exploits of certain terminal emulators. [CAN-2003-0020] A remotely triggered memory leak in mod_ssl can allow a denial of service attack due to excessive memory consumption. [CAN-2004-0113] This release is compatible with modules compiled for 2.0.42 and later versions. We consider this release to be the best version of Apache available and encourage users of all prior versions to upgrade." from http://www.apache.org/dist/httpd/Announcement2.html cu, boris From jkeating at j2solutions.net Mon Mar 22 23:29:03 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 22 Mar 2004 15:29:03 -0800 Subject: Fedora Legacy Test Update Notification: openssl095a Message-ID: <200403221529.07881.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1395 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1395 2004-03-22 --------------------------------------------------------------------- Name : openssl095a Version 7.2 : 0.9.5a-24.7.3.legacy Version 7.3 : 0.9.5a-24.7.3.legacy Version 8.0 : 0.9.5a-24.8.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: CAN-2003-0851: OpenSSL 0.9.6k does not properly handle certain ASN.1 sequences. As a result, OpenSSL performs a recursive function call that could exhaust system resources and crash the process using the OpenSSL library. CAN-2004-0081: OpenSSL prior to version 0.9.6d does not properly handle unknown message types. An attacker could cause the application using OpenSSL to enter an infinite loop, resulting in a denial of service. --------------------------------------------------------------------- Changelog: * Thu Mar 18 2004 Jesse Keating - 0.9.5a-24.7.3.legacy - add security fixes for CAN-2004-0081 and CAN-2003-0851 --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 6125c0171b9bd2c49e2f206fa616c70310262085 7.2/updates-testing/SRPMS/openssl095a-0.9.5a-24.7.3.legacy.src.rpm fff610245bcd73fce6b78c0e7f4155cf0c627762 7.2/updates-testing/i386/openssl095a-0.9.5a-24.7.3.legacy.i386.rpm 6125c0171b9bd2c49e2f206fa616c70310262085 7.3/updates-testing/SRPMS/openssl095a-0.9.5a-24.7.3.legacy.src.rpm fff610245bcd73fce6b78c0e7f4155cf0c627762 7.3/updates-testing/i386/openssl095a-0.9.5a-24.7.3.legacy.i386.rpm 6b789ea67363c4a7f23cc1e1363c32509605d5b4 8.0/updates-testing/SRPMS/openssl095a-0.9.5a-24.8.legacy.src.rpm f15faf931188fcc4991cd692eba88ef4dd3e670e 8.0/updates-testing/i386/openssl095a-0.9.5a-24.8.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Mon Mar 22 23:29:13 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 22 Mar 2004 15:29:13 -0800 Subject: Fedora Legacy Test Update Notification: openssl096 Message-ID: <200403221529.13388.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1395 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1395 2004-03-22 --------------------------------------------------------------------- Name : openssl096 Version 7.2 : 0.9.6-25.7.legacy Version 7.3 : 0.9.6-25.7.legacy Version 8.0 : 0.9.6-24.8.legacy Summary : Secure Sockets Layer Toolkit. Description : The OpenSSL certificate management tool and the shared libraries that provide various cryptographic algorithms and protocols. --------------------------------------------------------------------- Update Information: CAN-2003-0851: OpenSSL 0.9.6k does not properly handle certain ASN.1 sequences. As a result, OpenSSL performs a recursive function call that could exhaust system resources and crash the process using the OpenSSL library. CAN-2004-0081: OpenSSL prior to version 0.9.6d does not properly handle unknown message types. An attacker could cause the application using OpenSSL to enter an infinite loop, resulting in a denial of service. --------------------------------------------------------------------- Changelog: 7.2/7.3 * Thu Mar 18 2004 Jesse Keating - 0.9.6-25.7.legacy (there is no -24, move along) - add security fixes for CAN-2004-0081 and CAN-2003-0851 - add -Wa,--noexecstack to RPM_OPT_FLAGS so that assembled modules get tagged as not needing executable stacks. Ported from RHEL2.1AS packages 8.0 * Thu Mar 18 2004 Jesse Keating - 0.9.6-24.8.legacy - add security fixes for CAN-2004-0081 and CAN-2003-0851 - conditionalize use of -Wa,--noexecstack --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 296a86b860209645a73cdd081b03f3fb1d6e437d 7.2/updates-testing/SRPMS/openssl096-0.9.6-25.7.legacy.src.rpm f678d1b885a8236301afb4f92da2d451599643ce 7.2/updates-testing/i386/openssl096-0.9.6-25.7.legacy.i386.rpm 296a86b860209645a73cdd081b03f3fb1d6e437d 7.3/updates-testing/SRPMS/openssl096-0.9.6-25.7.legacy.src.rpm f678d1b885a8236301afb4f92da2d451599643ce 7.3/updates-testing/i386/openssl096-0.9.6-25.7.legacy.i386.rpm a13a09ee098c126ab7b452f13ae49cc870e0d5d2 8.0/updates-testing/SRPMS/openssl096-0.9.6-24.8.legacy.src.rpm 5fad5ab9fdbbf48cd725cb9d7edb853f651b0893 8.0/updates-testing/i386/openssl096-0.9.6-24.8.legacy.i386.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Mon Mar 22 23:29:16 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 22 Mar 2004 15:29:16 -0800 Subject: Fedora Legacy Test Update Notification: openssl Message-ID: <200403221529.16535.jkeating@j2solutions.net> --------------------------------------------------------------------- Fedora Test Update Notification FEDORA-2004-1395 Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1395 2004-03-22 --------------------------------------------------------------------- Name : openssl Version 7.2 : 0.9.6b-36.7.legacy Version 7.3 : 0.9.6b-36.7.legacy Version 8.0 : 0.9.6b-36.8.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: CAN-2003-0851: OpenSSL 0.9.6k does not properly handle certain ASN.1 sequences. As a result, OpenSSL performs a recursive function call that could exhaust system resources and crash the process using the OpenSSL library. CAN-2004-0081: OpenSSL prior to version 0.9.6d does not properly handle unknown message types. An attacker could cause the application using OpenSSL to enter an infinite loop, resulting in a denial of service. --------------------------------------------------------------------- Changelog: * Thu Mar 18 2004 Jesse Keating - 0.9.6b-36.7.legacy - add security fixes for CAN-2004-0081 and CAN-2003-0851 - updated ca-bundle.crt: removed expired GeoTrust roots, added freessl.com root, removed trustcenter.de Class 0 root --------------------------------------------------------------------- This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 2647596bc3e8d0090af0ea0e9841ba665872a729 7.2/updates-testing/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm 014a4d8fec25dde48ee8f8c14cc5250afc687542 7.2/updates-testing/i386/openssl-0.9.6b-36.7.legacy.i386.rpm 2647596bc3e8d0090af0ea0e9841ba665872a729 7.3/updates-testing/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm 014a4d8fec25dde48ee8f8c14cc5250afc687542 7.3/updates-testing/i386/openssl-0.9.6b-36.7.legacy.i386.rpm c4403aff66cc3891418f2f4a5fc9632ed87c6f79 7.3/updates-testing/i386/openssl-0.9.6b-36.7.legacy.i686.rpm 95ab8bd7b6e649f3e7995830e8f15c3fd55e83bd 8.0/updates-testing/SRPMS/openssl-0.9.6b-36.8.legacy.src.rpm bb6c9804df5d4214ca80474f2f3e87ddfe298908 8.0/updates-testing/i386/openssl-0.9.6b-36.8.legacy.i386.rpm d49da33be792303a8ea3295076b3a7e5c7a29ea1 8.0/updates-testing/i386/openssl-0.9.6b-36.8.legacy.i686.rpm Please note that this update is also available via yum and apt through the updates-testing channel. Many people find this an easier way to apply updates. --------------------------------------------------------------------- -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jackie.m at vt.edu Tue Mar 23 19:10:34 2004 From: jackie.m at vt.edu (jackie) Date: Tue, 23 Mar 2004 14:10:34 -0500 Subject: wu-ftpd In-Reply-To: <200403221529.16535.jkeating@j2solutions.net> References: <200403221529.16535.jkeating@j2solutions.net> Message-ID: I put this into bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1376 but since I'm not sure how to submit a package for review, I'll post it here as well. It's unsigned, but that's because I haven't set up keys yet (too lazy). Please review and abuse: I'm not sure how well this plays out with the putting things in the works to include in the update, but I've put together an updated wu-ftpd that includes patches for these vulnerabilities, blatantly stolen from the 2.1 AS distribution. sroms and roms can be gotten at ftp://ftp.iddl.vt.edu/pub/updates/wu-ftpd-2.6.2-12.73.1.i386.rpm and ftp://ftp.iddl.vt.edu/pub/updates/wu-ftpd-2.6.2-12.73.1.src.rpm enjoy, and let me knnow any issues that arise with these. -- Jackie Meese, Systems Administrator Institute for Distance and Distributed Learning, Va Tech Phone: 231-3682 http://www.iddl.vt.edu/ 3027 Torgersen Hall Mail Code: 0445 I am, and always will be, an idiot. From admin at cs.montana.edu Tue Mar 23 20:49:29 2004 From: admin at cs.montana.edu (Lucas Albers) Date: Tue, 23 Mar 2004 13:49:29 -0700 (MST) Subject: Fedora Legacy Test Update Notification: openssl095a In-Reply-To: <200403221529.07881.jkeating@j2solutions.net> References: <200403221529.07881.jkeating@j2solutions.net> Message-ID: <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> Jesse Keating said: > --------------------------------------------------------------------- > Fedora Test Update Notification > FEDORA-2004-1395 > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1395 > 2004-03-22 > --------------------------------------------------------------------- Do you have to restart your services or reboot the machine after installing these ssl libarary updates? -- Luke Computer Science System Administrator Security Administrator,College of Engineering Montana State University-Bozeman,Montana From heinlein at cse.ogi.edu Tue Mar 23 20:59:00 2004 From: heinlein at cse.ogi.edu (Paul Heinlein) Date: Tue, 23 Mar 2004 12:59:00 -0800 (PST) Subject: Fedora Legacy Test Update Notification: openssl095a In-Reply-To: <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> References: <200403221529.07881.jkeating@j2solutions.net> <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> Message-ID: On Tue, 23 Mar 2004, Lucas Albers wrote: > Do you have to restart your services or reboot the machine after > installing these ssl libarary updates? A reboot is the 100% completely safe (albeit vaguely Redmond-ish) method for picking up the new libraries. If you can easily identify the running services that are linked to libssl and libcrypto, then a simple service restart will suffice. -- Paul Heinlein From skvidal at phy.duke.edu Tue Mar 23 21:03:39 2004 From: skvidal at phy.duke.edu (seth vidal) Date: 23 Mar 2004 16:03:39 -0500 Subject: Fedora Legacy Test Update Notification: openssl095a In-Reply-To: <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> References: <200403221529.07881.jkeating@j2solutions.net> <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> Message-ID: <1080075819.14903.253.camel@opus> On Tue, 2004-03-23 at 15:49, Lucas Albers wrote: > Jesse Keating said: > > --------------------------------------------------------------------- > > Fedora Test Update Notification > > FEDORA-2004-1395 > > Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=1395 > > 2004-03-22 > > --------------------------------------------------------------------- > Do you have to restart your services or reboot the machine after > installing these ssl libarary updates? I'm pretty sure you need to restart all daemons using openssl. so for example: opensshd apache+mod_ssl imaps pop3s -sv From cturner at redhat.com Tue Mar 23 21:05:18 2004 From: cturner at redhat.com (Chip Turner) Date: 23 Mar 2004 16:05:18 -0500 Subject: Fedora Legacy Test Update Notification: openssl095a In-Reply-To: References: <200403221529.07881.jkeating@j2solutions.net> <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> Message-ID: Paul Heinlein writes: > On Tue, 23 Mar 2004, Lucas Albers wrote: > > > Do you have to restart your services or reboot the machine after > > installing these ssl libarary updates? > > A reboot is the 100% completely safe (albeit vaguely Redmond-ish) > method for picking up the new libraries. > > If you can easily identify the running services that are linked to > libssl and libcrypto, then a simple service restart will suffice. As an exercise I once wrote this script to detect any running processes that had mmap'd any files that were removed. Basically this detects things like a glibc or openssl update being applied but some processes not being restarted. Worked decently. Basically grepping /proc/*/maps for '(deleted)' (ignoring the SYSV results) will detect such processes; this script goes a bit further to figuer out what package the missing library was from, etc. Probably not useful here other than to express /proc/*/maps contains some info that helps detect these cases and to avoid unnecessary reboots (just restart affected services). -------------- next part -------------- A non-text attachment was scrubbed... Name: detect-stale-processes.py Type: application/octet-stream Size: 1577 bytes Desc: not available URL: -------------- next part -------------- Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From michal at harddata.com Tue Mar 23 22:01:03 2004 From: michal at harddata.com (Michal Jaegermann) Date: Tue, 23 Mar 2004 15:01:03 -0700 Subject: Fedora Legacy Test Update Notification: openssl095a In-Reply-To: ; from cturner@redhat.com on Tue, Mar 23, 2004 at 04:05:18PM -0500 References: <200403221529.07881.jkeating@j2solutions.net> <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> Message-ID: <20040323150103.A24974@mail.harddata.com> On Tue, Mar 23, 2004 at 04:05:18PM -0500, Chip Turner wrote: > > As an exercise I once wrote this script to detect any running > processes that had mmap'd any files that were removed. Ouch! This was a long exercise. For quite a while I am using something like that: #!/bin/bash grep -a deleted /proc/*/maps | sed -e '/SYSV0/d' -e 's,/maps:.*,,' | \ sort -u | while read p ; do echo $p ; ps uww --no-headers $(echo $p | sed 's,.*/,,') done Another possibility to identify names would be to do simply "cat $p/cmdline && echo" but this eats white space - which is often not nice. Michal From cturner at redhat.com Tue Mar 23 23:03:07 2004 From: cturner at redhat.com (Chip Turner) Date: 23 Mar 2004 18:03:07 -0500 Subject: Fedora Legacy Test Update Notification: openssl095a In-Reply-To: <20040323150103.A24974@mail.harddata.com> References: <200403221529.07881.jkeating@j2solutions.net> <2381.153.90.197.23.1080074969.squirrel@web1.cs.montana.edu> <20040323150103.A24974@mail.harddata.com> Message-ID: Michal Jaegermann writes: > On Tue, Mar 23, 2004 at 04:05:18PM -0500, Chip Turner wrote: > > > > As an exercise I once wrote this script to detect any running > > processes that had mmap'd any files that were removed. > > Ouch! This was a long exercise. For quite a while I am using > something like that: > > #!/bin/bash > grep -a deleted /proc/*/maps | sed -e '/SYSV0/d' -e 's,/maps:.*,,' | \ > sort -u | while read p ; do > echo $p ; ps uww --no-headers $(echo $p | sed 's,.*/,,') > done > > Another possibility to identify names would be to do simply > "cat $p/cmdline && echo" but this eats white space - which is often > not nice. Yep there are plenty of ways to do it simpler. The original idea was to integrate it into the applet to alert people 'hey, you should restart ssh' and such, but never went far enough with it to be user friendly enough to explain that kind of thing. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From warren at togami.com Sun Mar 28 20:12:50 2004 From: warren at togami.com (Warren Togami) Date: Sun, 28 Mar 2004 10:12:50 -1000 Subject: tool to compare/check rpm binaries In-Reply-To: <20040322045917.GG8136@angus.ind.WPI.EDU> References: <20040322045917.GG8136@angus.ind.WPI.EDU> Message-ID: <406731C2.6010404@togami.com> Charles R. Anderson wrote: > I've made a simple tool to check for differences in two rpm binary > packages. The script check for diffs in: > > Provides > Requires > ldd output > nm output (minus addresses) > diff -r on unpacked tree > > I've run it against the openssl builds in: > > http://bugzilla.fedora.us/show_bug.cgi?id=1395 > > For 7.x, the diffs are reasonable (Provides on %{name} differs due to > differing release numbers, Requires adds ld-linux.so.2, binary files > differ). However, for all the 8.0 builds, the symbol tables (nm > output) differ non-trivally. Is this something we should be concerned > about? > Neat! Would your tool be something we should include in the next fedora-rpmdevtools? https://bugzilla.fedora.us/show_bug.cgi?id=1175 If so, please submit it here and push for inclusion. Warren From sadhu at idc.iitb.ac.in Tue Mar 30 10:24:37 2004 From: sadhu at idc.iitb.ac.in (Nachiketa Sadhu) Date: Tue, 30 Mar 2004 15:54:37 +0530 Subject: Error message from yum update on RedHat 7.2 syatem Message-ID: <40694AE5.5010401@idc.iitb.ac.in> Hi, I installed yum on a RedHat 7.2 system as explained in "Using Fedora Legacy's yum for Red Hat Linux 7.x" documentation. On giving the command to update, I am getting the following error message: [root at abhikalpa root]# yum update Gathering package information from servers Getting headers from: Red Hat Linux 7.2 base Error getting file http://download.fedoralegacy.org/redhat/7.2/os/i386/headers/header.info [Errno 4] IOError: [Errno socket error] nonnumeric port I am behind a proxy server, and use a HTTP_PROXY setting. Can any one suggest any solution? Thanks sadhu From Milan.Slanar at fs.cvut.cz Wed Mar 24 09:22:42 2004 From: Milan.Slanar at fs.cvut.cz (Milan =?iso-8859-2?Q?Slana=F8?=) Date: Wed, 24 Mar 2004 10:22:42 +0100 Subject: Fedora Legacy Test Update Notification: openssl Message-ID: <1080120161.30571.5.camel@led.fsid.cvut.cz> openssl package for i686 is missing from 7.2/updates-testing directory! yum suggests updating only openssl-devel package for me. ... This update can be downloaded from: http://download.fedoralegacy.org/redhat/ 2647596bc3e8d0090af0ea0e9841ba665872a729 7.2/updates-testing/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm 014a4d8fec25dde48ee8f8c14cc5250afc687542 7.2/updates-testing/i386/openssl-0.9.6b-36.7.legacy.i386.rpm 2647596bc3e8d0090af0ea0e9841ba665872a729 7.3/updates-testing/SRPMS/openssl-0.9.6b-36.7.legacy.src.rpm 014a4d8fec25dde48ee8f8c14cc5250afc687542 7.3/updates-testing/i386/openssl-0.9.6b-36.7.legacy.i386.rpm c4403aff66cc3891418f2f4a5fc9632ed87c6f79 7.3/updates-testing/i386/openssl-0.9.6b-36.7.legacy.i686.rpm -- Milan Slana? Czech Technical University in Prague From boris at folgmann.de Wed Mar 24 12:11:35 2004 From: boris at folgmann.de (Boris Folgmann) Date: Wed, 24 Mar 2004 13:11:35 +0100 Subject: GIMP 2 RPM for RedHat? Message-ID: Hi! I tried to recompile the FC1-SRPM of the brandnew GIMP 2 stable release from ftp://ftp.gimp.org/pub/users/drc on a RH9 system. Problems are failed build dependencies: gtk2-devel >= 2.2.2 is needed by gimp-2.0.0-1 fontconfig-devel >= 2.2.0 is needed by gimp-2.0.0-1 I tried rpmbuild --rebuild --nodeps gimp-2.0.0-1.src.rpm, but the GTK+ test program failed, so it seems that those newer versions are really needed. Can anybody tell me how much needs to be done to do the recompile w/o upgrading the entire RH9 system to FC1? greetings, boris From sadhu at iitb.ac.in Tue Mar 30 10:22:04 2004 From: sadhu at iitb.ac.in (Nachiketa Sadhu) Date: Tue, 30 Mar 2004 15:52:04 +0530 Subject: Error message from yum update on RedHat 7.2 syatem Message-ID: <40694A4C.2070309@iitb.ac.in> Hi, I installed yum on a RedHat 7.2 system as explained in "Using Fedora Legacy's yum for Red Hat Linux 7.x" documentation. On giving the command to update, I am getting the following error message: [root at abhikalpa root]# yum update Gathering package information from servers Getting headers from: Red Hat Linux 7.2 base Error getting file http://download.fedoralegacy.org/redhat/7.2/os/i386/headers/header.info [Errno 4] IOError: [Errno socket error] nonnumeric port I am behind a proxy server, and use a HTTP_PROXY setting. Can any one suggest any solution? Thanks sadhu