Re: Hey kernel hackers, this is worth a read.
On Fri, Jul 30, 1999 at 08:58:09PM -0700, "Jordan K. Hubbard" [EMAIL PROTECTED] wrote: http://features.linuxtoday.com/stories/8191.html A story on upcoming plans for the Linux 2.4 kernel. Since they're going after a lot of the same performance goals we are, it's worth a read. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message From the article: "Linux 2.4 also includes a completely rewritten networking layer." Great. After a few years from now when they get all the bugs out, they will be right back to the quality of early 4.4BSD quality ;) However, the SMP stuff they are working on is something we need IMHO. -- yan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Zepeda wrote: The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with "real" users IMO is quite a bit less hackish. I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. If NIS sends chills down your spine, I guess you could also do a bit of non-daemon-based hackage... make a script replace the home directory and shell fields with appropriate values in a copied passwd and rsync the thing to your mail boxes... Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). As usual, there's more than one way to skin a cat. Later, --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). And we do it the other way: Generate the users file from mysql. I rather prefer it like that; then I can still auth users, if mysql goes down. Also, it saved my a$$ once; mysql lacking commit and rollback. I was disturbed into firing off an update command before having typed the where-clause. I then locked the password of every user, instead of only the users belonging to a single client... Luckily, I dump the database every hour, and rcs it, so I can recreate the database at any hourly version the last few months. Leif As usual, there's more than one way to skin a cat. Yeah.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : Do we have a list of all services that use bpf? I'm willing to edit the man : pages, given a list. I guess I could just grep-o-matic here, huh? Yes. I'm also in a holding off pattern until we know the exact impact for all daemons that use this... I think I found a solution that may be better (although more complicated): Let the sysadmin to define a bpf filter for the packets that are considered OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for normal functioning). Provide some typical examples. After this filter is defined and the system goes to a higher security level bpf first applies this filter to all the incoming packets, and only if they pass this filter they are checked for application-specified filters. If there is no such "master" filter defined then bpf can just deny new open()s as proposed earlier. This will allow the applications to use bpf but only for the purposes defined in the master filter. This also resolves the problem of services re-opening bpf after SIGHUP. And speaking on the issue of bpf enabled in GENERIC, I'm strongly pro it. Having bpf disabled is a big pain. May be it would be better to provide a separate prototype configuration file, say, SECURE with all the dangerous things disabled and explanations why they are disabled, so that peoples will think twice before re-enabling them. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: No elf(5) man page (docs/7914)
Sheldon Hearn wrote: On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote: If no-one objects I'll submit a manpage per a.out(5) style tomorrow for review untill it's ready for inclusion. Anyone who objects to your submissions is a woes -- real bastards wait for you to do the work before shooting you down. :-) That's correct. I really doubt anyone will raise any objections before the man page is actually committed. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Documenting writev(2) ENOBUFS error
: [ENOBUFS] Insufficient system buffer space exists to complete the op- :eration. : :Do you know what kind of circumstances that error *really* occurs :under? So you can get ENOBUFS not related to mbufs for UDP/local datagram sockets, but you should never get ENOBUFS from write for TCP sockets or local stream sockets. So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. It should probably mention that it doesn't occur for most files (or that it only occurs for datagram sockets - although it probably applies to some types of raw sockets, too, and possibly non-PF_INET/PF_UNIX sockets) to avoid people doing unnecessary checking or implementing kernel code that bails out when it shouldn't. It should be a fair requirement that the kernel continue to never fail with ENOBUFS for a write to a reliable stream (local file, fifo, pipe or stream socket) and that such cases be treated as bugs. I would assume that this corresponds to how other systems operate, as well. Of course I'm no authority on this, and I'm not sure about NFS writes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sun, Aug 01, 1999 at 02:43:28AM -0700, Mike Hoskins wrote: I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. We support NIS, and secure RPC, but not NIS+. Bill Paul was working on it some time back, but I'm not sure if he still is... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DOC volunteer WAS:RE: userfs help needed.
Judging by your description, why don't we use LyX? :) LaTeX sounds about right. 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: Documenting writev(2) ENOBUFS error
On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote: So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. FWIW, I committed: [ENOBUFS]The mbuf pool has been completely exhausted when writing to a socket ... N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, Aug 01, 1999, Juha Nurmela wrote: Hello. Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? -- |Chris Costello [EMAIL PROTECTED] |Advanced design: Upper management doesn't understand it. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, 1 Aug 1999, Chris Costello wrote: On Sun, Aug 01, 1999, Juha Nurmela wrote: Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? Yes, but (this might be a trademark ;) commonly the arguments would be used during the sysinit-attach, and at that time sysctl has not yet been able to change anything. Use of sysctl would require a sidestep from attach and later continuation with a sysctl_proc. Not a problem, but inconvenient, IMHO. And it's analogous to executing, they too can get arguments. Juha To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
On Sun, 1 Aug 1999, Keith Stevenson wrote:
the features that were requested. I honestly haven't figured out how to
implement the display of selected fields yet. I realize that this isn't a
Attached is a diff that takes care of that. Basically, the user can
specify a format that looks like "%f\t%U\t%A" to get the files name, the
username of the owner, and the last access time seperated by tabs
followed by a new line. All of the supported format specifiers are
documented in the man page. I looked around for another version of stat
that does this but could not locate one; therefore the format specifiers
are what made sense to me. There is also limited support for C-style
escape sequences (no \nnn).
Have a nice day!
Jamie
diff -c stat/stat.1 stat-jph/stat.1
*** stat/stat.1 Sun Aug 1 23:18:48 1999
--- stat-jph/stat.1 Sun Aug 1 23:50:31 1999
***
*** 42,71
The options are as follows:
.Bl -tag -width Fl
.It Fl d
! dereference symlinks
.It Fl f
! read filenames to be stat-ed from file ( - means stdin)
.It Fl g
! show time elements in GMT time zone. (implies -s)
.It Fl h
! print usage summary
.It Fl i
! ignore errors
.It Fl l
! display one element per line
.It Fl s
! print mode, uid, gid, and times as strings
.It Fl t
! terse output
.It Fl o Ar opts
! output only selected elements of struct stat
.It Fl f Ar file
! read filenames to be stat-ed from file ( - means stdin)
.El
.Sh EXAMPLES
An example or two will go here
.Pp
.Sh SEE ALSO
.Xr stat 2
.Rs
.Sh AUTHORS
--- 42,107
The options are as follows:
.Bl -tag -width Fl
.It Fl d
! Follow symbolic links.
.It Fl f
! Read filenames to be stat-ed from file ( - means stdin).
.It Fl g
! Show time elements in GMT time zone. (implies -s)
.It Fl h
! Print usage summary.
.It Fl i
! Ignore errors.
.It Fl l
! Display one element per line.
.It Fl s
! Print mode, uid, gid, and times as strings.
.It Fl t
! Terse output.
.It Fl o Ar opts
! Output only selected elements of struct stat. The following
! formatting tags are permitted:
! .Bl -tag -width Fl
! .It Ar %A
! last access time
! .It Ar %C
! file creation time
! .It Ar %G
! file group (group name)
! .It Ar %M
! last modify time
! .It Ar %P
! file permission mode (symbolic)
! .It Ar %U
! file owner (username)
! .It Ar %b
! blocks allocated for file
! .It Ar %d
! device file is on
! .It Ar %f
! file name
! .It Ar %g
! file group (gid)
! .It Ar %i
! inode
! .It Ar %l
! number of hard links to file
! .It Ar %p
! file permission mode (octal)
! .It Ar %s
! file size in blocks
! .It Ar %t
! type of file
! .It Ar %u
! file owner (uid)
! .El
.It Fl f Ar file
! Read filenames to be stat-ed from file ( - means stdin).
.El
.Sh EXAMPLES
An example or two will go here
.Pp
.Sh SEE ALSO
+ .Xr ls 1 ,
.Xr stat 2
.Rs
.Sh AUTHORS
***
*** 73,76
.Sh DIAGNOSTICS
Most errors are the result of bad filenames.
.Sh BUGS
! Some features (-f, -i, -o) are currently unimplemented
--- 109,112
.Sh DIAGNOSTICS
Most errors are the result of bad filenames.
.Sh BUGS
! Some features (-f and -i) are currently unimplemented
diff -c stat/stat.c stat-jph/stat.c
*** stat/stat.c Sun Aug 1 23:17:14 1999
--- stat-jph/stat.c Sun Aug 1 23:34:29 1999
***
*** 57,62
--- 57,65
void terseprint(const char*, const char*, const char*, const char*,
struct stat*, struct group*, struct passwd*, struct tm*,
struct tm*, struct tm*, int);
+ void customprint(const char *, const char*, const char*, const char*,
+const char*, struct stat*, struct group*, struct passwd*,
+struct tm*, struct tm*, struct tm*, int);
int vstat(const char*, struct stat*, int);
***
*** 78,85
struct stat inode;
struct tm *atime, *mtime, *ctime;
! extern char *optarg;
! extern int optind;
/* flags */
--- 81,87
struct stat inode;
struct tm *atime, *mtime, *ctime;
! char *oformat;
/* flags */
***
*** 113,122
f_listout = 1;
break;
case 'o':
- printf("Unimplemented.\n");
- exit(EX_OK);
f_customout = 1;
f_listout = 1;
break;
case 's':
f_stringout = 1;
--- 115,123
f_listout = 1;
break;
case 'o':
f_customout = 1;
f_listout = 1;
+ oformat = optarg;
break;
case 's':
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED] John-Mark Gurney writes: : I vote for allowing inetd.conf to specify a port number instead of a : service name... it should be very easy to make the modification, and : I'm willing to do all the work, assuming no one on -committers objects.. I'd love to be able to do this. I have a firewall-like machine that I run services on several different that have no real names... I'm hacking /etc/services now, which is just wrong... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: no elf(5) man page (docs/7914)
* Andy Doran ([EMAIL PROTECTED]) [990802 00:53]: Wes Peters writes: NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^) It'd be cool if Asmodai could bounce this around one of the NetBSD lists once it's near completion. tech-toolchain@ or tech-userlevel@ would be the right place I guess. Will do. I already saw some differences in the stucture member names though, so ye will need to adjust those. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
Sheldon Hearn wrote: On Fri, 30 Jul 1999 15:10:18 MST, Doug wrote: On some of the machines I administer I have some custom entries for /etc/services that make more sense than the defaults, especially for the ports 1023. Would you need these entries if inetd let you specify port numbers instead of service names? Errr... while that may be of value to someone, it has nothing to do with the issue Ben and I were discussing. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message 37a3e203.de0fe...@gorean.org, Doug wrote: } Sheldon Hearn wrote: } } On Fri, 30 Jul 1999 15:05:14 MST, Doug wrote: } } I still haven't heard anyone answer the two key (IMO) questions. } } Your questions are easier answered in reverse order: } } and how do you justify the additional cost to parse the file for every } single system call that uses it? } } The information is part of the comments within the file. The cost is in } disk space, and it's cheaper than fleabites. } } Nowhere did I mention disk space. I agree that if that were the only is } sue } I wouldn't be raising the objection. } } Why is it better to have this in the file than in a man page, } } Since it costs nothing to have it in /etc/services, why not leave it } there along with the information with which it's associated? The } alternative is to have a manpage that contains most of the information } in /etc/services! } } And why is that bad? Since when is redundancy in the documentation a } problem? Like you said, disk is cheap. } } My only concern is that putting it IN the file has more costs than } benefits. } } What am I missing here, that I don't see a cost? What software scans the } lines in /etc/services beyond the comment delimiter, other than null } terminator searches? } } So, how many comments are you going to add? Let's say the total parsing } cost to the system for all of your additions is X. X is probably a pretty } small number, I'm not arguing that point at all. Now multiply X times every } packet on a highly loaded server, because that's how many times ipfw is } going to need to parse the file (roughly). No. ipfw deals with /etc/services only at startup time (any other behavior on its part would be ridiculous). } My point is simply that the information is valuable, but it belongs in } a } man page. There is no reason to add a good deal of non-functional } information to a file that is used by so many parts of the system. I think you're overestimating the cost by a considerable amount. I'm not saying that the cost is zero, but I am saying that it's close enough that the value of having the information *right there* outweighs the cost. Can you demonstrate a realistic scenario in which multiplying the volume of comments in /etc/services by, say, 10x results in a perceptible performance hit? -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
Jon Hamilton wrote: No. ipfw deals with /etc/services only at startup time (any other behavior on its part would be ridiculous). That's not entirely true, there are other situations (like adding a rule, etc.) but your point is well taken. And no, I can't provide specific examples, my point is really much simpler than that. I think you're overestimating the cost by a considerable amount. I'm not saying that the cost is zero, but I am saying that it's close enough that the value of having the information *right there* outweighs the cost. Anyone interested in the information will stay interested long enough to look it up in a man page. Even if the cost to the system is very very small, I think that adding it to the file is silly when it could just as easily be added to a man page. Of course, there are other benefits to having it in a man page too. The primary one being that changes/updates to the comments don't require a change to the file, and would be picked up automatically during a make world. Now you'll have to excuse me while I go sharpen my lance... Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message 37a3e944.7f28e...@gorean.org, Doug wrote: } Jon Hamilton wrote: } } No. ipfw deals with /etc/services only at startup time (any other behavior } on } its part would be ridiculous). } } That's not entirely true, there are other situations (like adding a rul } e, } etc.) but your point is well taken. And no, I can't provide specific } examples, my point is really much simpler than that. } } I think you're overestimating the cost by a considerable amount. I'm } not saying that the cost is zero, but I am saying that it's close enough } that the value of having the information *right there* outweighs the cost. } } Anyone interested in the information will stay interested long enough t } o } look it up in a man page. Even if the cost to the system is very very } small, I think that adding it to the file is silly when it could just as } easily be added to a man page. It's not just as easy for the person looking for the information; it doesn't *get* any easier than having it right there alongside the place you're going to use it. Just because in principle someone can go look up the information somewhere else, doesn't mean that it's not easier and more friendly to [also?] have the information right there in the file. } Of course, there are other benefits to having it in a man page too. The } primary one being that changes/updates to the comments don't require a } change to the file, and would be picked up automatically during a make } world. That is true, but then again this data doesn't change that often. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No elf(5) man page (docs/7914)
* Wes Peters (w...@softweyr.com) [990801 07:12]: Jeroen Ruigrok/Asmodai wrote: * Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]: We have an a.out(5), but no elf(5) (as pointed out in docs/7914). Does anyone feel up to writing one? Saw it before, noticed it, placed on my to-do list. If no-one objects I'll submit a manpage per a.out(5) style tomorrow for review untill it's ready for inclusion. NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^) Same goes for OpenBSD and a lot of Linux distro's as far as I have been able to discern. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Hey kernel hackers, this is worth a read.
On Fri, Jul 30, 1999 at 08:58:09PM -0700, Jordan K. Hubbard j...@zippy.cdrom.com wrote: http://features.linuxtoday.com/stories/8191.html A story on upcoming plans for the Linux 2.4 kernel. Since they're going after a lot of the same performance goals we are, it's worth a read. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Zepeda wrote: The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with real users IMO is quite a bit less hackish. I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. If NIS sends chills down your spine, I guess you could also do a bit of non-daemon-based hackage... make a script replace the home directory and shell fields with appropriate values in a copied passwd and rsync the thing to your mail boxes... Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). As usual, there's more than one way to skin a cat. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). And we do it the other way: Generate the users file from mysql. I rather prefer it like that; then I can still auth users, if mysql goes down. Also, it saved my a$$ once; mysql lacking commit and rollback. I was disturbed into firing off an update command before having typed the where-clause. I then locked the password of every user, instead of only the users belonging to a single client... Luckily, I dump the database every hour, and rcs it, so I can recreate the database at any hourly version the last few months. Leif As usual, there's more than one way to skin a cat. Yeah.. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sun, 1 Aug 1999, Mike Hoskins wrote: As usual, there's more than one way to skin a cat. And as always a bloodless vegetarian way too :) I just don't see any justification in hacking away at all of your software to bypass the passwd database. What is gained? - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message 37a3b701.851df...@softweyr.com Wes Peters writes: : Do we have a list of all services that use bpf? I'm willing to edit the man : pages, given a list. I guess I could just grep-o-matic here, huh? Yes. I'm also in a holding off pattern until we know the exact impact for all daemons that use this... I think I found a solution that may be better (although more complicated): Let the sysadmin to define a bpf filter for the packets that are considered OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for normal functioning). Provide some typical examples. After this filter is defined and the system goes to a higher security level bpf first applies this filter to all the incoming packets, and only if they pass this filter they are checked for application-specified filters. If there is no such master filter defined then bpf can just deny new open()s as proposed earlier. This will allow the applications to use bpf but only for the purposes defined in the master filter. This also resolves the problem of services re-opening bpf after SIGHUP. And speaking on the issue of bpf enabled in GENERIC, I'm strongly pro it. Having bpf disabled is a big pain. May be it would be better to provide a separate prototype configuration file, say, SECURE with all the dangerous things disabled and explanations why they are disabled, so that peoples will think twice before re-enabling them. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No elf(5) man page (docs/7914)
Sheldon Hearn wrote: On Fri, 30 Jul 1999 23:46:26 +0200, Jeroen Ruigrok/Asmodai wrote: If no-one objects I'll submit a manpage per a.out(5) style tomorrow for review untill it's ready for inclusion. Anyone who objects to your submissions is a woes -- real bastards wait for you to do the work before shooting you down. :-) That's correct. I really doubt anyone will raise any objections before the man page is actually committed. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Documenting writev(2) ENOBUFS error
: [ENOBUFS] Insufficient system buffer space exists to complete the op- :eration. : :Do you know what kind of circumstances that error *really* occurs :under? So you can get ENOBUFS not related to mbufs for UDP/local datagram sockets, but you should never get ENOBUFS from write for TCP sockets or local stream sockets. So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. It should probably mention that it doesn't occur for most files (or that it only occurs for datagram sockets - although it probably applies to some types of raw sockets, too, and possibly non-PF_INET/PF_UNIX sockets) to avoid people doing unnecessary checking or implementing kernel code that bails out when it shouldn't. It should be a fair requirement that the kernel continue to never fail with ENOBUFS for a write to a reliable stream (local file, fifo, pipe or stream socket) and that such cases be treated as bugs. I would assume that this corresponds to how other systems operate, as well. Of course I'm no authority on this, and I'm not sure about NFS writes. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Hey kernel hackers, this is worth a read.
Jan B. Koum wrote: On Fri, Jul 30, 1999 at 08:58:09PM -0700, Jordan K. Hubbard j...@zippy.cdrom.com wrote: http://features.linuxtoday.com/stories/8191.html From the article: Linux 2.4 also includes a completely rewritten networking layer. Great. After a few years from now when they get all the bugs out, they will be right back to the quality of early 4.4BSD quality ;) However, the SMP stuff they are working on is something we need IMHO. Agreed on both counts. I also like the idea of shorter turnover time between major branches. We've already got a pretty considerable amount of stuff that can't be ported back to -Stable without major headaches. It's not always easy to know exactly where to draw the line, but I think that the move from 3-4 should probably take less time than the move from 2-3 did. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sun, Aug 01, 1999 at 02:43:28AM -0700, Mike Hoskins wrote: I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. We support NIS, and secure RPC, but not NIS+. Bill Paul was working on it some time back, but I'm not sure if he still is... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Hey kernel hackers, this is worth a read.
On Sun, 1 Aug 1999, Doug wrote: Jan B. Koum wrote: On Fri, Jul 30, 1999 at 08:58:09PM -0700, Jordan K. Hubbard j...@zippy.cdrom.com wrote: http://features.linuxtoday.com/stories/8191.html From the article: Linux 2.4 also includes a completely rewritten networking layer. Great. After a few years from now when they get all the bugs out, they will be right back to the quality of early 4.4BSD quality ;) However, the SMP stuff they are working on is something we need IMHO. Agreed on both counts. I also like the idea of shorter turnover time between major branches. We've already got a pretty considerable amount of stuff that can't be ported back to -Stable without major headaches. It's not always easy to know exactly where to draw the line, but I think that the move from 3-4 should probably take less time than the move from 2-3 did. Aye, and it shall. The 3.X branch should be the -STABLE branch for only about a bit more than a year total, IIRC :) But 4.0 should also include things that aren't even here yet, like pccard rewrites and the redone VFS, maybe a rewrite of ipfw if we can agree on that, the IPv6 stacks being merged in, PAO changes being accepted into the main branch (at least some of them), finer-grained SMP (probably per-subsystem)... The turnaround time will be less, but we'll still have a LOT of great new things :) Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message 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: DOC volunteer WAS:RE: userfs help needed.
Judging by your description, why don't we use LyX? :) LaTeX sounds about right. 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
Proposing argv for klds and preloaded modules
Hello. Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Following url proposes patches to make a new syscall kldload(char *pathname, char **argv, struct kldload *) and keep old way in okldload(pathname). Modules can call module_get_file_argstr(mod) to get these arguments if they so prefer, this is the same with preloaded/kldloaded cases. The third argument, struct kldload, is unused. Arguments are catted together, blank separated, this was the existing way preloading did it (subject to change ?). Patches are against a recent (week ?) -CURRENT, original and modified files are also available. Juha http://qn-lpr2-165.quicknet.inet.fi:22/kldargs/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Documenting writev(2) ENOBUFS error
On Sat, Jul 31, 1999 at 06:50:09PM -0600, Wes Peters wrote: So, do you want to enumerate the cases in which this error can occur in the man page? This is not generally done, now that we have verified it is possible for the system to generate ENOBUFS on a writev. I think the text stands as it is. FWIW, I committed: [ENOBUFS]The mbuf pool has been completely exhausted when writing to a socket ... N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, Aug 01, 1999, Juha Nurmela wrote: Hello. Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? -- |Chris Costello ch...@calldei.com |Advanced design: Upper management doesn't understand it. ` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
On Sun, 1 Aug 1999, Chris Costello wrote: On Sun, Aug 01, 1999, Juha Nurmela wrote: Sometimes it would be handy to pass a commandline to a kld, preloaded modules already support arguments. kldload(2) unfortunately has only the pathname.ko argument. Is this really a problem? Can the administrator not use sysctl instead? Yes, but (this might be a trademark ;) commonly the arguments would be used during the sysinit-attach, and at that time sysctl has not yet been able to change anything. Use of sysctl would require a sidestep from attach and later continuation with a sysctl_proc. Not a problem, but inconvenient, IMHO. And it's analogous to executing, they too can get arguments. Juha To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: no elf(5) man page (docs/7914)
Wes Peters writes: NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^) It'd be cool if Asmodai could bounce this around one of the NetBSD lists once it's near completion. tech-toolchain@ or tech-userlevel@ would be the right place I guess. - ad To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
I've put a new version of stat(1) up for review. I've incorporated a few of the features that were requested. I honestly haven't figured out how to implement the display of selected fields yet. I realize that this isn't a huge step forward over the previous revision, but my hacking hours are limited. Code is available at: http://www.kagekaze.org/stat.tar.gz Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
It's getting better. I don't like that switch (errno) at all. But work on it some more, make it feature-complete., and I'd love to be able to import it. Also, there's a bug: access: Sun Aug 1 13:46:49 1999 Access: Sun Aug 1 00:09:26 1999 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: Was someone looking for a BSD licensed stat(1)?
On Sun, 1 Aug 1999, Keith Stevenson wrote: the features that were requested. I honestly haven't figured out how to implement the display of selected fields yet. I realize that this isn't a Attached is a diff that takes care of that. Basically, the user can specify a format that looks like %f\t%U\t%A to get the files name, the username of the owner, and the last access time seperated by tabs followed by a new line. All of the supported format specifiers are documented in the man page. I looked around for another version of stat that does this but could not locate one; therefore the format specifiers are what made sense to me. There is also limited support for C-style escape sequences (no \nnn). Have a nice day! Jamie diff -c stat/stat.1 stat-jph/stat.1 *** stat/stat.1 Sun Aug 1 23:18:48 1999 --- stat-jph/stat.1 Sun Aug 1 23:50:31 1999 *** *** 42,71 The options are as follows: .Bl -tag -width Fl .It Fl d ! dereference symlinks .It Fl f ! read filenames to be stat-ed from file ( - means stdin) .It Fl g ! show time elements in GMT time zone. (implies -s) .It Fl h ! print usage summary .It Fl i ! ignore errors .It Fl l ! display one element per line .It Fl s ! print mode, uid, gid, and times as strings .It Fl t ! terse output .It Fl o Ar opts ! output only selected elements of struct stat .It Fl f Ar file ! read filenames to be stat-ed from file ( - means stdin) .El .Sh EXAMPLES An example or two will go here .Pp .Sh SEE ALSO .Xr stat 2 .Rs .Sh AUTHORS --- 42,107 The options are as follows: .Bl -tag -width Fl .It Fl d ! Follow symbolic links. .It Fl f ! Read filenames to be stat-ed from file ( - means stdin). .It Fl g ! Show time elements in GMT time zone. (implies -s) .It Fl h ! Print usage summary. .It Fl i ! Ignore errors. .It Fl l ! Display one element per line. .It Fl s ! Print mode, uid, gid, and times as strings. .It Fl t ! Terse output. .It Fl o Ar opts ! Output only selected elements of struct stat. The following ! formatting tags are permitted: ! .Bl -tag -width Fl ! .It Ar %A ! last access time ! .It Ar %C ! file creation time ! .It Ar %G ! file group (group name) ! .It Ar %M ! last modify time ! .It Ar %P ! file permission mode (symbolic) ! .It Ar %U ! file owner (username) ! .It Ar %b ! blocks allocated for file ! .It Ar %d ! device file is on ! .It Ar %f ! file name ! .It Ar %g ! file group (gid) ! .It Ar %i ! inode ! .It Ar %l ! number of hard links to file ! .It Ar %p ! file permission mode (octal) ! .It Ar %s ! file size in blocks ! .It Ar %t ! type of file ! .It Ar %u ! file owner (uid) ! .El .It Fl f Ar file ! Read filenames to be stat-ed from file ( - means stdin). .El .Sh EXAMPLES An example or two will go here .Pp .Sh SEE ALSO + .Xr ls 1 , .Xr stat 2 .Rs .Sh AUTHORS *** *** 73,76 .Sh DIAGNOSTICS Most errors are the result of bad filenames. .Sh BUGS ! Some features (-f, -i, -o) are currently unimplemented --- 109,112 .Sh DIAGNOSTICS Most errors are the result of bad filenames. .Sh BUGS ! Some features (-f and -i) are currently unimplemented diff -c stat/stat.c stat-jph/stat.c *** stat/stat.c Sun Aug 1 23:17:14 1999 --- stat-jph/stat.c Sun Aug 1 23:34:29 1999 *** *** 57,62 --- 57,65 void terseprint(const char*, const char*, const char*, const char*, struct stat*, struct group*, struct passwd*, struct tm*, struct tm*, struct tm*, int); + void customprint(const char *, const char*, const char*, const char*, +const char*, struct stat*, struct group*, struct passwd*, +struct tm*, struct tm*, struct tm*, int); int vstat(const char*, struct stat*, int); *** *** 78,85 struct stat inode; struct tm *atime, *mtime, *ctime; ! extern char *optarg; ! extern int optind; /* flags */ --- 81,87 struct stat inode; struct tm *atime, *mtime, *ctime; ! char *oformat; /* flags */ *** *** 113,122 f_listout = 1; break; case 'o': - printf(Unimplemented.\n); - exit(EX_OK); f_customout = 1; f_listout = 1; break; case 's': f_stringout = 1; --- 115,123 f_listout = 1; break; case 'o': f_customout = 1; f_listout = 1; + oformat = optarg; break; case 's':
Re: Mentioning RFC numbers in /etc/services
In message 19990731161854.11...@hydrogen.fircrest.net John-Mark Gurney writes: : I vote for allowing inetd.conf to specify a port number instead of a : service name... it should be very easy to make the modification, and : I'm willing to do all the work, assuming no one on -committers objects.. I'd love to be able to do this. I have a firewall-like machine that I run services on several different that have no real names... I'm hacking /etc/services now, which is just wrong... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposing argv for klds and preloaded modules
In message pine.bsf.4.05.9908020021290.9676-100...@pena.oh5nxo.ampr.org Juha Nurmela writes: : Yes, but (this might be a trademark ;) commonly the arguments would : be used during the sysinit-attach, and at that time sysctl has not yet : been able to change anything. Use of sysctl would require a sidestep : from attach and later continuation with a sysctl_proc. Not a problem, : but inconvenient, IMHO. And it's analogous to executing, they too : can get arguments. I believe that the plan was to make to have more generic stuff so that all drivers woudln't have to parse argv... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: no elf(5) man page (docs/7914)
* Andy Doran (a...@netbsd.org) [990802 00:53]: Wes Peters writes: NetBSD doesn't have one as of 1.4, so they may be interested in yours. ;^) It'd be cool if Asmodai could bounce this around one of the NetBSD lists once it's near completion. tech-toolchain@ or tech-userlevel@ would be the right place I guess. Will do. I already saw some differences in the stucture member names though, so ye will need to adjust those. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
