Re: 8.0-BETA3/i386: make WITHOUT_TOOLCHAIN=yes buildworld broken
On 2009.08.30 01:34:43 +0800, Eugene Grosbein wrote: In 8.0-BETA3, make WITHOUT_TOOLCHAIN=yes buildworld breaks in 15 minutes after start: I'm pretty sure WITHOUT_TOOLCHAIN=yes hasn't worked with buildworld since 7.x, so this is nothing new. You need to specify it with installworld, not buildworld. At least I ran into that with NanoBSD some time ago. But thanks for report in any case. -- Simon L. Nielsen ___ 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: Upcoming Releases Schedule...
in newer FreeBSD versions, but that is very rare. - The more branches are supported, the more versions of both third party code and FreeBSD code need to be supported and the more likely it is that the software differs meaning that we need to adopt the fix to the branch. The real painful case for this was FreeBSD-SA-07:01.jail which AFAIR needed 6 different patches. This is one of the largest time cost with support many branches as this is by no means a linear cost. The older a branch is, the more likely it is that the code is much different than newer FreeBSD versions. This also the reason secteam was very happy when we could discontinue FreeBSD 4 support as it was significantly different from FreeBSD 5+. In that respect supporting FreeBSD 5 in the end was much cheaper than supporting FreeBSD 4 in the end. Of course this is less likely to be a problem in the future like it was with FreeBSD 4, but still - FreeBSD 5 and FreeBSD 8 are rather different and would not be fun to support both. - Even if we don't need different patches for older releases we still need to look at them for each advisory and potentially do separate testing for each release. - For some issues which are e.g. in the platform (as in i386, amd64, sparc64 etc.) dependent FreeBSD code or otherwise platform dependent code the complexity and time is a multiple of numbers of supported platforms and supported branches. There aren't many issues of this type but they could happen. - The actual advisory handling takes longer time the more releases is involved as the advisory need to contain info per release and patches need to be applied per branch both to the subversion tree and freebsd-update. This is not a big part, but it still takes time when you have 8 supported branches like we did at one point. There is also a cost in hardware for supported branches though this is less of an issue. Hardware is needed for testing / developing patches and for freebsd-update builds. Since we now have VMware and qemu hardware for reference systems are a smaller problem now. The time freebsd-update builds takes is an issue, but not a big one as we could just get more hardware if needed. The more releases are supported, the more disk-space is also needed for freebsd-update mirrors. Again, far from an unsolvable problem by any means, but also a factor - included for (slightly more) completeness. This is the costs I could come up with now - I'm sure there are more which I have forgotten. While I'm not going more into the general discussion of how long to support branches, I will note that as rwatson has said - adding more people to secteam is not as simple as it sounds (though we are in the process of expanding right now). Other is the thread have mentioned external people could support the older branches. This is partially correct, but only if the support is distributed externally as well. Even after a branch is not supported anymore the FreeBSD Security Team holds a lock on the branch and only in special cases allow commits to those branches. The reason for this is that some people might still just pull the latest version for RELENG_X_Y for whatever reason and they should not suddenly get less verified code. Newer patches also wouldn't make it to freebsd-update as that is managed by secteam. We have had one case where a committer was interested in supporting an older release and back-ported patches from security advisories for a while. The patches for the older releases were then reviewed in each case by the security team before commit, but that only lasted for a while and was a couple of years ago AFAIR. In theory this could happen again if the Security Officer at the time is OK with it - I haven't talked with Colin about this in a while, so I can't recall is position. There would still need to be committer which is the interface to secteam and do the commits. Most issues (though of course not all) which gets advisories are not public at the time of the advisory, so a fix to older branches would be likely be delayed some compared to initial disclosure. I hope this makes it a bit clearer what the cost of supporting old releases is (and even then I haven't gone much into the important part of also having ports support). [1] http://security.FreeBSD.org/ [2] http://www.freebsd.org/ports/ PS. I hope there aren't too many spelling and grammar errors in this mail, but just reading it over one time was more than enough :-). -- Simon L. Nielsen Hat: FreeBSD Deputy 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: linked ssl libraries to binary
On 2008.03.04 12:05:22 +, Chris wrote: On freebsd 6 it picks up /usr/local ssl libaries no problem and in fact uses them without even haveing to specify the directory it auto detects them over the base ssl. On freebsd 7 it uses the base libraries even when telling it to search in /usr/local. That sounds either like there is a bug in the program build system... it might also happen if the base system and and ports libraries have the same version number... I never tried that as I always use base system OpenSSL. So I then decided to move the binary I compiled on freebsd 6 over to the freebsd 7 box and when I ran ldd on the binary to my surprise it is using the base libraries on freebsd 7. Note that we do not guarentee at all that you can do that. I'm not even sure that the .so version number in the port and in the base system match. ldd on binary on freebsd 6 libssl.so.5 = /usr/local/lib/libssl.so.5 (0x48102000) libcrypto.so.5 = /usr/local/lib/libcrypto.so.5 (0x48143000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x4829f000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x482b8000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x482c) libm.so.4 = /lib/libm.so.4 (0x48396000) libpthread.so.2 = /lib/libpthread.so.2 (0x483ac000) libc.so.6 = /lib/libc.so.6 (0x483d3000) libbz2.so.2 = /usr/lib/libbz2.so.2 (0x484cb000) libz.so.3 = /lib/libz.so.3 (0x484dc000) ldd on same binary on freebsd 7 libssl.so.5 = /usr/lib/libssl.so.5 (0x28101000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x28142000) libcrypt.so.3 = /usr/local/lib/compat/libcrypt.so.3 (0x2829a000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x282b2000) libstdc++.so.5 = /usr/local/lib/compat/libstdc++.so.5 (0x282bd000) libm.so.4 = /usr/local/lib/compat/libm.so.4 (0x28388000) libpthread.so.2 = /usr/local/lib/compat/libpthread.so.2 (0x2839e000) libc.so.6 = /usr/local/lib/compat/libc.so.6 (0x283c3000) libc.so.7 = /lib/libc.so.7 (0x284a9000) Uhh, not good. If you link against two versions of libc bad things are bound to happen. That can happen if you have a old binary which links against a new lib... or something like that. If you want to this to work aither compile the binary statically or get all the 6.x libs and do some LDCONFIGPATH (or whatever the env var is called) to make sure those libs override the 7.x libs. libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x282c1000) libbz2.so.3 = /usr/lib/libbz2.so.3 (0x284ee000) libc.so.7 = /lib/libc.so.7 (0x283f3000) libcrypt.so.4 = /lib/libcrypt.so.4 (0x282a8000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x2815) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x283d5000) libm.so.5 = /lib/libm.so.5 (0x283c) libssl.so.5 = /usr/lib/libssl.so.5 (0x2810f000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x282cc000) libthr.so.3 = /lib/libthr.so.3 (0x283e) libz.so.4 = /lib/libz.so.4 (0x284fe000) That looks correct (at least no duplicate libs). Unfortunatly I have no idea why it crashes on 7 naively compiled. -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cryptodev and ssh on RELENG_7
On 2007.11.29 01:51:44 +0900, Norikatsu Shigemura wrote: On Tue, 27 Nov 2007 07:37:49 -0500 Mike Tancsa [EMAIL PROTECTED] wrote: I have a HiFN crypto card and can remember that it was used for ssh connections with 3des encryption (on 6.1 afair). But with RELENG_7 it isn't used at all (no interrupts) if I 'ssh -v -c 3des-cbc [EMAIL PROTECTED]' Any ideas what is wrong? dmesg: hifn0 mem 0x8000-0x8fff,0x8004-0x80041fff,0x8008-0x80087fff irq 12 at device 13.0 on pci0 hifn0: [ITHREAD] hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801ext clk, 4x mult crw-rw-rw- 1 root wheel - 0, 41 Nov 27 08:13:41 2007 /dev/crypto Hi, Are you sure you have device crypto and device cryptodev in the kernel? Also, there is a program in /usr/src/tools/tools/crypto called hifnstats. It will show some usuage stats. e.g. This issue is one of a gcc42 issue. But gcc42 is not wrong. OpenSSL has a using __FreeBSD_version issue. So to fix this issue, you should apply following patch. Actually I just don't see how the code in question could have ever detected FreeBSD correctly, unless the normal OpenSSL build system does some magic for this (which it doesn't seem to). I'm doing make universe test builds with the patch below now. I will try test this with actual hardware tomorrow (if I can find it), but it's quite possible I won't have time until Friday to get something set up to test. If somebody else can test the patch below with some crypto hardware that would be great. Thanks for the patch btw. :-). --- crypto/openssl/crypto/engine/eng_cryptodev.c.orig 2006-07-30 04:10:18.0 +0900 +++ crypto/openssl/crypto/engine/eng_cryptodev.c 2007-11-08 01:55:35.0 +0900 @@ -32,7 +32,7 @@ #include openssl/bn.h #if (defined(__unix__) || defined(unix)) !defined(USG) \ - (defined(OpenBSD) || defined(__FreeBSD_version)) + (defined(OpenBSD) || defined(__FreeBSD__)) #include sys/param.h # if (OpenBSD = 200112) || ((__FreeBSD_version = 470101 __FreeBSD_version 50) || __FreeBSD_version = 500041) # define HAVE_CRYPTODEV -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[EMAIL PROTECTED]: cvs commit: src/crypto/openssl/ssl d1_both.c dtls1.h ssl.h ssl_err.c]
Hey, RELENG_7 isn't -STABLE yet, so the issue mention in the commit mail beolow will not get a Security Advisory. This only affects applications using DTLS, and I doubt there are many of those, but users should still upgrade to get this fix, just in case. See the OpenSSL advisory for some more details: http://www.openssl.org/news/secadv_20071012.txt If anybody were wondering, and hadn't checked the OpenSSL advisory: older versions of FreeBSD aren't affected as they have OpenSSL 0.9.7 which isn't affected (it doesn't have DTLS support). - Forwarded message from Simon L. Nielsen [EMAIL PROTECTED] - From: Simon L. Nielsen [EMAIL PROTECTED] Date: Thu, 18 Oct 2007 22:20:04 + (UTC) To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/crypto/openssl/ssl d1_both.c dtls1.h ssl.h ssl_err.c simon 2007-10-18 22:20:04 UTC FreeBSD src repository Modified files:(Branch: RELENG_7) crypto/openssl/ssl d1_both.c dtls1.h ssl.h ssl_err.c Log: MFC: Import DTLS security fix from upstream OpenSSL_0_9_8-stable branch. Security: CVE-2007-4995 Security: http://www.openssl.org/news/secadv_20071012.txt Approved by:re (kensmith) Revision ChangesPath 1.1.1.1.2.1 +533 -605 src/crypto/openssl/ssl/d1_both.c 1.1.1.1.2.1 +3 -4 src/crypto/openssl/ssl/dtls1.h 1.1.1.16.2.1 +1 -0 src/crypto/openssl/ssl/ssl.h 1.1.1.11.2.1 +1 -0 src/crypto/openssl/ssl/ssl_err.c - End forwarded message - -- Simon L. Nielsen FreeBSD Deputy Security Officer pgp01rCYA40Ei.pgp Description: PGP signature
Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
On 2007.07.27 17:12:34 +1000, Joel Hatton wrote:
I'm dredging up an old issue here, but it appears to be unresolved in
RELENG_5_5 at this time. After upgrading to 5.5-RELEASE-p14, I found that
my jails wouldn't start anymore, and it comes down to this bit again. By
way of explanation, I'll include the patch for what I changed.
--- /tmp/jail Wed Feb 14 15:16:30 2007
+++ /etc/rc.d/jail Fri Jul 27 13:46:51 2007
@@ -218,7 +218,7 @@
{
local _device _mountpt _rest
- while read _device _mountpt _rest; do
+ cat ${jail_fstab} | while read _device _mountpt _rest; do
case :${_device} in
:#* | :)
continue
In short, the jail_mount_fstab function is not given the fstab file on
which the local variables depend. My patch may not be the most robust but
for me today it is expedient.
Hey,
Yes, looking at the code now it is clearly wrong. Guess I/we
(secteam) stared too much at the code so we missed this issue :-/.
Your patch is very close to the correct/cleaner patch which is
attached. How exactly does it fail without your patch? Does it say
cannot open : No such file or directory and then no jails start when
booting (that would be my guess from a quick check of the bug)?
Would it be possible for you to test the attached patch and see if it
fixes the issue for you?
Sorry if this has been discussed already, but I was surprised that this
hadn't been fixed yet. It certainly would have caused some anxious moments
if I'd upgraded a prod server with multiple jails before I realised!
I haven't heard of this issue before, so not many people are using 5.5
with jails. The bug was certainly introduced as a merge error in the
with the patch for FreeBSD-SA-07:01.jail.
As this is clearly a bug in a Security Advisory patch and RELENG_5 /
RELENG_5_5 are still supported I expect that an updated advisory will
be released to fix this bug shortly.
Thanks for reporting the issue, and sorry about the bad patch :-(.
--
Simon L. Nielsen
Hat: FreeBSD Security Team and pointyhat
Index: jail
===
RCS file: /home/ncvs/src/etc/rc.d/jail,v
retrieving revision 1.15.2.5.2.1
diff -u -d -r1.15.2.5.2.1 jail
--- jail11 Jan 2007 18:19:33 - 1.15.2.5.2.1
+++ jail27 Jul 2007 08:49:37 -
@@ -228,7 +228,7 @@
warn ${_mountpt} has symlink as parent - not mounting
from ${jail_fstab}
return
fi
- done ${_fstab}
+ done ${jail_fstab}
mount -a -F ${jail_fstab}
}
pgpfkwZGUCy2V.pgp
Description: PGP signature
Re: Canonical 4.x to 6.x upgrade docs?
On 2007.03.09 09:30:01 -0800, Bruce A. Mah wrote: I'm fairly sure that a number of the FreeBSD.org machines were upgraded using exactly this procedure (4.X to 5.4, then 5.4 to 6.X). Correct (though many systems were upgraded through reinstall). I upgraded one FreeBSD.org system from 4.10 - 6.1 and the upgrade went without problems following the migration guide, which frankly did suprise me a bit :-). So, thanks for writing the migration guide Bruce :-). -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Loosing spam fight - [EMAIL PROTECTED]
On 2007.01.27 13:04:28 -0200, JoaoBR wrote: On Saturday 27 January 2007 12:32, Jim Pingle wrote: Roland Smith wrote: Most spammers do not bother to return if they get a resend request. That's the whole point of doing this. So practically it doesn't increase bandwidth consumption. ... Greylisting is a decent idea, but it seems to me that it's just another tool in the ongoing arms race against spammers. It may work for a while, but eventually they'll catch on and it will only cause unnecessary delays for legitimate mail. finally some cares about the users here, that is a really important point, how do you justify that your client get the email he is waiting for an hour later? Probably he looks then for a better service provider ... Could this discussion please be continued on the apropriate list which is designed for spam - [EMAIL PROTECTED] Thanks. -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On 2007.01.13 12:29:37 +0100, Pawel Jakub Dawidek wrote: On Thu, Jan 11, 2007 at 04:51:02PM -0800, Colin Percival wrote: 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). So, I have been putting off replying to this thread, but I guess it seems like I should reply... :-) I don't like the way it was fixed. I do know it wasn't easy to fix. I don't like it either, but it was the best of bad solutions. My hope while developing the patch, and cursing computers in general :-), was that after the Security Advisory went out somebody would implement a fix which sucks less possibly by modifying some of the support tools. Your suggestion with modifying realpath to use chroot(2) certainly sounds like it could work, but I haven't thought about it in great detail if there are problems. The Security Team does not hold a lock on trying to improve the fix in src/etc/rc.d/jail, but anyone that does change the fix from the Security Advisory should be really really really really (did I mention really?) sure the fix is safe and have at least a few people with security clue review patches. It is very easy to get this wrong (my first patch did). Also, whatever fix is made should be in -CURRENT for a while (3 weeks min. IMO) before being MFC'ed, both because it gives more time for people to think about the fix and because -CURRENT isn't supported wrt. security issues, so if the fix is wrong we don't have to issue an advisory. BTW. with regard to the console.log file I really don't think it should be put back inside the jail unless it's possible to make the generation of the file entirely inside the jail since it's just not worth the risk/complexity. I think it should be possible to do this with jail(8) in -CURRENT (see -J flag), but: Note that it will probably be at least a couple of weeks before I feel like going anywhere near the jail rc.d script again (except for the warning comment I plan to add...), so don't wait for me with regard to improving this. And in case anyone were in doubt: Computers still suck :-). -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix [was: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail]
On 2007.01.20 14:03:08 +0100, Pawel Jakub Dawidek wrote: On Sat, Jan 20, 2007 at 01:24:33PM +0100, Simon L. Nielsen wrote: [...] BTW. with regard to the console.log file I really don't think it should be put back inside the jail unless it's possible to make the generation of the file entirely inside the jail since it's just not worth the risk/complexity. I think it should be possible to do this with jail(8) in -CURRENT (see -J flag), but: When -J operates on a file inside a jail, it create the same security hole as the one from security advisory, because it opens a file before calling jail(2). My thought with using -J was not place the info about jid in a file outside the jail root, basically (pseudo code): _tmpfile=`mktemp...` jail -J $_tmpfile sh /etc/rc /var/log/console.log _jid=`cat $_tmpfile | something` At least that was what I thought might be possible with the -J switch when I noticed it existed. In any case, actually coding this, verifying that it works and is safe is left up to anyone who cares about having console.log inside the jail. -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving FreeBSD-SA-07:01.jail fix
On 2007.01.20 17:52:32 +0100, Stefan Bethke wrote:
Am 20.01.2007 um 13:24 schrieb Simon L. Nielsen:
BTW. with regard to the console.log file I really don't think it
should be put back inside the jail unless it's possible to make the
generation of the file entirely inside the jail since it's just not
worth the risk/complexity.
I'm probably missing something, but why not replace:
_jail_id=$(head -1 ${_tmp_jail})
tail +2 ${_tmp_jail} ${_rootdir}/var/log/console.log
with:
_jail_id=$(head -1 ${_tmp_jail})
tail +2 ${_tmp_jail} | jexec ${_jail_id} sh -c cat /var/log/
console.log
I thought of, and actually implemented, a similar solution when I
worked on the problem but there are two problems:
- You cannot be sure cat exists inside the jail.
- The jail could already have exited again in which case jexec will
fail.
--
Simon L. Nielsen
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Canonical 4.x to 6.x upgrade docs?
On 2006.12.28 19:55:55 -0500, Charles Sprickman wrote: Is there any official doc on this? Perhaps I'm just not finding it? I would assume since everyone is being urged to get away from 4.x that somewhere there's a good step-by-step on how to do that. http://www.freebsd.org/releases/5.4R/migration-guide.html#UPGRADE That is the one I used (or perhaps I used it from 5.3-RELEASE, but should be the same), when I recently upgraded a system 4-5-6. The 5-6 should be pretty much like any other FreeBSD upgrade, just follow the normal documented upgrade procedure and don't skip steps. My upgrade actually turned out to be pretty painless and just work. -- Simon L. Nielsen ___ 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-RC2 Available
On 2006.12.28 01:26:41 -0800, Eric P. Scott wrote: Would someone please please please publicly document what all the various 6.x ISO images are, which of them are (or might be) needed for a fresh installation (assuming poor or nonexistent network connectivity), and which have overlapping bits. If this is actually explained anywhere that's supposed to be obvious, I have yet to find it. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-diff-media.html#AEN3220 -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RC2 ?
On 2006.12.15 09:33:22 -0600, Scott T. Hildreth wrote: Will there be a RC2 or just a realease? I'm not on re@ so I don't know the exact status of RC2, but currently it's not possible to distribute it since the master server which the FTP servers mirror from is out of service due to hardware problems. The server decided to develop problems at a time when it is not possible for anyone to get on-site to fix it, so we don't know exactly when it will be back. -- Simon L. Nielsen Hat: FreeBSD Admins Team ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php4 update
On 2006.10.16 20:02:05 +0200, Olivier Mueller wrote:
On Mon, 2006-10-16 at 10:25 -0700, Dominik Zalewski wrote:
Hi everybody,
I'm running FreeBSD 6.1-RELEASE on i386. I wanted to upgrade my php to
latest version 4.4.4_1 cause of security update.
When running portupgrade php4 I got:
= php -- open_basedir Race Condition Vulnerability.
Reference:
http://www.FreeBSD.org/ports/portaudit/edabe438-542f-11db-a5ae-00508d6a62df.htmlhttp://www.freebsd.org/ports/portaudit/edabe438-542f-11db-a5ae-00508d6a62df.html
= Please update your ports tree and try again.
Short version: add this to your /etc/make.conf:
# PHP 4 Port installation options
.if${.CURDIR:M*/lang/php4*}
DISABLE_VULNERABILITIES=yes
.endif
Long version: check in the newsgroups or mailing lists archives... :)
Only do the above if you really know what you are doing. Just adding
code like that to make.conf which will probably be forgotten is a bad
idea.
The DISABLE_VULNERABILITIES=yes knob can just be passed directly to
make for the individual port or e.g. using the '-m DISABLE_VULNERABILITIES=yes'
as an argument to portupgrade while upgrading PHP. This should of
cause only be done after having checked the URL from portaudit to
verify that the particular problem doesn't affect you (the
user/admin).
--
Simon L. Nielsen
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
On 2006.10.12 10:59:18 +0300, Patrick Okui wrote: One of my servers is colocated in a place on a different continent - which is why I haven't been able to upgrade it beyond RELENG_4. Google turns up a binary upgrade as the only way I can get to RELENG_6. Is this still the case (because the logistics on arranging that are ... interesting) or is there a relatively safe way to upgrade from RELENG_4 to RELENG_6 remotely? I have upgraded a system from 4.10 to 6.2 via 5.5 half a world away just using serial console (well and remote power, but that wasn't needed for the upgrade itself). I did this via buildworld etc. and it was actually quite painless, so it can be done. That said, of cause there is always the risk that something will make it blow up. Note that you have to be careful to follow the guidelines to the letter (see the migration guide which was part of 5.3 or 5.4 docs AFAIR) for the 4.x - 5.x part. -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gzip is faster with -O3
On 2006.08.09 17:53:01 -0500, Brooks Davis wrote: [...] Poul-Henning Kamp has a nice (if probably somewhat overkill for this case) writeup on doing benchmarking here: http://lists.freebsd.org/pipermail/freebsd-current/2004-January/019595.html It should be mentioned that this is in the Developers Handbook along with some more tips/comments from Robert Watson: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/testing.html -- Simon L. Nielsen ___ 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 Released
On 2006.05.09 01:00:14 -0400, Mike Jakubik wrote: Julian Elischer wrote: [...] the above points to a filel that says 6.0 errata Indeed. Where is the mention of current quota/bge/em/ufs problems? Don't tell me these will be shoved under the rug. Send patches. -- Simon L. Nielsen pgpan6ucZhbwj.pgp Description: PGP signature
Re: FreeBSD 6.1 Released
On 2006.05.11 20:53:42 -0400, Mike Jakubik wrote: Simon L. Nielsen wrote: On 2006.05.09 01:00:14 -0400, Mike Jakubik wrote: Julian Elischer wrote: [...] the above points to a filel that says 6.0 errata Indeed. Where is the mention of current quota/bge/em/ufs problems? Don't tell me these will be shoved under the rug. Send patches. Patches? For what? [...] For the errata page, which was what the above text mentioned. -- Simon L. Nielsen pgpo8BkxSgjrg.pgp Description: PGP signature
Re: portsnap mirror servers
On 2006.04.19 09:50:31 +0200, Oliver Brandmueller wrote: On Wed, Apr 19, 2006 at 01:28:56AM +0100, Chris wrote: On 18/04/06, Colin Percival [EMAIL PROTECTED] wrote: Why do you think there should be an .eu mirror? Whilst portsnap is fast, it is a noticeable speed difference when using from eu servers, I also think its a good idea for redundancy. I did not yet check in the sources or with tcpdump, but from the htrougput I see, I'd guess, there's a lot of sequential two-way communication involved. That kind of traffic is massively influenced by Hey, Recent portsnap versions (since the ones shipped in 6.0 AFAIR) uses HTTP pipelining (when possible) which means that the latency really doesn't matter since many requests are sent at once without waiting for the reply. I should mention that when pipelining is enabled I don't really see a big difference when using portsnap from Europe compared to systems in the US. More often the local disk limits the speed of portsnap updates for me rather than bandwith/latency. As Colin has said before, there will be more mirrors later, but there really just isn't a need for more right now. -- Simon L. Nielsen pgpEnLZ2E3Q1N.pgp Description: PGP signature
Re: devfs on /my/jail/dev ...
On 2006.03.27 23:18:21 -0400, Marc G. Fournier wrote: I'm missing something here ... I've looked in /etc/defaults/devfs.conf, and found that ruleset 4 is what I want for a jail ... so, I issue: devfs -m /vm/.t19/dev ruleset 4 I can't remember the details right now (other than it's easy to do it wrong), but basically you need to both filter the existing device entries and set a ruleset for new entries. I would suggest simply looking at how the jail rc.d script sets up the devfs and reading the entire devfs manual page a few times, or even better simply use the jail rc.d script to set it up. -- Simon L. Nielsen pgpefVzBaRXty.pgp Description: PGP signature
Re: new FreeBSD-webpage
[Redirected to -www since that's where stuff about the web page should be discussed, not -stable] On 2005.10.06 21:17:50 +1000, Peter Jeremy wrote: I'd suggest that the most important feature that is missing is a website map. The website looks nothing like it used to and many of my commonly referenced links are no longer on the home page. Finding my way around is going to be very time consuming until I learn my way around it. That sounds like a good idea. We have http://www.freebsd.org/search/index-site.html but it's in need of an update, and probably some place more visible to be linked from. On the positive side, I'm glad that it's still usable with a text browser. IMO actually even more than before. On the downside, I notice it now uses cookies. AFAIR (I haven't double checked) it uses a cookie to remember if you choose normal or large font - it's not required. -- Simon L. Nielsen pgp75US14SKaC.pgp Description: PGP signature
Re: HEADSUP: bridge(4) removed from HEAD
On 2005.09.27 20:26:37 -0700, Maxim Sobolev wrote: Max Laier wrote: All, as discussed on -arch, the old bridge(4) implementation has been removed from HEAD. The new if_bridge(4) is there to serve as a full functional replacement. If you find anything that does not work with if_bridge(4) that used to work with bridge(4), please let me or Andrew Thompson (thompsa@) know. Thanks. Have you updated the handbook to reflect this change? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bridging.html Considering that we only (more or less) document -STABLE branches in the Handbook it's not a big rush, as long as it's mentioned before 7.0 comes out, though documentation about if_bridge in the Handbook would of cause be nice, considering it's also in 6.0 :-). -- Simon L. Nielsen pgpCv4zmdrZYr.pgp Description: PGP signature
Re: ata breakage from RELENG_5 to RELENG_6
On 2005.08.22 16:24:12 -0400, Mike Tancsa wrote: [verify1] /usr/ports/sysutils/smartmontools# smartctl -a ad0 smartctl version 5.33 [i386-portbld-freebsd6.0] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ I think you have to specify full path for the device now... I ran in to the same thing and it confused me for a bit... [EMAIL PROTECTED]:~] smartctl -a /dev/ad0 smartctl version 5.33 [i386-portbld-freebsd6.0] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: HTS548080M9AT00 [...] On a 6.0-BETA2. -- Simon L. Nielsen pgp6WQRdmtwE7.pgp Description: PGP signature
Re: patch: fix ata panic with Thinkpad CD and DVD drives
On 2005.02.27 11:56:06 -0800, Nate Lawson wrote: If you've been having memory modified after free panics on -current and have a Thinkpad, the attached patch should fix things for you. A quick check of RELENG_5 indicates that the bug is probably there also but I haven't tested for it there. I don think it's in RELENG_5. The commit that (re)introduced the problem haven't been MFC'ed as far as I know, but I can't test it at the moment. It should also be noted that ATA MKIII also fixes this problem, at least it did for me. -- Simon L. Nielsen pgpYqbKoPZ0At.pgp Description: PGP signature
Re: marking ports as 'cleaned' in portaudit.conf ?
On 2005.06.24 10:58:36 +0100, Dick Davies wrote: I just manually patched up my ruby18 install and tried to tell portaudit that the local port is now clean, but it doesn't want to know: [EMAIL PROTECTED] rasputnik # portaudit Affected package: ruby-1.8.2_3 Type of problem: ruby -- arbitrary command execution on XMLRPC server. Reference: http://www.FreeBSD.org/ports/portaudit/594eb447-e398-11d9-a8bd-000cf18bbe54.html ^C [EMAIL PROTECTED] rasputnik # cat /usr/local/etc/portaudit.conf portaudit_fixed=594eb447-e398-11d9-a8bd-000cf18bbe54 [EMAIL PROTECTED] rasputnik # what did I miss? It seems like portaudit_fixed only works for system entries, ie. base system vulnerabilities and is ignored package entries. I think it would be useful to be able to suppress the certain package vulnerabilities like you are trying to, but I don't think I will get around to looking at implementing it any time soon. Of cause the real solution to this particular problem would be for someone to submit a patch for the port :-). -- Simon L. Nielsen pgpyTk4WFAGNc.pgp Description: PGP signature
Re: Which driver for Soekris lan1641?
On 2005.06.15 13:57:10 +0200, Constant, Benjamin wrote: Does someone knows which driver is used for the Soekris lan1641 quad ethernet card? Ethernet chipset is National Semicondutor DP83816 but I can't find any reference to it in the hardware notes for 5.4. It's sis(4). I need to know if ALTQ is available for this card. It should be, though I haven't tested it. See http://www.freebsd.org/cgi/man.cgi?query=altqmanpath=FreeBSD+5.4-RELEASE -- Simon L. Nielsen pgp3wtmvq0KBq.pgp Description: PGP signature
Re: /usr/local/etc/rc.d/*.sh not working?
On 2005.06.14 14:25:13 -0400, Michael W. Lucas wrote: On Tue, Jun 14, 2005 at 11:19:04AM -0700, Brooks Davis wrote: It's b) and this guess is wrong because we don't do any detection of rcorder compatable scripts yet. See /etc/rc.d/localpkg for exactly how the scripts in /usr/local/etc/rc.d get run. My suggestion would be to write up a single rc.d script that handles everything using some combination of ifconfig_if style variables or a config file. Then you have only one script and you'll be ready to go when we move to full rcordering (hopefully in 7.0). Thanks, a definite answer is appreciated. I'm going to take your advice, but also dig in to find out why these don't start. I intensely dislike unexplained behavior, and wonder what else is broken on these boxes... Just a hint... I would suggest sh -x /etc/rc.d/localpkg start or something like that to see what really goes on. -- Simon L. Nielsen pgp2A4IyBTFns.pgp Description: PGP signature
Re: How to configure FreeBSD for rebooting when kernel panic
On 2005.06.10 03:06:46 -0400, Kris Kennaway wrote: On Fri, Jun 10, 2005 at 11:04:17AM +0400, Andrey V. Elsukov wrote: Hi all, It is possible to configure OS for rebooting when kernel panic? That should be the default condition as long as you don't specify debugger support (or do and use DDB_UNATTENDED) BTW. note that DDB_UNATTENDED was been broken for a while (so it still went into the DDB) - it should be fixed now at least in -CURRENT, but I'm not sure if that change made it back to 5-STABLE/5.4-RELEASE. -- Simon L. Nielsen pgpcKkwG7pidi.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
On 2005.05.23 17:38:12 -0400, Mike Jakubik wrote: On Mon, May 23, 2005 5:08 pm, Simon L. Nielsen said: On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. Right, i didnt think so. Debian is a volunteer project too, and their packaging system supports all of their branches. But see how many branches they have to support - not many. It's quite a different question when you have new branches every 6 months compared to when you have one every few years. I guess i should look into rolling my own packages, to be sure. And yes, i realize that we just dont have an infrastructure for something like this. Well, you always have the option to simply backport whatever fixes you want yourself. There are a good chance that most things will work for quite a while. -- Simon L. Nielsen pgp61g1NHKYHu.pgp Description: PGP signature
Re: Lifetime of FreeBSD branches
On 2005.05.23 16:51:18 -0400, Mike Jakubik wrote: On Mon, May 23, 2005 3:42 pm, Colin Percival said: 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). Thanks for the info guys. Does this security support also mean that current ports will be compatible with the release? No, there are no guarantees about that. The ports/ people generally try to make things work with older releases, but there are no gurantees there. It's simply too much work to make such guarantees, and this is after all an volunteer project (for most parts anyway). See also http://www.freebsd.org/ports/ for the official statement. I'm surprised to see that 4.11 will be supported longer than RELENG_5. That is just the current status, RELENG_5 is almost certain to be supported longer than RELENG_4, but exactly how long isn't determined until FreeBSD 5.5, but Colin's timeline applies and is probably a very good estimate, since he is also one of the people that will actually work on supporting it :-). Guess my best bet would be to wait for 6.x. WRT. to security support there wouldn't be a difference. Now, does anyone know if a make buildworld/kernel update will be possible for 5.x to 6.x ? I'm assuming that they are similar enough for this to be possible. It's a much smaller step than 4.X - 5.X was, so it's much more likely that a the upgrade path will be much less painful, than 4.X - 5.X was/is. -- Simon L. Nielsen pgpKeXAoTgti8.pgp Description: PGP signature
Re: hu?
On 2005.04.07 13:19:27 +0300, Danny Braniss wrote: Am I the only one seing this: this is from a cvsup from yesterday: FreeBSD shuttle-2 5.4-STABLE FreeBSD 5.4-STABLE #5: ... ** That correct for RELENG_5. The source for 5.4-RELEASE has been branched so RELENG_5 is now 5.4-STABLE since changes to RELENG_5 will not automatically be part of 5.4-RELEASE. -- Simon L. Nielsen pgp8NBgVTQRTK.pgp Description: PGP signature
Kernel panic on 5.4-PRERELEASE in doselwakeup()
Hello
First, sorry for the lack of details, but given that 5.4 is in
prerelease I though it could be interesting to rapport the problem
anyway, in hope that somebody else has seen something similar.
I don't haave the actual panic message since the serial cable wasn't
connected at the time and I didn't really have the time to find out
how to get the panic string from the system, since it's my main
mailserver... of cause dumpdev wasn't configured either, since the
system hasn't paniced before... doh... anyway:
FreeBSD nfishbone.nitro.dk 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #2: Sat Apr 2
20:34:28 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FISHBONE i386
Tracing pid 82803 tid 100158 td 0xc1c04c00
doselwakeup(c3276274,59,da6479e0,c052a399,c3276274) at doselwakeup+0x6e
selwakeuppri(c3276274,59) at selwakeuppri+0xe
ttwakeup(c3276200,c3276200,c3276200,c1a64200,c06d4d40) at ttwakeup+0x21
ttymodem(c3276200,1) at ttymodem+0x13c
ptcopen(c1a64200,3,2000,c1c04c00,da647a80) at ptcopen+0x63
spec_open(da647a80,da647b3c,c0554aa3,da647a80,cbd5d1a0) at spec_open+0x270
spec_vnoperate(da647a80) at spec_vnoperate+0x13
vn_open_cred(da647be4,da647ce4,0,c3f85e00,4) at vn_open_cred+0x463
vn_open(da647be4,da647ce4,0,4,c06fa880) at vn_open+0x1e
kern_open(c1c04c00,bfbfe470,0,3,0) at kern_open+0xcc
open(c1c04c00,da647d14,3,5,292) at open+0x18
syscall(2f,2f,2f,,281cec2d) at syscall+0x213
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (5, FreeBSD ELF32, open), eip = 0x282bd59b, esp = 0xbfbfe43c, ebp =
0xbfbfe498 ---
I'm not sure if the following is correct.. but :
[EMAIL PROTECTED]:FISHBONE] nm kernel.debug | grep doselwakeup
c051f0ec t doselwakeup
[EMAIL PROTECTED]:~] printf 'obase=16\nibase=16\nC051F0EC+6E\n' | bc
C051F15A
[EMAIL PROTECTED]:FISHBONE] addr2line -e kernel.debug C051F15A
/usr/src/sys/kern/sys_generic.c:1082
sys/kern/sys_generic.c :
if (td == NULL) {
mtx_unlock(sellock);
return;
}
1082: TAILQ_REMOVE(td-td_selq, sip, si_thrlist);
sip-si_thread = NULL;
mtx_lock_spin(sched_lock);
td-td_flags = ~TDF_SELECT;
mtx_unlock_spin(sched_lock);
I don't know if this is useful to anyone... kernel config also
attached in case that's interesting.
--
Simon L. Nielsen
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.394.2.2 2003/12/07 23:52:53 scottl
Exp $
# $Id: FISHBONE,v 1.4 2005/04/02 15:38:53 simon Exp $
machine i386
cpu I486_CPU
cpu I586_CPU
cpu I686_CPU
ident FISHBONE
#To statically compile in device wiring instead of /boot/device.hints
#hints GENERIC.hints #Default places to look for devices.
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options SCHED_4BSD # 4BSD scheduler
options PREEMPTION # Enable kernel thread preemption
options INET# InterNETworking
options INET6 # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT# NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #P osix P1003_1B real-time
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options ADAPTIVE_GIANT # Giant mutex is adaptive.
# Debugging for use in -current
options KDB # Enable kernel debugger support.
options KDB_UNATTENDED
options DDB # Support DDB.
options GDB # Support remote GDB.
#optionsINVARIANTS # Enable calls of extra sanity checking
options INVARIANT_SUPPORT # Extra sanity checks
Re: patch: fix ata panic with Thinkpad CD and DVD drives
On 2005.02.27 11:56:06 -0800, Nate Lawson wrote: If you've been having memory modified after free panics on -current and have a Thinkpad, the attached patch should fix things for you. A quick check of RELENG_5 indicates that the bug is probably there also but I haven't tested for it there. I don think it's in RELENG_5. The commit that (re)introduced the problem haven't been MFC'ed as far as I know, but I can't test it at the moment. It should also be noted that ATA MKIII also fixes this problem, at least it did for me. -- Simon L. Nielsen pgpCIdr7HLZh6.pgp Description: PGP signature
[Solved] Re: sshd stops accepting connections
On 2004.11.12 21:12:12 +0100, Simon L. Nielsen wrote: Today I suddenly couldn't log in via ssh to a server I upgraded to FreeBSD 5.3-RELEASE 4 days ago. When I tried connect to port 22 using telnet(1) the following just happend: [EMAIL PROTECTED]:~] telnet 192.168.3.2 22 Trying 192.168.3.2... Connected to jet.nitro.dk. Escape character is '^]'. Connection closed by foreign host. [...] For the archives and anybody who may be interested... There is some kind of bug in OpenSSH 3.8.1p1's sshd (the one shipped with 5.3), possibly related to PAM and Privilege Separation. The fix for me was simply to install OpenSSH 3.9 from ports, and I haven't had the problem since. -- Simon L. Nielsen pgpHGjBqFhIvj.pgp Description: PGP signature
Re: GMIRROR can be destroyed by ordinary users
On 2005.01.08 15:32:22 +0100, Emanuel Strobl wrote: Dear list, dear Pawel, I think it's a big error that ordinary users can issue a 'gmirror stop /dev/mirrir/sample' with success! Are you sure about that? I can't do it on my test system: [EMAIL PROTECTED]:~] gmirror stop /dev/mirror/sys0 Permission denied -- Simon L. Nielsen pgpUzXiw1H0rY.pgp Description: PGP signature
Re: GMIRROR can be destroyed by ordinary users
On 2005.01.08 15:49:16 +0100, Emanuel Strobl wrote: Am Samstag, 8. Januar 2005 15:41 schrieb Simon L. Nielsen: I think it's a big error that ordinary users can issue a 'gmirror stop /dev/mirrir/sample' with success! Are you sure about that? I can't do it on my test system: [EMAIL PROTECTED]:~] gmirror stop /dev/mirror/sys0 Permission denied I'm quiet sure because I accidentally did it once, but unfortnately now I don't have a test machine. The only not so ordinary about my user is that it's in the group wheel. If you have a test machine, could you find out if that's the error? My user was also in wheel so that should not be the problem. If your user is in operator it might be another matter though (new test): [EMAIL PROTECTED]:~] id uid=2000(simon) gid=2000(simon) groups=2000(simon), 0(wheel), 5(operator), 68(dialer) [EMAIL PROTECTED]:~] ll /dev/mirror/sys0 crw-r- 1 root operator 233, 3 Jan 6 11:23 /dev/mirror/sys0 [EMAIL PROTECTED]:~] gmirror stop sys0 Cannot destroy device sys0 (error=16). [EMAIL PROTECTED]:~] gmirror stop -f sys0 hang I don't have a console on the system right now but I assume it got unhappy that I pulled the device under the file system :-). I'm not really sure it is expected that you can do that when being in the operator group. -- Simon L. Nielsen pgp73c4Zt8mCM.pgp Description: PGP signature
Re: GMIRROR can be destroyed by ordinary users
On 2005.01.08 19:39:42 +0100, Pawel Jakub Dawidek wrote: On Sat, Jan 08, 2005 at 04:33:14PM +0100, Simon L. Nielsen wrote: + I'm not really sure it is expected that you can do that when being in + the operator group. Yes. If you want to change it you should do: # chmod 600 /dev/geom.ctl Being in the operator group only gives read access to /dev/geom.ctl (it's root:operator crw-r-) so I think it's somewhat counter intuitive that one can stop the mirror without write permission there. Wouldn't it be better to only allow stopping the mirror (and similar) if the user has write access to geom.ctl? phk fixed some similar issues in some of the other GEOM classes not long ago, e.g. geom_bsd.c v. 1.71. -- Simon L. Nielsen pgpMo2UF4bc5i.pgp Description: PGP signature
Re: ports directories are broken again?
On 2005.01.04 14:30:14 -0800, Joe Rhett wrote: On Fri, Dec 31, 2004 at 05:22:00PM -0800, Kris Kennaway wrote: It provides a link to where the package would be if it exists. The web frontend has no knowledge of which packages are available at any given point in time because this set fluctuates on a daily basis, so the frontend is always going to have windows where it's out of date with respect to what's on the ftp site. I'm sorry, but clue me in here. You are saying that the online database of ports has no idea what is in the ports tree? There is a port, just not a package. The issue is that the web pages uses INDEX (from ports/INDEX) to know which ports exists [1], but INDEX says nothing about packages. It's a while since I looked at the scripts, but there is some kind of mechanism to detect if a package exists for a port, but AFAIR that only works when searching for -STABLE/-CURRENT and not releases. Somebody (tm) would have to make the scripts know which packages exist for which releases to fix this. [1] Which btw. is going to fail for 4.11 since there is no INDEX in CVS... -- Simon L. Nielsen FreeBSD Documentation Team pgpi3hoPltekG.pgp Description: PGP signature
Re: MFCs?
On 2005.01.01 12:17:13 +, Matt Dawson wrote: Is there any chance we will see the new ath, 802.11 and ITE (Gigabyte) RAID MFC'd into 5.x sometime in the future, or is this new stuff going to mean running -CURRENT? Sam has already said that the wlan parts will not be MFC'ed since they break the API/ABI. I would suspect (read I don't know for sure and it's Søren's call) that the ata changes are going to MFC'ed, but since there are some quirks in the ata code in CURRENT at the moment, which are being worked on, I wouldn't hold my breath for the MFC. -- Simon L. Nielsen pgpqmBv3iDjwP.pgp Description: PGP signature
Re: UPDATING file on FreeBSD Stable
On 2004.12.03 19:08:14 +0100, ptitoliv wrote: I have a little question about the UPDATING file on RELENG_5 branch. I have received a security advisory about procfs for my FreeBSD-STABLE. While looking the text of this mail, I saw that the UPDATING file was updating on all RELENG_X.X branches but not in the stable branch. Why not ? On the development branches (-CURRENT and -STABLE) UPDATING is used for changes which users should be aware since they could cause problems. Security fixes rarely fits this requirement. On the security / errata branches (RELENG_X_Y) UPDATING is used to document all changes, so people know exactly what to expect, since only very important changes go into those branches. So, in short the reason is that UPDATING has different goals on the different branches. At least I think that is the reason, I'm actually not 100% sure... :-). -- Simon L. Nielsen pgp9mCdkHchcE.pgp Description: PGP signature
sshd stops accepting connections
Hello Today I suddenly couldn't log in via ssh to a server I upgraded to FreeBSD 5.3-RELEASE 4 days ago. When I tried connect to port 22 using telnet(1) the following just happend: [EMAIL PROTECTED]:~] telnet 192.168.3.2 22 Trying 192.168.3.2... Connected to jet.nitro.dk. Escape character is '^]'. Connection closed by foreign host. The servar had been running FreeBSD 5.2.1 for a while without problems. After logging in on the console and sending the sshd master process a -HUP I could log in again (and I get the normal banner when connecting to the port with telnet(1)). I can't rally see in the log what happened, but there is a lot of stale sshd's hanging around, like: root46015 0,0 0,4 4928 2220 ?? IOns08pm 0:00,01 sshd: blah [pam] (sshd) root58286 0,0 0,4 4920 2236 ?? Is Tor12pm 0:00,04 sshd: pascal [priv] (sshd) sshd58287 0,0 0,0 00 ?? ZTor12pm 0:00,03 defunct root58288 0,0 0,4 4928 2236 ?? ITor12pm 0:00,01 sshd: pascal [pam] (sshd) root58932 0,0 0,4 4920 2236 ?? Is Tor01pm 0:00,05 sshd: ole_gudiksen [priv] (sshd) sshd58934 0,0 0,0 00 ?? ZTor01pm 0:00,06 defunct root58935 0,0 0,4 4928 2236 ?? ITor01pm 0:00,01 sshd: ole_gudiksen [pam] (sshd) pstree show the connection between some of the processes like this: | |-+= 58286 root sshd: pascal [priv] (sshd) | | |--- 58287 sshd defunct | | \--- 58288 root sshd: pascal [pam] (sshd) From all.log: Nov 11 12:04:38 nfishbone sshd[58286]: fatal: Timeout before authentication for 82.211.207.191 Nov 11 13:02:34 nfishbone sshd[58932]: fatal: Timeout before authentication for 192.38.66.33 The only odd thing I could find in the logs with regard to ssh was a few lines like: Nov 11 22:35:49 nfishbone sshd[62378]: syslogin_perform_logout: logout() returned an error I don't use any kind of exotic authentication on the system, only standard unix password file and ssh-keys. Does anybody have an idea of what's going on here, and if it's a ssh bug or something silly I have done? -- Simon L. Nielsen FreeBSD Documentation Team pgp0sQLHMdt0y.pgp Description: PGP signature
Re: ftp.freebsd.org
On 2004.10.23 15:57:37 -0700, Brandon Fosdick wrote: Jack Raats wrote: At this moment I cann't connect with ftp.freebsd.org. I've had the same problem all day. The Danish part of ftp.freebsd.org (ftp.beastie.tdk.net) does not seem to respond, I have poked one of the admins, but since it's late night here in Denmark, it will probably be some hours before anyone can look at the problem. -- Simon L. Nielsen FreeBSD Documentation Team pgpzaWMSIdCv8.pgp Description: PGP signature
Re: atacontrol Raid, cannot re-add member to array
On 2004.07.04 23:33:28 +0200, Harald Schmalzbauer wrote: I've never tried ataraid with non-raid controllers but I doubt that detach/attach would work. It does work, you just have to hotswap the disk [1]. I tried it some time ago, and I successfully did a rebuild, though I did kill one of the disks shortly after since I tried to plug in the power cable the wrong way during another test (yes that's stupid, I know :-) ). I asked Søren about the missing addspare in -stable but never got any answer. AFAIK Søren does not update the ata driver in stable since it's somewhat different than the one in -CURRENT, and he does not have the time to maintain both codebases. AFAIR somebody made a patch for addspare functionality on -STABLE not to long ago. It should be in GNATS somewhere. I just had extreme problems with ataraid on -current and am awaiting some response about these issues, I just can hope that some time ataraid will be lifted to what the man page promises. Well, I'm using it just fine on my main mailserver (running 5.2.1) but that's a RAID1 with standard a ATA controller. [1] WARNING: If you try to hotswap a disk without the proper hardware you might kill your disk (and possibly other parts of the computer)... -- Simon L. Nielsen FreeBSD Documentation Team pgpLB97JaIKEn.pgp Description: PGP signature
Re: Installing FreeBSD without sendmail
[Yes, a bit off-topic for -stable, but -current is not really working ATM] On 2004.04.12 05:02:06 -0700, Jamie Bowden wrote: On this note, sysinstall still puts 'sendmail_enable=NO' in rc.conf if you tell it not to start any MTA as of 5.2.1-RELEASE, which isn't sufficient to stop sendmail from starting at boot time. Could you elaborate? I just tried with my 5.2.1 CD and when I select None in the MTA selection menu, sendmail_enable=NONE is added to rc.conf. -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: Keymap pb when logged in
On 2003.11.09 14:03:07 +0100, Sebastien ROCHE wrote: When I log in, the accentuated characters don't work anymore even if I reload the keymap with kbdcontrol and the fonts with vidcontrol. Have you set the locale variables (LANG, LC_*) ? E.g. I have LANG=da_DK.ISO_8859-1 LC_MESSAGES=en_US.ISO_8859-1 So you probably need to set those variables to something along like that. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/l10n.html for more information. (LC_MESSAGES is set to stop programs from trying to speak Danish.) -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: Mail selection options in sysinstall(8).
On 2003.09.18 23:44:42 +0200, Clement Laforet wrote: On Thu, 18 Sep 2003 15:29:42 -0400 Tom Rhodes [EMAIL PROTECTED] wrote: Hi Tom ! This is just a quick note that the MTA installation options in sysinstall(8) has changed. Users now have the option of choosing between Sendmail, Postfix, and Exim. Due to legal issues, qmail was not added to the selection. Sorry. Do you think it could be a good idea to add simple SMTP systems like ssmtp or any local delivery /usr/sbin/sendmail clone ? Most of system act as standalone machine or satellite one (i.e. machine uses a smtp server on the LAN), and using a full features MTA is, for me, a little bit useless. Sounds like a good idea. Postfix and Exim were mainly chosen because we knew them, but the code was written with the intention to support more MTA's. To add an extra MTA to sysinstall requires that there is a package available, and we need to know if there is any extra steps are needed to make it just work out of the box. If you can supply this information I can rather quickly make a patch to add another MTA to sysinstall. -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: vnconfig and /dev/vn devices?
On 2003.01.02 15:51:12 +, Eric Timme wrote: Is there any way to get other vn devices such as vn0 vn1 etc so that I can mount multiple filesystems at a time? cd /dev sh MAKEDEV vn1 vn2 should do the trick. -- Simon L. Nielsen msg52790/pgp0.pgp Description: PGP signature
Re: Retrieving packages ?
On 2002.12.17 09:28:06 +, Sam Drinkard wrote: Yep.. that's what I tried... Don't know about pkg_add, haven't tried that yet. Problem is all the dependencies for the particular package. Perhaps somebody will comment on how/why it does not work after setting version to -Release. Could it be because it should be set to -RELEASE (with capital letters) ? I just looked in my sysinstall and i have : [CUT] Extract Detail high Release Name4.7-RELEASE Install Root/ [CUT] -- Simon L. Nielsen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Phoenix built from ports
On 2002.11.06 13:27:28 +, Jon wrote: Anyone else have a problem with phoenix 0.4_4 built from ports today? It compiled ok, and executes, but is unable to produce any window before it terminates 15 sec later. It apparently requires Perl 5.6 or higher. There has been some talk on the ports list about it the last couple of days. Try searching the ports archieves. -- Simon L. Nielsen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
