Re: Dropping connections without RST

> Geoff Rehmet writes: > > After the discussions regarding the "log_in_vain" > > sysctls, I was thinking about a feature I would > > like to implement: > > > > Instead of sending a RST (for TCP) or Port Unreachable > > (for UDP) where the box is not listening on a socket, > > I would like to impl

Re: Dropping connections without RST

> Brian W. Buchanan writes: > > > > Can anyone think of any reason why this feature should > > > > not be implemented? > > > > > > I like that idea... net.inet.{tcp,udp}.drop_in_vain ? > > > > Why do we need a sysctl knob for this when it can be easily accomplished > > with IPFW? > > Not that e

Re: Existance of /var/backups for periodic/daily

> The 200-220 periodic files under daily expect that the directory > /var/backups exist when they run to back up various files. If you > delete this directory, the "cp" commands will error. > > There seems to be two ways to fix the files. > > 1. Add a "if [ ! -d $bak ] ; then exit fi" to t

Re: Dropping connections without RST

> > On 17-Aug-99 Rodney W. Grimes wrote: > > I kinda like the idea of this, but can't that really just > > be done easily with a few ipfw rules, the last two being > > the important ones: > > > > for port in "22 53" ; do >

Re: Dropping connections without RST

> Rodney W. Grimes writes : > > > > > > > Now what would a box with so much security concern such that > > it needed this knob be doing running an ftp session though > > your point is valid and acceptable for low security boxes. And > > I can see

Re: Dropping connections without RST

> In message <[EMAIL PROTECTED]> Archie Cobbs writes: > : Not that easily.. how are you going to make ipfw dynamically know > : which ports have listeners and which don't? > > By filtering all RST packets? That would be closer than my set of rules, but has the undesired effect of filtering what

Re: Dropping connections without RST

[Charset iso-8859-1 unsupported, filtering to ASCII...] > > > > > > This is an ACK. I like those names, the idea is okay given that > > the documentation for it reflects what has been discussed here in > > this thread so folks can understand this is a very simple security > > measure. > Hmm, d

Re: REQ: Test /etc/rc clean-up

> > Hi folks, > > I have a diff for src/etc/rc that I'd like to have had used on a few > machines before I commit it. I'm pretty sure I haven't made any mistakes > with my changes, but you can never be too careful, right? Right... > > The diff homogenizes the manner in which variables are tes

Re: "The Matrix" screensaver, v.0.2

> On Sun, 22 Aug 1999, Ollivier Robert wrote: > > > According to Narvi: > > > "Falling letters like in the movie with red bills" > > > > Pill :) > > > > That very important... The screensaver triggered me to see the movie > > again. A. I love it. > > Yeah, it's gotta be the perfect hacke

Re: xntpd - VERY old folks, how about updating? :-)

> In message <[EMAIL PROTECTED]>, Karl Denninger writes: > >On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Karl Denninger writes: > >> > >> >This is not a port, its part of the RELEASE! > >> > > >> >Its several YEARS old, and doesn't work r

Re: xntpd - VERY old folks, how about updating? :-)

> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes > : > > >Does it help in the 3.4-stable version to set the second value in ntpdrift > >to 1? > > Yes, although I have never checked all the boundary conditions > to make sure the kernel-pl

Re: new man pages

> Where do I look for new man pages? I would like to read those for the > new ata driver and for ntpd. They were not created during a build > world some 5 days ago. And I cannot find them in > /usr/src/share/man/man4, where I would expect man ata/ad in any case. Sos already answered about ata/ad,

Re: 4.0 code freeze scheduled for Jan 15th

... > > I strongly suggest to not release 4.0 till the IPv6 import has been finished. > Beside the need for IPv6 it would be wrong to ship a release with a half- > complete implementation. I expect every person that has made similiar statements here and bore all the developers with the additiona

Re: ipfw optimizations

[Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi Luigi, > > > > i am looking at (minor) optimizations of the ipfw code in order to reduce > > the running time in the common cases. > > > > I have a few ideas (mostly along the lines of optimizing for the > > most commonly-used rules).

Re: ipfw optimizations

> In message <[EMAIL PROTECTED]>, Luigi Rizzo writes: > >> One of the things I would do to optimize ipfw is: > >> - instead of keeping one list with all the rules, split the list (the > >> internal one) by interface and by direction (one list for ed1 incoming, > >> one list for ed1 outgoing, e

Re: ipfw optimizations

[Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi, > > > > One of the things I would do to optimize ipfw is: > > > - instead of keeping one list with all the rules, split the list (the > > > internal one) by interface and by direction (one list for ed1 > incoming, > > > one list fo

Re: ipfw optimizations

... > > > Yes I agree, I love ipfw functionality. You were asking for ideas on how to > optimize ipfw. What I suggested is that in its INTERNAL representation of > the rules, ipfw could split the rules on a per interface/direction basis. > This means that you will not look at the rules that are

Re: ipfw optimizations

> > No, this is completly reasonable now that I understand what it is your > > proposing. Even the memory footprint is minimal if pointers to the > > actual rules is all we store in the per interface list, my largest set > > duplicated over 8 interfaces would only be 3200 rules. Stored as > > I

Re: ipfw optimizations

> > clnsrv "allow" tcp "" 43 "${tcp_nicname_c}""${tcp_nicname_s}" > > clnsrv "allow" tcp "" 53 "${tcp_domain_c}" "${tcp_domain_s}" > ... > > ... on and on up to the 1024 and then a few splattered after that. > > looks like the search path can become extremely long!. Yes,

Re: 4.0 slower than 3.4?

> In article <[EMAIL PROTECTED]>, > james <[EMAIL PROTECTED]> wrote: > > > It's interesting though how i had no ipf rules whatsoever, yet it > > introduced so much latency, as Alexander has pointed out in another email. > > Why is ipf so slow? I was planning on switching from ipfw/natd to > >

Re: Additional option to ls -l for large files

> I'm currently dealing with an increasing set of *very* large files, > most of them in the order of gigabytes. It becomes impossible to > figure the size of a file with ls -l with 9 or more digits displayed. > I would propose a new flag to ls which will together with option -l > change the unit t

Re: Additional option to ls -l for large files

[Charset windows-1252 unsupported, skipping...] Arghh... windblows... > >> I'm currently dealing with an increasing set of *very* large files, > >> most of them in the order of gigabytes. It becomes impossible to > >> figure the size of a file with ls -l with 9 or more digits displayed. > >> I

Re: Additional option to ls -l for large files

> At 2:49 PM -0800 1/11/00, Rodney W. Grimes wrote: > > > >Another thing that ``works for me''. Only make it ki, mi, and gi > > > >to fit with the new binary mode international appreviation standards, > > > >unless of cource you use base 10

Re: move portmap(8) from /usr/sbin to /sbin

> > Hi, > > I think we should move portmap(8) to /sbin for the following reason: > > portmap(8) and therefore mountd(8) should be started before > the nfs filesystems get mounted. But because portmap(8) is in > /usr/sbin , users with a nfs mounted /usr filesystem or with > diskless filesystems

Re: move portmap(8) from /usr/sbin to /sbin

> > > > portmap(8) and therefore mountd(8) should be started before > > > the nfs filesystems get mounted. But because portmap(8) is in > > > /usr/sbin , users with a nfs mounted /usr filesystem or with > > > diskless filesystems will have big problems. > > I mean, that if I do the change of sta

Re: move portmap(8) from /usr/sbin to /sbin

> > Hi, > > > should not have to run either, *even* for diskless boot. > > > > What's all this about loopback mounts in fstab about? What does > > that have to do with diskless startup? > > Ok. I just rethought everything. It seems that a move is > unnecessary because: > > - Shar

Re: move portmap(8) from /usr/sbin to /sbin

> On Wed, Jan 12, 2000 at 01:23:14AM -0800, Rodney W. Grimes wrote: > > > Also moving them to pass1 would bring up nfs exports before we > > brought up nfs mounts. syslogd would not be running to catch > > Shouldn't nfs exports happen before nfs mounts, so t

Re: move portmap(8) from /usr/sbin to /sbin

> "Rodney W. Grimes" wrote: > [..] > > So no disk, so just what is it that you are exporting??? > > Just a comment: > > I've seen scenarios where a local disk is attached holding a kernel, > bootblocks loader etc, but otherwise booting from a server ove

Re: Additional option to ls -l for large files

[Charset iso-8859-1 unsupported, filtering to ASCII...] > I'm sorry but I would find it non-obvious and more confusing. When ls or a > similar disk/memory utility tells me xxxK or xxxM, I would expect it to be > in 2^10 or 2^20 units. To appear otherwise would surprise me. I guess you get supri

Re: move portmap(8) from /usr/sbin to /sbin

> "Rodney W. Grimes" wrote: > ... > > > > Independent of order of export/mounting the dead lock occurs. Cross > > mounting via NFS is a verbotten thing in the sysadmin world of production > > systems. :-) I have had to fix it at several sites admin&#x

Re: Additional option to ls -l for large files

Sorry, I will slow down my reading and stop flipping 2^10 into 10^3. > From: Rodney W. Grimes [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 12, 2000 9:53 PM > > > [in regards to a previous post preferring base-10 for K and M units...] > >> I'm sorry but I

Re: move portmap(8) from /usr/sbin to /sbin

> :> Sometimes we just want to nfs-mount things on the same > :> machine. > : > :Sick, poor in performance and the wrong tool for the job. > :See mount_null(8) for more details on how to do it right. > : > :> > :> One more example: I don't like /var/news so I mount locally > :> /var/news > :> t

Re: FIC SD-11 not happy with ata

> %It seems Russell L. Carter wrote: > %> %It seems Russell L. Carter wrote: > %> %> > %> %> I swapped out my motherboard and am seeing this now: ... > > )(*&$#%$# stupid magazine benchmarkers never actually test > things like IO... gr We in the computer hardware business have a bet

Re: Please help spread the CVSup mirror load more evenly

> Hi David, > > John can implement a ping echo packet protocol for cvsup whose > response can have "cool" information on the server. Steven's > book on Networking already has the code for doing network latency > calculations . It is more like if John has the time to implement > such scheme

Re: Please help spread the CVSup mirror load more evenly

> > > Hi David, > > > > > > John can implement a ping echo packet protocol for cvsup whose > > > response can have "cool" information on the server. Steven's > > > book on Networking already has the code for doing network latency > > > calculations . It is more like if John has the time to implem

Re: Please help spread the CVSup mirror load more evenly

> On Fri, 21 Jan 2000, David O'Brien wrote: > > > On Fri, Jan 21, 2000 at 07:03:51PM -0500, Chuck Robey wrote: > > > I don't know ... I think it might be a good idea for the cvsup client to > > > make a connection to a cvsup master, get redirected from that master to > > > the actual handler of t

Re: With feature freeze being in place

> In article , > Alex Zepeda <[EMAIL PROTECTED]> wrote: > > > > I'm looking at /usr/{src,}/share/examples/cvsup/gnats-supfile, and as > > "equipped" it's not working (well it goes through the motions but checks > > out no files). Hmm. > > It w

Re: Please help spread the CVSup mirror load more evenly

> On Mon, Jan 24, 2000 at 02:17:54PM +0100, Brad Knowles wrote: > > At 11:34 PM +1300 2000/1/22, Joe Abley wrote: > > > > > This should give you a relative performance metric between the servers > > > you measured, hopefully with local network performance variations > > > cancelled out by the

Re: FIC SD-11 not happy with ata

> %> %It seems Russell L. Carter wrote: > %> %> %It seems Russell L. Carter wrote: > %> %> %> > %> %> %> I swapped out my motherboard and am seeing this now: > %... > % > %> > %> )(*&$#%$# stupid magazine benchmarkers never actually test > %> things like IO... gr > % > %We in the comp

Re: (FWD) Re: cvs commit: src/etc/periodic/daily 200.backup-passwd

> > > On Thu, 27 Jan 2000 00:23:23 PST, "David O'Brien" wrote: > > > I think what you really want is: > > > > sed 's/^\([^:#@+-]*\):[^:]*:/\1:(password):/' > > Eeek, I don't know why I sent you that. It should have been: > > sed 's/^\([ +-][^+-][^:]*\):[^:]*:/\1:(password)

Re: Problems installing FreeBSD 4.0 20000125-CURRENT

> < said: > > >> 3. On the first reboot after installing, the keyboard was in a funny > >> state. > > > Urk, can't reproduce it. I need a reproducible sequence of operations > > before we'll have any hope of tackling this one. > > >> Control-alt-del definitely didn't work, so I had to power of

Re: (FWD) Re: cvs commit: src/etc/periodic/daily 200.backup-pass

> > On 27-Jan-00 David O'Brien wrote: > > I would appreciate it if those that want things changed would please try > > Sheldon's `sed' expression below and report back how it worked for you. > > That will expose passwords of users whose entries are commented out, My awk script does not have tha

Re: Comments on this patch?

> In message <[EMAIL PROTECTED]> "David O'Brien" writes: > : > BTW, I'm getting numbers that are 2x bigger than before :-(.I had > : > makebuildworld down to around 1:20 at one point, but now it is 2:40. > : > : Which compilers for both times? > > What ever was on -current as of 2.5 years ag

Re: very silent, but heavy filesystem-crash

... > > Starting an 'fsck' results in: > > cage:[/] # fsck /scratch > ** /dev/da1s1g > ** Last Mounted on /scratch > ** Phase 1 - Check Blocks and Sizes > PARTIALLY TRUNCATED INODE I=16 > SALVAGE? [yn] ^C > * FILE SYSTEM MARKED DIRTY * Next step is run the `

Re: make installworld broken???

Good analysis deleted... > src/usr.bin/xinstall could probably have been named src/usr.bin/install, > but PROG has to be xinstall regardless. I guess they kept the two as > xinstall for consistancy and in case there were other gotcha's like this. But you forgot what happens if you have a ``file

Re: make installworld broken???

> "Rodney W. Grimes" wrote: > > Good analysis deleted... > > > > > src/usr.bin/xinstall could probably have been named src/usr.bin/install, > > > but PROG has to be xinstall regardless. I guess they kept the two as > > > xinstall for consist

Re: Dummy ethernet interface.

> Giorgos Keramidas writes: > > Is there some way to ifconfig up a dummy ethernet interface, one that > > will work like the loopback one (lo0) on FreeBSD? > > If you want an interface that loops back, you can have more than > one loopback interface (lo0, lo1, lo2, ...). > > If you want an inter

Re: dc0 wierdness with Compex Freedomline

> < said: > > > > The theoretical maximum for 100BaseT-FDX (which is 200Mbps) is 25MB/s > > (megabytes per second), 100BaseT-TX is 12MB/s [FYI: Mbps->MB/s you divide > > by 8] I realize my punctuation may be off, but there you are. > > Assuming you mean ``100BASE-T (half duplex)'' here... This

Re: dc0 wierdness with Compex Freedomline

> On Thu, Feb 24, 2000 at 02:07:40PM -0500, Garrett Wollman wrote: > > < said: > > Assuming you mean ``100BASE-T (half duplex)'' here... This is not > > quite right. In a CSMA/CD medium access protocol, like that used by > > Ethernet, the actual capacity of the link is always(*) somewhat less tha

Re: dc0 wierdness with Compex Freedomline

> On Fri, Feb 25, 2000 at 01:25:59AM -0800, Rodney W. Grimes wrote: > > > > There was a patch of DC21143 chips it seems that has a very strange > > thermal problem. Can you tell me what your hub link lite is doing > > when you see this major slow down? > > Nope

Re: Streamlining FreeBSD installations across many machines

> Perhaps this would be of interest in CURRENT issues: > > > We have several servers that we plan on deploying across the US. Their > purpose in life is network status and monitoring. The hardware profiles > are exactly the same... > > Currently, we're using DD to mirror a disk image onto

Re: dc0 wierdness with Compex Freedomline

> <<[EMAIL PROTECTED]> said: > > >> [I wrote:] > >> quite right. In a CSMA/CD medium access protocol, like that used by > >> Ethernet, the actual capacity of the link is always(*) somewhat less than > >> 100%; the exact value depends on the precise parameters of the > >> transmissions at both en

Re: dc0 wierdness with Compex Freedomline

> <<[EMAIL PROTECTED]> said: > > > I specifically excluded P(coll) by stating point to point or effectively > > point to point via switching. > > Rod, please bother to READ what people write before spewing nonsense. I did read it, and did not spew nonsense. P(coll) is non-sense when talking ab

Re: dc0 wierdness with Compex Freedomline

> <<[EMAIL PROTECTED]> said: > > >> I answered SPECIFICALLY about half-duplex. > > > The duplex does not in any way effect the maximal link layer transmission > > data rate. You seem to keep forgetting the maximal part... > > The maximum for full-duplex is utterly irrelevant, since the bounds

Re: dc0 wierdness with Compex Freedomline

> <<[EMAIL PROTECTED]> said: > > >> The maximum for full-duplex is utterly irrelevant, since the bounds on > >> performance for half-duplex Ethernet networks come from CSMA/CD. > > > I will say it one last time, duplex falls out of the equations when you > > solve for ``maximal''. > > Nonsense.

Re: Streamlining FreeBSD installations across many machines

> In article <[EMAIL PROTECTED]>, Rodney W. Grimes > <[EMAIL PROTECTED]> wrote: > > > A much faster way to do this is to just dd the first few megabytes > > of the disk (dd if=foo of=/dev/rXXd bs=32768 count=1024). Then use > > dump | restore to populate

Re: Hardware for 4.0

> Hello, > > I'm purchasing a server to run 4.0 on. It won't be in production > immediately, but I need to get a quote ASAP. > > What SCSI card would people recommend? It doesn't need RAID. > Any particular SCSI tape drive? We are partial to the TekRAM 390-F symbios 53C875 based controller. >

Re: openssl in -current

> Hmmm. I'm beginning to wonder if openssl shouldn't just be backed-out > at this point. The situation with RSA makes this far more problematic > than I think anyone first thought, and I've seen a lot of breakage so > far for what appears to be comparatively little gain over what we had > before

Re: Hardware for 4.0

> <<[EMAIL PROTECTED]> said: > > > IBM Hard drives... > > If you can actually get them Last time I bought a drive we > weren't able to get IBM in any reasonable timeframe and ended up with > a Seagate instead. (And that Cheetah 18LP's not a bad drive, either.) Should you run into that pro

Re: [re]writable cdrom drive

Ahhh.. did we just experience a major time warp some place? I just received about 15 messages I know I have read before, all dated 18 Aug 1999. > < said: > > > Or if there is a system call or modification to open such that I can issue : > > open("pci0:10:0", .) > > Don't be silly. > >

Re: Softupdates reliability?

> On Tue, 24 Aug 1999, Richard Tobin wrote: > > > > > Origin = "AuthenticAMD" Id = 0x580 Stepping=0 > > > > > You have one of the first K6-2s off the line. There were definite problems > > > with these, and as such, they were specially distinguished by having 66 > > > printed on top. > > >

Re: Softupdates reliability?

> As Rodney W. Grimes wrote ... > > > On Tue, 24 Aug 1999, Richard Tobin wrote: > > > > > > > > > Origin = "AuthenticAMD" Id = 0x580 Stepping=0 > > > The original K6-2's off the line where all 100MHz parts, it was later wh

Re: Softupdates reliability?

> On Wed, 25 Aug 1999, Wilko Bulte wrote: > > > The USA... your prices tend to be a lot better than ours. I could can the > > T2P4 but that would also mean I had to can the SIMMs (everything is DIMMs > > now), get an AGP videocard and can the perfectly fine Millenium II (I need > > the extra PCI

Re: $FreeBSD tag confusion

> John Polstra <[EMAIL PROTECTED]> writes: > > > The tags are expanding just fine up here in Seattle. :-) > > > > I wish you would have included the rest of the output from your cvs > > status command. It sounds a lot like your source tree was checked > > out with "-ko". That would show up in

Re: $FreeBSD tag confusion

> Rodney W. Grimes writes: > > >What verion of the cvs binary are you running (cvs -v)? > > Concurrent Versions System (CVS) 1.10 `Halibut' (client/server) > > >Are you getting a copy of CVSROOT? > > yes...as part of src-all, but it's not used

Re: HEADS UP

> I've just committed the revised TCP timer code. There are some > user visible changes: > > User visible TCP timers are now in units of the system clock > (10ms for the i386), not those of the slowtimeout (500ms). So > if you have customized one of these values, (e.g.: net.inet.tcp.ke

Re: PNP ids missing in sio.c

> < said: > > > The enumerator should assign these resources to a placeholder; I was > > thinking the nexus was as good an owner as any. If there's an > > "unknown" device that's probably even better. > > Some of them should be claimed by real devices -- for example, the > pseudo-i8237 ISA DM

Re: request for review: move of /var/cron/log to /var/log/cron.log

> Nick Hibma wrote: > > > > > > Please review the following patch to get all the log files in one place. > > > > The commit will be accompanied by a HEADS UP. If no one objects I will > > > > commit this in a couple of days. > > > > > > The only thing I don't like about this is that it intr

Re: optional 'make release' speed-up patch

> Hi, > >The following patch to /usr/src/release/Makefile allows the > specification of the variable FASTCLEAN, which instead of doing > a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of > course, this is only useful if your CHROOTDIR location is a > separate mount point (which min

Re: optional 'make release' speed-up patch

[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Matthew Thyer wrote in list.freebsd-current: > > YES please fix this ridiculous inefficiency pointed out by Rod! > > There's nothing broken, so there's nothing to fix (IMO). > > > The current method of cleaning the build tree is to chfl

Re: more

> * Tim Vanderhoek ([EMAIL PROTECTED]) [990912 17:50]: > >On Sun, Sep 12, 1999 at 03:20:02PM +0200, Jeroen Ruigrok/Asmodai wrote: > >> > >> On this CURRENT of 3-4 weeks old I can do /blah and then use / to find > >> the next occurance of blah in the same file. > >> > >> With the `new' more this

Re: An FS question perhaps... non blocking I/O.

> In article <[EMAIL PROTECTED]>, > Garrett Wollman <[EMAIL PROTECTED]> wrote: > > [POLLEXTEND, POLLATTRIB, POLLNLINK, POLLWRITE] > > > It is probably undocumented. I was a bit reluctant to document it > > since I know that the interface is not correct. One of these days, > > I (or more likel

Re: 2xPIIIx450 results & NFS results

> :> I/O, and then closing it. > : > :4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision > :1008.A, running `systat -vm 1' gives the normal display but without any > :numbers filled in, then switches over to an empty screen that says: > :... > > Whenever systat or

Re: 2xPIIIx450 results & NFS results

> < >said: > > > I've been getting this too on 4.0-C, just rebuild last night, still there. > > top displays: > > CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% > > idle > > On my dual-PPro Intel BB440FX system I am not seeing this. Do you have apm compiled in or not?

Re: 2xPIIIx450 results & NFS results

> OK, Upgraded my Asus P2B-D machien from BIOS version 1008 to 1010, the > problem disappeared. Popped back to my old 1008 BIOS, problem came back. So far about alls I have confirmed is that the problem does not exists with BIOS 1009 when the apm code is not compiled into the kernel. I'll have

Re: Testers please!

... > > One question comes to mind: is there a way that the TSCs could become > > desynchronized somehow? Even though all CPUs run at the same frequency, > > isn't there a strong possibility for slight frequency deviation since > > we use crystal oscillation instead of a more accurate atomic brea

Re: Automating filesystem check at boot time

[Charset iso-8859-1 unsupported, filtering to ASCII...] > I administer a number of remote FreeBSD boxes and starting with 3.x > they have been unreliable at rebooting. We all know FreeBSD wants to > keep running forever, however it seems to be at the expense of > reboot stability. I have found the

Re: On hub.freebsd.org refusing to talk to dialups

> > How much mail does the use of the MAPS DUL reject? I think they meant to ask ``how much SPAM mail does ...'' > > Virtually none. The idea is that dial-up users use their own ISP's > smarthosts, in which case the ISP can nail them if they are spammers, > and I don't get their spam if they g

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 th

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 poin

Re: 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 > >

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 h

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

Re: On hub.freebsd.org refusing to talk to dialups

> yes, Dynamic dialups are the real problems. I have a static dialup, and > its essentially mine to do with what I want. its not counted among my > ISP's dialup pools. And if you signed the additional clauses to our AUP that basically places you at legal and financial risk for violation of the ot

Re: Boot problems with new -current

[Charset ISO-8859-1 unsupported, filtering to ASCII...] > It seems Cejka Rudolf wrote: > > I think internal bad block remapping is long time here. But > > in the middle of 1996 I have bought a new Western Digital disk > > with some bad sectors and it runs without any problems till today > > (and

Re: On hub.freebsd.org refusing to talk to dialups

> > > 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 beha

Re: Loss of Functionality with newpnp

> > I'm just suggesting here that it would be nice if the authors of > > this code would make it _equally functional_ to what was removed. > > It's not nice to remove functionality unconditionally and then > > provide no replacement at all... > > That work is underway, and something to understand

Re: System crash on "vinum start"

> On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: > > Good software shouldn't panic. > I wish _I_ could convince some people of this :-(. > > > > Most certainly is. Could use the functionality to add to a plex's size for > > > striped or RAID5, but a bit of planning cures that. 8-)

Re: Loss of Functionality with newpnp

[Reinsertion of original answer by jkh] > > > That work is underway, and something to understand about -current > > > is that it doesn't have to actually work at all times during the > > > interim periods between releases. Now, should 4.0 be on the horizon > > > and the situation still be one wh

Re: System crash on "vinum start"

> As Rodney W. Grimes wrote ... > > > On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: > > > > Good software shouldn't panic. > > > I wish _I_ could convince some people of this :-(. > > > > rather than having to recover each logical

Re: HEADS UP: sigset_t changes committed

> On Thu, 30 Sep 1999, Harold Gutch wrote: > > > Uhm, that's the way I see it being _right now_ as well. What I > > was thinking of, was that things would go smoother if you > > wouldn't upgrade _right now_, but in [insert some time in the > > near future here], as things would perhaps be "fixed"

Re: new sigset_t and upgrading: a proposal

> Hi, > > In the recent discussion about the breakage of the upgrade path from > -stable to -current numerous suggestions and other kinds of remarks have > been made. In this light I have the following proposal. Please share > your thoughts... > > NOTE: This proposal only discusses upgrading fro

Re: new sigset_t and upgrading: a proposal

> "Rodney W. Grimes" wrote: > > > IMHO, the only ``correct'' fix for the latest incarnation of the > > problem is to finally once and for all fix the cross compilation > > environment instead of using a half cooked tools: target to deal > > with

Re: new sigset_t and upgrading: a proposal

> "Rodney W. Grimes" wrote: > > > > > 1. A compiler C running on machine 1 and capable of generating code > > >for machine 2 (the compiler includes headers and libraries), > > > 2. Source code compatible with compiler C, but also with machine

Re: new sigset_t and upgrading: a proposal

> > Why are the tools being built using new syscalls? What causes this? > > Mainly historical bugs. Includes are installed too early and they only > match the new syscalls. Tools are built using the new includes, so they > need new libraries to be consistent. Therefore the new libraries are >

Re: new sigset_t and upgrading: a proposal

> On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote: > > > Cons > > > > > > o Upgrading from 3.3 and before to -current is only possible after > > >an upgrade to post 3.3. > > > > Not good. > > We recommend th

Re: new sigset_t and upgrading: a proposal

[CC: trimmed to -current] > > > > But this still doesn't entirely solve the problem. You still have > > > > to build and install a new kernel before installing the world. > > > > While this is typically what most -current folks do anyways, it > > > > still prevents backing up to a previous kerne

Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...

> :Hi again, > : > : Whoops: a few hours after downgrading to 3.1-STABLE I had a double fault > :error (strange, it didn't look like a normal panic screen, just the > :message and the content of three registers, then the syncing disks > :message). It seems that I might be wrong about hardware not

Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...

> >On Thu, Oct 07, 1999 at 10:09:23AM -0700, Matthew Dillon wrote: > > > >> Intel's ECC implementation is not perfect (1), but it's good enough to > >> catch these sorts of problems. > > > >Just as an interesting side note, we had a motherboard which > >supported ECC ram and had ECC ram i

Re: People getting automatically unsub'ed from -arch

> > > > "Accidental" removals from the lists are so common that I give up. I no > > longer even try to get back on them -- it's been happening for _years_ now, > > and I have made multiple complaints about it, and if it's not a problem for > > whoever runs the mailing lists, then I just don't ca

  1   2   3   4   5   >