On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote:
> Jamie Howard (howar...@wam.umd.edu), with a little help from yours
> truly, has written a BSD-licensed version of grep(1) which has all the
> functionality of our current (GPLed) implementation, plus a little
> more, in one seve
If it will get ALL of you to give it a rest, how about:
per-rule logging limits
logging limit raising
logging limit resetting
Which would all NOT affect the statistics?
I am, yes, suggesting I will implement it.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
In message <87126.933053...@axl.noc.iafrica.com> Sheldon Hearn writes:
: I have a feeling it'll be time soon enough for us to make each of the
: decisions that is normally affected by securelevel dependant on the
: value of sysctl knobs. Presumeably one or more of them would be
: "write-once" knobs
On Wed, 28 Jul 1999 09:44:03 +0800
Peter Wemm wrote:
> > As far as I can tell, this is a RealTek 8139 board.
>
> Oh my, SMC must be really lowering their standards...
The SMC9432TX is still an EPIC/100. The newer revs of that board are
bug-free (unlike earlier models). I've had quite a l
In message <19755.933088...@axl.noc.iafrica.com> Sheldon Hearn writes:
: +#ifdef SUPPORT_DOT
: +/* Older configurations used '.' between user and group */
: +if ((group = strchr(q, ':')) != NULL ||
: +(group = strchr(q, '.')) != NULL) {
: +#else
:
> A better patch would check to see if the text to the right of the '.'
> is a valid group... However, the above will still parse
>
> fred.jones:fred.jones
>
> in the most desirable way, so I suppose the validity checking is
> overkill.
This is what I plan to commit (w/in minutes):
-
Due to the discussion of speed, I have been looking at it and it is really
slow. Even slower than I thought and I was thinking it was pretty slow.
So using gprof, I have discovered that it seems to spend a whole mess of
time in grep_malloc() and free(). So I pulled all the references to
malloc i
> http://www.freebsd.org/~des/software/grep-0.7.tar.gz>
Before importing, it must display a version number of 1.0 (or drop the
version number). This is not Linux where everything is version 0.xy.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord..
> If it will get ALL of you to give it a rest, how about:
> per-rule logging limits
> logging limit raising
> logging limit resetting
> Which would all NOT affect the statistics?
We need more input from people who use the code, to make sure they don't
depend on the current 'featu
$ uname -a
$ grep foo NONEXIST
Segmentation fault (core dumped)
$ gdb /usr/bin/grep grep.core
...
(no debugging symbols found)...
Core was generated by `grep'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done.
Rea
> A more general concern is whether Henry Spencer's regex routines
> -- at least in our present "alpha-quality" version -- are up to
I spoke to Henry at USENIX and he said he has a new version of his regex
library. I have added it to my plate of things to update.
--
-- David(obr...@nuxi.com
> I've had some interesting comments from David Bushong, motivating for
> inclusion of his Magdir candidate on PR 12554. He makes a strong case
> for a bloated file(1) Magdir. The only thing we're battling with is a
> filename for his submission.
My advice would be to submit his PR to Chris Demtri
> I think u must read following:
> http://www.freebsd.org/releases/3.2R/errata.html
There is nothing on the 3.2 errata that addresses this.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the bo
> various researchers and early-adopters, all of which can go to the
> KAME site and grab the patches to 3.2-stable if they want to play now,
> today. If we haven't done a good enough job of making that clear and
> are suffering from defections to other *BSDs because of this, then we
> just need t
Hi!
I have created a script to integrate FreBSD 3.2, KAME and PAO.
As a result I have the following source trees:
- FREEBSD+KAME("make world" is working :-)
- FREEBSD+PAO (haven't tested yet, no conflicts)
- FREEBSD+KAME+PAO(haven't tested yet, 2 minor conflicts)
Once I have
On Tue, 27 Jul 1999, Nate Williams wrote:
> > If it will get ALL of you to give it a rest, how about:
> > per-rule logging limits
> > logging limit raising
> > logging limit resetting
> > Which would all NOT affect the statistics?
>
> We need more input from people who use the code, t
Hi
Im getting unreferenced inodes that fills up /.
The box is running freebsd 2.2.6-release and sendmail 8.8.8
Sendmails databases are rebuilt once every half hour.
It seems like the unref. inodes comes from spammers.db and
domainalias.db.
Is there a way to avoid this? Will it get better if I u
Hi,
thanks for your answer. I'll try and remove /etc/ttys and
/etc/gettytab as well. I'm not so sure about /etc/login.conf because
I already tried to remove it and at boottime the system
began to whine about a missing class (daemon). Well, the
system booted and all daemons were running but I'm
On Mon, Jul 26, 1999 at 06:01:35PM -0700, Jordan K. Hubbard wrote:
> > I just wish that it was the other way around. I'd actually run
> > NT if I could get it in a VMWare compartment under FreeBSD.
>
> You would do well to pass these sentiments on to vmware; they're
> currently counting noses in
Peter Jeremy <[EMAIL PROTECTED]> writes:
> > If it ever gets
> >committed (I don't think it's particularly useful myself),
> That's 2 against, 1 (me) for.
Three against.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ha
Jaye Mathisen <[EMAIL PROTECTED]> writes:
> Maybe it could be made a sysctl knob...
No, a socket option would be more appropriate.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Hi David,
Your commit catalogued in the cvs log for newsyslog.c:
revision 1.23
date: 1999/06/28 03:15:02; author: obrien; state: Exp; lines: +2 -2
Syntax for user/group is changed from "user.group" to "user:group" to be
consistant with chown(8).
This one raised a number of eyebrows and a fe
On Mon, 26 Jul 1999, Warner Losh wrote:
> In message
> <[EMAIL PROTECTED]> "Brian
> F. Feldman" writes:
> : But we can install from a single downloaded boot floppy, over the
> : Internet, which is better.
>
> Is that still true? I thought we went back to two floppies to do
> this...
It depends
On Mon, Jul 26, 1999 at 10:41:24PM -0700, Doug wrote:
>
> the parts that they need. However right after 3.2-R came out there was a
> flurry of -questions mail about broken pkg dependencies because sysinstall
> wasn't properly registering the X install. If the port depending on the
> existence of /
On Tue, 27 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
> I'd like to grope around inside a .deb file, which has been created on a
> debian Linux box. Do we have any nifty tools for this, like rpm2cpio?
I would look for something called "alien", which supposedly can conve
On Tue, Jul 27, 1999 at 12:08:10PM +0200, Sheldon Hearn wrote:
>
> strongly opposed to it, or because you don't have time? If it's the
> latter, I'll do it. If the former, note that your commit message was
Consider also adding owner:group support to -stable in order to
provide the longest change
On Tue, 27 Jul 1999 06:54:32 -0400, Tim Vanderhoek wrote:
> It used to be that packages would depend on X, but Sheldon reminded me
> (although I think it was accidental :-) that XFree86 was added to
> PACKAGE_IGNORE_DEPENDS to prevent this.
PKG_IGNORE_DEPENDS is what I had in mind. :-P
Ciao,
I cleaned up the previously posted patches, tested them a little more,
and added a sysctl knob for logging SYN+FIN packets (before optionally
dropping them).
A FreeBSD 4.0-CURRENT machine with these patches and no firewall looks
like this to nmap (with tcp.drop_synfin and tcp.restrict_rst enabled
Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
What's more, the code is ac
On Tue, 27 Jul 1999 06:57:49 -0400, Tim Vanderhoek wrote:
> Consider also adding owner:group support to -stable in order to
> provide the longest change-over period possible.
You have to read the CURRENT newsyslog(8) manpage before you realize
that this is a lose-lose situation:
COMPATIBILITY
On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote:
> http://www.freebsd.org/~des/software/grep-0.7.tar.gz>
>
> I move that we replace GNU grep in our source tree with this
> implementation, once it's been reviewed by all concerned parties.
When I committed the port (textproc/freegrep)
Sheldon Hearn <[EMAIL PROTECTED]> writes:
> Version 0.3 broke port-building badly. Does version 0.7 make it through
> a build of a whole stack of ports?
Yes.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the
> :> There may be some confusion here. I am advocating that we *allow* the
> :> zeroing of counters at secure level 3.
> :
> :Which is what I am advocating against.
>
> Let me put it a different way:
>
> ipfw allows you to clear counters. It is a feature that already exists.
>
On 27 Jul 1999 13:48:21 +0200, Dag-Erling Smorgrav wrote:
> > Version 0.3 broke port-building badly. Does version 0.7 make it through
> > a build of a whole stack of ports?
>
> Yes.
Excellent. I'll nuke the port once you've merged the new grep to STABLE.
:-)
Later,
Sheldon.
To Unsubscribe:
It seems Dag-Erling Smorgrav wrote:
> Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
> truly, has written a BSD-licensed version of grep(1) which has all the
> functionality of our current (GPLed) implementation, plus a little
> more, in one seventh the source code and one fourth
On Tue, 27 Jul 1999, Soren Schmidt wrote:
> It seems Dag-Erling Smorgrav wrote:
> >
> > I move that we replace GNU grep in our source tree with this
> > implementation, once it's been reviewed by all concerned parties.
>
> Go for it, the more GNU stuff we nuke the better :)
>
> -Søren
>
Geez
On Tue, Jul 27, 1999 at 01:37:35PM +0200, Dag-Erling Smorgrav wrote:
>
> I move that we replace GNU grep in our source tree with this
> implementation, once it's been reviewed by all concerned parties.
Have you run your systems with J-grep as a replacement for GNU grep
for a while (making sure n
On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote:
> Getting rid of as much as possible, gradually, is a Very Good Thing;
> this is how we get stability and performance improvements.
Only if the replacements are as stable and robust as their predecessors.
In this case, the implemen
In <[EMAIL PROTECTED]> Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
> Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
> truly, has written a BSD-licensed version of grep(1) which has all the
> functionality of our current (GPLed) implementation, plus a little
> more, in one seven
On Tue, 27 Jul 1999, Sheldon Hearn wrote:
> In this case, I'm all for the change, since I don't use grep for serious
> regex work and the readability gain outweighs any loss of performance.
> you probably feel the same way. Out opinions are those of developers,
> though. It's always worth remembe
On Tue, 27 Jul 1999 07:49:22 EST, David Scheidt wrote:
> Does any have numbers about how much slower the new grep is?
Just by the way, if the latest version somehow uses mmap without my
having noticed, then I've ontroduced a red herring. ;-)
Version 0.3 certainly didn't use mmap. As I underst
On Tue, 27 Jul 1999, Sheldon Hearn wrote:
>
>
> On Tue, 27 Jul 1999 08:19:38 -0400, "Brian F. Feldman" wrote:
>
> > Getting rid of as much as possible, gradually, is a Very Good Thing;
> > this is how we get stability and performance improvements.
>
> Only if the replacements are as stable an
On Tue, 27 Jul 1999, Nickolay N. Dudorov wrote:
> After making it on the CURRENT system I can only
> see:
>
> grep: filename: Undefined error: 0
>
> for every filename.
Every file?
>
> This caused by very "unusual" return values for
> 'grep_open' (and other '..._open') func
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
> That's true. I'd like to see the replacement grep do mmaping of the
> input files if it doesn't already, as that would speed it up. Anyway,
It does not use mmap right now. And this causes a significant perforamce
hit on larger files. An older vers
On Tue, Jul 27, 1999 at 08:23:44AM -0400, Tim Vanderhoek wrote:
>
> How's it compare in speed? [I'd test it myself, but see my private
> email...]
Okay, following-up on myself, and indirectly Sheldon,
It does seem a little too slow. I'm not sure that this is because it
doesn't use mmap. Supp
I'l looking at defining about a dozen ioctl calls for a local device driver.
When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if
there are any "reserved" or "local" values for the first parameter?
In short, I'd hate to use a seemly unused value, just to suddenly be in
"Brian F. Feldman" wrote:
>
> Geez, why don't we just write our own compiler and linker, assembler,
> and everything? Let's get every last bit of GNU out of our system, for
> no reason! This kind of NIH is not necessary, and only hurts us by
> misdirecting our energies.
>
>
> Seriously, I'd lov
Dag-Erling Smorgrav wrote:
>
> Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
> truly, has written a BSD-licensed version of grep(1) which has all the
> functionality of our current (GPLed) implementation, plus a little
> more, in one seventh the source code and one fourth the bi
"Brian F. Feldman" wrote:
>
> That reminds me. I'd like to see something like stat(1) go into the source
> tree, but only if it were freely licensed, not GPL-infected. I could do
> it in a day, I suppose, if it were worth it. Worth it is here defined as
> "would be accepted to go in usr.bin."
Ma
> On Mon, 26 Jul 1999, Matthew Dillon wrote:
> > :Instead of zeroing it, how about raising the logging limit to (current +
> > :whatever the limit was)
> > :
> > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> > : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
> >
> >
> This one raised a number of eyebrows and a few people asked you to hold
> on to legacy support for a single release. It's a reasonable request,
> given the obscure error message one gets for providing the previously
> supported syntax:
>
> newsyslog: error in config file; bad permissions:
> /va
> COMPATIBILITY
> Previous versions of the chown utility used the dot (``.'')
> character to distinguish the group name. Begining with FreeBSD
> 4.0, this has been changed to be a colon (``:'') character so that
> user and group names may contain the dot character.
Hum... I t
On Tue, 27 Jul 1999 13:43:33 +0200, Sheldon Hearn wrote:
> Sorry for bringing this up without doing all my homework. Diffs in the
> pipeline. :-)
Ha!
Diffs that produce a win in the midst of an apparent lose-lose. We now
continue to support the dot as a separator without breaking user- and
gr
Hi Brian,
Okay, your mail quoted below came around the same time I sent my
diffs. This entire response assumes that you don't like the diffs.
On Tue, 27 Jul 1999 08:10:47 MST, "David O'Brien" wrote:
> It was a one character fix in -CURRENT and I don't see any reason to ugly
> the code with sup
On Tue, 27 Jul 1999, Anders Vidmark wrote:
> Hi
Hej, :-)
>
> Im getting unreferenced inodes that fills up /.
> The box is running freebsd 2.2.6-release and sendmail 8.8.8
> Sendmails databases are rebuilt once every half hour.
> It seems like the unref. inodes comes from spammers.db and
> dom
On Tue, 27 Jul 1999 23:18:14 +0900, "Daniel C. Sobral" wrote:
> I'm talking about cpdup, which can be found in
> http://www.backplane.com/FreeBSD/. Someone posted a port at the
> time, but I don't know if anyone ever committed the port.
I'll commit a port in the next few days.
Ciao,
Sheldon.
On Tue, Jul 27, 1999 at 05:25:23PM +0200, Sheldon Hearn wrote:
>
> Hi Brian,
To paraphase Bill Paul:
G that's part of my last name.
--
-- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bo
At 9:29 AM -0400 7/27/99, Tim Vanderhoek wrote:
> On a file with 10+ lines, the speed difference is rather
> restrictive. [...] Only about 10% of the time is spend in
> procline(). There seems to be a lot of unnecessary strncpy()
> that could be _easily_ avoided if free() on util.c:130 was
>
>>>$B#N#T#T#S"~#F#T%F%l%3%`;v6HIt(B $B(B
>>>
>>>$B!!(B
$B!!(B >>>
>>>$B?9ED(B $BFuO:(B mailto:[EMAIL PROTECTED] $B
On Tue, 27 Jul 1999 09:07:34 MST, "David O'Brien" wrote:
> To paraphase Bill Paul:
>
> G that's part of my last name.
N! I was chatting to a buddy about this just after I sent you the
diffs and actually mentioned to him that I thought I might have made
this mistake again.
Since t
> Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
> truly, has written a BSD-licensed version of grep(1) which has all the
> functionality of our current (GPLed) implementation, plus a little
> more, in one seventh the source code and one fourth the binary code.
> I move that we r
:But it might be hiding a real security threat/attack or a real breakin.
:Say I've spent all night trying to hack into your machine and finally get in.
:If I can reset all of ipfw's counters back to zero, and this is
:something your security checking scripts are checking, you might not
:thin
:> Subject: Re: securelevel and ipfw zero
:>
:> However, it does not allow you to do it if you are sitting at secure
:> level 3.
:
:You don't think that this discussion highlights the growing inadequacy
:of the securelevel mechanism's lack of granularity?
:Ciao,
:Sheldon.
It would be
> > You get *better* information on per-rule limits than on a global limit.
>
> No, you simply get a finer-grained ability to select.
Which is almost always better.
> > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > month of bad packets in it.
> >
> > If you're a
> :Instead of zeroing it, how about raising the logging limit to (current +
> :whatever the limit was)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> The way I see it either some piece of software is moni
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup,
> :just because a sophisticated one is available. It would be useful to have
> :a per-firewall-rule counter, decrement it on each match if logging and
> :set, and be able to reset to something higher.
> :
> : Brian Fu
> I like the ability at secure level 3 to only reset the counters forward..
> It fits in with such things as the "append only" flag.
Then we'd have to implement per-rule counters that default to
IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
different setup than what we
> ipfw allows you to clear counters. It is a feature that already exists.
>
> However, it does not allow you to do it if you are sitting at secure
> level 3.
>
> Why not? I can't think of any good reason why clearing the counters
> should be disallowed when sitting at a hi
:I just thought of a bad thing. If you allowed the counters to be zero'd
:(or advanced) at securelevel == 3, then a 'malicious user' could write a
:cronjob to continually reset them and cause a DoS attack on the system
:(or in the case of advance, reset them to ridiculously high values),
:thus fi
> Peter Jeremy <[EMAIL PROTECTED]> writes:
> > > If it ever gets
> > >committed (I don't think it's particularly useful myself),
> > That's 2 against, 1 (me) for.
>
> Three against.
4 against.
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body
> the parts that they need. However right after 3.2-R came out there was a
> flurry of -questions mail about broken pkg dependencies because sysinstall
> wasn't properly registering the X install. If the port depending on the
Just to clear up a misconception; this isn't actually a sysinstall
prob
> But we can install from a single downloaded boot floppy, over the
> Internet, which is better.
1. Irrelevant, since most people who want to try BSD/OS out probably
aren't concerned about how FreeBSD installs itself; they're
simply different products.
2. Incorrect, since we don't install
On Tue, Jul 27, 1999 at 11:12:25AM -0600, Nate Williams wrote:
> How do you figure? Currently, the kernel will quit 'logging' denied
> packets when the counter reaches a specific (compiled-in) number.
^
Then what is
net.inet.ip.fw.verbose
> > How do you figure? Currently, the kernel will quit 'logging' denied
> > packets when the counter reaches a specific (compiled-in) number.
> ^
> Then what is
>
> net.inet.ip.fw.verbose_limit: 0
Well I'll be. You learn something new e
On Tue, Jul 27, 1999 at 11:15:11AM -0600, Nate Williams wrote:
> Then we'd have to implement per-rule counters that default to
> IPFW_VERBOSE_LIMIT but that could be changed to anything.
*falling on my knees* If you're going to do that what would it cost me (in
chocolate bars or sushi) to get you
> > (Another thing I just thought of is that this could cause DoS attacks on
> > the system if a user compromised root and then set the limit to a very
> > high number.)
>
> If you have someone going berzerk as "root" on a firewall you're definitely
> going to have a completely different set of h
On Tue, 27 Jul 1999, Brian F. Feldman wrote:
> On Tue, 27 Jul 1999, Soren Schmidt wrote:
>
> > It seems Dag-Erling Smorgrav wrote:
> > >
> > > I move that we replace GNU grep in our source tree with this
> > > implementation, once it's been reviewed by all concerned parties.
> >
> > Go for i
> > > You get *better* information on per-rule limits than on a global limit.
> >
> > No, you simply get a finer-grained ability to select.
>
> Which is almost always better.
>
> > > > If I'm an admin, I'm going to think "Well lets see, I want to store a
> > > > month of bad packets in it.
> >
> > I like the ability at secure level 3 to only reset the counters forward..
> > It fits in with such things as the "append only" flag.
>
> Then we'd have to implement per-rule counters that default to
> IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> different setup t
> > > How do you figure? Currently, the kernel will quit 'logging' denied
> > > packets when the counter reaches a specific (compiled-in) number.
> > ^
> > Then what is
> >
> > net.inet.ip.fw.verbose_limit: 0
>
> Well I'll be. You learn
On Tue, 27 Jul 1999, Jordan K. Hubbard wrote:
> > the parts that they need. However right after 3.2-R came out there was a
> > flurry of -questions mail about broken pkg dependencies because sysinstall
> > wasn't properly registering the X install. If the port depending on the
>
> Just to clear
> > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > trusted, but I won't argue that point since the firewall is often the
> > > > most 'natural' place to stick network accounting software.
> > >
> > > If you can't trust something in the kernel, then you just can't t
> > > I like the ability at secure level 3 to only reset the counters forward..
> > > It fits in with such things as the "append only" flag.
> >
> > Then we'd have to implement per-rule counters that default to
> > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > diffe
* From: "Jordan K. Hubbard" <[EMAIL PROTECTED]>
* Just to clear up a misconception; this isn't actually a sysinstall
* problem. This is a ports bug which Satoshi or somebody introduced
* when they added a dependency on the XFree86 port very prematurely. It
* was premature because no actual
> > > > > One could argue that accounting numbers in a firewall shouldn't be
> > > > > trusted, but I won't argue that point since the firewall is often the
> > > > > most 'natural' place to stick network accounting software.
> > > >
> > > > If you can't trust something in the kernel, then you ju
> > Again, it's not a fix, it's a feature. Not being able to mess with
> > counters (logging or otherwise) is a feature. It may be a feature that
> > you can do without, but that decision is not to be made lightly.
>
> I'm _saying_ to create a completely separ
> > > > I like the ability at secure level 3 to only reset the counters forward..
> > > > It fits in with such things as the "append only" flag.
> > >
> > > Then we'd have to implement per-rule counters that default to
> > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very
> > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > counters (logging or otherwise) is a feature. It may be a feature that
>
> > > you can do without, but that decision is not to be made lightly.
> >
> > I'm _saying_ to create a comp
> > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > counters (logging or otherwise) is a feature. It may be a feature that
> >
> > > > you can do without, but that decision is not to be made lightly.
> > >
> > > I'm _saying_ to c
> > > > > Again, it's not a fix, it's a feature. Not being able to mess with
> > > > > counters (logging or otherwise) is a feature. It may be a feature that
> > >
> > > > > you can do without, but that decision is not to be made lightly.
> > > >
> > > > I'm _
On Tue, 27 Jul 1999, Kip Macy wrote:
> Is there anyone in particular to whom we should write at VMWare?
> I agree with his sentiments.
I picked a likely looking name from the "contact us" page. Make
sure that you only write if you are willing to pay for the product if they
make it, and
a system wide limit and each rule's logging counter individually resetable
back to 0.
On Tue, 27 Jul 1999, Joe Greco wrote:
>
> 1) Set a global VERBOSE_LIMIT mechanism and:
> a) allow your logging counter to be reset, or
> b) allow your limit to be raised to re-enable logging
>
> I'd like to see people other than you, I, and Matt discussing this.
> Other people who use this feature of IPFW that have an opinion one way
> or the other should speak up.
I must admit being a bad boy - I'm using ipfw for firewalling and
accounting: "log" rules for catching bad guys (and I'm n
On 27 Jul 1999, Dag-Erling Smorgrav wrote:
> I move that we replace GNU grep in our source tree with this
> implementation, once it's been reviewed by all concerned parties.
First, I'm all for this idea, and applaud you and Jamie for taking
it on. I do have a few questions. Does POSIX sa
On 1999-07-27 13:37:35 +0200, Dag-Erling Smorgrav wrote:
> Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
> truly, has written a BSD-licensed version of grep(1) which has all the
> functionality of our current (GPLed) implementation, plus a little
> more, in one seventh the source
On Tue, 27 Jul 1999, Doug wrote:
> First, I'm all for this idea, and applaud you and Jamie for taking
> it on. I do have a few questions. Does POSIX say anything about grep, and
> if so, is this version compliant? Also, I'd like to put in another vote
> for full GNU grep feature compliance,
On Tue, Jul 27, 1999 at 10:32:40AM -0700, Jordan K. Hubbard wrote:
>
> Just to clear up a misconception; this isn't actually a sysinstall
> problem. This is a ports bug which Satoshi or somebody introduced
> when they added a dependency on the XFree86 port very prematurely. It
I can claim a bi
On Tue, 27 Jul 1999, Jamie Howard wrote:
> I do not have a copy of POSIX, but I do have Unix98 which is a superset of
> POSIX. Right now, excluding bugs, it is Unix 98 and therefore POSIX
> compliant
Good news, thanks for addressing this concern.
> except for -e. -e should permit mul
Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card?
thanks,
kdl
--
Kelly D. Lucas| Kroll-O'Gara
Security Consultant | Information Security Group
[EMAIL PROTECTED] | 650-812-9400 x 117
"Any opinions that I state are my own, and not Kroll-O'Gara's"
On Tue, 27 Jul 1999 14:14:33 -0700
"Kelly D. Lucas" <[EMAIL PROTECTED]> wrote:
> Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card?
As far as I can tell, this is a RealTek 8139 board.
-- Jason R. Thorpe <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PRO
101 - 200 of 228 matches
Mail list logo
