Re: replacing grep(1)
John-Mark Gurney wrote: right now, I'm trying to think of a way to eliminate the fgetln searching for end of line... of course this would eliminate some of the simplicity of design, but we can get a BIG speed increase if we simply don't scan for the new line unless we NEED to... and if we do, why not use regexec to search for us? As Dillon said, the decrease in speed of the scan might not be that great. On the other hand, a decent pattern matching algorithm *does not* examine every character (which is why GNU grep performs so much better with bigger patterns). -- 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
:[EMAIL PROTECTED] (Wes Peters) writes: : : [ENOBUFS] Insufficient system buffer space exists to complete the op- :eration. : :Do you know what kind of circumstances that error *really* occurs :under? : :If it happened with files, that would be a bug and should be fixed. :The call is supposed to block to wait for writes to be possible. This I am almost certain that this error can only occur when writing to sockets, and only then of the network mbuf pool is completely exhausted. UDP is probably the most vulernable. It looks to me like it can't happen to stream sockets using write/writev. As far as I can tell, the ENOBUFS error can occur internally for sends if: - There is a shortage of mbufs at a low level (at higher levels, code either blocks or panics) - A network interface has a lot of packets queued (this is done at an IP level) - The socket buffer of a local datagram socket is full (the receiving socket, not the one the send occurred on) The TCP layer doesn't let ENOBUFS from low-level calls get through, but returns success. A TCP socket is prepared to resend the data at a higher level, anyhow, so the data is not lost and an error doesn't need to be returned. OOB data or implicit connections can return ENOBUFS for TCP sends, but they are activated by parameters only available through the send/sendto API. 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. 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] Look, we're obviously not going to convince each other with this discussion. I'm sorry I caused you much trouble by adding it without working it with you first, but I believe the current state is workable for both of us. Can we leave it as it is? * 2. Your INDEX files can frequently be out of date with the ports *collection and someone should be able to do their own "make index" *when that happens. There is a "chopindex" script in ports/Tools/portbuild/scripts that anyone can use to clean up the index file (remove extra dependencies, lines for non-existent packages, etc.). *packages and that is simply not [yet] the case. The INDEX file *certainly isn't for the ports - they already get the dependency *information out of the Makefiles - it's for the packages and for *rudimentary search features. It is for all of them, as well as things like the ports web page. The one I commit is simply one with most information -- you can derive the package index from this one, but not the other way around. * To put it another way, consider me as Bruce and this as a really * egregious style(9) bug on your part. You can argue about it forever, * but it won't make you any less wrong in the end. :) If you want to declare yourself Bruce, go ahead. Then I'm going to take your advice about Bruce-filters and take note to your opinion but respectfully stand by my decision, thank you very much. :) Satoshi 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...
"Jordan K. Hubbard" wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I'm a pro folk. Your machine will have to be compromised before bpf becomes and issue, and once a machine is compromised, it is compromised. The concept of "reducing damage" is an illusion. That's like calling finger a security tool. DHCP is very important nowadays. If anyone wants to delude themselves, they can very well press the "Yes! I want to delude myself." button by removing bpf from the kernel. Besides... is there anyone _seriously_ interested in security using GENERIC? Not that GENERIC is in any way deficient, but why use a kitchen-sink kernel? -- 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
Solution for mail pseudo-users?
Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. 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] Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
[EMAIL PROTECTED]Sergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Alex. -- Alexander B. Povolotsky[ICQ 18277558] [2:5020/145] [http://freebsd.svib.ru] [[EMAIL PROTECTED]] 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 Povolotsky wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. Use Cyrus :) The web pages at http://andrew2.andrew.cmu.edu/cyrus/ are horribly out of date, but the project is still active, and there's recent code in the FTP area. Cheers, Mick The Reverend Jasper P. O'Malley dotdot:[EMAIL PROTECTED] Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji 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.
[ cc'd to -doc, reply-to points there ] On Fri, Jul 30, 1999 at 04:09:20PM -0500, Alton, Matthew wrote: I prefer to work in flat ASCII. Perhaps the doc project can HTMLize the final product. We can, it just takes longer, that's all. It would make life simpler if you can follow the general structure, which basically consists of an overall document, containing zero or more parts, each part containing one or more chapters, each chapter containing zero or more sections, each section divided in to zero or more subsections (and so on, down to sub-sub-sub-sub-sub-sections). Each part, chapter, and section has a mandatory title. The Handbook is a good example of a document that uses parts, further divided in to chapters, and the Doc. Proj. primer is a good example of a document that dispenses with parts, and just uses chapters and sections. Generally, something like Title Abstract . . . Chapter 1: Overview . . . and then further chapters as necessary. Within the text, set off things that are 'out of band' information, like notes, tips, and important information. If you include instructions for the user to follow, please use "#" for the root prompt, and "%" for the regular user prompt. Refer to commands as 'command(n)', and assume that in the web (and PDF) version that will be generated that this will automatically turn in to a link to the manual page. The Doc. Proj. primer has a (sparse) writing style chapter that covers things like contractions, serial commas, and so on. Of course, you don't have to do any of this, it just makes it harder for whoever turns it in to DocBook (which will probably be me) to do the conversion. Once again, thanks for volunteering to do this. 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: So, back on the topic of enabling bpf in GENERIC...
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". That would mean you can't run a secured DHCP server :( -- 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: So, back on the topic of enabling bpf in GENERIC...
On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. 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...
On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote: On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. AFAIK it needs - but rarpd was already mentioned and there are lots of other tools which needs bpf and may reopen bpf. The securelevel is a realy nice feature and I use it often. My problem with it is that I asume the more features are put in the more often users may see that they can't raise it one step higher because of other needs. Maybe a set of sysctls with a switch to off only behavour would be a better way. -- 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: No MAXUID ?
On Fri, 30 Jul 1999, Matthew D. Fuller wrote: On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me that Mike Smith remarked I think that the administrator should be forced to override the warning manually to indicate that they are aware of the issues they are getting themselves in for, or at the very least that there should be some very serious warnings placed in the relevant manpages (mount_nfs, passwd(5), vipw, etc) covering these issues.a How about a bit of a compromise on it? Make pwd_mkdb just spew a warning like --- WARNING: UID(s) over X detected, may cause problems. --- by default, with a flag (-v?) to list the specific ones causing problems. Warning in manpages are, of course, always a Good Thing. I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar file. Then the behavior could be easily configured for your environment with something like "32bit_uid_ok=yes" dirrective in the file. Even an environment variable could work. I have thought about making such a file to avoid recompiling pwd_mkdb with different defaults for large passwd files. The defaults get tiring when using vipw. A save can take 30 seconds on some of our sytstems. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bootloader....
[Cross-posted: replying to -hackers] I'm looking at booting(embedded devices) and I've been looking at lilo boot loader code and booteasy bootloader code... does anyone know of any documentation that anyone out there has done on this topic? -- more specifically without bios calls/support? There is some information in the FreeBSD handbook http://www.freebsd.org/handbook/ for example, "PC Memory Utilization" and "The FreeBSD Booting Process", though much of this is currently out-of-date. Otherwise, as maintainer of the low-level i386 boot code, I can probably help with specific issues. I'm not aware off-hand of any code anywhere that doesn't rely on the BIOS at all, though in some cases (eg. src/sys/i386/boot/netboot) BIOS support could fairly easily be dispensed with, by writing a bit of extra code. I've seen the booteasy code at: ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ is there a newer version? this code is supposed to be compiled with TASM/Borland C right? is there source that can be compiled with gnu tools? See src/sys/boot/i386/boot0 in the FreeBSD source tree. -- Robert Nordier 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...
On Sat, 31 Jul 1999, Ben Rosengart wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. The isc dhcp server doesn't support a -SIGHUP reload, which would mean a reboot everytime you wanted to change the config file. For the average ISP this isn't a problem, for someone who uses dhcp to make configuring servers easier (me) this would suck. However that's an administrator's choice and changing the behavior wouldn't be that difficult. -- - 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
something wrong with malloc ?
Hi everybody, I received a letter from Cron daemon -- Date: Sat, 31 Jul 1999 02:10:00 +0600 (ESS) From: root (Cron Daemon) To: root Subject: Cron root@localhost /usr/libexec/atrun CRON in malloc(): warning: pointer to wrong page. -- surely, I'd like to reproduce it, but I simply do not remember what did was I doing ... anybody else seen it ? suggestions ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
I don't know if my previous send was successfull, so I will send again. MY apollogies if a copy of this email is already/has already been delivered. Alex, You may want to try the patches for qpopper (if this is what you're using) to connect to a MySQL db for this sort of stuff. If you don't like qpopper, implementing these sorts of changes is generally easy and not very time-consuming for most POP daemons that come with the source. Also, a patch for smtp (sendmail+MySQL) is in the works, you may want to look at http://www.colba.net/~paul/projects/ Cheers. _. Bosko Milekic [EMAIL PROTECTED] | Network Operations Delphi SuperNet | http://www.dsuper.net/ an Internet Direct company | +1.514.281.7500, x233 (phone) +1.514.281.6599 (fax) | http://www.dsuper.net/~bmilekic/| _| On Sat, 31 Jul 1999, Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. 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: No MAXUID ?
On Sat, 31 Jul 1999 13:39:16 -0400, Adrian Filipi-Martin wrote: I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar file. Eeeuw! :-) I'm not in favour of this idea, but issuing a single warning for one or more UID's encountered isn't behaviour that would make retrofitting your idea impossible if you decided to do it later. While warnings and error messages should give me enough information to address a problem efficiently (something on the wishlist of any Wintendo administrator), once I know there is more than zero potentially problematic entries, I can used cat, awk and sh to find all the culprits if I want to. Ciao, Sheldon. PS: Those two paragraphs have nothing to do with each other, by the way. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
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. 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! 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 far, I've had some great advice on this issue (although I think it's time the thread took a long walk off a short pier), so I definitely have my ears open. I'm just having trouble either understanding or believing what I'm hearing. :-) Ciao, Sheldon. 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)
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. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Fri, 30 Jul 1999 22:07:26 -0400, Tim Vanderhoek wrote: b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null b$ time grep '(vt100)|(printer)' longfile /dev/null You think that's fair? Surely you can't expect Jamie's extended regex support to outperform GNU's simple regex support? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
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? That behaviour is a function of laziness, rather than principle. If I'm correct in my suspicion that most people only meddle with /etc/services to appease inetd's harvest of sown laziness, then the effort required to change the current behaviour will be worthwhile. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is the _Device Driver Writers Guide_ still apropos?
* Nik Clayton ([EMAIL PROTECTED]) [990801 00:35]: How does the attached patch grab you? I think it perfect... Now to find the time to wrote the sucker ;) -- 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 scribbled this message on Aug 1: Would you need these entries if inetd let you specify port numbers instead of service names? 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.. -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson 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...
In message [EMAIL PROTECTED] Christopher Masto writes: : I hope you mean " 1". I often diagnose problems using tcpdump etc., : and I don't think bpf should be broken just because someone wants the : minor "flags can't be turned off" feature of level 1. Flags can't be turned off at level 1, and raw devices cannot be accessed: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing. Notice that raw devices cannot be opened... : It seems to be that disabling bpf is more appropriate for security : level 2 and up, if such a thing is desirable. I'm not sure it is. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. and 3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted. I could see arguments for both levels Warner 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...
In message [EMAIL PROTECTED] Bernd Walter writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : That would mean you can't run a secured DHCP server :( No. That would mean you'd have to start DHCP before raising the secure level. *THAT* is acceptible, unless restarting the dhcp server is a normal thing to do. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote: b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null b$ time grep '(vt100)|(printer)' longfile /dev/null You think that's fair? Surely you can't expect Jamie's extended regex support to outperform GNU's simple regex support? :-) GNU has no simple regex support. Actually, neither did Jamie's by the time I did that test, but I added the -E flag to make it obvious what was going on. :) I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. -- 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: Solution for mail pseudo-users?
Hi Alex, Alex Povolotsky [EMAIL PROTECTED] wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. cucipop is fairly simple to modify (it's well structured for change) and I've managed to hack in bits of merit radius client code into it once or twice -- to authenticate POP clients from the local radius server... sendmail local delivery was a pain, I ended up fudging that with an additional aliases file mapping names to files (ugh!)... Cheers Leigh -- | "By the time they had diminished | Leigh Hart, [EMAIL PROTECTED] | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | 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...
"Jordan K. Hubbard" wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Pro: it's not a vulnerability unless somebody has already cracked root. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] 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...
"Brian F. Feldman" wrote: On Fri, 30 Jul 1999, Brian F. Feldman wrote: In that case, my argument changes to: "There's no good reason not to have bpf in the GENERIC kernel." And how about having if (securelevel 3) return (EPERM); in bpf_open()? I like this. Nice one, Greenie! ;^) Now stop replying to yourself, it's too much like... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] 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] "Jordan K. Hubbard" writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Zounds good to me. This should be simple enough even *I* could handle it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] 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...
Matthew Dillon wrote: : consistant with the meaning of "raw devices". : :Disabling bpf it will break rarpd (and also rbootd but it is less :important). I think such a thing should be mentioned in documentation. : :-SB Not if rarpd is started via the rc files... it would hook up to bpf prior to the securelevel being raised. But I agree about the documentation. The various server documentation as well as the inetd documentation should mention that bpf-using servers need to be started from the rc's when securelevel is used. 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? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
On Sat, 31 Jul 1999, Tim Vanderhoek wrote: I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. If it is not, how about linking it with libregex? I realize it is GNU too, but it will be there whether or not grep gets replaced and the authors were at least kind enough to LGPL it instead. Hey, maybe someone who knows more about regular expressions than I do would feel compelled to rewrite GNU regex... :) I bet the existing Spencer libraries would be a good starting point and maybe the rumored new version is a great starting point... But that's enough hint dropping... Jamie 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: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 issue 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). 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. Doug 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fw: thunks
- jir ji jimaria j...@logx.com irc#tokyo15 icq jir 3941247- http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi VAIO PCG-C1 FreeBSD be late sorry Thunks kindness to Mr Dirk GOUDERS From: Dirk GOUDERS h...@musashi.et.bocholt.fh-ge.de Subject: Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 Starfire ethernet controller driver and plus question compaq presario dec et Date: Thu, 22 Jul 1999 09:55:05 +0200 o.k., Bill, I'll try to translate it for you: To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
John-Mark Gurney wrote: right now, I'm trying to think of a way to eliminate the fgetln searching for end of line... of course this would eliminate some of the simplicity of design, but we can get a BIG speed increase if we simply don't scan for the new line unless we NEED to... and if we do, why not use regexec to search for us? As Dillon said, the decrease in speed of the scan might not be that great. On the other hand, a decent pattern matching algorithm *does not* examine every character (which is why GNU grep performs so much better with bigger patterns). -- 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
:w...@softweyr.com (Wes Peters) writes: : : [ENOBUFS] Insufficient system buffer space exists to complete the op- :eration. : :Do you know what kind of circumstances that error *really* occurs :under? : :If it happened with files, that would be a bug and should be fixed. :The call is supposed to block to wait for writes to be possible. This I am almost certain that this error can only occur when writing to sockets, and only then of the network mbuf pool is completely exhausted. UDP is probably the most vulernable. It looks to me like it can't happen to stream sockets using write/writev. As far as I can tell, the ENOBUFS error can occur internally for sends if: - There is a shortage of mbufs at a low level (at higher levels, code either blocks or panics) - A network interface has a lot of packets queued (this is done at an IP level) - The socket buffer of a local datagram socket is full (the receiving socket, not the one the send occurred on) The TCP layer doesn't let ENOBUFS from low-level calls get through, but returns success. A TCP socket is prepared to resend the data at a higher level, anyhow, so the data is not lost and an error doesn't need to be returned. OOB data or implicit connections can return ENOBUFS for TCP sends, but they are activated by parameters only available through the send/sendto API. 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. 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?
* From: Jordan K. Hubbard j...@zippy.cdrom.com Look, we're obviously not going to convince each other with this discussion. I'm sorry I caused you much trouble by adding it without working it with you first, but I believe the current state is workable for both of us. Can we leave it as it is? * 2. Your INDEX files can frequently be out of date with the ports *collection and someone should be able to do their own make index *when that happens. There is a chopindex script in ports/Tools/portbuild/scripts that anyone can use to clean up the index file (remove extra dependencies, lines for non-existent packages, etc.). *packages and that is simply not [yet] the case. The INDEX file *certainly isn't for the ports - they already get the dependency *information out of the Makefiles - it's for the packages and for *rudimentary search features. It is for all of them, as well as things like the ports web page. The one I commit is simply one with most information -- you can derive the package index from this one, but not the other way around. * To put it another way, consider me as Bruce and this as a really * egregious style(9) bug on your part. You can argue about it forever, * but it won't make you any less wrong in the end. :) If you want to declare yourself Bruce, go ahead. Then I'm going to take your advice about Bruce-filters and take note to your opinion but respectfully stand by my decision, thank you very much. :) Satoshi 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...
Jordan K. Hubbard wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I'm a pro folk. Your machine will have to be compromised before bpf becomes and issue, and once a machine is compromised, it is compromised. The concept of reducing damage is an illusion. That's like calling finger a security tool. DHCP is very important nowadays. If anyone wants to delude themselves, they can very well press the Yes! I want to delude myself. button by removing bpf from the kernel. Besides... is there anyone _seriously_ interested in security using GENERIC? Not that GENERIC is in any way deficient, but why use a kitchen-sink kernel? -- 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
Solution for mail pseudo-users?
Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. 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 37a25361.34799...@bellatlantic.net Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Alex. -- Alexander B. Povolotsky[ICQ 18277558] [2:5020/145] [http://freebsd.svib.ru] [tark...@asteroid.svib.ru] 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 Povolotsky wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. Use Cyrus :) The web pages at http://andrew2.andrew.cmu.edu/cyrus/ are horribly out of date, but the project is still active, and there's recent code in the FTP area. Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jo...@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji 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.
[ cc'd to -doc, reply-to points there ] On Fri, Jul 30, 1999 at 04:09:20PM -0500, Alton, Matthew wrote: I prefer to work in flat ASCII. Perhaps the doc project can HTMLize the final product. We can, it just takes longer, that's all. It would make life simpler if you can follow the general structure, which basically consists of an overall document, containing zero or more parts, each part containing one or more chapters, each chapter containing zero or more sections, each section divided in to zero or more subsections (and so on, down to sub-sub-sub-sub-sub-sections). Each part, chapter, and section has a mandatory title. The Handbook is a good example of a document that uses parts, further divided in to chapters, and the Doc. Proj. primer is a good example of a document that dispenses with parts, and just uses chapters and sections. Generally, something like Title Abstract . . . Chapter 1: Overview . . . and then further chapters as necessary. Within the text, set off things that are 'out of band' information, like notes, tips, and important information. If you include instructions for the user to follow, please use # for the root prompt, and % for the regular user prompt. Refer to commands as 'command(n)', and assume that in the web (and PDF) version that will be generated that this will automatically turn in to a link to the manual page. The Doc. Proj. primer has a (sparse) writing style chapter that covers things like contractions, serial commas, and so on. Of course, you don't have to do any of this, it just makes it harder for whoever turns it in to DocBook (which will probably be me) to do the conversion. Once again, thanks for volunteering to do this. 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: Solution for mail pseudo-users?
Alex Povolotsky wrote: 37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Try Postfix instead of sendmail. It will come out much easier. -- 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: So, back on the topic of enabling bpf in GENERIC...
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. That would mean you can't run a secured DHCP server :( -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de 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...
On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. 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...
On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote: On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. AFAIK it needs - but rarpd was already mentioned and there are lots of other tools which needs bpf and may reopen bpf. The securelevel is a realy nice feature and I use it often. My problem with it is that I asume the more features are put in the more often users may see that they can't raise it one step higher because of other needs. Maybe a set of sysctls with a switch to off only behavour would be a better way. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
On Fri, 30 Jul 1999, Matthew D. Fuller wrote: On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me that Mike Smith remarked I think that the administrator should be forced to override the warning manually to indicate that they are aware of the issues they are getting themselves in for, or at the very least that there should be some very serious warnings placed in the relevant manpages (mount_nfs, passwd(5), vipw, etc) covering these issues.a How about a bit of a compromise on it? Make pwd_mkdb just spew a warning like --- WARNING: UID(s) over X detected, may cause problems. --- by default, with a flag (-v?) to list the specific ones causing problems. Warning in manpages are, of course, always a Good Thing. I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar file. Then the behavior could be easily configured for your environment with something like 32bit_uid_ok=yes dirrective in the file. Even an environment variable could work. I have thought about making such a file to avoid recompiling pwd_mkdb with different defaults for large passwd files. The defaults get tiring when using vipw. A save can take 30 seconds on some of our sytstems. Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bootloader....
[Cross-posted: replying to -hackers] I'm looking at booting(embedded devices) and I've been looking at lilo boot loader code and booteasy bootloader code... does anyone know of any documentation that anyone out there has done on this topic? -- more specifically without bios calls/support? There is some information in the FreeBSD handbook http://www.freebsd.org/handbook/ for example, PC Memory Utilization and The FreeBSD Booting Process, though much of this is currently out-of-date. Otherwise, as maintainer of the low-level i386 boot code, I can probably help with specific issues. I'm not aware off-hand of any code anywhere that doesn't rely on the BIOS at all, though in some cases (eg. src/sys/i386/boot/netboot) BIOS support could fairly easily be dispensed with, by writing a bit of extra code. I've seen the booteasy code at: ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ is there a newer version? this code is supposed to be compiled with TASM/Borland C right? is there source that can be compiled with gnu tools? See src/sys/boot/i386/boot0 in the FreeBSD source tree. -- Robert Nordier 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...
On Sat, 31 Jul 1999, Ben Rosengart wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. The isc dhcp server doesn't support a -SIGHUP reload, which would mean a reboot everytime you wanted to change the config file. For the average ISP this isn't a problem, for someone who uses dhcp to make configuring servers easier (me) this would suck. However that's an administrator's choice and changing the behavior wouldn't be that difficult. -- - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
something wrong with malloc ?
Hi everybody, I received a letter from Cron daemon -- Date: Sat, 31 Jul 1999 02:10:00 +0600 (ESS) From: root (Cron Daemon) To: root Subject: Cron r...@localhost /usr/libexec/atrun CRON in malloc(): warning: pointer to wrong page. -- surely, I'd like to reproduce it, but I simply do not remember what did was I doing ... anybody else seen it ? suggestions ? Regards, (Наилучшие пожелания) Ilia Chipitsine (Илья Шипицин) 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...
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. I hope you mean 1. I often diagnose problems using tcpdump etc., and I don't think bpf should be broken just because someone wants the minor flags can't be turned off feature of level 1. It seems to be that disabling bpf is more appropriate for security level 2 and up, if such a thing is desirable. I'm not sure it is. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
I don't know if my previous send was successfull, so I will send again. MY apollogies if a copy of this email is already/has already been delivered. Alex, You may want to try the patches for qpopper (if this is what you're using) to connect to a MySQL db for this sort of stuff. If you don't like qpopper, implementing these sorts of changes is generally easy and not very time-consuming for most POP daemons that come with the source. Also, a patch for smtp (sendmail+MySQL) is in the works, you may want to look at http://www.colba.net/~paul/projects/ Cheers. _. Bosko Milekic bmile...@dsuper.net | Network Operations Delphi SuperNet | http://www.dsuper.net/ an Internet Direct company | +1.514.281.7500, x233 (phone) +1.514.281.6599 (fax) | http://www.dsuper.net/~bmilekic/| _| On Sat, 31 Jul 1999, Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. 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: Is the _Device Driver Writers Guide_ still apropos?
On Fri, Jul 30, 1999 at 11:48:47PM +0200, Jeroen Ruigrok/Asmodai wrote: * Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]: Is the FreeBSD Device Driver Writers Guide at http://www.freebsd.org/tutorials/ddwg/ddwg.html still correct? I know there have been changes to this area of the tree over the past 6 months or so, but I don't know how much of that document is still appropriate for what we have now. As far as I have been able to learn and glance from Bill Paul and some other device driver guru's too much has changed in order for it to be correct under CURRENT. A rewrite is on my to-do list for the PDP, however, should people feel like they want to rewrite it, be my guest and cc: me on any submissions so I can include it in the PDP. Else I will start this ASAHP. How does the attached patch grab you? 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 Index: ddwg.sgml === RCS file: /home/ncvs/doc/en/tutorials/ddwg/ddwg.sgml,v retrieving revision 1.6 diff -u -r1.6 ddwg.sgml --- ddwg.sgml 1998/06/18 13:20:41 1.6 +++ ddwg.sgml 1999/07/31 18:25:12 @@ -28,6 +28,13 @@ toc +sect2.x specific + +pDue to changes in FreeBSD over time, this guide is only accurate as +regards FreeBSD 2.x. A replacement guide for FreeBSD 3.x and beyond +is being written. Please contact Jeroen Ruigrok tt/lt;asmo...@wxs.nlgt;/ +if you would like to help with this. + sect Overview p it
Re: No MAXUID ?
On Sat, 31 Jul 1999 13:39:16 -0400, Adrian Filipi-Martin wrote: I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar file. Eeeuw! :-) I'm not in favour of this idea, but issuing a single warning for one or more UID's encountered isn't behaviour that would make retrofitting your idea impossible if you decided to do it later. While warnings and error messages should give me enough information to address a problem efficiently (something on the wishlist of any Wintendo administrator), once I know there is more than zero potentially problematic entries, I can used cat, awk and sh to find all the culprits if I want to. Ciao, Sheldon. PS: Those two paragraphs have nothing to do with each other, by the way. :-) 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
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. 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! 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 far, I've had some great advice on this issue (although I think it's time the thread took a long walk off a short pier), so I definitely have my ears open. I'm just having trouble either understanding or believing what I'm hearing. :-) Ciao, Sheldon. 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)
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. :-) 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 Fri, 30 Jul 1999 22:07:26 -0400, Tim Vanderhoek wrote: b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null b$ time grep '(vt100)|(printer)' longfile /dev/null You think that's fair? Surely you can't expect Jamie's extended regex support to outperform GNU's simple regex support? :-) Ciao, Sheldon. 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
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? That behaviour is a function of laziness, rather than principle. If I'm correct in my suspicion that most people only meddle with /etc/services to appease inetd's harvest of sown laziness, then the effort required to change the current behaviour will be worthwhile. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
Mike Smith writes: v2 NFS doesn't support UIDs 65535, and UIDs around that number are magic to it as well. There are serious security issues here (files will appear to be owned by the wrong user). Hmm, isn't this a separate bug in itself (unrelated to pwd_mkdb)? Ie, somewhere in the kernel there should be a check for UID wrap that generates an error if detected. At least on the server; on the client of course it would be too late. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
I'd be in favor of adding a /etc/pwd_mkdb.conf or some similar file. ... While warnings and error messages should give me enough information to address a problem efficiently (something on the wishlist of any Wintendo administrator), once I know there is more than zero potentially problematic entries, I can used cat, awk and sh to find all the culprits if I want to. What we are looking at is a warning for potential problems with legacy tools. Yet another configuration file is not going to make our life any easier. What Sheldon proposed was to get rid of n-1 messages out of n. Maybe there is a good reason to have a config file, but this does not sound like one. Nick -- e-Mail: hi...@skylink.it 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 (sheld...@uunet.co.za) [990801 00:35]: 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. :-) Now, that gives me a good feeling =P I already started work on it... -- 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: Is the _Device Driver Writers Guide_ still apropos?
* Nik Clayton (n...@freebsd.org) [990801 00:35]: How does the attached patch grab you? I think it perfect... Now to find the time to wrote the sucker ;) -- 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: Mentioning RFC numbers in /etc/services
Sheldon Hearn scribbled this message on Aug 1: Would you need these entries if inetd let you specify port numbers instead of service names? 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.. -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought. -- Ralph Waldo Emerson 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...
In message 19990731193410.c18...@cicely8.cicely.de Bernd Walter writes: : Maybe a set of sysctls with a switch to off only behavour would be a : better way. Actually, a better way would be to have the interfaces to the network stack that would handle this stuff w/o needing to resort to bpf. Warner 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...
In message 19990731154458.a2...@netmonger.net Christopher Masto writes: : I hope you mean 1. I often diagnose problems using tcpdump etc., : and I don't think bpf should be broken just because someone wants the : minor flags can't be turned off feature of level 1. Flags can't be turned off at level 1, and raw devices cannot be accessed: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing. Notice that raw devices cannot be opened... : It seems to be that disabling bpf is more appropriate for security : level 2 and up, if such a thing is desirable. I'm not sure it is. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. and 3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted. I could see arguments for both levels Warner 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...
In message 19990731190814.a18...@cicely8.cicely.de Bernd Walter writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of raw devices. : That would mean you can't run a secured DHCP server :( No. That would mean you'd have to start DHCP before raising the secure level. *THAT* is acceptible, unless restarting the dhcp server is a normal thing to do. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
On Sat, Jul 31, 1999 at 11:56:16PM +0200, Sheldon Hearn wrote: b$ time ./grep -E '(vt100)|(printer)' longfile /dev/null b$ time grep '(vt100)|(printer)' longfile /dev/null You think that's fair? Surely you can't expect Jamie's extended regex support to outperform GNU's simple regex support? :-) GNU has no simple regex support. Actually, neither did Jamie's by the time I did that test, but I added the -E flag to make it obvious what was going on. :) I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. -- 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: Solution for mail pseudo-users?
Hi Alex, Alex Povolotsky tark...@asteroid.svib.ru wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. cucipop is fairly simple to modify (it's well structured for change) and I've managed to hack in bits of merit radius client code into it once or twice -- to authenticate POP clients from the local radius server... sendmail local delivery was a pain, I ended up fudging that with an additional aliases file mapping names to files (ugh!)... Cheers Leigh -- | By the time they had diminished | Leigh Hart, h...@dotat.com | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ... | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, The Far Side | http://www.dotat.com/hart/ | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Oh yeah, and check out the jail code (sections 2 and 4, I *think* -CURRENT only). - alex 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 Povolotsky wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. 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. - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: 37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? You can unload the user list from mySQL into a Berkeley db file and modify /etc/sendmail.cf to route the mail for the users listed in this file to a special delivery agent. And this special delivery agent would be a quite straightforward modification of /usr/libexec/mail.local. A variation of this would be to modify mail.local to add the data from mySQL database to getpwent, just like POP3 does, and instruct sendmail to process the mail for the extra users by mail.local. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Documenting writev(2) ENOBUFS error
Ville-Pertti Keinonen wrote: :w...@softweyr.com (Wes Peters) writes: : : [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. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.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)
Jeroen Ruigrok/Asmodai wrote: * Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]: Hi folks, 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. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com 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...
Jordan K. Hubbard wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Pro: it's not a vulnerability unless somebody has already cracked root. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com 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...
Brian F. Feldman wrote: On Fri, 30 Jul 1999, Brian F. Feldman wrote: In that case, my argument changes to: There's no good reason not to have bpf in the GENERIC kernel. And how about having if (securelevel 3) return (EPERM); in bpf_open()? I like this. Nice one, Greenie! ;^) Now stop replying to yourself, it's too much like... -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com 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 9518.933378...@zippy.cdrom.com Jordan K. Hubbard writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of raw devices. : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Zounds good to me. This should be simple enough even *I* could handle it. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com 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...
Matthew Dillon wrote: : consistant with the meaning of raw devices. : :Disabling bpf it will break rarpd (and also rbootd but it is less :important). I think such a thing should be mentioned in documentation. : :-SB Not if rarpd is started via the rc files... it would hook up to bpf prior to the securelevel being raised. But I agree about the documentation. The various server documentation as well as the inetd documentation should mention that bpf-using servers need to be started from the rc's when securelevel is used. 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? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com 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...
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... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
On Sat, 31 Jul 1999, Tim Vanderhoek wrote: I rather hope that the rumoured newer version of H. Spencer's regex lib is faster... Being as slow for that pattern as it is has got to be a bug of some sort... It's actually faster to scan the file twice, once for the first string and then for the second. If it is not, how about linking it with libregex? I realize it is GNU too, but it will be there whether or not grep gets replaced and the authors were at least kind enough to LGPL it instead. Hey, maybe someone who knows more about regular expressions than I do would feel compelled to rewrite GNU regex... :) I bet the existing Spencer libraries would be a good starting point and maybe the rumored new version is a great starting point... But that's enough hint dropping... Jamie 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
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 issue 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). 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. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
