Re: FreeBSD 13.0-RC5 Now Available
On 4/4/21 1:50 PM, Alan Somers wrote: > On Sat, Apr 3, 2021 at 9:34 AM Glen Barber <mailto:g...@freebsd.org>> wrote: > > The fifth RC build of the 13.0-RELEASE release cycle is now available. > > In the past, making these releases required pushing updates to > https://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/ . Historically, we often made changes directly on the update builders and then brought the svn tree back into sync later. > However, that repo is read-only now. I assume that it's been gitified, but > I can't find the new location. Where is it? I think the freebsd-update build code might be homeless right now. I know I have seen emails mentioning that it needs to land somewhere but I don't recall any decision being reached. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrade to 11.1-RELEASE fails to boot on aws EC2.
On 07/28/17 03:41, Peter Ankerst�l wrote: > It seems that FreeBSD 11.1-RELEASE also breaks on EC2 in some cases. I had > this problem before when upgrading to 11.0. This problem was noticed in the > ERRATA: https://www.freebsd.org/releases/11.0R/errata.html#open-issues > and later said to have been resolved with a EN: > https://www.freebsd.org/security/advisories/FreeBSD-EN-16:18.loader.asc > > Today I tried to upgrade a 11.0-RELEASE-p7 system to 11.1-RELEASE using the > good old build world method as described in the handbook. But after reboot > the machine hangs > in the loader. Do you know what version of FreeBSD this system was originally running? It may be that there are other oddities in the old partitioning which cause problems for the newer loader code. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
HEADS UP: Do not upgrade EC2 instances from 10.x to 11.x yet
[Apologies if anyone gets this twice; the first copy I sent seems to have been eaten by a mail server somewhere.] We've identified a bug in the loader(8) in 11.0-RELEASE (to be precise, FreeBSD 11 after April 6th) which results in it attempting to read past the end of the disk if the last partition is not aligned to a 4k boundary. On most (maybe all) physical hardware this results in significant delays to the boot while the spurious I/O fails; in Amazon EC2, this results in the instance hanging permanently. Most systems do not have such misaligned partitions, but the FreeBSD 10.x images in EC2 do, and will consequently hang on reboot if you upgrade them to 11.0 (or to 12-current, for that matter). I recommend not doing this. The AMIs which have been built for FreeBSD 11.0 have properly aligned partitions, and are not affected by this bug, so (once the release is out!) you'll still be able to get FreeBSD 11.0 by launching new EC2 instances. I imagine that this will be fixed with an errata notice shortly after the release, after which point it will be safe to upgrade (since you'll end up with the fixed loader), but as always that will ultimately be up to the release engineering team. Thanks to Peter Ankerstål, Allan Jude, Warner Losh, and Glen Barber for their help in tracking down this problem. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
HEADS UP: FreeBSD 7.3 EoL coming soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, On March 31st, FreeBSD 7.3 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of FreeBSD 7.3 are strongly encouraged to upgrade to FreeBSD 7.4, FreeBSD 8.1, FreeBSD 8.2, or FreeBSD 9.0 before the that date. Please note that due to the unexpectedly long interval between FreeBSD 8.2 and the upcoming FreeBSD 8.3, the EoL date for FreeBSD 8.2 (originaly set at February 29, 2012) has been postponed until July 31, 2012 in keeping with the policy of having a three-month upgrade window. In the unlikely event that FreeBSD 8.3-RELEASE arrives later than the end of April, the EoL dates for FreeBSD 8.1 and 8.2 will be further postponed. The current supported branches and expected EoL dates are: +-+ | Branch | Release | Type | Release date | Estimated EoL | |---+++-+-| |RELENG_7 |n/a |n/a |n/a |February 28, 2013| |---+++-+-| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |---+++-+-| |RELENG_7_4 |7.4-RELEASE |Extended|February 24, 2011|February 28, 2013| |---+++-+-| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012| |---+++-+-| |RELENG_8_2 |8.2-RELEASE |Normal |February 24, 2011|July 31, 2012| |---+++-+-| |RELENG_9 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_9_0 |9.0-RELEASE |Normal |January 10, 2012 |January 31, 2013 | +-+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9WFRoACgkQOM7KaQxqam6d1wCeL3/mYODX7++F6Z5oioJNhOfP wkYAn3/OtMkPuv5Vv4DD8RPCarhNpeS/ =mCaz -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
(8.2|7.4)-RC3 amd64 bits in place now
Hi all, I forgot to upload some of the amd64 RC3 bits to the mirrors earlier. They should be in place now. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch will also cease at the same point. Users of either of these FreeBSD releases are strongly encouraged to upgrade to either FreeBSD 7.3 or FreeBSD 8.1 before that date. The FreeBSD Ports Management Team wishes to remind users that November 30 is also the end of support for the Ports Collection for both FreeBSD 6.4 RELEASE and the FreeBSD 6.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A CVS tag will be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports CVS repository and use the RELEASE_6_EOL tag instead. The current supported branches and expected EoL dates are: +-+ | Branch | Release | Type | Release date | Estimated EoL | |---+++-+-| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |-| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |-| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |---+++-+-| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |---+++-+-| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| |---+++-+-| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012| +-+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkzONUAACgkQOM7KaQxqam6AGgCcCsVMApQTN0x0fS4yZDfvzKNS 1T4AoJp/mS24RZF6DHrLWssplNNveGcb =L3fZ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Looking for FreeBSD Update mirrors for 7.2-RELEASE
Hi all, When 7.1-RELEASE came out, FreeBSD Update was overwhelmed by the burst of traffic as thousands of people tried to upgrade at once. I'd like to make sure this doesn't happen again, so I'm looking for some extra temporary mirror capacity. If you can provide me with (a) 40 GB of disk space, (b) 1 TB of bandwidth (I expect 10+ Mbps for the first few days after the release announcement), (c) an HTTP server (or root/jail access so that I can install one myself), and (d) a firewall rule which blocks outgoing RST packets, for the month of May (depending on when the release happens, I might not need these extra mirrors beyond the middle of the month), please contact me. Extra points if you have a fast disk subsystem, since FreeBSD Update involves serving up lots of small files, and it has been disk seek limited in the past. The requirement (d) results from a bug in phttpget which (I think) caused a lot of failed attempts to upgrade systems to 7.1-RELEASE; I've fixed this bug now, but people upgrading from old releases will still have the buggy phttpget, so for now it's necessary to work around the bug by making sure that RSTs don't get sent (the buggy phttpget dies if a connection is reset instead of retrying it properly). Since I'm sure people will ask: I'm not looking for extra permanent mirrors at the moment. The FreeBSD Update mirroring code currently consists of Colin sshes into servers and copies bits around from the shell, so until I've made some improvements to that I don't really want to have any more mirrors than necessary. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD Update should be back to normal
Hi all, There are now more freebsd-update mirrors and it looks like they're handling the load quite well. It's possible that the load balancing between mirrors will need to be tweaked a bit. If you have problems accessing a mirror (e.g., if freebsd-update exits with an error of downloading files... failed or complains that a file does not exist) please: 1. Try again using the -s option to make sure that you're accessing the same mirror (to make sure that this wasn't a temporary network glitch). 2. Assuming the first mirror still fails, use the -s option to pick a different mirror. 3. Assuming that the second mirror works, send me an email telling me which mirror failed and which one worked so that I can have the load balancing adjusted. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD Update should be back to normal
Aristedes Maniatis wrote: On 09/01/2009, at 7:19 AM, Colin Percival wrote: 2. Assuming the first mirror still fails, use the -s option to pick a different mirror. Where can we find a list of mirrors? The list of is distributed via DNS SRV records: # host -t srv _http._tcp.update.freebsd.org prints a list of the mirrors (currently update1 through update4, but that is subject to change). -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD Update slow right now, please be patient
Hi all, FreeBSD Update is being slow right now due to server load issues. It will improve. Please be patient. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: freebsd-update not working from 7.1-PRERELEASE
Markus Oestreicher wrote: I installed 7.1-BETA-i386 from CD and used freebsd-update to get the latest prerelease updates. This got me to the following version: $ uname -a FreeBSD hostname 7.1-PRERELEASE-p1 FreeBSD 7.1-PRERELEASE-p1 #0: Sun Oct 5 12:15:12 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Hmm. I wonder why that's -PRERELEASE- instead of -BETA-. There might be a bug in the FreeBSD Update build code here... Fetching metadata signature for 7.1-PRERELEASE from update1.FreeBSD.org... failed. Right, FreeBSD Update thinks you're running 7.1-PRERELEASE (i.e., somewhere recent on the 7-STABLE branch, but we don't know exactly where) instead of 7.1-BETA (which is a very specific point on the branch -- specific enough that FreeBSD Update can figure out what your system should have installed and how to update it). The best solution here is to make FreeBSD Update realize that you're running 7.1-BETA: # env UNAME_r=7.1-BETA freebsd-update [...] Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: proposed change to support policy for FreeBSD Releases
jonathan michaels wrote: On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote: Some quite lively offline discussion has come to conclusion with the following suggestions to change the support policy. Obviously, this is what we feel would be a good idea, but it's obviously open to discussion and there's nobody demanding anything here. It just seems better. Thanks for the suggestions, but it might have helped to avoid confusion if you had contacted the FreeBSD security team privately before announcing your ideas here... Final The final minor release on a given branch will be supported by the Security Officer for a minimum of 24 months after the release. thank you gentle peoples for working out this solution. it has given me some much needed clarity as regards forward moving planning. No it hasn't. The FreeBSD Security team hasn't agreed to anything yet. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE panic
Kris Kennaway wrote: Petr Holub wrote: as I've said in my previous email (outside the list), I've got the kernel through freebsd-update and it seems there is no kernel.debug nor kernel.symbols present. Would it be possible to get the .symbols or .debug for that kernel? (See my previuous email with more detailed info). Ah, I missed that, sorry. Colin hopefully will have the kernel.debug handy. I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA4 Available
Ken Smith wrote: For users of FreeBSD Update due to some last-minute bumps in system libraries, installed third-party applications must be recompiled as per normal for a major upgrade, even if upgrading from an earlier 7.0 BETA. Put another way, if you want to upgrade to 7.0-BETA4, follow the instructions at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html not the simpler minor version upgrade instructions (even though that page says that the minor version upgrade instructions apply when going from 7.x to 7.x). It's irritating to have to rebuild all of the installed ports, but (unless some disaster strikes) this should be the last time it is needed until FreeBSD 8.x happens ~2 years from now. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3
Max Laier wrote: On Tuesday 04 December 2007, Colin Percival wrote: John Baldwin wrote: Considering that /etc/pf.conf is a file that users edit to configure pf(4), removing it out from under them is probably a very bad idea. The heuristics didn't work this time. :-( Yet they lose the configuration changes they might have applied to the original foo.conf. I don't think you should delete files that have changed. Maybe moving them somewhere for future reference would be the best thing to do? That is, in effect, what FreeBSD Update does -- the upgrade can always be rolled back (and /etc/pf.conf recovered) by freebsd-update rollback. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3
John Baldwin wrote: On Wednesday 28 November 2007 02:47:11 pm Colin Percival wrote: Miroslav Lachman wrote: I am not 100% sure, maybe I overlook something in binary major version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 my roots ~/.cshrc was accidentally replaced with dist version of .cshrc and /etc/pf.conf is missing. The fact that /etc/pf.conf disappeared is due to it being removed from the release (it is now in /usr/share/examples/etc). The fact that /.cshrc was upgraded in spite of having been locally modified is probably a bad idea -- I'll change the default freebsd-update.conf to deal with this. Considering that /etc/pf.conf is a file that users edit to configure pf(4), removing it out from under them is probably a very bad idea. The heuristics didn't work this time. :-( FreeBSD Update tries to guess what users want to have done -- in this case, the heuristic is if a configuration file is present in release X but not in release Y, it's probably not relevant in release Y; so let's delete it. The case of a default configuration file being moved from /etc/ into /usr/share/examples/etc is one which I didn't consider; but I think the general heuristic is a good one (consider the scenario where a /etc/foo.conf is renamed to /etc/food.conf -- with the current heuristic, at least the user gets a warning that the file is disappearing rather than suddenly finding that the foo daemon isn't starting up properly for no apparent reason). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3
Miroslav Lachman wrote: I am not 100% sure, maybe I overlook something in binary major version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 my roots ~/.cshrc was accidentally replaced with dist version of .cshrc and /etc/pf.conf is missing. The fact that /etc/pf.conf disappeared is due to it being removed from the release (it is now in /usr/share/examples/etc). The fact that /.cshrc was upgraded in spite of having been locally modified is probably a bad idea -- I'll change the default freebsd-update.conf to deal with this. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA3 Available
Ken Smith wrote: The 7.0-BETA3 builds are now available. If you would like to download an ISO image to install from they are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/arch/ISO-IMAGES/7.0/ (adjust arch to be your architecture, e.g. amd64, i386, etc.). If you would like to use cvsup to update an older machine the release tag is still RELENG_7. Due to a communications mix-up, it isn't yet possible to upgrade to 7.0-BETA3 using FreeBSD Update -- the bits are being assembled as I type this and binary upgrading to 7.0-BETA3 should work by the end of the day. For those of you who didn't read my earlier announcement and have no idea what I'm talking about, upgrading instructions are at http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html for upgrading from 6.x to 7.0-BETA3, and at http://www.daemonology.net/blog/2007-11-10-freebsd-minor-version-upgrade.html for upgrading from 7.0-BETA1.5 or 7.0-BETA2 to 7.0-BETA3. Colin Percival FreeBSD Security Officer FreeBSD Update wrangler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update 6.2-R - 6.3-B1 rollback failed
Jan Henrik Sylvester wrote: In short, as long as you don't build a custom kernel but call it GENERIC or SMP, FreeBSD Update should automatically DTRT. That is exactly my question. On 6.2-RELEASE, I sometimes used a modified ld-elf.so.1 or a single patched module without recompiling the kernel. What does using freebsd-update (accidentally or deliberately) do in that case? By accident, I discovered that it does not always fail. Does it skip the modified files, overwrite them with new versions, or overwrite them with an unpredictable bdiff merge that is likely garbage? Depending on the UpdateIfUnmodified option in freebsd-update.conf, it will either update files to clean new versions or print a warning message and not touch them. There's also an IgnorePaths directive which you can use to tell FreeBSD Update not to touch some files (even if they haven't been modified locally). FreeBSD Update will never produce mangled files as a result of applying a bsdiff patch to the wrong file -- it checks file hashes before and after applying patches and gracefully falls back to downloading complete files if it can't generate a file via patching. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADS UP] freebsd-update rollback broken on minor version upgrades
Colin Percival wrote: A quick heads-up to everyone here using my new FreeBSD Update upgrade code: If you have performed a minor version upgrade (e.g., 6.2-RELEASE - 6.3-BETA1 or 7.0-BETA1.5 - 7.0-BETA2) please do not attempt to roll it back using freebsd-update rollback. That code is currently broken and will make your system unbootable. I should have this fixed within the next couple of days. I have updated the code on my website and in the FreeBSD CVS tree. Anyone who downloads freebsd-update-upgrade.tgz from daemonology.net after this point, or anyone using the code in 6.3-RC1 or 7.0-RC1, should be able to rollback minor version upgrades successfully. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update 6.2-R - 6.3-B1 rollback failed
Jan Henrik Sylvester wrote: Colin Percival wrote: I believe that your system is now 6.3-BETA1 with a few shared libraries from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place (in fact, probably all you need is /lib/libc.so.6) your system should be ok. Let me know if you need any help with this. I guess I can download a 6.3-BETA1 cd and copy the files over from there. If you have a better way, please, let me know. That's probably the safest approach. Theoretically you could get all of the files from FreeBSD Update's database in /var/db/freebsd-update/files, but actually finding the right ones and installing them is likely to be difficult and error-prone. Getting the system back to 6.2-RELEASE might be more difficult, now that the FreeBSD Update code thinks that it has rolled back its updates, but I might be able to find a way to do that for you -- is it a disaster if this system ends up stuck at 6.3-BETA1? Not to be able to go back to 6.2-RELEASE is ok. If updating to 6.3-BETA2 (and eventually perhaps 7.0) is not possible because of the mixed system, it will limit my testing and I will have to reinstall at some point, which would not be a disaster, either. Upgrading to future releases should be fine. Once you get the libraries from 6.3-BETA1 installed again the system should be in exactly the same state as if you installed 6.3-BETA1 from the cd. Is there any cleanup to do besides replacing the libs (such as removing temporary freebsd-update directories)? You can save some disk space if you want by nuking everything in /var/db/freebsd-update/, but keeping those files will make upgrading to future releases with FreeBSD Update faster. Since your blog seems not to tell and there is no other documentation: Is freebsd-update -r supposed to work if not all files are from GENERIC/SMP? Does it skip files or overwrite them with GENERIC versions? (For security updates, the former might be desirable, but for updates between releases, only the latter would make sense to me.) FreeBSD Update does its best to handle recompiled and/or customized kernels, according to the following rules: 1. If /boot/GENERIC or /boot/SMP exist, assume that they contain a GENERIC or SMP kernel respectively (and update it accordingly). 2. If the running kernel identifies itself as GENERIC or SMP (or as SMP-GENERIC, which FreeBSD Update considers to be a synonym for SMP), assume it was built from the standard GENERIC or SMP kernel configuration. 3. If the running kernel identifies itself as something else, don't touch it. When upgrading, a couple more rules are applied: 1. If a custom kernel configuration is running, a warning message is printed telling the user to update the kernel manually before installing upgrades. 2. If the kernel configuration is one which was distributed in the current release but does not exist in the new release (e.g., FreeBSD 6.2 has GENERIC and SMP kernel configurations, but 7.0 only has a GENERIC configuration), upgrade it to a GENERIC kernel. In short, as long as you don't build a custom kernel but call it GENERIC or SMP, FreeBSD Update should automatically DTRT. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update 6.2-R - 6.3-B1 rollback failed
Jan Henrik Sylvester wrote: I tried to rollback the freebsd-update 6.2-R - 6.3-B1. To confirm that I understand what you're saying here: You upgraded from FreeBSD 6.2-RELEASE to 6.3-BETA1, then you ran freebsd-update rollback to move back to FreeBSD 6.2-RELEASE, right? It printed quite a few lines of /libexec/ld-elf.so.1: grep: Undefined symbol __sbmaskrune and /libexec/ld-elf.so.1: sort: Undefined symbol __sbmaskrune but finished with a 'done.' Ick. Right, I think I see what happened here -- the first step in the rollback process is to install the old libraries, but this overwrites the libraries currently in use by installed programs. Yep, this is definitely broken -- ironically, it works fine for rolling back from FreeBSD 7.x to FreeBSD 6.x, since installing the old libraries doesn't involve overwriting the newer ones. I'll get this fixed ASAP. I guess it was my fault, because on some of my 6.2 machines I had a patch for libexec/rtld-elf/rtld.c adding the symbol _dlsym that was needed for linux-flashplugin-7 at some time. This was probably one of these machines that had a GENERIC/SMP kernel but modified elf loader. Nope, not your fault -- I screwed up the rollback code. Now, how do I get this machine running again? I believe that your system is now 6.3-BETA1 with a few shared libraries from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place (in fact, probably all you need is /lib/libc.so.6) your system should be ok. Let me know if you need any help with this. Getting the system back to 6.2-RELEASE might be more difficult, now that the FreeBSD Update code thinks that it has rolled back its updates, but I might be able to find a way to do that for you -- is it a disaster if this system ends up stuck at 6.3-BETA1? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[HEADS UP] freebsd-update rollback broken on minor version upgrades
A quick heads-up to everyone here using my new FreeBSD Update upgrade code: If you have performed a minor version upgrade (e.g., 6.2-RELEASE - 6.3-BETA1 or 7.0-BETA1.5 - 7.0-BETA2) please do not attempt to roll it back using freebsd-update rollback. That code is currently broken and will make your system unbootable. I should have this fixed within the next couple of days. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. As promised, instructions on upgrading from FreeBSD 6.x to 7.0-BETA2 are now available: http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html Colin Percival FreeBSD Security Officer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3-BETA1 available
Ken Smith wrote: The 6.3-BETA1 builds got delayed a bit by a last minute MFC causing some undesired ABI breakage. That has been fixed and the 6.3-BETA1 builds for amd64, i386, pc98, and sparc64 have completed. Instructions on using FreeBSD Update to upgrade i386 and amd64 systems running FreeBSD 6.x to 6.3-BETA1 are now available: http://www.daemonology.net/blog/2007-11-10-freebsd-minor-version-upgrade.html Instructions on using FreeBSD Update to upgrade to 7.0-BETA2 should be here within 24 hours. Colin Percival FreeBSD Security Officer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2 EoL =~ s/January/May/
FreeBSD Security Officer wrote: Hello Everyone, In light of the longer-than-expected window between 6.2-RELEASE and 6.2-RELEASE, ^^^ This should read between 6.2-RELEASE and 6.3-RELEASE, of course... the End-of-Life date for FreeBSD 6.2 has been adjusted from January 31st, 2008 to May 31st, 2008. As a result, FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2 will all cease to be supported at the end of May 2008. FreeBSD users should plan on upgrading to either FreeBSD 6.3 or FreeBSD 7.0 once those have been released (hopefully by the end of December). FreeBSD 6.3 will be supported until the end of 2009, while FreeBSD 7.0 will be supported until the end of 2008. Colin Percival FreeBSD Security Officer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
Bruce A. Mah wrote: We've done point releases in the past but only in cases where there were severe problems and/or regressions with released versions. Look at the announcements and release notes for 4.6.2-RELEASE and 5.2.1-RELEASE...these were the two most recent instances where we did this. There's a reason for this...it's a lot of effort. Folks should realize that making a new release (even a new point release) is not just a matter of tagging the tree and typing make release. We (re@) need to figure out exactly what bugs are to be fixed, get the changes merged and tested, build at least one release candidate, get that tested, and finally build a set of RELEASE bits and push them out. I point releases have been obsoleted by errata notices. In the past when X.Y.Z-RELEASE has happened, it has been because of critical bugs in the X.Y-RELEASE which there wasn't any other mechanism to fix. Now that we have errata noticed and FreeBSD Update is in the base system, it's vastly easier for users to run freebsd-update fetch install than it is for them to upgrade to a new release. PS. This having been said I know there are some kernel fixes that were candidates for errata against 6.2-RELEASE...I'm not sure what their current state is. Don't ask me, I just approve the errata which you send to me. Which hasn't been anything at all lately. :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release cycle
Scott Long wrote: Colin Percival wrote: I point releases have been obsoleted by errata notices. In the past when X.Y.Z-RELEASE has happened, it has been because of critical bugs in the X.Y-RELEASE which there wasn't any other mechanism to fix. Now that we have errata noticed and FreeBSD Update is in the base system, it's vastly easier for users to run freebsd-update fetch install than it is for them to upgrade to a new release. Not really. 5.2.1 existed because people were having problems getting 5.2 installed on their ATA disks. If you have big problems with storage or network, freebsd-update isn't going to be of much use to you. Good point, I was forgetting exactly what the problems were that time. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote: - Original Message - From: John-Mark Gurney [EMAIL PROTECTED] Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? The file is correct when extracted but gtar is, as you say, throwing an error because of the tar format. The exit error is the issue as in a scripted environment, as we have, the error causes the failure of the whole operation. GNU tar is broken. POSIX specifically allows for vendor extensions (such as the SCHILY.* extensions which were introduced by star), and the correct way to handle them is by printing a warning message, ignoring the extension, and not treating it as an error. You can work around gtar's breakage by explicitly telling it to ignore these options via --pax-option=delete=SCHILY.* . Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote: When compressing files with specific filenames it appears that BSD tar is creating invalid archives which when handed to gnutar to ^ expand it errors with the following: [log] tar -xvzf test.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' cantiquedeno\353l1_loop.wav tar: Error exit delayed from previous errors [/log] This looks like fairly typical symptoms of gnutar being broken. What makes you think that the archive created by BSD tar was invalid? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote: - Original Message - From: Colin Percival [EMAIL PROTECTED] tar -xvzf test.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' cantiquedeno\353l1_loop.wav tar: Error exit delayed from previous errors This looks like fairly typical symptoms of gnutar being broken. What makes you think that the archive created by BSD tar was invalid? As a filename should have no bearing on what extended headers are set. Why not? In this case, bsdtar is detecting that the file name contains non-7-bit-ascii characters and is emitting a pax header for that reason; and since it can't suppress the pax header entirely, it goes ahead and emits the not vital but potentially useful headers for the device #, inode #, number of links, and high precision timestamps. I still see no evidence that bsdtar is doing anything wrong. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update weirdness
Joao Barros wrote: I just finished installing my new silent router with 6.2R and took freebsd-update for a spin... C3# uname -a FreeBSD C3.bsdtech.org 6.2-RELEASE-p2 FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:41:06 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 C3# freebsd-update fetch [...] No updates needed to update system to 6.2-RELEASE-p3. This may look odd, but it's actually correct. The version number reported by `uname` is the version number of the kernel, and the change from 6.2-RELEASE-p2 to 6.2-RELEASE-p3 didn't affect the kernel. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update problem (on 6.2)
Miroslav Lachman wrote: I did cvsup to RELENG_6_2 today and make build(world|kernel) install(kernel|world) After mergemaster reboot uname reports 6.2-RELEASE-p3 but `freebsd-update fetch` downloads patches to 6.2-RELEASE-p3 so I installed them by `freebsd-update install`. uname reports 6.2-RELEASE-p2 after reboot! This is correct. uname(1) reports the kernel version, and the change from 6.2-RELEASE-p2 to 6.2-RELEASE-p3 did not affect the kernel. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /etc/rc.d/jail This is correct. The version you have here is not the version which was distributed with the release -- it's the version in the latest RELENG_6_2. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update problem (on 6.2)
Don O'Neil wrote: Can I use freebsd-update to update from 6.1-STABLE-200608 to the latest version? When I try to run the program it says its not compatible... Is there a way to force it to update anyway Only by editing the freebsd-update script or by modifying uname(1). and is there any reason I would NOT want to force it? In general it's a bad idea, since FreeBSD Update looks at what files you had installed from the old release and whether you've modified any of them in order to decide how to upgrade to the new release. If you confuse freebsd-update enough to convince it to upgrade your non-supported installation, it's likely to overwrite modified configuration files or not update files. I'm just trying to figure out the best way to get my machine updated, which was installed from a snapshot ISO, without having to do a buildworld. There isn't any good solution here, yet. I might add support for the snapshot ISOs at some point (at least for upgrading to/from them -- there will not be security updates built for them). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update changes kernel to SMP-GENERIC
Jan Henrik Sylvester wrote: Before the last freebsd-update, I had a GENERIC kernel installed. Are you sure? :-) Now 'uname -v -i' gives me: FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:56:09 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP SMP-GENERIC Did something go wrong? What does `sysctl kern.bootfile` say? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ANNOUNCE: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-07:05.freebsd-update
Sohgo Takeuchi wrote: I found some typos in the document of FreeBSD-EN-07:05.freebsd-update. Thanks, I'll upload a fixed advisory to the web server. - src/UPDATING 1.416.2.29.2.5 - src/sys/conf/newvers.sh 1.69.2.13.2.5 + src/UPDATING 1.416.2.29.2.6 + src/sys/conf/newvers.sh 1.69.2.13.2.6 I guess I ought to update my CVS tree before using it to figure out the RCS numbers... :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update ignores /boot/kernel/kernel sometimes!?
Andy Hilker wrote: Somehow freebsd-update find /boot/kernel/kernel on some servers and patches it and on others not. Additional info: it seems that all machines where it does not work, have an SMP-GENERIC (i386) installed. There's a bug in how FreeBSD Update handles /boot/kernel. Basically, it's supposed to figure out if you're running a GENERIC or SMP kernel, and get the appropriate updates based on that; but I incorrectly assumed that the SMP kernel would identify itself as SMP. Instead, the i386 SMP kernel identifies itself as SMP-GENERIC, while the amd64 SMP kernel identifies itself as GENERIC, with the result that (a) On FreeBSD 6.2 i386 systems running an SMP kernel from /boot/kernel, the kernel will not be updated, and (b) On FreeBSD 6.2 amd64 systems running an SMP kernel from /boot/kernel, the kernel will be replaced with a GENERIC (non-SMP) kernel. I'm working on a patch for this and will be talking to re@ about having an Errata Notice sent out about this. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1 to 6.2 freebsd-update binary upgrade on amd64
Jim Howard wrote: I've used the 6.0 to 6.1/6.1 to 6.2 upgrade scripts on several i386 machines (from here: http://www.daemonology.net/blog/2006-11-26-freebsd-6.1-to-6.2-binary-upgrade.html) and it has worked flawlessly- and so easy! Today I updated a new amd64 server from 6.1 to 6.2 and after the process completed, I noticed that I ended up with a GENERIC kernel instead of SMP like I had before. This is a known bug. In short, the FreeBSD Update script uses `uname -i` to figure out if you have a GENERIC or SMP kernel installed; this works fine on i386, but for some reason the amd64 SMP kernel has an ident of GENERIC. This will be fixed before FreeBSD 6.3. If I were to roll back the update with freebsd-update, would I have do to it twice- once for the userland updates and once for the kernel? No, just one rollback run should be sufficient. Downgrading is easier than upgrading, since you don't start running the new kernel until you reboot. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update from 6.1 RELEASE to 6.2 RELEASE: directory creation caused failure.
Brian King wrote: I'm writing this email from a freebsd 6.2 system, but it was a rocky upgrade for me. I followed the process outlined at http://www.daemonology.net/blog/2006-11-26-freebsd-6.1-to-6.2-binary-upgrade.html to upgrade my GENERIC i386 kernel and userland. I had changed some configuration files, and when notified about it, i created a directory /usr/upgrade/newfiles and downloaded the appropriate copies of these files from the cvs into this directory. Oops. # sh freebsd-update.sh -f freebsd-update.conf -d /usr/upgrade install Installing updates...freebsd-update.sh: cannot create newfiles: Is a directory rm: newfiles: is a directory Yeah, you're not supposed to do that. In fact, it never occurred to me that someone would do that, largely because the FreeBSD Update working directory (/usr/upgrade in this case) is normally /var/db/freebsd-update. But since people upgrading from FreeBSD 6.1 don't have FreeBSD Update installed as part of the base system (and thus don't have the normal working directory) I added the flag to tell FreeBSD Update to use a different directory instead. Suggestion for the developer: either permit directory creation in /usr/upgrade, or document that it's a no-no. It will be documented. :-) Thanks, Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Hello Everyone,
I usually let security advisories speak for themselves, but I want to call
special attention to this one: If you use jails, READ THE ADVISORY, in
particular the NOTE WELL part below; and if you have problems after applying
the security patch, LET US KNOW -- we do everything we can to make sure
that security updates will never cause problems, but in this case we could
not fix the all of the security issues without either making assumptions
about how systems are configured or reducing functionality.
In the end we opted to reduce functionality (the jail startup process is
no longer logged to /var/log/console.log inside the jail), make an assumption
about how systems are configured (filesystems which are mounted via per-jail
fstab files should not be mounted on symlinks -- if you do this, adjust your
fstab files to give the real, non-symlinked, path to the mount point), and
leave a potential security problem unfixed (if you mount any filesystems via
per-jail fstab files on mount points which are visible within multiple jails,
there are problems -- don't do this).
While this is not ideal, this security issue was extraordinarily messy due to
the power and flexibility of the jails and the jail rc.d script. I can't
recall any other time when the security team has spent this long trying to
find a working patch for a security issue. I'd like to publicly thank Simon
Nielsen for the many many hours he spent working on this issue, as well as
the release engineering team for being very patient with us and delaying the
upcoming release to give us time to fix this.
Sincerely,
Colin Percival
FreeBSD Security Officer
FreeBSD Security Advisories wrote:
=
FreeBSD-SA-07:01.jail Security Advisory
The FreeBSD Project
Topic: Jail rc.d script privilege escalation
[snip]
NOTE WELL: The solution described changes the default location of the
console.log for jails from /var/log/console.log inside each jail to
/var/log/jail_${jail_name}_console.log on host system. If this is a
problem, it may be possible to create a hard link from the new position
of the console log file to a location inside the jail. A new rc.conf(5)
variable, jail_${jail_name}_consolelog, can be used to change the
location of console.log files on a per-jail basis.
In addition, the solution described below does not fully secure jail
configurations where two jails have overlapping directory trees and a
file system is mounted inside the overlap. Overlapping directory
trees can occur when jails share the same root directory; when a jail
has a root directory which is a subdirectory of another jail's root
directory; or when a part of the file system space of one jail is
mounted inside the file system space of another jail, e.g., using
nullfs or unionfs.
To handle overlapping jails safely the administrator must set the
sysctl(8) variable security.jail.chflags_allowed to 0 (the default)
and manually set the sunlnk file/directory flag on all mount points
and all parent directories of mount points. If this is done while
jails are running, the adminstrator must check that an attacker has
not replaced any directories with symlinks after setting the sunlnk
flag.
[snip]
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-07:01.jail.asc
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
Philipp Wuensche wrote:
Colin Percival wrote:
In the end we opted to reduce functionality (the jail startup process is
no longer logged to /var/log/console.log inside the jail)
Thats a bummer, when Dirk showed me this problem the first time my ideas
for fixing this problem without losing the functionality where changing
flags on the file so it can't be removed or/and checking if it is really
a file or a symlink instead. Of course you have to check if /var/log has
symlinked parent directories before.
First is quite problematic and setting flags on file is something
scripts which create a jail in the first place probably have to bother
with so option two would be my approach. Did I miss a possible problem
with that idea?
Assuming that option two means use file flags to make sure that the host
can write to the jailed /var/log/console.log securely, setting the sunlnk
flag on the jail's /var and /var/log would probably break many jails -- for
one thing, log rotation would become impossible. Then there's the problem
of systems with chflags_allowed=1...
(filesystems which are mounted via per-jail
fstab files should not be mounted on symlinks -- if you do this, adjust your
fstab files to give the real, non-symlinked, path to the mount point), and
If I understand the patch correct it checks recursive all parent
directories of a mountpoint in is_symlinked_mountpoint(), wouldn't it be
better to just check for a symlinked parent directory up to and not
including ${_rootdir}?
This option never occurred to me; I _think_ it would work, but it would require
canonicalizing the jail root path... even if I had thought of this, I might
have decided to avoid this on the basis that complexity == bugs == bad for
security patches.
Colin Percival
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 Release
Scott T. Hildreth wrote: Does anyone know if the Release is still going to happen today? The release is not going to happen today, but will be very soon. My guess is that builds and mirroring will happen over the weekend and the release announcement will go out on Monday or Tuesday depending upon your time zone. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibility for FreeBSD 4.11 Extended Support
John Smith wrote: Support for FreeBSD 4.11 is going to end sometime in late January. Originally, FreeBSD 6.2 was supposed to be released back in October. This would have given everyone about 3 months to stress test everything and migrate all their boxes from 4.11 direct to 6.2. You've had three months to stress test 6.2-BETA1, 6.2-BETA2, 6.2-BETA3, and 6.2-RC1. We release these for a reason, you know. Now it is near the end of December, and FreeBSD 6.2 RC2 has yet to be seen anywhere. Chances are that FreeBSD 6.2 Release will come out earliest mid-January. This does not give much time for people to migrate to the newest FreeBSD release. I think it would be fair if support is extended for a few more months especially since 6.2 is so late in coming. Your opinion has been noted. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update to track release engineering
Petr Holub wrote: To avoid repeating myself too many times, I'm just going to point to my latest blog entry: http://www.daemonology.net/blog/2006-11-26-freebsd-6.1-to-6.2-binary-u pgrade.html I've tested it (ok, one day later than I assumed) and resulted in a kernel panic after reboot when attempting to start mountd. Basically it looks like the new kernel hasn't been installed (/boot/kernel/kernel is dated Aug 30). That's strange. May it be because I'm tracking 6.1-SECURITY using freebsd-update and the binary diff fails then? That shouldn't be the case; I've used this script on lots of other systems which were running FreeBSD Update, and when files can't be generated by using a binary patch, the script just downloads the entire file instead. Assuming you still have the files in the script's working directory (/usr/upgrade, if you followed my blog post line for line), could you look for a directory named something-install or something-rollback and send me the INDEX-OLD and INDEX-NEW files from there? Hopefully that will let me figure out what went wrong... Maybe just an idea for improvement: it would be helpful if you can put the update candidates for changed config files (/etc) into /etc/upgrade in a way binary update from sysinstall does that. I understand why you want to avoid doing mergemaster from your script, but it would be fine to have the files at least ready so that user can diff them and decide what to do. I'm planning on adding automatic merging of configuration files soon. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update to track release engineering
Colin Percival wrote: Petr Holub wrote: I'm working on it. If I install RC1 now, would it be possible to upgrade to RC2 and RELEASE, or is it not ready yet? My intention is that anyone running 6.1-RELEASE, 6.2-BETA*, or 6.2-RC* will be able to upgrade to the latest release candidate or release. To avoid repeating myself too many times, I'm just going to point to my latest blog entry: http://www.daemonology.net/blog/2006-11-26-freebsd-6.1-to-6.2-binary-upgrade.html Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update to track release engineering
Petr Holub wrote: I'm working on it. If I install RC1 now, would it be possible to upgrade to RC2 and RELEASE, or is it not ready yet? My intention is that anyone running 6.1-RELEASE, 6.2-BETA*, or 6.2-RC* will be able to upgrade to the latest release candidate or release. I haven't worked out all the details yet as to how this should be done to minimize the chance that my script will accidentally break things, but I'm not going to release anything until I think that accidental breakage is very unlikely. :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: daemonology.net instructions - binary upgrade 5.3 to 6.1
Hans F. Nordhaug wrote: At daemonology.net Colin Percival has some excellent instructions on how to do binary upgrades - he has even written a script to do a 6.0 to 6.1 upgrade. My question is: Can I do a 5.3 to 6.1 upgrade using the instructions for 5.4 system to FreeBSD 6.0 - see http://www.daemonology.net/freebsd-upgrade-5.4-to-6.0/ Or, should I upgrade 5.3 to 6.0 and finally use the script to get from 6.0 to 6.1? I assume the former, but just want to be sure. Either option will probably work; but I've never done a 5.3-6.0 binary upgrade directly, so I can't guarantee that it will work. :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EV1 Servers makes me sick
Randi Harper wrote: On 10/3/06, Daniel Gerzo [EMAIL PROTECTED] wrote: also layeredtech.com is pretty good. Props to layeredtech. In the 20 months for which layeredtech has been providing free hosting for FreeBSD Update, one of the two Portsnap mirrors, and my personal website, I haven't had any complaints. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EV1 Servers makes me sick
Eduardo Meyer wrote: if your server is re-imaged with 6.0 vs the 5.4 version currently installed we will not be able to support this. We have found that the versions after 5.4 are inherantly unstable. Please let us know what course of action you would like to take. EV1Servers has never been a major supporter of FreeBSD -- back when they were RackShack, it took a petition of several hundred people before they started offering FreeBSD at all. I wonder if they'll start offering more recent FreeBSD releases next month after FreeBSD 5.4 becomes unsupported... Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
Christer Solskogen wrote: /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dh/dh_err.c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dh/dh_err.c:81: error: `DH_R_MODULUS_TOO_LARGE' undeclared here (not in a function) Looks like you don't have an updated dh.h yet. Try running cvsup again, maybe from a different mirror. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
Christer Solskogen wrote: I've tried norway's mirror (my default), the danish, the swedish mirror and the mirror in holland. No change. Just to be sure I also deletet src/crypto before I tried the different mirrors. Exactly what command did you run to try to compile this? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2-BETA1 Available
Massimo Lusetti wrote: On Wed, 2006-09-20 at 12:12 -0400, Ken Smith wrote: - FreeBSD Update, a binary security update tool, was recently imported into the FreeBSD base system, and the FreeBSD Security Team is building binary security updates for the i386 platform. Users are encouraged to test this. That's a perfect situation for testing this new feature, I'll test this as soon as binary security updates goes public. FreeBSD Update is public; if you are running a system which identifies itself as i386 running FreeBSD 6.2-BETA1, FreeBSD Update should be able to fetch the updates right now. If it doesn't, something is broken, and I'd like to hear about it. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Michael Abbott wrote: Damn, I'm confused now. Let me try and get this straight: CURRENT This is, by definition, broken a good part of the time, and is what it says, namely current, ie work in progress. Yes. STABLE This is broken some of the time and .. uh .. isn't really all that stable, actually. STABLE means you can update FreeBSD along this branch without needing to recompile applications or kernel modules. This means that companies can ship binary drivers for their hardware and say this driver will work on FreeBSD 6.x (which isn't possible on Linux). The fact that there are occasionally bugs introduced... well, that's an inevitable consequence of the stable branches being development branches. RELENG_n_m This is completely stable and only tracks security fixes. Security fixes and critical errata. The requirements for something being committed to such a branch after the release are that: 1. It must be an important bugfix, and 2. I must be absolutely certain that nothing bad will ever happen as a result of someone updating a FreeBSD n.m system to the latest updates on RELENG_n_m. RELENG_n (RELENG_6 at the moment) Has somebody just said that RELENG_6 = STABLE? Yes. I'm going to guess then that RELENG_7 is CURRENT. No, this doesn't make sense to me at all. RELENG_7 doesn't exist yet. RELENG_7 will be 7-STABLE once it exists, some time in 2007. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 ETA
Bryan Fullerton wrote: So... the releng web page indicates that RELENG_6 is frozen as of August 25th pending a 6.2R release on October 9th. I'm guessing, since there seem to still be lots of commits and there's no /releases/6.2R/ doc tree on the FreeBSD site, that these dates are no longer accurate. What is a valid ETA for starting the 6.2R releng process? I'm not part of the release engineering team, but I'm not aware of anything which they're waiting for before starting the freeze. I'd be surprised if RELENG_6 isn't frozen by this time next week. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.0-6.1 binary upgrade script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear FreeBSD 6.0 users, Those of you who read my blog (http://www.daemonology.net/blog/) will have seen this already; but for those of you who don't: I have written an automatic script for performing binary FreeBSD 6.0 - FreeBSD 6.1 upgrades. This script will install exactly the same files as are distributed on the ISO image, and it will attempt to automatically merge configuration file changes (in the very unlikely case that it cannot automatically merge changes, it will ask you to merge the changes for it). The script takes approximately 15 minutes, and typically downloads under 20MB of files and binary patches. Naturally, the cryptographic hashes of all the files are verified against values stored in the script, so as long as you trust the FreeBSD Security Officer (and if you don't, why are you running FreeBSD?), the process is entirely secure. The script can be obtained from http://www.daemonology.net/freebsd-upgrade-6.0-to-6.1/ and the SHA256 hash of the download is 29075fc5711e0b20d879c69d12bbe5414c1c56d597c8116da7acc0d291116d2f . Colin Percival FreeBSD Security Officer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEsLNnMt4ezdCTR/wRAmRUAKDQFOFxK3y58/vy0Vzx8sov8synWgCg4sYG UfDhAxNjWRq7+zawVvM8cp0= =3gBy -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-6.1 binary upgrade script
Peter Jeremy wrote: On Sun, 2006-Jul-09 00:42:31 -0700, Colin Percival wrote: I have written an automatic script for performing binary FreeBSD 6.0 - FreeBSD 6.1 upgrades. That sounds useful. Are you intending to provide this for future FreeBSD minor-revision releases? Yes. This is made much easier by the work I'm doing rewriting FreeBSD Update. But how can I tell that the script came from the FreeBSD Security Officer? You have signed your mail with a key (ID 0xD09347FC) that claims to be a Colin Percival with an Oxford Uni address (whereas this mail has a freebsd.org address) but the key that I downloaded from a PGP keyserver has no other signatures. You don't have a key in the FreeBSD CVS repository that I can locate Oops. I really ought to add my key there some day -- it hasn't mattered until now since I've always signed security-related emails with the SO key. Here's my PGP public key, which you will note is signed with the FreeBSD Security Officer key. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.3 (FreeBSD) mQGiBD5ST1YRBADxgAihxhkd5+87xPxAD3OvMzKKrAhWX9VPaABzjrQmDJrJ0cyb Boa6+aHlnaFZYEIv7DVDylNg5aUDRRDJOrKeWnSXs9Kizg9+ek/3V6202Z5mZiBG YjShN2nhApkTHTN0QfogOEXmY9BHzJzHix75fJZ5wk4q4X28FKVCReoeAwCg/2p/ rgnDBQFkJy/0Lnj6MZQw2KkEAKQ/nNK/KlKNlfA5KAuqS16l1WQKgOP+ispUoaVN arhTU7NCB+UKBAJHPQVeVAe+UvgeUhjh7psCp9C1Au0hmxnpluF1ljknRUzF2WlX ql38/1cHT2RxHr9i/fG8hHQCQkRLp1k01n7rVTzXX3j/K0V+CVbGWIJK7h47ceEL 4tk9A/0T7H1vCeuiu50aMDaigCOmd1XQb+dZlEs50mzLlC1mwtTodRBLqo3Ol78R nZ7DN73AHH7w2197kJ0I10dA6Q5MpScfXKUtnUuItSxv59E9O7SDus6ya77L0lCR cooYL49EuB/pwL/P+c/p+Ki9TmzauGE3Wji6gDH7kH/aVMFwwbQvQ29saW4gUGVy Y2l2YWwgPGNvbGluLnBlcmNpdmFsQHdhZGhhbS5veC5hYy51az6IWAQQEQIAGAUC PlJPVggLCQgHAwIBCgIZAQUbAwAKCRAy3h7N0JNH/EDpAKDEN7HNTjpDEf0K hlVxk8c868mrLwCcDDQ7TEi4XqeonghuoWYRE/oooq+IRgQQEQIABgUCQnhSngAK CRAV1ogEymzfsiShAJ4yFvxZXVWbuzG9lyZLgoUVeQ55FACfeVwS0Clf+93BByQq U0E8HE4rXsm0JUNvbGluIFBlcmNpdmFsIDxjcGVyY2l2YUBmcmVlYnNkLm9yZz6I TwQQEQIADwUCQSYZ3AgLCQgHAwIBCgAKCRAy3h7N0JNH/JU9AKCZEbOE4KD5FRmz xUhoJRJOKS6prwCeNNqyRB+lTg9006K7LAgMLYuUrDuIRgQQEQIABgUCQnhSpQAK CRAV1ogEymzfsivAAJ97Vk22Grq9IrmnKfQY3DHlReLBrQCeO7KaNWoct9y8t2FG pAiqEM02Kl25Ag0EPlJPVhAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg 2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvO meFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YA WCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtV jLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIIAPIwHNo3BY8l 8T54p1GbRXqGxw10B7/wuxc6XgdfDfJOMOjn48+O0LNwyWXWLPR5apGaqlubzG+O okQNP8okLQ5W6vRh09/Y3XfAlHh5nx5bwEFOmrRJPKvyZIY/KjvAA8PAgCIRKVfH IzUqvXbjESrzMuskkxoVRVyrx52FHx6XqQWGY+DJJV9VFDSxzwfq9K4JHQ3yRm7G 75hrPXUB8VC28mOLCEwwkKNyh9PQj27PEwjErPLJ0gKkkK0cfnvcv6pMBkRAHfL7 RqM4Z4yqqfaofS3B50Nr6dvpPx2Xyus3y03Zr9QZuKfFVYJ6Gb3oZuJnRXT5XIwD 5Fiw/V3xaD6ITAQYEQIADAUCPlJPVgUbDAAKCRAy3h7N0JNH/BntAKD/JPN0 g8NrWUVUfiKonbtL1vgMEgCdH+G2T8UJC2wyRTdp4+Io42+tsA0= =7ABx -END PGP PUBLIC KEY BLOCK- Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.5 Released
Ken Smith wrote: BitTorrent -- 5.5-RELEASE ISOs are not available via BitTorrent at this time. They may be made available in the future on an on-demand basis. Thanks to ps, torrents are now available for 5.5-RELEASE: http://torrents.freebsd.org:8080/ Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Security Survey
Dear FreeBSD users and system administrators, While the FreeBSD Security Team has traditionally been very good at investigating and responding to security issues in FreeBSD, this only solves half of the security problem: Unless users and administrators of FreeBSD systems apply the security patches provided, the advisories issued accomplish little beyond alerting potential attackers to the presence of vulnerabilities. The Security Team has been concerned for some time by anecdotal reports concerning the number of FreeBSD systems which are not being promptly updated or are running FreeBSD releases which have passed their End of Life dates and are no longer supported. In order to better understand which FreeBSD versions are in use, how people are (or aren't) keeping them updated, and why it seems so many systems are not being updated, I have put together a short survey of 12 questions. The information gathered will inform the work done by the Security Team, as well as my own personal work on FreeBSD this summer. If you administrate system(s) running FreeBSD (in the broad sense of are responsible for keeping system(s) secure and up to date), please visit http://people.freebsd.org/~cperciva/survey.html and complete the survey below before May 31st, 2006. Thanks, Colin Percival FreeBSD Security Officer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.11 snapshots?
If you absolutely must run FreeBSD 4.11, install the RELEASE and then run FreeBSD Update. Personally, since FreeBSD 4.11 will reach its EoL about 8 months from now, and the 4.x-[56].x upgrade path is non-trivial, I recommend installing FreeBSD 6.1 instead. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap mirror servers
Paul Mather wrote: On Fri, 2006-04-21 at 14:40 +0200, Benjamin Lutz wrote: Hm, but I see a quite noticeable speed difference between portsnap1 and portsnap2. The second one is quite a bit faster. I'll look into this over the summer. I notice that on 4.x portsnap never finds any mirrors because the grep of the output returned by host -t srv ... is not appropriate for 4.x's version of /usr/bin/host, which produces output different to that of 5.x onwards (a BIND8 vs BIND9 issue, I guess). So, maybe because of this, all of the portsnaps running on 4.x machines are hitting the same server each time instead of randomly choosing a mirror, thereby causing that mirror to be a bit more loaded? They are hitting the same server, but that server is portsnap2 (which is also portsnap.daemonology.net, which is the default server for pre-1.0 versions of portsnap from the ports tree). Given that most systems running portsnap are FreeBSD 6.0 or 6.1, this doesn't cause much differential loading. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap mirror servers
Chris wrote: How many mirrors does portsnap have, it seems to only have around 3 or 4 and they all located in the .us whilst cvs has dozens around the world. Two mirrors, actually: portsnap1.freebsd.org, and portsnap2.freebsd.org. Is there a eu pool of mirrors available to use or if not is their a way I can apply to host an eu mirror or even 2 eu mirrors. I have a list of people who have offered mirrors, but so far I haven't seen any need for additional mirrors -- the two which already exist are showing no signs of slowing down. Why do you think there should be an .eu mirror? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1-RC1 Available
Scott Long wrote: The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.1-RC1. ^^^ Just to check that I understand the numbering: The src tree says 6.1-RC on both RELENG_6 and RELENG_6_1, but you built the release images with the number set to 6.1-RC1? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 2.2.9 Released
Silves wrote: On Sat, 2006-Apr-01 13:25:59 -0700, Scott Long wrote: ^^^ It is my great pleasure and privilege to announce the availability of FreeBSD 2.2.9-RELEASE. I have just one curious question, why is FreeBSD 2.2.x still being developed ? This is maybe a stupid question, but i am only curious to know why ? Is there any special reason for this ? Look at the date on Scott's email. :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I turn off hyperthreading on 6.0 ?
Pete French wrote: I have: websvr04# sysctl machdep.hlt_logical_cpus machdep.hlt_logical_cpus: 1 but I am still seeing 4 CPU's as I have two physical processors, each with two logical ones onboard. The way machdep.hlt_logical_cpus works is by telling the scheduler to ignore the extra logical processors, not by pretending that the extra logical processors don't exist at all. (This was necessary to ensure that interrupts could still run on the extra threads -- otherwise some problems appeared with broken BIOSes which couldn't route interrupts correctly.) If you look at top(1), which processors do you see actually running processes? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How do I turn off hyperthreading on 6.0 ?
Pete French wrote: If you look at top(1), which processors do you see actually running processes? Errr, 0, 1, 2 and 3! What do # sysctl machdep.hlt_cpus # sysctl machdep.logical_cpus_mask # sysctl machdep.hyperthreading_allowed say? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Brian Candler wrote: I think the real concern here is: for how long after RELEASE_X_Y are binary patches for it made available? I build FreeBSD Update patches for all the branches supported by the FreeBSD Security Team. To answer a couple of other questions: FreeBSD Update is something which I _personally_ support; it isn't supported by the _project_, because at the moment there isn't anyone else who could take over running it if I get hit by a bus. Re the long list of requests people have made (starting with amd64 support and make this officially supported by the project), I'll get to those as soon as I have time. Sadly, I have a pesky thing called a full time job and my FreeBSD time has been occupied with portsnap lately. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What should be in GENERIC? (was Re: Facilitating binary kernel upgrades)
Robert Watson wrote: On Tue, 8 Nov 2005, Colin Percival wrote: I find this argument hard to accept. The vast majority of FreeBSD users will never need the NFS_ROOT option, and many systems do not even have the hardware for serial or parallel ports, yet those are supported in the GENERIC kernel. While I agree with you in principle, I think many people would disagree with your assertion about serial ports :-). Let me rephrase: Many people who run GENERIC kernels don't have hardware which supports serial ports. I'm not concerned about the people who run hundreds of headless servers, since they typically build their own kernels anyway. With regard to the specific three kernel options mentioned above: [snip] I should have known that you'd be able to explain why these options aren't enabled in the GENERIC kernel. Thanks for the explanations. Now I'll run off to install 6.0 on my NAT system so that I can run a GENERIC kernel on it again. :-) Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
What should be in GENERIC? (was Re: Facilitating binary kernel upgrades)
Tom Grove wrote: Richard Bejtlich wrote: After speaking with Colin, he mentioned that IPSec, NAT, and disk quotas (enabled via options QUOTA) are the three most popular kernel changes that prevent people from running GENERIC and hence using freebsd-update for binary kernel updates. Can anyone shed light on why those three features are not available in GENERIC? My guess is that just because those are the three most popular kernel changes that prevent people from running GENERIC doesn't mean that the majority of users implement these changes. I find this argument hard to accept. The vast majority of FreeBSD users will never need the NFS_ROOT option, and many systems do not even have the hardware for serial or parallel ports, yet those are supported in the GENERIC kernel. In deciding what options should go into the GENERIC kernel, I think the question we should be asking is not how many people use this?, but instead would adding this option inconvenience more people than it would help?. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to update to the security advisories
Roger Grosswiler wrote: i look since a long time, but i did not find. Is there a howto somewhere, how i have to go through the update for the security advisories? Thanks for any links, hints, ideas, comments and hot coffees :-D Each advisory has either instructions or a URL to instructions in the handbook on how to download and apply patches to your source tree and rebuild the affected parts of the base system. For a solution which is easier but not as supported (i.e., it's something I'm providing personally, rather than something the FreeBSD Security Team provides and supports), you might like to try FreeBSD Update (http://www.daemonology.net/freebsd-update, or security/freebsd-update in the ports tree). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall automatic filesystem size generation.
C. Michailidis wrote: Remember, I'm talking about the 'path of least resistance', I understand that I could label the slice manually with any number of different configurations. The issue I was hoping to shed some light on is... Can the auto-configuration mechanism stand to be improved?. Is it reasonable (in today's era of dirt cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by default? The default sizes are now currently 512 MB for / and /tmp, and 1024 MB plus space for one crashdump on /var. If anything, these are vast overkill for most systems; on /, for example, it is hard to imagine a situation where a normal user would use more than 150MB of space unless they were doing something which they shouldn't be doing. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 periodic security default problem
Volker wrote:
After inspecting the problem I found that the default of
daily_status_security_diff_flags in /etc/defaults/periodic.conf is -b
-u but the ${filter} expression in /etc/periodic/security.functions is
being set to grep '^'
diff produces a +/- diff format but the output is being filtered for ^
so no output comes from any of the /etc/periodic/security scripts. This
should be either changed to daily_status_security_diff_flags=-b in
/etc/defaults/periodic.conf or ${filter} being changed to 'grep ^+' in
/etc/periodic/security/security.functions.
Thanks for reporting this; I've changed the grep regex to '^[+]' in order
to catch lines from both unified and non-unified diffs. This change isn't
going to be in 6.0-BETA3, but hopefully I can get it MFCed before 6.0-RELEASE.
Colin Percival
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
Marc G. Fournier wrote: And, for the stupid question of the day ... how long before 5.x is no longer supported? The FreeBSD Security Team will support FreeBSD 5.x until at least the end of September 2007. Support from other teams and the ports tree may end sooner, but since there aren't very large differences between 5.x and 6.x I doubt there will be many problems. I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? If I was deploying a new server today, I'd install FreeBSD 5.4. If I were planning on installing a new server next month, I'd install FreeBSD 6.0-BETA-whatever-number-we're-up-to-by-then. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to compile 5.4-p3 kernel
Janet Sullivan wrote: I am unable to compile a 5.4p3 kernel. I get the following error: /usr/src/sys/netinet/tcp_input.c: In function `tcp_dooptions': /usr/src/sys/netinet/tcp_input.c:2706: warning: implicit declaration of function `TSTMP_GT' /usr/src/sys/netinet/tcp_input.c:2706: warning: nested extern declaration of `TSTMP_GT' What version of /usr/src/sys/netinet/tcp_var.h do you have on that system? Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Re: unable to compile 5.4-p3 kernel]
Colin Percival wrote: What version of /usr/src/sys/netinet/tcp_var.h do you have on that system? Oops. I meant to ask about src/sys/netinet/tcp_seq.h of course... Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to compile 5.4-p3 kernel
Janet Sullivan wrote: Janet Sullivan wrote: I just re-cvsup'd, and got a new version of src/sys/netinet/tcp_seq.h - might that have been the problem? Answer to self: Yes, it looks like that was the problem. The updated tcp_seq.h has made the kernel compile much happier. Yeah, it looks like the mirrors managed to update at exactly the wrong time and got one patch but not the other. Fortunately, this doesn't happen very often. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 SMP kernels now available via FreeBSD Update
Mipam wrote: Thanks for the kernel. What parameters did you change in your SMP kernel. Just curious, surely gonna try your kernel. :-) I didn't change any parameters, I just used the SMP kernel configuration from the source tree (i.e., GENERIC plus options SMP). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.4 SMP kernels now available via FreeBSD Update
It sounds like the SMP kernel I provided for FreeBSD 5.3 was quite popular, so I've started building an SMP kernel for FreeBSD 5.4 as well, in addition to the usual GENERIC kernel. To take advantage of this on your FreeBSD 5.4 SMP system, run the following commands as root: # touch /boot/kernel/SMP # freebsd-update fetch # freebsd-update install # echo 'bootfile=SMP' /boot/loader.conf and reboot. You should now find that `uname -ri` outputs 5.4-SECURITY SMP. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4 SMP kernels now available via FreeBSD Update
Billy Newsom wrote: Colin Percival wrote: It sounds like the SMP kernel I provided for FreeBSD 5.3 was quite popular [...] I'm curious how popular. Would you like to report some statistics here on the list? As in, how many SMP downloads did you get, say, in comparison to the GENERIC? Ok, I've gone through my log files, and it looks like the number of systems downloading SMP kernels is around 4% - 6% of the number of systems downloading GENERIC kernels. That said, I don't think this should be used as a measure of how popular SMP is on FreeBSD systems overall, since people with high-end SMP systems are more likely than average to build their own kernels rather than using those which I distribute and the availability of SMP kernels via FreeBSD Update wasn't very widely advertised. It is probably safe to conclude that _at least_ 5% of FreeBSD systems have more than one processor, but I suspect that the actual value is considerably higher than that. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4 not running HTT
Erik Trulsson wrote: It depends on which version you are looking at the source of. In the release/security branches (RELENG_5_4, etc.) all security patches (like this one) are noted in UPDATING. For the development branches (RELENG_5 , -CURRENT) security patches usually don't get mentioned. I.e. if you are looking at the source for RELENG_5_4 there is a notice in UPDATING, if you are looking at the source for RELENG_5 there is not. In this particular case there probably should have been a note added to UPDATING for both -STABLE and -CURRENT, but there wasn't. Quite right -- we fell into the trap of just following our standard procedures, instead of thinking about whether this met the test for being documented in UPDATING (which it certainly does, since it is a potentially astonishing user-visible change). I've added it to the stable branches, but not to -current, since hyper-threading is still enabled by default in HEAD. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
Francisco Reyes wrote: So why have a 6.X naming convention to begin with? Why not just stay in 5.X name wise? Because 5.x has been declared to be STABLE, and some of the changes in 6.x will require that applications (and especially kernel modules) be recompiled (which isn't allowed on a stable branch). Is the goal to have a new major branch every 2 years? Something like that, yes. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lifetime of FreeBSD branches
Mike Jakubik wrote: Could someone point me to a resource that outlines the expected supported lifetime of all the branches? Can't find anything concrete on the webpage. http://www.freebsd.org/security/ In addition to the material there (which is concerned with existing releases), FreeBSD 5.x is expected to be supported until late 2007 (FreeBSD 5.5 plus two years), and FreeBSD 6.x will probably be supported until early 2009 (the last FreeBSD 6.x release plus two years). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apache + Caching DNS: conflict at bootup? (DNS runs too late)
Rob wrote: Some time ago, there was (or still is) a similar conflict with hostname resolution at bootup when using ntpd. Yes, but not with named -- the problem was only when using a dns cache from the ports tree, since those are started later in the boot sequence. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MNT_USER?
Danny Braniss wrote: BTW, this, the MNT_NOEXEC, uncovered, IMHO, a bug in libexec/rtld-elf/rtld.c where it's now checking for MNT_NOEXEC, but only if LD_LIBRARY_PATH is set! This is not a bug. Checking for MNT_NOEXEC adds a cost in performance, and it is not necessary if LD_LIBRARY_PATH, LD_PRELOAD, and LD_LIBMAP* are not set -- based on the assumption, that is, that no (sane) sysadmin would ever put a MNT_NOEXEC-mounted filesystem into the default library path. I agree that it's a bit counter-intuitive, but it's really just a case of saving time by not checking for something which should Never Happen. :-) Colin Percival PS. Bravo to Ian for tracking down the bug in NFS -- I spent a while looking for this, but got hopelessly lost. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will 5.4 be an Extended Life release?
Brett Glass wrote: Actually, it tends not to recognize it at all. If the string doesn't say 4.11-RELEASE, the software reports that ports, packages, etc. can't be found. Try installing packages with /stand/sysinstall on a snapshot and you'll see what I mean. Colin's FreeBSD-update seems to exhibit similar behavior. FreeBSD Update will complain if it isn't foo-RELEASE or foo-SECURITY. I added this because some people were running FreeBSD Update on -STABLE or -CURRENT systems and getting, err, unanticipated breakage. (Consider what happens when you update a 5.0-current system by replacing its libc.so with one from a fully security-patched 5.0-release system.) I usually choose to allow users to shoot their own feet if they want, but since I wrote FreeBSD Update primarily for the benefit of less experienced FreeBSD users I decided that some anti-foot-shooting mechanisms were a good idea. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.4-RC3 Available
Ken Smith wrote: The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 5.4-RC3 [...] We encourage people to help with testing [...] I've been running 5.4-RC2 for the past week without problems (and -RC1 for a week before that, and -BETA before that). Should I upgrade to -RC3? I'm not sure if it's worth burning another few hundred megabytes of ftp mirror bandwidth. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ready for dual core Opterons?
Brett Glass wrote: According to the article at http://www.techweb.com/wire/hardware/160503169 AMD is going to be launching dual core Opterons this month. Will FreeBSD 5.4 be ready to handle them? My understanding is that dual core opterons just look like multiple processors to the operating system, so there should be no problems. For that matter, my understanding is that dual core opterons *are* separate processors, connected only via their normal external interface. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MNT_NOEXEC on root filesystem with diskless PXE boot?
Tom Alsberg wrote:
Perhaps this should go to -STABLE, I just couldn't be sure.
It will get more attention on freebsd-stable@, so I'm CCing that list.
We are trying out FreeBSD 5.4-PRERELEASE on diskless clients. I
noticed one problem, being that when setting the LD_LIBRARY_PATH
(or for that matter, LD_PRELOAD, and LD_LIBMAP_DISABLE) environment
variables, nothing will run, as /libexec/ld-elf.so.1 complains:
Cannot execute objects on /
According to the sources, this was added in 5.4, and will happen
if / is mounted noexec.
Yes, that's quite correct -- although I can't imagine how a bug which
caused / to be labelled as noexec managed to avoid causing major
problems until now.
I don't know anything about NFS, but hopefully someone on -stable
will be able to work out what's going on from the rest of your
email (quoted below).
Colin Percival
In this case, / is mounted by the BTX PXE loader over NFS (from a
FreeBSD 5.3 server, right now). mount does not show the noexec
flag. However, with the attached little C program I verified that
statfs really returns this flag (0x0006).
Now, I see that on FreeBSD 5.3 diskless clients this flag is also
returned on / - just it happened that nobody looked at it until
the change in rtld.c of FreeBSD 5.4:
if (fs.f_flags MNT_NOEXEC) {
_rtld_error(Cannot execute objects on %s\n, fs.f_mntonname);
close(fd);
return NULL;
}
I didn't yet understand (didn't check much) - why does statfs report
the MNT_NOEXEC flag on the / filesystem (and only the / filesystem,
when it's mounted from NFS by the bootloader - not any other
NFS filesystems)? BTW, this happens also with NetApp as the NFS
server - just to rule out any possibility of relation here.
Ideas appreciated,
-- Tom
#include stdio.h
#include fcntl.h
#include sys/param.h
#include sys/mount.h
int main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, invalid number of arguments);
return -1;
}
struct statfs stbuf;
if (statfs(argv[1], stbuf) != 0) {
perror(fstatfs);
return -1;
}
printf(FLAGS: 0x%08X\n, stbuf.f_flags);
if (stbuf.f_flags MNT_NOEXEC)
printf(MNT_NOEXEC\n);
return 0;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KDE refuses new processes when network goes away
Par Leijonhufvud wrote: When I start it up with network up everything is fine, but if the network dies (we have a slightly dodgy ADSL, which periodically plays yo-yo) it will refuse to open new processes or windows. Is it (likely to be) a KDE, xopen or freebsd problem? Is your /etc/hosts correct? I've seen this happen when the local hostname (i.e., the output of `hostname`) cannot be resolved. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 ntpd (5.3-STABLE-SNAP001)
Thomas Krause wrote: when starting ntpd at boot time, I've 2 ntpd's running: [...] Any idea why? I' running 5.3-STABLE-SNAP001. 1. You have some host names in ntp.conf which need to be resolved, and 2. At the time ntpd starts, the resolver isn't running. For some reason, ntpd makes one attempt to look up names in DNS and then goes into an infinite loop. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any hosting companies offering FreeBSD 5.3 yet?
John Pettitt wrote: I'm thinking about moving one of my servers to a new home (it's currently at servepath.com on a FreeBSD 5.0 box) - does anybody know of a reputable hosting company that's offering 5.3 boxes? I have a box with layeredtech.com; they were a bit slow in setting it up initially (about 80 hours -- but 48 hours of that was over a weekend), but aside from that I have no complaints. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
Brett Glass wrote: Would anyone else besides me like to see a 5.3.1 minor release sometime around, say, February? No, but quite a few people would like to see a 5.4 minor release sometime around, say, late February or early March. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5.3 SMP kernels now available via FreeBSD Update
In response to popular demand, I am now providing both GENERIC and SMP kernels via FreeBSD Update to people running FreeBSD 5.3. To take advantage of this on your FreeBSD 5.3 (and only 5.3!) SMP system, run the following commands as root: # touch /boot/kernel/SMP # freebsd-update fetch (this should mention downloading a new /boot/kernel/SMP file) # freebsd-update install (likewise, this should mention installing /boot/kernel/SMP) # echo 'bootfile=SMP' /boot/loader.conf and reboot. You should now find that `uname -ri` outputs 5.3-SECURITY SMP. Note again that this does not apply to any FreeBSD releases other than 5.3. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.10-RELEASE miniinst does not fit on 3 CD-R
At 09:19 01/06/2004, Daniel O'Connor wrote: miniinst isn't meant for small CD's, it's just meant to be smaller than the full disk. Would be nice to shave that 8Mb off though :) No it wouldn't. If we make it fit now, then we'll be struggling to make it continue to fit for years into the future. (Just look at the floppy disk situation.) Much better just to accept that it doesn't fit onto a 3 CD-R and move on. :-) Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any plans to update CVS beyond v1.11.5?
At 20:59 19/04/2004, Doug Lee wrote: CVS is being updated but FreeBSD still uses v1.11.5. ... Any plans to update CVS in the base system? CVS 1.11.15 was imported into -current four days ago. I would assume that it will be merged onto -stable at some point after 4.10-RELEASE. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix make release for 4-STABLE
At 09:28 19/01/2004, Ruslan Ermilov wrote: Maybe it's time for drivers.flp to appear on RELENG_4? If someone could MFC the support to sysinstall, I could help with release/ bits. I've already mentioned this to re@, but if there's a real need for space-saving, using NetBSD's makefs (ports/sysutils/makefs) saves about 23k on the mfsroot floppy. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: messed up /etc/gettytab
At 17:18 28/11/2003 +0100, Thomas Quinot wrote: * jag, 2003-11-28 : Would anybody post /etc/gettytab from release 4.9 You can get a fresh one from /usr/src/etc/gettytab Or if you don't have the source tree installed, from http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/etc/gettytab?rev=1.17.2.4 Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, are all the panics fixed now?
At 23:42 27/08/2003 +0400, Maxim Konovalov wrote: On Wed, 27 Aug 2003, 13:34-0500, Mike Silbersack wrote: So, I think we'll just include a warning with 4.9: WARNING! Do not attempt to stress a FreeBSD 4.9 machine if you: or Upgrade your FreeBSD to RedHat. s/RedHat/FreeBSD 4.8-RELEASE/ It's simple: we need to backout all these untested MFCs. Or fix the bugs. I don't know anything about the code in question, but now that people are getting repeatable panics, I assume that tracking down the bugs will be rather easier. There was a time when STABLE absolutely needed to be stable, but I'm not sure that's necessarily the case any more; now that we have all the release/security branches, I think it's safe to say that most systems which need absolute stability aren't going to be running STABLE. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PR 37395 - even with NO_SENDMAIL=true, /usr/sbin/sendmail overwritten
At 07:28 04/12/2002 -0800, Michael Sierchio wrote: What's the deal with this? This puppy broke a couple of my machines by overwriting /var/qmail/bin/sendmail via the symlink in /usr/sbin. Ack. Pppt. I think you're looking for mailwrapper(8) and possibly the NO_MAILWRAPPER option. There should be a single switch to disable sendwhale. There is. I'll reiterate that the make.conf switches are no substitute for packagizing the ever-more-bloated base system. Go ahead and submit your patches. I think most people agree that a packagized base system would be a Good Thing, but nobody has actually gotten around to doing it yet. Colin Percival To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
