Re: Problem with Compaq SMART-2SL array controller
Jonathan Lemon wrote: For now, you could remove the IDE devices from the config file, until this gets fixed. Ideally, the boot blocks/loader should be taught to boot from something other than wd() or da(). Alas, the loader uses BIOS to read the disk. Anything the BIOS can read, so can the loader. The way it _passes_ the information, though, is limited by the kernel. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Thus, over the years my wife and I have physically diverged. While I have zoomed toward a crusty middle-age, she has instead clung doggedly to the sweet bloom of youth. Naturally I think this unfair. Yet, if it was the other way around, I confess I wouldn't be happy either." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with Compaq SMART-2SL array controller
After doing a cvsup yesterday evening i can't seem to boot on my raid cotroller using the same kernel config. Is -current probing hardware i a different way now or ?? This is a consequence of a defect in the way that the ida driver works, and new code which resorts the disk drivers (so that the 'wd' driver throws out the 'ida' driver). The correct fix for this is nontrivial and a little while off; you might want to go back to your old kernel for a while if the issue hasn't already been resolved. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
Oliver Fromme [EMAIL PROTECTED] writes: The gcc optimizer is traditionally buggy. I wouldn't trust a system compiled with anything more than -O (especially on production servers). The higher optimization levels don't provide much of a speed improvement anyway, sometimes they make the code even slower. YMMV. This is a somewhat religious issue. There is no absolutely safe optimization level, and recommendations needn't remain constant, especially as the compiler changes. There are known problems that break code when compiling with -O. I know at least one case that breaks with -O or -O2 but works with -O3 (this applies to both pre-egcs and egcs compilers). When things will break is very unpredictable. In my experience, -O2 rarely causes additional breakage compared to -O in correct code. In egcs = 1.1 and gcc = 2.95, -O2 includes new optimizations that can improve performance quite significantly. Sometimes breakage can also be caused by incorrect code that is only exposed by the optimization. You really shouldn't generalize too much. All you can correctly state is that software package X seems to work well with gcc/egcs version Y at optimization level Z. You can also state that some gcc/egcs version has known bugs at some optimization level (however, all reasonably current versions have known bugs at *all* optimization levels). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
On Fri, Sep 24, 1999 at 12:08:10PM +0900, Daniel C. Sobral wrote: The point is that it _does_ hurt. Anything above -O3 is _likely_ to have bugs. I am forced to agree about the fact that optimisation is traditionally buggy :) I tried to optimize my system with -O3 and -pipe. So I build myself a new kernel and a new world, I booted the kernel (I forgot to install the world)... It booted, windowmaker came up, I executed a linux-compatible binary (elf) and my system ended up with a boot. Thank god I didn't do a installworld :) Right now I'm recompiling everything using only -O and -pipe. Maybe its the linux-libs that had to be recompiled, but I don't have the time to sort this out because this machine has to be kind online without the fear of too much downtime. (I know .. -current .. living on the edge) :) I'll try to sort it out this weekend. -Steve -- Stephan van BeerschotenEmail: [EMAIL PROTECTED] Network Engineer Luna Internet Services www.luna.nl PO Box 28013 3003 KA Rotterdam NL PGPKey fingerprint = 45 57 97 61 B2 12 FB 4C 77 8D 35 29 C4 2A 2D 27 "RETURN VALUES: The panic() function call does not return" :P To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freebsd-uthread.c
On Thu, 23 Sep 1999, Kip Macy wrote:
In three places in your code you do the following or something similar:
ptr = (CORE_ADDR) cached_pthread.nxt;
struct pthread has no member nxt in either -current or -stable
and your patch did not add it to pthread_private.h
What did you mean for this to be?
This field changed after I generated the patch. Here is the latest diff
against -current (not sure if it will work in -stable):
Index: Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/binutils/gdb/Makefile,v
retrieving revision 1.43
diff -u -r1.43 Makefile
--- Makefile1999/08/27 23:34:48 1.43
+++ Makefile1999/09/05 21:59:39
@@ -8,20 +8,20 @@
XSRCS= annotate.c ax-general.c ax-gdb.c bcache.c blockframe.c \
breakpoint.c buildsym.c c-exp.y c-lang.c c-typeprint.c \
c-valprint.c ch-exp.c ch-lang.c ch-typeprint.c ch-valprint.c\
- coffread.c command.c complaints.c copying.c corefile.c \
- corelow.c core-regset.c cp-valprint.c dcache.c dbxread.c demangle.c \
- dwarfread.c dwarf2read.c elfread.c environ.c eval.c exec.c \
- expprint.c f-exp.y f-lang.c f-typeprint.c f-valprint.c \
- findvar.c fork-child.c gdbarch.c gdbtypes.c infcmd.c inflow.c \
- infptrace.c infrun.c inftarg.c language.c jv-exp.y jv-lang.c\
- jv-valprint.c jv-typeprint.c nlmread.c m2-lang.c m2-exp.y \
- m2-typeprint.c m2-valprint.c main.c maint.c mdebugread.c\
- mem-break.c minsyms.c objfiles.c parse.c printcmd.c remote.c\
- remote-utils.c scm-exp.c scm-lang.c scm-valprint.c solib.c \
- source.c stabsread.c stack.c symfile.c symmisc.c symtab.c \
- target.c thread.c top.c tracepoint.c typeprint.c utils.c\
- valarith.c valops.c valprint.c values.c version.c serial.c \
- ser-unix.c ser-tcp.c callback.c
+ coffread.c command.c complaints.c copying.c core-regset.c \
+ corefile.c corelow.c cp-valprint.c dcache.c dbxread.c \
+ demangle.c dwarfread.c dwarf2read.c elfread.c environ.c eval.c \
+ exec.c expprint.c f-exp.y f-lang.c f-typeprint.c f-valprint.c \
+ findvar.c fork-child.c freebsd-uthread.c gdbarch.c gdbtypes.c \
+ infcmd.c inflow.c infptrace.c infrun.c inftarg.c language.c \
+ jv-exp.y jv-lang.c jv-valprint.c jv-typeprint.c nlmread.c \
+ m2-lang.c m2-exp.y m2-typeprint.c m2-valprint.c main.c maint.c \
+ mdebugread.c mem-break.c minsyms.c objfiles.c parse.c \
+ printcmd.c remote.c remote-utils.c scm-exp.c scm-lang.c \
+ scm-valprint.c solib.c source.c stabsread.c stack.c symfile.c \
+ symmisc.c symtab.c target.c thread.c top.c tracepoint.c \
+ typeprint.c utils.c valarith.c valops.c valprint.c values.c \
+ version.c serial.c ser-unix.c ser-tcp.c callback.c
SRCS= init.c ${XSRCS}
.if exists(${.CURDIR}/Makefile.${MACHINE_ARCH})
@@ -34,6 +34,8 @@
CFLAGS+= -I${SRCDIR}/bfd
CFLAGS+= -I${GDBDIR}/gdb
CFLAGS+= -I${GDBDIR}/gdb/config
+CFLAGS+= -I${.CURDIR}/../../../../lib/libc_r/uthread #pthread_private.h
+CFLAGS+= -I${.CURDIR}/../../../../lib/libc/include #spinlock.h
LDADD+=-L${RELTOP}/libbfd -lbfd
LDADD+=-L${RELTOP}/libopcodes -lopcodes
LDADD+=-lreadline
Index: freebsd-uthread.c
===
RCS file: freebsd-uthread.c
diff -N freebsd-uthread.c
--- /dev/null Fri Sep 24 08:17:20 1999
+++ freebsd-uthread.c Wed Aug 18 06:28:01 1999
@@ -0,0 +1,1005 @@
+/* Low level interface for debugging FreeBSD user threads for GDB, the GNU debugger.
+ Copyright 1996, 1999 Free Software Foundation, Inc.
+
+This file is part of GDB.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
+
+/* This module implements a sort of half target that sits between the
+ machine-independent parts of GDB and the ptrace interface (infptrace.c) to
+ provide access to the FreeBSD user-mode thread implementation.
+
+ FreeBSD threads are true user-mode threads, which are invoked via
+ the pthread_* interfaces. These are mostly implemented in
+ user-space, with all thread context kept in
Re: On hub.freebsd.org refusing to talk to dialups
Do you know about the RBL? How do you feel about it? We are using it via DNS and BGP on a test basis right now.I have had legitimate important mail blocked at Freebsd.org due to the source being on the RBL, but that is a price I am willing to pay. The RBL is great! There is a teensy bit of colateral damage, but not so much that I worry about it. Here in ZA, our USP traffic provider (Teleglobe) uses RBL, thus absolving us of the responsibility. Since we started getting this "cleanfeed", spam has dropped dramatically. What I particularly enjoy about the RBL is its strong sense of the need to listen to its client base, and to adapt as necessary. Paul Vixie has a high degree of respect, as a consequence. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RBL, DUL + other acronymns [was Re: On hub.freebsd.org refusing to talk to dialups]
For those who don't know the acronymns RBL, DUL, etc... (like me a few minutes ago :-), they are: RBL Realtime Blackhole List TSI Transport Security Initiative DUL Dial-up User List RSS Relay Spam Stopper. More information can be found at the site: http://maps.vix.com/. Regards, Mike Kennett. [trim of old thread] Do you know about the RBL? How do you feel about it? We are using it via DNS and BGP on a test basis right now.I have had legitimate important mail blocked at Freebsd.org due to the source being on the RBL, but that is a price I am willing to pay. The RBL is great! There is a teensy bit of colateral damage, but not so much that I worry about it. Here in ZA, our USP traffic provider (Teleglobe) uses RBL, thus absolving us of the responsibility. Since we started getting this "cleanfeed", spam has dropped dramatically. What I particularly enjoy about the RBL is its strong sense of the need to listen to its client base, and to adapt as necessary. Paul Vixie has a high degree of respect, as a consequence. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
From: "Rodney W. Grimes" [EMAIL PROTECTED] Date: Fri, 24 Sep 1999 03:00:55 -0700 (PDT) Another thing that ISP coulds start doing (we are in process with this now, but on a monitoring only basis, instead of a deny we just log them) is to block all outbound from AS tcp 25 setup packets. Not quite sure I follow this. This prevents your customers from being something that could get you on the RBL or the DUL MAP for bad behavior, it also inforces the use of your smart host relay, as it/they is/are the only way to get a tcp port 25 setup completed. About the only positive thing I have to say about the DUL is that Vix stated that entries are placed on it at the request of the custodians of the netblock in question. Do you know about the RBL? How do you feel about it? We are using it via DNS and BGP on a test basis right now.I have had legitimate important mail blocked at Freebsd.org due to the source being on the RBL, but that is a price I am willing to pay. I'm far more comfortable with the use of the RBL than the DUL. Indeed, my externally-visible home SMTP server uses the RBL (but not the DUL). Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD-specific denial of service
The following is from BUGTRAQ. There's a fix for -stable, though there is none for -current. Is -current vulnerable? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: [EMAIL PROTECTED] ITSD [EMAIL PROTECTED] Province of BC "e**(i*pi)+1=0" --- Forwarded Message Replied: Fri, 24 Sep 1999 07:32:41 -0700 Replied: Adrian Penisoara [EMAIL PROTECTED] Replied: "Charles M. Hannum" [EMAIL PROTECTED] Replied: [EMAIL PROTECTED] Replied: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id HAA19965 for cy; Fri, 24 Sep 1999 07:07:39 -0700 (PDT) Resent-Message-Id: [EMAIL PROTECTED] Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdL19958; Fri Sep 24 07:06:39 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id HAA19950 for [EMAIL PROTECTED]; Fri, 24 Sep 1999 07:06:39 -0700 (PDT) Received: from point.osg.gov.bc.ca(142.32.102.44) via SMTP by passer.osg.gov.bc.ca, id smtpdW19948; Fri Sep 24 07:06:27 1999 Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA04613 for [EMAIL PROTECTED]; Fri, 24 Sep 1999 07:06:27 -0700 Received: from hub.FreeBSD.ORG(204.216.27.18) via SMTP by point.osg.gov.bc.ca, id smtpda04611; Fri Sep 24 07:06:14 1999 Received: by hub.freebsd.org (Postfix, from userid 538) id 47FB414D1C; Fri, 24 Sep 1999 07:04:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 309E61CD621; Fri, 24 Sep 1999 07:04:18 -0700 (PDT) (envelope-from owner-freebsd-security) Received: by hub.freebsd.org (bulk_mailer v1.12); Fri, 24 Sep 1999 07:04:18 -0700 Delivered-To: [EMAIL PROTECTED] Received: from ady.warpnet.ro (ady.warpnet.ro [194.102.224.1]) by hub.freebsd.org (Postfix) with ESMTP id C4621150E5 for [EMAIL PROTECTED]; Fri, 24 Sep 1999 07:04:02 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id RAA36387; Fri, 24 Sep 1999 17:02:25 +0300 (EEST) (envelope-from [EMAIL PROTECTED]) Date: Fri, 24 Sep 1999 17:02:25 +0300 (EEST) From: Adrian Penisoara [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] To: "Charles M. Hannum" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD-specific denial of service In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [EMAIL PROTECTED] X-Loop: FreeBSD.org Precedence: bulk Resent-To: cy Resent-Date: Fri, 24 Sep 1999 07:06:39 -0700 Resent-From: Cy Schubert [EMAIL PROTECTED] X-UIDL: e11831742cf1648327586c6ab307b72c Hi, On Tue, 21 Sep 1999, Charles M. Hannum wrote: [Resending once, since it's been 10.5 days...] Here's an interesting denial-of-service attack against FreeBSD =3.0 systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no way to purge entries unless the `vnode' (e.g. the file) they point to is removed from memory -- which generally doesn't happen unless a certain magic number of `vnodes' is in use, and never happens when the `vnode' (i.e. file) is open. Thus it's possible to chew up an arbitrary amount of wired kernel memory relatively simply. Seems to be fixed in CVS version 1.38.2.3 of vfs_cache.c for RELENG_3 branch (meaning 3.3-STABLE) -- could you please check again ? Commit log: Limit aliases to a vnode in the namecache to a sysctl tunable 'vfs.cache.maxaliases'. This protects against a DoS via thousands of hardlinks to a file wiring down all kernel memory. Ady (@freebsd.ady.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-security" in the body of the message --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do FreeBSD mailing lists ignore MX preference?
On Fri, Sep 24, 1999 at 09:22:05AM -0500, Bruce Albrecht wrote: I know this is not -current related, but then, neither is the thread on hub.freebsd.org refusing DUL origin messages. I have a DSL line with static IP, and all my FreeBSD mailing lists are sent to [EMAIL PROTECTED] There are two DNS MX records for zuhause.mn.org, one at preference 100 with my IP address, and a second at preference 150 for the mn.org main mail server. Even though my IP has a lower preference value, none of my FreeBSD mailing list mail come directly to my machine, it all passes through the minuet.skypoint.net. I get plenty of mail sent to zuhause.mn.org from other locations which talk directly to my machine, so why don't the FreeBSD mailing lists? It's not allowed to use ip addresses in MX records, only hostnames, and postfix doesn't accept the ip address, sendmail does. jesper@freesbee$ host -t mx zuhause.mn.org zuhause.mn.org mail is handled (pri=100) by 205.215.217.178 zuhause.mn.org mail is handled (pri=150) by minuet.skypoint.net So change it to zuhause.mn.org. IN A 205.215.217.178 IN MX 100 zuhause.mn.org. IN MX 150 minuet.skypoint.net. /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Filtering port 25 (was Re: On hub.freebsd.org refusing to talk to dialups)
[This thread is off topic, but ... ] On 24 September 1999 at 3:00, "Rodney W. Grimes" [EMAIL PROTECTED] wrote: Another thing that ISP coulds start doing (we are in process with this now, but on a monitoring only basis, instead of a deny we just log them) is to block all outbound from AS tcp 25 setup packets. Monitoring this is not a bad idea. However, if you are suggesting that an ISP should /filter/ TCP port 25 packets, I have to disagree strongly. Vehemently, even :-) An ISP is in the business of delivering IP traffic. An ISP that fails to deliver ALL packets that are well formed (according to the relevant IETF standards and have a legitimate source address) is not doing what they are being payed to do. This prevents your customers from being something that could get you on the RBL or the DUL MAP for bad behavior, it also inforces the use of your smart host relay, as it/they is/are the only way to get a tcp port 25 setup completed. Evil! How does the ISP know I'm not running some other protocol (which is none of its business) on port 25? How does it know that I don't have a policy reason for accessing some other mail server than its own? Don't throw out the baby with the water! end-of-rant :-) Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
"Zach N. Heilig" [EMAIL PROTECTED] wrote: The application for the tests is mpg123. test mp3 playing time: 373 seconds. [ ... ] 1) No Optimization 225.08 real 224.30 user 0.23 sys [ ... ] 2) -O3 -mcpu=i486 -march=i486 -fomit-frame-pointer -fschedule-insns -fschedule-insns2 141.92 real 141.43 user 0.10 sys What do these timings represent? As you say the mp3 playing time is 373 seconds, but the "real" times vary, the timings don't appear to be the playing/processing of the mp3 file. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ccd build failure
In message [EMAIL PROTECTED] "Matthew D. Fuller" writes: : OK: : #!/bin/sh : (cvs status | grep '^File:' | grep -v 'Status: Up-to-date$') 2 /dev/null ^^ -q Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
These days the RBL is more of a preventative measure than a blocking measure. It has already forced most open relays to tighten up. I'll go with that. The DUL stops _huge_ amounts of "drive-by" spam, though... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
On Fri, 24 Sep 1999 12:08:10 +0900, "Daniel C. Sobral" [EMAIL PROTECTED] said: The point is that it _does_ hurt. Anything above -O3 is _likely_ to have bugs. And more to the point: the FreeBSD Project will not support those who compile their kernel or world with anything other than the default optimization settings and compilers. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do FreeBSD mailing lists ignore MX preference?
Non-authoritative answer: zuhause.mn.org preference = 150, mail exchanger = minuet.skypoint.net zuhause.mn.org preference = 100, mail exchanger = 205.215.217.178 postfix does not like your numeric MX record Sep 24 01:35:46 hub postfix/smtp[77991]: warning: valid_hostname: numeric hostname: 205.215.217.178 Sep 24 01:35:49 hub postfix/smtp[77991]: 76AE315266: to=[EMAIL PROTECTED], relay=minuet.skypoint.net, delay=66, status=sent (250 DAA01296 Message accepted for delivery) jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
From: "Rodney W. Grimes" [EMAIL PROTECTED]
Date: Fri, 24 Sep 1999 03:00:55 -0700 (PDT)
Another thing that ISP coulds start doing (we are in process with
this now, but on a monitoring only basis, instead of a deny we
just log them) is to block all outbound from AS tcp 25 setup packets.
Not quite sure I follow this.
ipfw add 10250 allow tcp from ${smtpsmarthost} to any 25 setup out via lnc1
ipfw add 10259 allow log tcp from any to any 25 setup out via lnc1
This is placed on all AS border routers, anyone attempting to
do direct port 25 outbound from our AS trips 10259 and gets to talk
to me about what it is they are doing.
The comptete rules set is a fair bit more complicated than the above
as we are also a transit AS and I have to allow the port 25 setup traffic
from them to work correctly, so I can't just go make 10259 a deny at
this time.
This prevents your customers from being something that could get you
on the RBL or the DUL MAP for bad behavior, it also inforces the use
of your smart host relay, as it/they is/are the only way to get a
tcp port 25 setup completed.
About the only positive thing I have to say about the DUL is that Vix
stated that entries are placed on it at the request of the custodians of
the netblock in question.
If that is the case then this is ideal. Everyone should be using the
DUL, as the maintainer of that IP space has specifically stated that
they do not want or allow smtp setup connections from that IP space.
Thus by using the DUL you are simply helping a costodian implement
the policy they have already layed down.
Do you know about the RBL? How do you feel about it? We are using
it via DNS and BGP on a test basis right now.I have had legitimate
important mail blocked at Freebsd.org due to the source being on the
RBL, but that is a price I am willing to pay.
I'm far more comfortable with the use of the RBL than the DUL.
Given what you stated above I don't see how you could favor the
RBL over the DUL, the DUL is stated administrative policy, the RBL
is a reactive to bad behavior and in opposition to stated administrative
policy for almost every entry in it.
Indeed, my externally-visible home SMTP server uses the RBL (but not the
DUL).
You should probably run both I know I am going to go see what it
takes to intergrate DUL into our current scheme of things. And submit
our IP dial up blocks for inclusion in the list.
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
would immediately unsubscribe to any isp that decided this was acceptable
behavior on their part.
I agree.
Your work also has a serious security concern if it allows this you to
directly attatch to it's port 25.
No it doesn't, but you do bring up another good point why not to use the
ISP's mail server. Security. I don't want email to bounce on your box
and potentially give the ISP's postmaster information they shouldn't be
having. (Including email about us switching ISP's because we hate their
email policy. :)
If your mail is sensitive use a proper transport, encrypt it.
Yes, our ISP *could* sniff packets are read our email if they wanted,
but it would be a breach of contract for them to do so.
No, it would not, I have yet to see any ISP's contract that says such
a thing. Do not attempt to apply common carrier status to ISP's,
that only works if they happen to be CLEC/LEC/IXC/LD's or some such,
and only if they screwed up thier organizationalization to cause the
ISP portion of the business to classify under the common carrier laws.
Basically, I think not allowing ISP's to allow the Dialup lines to
forward email as a good thing, but for them to limit was businesses do
with their IP traffic is simply too big brother'ish, no matter what
their contract states.
If _we_ don't start to do something about it, big brother _is_ going
to do something about it. Trust me on this one, being a member of the
USPA I know that we are far better off implementing our own (as ISP's)
set of safe gaurds that help eliminate certain undesirable behavior.
5 years ago I could get in a jump plan and not worry about a seat or
a seat belt. Now the FAA has regulated us into mandator seat's and
seat belts. Yes, it improved safety, but the fact that the FAA now
runs around poping surprize inspections cost me more tax payer dollars
for something we all knew we should have been doing all along. I
don't want any more stinking laws!!
Also understand that ISP's can be held legally liable under negligence
law for certain in actions. There are cases on the books that demonstrate
this. Unfortanate, but true non the less.
I'm as much at risk (or more) from spammers that abuse my mail host as
they are, so it behooves me to setup my mail machine (and network) to
'Do The Right Thing'. Rather than ISP's blocking email, they should
instead be working with their customers to provide them with expertise
on how to setup a working/usable mail server.
And we do, for dedicated connect customers ${smtpsmarthost} usally
includes their host as well, but we prefer to have them hand the
mail off to our servers since it is far better designed than 99%
of what any customer can even afford to do.
For the really big clients we even co-locate thier dedicated smtp
smarthost in our facility for them. This saves them traffic on
thier link, puts them on carrier class power and environment, and
gives them a 24x7 tech winnie to fix any problems.
They also have great benifits by agreeing to our standard AUP, they
have RBL filtering done, etc, etc, etc. This is the _service_ part
of ISP that every one else leaves out. If you want IP without service
go talk to someone else. We are about service. A lot of what we implemented
was actually caused by direct requests from customers. We have had
no complaints about it, and I don't get email from the RBL maintainers!
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
Strange. I use the RBL on my mail server here, but it really doesn't accomplish much. In the past 8 days it has blocked only 3 distinct spam e-mails, and that's typical. Yet I still receive an average of 5-10 spam mails in my mailbox every day. (*Must* *stop* *fist* *of* *death*!) A few random manual checks seem to indicate that the DUL would do much better for me. insert plug for the FreeBSDcon talk "Stopping Spam--Five Years in the Trenches" by Jonathan M Bresler ;P jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
At 03:00 AM 9/24/1999 -0700, you wrote: Another thing that ISP coulds start doing (we are in process with this now, but on a monitoring only basis, instead of a deny we just log them) is to block all outbound from AS tcp 25 setup packets. Hmm, maybe I'm interpreting this wrong (I hope so), but I interpret this as saying that basically you'd only be able to mail things through your local isp's mailhost. It means that if you use several different mail servers, all mail would still have to go through the local isp's. Personally, I Yep, thats exactly what I am saying. would immediately unsubscribe to any isp that decided this was acceptable behavior on their part. I use the mail server at work for all my outgoing mail. Why? Because the machine is lightly loaded and I don't have to worry about my mail getting lost in the depths of my isp's mail server for a couple hours because their loads tend to run high. (Hell, I don't generally even use the email account provided by the local isp because of load issues, my work account is so much more reliable). Our outbound smarthost smtp server is carefully monitor, has never lost a single mail message, and screaming fast at getting email out. After all we also run commercial opt-in bulk emailing for large clients and we do know how to get 100's of thosands of messages out in a real fast way. Probably mork work has been put into our smarthost than any company has bothered to put into thier smtp relay. Your work also has a serious security concern if it allows this you to directly attatch to it's port 25. Can you say firewall circumvention... I thought so. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
I agree. Your work also has a serious security concern if it allows this you to directly attatch to it's port 25. No it doesn't, but you do bring up another good point why not to use the ISP's mail server. Security. I don't want email to bounce on your box and potentially give the ISP's postmaster information they shouldn't be having. (Including email about us switching ISP's because we hate their email policy. :) If your mail is sensitive use a proper transport, encrypt it. All mail is senstive, it just that sometimes that the cost of encrypting is more expensive than the cost of setting everyone up so they can decrypt it. In short, there is no 'portable' way of encrypting/decrypting mail. Yes, our ISP *could* sniff packets are read our email if they wanted, but it would be a breach of contract for them to do so. No, it would not. *YES*, it would. Don't tell me what my ISP can/can not do, because you have no idea. Basically, I think not allowing ISP's to allow the Dialup lines to forward email as a good thing, but for them to limit was businesses do with their IP traffic is simply too big brother'ish, no matter what their contract states. If _we_ don't start to do something about it, big brother _is_ going to do something about it. Now you're going off the deep-end. Big-brother has shown that they simply don't *care* what happens, to the point that SPAM is still legal to do in almost all cases, and people must opt-out of it. They also have great benifits by agreeing to our standard AUP, they have RBL filtering done, etc, etc, etc. This is the _service_ part of ISP that every one else leaves out. As I stated before, any decent ISP will take the time to help a client setup services they desire, not do it for them. Doing it for a customer WHO WANTS TO DO IT THEMSELVES is the unix way. We're doing it, because you're too stupid/clueless to do it yourself, and we're not going to give out the 'secret' information. If the customer doesn't want to host it themselves, then by all means have the ability to do it for them, and you can charge them for it even. :) But, just because you think you are an ISP doesn't make you any more expert than people running their own businesses off it. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
One of us, at least, evidently. How much mail does the use of the MAPS DUL reject? varies sharply from day to day. since 8/31 dul has rejected 93 connection attempts. map has rejected 361 connection attempts. How much of that do you think is worth rejecting? all of it. dialup addresses are havens for spammersthese are throw away accounts that are covered by the cost of the spamming. only if the spammer is sued successfully does teh account become a problem to the spammer. legitimate dialup users should use the mail relay provided by their ISP. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experimental ACPI driver.
Hi, there. We wrote experimental ACPI driver for 4.0-CURRENT. This was just one week work so its functionallity is very very poor :-) but I think it is good idea to start with this for developping ACPI driver for FreeBSD because it is enough small to understand it. If someone already started wriring ACPI devive driver, please let us know. We'd like to merge them and would be happy in collaboration with you. If you have question please ask me or [EMAIL PROTECTED] . BTW, I've just start leaning a week ago, my knowledge is still little on ACPI :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rtc?
I reinstalled -current today, and for some reason there is an extra device generating interrupts. When I do a systat -vm 1 I find that there is a device called rtc at irq8 generating 128 interrupts. What is it? I didn't configure it, and it wasn't there before. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtc?
In message [EMAIL PROTECTED], Kenneth Culver writes: I reinstalled -current today, and for some reason there is an extra device generating interrupts. When I do a systat -vm 1 I find that there is a device called rtc at irq8 generating 128 interrupts. What is it? I didn't configure it, and it wasn't there before. It has always been there, it is the RTC clock or "softclock" which is used to tally up the user/system times for processes and a few similar statistics jobs. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
I agree. Your work also has a serious security concern if it allows this you to directly attatch to it's port 25. No it doesn't, but you do bring up another good point why not to use the ISP's mail server. Security. I don't want email to bounce on your box and potentially give the ISP's postmaster information they shouldn't be having. (Including email about us switching ISP's because we hate their email policy. :) If your mail is sensitive use a proper transport, encrypt it. All mail is senstive, it just that sometimes that the cost of encrypting is more expensive than the cost of setting everyone up so they can decrypt it. In short, there is no 'portable' way of encrypting/decrypting mail. Yes, our ISP *could* sniff packets are read our email if they wanted, but it would be a breach of contract for them to do so. No, it would not. *YES*, it would. Don't tell me what my ISP can/can not do, because you have no idea. I think you should take a chill pill, then go read that contract again... there should at least be a clause that allows them to monitor (``sniff'') for the purpose of rendering service. If not, they really blew thier contract from a legal prespective as now they can't even hook up a sniffer to trouble shoot, run tcpdump, etc. Basically, I think not allowing ISP's to allow the Dialup lines to forward email as a good thing, but for them to limit was businesses do with their IP traffic is simply too big brother'ish, no matter what their contract states. If _we_ don't start to do something about it, big brother _is_ going to do something about it. Now you're going off the deep-end. Big-brother has shown that they simply don't *care* what happens, to the point that SPAM is still legal to do in almost all cases, and people must opt-out of it. You haven't been around unregulated things much have you? HAM radio and the FCC use to be a pretty open page, now it's rules up the wazoo. Skydiving use to be totally unregulated, started out as a few pages in a FAR, now its getting bigger, and if the USPA had not taken drastics steps 5 years ago to impose it's own major self regulation the FCC was ready to cram some pretty tight rules down our throats. It took untold time and money to sway the FCC into letting us correct the problem ourselves. One reason spam is still legal is we (the internet community at large) has made inroads into cutting it down, and are infact at least trying to self regulate it. Uncle sam will only keep its hands off so long, but trust me, a few more kidnappings by email occur and your going to see some deadly serious laws proposed. We already have several laws on the books, one in Washigton, and another in California. There has been a propsed senate bill. If you think this is ``don't care'' aditude you had better wake up to just how the legislative process works. They never get it right the first 10 times, and by the time they get it done it's way more than what was ever needed. They also have great benifits by agreeing to our standard AUP, they have RBL filtering done, etc, etc, etc. This is the _service_ part of ISP that every one else leaves out. As I stated before, any decent ISP will take the time to help a client setup services they desire, not do it for them. Doing it for a customer WHO WANTS TO DO IT THEMSELVES is the unix way. We're doing it, because you're too stupid/clueless to do it yourself, and we're not going to give out the 'secret' information. Then your an exception in the general populus of clients, as we are an exception in the general populas of ISP's. Most customers actually like it when you do something for them for free that they wanted done anyway. Like I said else where, most of this has been done at customer requests. If the customer doesn't want to host it themselves, then by all means have the ability to do it for them, and you can charge them for it even. :) But, just because you think you are an ISP doesn't make you any more expert than people running their own businesses off it. We don't think we are an ISP, we are. Myself, well, I'm not, I just do contract work for a dozen or so companies that call themselves ISP's. If you really think I am lost and off the deep end, well... thats your right. Several of the peers to us are loving what we do for them... and our attrition rate has gone done since we implemented many of these policies. Being able to tout ``Reduced spam internet service'' on a sales litrature is a selling point to many a client... -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
: I would immediately unsubscribe to any isp that decided this was acceptable : behavior on their part. I use the mail server at work for all my outgoing : mail. Why? Because the machine is lightly loaded and I don't have to : worry about my mail getting lost in the depths of my isp's mail server for : a couple hours Amen. For that matter, I'd much rather have my private data on the public wire than on an independently administered server's disk -- make them at least take the trouble to run a sniffer in order to see the data! [But let's redirect this to chat.] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do FreeBSD mailing lists ignore MX preference?
According to Bruce Albrecht: zuhause.mn.org preference = 150, mail exchanger = minuet.skypoint.net zuhause.mn.org preference = 100, mail exchanger = 205.215.217.178 ^^^ This is plainly wrong. You're not allowed to put IP addresses in MX records. If you have a static address then you should have a PTR pointing to your machine. Use that. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
System crash on vinum start
I'm having a problem where the "vinum start" command crashes my system.
This happens regardless of whether it's being issued during bootup via
/etc/rc or from the command line on a running system.
Interestingly, however, if I issue the start command from the vinum
interactive prompt, it works properly with no crash.
I'm currently running on a snap built this morning (0924), but it was
also happening on a snap from 0914.
Crash info, vinum config, and disk info are below. Let me know if I
can provide any additional information.
Thanks,
Brad
# uname -a
FreeBSD 4.0-19990924-SNAP FreeBSD 4.0-19990924-SNAP #1: Fri Sep 24 15:49:04 EDT 1999
root@:/usr/src/sys/compile/PRISMDB i386
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 3878912
initial pcb at 332900
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x48
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018b64b
stack pointer = 0x10:0xc94f4bb0
frame pointer = 0x10:0xc94f4be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 195 (vinum)
interrupt mask = bio
trap number = 12
panic: page fault
syncing disks... 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112
112 112 112 giving up
dumping to dev #wd/0x20001, offset 786432
dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53
52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
281 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
#1 0xc0169e80 in poweroff_wait (junk=0xc02fd44f, howto=-928026240)
at ../../kern/kern_shutdown.c:531
#2 0xc0272269 in trap_fatal (frame=0xc94f4b70, eva=72)
at ../../i386/i386/trap.c:907
#3 0xc0271f41 in trap_pfault (frame=0xc94f4b70, usermode=0, eva=72)
at ../../i386/i386/trap.c:800
#4 0xc0271beb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 512, tf_ebp = -917550112, tf_isp = -917550180, tf_ebx = 0,
tf_edx = 0, tf_ecx = 8, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072122293, tf_cs = 8, tf_eflags = 66118, tf_esp = -91755,
tf_ss = 512}) at ../../i386/i386/trap.c:426
#5 0xc018b64b in getblk (vp=0x0, blkno=8, size=4096, slpflag=0, slptimeo=0)
at ../../kern/vfs_bio.c:2109
#6 0xc018995a in bread (vp=0x0, blkno=8, size=4096, cred=0x0, bpp=0xc94f4c50)
at ../../kern/vfs_bio.c:477
#7 0xc0d65fcf in ?? ()
#8 0xc0d67072 in ?? ()
#9 0xc0d64e6d in ?? ()
#10 0xc0d64ec7 in ?? ()
#11 0xc0d6af94 in ?? ()
#12 0xc019dc47 in spec_ioctl (ap=0xc94f4e08)
at ../../miscfs/specfs/spec_vnops.c:513
#13 0xc019d4bd in spec_vnoperate (ap=0xc94f4e08)
at ../../miscfs/specfs/spec_vnops.c:124
#14 0xc023ef09 in ufs_vnoperatespec (ap=0xc94f4e08)
at ../../ufs/ufs/ufs_vnops.c:2313
#15 0xc0197f20 in vn_ioctl (fp=0xc0d29100, com=3288352320,
data=0xc0d59000 "read", p=0xc8af7180) at vnode_if.h:395
#16 0xc0176fcb in ioctl (p=0xc8af7180, uap=0xc94f4f80) at ../../sys/file.h:166
#17 0xc02724a6 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 5, tf_esi = -1077950456, tf_ebp = -1077949432,
tf_isp = -917549100, tf_ebx = 5, tf_edx = 134794277,
tf_ecx = -1077950407, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134659084, tf_cs = 31, tf_eflags = 582, tf_esp = -1077950488,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#18 0xc02654c6 in Xint0x80_syscall ()
#19 0x804cbc7 in ?? ()
#20 0x8048492 in ?? ()
#21 0x80482fd in ?? ()
#22 0x80480e9 in ?? ()
# vinum list
Configuration summary
Drives: 4 (8 configured)
Volumes:1 (4 configured)
Plexes: 1 (8 configured)
Subdisks: 4 (16 configured)
D d0State: up Device /dev/da0eAvail: 0/17366 MB (0%)
D d1State: up Device /dev/da1eAvail: 0/17366 MB (0%)
D d2State: up Device /dev/da2eAvail: 0/17366 MB (0%)
D d3State: up Device /dev/da3eAvail: 0/17366 MB (0%)
V raid5 State: up Plexes: 1 Size: 50 GB
P raid5.p0 R5 State: up Subdisks: 4 Size: 50 GB
S raid5.p0.s0 State: up PO:0 B Size: 16 GB
S raid5.p0.s1
Re: Automating filesystem check at boot time
On Thu, 23 Sep 1999, Rodney W. Grimes wrote: You need to find and fix what ever it is that is not dieing when being told to die. Your work around is a bandaid that only hides the real problem, which is probably a bug some place in something. amd and NFS are good first conidates. Just what process does it complain that it is unable to kill, or does it just say could not kill? Vinum is usually the culprit for me, though I haven't built a world on most of these machines for a while, so this may be fixed. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtc?
Kenneth Culver writes: I reinstalled -current today, and for some reason there is an extra device generating interrupts. When I do a systat -vm 1 I find that there is a device called rtc at irq8 generating 128 interrupts. What is it? I didn't configure it, and it wasn't there before. It has always been there, it is the RTC clock or "softclock" which is ^ You meant statclock, right? used to tally up the user/system times for processes and a few similar statistics jobs. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc optimizer in -current system ...
Darryl Okahata wrote in list.freebsd-current: "Zach N. Heilig" [EMAIL PROTECTED] wrote: The application for the tests is mpg123. test mp3 playing time: 373 seconds. [ ... ] 1) No Optimization 225.08 real 224.30 user 0.23 sys [ ... ] 2) -O3 -mcpu=i486 -march=i486 -fomit-frame-pointer -fschedule-insns -fschedule-insns2 141.92 real 141.43 user 0.10 sys What do these timings represent? As you say the mp3 playing time is 373 seconds, but the "real" times vary, the timings don't appear to be the playing/processing of the mp3 file. Probably something like this: time mpg123 -qt file.mp3 Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do FreeBSD mailing lists ignore MX preference?
Ben Smithurst writes: Bruce Albrecht wrote: Non-authoritative answer: zuhause.mn.org preference = 150, mail exchanger = minuet.skypoint.net zuhause.mn.org preference = 100, mail exchanger = 205.215.217.178 "205.215.217.178." almost certainly does not have an address (A) record. Mail exchangers must be host names, not IP addresses. Unfortunately, I don't have control over the MX record. When I asked them to change it to my new static IP I gave them a valid PTR address (FQDN) and the new static IP, and they used the static IP instead of the FQDN. I've asked them to correct it, now that I know that it's wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DDB SMP?
I just ran across this:
Debugger("isp_attach")
Stopped at Debugger+0x37: movl$0,in_Debugger
db cont
whoa, other_cpus: 0x0002, stopped_cpus: 0x
panic: stop_cpus() failed
mp_lock = 0002; cpuid = 0; lapic.id =
Automatic reboot in 15 seconds - press a key on the console to abort
Whuffo?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
As Gary Schrock wrote ... At 03:00 AM 9/24/1999 -0700, you wrote: Another thing that ISP coulds start doing (we are in process with this now, but on a monitoring only basis, instead of a deny we just log them) is to block all outbound from AS tcp 25 setup packets. Hmm, maybe I'm interpreting this wrong (I hope so), but I interpret this as saying that basically you'd only be able to mail things through your local isp's mailhost. It means that if you use several different mail servers, all mail would still have to go through the local isp's. Personally, I would immediately unsubscribe to any isp that decided this was acceptable behavior on their part. I use the mail server at work for all my outgoing mail. Why? Because the machine is lightly loaded and I don't have to So, the mailserver at your workplace is an open relay? worry about my mail getting lost in the depths of my isp's mail server for a couple hours because their loads tend to run high. (Hell, I don't generally even use the email account provided by the local isp because of load issues, my work account is so much more reliable). I'd call this the ultimate reason to get another ISP. Not the relaying stuff. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ccd build failure
Warner Losh wrote in list.freebsd-current:
In message [EMAIL PROTECTED] "Matthew D. Fuller" writes:
: OK:
: #!/bin/sh
: (cvs status | grep '^File:' | grep -v 'Status: Up-to-date$') 2 /dev/null
^^ -q
Hm, that variant does not display the directory names at all.
I'd like to propose the following variant. It's a bit longer
than my first proposal, but just as efficient (maybe even more
efficient, because it doesn't have to fork two greps).
#!/bin/sh -
cvs status 21 \
| awk '/^File/ ! /Status: Up-to-date$/ {
$1 = dir "/" $2;
$2 = "";
print;
}
/cvs server: Examining/ {
dir = $4;
}'
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
I totally agree with this, while it doesn;t stop all spam (and some has to be added manually to my own lists) I've dramatically cut down on spam to my machines. DUL, while I'm not sure whether we should take this to -chat or not since we are now getting into noise on the -current list, is also a good thing. simply because noone on a dialup has reason to be sending mail directly to me, they should be sending it through thier ISP's mail servers. overall MAPS is the best thing to come along for spam control since ...I don;t know when. They aren;t as "strict" as ORB and Paul Vixie's attitude towa5rds it has been excellent. Its much easier to get off RBL than it is ORB, especially if you are on it by mistake, like a friend of mine was. -Pat ___ Pat Lynch [EMAIL PROTECTED] [EMAIL PROTECTED] Systems Administrator Rush Networking ___ On Fri, 24 Sep 1999, Mark Murray wrote: Do you know about the RBL? How do you feel about it? We are using it via DNS and BGP on a test basis right now.I have had legitimate important mail blocked at Freebsd.org due to the source being on the RBL, but that is a price I am willing to pay. The RBL is great! There is a teensy bit of colateral damage, but not so much that I worry about it. Here in ZA, our USP traffic provider (Teleglobe) uses RBL, thus absolving us of the responsibility. Since we started getting this "cleanfeed", spam has dropped dramatically. What I particularly enjoy about the RBL is its strong sense of the need to listen to its client base, and to adapt as necessary. Paul Vixie has a high degree of respect, as a consequence. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
If you use sendmail, this is pretty trivial, its a slight modification to
the original RBL check :
# DNS based IP address spam lists
R$* $: ${client_addr}
R$-.$-.$-.$-$: $(host $4.$3.$2.$1.rbl.maps.vix.com. $:
$1.$2.$3.$4 $)
R$-.$-.$-.$-$: $(host $4.$3.$2.$1.dul.maps.vix.com. $: OK $)
ROK $@ OK
R$+ $#error $@ 5.7.1 $: "Mail from " ${client_addr} "
refused by blackhole site rbl.maps.vix.com
or dul.maps.vix.com"
the last three lines in my email are one line though ;)
this is in the rule :
check_relay in Ruleset 98
essentially after checking the one, if it passes the first (RBL) it then
checks it vs. the second (DUL) if it actually gets an address back... it
rejects the mail, with the message.
___
Pat Lynch [EMAIL PROTECTED]
[EMAIL PROTECTED]
Systems Administrator Rush Networking
___
On Fri, 24 Sep 1999, Rodney W. Grimes wrote:
From: "Rodney W. Grimes" [EMAIL PROTECTED]
Date: Fri, 24 Sep 1999 03:00:55 -0700 (PDT)
Another thing that ISP coulds start doing (we are in process with
this now, but on a monitoring only basis, instead of a deny we
just log them) is to block all outbound from AS tcp 25 setup packets.
Not quite sure I follow this.
ipfw add 10250 allow tcp from ${smtpsmarthost} to any 25 setup out via lnc1
ipfw add 10259 allow log tcp from any to any 25 setup out via lnc1
This is placed on all AS border routers, anyone attempting to
do direct port 25 outbound from our AS trips 10259 and gets to talk
to me about what it is they are doing.
The comptete rules set is a fair bit more complicated than the above
as we are also a transit AS and I have to allow the port 25 setup traffic
from them to work correctly, so I can't just go make 10259 a deny at
this time.
This prevents your customers from being something that could get you
on the RBL or the DUL MAP for bad behavior, it also inforces the use
of your smart host relay, as it/they is/are the only way to get a
tcp port 25 setup completed.
About the only positive thing I have to say about the DUL is that Vix
stated that entries are placed on it at the request of the custodians of
the netblock in question.
If that is the case then this is ideal. Everyone should be using the
DUL, as the maintainer of that IP space has specifically stated that
they do not want or allow smtp setup connections from that IP space.
Thus by using the DUL you are simply helping a costodian implement
the policy they have already layed down.
Do you know about the RBL? How do you feel about it? We are using
it via DNS and BGP on a test basis right now.I have had legitimate
important mail blocked at Freebsd.org due to the source being on the
RBL, but that is a price I am willing to pay.
I'm far more comfortable with the use of the RBL than the DUL.
Given what you stated above I don't see how you could favor the
RBL over the DUL, the DUL is stated administrative policy, the RBL
is a reactive to bad behavior and in opposition to stated administrative
policy for almost every entry in it.
Indeed, my externally-visible home SMTP server uses the RBL (but not the
DUL).
You should probably run both I know I am going to go see what it
takes to intergrate DUL into our current scheme of things. And submit
our IP dial up blocks for inclusion in the list.
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DDB SMP?
I just ran across this:
Debugger("isp_attach")
Stopped at Debugger+0x37: movl$0,in_Debugger
db cont
whoa, other_cpus: 0x0002, stopped_cpus: 0x
panic: stop_cpus() failed
mp_lock = 0002; cpuid = 0; lapic.id =
Automatic reboot in 15 seconds - press a key on the console to abort
Whuffo?
The kernel probably entered the debugger after the AP had been started
but before it accepts any interrupts.
- Tor Egge
Index: sys/i386/i386/db_interface.c
===
RCS file: /home/ncvs/src/sys/i386/i386/db_interface.c,v
retrieving revision 1.46
diff -u -r1.46 db_interface.c
--- db_interface.c 1999/08/28 00:43:42 1.46
+++ db_interface.c 1999/09/24 23:43:34
@@ -167,7 +167,7 @@
#endif /* VERBOSE_CPUSTOP_ON_DDBBREAK */
/* Restart all the CPUs we previously stopped */
- if (stopped_cpus != other_cpus) {
+ if (stopped_cpus != other_cpus smp_started != 0) {
db_printf("whoa, other_cpus: 0x%08x, stopped_cpus: 0x%08x\n",
other_cpus, stopped_cpus);
panic("stop_cpus() failed");
Index: sys/i386/include/smp.h
===
RCS file: /home/ncvs/src/sys/i386/include/smp.h,v
retrieving revision 1.47
diff -u -r1.47 smp.h
--- smp.h 1999/08/28 00:44:25 1.47
+++ smp.h 1999/09/24 23:39:47
@@ -177,6 +177,7 @@
/* global data in init_smp.c */
extern int invltlb_ok;
extern int smp_active;
+extern int smp_started;
extern volatile intsmp_idle_loops;
#endif /* !LOCORE */
XFree86-3.3.5/kde-1.1.2/Current today.
This morning I made world, updated XFree86 and kde, which didn´t seem to be a problem until I started X and nowI get revers Icon's - silhouettes on the kde background. I get no text but a block where the text is and the mouse will often change to a block. I have never seen anything like it. I have recompiled X-11 3 times and kde twice. I have erased the .kde, .kderc, .klogin, Desktop each time. I have no idea where to look. It was fine yesterday with XFree86-3.3.4 and kde-1.1.1. Also tried twm and same problem so I can assume the it isn´t kde but .. . Does the same at -bpp 8/16/24/32 and 640x, 800x y 1024x. The video card is a sis-6326 8MB and am running the SVGA server. Thanks in advance or any suggestions. ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Friday, 24 September 1999 at 16:36:54 -0400, Brad Chisholm wrote: I'm having a problem where the "vinum start" command crashes my system. This happens regardless of whether it's being issued during bootup via /etc/rc or from the command line on a running system. Interestingly, however, if I issue the start command from the vinum interactive prompt, it works properly with no crash. I'm currently running on a snap built this morning (0924), but it was also happening on a snap from 0914. Crash info, vinum config, and disk info are below. Let me know if I can provide any additional information. Yes. Please read the instructions in vinum(4) about debugging panic dumps. I found a minor bug in 'vinum start' recently, but I doubt it's causing your problem. I'll commit it Real Soon Now. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
In article [EMAIL PROTECTED], Pat Lynch [EMAIL PROTECTED] wrote: If you use sendmail, this is pretty trivial, its a slight modification to the original RBL check : There's a nice patch for the sendmail 8.9.3 that allows you to specify multiple blacklists easily (e.g., both RBL and DUL). You'll find it here: http://www.sendmail.org/~ca/email/chk-89n.html John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Filtering port 25 (was Re: On hub.freebsd.org refusing to talkto dialups)
I understand the ISP's POV here, but I have legitimate reasons to telnet to port 25 on various machines (most of them administered by me), and I'd never dream of using an ISP that would stop me from doing so. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm oddity
I noticed a little quirk in the pcm driver -- it is reversing the channels in my sb16! The first couple times I play a certain mp3 that starts out (normally) in the left channel, it plays correctly in the left channel. Then suddenly it will switch, and start out in the right channel. The mixer still works properly, just the DSP (I think anynway) seems to be reversing the channels somewhere internally. It's odd, to say the least. My kernel is -current as of late sept 22. Can anyone else duplicate this? WM -- The difference between genius and stupidity is that genius has its limits. Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Quick 'n' Dirty CVS Status
[subject updated] On 24-Sep-99 Oliver Fromme wrote: Hm, that variant does not display the directory names at all. I'd like to propose the following variant. It's a bit longer than my first proposal, but just as efficient (maybe even more efficient, because it doesn't have to fork two greps). example snipped Regards Oliver If you can grok the flags that 'cvs update' uses.. 'cvs -qn update' is a lot less to type in, and it doesn't have to fork any children outside of cvs. :) --- John Baldwin [EMAIL PROTECTED] -- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
At 10:59 PM 9/24/99 +0200, Wilko Bulte wrote: As Gary Schrock wrote ... all mail would still have to go through the local isp's. Personally, I would immediately unsubscribe to any isp that decided this was acceptable behavior on their part. I use the mail server at work for all my outgoing mail. Why? Because the machine is lightly loaded and I don't have to So, the mailserver at your workplace is an open relay? No, it's definitely not. I've been using a pop before relay scheme that's been working fairly nicely. (Although occaisionally the server gets stuck in a state where it decides it doesn't recognize my pop check and refuses to relay my mail anyways). Back before sendmail started doing relay checking by default, I got hit with a spammer relay that so swamped the server it was immediately noticeable because nothing else was working. I've been very careful ever since then to make sure servers I'm responsible for don't leave relaying open. (As a defense, this was back when this was something that was still relatively new, and there wasn't a whole lot in the way of information about preventing relaying. These day's it's a lot easier to fix that problem). worry about my mail getting lost in the depths of my isp's mail server for a couple hours because their loads tend to run high. (Hell, I don't generally even use the email account provided by the local isp because of load issues, my work account is so much more reliable). I'd call this the ultimate reason to get another ISP. Not the relaying stuff. Why? The last thing I need is another email account, so I don't even *use* the email stuff from my isp. For everything besides occaisional issues with the load on their mail servers my isp is pretty good. However, for me it makes a lot more sense to use hte mail server at work, simply because that's a machine that's got few users, and I get the instant gratification of my mail going out immediately. For what it's worth, to clarify my viewpoint on this issue, I don't really object to the DUL, and quite honestly, after reading the information about it, I might even consider enabling it. It's not something that will affect my mail, because I *do* send the mail through a legit mail server. My objection is with the idea that an ISP would block my ability to use my mail host at work by blocking outside access through port 25. Why should my mail take an hour or two to filter through the local isp when it can go immediately through work? (And for the argument choose an isp that has a better mail relayer, that's not always practical. Say you're using adsl or cable modem, where you might not really have a choice on the isp, are you really going to give up the faster connection because a mail relay you don't use happens to be slow? I sure as hell wouldn't). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
