rcorder
Hello! Will rcorder on /usr/local/etc/rc.d problem solved before the 5.4 release? Or it will be still run only for /etc/rc.d? -- With respect, Boris ___ 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 Release Schedule
Ken Smith wrote: On Wed, Feb 02, 2005 at 01:57:11PM +0100, Ivan Voras wrote: Ken Smith wrote: http://www.freebsd.org/releases/5.4R/todo.html Is SCHED_ULE abandoned for 5.x? I wouldn't go as far as to say that but at the moment there are no plans to make changes in the default scheduler for 5.4. A lot of work has been done on it since 5.3 came out so we may 'advertise' it a bit in the release notes and encourage people to start trying it again. Ok, so the plan is to MFC the changes into RELENG_5? AFAIK, the ULE code in RELENG_5 is still the same as in 5.3-release. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adjusting time on a secured FreeBSD machine.
Eli K. Breen [EMAIL PROTECTED] wrote: I'm running in to an issue where I can't set the clock on a machine because the secure level was bumped to 2 before the clock was set. Unfortunately adjustments are now clamped to 1s. Is there any way I can force ntpd to adjust the clock by say, 1s every two seconds or at least something more frequent than 0.128 ms / update? No. (It's 0.5 ms/s, not 0.128 ms/s, BTW.) The ntpd(8) manpage says: | The maximum slew rate possible is limited to 500 parts-per-million | (PPM) as a consequence of the correctness principles on which the | NTP protocol and algorithm design are based. As a result, the local | clock can take a long time to converge to an acceptable offset, about | 2,000 s for each second the clock is outside the acceptable range. | During this interval the local clock will not be consistent with any | other network clock and the system cannot be used for distributed | applications that require correctly synchronized network time. So your choices are to reboot, or to wait until the local clock is synchronized again. You didn't mention how far off your clock is, so I can't tell how long it will take. The maximum slew rate is 1.8 seconds per hour, so if your clock is off by half a minute, it will take about 17 hours to get back in sync. If you can't wait, you'll have to reboot. Best regards Oliver PS: You need to specify the -x option to ntpd, so it does not try to step the clock by more than 1 second. -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C is quirky, flawed, and an enormous success. -- Dennis M. Ritchie. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AW: Slow Network with rl0 and 5.3
EVERYBODY: Could you please check if you have a rl(4) driven NIC and check if you experienced a speed degradation as well. Please let me know either way with information about the chipset on your NIC. Thanks! Hi, I'm using several 8139 NICs, all of them do good :) since 5.3 I'm every now and then having some ...discarding oversize packet frame...1542... (something similar) on the console but some serious downspeed hasn't bothered my notice yet. If you need some details or so let me know by cc please, I'm not reading this group on a very regular basis. Regards, Dorian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
share lists of spammers
Hi all, I know this is quite off topic for this lists, I was wondering if you guys will agree to share your anti-spam softwares' spam lists... the reason is obvious... Especially for SpamAssasin... Thank, Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
share lists of spammers
Hi all, I know this is quite off topic for this lists, I was wondering if you guys will agree to share your anti-spam softwares' spam lists... the reason is obvious... Especially for SpamAssasin... Thanks, Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: share lists of spammers
I'm sorry if I was annoying, i hit send and then saw that i wrote Thank, instead of Thanks and I thought to be polite On Thu, 3 Feb 2005 15:30:18 +0100, Ruben de Groot [EMAIL PROTECTED] wrote: Spamming multiple lists with multiple copies of the same off-topic messages is good enough a reason to get you on my spam list. On Thu, Feb 03, 2005 at 04:03:53PM +0200, Daniel typed: Hi all, I know this is quite off topic for this lists, I was wondering if you guys will agree to share your anti-spam softwares' spam lists... the reason is obvious... Especially for SpamAssasin... Thanks, Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AW: Slow Network with rl0 and 5.3
On Wednesday 02 February 2005 23:34, Dorian Büttner wrote: EVERYBODY: Could you please check if you have a rl(4) driven NIC and check if you experienced a speed degradation as well. Please let me know either way with information about the chipset on your NIC. Thanks! Hi, I'm using several 8139 NICs, all of them do good :) since 5.3 I'm every now and then having some ...discarding oversize packet frame...1542... (something similar) on the console but some serious downspeed hasn't bothered my notice yet. If you need some details or so let me know by cc please, I'm not reading this group on a very regular basis. PR kern/61448 might apply to you. Can you try the diff offered there and follow-up with your findings? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61448 Thanks. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpl5dgBkGfEV.pgp Description: PGP signature
Re: Adjusting time on a secured FreeBSD machine.
I'm not sure that this will cut it as it will days a very long time to adjust to the proper time. Is there any way to speed this up? -E- David Magda wrote: On Feb 2, 2005, at 16:56, Eli K. Breen wrote: Lastly this machine is in production and cannot be rebooted. Stop the NTP daemon and restart it so that it uses the -x option. From ntpd(8): Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize. This option can be used with the -q option. When you restart it make sure it's done with all the CLI options it has now, with the addition of the -x. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adjusting time on a secured FreeBSD machine.
On Thursday, February 03, 2005 5:57 PM, Eli K. Breen unleashed the infinite monkeys and produced: I'm not sure that this will cut it as it will days a very long time to adjust to the proper time. Is there any way to speed this up? Not within NTPd itself. You could go with manually stepping the time in 1s intervals. It's either that or drop the securelevel in rc.conf and reboot (then reset the securelevel). Of course, you probably want to make sure the hardware clock has a vaguely accurate idea of time. That'll help in future. -- Rob | Oh my God! They killed init! You bastards! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adjusting time on a secured FreeBSD machine.
Rob MacGregor [EMAIL PROTECTED] wrote: Eli K. Breen wrote: I'm not sure that this will cut it as it will days a very long time to adjust to the proper time. Is there any way to speed this up? Not within NTPd itself. You could go with manually stepping the time in 1s intervals. Adding to that, the following /bin/sh snippet should do (untested!). You have to kill ntpd before. STEP=100# number of seconds to step forward while [ $STEP -gt 0 ]; do date -f %s $(( `date +%s` + 1 )) sleep 1 STEP=$(( $STEP - 1 )) done It will take about 100 seconds to correct the clock forward by another 100 seconds. If you need to correct backwards, replace + 1 by - 1. For different numbers of seconds to correct, replace the 100 in the first line. When you have approached the correct time sufficiently (i.e. within a few seconds), restart ntpd with the -x option. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adjusting time on a secured FreeBSD machine.
Sorry for replying to myself ... Oliver Fromme [EMAIL PROTECTED] wrote: Adding to that, the following /bin/sh snippet should do (untested!). You have to kill ntpd before. STEP=100# number of seconds to step forward while [ $STEP -gt 0 ]; do date -f %s $(( `date +%s` + 1 )) sleep 1 STEP=$(( $STEP - 1 )) done It will take about 100 seconds to correct the clock forward by another 100 seconds. If you need to correct backwards, replace + 1 by - 1. For different numbers of seconds to correct, replace the 100 in the first line. When you have approached the correct time sufficiently (i.e. within a few seconds), restart ntpd with the -x option. Stepping backwards with that script won't work, I guess, because the steps will be larger than 1 second. If you have to step backwards, try to replace the date line with these: NOW=`date +%s` sleep 0.9 date -f %s $NOW Again: it's untested. Also beware that it might be a very bad idea to step the time on a live multi-user system. Some programs don't like it at all. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek ___ 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] perl symlinks in /usr/bin will be gone
Chuck Swiger [EMAIL PROTECTED] wrote: Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl Why should the authors of those scripts break them for systems which have /bin/env? -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ 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] perl symlinks in /usr/bin will be gone
In the last episode (Feb 03), Christian Weisgerber said: Chuck Swiger [EMAIL PROTECTED] wrote: Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl Why should the authors of those scripts break them for systems which have /bin/env? Are there any systems that have a /bin/env (and that do not also have a /bin - /usr/bin symlink)? -- Dan Nelson [EMAIL PROTECTED] ___ 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] perl symlinks in /usr/bin will be gone
On Feb 3, 2005, at 2:07 PM, Christian Weisgerber wrote: Well-behaved 3rd party scripts ought to start Perl via: #! /usr/bin/env perl Why should the authors of those scripts break them for systems which have /bin/env? Name one such system. [1] Hint: the path to env isn't going to change on a standards-compliant system for the same reason that /bin/sh is always found in the same place. See IEEE Std 1003.x-2001 (POSIX). -- -Chuck [1]: You might actually find a few very old, very broken versions of Linux which don't have a /bin/sh, only a /bin/bash. I've heard such creatures may have a /bin/env rather than a /usr/bin/env, too. ___ 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 Release Schedule
On Thu, Feb 03, 2005 at 11:54:02AM +0100, Ivan Voras wrote: Ok, so the plan is to MFC the changes into RELENG_5? AFAIK, the ULE code in RELENG_5 is still the same as in 5.3-release. That's correct. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA mkIII first official patches - please test!
ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. It contains a number of new things, and lacks a few features of the old code. New items include: o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load atapci and ata to get the base support, and then one or more of the device subdrivers atadisk atapicd atapifd atapist ataraid. All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE only supported on controllers that has this feature: Promise and Silicon Image for now. o ATA RAID support has been rewritten and and now supports these metadata formats: Adaptec HostRAID Highpoint V2 RocketRAID Highpoint V3 RocketRAID Intel MatrixRAID Integrated Technology Express LSILogic V2 MegaRAID LSILogic V3 MegaRAID Promise FastTrak Silicon Image Medley o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing features form current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. o The atapi-cam author has been informed and has had early access to this work but so far atapicam is not supported with these changes. However I do have my own atacam that puts both ATA and ATAPI devices under CAM, but its really just academic at this point. And then there all the things that I've happily forgotten about :) The snapshot is available as a patch for RELENG_5 and for CURRENT, and a common tarfile of the new ATA code. http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz Both patches and the tarfile is relative to /usr/src. You might want to remove the contents of sys/dev/ata/ before unpacking the tarfile. No changes are needed to your config file, unless you want ATA as modules. As usual, even if it works on all the HW I have here in the lab, thats by far not the same as it works on YOUR system. So use glowes and safety shoes and if it breaks I dont want the pieces, but would like to hear the nifty details on how exactly it got that way :) Enjoy! -- -Søren ___ 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] perl symlinks in /usr/bin will be gone
Charles Swiger: Why should the authors of those scripts break them for systems which have /bin/env? Name one such system. [1] There was a discussion about this a few years ago on comp.unix.shell. Let's see... http://tinyurl.com/45zqx Ah, I see, the starting point was actually the reverse assumption that all systems had /bin/env. Somebody mentioned /sbin/env on Irix, but I don't know whether that was instead of /usr/bin/env or in addition to it. Of course I can always handwave in the direction of those hundreds of Linux distributions... -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ 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] perl symlinks in /usr/bin will be gone
On Feb 3, 2005, at 3:55 PM, Christian Weisgerber wrote: [ ... ] Ah, I see, the starting point was actually the reverse assumption that all systems had /bin/env. Somebody mentioned /sbin/env on Irix, but I don't know whether that was instead of /usr/bin/env or in addition to it. Of course I can always handwave in the direction of those hundreds of Linux distributions... Rather than pursue a discussion about systems which neither of us actually uses (or anyone else on this list, probably), I would be just as happy to acknowledge whatever it is your point was and let this thread die peacefully. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
strange make problem with non root users 5.3-STABLE
have a look at this compiling a eggdrop had the same with some other apps as well. [EMAIL PROTECTED] eggdrop1.6.17 # make config make: Permission denied [EMAIL PROTECTED] eggdrop1.6.17 # make config make: Permission denied [EMAIL PROTECTED] eggdrop1.6.17 # cd .. [EMAIL PROTECTED] Gazzeh # cd eggdrop1.6.17 [EMAIL PROTECTED] eggdrop1.6.17 # make config Detecting modules done. Calculating dependencies... done. Building ./src/mod/Makefile... done. As you can see make gave a weird perm denied error then I simply changed dir and back and the command suddenly works, I have worked out when this happens doing a new command and then trying again makes it work. Any idea what could cause this? -r-xr-xr-x 1 root wheel 305232 Feb 3 19:43 /usr/bin/make Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
On Thu, Feb 03, 2005 at 09:52:57PM +0100, S?ren Schmidt wrote: As usual, even if it works on all the HW I have here in the lab, thats by far not the same as it works on YOUR system. So use glowes and safety shoes and if it breaks I dont want the pieces, but would like to hear the nifty details on how exactly it got that way :) THANK YOU! This is the first time since 7 Dec 04 that I've been able to boot a current -CURRENT on my Dell Inspiron 4150 laptop. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
On Thu, 03 Feb 2005 21:52:57 +0100, Søren Schmidt [EMAIL PROTECTED] wrote: ATA-mkIII first official snapshot. Using it without any problems on a few days old 6.0-CURRENT (P2 400 MHz) I decided to take the plunge and go for the kernel-module-approach. The only thing i was curious about is if there is any way to build the kernel-module using ATA_STATIC_ID .. (as i used to do in my normal kernel-configs) Beyond that, it works like a charm :) -- Pascal Hofstee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
On Thu, 3 Feb 2005 18:40:43 -0800, Pascal Hofstee [EMAIL PROTECTED] wrote: The only thing i was curious about is if there is any way to build the kernel-module using ATA_STATIC_ID .. (as i used to do in my normal kernel-configs) Ok .. I whacked myself with the proverbial clue-stick .. and simply put the ATA_STATIC_ID line back into my kernel-config. Even though i chose not to build ata-support not into the actual kernel the opt_ata.h file is of course still used in building the actual kernel-modules. Excuse the line noise :) -- Pascal Hofstee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 - 5 : sshd multiple log entries login_getclass: unknown class 'root'
On Tue, 1 Feb 2005, Andrew Konstantinov wrote: I can't reproduce this on my systems, many of which started at 5.3 and now build 5-stable. Are you using the system ssh or one you built from ports? What is the output of 'ls -l /etc/login.conf*'? I knew I wasn't hallucinating. When I rebuild and reinstall src/lib/libc from RELENG_5_3 sources on RELENG_5 system, all of the above problems disappear altogether. The bugs are in the dynamically linked library that sshd relies on. Once the new library is in place and /etc/rc.d/sshd restart is performed, the bugs disappear. I don't have time to dig into that right now, but I'll be back with patches. The simple fact stands that noone else can reproduce this, which leads me to believe you took a non-standard approach to upgrading, and therefore are getting what you asked for. :-) If you can provide exact reproduction steps, starting from bare metal, I'll follow them. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Geom RAID root report.
On Tue, 1 Feb 2005, David Gilbert wrote: Gmirror on the fix-it CD appears to be impotent. It appears to have only 'help', 'list', 'load' and 'unload' as commands. Not useful. If you manually load the geom_mirror.ko kernel module it probably gets useful. Someone pointed out that there's a hardwired path in there somewhere so load will fail, but if you load the module manually then the commands become available. I'll have to test it. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
