Unpacking Debian packages on FreeBSD
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? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unpacking Debian packages on FreeBSD
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? You can use ar ar x package.deb Milan Kopacka To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
Is there anyone in particular to whom we should write at VMWare? I agree with his sentiments. -Kip On Mon, 26 Jul 1999, 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 FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hot-swapping ata disks
It seems Iani Brankov wrote: [Charset koi8-r unsupported, filtering to ASCII...] Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). I have some experimental code that enables one to do this, but it is not without risk as the IDE channels are not designed for this. You also need to put the disk in a drawer that is able to shut off power etc so you dont burn any electronics while changing the drive. Once I get a little time I'll celan this up and make it available... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Which /etc-files do I need until vinum is initialized?
Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Regards, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Which /etc-files do I need until vinum is initialized?
On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: /etc/gettytab /etc/login.conf /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n "$vinum_drives" ]; then vinum read $vinum_drives mount /etc fi 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-hackers" in the body of the message
Re: FibreChannel support ?
Support exists for the Qlogic 2100 and 2200 FC-AL cards. On Tue, 27 Jul 1999, Papezik Milon wrote: Hi all, only simple question :-) Does FreeBSD support any FibreChannel controller or does body somebody writing a drive? For which card card? Thanks in advance. Milon -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
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 upgrade to freebsd 3.2? upgrade sendmail? TIA Anders Vidmark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Which /etc-files do I need until vinum is initialized?
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 not sure which effect the missing class has. Regards, Alex -Original Message- From: Greg Lehey [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 27. Juli 1999 09:43 To: Alexander Maret Cc: [EMAIL PROTECTED] Subject: Re: Which /etc-files do I need until vinum is initialized? On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: /etc/gettytab /etc/login.conf /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n "$vinum_drives" ]; then vinum read $vinum_drives mount /etc fi 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-hackers" in the body of the message
Re: VMWare plug/quickie tests.
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 FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan I _have_ written to them. If you look at the archives you'll see that I was one of the first :b. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
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-hackers" in the body of the message
replacing grep(1)
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 actually possible for mere mortals to read and understand. The source code is available for download from freefall: URL: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. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote: URL: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), Jamie assured me that he'd keep me updated on the progress of his software. That was the last I heard of it, and the port is still sitting at version 0.3 . Version 0.3 broke port-building badly. Does version 0.7 make it through a build of a whole stack of ports? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 body of the message
Re: securelevel and ipfw zero
: 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. 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 higher secure level. The counters are nothing more then statistics. Clearing statistics is not a security threat. 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 think that anyone has even been trying to break into your machine, much less made it into the machine. If I have some inside information, I could probably even get the counters back into the range where you might expect them to be at. Hopefully if this were to happen, you might see some other console/syslog messages or something else that catches your eye, but then again, maybe not. Just to help out people running at higher security levels, you could always implement something that lets you reset the values to some higher value that is easy to do computations from. E.g. ipfw --increment_counters=2 Which would bump all of the counters up to the value of "2", assuming they are all still less than that value. That way if you are trying to do some testing/debugging/counting after setting the counters, at least you have a nice round number to subtract from the current values. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 the binary code. What's more, the code is actually possible for mere mortals to read and understand. The source code is available for download from freefall: URL: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. Go for it, the more GNU stuff we nuke the better :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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, 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. /joking Seriously, I'd love for this to happen. Most GNU software is a hopeless, gruesome mess that should be dragged out and shot. Getting rid of as much as possible, gradually, is a Very Good Thing; this is how we get stability and performance improvements. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 nothing breaks)? There seems to be at least one dependency on GNU grep in /ports/Mk/bsd.port.mk where the -F argument is used. How's it compare in speed? [I'd test it myself, but see my private email...] -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 implementation we'll be introducing will introduce a performance loss, not a gain. As far as stability goes, there's a loss involved _if_ passing the GNU grep regression tests is important. Don't get me wrong. I'm all for replacing GNU software. Let's just be realistic and keep in mind that being non-GNU doesn't necessarily mean better. 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 remembering that. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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') function which is declared as 'int' (and return int result) and compared with NULL ;-( I prefer not to include the patch for this because I am uncompatible with such trics as: return ((f = fopen(path, mode)) != NULL) - 1; This was done this way because the gzopen and fopen both return pointers of different types. Maybe the best thing would be to have grep_open() return a void pointer since procfile() doesn't keep track of what files are open and not. This is ugly and not very reusable, but then again how many programs need transparent access to both gzip'd and plaintext files? Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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. Supposedly the merged buffer/vm means mmap doesn't make as large a difference as it used to. On a file with 10+ lines, the speed difference is rather restrictive. Looking over the gprof output, I think its authors (or some other intrepid hacker) will find ways to speed it up. 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 avoided, but I'll let the authors speak first. :-) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
reserved/local ioctl values?
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 conflict with a major set of ioctls (particularly terminal, as this is the type of driver it will be). Also, would it be wise to reuse an existing value? For instance, 'C' is used apparently by the SCSI system in /usr/include/cam/scsi/scsi_targetio.h, ISDN in /usr/include/machine/i4b_debug.h, and sound in /usr/include/machine/soundcard.h. In short, I want a value thats 'safe', in so far as I probably won't have to go back and redefine it later. I've been burned on thsi before (see majors.i386 in /usr/src/sys/i386/conf where 200-255 are now reserved... They weren't until post 2.2.6-ish when I spent 3 weeks doing tech support because one of the new device drivers in 2.2.8 conflicted with locally released code). Anyhow, good thoughts? -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group - owner:group
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: /var/log/exim/mainlog exim.mail 640 7 *24Z I will be adding the ":" syntax to -STABLE before 3.3-R, and it will accept both ":" and ".". It was a one character fix in -CURRENT and I don't see any reason to ugly the code with supporting both syntaxes in -CURRENT. The change will be documented in 4.0-R's release notes. If people don't read that, then they will be in trouble in many other ways. Anyway, it has been only ":" in -CURRENT for a while now, and I haven't received any death threats, so people must not be tripping over this on a daily basis. :-) The problem with printing out warnings is ``newsyslog'' is usually run from cron(8), and anything printed out will often not be seen as I am of the opinion many do not read root's mail. -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group - owner:group
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 think I should change this text slightly. I should not refer to chown(8) so strongly. It's on my list now. :-) -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group - owner:group
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
groupnames which include dots. I took my lead from chown(8).
Ciao,
Sheldon.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/Makefile,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile
--- Makefile1999/01/22 19:38:39 1.6
+++ Makefile1999/07/27 15:04:37
@@ -1,7 +1,7 @@
# $Id: Makefile,v 1.6 1999/01/22 19:38:39 wollman Exp $
PROG= newsyslog
-
+CFLAGS+=-DSUPPORT_DOT
MAN8= newsyslog.8
.include bsd.prog.mk
Index: newsyslog.8
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.8,v
retrieving revision 1.19
diff -u -d -r1.19 newsyslog.8
--- newsyslog.8 1999/06/28 03:15:01 1.19
+++ newsyslog.8 1999/07/27 14:18:12
@@ -275,12 +275,12 @@
.Pp
Copyright 1987, Massachusetts Institute of Technology
.Sh COMPATIBILITY
-Previous versions of the chown utility used the dot (``.'') character to
-distinguish the group name.
-Begining with
-.Fx 4.0 ,
-this has been changed to be a colon (``:'') character so that user and group
-names may contain the dot character.
+Previous versions of the
+.Nm
+utility used the dot (``.'') character to distinguish the group name.
+This has been changed to the colon (``:'') character so that user and group
+names may contain the dot character. Future versions may not provide
+backward compatibility.
.Sh "SEE ALSO"
.Xr gzip 1 ,
.Xr syslog 3 ,
Index: newsyslog.c
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v
retrieving revision 1.23
diff -u -d -r1.23 newsyslog.c
--- newsyslog.c 1999/06/28 03:15:02 1.23
+++ newsyslog.c 1999/07/27 15:06:24
@@ -286,7 +286,13 @@
if (!*parse)
errx(1, "malformed line (missing fields):\n%s", errline);
*parse = '\0';
+#ifdef SUPPORT_DOT
+/* Older configurations used '.' between user and group */
+if ((group = strchr(q, ':')) != NULL ||
+(group = strchr(q, '.')) != NULL) {
+#else
if ((group = strchr(q, ':')) != NULL) {
+#endif
*group++ = '\0';
if (*q) {
if (!(isnumber(*q))) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group - owner:group
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 supporting both syntaxes in -CURRENT. All I can offer in response is "because it's not _that_ ugly and there's no reason to leave concrete blocks on the upgrade path, even if you are supposed to walk it in steel-capped boots". :-) The change will be documented in 4.0-R's release notes. If people don't read that, then they will be in trouble in many other ways. Anyway, it has been only ":" in -CURRENT for a while now, and I haven't received any death threats, so people must not be tripping over this on a daily basis. :-) Judging by the number of PRs I've dealt with concerning the built-in tcp_wrappers included in 3.2, I have to say that this argument gives me the willies. There were _no_ complaints about inetd and built-in wrappers -- until it hits STABLE. :-) Jordan once told me that we do as much as (but no more than) we can to make the upgrade path as smooth as possible. I don't think that the extra line of code is more than we can do. :-) I'm acting out of self-preservation here. If a line of code can save me 5 PR's on 4.0-RELEASE, I'll take the line. *snort* The problem with printing out warnings is ``newsyslog'' is usually run from cron(8), and anything printed out will often not be seen as I am of the opinion many do not read root's mail. Oh, I wasn't suggesting that you should do anything about the warnings. I was trying to point out that the wallies who don't read the release notes are _definitely_ going to come crying to us. :-) Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
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 domainalias.db. Is there a way to avoid this? Will it get better if I upgrade to freebsd 3.2? upgrade sendmail? This could be due to filesystem corruption, either because of crashes or for some other reasons. You can try fsck -y on a quiet system (i.e. in single-user mode). 2.2.6-R is ancient, and it contained well known security holes. The same goes for your version of sendmail. You should definitely upgrade your server. 3.2-STABLE is officially recommended version, but if you're afraid of too many changes (ELF, bootloader, changed VM) you should at least upgrade to the latest 2.2-STABLE. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group - owner:group
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 body of the message
Re: replacing grep(1)
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 avoided, but I'll let the authors speak first. :-) Hmm, strncpy? Are these calls which really want strncpy for what it was originally designed for, or are they just trying to prevent buffer overruns? If it's the buffer-overrun answer, then maybe this would be a good test case for using strlcpy instead of strncpy, and see if it makes a performance difference (since the code won't waste it's time nulling-out bytes that don't need to be nulled-out). --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fw: help$B!!(Bme$B!!(Bfrom panic man
$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(B $B!!(B $B(B $B2#IM;TCf6h;32(B : help$B!!(Bme$B!!(Bfrom panic man $B!!$3$s$K$A$O$_$J$5$s!#!!?9ED$H?=$7$^$9!#(B $B!!(BGood afternoon everyone. $B!!(BIt is called Morita. $B#1!!$I$J$?$+!"(BRADIUS$B%5!<%P!<$N<-=q$rB>$N(BRADIUS$B%5!<%P!<$N<-=q$X(B $BE>Aw$7$?J}$$$^$9$+!)(B 1$B!!(BIs there the one that anyone, the dictionary of the RADIUS server were transferred to the dictionary of other RADIUS servers? $B#2!!$=$l$+$i!"$b$&$R$H$D
Re: newsyslog owner.group - owner:group
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 the first time, I've been quite careful about obrien and brian. Apologies and stuff. :-) Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
A couple of general problems:
o Too many diagnostics have "Undefined error: 0" appended.
Particularly in the case of "err(2, re_error)" in file.c,
you probably want to look at using errx() instead.
o Errors other than "no match" need to return a exit status
of 2: some in file.c and util.c are returning 1.
A more general concern is whether Henry Spencer's regex routines
-- at least in our present "alpha-quality" version -- are up to
supporting a grep without much further debugging. I don't recall
many of the problems I found when I last looked at these, though
here are two, after 5 minutes playing:
echo xx | grep '\(x\{1,2\}\)\1'
echo x | grep '[--x]'
--
Robert Nordier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
: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 :think that anyone has even been trying to break into your machine, much :less made it into the machine. If I have some inside information, :I could probably even get the counters back into the range where you :might expect them to be at. : :Hopefully if this were to happen, you might see some other console/syslog :messages or something else that catches your eye, but then again, :maybe not. : :Just to help out people running at higher security levels, you could :always implement something that lets you reset the values to some :... :Mike Pritchard I find this scenario highly unlikely. I can think of a thousand things. Well, a dozen anyway, that said hacker could do to the machine that are far more serious then clearing ipfw counters. And for that reason, I don't really consider it a realistic scenario. The hacker isn't going to give a damn about the ipfw counters. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel too course-grained?
: 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 interesting to see it turn into a bitmask, where setting it to '-1' secures everything. But I think the original intent was to make it more user-friendly in concept. It is simply a matter of relative merit. If a high securelevel still allows most files to be modified, it might as well allow clearing of the ipfw counters. Ultimately the only way to do securelevel properly is with capabilities. The system gives init all the major capabilities and init passes them on as appropriate. A system-wide secure level for a feature is created simply by globally destroying a particular capability. It would also be possible to destroy all instances of a capability except in the specific processes that need it - though in that case you wouldn't be able to restart the process in question. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
: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 monitor the counters, in which case the sysad does not need to clear them and does not need to look at log messages, or the sysad is monitoring the stuff manually and using the log messages. In the one case the counters don't need to be cleared (and, indeed, should not be), in the other case the sysad may want to clear them due to the manual monitoring. How do you figure? Currently, the kernel will quit 'logging' denied packets when the counter reaches a specific (compiled-in) number. Once that number is hit, you get 'hits', but no details as to what the signature of the hits are. The current 'signature' includes all of the IP information and such, which is invaluable (necessary?) for determing who's doing bad things (or not). This is in the kernel, and currently there is no way of modifying the counters in high securelevels. It doesn't matter if it's a human or a computer monitoring them, once the limit is reached alot of useful information is lost since the kernel no longer produces this information. # ipfw add 110 deny log tcp from any to any 110 via ed0 in Once the compiled in limit is reached, the kernel only says that we've got a hit, but it doesn't tell me who/when this happened. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 currently have. (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.) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
: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 filling up the disk. : :However, one could argue that *IF* they have root, they could just as :easily fill the disk with garbage and cause the same attack, ie; : :# dd if=/dev/zero of=/var/log/misc The hacker w/ root would have to be a complete bozo to write a cron job or loop to clear the ipfw counters rather then do something else that really blows the machine away! It isn't a scenario that fills me with fear. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
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 of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
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 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 package exists for XFree86 yet and yet it's part of the dependancy chain now for a lot of packages, resulting in severe dysfunction unless it's removed by hand from the INDEX you use for package adding. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Free BSDI CD!
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 off a single floppy either. In other words, "you lose, but thanks for playing and here's a copy of our home game." - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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_limit: 0 made for and why does it help changing it? 8-) It might also be nicer to give it its own facility for syslog... Achim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 everyday. :) made for and why does it help changing it? 8-) Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule counters, when in fact you may only want to change a single counter. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
(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 headaches. Why should someone start DoS attacks after capturing a firewall? It's like painting the fingernails before amputating the hand. So it was a bad example. If I had enough brain cells to boil a cup of water for my soup I'd be able to come up with more 'viable' issues where modifying the counters is a bad thing. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 it, the more GNU stuff we nuke the better :) -Søren 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. /joking Actually there is a difference between grep and gcc. you wouldn't ship cc on a binray -only embedded system. but you might want to ship grep (so that control scripts an use it). Seriously, I'd love for this to happen. Most GNU software is a hopeless, gruesome mess that should be dragged out and shot. Getting rid of as much as possible, gradually, is a Very Good Thing; this is how we get stability and performance improvements. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the If I'm an admin on today's internet (and I am), of course I realize that I'm not going to save a month worth of all bad packets, but I _can_ choose to hold onto a reasonable amount of logging information, which is what we are discussing. Sure, but you can't call 'tossing 4/5 of the information that I receive in a totally arbritary manner' useful logging information. A global count would allow you to log information in a totally arbitrary manner. No, it would give me complete control - up to the point where I've decided that further information is not useful. In that case, why have separate log rules? You may not ever get to see them if the limits are hit, so why not just one single rule to catch everything you want to log, since there's no guarantee that you'll see any logged information from the other rules. There's no guarantee either way. As long as you specify some limit at all, you risk losing data. Hell, you risk losing data if syslogd can't keep up with the kernel message buffer, or if your disk fills... You might get something, but it's totally arbitrary and based upon known 'scripts' on what information is logged. Finer grained logging gives you *better* information, since it's more detailed. If you don't care about details, then why are you logging at all? Because I want to know when Bad Things Happen. That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it allows you to sample the beginning of each 5 minute period, and you ought to be able to calculate the space required in a manner that allows you to guarantee that you have sufficient space. I can't speak for the author, but as one of those involved in the discussion this wasn't even on the radar screen. The purpose of the option was to make DoS attacks less likely. It wasn't intended to provide you a good 'sampling' of attack packets on your system. Security is not effectively done by sampling. Sampling is too easy to thwart, and too often misses intrusions that are easily done by not doing sampling. :) And, because IPFW is so low-cost, there is very little reason to do sampling. Sampling is often done when 'real-time' monitoring is too expensive. So what are you saying? I'm saying that you can set the limit as high as you feel necessary to be comfortable that you are getting sufficient data from the filter. In the event that you exceed the limit, I'm also saying that further data becomes largely irrelevant and/or a liability, and that it should be dropped. I'm not saying I just want to "sample" the first packet I get every five minutes. However, if I'm getting more than a thousand, the additional detail is useless. What I'm hearing is that you want to change FreeBSD from doing 'real-time' monitoring to doing polling. The latter can be implemented from the former, but not vice-versa. We would be losing flexibility and usefulness by moving towards a 'polling' model. No, nobody except you used the word "polling". You can continue to monitor in realtime. I'm merely looking for a way to restart monitoring after the system has clamped down (VERBOSE_LIMIT) on excessive logging, and I'm also questioning if there is a better way to implement the VERBOSE_LIMIT. My advice to you is to quit 'polling' for packets (because as you've implied, you're not interested in the most of the information anyway), Bull fng s#!+ I'm not interested in the information! However, I'm probably not interested in (or going to look at) more than 1000 entries per five minute period. and use a *MUCH* smaller limit on your rules, and limit the number of rules you have, and you'll have almost the same result. I am _not_ about to reduce the number of rules I feel are necessary to have. They are all there for a good reason. Paranoia. :-) Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 10, and you reset the counter every 5 minutes, you still _ought_ to be able to determine that you require 2GB of disk space per day to keep those records. Great, but why even log data when you *plan* on throwing much of it away, in a totally arbitrary fashion. Why even bother? So you argue for getting rid of the IPFW_VERBOSE_LIMIT function, then? Well then fine, just be quiet, don't define it in the first place, and abstain from participating in this discussion. Otherwise, you are clearly *planning* to throw away
Re: securelevel and ipfw zero
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 currently have. (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.) This is already possible via sysctl, the VERBOSE_LIMIT variable may be altered. ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 everyday. :) made for and why does it help changing it? 8-) Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule counters, when in fact you may only want to change a single counter. The _problem_ with this (and it is FINE for doing interactive work on the system as far as I am concerned) is that in a production environment with machines with 800 day uptimes and securelevel 3, once you pass the VERBOSE_LIMIT, you _can_ disable VERBOSE_LIMIT by setting this to 0, but you then become vulnerable to the DoS attacks we have all been arguing about. In other words, it simply disables VERBOSE_LIMIT. Useful, as I said, if you have a low VERBOSE_LIMIT and you are getting some attack that you want to monitor firsthand in more detail... ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
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 up a misconception; this isn't actually a sysinstall problem. Okey dokey. As long as y'all are aware of it I'm happy, I just hadn't seen it mentioned. Thanks for clarifying, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 trust anything at all. It isn't the kernel that's zero'ing the counters. :) Accounting numbers in a kernel firewall _should_ be trustable, and on that basis, one can clearly make an argument for separating the logging count from the accounting count - which should never be zero'ed, at least in securemode. One could argue that 'logging counters' in a firewall _should_ be trustable as well. You've argued against it, but I'm not convinced that your opinion (or mine) is enough to consider it a 'bug'. I'm not saying your desire for per-rule counters is invalid, I'm just not of that same mindset. But it does seem clear that it would be useful to have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT throttle. It would be useful. But, is it's usefulness more important than being able to rely on 'logging counters' being valid? (You argue no, but I'm not convinced...) 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. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 currently have. (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.) This is already possible via sysctl, the VERBOSE_LIMIT variable may be altered. Can this be altered in securelevel==3? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
* 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 package exists for XFree86 yet and yet * it's part of the dependancy chain now for a lot of packages, You are entitled to you opinion, but please don't misrepresent the facts. They are not part of the dependency chain for any *packages*. * resulting * in severe dysfunction unless it's removed by hand from the INDEX you * use for package adding. True, but all the INDEX files *I* make for package sets (and those are the only ones you ought to be using, since those are the only ones truly synced with the time of package builds) have the XFree86 stuff stripped. :) -PW To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 trust anything at all. It isn't the kernel that's zero'ing the counters. :) Accounting numbers in a kernel firewall _should_ be trustable, and on that basis, one can clearly make an argument for separating the logging count from the accounting count - which should never be zero'ed, at least in securemode. One could argue that 'logging counters' in a firewall _should_ be trustable as well. You've argued against it, but I'm not convinced that your opinion (or mine) is enough to consider it a 'bug'. I'm not saying your desire for per-rule counters is invalid, I'm just not of that same mindset. But it does seem clear that it would be useful to have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT throttle. It would be useful. But, is it's usefulness more important than being able to rely on 'logging counters' being valid? (You argue no, but I'm not convinced...) 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 separate counter which has nothing to do with accounting. The counter which you "trust" for any purposes can be the accounting counter, which nobody can mess with in securemode. The logging counter is merely to allow VERBOSE_LIMIT whether or not the logging throttle should be engaged, and therefore you can EITHER: 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 2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's logging counter to be reset. So, what's your vote? (I'm wondering if maybe we can do a combined 1a and 2 of some sort) ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 separate counter which has nothing to do with accounting. See above. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 separate counter which has nothing to do with accounting. See above. I did see above. If the sole purpose of a counter is to turn _off_ a feature to prevent DoS attacks, and it is clearly desirable that the admin (or a representative entity such as a monitoring system) would want to be able to re-enable the logging under those same terms at some admin-specified interval, how exactly would you choose to implement this? Please, be specific. If zeroing a counter whose sole purpose in life is to control logging output presents a problem for you, perhaps some other alternative is possible. I'm not quite sure what it would be. ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 separate counter which has nothing to do with accounting. See above. I did see above. If the sole purpose of a counter is to turn _off_ a feature to prevent DoS attacks, and it is clearly desirable that the admin (or a representative entity such as a monitoring system) would want to be able to re-enable the logging under those same terms at some admin-specified interval, how exactly would you choose to implement this? What was originally intended and what it's used for now are two different things. 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. A group of two very opinionated people doesn't make a consensus, or necessarily the 'right' decision. :) :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 separate counter which has nothing to do with accounting. See above. I did see above. If the sole purpose of a counter is to turn _off_ a feature to prevent DoS attacks, and it is clearly desirable that the admin (or a representative entity such as a monitoring system) would want to be able to re-enable the logging under those same terms at some admin-specified interval, how exactly would you choose to implement this? What was originally intended and what it's used for now are two different things. I agree; the function of verbose log limiting was overloaded onto the existing accounting counter. That is why I am saying that this really, really should be made into a separate log counter, whose sole function in life is counting for the purpose of determining VERBOSE_LIMIT excesses. I am not sure why you seem to have a problem with that. If I have a mechanism that exists for _one_ purpose and one purpose alone, why is it unacceptable to perform operation "X" (where X == zero it) on said device when that is an action that will cause it to work in a desired manner? 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. A group of two very opinionated people doesn't make a consensus, or necessarily the 'right' decision. :) :) :) ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare plug/quickie tests.
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 then be sure to tell them that if you are. When I responded to their standard "we have no plans for a freebsd port" response with some reasonable, calm information about market share, demographics, etc. the sales droid actually responded with something to the effect of, "Hmmm.. I wasn't aware of that, I'll have to pass that on." So perhaps there is hope, but I'm still not holding my breath. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 2) Set a rule-oriented VERBOSE_LIMIT mechanism and allow each rule's logging counter to be reset. So, what's your vote? (I'm wondering if maybe we can do a combined 1a and 2 of some sort) ... Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 not caring for a limit there as I'm preferring a DoS by crashing the firewall over someone getting through unnoticed) and the counters for accounting (that's why I'd like to have some "read and reset" function so I can milk them without dripping too much). Achim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 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, since while having our own code is a good thing, I am against introducing gratuitous differences since I have enough of those to deal with already. I think ports building is a good test, but has anyone tested it with RCS yet? IIRC RCS is heavily dependant on GNU grep, diff and patch. I don't think CVS is dependant on external programs anymore though. I use grep heavily in day to day administration tasks so I look forward to giving this a try. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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, since while having our own code is a good thing, I am against introducing gratuitous differences since I have enough of those to deal with already. 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 except for -e. -e should permit multiple patterns and it never occured to me that anyone would want to do this. When used with -F, multiple patterns are accepted. I use grep heavily in day to day administration tasks so I look forward to giving this a try. Cool, d/l it and post a bug-list :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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 multiple patterns and it never occured to me that anyone would want to do this. Ah, well, if the world were limited to just what I could imagine, how boring would that be? The more complete the feature set, the better off we are for my money. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMC 1211TX
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 PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMC 1211TX
Out of da blue Kelly D. Lucas aka ([EMAIL PROTECTED]) said: Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? Yes it's the real tek driver. device rl0 # RealTek 8129/8139 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" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message #:^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999, Doug wrote: Ah, well, if the world were limited to just what I could imagine, how boring would that be? The more complete the feature set, the better off we are for my money. You misinterpretted, I didn't know you could do that therefore I didn't implement that. I certainly understand why you would want to :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Which /etc-files do I need until vinum is initialized?
On Tue, Jul 27, 1999 at 05:12:49PM +0930, Greg Lehey wrote: each. But I think you could eliminate these ones: /etc/gettytab /etc/login.conf /etc/ttys I'm not shure on /etc/ttys - init reads it already for singleuser-mode to check if /dev/console is secure. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
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. Normally I don't post "me too" messages. I'll make an exception. Me too. -- - 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-hackers" in the body of the message
Re: replacing grep(1)
On Tue, 27 Jul 1999, James Howard wrote: On Tue, 27 Jul 1999, Doug wrote: Ah, well, if the world were limited to just what I could imagine, how boring would that be? The more complete the feature set, the better off we are for my money. You misinterpretted, I didn't know you could do that therefore I didn't implement that. I certainly understand why you would want to :) Ah, gotcha. Even better. :) Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: adding to periodic/weekly
On Wednesday, 28 July 1999 at 3:04:25 +1000, Sue Blake wrote: I want to add some maintenance tasks to be run weekly (maybe daily ones too). There seem to be at least five ways to do this: Just add it to the system crontab - Can run at a different time, if necessary. Leaves periodic unmolested. - Separates it from other weeklies, could become lost or confusing. Add it to /etc/periodic/weekly/999.local - This might be what the file is intended for. - Maybe I shouldn't clutter that file. Create /etc/weekly.local and put it in there - It's tempting because 999.local picks it up if present. - Comment says this is only for backward compatibility. Add another file /etc/periodic/weekly/high number.whatever - Can keep it away from existing sequence, or insert if necessary - Future upgrades might add files using the numbers I choose Put it in a numbered file under /usr/local/etc/periodic/weekly/ - This seems to be what it's intended for, but nobody said I could - Path is already in rc.conf but doesn't exist, not sure why not used - Can't find doc on its use, e.g. run in path order? unique numbers required? Which method is generally best, and why? Are any of these methods really naughty? Interesting question. I don't have any personal preferences, though I put my stuff in /etc/crontab or my private crontab out of habit. But this is probably material for -hackers, so I'm forwarding it there. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html 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-hackers" in the body of the message
Re: SMC 1211TX
Jason Thorpe wrote: 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. Oh my, SMC must be really lowering their standards... Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
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 _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMC 1211TX
On Wed, 28 Jul 1999 09:44:03 +0800 Peter Wemm [EMAIL PROTECTED] 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 lot of success with those boards under NetBSD; they perform *quite* well. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group - owner:group
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):
-if ((group = strchr(q, ':')) != NULL) {
+if ((group = strchr(q, ':')) != NULL ||
+(group = strrchr(q, '.')) != NULL) {
It the becomes [almost totally] non-ambigitous (since the separator is
required) and allows "david.obrien.staff". In my mind more people use
dots in usernames than group names. Anyay, it is documented to use :,
and I am just trying to be "liberal in what is accepted" (w/o
obfuscating the code).
--
-- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
$ 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.
Reading symbols from /usr/lib/libc.so.3...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x280a8538 in ftello (fp=0x0)
at /FBSD/src/lib/libc/../libc/stdio/ftell.c:76
76 if (fp-_seek == NULL) {
(gdb) where
#0 0x280a8538 in ftello (fp=0x0)
at /FBSD/src/lib/libc/../libc/stdio/ftell.c:76
#1 0x280a84e1 in ftell (fp=0x0) at /FBSD/src/lib/libc/../libc/stdio/ftell.c:59
#2 0x80490b7 in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
#3 0x80499f1 in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
#4 0x804968b in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
#5 0x8048d3d in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
(gdb)
--
-- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
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 Demtrito(sp?), file's maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Thus we see what Chris calls it, and we stay in sync with the offical distribution. ...something on my list of things to update in src/contrib/ over the summer. -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
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 to get the word out better. :-) Since KAME is probably closest to unified, I think we need to point people to the "offical" IPv6 patch set. The problem is the IPv6 wanting user does not know which of the available stacks to go with. It is easy to feel one would have to download 3 different stacks and experiement with all to determine which one works well. Lets help these people out. How about adding this to 3.3's RELEASE notes and a pointer from our website? (maybe also http://www.freebsd.org/handbook/install.html) -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Unpacking Debian packages on FreeBSD
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? Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Unpacking Debian packages on FreeBSD
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? You can use ar ar x package.deb Milan Kopacka To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: VMWare plug/quickie tests.
Is there anyone in particular to whom we should write at VMWare? I agree with his sentiments. -Kip On Mon, 26 Jul 1999, 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 FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: hot-swapping ata disks
It seems Iani Brankov wrote: [Charset koi8-r unsupported, filtering to ASCII...] Hi, I tried 'camcontrol rescan' and I found it works when I add a SCSI device while the system is on. I find it useful for adding/removing devices w/o restarting the box. (Maybe it's risky, but useful. I supposed that's the idea of the 'rescan' command in camcontrol) Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI anyway). I have some experimental code that enables one to do this, but it is not without risk as the IDE channels are not designed for this. You also need to put the disk in a drawer that is able to shut off power etc so you dont burn any electronics while changing the drive. Once I get a little time I'll celan this up and make it available... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Which /etc-files do I need until vinum is initialized?
Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Regards, Alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FibreChannel support ?
Hi all, only simple question :-) Does FreeBSD support any FibreChannel controller or does body somebody writing a drive? For which card card? Thanks in advance. Milon -- pape...@pvt.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Which /etc-files do I need until vinum is initialized?
On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: /etc/gettytab /etc/login.conf /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n $vinum_drives ]; then vinum read $vinum_drives mount /etc fi Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FibreChannel support ?
Support exists for the Qlogic 2100 and 2200 FC-AL cards. On Tue, 27 Jul 1999, Papezik Milon wrote: Hi all, only simple question :-) Does FreeBSD support any FibreChannel controller or does body somebody writing a drive? For which card card? Thanks in advance. Milon -- pape...@pvt.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[no subject]
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 upgrade to freebsd 3.2? upgrade sendmail? TIA Anders Vidmark an...@sdf.se To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Which /etc-files do I need until vinum is initialized?
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 not sure which effect the missing class has. Regards, Alex -Original Message- From: Greg Lehey [mailto:g...@lemis.com] Sent: Dienstag, 27. Juli 1999 09:43 To: Alexander Maret Cc: freebsd-hackers@freebsd.org Subject: Re: Which /etc-files do I need until vinum is initialized? On Tuesday, 27 July 1999 at 9:32:51 +0200, Alexander Maret wrote: Hi, I configured vinum (RAID 1) on a 3.2S System. As I want to mirror as much as I need to keep the system running (in case of a drive 1 failure) I mirrored /etc as well. At boot time (until vinum is initialized) the system only has the following files: /etc/defaults/rc.conf /etc/rc.conf /etc/rc /etc/fstab /etc/gettytab /etc/login.conf /etc/ttys Do I need all of these files or can I put some of them away (for example /etc/ttys or /etc/gettytab)? The files would of course be available as soon as vinum is initialized and /etc mounted. Interesting question. In view of the fact that I intend to make the root file system bootable One Of These Days, I don't think you should go to too much trouble here: after all, they're only a few kilobytes each. But I think you could eliminate these ones: /etc/gettytab /etc/login.conf /etc/ttys You might find it advantageous to modify /etc/rc to mount /etc (and anything else you want) immediately after starting Vinum: if [ X$start_vinum = XYES ]; then vinum start mount /etc elif [ -n $vinum_drives ]; then vinum read $vinum_drives mount /etc fi Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: VMWare plug/quickie tests.
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 FreeBSD-land to see if it makes market sense. All the techs there appear to be sold on the idea, but it takes more than tech buy-in to get a project approved. :) - Jordan I _have_ written to them. If you look at the archives you'll see that I was one of the first :b. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposal for new syscall to close files
Peter Jeremy jere...@gsmx07.alcatel.com.au 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 - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Squid - a bug in src/sys/kern/uipc_socket.c
Jaye Mathisen mr...@internetcds.com writes: Maybe it could be made a sysctl knob... No, a socket option would be more appropriate. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: newsyslog owner.group - owner:group
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 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: /var/log/exim/mainlog exim.mail 640 7 *24Z Is the reason you haven't re-instated legacy support because you are 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 broken, since chown(8) supports both periods and colons. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Free BSDI CD!
On Mon, 26 Jul 1999, Warner Losh wrote: In message pine.bsf.4.10.9907262321180.35843-100...@janus.syracuse.net 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 the size of your disks. For me, it's LS-120s, so do you think that should take 2 of em? :) Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
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 /var/db/pkg/X* is actually an error I'll report what I find to
the -ports list.
You need to specify port, eg. /usr/ports/x/y or package.
I'd be surprised if you find any port that depends on /var/db/pkg/x.
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.
Thus, only /usr/ports should depend on X. Few if any of these should be
looking through ${PKG_DBDIR} for information. No packages should
depend on X.
--
This is my .signature which gets appended to the end of my messages.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Unpacking Debian packages on FreeBSD
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 convert packages between formats. you should be able to find it on FreshMeat. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: newsyslog owner.group - owner:group
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-over period possible. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: XFree 3.3.4 not on ftp.freebsd.org?
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, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
TCP/IP hardening, take two
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): | Starting nmap V. 2.12 by Fyodor (fyo...@dhp.com, www.insecure.org/nmap/) | Interesting ports on destmp.follo.net (195.204.143.235): | (Not showing ports in state: filtered) | PortState Protocol Service | 22 opentcpssh | | TCP Sequence Prediction: Class=random positive increments | Difficulty=38742 (Worthy challenge) | No OS matches for host (see http://www.insecure.org/cgi-bin/nmap-submit.cgi). | TCP/IP fingerprint: | TSeq(Class=RI%gcd=2%SI=1429) | TSeq(Class=RI%gcd=1%SI=1026) | TSeq(Class=RI%gcd=1%SI=9756) | T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M) | T2(Resp=N) | T3(Resp=N) | T4(Resp=N) | T5(Resp=N) | T6(Resp=N) | T7(Resp=N) | PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E) | | | Nmap run completed -- 1 IP address (1 host up) scanned in 75 seconds Note: The TCP sequence prediction difficulty rating is meaningless, Successive nmap runs show ratings from approx. 5000 to approx. 4 for the same computer with the same software. DES -- Dag-Erling Smorgrav - d...@yes.no Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/27 11:18:30 @@ -48,6 +48,12 @@ tcp_extensions=NO# Set to Yes to turn on RFC1323 extensions. log_in_vain=NO # Disallow bad connection logging (or YES). tcp_keepalive=YES# Kill dead TCP connections (or NO). +tcp_drop_synfin=NO # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +tcp_log_synfin=NO# Set to YES to log TCP packets with SYN+FIN +tcp_restrict_rst=NO # Set to YES to restrict emission of RST +icmp_dropredirect=NO # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect=NO # Set to YES to log ICMP REDIRECT packets network_interfaces=auto # List of network interfaces (or auto). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/27 11:18:30 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 /dev/null fi + +if [ X$icmp_dropredirect = XYES ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 /dev/null +fi + +if [ X$icmp_logredirect = XYES ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 /dev/null +fi if [ X$gateway_enable = XYES ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,21 @@ if [ X$tcp_keepalive = XYES ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 /dev/null +fi + +if [ X$tcp_drop_synfin = XYES ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 /dev/null +fi + +if [ X$tcp_log_synfin = XYES ]; then + echo -n ' log SYN+FIN packets=YES' + sysctl -w net.inet.tcp.log_synfin=1 /dev/null +fi + +if [ X$tcp_restrict_rst = XYES ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 /dev/null fi if [ X$ipxgateway_enable = XYES ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/27 11:18:30 @@ -207,6 +207,8 @@ INET opt_inet.h IPDIVERT DUMMYNET opt_ipdn.h +IPFILTER opt_ipfilter.h +IPFILTER_LOG opt_ipfilter.h IPFIREWALL opt_ipfw.h IPFIREWALL_VERBOSE opt_ipfw.h IPFIREWALL_VERBOSE_LIMIT opt_ipfw.h @@ -220,11 +222,11 @@ PPP_BSDCOMPopt_ppp.h PPP_DEFLATEopt_ppp.h PPP_FILTER opt_ppp.h +SLIP_IFF_OPTS opt_slip.h TCP_COMPAT_42 opt_compat.h TCPDEBUG -IPFILTER opt_ipfilter.h -IPFILTER_LOG opt_ipfilter.h -SLIP_IFF_OPTS opt_slip.h +TCP_DROP_SYNFIN
replacing grep(1)
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 seventh the source code and one fourth the binary code. What's more, the code is actually possible for mere mortals to read and understand. The source code is available for download from freefall: URL: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. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: newsyslog owner.group - owner:group
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 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. If we don't offer backward compatibility, people will whine when they stub their toes. If we do, we break support for usernames which contain the dot (``.'') . I think David's chosen the lesser of two evils and I support his decision. However, I think we could at least introduce consistency with chown(8) by making dot-as-token support a compile-time option, -DSUPPORT_DOT which is turned _on_ by default. Later, -DSUPPORT_DOT can be removed from the Makefiles for chown(8) and newsyslog(8) and documented in src/Makefile.inc1 . Sorry for bringing this up without doing all my homework. Diffs in the pipeline. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
On 27 Jul 1999 13:37:35 +0200, Dag-Erling Smorgrav wrote: URL: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), Jamie assured me that he'd keep me updated on the progress of his software. That was the last I heard of it, and the port is still sitting at version 0.3 . Version 0.3 broke port-building badly. Does version 0.7 make it through a build of a whole stack of ports? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
